Patterns avancés multi-serveurs

Pourquoi ce chapitre change de niveau

Jusqu'ici, la formation a traité MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire comme une brique isolée : un client, un serveur, quelques outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire exposés. C'est suffisant pour un prototype, mais une entreprise qui déploie MCP en production se retrouve rapidement avec plusieurs dizaines de serveurs — un pour le CRM, un pour la base documentaire, un pour les tickets, un pour l'infrastructure cloud. Le problème n'est plus « comment exposer un outil » mais « comment faire coexister vingt sources d'outils sans que le système devienne ingérable ».

Ce chapitre aborde cette bascule : la composition multi-serveurs, le routing des appels, l'application de politiques centrales, la fiabilité des appels (cache, idempotence, retries), la gestion des workflows longs, et les anti-patterns qui rendent une architecture MCP invivable au bout de quelques mois.

Un déploiement MCP ne se juge pas au nombre d'outils exposés mais à la capacité du système à rester prévisible, auditable et réparable quand un serveur tombe, répond lentement, ou change de version sans préavis.

Composer plusieurs serveurs MCP

Un client MCP (l'orchestrateur, souvent intégré à l'agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire) peut se connecter simultanément à plusieurs serveurs. Chacun expose son propre catalogue d'outils, de ressources et de prompts. La composition consiste à agréger ces catalogues de façon cohérente pour le modèle qui doit choisir quel outil appeler.

Deux approches structurent la plupart des architectures observées :

1. Composition à plat : le client se connecte directement à N serveurs, et présente au modèle l'union de tous les outils disponibles. Simple à mettre en place, mais le nombre d'outils visibles croît linéairement avec le nombre de serveurs, ce qui dégrade la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire de sélection d'outil par le modèle au-delà d'une trentaine d'entrées.
2. Composition hiérarchique via un serveur agrégateur : un serveur MCP intermédiaire (parfois appelé gatewayPasserelleRéseauxÉquipement réseau reliant deux réseaux de couches différentes ou traduisant des protocoles ; en TCP/IP, route les paquets entre sous-réseaux.Voir dans le glossaire ou proxy MCP) se connecte lui-même aux serveurs métier en tant que client, puis republie un sous-ensemble filtré et enrichi d'outils vers le client final. Ce serveur agrégateur devient le point naturel pour appliquer des politiques centrales.

La composition hiérarchique est presque toujours préférable dès que l'organisation dépasse deux ou trois serveurs métier, car elle découple la surface exposée au modèle de la topologie réelle de l'infrastructure.

Routing des appels d'outils

Dans une architecture agrégée, le routing consiste à déterminer, pour chaque appel d'outil reçu du client, quel serveur métier doit réellement le traiter. Plusieurs stratégies coexistent :

• Routing par préfixe de nom : chaque outil republié est préfixé par l'identifiant de son serveur d'origine (crm.creer_contact, docs.rechercher). C'est la solution la plus simple et la plus lisible pour le modèle, au prix d'une certaine verbosité.
• Routing par métadonnées de capacité : le serveur agrégateur maintient une table de correspondance outil → serveur, indépendante du nommage exposé. Cela permet de renommer ou de faire évoluer un outil métier sans casser l'interface vue par le modèle.
• Routing dynamique par contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire : certains agrégateurs choisissent le serveur cible en fonction du contexte de la requête (locataire, région, environnement). Un même nom d'outil facturation.emettre peut pointer vers un serveur différent selon le client final. C'est puissant, mais cela complique fortement le débogage — à réserver aux cas où la multiplicité des environnements le justifie réellement.

Préférez systématiquement un nommage d'outil explicite et stable (domaine.action) même si le routing interne est dynamique. Le modèle raisonne sur les noms et les descriptions ; un nom ambigu augmente le risque de mauvaise sélection d'outil, avec des conséquences parfois coûteuses en production.

Politiques centrales : authentification, quotas, audit

Le serveur agrégateur est l'endroit naturel où appliquer les politiques transverses, plutôt que de les dupliquer dans chaque serveur métier :

• Authentification et autorisation : vérification du jeton du client, résolution de l'identité, application des permissions par outil ou par ressource avant même de transmettre l'appel au serveur cible.
• Quotas et limitation de débit : un agent mal configuré (ou une boucle de raisonnement défaillante) peut émettre des dizaines d'appels d'outils en quelques secondes. Des quotas par utilisateur, par serveur et par outil évitent qu'un incident local ne se transforme en incident de capacité pour l'ensemble du système.
• Audit et traçabilité : chaque appel d'outil, ses paramètres (avec masquage des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles) et sa réponse doivent être journalisés de façon centralisée. C'est la seule manière de reconstituer, a posteriori, la chaîne de décision d'un agent ayant produit un résultat incorrect.

Répliquer la logique d'autorisation dans chaque serveur métier semble plus simple à court terme, mais garantit une divergence à moyen terme : un correctif de sécurité appliqué sur un serveur et oublié sur un autre est l'un des scénarios d'incident les plus fréquents dans les architectures MCP multi-équipes.

Cache et idempotence

Les appels d'outils MCP ne sont pas gratuits : latence réseau, coût de calcul côté serveur métier, parfois coût financier direct (appel à une API tierce facturée à l'usage). Deux mécanismes réduisent ce coût sans sacrifier la fiabilité.

Cache

Le cache s'applique naturellement aux outils de lecture pure (recherche documentaire, consultation d'un statut, lecture d'une fiche). La clé de cache doit inclure l'identité de l'appelant si la réponse dépend des permissions, et une durée de validité (TTLTTLRéseauxCompteur porté par chaque paquet IP, décrémenté à chaque routeur traversé. À zéro, le paquet est détruit — ce qui évite les boucles infinies et permet à traceroute de cartographier un chemin.Voir dans le glossaire) adaptée à la fraîcheur requise par le domaine — quelques secondes pour un statut de ticket, plusieurs heures pour un référentiel produit.

Le cache ne doit jamais s'appliquer aveuglément aux outils d'écriture. Mettre en cache la réponse d'un outil paiement.executer reviendrait à masquer un état réel changeant.

Idempotence

L'idempotence est le mécanisme qui protège contre les effets d'un retry sur un outil d'écriture. Sans elle, un appel commande.creer rejoué après un timeout réseau peut créer deux commandes identiques. La pratique standard consiste à exiger, côté serveur métier, une clé d'idempotence fournie par l'appelant (souvent un identifiant de requête généré par le client) : le serveur mémorise les clés déjà traitées et renvoie le résultat original si la même clé se représente, sans ré-exécuter l'action.

L'outil reservations.creer accepte un paramètre idempotency_key. Si le client MCP perd la réponse à cause d'une coupure réseau et retente l'appel avec la même clé, le serveur détecte le doublon, ne crée pas de seconde réservation, et retourne l'identifiant de la réservation déjà créée.

Sans cette discipline, l'ajout de retries automatiques — pourtant indispensable à la résilience — devient lui-même une source de bugs.

Stratégies de retry

Tous les échecs d'appel ne se traitent pas de la même façon. Une bonne stratégie de retry distingue :

Le backoff exponentiel avec un peu de gigue (jitter) reste la référence pour éviter qu'un incident transitoire sur un serveur ne se transforme en tempête de requêtes synchronisées au moment où le service revient. Le nombre de tentatives doit rester borné et visible dans les journaux : un agent qui retente indéfiniment un outil défaillant consomme du budget de calcul sans jamais progresser.

Configurer des retries sur un outil d'écriture qui n'est pas idempotent est une décision qui expose directement à des doublons en production. Les deux mécanismes doivent être conçus ensemble, jamais l'un sans l'autre.

Workflows longs

Certains cas d'usage dépassent le modèle « un appel, une réponse » : génération d'un rapport qui prend plusieurs minutes, migration de données, validation humaine intercalée. MCP ne prescrit pas un mécanisme unique pour ces workflows longs, mais deux patterns dominent en pratique.

Pattern par notification de progression

Le serveur accepte l'appel, retourne immédiatement un identifiant de tâche, puis émet des notifications de progression via le canal de communication du protocole. Le client MCP peut afficher un état intermédiaire à l'utilisateur ou décider d'interroger l'avancement plus tard. Ce pattern convient bien aux tâches de durée moyenne (de quelques secondes à quelques minutes).

Pattern par sondage (polling) sur ressource

Le serveur métier crée une ressource représentant l'état de la tâche (task://id-1234), que le client peut relire périodiquement via les primitives de ressources MCP. C'est plus robuste face aux déconnexions du client, car l'état persiste côté serveur indépendamment de la session active.

Dans les deux cas, la reprise sur erreur est le point le plus souvent négligé : si le client se déconnecte pendant une tâche longue puis se reconnecte, il doit pouvoir retrouver l'état de la tâche via son identifiant plutôt que de la relancer depuis zéro. Cela suppose que l'identifiant de tâche soit stable et que le serveur conserve l'état au-delà de la durée d'une session client.

Une tâche longue déclenchée par un agent puis jamais reconsultée (parce que la session a expiré, ou que l'agent a changé de sujet) consomme des ressources sans que personne ne la ferme. Prévoyez systématiquement une expiration et un nettoyage automatique des tâches non consultées au-delà d'un délai raisonnable.

Anti-patterns à éviter

Le serveur MCP monolithe

Regrouper l'ensemble des capacités d'une organisation dans un unique serveur MCP semble économiser de la coordination au départ. En pratique, ce choix crée un point de couplage fort : toute équipe qui veut ajouter, modifier ou retirer un outil doit passer par le même dépôt de code, le même cycle de déploiement, les mêmes tests de non-régression que toutes les autres. Le serveur monolithe devient rapidement le goulot d'étranglement organisationnel de l'ensemble du programme MCP, bien avant de devenir un problème technique.

La décomposition par domaine métier (un serveur par équipe propriétaire d'un domaine), reliée par un agrégateur, préserve l'autonomie de déploiement de chaque équipe tout en gardant une expérience cohérente côté client.

Les outils trop larges

Un outil comme executer_requete_sql(requete: string) expose une capacité générique et puissante — mais transfère au modèle (et donc, indirectement, à l'utilisateur qui formule le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire) la responsabilité de construire une requête correcte et sûre. Ce type d'outil est difficile à auditer, difficile à limiter par permission fine, et ouvre la porte à des usages non prévus par les concepteurs du serveur.

Les outils bien conçus sont étroits et nommés par intention métier : commandes.rechercher_par_client(client_id) plutôt qu'un accès SQL généraliste. Cela réduit la surface d'erreur, améliore la précision de sélection par le modèle, et rend les politiques d'autorisation triviales à exprimer (un rôle donné a accès ou non à cet outil précis, plutôt qu'à une capacité générique dont il faudrait filtrer les usages a posteriori).

Un outil MCP bien conçu correspond à une action métier reconnaissable, pas à une primitive technique. Si un outil nécessite une phrase de description de dix lignes pour expliquer tous les usages possibles, c'est le signal qu'il devrait être scindé en plusieurs outils plus spécifiques.

Évolution du protocole et compatibilité

MCP est un protocole encore jeune et actif : les versions successives ajoutent des primitives (notifications, ressources dynamiques, capacités négociées à la connexion) et affinent les mécanismes existants. Une architecture multi-serveurs doit anticiper cette évolution :

• Négociation de capacités à la connexion : client et serveur échangent, dès l'établissement de la session, la liste des fonctionnalités du protocole qu'ils supportent. Un serveur agrégateur doit gérer une hétérogénéité de versions parmi les serveurs métier qu'il agrège, sans imposer la version la plus récente à tous.
• Dépréciation progressive des outils : lorsqu'un outil change de signature, conservez l'ancienne version en parallèle pendant une période de transition annoncée, plutôt que de casser silencieusement les intégrations existantes.
• Tests de contrat : au-delà des tests unitaires classiques, des tests de contrat entre le serveur agrégateur et chaque serveur métier permettent de détecter une rupture de compatibilité avant qu'elle n'atteigne la production, en particulier lors des mises à jour indépendantes de chaque serveur.

Traiter le catalogue d'outils d'un serveur MCP comme une API publique — avec versionnement sémantique et notes de changement — évite les régressions silencieuses quand plusieurs équipes consomment le même serveur agrégé.

Checklist de conception pour une architecture multi-serveurs

• Le nombre d'outils exposés au modèle reste-t-il dans une fourchette raisonnable (généralement moins d'une cinquantaine visibles simultanément) ?
• Les politiques d'authentification, de quotas et d'audit sont-elles centralisées dans l'agrégateur plutôt que dupliquées ?
• Chaque outil d'écriture accepte-t-il une clé d'idempotence, et les retries sont-ils configurés en conséquence ?
• Les tâches longues survivent-elles à une déconnexion du client, avec un identifiant stable et une expiration automatique ?
• Aucun serveur métier ne concentre-t-il l'ensemble des capacités de l'organisation (anti-pattern du monolithe) ?
• Chaque outil correspond-il à une intention métier précise plutôt qu'à une primitive technique généraliste ?
• Les changements de version des outils sont-ils annoncés et accompagnés d'une période de transition ?

Cette checklist ne remplace pas une revue d'architecture complète, mais elle couvre les défaillances les plus fréquemment observées dans les déploiements MCP qui passent du prototype à la production.

Synthèse

La complexité d'une architecture MCP ne vient pas du protocole lui-même, qui reste volontairement simple, mais de la composition de plusieurs serveurs dans un système cohérent. Un serveur agrégateur bien conçu centralise le routing et les politiques transverses ; l'idempotence et des retries disciplinés rendent les appels d'outils fiables face aux aléas réseau ; les workflows longs exigent une gestion explicite de l'état et de la reprise. À l'inverse, le serveur monolithe et les outils trop larges sont les deux anti-patterns qui, à eux seuls, expliquent la majorité des difficultés rencontrées lors du passage à l'échelle. Le chapitre suivant aborde la sécurité et la gouvernance des déploiements MCP, qui prolongent directement plusieurs des politiques centrales évoquées ici.