Il y a quelques jours, nous avons finalisé une livraison de 47 commits en 24 heures, répartis entre le backend et le frontend. Ils ont été réalisés par une seule personne travaillant avec un agent de codeAgent de codeUn agent d'IA qui écrit, modifie et teste du code de manière autonome au sein d'un projet. C'est un chiffre qui attire l'attention, et c'est pourquoi il convient de préciser d'emblée que ce n'est pas le plus important.
Ce qui est important, c'est de comprendre pourquoi cela a été possible, et ce qui se serait passé si le même outil avait été entre d'autres mains.
Écrire du code n'est plus le goulot d'étranglement
Un agent de code écrit vite, ne se fatigue pas et enchaîne des dizaines de modifications en une journée. Cela n'élimine pas le problème : cela le déplace. Auparavant, le plus long était de produire le code. Désormais, le plus long est de savoir de quel code on a besoin et de vérifier que celui qui a été écrit fait ce qu'il doit faire.
En d'autres termes : l'agent apporte la vitesse. La direction est donnée par la personne.
Ce qui se multiplie
Un agent amplifie la personne qui le dirige, dans les deux sens.
Si vous connaissez bien le système, que vous savez dans quel ordre faire les choses et que vous reconnaissez une erreur quand vous la voyez, l'agent transforme cette connaissance en travail accompli à un rythme qui n'existait pas auparavant.
Si vous ne le connaissez pas, l'agent transforme vos lacunes en code avec la même rapidité. Et il le fait avec une apparence soignée, ce qui est précisément ce qui le rend dangereux.
Un exemple, fictif mais très parlant. Une boutique en ligne décide de ne plus enregistrer les prix avec des décimales et de passer aux centimes entiers, afin d'éliminer les écarts d'arrondi. L'agent reçoit l'ordre, localise la vingtaine de fichiers concernés et les modifie tous en un après-midi. Les tests passent. Le code est lisible. Deux semaines plus tard, les remises en pourcentage commencent à afficher un centime de moins dans certains paniers. Dans un seul de ces fichiers, l'agent a arrondi avant de multiplier au lieu de le faire après. Personne ne l'a vu parce que les données de test étaient des montants ronds et parce que la modification avait exactement la même apparence que les vingt autres.
Quiconque connaissait ce calcul aurait demandé un test avec 19,99 € et 15 % avant d'accepter quoi que ce soit. Dans le cas contraire, on a accepté une modification correcte dans vingt endroits et erronée dans un seul, avec la même confiance dans les vingt et un.
C'est pourquoi cette phrase fonctionne dans les deux sens : l'agent multiplie ce que vous savez déjà, mais aussi ce que vous ignorez.
Trois choses que doit maîtriser la personne qui dirige un agent
1. Que demander. Il faut connaître le système suffisamment pour diviser le travail en étapes délimitées, les franchir dans le bon ordre et savoir quand le résultat ne correspond pas à ce qui a été demandé. Un agent répond à la question que vous lui posez, pas à celle que vous auriez dû lui poser.
2. À quoi il peut toucher. Les autorisations d'un agent doivent être minimales et explicites : quels repositories, quelles branches, quels credentials, et s'il a ou non accès à la production. Donner un accès total « pour aller plus vite » est le moyen le plus court de transformerTransformerL'architecture de base de presque tous les modèles de langage actuels une petite erreur en une grande.
3. Jusqu'où il va. Toutes les actions n'ont pas le même poids. Une modification sur une branche peut être annulée ; une suppression de données ou un déploiement mal effectué, pas toujours. Les actions irréversibles sont révisées par une personne avant d'être exécutées, sans exception.
Comment nous procédons
Ce n'est pas de la théorie. Notre quotidien avec les agents repose sur quatre règles non négociables :
- L'agent travaille librement en local et sur des branches de travail. Il ne touche pas à la production sans qu'une personne ne donne son accord, étape par étape.
- Avant de déployer, un backup de ce qui va être remplacé et une procédure de rollback déjà rédigée sont requis. Si quelque chose échoue, on restaure en une minute, on n'improvise pas.
- Les tests sont exécutés avant de toucher à quoi que ce soit, puis de nouveau sur le serveur après. Si l'un d'eux échoue, le déploiement n'a pas lieu, peu importe l'urgence.
- Quand l'agent dit « fait », quelqu'un vérifie que c'est vrai. L'affirmation n'est pas la preuve.
Ce sont des règles ennuyeuses. C'est précisément pour cela qu'elles fonctionnent.
Cela ne concerne pas seulement le code
Tout ce qui précède s'applique tout autant, sinon plus, aux agents qui commencent à intégrer les entreprises sans écrire une seule ligne de code : celui qui répond aux clients sur WhatsApp, celui qui enregistre les dépenses, celui qui déplace un rendez-vous, celui qui envoie un e-mail au nom de quelqu'un. Ce sont des actions sur des données et des personnes réelles, et certaines sont irréversibles.
La même question s'applique à tous : que peut-il faire seul, qu'est-ce qui nécessite une approbation et qui la donne. Dans NAiOS, un agent peut proposer un encaissement, un envoi ou une modification sur une fiche, mais l'action est confirmée par une personne. C'est ce que nous appelons une entreprise HITL, avec l'humain dans la boucleHuman in the Loop (HITL)Conception dans laquelle une personne examine ou approuve les actions pertinentes d'un système d'IA avant qu'elles ne prennent effet. Non pas parce que l'agent est maladroit, mais parce que la responsabilité ne se délègue pas.
Avec plusieurs agents, c'est encore plus vrai
Lorsqu'une personne coordonne plusieurs agents à la fois, ce qui précède cesse d'être une bonne pratique pour devenir une condition sine qua non. Une erreur ne se produit plus à un seul endroit ni à un seul moment. Les autorisations et les limites de chaque agent sont ce qui sépare une équipe qui progresse en parallèle d'un problème qui se propage en parallèle.
La conclusion
Les agents ne remplacent pas le discernement ; ils le rendent plus précieux. La personne qui sait parfaitement ce qu'elle fait obtient en un jour ce qui demandait auparavant des semaines. Celle qui ne le sait pas obtient la même chose, mais avec ses erreurs en plus.
La question pour toute entreprise qui adopte des agents n'est pas de savoir à quel point elle peut aller plus vite. C'est de savoir qui va les diriger, avec quelles autorisations et quelles limites. C'est, en fait, ce que le règlement européen sur l'IAAI Act (règlement européen sur l'IA)Règlement (UE) 2024/1689 : la première législation complète sur l'intelligence artificielle, avec des obligations par niveau de risque appelle le contrôle humain, et ce qu'il demande aux entreprises que leurs équipes sachent faire dès l'article 4. Nous commençons par là.
