Tester : donner à Claude une boucle de vérification

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Donner à chaque session un moyen de vérifier son propre travail avant qu’un humain le voie
• Protéger la vérification elle-même, pour qu’un agent ne puisse pas l’affaiblir

Ce qui change

Traditionnellement, le signal que le code fonctionne arrive tard : la CI quelques minutes plus tard, un testeur quelques jours plus tard, la production quelques semaines plus tard. Avec un agent qui produit le code, un signal tardif oblige une personne à tout vérifier, et cette personne devient le goulot d’étranglement.

Dans un cycle AI-native, la session reçoit un moyen de vérifier son travail — lancer les tests, le build, prendre une capture d’écran — et itère jusqu’à ce que la vérification passe. Ce qui arrive à l’ingénieur a déjà passé ce contrôle. Mettre en place la boucle revient à l’ingénieur qui pilote la session.

La boucle tourne pendant toute la tâche, autant de fois que nécessaire ; le sous-agent vérificateur de la leçon 7 en est une autre forme, qui fait le contrôle final dans un contexte neuf, non influencé par les hypothèses qui ont produit le code.

Pour démarrer

• Prérequis : aucun.
• Infrastructure : une suite de tests et un build qui se lancent localement en une commande chacun ; pour l’interface, un moyen pour Claude de voir le résultat (un outil de navigateur ou de capture d’écran, branché par MCP).

Mise en œuvre

1. Assurez-vous que les tests se lancent en une commande (make test, npm test) qui sort en erreur en cas d’échec.
2. Dans la section des commandes du CLAUDE.md, listez chaque commande avec un exemple de sortie saine, et demandez explicitement de les lancer avant d’annoncer qu’une tâche est terminée.
3. Pour un bogue, écrivez d’abord le test qui échoue. Demandez à Claude de reproduire le bogue sous forme de test, de le lancer et de confirmer qu’il échoue pour la raison attendue. Enregistrez ce test. Ensuite seulement, demandez de le faire passer sans le modifier. Un test qui existait avant le correctif, et que l’agent n’a pas pu réécrire, prouve que le bogue a disparu.
4. Pour l’interface, fermez la boucle visuellement : donnez à Claude un outil de capture et la maquette, et laissez-le itérer — implémenter, capturer, comparer, ajuster. Deux ou trois tours sont normaux.
5. Protégez la boucle : un agent qui corrige du code ne doit pas pouvoir affaiblir le contrôle de ce code. Un hook qui bloque la modification des fichiers de test pendant une tâche de correction s’en charge ; à défaut, rejetez en revue tout changement qui touche un test.

## Vérifier son travail
- Build : make build (doit se terminer par « Build succeeded »)
- Tests : make test (tout au vert ; ne jamais ignorer ni supprimer un test qui échoue)
- Lint : make lint (zéro avertissement)
Lance les trois avant d'annoncer qu'une tâche est terminée, et colle leur sortie.
Si un test échoue, corrige le code, pas le test.

Gouvernance

• Ce qui est imposé : la vérification avant l’annonce de fin, et l’interdiction pour l’agent de modifier les tests pendant un correctif, sous forme de hooks là où l’organisation veut une garantie.
• Ce qui fait preuve : la sortie réelle des tests, le journal de build ou la comparaison de captures, collés par Claude : la preuve vient de la chaîne d’outils.
• Où c’est tracé : dans la transcription de session, que l’export OpenTelemetry transmet à la supervision de l’organisation, et dans les vérifications de la pull request.
• Qui approuve : le responsable du code qui relit la pull request, libre de se concentrer sur l’intention et le risque, puisque la preuve mécanique est déjà jointe.

Mesurer

• Indicateur avancé : le taux de réussite de la CI au premier passage pour les changements écrits par l’agent.
• Indicateur retardé : le temps de revue par pull request, qui doit baisser quand les tests attrapent ce que les relecteurs attrapaient, et le taux d’échec des changements, suivi dans l’outil d’incidents.

À vous de jouer

Le test qui échoue d’abord. Prenez un bogue connu et demandez à Claude de le reproduire sous forme de test, de le lancer et de confirmer qu’il échoue pour la bonne raison. Enregistrez ce test, puis demandez le correctif sans le modifier. Ajoutez au CLAUDE.md la rubrique « Vérifier son travail » avec vos trois commandes et leur sortie saine, et décrivez le hook qui interdirait de toucher aux tests pendant un correctif.

Sources officielles : Give Claude a feedback loop (Claude Academy) · The AI-native SDLC playbook — Stage 4: Test · Best practices for Claude Code · Hooks guide

Points clés à retenir

• Donnez toujours à Claude un moyen de vérifier son travail : tests, build, capture d’écran
• Pour un bogue, le test qui échoue d’abord, enregistré avant le correctif
• Protégez la boucle : l’agent ne doit pas pouvoir modifier les tests qu’il doit faire passer
• La preuve vient de la chaîne d’outils, et libère le relecteur pour l’intention et le risque