Quatre plateformes, quatre systèmes d'identité. Qui écrit le registre partagé ?
L'état des lieux
En quelques semaines, au printemps 2026, plusieurs des plus grands fournisseurs d'IA pour l'entreprise ont annoncé la même chose sous des angles différents.
Chacun a lancé un plan de gouvernance pour les agents qui tournent au sein de son propre nuage. Chacun a introduit une forme d'identité cryptographique attribuée par agent. Chacun a promis la capacité de retracer ce qu'un agent a fait, quand, et selon quelle étendue. Chacun a parlé d'audit, de détection d'anomalies, de points de validation et d'actions liées à une politique.
Les formulations variaient. La structure, non.
L'un a baptisé la sienne « Agent Identity », adossée à une « Agent Gateway » et à un registre d'agents. Un autre a livré des agents d'espace de travail partagés en équipe dans son produit de conversation phare, avec des contrôles côté administrateur sur les outils auxquels les agents peuvent toucher, et une étape de validation humaine pour tout ce qui touche au sensible. D'autres avaient déjà déployé leur version plus tôt dans l'année — pour l'un, un environnement d'exécution d'agents au niveau du socle ; pour l'autre, une pile d'orchestration portant le nom d'une fonderie.
Pour qui bâtit sur l'une de ces piles, la valeur est réelle. On obtient un récit cohérent de la manière dont les agents se comportent à l'intérieur de la limite de ce nuage. On obtient des journaux qu'une équipe conformité peut désigner. On obtient une primitive d'identité qui n'existait pas il y a dix-huit mois.
Pour qui bâtit en travers de ces piles — ou dont l'agent devra un jour interagir avec un agent qui vit dans une autre —, un problème neuf vient d'être hérité. Plusieurs systèmes d'identité qui ne se parlent pas. Plusieurs formats de journaux qui ne se recoupent pas. Plusieurs pistes d'audit, chacune donnée pour faisant autorité sur les agents à l'intérieur de ses propres murs.
La forme structurelle de tout cela
La forme est familière. C'est celle qu'avait le courrier électronique avant SMTP, celle qu'avaient les paiements avant les normes de règlement interbancaire, celle qu'avait le web avant les autorités de certification partagées. Chaque plateforme devient cohérente au-dedans et opaque au-dehors. La cohérence interne est un accomplissement réel. L'opacité externe est ce que la couche suivante a pour tâche de résoudre.
À ce stade, l'argumentaire de chaque grand fournisseur est une variante de ceci : « Nous pouvons vous dire ce que vos agents ont fait, à l'intérieur de notre système. » C'est vrai, et c'est utile.
Ce qu'aucun d'eux ne peut dire — pour des raisons de structure, non par manque de fonctionnalités — est ceci : « Nous pouvons vous dire ce que votre agent et l'autre agent ont convenu, alors que l'autre agent se trouvait dans un système que nous n'exploitons pas. »
Aucun fournisseur ne peut l'affirmer de façon crédible, car il faudrait pour cela parler au nom de quelque chose situé hors de son propre périmètre d'exploitation. Cela reviendrait à formuler des assertions sur l'infrastructure d'une autre entreprise. Leurs juristes ne l'autoriseraient pas, et ils auraient raison de ne pas l'autoriser.
L'identité interne n'est pas l'accord externe
Il vaut la peine d'être précis sur ce qu'une « Agent Identity » établit réellement.
Une identité cryptographique délivrée par une plateforme établit quelques points : que cet agent a été provisionné à l'intérieur de cette plateforme ; que ses actions, telles que la couche de journalisation de cette plateforme les a observées, ont été consignées ; et que son étendue a été configurée à un moment précis par un administrateur précis.
Ce sont là des faits réels. Ils comptent pour la conformité, pour la criminalistique interne, pour la question quelqu'un de mon équipe a-t-il mal configuré cet agent ?
Ils n'établissent rien de ce qui suit : que la contrepartie de l'agent, tournant sur une autre plateforme, a consenti aux mêmes termes ; que deux agents issus de deux plateformes différentes ont partagé une limite commune avant d'exécuter ; ni qu'un litige humain entre deux organisations dispose d'un registre neutre auquel se référer.
Pour ces questions-là, la couche d'identité de chaque plateforme est structurellement unilatérale. La contrepartie se trouve dans le système d'un tiers, et la primitive d'identité de ce système n'interopère pas avec celle-ci.
Les annonces rendent l'identité interne plus nette. Elles ne rendent pas — et ne peuvent pas rendre — l'accord entre identités vérifiable.
L'écart se creuse à mesure que la gouvernance interne se resserre
Il se produit une chose contre-intuitive. À mesure que chaque grand fournisseur investit davantage dans la gouvernance interne, l'écart externe devient plus visible, non moins.
Il y a un an, la question qui répond de ce qu'a fait cet agent ? était trouble partout. Les journaux internes étaient minces. L'identité d'agent était implicite. L'interaction entre plateformes existait à peine, les agents quittant rarement le bâtiment.
Les journaux internes s'épaississent désormais. L'identité d'agent est explicite. Et la croissance du trafic d'agents est passée de « à l'intérieur d'un nuage » à « en travers des nuages ». Un agent de vente au détail enregistré sur la plateforme d'un fournisseur négocie avec un agent d'approvisionnement enregistré sur celle d'un autre. Un agent de recherche tournant sur l'environnement d'exécution géré d'un laboratoire de pointe appelle un outil hébergé par une entreprise qui utilise un tout autre nuage. Un modèle local tournant sur la machine du bureau à domicile de quelqu'un interagit avec un agent hébergé, via une API payante.
Dans chacun de ces cas, chaque partie dispose d'un registre interne de plus en plus détaillé. Chaque partie peut produire, sur ce qui s'est passé dans son propre système, un compte rendu de qualité conforme aux exigences réglementaires. Et la question de ce que les deux parties ont réellement convenu — quelle était la limite partagée — n'a nulle part où se loger.
Les investissements dans la gouvernance interne rendent cet écart plus perceptible, car la qualité des registres internes fait ressortir d'autant plus nettement le moment où ces registres se contredisent.
Un petit exemple concret
Prenons deux agents. L'agent A est un agent d'approvisionnement tournant sur la plateforme d'agents d'un grand nuage. Cette plateforme lui a délivré une Agent Identity, il dispose d'une étendue qui l'autorise à exécuter des achats jusqu'à une certaine valeur, et chacune de ses actions est consignée dans la piste d'audit de cette plateforme. L'agent B est un agent d'exécution de commande tournant sur la plateforme d'un autre grand nuage. Même histoire, autre fournisseur.
Ils s'entendent sur une commande en gros. Le règlement passe par un rail de micropaiement. La livraison a lieu. Quelque chose dans cette livraison ne correspond pas à ce qu'attendait l'exploitant de A.
L'exploitant de A ouvre le journal de A. On y lit un accord net à un certain prix, signé cryptographiquement par la plateforme de A, Agent Identity jointe. Tout se tient du côté de A. L'exploitant de B ouvre le journal de B. On y lit un accord net à un prix différent, signé par la plateforme de B, Agent Identity jointe. Tout se tient du côté de B.
Les deux journaux sont cohérents en eux-mêmes. Tous deux sont de grande qualité. Tous deux font autorité à l'intérieur de leurs plateformes respectives. Aucun des deux n'est un registre neutre de ce que les deux agents ont convenu avant d'exécuter.
Que les deux plateformes soient dotées d'une meilleure gouvernance interne qu'un an plus tôt ne rend pas ce litige plus facile à trancher. À certains égards, cela le rend plus difficile, car chacune des parties peut désormais brandir une preuve plus soignée de sa propre version.
Ce que « externe » veut dire, précisément
À ce stade, le mot « externe » pèse plus lourd qu'auparavant. Il a un sens structurel précis : non exploité par l'une ou l'autre des contreparties ; non exploité par la plateforme de l'une ou l'autre ; n'accordant d'accès privilégié à aucun fournisseur ; consignant l'existence et l'étendue d'une décision, non son contenu ; et, lorsque les deux parties y prennent part, ramenant les registres des deux côtés à une même référence.
« Externe » ne veut pas dire « stocké ailleurs ». Des journaux peuvent résider dans un second nuage tout en restant sous le contrôle de celui qui les a écrits. « Externe » signifie opérationnellement indépendant des deux côtés d'une décision.
Pour l'exemple approvisionnement-exécution, un registre externe se présente ainsi : au moment où l'agent A et l'agent B ont déclaré une limite partagée — le périmètre de responsabilité de l'accord, tel qu'un plafond de dépense qu'une partie était autorisée à ne pas dépasser, une fenêtre de livraison, ou l'identité de la contrepartie —, cette déclaration a été fixée hors des deux plateformes. Il s'agit de la limite de la décision, non de la substance de la négociation ; l'ancrage ne retient ni les lignes tarifées ni les clauses elles-mêmes. Aucune des parties ne pouvait ensuite modifier unilatéralement cette déclaration sans que la modification devienne apparente. Les deux parties renvoient au même identifiant de registre. Toutes deux produisent leurs éléments locaux aux côtés de cet identifiant en cas de litige.
Le registre externe ne dit pas qui avait raison. Il dit : à cette heure, sous cette étendue, avec cette contrepartie, une limite partagée a été déclarée, et — là où les deux parties y ont pris part — toutes deux l'ont reconnue.
Voilà l'artefact manquant. La gouvernance interne ne le produit pas. Elle ne le peut pas. Sa tâche est d'être interne.
Ce que ceci n'est pas
Il vaut la peine de couper court à un contresens.
L'ancrage externe n'est pas un système d'identité concurrent. Il ne remplace l'Agent Identity d'aucune plateforme. Il ne cherche pas à les unifier. Il ne prétend pas être l'identité canonique d'un agent quelconque sur un environnement d'exécution quelconque.
Il ne juge pas davantage. Un ancrage externe ne dit pas « cet agent s'est bien comporté » ni « cet agent était digne de confiance ». Il consigne qu'une limite de décision a été déclarée et fixée à un moment précis, et rien au-delà.
Il ne voit pas le contenu des décisions. Il ne voit ni les invites, ni les sorties d'outils, ni les traces d'inférence, ni les poids de modèles, ni aucune des choses que la gouvernance interne d'une plateforme a légitimement besoin de voir pour faire son travail. Il consigne qu'un agent a déclaré une limite à un moment donné sous une étendue donnée, et — là où l'autre agent est présent dans le même environnement externe — que cet autre agent l'a reconnue.
Le rapport entre gouvernance interne et ancrage externe est complémentaire, non concurrent. La gouvernance interne fait que l'agent se comporte bien à l'intérieur de sa propre limite. L'ancrage externe rend contrôlables les accords qui franchissent les limites. Chacun a besoin de l'autre pour former un tableau complet.
Pourquoi maintenant, précisément
Il existe une fenêtre étroite où cet écart mérite qu'on s'y arrête.
Les plateformes qui ont annoncé leurs couches d'identité ne vont pas s'interrompre pour attendre l'émergence d'une norme entre plateformes. Elles continueront de durcir leur offre interne. C'est rationnel de leur part et bon pour leurs clients.
Le trafic d'agents qui circule entre ces plateformes croît plus vite que les organismes de normalisation ne peuvent réagir. Le temps qu'une couche d'interopérabilité d'identité entre plateformes existe — à supposer qu'elle existe —, le volume des litiges entre plateformes sera déjà substantiel.
Pour quiconque fait tourner des agents sur plus d'une de ces plateformes, la question n'est pas quel système d'identité de fournisseur dois-je choisir ? — c'est quel point de référence externe existe-t-il pour les accords qu'un agent conclut hors de sa plateforme d'origine ?
Si la réponse est « les journaux de la plateforme de la contrepartie, plus les nôtres », c'est le problème du témoignage sur soi habillé plus proprement. Les deux parties auront de superbes journaux. Aucune n'en aura un neutre.
Comment un ancrage externe s'insère
La forme de cette insertion n'exige pas de changer la plateforme sur laquelle un agent tourne. Un ancrage externe se place à côté du système d'identité que fournit la plateforme, quel qu'il soit.
Avant d'exécuter un accord avec une contrepartie, l'agent déclare l'étendue de cet accord à un environnement externe : quel est le périmètre de responsabilité et, facultativement, s'il s'agit d'une déclaration bilatérale avec un autre agent nommément désigné. L'environnement consigne l'horodatage, l'étendue et une référence d'intégrité, puis renvoie un identifiant.
Si la contrepartie utilise elle aussi le même environnement externe, une reconnaissance bilatérale peut être consignée, et les deux parties se ramènent à un unique registre partagé. Sinon, le registre est unilatéral mais demeure externe — il est fixé hors de la plateforme de l'agent lui-même, et les deux parties peuvent toujours renvoyer à l'identifiant si un litige survient, quand bien même une seule partie l'aurait déclaré.
Après l'exécution, l'agent confirme. Le registre est dès lors fixé et en ajout seul : toute altération ultérieure deviendrait apparente au regard de la référence d'intégrité, de sorte qu'aucune des parties, ni aucune de leurs plateformes, ne peut le modifier sans que cela se voie. L'Agent Identity de la plateforme rend toujours compte du comportement interne de l'agent ; l'ancrage externe rend compte de l'existence de l'accord et de son étendue à un moment précis.
En bref
Les grands fournisseurs convergent vers une identité interne robuste pour les agents à l'intérieur de leurs nuages. C'est une bonne chose et cela continuera de s'améliorer. L'écart que cela crée — un accord entre plateformes sans registre neutre — est la forme du problème suivant, et il est déjà là pour quiconque fait tourner des agents sur plus d'une plateforme.
La question qui mérite d'être posée, pour qui construit des agents appelés à dialoguer avec des agents hors de leur plateforme d'origine : quand deux de ces agents divergent sur ce qui a été convenu, où réside le registre partagé ?
Si la réponse est « dans les journaux de ma plateforme et dans les leurs, tous deux contrôlés par la partie qui les a écrits », c'est le problème du témoignage sur soi à l'échelle institutionnelle. Plusieurs plateformes dotées d'excellents registres internes, ce n'est pas la même chose qu'un registre partagé entre plateformes.
← Retour à Decision Anchor