Chapitre 8 — Topologies de déploiement architecturales

Huitième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où deux systèmes à la logique d'orchestration identique se comportent très différemment en production, parce que la question « où tourne réellement le modèle » reçoit trois réponses, et chaque réponse fixe un plafond différent de latence, de coût et de sécurité.

Pourquoi ce chapitre existe

Les Chapitres 6 et 7 ont spécifié comment les agents se coordonnent. Ils sont restés silencieux sur une question qui décide d'autant du comportement réel : où tourne chaque agent, et comment modèles de langage, serveurs MCP et outils sont-ils disposés sur le réseau ? Les décisions architecturales de ce chapitre touchent chaque requête et chaque euro. Trois topologies largement distinctes ont émergé dans l'écosystème MCP au cours de 2025 et 2026, et aucune des trois n'est universellement juste. Chacune est optimisée pour une combinaison différente de contraintes, et le choix a des conséquences que les ingénieurs devraient pouvoir articuler avant de le faire.

8.1 L'agent IA réutilisable : modèle empaqueté avec le serveur

La première topologie empaquette un modèle de langage avec un serveur MCP et expose la combinaison comme une seule capacité boîte noire. Le client appelle « relisez cette pull request » comme il appellerait un outil ; en dessous, une boucle agentique complète tourne côté serveur, invoque le modèle, appelle des outils internes, et ne renvoie que la sortie finale. Le patron a émergé quand des organisations ont bâti des agents spécialisés — recherche, revue de code, analyse financière — qu'elles voulaient exposer à plusieurs applications hôtes sans que chacune ait à comprendre les internes.

Les forces sont réelles. L'encapsulation laisse les auteurs de l'agent changer de modèles ou restructurer l'orchestration sans qu'aucun changement ne soit visible des clients. La réutilisabilité à travers les applications hôtes signifie qu'un seul agent sert Claude Code, une application d'entreprise et un chatbot orienté client, par la même interface. Les coûts sont tout aussi réels. L'opacité rend le débogage difficile : quand l'agent prend une mauvaise décision, le client ne peut pas voir pourquoi. La latence s'empile parce que la boucle côté serveur tourne à chaque appel. Et le double budgeting est structurel : l'opérateur de l'agent paie pour ses invocations de modèle et le client paie pour les siennes, et le coût total par interaction peut être plus élevé qu'aucun des deux côtés ne le pensait au départ.

La variante multi-tenant — un seul processus d'agent qui sert plusieurs organisations clientes — améliore substantiellement l'économie opérationnelle en amortissant les coûts fixes sur les locataires. Elle introduit aussi la fuite de données entre locataires comme mode de défaillance de premier rang. Plusieurs incidents divulgués en 2025 portaient exactement sur cela, et les opérateurs devraient concevoir le multi-tenant dans l'exécution plutôt que se reposer sur la revue de code pour attraper les fuites entre requêtes.

8.2 Pureté MCP stricte : le modèle dans le client

La seconde topologie place le modèle de langage strictement dans le client. Les serveurs MCP n'exposent que des données et des outils — aucune inférence. L'hôte fait tourner le modèle, prend les décisions d'orchestration, et appelle les serveurs pour rassembler du contexte et exécuter des actions. La motivation, c'est la raison d'être originelle du protocole : MCP existe pour résoudre le problème d'intégration N fois M en fournissant une interface uniforme entre modèles et outils, et les serveurs qui font tourner leurs propres modèles réintroduisent le problème que le protocole devait résoudre.

Les forces sont le contrôle et la transparence. Chaque appel de modèle est observable par l'instrumentation du client. Le client choisit le modèle par requête, peut basculer entre fournisseurs, et porte directement tout le coût modèle — pas de double budgeting puisqu'il n'y a pas de second modèle dans la chaîne. Pour les industries régulées où les journaux d'audit du client doivent capter la chaîne de raisonnement complète, la pureté stricte satisfait l'exigence sans ambiguïté.

Les coûts sont tout aussi clairs. Chaque morceau d'intelligence doit être réimplémenté par chaque client, ce qui est un vrai fardeau pour les organisations à beaucoup d'applications hôtes. Certaines capacités — recherche multi-étapes, raffinement itératif — sont gauches à factoriser comme outils en un coup, et les exposer pousse soit une orchestration complexe dans le client soit viole silencieusement la pureté en laissant le serveur faire tourner son propre modèle. Et le client doit être capable de faire tourner l'orchestration, ce qui en pratique signifie s'appuyer sur Strands, LangChain, Semantic Kernel ou Microsoft Agent Framework plutôt que d'écrire la boucle à la main.

8.3 Hybride : orchestration côté client avec exécution côté serveur

La troisième topologie partage la différence. Le client orchestre et fait tourner l'inférence principale ; certains serveurs MCP font tourner leurs propres invocations de modèle pour des sous-tâches spécialisées. L'exemple le plus clair est un outil de recherche profonde de longue durée. Un client qui doit replier un résultat de recherche dans un workflow plus large ne veut pas gérer chaque étape de la recherche lui-même ; il veut appeler « cherche X et dis-moi ce que tu as trouvé » et recevoir une synthèse. La recherche est multi-étapes, multi-sources, et bénéficie de sa propre orchestration interne.

Le patron hybride fonctionne quand la frontière est tirée à une couture significative — une sous-tâche aux entrées et sorties claires, auto-contenue assez pour que l'intelligence côté serveur la termine sans coordination du client, et spécialisée assez pour que la faire tourner comme boîte noire batte la faire tourner via l'orchestrateur général. Recherche, analyse de code, synthèse documentaire collent au profil. La conversation générale, non.

Le coût, c'est la complexité architecturale. Il y a maintenant deux endroits où l'intelligence tourne, l'observabilité doit traverser la frontière, et l'attribution des coûts se trouve entre les deux patrons purs. Une discipline utile consiste à limiter le nombre de serveurs intelligents et à garder chacun focalisé sur une capacité bien définie. Deux ou trois est opérable ; douze devient une fédération que personne ne comprend. Les déploiements hybrides tendent aussi à évoluer vers l'une ou l'autre extrémité du spectre avec le temps, et les architectes devraient être honnêtes sur la question de savoir si leur hybride est une conception stable ou un état transitoire.

Ce que prépare le Chapitre 8

Les trois chapitres de la Partie III ont parcouru l'espace de conception des systèmes multi-agents du point de vue du mécanisme. Ce qu'ils ne couvrent pas encore, c'est le substrat en dessous : le contexte que chaque invocation de modèle reçoit et la mémoire qui persiste entre invocations. L'efficacité d'un agent dépend de ce qu'il peut voir quand il agit et de ce qu'il peut rappeler de ce qu'il a fait avant. La fenêtre de contexte est finie. L'architecture de mémoire doit être conçue. Les patrons de gestion de budget d'attention, d'usage de scratchpad, de mémoire épisodique et sémantique sont le substrat qui transforme un ensemble coordonné d'agents en un système qui fait du travail utile sur des heures, des jours ou plus longtemps.

Prochaine étape — Chapitre 9 : Gérer le budget d'attention. Pourquoi une fenêtre d'un million de tokens est une valeur plafond plutôt qu'un point de fonctionnement, ce qui mange le budget, et comment MCP, RAG et l'affinage épousent chacun une forme différente d'écart.