Tes agents, ton infrastructure : le dossier des runtimes auto‑hébergés

Les plateformes d’agents managées sont un bon deal, jusqu’au jour où elles ne le sont plus. Voici les cinq raisons pour lesquelles les équipes auto‑hébergent leur runtime d’agents, et le modèle d’infrastructure progressive qui rend la chose réellement faisable.

4 avril 2026Appstrate

souverainetéauto-hébergementinfrastructure

🌍 Le jour où AWS est tombé, ton IA est tombée avec lui

La fenêtre d’incident de février 2026 a duré sept heures. Bedrock est resté down pendant quatre d’entre elles. Pour les équipes qui avaient câblé leurs agents de production sur AgentCore, pas de fallback possible : le runtime était le provider. Les prompts étaient dans leur format. La state machine vivait sur leurs serveurs. Les logs résidaient dans leur région.

Pendant cette demi‑journée, pas mal de boîtes ont découvert sur quoi elles avaient vraiment construit.

Ce n’est pas un pitch anti‑managé. Bedrock AgentCore, Claude Managed Agents, Microsoft Agent Framework sont des produits bien conçus, et pour beaucoup d’équipes ce sont les bons choix. Mais le deal est précis : tu prends une plateforme clé en main, et tu cèdes le contrôle de la couche infrastructure.

Cet article parle de l’autre chemin, faire tourner le runtime toi‑même, et pourquoi plus d’équipes le choisissent que ne le prévoyait le consensus de 2025.

💡 Les cinq raisons d’auto‑héberger

« La vie privée » apparaît dans chaque pitch pro‑self‑hosting. C’est la moins intéressante des vraies raisons. Voici la liste dans l’ordre où tu regretteras de ne pas les avoir prises en compte.

1. La résidence des données n’est pas optionnelle

Si tu es régulé UE, HIPAA, GLBA, sous contrat défense, ou que tu opères dans un pays qui impose la localisation des données, où l’agent tourne est une question de conformité à réponse juridique. Tu ne répares pas « le container de l’agent a tourné dans us-east-1 » avec un NDA plus solide.

Les runtimes managés en 2026 offrent une certaine flexibilité régionale. Mais la région qui héberge tes données, celle qui sert ton LLM, celle qui tient l’orchestrateur et celle qui collecte les logs ne sont pas le même menu déroulant. L’auto‑hébergement est la seule façon de garantir les quatre.

2. BYOM n’est pas une feature, c’est un plan de sortie

Chaque runtime managé a son modèle de prédilection. Bedrock te pousse vers Anthropic et Nova. Claude Managed, c’est Claude. Azure, c’est OpenAI plus quelques poids ouverts. Changer de modèle reste une opération supportée sur ces plateformes. Jusqu’à celle qui ne l’est plus. Ou celle où le pricing a basculé le trimestre dernier.

Pire que le cloud lock‑in, il y a le model lock‑in. Les cloud providers exposent des primitives interchangeables : du compute reste du compute. Les modèles, non. Un prompt qui tient la route sur Claude 4.x casse subtilement sur GPT‑5. Un switch coûte du budget d’éval, pas juste du temps ingénieur.

Un runtime auto‑hébergé ramène le BYOM à un changement de config :

# Mardi : un agent Claude
MODEL=anthropic:claude-sonnet-4-6

# Mercredi, après l'annonce de pricing : un agent Gemini
MODEL=google:gemini-2.5-pro

# Le week-end, pour une charge sensible : un agent local
MODEL=ollama:llama-4-70b

Pas de migration de repo. Pas de swap de SDK. Pas de renégociation de contrat.

3. Le calcul de coût arrête de tenir à l’échelle

Le pricing managé de 2026 empile trois marges : le vendeur LLM sur le modèle, le vendeur runtime sur l’orchestration, et le cloud vendor sur le compute en dessous. À dix mille appels d’agent par jour, l’arithmétique passe. À un million, le spread entre managé et auto‑hébergé sur un nœud dédié devient une ligne de budget qui finance un ingénieur.

Ce n’est pas vrai à toutes les échelles. Charge bursty et petite, managé coûte moins cher. Charge soutenue et grande, ça finit par basculer. La vraie question : est‑ce que tu vois le point de bascule arriver ?

4. Embarquer des agents dans ton propre produit

Celle‑là est spécifique, mais elle grossit vite. Tu construis un SaaS. Tu veux livrer des agents à tes utilisateurs : brandés, dans ton app, avec ton auth, ta facturation, ton chemin de support.

Un runtime managé sert à tes utilisateurs une console qui n’est pas la tienne, une auth qui n’est pas la tienne, une page de prix qui n’est pas la tienne. Tu deviens revendeur. Pour beaucoup de produits, ça passe. Pour ceux qui vendent l’expérience, non.

Un runtime auto‑hébergé avec une API headless, exécuté par toi, invisible pour tes utilisateurs : c’est ce qui rend possible de vendre « un agent IA qui fait X » sans être visiblement bâti sur la plateforme de quelqu’un d’autre.

5. Air‑gap, cloud souverain, et « la sécu a dit non »

Il existe un pool non négligeable de cas d’usage où aucun appel externe ne sort du périmètre. Jamais. Défense, infrastructures critiques, recherche classifiée, back‑office financier régulé. Ces équipes ne règlent pas leur problème avec un runtime managé, point final.

L’auto‑hébergement n’est pas un nice‑to‑have ici : c’est la seule case à cocher qui produit un système qui tourne.

🧱 L’infrastructure progressive, en quatre tiers

L’objection historique à l’auto‑hébergement tenait en une phrase : « je ne veux pas faire tourner Postgres, Redis, S3, Docker, une queue et un secret store juste pour essayer ». Objection raisonnable. La réponse, en 2026 : rien de tout ça n’est requis au départ.

Le pattern que suit Appstrate, et qu’on défend pour tout runtime open‑source, s’appelle l’infrastructure progressive. Chaque dépendance externe est optionnelle, avec un fallback embarqué :

Composant	Infra complète	Fallback si absent	Tier
PostgreSQL	Managé ou self‑run	PGlite (Postgres WASM embarqué)	1+
Redis	Managé ou self‑run	Adapters in‑memory	2+
S3 / MinIO	Tout compatible S3	Stockage filesystem	3
Docker	Daemon sur l’host	Subprocess Bun, pas d’isolation	3

Au Tier 0, il te faut Bun et un terminal. Le runtime démarre, stocke tout dans ./data/ et te laisse lancer des agents. C’est le tier « est‑ce que je peux essayer ça en 30 secondes ? ».

Au Tier 3, tu fais tourner la stack complète, Postgres, Redis, S3, Docker, sur tes propres serveurs, dans ta propre région, derrière ton propre firewall. Même binaire. Même API. Mêmes agents.

Le point qui compte : passer du Tier 0 au Tier 3 est un changement de config, pas une réécriture. Tu ne choisis pas ton tier au démarrage. Tu le choisis quand la charge te le demande.

🪐 Ce que l’installation en une ligne fait vraiment

Voilà à quoi ressemble Appstrate sur une VM vierge :

curl -fsSL https://get.appstrate.dev | bash

Sous le capot :

Détection de l’host (Linux / macOS), installation de Bun s’il manque, de Docker s’il n’y est pas.
Pull de l’image plateforme, de l’image sidecar et de l’image agent Pi depuis GHCR.
Génération des secrets de signature (BETTER_AUTH_SECRET, CONNECTION_ENCRYPTION_KEY).
Démarrage de la plateforme sur :3000 avec stockage filesystem, queues en mémoire et Postgres embarqué.
Impression de l’URL et du lien de signup admin initial.

Zéro infra de ton côté. Tu apportes l’host. Ton laptop, un VPS à 5 $, un nœud bare metal dans un datacenter, un cluster K8s : l’installer s’adapte. Tu peux inspecter le script avant de l’exécuter (ce que tout lecteur un peu ops fera quand même), et tu peux lancer directement le Docker Compose sous‑jacent si tu veux zapper le wrapper.

Quand tu es prêt à scaler :

# pointe DATABASE_URL sur ton Postgres : PGlite est retiré, les données migrent
# pointe REDIS_URL sur ton Redis : in-memory est retiré, les queues migrent
# pointe S3_BUCKET sur ton S3 : filesystem est retiré, le stockage migre

Pas de réécriture. Pas de binaire différent. Pas de « ça ne marche que sur notre cloud ».

🔐 Le défaut souverain

L’auto‑hébergement n’est pas une feature qu’on ajoute à un runtime managé en décochant une case. C’est une contrainte de design posée dès le jour 1, et elle force des choix d’architecture précis :

Aucune dépendance dure sur un service externe. Ni pour le scheduling, ni pour le cache, ni pour le stockage, ni pour les secrets.
Des binaires statiques qui tournent en air‑gap. Pas de télémétrie « phone home » par défaut. Pas de serveur de licences.
Un modèle de données qui survit à un export. Chaque morceau d’état, agents, runs, logs, mémoire, vit dans des tables que tu possèdes, dans un format que tu peux lire, avec des migrations que tu peux lire.
Une licence qui te laisse forker. Apache 2.0 chez nous, la même licence que ton infra existante.

Les équipes qui ont besoin d’auto‑héberger, ce sont celles qui ont déjà été brûlées : rug‑pull de vendeur, changement de licence, rachat qui tue le produit, « free tier » supprimé qui mange un trimestre. Elles ne cherchent pas un trial. Elles cherchent un control plane qu’elles possèdent.

📚 Liens

Autres articles

C’est quoi une plateforme de runtime d’agents ? : la définition de catégorie que cet article assume.
Pourquoi les agents personnels fuitent leurs credentials : l’angle sandboxing, encore plus net en auto‑hébergé.
Claude Code pour les équipes : ce qui change quand les agents deviennent multi‑tenant.
Le paysage des runtimes d’agents en 2026 : la comparaison des cinq acteurs.

Documentation Appstrate

Concepts : l’architecture d’Appstrate.
Infrastructure progressive : le détail des tiers avec les snippets de config.
Docker Compose : le setup d’auto‑hébergement production.
Variables d’environnement : toutes les options configurables.