Votre serveur MCP tourne parfaitement en localhost. Cinq coches vertes. Des logs propres. Vous êtes un génie !

Puis vous essayez de le déployer.

Les tokens OAuth se retrouvent dans les logs. Les secrets sont codés en dur parce que « c’est juste un prototype ». Tout s’effondre avec deux utilisateurs simultanés.

Bienvenue en production.

Tout développeur se heurte à ce mur. Construire un serveur MCP, c’est l’affaire d’un après-midi. Le rendre prêt pour la production, c’est souvent réécrire la moitié du code. Nouveaux flux d’auth. Gestion sérieuse des secrets. Isolation du contexte multi-utilisateur. Une infrastructure de déploiement qui tourne sans surveillance.

Rien de tout ça n’est la partie sympa. Tout ça est obligatoire.

C’est pourquoi nous avons créé le Secure MCP Framework, le framework open source qui rend n’importe quel serveur MCP sécurisé et prêt pour la production, sans réécriture.


Pourquoi MCP déraille en conditions réelles

MCP fonctionne très bien jusqu’à ce qu’il rencontre de vrais utilisateurs. Tout ce qui semblait correct en local devient un problème :

Renouvellement de tokensqui fonctionnait parfaitement mais échoue silencieusement en prod. Votre contournement « temporaire » qui donnait un accès admin à l’agent vient de rater votre revue de sécurité. Vous êtes à trois semaines de votre deadline de démo, à déboguer des flux OAuth à 2h du matin.

Gestion des secretsqui était « suffisante » pour les tests est désormais un cauchemar de conformité. Votre outil d’observabilité a enregistré une clé API. Votre RSSI l’a trouvée. Votre déploiement est en cours de rollback.

Contexte multi-utilisateurauquel vous n’aviez pas pensé devient critique dès qu’une deuxième personne utilise votre outil. Le token Reddit de l’utilisateur A est transmis à la requête de l’utilisateur B. Vous devez maintenant expliquer pourquoi quelqu’un a vu les messages privés d’un autre.

Nous avons construit des centaines de serveurs MCP et des milliers d’outils chez Arcade.dev. Ce framework, c’est celui qu’on aurait voulu avoir dès le début : un moyen d’éviter la réécriture qui arrive toujours juste avant la mise en production.


La solution

Voici à quoi ressemble habituellement le passage du localhost à la production :

  • Écrire des handlers OAuth personnalisés pour chaque provider
  • Construire son propre gestionnaire de secrets
  • Implémenter l’isolation de scope multi-utilisateur
  • Mettre en place l’infrastructure de déploiement
  • Ajouter monitoring et logging
  • Gérer le renouvellement de tokens entre les services
  • Passer la revue de sécurité
  • Déployer (et prier)

Voici ce que ça donne avec le Secure MCP Framework :

arcade deploy

Ce n’est pas encore un wrapper d’API ou une simple gateway. Il joue le rôle d’unMCP runtimele même framework qu’on utilise en interne pour faire passer les serveurs MCP du prototype à la production, avec une autorisation au niveau de l’outil, des secrets qui ne touchent jamais le LLM, et un déploiement qui passe vraiment à l’échelle, intégré d’emblée.

Comme j’aime le dire : construisez un serveur MCP que votre RSSI vous autorisera vraiment à utiliser en prod.


Comment ça fonctionne

Vous pouvez passer d’une démo locale à un serveur prêt pour la production en une seule session.

uv pip install arcade-mcp
arcade new my_server
cd my_server
arcade deploy -e src/my_server/server.py

Définissez un outil avec un scope d’auth adapté :

@app.tool(requires_auth=Reddit(scopes=["read"]))
def get_posts(context: Context, subreddit: Annotated[str, "Subreddit name"]) -> dict:
    """Get posts from a subreddit"""
    token = context.get_auth_token_or_empty()
    # Your implementation here
    ...

Ce qui se passe vraiment sous le capot :

Le framework gère les flux OAuth, le renouvellement des tokens, et injecte les credentials côté serveur viaContext. Le LLM ne voit jamais les tokens. Le client non plus.

Le framework vous permet aussi de transmettre un contexte plus riche à vos outils (données utilisateur authentifiées, secrets, état du projet) via la même interface. Pas de câblage manuel, pas de variables globales, pas de bricolage.

Quand vous déployez sur le moteur Arcade, tout fonctionne exactement comme en production : pas de mock tokens, pas de hacks locaux, pas de « on corrigera ça plus tard ».

Les evals intégrés vous permettent de tester et de benchmarker en local avant de pousser quoi que ce soit en production. Utilisez vos propres credentials, validez votre configuration, détectez les problèmes avant vos utilisateurs.

Voici ce qui casse sans ça : Votre LLM voit le token OAuth dans le prompt. Il le logue. Ce token se retrouve dans votre outil d’observabilité. Votre équipe sécurité le découvre lors d’un audit de routine. Votre déploiement est tué. Vous passez une semaine à expliquer pourquoi vous pensiez que c’était acceptable.


Pourquoi les développeurs s’y intéressent

Le Secure MCP Framework est local-first mais prêt pour le cloud. Il fonctionne avec Cursor, VS Code, Claude Desktop et ChatGPT, et c’est la même base qui propulsedes workflows de production comme Claude Code RoutinesLa DX est propre, pythonique et rapide, parce que c’est le même système qu’on utilise pour chaque outil en production chez Arcade.

Il a fait ses preuves à l’échelle. Nous faisons tourner des milliers d’outils à travers ce framework. S’il existait un moyen de le casser, nous l’avons déjà trouvé et corrigé.

Et il évolue avec vous. Commencez par un prototype en localhost. Déployez en staging. Passez à l’échelle en production. Zéro réécriture. Le même code qui tourne sur votre machine tourne en prod, juste de façon plus sécurisée.

C’est comme ça qu’on empêche nos propres serveurs de s’effondrer dès qu’ils quittent le localhost.


Le chemin rapide vers la production

Les autres frameworks s’arrêtent à « ça tourne ».

Le Secure MCP Framework évolue avec vous, du prototype à la production, sans réécriture. Déployez, sécurisez, passez à l’échelle et améliorez en continu, en un seul mouvement.

Pas d’auth bricolée. Pas de « on s’occupera des secrets plus tard ». Pas de revues de sécurité surprises qui tuent votre lancement. S’appuyer sur unMCP runtime libère votre équipe engineering pour se concentrer sur la logique produit plutôt que sur la plomberie.

Juste du code qui fonctionne et qui livre.


Construisez comme nous construisons

Nous utilisons ce même framework pour chaque outil Arcade et chaque serveur MCP que nous livrons.

C’est comme ça qu’on construit. Maintenant c’est à vous.

Démarrer : Quickstart du Secure MCP Framework

Explorer arcade.dev/mcp

→ Lui mettre une étoile sur GitHub


P.S. Si votre serveur MCP passe votre première revue de sécurité sans ce framework, vous avez soit beaucoup de chance, soit vous êtes vraiment dangereux. Probablement les deux.