Un agent de code qui termine une tâche écrit souvent « C'est corrigé ». C'est là que se trouve le danger. Si l'agent n'a pas reçu les outils pour vérifier lui-même son travail, cette phrase est souvent fausse. Elle mène à des corrections qui ne corrigent rien, et parfois à des incidents graves en production.
Nous exigeons donc que chaque agent joigne la preuve qu'il a obtenue lui-même. Sans elle, la tâche n'est pas terminée. Cette règle détermine ce que nous confions à l'IA, ce que l'équipe relit et ce que vous recevez à chaque livraison.
Pas de preuve, pas de « terminé »
Un modèle de langage écrit la suite la plus probable d'un texte. Après une correction, la suite la plus probable est « c'est corrigé », que la correction fonctionne ou non. Seule l'observation du résultat tranche. Un ingénieur de Cursor en a fait un principe de sa méthode 
pstack · Prove it works : « ça compile » ne prouve rien, l'agent doit observer le résultat réel.
Chaque agent joint donc la preuve de ce qu'il annonce : le test qui échouait et passe désormais, les captures de la page sur mobile et sur ordinateur. Quand il n'a pas pu vérifier, il écrit « non vérifié ».
Ce qu'un agent doit pouvoir vérifier seul
Exiger des preuves ne sert à rien si l'agent ne peut pas les obtenir. Nous lui donnons donc les moyens de contrôler son travail.
- La documentation à jour des outils qu'il utilise, pour vérifier qu'une fonction existe au lieu de s'en souvenir.
- Une carte des dépendances du code, pour savoir ce qu'un changement peut casser avant de le faire.
- Un navigateur et des simulateurs, pour ouvrir chaque page sur mobile, tablette et ordinateur.
- Des tests de parcours, où un agent suit un objectif comme « passer à l'offre Pro » et où une vérification exacte contrôle le résultat affiché.
Quand un agent signale un défaut, il doit le reproduire par un test avant que nous le prenions en compte. Ce test reste ensuite dans le produit et rejoue le scénario à chaque modification.
Ce que nous confions à un agent
Notre critère tient en une question. Peut-on vérifier le résultat sans relire tout le code ? Erik Schluntz, ingénieur chez Anthropic, compare une application à un arbre dans sa conférence 
Vibe coding in prod. Nous utilisons cette image pour décider où va la relecture humaine.
Où va la relecture humaine
Feuilles
Un écran de rapport, un export, une page d'administration.
Confiées à un agent, jugées sur leurs résultats testés.
Branches
Un parcours de réservation, un formulaire partagé.
Contrats testés. Tout changement de contrat est relu.
Tronc
Les données, les droits d'accès, le paiement.
Compris et relu par l'équipe à chaque changement.
Les feuilles sont les fonctionnalités dont rien ne dépend. Quand leurs entrées et leurs sorties sont testées, leur résultat suffit à les juger. Le tronc porte les données, les droits d'accès et le paiement. L'équipe le comprend et le relit, parce que tout le reste en dépend et qu'aucun test ne mesure la dette technique.
Chaque test ajouté rend une partie de plus vérifiable, donc confiable à un agent. C'est pourquoi près d'un tiers du code que nous écrivons sert à vérifier le reste.
Ce que l'équipe décide
L'agent exécute vite. Décider de ce qu'il faut exécuter, et de la manière de savoir que c'est juste, reste le travail de l'équipe.
Les bonnes questions, avant la première ligne de code. Que se passe-t-il si le paiement échoue à mi-parcours ? Qui peut voir les données d'un autre client ? Que fait l'application sans connexion ? Un agent ne pose pas ces questions de lui-même. Savoir les poser vient de projets livrés et de pannes corrigées. Erik Schluntz le souligne aussi : sans les bonnes questions, on ne pilote pas un agent, on le subit.
L'architecture. Les frontières entre les modules, les données partagées et ce qui doit pouvoir évoluer forment le tronc de l'application. Un agent reproduit la structure qu'il trouve, bonne ou mauvaise. C'est donc à l'équipe de la dessiner.
La définition de « terminé ». Avant chaque tâche, l'équipe écrit ce qui doit être vrai pour qu'elle soit finie : les cas à couvrir, les résultats attendus, les écrans à vérifier. Un test peut passer avec un résultat faux si le résultat attendu est faux. Le montant d'un remboursement, la règle d'une annulation ou le droit d'un utilisateur se décident donc avec vous, puis s'écrivent dans les tests. L'agent écrit ensuite le code qui les respecte.
Du code prêt pour la production
Chaque évolution arrive testée, vérifiée sur mobile et sur ordinateur, avec l'adresse de la version à valider. Vous contrôlez le résultat vous-même avant la mise en production.
Quatre questions à poser à vos développeurs
- Comment vos agents prouvent-ils ce qu'ils annoncent ?
- Quelles parties de mon produit une personne relit-elle, et pourquoi celles-là ?
- Qui fixe les résultats attendus dans les tests ?
- Que recevrai-je pour valider une évolution ?
Vous voulez reprendre une application existante ou en construire une avec cette méthode ? Parlons-en.
SaaS
Swiss Made Software