Six agents IA ont écrit un écran complet de mon cockpit en deux heures. Ce n'est pas la partie intéressante.
TL;DR : la génération de code n'est plus le goulot d'étranglement. La preuve, si. Un workflow multi-agents ne vaut que par son harnais de vérification. Le mien exige quatre preuves : parité visuelle avec le design, parcours cliqués au navigateur, tests verts, punch-list vide. Donne à tes agents des obligations de preuve. Pas des instructions plus longues.
Cet article est pour les devs qui utilisent des agents de code et veulent livrer avec, pas juste faire des démos.
Le contexte
Mon cockpit de prospection est une app perso en Go. Du SSR avec html/template, du htmx, un PostgreSQL derrière.
Il me fallait un écran entier de plus : liste, vue détail, ajout, édition de statut. La maquette existait. Un écran voisin servait de modèle de code.
J'ai orchestré un workflow multi-agents : des agents IA spécialisés qui s'enchaînent, chacun avec un rôle. Backend, design, vérification, tests. Six agents au total, environ deux heures.
À la fin : le store, la migration, les handlers, le template, la navigation et les tests, mergés. Mais le mérite n'est pas où on le met d'habitude.
Une instruction ne se vérifie pas. Une preuve, si
« Fais l'écran » est une instruction. Un agent répond toujours la même chose à une instruction : « c'est fait ».
Parfois c'est vrai. Parfois c'est plausible. Et le plausible est le vrai danger, parce qu'il passe la relecture rapide.
La solution n'est pas d'écrire des prompts plus longs. C'est de changer la nature de la demande : chaque agent reçoit une obligation de preuve, binaire, vérifiable sans lui.
Pour cet écran, il y en avait quatre. L'écran est identique au design, en thème clair et en thème sombre. Les quatre parcours passent dans un vrai navigateur. La suite de tests est verte. La punch-list est vide.
Une punch-list est la liste des écarts restants, héritée du bâtiment. Tant qu'elle n'est pas vide, ce n'est pas livré.
Preuve n°1 : la parité visuelle se mesure, elle ne se déclare pas
Le piège classique : l'agent affirme que l'interface est conforme. Personne ne compare vraiment.
Chez moi, un inspecteur de design tourne sur un port dédié. Il affiche la maquette de référence, à côté du rendu réel de l'app.
L'agent de vérification compare les deux, écran par écran, dans les deux thèmes. Chaque écart part dans la punch-list : un espacement, une couleur, une ombre, un état vide.
Le verdict de ce run : approuvé, punch-list vide, en clair et en sombre. Ce verdict est un fait, pas une opinion d'agent.
Preuve n°2 : les parcours se cliquent dans un vrai navigateur
La semaine dernière, j'écrivais qu'une suite E2E verte peut mentir quand elle asserte du JSON au lieu du DOM. La règle vaut double pour du code écrit par un agent.
Donc les quatre parcours de l'écran ont été joués dans un vrai navigateur, sur l'app réelle. Ajouter une cible. Ajouter une personne. Changer un statut. Promouvoir un dossier.
Pas de simulation, pas d'appel d'API direct. Le formulaire, le clic, le rendu. Ce que verra l'utilisateur, vérifié comme l'utilisateur.
Preuve n°3 : les tests restent le sol
Le classique garde sa place, en barrière de sortie : go build, go vet, et la suite complète. Ce run s'est terminé à 167 tests verts.
Détail qui compte : les tests du store PostgreSQL sont gardés par une variable d'environnement. Sans base de test, ils se skippent proprement. La suite reste rejouable partout, par un humain comme par un agent.
Preuve n°4 : l'environnement est une règle écrite
Le premier lancement du workflow a fait n'importe quoi. Binaire local lancé à la main, tentative de pkill sur des process qui tournaient.
Je l'ai corrigé en cours de run, et la correction est devenue une règle écrite du harnais. Jamais de pkill. Toujours reconstruire et relancer par docker compose. Le jeu de données de démo est idempotent, derrière une variable d'environnement.
C'est le vrai cycle d'apprentissage : chaque erreur d'agent devient une règle du harnais. Pas un meilleur prompt. Une règle, écrite, que le prochain run ne pourra pas contourner.
Ce que ça change, et ce que ça ne change pas
Le temps humain ne disparaît pas. Il se déplace. Je passe moins de temps à écrire du code, et plus de temps à définir des preuves, arbitrer une punch-list, relire un diff.
C'est le bon échange. La génération est rapide partout. La confiance, elle, ne vient que du harnais.
Et les limites sont réelles. Ce workflow a marché parce qu'une maquette de référence existait, et qu'un écran voisin donnait le modèle de code. Sans référence exigible, le harnais n'a rien à comparer, et l'agent retombe dans le plausible.
La checklist avant de lancer un workflow d'agents
Avant de confier une feature à des agents, passe cette liste. C'est elle qui sépare l'outil de production du générateur de démos.
- Une référence exigible existe : maquette, écran modèle, contrat d'API
- Chaque agent a une obligation de preuve binaire, pas un objectif flou
- La vérification visuelle compare au design, dans les deux thèmes
- Les parcours critiques se jouent dans un vrai navigateur, assertions sur le DOM
build,vetet tests sont des barrières, pas des suggestions- L'environnement est réglé par des règles écrites : docker, seed idempotent, ports
- Chaque erreur d'agent devient une règle du harnais, pas un meilleur prompt
Ce qu'il faut retenir
Les agents n'ont pas besoin de meilleures instructions. Ils ont besoin d'obligations de preuve.
Un écran livré en deux heures n'a de valeur que si tu peux dire pourquoi tu lui fais confiance. Chez moi, la réponse tient en quatre preuves, toutes vérifiables sans demander son avis à l'agent.
Construis le harnais une fois. Il resservira à chaque feature, et il vieillit mieux que n'importe quel prompt.
Tu veux industrialiser des agents de code sans livrer du plausible ? Parlons-en.