Agent IA auto-hébergé en Docker : guide pratique 2026

Pourquoi Docker est la façon par défaut de faire tourner un agent IA auto-hébergé

Si vous avez décidé que vous voulez un agent IA sur votre propre infrastructure plutôt que de payer un abonnement SaaS mensuel, Docker est presque certainement la façon dont vous allez le faire tourner. En 2026 tout runtime d'agent open source sérieux livre un Dockerfile ou un docker-compose.yml. Le pattern a convergé parce que les conteneurs résolvent quatre problèmes à la fois qui apparaissent quand on auto-héberge un agent : la version du runtime Python ou Node, les dépendances système pour l'audio ou la vision, la surface réseau à exposer aux webhooks Telegram ou Slack, et l'état persistant (une base de données et un magasin vectoriel) dont l'agent a besoin entre les redémarrages.

Ce billet décrit ce que faire tourner un agent IA auto-hébergé en Docker ressemble réellement en 2026 : l'architecture, les plateformes qui valent le détour, les compromis auxquels vous souscrivez, et la configuration la moins chère qui survit à un redémarrage. Il est écrit pour quelqu'un qui a déjà utilisé Docker mais n'a pas encore choisi de stack d'agent.

Ce que "agent IA auto-hébergé" veut dire en pratique

L'expression couvre un large éventail de produits. Avant de choisir une image Docker, séparez-les en trois catégories.

Les agents de workflow sont des plateformes visuelles ou low-code où vous reliez des cases pour composer un agent. n8n, Dify et Flowise en sont les exemples canoniques. Ils tournent comme une application web sur laquelle vous vous connectez, et l'agent est un workflow que vous dessinez et déclenchez. Bon choix si vous voulez une GUI et plus de 400 intégrations prêtes.

Les frameworks d'agent orientés code sont des bibliothèques sur lesquelles vous écrivez du Python ou du TypeScript. LangChain ou LangGraph, AutoGen, CrewAI et le SDK Agents d'OpenAI vivent ici. Vous livrez votre code en image Docker. Bon choix si vous êtes développeur et voulez un contrôle total sur le prompt, les outils et la machine à états.

Les agents runtime sont des agents pré-construits que vous auto-hébergez et connectez à votre propre application de messagerie (Telegram, Slack, WhatsApp, Signal, e-mail). Hermes Agent, OpenHands et Agent Zero en sont des exemples. Vous n'écrivez pas la boucle de l'agent, elle est livrée. Vous apportez une clé d'API, vous apportez un serveur, et vous lui parlez depuis votre téléphone.

La recette Docker est similaire pour les trois. Les différences sont dans ce que vous mettez autour du conteneur : une base de données pour la mémoire persistante, un magasin vectoriel pour la recherche sémantique, et un récepteur de webhook pour l'application de messagerie que vous connectez.

Une image style schéma montrant un conteneur docker avec des flèches vers une base postgres, un magasin vectoriel et un webhook telegram

L'architecture de référence

Presque tous les agents IA auto-hébergés en Docker finissent par avoir cette forme :

| Composant | Image typique | À quoi ça sert | |---|---|---| | Runtime de l'agent | Image personnalisée ou ghcr.io/<projet>/<agent> | La boucle de l'agent : reçoit l'entrée, appelle le LLM, exécute les outils | | Passerelle LLM | ollama/ollama pour du local, ou API externe | Le modèle lui-même, ou un proxy vers OpenAI / Anthropic / OpenRouter | | Base relationnelle | postgres:16 | Conversations, état utilisateur, tâches planifiées | | Magasin vectoriel | qdrant/qdrant ou pgvector dans Postgres | Mémoire à long terme, recherche sémantique, RAG | | Reverse proxy | traefik ou caddy | Terminaison TLS, routage des webhooks | | Adaptateur de messagerie | À l'intérieur de l'image de l'agent | Connecteurs Telegram, Slack, Discord, WhatsApp, Signal |

Vous n'aurez pas besoin de toutes les couches. Si votre agent ne fait que du texte et utilise une API LLM externe, vous pouvez sauter Ollama. Si votre application de messagerie utilise le long-polling au lieu des webhooks (Telegram supporte les deux), vous pouvez sauter le reverse proxy. La stack minimale viable sur un VPS à 5 dollars c'est le runtime de l'agent plus Postgres, avec le modèle appelé via une API externe. Cela fait environ trois ou quatre conteneurs dans un seul docker-compose.yml.

Un docker-compose.yml minimal

Pour la plupart des agents personnels ou en petite équipe, voici la forme du fichier compose. Remplacez your-agent-image par le runtime que vous avez choisi.

services:
  agent:
    image: your-agent-image:latest
    restart: unless-stopped
    environment:
      DATABASE_URL: postgres://agent:agent@db:5432/agent
      MODEL_PROVIDER: openai
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      TELEGRAM_BOT_TOKEN: ${TELEGRAM_BOT_TOKEN}
    depends_on:
      - db
    ports:
      - "127.0.0.1:8080:8080"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: agent
      POSTGRES_PASSWORD: agent
      POSTGRES_DB: agent
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Trois points à signaler. Le port de l'agent est lié à 127.0.0.1 plutôt qu'à 0.0.0.0 parce qu'un webhook public devrait arriver via un reverse proxy qui termine TLS, pas directement sur un port de conteneur exposé. Les secrets vivent dans un fichier .env à côté du compose (et jamais dans git). Le volume Postgres est nommé pour que docker compose le préserve entre les redémarrages ; perdez ce volume et vous perdez la mémoire de votre agent.

Les options à connaître en 2026

Voici la liste courte des stacks d'agent open source qui livrent des images Docker et ont de la traction en 2026.

| Projet | Type | Licence | Intégrations de messagerie | Notes | |---|---|---|---|---| | Hermes Agent | Runtime | MIT | Telegram, Slack, Discord, WhatsApp, Signal, e-mail | Mémoire persistante, BYOK pour le modèle, création autonome de skills | | n8n | Workflow | Sustainable Use | 400+ via nœuds | Constructeur de workflows visuel, large catalogue d'intégrations | | Dify | Workflow | Apache 2.0 | Web UI, widgets embarquables | Approche RAG, orchestration de prompts, monitoring inclus | | Flowise | Workflow | Apache 2.0 | Web UI, nœuds REST/Slack/Telegram | LangChain en glisser-déposer | | LangGraph | Framework | MIT | Ce que vous câblez | Orienté code, graphes d'état profonds | | AutoGen | Framework | CC-BY 4.0 (Microsoft) | Ce que vous câblez | Conversation multi-agent | | OpenHands | Runtime | MIT | Web UI, IDE | Agent d'ingénierie logicielle dans un Docker isolé | | Agent Zero | Runtime | MIT | Web UI, terminal | Agent autonome d'utilisation d'ordinateur |

Le découpage compte parce que le bon choix dépend de ce que vous voulez de l'agent. Une plateforme de workflow est le bon choix si vous voulez automatiser un processus métier avec 14 étapes et 5 APIs externes. Un framework est le bon choix si vous construisez un produit sur mesure. Un runtime est le bon choix si vous voulez un agent personnel qui vit sur votre téléphone via une application de messagerie et qui se souvient de vous.

Pour le cas d'usage personnel centré sur la messagerie, Hermes Agent se compare directement à n8n côté workflow et à LangChain côté framework.

Les vrais compromis

Auto-héberger en Docker n'est pas gratuit, même si les binaires le sont. La liste honnête des compromis en 2026 :

Vous portez l'uptime. Un fournisseur d'agent managé surveille les processus, redémarre les conteneurs tombés, et réveille quelqu'un à 3 heures du matin quand une release casse la production. Sur un VPS auto-hébergé c'est vous, même si vous avez configuré restart: unless-stopped. Docker redémarre les conteneurs ; il ne répare pas un volume Postgres corrompu ni un token de bot Telegram expiré.

Vous êtes propriétaire des données, complètement. C'est l'avantage qui rend les compromis acceptables pour la plupart des lecteurs. Vos conversations, vos notes client, votre liste de contacts : rien ne touche un tiers à part le fournisseur de LLM que vous choisissez. Les utilisateurs européens sur un VPS européen obtiennent la résidence des données au sens du RGPD sans paperasse. Les professionnels de santé ou de la comptabilité sur du matériel qu'ils contrôlent ont une réponse défendable à "où vivent les données ?".

Vous payez la facture du modèle. Utiliser votre propre clé d'API (BYOK) coûte typiquement quelques dollars par mois pour un agent personnel, plutôt que les 20 dollars ou plus qu'un équivalent hébergé facture. La contrepartie c'est qu'il faut recharger un solde chez OpenAI ou Anthropic et le surveiller.

Vous portez la mise à jour. Tirer une image plus récente est une seule commande, mais lire le changelog et migrer le schéma de la base ne l'est pas. Prévoyez une fenêtre de 15 minutes tous les deux mois.

Vous n'êtes pas propriétaire du LLM. À moins que vous ne fassiez tourner Ollama ou vLLM localement sur un GPU, le modèle lui-même reste un appel d'API vers OpenAI, Anthropic, Google, Mistral, ou un agrégateur comme OpenRouter. Auto-hébergé en 2026 veut habituellement dire runtime auto-hébergé, pas poids auto-hébergés. Ce n'est pas grave : le runtime est là où vivent 90% de la sensibilité des données.

Si ces compromis sont acceptables, le gain est significatif. L'infrastructure auto-hébergée affiche environ 55% de réduction du coût total de possession sur 18 mois face au SaaS équivalent, avec un avantage de latence de l'ordre de 18 ms quand le modèle aussi est local. Pour la plupart des lecteurs le gain économique arrive plus tôt, vers le troisième mois.

À quoi ressemble la configuration la moins chère

Une base pratique 2026 pour un agent auto-hébergé à une personne :

Un VPS à 5 à 10 dollars par mois (Hetzner, Vultr, Contabo) avec 2 Go de RAM
Docker et Docker Compose installés
Un reverse proxy (Caddy est le plus simple pour le TLS automatique) sur le port 443
Un conteneur runtime d'agent, un conteneur Postgres
Une clé d'API de modèle rechargée de 5 à 10 dollars
Un bot de messagerie (un bot Telegram est le plus rapide à mettre en place)

Facture mensuelle totale : environ 7 à 20 dollars selon l'usage, dont 4 à 10 en tokens d'API et le reste en VPS. La configuration prend 15 à 30 minutes si vous avez déjà utilisé Docker ; plutôt une soirée sinon. Le dimensionnement du VPS est détaillé dans notre article dédié à l'hébergement VPS pas cher pour un agent IA, et le calcul de coût entre auto-hébergé et managé est ici.

Un espace de travail sombre et propre la nuit avec un ordinateur portable affichant une sortie de terminal et un téléphone montrant une bulle de message verte d'un agent IA auto-hébergé

Quand auto-héberger est la mauvaise réponse

Une liste courte de cas où la voie Docker est le mauvais outil.

Vous avez besoin de zéro implication ops et votre équipe ne tolère aucune coupure. Payez un runtime managé.
Vous voulez des SLAs fournisseur et un numéro de téléphone à appeler. Managé.
Vous avez moins d'une heure de patience pour la configuration initiale. Managé.
Votre agent doit passer à l'échelle élastiquement vers des milliers d'utilisateurs simultanés dès demain. Un runtime managé sur Kubernetes vaut la prime.

Pour tout le monde sinon (fondateurs solo, développeurs indépendants, petits cabinets, professionnels sensibles à la confidentialité, hobbyistes) Docker sur un petit VPS est le chemin avec le meilleur ratio entre contrôle et temps d'installation.

Où Hermes s'inscrit

Hermify est un runtime d'agent IA auto-hébergé sous licence MIT qui se distribue comme image Docker. Vous apportez votre propre clé de fournisseur de modèle (OpenAI, Anthropic, OpenRouter, Mistral ou autres), vous faites tourner le conteneur sur un VPS ou votre propre machine, et vous lui parlez via Telegram, Slack, Discord, WhatsApp, Signal ou e-mail. Il garde une mémoire persistante entre les conversations, apprend des skills réutilisables à partir de votre usage et reste hors de votre chemin le reste du temps. C'est une option parmi les runtimes listés plus haut ; il se trouve que c'est celle que nous maintenons.

Si la forme agent personnel sur votre téléphone est ce que vous voulez et que vous avez une heure pour mettre un conteneur Docker derrière un reverse proxy, Commencez avec Hermify. Si vous préférez sauter le VPS et nous laisser le faire tourner pour vous, l'offre managée s'occupe du conteneur, du Postgres, du TLS et des mises à jour pendant que vous gardez votre propre clé de modèle.