Interopérabilité des agents IA : garder sa stack créative portable
La plupart des équipes choisissent un agent IA sans se demander si elles pourraient un jour le quitter. Deux protocoles ouverts, MCP et A2A, déterminent désormais la portabilité réelle de vos agents, de vos outils et de votre historique. Voici ce que fait chacun, où se cache encore la dépendance fournisseur, et les questions qui la révèlent avant de signer.
- Ce que font MCP et A2A, en mots simples
- Où se cache la dépendance même quand un vendeur cite les standards
- Cinq questions à poser par écrit avant de vous engager
La question que les acheteurs oublient : peut-on partir ?
Les démos d'agents montrent ce qu'un agent sait faire. Elles montrent rarement ce que coûte l'arrêt. Il y a un an, comme le rappelle sista.ai, l'interopérabilité des agents était une diapositive dans une présentation commerciale. En 2026, c'est un standard opérationnel que des entreprises font tourner en production. Avant les protocoles ouverts, remplacer l'agent d'un fournisseur obligeait à reconstruire chaque intégration sur mesure qui le reliait aux autres systèmes et agents.
Choisir un agent, c'est donc aussi choisir un coût de sortie. Pour les équipes créatives, où les agents liront des briefs, écriront dans des bibliothèques d'assets et se passeront le travail, ce coût de sortie mérite d'être connu dès le premier jour.
Deux protocoles, deux directions
Deux termes, définis une fois. Le Model Context Protocol (MCP) est une manière standard pour un agent de se connecter à vos outils et à vos données : fichiers, CRM, base de données, bibliothèque d'assets. Selon la formule de sista.ai, c'est la façon dont un agent descend dans vos systèmes. Le protocole Agent2Agent (A2A) est une manière standard pour un agent de parler à un autre : la façon dont un agent se tourne vers ses pairs. Le guide de Galileo rappelle que A2A a été publié en avril 2025 sous licence ouverte et qu'il est aujourd'hui gouverné par la Linux Foundation, et The Agile Brand Guide souligne que les deux protocoles se complètent plutôt qu'ils ne se concurrencent.
Imaginez la fabrication d'une campagne. Un agent d'interprétation de brief demande des variantes à un agent de copy, qui demande un contrôle à un agent de conformité. The Agile Brand Guide donne un exemple marketing voisin, où un agent demande à d'autres la sélection d'audience, la logique d'offre, les variantes créatives et la revue de conformité. Avec A2A, ces passations suivent un format commun même si trois fournisseurs ont construit les trois agents. Avec MCP, chaque agent accède à votre bibliothèque d'assets et à votre historique de validation de la même façon. Notre panorama sur l'IA multi-agents et pourquoi la création devrait s'y intéresser explique le schéma, et notre article sur la façon dont les systèmes multi-agents gèrent les conflits traite de ce qui se passe quand ils ne sont pas d'accord.
Deux formes de dépendance
MLVeda distingue deux dépendances. La dépendance verticale est celle à un seul fournisseur d'intergiciel pour l'accès aux outils, et elle s'approfondit avec chaque connecteur propriétaire. La dépendance horizontale est celle à une seule plateforme d'IA pour la coordination des agents. Les protocoles ouverts traitent les deux en principe : avec MCP et A2A, une entreprise peut changer d'agent ou de fournisseur, ou ajouter un outil spécialisé, sans reconstruire sa couche d'intégration. Les mots importants de cette phrase sont « en principe ».
Ce que les protocoles ouverts ne vous donnent pas
Vos données. sista.ai est tranchant sur ce point : des protocoles de communication ouverts ne signifient pas automatiquement que vous pouvez exporter vos données, les configurations de vos agents ou l'historique de vos workflows. Cela doit figurer au contrat, pas être supposé.
La preuve du support. « Nous avons des intégrations » n'est pas un support de protocole. Exigez-le par écrit, versions comprises, et vérifiez qui gouverne le standard.
La mémoire de votre équipe. La dépendance propre à la création se loge dans les règles de marque, l'historique de validation, les bibliothèques de prompts et les fiches de génération. Si tout cela vit dans la plateforme d'un agent, changer de fournisseur revient à perdre la mémoire du travail. Le remède : garder le système de référence hors de tout agent, avec briefs, validations, assets, règles de marque et fiches de génération dans un espace neutre, et des agents qui lisent et écrivent via des interfaces standard. Nos checklists sur la préparation de vos données pour l'IA agentique et sur l'effet miroir des processus montrent ce que cet espace doit contenir, et une bibliothèque de prompts dont votre équipe est propriétaire est l'actif portable le plus simple pour commencer.
La sécurité par défaut. Des connexions plus faciles relèvent l'enjeu de la conception des permissions. Décidez ce que chaque agent peut lire, écrire et publier, quel que soit le protocole.
Cinq questions à poser par écrit
Posez-les à chaque fournisseur et conservez les réponses avec le contrat :
- Quels protocoles supportez-vous pour l'accès aux outils et aux données, et pour les passations entre agents, et dans quelles versions ?
- Où vivent les configurations d'agents, les prompts et les règles de marque, et dans quel format pouvons-nous les exporter ?
- Pouvons-nous exporter l'historique des workflows, les validations et les journaux d'audit dans un format ouvert, et à quel coût ?
- Combien coûte le départ, en frais, en délai et en accompagnement à la migration ?
- Quelles parties du produit ne fonctionnent qu'à l'intérieur de votre plateforme ?
Le playbook de The Pedowitz Group sur les standards ouverts décrit le même basculement : une stack qui remplace les intégrations ponctuelles par des contrats communs entre outils, données et agents, de sorte que les fournisseurs puissent changer tandis que les contrats restent stables. Les questions deux à cinq sont ce qui transforme cette idée en quelque chose d'opposable. Standardiser d'abord vos workflows créatifs, comme le défend notre article sur la survie face au taux d'échec de l'IA agentique, rend aussi les réponses plus faciles à juger.
Commencer petit : un système de référence, une interface standard
Évitez la grande architecture. Exposez un système de référence, comme la bibliothèque d'assets ou le dépôt de briefs, via une interface standard. Connectez-y un agent. Puis faites le test qui compte : remplacez cet agent par un autre dans un bac à sable et regardez ce qui casse. Avec les deux protocoles réellement en place, selon sista.ai, changer de fournisseur se rapproche du remplacement d'un outil SaaS qui parle une API standard : du travail, mais pas une reconstruction à partir de zéro.
Un environnement de production qui garde briefs, validations et assets dans un seul endroit gouverné offre à chaque agent, quel que soit son concepteur, une source unique où lire et écrire. C'est le rôle d'infrastructure que MTM joue pour les équipes créatives qui ajoutent de l'IA à leur workflow (Accelerate with AI) : les agents changent, le dossier reste en place.
La décision à prendre ce trimestre
Avant le prochain achat d'agent, ajoutez une ligne à l'évaluation : le coût du départ. Posez les cinq questions, inscrivez les réponses au contrat, et gardez vos briefs, vos validations et vos règles de marque là où aucun fournisseur ne les contrôle. Les agents continueront de changer. Le dossier de la façon dont votre équipe travaille ne devrait pas avoir à le faire.
FAQ
MCP et A2A remplacent-ils les API ? Non. A2A complète MCP, et les API directes restent le moyen de relier des applications bien délimitées, comme l'explique The Agile Brand Guide. Les protocoles standardisent la conversation entre agents et outils. Ils ne dispensent pas d'intégrations solides.
Une plateforme qui supporte MCP est-elle automatiquement sûre à connecter ? Non. Le support d'un protocole ne dit rien de ce qu'un agent a le droit de lire ou de modifier. Limitez les permissions par agent et par système, et journalisez ce que fait chacun.
Peut-on changer de fournisseur d'agents sans tout reconstruire ? On se rapproche d'un remplacement d'outil plutôt que d'une reconstruction, si les deux protocoles sont réellement implémentés des deux côtés, selon sista.ai. Vos exports de configurations, de prompts et d'historique décident de la fluidité du changement.
Les petites équipes doivent-elles s'en soucier ? Si vous prévoyez de faire tourner plus d'un agent ou d'en changer, oui. Chaque connecteur sur mesure ajouté aujourd'hui est un coût à défaire plus tard, et le moment le moins cher pour poser la question de la sortie est avant le premier.
Que faut-il mettre dans le contrat ? Des droits d'export sur les données, les configurations d'agents et l'historique des workflows dans des formats ouverts ; un support de protocole nommé avec ses versions ; un accompagnement à la migration et son prix ; et un préavis avant tout changement lié aux protocoles.
Sources
- https://sista.ai/it/insights/agent2agent-a2a-protocol-explained
- https://galileo.ai/blog/google-agent2agent-a2a-protocol-guide
- https://agilebrandguide.com/wiki/agentic-ai/agent2agent-a2a-protocol/
- https://www.mlveda.com/blog/the-mcp-standard-and-the-death-of-integration-lock-in-what-pe-operating-partners-need-to-know-about-agent-interoperability
- https://www.pedowitzgroup.com/how-will-open-standards-mcp-etc.-affect-interoperability
