« J'ai livré mon ticket, mais je ne sais plus ce que j'ai livré »

· 13 min read
ia agentic claude-code clean-agentic-dev dette-de-comprehension

Cette phrase, je l’entends très souvent en formation. Le code tourne, les tests passent, la PR est mergée. Et la personne qui l’a poussée n’aurait pas su l’expliquer au standup.

Elle n’arrive jamais seule. Dans la même famille, je note régulièrement :

  • « J’ai l’impression que je fais trop confiance à l’IA. »
  • « On livre sans comprendre. »
  • « Je lance, je reviens, et c’est prêt. Comme un micro-ondes. »
  • « Je brûle des tokens à relire du code qui sera jeté. »

Quatre phrases qui reviennent d’une équipe à l’autre, quelle que soit la stack. Et au fond un seul problème : le code sort plus vite qu’on ne le comprend. Pendant toute notre carrière, écrire le code et le comprendre étaient la même activité. Tu ne pouvais pas taper une fonction sans savoir ce qu’elle faisait. L’agent a découplé les deux. Et personne ne nous a dit quoi faire de la moitié qui reste.

Alors, comme promis, le billet du dimanche : d’abord l’état de l’art, ensuite mon avis.

1. Ce que disent les chiffres

On utilise plus, on fait moins confiance

Le sondage Stack Overflow 2025 (49 000 répondants) le dit sans nuance : 84 % des devs utilisent ou prévoient d’utiliser l’IA, mais seulement 33 % font confiance à ce qu’elle produit, et 46 % s’en méfient activement. La frustration numéro un, citée par deux tiers des répondants : des solutions « presque justes, mais pas tout à fait ». Et 45 % disent que déboguer du code généré prend plus de temps que prévu.

Le « presque juste » est le cœur du sujet. Un code faux, tu le vois. Un code presque juste, tu le merges.

On se croit plus rapide qu’on ne l’est

L’étude METR de 2025 est celle qui a fait le plus de bruit. Seize devs expérimentés, 246 tâches sur leurs propres repos open source, un tirage au sort pour savoir qui a droit à l’IA. Résultat : les devs assistés mettent 19 % plus de temps. Avant l’étude, ils prédisaient un gain de 24 %. Après, alors même qu’ils avaient ralenti, ils estimaient encore avoir gagné 20 %.

Je ne retiens pas le chiffre de 19 % (l’étude date, les outils ont changé, les auteurs eux-mêmes sont prudents). Je retiens l’écart entre le ressenti et la mesure. Quand tu as l’impression que « ça va vite », ton impression n’est pas une donnée. Le micro-ondes a l’air rapide parce que tu n’es pas devant.

On apprend moins, surtout à déboguer

En janvier 2026, Anthropic a publié un essai contrôlé randomisé sur 52 développeurs à qui on apprend une bibliothèque Python inconnue (Trio), moitié avec un assistant IA, moitié sans. Les deux groupes finissent quasiment en même temps. Au quiz de compréhension juste après, le groupe IA fait 50 % contre 67 % : dix-sept points de moins, et l’écart le plus fort porte sur les questions de debugging.

Mais le résultat vraiment utile est dans les détails. Les chercheurs ont regardé comment les gens utilisaient l’IA et ont trouvé six profils. Trois qui apprennent mal : ceux qui délèguent tout d’emblée, ceux qui posent une ou deux questions puis délèguent tout, et ceux qui utilisent l’IA comme une béquille de debug (« corrige ça », « et ça »). Trois qui apprennent bien : ceux qui font générer puis posent des questions pour comprendre, ceux qui demandent le code avec l’explication, et ceux qui ne posent que des questions conceptuelles et résolvent les erreurs eux-mêmes. La conclusion des auteurs tient en une phrase : « not all AI-reliance is the same ».

Autrement dit, ce n’est pas l’IA qui fait livrer sans comprendre. C’est une façon précise de l’utiliser.

Le code lui-même se dégrade

GitClear a analysé 211 millions de lignes modifiées entre 2020 et 2024. En 2024, les blocs de cinq lignes ou plus dupliqués à côté de code existant ont été multipliés par huit, et les lignes « déplacées » (le signal classique d’un refactoring) ont chuté de près de 40 %. Pour la première fois, on a plus copié-collé que refactoré.

Rien de surprenant : un agent avec un contexte limité préfère réécrire plutôt que réutiliser. Mais pour notre sujet, ça veut dire que le code que personne ne comprend grossit plus vite que le code qu’on comprenait déjà.

Un nom pour tout ça : la dette de compréhension

Addy Osmani (équipe Chrome chez Google) a posé le terme : comprehension debt, l’écart grandissant entre la quantité de code dans un système et la part que des humains comprennent réellement. Ce qui la rend dangereuse, c’est qu’elle ne frotte pas. La dette technique ralentit les builds et fait râler. La dette de compréhension, elle, laisse tous les voyants au vert : « The codebase looks healthy while comprehension quietly hollows out underneath it. » Les tests passent, la vélocité tient, les PR sont approuvées. Puis un changement simple casse un truc que personne ne sait expliquer.

Sa phrase que je retiens : « Tests are necessary. They are not sufficient. »

2. Deux écoles, et une doc officielle

École 1 : « Ne lis plus le code, blinde les contraintes »

C’est la position la plus radicale, et elle vient de là où on ne l’attendait pas. En juillet 2026, Robert C. Martin, Uncle Bob, l’auteur de Clean Code, écrit sur X : « My current strategy is to not read any of the code written by my agents. »

Ce n’est pas du laxisme, c’est un déplacement. Il ne relit plus les lignes, il relit les contraintes. Pour chaque story, il enchaîne cinq agents étroits : un specifier qui transforme la demande en critères d’acceptation Gherkin et en procédure QA, un coder qui écrit tests unitaires et implémentation, un cleaner qui chasse les fonctions à mauvais score CRAP (couverture croisée avec complexité), un hardener qui fait du mutation testing (on altère le code source, les tests doivent casser), et un QA qui exécute le scénario. Lui, il relit les Gherkin et la procédure QA. Pas le code. Il a aussi constaté que les longues règles écrites dans un prompt se diluent au fil du contexte, et qu’une contrainte vérifiée par un outil vaut dix contraintes écrites en toutes lettres.

Quelques semaines plus tard, il nuance lui-même : « Lots of times I just use unit tests and crap. » Et Grady Booch lui répond que des métriques n’attraperont jamais ce qu’un œil expérimenté voit tout de suite : le code mort, la faille, la mauvaise abstraction.

Kent Beck est sur une ligne voisine mais moins extrême. Il appelle ça augmented coding, par opposition au vibe coding : « In vibe coding you don’t care about the code, just the behavior of the system. In augmented coding you care about the code, its complexity, the tests, & their coverage. » Il tape très peu de code, impose le TDD à l’agent un test à la fois, sépare strictement les commits de structure et de comportement, et surtout il surveille les signaux d’alerte : l’agent qui boucle, qui ajoute une fonctionnalité non demandée, ou qui triche en désactivant un test.

École 2 : « Tu restes responsable de chaque ligne »

Simon Willison, qui a lancé le terme vibe engineering avant de se rallier à agentic engineering, tient le fil de la responsabilité. Le vibe coding, pour lui, c’est accepter le résultat « if it appears to work ». Acceptable pour un script perso. Irresponsable pour un logiciel que d’autres utiliseront. L’ingénieur, lui, « accelerates their work with LLMs while staying proudly and confidently accountable for the software they produce ». Sa liste de ce qui rend cette responsabilité possible ressemble étrangement au bon vieux métier : tests, planification en amont, doc, hygiène git, CI, culture de la revue, tests manuels sur les cas limites.

Osmani conclut dans le même sens : « Making code cheap to generate doesn’t make understanding cheap to skip. The comprehension work is the job. »

Ce que dit la doc d’Anthropic

Entre les deux, la doc officielle de Claude Code est plus terre à terre, et à mon avis plus utile pour une équipe.

Première règle, celle que Boris Cherny (le créateur de l’outil) qualifie de conseil le plus important : donner à l’agent un moyen de vérifier son propre travail. Tests, build, lint, script de diff, capture d’écran comparée à la maquette. La doc le formule ainsi : « Claude stops when the work looks done. Without a check it can run, “looks done” is the only signal available, and you become the verification loop. » Et plus loin, sur ce qu’elle appelle le trust-then-verify gap : « If you can’t verify it, don’t ship it. »

Deuxième règle : explorer, planifier, puis coder. Le plan mode existe précisément pour séparer la compréhension du problème de la production du code. Pour les grosses features, la doc recommande même de se faire interviewer par l’agent avant qu’il écrive une ligne.

Troisième règle : faire relire par un second agent, dans un contexte neuf, qui ne voit que le diff et les critères, pas le raisonnement qui a produit le code. Et exiger des preuves plutôt que des affirmations : la sortie des tests, la commande exécutée, la capture d’écran.

Et les chercheurs de l’étude sur l’apprentissage ajoutent une consigne pour les individus : accepter un peu d’effort cognitif, et utiliser les modes d’apprentissage des outils (Claude Code a un mode Learning / Explanatory) quand on touche une techno nouvelle.

3. Mon avis

Je ne vais pas te dire « relis tout » : personne ne le fait, et ceux qui le prétendent ne tiennent pas longtemps. Je ne vais pas non plus te dire « ne relis rien » : ça marche pour Uncle Bob parce qu’il a cinquante ans de jugement architectural et qu’il dessine lui-même la structure des modules avant de lancer ses agents. Dans une équipe avec trois juniors, « je ne relis pas » devient très vite « personne ne relit ».

La bonne question n’est pas « dois-je lire le code ? ». C’est « qu’est-ce que je dois comprendre, et à quel moment ? ». Voilà comment je réponds, pain point par pain point.

« Je livre sans comprendre. » Déplace la compréhension en amont. Si tu comprends le plan, tu comprends le code, même sans l’avoir lu ligne à ligne. Si tu ne comprends pas le plan, lire le diff ne te sauvera pas. Donc : plan mode systématique dès que le changement touche plus d’un fichier, et tu ne valides pas un plan que tu ne saurais pas expliquer à un collègue. Le plan, c’est la seule chose qui est à la fois courte, stable et porteuse de toutes les décisions. C’est là que ton attention vaut le plus cher.

« Je brûle des tokens à relire du code qui sera jeté. » Si tu relis du code jetable, c’est que tu relis trop tôt et au mauvais niveau. Ne relis pas pendant que l’agent itère. Relis quand les vérifications sont vertes, et relis aux frontières : les interfaces, les invariants, les migrations, tout ce qui sera dur à défaire. Les lignes du milieu, confie-les à un agent relecteur dans un contexte vierge, avec des critères précis (« signale les écarts avec le plan, pas les préférences de style »). Toi, tu lis le rapport et les preuves. Ta relecture passe de « je lis 400 lignes » à « je lis 15 lignes de findings et je vais vérifier les deux qui m’inquiètent ».

« Comme un micro-ondes. » Le micro-ondes n’est pas le problème. Un micro-ondes sans thermomètre, si. La doc Anthropic le dit en une phrase : la présence d’une vérification exécutable est « la différence entre une session que tu regardes et une session dont tu t’éloignes ». Avant de lancer, demande-toi : qu’est-ce qui va dire pass ou fail sans moi ? Un test, un build, un script de comparaison, une capture d’écran. Si la réponse est « rien », tu n’as pas le droit de t’éloigner. Et dans ce cas, le vrai boulot c’est d’écrire cette vérification, pas de surveiller l’agent.

« Je fais trop confiance à l’IA. » Je dirais plutôt : tu fais confiance au mauvais signal. « Ça a l’air de marcher » n’est pas un signal, c’est une impression, et METR nous a montré ce que valent nos impressions. Un signal, c’est une sortie de test que tu as vue, une commande dont tu as vu le résultat, un second agent qui a essayé de casser le code et n’y est pas arrivé. Exige des preuves, pas des affirmations. Et quand l’agent dit « c’est fait », ta première réaction doit être « montre ».

Et le debugging. C’est là que l’étude d’Anthropic fait le plus mal, et c’est là que je serais le plus strict. Le réflexe « je colle l’erreur et je laisse faire » est exactement le profil qui apprend le moins. Quand ça casse, prends trente secondes pour formuler une hypothèse avant de déléguer. Ou demande à l’agent d’expliquer la cause avant de corriger. Tu perds une minute, tu gardes le muscle qui te servira le jour où l’agent sera lui-même perdu. Et il le sera.

Dernière chose, pour les équipes. Je recommande une règle très simple : on ne ferme pas un ticket qu’on ne sait pas expliquer en deux minutes. Ce que ça fait, pourquoi comme ça, et ce qui a été vérifié. Pas le code, les décisions. Si tu n’y arrives pas, le ticket n’est pas fini. C’est le test d’Osmani appliqué au quotidien : distinguer honnêtement « les tests passent » de « je comprends ce que fait ce code et pourquoi ».

Livrer sans comprendre, ce n’est pas un bug de l’IA. C’est un bug de workflow. Et un workflow, ça se corrige.

Bon dimanche.

Sources