Pourquoi l’infra agents devient un sujet de comité de direction
Les enquêtes dirigeants (PwC et autres) montrent le même schéma : budgets IA en hausse, agents adoptés, mais peu d’organisations connectent réellement les agents entre workflows et fonctions — or c’est là que se situe le saut de valeur.
Sans couche d’interopérabilité, chaque projet recrée ses connecteurs, ses droits et ses logs. Le résultat est prévisible : sprawl, coûts de maintenance, impossibilité d’auditer, et lock-in fournisseur sur les connecteurs critiques (CRM, identité, facturation).
À retenir
Principe d’architecture : séparer « intelligence » (modèle) et « capacité d’agir » (outils, données, permissions). C’est la condition pour changer de modèle demain sans reconstruire toute l’entreprise.
MCP en langage dirigeant
Le Model Context Protocol formalise comment un agent découvre et utilise des outils et contextes (bases, APIs, fichiers). Pour une organisation, cela se traduit en trois bénéfices concrets.
- Réutilisation : un connecteur CRM sert plusieurs agents, pas un projet jetable.
- Permissions plus explicites : scopes et accès deviennent des objets d’architecture, pas des secrets dans un prompt.
- Écosystème : moins de glue code interne, plus de serveurs/connecteurs standardisés.
A2A : de l’agent isolé au système de spécialistes
L’agent-to-agent permet à des agents spécialisés de collaborer (recherche, analyse, exécution, contrôle) sans monolithe central opaque. Le transfert de A2A vers l’Agentic AI Foundation signale une volonté de standard ouvert — pertinent si vous refusez d’être prisonnier d’une stack unique.
Pour une PME, A2A n’est pas un projet « à lancer demain ». C’est un critère d’achat et de design : vos futurs agents doivent pouvoir échanger des contrats d’entrée/sortie clairs, sous orchestration contrôlée.
Architecture cible simplifiée (lisible en PME)
Les plateformes agentiques d’entreprise que décrivent McKinsey QuantumBlack ou les SI majeurs convergent vers cette idée de « glue layer » : composable, observable, multi-fournisseur. Même une PME de 30 personnes peut viser une version allégée de ce schéma — plutôt qu’un Zapier spaghetti sans propriétaire.
- Couche identité & secrets : comptes techniques, SSO, vault.
- Couche outils / MCP : CRM, messagerie, fichiers, knowledge base.
- Couche agents : agents métier bornés + orchestrateur.
- Couche gouvernance : logs, budgets, evaluation, allowlists.
Critères d’achat et anti-lock-in
- Le fournisseur expose-t-il des protocoles ouverts ou uniquement son SDK propriétaire ?
- Peut-on auditer chaque appel outil (qui, quoi, quand, avec quel contexte) ?
- Les connecteurs critiques (CRM, facturation) sont-ils portables si vous changez de modèle ?
- Existe-t-il une stratégie multi-agents sans tout réécrire ?
À retenir
Ne pas attendre le « standard parfait » pour démarrer un lighthouse. Mais refuser les lock-in évidents sur l’identité, le CRM et les logs d’audit.
Questions fréquentes
Faut-il maîtriser MCP pour déployer un premier agent ?
Non au jour 1 d’un lighthouse. Oui dès que vous industrialisez plusieurs agents ou que vous choisissez une plateforme : l’interopérabilité devient alors un critère d’achat aussi important que la qualité du modèle.
MCP/A2A remplacent-ils Make ou n8n ?
Pas immédiatement. Ils coexistent : l’automatisation événementielle reste utile. MCP/A2A adressent surtout l’accès outils des agents et la collaboration entre agents — une couche au-dessus ou à côté de l’iPaaS.
Quel risque si on ignore totalement le sujet ?
Sprawl d’agents, coûts de reconnectique, impossibilité de prouver conformité (RGPD / AI Act), et migration douloureuse dans 18 mois. C’est exactement le piège « tout Zapier » des années précédentes, version agents.
À retenir
En 2026, la valeur durable bascule de « quel modèle » vers « quelle infra agents ». MCP/A2A et les standards ouverts sont le langage de cette couche. Concevoir pour l’interopérabilité maintenant évite le spaghetti de demain.