Je ne lis plus le code de mes agents
(Publié le 16 octobre 2026 - English version)
Dit comme ça, c'est de l'inconscience, et pourtant Robert C. Martin a écrit sur X qu'il ne lisait plus une ligne du code produit par ses agents. C'est le même Martin qui a écrit Clean Code, le livre qui a convaincu toute une génération de développeurs qu'un code propre se lit comme une prose bien écrite.
Je n'ai découvert ce message que récemment, alors que ce texte dormait dans mes brouillons depuis longtemps, parce que je voulais d'abord éprouver mes pratiques sur un projet réel. Martin entoure ses agents de contraintes très strictes et je fais à peu près la même chose, mais ces quelques mois m'ont surtout montré sur quoi repose ma confiance. Elle repose sur la spécification, ce document que personne ne relisait après la première implémentation, et sur les tests qui en découlent. Ils servent deux fois, aujourd'hui pour l'agent qui implémente et demain pour celui qui fera évoluer le projet.
Les tests disent à l'agent ce qu'il doit produire
L'agent ressemble au sous-traitant d'autrefois, compétent mais ignorant du métier, qui comble chaque trou de la spécification en devinant. C'est à lui qu'on remettait des spécifications détaillées, et les tests d'acceptance en jouent aujourd'hui le rôle, par l'exemple. La spécification dit ce que l'application doit faire, et les tests montrent ce qu'elle doit répondre dans une situation précise, si bien que l'agent n'a plus à deviner.
De chaque spécification, l'agent tire ces tests en langage naturel, écrits avant le code, et je le pousse à les rendre les plus profonds possible, avec le maximum de cas et surtout les cas aux limites. Pendant l'implémentation, il les rejoue et sait tout de suite si ce qu'il vient d'écrire fonctionne, ce qui le rend bien plus autonome.
L'agent compile ensuite ces tests en un script qui interroge l'application sans repasser par le LLM, et le verdict ne peut donc plus être halluciné, même s'il ne vaut que ce que vaut le test. Les tests unitaires, l'analyse statique et les règles d'écriture complètent le dispositif et gardent le code lisible par un humain, le jour où il faudra quand même le lire.
La spécification est un investissement sur l'avenir du projet
Le jour où l'on revient sur l'application pour demander une évolution, tout dépend de ce qui a été écrit.
Sans spécification, l'agent doit d'abord comprendre comment l'application fonctionne. Il fait de la rétro-ingénierie et cherche à coups de grep le code qu'il devra modifier, au risque de changer un endroit sans voir qu'un autre, plus loin, en dépendait. Avec une spécification à jour, il sait où il met les pieds : il a les informations nécessaires pour poursuivre le travail sans reconstituer les intentions à partir du code.
Un développeur ne fait pas autrement quand il reprend le travail d'un collègue, ou son propre code après des mois d'absence. La spécification ne sert donc pas seulement à cadrer l'implémentation, elle est la mémoire du projet, et c'est elle qui lui permettra d'évoluer sur le long terme.
Quand le projet grossit, la contradiction menace cette mémoire bien plus que le volume. L'agent ne charge que ce dont il a besoin, mais quand deux fichiers se contredisent, il ne sait plus lequel croire. C'est pourquoi chaque modification de spécification s'accompagne d'une recherche de contradictions. Cette règle peut paraître anecdotique, mais elle est en vérité déterminante pour le vieillissement du projet.
C'est sur cette mémoire que se fait la différence entre un développeur qui maîtrise le développement agentique et le vibe coder, c'est-à-dire celui qui se contente de prompter et de regarder le résultat tourner. Quand il revient sur son projet pour le faire évoluer, il prompte à nouveau, l'agent refait sa rétro-ingénierie, et dès que le projet devient complexe, il casse des choses. Je pense que les entreprises qui codent vite de cette façon s'en mordront les doigts, le jour où leur taux de bugs explosera.
Pour la première fois, la spécification reste à jour
Une spécification fausse ou des tests qui couvrent mal les cas, ça existait bien avant l'IA et ça existera encore, car le problème a toujours été ailleurs.
Dans beaucoup d'entreprises, l'expression de besoin, les spécifications et les tests d'acceptance étaient écrits par d'autres personnes que celles qui implémentaient. En cours de route, on découvrait des anomalies et on précisait des points, mais le développeur ne remontait presque jamais ces décisions dans la spécification, parce qu'un développeur n'aime pas écrire. Avec le temps, la spécification finissait par décrire un logiciel qui n'existait plus, au point que "pas la peine de chercher dans la spec, elle n'est pas à jour" était devenu une blague de couloir. Pourquoi croyez-vous que l'une des quatre valeurs du manifeste agile est "des logiciels opérationnels plus qu'une documentation exhaustive" ? Avec un agent, qui repart à froid à chaque session, cette documentation devient la mémoire du projet.
Avec l'IA, la spécification, les tests et le code se mettent à jour en quelques instants, mais dans l'ordre : la spécification d'abord, validée par un humain, puis les tests qui en découlent, et le code en dernier. On pourrait y voir un retour au cycle en V, sauf que ces documents ne sont plus figés avant le code : ils se réécrivent à chaque changement. Chaque erreur et chaque mauvaise expérience viennent ainsi enrichir la spécification et les tests au lieu de se perdre dans le code.
Un développeur de l'équipe devait un jour changer un simple numéro de port, et il a trouvé bien lourd de passer d'abord par la spécification. En chemin, on a découvert que nos hôtes "primary" et "replica" pointaient vers le même HAProxy et que seul le port séparait les écritures des lectures, une contrainte d'architecture écrite nulle part, qui l'est désormais dans la spécification.
Ce que je lis à la place du code
Je ne lis donc plus le code, parce que la spécification et ses tests disent mieux que lui ce que l'application doit faire. Ma relecture n'a pas disparu, elle s'est déplacée vers la spécification, comme la revue de code a changé d'étage, et c'est là que se prennent désormais les décisions.
Je ne suis d'ailleurs pas le seul à faire ce chemin, et la démarche commence à se formaliser sous le nom de spec-driven development, avec ses outils et ses formats de spécification pensés pour les agents. La plupart de ces outils traitent pourtant la spécification comme le point de départ d'une implémentation, sans dire ce qu'elle devient ensuite, alors que sa valeur se mesure surtout des mois plus tard, le jour où il faut faire évoluer le projet.
Reste à savoir combien d'équipes accepteront ce détour par la spécification pour un simple numéro de port, alors que c'est lui qui protège le projet.
Cet article est le troisième d'une série sur le travail avec les agents, après J'ai arrêté de lancer plusieurs agents et Ceux qui ont supprimé la revue de code ont raison.
Suivez-moi sur Bluesky: @bouchery.fr
