Le paysage des runtimes d’agents en 2026

🗺️ Cinq plateformes, une catégorie, des paris très différents

Il y a un an, à la question « où faire tourner cet agent en prod ? », la réponse tenait dans un haussement d’épaules. Tu prenais un framework, tu le câblais à ton serveur web, tu croisais les doigts. Il n’y avait pas de catégorie.

En mars 2026, cinq plateformes crédibles se revendiquent runtimes d’agents et entendent à peu près la même chose par là. Elles résolvent toutes le même problème (exécuter un agent comme un processus sandboxé, avec état, multi-tenant) et parient chacune sur un étage différent de la stack.

Cet article, c’est la comparaison qu’on aurait aimé avoir sous la main quand on a commencé à construire Appstrate. Elle n’est pas neutre : on fait partie des cinq. Mais le tableau reflète les vrais trade-offs, et on dit franchement où chacun gagne.

📊 Le tableau

	Bedrock AgentCore	Claude Managed Agents	Microsoft Agent Framework	LangGraph Cloud	Appstrate
Vendeur	AWS	Anthropic	Microsoft / Azure	LangChain	Open‑source
Auto-hébergeable	❌	❌	Partiellement (via Azure)	Partiellement (via LangGraph OSS)	✅
Licence	Propriétaire	Propriétaire	Propriétaire	MIT (OSS core) + cloud fermé	Apache 2.0
BYOM	Modèles Bedrock + endpoint maison	Claude uniquement (+ quelques partenaires)	Azure OpenAI d’abord, poids ouverts ensuite	N’importe lequel (c’est ton graphe)	N’importe lequel (provider-neutre)
Sandboxing	Firecracker microVM	Sandbox propriétaire	Azure Container Apps	Ton infra	Docker + sidecar (Firecracker sur la roadmap)
Primitives multi-tenant	Comptes AWS / IAM	Workspaces Anthropic	Entra / Azure AD	Limitées	Orgs + apps + end-users + impersonation
Credential broker	Adossé à IAM	Partiel	Adossé à Key Vault	DIY	Sidecar, allowlists par provider
Scheduling	EventBridge	Limité	Azure Logic Apps / Functions	DIY	Basé sur BullMQ, first-class
Webhooks	EventBridge	Limités	Event Grid	DIY	First-class, spec Standard Webhooks
API headless	✅	✅	✅	✅	✅ (191 endpoints)
API versionnée	Par date	Par feature	Par date	Semver sur le SDK	Par date (Appstrate-Version)
Meilleur pour	Équipes AWS-native	Équipes tout-Claude	Entreprises Azure-native	Équipes aux graphes complexes	Tous les autres

🧠 Un paragraphe par acteur

Chacune de ces plateformes est une sérieuse pièce d’ingénierie. Ce qui les sépare, c’est le pari qu’elles ont posé sur qui est leur utilisateur.

AWS Bedrock AgentCore, le pari cloud-native

AgentCore, c’est le plus riche en infra des cinq. Firecracker microVMs, accès aux outils médié par IAM, EventBridge pour les webhooks, CloudWatch pour les logs, KMS pour les clés. Si toute ta stack vit déjà sur AWS, AgentCore s’y encastre et hérite des patterns opérationnels que ton équipe connaît par cœur. Le revers est le plus prévisible du monde : tu tournes sur AWS, tu paies les prix AWS, tu te retrouves ferré aux primitives AWS, et toute histoire de cross-region reste une histoire de cross-region AWS. Excellent pour les AWS shops. Rédhibitoire dès qu’il est question de résidence des données, ou pour les équipes dont la revue sécu traite le vendor lock-in cloud comme un risque.

Anthropic Claude Managed Agents, le pari model-native

Claude Managed, c’est le chemin le plus fluide entre un prompt et un agent qui tourne, à condition que le prompt vise Claude. Le runtime est accordé sur le tool-calling de Claude, le thinking de Claude, le computer-use de Claude, le caching de Claude. Pour une équipe qui a tranché sur Claude et qui veut livrer, Claude Managed fait sauter une quantité sérieuse de câblage. Pour une équipe qui veut évaluer sérieusement un autre modèle, se couvrir contre les changements de prix ou brancher un fallback local, la plateforme est mauvaise par construction.

Microsoft Agent Framework, le pari enterprise-native

Ce qui rend MSAF intéressant : il est partiellement auto-hébergeable via ses composants OSS, ce qui en fait le seul runtime managé à tenir un discours cohérent pour Azure Stack et les clouds souverains. Si ton procurement passe déjà par des Microsoft Enterprise Agreements, la voie est toute tracée. Le trade : l’expérience complète reste Azure-first, Entra-first, et le meilleur outillage présuppose une .NET shop. Dans ce cas, l’option est d’une grande propreté. Sinon, tu restes second-class.

LangGraph Cloud, le pari graph-native

LangGraph Cloud est la seule plateforme des cinq dont l’abstraction centrale est le graphe de l’agent, et non l’agent vu comme une boîte noire. Si tes agents reposent sur des state machines explicites et complexes (orchestration multi-agent, human-in-the-loop, long-running avec checkpoints), le modèle LangGraph épouse ta façon de penser. Le trade : toute l’infrastructure qui entoure le graphe est à ta charge, déploiement, multi-tenant, scheduling, audit. LangGraph Cloud gère l’orchestrateur, pas la plateforme qui l’entoure. Excellent si tu cherches un moteur d’exécution bien conçu. Pas un remplaçant de plateforme.

Appstrate, le pari open‑source

Appstrate est le seul des cinq à être Apache 2.0, auto-hébergeable par défaut et provider-neutre côté modèles. On parie que la catégorie runtime d’agents va suivre la même trajectoire que le cloud : trois ou quatre gagnants propriétaires avec d’excellents produits managés, une ou deux alternatives open‑source qui captent la long tail des équipes qui ont besoin de garder la main sur l’infrastructure. Industries régulées, SaaS builders qui embarquent des agents, charges où chaque centime compte, déploiements souverains, équipes échaudées une fois par un rug-pull de vendeur. C’est pour cette long tail qu’on construit. Le pari, c’est que la catégorie devienne assez grosse pour que la long tail soit un vrai business, comme Linux et Postgres le sont devenus.

🎯 Les axes qui tranchent vraiment

Si tu évalues les cinq, une liste de pros et cons rend moins service qu’un arbitrage sur une poignée d’axes. Voici la version courte.

Stratégie modèle

Si tu t’es déjà engagé sur une famille de modèles et que rien ne bougera, prends le runtime accordé avec : Claude Managed pour Claude, AgentCore pour les familles Bedrock, MSAF pour Azure OpenAI. Si tu n’as rien tranché, ou si tu veux garder les options ouvertes, la neutralité modèle pèse plus lourd que le tuning maison. Ça pointe vers LangGraph ou Appstrate.

Où les données doivent vivre

Si tes données ne peuvent pas quitter une région précise, certains clouds, ou ton propre périmètre, la question n’est plus « quel runtime » mais « quel runtime me laissera seulement tourner dans ce périmètre ». Sur cet axe, il ne reste qu’Appstrate et les morceaux auto‑hébergés de LangGraph et MSAF. Les autres sont hors-jeu, par design.

Modèle multi-tenant

Si tu fais tourner des agents pour le compte de tes utilisateurs (pas juste ton équipe), les primitives multi-tenant pèsent lourd. AWS IAM et Azure Entra sont puissants, mais conçus pour l’identité entreprise, pas pour l’embedding end-user. Des end-users à la Stripe avec impersonation, des clés API scopées par application, des webhooks pensés pour du B2B SaaS : c’est une exigence produit précise, et les cinq n’y répondent pas de la même façon.

Tolérance aux ops

Si ton équipe n’a zéro bande passante ops, l’auto‑hébergement est un trade perdant, quels que soient les arguments OSS. Prends un runtime managé, paie la taxe, livre. Si ton équipe fait tourner Postgres, Redis et Docker sur Kubernetes ou une flotte de VMs sans sourciller, l’auto‑hébergement débloque les gains de prix, de souveraineté et de flexibilité que les plateformes managées ne peuvent pas égaler.

Communauté et portabilité

Les plateformes fermées offrent un support vendor de très bonne facture. Ce qui leur manque, c’est une seconde implémentation vers laquelle migrer sans tout réécrire. Du code Apache 2.0 avec une API interne propre, c’est un autre type d’assurance : elle ne te protège pas des incidents, mais elle te protège du vendeur qui disparaît, change de licence ou pousse son produit upmarket.

🧭 Guide de décision, version courte

Le tableau plus haut demande beaucoup d’attention. Voici la version ramassée :

• Tu es AWS-native, Claude-native ou Azure-native, et tu t’en portes très bien : prends le runtime vendeur qui s’y cale. La taxe d’intégration est réelle, et les plateformes vendeur la paient pour toi.
• Tu construis des agents dans un déploiement régulé ou souverain : Appstrate ou LangGraph auto‑hébergé. Probablement Appstrate si tu veux aussi les primitives multi-tenant.
• Tu construis un SaaS qui embarque des agents pour tes utilisateurs, brandés, avec ton auth : Appstrate. Le triptyque end-user, impersonation et webhooks est taillé exactement pour cette forme.
• Tu fais tourner des graphes d’agents réellement complexes avec des checkpoints human-in-the-loop : LangGraph. L’abstraction graphe, c’est là que se joue la différence.
• Tu fais tourner beaucoup d’agents et la facture managée bouffe ta marge : auto‑héberge quelque chose. Appstrate, c’est le trade le moins cher entre infra à opérer et plateforme à construire.

🔓 Pourquoi on parie sur l’open‑source

Conclusion franche, puisqu’on est un des cinq.

Toutes les catégories d’infrastructure matures de ces vingt dernières années ont fini par prendre la même forme. Des leaders propriétaires avec d’excellents produits (VMware, Oracle, Splunk, Datadog). Des alternatives open‑source qui captent la long tail et finissent par tirer les marges propriétaires vers le bas (KVM, Postgres, OpenTelemetry, Grafana). Les alternatives open‑source n’ont pas gagné parce qu’elles étaient meilleures. Elles ont gagné parce qu’elles donnent aux équipes un control plane qu’elles possèdent, dans un monde où les enjeux de ne pas le posséder ne cessent de grimper.

Les runtimes d’agents, c’est la prochaine catégorie sur cette trajectoire. Les enjeux sont élevés : ces systèmes détiennent les credentials de tes utilisateurs, tournent sur leurs données et prennent des actions aux conséquences bien réelles. Les équipes ressentent déjà le besoin d’un control plane qu’elles peuvent ouvrir, lire, forker et faire tourner où elles veulent. C’est cette long tail qu’on vise.

Rien de tout ça ne veut dire que les plateformes propriétaires vont perdre. Bedrock, Claude Managed et MSAF seront le défaut pour une bonne part du marché, comme Oracle reste le défaut pour une bonne part des bases de données. Ce que ça veut dire : il faut une option open‑source crédible pour l’autre part. C’est la case qu’Appstrate s’efforce d’occuper.

📚 Liens

Autres articles

• Une plateforme de runtime d’agents, c’est quoi au juste ? : la définition de catégorie derrière le tableau ci-dessus.
• Pourquoi les agents personnels fuitent leurs credentials : l’axe sandboxing, en détail.
• Tes agents, ton infrastructure : le plaidoyer pour l’auto‑hébergement.
• Claude Code pour les équipes : l’axe multi-tenant, en détail.

Documentation Appstrate

• Compare : la version doc de cette comparaison, avec davantage de lignes.
• Concepts : l’architecture d’Appstrate en détail.
• Quickstart : cinq minutes pour ton premier run.