Comment nous avons découpé l'outillage de notre flotte d'agents en vingt micro-services indépendants sous le protocole MCP, hébergés sur Google Cloud Run en région parisienne avec mise en veille intégrale.
1. LE PROTOCOLE MCP : LE STANDARD « USB-C » DE L'IA AGENTIQUE
Pendant des années, connecter un grand modèle de langage à des outils externes (bases de données, APIs météo, systèmes de fichiers, gestionnaires de tâches) relevait du bricolage sur-mesure : chaque framework inventait son propre schéma JSON, ses propres conventions d'appels de fonctions (Function Calling) et sa propre tuyauterie d'authentification.
L'émergence du Model Context Protocol (MCP) standardisé par Anthropic a balayé cette cacophonie. MCP est devenu l'équivalent de la prise USB-C pour les intelligences artificielles :
- L'agent n'a plus besoin de connaître le code d'implémentation d'un outil.
- Il interroge simplement le serveur MCP qui lui expose son catalogue de fonctions disponibles et leurs schémas d'entrée/sortie.
- L'exécution est découplée, standardisée, portable d'un modèle à l'autre (Gemini, Claude, GPT, Ollama).
Au sein de l'environnement Crilo Automation, nous avons fait le choix de pousser cette logique jusqu'à son paroxysme : déployer l'intégralité de nos capacités métier sous forme de 20 micro-services Cloud Run MCP indépendants en région europe-west9 (Paris).
2. POURQUOI 20 MICRO-SERVICES PLUTÔT QU'UN MONOLITHE ?
Le réflexe classique d'un développeur pressé est de regrouper tous ses outils au sein d'un unique serveur géant. C'est pratique... jusqu'au premier pépin en production.
En éclatant notre flotte en 20 micro-services étanches (MCP Blogger, MCP Cloudflare, MCP Google Drive, MCP Calendar, MCP Recherche Web, MCP Juridique, MCP GitHub, etc.), nous avons obtenu des avantages décisifs :
CONSTELLATION DES 20 MICRO-SERVICES CLOUD RUN
─────────────────────────────────────────────
┌───────────────┐ ┌───────────────┐
│ mcp-blogger │ │ mcp-cloudflare│
└───────┬───────┘ └───────┬───────┘
│ │
▼ ▼
═════════════════════════════════════════════════
BUS DE COMMUNICATION MCP
═════════════════════════════════════════════════
▲ ▲
│ │
┌───────┴───────┐ ┌───────┴───────┐
│ mcp-calendar │ │ mcp-juridique│
└───────────────┘ └───────────────┘- Isolation des pannes (Blast Radius réduit) : Si l'API Google Calendar change ses contrats ou plante, le serveur MCP Blogger continue de fonctionner sans être impacté.
- Moindre privilège d'authentification : Le conteneur du serveur MCP Cloudflare ne possède que les jetons Cloudflare. En cas de faille, il est impossible de rebondir vers Google Drive ou GitHub.
- Mise à l'échelle chirurgicale : Si le scraper web est sollicité 500 fois dans l'heure, seul son conteneur scale. Les 19 autres restent paisiblement endormis.
3. LE SCALE-TO-ZERO EN PRATIQUE : 0,00 € AU REPOS
Le cœur économique de cette architecture repose sur la fonctionnalité Scale-to-Zero de Google Cloud Run (min-instances = 0).
Tant qu'aucun agent ne sollicite un outil :
- Zéro processeur virtuel alloué.
- Zéro gigaoctet de mémoire réservé.
- Zéro euro facturé pour ces conteneurs au repos — au repos uniquement (voir l'encadré ci-dessous).
- 0 € au repos : un conteneur Scale-to-Zero éteint ne consomme ni processeur ni mémoire.
- 0 € d'exploitation : non — une sonde active, un trafic réel ou un service toujours chaud facturent (nous avons mesuré jusqu'à ~38 € de surcoût sur ce seul piège).
- 0 € garanti : jamais — la gratuité dépend des quotas, des offres et de l'usage, et peut évoluer. Ce chiffre est une photographie datée, pas une promesse.
Dès qu'une requête arrive, Cloud Run réveille un conteneur en moins de 800 millisecondes grâce à l'optimisation extrême de nos images Docker : socle Alpine Linux ultra-léger, Python dépouillé de bibliothèques inutiles, et utilisation du framework asynchrone ultra-rapide FastMCP.
L'agent exécute son action, récupère le résultat, et le conteneur s'éteint automatiquement après quelques minutes d'inactivité.
- Démarrage à froid (Cold Start) : Moins de 750 ms pour le premier appel de fonction.
- Consommation mémoire au repos : 0 Mo (instance détruite).
- Latence en régime établi : 45 à 80 ms par invocation d'outil.
4. LE PIÈGE MORTEL DE LA SONDE ACTIVE : LA FACTURE CACHÉE
Mais attention : le serverless gratuit au repos cache un redoutable piège opérationnel dans lequel nous sommes nous-mêmes tombés (consigné dans l'Issue GrokBot#46).
Par réflexe d'administrateur système soucieux de surveiller son infrastructure, nous avions configuré un ordonnanceur automatique (Cloud Scheduler) chargé d'envoyer un « ping de santé » (Healthcheck) toutes les 2 minutes sur chacun des 20 services pour vérifier qu'ils étaient bien en ligne.
Le calcul mathématique s'est avéré impitoyable :
20 services × 30 pings par heure × 24 heures × 30 jours = 432 000 invocations mensuelles forcées !
En voulant simplement « surveiller » des serveurs censés dormir, notre propre sonde empêchait les conteneurs de s'éteindre, brûlant du temps de calcul payant et générant près de 38 euros de surcoût mensuel injustifié sur Cloud Run.
Dans une architecture Scale-to-Zero, une sonde de monitoring active qui interroge vos conteneurs en boucle transforme mécaniquement un système gratuit au repos en un cluster allumé en permanence. La surveillance serverless doit être passive (écoute des logs et métriques natives Cloud Logging), jamais active.
Dès que nous avons neutralisé cette sonde active, le trafic est retombé à zéro et les conteneurs ont retrouvé leur sommeil économique salvateur.
5. LES RÈGLES DE CONCEPTION POUR VOTRE ÉCOSYSTÈME MCP
Pour quiconque souhaite répliquer cette infrastructure distribuée, voici notre guide de survie :
- Une image Docker par responsabilité : Résistez à la tentation de tout mettre dans un même Dockerfile. La légèreté de l'image est le secret absolu d'un cold start imperceptible.
- Pas de pooling de connexions persistant : Dans un conteneur qui s'éteint, oubliez les connexions longues durées vers des bases de données. Privilégiez des connexions éphémères ou des architectures REST légères.
- Sécurisez le point d'entrée avec Cloudflare ou IAM : Vos micro-services ne doivent jamais être ouverts aux quatre vents sur le web public. Protégez-les par authentification Google Cloud IAM ou par des jetons d'en-tête stricts.
- Surveillez les logs, pas les pings : Laissez vos serveurs dormir. Si une erreur survient lors d'un appel réel de votre agent, Cloud Logging vous alertera instantanément sans vous coûter un centime.