Déléguer du code à un agent IA demande de décider ce qu’il peut exécuter seul, comment vérifier son travail et quelles décisions restent à notre charge. Ce cadre commence bien avant la relecture du code.
Imaginons une demande ordinaire dans un SaaS : « Ajoute un bouton pour exporter les données clients. »
L’agent crée le bouton, écrit la fonction d’export et ajoute des tests. Tout passe. Le fichier se télécharge.
Mais quelles données contient-il ? Celles de l’entreprise connectée ? Seulement les clients sélectionnés ? Les contacts archivés aussi ? Et qui a le droit de lancer cet export ?
Ce scénario est fictif. Il illustre pourtant une difficulté concrète : une demande peut sembler terminée alors que plusieurs décisions n’ont jamais été prises explicitement.
En écoutant The Friction Is Your Judgment, d’Armin Ronacher et Cristina Poncela, j’ai retenu leur distinction entre deux problèmes. L’un concerne notre comportement face à la vitesse de production des agents. L’autre concerne la manière de structurer le logiciel pour qu’ils puissent y travailler correctement. Les intervenants défendent notamment le maintien de points de réflexion et de revue humaine là où les changements engagent des conséquences importantes. Voir le support de la conférence.
Je propose de prolonger cette réflexion avec sept questions. Elles concernent ici les agents qui développent votre logiciel : ceux qui lisent le dépôt, modifient des fichiers et exécutent des commandes.
Définir le besoin et les limites
Arbitrer les ambiguïtés métier
Accepter à partir de preuves
Donner à l’agent de quoi travailler correctement
Avant de parler d’autonomie, il faut regarder l’environnement dans lequel on demande à l’agent d’intervenir.
Context engineering : que doit connaître l’agent ?
Le context engineering consiste à organiser les informations utiles à la tâche. Architecture, conventions, vocabulaire métier, documentation, décisions passées : tout ne figure pas dans la demande initiale.
Pour notre export, l’agent doit savoir que les données appartiennent à des entreprises distinctes, comment les droits sont définis et ce que signifie « client actif ». Il doit aussi pouvoir retrouver l’endroit où ces règles sont déjà appliquées.
Dans les outils de développement qui le prennent en charge, le fichier AGENTS.md rassemble les instructions destinées à l’agent. C’est un moyen de lui fournir du contexte ; d’autres agents peuvent recevoir leurs consignes par des mécanismes différents.
Ce fichier peut indiquer les commandes de validation, les conventions et les documents à consulter. Il ne remplace pas une règle métier absente ou une décision produit que personne n’a prise.
Je commencerais donc par un contexte court qui oriente vers des sources précises. Une documentation volumineuse mais contradictoire laisse encore à l’agent le soin de choisir quelle version croire.
Pour un fondateur, la question utile est simple : les informations nécessaires pour réaliser cette tâche existent-elles ailleurs que dans la tête d’une personne ?
Boundaries : quelles frontières architecturales ?
Les frontières architecturales définissent les responsabilités des différentes parties du logiciel.
Dans notre exemple, le bouton déclenche une action. Un service vérifie les droits. Une couche d’accès aux données récupère les clients autorisés. Le code d’export transforme ces données en fichier.
Si chaque nouvelle fonctionnalité réinvente ce parcours, il devient difficile de vérifier que les mêmes règles s’appliquent partout. Une correction apportée à un endroit peut laisser les autres chemins inchangés.
Une frontière claire indique à l’agent par où passer. Elle aide aussi la personne qui relit à repérer une modification inhabituelle : pourquoi ce bouton contient-il sa propre logique d’autorisation ?
C’est une question de maintenance autant que de travail avec l’IA. Les agents rendent simplement plus pressant le besoin de chemins compréhensibles et cohérents.
Primitives : quelles briques réutiliser ?
Les primitives sont les éléments réutilisables déjà prévus dans le projet : composants d’interface, fonctions métier, services, clients API.
Pour l’export, cela peut être un bouton qui gère déjà le chargement, un service qui sélectionne les clients accessibles et une fonction commune qui génère les fichiers.
Ces briques portent des décisions que l’équipe a déjà prises. Les réutiliser évite de rouvrir ces décisions à chaque tâche.
Encore faut-il qu’elles soient faciles à trouver et adaptées au besoin. Une fonction commune dont le nom ne décrit pas le rôle, ou qui mélange plusieurs responsabilités, sera difficile à employer correctement.
Le travail humain consiste donc aussi à entretenir ces briques. Une instruction demandant de « réutiliser l’existant » aide peu si l’existant est introuvable ou incohérent.
Définir ce qu’il peut réellement faire
Connaître les règles et disposer des bonnes briques ne suffit pas. Il faut distinguer les actions accessibles à l’agent des contraintes imposées à son travail.
Permissions : quelles actions sont autorisées ?
Lire un fichier, modifier une branche, accéder à des données réelles et déployer sont des capacités différentes.
Pour développer notre export, l’agent peut travailler avec des données fictives dans un environnement isolé. La tâche ne lui donne pas automatiquement une raison de consulter les fichiers clients en production.
Écrire « ne touche pas à la production » dans ses instructions exprime une règle. Ne pas lui fournir d’accès à la production établit une limite technique.
Cette distinction devient essentielle lorsqu’on augmente son autonomie. Les permissions doivent correspondre à la tâche et aux conséquences possibles d’une erreur.
L’objectif est de lui permettre d’avancer seul dans un périmètre défini. Si chaque lecture de fichier nécessite une approbation, les validations importantes risquent de se perdre dans les demandes ordinaires.
Guardrails : quels garde-fous imposer ?
Les garde-fous rendent certaines règles contrôlables : vérification des types, lint, tests, contrôles de sécurité et validations automatiques avant intégration.
Pour notre export, un contrôle peut vérifier qu’une entreprise n’accède jamais aux clients d’une autre. Une règle d’architecture peut interdire les accès directs à la base depuis les composants d’interface.
Chaque contrôle couvre toutefois une propriété précise. TypeScript ne peut pas deviner que les contacts archivés doivent être exclus si cette exigence n’existe nulle part.
Il faut également regarder qui peut modifier ces protections. Une validation perd sa portée si l’agent peut supprimer le test gênant et intégrer lui-même le changement sans contrôle extérieur.
Le cadre doit préciser ce qui est obligatoire et qui peut autoriser une exception. Cela permet de traiter les exceptions comme des décisions visibles.
Vérifier le résultat et comprendre le travail
Une fois les limites posées, deux questions restent ouvertes : la tâche a-t-elle été correctement accomplie, et dispose-t-on des éléments pour le vérifier ?
Evals : comment évaluer le travail ?
« Les tests passent » est une information utile. Sa portée dépend de ce que les tests vérifient.
Dans notre scénario, un test peut confirmer qu’un fichier CSV est généré sans vérifier que son contenu correspond aux filtres sélectionnés. Le code fonctionne selon le test, mais la fonctionnalité reste incomplète.
Les evals, ou évaluations, consistent à donner une tâche à l’agent puis à mesurer sa réussite selon des critères définis. Pour un agent de développement, les tests du logiciel peuvent en faire partie. On peut aussi examiner le résultat final et les actions effectuées. Anthropic décrit cette combinaison dans son guide consacré aux évaluations d’agents. Lire le guide.
Pour notre export, les critères pourraient être :
- Le fichier contient uniquement les clients correspondant aux filtres demandés.
- Un utilisateur sans autorisation ne peut pas déclencher l’export.
- Aucune donnée d’une autre entreprise n’apparaît dans le fichier.
- L’interface explique un échec et permet de réessayer.
- L’implémentation respecte les services existants sans affaiblir leurs contrôles.
Ces critères doivent être établis avant de juger la solution. Sinon, on risque d’accepter la définition de la réussite proposée après coup par l’agent.
Pas besoin de commencer par une plateforme d’évaluation complexe. Sur une première tâche, des critères d’acceptation explicites et une vérification du parcours constituent déjà une base. Lorsque l’usage devient régulier, conserver des tâches représentatives et comparer plusieurs exécutions permet d’évaluer la méthode de travail elle-même.
Observability : comment comprendre ce qu’il a fait ?
L’évaluation porte sur la réussite. L’observabilité fournit les traces nécessaires pour comprendre l’exécution.
Quels fichiers ont changé ? Quelles commandes ont été lancées ? Quels contrôles ont échoué ? Combien de tentatives ont été nécessaires ? Quel temps et quel coût ont été engagés ?
Pour l’export, je voudrais pouvoir retrouver les modifications, les résultats des vérifications et les limites encore signalées. Le résumé final de l’agent doit renvoyer à des éléments vérifiables.
Ses explications sur ses choix peuvent aider à la revue. Elles ne constituent pas, à elles seules, une preuve que le comportement annoncé est bien celui du logiciel.
Il faut aussi choisir les traces avec soin. Pour comprendre une génération de fichier, enregistrer les paramètres techniques et le résultat de l’opération peut suffire ; recopier les données clients dans les journaux créerait une exposition supplémentaire.
La mesure intéressante devient alors le temps nécessaire pour obtenir un changement accepté, en incluant la revue et les reprises. Le temps de génération n’en représente qu’une partie.
Placer le jugement humain avant, pendant et après
Avec ce cadre, la place de l’humain apparaît à plusieurs moments.
Avant l’exécution, quelqu’un définit le besoin, les limites et les critères de réussite. Pendant le travail, certaines découvertes peuvent exiger un arbitrage. À la fin, une personne ou un contrôle autorisé décide si les preuves sont suffisantes pour accepter le changement.
Reprenons notre export. L’agent découvre qu’il existe plusieurs interprétations de « client actif ». Choisir l’une d’elles modifierait les données transmises aux utilisateurs. Cette ambiguïté doit remonter à quelqu’un qui peut trancher la définition métier.
À l’inverse, corriger une erreur de formatage détectée par le lint ne demande généralement pas une nouvelle décision produit.
C’est là que la friction mérite d’être choisie. Une interruption doit correspondre à une décision identifiable, avec les options et leurs conséquences. Une succession de boutons « approuver » sans explication produit peu de jugement.
Il reste une condition : la personne qui approuve doit pouvoir comprendre ce qu’elle accepte. Un fondateur non technique peut arbitrer le périmètre d’un export. Une modification de l’isolation des données exige une compétence technique adaptée.
La présence d’un humain dans le processus ne garantit donc rien à elle seule. Il lui faut du contexte, des preuves, du temps et l’autorité nécessaire pour décider.
Ce qu’il faut retenir
Le contexte, les frontières et les briques donnent à l’agent les moyens de travailler. Les permissions et les garde-fous limitent ses actions et imposent des contrôles. Les évaluations et l’observabilité permettent de juger le résultat et d’en comprendre la production.
Construire ce cadre demande déjà du jugement humain. L’autonomie peut ensuite progresser là où les tâches sont suffisamment définies, les erreurs détectables et leurs conséquences maîtrisées.
Conclusion
Je retiens de cette réflexion une exigence pour les équipes qui développent avec des agents : être capables d’expliquer ce qu’elles délèguent et ce qu’elles continuent d’assumer.
Pour votre prochaine tâche, écrivez ce qui permettra de l’accepter et ce qui devra provoquer une interruption. Vous découvrirez peut-être qu’une partie du travail consiste encore à décider ce que vous voulez construire.
Si votre équipe utilise déjà des agents sans avoir clarifié ces responsabilités, nous pouvons examiner une tâche concrète et les contrôles qui l’entourent lors d’un échange de 30 minutes.