Systems Design Meditation · Edition 2
Après les API
Pourquoi MCP annonce une nouvelle couche d'infrastructure
Edward Calderón
Architecte Logiciel
Les API ont interconnecté les logiciels. Les agents introduisent des logiciels qui doivent décider à quels logiciels se connecter.
Une intégration classique commence par une connaissance préalable : le développeur sélectionne un point de terminaison, étudie son schéma et écrit du code déterministe autour. L'appelant connaît le service et, le plus souvent, l'opération. Le logiciel agentique remet cette hypothèse en cause. Il peut lui falloir découvrir des capacités, comprendre leurs descriptions, choisir parmi elles et transporter du contexte au-delà de cette frontière.
De l'invocation à la découverte
REST, RPC et les flux d'événements restent essentiels. MCP ne les rend pas obsolètes. Il s'attaque à une autre couche : présenter des outils, des ressources et des prompts aux clients pilotés par des modèles, au moyen d'une interface partagée. L'opération sous-jacente peut toujours être un appel d'API, une requête en base de données ou un processus local.
Cette distinction est importante. La découverte ne se résume pas à un SDK plus élégant. Une machine qui sélectionne une capacité a besoin de noms et de descriptions qui soutiennent un raisonnement correct, de schémas qui contraignent les entrées, et de limites de sécurité explicites. Une description d'outil ambiguë est un défaut architectural, car elle modifie le comportement de sélection.
La spécification de MCP définit une architecture client-hôte-serveur et la négociation de capacités. Elle avertit également les implémenteurs de préserver le consentement, la confidentialité des données et la sécurité des outils. Ce sont là des indices sur la nouvelle couche : l'échange de contexte ne peut être dissocié de l'autorité.
Ce qui m'intéresse, ce n'est pas de savoir si MCP deviendra le protocole ultime. C'est le fait que l'interaction entre agents et systèmes soit devenue suffisamment importante pour exiger une couche protocolaire, tout simplement. Le protocole pourra évoluer. Le besoin, lui, demeurera.
Le plan de contrôle autour des outils
Un écosystème d'outils pour agents utile nécessite plus qu'un catalogue. Il exige un cycle de vie et une gouvernance. Qui a enregistré un outil ? Quelle version est active ? Quel tenant peut le voir ? La découverte implique-t-elle une autorisation, ou une simple prise de connaissance ? Comment les résultats sont-ils marqués comme non fiables ? Que se passe-t-il lorsqu'un serveur disparaît au milieu d'un flux de travail ?
Ce sont des questions de systèmes distribués. Les services tombent en panne indépendamment les uns des autres. Les schémas évoluent. Les nouvelles tentatives peuvent dupliquer des effets de bord. L'agent peut détenir un contexte obsolète. Un appel d'outil qui paraît atomique au modèle peut en réalité s'appuyer sur plusieurs opérations non atomiques.
Imaginez un agent d'exploitation choisissant entre des outils pour lire la télémétrie, créer un incident et modifier la capacité. La découverte devrait exposer les trois capacités, mais l'autorisation ne devrait pas être uniforme. La lecture peut être étendue. La création d'un incident devrait être idempotente. Les changements de capacité devraient exiger une politique plus stricte et inclure une plage délimitée. Un protocole partagé aide à décrire l'interface ; la plateforme doit néanmoins faire respecter la frontière.
Les frontières entre fournisseurs rendent tout cela d'autant plus important. Les organisations utiliseront plusieurs fournisseurs de modèles et des centaines de services internes et externes. Les adaptateurs sur mesure créent un couplage dans les deux sens. Une couche protocolaire permet à un outil d'évoluer sans que chaque client ait à apprendre son intégration privée, et à un client de changer sans que chaque service soit réécrit.
La normalisation sans mythologie
Les écosystèmes majeurs s'accélèrent souvent lorsque les interfaces deviennent prévisibles. Mais les analogies peuvent masquer davantage qu'elles n'expliquent. MCP n'est pas simplement « le nouveau HTTP ». HTTP transporte des représentations entre des composants en réseau. MCP définit des conventions pour le contexte et les capacités destinés aux modèles, en s'appuyant généralement sur des transports existants.
L'affirmation architecturale utile est plus modeste. Les interfaces standard réduisent le nombre d'accords bilatéraux nécessaires à la coopération entre composants. Elles ouvrent l'espace à l'outillage : registres, passerelles, moteurs de politiques, bancs de test et observabilité. Elles rendent également les défaillances comparables.
La normalisation ne crée pas automatiquement l'interopérabilité. Deux serveurs peuvent implémenter le même protocole tout en utilisant des sémantiques incompatibles. Un outil nommé `search` peut chercher dans les documents d'un client, sur le web public ou dans une base de données opérationnelle. La qualité sémantique, la provenance et la confiance restent des préoccupations à l'échelle du système.
Cela suggère une conception en couches. Utilisez les protocoles pour la découverte et l'échange. Utilisez l'identité et la politique pour l'autorisation. Utilisez des contrats de domaine pour le sens. Utilisez le traçage et les journaux d'audit pour l'imputabilité. Utilisez des API et des files d'attente ordinaires pour une exécution fiable. Aucune couche ne devrait prétendre résoudre les problèmes des autres.
Pour les développeurs, la valeur immédiate de MCP n'est donc pas une promesse d'universalité. C'est une pression concrète en faveur du découplage entre clients de modèles et implémentations d'outils. Cela rend l'expérimentation moins coûteuse et le remplacement plus réversible.
Les protocoles comptent parce qu'ils permettent aux systèmes d'évoluer indépendamment.