Quand l'IA prend le pouvoir
Ces dernières années, les entreprises se sont concentrées sur ce que l'IA générative peut nous apporter. Les agents d'IA introduisent une question bien plus lourde de conséquences : que se passe-t-il lorsque le logiciel peut décider de la prochaine action à mener, puis l'exécuter lui-même ?
En juillet 2026, un agent d'IA utilisé dans le cadre d'une évaluation de la cybersécurité d'OpenAI a compromis une partie de l'infrastructure de production de Hugging Face. Il convient de replacer les choses dans leur contexte avant de s'emballer. Il ne s'agissait pas d'une application d'entreprise classique décidant soudainement d'attaquer une autre société. OpenAI testait délibérément des modèles hautement performants sur des tâches de cybersécurité complexes, et les classificateurs de production normalement utilisés pour empêcher les modèles de poursuivre des activités informatiques à haut risque avaient été intentionnellement désactivés pour cette évaluation.
Malgré cela, ce qui s'est passé mérite qu'on s'y attarde. Selon les enquêtes qui ont suivi, l'agent semble avoir conclu que les informations détenues par Hugging Face pouvaient l'aider à atteindre l'objectif d'évaluation qui lui avait été fixé. Il a trouvé une faille grâce à une vulnérabilité de type zero-day dans l'infrastructure utilisée par l'environnement d'évaluation, a obtenu un accès plus large à Internet, a enchaîné d'autres vecteurs d'attaque, a récupéré des identifiants et a finalement atteint les systèmes de Hugging Face. L'analyse médico-légale de Hugging Face a recensé environ 17 600 actions individuelles, regroupées en quelque 6 280 clusters.
La tentation, naturellement, est de titrer sur « l'évasion de l'IA » ou « l'IA devenue incontrôlable ». Je ne pense pas que l'une ou l'autre de ces formulations soit particulièrement pertinente. Autant que les enquêtes ont pu l'établir, le logiciel tentait d'atteindre l'objectif qui lui avait été assigné et a trouvé un chemin que personne n'avait anticipé. Hugging Face estime que l'agent essayait en réalité de tricher lors de l'évaluation en accédant aux systèmes de production, où il pensait pouvoir trouver des informations sur le benchmark ou les solutions.
C'est tout de suite beaucoup moins théâtral, mais du point de vue de la transformation numérique, c'est probablement bien plus important.
Ces dernières années, la plupart des organisations ont appréhendé l'IA générative comme un outil auquel on pose des questions. On lui fournit des informations, on lui pose une question et on obtient un résultat. Elle peut résumer un contrat, analyser des données, écrire du code ou rédiger un e-mail, mais il y a généralement toujours un être humain de l'autre côté qui décide de la suite des événements.
Les agents commencent à brouiller cette frontière. Donnez à cette même intelligence un accès à des outils et elle pourra récupérer des informations, appeler une API, mettre à jour un enregistrement, exécuter du code, envoyer l'e-mail ou effectuer la modification elle-même. OpenAI décrit les agents de manière très similaire : des systèmes capables de gérer de façon indépendante l'exécution de flux de travail, de prendre des décisions, de sélectionner les outils appropriés et d'interagir avec des systèmes externes au nom d'un utilisateur.
Le chatbot vient d'obtenir un accès en écriture.
C'est ce virage qui fait de la gouvernance des agents d'IA une préoccupation concrète pour l'entreprise, plutôt qu'un simple débat de principe de plus. Dès lors que le logiciel peut agir au lieu de se contenter de faire des recommandations, les questions d'identité, de droits d'accès, de contrôles, d'auditabilité et de responsabilité s'invitent au cœur même de l'architecture.
L'automatisation change lorsque l'on donne au logiciel une intention, et non des instructions
Les logiciels transforment notre quotidien depuis des décennies, il ne faudrait donc pas surestimer la nouveauté de la situation. Nous n'avons pas besoin de l'IA pour mettre à jour une base de données, déclencher une API ou exécuter un flux de travail. Les scripts, les moteurs de règles, les plateformes d'orchestration et les processus automatisés s'en chargent parfaitement depuis des années.
La différence réside dans la manière de passer de l'objectif à l'action. L'automatisation traditionnelle est normalement conçue autour d'un parcours défini à l'avance. Quand X se produit, récupérer Y. Si la réponse est Z, effectuer telle action. Même si cela implique des centaines de règles, d'embranchements et d'exceptions, le processus a toujours été modélisé au préalable par un humain.
Les agents nous permettent potentiellement d'aller plus loin en fixant un résultat au logiciel plutôt qu'en lui fournissant chaque instruction nécessaire pour y parvenir. Le problème est posé de la sorte : déterminez de quelles informations vous avez besoin. Décidez des outils appropriés. Gérez les retours d'information et menez à bien la tâche.
Cette distinction est cruciale car le chemin d'exécution peut devenir dynamique. Un agent peut commencer par interroger un système, découvrir qu'il a besoin d'un contexte supplémentaire, appeler un autre service, se heurter à un résultat inattendu, revoir son approche et poursuivre sa tâche. Les architectures d'agents actuelles sont explicitement conçues autour de cette capacité à gérer un flux de travail, à choisir des outils et à prendre des mesures en fonction de l'avancement de la tâche.
Il s'agit d'une proposition fondamentalement différente de l'automatisation classique. Le logiciel ne se contente plus d'exécuter un flux prédéterminé. Dans les limites que nous lui fixons, nous lui laissons une certaine marge d'appréciation sur la manière dont ce flux se déroule.
Et c'est là que le sujet devient bien plus intéressant qu'une simple discussion sur la capacité de l'IA à rédiger un meilleur e-mail.
L'opportunité réside dans la suppression de la coordination, pas des personnes
Au sein d'une organisation, une quantité surprenante de travail n'est pas difficile parce qu'une tâche individuelle est particulièrement complexe, mais en raison de la coordination requise entre ces tâches.
Ouvrir le CRM. Trouver le client. Copier un identifiant dans la plateforme de facturation. Lire les notes. Consulter un autre système. Comprendre leur signification. Demander à une autre équipe si une situation est normale. Attendre la réponse. Mettre à jour la première plateforme et envoyer un e-mail au client.
Cela vous rappelle quelque chose ?
Nous avons passé des années à essayer d'automatiser ces processus, et les technologies de gestion des flux de travail classiques sont extrêmement efficaces lorsque les étapes peuvent être décrites de manière prévisible. Les difficultés résident généralement dans les exceptions : un document mal structuré, un compte qui ne correspond pas tout à fait, trois systèmes en contradiction, ou le moment du processus où un collaborateur doit lire et comprendre une information avant de savoir ce qu'il doit faire ensuite.
C'est précisément dans ce genre de flux de travail que les agents s'avèrent potentiellement utiles. Les recommandations actuelles d'OpenAI identifient spécifiquement la prise de décision complexe, les règles difficiles à maintenir et la forte dépendance à l'égard d'informations non structurées comme des domaines où une approche par agents peut apporter une valeur ajoutée que l'automatisation déterministe classique n'offre pas. Elles soulignent également, à juste titre, qu'en l'absence de ces caractéristiques, une solution déterministe reste souvent la meilleure option.
Si un logiciel peut prendre en charge une partie de la coordination entre les systèmes, les informations et les décisions, le gain d'efficacité potentiel est significatif. Non pas parce que tous les acteurs du processus disparaissent soudainement, mais parce que nous pouvons cesser d'utiliser des humains comme de coûteux intermédiaires entre des plateformes qui n'ont jamais été très douées pour communiquer entre elles.
La nuance est de taille. L'objectif ne doit pas nécessairement être de supprimer les collaborateurs de l'organisation. Il doit être de supprimer les tâches que nous leur imposons aujourd'hui simplement parce que la technologie sous-jacente ne gère pas bien le contexte, l'ambiguïté ou les exceptions.
C'est pourquoi je pense que l'opportunité offerte par les agents dépasse de loin un simple gain de productivité marginal. Rédiger la réponse à un client dix secondes plus vite est certes utile. Permettre à un logiciel d'analyser le problème, de rapprocher les informations pertinentes et de faire progresser le processus est d'un tout autre ordre.
Bien sûr, plus le logiciel fait progresser le processus, plus il se rapproche d'une action lourde de conséquences.
Et c'est là que les choses se compliquent nettement.
La capacité n'est pas l'autorité
Quelques mois avant l'incident de Hugging Face, PocketOS a publié un compte rendu sans fard d'un agent d'IA ayant supprimé la base de données de production de l'entreprise. La suppression a pris neuf secondes. La restauration a nécessité soixante heures. Les sauvegardes existaient, mais dataient de trois mois car le processus de sauvegarde s'était arrêté en silence.
PocketOS précise également de manière très claire qu'il ne s'agissait pas d'un simple « problème d'IA ». L'entreprise indique que l'agent a agi avec assurance en utilisant des droits d'accès qu'il n'aurait jamais dû posséder, sur un environnement qui ne présentait pas de barrières suffisantes contre une action destructrice.
C'est là une leçon précieuse.
Les humains suppriment des bases de données de production depuis des années, et les bugs logiciels y ont également largement contribué. L'élément notable ici est que l'acteur disposait d'une autorité suffisante pour que son erreur ait un impact réel.
Nous comprenons déjà ce principe lorsqu'il s'agit d'un humain. Un conseiller du service client peut être autorisé à accorder un remboursement de 20 € sans que personne ne s'en soucie. Un montant de 200 € peut encore sembler tout à fait raisonnable. Un remboursement de 20 000 € ouvre probablement un tout autre débat.
Le même principe s'applique ailleurs. Un agent qui identifie une faute d'orthographe dans les métadonnées d'un contenu et la corrige est une action plutôt inoffensive. En revanche, si le champ qu'il souhaite modifier détermine si ce contenu peut être diffusé sur un territoire donné, la conséquence est tout autre. De même, un agent peut identifier correctement un problème de configuration de production, mais cela ne signifie pas qu'il doive hériter de droits illimités pour reconfigurer l'ensemble de l'environnement.
Rien de tout cela n'est particulièrement nouveau. Il s'agit de gestion des identités et des accès appliquée à un nouveau type d'acteur, et je soupçonne que cela deviendra l'un des piliers d'une gouvernance efficace de l'IA par agents.
Microsoft traite déjà les agents dans ces termes. Ses recommandations actuelles préconisent une identité d'agent d'IA unique et dédiée, un propriétaire ou un garant désigné, un objectif et des accès aux données clairement documentés, un accès basé sur le principe du moindre privilège, des autorisations d'outils contrôlées, une journalisation des activités et des procédures de révocation testées. Les travaux du NIST dans ce même domaine examinent explicitement l'identification, l'autorisation, l'audit et la non-répudiation pour les agents d'IA.
En pratique, cela signifie que les autorisations des agents d'IA doivent être traitées avec le même sérieux que les comptes d'administration humains ou de services privilégiés. Un agent peut être parfaitement capable de déterminer ce qui doit se passer sans pour autant être autorisé à le mettre en œuvre.
Cette distinction est essentielle. Les contrôles des agents d'IA ne peuvent pas simplement se limiter à vérifier si un modèle est techniquement capable d'effectuer une action. Ils doivent déterminer si cet agent précis, agissant dans ce contexte précis, est autorisé à l'exécuter.
Par ailleurs, je crains que la prolifération des agents d'IA ne devienne l'un de ces problèmes dont les entreprises n'ont pas conscience jusqu'à ce que quelqu'un demande enfin : « Combien d'agents avons-nous réellement ? » Nous avons déjà connu des situations similaires avec les applications SaaS, les ressources cloud, les comptes de service et les clés d'API. Il n'y a aucune raison évidente pour que le parc d'agents s'organise mieux de lui-même, en particulier dans les entreprises où l'expérimentation est délibérément décentralisée au sein des équipes.
Cela ne signifie pas pour autant qu'il faille centraliser toutes les initiatives d'IA. Une équipe centrale a peu de chances de comprendre suffisamment bien chaque processus pour identifier elle-même toutes les applications utiles. Une innovation décentralisée peut être tout à fait judicieuse.
Une autorité déléguée par accident est en revanche une tout autre histoire.
L'IA par agents hérite de chaque faille de votre parc informatique
Il y a un autre sujet délicat sous-jacent. Votre agent va hériter de votre parc informatique existant.
Les API rutilantes, les systèmes hérités, les dossiers clients incohérents, l'intégration que quelqu'un a codée il y a huit ans et à laquelle personne ne veut toucher, et la plateforme qui nomme un client d'une certaine façon alors qu'une autre l'appelle autrement. Une entreprise grandit, des plateformes sont achetées, les équipes résolvent des problèmes individuels, des acquisitions ont lieu, les fournisseurs changent et les priorités évoluent. Finalement, vous vous retrouvez avec ce que tout le monde qualifie poliment d'architecture actuelle.
Imaginez maintenant un agent traitant le cas d'un client qui a payé pour un service mais ne peut pas y accéder. La réponse peut nécessiter des informations provenant du CRM, de la facturation, de l'authentification, des droits d'accès et des systèmes de support avant que quiconque puisse déterminer ce qui s'est réellement passé.
Un conseiller humain gérera souvent ces incohérences presque sans y penser. Il sait qu'un système se met à jour avant un autre. Il remarque que les identifiants sont légèrement différents. Peut-être se souvient-il que les clients disposant d'une ancienne offre se comportent différemment, ou demande-t-il simplement à son collègue d'à côté parce que la documentation n'a pas été mise à jour depuis 2023.
Confiez cette tâche à un agent, et ces hypothèses devront être formalisées quelque part. Quel système fait foi ? Que se passe-t-il si la facturation indique que le paiement a réussi mais que la plateforme de gestion des droits indique que le compte est inactif ? L'information est-elle erronée ou s'agit-il d'une règle de gestion que l'agent ne comprend pas ? Une plateforme a-t-elle simplement cinq minutes de retard ?
Ce sont de vieux problèmes de données et d'architecture, mais avec un nouvel utilisateur. La différence majeure est que cet utilisateur peut désormais agir en fonction de la conclusion à laquelle il parvient.
De mauvaises données fournies à un chatbot peuvent générer une mauvaise réponse. De mauvaises données fournies à un logiciel autonome peuvent générer un mauvais résultat.
Il existe également une autre complication. Les informations ne sont pas nécessairement erronées par accident. Des recherches publiées en juillet ont mis en évidence des attaques par injection de données d'agent, dans lesquelles des informations contrôlées par un attaquant pouvaient être présentées comme des données contextuelles apparemment légitimes et influencer ce qu'un agent faisait par la suite. Les chercheurs ont identifié des vulnérabilités dans de réels agents web et de codage, susceptibles d'entraîner des clics involontaires, l'exécution de code à distance et des actions malveillantes sur la chaîne d'approvisionnement logicielle.
Cela crée un croisement délicat entre architecture des données et sécurité. Si l'information peut influencer l'action, l'origine de cette information, sa fiabilité et le poids que l'agent doit lui accorder ne sont plus des questions de gouvernance abstraites. Ils font partie intégrante du modèle d'exécution.
C'est aussi pourquoi je me méfierais de l'idée selon laquelle les agents rendraient d'une certaine manière la dette technique moins importante. Un agent peut faciliter la navigation dans des environnements fragmentés parce qu'il peut raisonner sur une tâche plutôt que de s'appuyer entièrement sur un parcours d'intégration fixe, mais il a toujours besoin d'accéder aux systèmes, d'interfaces exploitables, de données cohérentes, d'autorisations appropriées et d'une idée de ce qu'il doit faire en cas d'échec en cours de route.
Si l'API n'existe pas, l'agent a besoin d'un autre moyen d'accès. Si le même client possède six identifiants, quelqu'un ou quelque chose doit encore établir s'ils représentent la même personne. Si une règle de gestion non documentée influe sur la décision, cette connaissance doit être accessible quelque part.
Placer une couche d'orchestration intelligente devant un parc informatique désordonné n'efface pas le désordre. Cela peut rendre le désordre plus facile à appréhender. Mais cela peut aussi permettre aux conséquences de ce désordre de se propager considérablement plus vite.
La supervision humaine a un coût économique
À ce stade de la réflexion, on entend souvent dire qu'il y aura toujours un humain dans la boucle.
C'est rassurant, mais cela soulève une question évidente : si quelqu'un doit encore examiner et approuver tout ce que fait l'agent, qu'avons-nous réellement automatisé ?
Imaginez que notre agent de service client ait consulté cinq systèmes, identifié un problème de compte, établi que le client a été facturé à tort et calculé qu'un remboursement de 20 € est approprié. Il place ensuite le dossier dans une file d'attente pour qu'un humain clique sur « Approuver ».
Le gain peut rester appréciable car l'analyse a été automatisée, mais si vous appliquez ce processus à des dizaines de milliers de transactions, vous conservez une opération manuelle considérable. Le goulot d'étranglement s'est déplacé plutôt que de disparaître.
C'est là que les discours prudents autour de l'IA par agents entrent en conflit avec la réalité économique de l'automatisation. Nous introduisons l'autonomie parce que nous voulons qu'un logiciel allège un processus, puis cette autonomie nous inquiète au point de réintroduire un humain dans chaque transaction.
Au bout du compte, cela va à l'encontre du but recherché.
Le défi de la supervision des agents d'IA réside donc dans le fait qu'une surveillance accrue n'est pas systématiquement préférable. Chaque étape d'approbation peut réduire un risque particulier, mais elle réintroduit également du coût, des délais et des interventions manuelles dans le processus. La vraie question est de savoir où le jugement humain apporte une réelle valeur ajoutée.
Si le remboursement est de 20 €, que les règles sont claires, que tous les systèmes concernés concordent et que l'action est facilement réversible, l'approbation humaine n'est peut-être pas nécessaire. Si le montant est de 20 000 €, que deux systèmes se contredisent ou que la situation sort des paramètres normaux, c'est le moment idéal pour faire intervenir un collaborateur.
Pour de nombreux processus, l'idéal n'est donc probablement pas d'avoir l'humain systématiquement dans la boucle, mais l'humain par exception. Les tâches routinières et bien comprises deviennent de plus en plus autonomes, tandis que les cas inhabituels, ambigus ou à fort enjeu sont remontés.
Cela laisse une grande marge de manœuvre pour introduire l'autonomie de manière progressive. Un agent peut commencer par observer et recommander. Une fois son comportement maîtrisé, il peut préparer des actions pour approbation. À terme, certaines catégories d'actions routinières et réversibles peuvent être exécutées automatiquement, les humains n'intervenant que lorsque le processus franchit un seuil convenu.
Les recommandations d'OpenAI adoptent une approche similaire basée sur le risque. Elles préconisent une intervention humaine lorsque les agents dépassent des seuils d'erreur définis et pour les actions sensibles, irréversibles ou à enjeux élevés, telles que les remboursements ou les paiements importants.
PocketOS est parvenu à cette même conclusion par un chemin beaucoup moins théorique. Suite à son incident de base de données, les opérations destructrices nécessitent désormais une confirmation humaine explicite. L'entreprise n'a pas pour autant renoncé aux agents autonomes. Elle indique continuer à faire tourner plusieurs agents autonomes spécialisés en production, tout en modifiant l'emplacement de la frontière de contrôle.
C'est, selon moi, la manière la plus pertinente d'envisager la supervision humaine. C'est un contrôle qui doit s'appliquer là où les conséquences le justifient, et non pas nécessairement un modèle opérationnel permanent pour chaque action effectuée par un logiciel autonome.
Le but de l'automatisation reste, après tout, d'automatiser. Le problème de conception consiste à décider où les humains améliorent véritablement le résultat et où ils sont simplement maintenus parce que nous ne faisons pas encore assez confiance au système pour les retirer.
L'autonomie sans traçabilité est indéfendable sur le plan opérationnel
Si nous évoluons vers un modèle d'humain par exception, un autre aspect devient d'autant plus crucial : comprendre ce que l'agent a réellement fait.
L'enquête sur Hugging Face en est un exemple extrême mais parlant. Sa reconstruction médico-légale a couvert environ 17 600 actions à travers des milliers de clusters, les enquêteurs reconstituant la manière dont l'agent s'est déplacé dans les systèmes et a adapté son comportement au fil du temps.
Ramenez cela à un processus d'entreprise classique. Un client affirme qu'une modification a été effectuée à tort sur son compte et vous découvrez qu'un agent en est à l'origine.
Dire « C'est l'IA qui l'a fait » ne vous mènera pas bien loin lors de la revue d'incident.
Vous voudrez savoir quel agent a agi, qui a initié la tâche, quelles informations il a utilisées, ce que ces informations contenaient à ce moment-là, quels outils il a appelés et quelle autorisation a finalement permis la modification. Si un autre agent est intervenu en cours de route, cela a probablement aussi son importance.
C'est là que l'auditabilité des agents d'IA cesse d'être une simple bonne pratique de gouvernance pour devenir une exigence opérationnelle. Moins l'intervention humaine est directe dans l'exécution, plus l'observabilité globale doit être renforcée.
Les recommandations actuelles de Microsoft préconisent de consigner l'identité de l'agent, son rôle et son champ d'action réel, l'action effectuée, la ressource concernée et l'identité de l'utilisateur pour le compte duquel il agissait. De même, le NIST examine explicitement l'audit et la non-répudiation dans le cadre du problème d'identité et d'autorisation des agents.
Cela ne signifie pas que chaque action autonome doive être surveillée par un humain. Nous exploitons déjà d'immenses environnements automatisés sans placer une personne derrière chaque transaction, événement d'infrastructure ou requête réseau. Nous définissons des limites, des contrôles et des alertes, puis nous enquêtons sur ce qui en sort.
Il n'y a pas de raison évidente pour que des systèmes d'agents matures fonctionnent différemment.
L'autonomie ne supprime pas la supervision. Elle modifie le moment où elle s'exerce.
L'intention déléguée complexifie la frontière de confiance
Il y a une autre évolution qui mérite attention, car elle rend ce problème encore plus intéressant.
Les agents sont de plus en plus conçus pour communiquer et collaborer avec d'autres agents. Le protocole Agent2Agent de Google normalise la façon dont les agents peuvent se découvrir et communiquer entre eux, y compris ceux conçus par des équipes différentes ou sur des environnements techniques distincts. Ses récents travaux sur l'Agentic Resource Discovery traitent de la question connexe de savoir comment les agents peuvent trouver et valider des outils, des compétences et d'autres agents répartis entre différentes équipes, organisations et plateformes.
Imaginez qu'un agent interne reçoive une tâche et détermine qu'un autre agent spécialisé peut en réaliser une partie. Ce second agent utilise un outil qui appelle l'un de vos services et finit par modifier quelque chose.
Qui agit ici ?
Le second agent ? Le premier agent ? La personne qui a initié la tâche d'origine ?
Si le premier agent est autorisé à effectuer une action, peut-il déléguer cette autorité ? Le second agent en reçoit-il la totalité, une partie ou rien du tout ? Que se passe-t-il si les agents appartiennent à des organisations différentes ?
Ce sont des questions émergentes et il serait prématuré de prétendre que le secteur a déjà tranché sur toutes les réponses. L'initiative sur les normes des agents d'IA du NIST (AI Agent Standards Initiative) mène des travaux spécifiques autour de l'authentification des agents et des infrastructures d'identité pour sécuriser les interactions homme-agent et multi-agents.
Mais la direction prise est claire. Historiquement, la confiance a souvent été associée à un utilisateur, une application ou une intégration connue. Dès lors que des agents peuvent découvrir dynamiquement des capacités et déléguer des parties d'un objectif ailleurs, la confiance et l'autorité doivent pouvoir être garanties tout au long de ce parcours.
La tâche peut être dynamique. La responsabilité, elle, ne peut pas s'évanouir à chaque fois qu'elle franchit une nouvelle frontière.
La transformation par agents devrait commencer par la délégation, pas par la technologie
Il existe un schéma classique lors des ruptures technologiques majeures que la plupart des professionnels de la transformation reconnaîtront. Un sujet devient stratégique, la direction décide que l'organisation doit s'en emparer, et chacun commence à chercher où l'appliquer.
Nous avons besoin d'une stratégie d'IA. Il nous faut des cas d'usage d'agents. Nous devrions organiser un atelier. Quels processus pouvons-nous confier à des agents ?
J'aborderais plutôt le problème dans l'autre sens.
Commencez par le processus qui agace tout le monde. Celui qui est lent, coûteux, fragmenté ou qui repose sur un collaborateur passant sa journée à transférer des données d'un système à un autre. Comprenez où sont prises les décisions, sur quelles informations elles s'appuient, quels systèmes sont impliqués, à quel moment surviennent les exceptions complexes et ce qui se passe en cas de problème.
Ensuite, analysez ce que font réellement les collaborateurs dans ce processus. Exercent-ils un jugement à forte valeur ajoutée, ou compensent-ils les limites des technologies qui les entourent ? Approuvent-ils une action en raison d'un réel risque financier ou opérationnel, ou simplement parce que le flux de travail est incapable de distinguer un cas de routine d'un cas inhabituel ? Réconcilient-ils manuellement les informations parce que l'organisation a réellement besoin de leur expertise, ou parce que deux systèmes utilisent des identifiants différents ?
Ce sont des problèmes bien distincts.
Une fois cela compris, décidez de ce que vous êtes prêt à déléguer. Quelles décisions le logiciel peut-il prendre ? Quelles actions peut-il mener ? Lesquelles sont réversibles ? Quand devez-vous prévoir une escalade ? De quelle autorité a-t-il besoin ? De quelles preuves auriez-vous besoin a posteriori si quelqu'un vous demandait les raisons d'une décision ?
C'est seulement à ce moment-là que le choix technologique devient véritablement intéressant.
Un agent peut être une excellente solution. Ou pas. Et c'est très bien ainsi. Les guides actuels sur la conception des agents font la même distinction : les agents sont particulièrement adaptés aux flux de travail où l'ambiguïté, les décisions complexes ou les données non structurées mettent en difficulté les approches déterministes. En revanche, lorsque ces caractéristiques sont absentes, l'automatisation conventionnelle peut rester tout à fait suffisante.
L'objectif n'est pas de déployer des agents. Il est d'améliorer l'entreprise.
L'architecture de l'automatisation devient l'architecture de l'autorité
Ces vingt dernières années, la transformation numérique a consisté en grande partie à connecter les personnes aux systèmes, et les systèmes entre eux. Nous commençons aujourd'hui à introduire un nouvel acteur dans ce parc informatique : un logiciel capable de recevoir un objectif, de déterminer comment l'atteindre et d'utiliser ces systèmes en notre nom.
Cela ouvre des perspectives réellement intéressantes, notamment pour les tâches de coordination qui résistaient jusqu'ici à l'automatisation classique. Le NIST lui-même décrit le potentiel des agents pour améliorer la productivité, l'efficacité et la prise de décision, tout en soulignant la nécessité de contrôles d'identification et d'autorisation appropriés lorsque ces agents accèdent aux données, outils et applications de l'organisation.
Je pense que cette double dimension est essentielle. L'opportunité et le risque proviennent de la même caractéristique : l'agent dispose d'une certaine liberté pour décider de la manière dont le travail est effectué.
Dès lors, l'architecture ne se limite plus à vérifier si un système peut se connecter à un autre. Elle détermine de plus en plus quel acteur autonome peut utiliser quelle information, exercer quelle capacité, sous quelle autorité, avec quelles limites et en laissant quelles traces.
En pratique, la gouvernance des agents d'IA en entreprise ne sera donc probablement pas résolue par un énième document de politique générale publié sur l'intranet. Elle doit se traduire concrètement dans les identités que nous créons, les droits que nous accordons, les contrôles autour des actions critiques, la qualité et la provenance des données que les agents exploitent, les circuits d'escalade que nous concevons et les preuves d'audit que nous conservons ensuite.
Hugging Face nous montre un cas extrême de logiciel autonome trouvant un chemin inattendu par ses concepteurs. PocketOS illustre de façon plus quotidienne ce qui se produit lorsqu'un agent dispose simplement de plus d'autorité que sa tâche ne l'exige. Les travaux émergents autour de l'identité des agents, du moindre privilège, de l'interaction multi-agents sécurisée et de la découverte de ressources de confiance montrent que le modèle de contrôle doit déjà s'adapter aux capacités technologiques.
Rien de tout cela n'est un argument contre l'IA par agents. Bien au contraire. Si les agents peuvent éliminer une partie de la coordination humaine qui rend les entreprises numériques modernes coûteuses et lourdes à gérer, il y a une raison très concrète de s'y intéresser.
Mais introduire des acteurs autonomes dans un écosystème numérique existant n'est pas un simple projet d'IA de plus. Cela bouscule les principes d'identité, de confiance, de données, de responsabilité et, en fin de compte, d'autorité.
Ainsi, avant de vous demander ce qu'un agent peut faire, je commencerais par poser une autre question.
Qu'êtes-vous réellement prêt à le laisser faire ?
Quand l'IA prend le pouvoir
Ces dernières années, les entreprises se sont concentrées sur ce que l'IA générative peut nous apporter. Les agents d'IA introduisent une question bien plus lourde de conséquences : que se passe-t-il lorsque le logiciel peut décider de la prochaine action à mener, puis l'exécuter lui-même ?
En juillet 2026, un agent d'IA utilisé dans le cadre d'une évaluation de la cybersécurité d'OpenAI a compromis une partie de l'infrastructure de production de Hugging Face. Il convient de replacer les choses dans leur contexte avant de s'emballer. Il ne s'agissait pas d'une application d'entreprise classique décidant soudainement d'attaquer une autre société. OpenAI testait délibérément des modèles hautement performants sur des tâches de cybersécurité complexes, et les classificateurs de production normalement utilisés pour empêcher les modèles de poursuivre des activités informatiques à haut risque avaient été intentionnellement désactivés pour cette évaluation.
Malgré cela, ce qui s'est passé mérite qu'on s'y attarde. Selon les enquêtes qui ont suivi, l'agent semble avoir conclu que les informations détenues par Hugging Face pouvaient l'aider à atteindre l'objectif d'évaluation qui lui avait été fixé. Il a trouvé une faille grâce à une vulnérabilité de type zero-day dans l'infrastructure utilisée par l'environnement d'évaluation, a obtenu un accès plus large à Internet, a enchaîné d'autres vecteurs d'attaque, a récupéré des identifiants et a finalement atteint les systèmes de Hugging Face. L'analyse médico-légale de Hugging Face a recensé environ 17 600 actions individuelles, regroupées en quelque 6 280 clusters.
La tentation, naturellement, est de titrer sur « l'évasion de l'IA » ou « l'IA devenue incontrôlable ». Je ne pense pas que l'une ou l'autre de ces formulations soit particulièrement pertinente. Autant que les enquêtes ont pu l'établir, le logiciel tentait d'atteindre l'objectif qui lui avait été assigné et a trouvé un chemin que personne n'avait anticipé. Hugging Face estime que l'agent essayait en réalité de tricher lors de l'évaluation en accédant aux systèmes de production, où il pensait pouvoir trouver des informations sur le benchmark ou les solutions.
C'est tout de suite beaucoup moins théâtral, mais du point de vue de la transformation numérique, c'est probablement bien plus important.
Ces dernières années, la plupart des organisations ont appréhendé l'IA générative comme un outil auquel on pose des questions. On lui fournit des informations, on lui pose une question et on obtient un résultat. Elle peut résumer un contrat, analyser des données, écrire du code ou rédiger un e-mail, mais il y a généralement toujours un être humain de l'autre côté qui décide de la suite des événements.
Les agents commencent à brouiller cette frontière. Donnez à cette même intelligence un accès à des outils et elle pourra récupérer des informations, appeler une API, mettre à jour un enregistrement, exécuter du code, envoyer l'e-mail ou effectuer la modification elle-même. OpenAI décrit les agents de manière très similaire : des systèmes capables de gérer de façon indépendante l'exécution de flux de travail, de prendre des décisions, de sélectionner les outils appropriés et d'interagir avec des systèmes externes au nom d'un utilisateur.
Le chatbot vient d'obtenir un accès en écriture.
C'est ce virage qui fait de la gouvernance des agents d'IA une préoccupation concrète pour l'entreprise, plutôt qu'un simple débat de principe de plus. Dès lors que le logiciel peut agir au lieu de se contenter de faire des recommandations, les questions d'identité, de droits d'accès, de contrôles, d'auditabilité et de responsabilité s'invitent au cœur même de l'architecture.
L'automatisation change lorsque l'on donne au logiciel une intention, et non des instructions
Les logiciels transforment notre quotidien depuis des décennies, il ne faudrait donc pas surestimer la nouveauté de la situation. Nous n'avons pas besoin de l'IA pour mettre à jour une base de données, déclencher une API ou exécuter un flux de travail. Les scripts, les moteurs de règles, les plateformes d'orchestration et les processus automatisés s'en chargent parfaitement depuis des années.
La différence réside dans la manière de passer de l'objectif à l'action. L'automatisation traditionnelle est normalement conçue autour d'un parcours défini à l'avance. Quand X se produit, récupérer Y. Si la réponse est Z, effectuer telle action. Même si cela implique des centaines de règles, d'embranchements et d'exceptions, le processus a toujours été modélisé au préalable par un humain.
Les agents nous permettent potentiellement d'aller plus loin en fixant un résultat au logiciel plutôt qu'en lui fournissant chaque instruction nécessaire pour y parvenir. Le problème est posé de la sorte : déterminez de quelles informations vous avez besoin. Décidez des outils appropriés. Gérez les retours d'information et menez à bien la tâche.
Cette distinction est cruciale car le chemin d'exécution peut devenir dynamique. Un agent peut commencer par interroger un système, découvrir qu'il a besoin d'un contexte supplémentaire, appeler un autre service, se heurter à un résultat inattendu, revoir son approche et poursuivre sa tâche. Les architectures d'agents actuelles sont explicitement conçues autour de cette capacité à gérer un flux de travail, à choisir des outils et à prendre des mesures en fonction de l'avancement de la tâche.
Il s'agit d'une proposition fondamentalement différente de l'automatisation classique. Le logiciel ne se contente plus d'exécuter un flux prédéterminé. Dans les limites que nous lui fixons, nous lui laissons une certaine marge d'appréciation sur la manière dont ce flux se déroule.
Et c'est là que le sujet devient bien plus intéressant qu'une simple discussion sur la capacité de l'IA à rédiger un meilleur e-mail.
L'opportunité réside dans la suppression de la coordination, pas des personnes
Au sein d'une organisation, une quantité surprenante de travail n'est pas difficile parce qu'une tâche individuelle est particulièrement complexe, mais en raison de la coordination requise entre ces tâches.
Ouvrir le CRM. Trouver le client. Copier un identifiant dans la plateforme de facturation. Lire les notes. Consulter un autre système. Comprendre leur signification. Demander à une autre équipe si une situation est normale. Attendre la réponse. Mettre à jour la première plateforme et envoyer un e-mail au client.
Cela vous rappelle quelque chose ?
Nous avons passé des années à essayer d'automatiser ces processus, et les technologies de gestion des flux de travail classiques sont extrêmement efficaces lorsque les étapes peuvent être décrites de manière prévisible. Les difficultés résident généralement dans les exceptions : un document mal structuré, un compte qui ne correspond pas tout à fait, trois systèmes en contradiction, ou le moment du processus où un collaborateur doit lire et comprendre une information avant de savoir ce qu'il doit faire ensuite.
C'est précisément dans ce genre de flux de travail que les agents s'avèrent potentiellement utiles. Les recommandations actuelles d'OpenAI identifient spécifiquement la prise de décision complexe, les règles difficiles à maintenir et la forte dépendance à l'égard d'informations non structurées comme des domaines où une approche par agents peut apporter une valeur ajoutée que l'automatisation déterministe classique n'offre pas. Elles soulignent également, à juste titre, qu'en l'absence de ces caractéristiques, une solution déterministe reste souvent la meilleure option.
Si un logiciel peut prendre en charge une partie de la coordination entre les systèmes, les informations et les décisions, le gain d'efficacité potentiel est significatif. Non pas parce que tous les acteurs du processus disparaissent soudainement, mais parce que nous pouvons cesser d'utiliser des humains comme de coûteux intermédiaires entre des plateformes qui n'ont jamais été très douées pour communiquer entre elles.
La nuance est de taille. L'objectif ne doit pas nécessairement être de supprimer les collaborateurs de l'organisation. Il doit être de supprimer les tâches que nous leur imposons aujourd'hui simplement parce que la technologie sous-jacente ne gère pas bien le contexte, l'ambiguïté ou les exceptions.
C'est pourquoi je pense que l'opportunité offerte par les agents dépasse de loin un simple gain de productivité marginal. Rédiger la réponse à un client dix secondes plus vite est certes utile. Permettre à un logiciel d'analyser le problème, de rapprocher les informations pertinentes et de faire progresser le processus est d'un tout autre ordre.
Bien sûr, plus le logiciel fait progresser le processus, plus il se rapproche d'une action lourde de conséquences.
Et c'est là que les choses se compliquent nettement.
La capacité n'est pas l'autorité
Quelques mois avant l'incident de Hugging Face, PocketOS a publié un compte rendu sans fard d'un agent d'IA ayant supprimé la base de données de production de l'entreprise. La suppression a pris neuf secondes. La restauration a nécessité soixante heures. Les sauvegardes existaient, mais dataient de trois mois car le processus de sauvegarde s'était arrêté en silence.
PocketOS précise également de manière très claire qu'il ne s'agissait pas d'un simple « problème d'IA ». L'entreprise indique que l'agent a agi avec assurance en utilisant des droits d'accès qu'il n'aurait jamais dû posséder, sur un environnement qui ne présentait pas de barrières suffisantes contre une action destructrice.
C'est là une leçon précieuse.
Les humains suppriment des bases de données de production depuis des années, et les bugs logiciels y ont également largement contribué. L'élément notable ici est que l'acteur disposait d'une autorité suffisante pour que son erreur ait un impact réel.
Nous comprenons déjà ce principe lorsqu'il s'agit d'un humain. Un conseiller du service client peut être autorisé à accorder un remboursement de 20 € sans que personne ne s'en soucie. Un montant de 200 € peut encore sembler tout à fait raisonnable. Un remboursement de 20 000 € ouvre probablement un tout autre débat.
Le même principe s'applique ailleurs. Un agent qui identifie une faute d'orthographe dans les métadonnées d'un contenu et la corrige est une action plutôt inoffensive. En revanche, si le champ qu'il souhaite modifier détermine si ce contenu peut être diffusé sur un territoire donné, la conséquence est tout autre. De même, un agent peut identifier correctement un problème de configuration de production, mais cela ne signifie pas qu'il doive hériter de droits illimités pour reconfigurer l'ensemble de l'environnement.
Rien de tout cela n'est particulièrement nouveau. Il s'agit de gestion des identités et des accès appliquée à un nouveau type d'acteur, et je soupçonne que cela deviendra l'un des piliers d'une gouvernance efficace de l'IA par agents.
Microsoft traite déjà les agents dans ces termes. Ses recommandations actuelles préconisent une identité d'agent d'IA unique et dédiée, un propriétaire ou un garant désigné, un objectif et des accès aux données clairement documentés, un accès basé sur le principe du moindre privilège, des autorisations d'outils contrôlées, une journalisation des activités et des procédures de révocation testées. Les travaux du NIST dans ce même domaine examinent explicitement l'identification, l'autorisation, l'audit et la non-répudiation pour les agents d'IA.
En pratique, cela signifie que les autorisations des agents d'IA doivent être traitées avec le même sérieux que les comptes d'administration humains ou de services privilégiés. Un agent peut être parfaitement capable de déterminer ce qui doit se passer sans pour autant être autorisé à le mettre en œuvre.
Cette distinction est essentielle. Les contrôles des agents d'IA ne peuvent pas simplement se limiter à vérifier si un modèle est techniquement capable d'effectuer une action. Ils doivent déterminer si cet agent précis, agissant dans ce contexte précis, est autorisé à l'exécuter.
Par ailleurs, je crains que la prolifération des agents d'IA ne devienne l'un de ces problèmes dont les entreprises n'ont pas conscience jusqu'à ce que quelqu'un demande enfin : « Combien d'agents avons-nous réellement ? » Nous avons déjà connu des situations similaires avec les applications SaaS, les ressources cloud, les comptes de service et les clés d'API. Il n'y a aucune raison évidente pour que le parc d'agents s'organise mieux de lui-même, en particulier dans les entreprises où l'expérimentation est délibérément décentralisée au sein des équipes.
Cela ne signifie pas pour autant qu'il faille centraliser toutes les initiatives d'IA. Une équipe centrale a peu de chances de comprendre suffisamment bien chaque processus pour identifier elle-même toutes les applications utiles. Une innovation décentralisée peut être tout à fait judicieuse.
Une autorité déléguée par accident est en revanche une tout autre histoire.
L'IA par agents hérite de chaque faille de votre parc informatique
Il y a un autre sujet délicat sous-jacent. Votre agent va hériter de votre parc informatique existant.
Les API rutilantes, les systèmes hérités, les dossiers clients incohérents, l'intégration que quelqu'un a codée il y a huit ans et à laquelle personne ne veut toucher, et la plateforme qui nomme un client d'une certaine façon alors qu'une autre l'appelle autrement. Une entreprise grandit, des plateformes sont achetées, les équipes résolvent des problèmes individuels, des acquisitions ont lieu, les fournisseurs changent et les priorités évoluent. Finalement, vous vous retrouvez avec ce que tout le monde qualifie poliment d'architecture actuelle.
Imaginez maintenant un agent traitant le cas d'un client qui a payé pour un service mais ne peut pas y accéder. La réponse peut nécessiter des informations provenant du CRM, de la facturation, de l'authentification, des droits d'accès et des systèmes de support avant que quiconque puisse déterminer ce qui s'est réellement passé.
Un conseiller humain gérera souvent ces incohérences presque sans y penser. Il sait qu'un système se met à jour avant un autre. Il remarque que les identifiants sont légèrement différents. Peut-être se souvient-il que les clients disposant d'une ancienne offre se comportent différemment, ou demande-t-il simplement à son collègue d'à côté parce que la documentation n'a pas été mise à jour depuis 2023.
Confiez cette tâche à un agent, et ces hypothèses devront être formalisées quelque part. Quel système fait foi ? Que se passe-t-il si la facturation indique que le paiement a réussi mais que la plateforme de gestion des droits indique que le compte est inactif ? L'information est-elle erronée ou s'agit-il d'une règle de gestion que l'agent ne comprend pas ? Une plateforme a-t-elle simplement cinq minutes de retard ?
Ce sont de vieux problèmes de données et d'architecture, mais avec un nouvel utilisateur. La différence majeure est que cet utilisateur peut désormais agir en fonction de la conclusion à laquelle il parvient.
De mauvaises données fournies à un chatbot peuvent générer une mauvaise réponse. De mauvaises données fournies à un logiciel autonome peuvent générer un mauvais résultat.
Il existe également une autre complication. Les informations ne sont pas nécessairement erronées par accident. Des recherches publiées en juillet ont mis en évidence des attaques par injection de données d'agent, dans lesquelles des informations contrôlées par un attaquant pouvaient être présentées comme des données contextuelles apparemment légitimes et influencer ce qu'un agent faisait par la suite. Les chercheurs ont identifié des vulnérabilités dans de réels agents web et de codage, susceptibles d'entraîner des clics involontaires, l'exécution de code à distance et des actions malveillantes sur la chaîne d'approvisionnement logicielle.
Cela crée un croisement délicat entre architecture des données et sécurité. Si l'information peut influencer l'action, l'origine de cette information, sa fiabilité et le poids que l'agent doit lui accorder ne sont plus des questions de gouvernance abstraites. Ils font partie intégrante du modèle d'exécution.
C'est aussi pourquoi je me méfierais de l'idée selon laquelle les agents rendraient d'une certaine manière la dette technique moins importante. Un agent peut faciliter la navigation dans des environnements fragmentés parce qu'il peut raisonner sur une tâche plutôt que de s'appuyer entièrement sur un parcours d'intégration fixe, mais il a toujours besoin d'accéder aux systèmes, d'interfaces exploitables, de données cohérentes, d'autorisations appropriées et d'une idée de ce qu'il doit faire en cas d'échec en cours de route.
Si l'API n'existe pas, l'agent a besoin d'un autre moyen d'accès. Si le même client possède six identifiants, quelqu'un ou quelque chose doit encore établir s'ils représentent la même personne. Si une règle de gestion non documentée influe sur la décision, cette connaissance doit être accessible quelque part.
Placer une couche d'orchestration intelligente devant un parc informatique désordonné n'efface pas le désordre. Cela peut rendre le désordre plus facile à appréhender. Mais cela peut aussi permettre aux conséquences de ce désordre de se propager considérablement plus vite.
La supervision humaine a un coût économique
À ce stade de la réflexion, on entend souvent dire qu'il y aura toujours un humain dans la boucle.
C'est rassurant, mais cela soulève une question évidente : si quelqu'un doit encore examiner et approuver tout ce que fait l'agent, qu'avons-nous réellement automatisé ?
Imaginez que notre agent de service client ait consulté cinq systèmes, identifié un problème de compte, établi que le client a été facturé à tort et calculé qu'un remboursement de 20 € est approprié. Il place ensuite le dossier dans une file d'attente pour qu'un humain clique sur « Approuver ».
Le gain peut rester appréciable car l'analyse a été automatisée, mais si vous appliquez ce processus à des dizaines de milliers de transactions, vous conservez une opération manuelle considérable. Le goulot d'étranglement s'est déplacé plutôt que de disparaître.
C'est là que les discours prudents autour de l'IA par agents entrent en conflit avec la réalité économique de l'automatisation. Nous introduisons l'autonomie parce que nous voulons qu'un logiciel allège un processus, puis cette autonomie nous inquiète au point de réintroduire un humain dans chaque transaction.
Au bout du compte, cela va à l'encontre du but recherché.
Le défi de la supervision des agents d'IA réside donc dans le fait qu'une surveillance accrue n'est pas systématiquement préférable. Chaque étape d'approbation peut réduire un risque particulier, mais elle réintroduit également du coût, des délais et des interventions manuelles dans le processus. La vraie question est de savoir où le jugement humain apporte une réelle valeur ajoutée.
Si le remboursement est de 20 €, que les règles sont claires, que tous les systèmes concernés concordent et que l'action est facilement réversible, l'approbation humaine n'est peut-être pas nécessaire. Si le montant est de 20 000 €, que deux systèmes se contredisent ou que la situation sort des paramètres normaux, c'est le moment idéal pour faire intervenir un collaborateur.
Pour de nombreux processus, l'idéal n'est donc probablement pas d'avoir l'humain systématiquement dans la boucle, mais l'humain par exception. Les tâches routinières et bien comprises deviennent de plus en plus autonomes, tandis que les cas inhabituels, ambigus ou à fort enjeu sont remontés.
Cela laisse une grande marge de manœuvre pour introduire l'autonomie de manière progressive. Un agent peut commencer par observer et recommander. Une fois son comportement maîtrisé, il peut préparer des actions pour approbation. À terme, certaines catégories d'actions routinières et réversibles peuvent être exécutées automatiquement, les humains n'intervenant que lorsque le processus franchit un seuil convenu.
Les recommandations d'OpenAI adoptent une approche similaire basée sur le risque. Elles préconisent une intervention humaine lorsque les agents dépassent des seuils d'erreur définis et pour les actions sensibles, irréversibles ou à enjeux élevés, telles que les remboursements ou les paiements importants.
PocketOS est parvenu à cette même conclusion par un chemin beaucoup moins théorique. Suite à son incident de base de données, les opérations destructrices nécessitent désormais une confirmation humaine explicite. L'entreprise n'a pas pour autant renoncé aux agents autonomes. Elle indique continuer à faire tourner plusieurs agents autonomes spécialisés en production, tout en modifiant l'emplacement de la frontière de contrôle.
C'est, selon moi, la manière la plus pertinente d'envisager la supervision humaine. C'est un contrôle qui doit s'appliquer là où les conséquences le justifient, et non pas nécessairement un modèle opérationnel permanent pour chaque action effectuée par un logiciel autonome.
Le but de l'automatisation reste, après tout, d'automatiser. Le problème de conception consiste à décider où les humains améliorent véritablement le résultat et où ils sont simplement maintenus parce que nous ne faisons pas encore assez confiance au système pour les retirer.
L'autonomie sans traçabilité est indéfendable sur le plan opérationnel
Si nous évoluons vers un modèle d'humain par exception, un autre aspect devient d'autant plus crucial : comprendre ce que l'agent a réellement fait.
L'enquête sur Hugging Face en est un exemple extrême mais parlant. Sa reconstruction médico-légale a couvert environ 17 600 actions à travers des milliers de clusters, les enquêteurs reconstituant la manière dont l'agent s'est déplacé dans les systèmes et a adapté son comportement au fil du temps.
Ramenez cela à un processus d'entreprise classique. Un client affirme qu'une modification a été effectuée à tort sur son compte et vous découvrez qu'un agent en est à l'origine.
Dire « C'est l'IA qui l'a fait » ne vous mènera pas bien loin lors de la revue d'incident.
Vous voudrez savoir quel agent a agi, qui a initié la tâche, quelles informations il a utilisées, ce que ces informations contenaient à ce moment-là, quels outils il a appelés et quelle autorisation a finalement permis la modification. Si un autre agent est intervenu en cours de route, cela a probablement aussi son importance.
C'est là que l'auditabilité des agents d'IA cesse d'être une simple bonne pratique de gouvernance pour devenir une exigence opérationnelle. Moins l'intervention humaine est directe dans l'exécution, plus l'observabilité globale doit être renforcée.
Les recommandations actuelles de Microsoft préconisent de consigner l'identité de l'agent, son rôle et son champ d'action réel, l'action effectuée, la ressource concernée et l'identité de l'utilisateur pour le compte duquel il agissait. De même, le NIST examine explicitement l'audit et la non-répudiation dans le cadre du problème d'identité et d'autorisation des agents.
Cela ne signifie pas que chaque action autonome doive être surveillée par un humain. Nous exploitons déjà d'immenses environnements automatisés sans placer une personne derrière chaque transaction, événement d'infrastructure ou requête réseau. Nous définissons des limites, des contrôles et des alertes, puis nous enquêtons sur ce qui en sort.
Il n'y a pas de raison évidente pour que des systèmes d'agents matures fonctionnent différemment.
L'autonomie ne supprime pas la supervision. Elle modifie le moment où elle s'exerce.
L'intention déléguée complexifie la frontière de confiance
Il y a une autre évolution qui mérite attention, car elle rend ce problème encore plus intéressant.
Les agents sont de plus en plus conçus pour communiquer et collaborer avec d'autres agents. Le protocole Agent2Agent de Google normalise la façon dont les agents peuvent se découvrir et communiquer entre eux, y compris ceux conçus par des équipes différentes ou sur des environnements techniques distincts. Ses récents travaux sur l'Agentic Resource Discovery traitent de la question connexe de savoir comment les agents peuvent trouver et valider des outils, des compétences et d'autres agents répartis entre différentes équipes, organisations et plateformes.
Imaginez qu'un agent interne reçoive une tâche et détermine qu'un autre agent spécialisé peut en réaliser une partie. Ce second agent utilise un outil qui appelle l'un de vos services et finit par modifier quelque chose.
Qui agit ici ?
Le second agent ? Le premier agent ? La personne qui a initié la tâche d'origine ?
Si le premier agent est autorisé à effectuer une action, peut-il déléguer cette autorité ? Le second agent en reçoit-il la totalité, une partie ou rien du tout ? Que se passe-t-il si les agents appartiennent à des organisations différentes ?
Ce sont des questions émergentes et il serait prématuré de prétendre que le secteur a déjà tranché sur toutes les réponses. L'initiative sur les normes des agents d'IA du NIST (AI Agent Standards Initiative) mène des travaux spécifiques autour de l'authentification des agents et des infrastructures d'identité pour sécuriser les interactions homme-agent et multi-agents.
Mais la direction prise est claire. Historiquement, la confiance a souvent été associée à un utilisateur, une application ou une intégration connue. Dès lors que des agents peuvent découvrir dynamiquement des capacités et déléguer des parties d'un objectif ailleurs, la confiance et l'autorité doivent pouvoir être garanties tout au long de ce parcours.
La tâche peut être dynamique. La responsabilité, elle, ne peut pas s'évanouir à chaque fois qu'elle franchit une nouvelle frontière.
La transformation par agents devrait commencer par la délégation, pas par la technologie
Il existe un schéma classique lors des ruptures technologiques majeures que la plupart des professionnels de la transformation reconnaîtront. Un sujet devient stratégique, la direction décide que l'organisation doit s'en emparer, et chacun commence à chercher où l'appliquer.
Nous avons besoin d'une stratégie d'IA. Il nous faut des cas d'usage d'agents. Nous devrions organiser un atelier. Quels processus pouvons-nous confier à des agents ?
J'aborderais plutôt le problème dans l'autre sens.
Commencez par le processus qui agace tout le monde. Celui qui est lent, coûteux, fragmenté ou qui repose sur un collaborateur passant sa journée à transférer des données d'un système à un autre. Comprenez où sont prises les décisions, sur quelles informations elles s'appuient, quels systèmes sont impliqués, à quel moment surviennent les exceptions complexes et ce qui se passe en cas de problème.
Ensuite, analysez ce que font réellement les collaborateurs dans ce processus. Exercent-ils un jugement à forte valeur ajoutée, ou compensent-ils les limites des technologies qui les entourent ? Approuvent-ils une action en raison d'un réel risque financier ou opérationnel, ou simplement parce que le flux de travail est incapable de distinguer un cas de routine d'un cas inhabituel ? Réconcilient-ils manuellement les informations parce que l'organisation a réellement besoin de leur expertise, ou parce que deux systèmes utilisent des identifiants différents ?
Ce sont des problèmes bien distincts.
Une fois cela compris, décidez de ce que vous êtes prêt à déléguer. Quelles décisions le logiciel peut-il prendre ? Quelles actions peut-il mener ? Lesquelles sont réversibles ? Quand devez-vous prévoir une escalade ? De quelle autorité a-t-il besoin ? De quelles preuves auriez-vous besoin a posteriori si quelqu'un vous demandait les raisons d'une décision ?
C'est seulement à ce moment-là que le choix technologique devient véritablement intéressant.
Un agent peut être une excellente solution. Ou pas. Et c'est très bien ainsi. Les guides actuels sur la conception des agents font la même distinction : les agents sont particulièrement adaptés aux flux de travail où l'ambiguïté, les décisions complexes ou les données non structurées mettent en difficulté les approches déterministes. En revanche, lorsque ces caractéristiques sont absentes, l'automatisation conventionnelle peut rester tout à fait suffisante.
L'objectif n'est pas de déployer des agents. Il est d'améliorer l'entreprise.
L'architecture de l'automatisation devient l'architecture de l'autorité
Ces vingt dernières années, la transformation numérique a consisté en grande partie à connecter les personnes aux systèmes, et les systèmes entre eux. Nous commençons aujourd'hui à introduire un nouvel acteur dans ce parc informatique : un logiciel capable de recevoir un objectif, de déterminer comment l'atteindre et d'utiliser ces systèmes en notre nom.
Cela ouvre des perspectives réellement intéressantes, notamment pour les tâches de coordination qui résistaient jusqu'ici à l'automatisation classique. Le NIST lui-même décrit le potentiel des agents pour améliorer la productivité, l'efficacité et la prise de décision, tout en soulignant la nécessité de contrôles d'identification et d'autorisation appropriés lorsque ces agents accèdent aux données, outils et applications de l'organisation.
Je pense que cette double dimension est essentielle. L'opportunité et le risque proviennent de la même caractéristique : l'agent dispose d'une certaine liberté pour décider de la manière dont le travail est effectué.
Dès lors, l'architecture ne se limite plus à vérifier si un système peut se connecter à un autre. Elle détermine de plus en plus quel acteur autonome peut utiliser quelle information, exercer quelle capacité, sous quelle autorité, avec quelles limites et en laissant quelles traces.
En pratique, la gouvernance des agents d'IA en entreprise ne sera donc probablement pas résolue par un énième document de politique générale publié sur l'intranet. Elle doit se traduire concrètement dans les identités que nous créons, les droits que nous accordons, les contrôles autour des actions critiques, la qualité et la provenance des données que les agents exploitent, les circuits d'escalade que nous concevons et les preuves d'audit que nous conservons ensuite.
Hugging Face nous montre un cas extrême de logiciel autonome trouvant un chemin inattendu par ses concepteurs. PocketOS illustre de façon plus quotidienne ce qui se produit lorsqu'un agent dispose simplement de plus d'autorité que sa tâche ne l'exige. Les travaux émergents autour de l'identité des agents, du moindre privilège, de l'interaction multi-agents sécurisée et de la découverte de ressources de confiance montrent que le modèle de contrôle doit déjà s'adapter aux capacités technologiques.
Rien de tout cela n'est un argument contre l'IA par agents. Bien au contraire. Si les agents peuvent éliminer une partie de la coordination humaine qui rend les entreprises numériques modernes coûteuses et lourdes à gérer, il y a une raison très concrète de s'y intéresser.
Mais introduire des acteurs autonomes dans un écosystème numérique existant n'est pas un simple projet d'IA de plus. Cela bouscule les principes d'identité, de confiance, de données, de responsabilité et, en fin de compte, d'autorité.
Ainsi, avant de vous demander ce qu'un agent peut faire, je commencerais par poser une autre question.
Qu'êtes-vous réellement prêt à le laisser faire ?
Quand l'IA prend le pouvoir
Ces dernières années, les entreprises se sont concentrées sur ce que l'IA générative peut nous apporter. Les agents d'IA introduisent une question bien plus lourde de conséquences : que se passe-t-il lorsque le logiciel peut décider de la prochaine action à mener, puis l'exécuter lui-même ?
En juillet 2026, un agent d'IA utilisé dans le cadre d'une évaluation de la cybersécurité d'OpenAI a compromis une partie de l'infrastructure de production de Hugging Face. Il convient de replacer les choses dans leur contexte avant de s'emballer. Il ne s'agissait pas d'une application d'entreprise classique décidant soudainement d'attaquer une autre société. OpenAI testait délibérément des modèles hautement performants sur des tâches de cybersécurité complexes, et les classificateurs de production normalement utilisés pour empêcher les modèles de poursuivre des activités informatiques à haut risque avaient été intentionnellement désactivés pour cette évaluation.
Malgré cela, ce qui s'est passé mérite qu'on s'y attarde. Selon les enquêtes qui ont suivi, l'agent semble avoir conclu que les informations détenues par Hugging Face pouvaient l'aider à atteindre l'objectif d'évaluation qui lui avait été fixé. Il a trouvé une faille grâce à une vulnérabilité de type zero-day dans l'infrastructure utilisée par l'environnement d'évaluation, a obtenu un accès plus large à Internet, a enchaîné d'autres vecteurs d'attaque, a récupéré des identifiants et a finalement atteint les systèmes de Hugging Face. L'analyse médico-légale de Hugging Face a recensé environ 17 600 actions individuelles, regroupées en quelque 6 280 clusters.
La tentation, naturellement, est de titrer sur « l'évasion de l'IA » ou « l'IA devenue incontrôlable ». Je ne pense pas que l'une ou l'autre de ces formulations soit particulièrement pertinente. Autant que les enquêtes ont pu l'établir, le logiciel tentait d'atteindre l'objectif qui lui avait été assigné et a trouvé un chemin que personne n'avait anticipé. Hugging Face estime que l'agent essayait en réalité de tricher lors de l'évaluation en accédant aux systèmes de production, où il pensait pouvoir trouver des informations sur le benchmark ou les solutions.
C'est tout de suite beaucoup moins théâtral, mais du point de vue de la transformation numérique, c'est probablement bien plus important.
Ces dernières années, la plupart des organisations ont appréhendé l'IA générative comme un outil auquel on pose des questions. On lui fournit des informations, on lui pose une question et on obtient un résultat. Elle peut résumer un contrat, analyser des données, écrire du code ou rédiger un e-mail, mais il y a généralement toujours un être humain de l'autre côté qui décide de la suite des événements.
Les agents commencent à brouiller cette frontière. Donnez à cette même intelligence un accès à des outils et elle pourra récupérer des informations, appeler une API, mettre à jour un enregistrement, exécuter du code, envoyer l'e-mail ou effectuer la modification elle-même. OpenAI décrit les agents de manière très similaire : des systèmes capables de gérer de façon indépendante l'exécution de flux de travail, de prendre des décisions, de sélectionner les outils appropriés et d'interagir avec des systèmes externes au nom d'un utilisateur.
Le chatbot vient d'obtenir un accès en écriture.
C'est ce virage qui fait de la gouvernance des agents d'IA une préoccupation concrète pour l'entreprise, plutôt qu'un simple débat de principe de plus. Dès lors que le logiciel peut agir au lieu de se contenter de faire des recommandations, les questions d'identité, de droits d'accès, de contrôles, d'auditabilité et de responsabilité s'invitent au cœur même de l'architecture.
L'automatisation change lorsque l'on donne au logiciel une intention, et non des instructions
Les logiciels transforment notre quotidien depuis des décennies, il ne faudrait donc pas surestimer la nouveauté de la situation. Nous n'avons pas besoin de l'IA pour mettre à jour une base de données, déclencher une API ou exécuter un flux de travail. Les scripts, les moteurs de règles, les plateformes d'orchestration et les processus automatisés s'en chargent parfaitement depuis des années.
La différence réside dans la manière de passer de l'objectif à l'action. L'automatisation traditionnelle est normalement conçue autour d'un parcours défini à l'avance. Quand X se produit, récupérer Y. Si la réponse est Z, effectuer telle action. Même si cela implique des centaines de règles, d'embranchements et d'exceptions, le processus a toujours été modélisé au préalable par un humain.
Les agents nous permettent potentiellement d'aller plus loin en fixant un résultat au logiciel plutôt qu'en lui fournissant chaque instruction nécessaire pour y parvenir. Le problème est posé de la sorte : déterminez de quelles informations vous avez besoin. Décidez des outils appropriés. Gérez les retours d'information et menez à bien la tâche.
Cette distinction est cruciale car le chemin d'exécution peut devenir dynamique. Un agent peut commencer par interroger un système, découvrir qu'il a besoin d'un contexte supplémentaire, appeler un autre service, se heurter à un résultat inattendu, revoir son approche et poursuivre sa tâche. Les architectures d'agents actuelles sont explicitement conçues autour de cette capacité à gérer un flux de travail, à choisir des outils et à prendre des mesures en fonction de l'avancement de la tâche.
Il s'agit d'une proposition fondamentalement différente de l'automatisation classique. Le logiciel ne se contente plus d'exécuter un flux prédéterminé. Dans les limites que nous lui fixons, nous lui laissons une certaine marge d'appréciation sur la manière dont ce flux se déroule.
Et c'est là que le sujet devient bien plus intéressant qu'une simple discussion sur la capacité de l'IA à rédiger un meilleur e-mail.
L'opportunité réside dans la suppression de la coordination, pas des personnes
Au sein d'une organisation, une quantité surprenante de travail n'est pas difficile parce qu'une tâche individuelle est particulièrement complexe, mais en raison de la coordination requise entre ces tâches.
Ouvrir le CRM. Trouver le client. Copier un identifiant dans la plateforme de facturation. Lire les notes. Consulter un autre système. Comprendre leur signification. Demander à une autre équipe si une situation est normale. Attendre la réponse. Mettre à jour la première plateforme et envoyer un e-mail au client.
Cela vous rappelle quelque chose ?
Nous avons passé des années à essayer d'automatiser ces processus, et les technologies de gestion des flux de travail classiques sont extrêmement efficaces lorsque les étapes peuvent être décrites de manière prévisible. Les difficultés résident généralement dans les exceptions : un document mal structuré, un compte qui ne correspond pas tout à fait, trois systèmes en contradiction, ou le moment du processus où un collaborateur doit lire et comprendre une information avant de savoir ce qu'il doit faire ensuite.
C'est précisément dans ce genre de flux de travail que les agents s'avèrent potentiellement utiles. Les recommandations actuelles d'OpenAI identifient spécifiquement la prise de décision complexe, les règles difficiles à maintenir et la forte dépendance à l'égard d'informations non structurées comme des domaines où une approche par agents peut apporter une valeur ajoutée que l'automatisation déterministe classique n'offre pas. Elles soulignent également, à juste titre, qu'en l'absence de ces caractéristiques, une solution déterministe reste souvent la meilleure option.
Si un logiciel peut prendre en charge une partie de la coordination entre les systèmes, les informations et les décisions, le gain d'efficacité potentiel est significatif. Non pas parce que tous les acteurs du processus disparaissent soudainement, mais parce que nous pouvons cesser d'utiliser des humains comme de coûteux intermédiaires entre des plateformes qui n'ont jamais été très douées pour communiquer entre elles.
La nuance est de taille. L'objectif ne doit pas nécessairement être de supprimer les collaborateurs de l'organisation. Il doit être de supprimer les tâches que nous leur imposons aujourd'hui simplement parce que la technologie sous-jacente ne gère pas bien le contexte, l'ambiguïté ou les exceptions.
C'est pourquoi je pense que l'opportunité offerte par les agents dépasse de loin un simple gain de productivité marginal. Rédiger la réponse à un client dix secondes plus vite est certes utile. Permettre à un logiciel d'analyser le problème, de rapprocher les informations pertinentes et de faire progresser le processus est d'un tout autre ordre.
Bien sûr, plus le logiciel fait progresser le processus, plus il se rapproche d'une action lourde de conséquences.
Et c'est là que les choses se compliquent nettement.
La capacité n'est pas l'autorité
Quelques mois avant l'incident de Hugging Face, PocketOS a publié un compte rendu sans fard d'un agent d'IA ayant supprimé la base de données de production de l'entreprise. La suppression a pris neuf secondes. La restauration a nécessité soixante heures. Les sauvegardes existaient, mais dataient de trois mois car le processus de sauvegarde s'était arrêté en silence.
PocketOS précise également de manière très claire qu'il ne s'agissait pas d'un simple « problème d'IA ». L'entreprise indique que l'agent a agi avec assurance en utilisant des droits d'accès qu'il n'aurait jamais dû posséder, sur un environnement qui ne présentait pas de barrières suffisantes contre une action destructrice.
C'est là une leçon précieuse.
Les humains suppriment des bases de données de production depuis des années, et les bugs logiciels y ont également largement contribué. L'élément notable ici est que l'acteur disposait d'une autorité suffisante pour que son erreur ait un impact réel.
Nous comprenons déjà ce principe lorsqu'il s'agit d'un humain. Un conseiller du service client peut être autorisé à accorder un remboursement de 20 € sans que personne ne s'en soucie. Un montant de 200 € peut encore sembler tout à fait raisonnable. Un remboursement de 20 000 € ouvre probablement un tout autre débat.
Le même principe s'applique ailleurs. Un agent qui identifie une faute d'orthographe dans les métadonnées d'un contenu et la corrige est une action plutôt inoffensive. En revanche, si le champ qu'il souhaite modifier détermine si ce contenu peut être diffusé sur un territoire donné, la conséquence est tout autre. De même, un agent peut identifier correctement un problème de configuration de production, mais cela ne signifie pas qu'il doive hériter de droits illimités pour reconfigurer l'ensemble de l'environnement.
Rien de tout cela n'est particulièrement nouveau. Il s'agit de gestion des identités et des accès appliquée à un nouveau type d'acteur, et je soupçonne que cela deviendra l'un des piliers d'une gouvernance efficace de l'IA par agents.
Microsoft traite déjà les agents dans ces termes. Ses recommandations actuelles préconisent une identité d'agent d'IA unique et dédiée, un propriétaire ou un garant désigné, un objectif et des accès aux données clairement documentés, un accès basé sur le principe du moindre privilège, des autorisations d'outils contrôlées, une journalisation des activités et des procédures de révocation testées. Les travaux du NIST dans ce même domaine examinent explicitement l'identification, l'autorisation, l'audit et la non-répudiation pour les agents d'IA.
En pratique, cela signifie que les autorisations des agents d'IA doivent être traitées avec le même sérieux que les comptes d'administration humains ou de services privilégiés. Un agent peut être parfaitement capable de déterminer ce qui doit se passer sans pour autant être autorisé à le mettre en œuvre.
Cette distinction est essentielle. Les contrôles des agents d'IA ne peuvent pas simplement se limiter à vérifier si un modèle est techniquement capable d'effectuer une action. Ils doivent déterminer si cet agent précis, agissant dans ce contexte précis, est autorisé à l'exécuter.
Par ailleurs, je crains que la prolifération des agents d'IA ne devienne l'un de ces problèmes dont les entreprises n'ont pas conscience jusqu'à ce que quelqu'un demande enfin : « Combien d'agents avons-nous réellement ? » Nous avons déjà connu des situations similaires avec les applications SaaS, les ressources cloud, les comptes de service et les clés d'API. Il n'y a aucune raison évidente pour que le parc d'agents s'organise mieux de lui-même, en particulier dans les entreprises où l'expérimentation est délibérément décentralisée au sein des équipes.
Cela ne signifie pas pour autant qu'il faille centraliser toutes les initiatives d'IA. Une équipe centrale a peu de chances de comprendre suffisamment bien chaque processus pour identifier elle-même toutes les applications utiles. Une innovation décentralisée peut être tout à fait judicieuse.
Une autorité déléguée par accident est en revanche une tout autre histoire.
L'IA par agents hérite de chaque faille de votre parc informatique
Il y a un autre sujet délicat sous-jacent. Votre agent va hériter de votre parc informatique existant.
Les API rutilantes, les systèmes hérités, les dossiers clients incohérents, l'intégration que quelqu'un a codée il y a huit ans et à laquelle personne ne veut toucher, et la plateforme qui nomme un client d'une certaine façon alors qu'une autre l'appelle autrement. Une entreprise grandit, des plateformes sont achetées, les équipes résolvent des problèmes individuels, des acquisitions ont lieu, les fournisseurs changent et les priorités évoluent. Finalement, vous vous retrouvez avec ce que tout le monde qualifie poliment d'architecture actuelle.
Imaginez maintenant un agent traitant le cas d'un client qui a payé pour un service mais ne peut pas y accéder. La réponse peut nécessiter des informations provenant du CRM, de la facturation, de l'authentification, des droits d'accès et des systèmes de support avant que quiconque puisse déterminer ce qui s'est réellement passé.
Un conseiller humain gérera souvent ces incohérences presque sans y penser. Il sait qu'un système se met à jour avant un autre. Il remarque que les identifiants sont légèrement différents. Peut-être se souvient-il que les clients disposant d'une ancienne offre se comportent différemment, ou demande-t-il simplement à son collègue d'à côté parce que la documentation n'a pas été mise à jour depuis 2023.
Confiez cette tâche à un agent, et ces hypothèses devront être formalisées quelque part. Quel système fait foi ? Que se passe-t-il si la facturation indique que le paiement a réussi mais que la plateforme de gestion des droits indique que le compte est inactif ? L'information est-elle erronée ou s'agit-il d'une règle de gestion que l'agent ne comprend pas ? Une plateforme a-t-elle simplement cinq minutes de retard ?
Ce sont de vieux problèmes de données et d'architecture, mais avec un nouvel utilisateur. La différence majeure est que cet utilisateur peut désormais agir en fonction de la conclusion à laquelle il parvient.
De mauvaises données fournies à un chatbot peuvent générer une mauvaise réponse. De mauvaises données fournies à un logiciel autonome peuvent générer un mauvais résultat.
Il existe également une autre complication. Les informations ne sont pas nécessairement erronées par accident. Des recherches publiées en juillet ont mis en évidence des attaques par injection de données d'agent, dans lesquelles des informations contrôlées par un attaquant pouvaient être présentées comme des données contextuelles apparemment légitimes et influencer ce qu'un agent faisait par la suite. Les chercheurs ont identifié des vulnérabilités dans de réels agents web et de codage, susceptibles d'entraîner des clics involontaires, l'exécution de code à distance et des actions malveillantes sur la chaîne d'approvisionnement logicielle.
Cela crée un croisement délicat entre architecture des données et sécurité. Si l'information peut influencer l'action, l'origine de cette information, sa fiabilité et le poids que l'agent doit lui accorder ne sont plus des questions de gouvernance abstraites. Ils font partie intégrante du modèle d'exécution.
C'est aussi pourquoi je me méfierais de l'idée selon laquelle les agents rendraient d'une certaine manière la dette technique moins importante. Un agent peut faciliter la navigation dans des environnements fragmentés parce qu'il peut raisonner sur une tâche plutôt que de s'appuyer entièrement sur un parcours d'intégration fixe, mais il a toujours besoin d'accéder aux systèmes, d'interfaces exploitables, de données cohérentes, d'autorisations appropriées et d'une idée de ce qu'il doit faire en cas d'échec en cours de route.
Si l'API n'existe pas, l'agent a besoin d'un autre moyen d'accès. Si le même client possède six identifiants, quelqu'un ou quelque chose doit encore établir s'ils représentent la même personne. Si une règle de gestion non documentée influe sur la décision, cette connaissance doit être accessible quelque part.
Placer une couche d'orchestration intelligente devant un parc informatique désordonné n'efface pas le désordre. Cela peut rendre le désordre plus facile à appréhender. Mais cela peut aussi permettre aux conséquences de ce désordre de se propager considérablement plus vite.
La supervision humaine a un coût économique
À ce stade de la réflexion, on entend souvent dire qu'il y aura toujours un humain dans la boucle.
C'est rassurant, mais cela soulève une question évidente : si quelqu'un doit encore examiner et approuver tout ce que fait l'agent, qu'avons-nous réellement automatisé ?
Imaginez que notre agent de service client ait consulté cinq systèmes, identifié un problème de compte, établi que le client a été facturé à tort et calculé qu'un remboursement de 20 € est approprié. Il place ensuite le dossier dans une file d'attente pour qu'un humain clique sur « Approuver ».
Le gain peut rester appréciable car l'analyse a été automatisée, mais si vous appliquez ce processus à des dizaines de milliers de transactions, vous conservez une opération manuelle considérable. Le goulot d'étranglement s'est déplacé plutôt que de disparaître.
C'est là que les discours prudents autour de l'IA par agents entrent en conflit avec la réalité économique de l'automatisation. Nous introduisons l'autonomie parce que nous voulons qu'un logiciel allège un processus, puis cette autonomie nous inquiète au point de réintroduire un humain dans chaque transaction.
Au bout du compte, cela va à l'encontre du but recherché.
Le défi de la supervision des agents d'IA réside donc dans le fait qu'une surveillance accrue n'est pas systématiquement préférable. Chaque étape d'approbation peut réduire un risque particulier, mais elle réintroduit également du coût, des délais et des interventions manuelles dans le processus. La vraie question est de savoir où le jugement humain apporte une réelle valeur ajoutée.
Si le remboursement est de 20 €, que les règles sont claires, que tous les systèmes concernés concordent et que l'action est facilement réversible, l'approbation humaine n'est peut-être pas nécessaire. Si le montant est de 20 000 €, que deux systèmes se contredisent ou que la situation sort des paramètres normaux, c'est le moment idéal pour faire intervenir un collaborateur.
Pour de nombreux processus, l'idéal n'est donc probablement pas d'avoir l'humain systématiquement dans la boucle, mais l'humain par exception. Les tâches routinières et bien comprises deviennent de plus en plus autonomes, tandis que les cas inhabituels, ambigus ou à fort enjeu sont remontés.
Cela laisse une grande marge de manœuvre pour introduire l'autonomie de manière progressive. Un agent peut commencer par observer et recommander. Une fois son comportement maîtrisé, il peut préparer des actions pour approbation. À terme, certaines catégories d'actions routinières et réversibles peuvent être exécutées automatiquement, les humains n'intervenant que lorsque le processus franchit un seuil convenu.
Les recommandations d'OpenAI adoptent une approche similaire basée sur le risque. Elles préconisent une intervention humaine lorsque les agents dépassent des seuils d'erreur définis et pour les actions sensibles, irréversibles ou à enjeux élevés, telles que les remboursements ou les paiements importants.
PocketOS est parvenu à cette même conclusion par un chemin beaucoup moins théorique. Suite à son incident de base de données, les opérations destructrices nécessitent désormais une confirmation humaine explicite. L'entreprise n'a pas pour autant renoncé aux agents autonomes. Elle indique continuer à faire tourner plusieurs agents autonomes spécialisés en production, tout en modifiant l'emplacement de la frontière de contrôle.
C'est, selon moi, la manière la plus pertinente d'envisager la supervision humaine. C'est un contrôle qui doit s'appliquer là où les conséquences le justifient, et non pas nécessairement un modèle opérationnel permanent pour chaque action effectuée par un logiciel autonome.
Le but de l'automatisation reste, après tout, d'automatiser. Le problème de conception consiste à décider où les humains améliorent véritablement le résultat et où ils sont simplement maintenus parce que nous ne faisons pas encore assez confiance au système pour les retirer.
L'autonomie sans traçabilité est indéfendable sur le plan opérationnel
Si nous évoluons vers un modèle d'humain par exception, un autre aspect devient d'autant plus crucial : comprendre ce que l'agent a réellement fait.
L'enquête sur Hugging Face en est un exemple extrême mais parlant. Sa reconstruction médico-légale a couvert environ 17 600 actions à travers des milliers de clusters, les enquêteurs reconstituant la manière dont l'agent s'est déplacé dans les systèmes et a adapté son comportement au fil du temps.
Ramenez cela à un processus d'entreprise classique. Un client affirme qu'une modification a été effectuée à tort sur son compte et vous découvrez qu'un agent en est à l'origine.
Dire « C'est l'IA qui l'a fait » ne vous mènera pas bien loin lors de la revue d'incident.
Vous voudrez savoir quel agent a agi, qui a initié la tâche, quelles informations il a utilisées, ce que ces informations contenaient à ce moment-là, quels outils il a appelés et quelle autorisation a finalement permis la modification. Si un autre agent est intervenu en cours de route, cela a probablement aussi son importance.
C'est là que l'auditabilité des agents d'IA cesse d'être une simple bonne pratique de gouvernance pour devenir une exigence opérationnelle. Moins l'intervention humaine est directe dans l'exécution, plus l'observabilité globale doit être renforcée.
Les recommandations actuelles de Microsoft préconisent de consigner l'identité de l'agent, son rôle et son champ d'action réel, l'action effectuée, la ressource concernée et l'identité de l'utilisateur pour le compte duquel il agissait. De même, le NIST examine explicitement l'audit et la non-répudiation dans le cadre du problème d'identité et d'autorisation des agents.
Cela ne signifie pas que chaque action autonome doive être surveillée par un humain. Nous exploitons déjà d'immenses environnements automatisés sans placer une personne derrière chaque transaction, événement d'infrastructure ou requête réseau. Nous définissons des limites, des contrôles et des alertes, puis nous enquêtons sur ce qui en sort.
Il n'y a pas de raison évidente pour que des systèmes d'agents matures fonctionnent différemment.
L'autonomie ne supprime pas la supervision. Elle modifie le moment où elle s'exerce.
L'intention déléguée complexifie la frontière de confiance
Il y a une autre évolution qui mérite attention, car elle rend ce problème encore plus intéressant.
Les agents sont de plus en plus conçus pour communiquer et collaborer avec d'autres agents. Le protocole Agent2Agent de Google normalise la façon dont les agents peuvent se découvrir et communiquer entre eux, y compris ceux conçus par des équipes différentes ou sur des environnements techniques distincts. Ses récents travaux sur l'Agentic Resource Discovery traitent de la question connexe de savoir comment les agents peuvent trouver et valider des outils, des compétences et d'autres agents répartis entre différentes équipes, organisations et plateformes.
Imaginez qu'un agent interne reçoive une tâche et détermine qu'un autre agent spécialisé peut en réaliser une partie. Ce second agent utilise un outil qui appelle l'un de vos services et finit par modifier quelque chose.
Qui agit ici ?
Le second agent ? Le premier agent ? La personne qui a initié la tâche d'origine ?
Si le premier agent est autorisé à effectuer une action, peut-il déléguer cette autorité ? Le second agent en reçoit-il la totalité, une partie ou rien du tout ? Que se passe-t-il si les agents appartiennent à des organisations différentes ?
Ce sont des questions émergentes et il serait prématuré de prétendre que le secteur a déjà tranché sur toutes les réponses. L'initiative sur les normes des agents d'IA du NIST (AI Agent Standards Initiative) mène des travaux spécifiques autour de l'authentification des agents et des infrastructures d'identité pour sécuriser les interactions homme-agent et multi-agents.
Mais la direction prise est claire. Historiquement, la confiance a souvent été associée à un utilisateur, une application ou une intégration connue. Dès lors que des agents peuvent découvrir dynamiquement des capacités et déléguer des parties d'un objectif ailleurs, la confiance et l'autorité doivent pouvoir être garanties tout au long de ce parcours.
La tâche peut être dynamique. La responsabilité, elle, ne peut pas s'évanouir à chaque fois qu'elle franchit une nouvelle frontière.
La transformation par agents devrait commencer par la délégation, pas par la technologie
Il existe un schéma classique lors des ruptures technologiques majeures que la plupart des professionnels de la transformation reconnaîtront. Un sujet devient stratégique, la direction décide que l'organisation doit s'en emparer, et chacun commence à chercher où l'appliquer.
Nous avons besoin d'une stratégie d'IA. Il nous faut des cas d'usage d'agents. Nous devrions organiser un atelier. Quels processus pouvons-nous confier à des agents ?
J'aborderais plutôt le problème dans l'autre sens.
Commencez par le processus qui agace tout le monde. Celui qui est lent, coûteux, fragmenté ou qui repose sur un collaborateur passant sa journée à transférer des données d'un système à un autre. Comprenez où sont prises les décisions, sur quelles informations elles s'appuient, quels systèmes sont impliqués, à quel moment surviennent les exceptions complexes et ce qui se passe en cas de problème.
Ensuite, analysez ce que font réellement les collaborateurs dans ce processus. Exercent-ils un jugement à forte valeur ajoutée, ou compensent-ils les limites des technologies qui les entourent ? Approuvent-ils une action en raison d'un réel risque financier ou opérationnel, ou simplement parce que le flux de travail est incapable de distinguer un cas de routine d'un cas inhabituel ? Réconcilient-ils manuellement les informations parce que l'organisation a réellement besoin de leur expertise, ou parce que deux systèmes utilisent des identifiants différents ?
Ce sont des problèmes bien distincts.
Une fois cela compris, décidez de ce que vous êtes prêt à déléguer. Quelles décisions le logiciel peut-il prendre ? Quelles actions peut-il mener ? Lesquelles sont réversibles ? Quand devez-vous prévoir une escalade ? De quelle autorité a-t-il besoin ? De quelles preuves auriez-vous besoin a posteriori si quelqu'un vous demandait les raisons d'une décision ?
C'est seulement à ce moment-là que le choix technologique devient véritablement intéressant.
Un agent peut être une excellente solution. Ou pas. Et c'est très bien ainsi. Les guides actuels sur la conception des agents font la même distinction : les agents sont particulièrement adaptés aux flux de travail où l'ambiguïté, les décisions complexes ou les données non structurées mettent en difficulté les approches déterministes. En revanche, lorsque ces caractéristiques sont absentes, l'automatisation conventionnelle peut rester tout à fait suffisante.
L'objectif n'est pas de déployer des agents. Il est d'améliorer l'entreprise.
L'architecture de l'automatisation devient l'architecture de l'autorité
Ces vingt dernières années, la transformation numérique a consisté en grande partie à connecter les personnes aux systèmes, et les systèmes entre eux. Nous commençons aujourd'hui à introduire un nouvel acteur dans ce parc informatique : un logiciel capable de recevoir un objectif, de déterminer comment l'atteindre et d'utiliser ces systèmes en notre nom.
Cela ouvre des perspectives réellement intéressantes, notamment pour les tâches de coordination qui résistaient jusqu'ici à l'automatisation classique. Le NIST lui-même décrit le potentiel des agents pour améliorer la productivité, l'efficacité et la prise de décision, tout en soulignant la nécessité de contrôles d'identification et d'autorisation appropriés lorsque ces agents accèdent aux données, outils et applications de l'organisation.
Je pense que cette double dimension est essentielle. L'opportunité et le risque proviennent de la même caractéristique : l'agent dispose d'une certaine liberté pour décider de la manière dont le travail est effectué.
Dès lors, l'architecture ne se limite plus à vérifier si un système peut se connecter à un autre. Elle détermine de plus en plus quel acteur autonome peut utiliser quelle information, exercer quelle capacité, sous quelle autorité, avec quelles limites et en laissant quelles traces.
En pratique, la gouvernance des agents d'IA en entreprise ne sera donc probablement pas résolue par un énième document de politique générale publié sur l'intranet. Elle doit se traduire concrètement dans les identités que nous créons, les droits que nous accordons, les contrôles autour des actions critiques, la qualité et la provenance des données que les agents exploitent, les circuits d'escalade que nous concevons et les preuves d'audit que nous conservons ensuite.
Hugging Face nous montre un cas extrême de logiciel autonome trouvant un chemin inattendu par ses concepteurs. PocketOS illustre de façon plus quotidienne ce qui se produit lorsqu'un agent dispose simplement de plus d'autorité que sa tâche ne l'exige. Les travaux émergents autour de l'identité des agents, du moindre privilège, de l'interaction multi-agents sécurisée et de la découverte de ressources de confiance montrent que le modèle de contrôle doit déjà s'adapter aux capacités technologiques.
Rien de tout cela n'est un argument contre l'IA par agents. Bien au contraire. Si les agents peuvent éliminer une partie de la coordination humaine qui rend les entreprises numériques modernes coûteuses et lourdes à gérer, il y a une raison très concrète de s'y intéresser.
Mais introduire des acteurs autonomes dans un écosystème numérique existant n'est pas un simple projet d'IA de plus. Cela bouscule les principes d'identité, de confiance, de données, de responsabilité et, en fin de compte, d'autorité.
Ainsi, avant de vous demander ce qu'un agent peut faire, je commencerais par poser une autre question.
Qu'êtes-vous réellement prêt à le laisser faire ?
Quand l'IA prend le pouvoir
Ces dernières années, les entreprises se sont concentrées sur ce que l'IA générative peut nous apporter. Les agents d'IA introduisent une question bien plus lourde de conséquences : que se passe-t-il lorsque le logiciel peut décider de la prochaine action à mener, puis l'exécuter lui-même ?
En juillet 2026, un agent d'IA utilisé dans le cadre d'une évaluation de la cybersécurité d'OpenAI a compromis une partie de l'infrastructure de production de Hugging Face. Il convient de replacer les choses dans leur contexte avant de s'emballer. Il ne s'agissait pas d'une application d'entreprise classique décidant soudainement d'attaquer une autre société. OpenAI testait délibérément des modèles hautement performants sur des tâches de cybersécurité complexes, et les classificateurs de production normalement utilisés pour empêcher les modèles de poursuivre des activités informatiques à haut risque avaient été intentionnellement désactivés pour cette évaluation.
Malgré cela, ce qui s'est passé mérite qu'on s'y attarde. Selon les enquêtes qui ont suivi, l'agent semble avoir conclu que les informations détenues par Hugging Face pouvaient l'aider à atteindre l'objectif d'évaluation qui lui avait été fixé. Il a trouvé une faille grâce à une vulnérabilité de type zero-day dans l'infrastructure utilisée par l'environnement d'évaluation, a obtenu un accès plus large à Internet, a enchaîné d'autres vecteurs d'attaque, a récupéré des identifiants et a finalement atteint les systèmes de Hugging Face. L'analyse médico-légale de Hugging Face a recensé environ 17 600 actions individuelles, regroupées en quelque 6 280 clusters.
La tentation, naturellement, est de titrer sur « l'évasion de l'IA » ou « l'IA devenue incontrôlable ». Je ne pense pas que l'une ou l'autre de ces formulations soit particulièrement pertinente. Autant que les enquêtes ont pu l'établir, le logiciel tentait d'atteindre l'objectif qui lui avait été assigné et a trouvé un chemin que personne n'avait anticipé. Hugging Face estime que l'agent essayait en réalité de tricher lors de l'évaluation en accédant aux systèmes de production, où il pensait pouvoir trouver des informations sur le benchmark ou les solutions.
C'est tout de suite beaucoup moins théâtral, mais du point de vue de la transformation numérique, c'est probablement bien plus important.
Ces dernières années, la plupart des organisations ont appréhendé l'IA générative comme un outil auquel on pose des questions. On lui fournit des informations, on lui pose une question et on obtient un résultat. Elle peut résumer un contrat, analyser des données, écrire du code ou rédiger un e-mail, mais il y a généralement toujours un être humain de l'autre côté qui décide de la suite des événements.
Les agents commencent à brouiller cette frontière. Donnez à cette même intelligence un accès à des outils et elle pourra récupérer des informations, appeler une API, mettre à jour un enregistrement, exécuter du code, envoyer l'e-mail ou effectuer la modification elle-même. OpenAI décrit les agents de manière très similaire : des systèmes capables de gérer de façon indépendante l'exécution de flux de travail, de prendre des décisions, de sélectionner les outils appropriés et d'interagir avec des systèmes externes au nom d'un utilisateur.
Le chatbot vient d'obtenir un accès en écriture.
C'est ce virage qui fait de la gouvernance des agents d'IA une préoccupation concrète pour l'entreprise, plutôt qu'un simple débat de principe de plus. Dès lors que le logiciel peut agir au lieu de se contenter de faire des recommandations, les questions d'identité, de droits d'accès, de contrôles, d'auditabilité et de responsabilité s'invitent au cœur même de l'architecture.
L'automatisation change lorsque l'on donne au logiciel une intention, et non des instructions
Les logiciels transforment notre quotidien depuis des décennies, il ne faudrait donc pas surestimer la nouveauté de la situation. Nous n'avons pas besoin de l'IA pour mettre à jour une base de données, déclencher une API ou exécuter un flux de travail. Les scripts, les moteurs de règles, les plateformes d'orchestration et les processus automatisés s'en chargent parfaitement depuis des années.
La différence réside dans la manière de passer de l'objectif à l'action. L'automatisation traditionnelle est normalement conçue autour d'un parcours défini à l'avance. Quand X se produit, récupérer Y. Si la réponse est Z, effectuer telle action. Même si cela implique des centaines de règles, d'embranchements et d'exceptions, le processus a toujours été modélisé au préalable par un humain.
Les agents nous permettent potentiellement d'aller plus loin en fixant un résultat au logiciel plutôt qu'en lui fournissant chaque instruction nécessaire pour y parvenir. Le problème est posé de la sorte : déterminez de quelles informations vous avez besoin. Décidez des outils appropriés. Gérez les retours d'information et menez à bien la tâche.
Cette distinction est cruciale car le chemin d'exécution peut devenir dynamique. Un agent peut commencer par interroger un système, découvrir qu'il a besoin d'un contexte supplémentaire, appeler un autre service, se heurter à un résultat inattendu, revoir son approche et poursuivre sa tâche. Les architectures d'agents actuelles sont explicitement conçues autour de cette capacité à gérer un flux de travail, à choisir des outils et à prendre des mesures en fonction de l'avancement de la tâche.
Il s'agit d'une proposition fondamentalement différente de l'automatisation classique. Le logiciel ne se contente plus d'exécuter un flux prédéterminé. Dans les limites que nous lui fixons, nous lui laissons une certaine marge d'appréciation sur la manière dont ce flux se déroule.
Et c'est là que le sujet devient bien plus intéressant qu'une simple discussion sur la capacité de l'IA à rédiger un meilleur e-mail.
L'opportunité réside dans la suppression de la coordination, pas des personnes
Au sein d'une organisation, une quantité surprenante de travail n'est pas difficile parce qu'une tâche individuelle est particulièrement complexe, mais en raison de la coordination requise entre ces tâches.
Ouvrir le CRM. Trouver le client. Copier un identifiant dans la plateforme de facturation. Lire les notes. Consulter un autre système. Comprendre leur signification. Demander à une autre équipe si une situation est normale. Attendre la réponse. Mettre à jour la première plateforme et envoyer un e-mail au client.
Cela vous rappelle quelque chose ?
Nous avons passé des années à essayer d'automatiser ces processus, et les technologies de gestion des flux de travail classiques sont extrêmement efficaces lorsque les étapes peuvent être décrites de manière prévisible. Les difficultés résident généralement dans les exceptions : un document mal structuré, un compte qui ne correspond pas tout à fait, trois systèmes en contradiction, ou le moment du processus où un collaborateur doit lire et comprendre une information avant de savoir ce qu'il doit faire ensuite.
C'est précisément dans ce genre de flux de travail que les agents s'avèrent potentiellement utiles. Les recommandations actuelles d'OpenAI identifient spécifiquement la prise de décision complexe, les règles difficiles à maintenir et la forte dépendance à l'égard d'informations non structurées comme des domaines où une approche par agents peut apporter une valeur ajoutée que l'automatisation déterministe classique n'offre pas. Elles soulignent également, à juste titre, qu'en l'absence de ces caractéristiques, une solution déterministe reste souvent la meilleure option.
Si un logiciel peut prendre en charge une partie de la coordination entre les systèmes, les informations et les décisions, le gain d'efficacité potentiel est significatif. Non pas parce que tous les acteurs du processus disparaissent soudainement, mais parce que nous pouvons cesser d'utiliser des humains comme de coûteux intermédiaires entre des plateformes qui n'ont jamais été très douées pour communiquer entre elles.
La nuance est de taille. L'objectif ne doit pas nécessairement être de supprimer les collaborateurs de l'organisation. Il doit être de supprimer les tâches que nous leur imposons aujourd'hui simplement parce que la technologie sous-jacente ne gère pas bien le contexte, l'ambiguïté ou les exceptions.
C'est pourquoi je pense que l'opportunité offerte par les agents dépasse de loin un simple gain de productivité marginal. Rédiger la réponse à un client dix secondes plus vite est certes utile. Permettre à un logiciel d'analyser le problème, de rapprocher les informations pertinentes et de faire progresser le processus est d'un tout autre ordre.
Bien sûr, plus le logiciel fait progresser le processus, plus il se rapproche d'une action lourde de conséquences.
Et c'est là que les choses se compliquent nettement.
La capacité n'est pas l'autorité
Quelques mois avant l'incident de Hugging Face, PocketOS a publié un compte rendu sans fard d'un agent d'IA ayant supprimé la base de données de production de l'entreprise. La suppression a pris neuf secondes. La restauration a nécessité soixante heures. Les sauvegardes existaient, mais dataient de trois mois car le processus de sauvegarde s'était arrêté en silence.
PocketOS précise également de manière très claire qu'il ne s'agissait pas d'un simple « problème d'IA ». L'entreprise indique que l'agent a agi avec assurance en utilisant des droits d'accès qu'il n'aurait jamais dû posséder, sur un environnement qui ne présentait pas de barrières suffisantes contre une action destructrice.
C'est là une leçon précieuse.
Les humains suppriment des bases de données de production depuis des années, et les bugs logiciels y ont également largement contribué. L'élément notable ici est que l'acteur disposait d'une autorité suffisante pour que son erreur ait un impact réel.
Nous comprenons déjà ce principe lorsqu'il s'agit d'un humain. Un conseiller du service client peut être autorisé à accorder un remboursement de 20 € sans que personne ne s'en soucie. Un montant de 200 € peut encore sembler tout à fait raisonnable. Un remboursement de 20 000 € ouvre probablement un tout autre débat.
Le même principe s'applique ailleurs. Un agent qui identifie une faute d'orthographe dans les métadonnées d'un contenu et la corrige est une action plutôt inoffensive. En revanche, si le champ qu'il souhaite modifier détermine si ce contenu peut être diffusé sur un territoire donné, la conséquence est tout autre. De même, un agent peut identifier correctement un problème de configuration de production, mais cela ne signifie pas qu'il doive hériter de droits illimités pour reconfigurer l'ensemble de l'environnement.
Rien de tout cela n'est particulièrement nouveau. Il s'agit de gestion des identités et des accès appliquée à un nouveau type d'acteur, et je soupçonne que cela deviendra l'un des piliers d'une gouvernance efficace de l'IA par agents.
Microsoft traite déjà les agents dans ces termes. Ses recommandations actuelles préconisent une identité d'agent d'IA unique et dédiée, un propriétaire ou un garant désigné, un objectif et des accès aux données clairement documentés, un accès basé sur le principe du moindre privilège, des autorisations d'outils contrôlées, une journalisation des activités et des procédures de révocation testées. Les travaux du NIST dans ce même domaine examinent explicitement l'identification, l'autorisation, l'audit et la non-répudiation pour les agents d'IA.
En pratique, cela signifie que les autorisations des agents d'IA doivent être traitées avec le même sérieux que les comptes d'administration humains ou de services privilégiés. Un agent peut être parfaitement capable de déterminer ce qui doit se passer sans pour autant être autorisé à le mettre en œuvre.
Cette distinction est essentielle. Les contrôles des agents d'IA ne peuvent pas simplement se limiter à vérifier si un modèle est techniquement capable d'effectuer une action. Ils doivent déterminer si cet agent précis, agissant dans ce contexte précis, est autorisé à l'exécuter.
Par ailleurs, je crains que la prolifération des agents d'IA ne devienne l'un de ces problèmes dont les entreprises n'ont pas conscience jusqu'à ce que quelqu'un demande enfin : « Combien d'agents avons-nous réellement ? » Nous avons déjà connu des situations similaires avec les applications SaaS, les ressources cloud, les comptes de service et les clés d'API. Il n'y a aucune raison évidente pour que le parc d'agents s'organise mieux de lui-même, en particulier dans les entreprises où l'expérimentation est délibérément décentralisée au sein des équipes.
Cela ne signifie pas pour autant qu'il faille centraliser toutes les initiatives d'IA. Une équipe centrale a peu de chances de comprendre suffisamment bien chaque processus pour identifier elle-même toutes les applications utiles. Une innovation décentralisée peut être tout à fait judicieuse.
Une autorité déléguée par accident est en revanche une tout autre histoire.
L'IA par agents hérite de chaque faille de votre parc informatique
Il y a un autre sujet délicat sous-jacent. Votre agent va hériter de votre parc informatique existant.
Les API rutilantes, les systèmes hérités, les dossiers clients incohérents, l'intégration que quelqu'un a codée il y a huit ans et à laquelle personne ne veut toucher, et la plateforme qui nomme un client d'une certaine façon alors qu'une autre l'appelle autrement. Une entreprise grandit, des plateformes sont achetées, les équipes résolvent des problèmes individuels, des acquisitions ont lieu, les fournisseurs changent et les priorités évoluent. Finalement, vous vous retrouvez avec ce que tout le monde qualifie poliment d'architecture actuelle.
Imaginez maintenant un agent traitant le cas d'un client qui a payé pour un service mais ne peut pas y accéder. La réponse peut nécessiter des informations provenant du CRM, de la facturation, de l'authentification, des droits d'accès et des systèmes de support avant que quiconque puisse déterminer ce qui s'est réellement passé.
Un conseiller humain gérera souvent ces incohérences presque sans y penser. Il sait qu'un système se met à jour avant un autre. Il remarque que les identifiants sont légèrement différents. Peut-être se souvient-il que les clients disposant d'une ancienne offre se comportent différemment, ou demande-t-il simplement à son collègue d'à côté parce que la documentation n'a pas été mise à jour depuis 2023.
Confiez cette tâche à un agent, et ces hypothèses devront être formalisées quelque part. Quel système fait foi ? Que se passe-t-il si la facturation indique que le paiement a réussi mais que la plateforme de gestion des droits indique que le compte est inactif ? L'information est-elle erronée ou s'agit-il d'une règle de gestion que l'agent ne comprend pas ? Une plateforme a-t-elle simplement cinq minutes de retard ?
Ce sont de vieux problèmes de données et d'architecture, mais avec un nouvel utilisateur. La différence majeure est que cet utilisateur peut désormais agir en fonction de la conclusion à laquelle il parvient.
De mauvaises données fournies à un chatbot peuvent générer une mauvaise réponse. De mauvaises données fournies à un logiciel autonome peuvent générer un mauvais résultat.
Il existe également une autre complication. Les informations ne sont pas nécessairement erronées par accident. Des recherches publiées en juillet ont mis en évidence des attaques par injection de données d'agent, dans lesquelles des informations contrôlées par un attaquant pouvaient être présentées comme des données contextuelles apparemment légitimes et influencer ce qu'un agent faisait par la suite. Les chercheurs ont identifié des vulnérabilités dans de réels agents web et de codage, susceptibles d'entraîner des clics involontaires, l'exécution de code à distance et des actions malveillantes sur la chaîne d'approvisionnement logicielle.
Cela crée un croisement délicat entre architecture des données et sécurité. Si l'information peut influencer l'action, l'origine de cette information, sa fiabilité et le poids que l'agent doit lui accorder ne sont plus des questions de gouvernance abstraites. Ils font partie intégrante du modèle d'exécution.
C'est aussi pourquoi je me méfierais de l'idée selon laquelle les agents rendraient d'une certaine manière la dette technique moins importante. Un agent peut faciliter la navigation dans des environnements fragmentés parce qu'il peut raisonner sur une tâche plutôt que de s'appuyer entièrement sur un parcours d'intégration fixe, mais il a toujours besoin d'accéder aux systèmes, d'interfaces exploitables, de données cohérentes, d'autorisations appropriées et d'une idée de ce qu'il doit faire en cas d'échec en cours de route.
Si l'API n'existe pas, l'agent a besoin d'un autre moyen d'accès. Si le même client possède six identifiants, quelqu'un ou quelque chose doit encore établir s'ils représentent la même personne. Si une règle de gestion non documentée influe sur la décision, cette connaissance doit être accessible quelque part.
Placer une couche d'orchestration intelligente devant un parc informatique désordonné n'efface pas le désordre. Cela peut rendre le désordre plus facile à appréhender. Mais cela peut aussi permettre aux conséquences de ce désordre de se propager considérablement plus vite.
La supervision humaine a un coût économique
À ce stade de la réflexion, on entend souvent dire qu'il y aura toujours un humain dans la boucle.
C'est rassurant, mais cela soulève une question évidente : si quelqu'un doit encore examiner et approuver tout ce que fait l'agent, qu'avons-nous réellement automatisé ?
Imaginez que notre agent de service client ait consulté cinq systèmes, identifié un problème de compte, établi que le client a été facturé à tort et calculé qu'un remboursement de 20 € est approprié. Il place ensuite le dossier dans une file d'attente pour qu'un humain clique sur « Approuver ».
Le gain peut rester appréciable car l'analyse a été automatisée, mais si vous appliquez ce processus à des dizaines de milliers de transactions, vous conservez une opération manuelle considérable. Le goulot d'étranglement s'est déplacé plutôt que de disparaître.
C'est là que les discours prudents autour de l'IA par agents entrent en conflit avec la réalité économique de l'automatisation. Nous introduisons l'autonomie parce que nous voulons qu'un logiciel allège un processus, puis cette autonomie nous inquiète au point de réintroduire un humain dans chaque transaction.
Au bout du compte, cela va à l'encontre du but recherché.
Le défi de la supervision des agents d'IA réside donc dans le fait qu'une surveillance accrue n'est pas systématiquement préférable. Chaque étape d'approbation peut réduire un risque particulier, mais elle réintroduit également du coût, des délais et des interventions manuelles dans le processus. La vraie question est de savoir où le jugement humain apporte une réelle valeur ajoutée.
Si le remboursement est de 20 €, que les règles sont claires, que tous les systèmes concernés concordent et que l'action est facilement réversible, l'approbation humaine n'est peut-être pas nécessaire. Si le montant est de 20 000 €, que deux systèmes se contredisent ou que la situation sort des paramètres normaux, c'est le moment idéal pour faire intervenir un collaborateur.
Pour de nombreux processus, l'idéal n'est donc probablement pas d'avoir l'humain systématiquement dans la boucle, mais l'humain par exception. Les tâches routinières et bien comprises deviennent de plus en plus autonomes, tandis que les cas inhabituels, ambigus ou à fort enjeu sont remontés.
Cela laisse une grande marge de manœuvre pour introduire l'autonomie de manière progressive. Un agent peut commencer par observer et recommander. Une fois son comportement maîtrisé, il peut préparer des actions pour approbation. À terme, certaines catégories d'actions routinières et réversibles peuvent être exécutées automatiquement, les humains n'intervenant que lorsque le processus franchit un seuil convenu.
Les recommandations d'OpenAI adoptent une approche similaire basée sur le risque. Elles préconisent une intervention humaine lorsque les agents dépassent des seuils d'erreur définis et pour les actions sensibles, irréversibles ou à enjeux élevés, telles que les remboursements ou les paiements importants.
PocketOS est parvenu à cette même conclusion par un chemin beaucoup moins théorique. Suite à son incident de base de données, les opérations destructrices nécessitent désormais une confirmation humaine explicite. L'entreprise n'a pas pour autant renoncé aux agents autonomes. Elle indique continuer à faire tourner plusieurs agents autonomes spécialisés en production, tout en modifiant l'emplacement de la frontière de contrôle.
C'est, selon moi, la manière la plus pertinente d'envisager la supervision humaine. C'est un contrôle qui doit s'appliquer là où les conséquences le justifient, et non pas nécessairement un modèle opérationnel permanent pour chaque action effectuée par un logiciel autonome.
Le but de l'automatisation reste, après tout, d'automatiser. Le problème de conception consiste à décider où les humains améliorent véritablement le résultat et où ils sont simplement maintenus parce que nous ne faisons pas encore assez confiance au système pour les retirer.
L'autonomie sans traçabilité est indéfendable sur le plan opérationnel
Si nous évoluons vers un modèle d'humain par exception, un autre aspect devient d'autant plus crucial : comprendre ce que l'agent a réellement fait.
L'enquête sur Hugging Face en est un exemple extrême mais parlant. Sa reconstruction médico-légale a couvert environ 17 600 actions à travers des milliers de clusters, les enquêteurs reconstituant la manière dont l'agent s'est déplacé dans les systèmes et a adapté son comportement au fil du temps.
Ramenez cela à un processus d'entreprise classique. Un client affirme qu'une modification a été effectuée à tort sur son compte et vous découvrez qu'un agent en est à l'origine.
Dire « C'est l'IA qui l'a fait » ne vous mènera pas bien loin lors de la revue d'incident.
Vous voudrez savoir quel agent a agi, qui a initié la tâche, quelles informations il a utilisées, ce que ces informations contenaient à ce moment-là, quels outils il a appelés et quelle autorisation a finalement permis la modification. Si un autre agent est intervenu en cours de route, cela a probablement aussi son importance.
C'est là que l'auditabilité des agents d'IA cesse d'être une simple bonne pratique de gouvernance pour devenir une exigence opérationnelle. Moins l'intervention humaine est directe dans l'exécution, plus l'observabilité globale doit être renforcée.
Les recommandations actuelles de Microsoft préconisent de consigner l'identité de l'agent, son rôle et son champ d'action réel, l'action effectuée, la ressource concernée et l'identité de l'utilisateur pour le compte duquel il agissait. De même, le NIST examine explicitement l'audit et la non-répudiation dans le cadre du problème d'identité et d'autorisation des agents.
Cela ne signifie pas que chaque action autonome doive être surveillée par un humain. Nous exploitons déjà d'immenses environnements automatisés sans placer une personne derrière chaque transaction, événement d'infrastructure ou requête réseau. Nous définissons des limites, des contrôles et des alertes, puis nous enquêtons sur ce qui en sort.
Il n'y a pas de raison évidente pour que des systèmes d'agents matures fonctionnent différemment.
L'autonomie ne supprime pas la supervision. Elle modifie le moment où elle s'exerce.
L'intention déléguée complexifie la frontière de confiance
Il y a une autre évolution qui mérite attention, car elle rend ce problème encore plus intéressant.
Les agents sont de plus en plus conçus pour communiquer et collaborer avec d'autres agents. Le protocole Agent2Agent de Google normalise la façon dont les agents peuvent se découvrir et communiquer entre eux, y compris ceux conçus par des équipes différentes ou sur des environnements techniques distincts. Ses récents travaux sur l'Agentic Resource Discovery traitent de la question connexe de savoir comment les agents peuvent trouver et valider des outils, des compétences et d'autres agents répartis entre différentes équipes, organisations et plateformes.
Imaginez qu'un agent interne reçoive une tâche et détermine qu'un autre agent spécialisé peut en réaliser une partie. Ce second agent utilise un outil qui appelle l'un de vos services et finit par modifier quelque chose.
Qui agit ici ?
Le second agent ? Le premier agent ? La personne qui a initié la tâche d'origine ?
Si le premier agent est autorisé à effectuer une action, peut-il déléguer cette autorité ? Le second agent en reçoit-il la totalité, une partie ou rien du tout ? Que se passe-t-il si les agents appartiennent à des organisations différentes ?
Ce sont des questions émergentes et il serait prématuré de prétendre que le secteur a déjà tranché sur toutes les réponses. L'initiative sur les normes des agents d'IA du NIST (AI Agent Standards Initiative) mène des travaux spécifiques autour de l'authentification des agents et des infrastructures d'identité pour sécuriser les interactions homme-agent et multi-agents.
Mais la direction prise est claire. Historiquement, la confiance a souvent été associée à un utilisateur, une application ou une intégration connue. Dès lors que des agents peuvent découvrir dynamiquement des capacités et déléguer des parties d'un objectif ailleurs, la confiance et l'autorité doivent pouvoir être garanties tout au long de ce parcours.
La tâche peut être dynamique. La responsabilité, elle, ne peut pas s'évanouir à chaque fois qu'elle franchit une nouvelle frontière.
La transformation par agents devrait commencer par la délégation, pas par la technologie
Il existe un schéma classique lors des ruptures technologiques majeures que la plupart des professionnels de la transformation reconnaîtront. Un sujet devient stratégique, la direction décide que l'organisation doit s'en emparer, et chacun commence à chercher où l'appliquer.
Nous avons besoin d'une stratégie d'IA. Il nous faut des cas d'usage d'agents. Nous devrions organiser un atelier. Quels processus pouvons-nous confier à des agents ?
J'aborderais plutôt le problème dans l'autre sens.
Commencez par le processus qui agace tout le monde. Celui qui est lent, coûteux, fragmenté ou qui repose sur un collaborateur passant sa journée à transférer des données d'un système à un autre. Comprenez où sont prises les décisions, sur quelles informations elles s'appuient, quels systèmes sont impliqués, à quel moment surviennent les exceptions complexes et ce qui se passe en cas de problème.
Ensuite, analysez ce que font réellement les collaborateurs dans ce processus. Exercent-ils un jugement à forte valeur ajoutée, ou compensent-ils les limites des technologies qui les entourent ? Approuvent-ils une action en raison d'un réel risque financier ou opérationnel, ou simplement parce que le flux de travail est incapable de distinguer un cas de routine d'un cas inhabituel ? Réconcilient-ils manuellement les informations parce que l'organisation a réellement besoin de leur expertise, ou parce que deux systèmes utilisent des identifiants différents ?
Ce sont des problèmes bien distincts.
Une fois cela compris, décidez de ce que vous êtes prêt à déléguer. Quelles décisions le logiciel peut-il prendre ? Quelles actions peut-il mener ? Lesquelles sont réversibles ? Quand devez-vous prévoir une escalade ? De quelle autorité a-t-il besoin ? De quelles preuves auriez-vous besoin a posteriori si quelqu'un vous demandait les raisons d'une décision ?
C'est seulement à ce moment-là que le choix technologique devient véritablement intéressant.
Un agent peut être une excellente solution. Ou pas. Et c'est très bien ainsi. Les guides actuels sur la conception des agents font la même distinction : les agents sont particulièrement adaptés aux flux de travail où l'ambiguïté, les décisions complexes ou les données non structurées mettent en difficulté les approches déterministes. En revanche, lorsque ces caractéristiques sont absentes, l'automatisation conventionnelle peut rester tout à fait suffisante.
L'objectif n'est pas de déployer des agents. Il est d'améliorer l'entreprise.
L'architecture de l'automatisation devient l'architecture de l'autorité
Ces vingt dernières années, la transformation numérique a consisté en grande partie à connecter les personnes aux systèmes, et les systèmes entre eux. Nous commençons aujourd'hui à introduire un nouvel acteur dans ce parc informatique : un logiciel capable de recevoir un objectif, de déterminer comment l'atteindre et d'utiliser ces systèmes en notre nom.
Cela ouvre des perspectives réellement intéressantes, notamment pour les tâches de coordination qui résistaient jusqu'ici à l'automatisation classique. Le NIST lui-même décrit le potentiel des agents pour améliorer la productivité, l'efficacité et la prise de décision, tout en soulignant la nécessité de contrôles d'identification et d'autorisation appropriés lorsque ces agents accèdent aux données, outils et applications de l'organisation.
Je pense que cette double dimension est essentielle. L'opportunité et le risque proviennent de la même caractéristique : l'agent dispose d'une certaine liberté pour décider de la manière dont le travail est effectué.
Dès lors, l'architecture ne se limite plus à vérifier si un système peut se connecter à un autre. Elle détermine de plus en plus quel acteur autonome peut utiliser quelle information, exercer quelle capacité, sous quelle autorité, avec quelles limites et en laissant quelles traces.
En pratique, la gouvernance des agents d'IA en entreprise ne sera donc probablement pas résolue par un énième document de politique générale publié sur l'intranet. Elle doit se traduire concrètement dans les identités que nous créons, les droits que nous accordons, les contrôles autour des actions critiques, la qualité et la provenance des données que les agents exploitent, les circuits d'escalade que nous concevons et les preuves d'audit que nous conservons ensuite.
Hugging Face nous montre un cas extrême de logiciel autonome trouvant un chemin inattendu par ses concepteurs. PocketOS illustre de façon plus quotidienne ce qui se produit lorsqu'un agent dispose simplement de plus d'autorité que sa tâche ne l'exige. Les travaux émergents autour de l'identité des agents, du moindre privilège, de l'interaction multi-agents sécurisée et de la découverte de ressources de confiance montrent que le modèle de contrôle doit déjà s'adapter aux capacités technologiques.
Rien de tout cela n'est un argument contre l'IA par agents. Bien au contraire. Si les agents peuvent éliminer une partie de la coordination humaine qui rend les entreprises numériques modernes coûteuses et lourdes à gérer, il y a une raison très concrète de s'y intéresser.
Mais introduire des acteurs autonomes dans un écosystème numérique existant n'est pas un simple projet d'IA de plus. Cela bouscule les principes d'identité, de confiance, de données, de responsabilité et, en fin de compte, d'autorité.
Ainsi, avant de vous demander ce qu'un agent peut faire, je commencerais par poser une autre question.
Qu'êtes-vous réellement prêt à le laisser faire ?
Si les défis évoqués ici vous semblent familiers, ou si vous vous demandez comment l'IA agentique s'intègre dans votre environnement numérique plus large, nous serions ravis de partager nos impressions. Écrivez-nous à hello@spicymango.co.uk, appelez-nous ou contactez-nous via notre formulaire de contact.
Si les défis évoqués ici vous semblent familiers, ou si vous vous demandez comment l'IA agentique s'intègre dans votre environnement numérique plus large, nous serions ravis de partager nos impressions. Écrivez-nous à hello@spicymango.co.uk, appelez-nous ou contactez-nous via notre formulaire de contact.
Si les défis évoqués ici vous semblent familiers, ou si vous vous demandez comment l'IA agentique s'intègre dans votre environnement numérique plus large, nous serions ravis de partager nos impressions. Écrivez-nous à hello@spicymango.co.uk, appelez-nous ou contactez-nous via notre formulaire de contact.
