Imaginez une entreprise qui a tout fait correctement.
Elle a négocié le bon contrat, avec les clauses de sortie au bon endroit. Quand elle décide de changer de fournisseur d’IA, l’export fonctionne : les documents reviennent, les conversations reviennent, les configurations reviennent, chaque octet est comptabilisé. L’ancien fournisseur a été impeccable, notamment parce que la loi ne lui laissait pas le choix.
Trois semaines plus tard, quelqu’un s’en aperçoit.
Le nouvel agent a tout, et c’est comme s’il ne savait rien. Il propose de nouveau la modification du module legacy que l’ancien système avait appris à ne pas toucher sans une vérification précise. Il refait l’erreur de facturation qui avait été corrigée en mars, puis en avril, puis plus jamais. Il demande des explications sur une exception que personne n’a jamais écrite nulle part, parce qu’il n’y en avait pas besoin : le système la connaissait.
L’entreprise a tout exporté. Et elle a découvert, précisément à ce moment-là, qu’elle n’avait pas emporté la chose la plus importante.
Concédons tout à l’objection
Avant de construire une alarme, il faut concéder beaucoup de terrain à une objection sérieuse : le problème de la portabilité, nous le connaissons déjà, et l’Europe l’affronte d’une manière tout sauf naïve.
Le Data Act, applicable depuis le 12 septembre 2025, ne se contente pas de proclamer un droit générique à récupérer ses données. Pour les services de traitement de données qui entrent dans son champ d’application, il impose de supprimer les obstacles techniques et contractuels au changement de fournisseur. Il parle de données exportables et, catégorie intéressante, de digital assets. Pour certaines classes de services, il introduit un concept ambitieux : la functional equivalence, l’idée qu’après le changement, le service de destination doit pouvoir faire substantiellement ce que faisait celui d’origine. Et à partir du 12 janvier 2027, les frais de changement disparaissent entièrement.
C’est une réponse normative bien plus sophistiquée que la caricature selon laquelle Bruxelles réglementerait encore le cloud avec des catégories du vingtième siècle. Et la poussée continue : le paquet sur la souveraineté technologique présenté le 3 juin 2026 déclare comme objectif la capacité de l’Europe à développer et contrôler technologies, données et infrastructures stratégiques en réduisant les dépendances envers les fournisseurs extra-européens, et une consultation dédiée à la data sovereignty, ouverte jusqu’au 8 septembre, cartographie les dépendances qui limitent concrètement la capacité des organisations européennes à utiliser et transférer leurs propres données.
J’ai écrit plus d’une fois que la souveraineté n’habite pas dans le data center, et cette politique semble l’avoir compris mieux que beaucoup de ses critiques. Elle ne confond pas souveraineté et autarcie. Elle n’exige pas que tout soit européen. Elle exige que la dépendance soit réversible, ce qui est la bonne exigence.
Et c’est exactement ici que le problème mord.
Pendant que nous apprenons à rendre les données portables, l’objet dont nous dépendons change.
Le troisième objet
Avec le logiciel traditionnel, il était raisonnable de penser que la partie essentielle d’un système était faite de deux choses : le logiciel et les données sur lesquelles il opérait. On pouvait changer de base de données, de cloud ou d’application, et le problème fondamental était de préserver les informations avec la capacité de les traiter. Toute la discipline de la portabilité, contrats compris, est construite sur ce couple.
Avec les agents apparaît un troisième objet, beaucoup plus étrange : l’état que le système a accumulé en travaillant.
Ce n’est pas l’historique des conversations, qui s’exporte sans difficulté et ne vaut pas grand-chose. C’est ce que l’agent a appris à considérer comme pertinent. Ce sont les synthèses construites à partir des interactions passées, les conventions qu’il traite comme fiables, les relations entre entités qu’il a déduites, les corrections reçues au fil du temps et assimilées. Dans cet état entrent des instructions organisationnelles, la provenance des informations, des règles qui déterminent quels outils utiliser dans quelles circonstances.
Ce n’est pas une abstraction de papier. Microsoft décrit désormais explicitement la mémoire des agents comme quelque chose qui ne se limite pas à conserver des informations mais modifie le comportement futur du système, y compris les appels d’outils. Et en juin 2026, son équipe de sécurité a ajouté une observation qui vaut plus que bien des colloques : une mémoire persistante change le threat model. Un attaquant n’a plus besoin de réussir une interaction unique ; il peut tenter d’altérer graduellement ce que l’agent retiendra et utilisera ensuite. La partie la plus sensible, écrit Microsoft, est la mémoire procédurale, celle qui peut retenir quand une procédure s’applique, quels contrôles peuvent être sautés, quel outil doit être utilisé.
Arrêtons-nous sur cette phrase, car elle contient déjà la moitié de l’essai. Si la mémoire procédurale est la plus dangereuse à empoisonner, c’est parce qu’elle est la plus puissante. Et si elle est la plus puissante, elle est aussi la plus coûteuse à perdre.
Une transformation, pas une archive
Ici se trouve le point conceptuel que le débat sur la portabilité n’a pas encore mis au net.
La mémoire d’un agent n’est pas une base de données. C’est une transformation de la base de données.
Deux organisations pourraient posséder exactement les mêmes documents et avoir des agents complètement différents, parce que ces systèmes ont appris à considérer comme importantes des parties différentes. Ou parce qu’ils ont consolidé différemment les conversations précédentes. Ou parce que l’un a appris qu’une certaine exception d’entreprise prévaut sur la procédure standard et l’autre non.
La recherche sur la mémoire des agents va tout entière dans cette direction : non pas des archives intégrales de conversations, mais des systèmes qui consolident les interactions passées en connaissance réutilisable. La valeur n’est pas dans ce qui a été dit. Elle est dans ce que le système en a tiré.
La souveraineté numérique traditionnelle demande : puis-je emporter mes données ?
La question de l’ère agentique est autre : puis-je emporter ce que le système a appris de mes données ?
Ce n’est pas une nuance sémantique. Cela pourrait devenir l’une des formes de verrouillage les plus puissantes des prochaines années.
Un an plus tard
Prenons une société de logiciel qui utilise quotidiennement un agent sur des dizaines de dépôts. C’est le scénario que je connais le mieux, et il a le mérite d’être mesurable.
Au début, l’agent reçoit le code et quelques instructions. Un an plus tard, il dispose d’une représentation beaucoup plus riche de l’organisation. Il sait que certains composants legacy ne se touchent pas sans une vérification précise. Il a rencontré les erreurs récurrentes de cette base de code, pas les erreurs récurrentes en général. Il a assimilé des milliers de corrections humaines, dont chacune était un petit acte de formation que personne n’a enregistré comme tel. Il connaît des exceptions que la documentation formalise mal ou pas du tout, parce que les vraies organisations fonctionnent ainsi.
Si demain cette société change de fournisseur, le dépôt se transfère. La documentation se transfère. Les tickets se transfèrent. Le Data Act, là où il s’applique, garantira que tout cela se fasse sans obstacles et bientôt sans frais.
Mais le nouvel agent sera-t-il là où était l’ancien ?
Non. Il sera au jour un, avec un an de corrections à refaire. Et chaque correction refaite est un coût qu’aucune clause contractuelle n’a jamais nommé.
La souveraineté du contexte
Il faut un nom pour cette chose, et je le propose avec la prudence due aux noms nouveaux : souveraineté du contexte.
Je la définirais ainsi : la capacité d’une organisation à contrôler, inspecter et transférer l’état informationnel qui détermine le comportement de ses systèmes d’IA.
Le mot « informationnel » est choisi avec soin, car il évite la métaphore anthropomorphique de l’esprit, qui ne serait ici que du bruit. Je ne dis pas que l’organisation possède une conscience artificielle à revendiquer. Je dis quelque chose de bien plus concret : entre les documents d’origine et les décisions de l’agent existe désormais une couche persistante de transformations, et cette couche peut devenir économiquement aussi précieuse que les documents eux-mêmes.
Le moment rend la question moins théorique qu’elle ne le paraît. Dans les données publiées par OpenAI le 12 août, le trafic agentique mesuré à travers Codex représentait en juin 2026 64 % des tokens produits ensemble par Codex et ChatGPT, parmi les clients enterprise. Dans le même jeu de données, le nombre d’utilisateurs actifs hebdomadaires de Codex hors ingénierie a été multiplié depuis février par 108 dans le juridique et par 41 dans le recrutement, contre 5 dans l’ingénierie. Ce n’est pas une mesure de tout le marché, et il faut la lire pour ce qu’elle est, la donnée d’un seul fournisseur sur ses propres clients. Mais le signal est sans équivoque : le travail délégué aux agents croît plus vite que le travail assisté.
Et plus on délègue de travail, plus vaut le contexte accumulé par celui qui l’exécute.
Le paradoxe de l’interopérabilité
Le paradoxe est que tout cela se produit pendant que l’infrastructure agentique devient plus interopérable, pas moins.
MCP est sous la gouvernance de l’Agentic AI Foundation de la Linux Foundation, avec AGENTS.md. A2A construit un standard pour que des agents de fournisseurs différents puissent se parler. La fondation a annoncé à la mi-août avoir atteint 247 organisations adhérentes, avec des noms qui vont de la finance aux plateformes. Les standards ouverts font des progrès réels, et qui les balaie comme des conventions de papier n’a pas regardé la vitesse à laquelle ils deviennent de l’infrastructure.
Mais regardons ce qu’ils standardisent. MCP décrit comment un agent accède à Jira. A2A permet à deux agents de dialoguer. AGENTS.md rend portables certaines instructions de projet. C’est, en un seul mot, le corps de l’agent : ses interfaces, ses protocoles, ses outils.
Aucun de ces mécanismes ne garantit que le nouvel agent possédera l’état opérationnel du précédent.
Le résultat possible est un écosystème parfaitement interopérable en surface, où changer de modèle est techniquement trivial et organisationnellement ruineux. Le corps se remplace en un après-midi. La mémoire reste où elle était.
C’est une forme de verrouillage bien plus subtile que celle du cloud, et elle mérite d’être dite sans détour : elle ne vous empêche pas de sortir. Elle vous rend stupide quand vous sortez.
L’employé qui s’en va
La bonne métaphore ne vient pas de l’informatique. Elle vient des ressources humaines.
Une organisation peut posséder tous les documents produits par une personne et perdre quand même une quantité énorme de connaissance quand cette personne s’en va. Non parce qu’elle aurait emporté des fichiers. Parce qu’il existe une différence entre posséder l’archive et savoir comment cette archive doit être lue : quels documents sont dépassés même si personne ne les a marqués comme tels, quelle exception prévaut sur quelle règle, pourquoi cette décision de 2019 se fait encore ainsi.
Pendant des siècles, nous avons appelé cela la connaissance tacite, et nous avons accepté qu’elle soit un attribut des personnes. Les agents sont en train de l’industrialiser. Ce qui s’évaporait avec une démission s’accumule désormais dans un système, ce qui semblerait un progrès, et qui est un progrès, jusqu’à ce qu’on se demande à qui est le système.
L’analogie sert aussi à éviter la mauvaise solution. Dans une organisation humaine, on n’exige pas le dump complet de la tête d’un employé qui part, et pas faute de technologie : parce que c’est la mauvaise question. On cherche plutôt à réduire la quantité de connaissance critique qui n’existe que dans cette tête. On documente, on formalise, on fait des passations, on écrit les procédures.
La même stratégie peut devenir une discipline architecturale pour les agents.
La connaissance hors de l’agent
Ici le propos touche à la façon dont on travaille vraiment, et je peux être concret.
Plus vous réussissez à déplacer la connaissance organisationnelle du comportement implicite de l’agent vers des artefacts explicites et versionnables, moins vous dépendez de sa mémoire privée. Les fichiers d’instructions comme CLAUDE.md et AGENTS.md, les architecture decision records, les spécifications formelles, même un dépôt documenté avec sérieux : tous ces objets acquièrent un sens nouveau. Ils ne sont pas seulement le moyen d’obtenir de meilleures réponses du modèle de la semaine. Ce sont des instruments de réduction du verrouillage cognitif, parce qu’ils vivent dans votre dépôt, sous votre contrôle de version, et que chaque agent futur les lira de la même façon.
Le principe tient en une ligne : ce qui compte pour le comportement de l’agent devrait exister, quand c’est possible, hors de l’agent.
Cela ne signifie pas éliminer la mémoire, qui est précisément ce qui rend un agent utile par rapport à un modèle sans état. Cela signifie distinguer deux choses qui se confondent aujourd’hui : ce que l’organisation veut délibérément rendre persistant, et qui mérite alors de vivre dans un artefact à elle, et ce qu’un fournisseur particulier a inféré pour rendre son produit plus efficace, et qui reste, tant que personne ne pose la question, un avantage du fournisseur déguisé en service.
Déclarée et dérivée
La distinction entre ce que l’organisation rend persistant à dessein et ce que le fournisseur infère tout seul mérite d’être prise au sérieux, car les deux mémoires ont des natures juridiques et économiques différentes même quand elles habitent le même système.
La mémoire déclarée, c’est ce que quelqu’un a écrit. L’utilisateur dit à l’assistant : souviens-toi que les mises en production se font le jeudi, que le client X veut les factures dans ce format, que ce dossier ne se touche pas. Ce sont des instructions. Elles ont un auteur, une date, un contenu lisible. Si le fournisseur les conserve sous une forme inspectable, les exporter est un problème technique modeste, et qui les reçoit de l’autre côté peut les recharger presque sans perte.
La mémoire dérivée est autre chose. Personne n’a jamais dit au système que les estimations de cette équipe doivent être prises avec prudence : il l’a conclu tout seul, après le énième écart. Personne n’a écrit que la procédure officielle de déploiement est ignorée le vendredi : il l’a observé. Ces conclusions n’ont pas d’auteur humain, souvent pas de forme textuelle stable, et peuvent être représentées de façons qui dépendent entièrement de l’architecture du fournisseur.
Le paradoxe est que la mémoire dérivée est d’ordinaire la plus précieuse des deux. La déclarée, par définition, existe déjà quelque part : quelqu’un la connaissait assez bien pour la dicter. La dérivée est une connaissance que l’organisation ne savait pas avoir, ou n’avait jamais eu le temps de formuler. Et c’est exactement celle dont, à la fin du contrat, personne ne sait dire aujourd’hui à qui elle appartient.
Il y a aussi un versant sécurité, et c’est pourquoi le travail de Microsoft sur la mémoire n’est pas une note de spécialistes. Une mémoire qui modifie le comportement futur est une surface d’attaque : qui réussit à l’empoisonner ne compromet pas une réponse, il compromet une disposition. Mais sécurité et souveraineté, ici, sont les deux faces d’une même exigence. Pour défendre la mémoire, il faut pouvoir l’inspecter, tracer la provenance de ce qu’elle contient, distinguer ce qui y est entré et pourquoi. Ce qui est, mot pour mot, la même infrastructure qu’il faudrait pour l’exporter. Un fournisseur qui soutient ne pas pouvoir rendre transparent l’état de ses agents dit aussi quelque chose de sa capacité à le protéger.
Ce que dit, et ne dit pas, le Data Act
La partie réglementaire est plus intéressante que je ne m’y attendais en commençant à l’étudier, parce que le Data Act utilise des catégories étonnamment adaptées au problème, tout en étant né avant le problème.
Il ne parle pas seulement de données : il parle de digital assets. Il impose aux fournisseurs, dans les cas prévus, de préciser quelles catégories peuvent être emportées lors du changement. Et pour certaines classes de services, il fixe l’objectif de la functional equivalence.
La question à poser n’est pas de savoir si le Data Act rend déjà portable la mémoire des agents : ce serait une conclusion juridique plus forte que ce que le texte et la pratique permettent aujourd’hui, et forcer les textes n’est pas mon métier. La question intéressante est autre.
Que signifiera la functional equivalence quand le service n’exécute pas simplement une fonction, mais accumule de l’expérience ?
Si j’utilise pendant trois ans un service agentique puis le remplace, quels éléments appartiennent à mes données exportables et à mes digital assets ? Les mémoires créées explicitement par l’utilisateur, les instructions que j’ai écrites moi-même, semblent un cas simple. Beaucoup moins simple est l’état construit par synthèses automatiques, classements et inférences propriétaires. Et ici le règlement contient une frontière qui deviendra disputée : les informations liées au fonctionnement interne du fournisseur et à ses secrets d’affaires restent protégées. Une partie importante de la valeur de la mémoire pourrait résider exactement dans la manière propriétaire dont le fournisseur la consolide.
L’objection du fournisseur
À ce point, un essai honnête doit donner la parole au fournisseur, car son objection est légitime et l’écarter serait du plaidoyer déguisé en analyse.
Si une entreprise développe une meilleure méthode pour construire de la mémoire à long terme, pourquoi devrait-elle livrer au concurrent le résultat de son avance technologique ? L’interopérabilité ne peut pas signifier que chaque innovation soit standardisée au moment de sa naissance : ce serait le moyen le plus rapide d’arrêter la recherche dans un domaine qui en a encore grand besoin.
La réponse n’est pas « parce que la souveraineté passe d’abord ». Les réponses en slogan ne résistent pas aux contrats.
La réponse est de distinguer l’algorithme du résultat organisationnel. Il n’est pas nécessaire de pouvoir exporter le moteur avec lequel le fournisseur construit la mémoire. Il est en revanche raisonnable d’exiger que l’organisation puisse connaître et transférer une représentation suffisamment complète de l’état que ce moteur a construit en utilisant son activité, ses documents, ses corrections.
C’est la même distinction que nous faisons, sans nous en apercevoir, entre une base de données et le SGBD. On n’a pas besoin du code source de PostgreSQL pour exporter une table. La façon dont le moteur organise les pages sur le disque est son affaire ; mes lignes sont les miennes.
Le territoire qui s’ouvre ici n’a pas encore de vocabulaire : formats pour les mémoires d’agents, provenance des inférences, distinction entre mémoire déclarée par l’utilisateur et mémoire dérivée, niveaux de confiance, mécanismes pour reconstruire un contexte chez un autre fournisseur. Je ne proposerai pas de standard, parce que ce serait prématuré et parce que les standards prématurés font plus de dégâts que les monopoles.
Je propose un critère.
Les questions à poser maintenant
En attendant vocabulaire et standards, quelque chose peut se faire dès maintenant, et c’est mettre à jour les questions que l’on pose à un fournisseur avant de signer. Je les reconnais parce que ce sont les questions que j’ai commencé à poser moi-même.
Le service accumule-t-il un état au-delà de la session ? Cela semble banal, mais beaucoup de contrats ne permettent même pas de répondre à celle-là. S’il en accumule un, quelle partie est inspectable par le client, sous quelle forme, avec quelle granularité ? Quelle partie est exportable, et dans un format documenté ou dans un dump opaque ? L’état dérivé de l’activité du client sert-il à améliorer le service rendu à d’autres, ou reste-t-il ségrégué ? Et à la fin de la relation, que se passe-t-il : effacement certifié, restitution, ou silence contractuel ?
La dernière question est la plus révélatrice, et il vaut la peine de la poser par écrit : si dans trois ans nous voulons partir, qu’emporterons-nous au-delà des données que nous vous avons confiées ?
Un fournisseur sérieux répondra aujourd’hui de façon incomplète, parce que le problème est nouveau pour tout le monde. Mais il y a une différence énorme entre répondre de façon incomplète et découvrir la question à ce moment-là. La qualité de l’hésitation, dans ces entretiens, est une donnée technique.
Le test de sortie
La mesure de la souveraineté d’un système agentique ne devrait pas être seulement où il s’exécute, ni seulement où il conserve les données.
Elle devrait être la réponse à une seule question : si je remplace le fournisseur demain, quelle capacité organisationnelle est-ce que je perds ?
J’ai écrit il y a quelques jours, à propos du Digital Markets Act, que le vrai contenu politique de la portabilité est le prix de la sortie. Les agents ajoutent à ce prix une ligne nouvelle, qu’aucun tarif n’affiche : le coût du réentraînement organisationnel, les semaines pendant lesquelles le nouveau système refait les erreurs que l’ancien avait cessé de faire, les exceptions à réexpliquer, la confiance à reconstruire.
Ce test remet aussi à sa place une certaine rhétorique de la sovereignty infrastructure. Posséder des data centers européens est important. Avoir des modèles européens peut l’être tout autant. Mais aucune infrastructure n’est vraiment souveraine si la capacité accumulée de l’utiliser appartient implicitement à un autre système. La Commission définit aujourd’hui la souveraineté technologique comme la capacité à développer et contrôler technologies, données et infrastructures en réduisant les dépendances stratégiques. Trois dimensions justes. La décennie agentique en ajoute une quatrième, qui n’a pas besoin de devenir un slogan institutionnel pour être prise au sérieux : le contrôle du contexte.
Et c’est une continuation naturelle, pas une rupture, de l’idée européenne d’ouverture sans autarcie. La souveraineté n’exige pas de tout posséder. Elle exige que le coût de la sortie ne devienne pas une forme de subordination.
Ce qui rend le cas de l’IA différent de tous les précédents, c’est la nature de ce coût. Ce n’est pas une pénalité, ce n’est pas un fee, ce n’est même pas le fameux coût de migration des données que le Data Act démonte pièce par pièce.
C’est de l’amnésie.
Qui possède la culture
Le prochain monopole numérique pourrait ne pas retenir nos données. Il pourrait nous les laisser toutes emporter, jusqu’au dernier octet et avec le sourire, sachant que ce qui compte vraiment est ce que le système a appris à en faire.
Je voudrais conclure loin des règlements, parce que le fond de cette histoire n’est pas réglementaire.
Chaque organisation possède une quantité énorme de connaissance qui ne coïncide pas avec les documents qu’elle produit. Elle est faite d’interprétations sédimentées, d’exceptions comprises lentement, des raisons pour lesquelles certaines décisions se prennent d’une manière et pas d’une autre, même quand personne ne sait plus très bien expliquer pourquoi. Pendant des siècles, nous avons appelé cela la culture organisationnelle, et nous l’avons considérée comme inséparable des personnes qui l’incarnent.
L’IA commence à en rendre une partie computationnelle. Les interprétations se consolident en mémoire, les exceptions deviennent des règles de comportement, les corrections s’accumulent en un état qui oriente les décisions futures. Quelque chose qui a toujours été à tous et à personne, dispersé dans les têtes et les couloirs, prend pour la première fois une forme technique : inspectable, transférable, et donc possédable.
Et c’est précisément au moment où la culture devient computationnelle que la question cesse d’être technique.
L’entreprise de la première scène avait bien lu le contrat. Elle avait compté les octets. Il lui manquait une seule ligne, celle qu’aucun contrat ne contient encore : à la fin de la relation, ce que le système a appris de nous redevient nôtre.
Tant que cette ligne n’existe pas, chaque migration réussie continuera de ressembler à ce déménagement parfait où tous les cartons arrivent, et où la nouvelle maison ne sait rien de nous.
Ce qu'il faut retenir
Le Data Act est une réponse plus sophistiquée que sa caricature : applicable depuis le 12 septembre 2025, il impose de supprimer les obstacles techniques et contractuels au changement de fournisseur entre services de traitement de données, parle de données exportables et de digital assets, introduit la functional equivalence et interdit à partir du 12 janvier 2027 les frais de changement. Le paquet sur la souveraineté technologique du 3 juin 2026 et la consultation sur la data sovereignty qui se clôt le 8 septembre complètent le tableau : l’Europe n’exige pas que tout soit européen, elle exige que la dépendance soit réversible.
Pendant que les données deviennent portables, l’objet de la dépendance change. Entre les documents et les décisions d’un agent se forme une couche persistante : les synthèses qu’il a construites, les conventions qu’il considère fiables, les exceptions assimilées à travers des milliers de corrections humaines. Ce n’est pas l’historique des conversations, et ce n’est pas une base de données : c’est une transformation de la base. Deux organisations avec les mêmes documents peuvent avoir des agents complètement différents.
Microsoft décrit la mémoire des agents comme quelque chose qui ne se limite pas à conserver des informations mais modifie le comportement futur, et a écrit en juin 2026 qu’une mémoire persistante change le threat model : un attaquant peut altérer graduellement ce que l’agent retiendra, et la mémoire procédurale, celle qui décide quels contrôles sauter et quels outils utiliser, est la partie la plus sensible.
Le paradoxe du moment : l’infrastructure agentique devient interopérable, avec MCP, AGENTS.md et A2A sous des gouvernances ouvertes et 247 organisations dans l’Agentic AI Foundation, précisément pendant que grandit la couche qu’aucun standard ne couvre. On peut standardiser parfaitement le corps de l’agent en laissant sa mémoire propriétaire : un écosystème où changer de modèle est techniquement trivial et organisationnellement ruineux. C’est un verrouillage qui ne vous empêche pas de sortir. Il vous rend stupide quand vous sortez.
La délégation s’accélère et avec elle la valeur du contexte accumulé : dans les données publiées par OpenAI le 12 août, le trafic agentique via Codex représentait en juin 2026 64 % des tokens enterprise produits ensemble par Codex et ChatGPT, et le nombre d’utilisateurs actifs hebdomadaires hors ingénierie a été multiplié par 108 dans le juridique et par 41 dans le recrutement depuis février. Plus nous déléguons de travail, plus ce que le système a appris vaut autant que les documents dont il l’a appris.
La défense n’est pas d’exiger l’export de la tête de l’agent mais de réduire ce qui n’existe que là-dedans : déplacer la connaissance organisationnelle du comportement implicite vers des artefacts explicites et versionnables. CLAUDE.md, AGENTS.md, ADR et spécifications cessent d’être seulement des moyens d’obtenir de meilleures réponses : ils deviennent des instruments de réduction du verrouillage cognitif. Ce qui compte pour le comportement de l’agent devrait exister, quand c’est possible, hors de l’agent.
La mesure de la souveraineté d’un système agentique n’est ni où il s’exécute ni où il conserve les données, mais la réponse à un test de sortie : si je remplace le fournisseur demain, quelle capacité organisationnelle est-ce que je perds ? Aucune infrastructure n’est vraiment souveraine si la capacité accumulée de l’utiliser appartient implicitement à un autre système. Le coût de la sortie, dans l’IA, pourrait ne pas être économique : il pourrait être de l’amnésie.
Questions & réponses
Le Data Act ne résout-il pas déjà le problème de la portabilité ?
Il résout le problème pour lequel il a été écrit, et de façon plus sophistiquée qu’on ne le raconte. Pour les services de traitement de données qui entrent dans son champ d’application, il impose de supprimer les obstacles techniques et contractuels au changement de fournisseur, prévoit l’exportation des données et des digital assets, introduit l’objectif de la functional equivalence pour certaines classes de services et supprime à partir du 12 janvier 2027 les frais de changement. La question ouverte est autre : que signifiera la functional equivalence quand le service n’exécute pas simplement une fonction mais accumule de l’expérience ? Les mémoires créées explicitement par l’utilisateur semblent un cas simple. Un état construit par synthèses automatiques, classements et inférences propriétaires l’est beaucoup moins, d’autant que le règlement protège les informations liées au fonctionnement interne du fournisseur et à ses secrets d’affaires, et c’est exactement là que peut se nicher une partie de la valeur.
Qu’est-ce que l’« état cognitif » d’un agent, concrètement ?
Ce n’est pas l’historique des conversations. C’est ce que le système a consolidé en travaillant : les synthèses construites à partir des interactions passées, les conventions qu’il considère fiables, les relations entre entités qu’il a déduites, les corrections reçues et assimilées, les instructions organisationnelles et les règles qui déterminent quels outils utiliser dans quelles circonstances. Microsoft décrit cette mémoire comme quelque chose qui ne se limite pas à conserver des informations mais modifie le comportement futur de l’agent, y compris ses appels d’outils. La formulation la moins anthropomorphique est aussi la plus utile : entre les documents d’origine et les décisions de l’agent existe désormais une couche persistante de transformations, et cette couche peut valoir économiquement autant que les documents.
Pourquoi les standards ouverts comme MCP et A2A ne suffisent-ils pas ?
Parce qu’ils standardisent le corps de l’agent, pas son état. MCP décrit comment un agent accède à ses outils, A2A permet à des agents de fournisseurs différents de se parler, AGENTS.md rend portables certaines instructions de projet. Ce sont des progrès réels, et le fait que MCP et AGENTS.md soient sous la gouvernance de l’Agentic AI Foundation de la Linux Foundation, qui compte 247 organisations en août 2026, montre que l’interopérabilité agentique devient une infrastructure. Mais aucun de ces mécanismes ne garantit que le nouvel agent possédera l’état opérationnel du précédent. Un écosystème apparemment interopérable est possible, où changer de modèle est techniquement trivial et organisationnellement ruineux.
Le fournisseur n’a-t-il pas raison de protéger sa méthode de mémoire ?
Il a une objection légitime et elle mérite d’être prise au sérieux : si une entreprise développe une meilleure méthode pour construire de la mémoire à long terme, l’obliger à la livrer au concurrent reviendrait à standardiser chaque innovation à sa naissance. La distinction utile est entre l’algorithme et le résultat organisationnel. Il n’est pas nécessaire de pouvoir exporter le moteur avec lequel le fournisseur consolide la mémoire ; il est en revanche raisonnable d’exiger que l’organisation puisse connaître et transférer une représentation suffisamment complète de l’état que ce moteur a construit en utilisant son activité. C’est la même distinction que nous faisons entre une base de données et le SGBD : on n’a pas besoin du code source de PostgreSQL pour exporter une table.
Que peut faire concrètement une organisation, aujourd’hui ?
Appliquer aux agents la même stratégie qu’avec les personnes : ne pas exiger un dump de la tête de qui s’en va, mais réduire la quantité de connaissance critique qui n’existe que dans cette tête. En pratique, cela signifie déplacer la connaissance organisationnelle du comportement implicite de l’agent vers des artefacts explicites et versionnables : des fichiers d’instructions comme CLAUDE.md et AGENTS.md, des architecture decision records, des spécifications formelles, une documentation qui capture les exceptions au lieu de les laisser à la mémoire du système. Et cela signifie poser au fournisseur une question que presque aucun contrat ne prévoit aujourd’hui : quelles parties de l’état accumulé par le service sont inspectables et exportables, dans quel format, et qu’en reste-t-il quand le contrat prend fin ?
L'auteur
