Exécuter DisPatch et mes outils IA dans Docker : un fichier, une seule commande

J’utilise ma propre application de chat IA, DisPatch, pour ma famille. Jusqu’à ce mois-ci, son installation nécessitait Python, un environnement virtuel et un fichier de service. Désormais, elle est fournie sous forme d’image Docker ; toute la configuration se fait via un seul fichier et une seule commande sur votre propre serveur. Cette page vous guide pas à pas, depuis un dossier vide jusqu’à un chat fonctionnel, en utilisant un petit modèle IA qui tourne directement sur votre processeur afin que vous puissiez le tester sans avoir à vous inscrire nulle part.

Chaque commande indiquée sur cette page est exactement celle que j’ai exécutée le 19 octobre 2026. Je ne dispose pas de Docker Desktop sur cette machine ; j’ai donc utilisé Podman 5.8 avec Docker Compose 5.6 sous Linux. Les commandes restent identiques ; lorsque Podman nécessitait quelque chose de supplémentaire, je le précise dans la partie technique à la fin.

Ce que vous obtenez à la fin

Atlas est le personnage par défaut dans DisPatch. Il répond aux questions et, lorsqu’il dispose d’un modèle prenant en charge les outils, il peut effectuer des recherches : recherche web, lecture de pages, météo, Wikipédia, taux de change, heure ou calculatrice. Le même chat s’ouvre également sur un téléphone :

Pour découvrir ce que DisPatch peut faire de plus (profils individuels pour chaque membre de la famille, mode enfants, sauvegardes), consultez l’article sur DisPatch 3.0. Cette page se concentre uniquement sur son installation.

Étape 1 : installer Docker

• Windows ou Mac : installez Docker Desktop puis lancez-le une fois.
• Linux : installez Docker Engine ainsi que le plugin Compose, via votre distribution ou selon les instructions de Docker.

Vérifiez que tout fonctionne en ouvrant un terminal (PowerShell sous Windows) et en tapant docker compose version. Tout numéro de version indique que vous êtes prêt.

Étape 2 : créer un dossier et un fichier

Créez un dossier nommé dispatch puis enregistrez-y le contenu suivant sous le nom docker-compose.yml :

services:
  dispatch:
    image: ghcr.io/laserlloyd/dispatch_chat:main
    ports:
      - "8765:8765"
    volumes:
      - dispatch-data:/data
    restart: unless-stopped
    init: true
    stop_grace_period: 30s

  # Optionnel : un petit modèle IA qui tourne sur votre processeur, sans compte requis.
  # Supprimez ce bloc si vous comptez utiliser Ollama, LM Studio ou un service cloud à la place.
  model:
    image: ghcr.io/ggml-org/llama.cpp:server-b11723
    command: ["-hf", "unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M", "--jinja",
              "--host", "0.0.0.0", "--port", "8080", "--ctx-size", "8192"]
    environment:
      LLAMA_CACHE: /models
    volumes:
      - model-files:/models
    restart: unless-stopped

volumes:
  dispatch-data:
  model-files:

Deux services sont définis. dispatch correspond à l’application de chat. model est le serveur d’llama.cpp, qui télécharge le modèle Qwen3 4B Instruct (2,5 Go) lors de son premier démarrage et le conserve. Vos conversations sont stockées dans un volume nommé dispatch-data, qui subsiste même après les mises à jour ou redémarrages.

"8765:8765" permet à d’autres appareils du réseau d’accéder à DisPatch, ce qui est idéal pour un chat familial. Si vous souhaitez le limiter uniquement à cet ordinateur, remplacez cette ligne par "127.0.0.1:8765:8765".

Étape 3 : lancer le tout

Dans un terminal, depuis le dossier dispatch :

docker compose up -d
docker compose ps

Lors du premier démarrage, les deux images et le modèle sont téléchargés ; prévoyez donc quelques minutes. Sur ma machine, DisPatch a répondu 5 secondes après l’arrivée de son image, tandis que le serveur de modèle a mis environ 20 secondes pour télécharger et charger le modèle sur mon réseau. docker compose ps devrait alors afficher les deux services comme étant Up.

Étape 4 : créer votre compte

Ouvrez http://localhost:8765 dans un navigateur. Un nouvel install DisPatch reste verrouillé tant qu’un propriétaire n’est pas défini ; comme il tourne dans un conteneur, il demande un token de configuration unique. Récupérez-le via les logs :

docker compose logs dispatch | grep "SETUP TOKEN"

Si grep n’est pas disponible (sous Windows), exécutez simplement docker compose logs dispatch et repérez la ligne commençant par SETUP TOKEN:. Ce token change à chaque démarrage de DisPatch et devient inutilisable dès qu’un propriétaire est créé.

Le mot de passe doit comporter au moins 8 caractères. Le code PIN est facultatif, il sert à déverrouiller rapidement l’application. Si vous en indiquez un, DisPatch enregistre un code de récupération dans ses données ; il convient alors de le copier en lieu sûr :

docker compose exec dispatch cat /data/RECOVERY-CODE.txt

Étape 5 : connecter l’IA

La deuxième étape de l’assistant cherche un serveur de modèles sur la même machine. En contexte Docker, il ne repère pas automatiquement le service model ; vous devez donc le renseigner manuellement :

Champ	Valeur à saisir
Type	OpenAI-compatible
Adresse	http://model:8080/v1
Clé API	laisser vide
Modèle par défaut	unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M

Vous souhaitez utiliser un modèle cloud à la place ? Choisissez-le dans le même champ et indiquez votre clé API. J’ai testé cela avec un fournisseur cloud compatible OpenAI : « Tester et enregistrer » a listé ses modèles, et Atlas a pu dialoguer via celui-ci. La clé API est stockée dans les données de DisPatch, jamais dans le fichier compose.

Étape 6 : finaliser et dire bonjour

Les dernières étapes sont rapides. La fonction vocale est un add-on séparé que vous pouvez ignorer. « Famille » permet d’ajouter d’autres personnes (vous le ferez plus tard). « Réseau » demande de préciser qui peut accéder à DisPatch : choisissez la même option que pour le port au moment de l’étape 2.

Cliquez sur Terminer. Si la page affiche encore le formulaire de création du compte propriétaire après cela, rechargez-la. Il s’agit d’un bug d’affichage dans la version actuelle (le compte a bien été créé, mais l’ancien formulaire reste visible). Ensuite, sélectionnez Atlas à gauche, appuyez sur + pour ouvrir un nouveau chat et posez-lui une question.

Pour utiliser DisPatch depuis un téléphone connecté au même Wi-Fi, ouvrez http://<your computer's address>:8765. L’installation sur l’écran d’accueil, les notifications et le micro nécessitent HTTPS ; la partie technique aborde ce point.

C’est tout pour la configuration. Ce qui suit s’adresse à ceux qui souhaitent en savoir davantage, sécuriser leurs données ou ajouter mes autres outils.

Comment les différents éléments s’assemblent

L’image DisPatch s’exécute en tant qu’utilisateur ordinaire (uid 1000), et non en tant que root. Toutes les données écrites le sont dans /data, qui correspond au volume dispatch-data : la base de données SQLite, les fichiers téléchargés, les avatars, les paramètres ainsi que les sauvegardes quotidiennes. Si vous supprimez le conteneur, rien n’est perdu ; en revanche, si vous supprimez le volume, tout disparaît.

L’étiquette d’image main correspond à la branche principale du dépôt DisPatch. Au 19 octobre 2026, les étiquettes publiées étaient main ainsi qu’une étiquette sha-<commit> par build ; il n’y a pour l’instant aucune étiquette basée sur un numéro de version. Si vous souhaitez conserver la même image jusqu’à ce que vous décidiez de la mettre à jour, utilisez une étiquette sha- disponible sur la page du paquet. Des images sont proposées pour les architectures Intel/AMD 64 bits et ARM ; j’ai utilisé celle destinée à Intel/AMD.

Vos données : sauvegardez-les, restaurez-les, mettez-les à jour en toute sécurité

Arrêtez d’abord DisPatch afin que sa base de données soit complètement écrite, puis copiez le volume dans un fichier :

docker compose stop dispatch
docker run --rm -v dispatch_dispatch-data:/data:ro -v "$PWD":/backup alpine \
  tar czf /backup/dispatch-backup.tgz -C /data .
docker compose start dispatch

Compose nomme le volume d’après le nom du dossier ; ainsi, un dossier appelé dispatch donne le nom dispatch_dispatch-data. La commande docker volume ls affiche le nom réel du volume. Lors de mes tests, avec quelques conversations enregistrées, j’ai obtenu un fichier de 3,7 Mo.

Pour restaurer ces données dans un nouveau volume (j’ai ainsi restauré mon ancien volume et lancé un second DisPatch : mêmes propriétaires, même contenu avec 8 messages) :

docker volume create dispatch_dispatch-data
docker run --rm -v dispatch_dispatch-data:/data -v "$PWD":/backup:ro alpine \
  sh -c 'tar xzf /backup/dispatch-backup.tgz -C /data && chown -R 1000:1000 /data'
docker compose up -d

Ne copiez pas isolément le fichier chats.db depuis un conteneur en cours d’exécution : les messages récents se trouvent dans le fichier chats.db-wal à côté de celui-ci, tant que DisPatch n’est pas arrêté.

Mettre à jour nécessite deux commandes. Sur une installation déjà remplie, j’ai exécuté docker compose down, pull puis up -d ; les propriétaires et tous les messages sont restés en place, et aucun nouveau token de configuration n’a été généré.

docker compose pull
docker compose up -d

Faites une sauvegarde avant toute mise à jour majeure : DisPatch migre sa base de données au démarrage, et une image plus ancienne pourrait ne pas être capable de lire cette version mise à jour.

Paramètres de sécurité par défaut, et un réglage à vérifier

• Bloqué tant qu’aucun propriétaire n’est défini. Jusqu’à ce que la première étape de l’assistant de configuration soit effectuée, seule une page de connexion est accessible depuis le réseau ; pour créer un propriétaire, il faut utiliser le token affiché dans les logs.
• Les visiteurs non connectés accèdent à la vue Restricted. Ce point m’a surpris lors des tests : depuis un navigateur jamais utilisé pour se connecter, j’ai pu ouvrir Atlas et recevoir des réponses. Il s’agit d’une caractéristique de DisPatch 3.0 (un visiteur est traité comme un profil Restricted d’enfant, avec 200 réponses autorisées par jour), mais ces réponses sont générées via votre connexion IA. Si DisPatch se trouve sur votre réseau et utilise une clé cloud payante, modifiez dans les paramètres : « Settings → All settings → People & Profiles → “A device that has not signed in” » pour le valeur Sign-in screen only.
• L’accès au service dépend de la ligne ports. "8765:8765" autorise l’accès depuis tout le réseau ; "127.0.0.1:8765:8765" limite l’accès à la seule machine locale. Le conteneur écoute toujours sur toutes les adresses de son propre réseau interne.
• HTTPS reste à votre responsabilité. Le docker-compose.yml fourni dans le dépôt propose un proxy Caddy optionnel (--profile proxy) pour mettre en place un nom de domaine réel avec certificats ; je ne l’ai pas testé cette fois-ci. Si vous utilisez nginx, conservez proxy_set_header Host $host;, sinon le chat s’affiche mais ne se mettra jamais à jour (DisPatch vérifie que l’origine du navigateur correspond au header Host).
• Le serveur modèle n’utilise aucune clé. Son port n’étant pas publié dans le fichier ci-dessus, seul DisPatch peut y accéder. N’ajoutez pas de ligne ports: à la section model sauf si vous fournissez également à llama.cpp un paramètre --api-key.

Le guide complet sur l’utilisation de Docker avec DisPatch, incluant les montages bind, les identifiants utilisateurs et l’intégration de l’agent qui ne fonctionne pas bien dans un conteneur, se trouve dans le fichier docs/deploy-docker.md du dépôt.

Intégration de mes autres outils

Chacun de mes autres outils possède un fichier deploy/compose/compose.yml dans son propre dépôt. Leurs images ne sont pas encore publiées sur un registre ; il faut donc cloner le dépôt et ajouter l’option --build. Sur ma machine, chaque compilation a pris moins d’une minute, les images de base étant déjà téléchargées. Le 19 octobre 2026, j’ai cloné ces dépôts et lancé chacun des outils suivants :

Outil	Description	Image	Port	Vérifications effectuées
DisPatch	l’application de chat	publiée, 599 Mo	8765	Tout ce qui a été mentionné ci-dessus
MailForge	assistant de messagerie ne pouvant pas envoyer de courriels seul	à compiler, 420 Mo	8090	Le tableau de bord s’ouvre, aucune boîte mail n’est connectée
InfoForge + kiwix	moteur de recherche Wikipédia hors ligne pour les réponses IA	à compiler, 128 Mo, plus 66 Mo pour Kiwix	aucun (Kiwix utilise le port 8090)	Fonctionnement des outils doctor et search sur un fichier Wikipédia de 23 Mo
ThemeForge	page de prévisualisation des thèmes	à compiler, 13,8 Mo	8185	La page s’ouvre correctement
StudioForge	serveur modèle GPU	à compiler, 568 Mo (Vulkan)	1234, 8080, 1235	Sert un modèle sur une GPU intégrée AMD ; détails ci-dessous
CrucibleForge	outil de benchmark pour modèles IA	à compiler, 129 Mo	8777	L’outil démarre et s’ouvre ; aucun benchmark n’a été exécuté
TransForge	traducteur de sites web	à compiler	aucun	Pas testé lors de cette série d’essais

Les tailles indiquées correspondent à ce que Podman a rapporté sur le disque. Les fichiers compose propres à ces outils publient leurs ports uniquement sur 127.0.0.1, sauf si vous modifiez cette configuration.

MailForge

MailForge chiffre les mots de passe de vos boîtes mail à l’aide d’un mot de passe de clé que vous choisissez ; ce mot de passe ne peut pas être récupéré, alors conservez-le dans un gestionnaire de mots de passe. Vous devez également indiquer à LLM_BASE_URL l’adresse de votre propre serveur de modèles (192.0.2.10 ci-dessous représente cette adresse). Par défaut, le port utilisé est le 1234 sur l’hôte Docker ; toutes les requêtes de MailForge seront envoyées à cet endroit.

git clone https://github.com/LaserLloyd/MailForge.git
cd MailForge
read -rsp 'Phrase de passe du keyring MailForge : ' MAILFORGE_KEYRING_PASSWORD; export MAILFORGE_KEYRING_PASSWORD
LLM_BASE_URL=http://192.0.2.10:1234/v1 \
  docker compose -f deploy/compose/compose.yml up -d --build
docker compose -f deploy/compose/compose.yml logs app | grep "MailForge UI"

La ligne de journal affiche une adresse du type http://127.0.0.1:8090/?token=… ; ouvrez-la dans un navigateur.

InfoForge et Wikipédia hors ligne

Placez un fichier .zim provenant de la bibliothèque Kiwix dans le dossier deploy/compose/zims/, puis indiquez son nom dans le fichier infoforge.config.yaml (copiez-le depuis infoforge.config.example.yaml). J’ai utilisé le petit fichier de 23 Mo intitulé « Chemistry by Wikipedia » pour effectuer les tests.

git clone https://github.com/LaserLloyd/InfoForge.git
cd InfoForge/deploy/compose
docker compose up -d kiwix
docker compose --profile cli build infoforge
docker compose --profile cli run --rm infoforge doctor
docker compose --profile cli run --rm infoforge search "noble gas"

La recherche fonctionne sans aucun modèle d’IA :

[1] Noble Gas  (score 19.0, 4222 caractères)
[2] Gas  (score 16.0, 1586 caractères)
[3] Noble gas compound  (score 10.5, 2045 caractères)

infoforge ask nécessite un serveur de modèles défini dans base_url ; avec l’adresse par défaut, la commande doctor passe tous les tests sauf celui relatif au « llm primary », ce qui est normal.

ThemeForge

git clone https://github.com/LaserLloyd/ThemeForge.git
cd ThemeForge
docker compose -f deploy/compose/compose.yml up -d --build

Ouvrez ensuite http://localhost:8185.

## Un serveur de modèles GPU : StudioForge

StudioForge est mon propre serveur de modèles. Il exécute les modèles sur une carte graphique, gère plusieurs modèles et plusieurs clients ; depuis la version 2.0, il nécessite un compte propriétaire ainsi qu’une clé API pour chaque client. Son image n’est pas encore disponible sur un registre, donc cette section explique comment la construire.

Je pensais écrire « NVIDIA uniquement » ici. Le mini-PC que j’ai testé ne dispose pas de carte NVIDIA ; il a seulement la GPU Radeon intégrée d’AMD, présente dans le processeur Ryzen AI 9 365. J’ai tout de même compilé l’image Vulkan, fourni la GPU en question, et ça a fonctionné : au premier démarrage, StudioForge a téléchargé depuis GitHub le moteur llama.cpp précompilé correspondant, l’a testé, puis a servi le modèle Qwen3 4B avec toutes les couches exécutées sur la GPU, à un débit de 23 à 28 tokens par seconde. À titre de comparaison, le service de modèles model mentionné plus haut atteignait 22 tokens par seconde avec le même modèle ; sur cette puce, la GPU libère donc davantage le processeur qu’elle ne accélère les réponses.

git clone https://github.com/LaserLloyd/StudioForge.git
cd StudioForge/deploy/compose
cp env.example .env
# Dans .env : SF_BACKEND=vulkan, SF_MODELS=/chemin/vers/vos/fichiers_gguf,
#          SF_OWNER_PASSWORD (mot de passe de 10 caractères minimum),
#          SF_VIDEO_GID et SF_RENDER_GID = valeurs fournies par : getent group video render
docker compose -f compose.yml -f compose.vulkan.yml build
docker compose -f compose.yml -f compose.vulkan.yml up -d
docker compose -f compose.yml -f compose.vulkan.yml exec studioforge \
  studioforge keys create --name dispatch --scope inference

La dernière commande affiche une clé une seule fois. Le panneau de contrôle est accessible à l’adresse http://localhost:8080 (utilisateur owner, mot de passe défini précédemment). Pour une carte NVIDIA, le fichier requis est compose.cuda.yml et il faut définir SF_BACKEND=cuda ; je n’ai pas testé cette configuration ici, et l’image CUDA est nettement plus volumineuse.

DisPatch et StudioForge, ensemble

Le dépôt de DisPatch contient le fichier deploy/compose/stack.yml, qui lance les deux services sur un même réseau et préconfigure la connexion de DisPatch à StudioForge. En sortie de boîte, il tente de récupérer une image StudioForge qui n’est pas encore publique ; il faut donc le configurer pour qu’il utilise l’image que vous venez de construire. Voici les paramètres que j’ai ajoutés dans stack.env :

git clone https://github.com/LaserLloyd/DisPatch_Chat.git
cd DisPatch_Chat
cp deploy/compose/stack.env.example deploy/compose/stack.env
# Ajouter à deploy/compose/stack.env :
#   DISPATCH_IMAGE=ghcr.io/laserlloyd/dispatch_chat:main
#   STUDIOFORGE_IMAGE=ghcr.io/laserlloyd/studioforge:2.0.1-vulkan
#   STUDIOFORGE_MODELS=/chemin/vers/vos/fichiers_gguf
#   STACK_MODEL=<l’identifiant du modèle listé dans StudioForge>
#   SF_OWNER_PASSWORD (le même mot de passe propriétaire de 10 caractères minimum)

Le fichier de configuration réserve une GPU NVIDIA. Pour les systèmes AMD ou Intel utilisant Vulkan, j’ai remplacé cette configuration par un second fichier, stack-amd.yml :

services:
  studioforge:
    deploy: !reset {}
    devices: ["/dev/dri:/dev/dri"]
    group_add: ["39", "105"]   # numéros des groupes vidéo et de rendu sur votre système

docker compose -f deploy/compose/stack.yml -f stack-amd.yml \
  --env-file deploy/compose/stack.env up -d
docker compose -f deploy/compose/stack.yml -f stack-amd.yml \
  --env-file deploy/compose/stack.env exec studioforge \
  studioforge keys create --name dispatch --scope inference

Ensuite, terminez le processus de configuration de DisPatch comme indiqué précédemment, ouvrez les Paramètres → Connexions, cliquez sur Modifier pour la connexion à StudioForge, collez la clé obtenue et appuyez sur Tester.

L’identifiant du modèle se trouve en exécutant curl -H "Authorization: Bearer <key>" http://localhost:1234/v1/models ou dans l’onglet Modèles du panneau d’administration. Si vos modèles se trouvent dans un dossier téléchargé depuis Hugging Face, l’identifiant correspond au chemin complet du dossier ; il est long mais fonctionne parfaitement.

## Pièges à éviter

• Recharger la page après la configuration. Dans la version que j’ai testée, le formulaire de création du compte propriétaire reste affiché après la fermeture du processus de configuration. Le compte existe déjà ; il suffit de recharger la page.
• Le processus de configuration ne trouve pas le modèle tout seul. À l’intérieur de Docker, sa recherche se limite au conteneur et non aux autres services. Il faut alors indiquer http://model:8080/v1.
• Modèles de petite taille et requêtes externes. Avec le modèle Qwen2.5 1,5B, Atlas affichait parfois une ligne du type « Recherche web : … » sans effectuer réellement la requête. Le modèle 4B mentionné ci-dessus a quant à lui exécuté correctement les requêtes météo à chaque tentative. Plus le modèle est grand, mieux c’est.
• Le code de récupération n’existe que si un PIN est défini. Avec uniquement un mot de passe, il n’y a pas de fichier RECOVERY-CODE.txt, bien que la liste de vérification du processus de configuration en fasse mention.
• Deux outils sollicitent le port 8090. MailForge et kiwix d’InfoForge utilisent tous deux le port 8090 par défaut sur ce système. Si vous exécutez les deux, il faut définir HOST_PORT pour MailForge ou KIWIX_PORT pour kiwix.
• Le premier démarrage de StudioForge nécessite GitHub. Il télécharge l’moteur llama.cpp via l’API GitHub, qui autorise 60 requêtes anonymes par heure et par adresse IP. Ma première tentative a atteint cette limite ; l’image Vulkan minimale a alors tenté de compiler l’moteur à partir du code source, ce qu’elle ne peut pas faire (il n’y a pas d’git dans l’image), et a affiché can_serve: false. Un redémarrage après réinitialisation de la limite a résolu le problème. Selon les messages de log de StudioForge, définir GITHUB_TOKEN dans .env augmente cette limite.
• docker compose down -v supprime vos conversations. En revanche, la commande simple down ne le fait pas.
• Utilisateurs de Podman : sur Fedora et autres systèmes SELinux, ajoutez :z au montage du dossier de sauvegarde ("$PWD":/backup:z). Podman avec Docker Compose rejette également les fichiers de configuration des outils dont le bloc healthcheck ne contient pas de ligne test: (« il faut définir une commande de vérification ») ; j’ai donc ajouté cette commande dans un petit fichier de surcharge en me basant sur chaque Dockerfile. Pour kiwix exécuté sans droits root, il faut spécifier KIWIX_USER=0. Les utilisateurs de Docker peuvent ignorer ce point.

## Ce que je n’ai pas testé

• Docker Desktop sur Windows ou Mac. J’ai utilisé Podman avec Docker Compose sous Linux, uniquement en architecture x86-64.
• Ollama ou LM Studio exécutés hors de Docker sur le même ordinateur. Sur Docker Desktop, l’adresse serait http://host.docker.internal:11434/v1 pour Ollama ; ce serveur doit accepter les connexions en provenance du conteneur, mais je ne l’ai pas vérifié.
• Les images NVIDIA et ROCm de StudioForge, la version incluant le module vocal (VOICE=1), le profil HTTPS Caddy, ainsi que TransForge.
• L’utilisation de ask dans InfoForge avec un modèle, ainsi que les tests de performance via CrucibleForge.

DisPatch sur GitHub StudioForge MailForge InfoForge

Voir aussi : DisPatch 3.0 : profils familiaux et assistant de configuration, DisPatch, StudioForge, ainsi que comment faire en sorte qu’une IA adapte n’importe quel projet à votre système.