Un agent est une intégration. Cent sont un problème de gouvernance.
Les agents ont obtenu une identité de production avant de disposer d'un moyen stable d'enregistrer ce qu'ils ont fait. Microsoft Entra Agent ID est disponible, avec des parrains et des dates d'expiration. Les conventions OpenTelemetry pour les traces d'agents restent expérimentales. Cet écart n'est pas un détail : il décide de ce qu'il est raisonnable de mettre en production cette année, et transforme une question d'IA en une question de gouvernance.
La question intéressante au sujet des agents n'est plus de savoir s'ils fonctionnent. Dans les projets que nous voyons, un agent qui lit le courriel d'un fournisseur et propose la commande correspondante fonctionne suffisamment bien pour être conservé. La question intéressante est ce qui se passe le jour où il y en a quarante, construits par quatre équipes, dont trois sont déjà passées à autre chose.
Ce n'est pas un problème d'IA. Chacune de ses composantes est un problème que le secteur connaît déjà par son nom : identité, attribution des accès, audit, imputation des coûts, portée d'une défaillance, gestion des changements. La difficulté est qu'ils arrivent tous en même temps, attachés à quelque chose qui décide par lui-même.
Trois vagues, et seule la troisième est difficile
La première vague portait sur les modèles. Lequel, de quelle taille, à quel prix par million de jetons. Elle semblait décisive à l'époque et s'est révélée la moins durable : le modèle aujourd'hui en production sera remplacé deux fois avant que cet article ne vieillisse.
La deuxième vague portait sur les agents. Comment en relier un à un système réel, où passe la ligne entre ce qu'il décide et ce que le code exécute. Nous avons écrit sur cette ligne dans les agents décident, le code exécute, et la réponse tient : le jugement d'un côté, les garanties de l'autre.
La troisième vague ne porte pas sur de meilleurs agents. Elle porte sur un ensemble d'agents. Et un ensemble se comporte tout autrement qu'une intégration, parce que le mode de défaillance change. Un agent qui se trompe sur une permission est un défaut. Quarante agents partageant un service principal, c'est un incident sans moyen de savoir lequel a agi.
Ce qui a réellement changé cette dernière année
Deux choses se sont produites, et il vaut la peine de les énoncer avec précision, car la précision est l'argument.
Les agents ont obtenu une véritable identité. Microsoft Entra Agent ID introduit quatre nouveaux types d'objet : un agent identity blueprint, un blueprint principal, une agent identity et un agent user. Une agent identity est un compte dans Entra ID, gouverné par la même mécanique de cycle de vie qu'une personne : packages d'accès, gestion des droits, Accès conditionnel appliqué au niveau du blueprint afin que tous les agents qui en découlent héritent de la politique, et signaux de risque venus d'Identity Protection.
La partie de cette conception qui mérite une pause est le parrain. Chaque agent identity a une personne responsable de son accès et de son cycle de vie. Si cette personne quitte l'organisation, le parrainage est transféré automatiquement à son responsable. Quelqu'un répond toujours de l'agent, par construction, et le système refuse que ce quelqu'un soit personne.
Les agents n'ont pas obtenu de moyen stable d'enregistrer ce qu'ils ont fait. Les conventions sémantiques GenAI d'OpenTelemetry, le vocabulaire neutre pour les traces d'agents, sont passées dans un dépôt dédié à la version v1.42.0 du 12 juin 2026 et restent préstables. Il n'y a pas de 1.0. La forme est déjà bonne et largement émise, et elle reste explicitement susceptible d'évoluer.
Mises côte à côte, l'asymétrie constitue toute l'histoire :
| Sujet | État actuel | Ce que cela signifie en pratique |
|---|---|---|
| Identité | Disponible, gouverné | On donne à l'agent un nom, un responsable et une échéance |
| Droits d'accès | Disponible | L'accès arrive dans un package, avec approbateur et date de fin |
| Conditions d'accès | Disponible | L'Accès conditionnel évalue le risque de l'agent avant d'accorder |
| Trace et audit | Préstable, sans 1.0 | On instrumente, on fige la version et on prévoit des changements |
| Qualité de l'évaluation | Préstable | Savoir si l'agent a bien fait reste à la charge de qui l'exploite |
On sait désormais dire qui est un agent, à quoi il peut toucher et qui en répond. Dire exactement ce qu'il a fait, dans un format encore lisible l'an prochain, est la partie qui manque. Qui planifie un ensemble d'agents cette année planifie autour de ce manque, qu'il l'ait remarqué ou non.
Le protocole s'est doté d'une structure de gouvernance
Il existe une deuxième preuve, et ce n'est pas une analogie.
Le Model Context Protocol a passé sa première année à être une couche de description : cet outil existe, voici comment l'appeler. Les révisions suivantes ont presque toutes porté sur le contrôle. La révision de juin 2025 a classé les serveurs MCP comme Resource Servers OAuth 2.0, rendu obligatoires les métadonnées de ressource protégée du RFC 9728, et exigé que le client lie chaque jeton à un serveur précis via le paramètre de ressource du RFC 8707. La révision de novembre 2025 a ajouté le consentement incrémental de portées par l'en-tête WWW-Authenticate, des documents de métadonnées de client ID pour l'enregistrement, et un mécanisme expérimental de tasks pour les requêtes durables, avec interrogation et récupération différée du résultat.
Ce dernier compte davantage qu'il n'y paraît. Les tasks existent parce que les agents se sont mis à faire un travail qui survit à une requête. Un travail qui survit à une requête est un travail qui a besoin d'un état, d'un propriétaire et d'un moyen d'être annulé, ce qui est la définition d'une chose à gouverner.
Puis le protocole a fait ce que fait une infrastructure lorsqu'elle devient porteuse : il a formalisé sa propre gouvernance. Groupes de travail, groupes d'intérêt, une structure documentée, un système de niveaux pour les SDK avec des engagements de maintenance. Les protocoles qui restent des jouets ne créent pas de comités.
Ce qu'exige un ensemble d'agents, et à qui revient chaque partie
Les neuf sujets ci-dessous sont ceux que nous avons vus mal tourner. Les regrouper ainsi est utile, car cela montre que presque aucun ne relève de l'équipe IA.
| Sujet | La question qui échoue | À qui cela revient |
|---|---|---|
| Identité | Lequel des agents a fait cela ? | Identité |
| Droits d'accès | Qui a approuvé cet accès, et quand se termine-t-il ? | Identité et le responsable métier |
| Isolement | À quoi d'autre pouvait-il accéder lorsque cela a mal tourné ? | Plateforme |
| Audit | Peut-on reconstituer la décision six mois plus tard ? | Plateforme et conformité |
| Observabilité | Est-il en échec maintenant, et comment le saurions-nous ? | Plateforme |
| Coût | Quelle équipe paie cette boucle ? | Finance et plateforme |
| Politique | Que ne peut-il jamais faire, quel que soit le prompt ? | Sécurité |
| Approbation | Quelles actions exigent une personne avant de se concrétiser ? | Le responsable métier |
| Responsabilité | Qui signe lorsque c'est faux ? | Une personne nommée |
Seule la dernière ligne est nouvelle, et elle ne l'est qu'au sens où le secteur n'en a pas encore pris l'habitude.
Une identité par agent, et pourquoi le raccourci coûte cher
Le raccourci le plus courant que nous voyons est un service principal partagé par tous les agents qu'une équipe publie. C'est simple, cela fonctionne le premier jour, et cela détruit trois propriétés à la fois.
On perd l'imputation : le journal d'audit conserve le principal, non lequel des agents l'a utilisé, et la réponse à « lequel a fait cela » devient un exercice de reconstitution à partir de journaux applicatifs qui n'existent peut-être pas. On perd le moindre privilège : le principal partagé accumule l'union de toutes les permissions dont un agent a eu besoin, si bien que le plus récent et le moins revu hérite des droits du plus ancien et du plus éprouvé. Et on perd la capacité de révoquer : couper l'agent compromis les coupe tous.
La forme qui survit est ennuyeuse et connue :
Un blueprint porte la politique. Chaque agent en reçoit son identité. L'accès arrive dans un package avec approbateur et date de fin, au lieu d'être une concession permanente qui survit au projet qui en avait besoin.
Le détail qui mérite une décision, non une valeur par défaut
Entra Agent ID permet à une agent identity de demander un package d'accès par voie programmatique, en son propre nom, en créant une demande d'attribution. Le parrain peut aussi demander au nom de l'agent, et un administrateur peut attribuer directement.
Il vaut la peine de relire la première voie. Un agent peut demander davantage d'accès.
Ce n'est pas un défaut. C'est la primitive correcte pour un système où le travail se découvre à l'exécution, et la demande tombe toujours dans un flux d'approbation avec un approbateur humain. Mais c'est une véritable bifurcation d'architecture, et ce doit être une décision que l'organisation prend délibérément, plutôt qu'une chose qu'elle découvre lors d'un audit.
Notre position, par le même raisonnement que nous appliquons à tout chemin d'élévation de privilèges : pouvoir demander est acceptable, l'approbation ne doit jamais être automatique, et l'approbateur doit être quelqu'un qui comprend ce qu'est cette ressource. Un flux d'approbation qui achemine vers une personne incapable d'évaluer la demande est un tampon avec un meilleur journal.
L'approbation appartient à l'étape irréversible
L'instinct, lorsqu'une équipe mesure tout ce qu'un agent peut faire, est de placer une personne devant tout. Cela échoue en quinze jours : ceux qui relisent cessent de lire, et l'on a ajouté de la latence sans ajouter de jugement.
La ligne qui tient est la même que celle qui gouverne le reste du système. Demandez une personne là où l'action est irréversible ou visible de l'extérieur, et nulle part ailleurs.
| Approuver | Ne pas approuver |
|---|---|
| De l'argent qui sort de l'organisation | Lire des données que le demandeur peut déjà lire |
| Tout ce qui part vers un client | Résumer, classer, rédiger une proposition |
| Modifications de permissions et de rôles | Interroger des systèmes de référence |
| Supprimer ou écraser des enregistrements | Proposer une action pour relecture |
| Publier sur une surface publique | Tout ce qui se défait sans coût |
Le critère n'est pas l'importance apparente de l'action. C'est de savoir si une erreur passée inaperçue se corrige encore lundi.
Le coût est un contrôle, pas un rapport
La consommation de jetons est généralement traitée comme une question financière découverte en fin de mois. Dans un ensemble d'agents, c'est un mécanisme de sécurité, car coût incontrôlé et comportement incontrôlé sont le même événement vu sous deux angles. Un agent bloqué dans une boucle de reprises contre un outil défaillant produit exactement un symptôme visible avant que quiconque ne remarque le comportement : la facture.
Ce qui signifie que le budget appartient à l'identité, et non à un tableau de bord :
# La limite appartient à l'identité de l'agent, pas à une revue mensuelle.
# Un agent bloqué dans une boucle dépense son propre budget et s'arrête.
# Il ne dépense pas celui de l'équipe, ni celui de l'agent voisin.
def appeler_modele(agent: AgentIdentity, requete: Requete) -> Reponse:
if budget.depense(agent.id, aujourdhui()) >= agent.limite_journaliere:
raise BudgetEpuise(agent.id) # échec fermé, et alerte
reponse = modele.invoquer(requete)
budget.enregistrer(agent.id, reponse.jetons, reponse.cout)
return reponse
Des limites par agent apportent trois choses qu'un rapport mensuel n'apporte pas : la boucle s'arrête d'elle-même, la défaillance est imputée à un agent et non à une équipe, et l'alerte se déclenche pendant que la cause est encore à l'écran.
L'audit, quand la raison est une probabilité
L'audit traditionnel répond à ce qui s'est passé et sous quelle autorité. Avec les agents, il y a une troisième question, et c'est celle que l'on pose dans la salle juste après un incident : pourquoi a-t-il choisi cela.
Cette réponse ne peut pas être une explication du modèle, car une explication donnée après coup est un récit plausible, non un enregistrement. Ce que l'on peut enregistrer, c'est tout ce qui entoure la décision, et cela se révèle suffisant :
- l'identité de l'agent, non le principal partagé ;
- les outils disponibles à ce moment-là, et leurs versions ;
- les entrées que l'agent a réellement reçues, y compris ce qu'une étape de recherche a renvoyé ;
- les appels aux outils, dans l'ordre, avec leurs paramètres ;
- les approbations accordées, par qui et quand ;
- le modèle et sa version, car le comportement change de l'une à l'autre.
En recréant cela, on reproduit la décision, ce qui est précisément ce que veut un auditeur. C'est aussi exactement la surface que décrivent les conventions GenAI d'OpenTelemetry, et exactement pourquoi leur état préstable est une contrainte de planification et non une note de bas de page. Instrumenter maintenant, figer la version de la convention, et prévoir une migration.
La conclusion inconfortable
Une organisation dotée d'une identité en ordre, d'une gestion des droits qui fonctionne, d'un audit véritable et d'une imputation honnête des coûts peut mettre un ensemble d'agents en production cette année. Une organisation qui en est dépourvue n'est pas lente faute d'agents. Elle est lente parce que cette fondation n'a jamais été posée, et les agents rendent ce manque mesurable comme rien avant eux.
Nous avons écrit quelque chose de semblable sur l'assistant qui ne lit que ce que l'utilisateur peut lire et sur ce qu'il faut mettre en ordre avant d'activer Copilot. Le motif se répète parce qu'au fond il ne s'agit pas d'IA. Chaque vague d'automatisation pose la même question à une organisation, et la pose de plus en plus fort : savez-vous qui a le droit de faire quoi, et pouvez-vous prouver ce qui a été fait ?
Les agents sont la version la plus sonore de cette question à ce jour. Ils sont aussi la première qui la répétera plusieurs centaines de fois par jour, sans se lasser, jusqu'à ce que quelqu'un réponde.
