La réalité multi-fournisseur des agents
Une entreprise typique en 2026 exécute des agents IA d’au moins trois fournisseurs :
- Salesforce Agentforce gère l’automatisation Ventes, Service et Marketing
- Microsoft Copilot Studio gère les workflows centrés Office et le helpdesk IT
- Google Vertex AI alimente l’analytique de données et les pipelines ML personnalisés
- ServiceNow automatise la gestion des services IT et les demandes RH
- Les agents personnalisés construits sur LangGraph, CrewAI ou des frameworks internes comblent les lacunes
Ce n’est pas un futur hypothétique. C’est la réalité de toute entreprise qui a adopté des agents IA de ses fournisseurs logiciels existants. Et cela crée un problème de gouvernance qu’aucun de ces fournisseurs n’est équipé pour résoudre.
Pourquoi la gouvernance mono-fournisseur échoue
Chaque fournisseur ne gouverne que ses propres agents :
- Salesforce gouverne les agents Agentforce via Einstein Trust Layer — mais uniquement pour les agents s’exécutant dans Salesforce
- ServiceNow gouverne ses agents autonomes via les garde-fous Now Assist — mais uniquement pour les workflows ITSM et RH
- Microsoft gouverne les actions Copilot via les politiques Copilot Studio — mais uniquement pour les interactions Office 365
- Google fournit le monitoring Vertex AI — mais uniquement pour les modèles déployés sur GCP
Le résultat est des silos de gouvernance. Votre agent Commercial dans Agentforce apprend qu’un client préfère l’email au téléphone. Votre agent IT dans ServiceNow résout le problème VPN de ce même client. Ils ne partagent aucun contexte. Pas de piste d’audit unifiée. Pas de politiques d’approbation cohérentes. Pas de mémoire inter-fournisseurs.
Quand le RSSI demande « qu’ont fait nos agents IA ce trimestre ? », aucun système unique ne peut répondre.
La convergence des protocoles permet la coordination inter-fournisseurs
Deux standards émergents rendent la coordination inter-fournisseurs d’agents techniquement possible :
MCP (Model Context Protocol) — le standard pour connecter les agents IA aux outils et sources de données externes. Microsoft Copilot Studio, n8n et plus de 100 plateformes supportent désormais MCP.
A2A (Agent-to-Agent Protocol) — le standard pour que les agents découvrent des capacités, délèguent des tâches et synchronisent l’état entre plateformes. Salesforce, Google, ServiceNow, SAP et PayPal font partie des plus de 100 supporters.
Ensemble, MCP + A2A forment le stack de communication standard des agents d’entreprise. Un agent peut utiliser MCP pour accéder aux outils et A2A pour se coordonner avec d’autres agents — quel que soit le fournisseur qui l’a construit.
Mais le support du protocole seul n’est pas de la gouvernance. Vous avez aussi besoin de :
Ce que la gouvernance inter-fournisseurs requiert vraiment
Une couche de gouvernance qui fonctionne à travers tous les fournisseurs nécessite cinq capacités :
1. Connectivité agnostique du protocole
La couche de gouvernance doit parler à la fois MCP et A2A. Certains fournisseurs utilisent l’un, certains l’autre, certains les deux. Votre couche de gouvernance ne peut pas prendre parti — elle doit faire le pont entre les deux protocoles.
2. Politiques agnostiques du fournisseur
Les portes d’approbation, le RBAC, les contrôles budgétaires et les règles d’escalade doivent s’appliquer de manière cohérente, que l’agent s’exécute dans Salesforce, ServiceNow ou un framework personnalisé. « Les agents du fournisseur X nécessitent une approbation pour les actions supérieures à 1 000 $ » devrait être une seule politique, pas cinq configurations spécifiques à chaque fournisseur.
3. Mémoire unifiée
Les agents de différents fournisseurs travaillant avec le même client, projet ou département ont besoin d’un contexte partagé. Une hiérarchie de mémoire à 5 couches — entité, conversation, workflow, département et système de fichiers virtuel — qui s’étend à travers toutes les plateformes d’agents.
4. Piste d’audit consolidée
Un seul journal d’audit qui capture chaque action d’agent à travers chaque fournisseur. Qui a approuvé quoi, quand et pourquoi. Quel agent a accédé à quelles données. Quel était le coût. Exportable vers votre infrastructure de conformité existante.
5. Orchestration au niveau département
Les départements d’entreprise ne correspondent pas proprement aux frontières des fournisseurs. Le juridique utilise des agents de deux fournisseurs. La finance en utilise trois. La couche de gouvernance doit organiser les agents par département, pas par fournisseur — parce que c’est ainsi que l’entreprise pense.
Le marché valide l’urgence
Les chiffres racontent l’histoire :
- 88 % des dirigeants augmentent leur budget IA pour l’IA agentique (Capgemini)
- 79 % disent que les agents IA sont déjà adoptés dans leur organisation
- 100+ entreprises supportent le protocole A2A, signalant que la coordination multi-fournisseur d’agents est une priorité industrielle
Ce n’est pas de la demande théorique. Les entreprises déploient activement des agents de multiples fournisseurs et découvrent que la gouvernance est la couche manquante.
L’approche de JieGou
JieGou est conçu comme la couche de gouvernance au-dessus des plateformes d’agents spécifiques aux fournisseurs :
- Pont dual-protocole : Supporte à la fois MCP (245 serveurs certifiés avec certification à 3 niveaux) et A2A (hôte, consommateur et registre) à travers une seule couche de gouvernance
- Gouvernance à 10 couches : Portes d’approbation, RBAC, journalisation d’audit, chiffrement BYOK, contrôles budgétaires, détection d’injection de prompts et autonomie graduée — appliqués de manière cohérente sur chaque agent
- Hiérarchie de mémoire à 5 couches : Mémoire d’entité, de conversation, de workflow, de département et de système de fichiers virtuel partagée entre tous les agents quel que soit le fournisseur d’origine
- Couverture de 20 départements : Packs départementaux pré-construits pour Ventes, Marketing, Support, RH, Finance, Opérations, Juridique, Ingénierie, Direction, IT, Gestion de Produit, R&D, Produit, Réussite Client et Données & Analytique
- Architecture inter-fournisseurs : JieGou se positionne au-dessus de Salesforce, Microsoft, Google, ServiceNow et des plateformes d’agents personnalisées, fournissant une gouvernance unifiée sans remplacer aucune d’entre elles
Ce que cela signifie pour les architectes d’entreprise
Si vous concevez l’architecture d’agents de votre entreprise, considérez ces principes :
-
Ne confondez pas capacité d’agent et gouvernance d’agent. Salesforce est excellent pour construire des agents commerciaux. Cela n’en fait pas le bon choix pour gouverner tous vos agents.
-
Planifiez le multi-fournisseur dès le premier jour. Même si vous commencez avec un seul fournisseur d’agents, vous en ajouterez d’autres. Votre architecture de gouvernance devrait supposer le multi-fournisseur.
-
La conformité aux protocoles compte pour les achats. L’adhésion à l’AAIF croît (Salesforce, SAP, PayPal, Samsung). La conformité aux standards devient une case à cocher dans les achats.
-
La gouvernance est une couche séparée. Tout comme vous n’utilisez pas votre CRM comme fournisseur d’identité, vous ne devriez pas utiliser votre CRM comme plateforme de gouvernance d’agents.
Prêt à voir comment fonctionne la gouvernance unifiée à travers les fournisseurs ?
- Voir le diagramme d’architecture — Architecture de gouvernance inter-fournisseurs de JieGou
- Passer l’évaluation de gouvernance — Évaluez votre préparation à la gouvernance multi-fournisseur
- Démarrer un essai Enterprise — Essai de 14 jours avec toutes les fonctionnalités de gouvernance