Vous avez probablement entendu parler de MCP. Model Context Protocol, la norme qui permet aux agents IA de communiquer avec des outils externes. Vous avez peut-être configuré un ou deux serveurs. Mais quelqu'un mentionne ensuite « le registre » et vous acquiescez comme si vous saviez ce que cela signifie.
La plupart des gens ne le savent pas. Pas précisément. Et ce manque de précision engendre de vrais problèmes dès lors que vous construisez un système qui doit réellement passer à l’échelle.
Voici ce qu’est réellement le registre MCP, ce qu’il n’est pas, et pourquoi les équipes qui l’ignorent aujourd’hui passent souvent beaucoup de temps à démêler du code spaghetti codé en dur plus tard.
Ce que la plupart des équipes découvrent six mois trop tard
- Le registre stocke des métadonnées et des pointeurs d’installation, pas des binaires de serveurs : ceux-ci résident dans npm ou PyPI.
- Sans registre, chaque connexion entre un agent et un outil constitue un endpoint codé à la main, qui échoue indépendamment dès que quelque chose change.
- L’adoption de l’IA en entreprise dépend d’une gouvernance soutenue par un registre : la découverte seule ne suffit pas.
Ce qu’est réellement le registre MCP (et ce qu’il n’est pas)
Le registre MCP est le dépôt centralisé officiel de métadonnées pour les serveurs MCP accessibles publiquement. Cette formulation est volontairement précise. Ce n’est pas un hôte d’exécution. Ce n’est pas un magasin de packages. C’est un dépôt de métadonnées.
Lorsqu’un auteur de serveur publie dans le registre, ce qui y est réellement ajouté correspond à des métadonnées structurées : le nom du serveur, sa description, son type de transport, ses informations de connexion et ses instructions d’installation encodées dans un schéma mcp.json. Le binaire réel du serveur ne va nulle part. L’artefact reste dans npm, PyPI ou le registre de conteneurs où il se trouve déjà. Le registre MCP sait simplement où le trouver et comment le décrire.
C’est l’idée reçue que je rencontre le plus souvent. Quelqu’un demande pourquoi il ne peut pas « télécharger un outil » depuis le registre, ou pourquoi un serveur MCP trouvé dans le registre ne s’exécute pas depuis l’URL du registre. Il ne s’exécute pas depuis cette URL. Cela n’a jamais été son rôle. Le registre est un plan de contrôle, pas un hôte.
Considérez-le comme la fiche d’un catalogue de bibliothèque. La fiche vous indique ce qu’est le livre, où il est rangé et s’il est disponible. Le livre se trouve sur l’étagère. Le catalogue est une chose totalement différente.
En avril 2026, le registre officiel sur registry.modelcontextprotocol.io comptait plus de 9 600 entrées répertoriées, Anthropic faisant état de plus de 10 000 serveurs publics actifs dans l’ensemble de l’écosystème. Cette ampleur explique en partie pourquoi un mécanisme de découverte structuré n’est plus optionnel.
L’architecture du registre : métaregistre, API et sous-registres
Le registre MCP n’est pas simplement un site web hébergé unique. Il s’agit d’une spécification accompagnée d’une implémentation de référence hébergée.
Comment le métaregistre stocke et fournit les métadonnées
Le registre fonctionne comme un métaregistre : une source unique de vérité pour les métadonnées structurées, tandis que les artefacts réels résident dans des registres de packages externes. Chaque entrée suit un schéma défini, généralement exposé via mcp.json, qui inclut les détails de connexion, les transports pris en charge (SSE, HTTP streamable), la configuration d’environnement et suffisamment de description pour qu’un agent ou un développeur puisse déterminer si le serveur est pertinent.
Ce que fournit le registre est un catalogue de pointeurs d’installation et de descriptions lisibles par machine. Ce n’est pas un dépôt de binaires. Vous l’interrogez pour savoir ce qui existe et comment l’obtenir. Vous vous rendez ailleurs pour l’obtenir réellement. Cette séparation est intentionnelle et importante pour la sécurité : le registre peut être modéré sans devenir un hôte de packages.
Sous-registres publics et privés
L’API du registre est une spécification, ce qui signifie que n’importe qui peut implémenter un registre conforme aux côtés ou en dessous du registre officiel. Les organisations ne sont pas limitées au registre MCP officiel. Elles peuvent gérer un sous-registre privé contenant des serveurs internes qui ne conviennent pas à une liste publique, et le fédérer avec le registre officiel afin que les agents bénéficient d’une surface de découverte unifiée.
Les espaces de noms et les sous-registres publics/privés permettent aux entreprises de définir ce qui est visible selon l’environnement, l’équipe ou le profil du développeur, sans tout regrouper dans une liste indifférenciée. Un espace de noms de préproduction présente des serveurs différents de ceux d’un espace de production. Le profil d’une équipe soumise à une habilitation de sécurité affiche des serveurs qu’un profil d’ingénierie général ne voit pas. Ce modèle de fédération permet à la spécification du registre de réduire la fragmentation entre les registres existants, plutôt que d’obliger tout le monde à repartir de zéro.
📊 En pratique :
Le registre officiel a été lancé en version préliminaire. Les équipes qui créent des systèmes de production devraient implémenter des sous-registres privés conformes pour leurs serveurs internes plutôt que d’attendre la disponibilité générale, car le modèle de fédération de la spécification le prend directement en charge et évite de dépendre d’un point unique.
Le problème N×M : pourquoi les agents IA ont besoin d’un registre à grande échelle
Voici l’échec de mise à l’échelle qui rend les registres nécessaires, formulé simplement.
Imaginez que vous avez cinq agents IA. Chacun doit appeler quatre outils MCP différents : un serveur Grafana, un serveur Gmail, un serveur Jira et une base de connaissances interne. Sans registre, chaque agent code en dur l’endpoint de chaque outil. Cela fait cinq agents multipliés par quatre outils : vingt connexions codées en dur distinctes. Chacune doit connaître l’endpoint exact, la configuration de transport et les détails d’authentification.
Votre nombre d’agents double ensuite pour atteindre dix. Vous ajoutez trois nouveaux outils. Vous arrivez à cinquante-deux connexions, toutes maintenues individuellement. Un outil déplace son endpoint. Vous le mettez à jour dans certains agents, mais vous en oubliez deux. Ces deux agents commencent à échouer d’une manière qui ressemble à des problèmes d’authentification, jusqu’à ce qu’une personne remonte la trace jusqu’à l’URL obsolète.
C’est le problème N×M. Comme l’explique TrueFoundry, sans registre, chaque nouvelle combinaison agent-outil exige une nouvelle connexion sur mesure, et le coût de maintenance augmente de façon multiplicative plutôt que linéaire.
Un registre brise cette multiplication. Les agents interrogent le registre pour découvrir ce qui est disponible et où. Les outils s’enregistrent une seule fois et peuvent être découverts par tout agent qui en a besoin. Le registre conserve la vérité sur les endpoints. Les agents n’ont plus à le faire eux-mêmes.
🤔 Réfléchissez-y :
Les équipes ignorent souvent la gouvernance par registre parce qu’« elles n’ont que quatre outils pour le moment ». Ce sont aussi ces équipes qui se retrouvent avec trente connexions codées en dur six mois plus tard, lorsque leur nombre d’agents triple. Les calculs N×M n’attendent pas que vous vous sentiez prêt.
Ce que permet le registre MCP : découverte, authentification et gouvernance
La découverte est la fonction évidente. La gouvernance est celle qui compte le plus à grande échelle.
Découverte d’outils pour les agents IA et les applications LLM
Un agent utilisant un registre n’a pas besoin de connaître à l’avance les outils MCP existants. Il interroge le registre dynamiquement et reçoit une liste de serveurs MCP disponibles avec suffisamment de métadonnées pour déterminer celui qui correspond à la tâche en cours. C’est la différence entre un agent qui ne peut appeler que les outils que son créateur a mémorisés lors de sa conception, et un agent qui peut trouver l’outil adapté à un nouveau contexte pour lequel il n’a pas été explicitement conçu.
En pratique : un agent de support client interroge le registre, trouve un serveur MCP Grafana pour les métriques d’infrastructure et un serveur MCP Gmail pour l’historique client, sélectionne les deux selon leurs descriptions et leurs schémas, puis poursuit son travail. Aucun endpoint n’était codé en dur dans l’agent. Le registre est l’infrastructure qui rend cela possible pour les applications IA à grande échelle.
Avec plus de 9 600 serveurs dans le registre officiel, la sélection manuelle a de fait cessé d’être une option. Le registre rend cet écosystème exploitable plutôt que simplement vaste.
Authentification et contrôle d’accès limité par espace de noms
Les registres contrôlent également les serveurs que les agents sont autorisés à voir. Un registre peut appliquer une authentification et des configurations limitées par espace de noms qui restreignent la visibilité des serveurs selon l’environnement, le rôle ou le profil du développeur.
AWS Q Developer, par exemple, applique des serveurs MCP placés sur liste d’autorisation via une URL de registre intégrée aux profils des développeurs. Un agent s’exécutant dans cet environnement ne voit que les serveurs MCP approuvés que le registre expose pour ce profil. Les serveurs hors de la liste d’autorisation n’apparaissent tout simplement pas. Il n’y a ni lutte autour de listes de refus ni rejet à l’exécution : la configuration détermine le périmètre de découverte avant même que l’agent n’effectue une requête.
Il s’agit d’un RBAC au niveau de la découverte, et pas seulement au niveau de l’exécution. Vous pouvez ainsi donner au profil d’agent d’un développeur junior l’accès à des outils de documentation et de recherche, tandis que le profil d’un ingénieur plateforme senior peut accéder aux serveurs d’infrastructure et de déploiement. Même registre, périmètres différents.
Gouvernance, modération et politiques de confiance pilotées par la communauté
Le registre constitue également un point de contrôle pour la sécurité. L’analyse d’InfoWorld sur l’adoption de MCP en entreprise le présente explicitement : le registre n’est pas seulement un catalogue d’outils, c’est un plan de contrôle central pour l’IA agentique. La position de MACH Alliance sur la gouvernance indépendante des fournisseurs va dans le même sens : la couche de gouvernance doit être indépendante du mécanisme d’application d’un fournisseur unique.
Concrètement, le registre officiel utilise une modération pilotée par la communauté pour signaler les serveurs qui semblent non vérifiés, qui usurpent l’identité de services légitimes ou qui n’ont pas été évalués selon des critères de sécurité de base. Les sous-registres d’entreprise peuvent y ajouter leurs propres workflows de validation internes. Avant qu’un serveur puisse être répertorié, il peut devoir passer des contrôles d’audit, avoir un propriétaire désigné et comporter une classification de risque documentée. Le registre devient le point d’application, et pas seulement le catalogue.
Où se situe le registre MCP dans une pile IA d’entreprise
Les équipes d’entreprise qui adoptent MCP à grande échelle commencent généralement par le même problème de découverte : quelqu’un doit trouver un serveur, ouvre onze onglets, ne sait pas quel registre fait autorité, puis finit par copier-coller une configuration depuis un fichier readme GitHub mis à jour pour la dernière fois il y a huit mois.
C’est à ce moment qu’un registre MCP d’entreprise devient une infrastructure plutôt qu’une commodité.
La couverture par InfoWorld de l’implémentation de MCP en entreprise décrit clairement le schéma : les organisations découvrent rapidement que les simples catalogues d’outils sont insuffisants. Elles ont besoin d’autorisations par agent, d’une observabilité approfondie du comportement des agents et d’une application des politiques en ligne à mesure que le nombre de serveurs MCP en fonctionnement augmente. JFrog, WorkOS, TrueFoundry et AWS ont tous abordé le registre comme une composante d’infrastructure axée d’abord sur la gouvernance, et non comme une commodité pour développeurs.
Le registre se situe entre vos agents et vos outils. Il centralise les métadonnées dont vos agents ont besoin pour prendre des décisions de routage, contient la logique de contrôle d’accès qui détermine quels agents atteignent quels serveurs MCP, et conserve la piste d’audit qui indique aux équipes de sécurité ce qui s’est passé après coup. Dans une pile IA d’entreprise, il s’agit de la couche amont du registre MCP : le plan où réside réellement la gouvernance.
Un modèle d’implémentation que j’ai vu fonctionner : une équipe plateforme chez Latenode crée un workflow qui récupère des entrées candidates depuis l’API du registre officiel, enrichit les métadonnées de chaque serveur à l’aide de l’un des plus de 1 200 modèles IA disponibles afin de générer des descriptions internes et des balises de risque cohérentes, puis écrit le résultat sélectionné dans un registre interne. Le même workflow s’exécute selon une planification afin de rester à jour à mesure que l’écosystème se développe. Six étapes, une exécution dans le modèle tarifaire de Latenode, et l’équipe cesse de consacrer des jours à la découverte manuelle. Le workflow ne remplace pas le registre. Il construit la couche de contrôle interne au-dessus de celui-ci.
Trois idées reçues qui continuent de compromettre les configurations de registre des équipes
Elles reviennent sans cesse. Les comprendre de travers dès le départ crée des problèmes pénibles à démêler plus tard.
Le registre héberge les serveurs et binaires réels
C’est l’idée reçue la plus courante. Les équipes s’attendent à trouver dans le registre des packages de serveurs exécutables, comme elles trouveraient des packages dans npm. Elles trouvent à la place des métadonnées : descriptions, schémas, types de transport et instructions d’installation pointant vers npm, PyPI ou un registre de conteneurs. Lorsqu’elles ne peuvent pas « exécuter » quelque chose depuis l’URL du registre, elles supposent qu’il est défaillant. Ce n’est pas le cas. Le registre est un dépôt de métadonnées. Le traiter comme une marketplace ou un magasin de packages signifie que vous cherchez la mauvaise chose au bon endroit.
Vous devez utiliser uniquement le registre MCP officiel
Le registre officiel sur
registry.modelcontextprotocol.ioest une implémentation de référence, et non le seul registre autorisé. L’API du registre est une spécification que toute organisation peut implémenter. Vous pouvez gérer un sous-registre privé pour les serveurs internes, le fédérer avec le registre officiel et offrir à vos agents une surface de découverte unifiée qui inclut les deux. Les équipes qui pensent être limitées au registre officiel finissent soit par exposer publiquement des serveurs internes, ce qui est une mauvaise idée, soit par maintenir un catalogue séparé et impossible à découvrir que les agents ne peuvent pas utiliser dynamiquement, ce qui est tout aussi problématique. Le registre officiel est une bonne source principale de vérité pour les serveurs MCP, mais pas la seule source.Les registres servent uniquement aux démonstrations et aux expérimentations, pas à la production
Le registre officiel a été lancé en version préliminaire, ce qui donne à certaines équipes une excuse pour reporter son adoption. Ce statut signifie que des réinitialisations de données et des changements incompatibles sont possibles avant la disponibilité générale, ce dont il convient de tenir compte dans la conception des systèmes de production. Mais c’est un argument en faveur de l’exécution d’un registre privé conforme offrant des garanties stables, et non un argument pour ignorer complètement la couche de registre. Les registres MCP que les équipes d’entreprise déploient aujourd’hui en production sont des implémentations privées de cette même spécification. La version préliminaire officiellement hébergée est une instance d’un modèle plus large qui est déjà adapté à la production dans les environnements d’entreprise.
Cette dernière idée reçue est celle qui coûte le plus cher.
