Chapitre 13 — Frameworks et intégration cloud

Treizième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où personne ne construit du MCP de production à partir du protocole brut, où la question honnête de 2025-2026 devient sur quel framework standardiser, et où la réponse dépend moins des fonctionnalités que du cloud sur lequel vit le reste du système.

Pourquoi ce chapitre existe

Le temps qu'une équipe câble authentification, transport, état de session, retry d'erreur, journalisation structurée, et les douze plus petits détails qui séparent une démo d'un service opérable, ce qui avait commencé par « on va juste parler MCP sur HTTP » est devenu un petit framework à soi — généralement plus mauvais que les frameworks qui existent déjà. La question d'ingénierie devient sur quel framework public standardiser, ce que chacun fait bien, et comment ils se connectent aux services cloud qui tiennent l'état. Ce chapitre parcourt le paysage méthodiquement : Strands avec Amazon Bedrock ; les services AWS qui l'entourent pour l'état et la récupération ; le Microsoft Agent Framework, LangChain et Semantic Kernel comme autres options de production ; et les patrons d'intégration sur lesquels les architectures de référence ont convergé. Le but n'est pas de couronner un vainqueur mais de décrire à quoi chaque framework sert vraiment.

13.1 Strands Agents et Amazon Bedrock

Strands est le framework d'agents open source qu'AWS a publié en 2025 et qui tourne désormais dans Amazon Q, AWS Support et l'assistant AWS Glue. Le cadrage est délibéré : Strands est piloté par le modèle, ce qui signifie que la boucle qui décide quoi faire ensuite, c'est la propre boucle de tool-calling du modèle, pas un graphe de planification que le framework imposerait par-dessus. Le travail du framework est de rendre cette boucle fiable en production — gérer les invocations d'outils, gérer l'état de session, brancher les serveurs MCP comme sources d'outils de premier rang via MCPClient, et router le tout par le catalogue de modèles hébergés de Bedrock. La couche modèle est branchable — API d'Anthropic, OpenAI, Ollama, LiteLLM — mais Bedrock est le défaut et le récit d'audit.

L'histoire multi-agents est l'endroit où Strands gagne sa réputation de production. Trois patrons de composition s'inscrivent proprement sur les formes d'orchestration des chapitres précédents : Agents-as-Tools (la forme la plus simple, un agent enveloppé en outil qu'un autre agent peut appeler) ; Swarm (pair-à-pair avec mémoire de travail partagée) ; et Graph (topologie déterministe où le modèle remplit chaque nœud). Les patrons s'imbriquent en production. La taxe opérationnelle se paie en observabilité, et Strands la paie en émettant des spans OpenTelemetry pour chaque invocation d'agent, chaque appel d'outil, chaque appel de modèle — pour qu'une composition à quatre niveaux se reconstruise depuis les logs sans instrumentation par niveau. Bedrock ajoute le récit de frontière d'accès : IAM contrôle quels modèles un agent donné peut invoquer ; CloudTrail journalise l'usage. Bedrock Guardrails gère le filtrage de contenu à la passerelle, Knowledge Bases donne une récupération gérée, et AgentCore — l'ensemble de primitives d'AWS de 2025 — formalise mémoire, identité et soucis d'exécution pour les équipes qui veulent une exécution entièrement gérée plutôt qu'auto-hébergée.

13.2 AWS comme couche d'état

Un agent qui tourne pendant des heures et qui se rappelle ce qui s'est passé hier a besoin d'un stockage qui survit au processus. Le patron qui s'est installé en production : état d'exécution (session courante, registre de tâches, appels d'outils en vol) dans DynamoDB pour un accès rapide par clé ; état d'artefact (documents produits, travail intermédiaire) dans S3 avec une structure de clés préfixée par session qui donne à la fois des frontières IAM naturelles et un versionnage gratuit ; état sémantique (mémoire à long terme, conversations passées) dans un store vectoriel — OpenSearch Service pour la mémoire de travail chaude, le plus récent S3 Vectors pour la mémoire froide ou d'archive. La séparation en deux niveaux entre S3 et DynamoDB n'est pas une optimisation prématurée. Elle garde l'item DynamoDB sous 400 Ko, évite une amplification de lecture à chaque étape, et laisse chaque couche se mettre à l'échelle indépendamment.

Le choix de couche d'état décide du mode de défaillance du système entier. Un agent dont l'état n'est qu'en mémoire processus perd tout au redémarrage. Un agent dont la mémoire est durable mais dont l'index est désynchronisé rappelle des références à des documents qu'il ne peut plus trouver. Les déploiements de production traitent ces points comme des contrats de cohérence séparés : transactions DynamoDB pour l'atomicité de l'état, S3 strong-read-after-write pour le contrat d'artefact, un pipeline d'indexation qui publie les documents dans S3 avant de surcharger leurs vecteurs pour que la récupération ne pointe pas vers quelque chose qui n'existe pas encore. La frontière de sécurité mérite le même soin. La propre guidance Strands d'AWS recommande des credentials par session via STS plutôt que de réutiliser le rôle d'exécution pour les appels d'outils sur des données utilisateur — AgentCore Identity automatise cela — pour que l'identité au niveau AWS derrière une action destructive soit l'utilisateur final réel, non un rôle d'agent partagé. Dans les environnements régulés, c'est la seule réponse acceptable.

13.3 Microsoft Agent Framework, LangChain et Semantic Kernel

Le côté Microsoft et open source du paysage s'est installé différemment. Le Microsoft Agent Framework est arrivé fin 2025 comme la fusion explicite de Semantic Kernel et AutoGen — le modèle de plugins et l'intégration .NET de SK avec les patrons multi-agents et la DX Python-first d'AutoGen. L'intégration MCP est intégrée via MCPStdioTool et MCPStreamableHTTPTool ; Azure AI Foundry est la maison hébergée, équivalente à Bedrock côté AWS. La fonctionnalité distinctive contre Strands, c'est que le graphe de conversation entre agents est un objet explicite et rejouable — ce qui compte énormément pour l'évaluation, parce qu'une conversation échouée peut être rejouée avec un prompt modifié et comparée tour par tour. Le coût, c'est plus de structure que Strands n'en impose ; le bon arbitrage dans les déploiements mûrs, le mauvais dans le travail exploratoire.

LangChain en 2026 est un animal différent de LangChain en 2023. L'abstraction originale des chaînes est devenue secondaire ; la surface principale est LangGraph pour l'orchestration et LangSmith pour l'observabilité et l'évaluation. Les forces, c'est l'ampleur — chaque modèle, base de données et outil semble avoir un adaptateur — et la maturité d'évaluation de LangSmith. La faiblesse que les praticiens nomment honnêtement, c'est la surface : les abstractions de haut niveau du framework sont excellentes pour les premiers quatre-vingt-dix pour cent du travail, et les dix derniers pour cent se font généralement en pelant les couches jusqu'à ce que l'équipe comprenne ce que chacune fait. Les équipes qui planifient cette transition livrent plus vite que celles qui se battent contre les abstractions. Semantic Kernel reste le framework des équipes .NET ; le modèle de plugins [KernelFunction] s'inscrit proprement dans les hôtes de services .NET. Un patron qui a émergé à travers les trois : agent fin, MCP épais — les capacités vivent derrière la frontière du protocole, les frameworks deviennent de fins proxys, et le même serveur MCP est consommé par Strands sur AWS, par Microsoft Agent Framework sur Azure et par LangChain sur le portable d'un développeur sans travail de portage. C'est la trajectoire que le protocole a été conçu pour rendre possible.

13.4 Les patrons d'intégration de production

Trois patrons se sont installés dans les architectures de référence 2025-2026. Le patron passerelle plus couche d'état place une passerelle de modèle gérée (Bedrock, AI Foundry, LiteLLM) devant la couche modèle et une couche d'état durable séparée derrière. La passerelle, c'est là que vivent auth, rate limiting, filtrage de contenu et audit ; la couche d'état, c'est là que vit la durabilité. Ce patron est le défaut de production ; les nouveaux déploiements devraient l'adopter sauf raison spécifique de ne pas le faire, parce que les équipes qui sautent la passerelle et appellent directement le fournisseur de modèle le regrettent dans le trimestre. Le patron service mesh MCP traite les serveurs MCP comme des microservices et les expose à travers un mesh qui gère mTLS, retries et coupe-circuits — vaut le coût uniquement à l'échelle (plus de dix serveurs) ou dans les environnements régulés qui exigent une attestation au niveau réseau. Le patron tout-géré remet l'exécution, la mémoire, l'identité et le registre d'outils à un service d'agent géré par le cloud (Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex AI Agent Builder) ; il gagne pour l'automatisation interne et les copilotes où l'agent n'est pas le produit principal, et perd pour les équipes où l'agent est le produit et où les leviers opérationnels comptent. Deux patrons qui n'ont pas gagné, et qui valent la peine d'être nommés comme exemples négatifs : tout-dans-le-contexte-du-LLM (agents dont la mémoire est un prompt système qui grandit sans cesse) et framework-comme-orchestrateur (un DAG rigide où le modèle remplit les paramètres des nœuds). Les deux meurent en production pour les raisons que le Chapitre 9 a parcourues, et la leçon que le domaine a absorbée, c'est que le bon équilibre entre structure du framework et liberté du modèle bascule davantage vers le modèle à mesure que le modèle devient plus capable.

Ce que prépare le Chapitre 13

Les frameworks et services cloud permettent aux équipes de livrer des agents fondés sur MCP sans réécrire la pile de protocole à chaque fois. Ce qu'ils ne disent pas, à eux seuls, c'est si le système résultant fonctionne — si l'agent résout les tâches pour lesquelles il a été bâti, comment il se comporte sous charge, où sont les falaises de performance, et comment comparer honnêtement deux architectures concurrentes. Le Chapitre 14 prend la question de front : il parcourt le MCP-Universe Benchmark, les deux modes de défaillance systémiques que le benchmark a découverts (dégradation à long contexte et exploration d'outils inconnus), et le côté débit où l'écart entre un pool de sessions partagées et le patron naïf session-par-requête est d'environ un ordre de grandeur.

Prochaine étape — Chapitre 14 : Benchmarking, tests et performance. MCP-Universe sur de vrais serveurs, les atténuations de long contexte et d'outils inconnus qui fonctionnent, l'écart de débit dix-pour-un entre session-par-requête et pools de sessions partagées, et où la série va ensuite.