ouvrir guide/chapitre-06 --done
Chapitre 6 · Acte II · Le geste professionnel
La preuve
par les tests
10 min · espace pour avancer, flèches pour revenir
Le trust-then-verify gap
Un code peut cocher toutes les cases de la vraisemblance et rater la justesse.
Le code généré est bien structuré, bien nommé, bien commenté. Il inspire confiance. La vraisemblance et la justesse sont deux propriétés indépendantes.
Ce que la relecture attrape, ce qu'elle rate
La lecture humaine 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 ne se laissent pas impressionner par un code bien présenté.
Quand j'audite une équipe, je ne demande 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 du guide
Un done décoratif
Personne ne peut trancher
- « 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
Une machine tranche, sans opinion
- « npm test passe, y compris les trois nouveaux tests »
- « le build et le typecheck sortent sans erreur »
- « la capture de /checkout est identique à la maquette »
- « l’app démarre et l’inscription va au bout »
La différence de formulation est minuscule. La différence de résultat sépare un produit d'une démo.
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.
Regardez le harnais se mettre en place autour de vous : chaque barre est un test, et elles échouent toutes.
Le piège classique
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. Une suite verte qui valide le bug : pire que pas de tests du tout.
- Parade 1→faire écrire les tests depuis la spécification, sans regarder l'implémentation.
- Parade 2→exiger de voir chaque nouveau test échouer avant la correction.
À vous
Claude a écrit les tests après le code. Tout est vert. Que prouve cette suite ?
Choisissez : la scène vous répond.
Chez Talia · le forfait qui ne se recrédite pas
❯ 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.
Le rouge prouve que le test capture le bug. Le vert prouve que la correction corrige. Et le test reste : ce bug ne pourra plus revenir.
Trois preuves de plus, par ordre de prix
- Build, lint, typecheckLes moins chers de tous : quelques secondes, aucune écriture, et ils attrapent une quantité étonnante d'erreurs. À exiger à la fin de chaque tâche.
- La capture d'écran comparéeUne suite verte n'a jamais garanti qu'un écran est bien aligné. Sur de l'interface, je ne valide jamais sur la sortie du terminal : je valide sur l'image.
- L'application lancéeLa preuve reine : créer un compte, ajouter au panier, payer. La seule vérification qui traverse toutes les couches en même temps.
Boucler jusqu'au vert
Le bon critère de done est celui que Claude peut lancer seul, en une commande.
Vous définissez le vert, il se débrouille pour l'atteindre : il lance, lit l'échec, corrige, relance. Deux garde-fous : un done faible fait converger vers du faux, et il faut interdire explicitement de modifier les tests pendant la correction.
Quatre barreaux, du plus simple au plus dur
- Dans le prompt« Lance les tests et corrige jusqu'au vert », dans le même message. Aucune configuration.
- Dans la sessionLe critère posé comme objectif : un évaluateur le revérifie après chaque tour, et ne se dilue pas.
- En barrière dureUn hook de fin de tour empêche la session de rendre la main tant que la vérification échoue.
- Par un regard neufFaire relire le diff dans un contexte vierge : celui qui note n'est pas celui qui a fait.
Mise en garde sur le dernier : un relecteur à qui l'on demande de trouver des manques en trouvera, même quand le travail est bon. Cantonnez-le à la justesse et aux exigences écrites.
Ce que je demande à la fin de chaque tâche
Une tâche n'est pas finie quand le code marche. Elle est finie quand les tests qui le prouvent existent, que la non-régression a été vérifiée, et que la mémoire du projet est à jour.
Les deux familles de tests : unitaires pour les règles métier, fonctionnels pour le parcours réel.
À écrire UNE FOIS dans le brief, pas à redemander : le done élargi devient le comportement par défaut du projet.
Une tâche livrée avec ses preuves
❯ 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 de tokens. Le surcoût est immédiat et visible ; ce qu'il évite ne l'est pas. Comparer les deux revient à comparer une facture et une assurance.
Fin du chapitre 6
Vérifier, c'est aussi savoir s'arrêter quand la boucle ne converge pas. Au chapitre suivant : interrompre tôt, rembobiner, nettoyer le contexte.
Une 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é a son propre rôle au chapitre 8.