MCP, une techno prometteuse mais à remettre à sa place

Comme le rappelle la dernière enquête d’Open Garden, MCP, AdCP et AAMP ne s’opposent pas réellement. Ils occupent des niveaux différents dans les futures architectures publicitaires pilotées par des agents IA. La nuance mérite d’être martelée tant la formulation initiale du marché (“le marché bascule de l’un vers l’autre”) a entretenu la confusion.

Pour le dire autrement : AdCP cherche à créer un nouveau canal de transaction agentique, là où MCP standardise l’accès aux canaux qui existent déjà. L’un travaille sur la couche transactionnelle, l’autre sur la couche d’infrastructure. Les deux sont complémentaires, et le marché aura probablement besoin des deux.

Comme expliqué dans l’article, un MCP, c’est avant tout un wrapper d’API. Cela revient plus ou moins à donner à un LLM un accès direct à une API avec un peu de documentation supplémentaire. L’intérêt, c’est que c’est souvent “plug-and-play “ : le MCP élude une partie des complexités techniques de l’API sous-jacente.

Les points forts sont évidents : simplicité d’utilisation, déploiement rapide, peu de connaissances techniques requises sur l’outil sous-jacent.

Mais il y a des limites importantes que le marché sous-estime aujourd’hui :

Le contrôle des actions. Techniquement, on peut donner des droits limités au LLM sur l’usage du MCP, donc le contrôle n’est pas binaire en soi. Le problème, c’est plutôt que l’humain le devient rapidement : à force de se voir demander une validation toutes les 15 secondes, il finit par accorder tous les droits par lassitude. La perte de contrôle ne vient pas de la techno mais de l’expérience utilisateur.

Le traitement multi-outils. Si je dois interagir avec plusieurs outils - par exemple récupérer des données chez X et Y, les croiser, puis envoyer le résultat à Z - tout se passe aujourd’hui dans la fenêtre de contexte du LLM. Cela génère des volumes de tokens très conséquents et augmente significativement le risque d’erreurs ou d’hallucinations.

L’économie du modèle. Ces volumes de tokens deviennent aussi rapidement un sujet de coût, dès que l’on commence à multiplier les outils et les étapes de traitement. À grande échelle, cela oblige rapidement à mieux orchestrer les flux, limiter intelligemment le contexte manipulé par le LLM et structurer plus finement les interactions entre les outils.

L’absence de tiers de confiance. Claude ou un autre LLM exécute les actions directement depuis le chat, sans audit trail métier, sans workflow d’approbation multi-niveaux, sans gestion fine des permissions par utilisateur ou équipe. Pour un trader qui gère des budgets à six ou sept chiffres, ce n’est pas suffisant.

Pour l’adtech, MCP est l’équivalent d’une API

Vous l’aurez donc peut-être compris, dans le contexte adtech, un MCP est exactement comme une API : un moyen d’accéder programmatiquement aux outils et plateformes existantes. Ni plus, ni moins.

Je ne crois pas, en l’état actuel, à la solution “LLM + MCP seul” pour des cas d’usage de production, surtout dès qu’on commence à faire interagir plusieurs MCP ensemble, ce qui est exactement le besoin réel en adtech (croiser DSP, outils de mesure, clean rooms, adservers). Le pattern “LLM + MCP nu dans un chat” ne scale pas.

En revanche, le pattern “LLM + couche applicative + MCP/API” scale très bien. C’est précisément ce qu’on construit chez Concord, avec une couche d’orchestration entre le LLM et les outils, qui gère le scheduling des jobs, la persistance des données, les workflows métier et le human-in-the-loop.

C’est cette couche intermédiaire qui transforme une démo sympa en plateforme déployable à grande échelle dans des équipes de trading. Sans elle, on reste dans du bricolage. C’est intéressant pour des power users qui veulent expérimenter, mais loin d’être suffisant pour industrialiser l’achat média assisté par IA.

Le faux choix copilot vs autonomie

L’article observe à juste titre que le marché converge vers une logique de copilot plutôt que d’agent totalement autonome. Mais cette opposition est en partie un faux débat .

Avec une bonne architecture incluant un “human-in-the-loop” bien pensé, on peut combiner automatisation poussée et validation humaine sur les décisions à enjeu. Le choix entre les deux disparaît dès lors qu’on construit la bonne couche d’orchestration au-dessus des MCP et des APIs.

Pourquoi je reste prudent sur AdCP, du moins pour le moment

J’ai du mal à voir comment ce protocole peut fonctionner de manière réellement autonome. Si un “buyer agent” négocie automatiquement avec un “seller agent” et que chacun repart avec une version différente du résultat, qui a raison ? Qui porte la responsabilité du dernier mot ? Qui tranche en cas de litige ?

Sans tiers de confiance ni mécanisme de réconciliation, on ne peut pas confier des budgets significatifs à ce type de protocole. Cela peut éventuellement servir à de la découverte d’inventaire ou à de la pré-qualification, mais l’automatisation complète du gré à gré agentique me paraît très long shot à court et moyen terme.

Cela dit, la version 3 du protocole, sortie récemment, commence à s’attaquer à certaines de ces questions. C’est plutôt bon signe, et il faudra suivre comment ces mécanismes évoluent concrètement dans les prochains mois.

Nicolas Cosson est le co-fondateur de Concord.