Le meilleur workflow basé sur l'agentique est volontairement ennuyeux
Les workflows de développement assistés par l’IA les plus utiles ne sont pas les plus spectaculaires. Ce sont ceux qui sont monotones, reproductibles et faciles à expliquer à un autre ingénieur après une longue semaine. La démo en une seule commande reste séduisante : on demande une fonctionnalité, on obtient une réponse aboutie, et on a l’impression que tout le cycle de vie du logiciel a été condensé en un seul échange élégant. Mais un logiciel ne se livre pas sous la forme d’un simple échange. Il est livré sous la forme d’une série de décisions : quelle est la tâche à accomplir, sur quoi l’agent est-il autorisé à intervenir, quels contrôles doivent être validés, qui peut approuver la modification, et que se passe-t-il si la modification est erronée ? Le plus difficile n’est pas d’amener un modèle à produire un résultat. Le plus difficile est de construire un système qui maintienne ce résultat à l’intérieur d’une limite contrôlée par l’humain.
C’est pourquoi les recommandations les plus fortes émises récemment par les principaux éditeurs d’outils reviennent sans cesse à la même idée, formulée avec des mots différents. Le travail le plus important s’oriente désormais vers les environnements, les boucles de rétroaction et les garde-fous que les humains conçoivent pour que les agents puissent y opérer. Le rôle du développeur ne disparaît pas ; il se rapproche du plan de contrôle. Plus l’agent devient performant, plus il est important de rendre le flux de travail lisible, déterministe dans la mesure du possible, et vérifiable là où cela compte. L’intervention humaine n’est pas une solution de repli. C’est le modèle opérationnel.
L’implication pratique est dérangeante pour quiconque espère que l’autonomie fera disparaître la coordination. En général, c’est l’inverse qui se produit. Dès qu’un agent est capable d’écrire du code, d’ouvrir des pull requests, d’exécuter des tests, de modifier la configuration ou d’invoquer des outils dans d’autres systèmes, l’équipe a établi une limite de délégation. La délégation est puissante, mais elle a toujours un coût. Elle nécessite un périmètre, des autorisations, une vérification et une réponse claire à la question : « Qui est responsable si cela tourne mal ? » Si cette réponse est « le modèle », c’est que la conception du système a déjà échoué.
L’autonomie n’est utile que lorsque la limite est visible.
Construisez un plan de contrôle, pas un raccourci
Lorsque les équipes disent vouloir un « workflow agentique », elles imaginent souvent que la rapidité en est le principal avantage. La rapidité compte, mais uniquement parce qu’elle permet de gagner du temps pour un meilleur jugement. Un bon plan de contrôle n’est pas un outil unique ; c’est une chaîne de petites contraintes qui rendent le travail plus sûr et plus facile à appréhender. Le flux de travail commence avant même que l’agent n’écrive une seule ligne de code. La tâche doit être suffisamment précise pour que l’agent puisse la mener à bien sans avoir à inventer des exigences produit, et suffisamment ciblée pour qu’un humain puisse déterminer ce qui constitue une réussite. Si un brief d’un paragraphe ne parvient pas à définir l’objectif, le risque et les critères d’acceptation, alors la tâche est trop vaste pour être déléguée.
Définir le périmètre avant le code
Le périmètre est la première forme de contrôle. Définissez le changement en langage clair avant que le modèle n’atteigne le référentiel. Précisez la zone du fichier, l’objectif, les limites et la liste des « choses à ne pas faire ». En pratique, cela signifie qu’un ingénieur devrait pouvoir dire, par exemple : « Mettez à jour le parcours de validation de la facturation, ne modifiez pas la logique de tarification et ne touchez pas au contenu destiné aux clients. » Cette phrase supplémentaire empêche l’agent de résoudre avec élégance le mauvais problème. Les bons agents sont très doués pour élargir l’espace des solutions. Les humains doivent le restreindre.
Autorisations avant action
L’accès constitue la deuxième forme de contrôle. Un agent de codage disposant d’un accès en lecture seule est un système très différent de celui capable d’écrire dans le référentiel, de déclencher des déploiements ou d’accéder à des secrets. La tentation est d’accorder des autorisations étendues, car c’est plus simple. Mais la simplicité au moment de la configuration se transforme souvent en complexité en cas d’incident. Un workflow sécurisé ne confère à l’agent que les périmètres dont il a besoin pour la tâche à accomplir. Si la tâche consiste à inspecter des journaux, l’agent ne devrait pas pouvoir renouveler les identifiants. Si la tâche consiste à rédiger un correctif, l’agent ne devrait pas pouvoir contourner les protections des branches. Plus l’agent a de capacités, plus l’autorisation doit être explicite.
Vérification après le code
C’est lors de la vérification que le système gagne la confiance. Les agents sont doués pour rendre les choses plausibles ; ce sont les tests, le linting et les contrôles de sécurité qui vous indiquent si le système est réellement sûr. Le travail de mise en place de l’environnement environnant est tout aussi important que le code lui-même : l’interface utilisateur, les journaux, les métriques et la documentation font tous partie de la boucle de rétroaction. Si vos tests sont insuffisants, votre agent tirera de mauvaises conclusions. Si votre observabilité est médiocre, l’agent optimisera le mauvais signal. Les contrôles déterministes ne relèvent pas de la bureaucratie. Ils font la différence entre une supposition hasardeuse et une modification validée.
L’approbation humaine à la frontière
La limite de fusion est le point où le jugement humain doit rester explicite. Une pull request est utile précisément parce qu’elle crée un objet lisible : un diff, un résultat de test, un historique et un cadre de responsabilité. La revue ne doit pas se demander : « L’agent semble-t-il sûr de lui ? » Elle doit plutôt se demander : « Qu’est-ce qui a changé, qu’est-ce qui n’a pas changé, quelles hypothèses ont été formulées et quel est le chemin de retour en arrière ? » Le but de l’automatisation pilotée par les événements n’est pas de supprimer la révision ; il s’agit d’éliminer les tâches répétitives afin que les réviseurs puissent consacrer leur temps aux aspects significatifs. Si la modification touche à l’authentification, à la facturation, à l’accès aux données, au déploiement ou aux secrets, la réponse doit être l’approbation humaine, et non un modèle plus rapide.
Le même principe s’applique après le déploiement. Si un agent est autorisé à proposer un correctif, il faut tout de même qu’une personne puisse expliquer pourquoi ce correctif est acceptable dans le contexte de production. « Les tests ont réussi » est un bon indicateur, mais cela ne remplace pas la prise de responsabilité. Prendre la responsabilité, c’est savoir quels utilisateurs sont concernés, quelles invariantes sont importantes et ce qui se passera si la modification doit être annulée à 4 heures du matin. Un plan de contrôle sans chemin de retour n’est qu’une machine à confiance.
Les trois modes de défaillance que les humains sont là pour prévenir
Le premier mode de défaillance est une portée erronée, mais assumée avec assurance. L’agent résout un problème apparenté au lieu du problème réel, et comme le résultat est soigné, l’erreur est difficile à repérer. Cela se produit lorsque le cahier des charges est vague ou lorsque la tâche est formulée en termes de résultat plutôt que de modification délimitée. Un modèle se fait un plaisir de produire une réponse plus ambitieuse que celle demandée par l’équipe. La révision humaine a pour but d’empêcher que « mieux que ce qui a été demandé » ne devienne « différent de ce qui a été demandé ».
Le deuxième mode de défaillance concerne les effets secondaires qui semblent inoffensifs. Un correctif peut améliorer un chemin d’exécution tout en modifiant discrètement la gestion des erreurs, la journalisation, les variables d’environnement ou les paramètres par défaut ailleurs dans la pile. La différence peut être minime ; l’ampleur des répercussions, en revanche, peut ne pas l’être. Cela est particulièrement dangereux dans les systèmes où l’agent peut intervenir sur plusieurs outils ou dépôts. Moins il y a de supervision humaine, plus le risque de mauvaise interprétation des intentions et de conséquences imprévues est grand. La solution n’est pas d’interdire les agents. La solution consiste à rendre les limites et les autorisations suffisamment visibles pour que les effets secondaires ne puissent pas passer inaperçus.
Le troisième mode de défaillance est la dérive de la responsabilité. Une fois qu’une équipe s’habitue à déléguer, il est facile de commencer à déléguer la révision de la délégation, puis la révision de la révision, et enfin la responsabilité elle-même. Le workflow produit toujours du code, mais personne ne se sent pleinement responsable de la conformité de ce code avec la réalité. La surveillance des agents de codage internes rappelle utilement que, même au sein d’une entreprise, même dans le cadre de flux de travail internes, l’autonomie nécessite toujours un suivi et un jugement humain. La confiance n’est pas une impression. C’est un système qu’il faut entretenir.
À quoi ressemble un modèle opérationnel concret ?
Les meilleures équipes ne se demandent pas s’il faut ou non utiliser des agents. Elles se demandent quelles parties du cycle de vie du logiciel peuvent être déléguées en toute sécurité et lesquelles doivent rester sous la direction d’humains. Un modèle pratique se présente généralement ainsi :
- Une tâche, une branche, un responsable. Évitez les exécutions d’agents à objectifs multiples qui mélangent refactorisation, développement de fonctionnalités et nettoyage.
- Uniquement des PR. Pas d’écriture directe dans les systèmes de production, pas de modifications silencieuses à l’insu du réviseur.
- Priorité aux vérifications déterministes. Les tests, le linting, la vérification de la compilation et les analyses de sécurité doivent être effectués avant la révision humaine.
- Examinez le diff, pas le résumé. Les résumés sont utiles, mais c’est dans le diff que réside la vérité.
- Signalez les zones à risque. L’authentification, la facturation, la suppression de données, les secrets et les modifications d’infrastructure méritent un validateur humain final.
- Prévoyez une procédure de retour en arrière. Si la modification ne peut pas être annulée rapidement, il est trop risqué de la traiter comme une opération de routine.
Ce modèle n’est pas anti-agent. Il est en faveur de la responsabilisation. En réalité, les équipes « agentiques » les plus performantes ont tendance à devenir plus disciplinées, et non l’inverse. Elles consacrent moins de temps à la saisie et davantage à la conception de l’échafaudage qui garantit la fiabilité du résultat. Cela peut sembler être une charge supplémentaire jusqu’à ce que l’on compare ce temps au coût du débogage d’un système qui a trop changé, trop rapidement, et sans responsable clairement identifié.
Le mot clé ici est « orchestration ». L’orchestration ne consiste pas à « laisser l’agent faire tout ». L’orchestration consiste à décider quels déclencheurs sont sûrs, quel contexte l’agent reçoit, quelles vérifications sont obligatoires et à quels moments le jugement humain doit rester dans la boucle. Plus le flux de travail est mature, plus les points de transfert deviennent visibles. L’agent ne remplace pas le développeur. Il oblige ce dernier à être plus explicite quant au système au sein duquel l’agent opère.
Le véritable test consiste à savoir si vous pouvez expliquer le changement
Une équipe dispose d’un bon plan de contrôle lorsqu’un ingénieur senior est capable d’expliquer la modification apportée par l’agent en une minute, sans gesticuler. Il doit pouvoir préciser quelle était la tâche, pourquoi l’agent était approprié, quels étaient les contrôles critiques et à quel moment la décision humaine a été prise. S’il n’en est pas capable, le workflow est trop « magique ». Et la magie est précisément ce dont un logiciel de production n’a pas besoin.
C’est pourquoi « l’intervention humaine » n’est pas un slogan d’avertissement ; c’est un principe de conception axé sur la responsabilité. Les humains ne restent pas dans la boucle parce que les agents sont faibles. L’humain reste dans la boucle parce que les systèmes logiciels ont des effets secondaires, que les incitations dérivent, que des bogues se cachent dans les points d’intégration, et que les décisions relatives au produit ne se résument pas à la rédaction de code. Le modèle peut évoluer rapidement à travers les parties mécaniques. L’humain doit toutefois décider de ce qui constitue un succès, quel risque est acceptable, et quel changement mérite d’être mis à la disposition des utilisateurs.
C’est là le véritable sens du plan de contrôle. Ce n’est pas un rempart contre l’automatisation. C’est l’ensemble des limites définies par l’humain qui permet à l’automatisation de se développer sans perdre de vue ses objectifs. Les meilleurs flux de travail « agentiques » sont ceux où la machine se charge davantage de l’exécution et où l’humain se charge davantage du jugement. Cette répartition n’est pas un compromis. C’est la raison pour laquelle le système fonctionne.
Sources
- OpenAI — L’ingénierie de l’exploitation : tirer parti de Codex dans un monde où les agents priment
- GitHub — Du codeur à l’orchestrateur : comment les agents transforment le rôle du développeur
- Anthropic — Des agents dignes de confiance dans la pratique
- OpenAI — Comment nous surveillons les agents de codage internes pour détecter tout désalignement
