Dans quels cas utiliser une plateforme d'agents runtime ?

À propos des plateformes d'agents runtime

Une plateforme d'agents runtime est l'infrastructure qui fait tourner des agents runtime en production, multi-tenant, sandboxée, derrière une API. C'est la 5e brique d'une stack qui empile 1.LLM → 2.Harness → 3.Agent → 4.Runtime → 5.Plateforme d'agents runtime.

Pour une description détaillée de ces cinq briques, voir l'article Une plateforme d'agents runtime, c'est quoi au juste ?.

1. Déployer des automatisations capables de s'adapter et de s'auto-corriger

Beaucoup d'équipes utilisent Zapier ou n8n pour leurs automatisations. Ces outils savent appeler un LLM, et leurs nœuds « AI Agent » peuvent même retenter une action en variant la stratégie à l'intérieur d'un run. Mais le workflow lui-même reste un graphe figé : l'agent ne réécrit pas sa propre topologie, n'apprend rien d'un run à l'autre, et chez n8n une simple erreur d'outil fait crasher tout le workflow au lieu de revenir à l'agent pour qu'il décide quoi faire. C'est de l'adaptation tactique, pas stratégique.

À l'inverse, un agent fonctionne sur une boucle de rétroaction : il choisit un outil, observe ce qu'il retourne, ajuste, recommence.

Zapier ou n8n avec un nœud LLM couvre déjà énormément (classification, RAG one-shot, extraction). Mais dès que la séquence d'appels n'est pas connue à l'avance et que l'agent doit décider à chaque tour de l'étape suivante, le workflow atteint sa limite.

Zapier/n8n + nœud LLM	Agent runtime
Trier un ticket contre une KB	Réconcilier factures Stripe ↔ compta
Router une alerte par contenu de log	Diagnostiquer une panne en interrogeant 4 systèmes en boucle
Classer une demande procurement	Négocier un planning multi-contraintes avec replanification
Extraire les champs d'un PDF de facture	Investiguer un incident sécurité par pivots successifs

Ce qui est intéressant : un agent runtime reste léger côté infra. Un prompt, un ou deux providers (Gmail, Slack, Notion, Jira), un schedule cron, un environnement sandboxé où il tourne en autonomie, opéré par un end-user unique sur son laptop ou un VPS (souvent l'admin qui a tout câblé).

2. Contrôler les agents runtime via une API

Un agent runtime classique se pilote très bien depuis un outil de dev (Claude Code, Antigravity, Codex) ou un agent personnel (OpenClaw, Hermes). Mais ça reste un usage solo : un utilisateur, une machine. Pour brancher cet agent à un système plus large, il faut une plateforme d'agents runtime qui expose une API.

L'API joue le rôle d'une prise standard : n'importe quel système (service interne, cron managé, n8n, Zapier) peut s'y brancher pour déclencher l'agent, observer son exécution, et récupérer le résultat de façon asynchrone via webhook.

Concrètement, ça donne un endpoint POST /runs qui lance un run, un GET /runs/:id qui récupère son statut, un stream SSE pour suivre la progression en direct, et un webhook HMAC-signé qui prévient le système appelant à la fin. Un nœud n8n qui appelle l'agent reste un pattern parfaitement valide : on garde le workflow déterministe pour l'orchestration, et on délègue à l'agent la partie qui demande la boucle.

3. Déployer des agents runtime sécurisés

Dès qu'un agent tourne en production, trois risques apparaissent :

• L'agent qui se trompe en toute confiance (le plus fréquent). L'IA de Replit a ainsi supprimé une base de production avec 1200 enregistrements clients, puis fabriqué 4000 faux records pour combler le vide. Pas de malveillance, juste une certitude erronée.
• L'injection de prompt. Un email piégé dans une boîte support peut convaincre l'agent de divulguer un secret ou d'exécuter une commande destructrice.
• Les credentials manipulés. Un agent qui appelle Stripe a besoin d'une clé, et si cette clé finit dans le contexte du LLM, elle devient exfiltrable par un simple prompt.

Une plateforme d'agents runtime répond à ces trois risques par deux mécanismes complémentaires.

Le sandbox per-run joue le rôle d'un aquarium fermé : chaque run tourne dans son propre environnement isolé. L'agent n'atteint ni la base de prod, ni le filesystem des autres runs, ni les variables d'environnement de la machine hôte, sauf si la plateforme l'y autorise explicitement. Une injection de prompt qui pousse l'agent à essayer DROP TABLE users se heurte au mur du sandbox.

Le degré d'isolation se choisit selon la criticité. Cinq niveaux dominent le marché, du plus léger au plus isolé (chaque cran ajoute de la sécurité, mais aussi de l'overhead RAM ou syscall) :

Côté Appstrate, l'isolation suit un modèle progressif sur 4 tiers : du Tier 0 (Bun subprocess sur l'hôte, sans isolation, pour le dev) au Tier 3 (RUN_ADAPTER=docker, chaque run dans un container isolé avec sidecar, le défaut en production). L'isolation MicroVM (Firecracker) est sur la roadmap pour les charges les plus sensibles.

Le credential broker (parfois appelé sidecar) joue le rôle d'un guichetier de banque : la clé vit dans un vault, l'agent demande « appelle Stripe » sans la connaître, le guichetier l'injecte au dernier moment côté réseau. Le LLM ne voit jamais le secret.

Anthropic Managed Agents le formule explicitement : « the harness is never made aware of any credentials. » AWS Bedrock AgentCore Identity converge : « agents never have direct access to long-term secrets or refresh tokens. » Les deux disent la même chose : isoler le LLM du secret par construction.

Tout ça est tracé dans un audit trail par tenant : qui a lancé quoi, quand, sur quelles données. La sécu peut rejouer un incident sans avoir à fouiller dans des logs dispersés.

4. Collaborer en équipe avec des agents runtime

L'équipe support a déployé un agent de triage qui tourne bien. L'équipe RH demande un agent de synthèse d'entretien, l'équipe finance un agent de rapprochement Stripe, l'équipe plateforme un reviewer de PRs partagé entre les devs. La question devient : qui a le droit de lancer quoi, avec les credentials de quelle équipe, sur quels systèmes ?

Avec une plateforme d'agents runtime, on peut structurer plusieurs équipes au sein d'une même infrastructure (organisations, workspaces, membres, rôles).

Dans une organisation, chaque équipe a son workspace isolé (une application chez Appstrate) avec ses agents, ses runs, ses logs, ses rôles, et ses credentials scopées (le Gmail support n'est pas le Gmail RH). C'est le multi-tenant interne : un seul runtime, plusieurs équipes, zéro mélange. Sans cette couche, les agents tournent sous un compte unique, les credentials traînent en cleartext, et les permissions se bricolent à la main à chaque nouvelle équipe.

Pour simplifier encore plus le partage des agents entre équipes, nous avons d'ailleurs imaginé AFPS, un format ouvert qui sert de registry de packages versionnés : @acme/[email protected], dist-tags latest et beta, retrait d'une version qui pose problème. Une équipe publie, les autres consomment.

L'organisation y gagne un point central de gouvernance sur tous ses agents, des accès scopés par équipe, et l'audit que la sécu demande.

5. Embarquer un agent dans son produit SaaS

Quand on veut embarquer une fonctionnalité agentique dans son propre produit SaaS, l'agent ne sert plus l'équipe interne mais les clients du produit. Quelques exemples :

• Un SaaS support B2B expose à chaque client un agent « rédige un premier jet » qui parle avec le Gmail du client.
• Un outil RH propose à chaque manager un agent « génère le rapport d'entretien » avec accès au Google Drive de l'entreprise.
• Un vertical SaaS de compta déclenche, par end-user, un agent de réconciliation sur le Stripe du client.
• Une plateforme d'aide aux subventions propose à chaque chercheur un agent qui identifie les appels à projets et rédige un premier jet, avec accès à son Google Drive.

Le parallèle Stripe résume le besoin : un User est dans l'équipe, un Customer est dans le marché — deux cycles de vie, deux jeux de permissions. Les credentials de l'éditeur et ceux du client final ne doivent jamais se croiser, sinon l'implémentation maison casse vite (sessions qui se croisent, tokens réutilisés, crons sans contexte). Évitable avec un runtime multi-tenant by design.

La mécanique tient en deux temps.

1. Configuration OAuth (une fois par end-user).

• Chaque utilisateur final est représenté par un end-user (eu_xxx).
• Le SaaS initie le flow OAuth via l'API connections avec le header Appstrate-User: eu_xxx.
• L'end-user voit la page de consentement standard (Google, Slack, Stripe…) et accepte.
• Les tokens reviennent chiffrés dans le vault Appstrate. Le SaaS ne les manipule jamais.

2. Utilisation au run (à chaque exécution).

• Le backend du SaaS appelle l'API Appstrate avec une API key scopée et le header Appstrate-User: eu_xxx.
• Le sidecar récupère les credentials de cet end-user dans le vault et les injecte côté réseau.
• Le LLM ne voit jamais le secret.
• Les webhooks HMAC-signés remontent les résultats dans le produit.

6. Déployer des agents runtime souverains

Un cadre légal ou contractuel impose que tout reste chez soi : données, modèle, logs, compute. Le runtime managé est écarté avant la discussion technique, pour des raisons juridiques.

Quelques profils typiques :

• une banque régulée UE,
• un opérateur santé sous HIPAA,
• un sous-traitant défense,
• une entreprise tenue à la localisation FR de ses données.

L'image qui colle : l'agent dans une enveloppe scellée. Tout ce qu'il faut à l'intérieur (compute, modèle, providers, vault), rien ne franchit la frontière sans autorisation explicite.

À quoi ça ressemble en pratique :

• un agent qui lit une base Postgres derrière le VPN, aucune row ne sort du datacenter,
• un agent air-gapped chez un client défense, sans accès internet, avec un LLM local servi en interne,
• un agent contraint à une région par contrat (UE, Canada, Suisse) avec compute, stockage, LLM et logs co-localisés.

Les primitives qui s'ajoutent à ce stade :

• Self-host complet : la frontière de l'enveloppe coïncide avec celle du datacenter.
• Outbound proxies : policer les appels LLM (qui appelle quel modèle, depuis où, vers où).
• Custom providers : APIs internes sans OAuth public, propres au client.
• AFPS comme document d'audit : le champ authorizedUris du manifest dicte ce que l'agent a le droit d'appeler, et le sidecar refuse tout ce qui n'y figure pas. Les credentials sont chiffrés AES par application.

L'auto-hébergement reste la seule façon de garantir les quatre régions qui entrent en jeu pour un agent : données, LLM, orchestrateur, logs. Ce cas en est la concrétisation opérationnelle : on choisit le runtime parce qu'il peut ne pas sortir.

Six cas, une cartographie

Cas d'usage	Déclencheur	Consommateur	Primitives ajoutées
Automatisation adaptative	Cron, webhook, email	Équipe ops/support	Agent, providers, schedule
Contrôle par API	Intégration à une stack existante	Service interne, cron, n8n, Zapier	+ API HTTP, SSE, webhooks
Agents sécurisés	Production avec credentials sensibles ou risque d'injection	Tout agent en prod	+ sandbox, credential broker, audit trail
Agents par équipe	Une 2e équipe demande son agent	Membres internes par équipe	+ orgs, membres, rôles, credentials scopées, AFPS
Agents dans un SaaS	End-user du produit	Clients externes du SaaS	+ application, end-user, impersonation
Agents souverains	Cadre légal ou contractuel	Régulés, air-gap	+ self-host, proxies, custom providers

Une organisation peut être concernée par un seul de ces cas, plusieurs en parallèle, ou les six. Les primitives s'additionnent quand on combine.

Quel cas pour quelle situation

Pour déployer des automatisations capables de s'adapter et de s'auto-corriger : un prompt, un provider, un schedule. Une journée pour un premier agent qui tient, un mois pour le stabiliser.

Pour contrôler les agents runtime via une API : un endpoint POST /runs, un stream SSE pour suivre la progression, un webhook HMAC-signé pour la fin. L'agent devient une brique consommable depuis n'importe quel système.

Pour déployer des agents runtime sécurisés : sandbox per-run, credential broker côté réseau, audit trail par tenant. Le LLM ne voit jamais les secrets.

Pour collaborer en équipe avec des agents runtime : orgs, membres, rôles, credentials scopées. AFPS s'ajoute pour partager et versionner les agents entre équipes.

Pour embarquer un agent dans son produit SaaS : application, end-user, impersonation. Soit la plateforme le porte, soit il faut le construire.

Pour déployer des agents runtime souverains : self-host complet, outbound proxies, custom providers. Appstrate est Apache 2.0, self-hostable en docker compose up, et la doc self-hosting couvre du Tier 0 local au déploiement air-gap.

Trois prochaines étapes :

1. Lire les pages concepts et multi-tenancy pour la cartographie technique complète.
2. Installer en local : curl get.appstrate.dev | bash.
3. Ouvrir une issue ou venir sur Discord si aucun des six cas ci-dessus n'englobe le besoin réel.