Les protocoles agentiques se développent rapidement et sont en cours de standardisation. Essayons d’y voir un peu plus clair sur leurs périmètres et leur utilités respectives.
A. Les protocoles agentiques
Les protocoles agentiques se développent parce que les LLM ne sont plus seulement des modèles de texte, mais deviennent des agents logiciels capables de :
- raisonner sur la durée
- interagir avec des outils
- coopérer avec d’autres agents
- dialoguer avec des humains
- agir dans des environnements réels
Or, dès qu’un agent sort du simple « prompt réponse », des standards deviennent nécessaires. Les protocoles ci-dessous répondent chacun à une couche différente du problème.
1. MCP — Model Context Protocol
Le Model Context Protocol part d’un constat simple mais fondamental :
un agent n’est pas intelligent uniquement par son modèle, mais par le contexte qu’on lui donne et les actions qu’on lui autorise.
Historiquement, le contexte était injecté dans le prompt :
- fichiers collés en texte
- instructions longues
- descriptions d’API écrites à la main
Or cela ne passe pas à l’échelle. MCP, initié par Anthropic, introduit une séparation nette entre le raisonnement et le monde extérieur.
Ce que fait MCP
MCP définit un protocole standard par lequel un agent peut découvrir dynamiquement :
- des données (resources)
- des actions possibles (tools)
- leurs schémas exacts
Sans que ces éléments soient codés en dur dans le prompt. Un serveur MCP expose par exemple :
- un système de fichiers
- une base de données
- une API métier
- un environnement d’exécution
Le modèle n’a pas besoin de savoir comment ça marche :
- il sait ce qui est disponible
- quels paramètres fournir
- quel type de résultat attendre
Avec MCP, le prompt est allégé et l’agent peut s’adapter à des environnements inconnus. On passe d’un LLM à un agent outillé.
Exemple dans un IDE moderne :
- MCP expose :
- le dépôt Git
- les tests
- les tickets
- le linter
- l’agent :
- lit le code
- exécute un test
- corrige une fonction
- vérifie l’impact
Tout cela sans jamais recevoir le dépôt en texte brut.
2. A2A Agent-to-Agent Protocol
Si MCP répond à la question « comment un agent interagit avec son environnement », A2A répond à une autre question clé :
comment plusieurs agents collaborent-ils entre eux ?
Le protocole Agent-to-Agent est porté notamment par Google, dans une vision très distribuée des systèmes d’agents.
Le problème que résout A2A
Dans un système multi-agents :
- chaque agent a un rôle
- une spécialisation
- parfois un fournisseur ou un modèle différent
A2A définit donc un langage commun d’échange entre agents.
Fonctionnement conceptuel
A2A permet :
- de découvrir d’autres agents
- de comprendre leurs capacités
- de leur déléguer une tâche
- de recevoir un résultat structuré
Ce protocole est orthogonal au modèle : un agent Gemini, un agent GPT, un agent open-source peuvent coopérer tant qu’ils parlent A2A.
Exemple
Dans une entreprise :
- un agent “Marché” détecte une opportunité
- il contacte un agent “Juridique” pour vérifier la conformité
- puis un agent “Finance” pour estimer le ROI
Chaque agent raisonne localement, mais la tâche est collective.
3. ACP Agent Communication Protocol
L’Agent Communication Protocol, soutenu par IBM, est plus ancien dans son esprit et plus formel. Là où A2A est pragmatique et orienté orchestration, ACP est orienté dialogue structuré et négociation.
Ce que ACP apporte de spécifique
ACP définit :
- des actes de communication explicites :
- proposer
- accepter
- refuser
- informer
- s’engager
- des séquences de dialogue normées.
Il permet :
- des négociations contractuelles
- des raisonnements collectifs vérifiables
- une meilleure auditabilité
Pourquoi c’est important
Dès qu’un agent :
- négocie un prix
- engage une ressource
- prend un engagement durable
On ne peut plus se contenter d’un simple appel de fonction. ACP introduit une dimension sociale et juridique dans les systèmes agentiques.
Exemple
Dans une supply chain :
- un agent fournisseur propose un délai
- un agent client refuse
- un compromis est négocié
- un engagement est formalisé
Le protocole ACP structure la conversation, pas seulement les messages.
4. A2UI — Agent-to-User Interface
A2UI part d’un principe essentiel :
un agent autonome sans interface humaine est dangereux ou inutilisable.
Ce protocole s’intéresse à la relation agent / utilisateur, pas au modèle.
Ce que fait A2UI
A2UI définit comment un agent :
- affiche une information
- demande une confirmation
- explique une décision
- sollicite une action humaine
Il abstrait l’interface :
- web
- mobile
- desktop
- voix
- wearable
Ce que ça change
Sans A2UI :
- l’agent agit sans consultation de l’utilisateur
- ou doit dépendre d’une UI codée sur mesure
Avec A2UI :
- l’agent devient collaboratif
- l’humain reste dans la boucle
- les décisions sont explicables / démontrables
Exemple
Un agent financier :
- détecte une anomalie
- affiche un résumé clair
- propose une action
- attend une validation explicite
L’agent ne remplace pas l’humain, il l’assiste intelligemment.
5. UCP / AP2 — Protocoles de contrôle et de gouvernance
UCP et AP2 ne sont pas encore des standards stabilisés, mais ils émergent afin de répondre à une inquiétude centrale :
qui contrôle réellement l’agent ?
Ces protocoles visent la gouvernance agentique.
Le problème traité
Quand un agent peut :
- agir seul
- appeler des API
- déclencher des paiements
- modifier des systèmes
il faut définir :
- ce qu’il a le droit de faire
- dans quelles limites
- avec quelle traçabilité
Ce que ces protocoles cherchent à formaliser
Ils introduisent :
- des permissions fines
- des niveaux d’autonomie
- des journaux d’actions
- des mécanismes de révocation
On passe d’un agent “magique” à un agent responsable et contrôlable, dans l’esprit des exigences réglementaires modernes.
Exemple
Un agent personnel :
- peut lire les mails
- peut proposer une action
- mais ne peut jamais l’exécuter sans validation
Chaque action est :
- explicable
- loggée
- réversible
6. Les composants d’une architecture
Ces protocoles ne sont pas concurrents, ils sont complémentaires :
- MCP : renseigne l’agent sur les actions qu’il peut mener (il rebouche le gouffre d’action)
- A2A / ACP : permettent aux agents de coopérer
- A2UI : relie l’agent à l’humain
- UCP / AP2 : garantissent le contrôle et la confiance
Ensemble, ils dessinent l’architecture des systèmes intelligents de demain, où les agents ne sont plus des gadgets conversationnels, mais de véritables acteurs logiciels.
B. Ces protocoles structurent les produits
Ce qui frappe dans la montée en puissance des protocoles agentiques, ce n’est pas leur diversité, mais la confusion persistante entre capacité technique et valeur produit. MCP, A2A, ACP, A2UI, UCP, AP2 sont souvent présentés comme des briques interchangeables, alors qu’ils incarnent des visions profondément différentes de la relation entre automatisation, expérience utilisateur et business.
Regardés à travers une grille e-commerce ces protocoles ne répondent pas aux mêmes problèmes. Certains optimisent l’exécution, d’autres la décision, d’autres encore tentent de stabiliser un cadre d’expérience. Ce sont ces arguments là qu’il faut lire.
1. Quand la valeur est surtout interne : MCP et A2A
Dans un e-commerce (exemple de bricolage), une grande partie de la complexité ne se voit pas. Elle se situe dans la préparation des commandes, la synchronisation des stocks, la gestion des contraintes logistiques.
Un protocole comme MCP excelle précisément à cet endroit.
Lorsqu’un client valide un panier combinant carrelage, colle compatible, joints et livraison fractionnée, MCP permet à des systèmes hétérogènes (PIM, OMS, stock, transport) de s’orchestrer automatiquement : vérification des compatibilités, ajustement des dates, réservation de stock. La valeur est nette : moins d’erreurs, moins de SAV, moins de coûts.
Mais cette valeur reste invisible pour l’utilisateur qui ne vie que l’expérience globale. Le raisonnement n’est ni exposé, ni explicable. Si une date change ou si un prix évolue, l’utilisateur ne dispose d’aucun cadre pour comprendre. Tant que tout fonctionne, ce n’est pas un problème. Dès qu’une friction apparaît, l’opacité devient un risque.
A2A fonctionne sur une logique proche, mais côté organisation.
Dans un contexte SAV, un conseiller peut déclencher un enchaînement d’agents : analyse de l’historique client, détection d’un défaut produit récurrent, proposition d’un geste commercial. Le gain est réel en efficacité et en temps de traitement. Mais, là encore, côté client, la décision semble arbitraire. Le protocole optimise la coordination interne, pas la lisibilité externe.
Ces protocoles créent donc de la valeur, mais une valeur structurelle et non expérientielle.
2. Quand la décision devient trop impactante pour rester invisible : ACP et AP2
Ces protocoles déplacent le centre de gravité vers la décision elle-même.
Avec ACP, il devient possible de générer des ensembles complexes : un projet “refaire une salle de bain”, incluant produits, quantités, étapes, arbitrages de coût et de disponibilité. Sur le papier, la promesse est forte : panier moyen élevé, cross-sell optimisé, cohérence globale.
Mais dès que l’on observe l’expérience réelle, des questions apparaissent. L’utilisateur reçoit une proposition globale sans toujours comprendre :
- pourquoi tel carrelage plutôt qu’un autre
- quelles hypothèses ont été retenues
- ce qui se passe s’il modifie un élément
La puissance décisionnelle devient un problème UX. La moindre remise en question fragilise l’ensemble. La réversibilité est faible, la confiance conditionnelle.
AP2 pousse encore plus loin cette logique. Dans un cadre expérimental, par exemple un assistant “expert travaux” pour clients avertis, le protocole permet des raisonnements sophistiqués, multi-critères. Mais cette sophistication a un coût : implémentations spécifiques, dépendance forte aux équipes IA, difficulté à industrialiser et à maintenir. AP2 est un excellent laboratoire, mais un standard produit fragile.
Ces protocoles brillent par leur intelligence décisionnelle, mais peinent à fournir un cadre compréhensible et donc assumable face à l’utilisateur.
3. Quand le protocole devient un cadre d’expérience : A2UI et UCP
La bascule la plus intéressante se produit lorsque le protocole cesse d’être un moteur caché pour devenir un organisateur explicite de l’interaction.
Avec A2UI, l’agent n’est plus seulement décisionnaire, il est l’interface
Dans un parcours de conception de cuisine, chaque action est formulée, expliquée, soumise à validation. La recommandation est distincte de l’action. L’ajout au panier n’est jamais implicite. Les moments critiques (ex : modification, suppression, engagement financier ) sont cadrés par des confirmations explicites.
Ce déplacement change profondément la relation utilisateur :
- le raisonnement devient visible
- l’erreur devient corrigeable
- la confiance n’est plus aveugle mais négociée
UCP va encore plus loin en structurant non pas une interaction, mais une intention dans la durée.
Un projet “rénover une terrasse” peut commencer en ligne, se poursuivre en magasin avec un vendeur, puis être repris plus tard pour une commande ou un SAV. Le protocole ne transporte pas seulement des actions, mais un cadre : contraintes, hypothèses, décisions déjà prises.
Pour le business, l’impact est majeur : continuité omnicanale, réduction des redites, meilleure conversion sur des cycles longs. Pour l’utilisateur, l’expérience n’est plus fragmentée. Le projet existe indépendamment du canal.
4. Ce que révèle la comparaison
Ce que cette comparaison met en lumière, ce n’est pas un “meilleur protocole”, mais des niveaux de responsabilité différents.
- MCP et A2A optimisent l’exécution
- ACP et AP2 optimisent la décision
- A2UI et UCP structurent la relation entre décision, action et responsabilité
Dans un e-commerce de bricolage, où l’achat engage un projet, c’est ce dernier point qui devient décisif. Le protocole n’est plus une brique technique neutre. Il devient un choix de cadre : ce que l’on montre, ce que l’on explique, ce que l’on assume.
5. Tableau de synthèse
| Protocole | Valeur business principale | Cas d’usage pertinent |
|---|---|---|
| MCP | Réduction coûts, efficacité interne | Orchestration logistique, back-office |
| A2A | Productivité support, coordination | SAV, opérations internes |
| ACP | Panier moyen, cohérence projet | Recommandations globales |
| A2UI | Conversion, confiance, baisse abandon | Parcours projets guidés |
| UCP | Continuité omnicanale, projets longs | Vente de projets complexes |
| AP2 | Innovation, expertise avancée | Expérimentation, R&D |
6. L‘argumentation décisive
Nous sommes au début de l’histoire Agentique et il y a de nombreuses évolutions a venir. A date on peut néanmoins dire ceci :
Ce n’est pas un problème de performance, ni même d’intelligence. C’est un problème de cadrage.
Les protocoles agentiques qui compteront demain ne seront pas ceux qui décident le mieux, mais ceux qui permettent au produit d’expliquer, de limiter, de révoquer et d’assumer.
Dans un commerce de projets, comme le bricolage cette capacité n’est pas un supplément d’UX. C’est la condition même de la valeur.