Avec l'IA, je code plus lentement — 2.

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

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² 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.

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³. 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.

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

« 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 ? »

Pour répondre à ces questions, j'ai besoin de vous expliquer comment je travaille désormais avec l'IA.

---

Mon travail, en sept étapes

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.

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 :

• Avant le code · étapes 01–03 : 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.
• Le code et sa boucle · étapes 04–06 : 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.
• Après le code · étape 07 : 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.

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.

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.

---

Le harnais qui libère

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. 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.

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⁴ 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é.

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.

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.

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.

Ce n'est pas parfait, mais ça me convient. Je me rappelle de mon premier commit sur lucid-lint, 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.

---

Catalyser le courage

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 !! » 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.

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 :

« 90 % de mes compétences viennent de perdre leur valeur, le levier sur les 10 % restants vient d'être multiplié par 1000. »⁵

Supprimer, réviser et refactorer sont des actes fondamentaux de ces 10 %.

Je reviens à mon fil rouge lucid-lint. 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.

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.

---

L'IA, casseur de complaisance

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.

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, 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 ! » 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.

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.

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.

Il arrive, malgré tout, qu'une simple règle de lisibilité dans lucid-lint 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.

---

De la rigueur du cadre à la rigueur de la boucle

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. 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 ?

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 :

1. Les tests passaient souvent en test after malgré les directives
2. En test first, Copilot générait une cohorte de tests avant de commencer à implémenter

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.

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. 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.

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.

La cohorte tombe d'un bloc : le Red est court-circuité, écrit après coup.

→

Le Red redevient un vrai départ : moins de tests créés à la fois, la boucle se referme.

Dans mes explorations, j'ai travaillé en Spec Driven Development (SDD) avec l'IA. Avec des frameworks — SpecKit⁶, OpenSpec⁷ 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 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.

Une idée, venue au visionnage d'un tuto BMAD⁸, 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 — l'IA est très dure avec mes idées, je suis très dur avec ses propositions — puis session neuve et enfin génération de code+explication. 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.

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é.

Ce Reflect macro, il apparait une fois par boucle harnais → code → revue → Reflect. 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.

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.⁹

La rigueur ne s'est pas effacée. Elle s'est déplacée du cadre figé vers la boucle réflexive. 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.

---

Note de vigilance

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.

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 cognitive¹⁰ :

« 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.

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".

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"¹¹.

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 — rappellent¹² la définition des User stories :

As a    <who>
I want  <what>
so that <why>

Le <how> 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.

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.

1. Pourquoi l'intention · Reflect narratif
2. Comment la conception · Reflect macro
3. Quoi l'exécution · TDD + Reflect

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é¹³, 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, 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.

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.

---

Vers l'article 3

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.

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. L'IA, quant à elle, joue un rôle de médiateur et d'archiviste.

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.

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.

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.

---

Notes et références