Le risque lié aux agents ne réside plus seulement dans ce qu’ils écrivent, mais aussi dans ce qu’ils sont capables de faire
Les agents de développement franchissent un cap important : ils ne se contentent plus de suggérer du code, ils exécutent des tâches. Ils inspectent les dépôts, modifient plusieurs fichiers, exécutent des tests, consomment des crédits de calcul, ouvrent des pull requests et peuvent enchaîner ces actions au cours de longues sessions. Pour une équipe de développement logiciel, cela représente un réel gain de rapidité. Il s’agit également d’un changement de nature : l’enjeu ne réside plus uniquement dans la qualité d’un extrait de code généré, mais dans le contrôle d’un système capable d’agir.
Deux publications récentes vont dans le même sens. Gartner affirme que la gouvernance de l’IA agentique ne peut se limiter à un ensemble de politiques écrites : elle doit devenir un ensemble de contrôles d’exécution capables d’arrêter une action risquée avant qu’elle n’affecte la production, les identifiants, les budgets ou les données. Un article de synthèse publié sur arXiv décrit le passage d’une simple génération de code à un cycle de vie de développement logiciel « agentique », où la valeur se mesure aux modifications réellement qualifiées pour la production, et non au volume de lignes produites.
La conclusion pratique est simple : les humains doivent rester aux commandes, mais pas en tant que validateurs héroïques placés uniquement en fin de processus. Ils doivent définir des limites, choisir des niveaux d’autonomie, exiger des traces, organiser les revues, fixer les budgets et décider quelles actions nécessitent une approbation explicite. En d’autres termes, le rôle de l’humain évolue : moins de micro-contrôle de chaque suggestion, plus de contrôle sur un système de livraison.
Pourquoi les politiques sur papier ne suffisent plus
Dans un processus traditionnel, une règle de sécurité ou de conformité s’applique souvent par étapes : convention d’équipe, liste de contrôle des pull requests, révision humaine, pipeline d’intégration continue (CI), validation avant déploiement. Ce modèle fonctionne parce que les actions se déroulent à un rythme humain et que les points de contrôle sont relativement stables. Un agent autonome remet cette hypothèse en cause. Il peut effectuer des dizaines d’opérations en quelques minutes, combiner des outils, réessayer des commandes après un échec et réviser son plan en fonction des résultats observés.
Si la seule protection est une politique consignée dans un document interne, elle arrive trop tard. Elle décrit ce qui aurait dû se passer, mais n’empêche pas une commande destructrice, une fuite d’informations dans une invite de commande, une consommation excessive de jetons ou une pull request mêlant un correctif utile à une dette cachée. La gouvernance doit donc passer du commentaire à l’exécution.
Pour une équipe de développement, cela signifie traiter chaque agent comme une identité soumise à gouvernance. Qui l’a lancé ? Sur quel dépôt ? Avec quels droits ? Pour quelle tâche ? Pendant combien de temps ? A-t-il accès au réseau, aux secrets, aux bases de données locales, aux tickets clients ou aux environnements de préproduction ? Ces questions relèvent de l’IAM, du DevOps et de la sécurité des applications, mais elles deviennent également des questions d’ingénierie produit. Un agent capable de modifier du code est un acteur au sein du système logiciel.
Le plan de contrôle pour une équipe logicielle
Un plan de contrôle « agentique » ne doit pas nécessairement être dès le départ un produit complexe. Il s’agit avant tout d’une architecture de décisions. Les équipes peuvent commencer par classer les actions en fonction du risque. La lecture de code public, la génération d’un test unitaire ou la proposition de documentation peuvent être autorisées de manière générale. Modifier une migration de base de données, changer une politique d’authentification, intervenir sur la configuration du cloud ou exécuter un script destructeur devrait nécessiter une autorisation humaine explicite.
Le deuxième élément constitutif est l’environnement d’exécution. Les agents doivent travailler dans des branches isolées, des sandbox locales ou distantes, et avec un accès temporaire minimal. Les secrets ne doivent pas être accessibles par défaut. L’accès au réseau doit être limité lorsque la tâche ne l’exige pas. Les commandes sensibles doivent être bloquées ou transformées en demandes d’autorisation. Il ne s’agit pas d’une méfiance envers l’outil ; c’est la même logique qui a conduit les équipes à séparer le développement, les tests et la production.
Le troisième pilier est la traçabilité. Une pull request générée avec l’aide d’un agent doit retracer le déroulement des opérations : intention initiale, fichiers modifiés, tests exécutés, échecs rencontrés, hypothèses formulées et éléments non vérifiés. Sans ce journal, le réviseur humain se retrouve face à un résultat final opaque. Grâce à lui, le réviseur peut se concentrer sur les décisions importantes plutôt que de devoir reconstituer le cheminement.
- Identité : chaque agent a un responsable humain, un périmètre d’action et des droits limités.
- Autonomie à plusieurs niveaux : les actions réversibles peuvent être automatisées, tandis que les actions irréversibles restent soumises à validation.
- Bac à sable : l’agent fonctionne dans un espace contrôlé, et non sur l’ensemble de la machine ou du cloud.
- Budgets : les jetons, le temps CPU, les appels d’outils et les exécutions CI sont plafonnés.
- Observabilité : les invites, les décisions, les commandes et les résultats critiques sont enregistrés.
Le véritable indicateur : une modification qualifiée pour la production
Le piège avec les agents de codage est de mesurer ce qu’ils produisent facilement : nombre de fichiers modifiés, vitesse de génération, nombre de tests ajoutés, volume de pull requests ouvertes. Ces indicateurs peuvent donner l’impression d’un progrès tout en transférant les coûts vers la révision, l’intégration, la sécurité ou les opérations. L’article publié sur arXiv décrit précisément ce paradoxe du débit : l’agent peut accélérer la production de code plus rapidement que l’organisation ne parvient à renforcer sa capacité à valider ce code.
Un meilleur indicateur est la modification qualifiée pour la production. Une modification qualifiée n’est pas simplement du code qui se compile. Elle répond à l’intention métier, respecte l’architecture, passe les tests pertinents, ne rompt pas les contrats existants, n’expose pas de données sensibles, reste observable en production et peut être expliquée par un responsable humain. Cette définition place l’humain à la bonne place : non pas comme un obstacle à la rapidité, mais comme le garant de la valeur fournie.
Dans ce modèle, l’IA est extrêmement utile. Elle peut préparer des alternatives, rédiger des tests, résumer l’impact, rechercher d’éventuelles régressions, générer de la documentation de migration et proposer une stratégie de retour en arrière. Mais le passage de « plausible » à « acceptable » reste une décision d’ingénierie. Un modèle peut aider à formuler l’argumentation ; il n’assume pas la responsabilité du service en production.
Ce que les équipes peuvent faire dès maintenant
La première mesure consiste à rendre explicites les zones rouges. De nombreuses équipes autorisent implicitement les agents à accéder aux dépôts réels sans définir ce qu’ils ne doivent en aucun cas faire. Les équipes doivent dresser la liste des commandes dangereuses, des fichiers sensibles, des services qui ne doivent pas être appelés, des données qui ne doivent jamais figurer dans une invite de commande, ainsi que des types de modifications nécessitant une validation par un responsable. Cette liste doit être associée au dépôt, à l’instar des règles d’intégration continue (CI) ou des conventions de sécurité.
La deuxième mesure consiste à modifier les pull requests générées par l’IA. Une pull request doit indiquer si un agent a contribué, quelles instructions il a reçues, quels tests il a exécutés et quelles parties restent à vérifier. Il ne s’agit pas de stigmatiser l’outil. Cela aide le réviseur à adapter son niveau d’attention. Une pull request générée rapidement peut être excellente ; elle a simplement besoin d’un contexte de révision qui corresponde à la manière dont elle a été produite.
La troisième mesure consiste à définir des budgets. Les agents ont des coûts variables : utilisation des modèles, environnement de test, outils, intégration continue, stockage des traces, temps de révision et retouches. Sans budgets, l’équipe découvre la facture après coup. Avec des budgets, elle peut décider quelles tâches méritent une plus grande autonomie, lesquelles doivent rester manuelles, et dans quels cas l’assistance apporte un réel gain net.
La quatrième mesure consiste à former les développeurs pour qu’ils deviennent de meilleurs opérateurs d’agents. Cela implique de formuler des intentions précises, de décomposer les tâches, de vérifier les résultats, d’analyser les différences de manière critique, de concevoir des tests comme des oracles et de reprendre le contrôle lorsque l’agent s’écarte dans la mauvaise direction. Le métier ne disparaît pas ; il évolue vers une orchestration responsable.
Conserver le contrôle humain sans tout ralentir
Maintenir le contrôle humain ne signifie pas demander une validation manuelle pour chaque ligne de code. Ce serait inefficace et, paradoxalement, dangereux : les relecteurs finiraient par cliquer mécaniquement. Le meilleur modèle est celui d’une autonomie proportionnelle au risque. Plus une action est réversible, isolée et observable, plus elle peut être automatisée. Plus elle touche à la sécurité, aux données, aux coûts ou à la production, plus elle doit passer par un contrôle humain explicite.
Cette approche est compatible avec la rapidité. Un agent peut agir rapidement dans un périmètre restreint. Il peut préparer une modification, effectuer des tests, documenter ses choix et proposer des actions de suivi. L’humain responsable intervient là où le jugement est essentiel : intention, compromis, architecture, risque et acceptation finale. Il s’agit là d’une meilleure répartition des tâches que le fantasme d’un agent entièrement autonome ou la méfiance qui bloque toute expérimentation.
La maturité d’une équipe ne se mesurera donc pas au nombre d’agents déployés, mais à la qualité des garde-fous qui les entourent. Les organisations qui réussiront ne seront pas celles qui excluront les humains du processus. Ce seront celles qui concevront un processus dans lequel l’agent accélère l’exécution et où l’humain conserve le pouvoir de dire non, d’exiger des preuves et de prendre la décision finale.
