Une plateforme de runtime d’agents, c’est quoi au juste ?
En 2026, AWS, Anthropic et Microsoft ont tous sorti des produits estampillés « agent runtime ». Voici ce que cette catégorie recouvre vraiment, et pourquoi elle compte pour les équipes qui construisent dessus.
🚨 2026, l’année où « agent runtime » est devenu une catégorie
En quelques mois, trois des plus gros vendeurs d’infra de la planète ont sorti des produits qui partagent le même mot-clé :
- AWS Bedrock AgentCore : « Runtime managé pour agents autonomes »
- Anthropic Claude Managed Agents : « Des agents qui tournent sur notre infrastructure »
- Microsoft Agent Framework : « Runtime pour agents d’entreprise dans Azure »
Trois vendeurs différents, un vocabulaire commun, et personne qui s’est donné la peine de poser la définition.
Pendant ce temps, sur le terrain, les builders continuent de confondre cinq choses bien distinctes quand ils parlent de « plateforme d’agents » : une gateway LLM, une bibliothèque de prompts, un framework, un workflow builder et un runtime. Sur une slide, tout se ressemble. En pratique, ce sont cinq produits différents, et aucun n’est interchangeable.
Cet article, c’est la définition qu’on aurait aimé lire avant de commencer à construire Appstrate. Elle répond à une question précise :
Quand on dit « agent runtime platform », on parle de quoi au juste ?
🤯 Le problème : cinq produits qui se font passer pour un seul
Pose les buzzwords et regarde ce que chaque outil fait vraiment :
| Catégorie | De quoi il s’agit | Exemple |
|---|---|---|
| Gateway LLM | Un proxy devant les API des modèles. Ajoute cache, rate-limit, observabilité. | OpenRouter, LiteLLM, Portkey |
| Bibliothèque de prompts | Un stockage versionné de prompts, avec une UI pour les tester. | Humanloop, PromptLayer |
| Framework d’agents | Une bibliothèque de code pour câbler des tool calls dans ton process. | LangChain, LangGraph, CrewAI, AutoGen |
| Workflow builder | Un graphe visuel d’étapes déterministes, déclenché par événements. | n8n, Zapier, Make |
| Agent runtime platform | L’infrastructure qui exécute des agents comme des processus isolés, avec état, multi-tenant. | Bedrock AgentCore, Claude Managed, Appstrate |
Les quatre premières catégories existent depuis des années. La cinquième est neuve, et c’est elle que la vague 2026 pousse dans le mainstream.
La distinction compte parce qu’un runtime d’agents résout un tout autre problème. Il ne t’aide pas à écrire l’agent : il l’exécute pour toi, en sécurité, à travers des utilisateurs, des sessions et des comptes, avec tout ce qu’un système de production exige et qu’un framework refusera toujours de t’offrir : isolation, credentials, audit, état, scheduling, multi-tenant, rate-limiting, observabilité.
🧱 La définition
Une agent runtime platform, c’est l’infrastructure qui exécute les agents comme des processus sandboxés, avec état, multi-tenant, et les expose derrière une API.
Quatre mots portent la phrase :
1. Processus, pas prompt
Un appel de framework est sans état : tu passes un prompt, tu récupères des tokens, c’est plié.
Un runtime, lui, exécute un processus. L’agent dispose d’un filesystem, d’outils, d’une mémoire, d’un working directory, d’un exit code, de logs. Il peut écrire un PDF, lancer une requête SQL, appeler une API, réessayer, reprendre. Ça tient plus de la Cloud Function que de la chat completion.
2. Sandboxé
Le processus tourne dans un environnement isolé : container, microVM ou V8 isolate, selon le cas. L’agent n’atteint ni ta base de prod, ni les données de tes autres utilisateurs, ni tes variables d’environnement, sauf si le runtime l’y autorise explicitement.
C’est le gros apport qu’un runtime fournit et qu’un framework ne fournira jamais. Quand ton agent n’est qu’une fonction dans ton serveur Node.js, il suffit d’une injection de prompt pour que const result = await agent.run(prompt) se transforme en DROP TABLE users.
3. Avec état
Les agents ne vivent pas le temps d’un appel. Ils traversent des sessions, se souviennent de ce qu’ils ont fait la fois d’avant et reprennent où ils s’étaient arrêtés. Un runtime persiste cet état pour toi : dans l’enregistrement du run, dans une mémoire par utilisateur, dans un log d’audit.
4. Multi-tenant
Le runtime est pensé dès le jour 1 autour des organisations, des users, des clés API, des permissions, des quotas et de l’impersonation. Pas bricolé après coup. Parce que le jour où tu livres un agent à plus d’une personne, tu as besoin de toute cette mécanique, et greffer du multi-tenant sur un framework single-tenant, c’est la recette pour livrer des CVE en série.
🏗️ Anatomie d’un runtime
Toutes les agent runtime platforms de 2026, propriétaires ou open‑source, partagent les quatre mêmes pièces mobiles. Seuls les détails d’implémentation changent.
┌─────────────────────────────────────────────────────────────┐
│ Agent Runtime Platform │
│ │
│ ┌──────────────┐ │
│ │ API HTTP/SDK│ POST /runs, GET /runs/:id, webhooks… │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Validation │ Valide le schéma, injecte le contexte, │
│ │ entrée │ résout credentials, applique quotas │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Sandbox (une par run) │ │
│ │ │ │
│ │ Processus agent ←→ Filesystem │ │
│ │ ↕ │ │
│ │ Outils Mémoire │ │
│ │ ↕ ↕ │ │
│ │ Provider LLM État du run précédent │ │
│ │ ↕ │ │
│ │ Requêtes sortantes via credential broker │ │
│ └───────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Validation │ Valide le schéma, │
│ │ sortie │ persiste l’état, logge │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ Stream SSE + webhook + record audit │
└─────────────────────────────────────────────────────────────┘Validation d’entrée. L’API reçoit la requête de run, vérifie que l’agent existe, valide l’entrée contre un JSON schema, résout les credentials à partir des connexions de l’utilisateur appelant, applique les rate limits et rejette le run à la moindre anomalie.
Sandbox. Un environnement vierge et isolé est créé pour le run. L’agent a son propre filesystem, peut appeler les outils enregistrés et discute avec un ou plusieurs providers LLM via un credential broker. Il n’a aucun accès au réseau de l’hôte, aux autres runs ni aux credentials en clair.
Mémoire et état. Entre deux runs, le runtime persiste deux choses bien distinctes. L’état, c’est ce que l’agent a renvoyé explicitement (« 47 factures traitées, dernier ID = 983 »). La mémoire, c’est un stockage clé-valeur scopé par utilisateur, application ou organisation. Les deux sont réinjectés dans le prompt au run suivant.
Validation de sortie. Avant que le run ne soit marqué terminé, la sortie est validée contre le schema déclaré. L’événement part en log, le webhook est émis, le stream SSE de l’appelant se referme.
Le runtime est propriétaire du processus qui entoure l’agent. L’auteur de l’agent reste propriétaire du prompt et des outils. C’est là que passe la ligne de partage.
⚖️ Runtime vs Framework vs Workflow builder
Ce sont les trois que l’on confond le plus souvent. La question qui tranche : où le code s’exécute, et à qui appartient le processus ?
| Framework (LangChain) | Workflow builder (n8n) | Runtime platform (Appstrate, Bedrock) | |
|---|---|---|---|
| Où tourne l’agent | Dans le process de ton app | Sur le serveur du builder | Dans un sandbox isolé géré par le runtime |
| Qui gère l’isolation | Toi | Pas isolé (process partagé) | Le runtime (Docker / microVM) |
| Qui gère les credentials | Toi | Les env vars du serveur | Un credential broker que l’agent ne peut pas lire |
| Multi-tenant | À ta charge | Workspaces, limités | First-class : orgs / apps / end-users |
| État entre runs | À ta charge | Variables par workflow | Mémoire et état, persistés, scopés |
| Déterministe ? | Oui, si tu l’écris ainsi | Oui (graphe d’étapes) | Non, c’est le LLM qui décide |
| Ce que tu livres | Du code | Un graphe JSON | Un agent package (prompt + schema + outils) |
Un framework, c’est une boîte à outils. Un workflow builder, c’est un éditeur de procédure visuelle. Un runtime, c’est l’endroit où les agents vivent.
Si ton agent doit tourner une fois, pour un utilisateur, sur ton laptop : prends un framework. Si ton agent doit enchaîner les cinq mêmes étapes chaque mardi sur un seul compte : prends un workflow builder. Si ton agent doit tourner pour le compte de centaines d’utilisateurs, avec leurs credentials, en production, avec audit trail et SLA : il te faut un runtime.
🚀 Pourquoi ça compte en 2026
Trois dynamiques ont convergé cette année pour rendre la catégorie runtime inévitable.
1. Les agents ont quitté l’état de prototype. Claude Code, OpenClaw et Antigravity ont fait des agents de code autonomes un outil du quotidien. Les entreprises veulent maintenant le même comportement pour la réconciliation de factures, le triage du support, les ops marketing, le tout sur leurs propres données, avec leurs credentials. C’est une charge de production, plus un prototype. Et ça réclame une infra de production.
2. Les LLM sont devenus assez capables pour devenir dangereux. Un agent Claude 4.x avec accès au filesystem et un prompt cassé peut détruire un dossier. Un agent GPT-5 avec ton token OAuth Gmail et un mail piégé dans la boîte de réception peut faire partir tes factures chez un concurrent. L’injection de prompt a quitté le terrain théorique, et la seule défense qui tienne vraiment, c’est d’exécuter l’agent dans un sandbox hors d’atteinte de ce qu’il n’est pas censé toucher.
3. L’IA multi-tenant est plus dure qu’on ne le croit. Chaque SaaS builder qui a tenté de laisser ses utilisateurs connecter Gmail pour y lancer un agent a fait le même constat : stocker les tokens, c’est 5 % du boulot. Reste l’isolation par user, l’impersonation pour le support, les rate limits par org, l’audit pour la compliance, les webhooks pour l’asynchrone, l’idempotence pour les retries. Le runtime, c’est précisément ce qui empaquette tout ça, pour éviter de le reconstruire sept fois.
Tu peux tout te taper toi-même, par-dessus un framework. On a essayé. Ça prend un an.
🔓 L’argument open‑source
La version franche : AWS Bedrock AgentCore, Claude Managed Agents et Microsoft Agent Framework sont des produits bien conçus. Ce sont aussi des plateformes fermées avec les trade-offs qui vont avec : tu tournes sur leur infra, avec leurs modèles, dans leurs régions, sous leur pricing. Pour pas mal d’équipes, le marché est correct. Pour un nombre croissant d’autres, il ne l’est plus.
Les équipes qui ne peuvent pas ou ne veulent pas d’un runtime managé partagent en général quelques contraintes :
- Résidence des données. UE, santé, banque, défense. La donnée ne sort pas du bâtiment.
- Liberté de modèle. BYOM : Claude aujourd’hui, Gemini demain, un modèle local pour les charges sensibles.
- Contrôle des coûts. Faire tourner des agents à l’échelle sur de l’infra managée, c’est empiler une marge sur la marge LLM sur la marge compute. Au volume, le calcul ne tient plus.
- Embarquer dans un produit. Les SaaS builders qui veulent livrer des agents à leurs propres utilisateurs, brandés, avec leur propre auth, pas derrière une console Bedrock.
Le runtime d’agents open‑source répond à ces contraintes. Même architecture : sandbox, credential broker, multi-tenant, API. Mais avec l’infrastructure que tu choisis, les modèles que tu choisis et une licence que tu peux lire.
C’est ce qu’on construit avec Appstrate. Install en une ligne, Apache 2.0 (compatible MIT), même binaire sur un laptop ou dans un datacenter air-gapped, API de 191 endpoints, end-users et webhooks inclus. La doc d’architecture, ce sont les preuves.
📚 Liens
Autres articles
- Pourquoi les agents personnels fuitent leurs credentials : le versant sandbox de l’anatomie.
- Tes agents, ton infrastructure : le plaidoyer pour les runtimes auto‑hébergés.
- Claude Code pour les équipes : ce qui change quand les agents deviennent multi-tenant.
- Le paysage des runtimes d’agents en 2026 : comparaison sans bullshit des cinq acteurs.
Documentation Appstrate
- Concepts : l’architecture d’Appstrate, en détail.
- Compare : le tableau comparatif, avec les lignes qu’on n’a pas pu caser ici.
- Quickstart : ton premier run, en cinq minutes.