MCP : votre agent de code est aveugle sans ce protocole

Le jour où l'agent s'est bloqué sur un ticket Jira

Imaginez la scène : un ingénieur chez Block passe une matinée à regarder son agent de codage tourner en rond. L'agent comprend le problème — un bug dans le service de paiement — mais il ne peut pas consulter les tickets Jira pour retrouver le contexte d'origine, ni accéder au Datadog pour lire les métriques de production, ni interroger la base de code interne GitLab. Il a le modèle le plus puissant du marché entre les mains, et il est aveugle.

Ce n'est pas une fiction. C'est l'état de fait que l'équipe Goose de Block a documenté avant de déployer le Model Context Protocol en interne : avant MCP, chaque agent exigeait des intégrations sur mesure pour chaque outil. Jira, GitHub, les systèmes de déploiement, les bases de données, les API internes — chaque combinaison représentait un chantier distinct¹. Le résultat était un problème d'échelle classique : N agents multiplié par M outils donnait N×M intégrations à maintenir. Autrement dit, une dette technique qui croissait de façon quadratique avec l'adoption.

MCP n'est pas un framework de plus. C'est la couche manquante entre l'intelligence des agents et l'écosystème des outils. Comprendre pourquoi — et ce qu'il change en profondeur — est devenu une compétence d'architecte en 2026. C'est l'un des volets de notre série sur l'agentic coding en entreprise.

Le problème N×M que tout le monde évitait de nommer

Pendant les premières années du développement assisté par IA, les équipes ingénierie ont résolu le problème de l'accès aux outils de la même façon qu'elles résolvent tout problème pressant : en codant une solution ad hoc. Un connecteur pour GitHub ici, un wrapper d'API pour la base de données là, un script qui interroge Confluence en JSON. Ça fonctionne à la marge. Ça ne tient pas à l'échelle.

Block l'a mesuré concrètement avec leur plateforme Goose. 60 % de leurs équipes d'ingénierie utilisaient des agents IA régulièrement ; 3 200 agents personnalisés avaient été créés en interne ; 40 serveurs MCP étaient déployés pour couvrir l'accès aux outils¹. Ces chiffres racontent une histoire précise : sans protocole standardisé, la prolifération des agents engendre une prolifération équivalente des intégrations. Chaque équipe réinvente la roue, chaque agent porte sa propre couche de connectivité.

Le problème N×M est le nom technique de cette dynamique. Il n'existe qu'une façon de le résoudre : extraire la couche d'intégration du code des agents et la standardiser en protocole. C'est exactement ce que fait MCP.

MCP : définition d'un protocole ouvert pour agents

Le Model Context Protocol est un protocole ouvert qui permet aux agents IA de se connecter, accéder et interagir de manière sécurisée avec des outils externes, des sources de données et des API. Sa mission est précise : fournir aux agents un accès structuré et fiable au contexte et aux fonctionnalités au-delà de leurs données d'entraînement².

L'architecture est simple dans sa conception. Un serveur MCP expose trois types de primitives :

• Des outils (tools) : fonctions que l'agent peut invoquer — créer un ticket, exécuter un test, déployer une version.
• Des ressources (resources) : données structurées en lecture seule — la liste des PRs ouvertes, les logs d'une session, la documentation d'une API.
• Des prompts (prompts) : modèles réutilisables pour guider les interactions de l'agent avec l'utilisateur.

Ce qui change fondamentalement, c'est le mode d'interaction. Dans le web traditionnel, un navigateur parse du HTML, simule des clics, interprète des pixels. Un agent MCP, lui, découvre et invoque des outils de façon autonome, sur la base de schémas structurés². Il n'y a plus de fragile scraping, plus de parsing incertain. La précision des schémas remplace le polissage de la mise en page.

Pour l'architecte, cette bascule est décisive. On cesse de construire des interfaces pour des yeux humains, on commence à construire des interfaces pour des intentions de machine.

Au-delà du chat : quand les interfaces deviennent ambiantes

L'erreur la plus répandue sur MCP est de le voir comme un outil pour améliorer les chatbots. C'est une vision radicalement trop étroite. Block l'a formulé clairement : les interfaces conversationnelles ne sont que les roues d'apprentissage de l'UX agentique, pas sa forme finale¹.

Goose explore aujourd'hui des patterns d'interaction d'une autre nature :

Les agents ambiants observent le contexte en continu et proposent des actions sans que l'utilisateur les invoque explicitement. Un agent surveille vos alertes Datadog et ouvre automatiquement un ticket d'investigation dès qu'un seuil est franchi — sans que vous ayez formulé la moindre commande.

Les agents spatiaux apparaissent de façon contextuelle à l'intérieur de zones spécifiques de l'interface. Ils ne vivent pas dans une fenêtre de chat séparée ; ils émergent là où la donnée est présente.

Les agents de workflow sont embarqués dans des processus multi-étapes — validation de code, revue de sécurité, processus de release — comme des acteurs à part entière, pas comme des assistants optionnels.

Ce que MCP rend possible dans chacun de ces cas, c'est la connexion structurée entre l'intelligence de l'agent et le contexte opérationnel. Un agent ambiant sans MCP est un agent qui hallucine le contexte. Un agent ambiant avec MCP est un agent qui lit l'état réel du système.

Block note également des patterns d'interaction modale : des agents révélant progressivement leurs capacités (progressive disclosure), des mécanismes de visualisation du niveau de confiance de l'agent (confidence visualization), et des fonctions d'annulation systématique des actions (undo/rollback). Ces patterns ne sont pas anecdotiques — ils sont la condition de l'adoption en production. Un agent que l'on ne peut pas corriger est un agent que l'on n'adopte pas.

Peter Aideloje, dans son analyse publiée sur LogRocket, résume le changement de paradigme : les utilisateurs n'auront plus à naviguer, filtrer et remplir des formulaires. Ils exprimeront une intention, et les agents la réaliseront². MCP est le câblage qui rend cette délégation possible sans perte de fiabilité. Ce déplacement de paradigme a aussi des implications pour les développeurs eux-mêmes : construire des serveurs MCP bien définis est désormais une compétence aussi structurante que construire une bonne API REST l'était à l'ère microservices.

La question que les équipes évitent : qui est cet agent ?

MCP résout le problème de la connectivité. Il ne résout pas le problème de l'identité. Et c'est là que la plupart des déploiements en entreprise commencent à vaciller.

Considérez ce scénario : un ingénieur on-call chez Uber lance une investigation sur un incident de production. Il initie une session avec un Oncall Agent, qui délègue l'analyse à un Investigation Agent, qui lui-même interroge un Monitoring Agent avant d'accéder aux données via une MCP Gateway. La chaîne comporte trois hops. À chaque hop, la question se pose : qui agit exactement, et au nom de qui ?

Les équipes sécurité d'Uber (Matt Mathew, Prasad Borole, Meng Huang et al.) ont nommé le problème avec une précision chirurgicale : « Execution context — originating user, intermediate agents — is dropped across agent hops »³. Les pistes d'audit deviennent incomplètes. Les politiques d'accès granulaires ne peuvent plus être appliquées de façon cohérente. Le système ne peut pas raisonner sur la chaîne complète des acteurs qui ont initié une requête.

La définition qu'Uber propose de l'agency est devenue une référence dans la doctrine : « An agent is best defined as an entity that is authorized to act for or in the place of another. » Cette formulation pose la délégation — et non l'autonomie — comme propriété fondatrice. Ce détail change tout à l'architecture de sécurité.

Zero Trust pour les agents : la doctrine single-hop d'Uber

Face à ce problème, Uber a construit une extension de son architecture Zero Trust existante, déployée aujourd'hui pour plusieurs milliers d'agents internes. L'architecture comporte six composants nommés³ :

Un Agent Registry sert de source de vérité pour les mappings entre agents et workloads. Un AI Agent Mesh constitue le plan de données pour la communication inter-agents. Un Security Token Service (STS) émet des JWT courts et scopés. Une MCP Gateway joue le rôle de point d'application des politiques pour l'invocation des outils. Une AI Gateway médiatise les appels aux modèles IA externes avec des guardrails de sécurité. SPIRE — projet CNCF graduated — fournit les credentials workload cryptographiquement signés.

La doctrine pivot est formulée en une ligne : « Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. »³

Ce que cela signifie opérationnellement : chaque JWT est valide uniquement pour une destination spécifique, pour une durée de quelques minutes. Un token volé a un blast radius minimal. Il n'existe pas de bearer token réutilisable entre services — contraste direct avec OAuth classique.

La chaîne des acteurs (actor chain) est la pièce centrale du dispositif. Dans le walkthrough d'Uber, la MCP Gateway reçoit un JWT portant l'actor chain [user1, oncall-agent, investigation-agent] — une liste vérifiable de tous les participants à la requête. Les décisions d'accès au niveau de chaque outil sont basées sur l'historique complet, pas seulement sur l'identité du dernier agent appelant.

Le tout fonctionne. La preuve : « P99 latency for the STS Token Exchange API is consistently below 40 milliseconds. »³ L'overhead sécurité n'est pas un prétexte pour ralentir l'adoption. C'est un point que nous approfondissons dans notre volet sur la sécurité de l'agentic coding.

Les risques réels et les angles morts du déploiement

Le tableau ne serait pas honnête sans les zones d'ombre. Uber lui-même les identifie.

La migration des agents legacy est un chantier de longue haleine. Les agents existants, construits avant que l'architecture d'identité soit disponible, doivent être refactorisés progressivement. Ce travail n'a pas de raccourci.

Les coûts de l'architecture restent opaques. Uber ne publie pas le nombre de serveurs STS nécessaires, ni le volume de JWT émis par jour, ni la charge réseau du per-hop token exchange à l'échelle de milliers d'agents. Ces chiffres seraient utiles pour dimensionner un déploiement similaire.

Le protocole A2A sur lequel repose le Standardized A2A Client d'Uber est encore un draft. Le risque d'adopter une dépendance sur un standard qui peut évoluer est réel, même si l'alignement sur SPIFFE/SPIRE (CNCF graduated) et RFC 8693 (OAuth 2.0 Token Exchange) ancre l'architecture sur des fondations solides.

La question de la confiance des utilisateurs reste entière. Un agent qui agit en votre nom sur dix outils différents demande un niveau de confiance qui ne se décrète pas — il se construit, par la transparence de l'actor chain, par les mécanismes de confirmation sur les actions à fort impact, par l'observabilité temps réel. Block l'a appris avec Goose : les développeurs adoptent les agents si les agents restent prévisibles et réversibles, pas seulement s'ils sont puissants.

Il y a aussi un risque d'ordre GDPR et vie privée que l'article d'Uber n'adresse pas. L'actor chain transporte nommément le lignage de chaque requête : un ingénieur on-call est traçable dans tous les hops. Cette traçabilité est une fonctionnalité du point de vue de l'audit, mais elle soulève des questions sur la rétention des données personnelles dans les logs d'infrastructure — un angle que les équipes juridiques et DPO devront adresser avant de passer à l'échelle.

Enfin, les équipes ne doivent pas sous-estimer la complexité de débogage des architectures multi-agents. Tracer une défaillance à travers une chaîne d'agents qui s'invoquent mutuellement via des serveurs MCP différents, avec des tokens éphémères et des actor chains partielles, est un problème d'observabilité non trivial. L'investissement dans des outils de tracing distribué n'est pas optionnel dans ces architectures.

Ce que SFEIR observe en pratique : Context Engineering et Harness

Dans les accompagnements SFEIR auprès de clients comme Société Générale, EDF ou Airbus, le même pattern revient : les équipes qui déploient des agents de codage se heurtent rapidement à la question du contexte et de l'accès aux outils. MCP donne une réponse structurelle à la seconde ; le Context Engineering — tel que SFEIR le théorise — donne une réponse à la première.

Le Context Engineering n'est pas du prompt engineering augmenté. C'est la discipline qui consiste à nourrir les agents avec le contexte exact dont ils ont besoin : mémoire persistante cross-sessions (Warm memory), knowledge base récupérée à la demande via des serveurs MCP (Cold memory), état courant injecté en session (Hot memory). La formule de Patrick Debois reste la plus juste : « Chaque session est un nouvel employé qui repart de zéro » — MCP est ce qui lui permet de ne pas repartir de zéro.

La progression logique que SFEIR observe sur le terrain va de : prompt engineering (interaction isolée, ROI linéaire) → context engineering (environnement global, ROI composé) → Harness Engineering (l'équation Agent = Modèle + Harnais, où le harnais intègre désormais une couche d'identité orientée machine, en plus des guides feedforward et des sensors feedback).

MCP est, dans ce cadre, une brique du harnais. Il n'est pas suffisant seul. Mais sans lui, le harnais est borgne.

Points clés

• MCP résout le problème N×M : au lieu de N agents × M intégrations ad hoc, les outils exposent un serveur MCP une seule fois et tout agent compatible peut y accéder. Block l'a validé avec Goose et 40+ serveurs MCP déployés en interne¹.
• MCP n'est pas un protocole de chatbot : Block documente des patterns d'interfaces ambiantes, spatiales et de workflow où l'agent agit sans être explicitement invoqué — MCP est le câblage structuré qui rend cette autonomie fiable¹.
• La MCP Gateway devient un point d'application des politiques de sécurité : dans l'architecture Uber, chaque invocation d'outil passe par une gateway qui vérifie l'actor chain complète — pas seulement l'identité du dernier agent appelant³.
• La doctrine single-hop, short-lived tokens est la réponse d'Uber au problème de provenance dans les workflows multi-agents : des JWT avec TTL en minutes, audience-specific, portant la chaîne d'acteurs vérifiable. P99 latency < 40ms en production³.
• L'identité orientée machine nécessite un nouveau modèle : les frameworks IAM classiques couvrent les humains et les workloads, mais pas l'agency au sens Uber — « an entity authorized to act for or in the place of another ». Les RSSI qui déploient des agents sans adresser ce gap créent des angles morts d'audit³.
• La séquence pratique pour les équipes : (1) standardiser l'accès aux outils internes via des serveurs MCP, (2) construire une couche de context engineering qui alimente les agents en mémoire persistante, (3) ajouter une couche d'identité agent avant de passer à l'échelle — dans cet ordre, pas l'inverse.
• Les serveurs MCP conçus pour la compréhension machine ont des exigences différentes des APIs REST classiques : contrats stricts, gestion explicite des erreurs, métadonnées riches, et sécurité pensée dès la conception (permissions, pistes d'audit, limitation de débit) plutôt qu'ajoutée après coup².

Sources

1. Block / Goose, MCP UI: The Future of Agentic Interfaces — block.github.io, 25 août 2025.
2. Peter Aideloje (LogRocket), MCP is replacing the browser — blog.logrocket.com, 15 septembre 2025.
3. Uber Engineering, Solving the Agent Identity Crisis — uber.com, 21 mai 2026.