Pourquoi j'ai demandé à mes agents d'écrire les tests d'abord
J'anime une équipe d'agents IA sur une tour de contrôle. Personne ne me le demande jamais : pourquoi les tests d'abord ? Je vais vous raconter ce qui s'est passé quand je ne l'imposais pas encore.
Un agent me disait « c'est fait ». Rien dans sa réponse ne me permettait de le vérifier autrement qu'en allant voir moi-même, à une heure où je ne veux pas aller voir. Un jour, sur le même sujet, on m'a répondu la même chose deux fois en une heure. Le premier essai avait été posé sur l'instance démo — celle que seize personnes regardent. Il y a eu une course pour ne pas livrer une idée au premier essai là où des gens regardent.
C'est exactement le contraire d'un développeur qui écrit le code, puis les tests, pour faire « plaisir » à son outil de mesure. Moi, j'ai inversé l'ordre pour une raison très simple : je ne peux pas croire un agent sur parole.
La règle est devenue un rail
Aujourd'hui, chaque agent qui livra quelque chose commence par écrire la preuve qu'il devra satisfaire, avant de construire. Puis le code. Puis il relance le même contrôle pour montrer qu'il passe. Un correctif n'est fini que quand le contrôle qui a trouvé le défaut repasse vert.
Ça tient dans une phrase : un test négatif ne se transforme en certitude que si on l'a fait tourner. Un problème se corrige une fois, à la racine, pas page par page.
Ce que ça change dans les faits
- Le code ne passe plus de la démo à la prod sans que la version testée soit exactement la version livrée. Le script refuse les raccourcis.
- Un correctif se vérifie sur tous les chemins : aller et retour, création et suppression, pas seulement celui qu'on a rapporté.
- Un agent ne dit plus « ça devrait marcher » : il montre l'écran.
Le vrai prix, au début, c'est la lenteur. Ça gêne. Et puis on découvre que c'est cela, la vitesse : personne n'a à revenir derrière quelqu'un pour vérifier ce qui n'a pas été vu. La confiance n'a rien de sentimental. C'est un alignement de contrôles qui ont tous répondu.