Tableau de synthèse de la section : quatre angles morts du discours dominant sur la productivité IA, chacun avec son chiffre-clé et sa source.</caption>
Ce que les métriques ratent</th>	Chiffre-clé</th>	Source</th> </tr> </thead>
Perception ≠</span> réalité</th>	−19 %</span> vs +24 % attendu</span> </td>	METR ^{3</a></sup></span></td> </tr>}
Rédaction ≠</span> livraison</th>	+91 % / +98 %</span> revue · PR créées</span> </td>	Faros ^{4</a></sup></span></td> </tr>}
Dette technique invisible</th>	8,3 % → 12,3 %</span> part de copy-paste, 2020 → 2024</span> </td>	GitClear ^{5</a></sup> + DORA 6</a></sup></span></td> </tr>}
Success ≠</span> incident</th>	45 %</span> du code IA = ≥ 1 CVE OWASP</span> </td>	Veracode ^{9</a></sup></span></td> </tr> </tbody> </table> Quatre lignes, quatre études indépendantes : METR (expérience contrôlée), Faros (télémétrie 22 000 devs), GitClear + DORA (211 M lignes + benchmark décennal), Veracode (audit GenAI 2025).</span> </figcaption> Voir la figure 7 sur le site ↗</a> </figure> La vitesse n'est pas la précipitation</h2> Lorsqu'on compare le temps de trajet en avion ou en voiture, on compare de porte à porte plutôt que le temps passé dans le véhicule. C'est la vitesse. Sauter dans le premier bus arrivé et se rendre compte que ce n'est pas la bonne direction, c'est de la précipitation. Automatiser une tâche de développement peut relever de l'un ou de l'autre. L'IA ne fait pas la différence entre les deux. C'est le développeur qui décide où et comment l'utiliser. Personne n'aime s'apercevoir que la mémoire de Claude Code a mélangé le nom d'un client avec un autre le jour de la démo. Cet arbitrage régulier prend du temps. Un temps incompressible mais indispensable qui se prend avant d'écrire. C'est le temps nécessaire à la qualité. Si je devais résumer en deux formules :</p> Précipitation</span> =</span> accélération</span> −</span> attention</span> </span> </p> Vitesse</span> =</span> accélération</span> +</span> réflexion</span> +</span> qualité</span> </span> </p> </div> Avant l'IA, nous passions 10 % de notre temps à écrire du code, et 90 % à le relire, le concevoir, y réfléchir, le réorganiser et aller lire de la documentation. Si nous possédons un outil qui peut accélérer ces 10 %, le gain est faible à long terme. Il ne peut être pérenne qu'à deux conditions : savoir accélérer une part des 90 % et investir plus de temps sur ce qu'on n'accélère pas.</p> Ce qui vient ensuite</h2> Avec daily-ops, j'avais identifié le logiciel accidentel et ajouté la structure dès le 25 avril. Ce matin encore, quatre semaines plus tard, je corrigeais un bug né des premiers jours. La discipline ne suffit pas à effacer la précipitation initiale.</p> Si la vitesse mesurée n'est pas la productivité réelle, et si la discipline n'efface pas la précipitation, alors la question devient : qu'est-ce que l'IA m'apporte vraiment</em> ? Ce sera l'objet du second article.</p> Note méthodique — quatre biais</h2> Article basé sur mes recherches personnelles, dont je partage les sources. J'attire l'attention sur quatre biais qui peuvent creuser un écart entre nos points de vue :</p> Early-adopter</strong> : la nature et le nombre d'années de mon expérience ont une influence. Nos domaines, niveau de responsabilité et organisation varient. J'essaie de me renseigner et de prendre en compte le panel le plus large possible, et suis conscient que ma vision a des angles morts.</li> Temporalité</strong> : certaines études citées ont plus d'un an en mai 2026. Le domaine de l'IA change assez vite pour que les données aient déjà perdu du sens. J'ai sélectionné les sources qui sont, à ma connaissance, toujours valables.</li> Sélection des incidents</strong> : je ne traite pas ici les incidents où l'IA n'est qu'un démultiplicateur d'une faute humaine évidente — supprimer la base de prod sans backup, exposer des credentials sans audit. Ces cas existent en abondance, mais ils racontent moins l'IA que la pratique qui l'entoure.</li> Mes croyances et connaissances</strong> : j'écris en faveur d'une pratique que j'ai adoptée. Y adhérer ou pas peut donner une compréhension différente de mes propos. Sur ce biais en particulier, à vous de faire la part des choses.</li> </ol> Notes et références</h2> ^{1</sup> Second Talent, AI Coding Assistant Statistics & Trends [2025]</em></a>, secondtalent.com, 2025.</p> </div> ^2</sup>Stack Overflow, Developer Survey 2025</em></a>, stackoverflow.co.</p> </div> ^3</sup>Becker, J. et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity</em></a>, METR, arXiv:2507.09089, juillet 2025 (résumé METR</a>).</p> </div> ^4</sup>Faros AI, The AI Productivity Paradox Research Report</em></a>, faros.ai, 2025.</p> </div> ^5</sup>GitClear, AI Copilot Code Quality 2025 Research Report</em></a>, gitclear.com, février 2025.</p> </div> ^6</sup>Google, Accelerate State of DevOps Report 2024</em></a>, dora.dev.</p> </div> ^7</sup>Solar-Lezama, A., interview au Wall Street Journal</em></a>, citée dans DevOps.com</a>, AI in Software Development: Productivity at the Cost of Code Quality?</em>, 2025.</p> </div> ^8</sup>Vibe Coder Blog, Security Researchers Sound the Alarm on AI Code Vulnerabilities</em></a>, blog.vibecoder.me, avril 2026 ; voir aussi CVE-2025-48757</a>.</p> </div> ^9</sup>Veracode, 2025 GenAI Code Security Report</em></a>, veracode.com.</p> </div> ^10</sup>SoftwareSeni, analyse de Veracode 2025 et Apiiro</a>, softwareseni.com, février 2026.</p> </div> ^11</sup>Futurity, AI-generated code is vulnerable</em></a>, futurity.org, 2026.</p> </div> Pourquoi ce site, et pourquoi maintenant 2026-05-22T00:00:00+00:00 Un été, à 9 ou 10 ans, je tenais un hors-série du magazine Tilt</em> avec des listings en BASIC. J'ai encore la couverture en tête. Avec mon frère, nous avons copié plusieurs pages de code sur notre Thomson TO9. Par séances de trente minutes à une heure, l'un dictait et relisait pendant que l'autre tapait ce programme que nous ne comprenions qu'à moitié. On a fini par abandonner. Vers la fin des vacances, j'ai repris le hors-série et j'ai terminé seul. J'ai enfin pu lancer le programme. La forme du billard et quelques billes s'affichaient. Mais un grand trait au milieu de l'écran montrait qu'il y avait eu des erreurs de recopie. Le jeu ne répondait à rien.</p> FIG. 1 · Couverture Tilt — Micro-Jeux</em>, HS 05, août 1987 · scan abandonware-magazines</a></figcaption> </figure> Patiemment, j'ai relu et comparé, me rendant compte que certains numéros de ligne en BASIC avaient été décalés. Je démarrais le programme à nouveau, voyant parfois un changement, parfois des erreurs de syntaxe nouvelles. J'ai corrigé avec le listing. Il était plus fiable que mes déductions. L'erreur venait de la transcription. Le programme, lui, fonctionnait. La rentrée approchant, j'ai laissé tomber. Je n'avais plus envie de revenir dessus.</p> Le décor de cet été-là s'était posé quelques années plus tôt. J'apprenais à lire et à écrire quand mes parents nous ont offert ce Thomson TO9</a>, sur lequel j'ai découvert le BASIC. À cet âge, je pouvais lire tout seul Un éléphant ça compte énormément</em> d'Helme Heine. Je collais une étiquette en minuscules cursives garage de clarke</em>, et racontais « Clarke a accéléré droit vers le tremplin. Il a pris son envol et atterri de l'autre côté de la rivière. Il avait échappé à l'avalanche. »</em> Je tapais à deux doigts des GOTO infinis, un jeu « nombre secret »</em> avec des IF/PRINT/INPUT. J'essayais de dessiner un polygone avec POINT/LINE — il s'avérait mal fermé à l'affichage.</p> FIG. 2 · Helme Heine, Un éléphant ça compte énormément</em>, Gallimard Jeunesse, coll. folio benjamin.</figcaption> </figure> Ce qu'un enfant ne pouvait pas deviner, c'était comment ces trois gestes allaient n'en faire qu'un. Le code, la lecture, l'écriture : une seule discipline.</p> Cette discipline est l'alignement de la pensée avec l'écrit</mark> . J'en ai appris l'exigence par le code, mais elle dépasse le code. Ce site existe pour incarner cette exigence, par des objets concrets : outils, écrits, prises de position.</p> LISTING 1 · ARBORESCENCE</span>TREE</span> </figcaption> experiments/ ├── ai │ ├── assist │ ├── audiobook-pipeline │ ├── autopreneur │ ├── bmad-context-viewer │ ├── mercurai │ ├── notebooklm-py │ ├── rhetorix │ └── SDD ├── autopreneur │ └── voice-notes ├── games │ ├── drop-escape-clone │ ├── lab-doku │ └── mdr-serious-game ├── lang-tools │ ├── carbon │ └── lean4 ├── media │ └── music-gen └── misc 22 directories</code></pre> </figure> J'ai l'habitude de tester la moindre idée qui me passe par la tête. Je stocke ces expériences dans un dossier experiments/</code>. Je le trie systématiquement, impitoyablement : je compare chaque chantier 2 à 2. Seuls les plus pertinents restent. C'est le death-match</em> des prototypes pour gagner le droit d'être promu au rang de projet. Et le prochain sur la ligne d'arrivée est Rhetorix</a></strong> : décrypter la rhétorique d'un article de presse. En novembre 2025, pour ma recherche d'emploi, j'ai bricolé quelques scripts et prompts. J'en ai extrait inflecv</a>, qui transforme une offre d'emploi en CV adapté. Toujours pour piloter l'IA, /glance</code></a> formate les retours IA pour les rendre simples à lire et à survoler. Pour vérifier qu'un projet évolue dans le bon sens, /feature-torture</code></a> est un banc de dissection d'une fonctionnalité pour juger si elle survit, mute ou disparaît. Jusqu'ici, j'ai créé pour m'amuser ou me faciliter la vie. J'ai partagé afin de m'imposer un standard de qualité — la qualité minimum pour ne pas m'en vouloir, dans quelques semaines ou quelques mois, quand je voudrai reprendre le travail. C'est de cette matière que naissent les billets qu'on lit ici.</p> Pourquoi tenir à ce soin-là en 2026 ? Face à des projets et créations uniformes, l'impression que quelqu'un a repris, remanié et perfectionné 100 fois son travail me manque. Le danger de la génération automatique n'est pas le remplacement pur et simple, mais que notre contenu devienne indiscernable de celui de l'IA. Il y a un an, une vidéo IA montrait 3 bras par personne. En 2026, la différence de forme entre les contenus automatiques ou manuels s'amenuise. Quand je mets en pause lucid-lint</code></a>, /feature-torture</code> ou un article, je veux être sûr qu'ils sont utilisables et que je pourrai les reprendre plus tard avec plaisir</em>. Lorsque je les démarre, l'IA me sert à construire plus vite les filets de sécurité, la documentation lisible, le suivi du projet. Demain ou dans un an, je saurai où j'en suis sur chaque projet, et chaque projet me racontera son histoire.</p> LISTING 2 · LUCID-LINT</span>v0.2.0</span> </figcaption> $ lucid-lint check examples/sample.md ~~~~~ ⟨ • ⟩ ───── lucid-lint v0.2.0 cognitive accessibility linter · prose · EN / FR ──────────────────────────────────────────────── warning sample.md:3:1 Sentence is 29 words long (maximum 22). warning sample.md:46:1 Sentence has 4 commas (maximum 3). info sample.md:1:1 Kandel-Moles ease score 72.9 (target ≤ 9.0). summary: 7 warnings, 1 info. score: 50/100 structure ▓▓▓░░░░░░░░░░░░░░░░░ 5/20 rhythm ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 20/20 lexicon ▓▓▓▓▓▓░░░░░░░░░░░░░░ 10/20 syntax ▓▓▓▓▓▓░░░░░░░░░░░░░░ 10/20 readability ▓▓▓░░░░░░░░░░░░░░░░░ 5/20 exit: 1</code></pre> </figure> Cet article est une première page. Les personnages sont présentés : des expérimentations, des outils et des recherches. Je les mettrai en scène, les ferai parler, au fil des chapitres à venir : certains conteront l'échec d'un prototype ou l'excitation face à une idée prometteuse ; parfois, vous suivrez un seul protagoniste de bout en bout ; enfin, des séries analyseront les enjeux du code et de ce qu'on en fait. La table des matières vous interpelle ? Écrivez-moi. Je prendrai le temps de vous lire et de répondre.</p> Références</p> FIG. 1 — Tilt — Micro-Jeux</em>, hors-série n°5, août 1987, Éditions Mondiales. Scan : abandonware-magazines.org</a>.</p> FIG. 2 — Helme Heine, Un éléphant ça compte énormément</em>, Gallimard Jeunesse, coll. folio benjamin.</p> Matériel — Thomson TO9</a> (Wikipédia).</p> </div> Outils cités</p> lucid-lint</a> — linter d'accessibilité cognitive pour la prose.</p> /feature-torture</a> — banc de dissection pour une fonctionnalité.</p> /glance</a> — formater les retours IA pour la lecture-survol.</p> inflecv</a> — d'une offre d'emploi à un CV adapté.</p> Rhetorix</a> — prototype, décrypter la rhétorique d'un article de presse.</p> </div> </aside>}}

Avec l'IA, je code plus lentement — 2

2026-06-11T00:00:00+00:00

</div>

Depuis le premier article de cette série</a>, un retour m'a poussé à revoir ma copie. Johan Massin</a> m'a signalé une nouvelle étude METR de février 2026 faisant suite aux −19 % de perte de productivité 1</a></sup> avec l'IA. Alors, finalement, est-ce que cette augmentation de productivité attendue a du sens ?</p>

Ce qui rend cette suite intéressante à mes yeux, c'est l'aveu de ses auteurs concernant les difficultés méthodologiques rencontrées. Les conditions changent. Les tâches changent de nature. Les développeurs travaillent sur autre chose pendant que l'agent tourne. Cela me rappelle cette proportion des 10/90 2</a></sup> et la charge cognitive. Cet article METR s'arrête sur un problème nouveau : non seulement on ne mesure pas la bonne chose dans la vitesse de développement, mais on n'est plus capable de la mesurer de la bonne manière.</p>

Les difficultés de méthode, elles, n'ont pas été levées — METR juge même son suivi peu fiable. Et les nouveaux chiffres ne prolongent pas le premier : sur le même axe, la variation du temps quand l'IA est autorisée, le +19 % de temps de 2025 — plus lent — devient −18 % pour les développeurs initiaux et −4 % pour les nouveaux — plus vite 3</a></sup>. Le signe s'inverse. En cause : de moins en moins de développeurs acceptent de participer sans IA, et les projets greenfield affluent dans le panel.</p>

Dans la discussion sur le Slack Okiwi, suite au rappel de Johan, Jean-Baptiste Dusseaut</a> nous questionne :</p>

« C'est quoi, la productivité ? Quand je déclare fini ? Quand c'est en prod ? En prod sans défaut ? En prod sans défaut et que des gens s'en servent ? »</p> </blockquote>
Pour répondre à ces questions, j'ai besoin de vous expliquer comment je travaille désormais avec l'IA.</p>

</div>
Mon travail, en sept étapes</h2>
Ce qui suit est ma manière de travailler avec l'IA dans mes développements personnels, open source pour la plupart. Elle trouve ses origines dans mon expérience d'artisan logiciel, les concepts de product management et mes échanges avec d'autres praticiens.</p>
Influencé par Lean et Agile, j'ai choisi une représentation inspirée de Value Stream Mapping. Elle est marquée par 7 étapes principales regroupées ainsi :</p>

Avant le code · étapes 01–03</span></strong> : je prends le temps de définir le domaine, d'ajuster le périmètre visé et enfin de concevoir la forme globale. À l'issue de ces 3 étapes, j'ai un cadre précis de ce que je compte coder.</li>
Le code et sa boucle · étapes 04–06</span></strong> : La responsabilité des 3 étapes suivantes est la mise en production d'un code de qualité. D'abord, l'élaboration du harnais qui garantit la qualité, puis la génération du code. Ensuite, différentes revues et intégrations prennent le relais. Ces trois étapes sont orchestrées par une boucle de rétroaction continue centrée sur la compréhension humaine et l'adaptation.</li>
Après le code · étape 07</span></strong> : La dernière étape, le suivi de la livraison et sa maintenance, démarrent immédiatement après chaque livraison réussie. Cette étape comprend des activités comme le dogfood, la communication et le suivi statistique.</li> </ul>
Cette séquence est adaptable, jamais figée. Elle reste très classique et je la connaissais de manière empirique uniquement. Pour les besoins de l'article, j'ai reconstitué avec l'IA et mes commits sur lucid-lint les patterns et checkpoints les plus évidents, puis comparé avec l'idée abstraite que je m'en faisais. La dernière étape est très généraliste — presque fourre-tout. La raison : je garde lucid-lint comme exemple le plus récent et représentatif, et j'en suis pour l'instant le seul utilisateur quotidien.</p>
Parlons à nouveau des études METR. La courbe METR vit dans l'enchainement d'étapes semblables aux miennes. Le temps que je prends vit entre les boucles que ces étapes jalonnent. C'est le ralentissement volontaire pour les vérifications, celui des transitions entre deux actions finies pour garantir à la deuxième qu'elle reprendra sur des bases saines. Voici comment toutes ces étapes s'articulent.</p>
</div>
Le harnais qui libère</h2>
Un logiciel personnel est souvent issu d'une expérimentation, ou d'un prototype de recherche. La qualité initiale se contente de quelques tests et documents de réflexion. Avant de coder plus, je génère les tests manquants, j'installe les linters, je construis la chaîne de livraison initiale</span>. J'ajoute aussi les documents d'intention comme README, CODING_STANDARDS ou LICENSE et CONTRIBUTING pour l'open source. Ce sont les conditions pour implémenter sereinement les règles métier. Une fois ces conditions atteintes, j'ai une hygiène personnelle : le N+1. Lorsque je sécurise la qualité connue avec N garde-fous, j'en ajoute un pour ce qui est inconnu. Cela peut être du shift-left depuis la CI vers une règle pre-commit, du mutation testing, l'analyse statique ou une génération de documentation. Je choisis en fonction de la nature du projet ce qui me semble moins maitrisable.</p>
Ensuite, tout cela doit grandir avec les principes de développement classiques : test first, DDD, CUPID, etc. Ces principes sont issus du Lean, des méthodes agiles — en particulier eXtreme Programming — et du craft. Tidy First de Kent Beck 4</a></sup> m'inspire à chaque itération de code : la base saine du début doit le rester. Pour la faire évoluer, il faut la challenger avant chaque nouvelle fonctionnalité.</p>
Certains principes ont en revanche changé avec l'IA. Parfois, parce que ses capacités permettent de plus vite construire une qualité que j'aurais trouvée hors de portée ou overkill dans le passé. CodeQL et OpenSSF permettent des standards de qualité simples. Mais atteindre le minimum requis pour qu'ils ne lèvent pas d'alerte est long et rébarbatif. Avec une assistance IA, cela devient aisé. J'ai même trouvé cela ludique, sur lucid-lint, de chercher à atteindre ce badge BestPractices. Et le N+1 m'a mené à me poser la question de la revue par un autre contributeur. Je ne l'avais pas.</p>
Je suis seul contributeur sur plusieurs projets open source, et un autre point de vue me semble important. J'utilise Claude Code au quotidien. J'ai automatisé la revue avec Gemini Code Assist. Là où mon assistant habituel et moi laissions régulièrement passer des imperfections, ce nouvel outil dans la chaîne pouvait les repérer.</p>
Lorsque je demande à l'IA de rendre visuel un aspect complexe de l'architecture ou du parcours utilisateur, je fais attention à critiquer et modifier pour mieux m'impliquer. Aussi, j'ai découvert qu'il était plus efficace de générer un script pour représenter un graphique à partir des données brutes, par exemple, que de générer le graphique directement. Le résultat de ces pratiques, ce sont des documents utiles pour moi et des inputs fiables dans mon contexte Claude Code. J'écris pour l'humain. J'écris pour l'IA. Je n'écris qu'une fois.</span></p>
Ce n'est pas parfait, mais ça me convient. Je me rappelle de mon premier commit sur lucid-lint</code>, lorsque j'avais appliqué ce harnais en même temps que j'expérimentais la faisabilité sur quelques règles. La CI m'a crié dessus. Très fort. "It works on my machine" est aussi vrai pour la qualité. J'ai dû dédier 5 commits à corriger GitHub Actions, puis encore une vingtaine pour réaligner mes tests.</p>
</div> Catalyser le courage</h2> Sans l'IA, j'aurais pu être découragé par un tel travail et simplement arrêter le projet. Au contraire, j'ai eu en tête l'image de Senku, de Dr Stone, s'exclamant « Voilà qui est follement excitant !! »</em> J'ai retroussé mes manches et celles de Claude Code, et ensemble, en deux heures, nous avons ajusté la base de code. Le courage de refuser le compromis. Un rêve que je n'atteignais que rarement auparavant. Ou alors en quelques jours plutôt qu'en quelques heures.</p> Beaucoup penseraient que je parle d'accélération immédiate. Et c'est le cas. La différence c'est que cette accélération locale sert à oser booster la pérennité. Cela me rappelle le tweet de Kent Beck :</p> « 90 % de mes compétences viennent de perdre leur valeur, le levier sur les 10 % restants vient d'être multiplié par 1000. »5</a></sup></p> </blockquote> Supprimer, réviser et refactorer sont des actes fondamentaux de ces 10 %.</p> Je reviens à mon fil rouge lucid-lint</code>. Alors qu'il fonctionnait et donnait des résultats, j'ai pris quelques décisions folles. Au bout d'une journée d'existence de l'outil en production, j'ai jeté et refondu des fondamentaux : quatre catégories mortes en 24 h. Plus tard, pour mieux m'y retrouver, j'ai renommé 81 features de la roadmap et créé un système de gestion pour celles-ci. Plus clivant encore : au lieu de gagner 5,6 % de perf sur les textes anglais longs, j'ai réécrit le parseur Markdown pour équilibrer un gain moindre, mais pour tous les textes. Et ce, alors que tous les tests, golden snapshots et property tests, étaient verts.</p> Le point commun ? Le filet de sécurité n'est pas un gage de qualité. C'est ce qui m'autorise à être courageux. Et ce que ce courage libère, ce n'est pas du temps — c'est du jugement.</span></p> </div> L'IA, casseur de complaisance</h2> Ce jugement, je le garde pour moi. Et pour l'enrichir, je le nourris des analyses de l'IA, d'un côté, et de ses critiques, de l'autre. Pour le premier enrichissement, j'ai pour seul objectif de réduire le poids administratif de collecte et de synthèse. Le temps gagné est ainsi réinvesti dans la qualification des options avant un choix, par exemple pour un death match entre 2 expérimentations prêtes à devenir de vrais projets.</p> Pour l'enrichissement critique, c'est le plus cruel pour moi. Je demande explicitement à l'IA d'être dure avec ce que nous produisons. J'ai même un skill, /feature-torture</code>, dédié à faire un stress test d'une évolution prévue dans la roadmap. Une sorte de Dewey, de la série Malcolm : « Toi tu vis. Toi tu vis. Toi tu crèves ! »</em> Et aussi toi tu changes, toi tu te scindes. Une sortie riche de ce skill me permet de garder la tête froide et de prendre la décision finale. L'IA n'a pas d'égo, pas d'attachement émotionnel. J'utilise ces qualités pour mieux juger.</p> Je suis encore plus dur avec moi-même sur la rédaction de mes articles. Celui-ci ne fait pas exception. Claude Code revoit chaque mot, phrase, paragraphe et relit la cohérence globale. Je ne le laisse pas me dire que c'est bien si c'est juste passable. C'est dur. C'est exténuant. Et le pire ? Là où je croyais m'améliorer, les statistiques me montrent que je régresse sur l'utilisation abusive des hedge ("parfois", "souvent", "plutôt", "peut-être"), alors que les conventions que J'AI choisies les proscrivent. Chaque paragraphe est repassé à la moulinette environ 4 fois — oui, nous avons compté — avant qu'il soit bon.</p> Est-ce abusif de compter tout cela ? Pas si je veux être tranquille. Je ne veux pas laisser passer des phrases qui seraient mal comprises. Tout comme je m'interdis de laisser un bug ou une mauvaise conception s'échapper dans la nature. Pour éviter leur accumulation, je demande à l'IA de casser ma complaisance avant que je la confonde avec de la cohérence</span>.</p> Il arrive, malgré tout, qu'une simple règle de lisibilité dans lucid-lint</code> passe la torture, les revues locales et les tests, puis au premier essai en conditions réelles : le linter explose en vol ! Il s'agissait d'une règle, expérimentale, repérant les nombres sans ancrage proche — sans unité, par exemple. Mais lâchée dans le monde réel, elle délimitait mal les nombres, confondait les numéros de version avec de grandes valeurs numériques et finissait par crasher l'exécution. Bilan : quelques heures et trois commits.</p> </div> De la rigueur du cadre à la rigueur de la boucle</h2> Cela veut-il dire que les tests étaient superflus ? Non, mille fois non. Ou plutôt 841 fois non — le nombre de tests unitaires sur lucid-lint</code>. Et la rigueur est là, elle aussi, dans leur diversité — certains tests s'assurent que la documentation reste cohérente entre les deux langues — et dans le contrôle des tests eux-mêmes — mutation testing et relectures humaines + IA pour s'assurer de leur pertinence. Est-ce que je fais toujours du TDD avec l'IA ?</p> Un petit saut dans le temps. Dans mes premières utilisations de GitHub Copilot, j'avais tenté de lui faire faire du TDD. Deux constatations décevantes :</p> Les tests passaient souvent en test after malgré les directives</li> En test first, Copilot générait une cohorte de tests avant de commencer à implémenter</li> </ol> </div> Le premier se corrigeait avec le temps. Le deuxième a demandé une astuce qui s'est révélée fondamentale : ajouter une étape à TDD. Red → Green → Refactor → Reflect</strong>.</p> Cette 4e étape demande à l'IA de revoir l'exécution précédente des trois premières étapes, d'en tirer des apprentissages, et de changer le plan pour la suite quand nécessaire^{6</a></sup>. Honnêtement ? Peu de changements de plan. Livrés à eux-mêmes en test first, les assistants génèrent une cohorte de tests d'un bloc, en amont. Reflect casse ce réflexe — le Red redevient respecté. Les tests inutiles ou en doublon sont à nouveau tués dans l'œuf. Et un bonus : une verbosité maîtrisée qui me donne des informations utiles en relecture de code.</p>} Deux roues du cycle TDD agentique, avant et après l'ajout de Reflect. À gauche, sans Reflect : les trois temps Red, Green, Refactor forment un triangle, Red en haut à gauche. Une cohorte de tests générée d'un bloc, posée au-dessus du cycle, tombe directement sur Green ; sa flèche vers Red est barrée — le Red est court-circuité. À droite, avec Reflect : le cycle est complet, Red en haut à gauche puis Green, Refactor, et une quatrième étape Reflect en bas à gauche qui referme la boucle vers un nouveau Red.</p> Sans Reflectétat courant</span></figcaption> La cohorte tombe d'un bloc : le Red est court-circuité, écrit après coup.</p> </figure> →</span></div> Avec Reflectvue cible</span></figcaption> Le Red redevient un vrai départ : moins de tests créés à la fois, la boucle se referme.</p> </figure> </div> </figure> Dans mes explorations, j'ai travaillé en Spec Driven Development</em> (SDD) avec l'IA. Avec des frameworks — SpecKit7</a></sup>, OpenSpec8</a></sup> et BMAD. Même si les implémentations sont bonnes, je les trouvais lourdes et inflexibles. J'ai tenté une implémentation maison de micro framework SDD, dans le but de reprendre la main grâce à des micro-étapes plus granulaires. Le problème était similaire, le cadre restait figé par l'enchainement des étapes. Dans certains cas, comme des mises à jour de doc ou des améliorations esthétiques simples, il était inutile. Dans d'autres cas, comme pour les refactos évoqués plus tôt, trop léger. Mais une perle s'est glissée dans mon cadre : une étape Reflect</strong> entre deux boucles de feature. C'est cette étape qui m'a mené à abandonner le SDD au sens strict pour un cadre plus fluide et rigoureux à la fois.</p> </div> Une idée, venue au visionnage d'un tuto BMAD9</a></sup>, m'a mise sur cette piste : transférer la connaissance accumulée d'une session vers des documents de contexte, et redémarrer une session pour assurer ce transfert efficace. Les étapes 4-5-6 prennent ainsi la forme d'un double diamant compact : d'abord un brainstorm adversarial</em> — l'IA est très dure avec mes idées, je suis très dur avec ses propositions — puis session neuve</em> et enfin génération de code+explication</em>. Ces deux diamants interviennent au sein de chaque bloc pour une implémentation substantielle, ou au travers des trois étapes quand cela est plus trivial.</p> Le double diamant compact des étapes 4-5-6, lu de gauche à droite. En entrée, une intention. Premier losange, le brainstorm adversarial : on explore (l'humain et l'IA se challengent), puis on tranche. Au point de jonction, une session neuve repart d'un contexte transféré. Second losange, code et explication : on code, puis on explique. En sortie, du code maîtrisé.</p> Ce Reflect macro, il apparait une fois par boucle harnais → code → revue → Reflect</em>. Entre les cycles, l'IA génère un fichier de tests manuels à destination de l'humain. Je l'utilise comme une démo plus qu'une vérification. Il y a rarement des erreurs, mais souvent des remarques. Cette étape rétablit la conception émergente qui est atténuée en TDD agentique.</p> Les idées de nouvelles features, des décisions de refacto et des ajustements pour l'expérience utilisateur sont issus de cette phase. Cela m'évite aussi de revenir du déjeuner incapable de dire à quoi sert le commit de 11 h, ni pourquoi sa conception est déjà à revoir. Je trouve cela important d'étudier et comprendre ce qui est produit, car le code généré par IA est, pour mon cerveau, du legacy de quelques heures.</span>10</a></sup></p> La rigueur ne s'est pas effacée. Elle s'est déplacée du cadre figé vers la boucle réflexive.</span> Le rythme de mon travail alterne entre des phases de création, où l'IA dégrossit avec une influence humaine, et des phases de revues, où l'humain reprend la main activement sur les bases de l'agent IA.</p> </div> Note de vigilance</h2> Avec l'évolution des modèles et des agents de code, associés à des bonnes pratiques, la dette technique peut être maîtrisée. Sur le long terme, quand la complexité augmente, deux autres dettes interviennent : la dette cognitive et la dette d'intention. Cette triple dette, c'est le cercle vicieux où chacune nourrit l'autre.</p> Par exemple, la semaine dernière, je modifiais une dizaine de repos d'un même système. Dès le troisième, je me rends compte que je n'ai ni relu, ni testé manuellement. J'avais pourtant appliqué ma méthode. C'est ce que Margaret-Anne Storey nomme la dette cognitive11</a></sup> :</p> « la dette cognitive reste invisible jusqu'à ce qu'il soit trop tard : l'équipe croit comprendre le système mieux qu'elle ne le comprend vraiment » — Storey, février 2026.</p> </blockquote> Storey a nommé ce qui me hantait sans que je le sache. Dans mon cas, je l'ai repérée à temps. Mais c'est un rappel : le danger est de passer trop vite sans regarder ce qui est généré. Sans contribution active de ma part, ma compréhension du logiciel devient illusoire. Pour réduire ce risque de perte de compréhension, je me concentre sur le "comment".</p> Fin 2025, je développais un jeu vidéo en dilettante. Je perfectionnais le système des dialogues à n'en plus finir. Ce faisant je me sentais de plus en plus perdu. Lors d'une revue, le problème m'a sauté aux yeux : j'avais perdu de vue le "Pourquoi". Pourquoi ce système de dialogue et pourquoi développer ce jeu. Parce que je voulais raconter et expérimenter. C'est la troisième dette, appelée par Storey "dette d'intention"12</a></sup>.</p> L'apprentissage était fort : prendre le temps de se redemander "pourquoi" dans un troisième niveau de Reflect. Les trois niveaux de Reflect — quoi, comment et pourquoi — rappellent13</a></sup> la définition des User stories :</p> As a <who></span> I want <what></span> so that <why></span></pre> Le <how></code> se retrouve dans le Acceptance Criteria. Sur des projets personnels, seul, avec un rythme irrégulier, je perds souvent le fil et omets l'un de ces niveaux.</p> Trois anneaux concentriques colorés, une boucle de relecture chacun. L'anneau interne (bleu) est Quoi, la relecture de l'exécution. L'anneau médian (ambre) est Comment, la relecture de la conception. L'anneau externe (rouge) est Pourquoi, la relecture de l'intention. Ensemble ils suivent la structure d'une user story : qui, quoi, pourquoi — le comment vivant dans les critères d'acceptation.</p> </span> Pourquoi</span> l'intention · Reflect narratif</span> </li> </span> Comment</span> la conception · Reflect macro</span> </li> </span> Quoi</span> l'exécution · TDD + Reflect</span> </li> </ol> </div> Trois anneaux emboîtés, une relecture chacun. Plus la boucle est externe, plus elle est rare — et plus son oubli coûte cher.</figcaption> </figure> Le piège à éviter est de ne pas participer activement aux prises de notes et modélisations. C'est ce que Michael Gerlich a étudié14</a></sup>, sur 666 personnes via des questionnaires et des entretiens. Il conclut à une corrélation négative forte entre l'usage fréquent d'outils IA et la capacité de pensée critique. Les plus jeunes, plus dépendants de l'IA, sont plus touchés tandis que le niveau d'éducation est corrélé à de meilleurs résultats. Mais le plus important : la décharge cognitive (Cognitive offloading</em>, délégation à l'IA) est en cause. Ce que j'en tire, c'est que déléguer la recherche et la synthèse de connaissance peut aider, tandis que déléguer le raisonnement réduit la pensée critique.</p> Cette étude montre le piège dans lequel je retombe souvent — par fatigue, paresse ou impatience : dépasser le seuil de la décharge cognitive vers une décharge de raisonnement. C'est-à-dire passer de l'aide vertueuse de l'IA pour mieux raisonner et se rappeler, au remplacement par l'IA qui effrite le sens critique. Le sens critique est justement ce qui déclenche les Reflect et les nourrit.</p> </div> Vers l'article 3</h2> Tous les patterns dont je parle s'arrêtent à la frontière du clavier. Ce sont les miens. S'ils peuvent inspirer, je n'ai aucune garantie qu'ils soient généralisables.</p> Les artefacts qui me servent sont déjà transmis à d'autres. Des collègues, des clients pour lesquels je travaille et mon futur moi. De ce fait, c'est une transmission d'humain à humain. Et la compréhension ne s'accélère pas.</span> L'IA, quant à elle, joue un rôle de médiateur et d'archiviste.</p> Je reste sur la même idée. Je n'ai pas accéléré ma création de code. En revanche, je suis conscient d'avoir produit plus. D'avoir terminé plus de projets. Des projets plus aboutis. Mon accélération n'est pas dans l'immédiateté de génération du code, mais dans la qualité que je suis capable d'atteindre désormais.</span></p> J'utilise un processus similaire pour l'écriture et pour le code. Et cet article m'a fait réfléchir à ma propre méthode, par des recherches, par l'effort de synthèse et par une introspection plus profonde que d'habitude. Comme un Reflect au-delà de mes 3 premières boucles, la boucle narrative. Celle de l'introspection personnelle.</p> Le niveau supérieur que je souhaite partager, il est en lien avec mon quotidien professionnel. Je l'observe et le vis dans des projets en équipe, des projets d'entreprise. C'est le Reflect collectif au niveau de l'organisation. Ce sera l'objet du troisième et dernier article de cette série.</p> Notes et références</h2> ^2</sup>Voir le premier article de la série</a>. Avant l'IA, j'écrivais le code dans environ 10 % de mon temps ; les 90 % restants allaient à le concevoir, le relire, l'organiser, le documenter et le maintenir. Ne me rappelant plus d'où me venaient les chiffres que je prenais pour acquis, j'ai recherché. Voici ce que j'ai trouvé : Abelson et Sussman posent le principe dès 1985 (« Programs must be written for people to read, and only incidentally for machines to execute</em> », SICP</em>), Peter Hallam le chiffre (2 à 5 % d'écriture pure ; What Do Programmers Really Do Anyway?</em>, 2006), et Robert C. Martin le fixe en formule mémorable — « lecture/écriture bien au-delà de 10:1 » (Clean Code</em>, 2008).</p> </div> ^1</sup>METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity</em>, juillet 2025 (16 développeurs, 246 tâches ; +19 % de temps, soit −19 % de productivité). https://arxiv.org/abs/2507.09089</a></p> </div> ^3</sup>METR — We Are Changing our Developer Productivity Experiment Design</em>, 24 février 2026. Sur l'axe « Change in time when AI allowed » (négatif = plus rapide), l'estimation revue donne −18 % de temps (≈ 18 % plus vite) pour les développeurs initiaux (IC −38 % à +9 %) et −4 % pour les nouveaux (IC −15 % à +9 %) — un quasi-renversement du +19 % de temps (plus lent) mesuré en 2025, que METR juge peu fiable du fait d'effets de sélection (de plus en plus de développeurs refusant de travailler sans IA). https://metr.org/blog/2026-02-24-uplift-update/</a></p> </div> ^{4</sup> Kent Beck — Tidy First?</em>, O'Reilly, 2023 (ISBN 978-1-098-15124-9).</p> </div>}^5</sup>Kent Beck — « The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x », tweet du 18 avril 2023 https://x.com/KentBeck/status/1648413998025707520</a> ; développé dans l'essai 90% of my skills are now worth $0</em> (tidyfirst.substack.com).</p> </div> ^6</sup>lucid-lint</em> — CODING_STANDARDS.md</em>, §3 « TDD with a fourth step — Reflect » : « Reflect updates the plan, not the code.</em> » https://github.com/bastien-gallay/lucid-lint/blob/main/CODING_STANDARDS.md#3-tdd-with-a-fourth-step--reflect</a></p> </div> ^7</sup>GitHub — Spec Kit</em>. https://github.com/github/spec-kit</a></p> </div> ^8</sup>OpenSpec</em>. https://github.com/Fission-AI/OpenSpec</a></p> </div> ^9</sup>BMAD-METHOD</em> (bmad-code-org), tutoriel Getting Started</em> : « Always start a fresh chat for each workflow.</em> » https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/tutorials/getting-started.md</a></p> </div> ^{10</sup> Michael Feathers — Working Effectively with Legacy Code</em>, 2004 (ISBN 978-0-13-117705-5).</p> </div>}^11</sup>Margaret-Anne Storey — How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt</em>, 9 février 2026 (cadre conceptuel). https://margaretstorey.com/blog/2026/02/09/cognitive-debt/</a> — Martin Fowler reprend et discute ce cadre dans Fragments</em> (2 avril 2026, https://martinfowler.com/fragments/2026-04-02.html</a>).</p> </div> ^12</sup>Margaret-Anne Storey — From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI</em>, mars 2026. https://arxiv.org/abs/2603.22106</a></p> </div> ^{13</sup> Encore une recherche qui m'a donné quelques surprises. Le triple-loop learning</em> est souvent attribué à tort à Argyris et Schön. En réalité, ils n'en décrivent que deux (simple et double boucle) ; l'ancêtre du troisième niveau est le « Learning III » de Bateson (Steps to an Ecology of Mind</em>, 1972), et Tosey, Visser et Saunders (Management Learning</em>, 2012, DOI 10.1177/1350507611426239) montrent que cette généalogie est en partie reconstruite a posteriori.</p> </div> ^{14</sup> Michael Gerlich — AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking</em>, Societies</em> 15(1):6, 2025 (N=666 ; étude non spécifique au logiciel). DOI : 10.3390/soc15010006.</p> </div>}}

Ce que les chiffres ne mesurent pas</h2>

La dette technique devient invisible</h3>

Pourquoi ce site, et pourquoi maintenant

Écrits — Bastien Gallay

Avec l'IA, je code plus lentement — 2

Avec l'IA, je code plus lentement