Étude de cas · Ingénierie plateforme
Un point d'accès pour chaque agent, au lieu de 20 configurations MCP par dépôt.
Une équipe plateforme maintenait à la main des listes de serveurs MCP dans chaque dépôt. En les faisant toutes transiter par un seul portail onemcp, elle a supprimé la dispersion des configurations, déplacé les identifiants côté hôte et rendu à ses agents de codage la marge nécessaire pour raisonner.
- Secteur
- Plateforme de développement interne
- Équipe
- ~60 ingénieurs, 1 équipe plateforme
- Stack technique
- Claude Code · Cursor · GitHub · Postgres · Linear · Sentry
# Synthèse
- Plus de 20 serveurs MCP accessibles par 1 point d'accès
- Surcharge d'outils par requête réduite d'environ 90 %
- Aucun identifiant amont stocké dans les configurations clientes
Scénario illustratif inspiré de déploiements onemcp courants. L'équipe décrite est une composition et non un client nommé ; les chiffres sont représentatifs et non mesurés.
Contexte
L'équipe plateforme accompagnait une soixantaine d'ingénieurs répartis dans une douzaine d'escouades produit. En un an d'adoption de MCP, chaque escouade avait câblé son propre ensemble de serveurs — GitHub, Postgres, Linear, Sentry, un outil de déploiement interne — directement dans les configurations de Claude Code et de Cursor. Chaque dépôt portait son propre mcp.json, et intégrer un nouvel outil supposait une pull request contre tous les projets qui le souhaitaient.
Le dispositif fonctionnait, mais ne passait pas à l'échelle. Une vingtaine de serveurs se retrouvaient désormais dupliqués dans des dizaines de fichiers de configuration, chacun avec des versions légèrement différentes et des identifiants collés par la première personne à l'avoir mis en place.
Le défi
Trois problèmes revenaient à chaque rétrospective.
- Dispersion des configurations. Ajouter ou mettre à jour un serveur imposait de toucher à chaque dépôt. Les configurations dérivaient, et personne ne pouvait dire avec certitude quelle escouade disposait de quels outils.
- Des identifiants au mauvais endroit. Jetons d'accès personnels et clés d'API vivaient sur les machines des développeurs et, parfois, dans des configurations versionnées. Faire tourner un jeton compromis relevait de la chasse au trésor.
- Une fenêtre de contexte encombrée. Chaque serveur MCP injectait l'intégralité de son schéma d'outils dans chaque prompt. Avec vingt serveurs connectés, l'agent consacrait une large part de son contexte aux définitions d'outils avant même de voir la première ligne de la tâche.
L'approche
L'équipe a mis en place un unique portail onemcp, y a ajouté ses serveurs une fois pour toutes et a authentifié chaque amont sur place. Au lieu que chaque client dialogue avec chaque serveur, les clients dialoguent avec le portail, qui répartit ensuite vers les amonts.
Deux éléments ont changé la nature du problème :
- Un seul point d'accès en remplace beaucoup. Un dépôt ne liste plus de serveurs ; il pointe Claude Code ou Cursor vers l'URL du portail et hérite de tout l'outillage sélectionné. Remplacer ou mettre à jour un serveur se fait une fois, dans le portail.
- Le Code Mode remplace le mur de définitions. Plutôt que d'injecter chaque schéma d'outil en amont, le portail expose trois méta-outils —
search,describeetexecute. L'agent découvre à la demande la poignée d'outils qu'exige une tâche et les appelle depuis un unique script, en un seul aller-retour.
Le déploiement
La migration s'est déroulée escouade par escouade sur deux semaines. Pour chaque dépôt, l'équipe a supprimé la liste locale de serveurs et inséré une seule entrée de portail. Le portail détenant les identifiants, les développeurs ont retiré au passage les jetons de leurs machines.
L'équipe plateforme a conservé le portail comme point de contrôle unique : les nouveaux serveurs étaient examinés et ajoutés de façon centralisée, et les accès gérés en un seul endroit plutôt qu'à travers des dizaines de fichiers mcp.json.
Les résultats
- Plus de 20 serveurs derrière un point d'accès. Les dépôts référencent une seule URL de portail. Ajouter un outil est une modification du portail, non une pull request touchant l'ensemble du parc.
- Surcharge d'outils par requête réduite d'environ 90 %. Substituer trois méta-outils à des centaines de définitions préchargées a ramené la surcharge par requête d'environ 15 000 jetons vers ~500 — un contexte que les agents consacrent désormais à la tâche.
- Identifiants côté hôte. L'OAuth amont et les jetons demeurent dans le portail, jamais dans les configurations clientes ni dans les fichiers versionnés. La rotation se fait par une seule mise à jour, en un seul endroit.
Nous avons cessé de livrer la configuration MCP dans les pull requests. Désormais un dépôt pointe vers un seul point d'accès et obtient tout, et c'est l'équipe sécurité qui détient les jetons, plus nous.