Le lundi matin, je n’ouvre plus un éditeur de code. J’ouvre des conversations. Un agent par projet, chacun avec son périmètre, ses specs et son canal. Je donne le cadre, j’arbitre, je récupère du travail terminé. La journée ressemble beaucoup plus à celle d’un chef de projet qu’à celle d’un développeur.
Et il y a une phrase que je devrais pouvoir dire pour rassurer un client, mais que je ne dirai pas, parce qu’elle serait fausse : je ne relis pas ce code ligne à ligne.
Le chiffre que personne n’aime poser sur la table
Un agent de dev correctement cadré produit, sur une journée, un volume de code qu’un humain met plusieurs jours à écrire. Multipliez par le nombre de projets qui tournent en parallèle. Puis posez la question honnêtement : qui relit tout ça ?
Personne. Ni moi, ni les équipes qui prétendent le contraire. Dans le meilleur des cas, on relit les passages sensibles et on survole le reste. C’est déjà ce qui se passait avant les agents, avec des pull requests humaines de huit cents lignes approuvées en quatre minutes. La différence, c’est que le volume a rendu le mensonge intenable.
Cette question traverse toute l’industrie cette année. On est passés en quelques mois de l’assistant unique qui complète des lignes à des flottes d’agents qui écrivent, testent, relisent et proposent des correctifs, l’humain occupant la place de l’orchestrateur. Le débat ne porte plus sur la capacité des agents à produire du code. Il porte sur ce qui garantit ce code une fois produit.
La relecture humaine était déjà une garantie fragile
Avant d’enterrer la revue de code, il faut être juste avec elle : elle n’a jamais fait ce qu’on lui prêtait.
Une revue porte sur un diff, c’est-à-dire sur ce qui change, jamais sur l’état réel du système après déploiement. Elle repère des erreurs de logique, des oublis, des maladresses de conception. Elle ne voit ni ce qui traîne sur le serveur, ni ce qu’une dépendance transitive a introduit, ni ce que la configuration de l’hébergeur autorise sans le dire.
Autrement dit, la revue a toujours été une lecture d’intention. Utile, mais partielle. On lui a fait porter une promesse de sécurité qu’elle n’a jamais tenue.
Ce que la relecture n’aurait jamais vu
J’ai un exemple précis, et il m’est arrivé à moi. En août, un script de bascule de configuration écrit par un agent a déposé une sauvegarde dans la racine web de l’un de mes SaaS. Pendant environ vingt-quatre heures, ce fichier a été téléchargeable depuis internet, avec des identifiants en clair dedans. J’ai raconté l’incident en détail dans cet article.
Ce qui compte ici, c’est la nature de la faute. Le code du script était correct. Sa logique était correcte. Une relecture ligne à ligne l’aurait validé sans hésiter, parce qu’il n’y avait rien à redire sur les lignes. Le problème n’était pas dans le diff, il était dans l’état du serveur après exécution : un fichier au mauvais endroit, servi par une configuration par défaut que je n’avais jamais vérifiée.
Ce n’est pas une relecture qui l’a trouvé. C’est un contrôle sur le système déployé, demandé après coup. La leçon est désagréable mais claire : la garantie ne se trouvait pas là où je la cherchais.
La garantie a changé de place
Elle est passée du lecteur au pipeline. Concrètement, voilà les portes que je fais passer au code produit par un agent, avant qu’il arrive quelque part où il compte.
- Des specs écrites avant de lancer l’agent. Pas un prompt d’une phrase. Un agent qui ne sait pas précisément ce qu’il construit produit du code qu’on ne peut pas juger, parce qu’on n’a rien à quoi le comparer. C’est la partie la moins spectaculaire du travail et de loin la plus rentable.
- Des tests écrits par un autre agent que celui qui a écrit le code. Règle non négociable. Un auteur qui se note lui-même écrit les tests qui passent, pas ceux qui cherchent la faille.
- Un agent de contrôle en parallèle, dont le seul travail est de chercher ce qui cloche : gardes manquantes, cas limites, écarts par rapport aux specs. Sa revue est bloquante.
- Un scan de secrets et de résidus sur l’artefact déployé, pas sur le diff. C’est exactement ce qui manquait en août. Les fichiers temporaires, sauvegardes et sondes que les scripts de déploiement adorent laisser derrière eux n’apparaissent jamais dans un commit.
- Un contrôle des dépendances, parce qu’un agent qui a le droit d’installer des paquets finit par en installer un de trop.
- Un test d’intrusion automatisé avant mise en ligne, sur l’application telle qu’elle tourne réellement.
Rien dans cette liste n’est révolutionnaire. Ce sont des pratiques d’ingénierie connues depuis quinze ans. Ce qui change, c’est qu’elles sont passées du statut de bonne intention à celui de condition de livraison, parce que plus rien d’autre ne tient.
Bloquant, ou inexistant
Un point mérite d’être isolé, parce qu’il décide de tout le reste : un contrôle qui produit un avertissement est un contrôle mort.
Tout le monde a déjà vu ça. Un tableau de bord avec quarante alertes orange que plus personne ne regarde depuis six mois. Si un contrôle n’arrête pas la chaîne, il ne sert qu’à se donner bonne conscience et à produire une trace en cas de problème. Dans un dispositif où l’humain ne relit plus, la seule chose qui protège, c’est ce qui refuse de continuer.
Cela a un coût immédiat et désagréable : la chaîne s’arrête souvent, y compris pour des faux positifs, y compris à des moments qui arrangent mal. C’est le prix, et il se paie tous les jours.
Ce que l’humain garde, et qui n’est pas délégable
Déplacer la garantie ne veut pas dire disparaître. Quatre choses restent entièrement de mon côté.
Le périmètre, d’abord : décider ce qu’on construit et surtout ce qu’on ne construit pas. Un agent ne dira jamais non à une fonctionnalité inutile, il la codera très bien.
Les choix d’architecture ensuite, parce qu’ils engagent des années et qu’un agent optimise ce qu’on lui demande, dans l’horizon qu’on lui donne.
Les arbitrages, quand un contrôle bloque et qu’il faut décider entre corriger, contourner ou repousser. C’est une décision de risque, elle n’appartient pas à la machine.
Et la responsabilité, qui est la seule chose vraiment non délégable. Quand un client subit un incident, personne n’acceptera « c’est l’agent qui l’a écrit ». Ce n’est d’ailleurs pas une excuse, c’est un aveu d’absence de dispositif.
L’économie s’inverse
Voilà ce qui m’a le plus surpris en pratique. Écrire le code est devenu la partie la moins chère du travail. La vérifier est devenue la plus chère.
Construire ce pipeline, le maintenir, traiter ses faux positifs, réparer ses trous quand un incident en révèle un, tout cela représente aujourd’hui l’essentiel de l’effort. Ce n’est plus une charge annexe, c’est le produit. Une équipe qui accélère la génération sans investir la même énergie dans la vérification ne gagne pas du temps, elle avance sa dette.
Si vous achetez du développement à quelqu’un qui travaille comme ça
De plus en plus de prestataires livrent du code produit par des agents. Beaucoup ne le disent pas. Trois questions suffisent à savoir à qui vous avez affaire.
- Qui écrit les tests ? Si c’est le même agent que celui qui écrit le code, la réponse est mauvaise, et elle l’est pour une raison structurelle, pas par méfiance de principe.
- Quels contrôles sont bloquants ? Demandez la liste, pas une philosophie. S’il n’y a que des rapports et des avertissements, il n’y a rien.
- Que se passe-t-il quand un contrôle échoue ? La bonne réponse est ennuyeuse : ça s’arrête, quelqu’un regarde, ça repart. Si la réponse est floue, c’est que la question ne s’est jamais posée, donc que la chaîne ne bloque jamais.
Et si vous vous demandez ce que ça donne quand ce n’est pas encadré, la réponse tient en une phrase : un fichier de sauvegarde téléchargeable pendant vingt-quatre heures, avec les identifiants de production dedans.
La revue de code ligne à ligne ne reviendra pas. Elle ne tenait déjà plus la route avant les agents, et le volume produit aujourd’hui l’a définitivement rendue décorative. Ce qui la remplace n’est ni magique ni confortable : c’est une chaîne de contrôles qui dit non, souvent, et qu’il faut payer.
Je construis et je livre des applications métier avec ce type de dispositif. Si vous voulez en parler concrètement, c’est par ici.