Depuis le chapitre 5, vous savez cadrer. Mais un plan validé et un prompt parfait produisent encore, parfois, du code faux. Pas du code qui plante : du code qui compile, qui tourne, qui a l'air juste, et qui se trompe dans un recoin que personne n'a exécuté.
Ce chapitre traite le problème à la racine, et il pèse plus lourd que tous les autres. Sur ce point, tout l'écosystème converge, jusqu'à Boris Cherny, le créateur de Claude Code : le levier n°1 pour obtenir du bon code d'un agent, c'est de lui donner un moyen de vérifier son propre travail. Sans vérification, vous empilez du plausible. Avec, vous changez de métier : vous ne relisez plus des promesses, vous constatez des preuves.
Le fossé entre « ça a l'air bon » et « c'est bon »
Ce fossé porte un nom dans l'écosystème : le trust-then-verify gap. Un modèle de langage est entraîné à produire du vraisemblable, et il y excelle : le code généré est bien structuré, bien nommé, bien commenté. Il inspire confiance. Le problème est que la vraisemblance et la justesse sont deux propriétés indépendantes : un code peut cocher toutes les cases de la première et rater la seconde, dans une condition inversée au fond d'un fichier, un fuseau horaire, un arrondi.
La lecture humaine est un mauvais détecteur de code faux. Elle attrape le style, les noms douteux, l'architecture bancale ; elle rate l'inversion de logique au milieu de quatre cents lignes propres. Un test, un compilateur, un build, eux, ne se laissent pas impressionner par un code bien présenté.
C'est d'ailleurs la première chose que je regarde quand j'audite la pratique d'une équipe : non pas « avez-vous relu ? », mais « qu'est-ce qui casse si c'est faux ? ». Quand la réponse est « rien », le reste de l'audit est écrit d'avance.
La règle d'or : un done exécutable
D'où la règle d'or de ce guide, celle qui subordonne toutes les autres : jamais une tâche sans critère de done exécutable. Exécutable veut dire qu'une machine peut trancher, oui ou non, sans opinion. Comparez.
Un done décoratif
- « fais en sorte que ça marche »
- « vérifie bien ton code »
- « assure-toi qu'il n'y a pas de régression »
- « teste tout correctement »
Un done exécutable
- « npm test passe, y compris les trois nouveaux tests »
- « le build et le typecheck sortent sans erreur »
- « la capture d'écran de /checkout est identique à la maquette »
- « l'app démarre et le parcours d'inscription va au bout »
La colonne de gauche a l'air exigeante, elle est inutile : un agent à qui l'on demande « vérifie » répond « tout est bon » avec un aplomb parfait, parce que rien ne l'oblige à confronter son code au réel. La colonne de droite donne à Claude une commande à lancer et un verdict à obtenir. La différence de formulation est minuscule ; la différence de résultat est celle qui sépare un produit d'une démo.
Des tests qui prouvent, pas des tests qui décorent
Claude écrit très bien les tests, à condition de savoir quoi demander. Le piège classique s'appelle le test écrit après coup : le code est terminé, vous demandez « ajoute des tests », Claude lit l'implémentation, en déduit le comportement et écrit des tests qui vérifient... ce que le code fait déjà. Si le code contient un bug, le test le grave dans le marbre.
Vous obtenez une suite verte qui valide le bug, c'est-à-dire pire que pas de tests du tout : une fausse assurance.
Deux parades, cumulables. La première : faire écrire les tests depuis la spécification, pas depuis le code (« écris les tests à partir de SPEC.md, sans regarder l'implémentation »). La seconde : exiger de voir chaque nouveau test échouer avant la correction. Un test qui n'a jamais été rouge ne prouve rien ; il n'a jamais démontré qu'il détectait quoi que ce soit.
Le TDD inversé
Cette deuxième parade porte un nom quand on en fait une méthode : le TDD inversé. Le test devient la spécification exécutable de la tâche : impossible de la déclarer finie tant qu'il est rouge. Cette discipline demandait des années d'habitude aux équipes humaines ; avec un agent qui ne se lasse jamais de relancer la suite, elle devient naturelle.
- Écrire le test d'abordLe voir échouer : le rouge prouve qu'il capture bien le bug.
- Laisser Claude implémenterJusqu'à faire passer le test au vert : le vert prouve que la correction corrige.
- Le test reste dans le projetCe bug précis ne pourra plus jamais revenir sans déclencher une alarme.
Voyez sur un bug réel du cabinet de Talia, la kiné du chapitre 1.
❯ Chez Talia : le forfait 10 séances ne se recrédite pas ❯ quand une séance est annulée à temps. Écris d'abord le ❯ test qui reproduit le bug et montre-le moi rouge. · Claude écrit le test... forfait.test.ts : « l'annulation à temps recrédite » ✗ 1 échec : attendu 6 séances restantes, reçu 5. Capturé. ❯ Parfait. Corrige, et fais tourner toute la suite. · Claude corrige forfait.ts... ✓ 24 tests passés, 0 échec. Et le bug ne reviendra plus.
Chaque étape de cette petite scène prouve quelque chose.
Trois preuves pour le prix d'un prompt.
Vérifier au-delà des tests
- 01 · Les testsUn instrument dans la panoplie, pas toute la panoplie : une suite verte n'a jamais garanti qu'un écran est bien aligné.
- 02 · Build, lint, typecheckLes moins chers de tous : quelques secondes, aucune écriture, et ils attrapent une quantité étonnante d'erreurs. À exiger systématiquement, à la fin de chaque tâche.
- 03 · La capture d'écran comparéeLa preuve adaptée au visuel : Claude lance l'app, capture la page et compare à la maquette ou à la version de référence, puis corrige ce qui diffère. Quinze ans de mobile m'ont rendu intraitable là-dessus : sur de l'interface, je ne valide jamais sur la sortie du terminal, je valide sur l'image.
- 04 · L'application réellement lancéeLa preuve reine : dérouler le parcours pour de vrai, créer un compte, ajouter au panier, payer. La seule vérification qui traverse toutes les couches en même temps, et Claude sait la faire lui-même en pilotant l'app.
Boucler jusqu'au vert
Car c'est là que tout se rejoint : une fois le critère exécutable posé, Claude n'a plus besoin de vous pour itérer. Il lance la commande, lit l'échec, corrige, relance, jusqu'au vert, sans intervention. Vous formulez la tâche et sa preuve, vous revenez devant un travail vérifié. C'est la boucle agentique du chapitre 2 devenue votre meilleur outil : elle observe, elle recommence, et elle ne se décourage pas.
Deux garde-fous pour que la boucle reste honnête. D'abord, la qualité de la boucle est exactement celle du critère : un done faible fait converger vers du faux avec une grande efficacité. Ensuite, interdisez explicitement de modifier les tests pendant la correction : le chemin le plus court vers le vert passe parfois par l'affaiblissement du test, et un agent peut l'emprunter si rien ne le lui interdit.
Une dernière précision d'honnêteté : la vérification fonctionnelle prouve que le code fait ce qu'on attend, pas qu'il est sûr. La sécurité mérite son propre regard : un rôle d'expert dédié au chapitre 8, et sa version automatisée en CI au chapitre 11.
Quatre façons de tenir la barrière
Poser le critère dans le prompt est le degré zéro, et il suffit la plupart du temps. Mais plus la session est longue, moins vous êtes là pour constater qu'elle s'est arrêtée trop tôt. Il existe donc une échelle, et chaque barreau échange un peu de mise en place contre beaucoup d'attention en moins.
- Dans le prompt« Lance les tests et corrige jusqu'au vert », dans le même message que la tâche. Aucune configuration, valable dès aujourd'hui.
- À l'échelle de la sessionPosez le critère comme objectif avec /goal : un évaluateur séparé le revérifie après chaque tour, et Claude continue tant qu'il n'est pas tenu. Contrairement à une consigne de prompt, il ne se dilue pas au fil d'une longue session.
- En barrière dureUn hook de fin de tour exécute votre vérification comme un script et empêche la session de rendre la main tant qu'elle échoue. C'est la logique du chapitre 9 : quand l'oubli est inacceptable, on ne demande pas, on garantit.
- Par un regard extérieurFaites relire le diff dans un contexte neuf, avec la commande de revue intégrée ou un subagent que vous cadrez. Celui qui note le travail n'est alors pas celui qui l'a fait : l'argument du chapitre 8, rendu automatique.
Le done élargi : ce que je demande à la fin de chaque tâche
Reste une habitude que j'ai prise sur tous mes projets, et qui a plus changé la qualité de ce que je livre que n'importe quelle astuce de prompt. Elle consiste à élargir la définition de « fini ».
Une tâche n'est pas terminée quand le code marche. Elle est terminée quand le code marche, que les tests qui le prouvent existent, que la non-régression a été vérifiée, et que la mémoire du projet a été mise à jour si quelque chose a changé. Ces quatre choses forment un seul geste, et ce geste est délégable en entier : c'est Claude qui les fait, à condition qu'on le lui demande une bonne fois.
- 01 · Les tests, les deux famillesLes tests unitaires pour les règles métier, les tests fonctionnels pour le parcours réel. Les premiers disent que la règle des 24 h est juste, les seconds qu'un patient arrive vraiment au bout de son annulation. Demander les deux, systématiquement, coûte une ligne de consigne.
- 02 · La non-régressionRelancer la suite complète quand la zone touchée est sensible, et pas seulement les tests du jour. C'est la seule façon de savoir que la correction d'aujourd'hui n'a pas défait le travail d'avant-hier, au moment précis où on peut encore le rattraper sans rien chercher.
- 03 · La mémoire du projetSi la tâche a introduit une convention, un piège ou une décision, le CLAUDE.md et le PRODUCT.md du module concerné doivent en porter la trace avant la fin de la session. Sinon la prochaine session redécouvrira, et se trompera.
Le plus efficace n'est pas de le redemander à chaque fois, mais de l'écrire une fois pour toutes dans le brief, à la racine ou dans le module concerné (chapitres 3 et 4). Le done élargi devient alors le comportement par défaut du projet, pour vous comme pour les autres sessions.
❯ Ajoute le rappel SMS 24 h avant la séance. · Claude implémente puis applique le done du projet... rappels/ : service écrit, règle branchée sur les créneaux. ✓ 4 tests unitaires (fenêtre, fuseau, annulation, doublon) ✓ 1 test fonctionnel : le patient reçoit un seul SMS ✓ Suite complète relancée : 47/47, aucune régression rappels/CLAUDE.md mis à jour : le fuseau est celui du cabinet, jamais celui du patient. Piège rencontré ce jour.
Oui, ça coûte plus cher. Et ça vaut le prix.
Soyons honnête sur la contrepartie, parce que ce guide ne vend pas de repas gratuit : ce done élargi consomme plus de tokens qu'une tâche livrée dès que le code compile. Les tests s'écrivent, la suite se relance, les briefs se relisent.
Ce surcoût est immédiat et visible. Ce qu'il évite ne l'est pas : la régression trouvée trois semaines plus tard en production, la session qui redécouvre une convention déjà tranchée, le bug que personne ne sait reproduire. Comparer les deux revient à comparer une facture et une assurance.
Mon expérience, sur mes projets comme sur ceux que je reprends, est sans ambiguïté : la qualité obtenue est d'un autre ordre, et le surcoût se rembourse dès la première régression évitée. Le chapitre 10 vous apprendra où récupérer ces tokens ailleurs, sur les tâches qui n'en méritent pas autant. Payer plus là où c'est utile, moins là où ça ne l'est pas : c'est exactement ça, payer juste.
Une tâche finie, ce n'est pas du code qui marche : c'est du code prouvé, dont le projet se souvient.
Questions fréquentes sur la preuve par les tests
Claude peut-il écrire des tests ?
Oui, et il le fait très bien : tests unitaires, fonctionnels, cas limites auxquels on ne pense pas. La condition tient dans la commande : demandez les tests à partir de la spécification ou du bug décrit, pas à partir du code existant, sinon vous obtenez des tests qui confirment ce que le code fait déjà, bug compris. Et exigez de voir chaque nouveau test échouer avant la correction : un test qui n'a jamais été rouge ne prouve rien.
Comment éviter les bugs quand on code avec une IA ?
En remplaçant la confiance par des preuves exécutables. Chaque tâche confiée à Claude doit avoir un critère de done qu'une machine peut trancher : tests qui passent, build sans erreur, typecheck propre, capture d'écran conforme, application réellement lancée. C'est le levier le plus efficace de toute la pratique, loin devant la relecture humaine, qui attrape le style mais rate les recoins. Le chapitre 8 y ajoute la revue par des rôles séparés.
Qu'est-ce que le TDD avec une IA ?
Le TDD inversé consiste à faire écrire le test avant le code : le test reproduit le bug ou décrit le comportement attendu, on vérifie qu'il échoue, puis Claude implémente jusqu'à le faire passer au vert. Le test devient une spécification exécutable : impossible de déclarer la tâche finie tant qu'il est rouge. Une discipline qui demandait des années d'habitude aux équipes humaines devient naturelle avec un agent qui relance la suite sans se lasser.
Faut-il demander à Claude de mettre à jour la documentation lui-même ?
Oui, et c'est un réflexe qui se paie tout seul. Écrivez une fois dans le brief du projet qu'à la fin de chaque tâche, Claude met à jour le CLAUDE.md et le PRODUCT.md du module si une convention, un piège ou une décision a changé. La mémoire du projet reste ainsi synchronisée avec le code, et la session suivante ne redécouvre pas ce qui a déjà été tranché. Cela consomme un peu plus de tokens, et évite des heures de redécouverte.
Qu'est-ce que le trust-then-verify gap ?
C'est l'écart entre un code qui inspire confiance et un code qui est juste. Le code généré par IA est optimisé pour être plausible : il compile, il est bien présenté, il passe la relecture, et il peut être faux dans un cas limite que personne n'a exécuté. La parade n'est pas de relire plus fort, mais de faire vérifier par des outils : tests, build, lint, typecheck, exécution réelle de l'application.
La suiteVérifier, c'est aussi savoir s'arrêter quand la boucle ne converge pas. Au chapitre 7, l'hygiène de session : interrompre tôt, rembobiner, nettoyer le contexte, et transformer chaque erreur de Claude en amélioration durable.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe