Orchestration multi-fournisseurs : coordonner des agents issus de différents frameworks

L'orchestration d'agents multi-fournisseurs désigne la coordination d'agents IA issus de frameworks et de fournisseurs différents via un protocole commun et ouvert. Grâce à Agent-to-Agent (A2A), un orchestrateur LangGraph pilote par exemple des agents CrewAI et AutoGen sans divulguer leurs prompts, modèles ou mémoire internes. L'objectif est l'interopérabilité sans vendor lock-in : des agents qui vivent dans des environnements séparés collaborent sur une tâche commune.

• Qui coordonne qui ? Un agent orchestrateur appelle des agents pairs via A2A. La logique interne des agents appelés reste volontairement opaque.
• Quel protocole pour quoi ? MCP pour la relation agent-outil, A2A pour la relation agent-agent. En 2026, c'est la stack convergente du secteur.
• Qu'est-ce que cela apporte ? Aucun lock-in chez un fournisseur unique, car les agents deviennent interchangeables grâce à des AgentCards portables et aucun environnement ne doit exposer les autres.

Pourquoi coordonner plusieurs frameworks plutôt qu'un monolithe

Dans la réalité des entreprises européennes, on ne part pas d'une page blanche. L'agent CRM vit dans Salesforce, l'agent ERP dans SAP, l'agent de productivité chez Microsoft, une étape de raisonnement spécialisée peut-être directement dans l'Anthropic Claude Agent SDK. Personne ne reconstruit tout cela dans un seul framework. L'orchestration multi-fournisseurs accepte cette hétérogénéité comme la norme et pose un langage commun par-dessus.

La clé conceptuelle d'A2A : le protocole définit comment les agents se parlent, pas comment ils pensent. Un agent Salesforce peut appeler un agent SAP sans qu'aucun des deux ne dévoile ses prompts, sa mémoire ou son modèle. C'est justement cette encapsulation qui permet à un orchestrateur LangGraph de piloter un agent CrewAI ou AutoGen sans connaître son fonctionnement interne.

Architecture : la stack de protocoles convergente en 2026

Après douze mois de réorganisation publique, la stack est claire. Anthropic a apporté MCP le 9 décembre 2025 à l'Agentic AI Foundation, au sein de la Linux Foundation ; Google a fait don d'A2A à la Linux Foundation le 23 juin 2025, avec AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow comme membres fondateurs. L'ACP d'IBM a fusionné avec A2A en août 2025.

L'évaluation honnête : MCP plus A2A forment la stack convergente. AGNTCY est le complément rationnel lorsque l'identité et l'observabilité inter-fournisseurs sont réellement nécessaires. NANDA a sa place sur la liste de veille, pas sur le chemin critique d'un programme 2026.

Les briques techniques essentielles d'A2A

• Transport : JSON-RPC 2.0 sur HTTPS, streaming via Server-Sent Events, notifications push optionnelles pour les tâches longues.
• AgentCard : un document JSON par agent avec endpoint, capacités, skills pris en charge, modalités et schémas d'authentification. C'est le contrat inter-systèmes par excellence.
• Cycle de vie des tâches : submitted -> working -> input-required -> completed | failed | canceled. Le résultat d'une tâche consiste en un ou plusieurs artefacts.
• Trois modes d'interaction : synchrone, polling asynchrone, ainsi que streaming/push pour les tâches de longue durée.

Avantages de l'interopérabilité et leurs limites

Le principal avantage n'est pas une promesse marketing, il est structurel : qui connecte ses agents via des AgentCards portables peut remplacer un agent spécialisé faible par un meilleur sans remanier l'orchestrateur. Pour une agence, cela signifie rendre des agents construits une seule fois appelables dans n'importe quel environnement client.

Les limites sont tout aussi réelles et doivent entrer dans chaque décision d'architecture :

• Frontières de confiance : chaque pair A2A est opaque pour les autres. C'est bon pour la confidentialité, mais mauvais pour l'audit en boîte blanche. Les traces inter-fournisseurs sont difficiles.
• Amplification de l'injection de prompt : chaque nouvelle fenêtre de contexte de sous-agent est une nouvelle surface d'attaque. La classe EchoLeak (CVE-2025-32711, Aim Labs, Microsoft 365 Copilot, juin 2025) croît linéairement avec le nombre d'agents qui ingèrent du contenu non fiable.
• Vendor lock-in par la porte dérobée : les extensions propriétaires d'A2A portant sur l'AgentCard ou la sémantique des tâches sapent précisément la portabilité qui fonde le protocole. Le signal de veille 2026 : l'AgentCard restera-t-elle un document JSON portable ?
• Maturité : en 2026, le hub-and-spoke via A2A est encore en cours de productisation et ne constitue pas un standard abouti. AGNTCY et NANDA ne sont pas encore des paris pour la production.

Scénario pratique : LangGraph orchestre quatre agents par-delà les frontières entre fournisseurs

Un flux transverse concret d'un grand groupe, qui relie ventes, service client et finance. L'orchestrateur est LangGraph (v1.0, disponibilité générale le 22 octobre 2025, licence MIT) ; les agents spécialisés internes parlent chacun leur propre framework et sont appelés via A2A. Pour qu'un orchestrateur externe comme LangGraph puisse appeler un agent Joule via A2A, SAP étend Joule avec l'A2A bidirectionnel. Selon SAP, il doit être disponible de manière générale au T4 2026 (état : octobre 2026, SAP Sapphire 2026 Innovation News Guide).

```text
Orchestrateur LangGraph (durable state, checkpointing)
|
|-- tâche A2A --> agent Agentforce 360 (données CRM, Atlas Reasoning, pas d'A2A en interne)
|-- tâche A2A --> agent CrewAI Enrichment (enrichissement de leads, processus propre)
|-- tâche A2A --> agent AutoGen Review (critic-generator, contrôle qualité)
|-- tâche A2A --> agent SAP Joule (écriture comptable après validation, A2A bidirectionnel annoncé pour T4 2026)
|
|-- MCP --> ABAP / S4HANA / Integration Suite (outils)

Chemin d'écriture : single-threaded. Seul le nœud LangGraph valide les écritures ; la comptabilisation passe par la tâche Joule.
Chaque saut A2A porte le même trace ID (audit + RGPD).
```

Ce qui compte, c'est la discipline d'écriture. En avril 2026, Cognition a précisé la forme efficace : plusieurs agents apportent de l'intelligence, mais les écritures restent single-threaded. Le fan-out à dominante lecture (enrichissement, retrieval, revue) est robuste ; l'écriture parallèle dans un état partagé est fragile. Dans le scénario, trois agents collectent et vérifient, et l'écriture n'a lieu qu'à un seul endroit : via la tâche Joule que l'orchestrateur valide. Pour situer les coûts : le pattern orchestrateur-worker derrière Claude Research a obtenu dans l'évaluation de recherche interne un résultat supérieur de 90,2 % à celui d'un agent Claude Opus 4 seul, mais a consommé environ 15 fois plus de tokens qu'une interaction de chat normale (Anthropic, 13 juin 2025). Ce surcoût n'est rentable que pour des tâches à forte valeur et parallélisables, pas de manière générale.

Obligations RGPD et règles pratiques dans les flux multi-fournisseurs

Dès que des agents tournent chez différents fournisseurs de calcul, le flux de données franchit à chaque tâche plusieurs frontières de résidence des données et de sous-traitance.

• Chaîne de sous-traitance (art. 28 RGPD) : chaque fournisseur d'agents est potentiellement sous-traitant. Le multi-agent allonge la chaîne ; chaque saut A2A constitue potentiellement une relation de sous-traitance distincte.
• Transferts internationaux (art. 44-49) : pour chaque saut d'agent vers un pays tiers reposant sur des clauses contractuelles types (art. 46), tu as besoin d'une analyse d'impact des transferts (TIA) distincte. Tu y vérifies si la législation ou les pratiques des autorités du pays de destination compromettent l'efficacité des clauses (recommandations 01/2020 du CEPD). Si le saut va vers un fournisseur américain certifié au titre de l'EU-US Data Privacy Framework, le transfert repose sur la décision d'adéquation de la Commission au sens de l'art. 45 RGPD (décision d'exécution (UE) 2023/1795). Tant que cette décision s'applique, la TIA n'est pas nécessaire.
• Piste d'audit : trace de bout en bout de chaque appel d'agent, versions de modèles épinglées, enregistrement de tous les prompts des sous-agents et des AgentCards utilisées, corrélation via un trace ID unique. La loi n'impose pas le trace ID. Mais il montre quel agent a traité quelles données et quand, et facilite ainsi la démonstration de conformité au titre de l'art. 5, paragraphe 2, du RGPD. Le pattern Allianz Project Nemo, avec un agent d'audit dédié, sert ici de modèle de référence pertinent.
• Cohérence linguistique : un agent qui tutoie avec Du et appelle un agent qui vouvoie avec Sie paraît cassé aux yeux du client. Le ton de voix doit être imposé au niveau de l'AgentCard et des modèles de prompts.

Pour les agences et le B2B

Pour les agences en Europe, le principal levier de stratégie produit en 2026 consiste à publier une AgentCard pour chaque agent productisé. Les environnements de tes clients appellent ainsi tes agents directement depuis Agentforce, Joule ou Copilot Studio, sans intégration sur mesure. Sans AgentCard, ton agent reste durablement derrière une interface spécifique. Pour les décideurs B2B, la question d'achat est concrète : le contrat Agentforce, Joule ou Copilot Studio garantit-il l'interopérabilité A2A et la conformité au standard MCP, et que se passe-t-il en cas de sortie ? L'architecture par défaut rationnelle pour les PME : n8n ou LangGraph pour l'orchestration, MCP pour les outils, A2A pour chaque handshake entre plateformes. Blck Alpaca accompagne ces décisions de manière concrète : de la revue du choix des patterns jusqu'à une architecture d'audit compatible avec les exigences de souveraineté, en passant par des stratégies AgentCard gouvernées.