Chapitre 5.4 — Vérifier le travail
⏱️ TL;DR — « Ça devrait marcher » n’est pas une preuve. La compétence qui sépare l’amateur de l’ingénieur augmenté : exiger l’observation. Faire lancer le code, exercer le vrai flux, lire la diff — pas se fier à l’affirmation de l’agent. Les tests et le build sont des preuves ; « j’ai vérifié » n’en est pas une tant que tu ne vois pas la sortie. La skill
/verifyexiste justement pour piloter cette vérification de bout en bout.
🎯 Objectifs
- Distinguer une preuve d’une affirmation.
- Faire vérifier un changement par l’observation du comportement.
- Utiliser
/verifyet le lancement réel de l’app. - Lire une diff de façon critique.
Affirmation ≠ preuve
L’agent conclut souvent par « c’est fait, ça devrait fonctionner ». C’est une affirmation, pas une preuve. La boucle agentique (1.1) est puissante quand elle observe ; si l’agent s’arrête avant d’observer (parce que rien ne l’y force), il peut livrer du code plausible mais faux.
| Affirmation (insuffisant) | Preuve (suffisant) |
|---|---|
| « les tests devraient passer » | la sortie de npm test montrée, verte |
| « l’écran fonctionne » | l’écran lancé, le flux exercé, le résultat observé |
| « j’ai géré le cas d’erreur » | un test qui déclenche l’erreur et vérifie le comportement |
| « le build est bon » | npm run build exécuté, sortie sans erreur |
💡 Réflexe d’architecte — Termine tes prompts par « montre-moi la preuve » : « …et lance
npm test, montre la sortie » ; « …ouvre l’écran et décris ce que tu vois ». Tu transformes une conclusion en observation. Le simple fait de demander la preuve change ce que l’agent fait dans sa dernière boucle.
Vérifier par le comportement, pas par le code
Relire le code te dit qu’il a l’air juste. Seul l’exécution te dit qu’il fait la bonne chose. Trois niveaux d’observation, du plus léger au plus fort :
- Typecheck/lint : nécessaire, pas suffisant (du code typé peut être faux).
- Tests : la preuve reproductible que le comportement attendu tient sur des cas précis.
- Exercer le vrai flux : lancer l’app et faire l’action (créer une tâche, la supprimer) — la seule preuve que l’utilisateur réussira.
Un changement sérieux mérite le niveau adapté : un util pur → un test ; un écran → l’exercer réellement.
La skill /verify et le lancement réel
La skill /verify est faite pour ça : elle pilote la vérification de bout en bout — elle exerce le flux affecté et observe le comportement, au lieu de se contenter d’un typecheck. À utiliser avant de considérer un changement non trivial comme « fini ». (Elle amorce même une routine de vérif propre au projet si tu n’en as pas.)
De même, faire lancer l’app (voir la skill /run, Partie 10/11) pour voir le changement dans le vrai produit est souvent la vérification la plus honnête. « Les tests passent » et « l’écran marche vraiment » ne sont pas la même garantie ; les deux comptent.
⚠️ Piège — Se fier au typecheck vert comme preuve que « ça marche ». Le typecheck prouve que les types sont cohérents, pas que le comportement est correct. Un
deleteTaskqui compile parfaitement peut oublier de rafraîchir la liste. Seul l’exercice du flux le révèle.
Lire une diff de façon critique
Avant d’accepter un changement, lis la diff — surtout sur le code de production (moins besoin sur des tests ou de la doc). Ce que tu cherches :
- des modifications hors périmètre (l’agent a touché à autre chose « au passage ») ;
- un contournement de tes conventions (un
any, une valeur en dur, une primitive réinventée) ; - un cas manquant (l’erreur, l’état vide, la limite) ;
- de la complexité inutile ajoutée.
Tu n’as pas à tout relire ligne à ligne : concentre-toi sur les fichiers de cœur métier et le fichier-modèle ; survole le reste. Le harness te donne des liens cliquables fichier:ligne — sers-t’en.
🧭 Sur TaskFlow — À chaque étape du CRUD (5.5), on conclura par une preuve : le test de l’action + l’exercice du flux dans l’app. On ne dira jamais « la suppression marche » sans avoir vu une tâche disparaître réellement. En Partie 7, on rendra la partie « tests verts » automatique (hook), pour que la preuve minimale soit garantie sans y penser.
✏️ Exercices
Exercice 1 — Exige la preuve. Sur ta prochaine tâche, termine par « lance les tests et montre la sortie ; ouvre l’écran et décris ce que tu vois ». Compare avec ta pratique habituelle : combien de fois « ça devrait marcher » cachait un défaut ?
✅ Solution
Assez souvent, exiger la preuve révèle un écart : un test rouge « oublié », un flux qui casse sur un cas limite, un rafraîchissement manquant. Le coût est minime (une phrase de plus) ; le gain, énorme (tu ne livres pas du faux-positif). Fais-en un réflexe de fin de tâche.
Exercice 2 — Diff critique. Prends un changement récent produit par l’agent. Lis sa diff avec la grille (hors périmètre / contournement / cas manquant / complexité). Trouves-tu au moins un point ?
✅ Solution
La grille remonte souvent un petit hors-périmètre (« tant que j’y étais… ») ou un cas non géré. Repérer ces points avant le merge évite qu’ils s’installent. Concentre ta lecture sur le cœur métier ; c’est là que les défauts coûtent cher.
🧠 Quiz de révision
1. Pourquoi « ça devrait marcher » ne suffit-il pas ?
Parce que c’est une affirmation, pas une preuve. La boucle de l’agent n’est fiable que lorsqu’elle observe ; sans observation forcée, il peut livrer du code plausible mais faux.
2. Quels sont les trois niveaux d’observation ?
Typecheck/lint (ça compile), tests (ça fait X sur des cas), exercer le vrai flux (l’utilisateur peut faire Y). Du plus léger au plus fort ; on choisit selon l’enjeu.
3. Le typecheck vert prouve-t-il que « ça marche » ?
Non : il prouve que les types sont cohérents, pas que le comportement est correct. Un code parfaitement typé peut oublier de rafraîchir une liste. Il faut exercer le flux.
4. À quoi sert la skill /verify ?
/verify ?À piloter la vérification de bout en bout : exercer le flux affecté et observer le comportement, plutôt que se contenter d’un typecheck. À lancer avant de déclarer « fini » un changement non trivial.
5. Sur quoi concentrer la lecture d’une diff ?
Sur le cœur métier et le fichier-modèle (survol du reste). On cherche : modifs hors périmètre, contournement de conventions, cas manquant, complexité inutile.
Chapitre suivant : Atelier — première feature de TaskFlow — le CRUD des tâches, en pilotant toute la boucle.