Les humains s’accrochent désespérément alors que l’IA accélère la livraison de logiciels

Pendant la majeure partie de l’histoire du développement logiciel, les humains ont été le contrôle. Un développeur effectue une modification, une autre personne la révise, quelqu’un l’approuve, et finalement elle est déployée.

L’IA accélère tout ce système alors que nous essayons encore de garder les humains au centre. Les développeurs peuvent désormais créer du code et des modifications en quelques secondes. Les agents peuvent travailler à travers les dépôts, les outils, l’infrastructure et d’autres systèmes avec moins d’intervention humaine.

Notre instinct est de réintégrer les humains dans le processus. Nous examinons la pull request, approuvons l’appel d’outil, vérifions la modification et confirmons le déploiement parce que nous voulons nous assurer que l’IA n’a pas fait quelque chose qu’elle n’était pas censée faire. Nous nous accrochons désespérément.\r\n\r\nCet instinct a du sens. La révision humaine nous a offert un moyen de garder le contrôle à mesure que le logiciel progresse vers la production. Mais l’IA commence à fonctionner à une vitesse et un volume où les humains ne peuvent plus rester l’unité d’échelle pour la gouvernance.

L’IA se déplace déjà plus rapidement que la révision humaine

La première vague d’IA générative dans le développement logiciel s’est principalement concentrée sur l’aide aux développeurs pour écrire du code plus rapidement. Cela change à lui seul la livraison de logiciels. Plus de code signifie davantage de changements d’applications, d’infrastructures et de bases de données qui traversent les phases de test, de sécurité, de révision, de déploiement et de production.

Le problème n’est pas forcément que l’IA crée de mauvaises modifications. Elle crée davantage de changements, plus rapidement. Si le contrôle de toute cette nouvelle production repose sur une autre personne qui examine chaque modification, le calcul finit par ne plus fonctionner.

Nous constatons déjà des signes. Anthropic a récemment indiqué que les utilisateurs de Claude Code approuvent environ 93 % des invites d’autorisation. L’entreprise a découvert que des invites répétées peuvent entraîner une fatigue d’approbation, les personnes prêtant moins d’attention à mesure que le nombre d’approbations augmente. Anthropic utilise désormais un classificateur automatisé pour évaluer les actions et stopper celles potentiellement dangereuses plutôt que de demander à une personne d’approuver tout.

Réfléchissez à ce que cela implique pour la supervision humaine. Si quelqu’un clique sur approuver 93 % du temps, ajouter une autre approbation ne vous donne pas nécessairement plus de contrôle. À un certain moment, l’humain devient simplement une autre étape du flux de travail.

Nous pouvons utiliser l’IA pour créer davantage de logiciels. Nous ne pouvons pas répondre en créant une opération de révision humaine d’une taille équivalente derrière cela.

L’IA passe de la création de code à l’action

Les assistants de codage ont donné à l’IA un rôle dans le développement. Les agents offrent à l’IA la capacité de participer à une grande partie du cycle de vie du développement logiciel (SDLC). Un agent peut recevoir un objectif, décider comment l’accomplir, utiliser des outils, observer les résultats et ajuster son action suivante.

En génie logiciel, cela peut signifier modifier des fichiers, exécuter des commandes, interagir avec des dépôts, appeler des API, tester du code ou travailler avec l’infrastructure. Les gens se sentent également plus à l’aise de laisser les agents travailler de façon autonome. Dans une étude portant sur des millions d’interactions humain‑agent, Anthropic a constaté que les utilisateurs expérimentés de Claude Code utilisaient l’auto‑approbation complète dans plus de 40 % des sessions, soit environ deux fois le taux des nouveaux utilisateurs.

Cela ne signifie pas que des agents autonomes gèrent aujourd’hui des environnements de production partout. Ce n’est pas le cas. Mais le développement logiciel nous offre un aperçu précoce de la direction que cela prend.

Aujourd’hui, l’IA crée davantage de changements, et la révision humaine commence à être sous tension. Ensuite, l’IA participera à davantage d’étapes du SDLC. Finalement, les agents créeront, valideront, déploieront, observeront et corrigeront les changements avec beaucoup moins d’intervention humaine.

À chaque étape, nous éliminons un autre point où une personne assurait le contrôle. La question passe de « l’IA peut‑elle faire le travail ? » à « ce que l’IA devrait être autorisée à faire de façon autonome ? ».

La permission n’est pas une autorité

Les agents ont besoin d’accès pour accomplir un travail utile. Un agent qui aide à déployer un logiciel peut nécessiter l’accès à un dépôt, à un système CI/CD, à un environnement cloud ou à une base de données. Retirer cet accès, c’est également enlever une grande partie de ce qui rend l’agent utile.

Mais l’accès et l’autorité ne sont pas la même chose. Accorder à un agent la permission d’atteindre un système ne signifie pas qu’il doit avoir l’autorité d’exécuter chaque action disponible dans ce système.

Le contrôle d’accès traditionnel peut nous indiquer si un agent a la permission d’atteindre quelque chose. Nous avons également besoin d’un moyen de déterminer si l’action spécifique qu’il souhaite entreprendre doit être exécutée. Cela devient plus important lorsque le système qui prend la décision peut interpréter une tâche différemment de la personne qui l’a assignée, rencontrer un obstacle et choisir une autre voie, ou utiliser un outil légitime d’une manière que personne n’avait anticipée.

OWASP décrit une version de ce problème comme Agence excessive. Elle pointe vers une fonctionnalité, des permissions et une autonomie excessives comme causes d’actions préjudiciables et recommande une approbation indépendante pour les actions à fort impact.

NVIDIA aborde le même problème au niveau de l’architecture. Son Open Agent Safety Platform place l’application des politiques en dehors de l’agent et fait un point simple : on ne peut pas s’attendre à ce qu’un agent gouverne entièrement son propre comportement.

Cela devrait façonner la façon dont nous construisons le cycle de vie du développement logiciel IA. Un agent peut avoir besoin d’une autorisation pour accéder à une base de données, à un environnement d’infrastructure ou à un système de déploiement. Cela ne signifie pas que l’agent doit décider lui‑même que chaque modification qu’il souhaite apporter est sûre.

L’IA prend des décisions basées sur des probabilités. Nous ne devrions pas laisser chacune de ces décisions devenir automatiquement une action contre un système critique.

L’Humain dans la Boucle Ne Peut Pas Être la Solution Complète

La réponse évidente consiste à garder une personne devant les actions IA conséquentes. Pour certaines décisions, c’est exactement ce que nous devrions faire. L’erreur consiste à transformer le « humain dans la boucle » en réponse à chaque décision.

Si chaque action d’un agent nécessite qu’une personne la révise et clique sur approuver, nous recréons le goulet d’étranglement que l’IA était censée éliminer. Pire encore, trop d’approbations peuvent transformer la supervision en habitude. Une personne qui clique sur approuver toute la journée n’exerce pas nécessairement son jugement.

Nous devons être plus délibérés quant à l’endroit où les décisions sont prises. L’IA peut prendre des décisions dans le cadre du travail que nous lui avons confié. La politique peut gérer les décisions où les règles sont déjà connues. Les personnes peuvent gérer les exceptions et les décisions qui nécessitent réellement un jugement.

Une modification à faible risque qui respecte la politique établie ne devrait pas nécessiter qu’une personne la surveille. Une modification qui viole la politique devrait s’arrêter automatiquement. Une exception avec des conséquences commerciales, de sécurité ou opérationnelles significatives peut nécessiter qu’une personne prenne la décision.

C’est un modèle très différent de simplement placer un humain dans chaque boucle. L’objectif n’est pas d’éliminer les humains. Il s’agit d’arrêter de faire de l’attention humaine le facteur dont dépend chaque action et de faire du chemin gouverné le chemin le plus simple.

Placez le Contrôle Là Où l’Action Se Produit

Les entreprises ne vont pas se standardiser sur un seul modèle IA ou un seul agent. Les développeurs utiliseront différents copilotes. Les équipes expérimenteront avec différents modèles. L’IA apparaîtra dans les outils de développement, les produits de sécurité, les plateformes de données et les applications internes.

Essayer de créer un processus de gouvernance différent autour de chaque outil IA ne sera pas évolutif. Le contrôle doit être placé plus près de l’action que l’IA veut entreprendre.

Si une modification générée par l’IA entre dans un pipeline de déploiement, elle doit faire face aux mêmes politiques qu’une modification générée par un humain. Si un agent veut modifier l’infrastructure, les données ou une base de données de production, les contrôles autour de ce système ne doivent pas disparaître parce que l’acteur a changé.

L’origine de la modification ne détermine pas le risque. C’est la modification elle‑même qui le fait. Un développeur, un assistant de codage, un processus automatisé ou un agent autonome peuvent emprunter un chemin différent vers la même action, mais cette action peut toujours être soumise à la même politique avant de devenir conséquente.

Cela permet également à la technologie d’évoluer sans obliger les entreprises à reconstruire la gouvernance à chaque fois. Les modèles changeront. Les agents deviendront plus capables. Les contrôles autour des systèmes critiques peuvent rester cohérents.

NIST adopte une approche similaire basée sur le risque dans son AI Risk Management Framework, qui considère la gouvernance comme quelque chose qui doit fonctionner tout au long du cycle de vie de l’IA plutôt que comme une unique approbation à la fin. Pour la livraison de logiciels, cela signifie placer les contrôles dans le chemin déjà emprunté par l’IA au lieu d’ajouter un autre processus manuel.

Lorsque l’Humain S’en Va, les Preuves Ne Peuvent Pas Partir Avec Lui

Il existe un autre problème caché dans le modèle de révision humaine. Lorsque vous retirez la personne du processus, vous ne perdez pas seulement la révision. Vous pouvez également perdre la personne qui a aidé à prouver que la révision a eu lieu.

Cela devient un problème sérieux pour les entreprises soumises à des exigences de sécurité, de conformité et d’audit. Elles doivent toujours savoir ce qui a changé, qui ou quoi l’a initié, quelle politique a été appliquée, si elle a été validée, qui a approuvé une exception, où la modification a été exécutée et ce qui s’est passé ensuite.

Vous ne pouvez pas automatiser la modification et laisser les preuves manuelles. Dans un processus piloté par l’humain, les équipes peuvent reconstruire les preuves plus tard à partir des tickets, des approbations, des journaux de pipeline, des captures d’écran et des conversations. Cette approche devient plus difficile à mesure que le volume des changements augmente et devient irréaliste lorsque les machines créent et exécutent des changements en continu.

Les preuves doivent devenir partie intégrante du processus de livraison. Les décisions de politique, les approbations, les exceptions, les déploiements et les résultats doivent créer des enregistrements au fur et à mesure que le travail se déroule. Les preuves d’audit deviennent un sous‑produit de la livraison logicielle plutôt qu’un ensemble que les équipes assemblent après coup.

Cela laisse deux missions différentes pour la gouvernance dans un cycle de vie du développement logiciel piloté par l’IA. Avant une action, déterminer si elle doit se produire. Après l’action, prouver ce qui s’est passé.

Les Humains Ne Disparaissent Pas. Notre Rôle Évolue.

Il est compréhensible de mesurer le contrôle par le nombre de fois où une personne intervient. Plus de revues semblent plus sûres. Plus d’approbations semblent plus sûres. Garder un humain dans chaque boucle paraît plus rassurant.

L’IA mettra cette hypothèse à l’épreuve. Si l’IA continue d’augmenter la quantité de logiciels que nous pouvons créer, les humains ne pourront pas réviser chaque changement, approuver chaque action, surveiller chaque déploiement et reconstruire chaque décision par la suite. Tenter de le faire ralentira soit l’IA, soit transformera la supervision humaine en simple tampon.

Le cycle de vie du développement logiciel IA nécessite une division du travail différente. L’IA peut prendre en charge davantage de tâches tandis que la politique régit les décisions répétables et les personnes interviennent lorsqu’une situation nécessite réellement un jugement. Les preuves devraient être générées automatiquement au fur et à mesure.

Nous allons donner plus d’accès à l’IA parce que c’est ainsi qu’elle devient utile. Nous allons accorder plus d’autonomie aux agents parce que c’est ainsi que nous tirons davantage parti d’eux. Le défi consiste à s’assurer que cet accès et cette autonomie accrus ne se transforment pas silencieusement en une autorité illimitée.

Les humains n’ont pas besoin de se cramponner davantage. L’objectif n’est pas moins de contrôle. C’est un modèle de contrôle qui ne dépend pas de notre maintien de chaque décision. Nous devons créer les mécanismes qui nous permettent de relâcher notre emprise sans perdre le contrôle.