Les agents IA ne tueront pas ton système de référence. Tes limites de débit, si.

Zain Hoda, cofondateur de Vanna AI, a écrit récemment un fil percutant où il soutient que les agents IA vont vider les systèmes de référence de leur substance.¹ Sa thèse : dès qu’un agent peut cloner tout ton CRM en quelques secondes, le fossé défensif des données s’évapore. Le système de référence devient un simple point d’écriture, et l’agent devient la vraie interface.

Il a raison sur le problème. Je pense qu’il a tort sur l’issue.

Les systèmes de référence ne vont pas s’effondrer. Mais ceux qui luttent contre ce virage seront remplacés, sans l’ombre d’un doute, par ceux qui ne le font pas.

Le parallèle avec la cybersécurité, que personne ne fait

En cybersécurité, il existe un principe fondateur : autoriser au plus près de la ressource. Ne mets pas toute ta confiance au périmètre en espérant que ça tienne. Descends le contrôle d’accès là où les données vivent vraiment.

Les systèmes de référence font déjà ça, et depuis des décennies. Ils réunissent deux choses vraiment difficiles à séparer : les données de l’entreprise et les règles d’accès qui disent qui peut les voir et les modifier. Qui peut consulter cette fiche client ? Qui peut approuver cette note de frais ? Qui a changé ce champ, et quand ?

Ce ne sont pas des fonctions accessoires. C’est toute la raison pour laquelle les secteurs réglementés ne peuvent pas tout déverser dans la fenêtre de contexte d’un agent et passer à autre chose.²

Hoda le reconnaît en passant (gouvernance, permissions, synchronisation multi-utilisateurs), mais il balaie ça comme « a much smaller business », un marché bien plus petit. Je pense que c’est le sous-estimer largement.

Les limites de débit, c’est le mauvais combat

Sur un point, je suis tout à fait d’accord : les systèmes de référence qui répondent à l’IA en verrouillant l’accès à leur API jouent une partie perdue d’avance. Une partie stupide, même.

Les limites de débit ne protègent pas ton fossé. Elles rendent juste ton produit moins bon. Un agent assez motivé mettra les données en cache en local, se synchronisera de temps en temps et te contournera complètement. Bravo : tu viens d’apprendre à tes clients à te traiter comme une dépendance en amont peu fiable, plutôt que comme le centre de leur façon de travailler.

C’est l’équivalent, pour le logiciel d’entreprise, de l’industrie musicale qui attaquait Napster en justice. Tu n’as pas tort sur la propriété. Tu as catastrophiquement tort sur la stratégie.

MCP, c’est l’adaptation qui compte

C’est là que ça devient intéressant.

Le Model Context Protocol est un standard ouvert qui permet aux agents IA de parler aux logiciels d’entreprise de façon structurée.³ Ce n’est pas une couche d’intégration de plus. C’est un moyen, pour les systèmes de référence, de rester compétitifs justement parce que il leur permet de garder le contrôle là où ça compte.

Un serveur MCP se place devant tes données et les expose aux agents IA de façon structurée et encadrée. Pense à la conciergerie d’un hôtel. L’agent n’obtient pas le passe de toutes les chambres. Il fait une demande, le concierge vérifie qu’elle est permise et ne remet que ce qui convient. Chaque interaction est cadrée, authentifiée et journalisée.

C’est le principe « autoriser au plus près de la ressource », appliqué à l’IA. Plutôt que de combattre l’accès des agents, tu le fais passer par une couche que tu contrôles.

Le système de référence qui adopte MCP dit : « Oui, les agents peuvent interagir avec nos données. Voici le protocole. Voici les permissions. Voici la piste d’audit. » Celui qui le combat dit : « Non, pas plus de dix appels d’API par minute. » Sur lequel tu veux construire ?

Bien sûr, MCP n’a rien de magique. Publie un point d’accès MCP sans authentification ni contrôle d’accès et tu viens d’ouvrir la porte à tous les agents d’internet.⁴ L’incident Clawdbot de janvier l’a prouvé : plus d’un millier de déploiements exposés, la plupart avec la configuration par défaut et aucune authentification. La conciergerie ne marche que si quelqu’un vérifie vraiment les identités.

Traiter les changements comme des virements bancaires

Il y a un autre angle qui n’a pas assez d’attention : la réversibilité.

Les agents IA vont se tromper. Ils vont modifier la mauvaise fiche, fusionner des doublons qui ne devaient pas l’être, créer des entrées à partir d’un contexte halluciné. Ce n’est pas une hypothèse. C’est le coût inévitable de l’action autonome à grande échelle.

Les systèmes de référence sont particulièrement bien placés pour gérer ça, mais seulement s’ils traitent chaque changement initié par une IA comme un virement bancaire. Quand ta banque traite un paiement, elle ne se contente pas de retirer d’un compte et d’ajouter à un autre. Elle crée une trace du virement : ce qui a changé, quand, par qui, et quels étaient les soldes avant et après. Si quelque chose tourne mal, la banque peut annuler le virement proprement, sans dérégler tout le reste.

Chaque changement d’un agent IA devrait fonctionner pareil. Distinct, enregistré, avec un état avant et après clair. Si l’agent met une fiche client à jour de travers, tu dois pouvoir annuler sans craindre ce qui casse en aval.

Rends le retour en arrière facile. Rends le rayon d’impact visible. Donne aux humains un annuler en un clic qui ne dégénère pas en chaos.

C’est là que l’argument « la gouvernance n’est qu’une fonctionnalité » s’écroule complètement. Construire ce suivi des changements et cette annulation sûre dans une plateforme de données n’est pas un accessoire qu’on boulonne sur le côté. C’est de l’ingénierie vraiment difficile, au cœur du système. Et c’est précisément ce qu’un cache d’agent autonome ne peut pas bien faire, parce qu’il ne possède pas l’état de référence.

Le vrai clivage

Ce qui se passe vraiment, ce n’est pas « les systèmes de référence s’effondrent ». C’est une bifurcation.

Les systèmes de référence qui s’adaptent exposeront de riches interfaces MCP, garderont un contrôle d’accès faisant autorité, offriront un audit au niveau de chaque changement et feront de l’IA un citoyen de première classe de leur plateforme.⁵ Ils auront plus de valeur, pas moins, parce qu’ils sont la couche de confiance d’une pile de plus en plus autonome.

Les systèmes de référence qui ne s’adaptent pas limiteront, restreindront et plaideront jusqu’à l’insignifiance. Leurs clients migreront vers des plateformes qui travaillent avec le paradigme des agents plutôt que contre lui.

Le fossé n’a jamais été « on stocke tes données ». C’était « on est le système à qui tu confies tes données ». La confiance demande de la gouvernance, de l’auditabilité et du contrôle. Ça ne disparaît pas. Ça va compter bien plus.

En bref

Les systèmes de référence ne meurent pas. Mais ceux qui voient l’accès de l’IA comme une menace plutôt que comme une contrainte de conception perdront face à ceux qui ne le font pas. MCP donne à ces plateformes un moyen de rester la référence tout en s’ouvrant aux agents. Les gagnants seront les plateformes qui rendent l’interaction avec l’IA traçable, réversible et auditable par défaut.

Les perdants seront ceux qui débattent encore de limites de débit.

Zain Hoda (co-founder, Vanna AI), “The Agent Will Eat Your System of Record” (X/Twitter, 2025). Lien ↩
Cerbos, “MCP Permissions: Securing AI Agent Access to Tools” (septembre 2025). Traitement détaillé de l’application du contrôle d’accès via des serveurs MCP. Lien ↩
Anthropic, “Model Context Protocol” (novembre 2024). Le protocole a été donné à l’Agentic AI Foundation, sous l’égide de la Linux Foundation, en décembre 2025. Wikipédia ↩
PointGuard AI, “Clawdbot MCP Vulnerability Exposes AI Agents” (janvier 2026). Plus d’un millier de déploiements MCP exposés sans authentification, un exemple réel de ce qui arrive quand personne ne tient la conciergerie. Lien ↩
Microsoft, “Dynamics 365 ERP Model Context Protocol” (novembre 2025). La façon dont Microsoft décrit le passage « from systems of record to systems of action ». Lien ↩