Comment conteneuriser vos applications IA open source avec Docker en 7 etapes

En 2026, la conteneurisation est devenue le standard de deploiement pour les applications web, les microservices et les API. Mais les applications d’intelligence artificielle open source posent des defis specifiques que les guides Docker classiques n’adressent pas : des modeles de plusieurs gigaoctets a gerer en dehors de l’image, un GPU a exposer au conteneur avec les bons drivers, des dependances Python massives (PyTorch seul pese 2 Go), et des considerations de securite amplifiees par la presence de cles API et de donnees sensibles dans l’environnement d’execution.

Ce guide detaille les 7 etapes pour conteneuriser correctement vos applications IA open source avec Docker. Chaque etape est illustree avec des exemples concrets adaptes aux frameworks les plus utilises par les equipes francaises : LangChain, Ollama, vLLM, Hugging Face Transformers, et les pipelines de RAG (Retrieval-Augmented Generation). L’objectif n’est pas de produire une image qui « marche » en local, mais une image optimisee, securisee et prete pour un deploiement en production.

Que vous soyez un developpeur qui deploie son premier modele ou un architecte qui industrialise une plateforme d’inference, ce guide vous fournira les fondamentaux et les bonnes pratiques qui feront la difference entre un prototype fragile et un service de production robuste. Les recents incidents de securite sur les frameworks IA — comme l’exploitation massive de Langflow CVE-2026-0768 — rendent ce sujet plus urgent que jamais.

Etape 1 — Choisir la bonne image de base et structurer le multi-stage build

Le choix de l’image de base conditionne tout : la taille finale de l’image, la surface d’attaque, la compatibilite avec vos dependances, et les performances au runtime. Pour les applications IA Python, le reflexe est souvent de partir de python:3.12 — une image de plus de 1 Go qui inclut un compilateur C, des headers de developpement, et des centaines de packages systeme dont vous n’aurez jamais besoin en production.

La solution est le build multi-stage. Le principe est simple : une premiere etape (le « builder ») installe les dependances, compile les extensions natives (les *.so de PyTorch, numpy, etc.) et prepare l’environnement Python. Une deuxieme etape (le « runner ») copie uniquement les fichiers necessaires depuis le builder dans une image minimale. Le resultat typique : une image de production de 600 a 800 Mo au lieu de 4+ Go, avec une surface d’attaque reduite de 80 %.

Pour l’etape de build, utilisez python:3.12-slim comme base. L’image slim contient les headers necessaires pour compiler la plupart des extensions Python tout en etant 5 fois plus legere que l’image complete. Si vos dependances necessitent des bibliotheques systeme specifiques (comme libgl1 pour OpenCV ou libsndfile1 pour le traitement audio), installez-les dans l’etape de build avec apt-get install --no-install-recommends.

Pour l’etape finale, deux options. Si vous avez besoin du GPU, utilisez nvidia/cuda:12.6-runtime-ubuntu24.04 comme base de l’etape runner — l’image runtime est suffisante pour l’inference, l’image devel est reservee a la compilation de noyaux CUDA. Sans GPU, restez sur python:3.12-slim ou explorez les images distroless de Google pour une surface d’attaque minimale.

Quelques regles absolues : epinglez toujours une version precise de l’image de base (jamais :latest), groupez les instructions RUN pour reduire le nombre de couches, et placez les copies de fichiers qui changent frequemment (votre code source) apres celles qui changent rarement (les dependances) pour maximiser le cache Docker.

Etape 2 — Gerer les dependances Python massives sans exploser la taille de l’image

Les dependances d’une application IA ne ressemblent en rien a celles d’une application web classique. PyTorch pese 2 Go. TensorFlow avoisine les 1,5 Go. Les modeles de sentence-transformers ajoutent 400 Mo. Si vous installez ces dependances naïvement dans un Dockerfile, vous obtenez une image de 6 a 8 Go qui prend 10 minutes a construire et 5 minutes a pousser vers un registre.

La premiere optimisation est d’installer uniquement les variantes CPU ou GPU de PyTorch selon votre cible de deploiement. La commande pip install torch --index-url https://download.pytorch.org/whl/cpu installe la variante CPU-only qui pese 300 Mo au lieu de 2 Go. Si vous avez besoin du GPU, ciblez la version CUDA correspondant a votre image de base : --index-url https://download.pytorch.org/whl/cu126 pour CUDA 12.6.

La deuxieme optimisation est le fichier de contraintes. Creez un requirements.txt avec des versions epinglees (via pip freeze ou pip-compile) et un fichier constraints.txt qui exclut les packages de developpement et de test. Utilisez pip install --no-deps pour les packages principaux, puis pip install -r requirements.txt pour resoudre les dependances completes. Cette approche evite l’installation de packages de test, de documentation et d’outils de build qui se glissent souvent dans l’arbre de dependances.

La troisieme optimisation est l’utilisation de uv au lieu de pip. L’installateur uv (ecrit en Rust par Astral, les createurs de Ruff) est 10 a 100 fois plus rapide que pip pour la resolution et l’installation de dependances. Dans un Dockerfile, remplacez pip install -r requirements.txt par uv pip install --system -r requirements.txt. Le gain de temps sur un build qui installe 200+ packages est considerable. Le guide sur la configuration d’environnements Python avec uv detaille les avantages de cette migration.

Enfin, utilisez un fichier .dockerignore agressif pour exclure les repertoires __pycache__, .git, *.pyc, les environments virtuels locaux (.venv), les modeles locaux, et les fichiers de donnees. Chaque fichier copie dans le contexte de build ralentit la commande docker build et peut invalider le cache inutilement.

Etape 3 — Configurer le GPU passthrough pour l’inference

L’inference de modeles IA en production necessite un GPU dans la grande majorite des cas. Un modele de 7 milliards de parametres (Mistral 7B, Llama 3.1 8B) genere des tokens 20 a 50 fois plus rapidement sur un GPU NVIDIA A10G que sur un CPU Intel moderne. La conteneurisation du GPU avec Docker repose sur le NVIDIA Container Toolkit (anciennement nvidia-docker2).

Le prerequis cote hote est l’installation du driver NVIDIA et du NVIDIA Container Toolkit. Sur Ubuntu 24.04, c’est une sequence de quatre commandes : ajout du repository NVIDIA, installation de nvidia-container-toolkit, redemarrage de Docker, et verification avec docker run --gpus all nvidia/cuda:12.6-base-ubuntu24.04 nvidia-smi. Si nvidia-smi affiche vos GPU depuis le conteneur, la configuration est correcte.

Dans le Dockerfile, la cle est l’image de base. Utilisez nvidia/cuda:12.6-runtime-ubuntu24.04 pour l’inference (contient les bibliotheques CUDA runtime sans les outils de compilation) ou nvidia/cuda:12.6-cudnn-runtime-ubuntu24.04 si vous avez besoin de cuDNN (pour les modeles TensorFlow ou les operations de convolution). La version CUDA de l’image doit correspondre a celle du driver installe sur l’hote — verifiez la compatibilite dans la matrice NVIDIA.

Au runtime, exposez le GPU avec le flag --gpus all pour donner acces a tous les GPU, ou --gpus "device=0" pour un GPU specifique. Dans un fichier Docker Compose, utilisez la section deploy.resources.reservations.devices pour declarer les GPU requis. Pour les deploiements multi-tenant ou plusieurs conteneurs partagent un GPU, activez le MPS (Multi-Process Service) ou le time-slicing de NVIDIA pour repartir equitablement le temps GPU.

Un piege courant : les variables d’environnement CUDA_VISIBLE_DEVICES et NVIDIA_VISIBLE_DEVICES. La premiere est interpretee par les bibliotheques CUDA a l’interieur du conteneur, la seconde par le NVIDIA Container Toolkit au moment du lancement. Les confondre produit des erreurs silencieuses ou le modele tourne sur CPU sans que vous le sachiez — avec un facteur de latence de 20x en production. Validez toujours le GPU dans votre script d’entrypoint avec un torch.cuda.is_available() ou equivalent.

Etape 4 — Gerer les modeles IA volumineux en dehors de l’image

C’est probablement l’erreur la plus courante dans la conteneurisation d’applications IA : embarquer le modele dans l’image Docker. Un modele Llama 3.1 8B au format GGUF pese 4,7 Go. Un modele de sentence-transformers comme all-MiniLM-L6-v2 pese 90 Mo mais le cache Hugging Face associe fait 200 Mo. Integrer ces fichiers dans l’image transforme chaque docker pull en une operation de 20 minutes et chaque mise a jour du code applicatif en un re-telechargement complet du modele.

La bonne approche est de stocker les modeles dans des volumes Docker nommes et de les monter au runtime. Creez un volume dedie : docker volume create ia-models. Montez-le dans le conteneur au point ou votre framework attend les modeles : -v ia-models:/models pour un repertoire generique, ou -v ia-models:/root/.cache/huggingface pour le cache Hugging Face.

Le script d’entrypoint doit verifier la presence du modele au demarrage et le telecharger si absent. Implementez cette verification avec un hash SHA256 : calculez le hash du modele attendu, stockez-le dans une variable d’environnement ou un fichier de configuration, et comparez-le au hash du fichier present dans le volume. Cette verification garantit que le modele n’a pas ete corrompu ou remplace par un artefact malveillant — un risque reel apres les incidents de supply chain sur les packages open source.

Pour les deploiements multi-conteneurs qui partagent le meme modele (par exemple, 4 replicas d’un serveur d’inference), un seul volume suffit : montez-le en lecture seule (:ro) sur les replicas d’inference et en lecture-ecriture sur un conteneur init dedie au telechargement. Cette architecture elimine la duplication de modeles et reduit les couts de stockage de 75 % dans les deploiements horizontalement scales.

Etape 5 — Concevoir un entrypoint robuste avec preload et health checks

Le demarrage d’une application IA n’est pas instantane. Le chargement d’un modele de 7 milliards de parametres en memoire GPU prend 15 a 45 secondes selon le materiel et le format du modele. Pendant ce temps, le conteneur est « en cours de demarrage » mais pas « pret a servir ». Si votre orchestrateur (Kubernetes, Docker Compose avec des health checks) ne distingue pas ces deux etats, il va envoyer du trafic a un conteneur qui n’a pas encore charge son modele, resultant en des erreurs 503 ou des timeouts.

La solution est un entrypoint en trois phases. Phase 1 : initialisation. Le script verifie les prerequis (GPU disponible, modele present dans le volume, connectivity aux services dependants). Si un prerequis manque, le conteneur echoue immediatement avec un message d’erreur explicite — pas un crash silencieux 30 secondes plus tard. Phase 2 : preload. Le modele est charge en memoire (GPU ou CPU) et un premier appel d’inference « warmup » est effectue pour forcer la compilation JIT des noyaux CUDA. Phase 3 : service. Le serveur HTTP (FastAPI, uvicorn, vLLM) demarre et commence a accepter les requetes.

Implementez deux endpoints de sante. Le liveness probe (/healthz) confirme que le processus est vivant — il retourne 200 si le serveur HTTP repond, independamment de l’etat du modele. Le readiness probe (/readyz) confirme que le modele est charge et que le conteneur est pret a traiter des requetes d’inference. Kubernetes utilise le liveness probe pour redemarrer les conteneurs bloques et le readiness probe pour router le trafic uniquement vers les conteneurs prets.

Le graceful shutdown est tout aussi important. Quand le conteneur recoit un signal SIGTERM (deploiement, scaling down, maintenance), il doit arreter d’accepter de nouvelles requetes, terminer les requetes en cours (avec un timeout raisonnable de 30 a 60 secondes), liberer la memoire GPU, et quitter proprement. Sans cela, les requetes en cours sont coupees et les ressources GPU restent allouees jusqu’au timeout du orchestrateur.

Etape 6 — Securiser le conteneur pour un deploiement en production

La securisation d’un conteneur IA n’est pas differente conceptuellement de celle d’un conteneur classique, mais les enjeux sont plus eleves. Un conteneur IA en production heberge des cles API qui valent des milliers d’euros par mois, accede a des donnees sensibles via des pipelines RAG, et dispose souvent d’un acces GPU qui a une valeur de calcul considerable. L’exploitation recente de Langflow CVE-2026-0768 a montre comment un conteneur IA mal securise devient une mine d’or pour le credential harvesting.

Regle 1 : utilisateur non-root. Creez un utilisateur dedie dans le Dockerfile (RUN adduser --system --no-create-home appuser) et basculez vers cet utilisateur avec USER appuser avant le CMD. Le processus IA n’a jamais besoin des privileges root pour faire de l’inference. Si vos dependances exigent root a l’installation, faites-le dans l’etape de build du multi-stage et copiez les fichiers dans l’etape finale qui tourne en non-root.

Regle 2 : filesystem en lecture seule. Lancez le conteneur avec --read-only et ajoutez des tmpfs pour les repertoires ou l’application a besoin d’ecrire temporairement (/tmp, le repertoire de cache du tokenizer). Un filesystem en lecture seule empeche un attaquant qui obtient une RCE de persister un backdoor ou de modifier les fichiers de configuration.

Regle 3 : capabilities minimales. Par defaut, Docker attribue un ensemble de capabilities Linux au conteneur. Retirez-les toutes avec --cap-drop=ALL, puis ajoutez uniquement celles dont l’application a besoin. Pour une application IA d’inference, aucune capability supplementaire n’est generalement necessaire. Si votre application a besoin de binder un port sous 1024, ajoutez --cap-add=NET_BIND_SERVICE — mais il est prefereable d’utiliser un port au-dessus de 1024 et de router via un reverse proxy.

Regle 4 : scan de vulnerabilites. Integrez trivy image votre-image:tag dans votre pipeline CI/CD et bloquez le deploiement si des CVE critiques sont detectees. Pour les images IA, scannez egalement les dependances Python avec trivy fs --scanners vuln /app — les bibliotheques comme PyTorch, Pillow et numpy sont frequemment concernees par des CVE. L’audit de dependances Python est une etape indispensable avant chaque release.

Regle 5 : gestion des secrets. Ne stockez jamais de cles API dans les variables d’environnement du Dockerfile (instruction ENV) ou dans les layers de l’image. Utilisez les Docker Secrets en mode Swarm, les ExternalSecrets avec Kubernetes, ou montez les credentials depuis un gestionnaire de secrets (Vault, AWS Secrets Manager) au runtime via un volume temporaire. La valeur des credentials dans un conteneur IA est trop elevee pour tolerer un stockage en clair.

Docker Compose vs Kubernetes pour les applications IA : tableau comparatif

Le choix de l’orchestrateur depend de la complexite de votre deploiement, du nombre de replicas, et de vos besoins en scaling GPU. Voici un tableau comparatif pour guider votre decision.

Pour les PME francaises qui debutent avec l’IA en production, notre recommandation est pragmatique : commencez par Docker Compose pour le developpement et le staging. Quand vous atteignez le point ou vous avez besoin de zero-downtime deployments, de scaling automatique ou de gestion avancee du GPU, migrez vers Kubernetes — ou plus precisement vers K3s, une distribution Kubernetes legere parfaitement adaptee aux PME. Le guide de migration Docker Compose vers Kubernetes couvre cette transition en detail.

Etape 7 — Orchestrer et monitorer en production

L’orchestration d’applications IA en production a ses propres specificites. Un serveur d’inference (vLLM, TGI, Ollama) consomme la totalite de la memoire GPU meme quand il ne traite aucune requete — le modele reste charge en VRAM pour garantir une latence de premiere inference inferieure a 100 ms. Cette caracteristique a des implications directes sur le scaling et le cout.

Scaling GPU-aware. Le scaling horizontal classique (ajouter des replicas quand le CPU ou la memoire depasse un seuil) ne fonctionne pas pour l’inference IA. Utilisez des metriques personnalisees : le nombre de requetes en file d’attente, la latence P99, ou le taux d’utilisation GPU (via nvidia-smi --query-gpu=utilization.gpu). Avec Kubernetes, le Horizontal Pod Autoscaler (HPA) combine a KEDA (Kubernetes Event-Driven Autoscaling) permet de scaler sur n’importe quelle metrique Prometheus, y compris les metriques GPU NVIDIA exportees par le dcgm-exporter.

Monitoring specifique IA. Au-dela des metriques systeme classiques (CPU, memoire, reseau), surveillez les metriques d’inference : tokens par seconde, latence de premiere token (TTFT), latence inter-token, taille du batch, taux de cache KV, et utilisation de la VRAM. vLLM et TGI exposent ces metriques nativement au format Prometheus. Deployez un stack de monitoring dedie avec Prometheus pour la collecte, Grafana pour la visualisation, et Alertmanager pour les alertes.

Logging structure. Les logs d’une application IA contiennent des informations sensibles : les prompts utilisateurs, les reponses du modele, les tokens d’API dans les headers. Implementez un logging structure (JSON) avec un filtrage explicite des champs sensibles. Utilisez les labels OpenTelemetry pour tracer les requetes de bout en bout, du reverse proxy au serveur d’inference, en passant par les appels aux bases vectorielles.

Cout et optimisation. Le GPU est la ressource la plus couteuse d’un deploiement IA. Un GPU NVIDIA A100 coute environ 3 euros par heure en cloud, soit 2 100 euros par mois. Optimisez l’utilisation en implementant le batching dynamique (regrouper plusieurs requetes dans un seul appel d’inference), le quantization (reduire la precision du modele de FP16 a INT4 pour diviser la consommation VRAM par 4), et le scale-to-zero pour les workloads intermittents (eteindre les replicas GPU quand il n’y a pas de trafic, avec un cold start de 30 a 60 secondes). Notre guide pour deployer Ollama en production securisee detaille ces optimisations pour les modeles open weight.

Les 5 erreurs fatales a eviter

Erreur 1 : embarquer le modele dans l’image Docker. Chaque docker pull re-telecharge 5 a 10 Go de poids de modele. Chaque mise a jour du code applicatif invalide la couche du modele. La solution : volumes nommes avec telechargement a l’init (etape 4).

Erreur 2 : utiliser :latest comme tag d’image de base. Le tag latest pointe vers une image differente chaque semaine. Un build qui fonctionnait lundi peut echouer vendredi parce que la base a change. La solution : epinglez une version precise (python:3.12.5-slim-bookworm).

Erreur 3 : ignorer le .dockerignore. Sans .dockerignore, Docker copie le repertoire .git (parfois 500 Mo), les environnements virtuels locaux (2 Go), et les modeles telecharges en local (10+ Go) dans le contexte de build. Le build prend 15 minutes au lieu de 2.

Erreur 4 : stocker les cles API dans le Dockerfile. L’instruction ENV OPENAI_API_KEY=sk-... persiste la cle dans une couche de l’image. N’importe qui avec acces a l’image peut l’extraire avec docker inspect ou docker history. La solution : injection au runtime via secrets manager (etape 6).

Erreur 5 : pas de health check. Sans health check, votre orchestrateur envoie du trafic a un conteneur qui charge encore son modele (30 secondes de 503). Sans readiness probe, Kubernetes n’attend pas la fin du chargement du modele avant de router le trafic. La solution : endpoints /healthz et /readyz avec preload warmup (etape 5).

Questions frequentes