À propos de ce site

D’où vient le jugement

Écrire sous pseudonyme ne veut pas dire sortir de nulle part. Derrière les initiales, il y a un ingénieur logiciel de formation, avec près de dix ans de métier : de vrais systèmes en production, des bases de code complexes, conçues, construites, déboguées et maintenues à la main. Le premier tronçon de cette carrière s’est déroulé entièrement avant les assistants d’IA, et cela s’est révélé un cadeau. Le jugement sur lequel tourne ce site, ce qui casse, ce qui tient à l’échelle, ce qu’un changement coûte vraiment, s’est construit sans modèle à qui poser la question.

Le goût d’ingénierie hérité de ces années n’a rien de spectaculaire : la solution la plus simple qui fonctionne, de petites abstractions, et une planification à six mois environ, pas plus. De tout le code écrit au fil des ans pour faciliter une extension future, une pièce sur vingt, peut-être, a fini par être étendue. Les activités changent de cap, les projets s’achèvent ou s’arrêtent, et personne ne revient pour les todos. L’obsession du détail va là où elle rapporte : la dernière passe de relecture, la formulation exacte d’une contrainte, la configuration ennuyeuse qui décide si un outil se tient.

L’intérêt pour l’IA est plus ancien que les produits. Il y a eu des cours de machine learning et d’IA pendant les études, et des lectures sur le sujet bien avant que ce soit une chose normale. Puis ChatGPT est sorti, et c’était ce que ce domaine avait produit de plus proche de la magie. Le flux de travail d’ici a traversé toutes les phases depuis : copier des extraits entre un chat du navigateur et l’éditeur, le premier Copilot qui ne faisait que compléter, le chat qui arrive dans l’IDE, la période où personne ne savait dire si GPT, Gemini ou Claude menait, et maintenant des agents qui travaillent dans le terminal.

L’objectif n’a jamais bougé : pas une IA qui construit le produit toute seule, mais un ingénieur rendu plus rapide et plus précis, avec des outils configurés avec assez de soin pour faire le moins d’erreurs possible. Ce travail de configuration, quoi déléguer, quoi garder, comment formuler les garde-fous, est l’essentiel de ce qui s’écrit ici.

Ce que vous trouverez

Quatre types d’articles. Des analyses quand un labo sort un modèle, centrées sur la pratique plutôt que sur le communiqué de presse. Des lectures de benchmarks qui confrontent les chiffres à l’expérience réelle. Des expériences tirées des montages de l’auteur, de la gestion du contexte aux agents qui se délèguent du travail dans le terminal. Et des guides pour utiliser ces outils au quotidien.

Comment c’est écrit

Tout part de l’usage réel. L’auteur passe l’essentiel de ses journées dans ces outils et écrit à la première personne à partir de cette expérience. Les opinions apparaissent quand elles ont été gagnées, et elles sont signalées comme telles.

L’anglais fait référence. Chaque article paraît aussi en espagnol, en allemand, en français, en italien et en portugais, traduit avec soin plutôt que passé à la machine et oublié.

Les sources

Chaque affirmation factuelle renvoie à une source numérotée : papiers de recherche, annonces officielles, changelogs, dépôts de benchmarks. Ce qui ne peut être ni sourcé ni reproduit n’est pas publié. Et quand les chiffres contredisent l’expérience vécue, l’article le dit.

Corrections

Les erreurs sont corrigées dans l’article lui-même. Quand une erreur factuelle apparaît, le texte est corrigé et la date de mise à jour affichée en haut de la page change avec lui, pour que vous voyiez toujours que quelque chose a bougé.

Les retouches cosmétiques, une coquille ou une phrase plus claire, ne touchent jamais à cette date. Rien n’est réécrit en silence pour paraître juste après coup : si une affirmation se révèle fausse, la correction dit ce qui a changé.