Docker Compose en production en 2026 : le cadre de décision d’un CTO

Vous n’avez pas besoin de Kubernetes. Pas encore. Si votre produit est avant la série B, que votre trafic se compte en dizaines de millions de requêtes par mois (pas en milliards) et que votre équipe compte moins d’une douzaine d’ingénieurs, Docker Compose en production peut être le bon choix — à condition de le traiter comme de la production, pas comme un environnement de développement prolongé.

Le débat a repris ce mois-ci après une nouvelle salve d’articles posant la question « Faut-il exécuter un simple Docker Compose en production en 2026 ? » et une semaine de gros titres sécurité : un contournement d’authentification cPanel activement exploité, des instances Ubuntu pilonnées par des DDoS, et des divulgations de vulnérabilités du noyau sans préavis pour les distributions. Traduction : votre surface d’exploitation sera mise à l’épreuve que vous tourniez sur k8s ou Compose. La question est la complexité que vous voulez payer aujourd’hui.

La véritable décision à prendre

Vous ne choisissez pas entre un « Compose jouet » et un « vrai Kubernetes ». Vous choisissez entre :

• Un à quelques hôtes, réseau simple, charges prévisibles, 99,9 % SLO — Compose + un hôte Linux durci + un proxy inverse + des déploiements disciplinés.
• Beaucoup d’hôtes, charges en pics ou spécialisées (GPU/ML/batch), isolation multi-tenant, 99,99 %+ — un ordonnanceur (Kubernetes, ECS ou Nomad) avec l’outillage et la maturité d’équipe qui vont avec.

Tout le reste est du détail. Voici le cadre que nous utilisons avec des startups et scale-ups US (et que nos équipes SRE basées au Brazil opèrent au quotidien).

La grille en 8 axes d’un CTO pour évaluer la viabilité de Compose

1) Taille de l’équipe et maturité d’astreinte

• Compatible Compose : 2–6 ingénieurs, 1–2 SRE ou généralistes aguerris, une seule rotation d’astreinte, et un seuil clair « une personne peut comprendre toute la stack ».
• Territoire ordonnanceur : 3+ squads, équipe plateforme dédiée, >30 services, ou mandat d’infra en self-service par équipes feature.

2) Profil de charge

• Compatible Compose : Principalement des API web long-courant, quelques workers, des tâches planifiées type cron, une base de données, un cache.
• Territoire ordonnanceur : Tâches batch en pics, GPU/accélérateurs, bacs à sable par tenant, ou des centaines de tâches éphémères/jour.

3) SLO et budget d’indisponibilité

• Compatible Compose : 99,9 % de disponibilité (≈ 43 minutes/mois). Les déploiements blue/green ou des redémarrages échelonnés permettent de rester dans le budget.
• Territoire ordonnanceur : 99,99 % (≈ 4,3 minutes/mois) ou plus, HA multi-AZ, replanification automatisée sur plusieurs nœuds.

4) Cadence de déploiement et rollback

• Compatible Compose : Releases quotidiennes avec blue/green ou canary par en-tête dans le proxy en edge, rollback simple en changeant le nom de projet Compose.
• Territoire ordonnanceur : Déploiements multiples/heure sur des dizaines de services avec canarying automatique et gestion de trafic.

5) Réseau et découverte de services

• Compatible Compose : Un petit nombre de réseaux internes, Traefik/Caddy en frontal, découverte basée DNS sur 1–3 hôtes.
• Territoire ordonnanceur : Maillage complexe, network policies, mTLS entre services, réseaux virtuels par tenant.

6) Charges avec état

• Compatible Compose : Un ou deux services stateful (Postgres, Redis) sur des VM dédiées avec sauvegardes managées et PITR.
• Territoire ordonnanceur : Des dizaines de stateful sets, volumes dynamiques multi-nœuds, ou HA stricte multi-AZ pour les bases de données.

7) Conformité et isolation

• Compatible Compose : SOC2 avec infra mono-tenant par environnement, gestion simple des secrets, audit depuis l’hôte.
• Territoire ordonnanceur : HIPAA/PCI avec network policies, niveaux de sécurité de pods et contraintes d’exécution fines.

8) Coûts et priorités

• Compatible Compose : Vous voulez livrer des fonctionnalités, pas opérer une plateforme. Comptez 2 à 4 heures‑ingénieur/mois de maintenance infra.
• Territoire ordonnanceur : Vous payez déjà pour une équipe plateforme ou un fournisseur ; l’infra est un avantage compétitif.

Un blueprint Compose niveau production (2026)

Si vos réponses penchent « Compatible Compose », exécutez‑le sérieusement. Voici un blueprint que nous durcissons pour des équipes traitant 10–150 rps en moyenne (pics x5–10) avec un SLO de 99,9 %.

Hôtes et OS

• Commencez avec deux VM de production (optimisées compute, p. ex. c7a.large ou équivalent) derrière un équilibreur de charge managé. Placez Postgres sur sa propre VM. Cela apporte isolation, reprise simple et évite les « voisins bruyants ».
• Activez les mises à jour de sécurité automatiques et planifiez un créneau hebdomadaire de patch. Avec des vulnérabilités du noyau publiées sans préavis, partez du principe qu’il faudra redémarrer au moins une fois par mois. Concevez des redémarrages roulants (voir ci‑dessous).
• Durcissez Docker : user namespaces, seccomp par défaut, no-new-privileges, suppression de NET_RAW, définissez des limites mémoire/CPU pour chaque conteneur. Envisagez Docker rootless ou Podman si votre équipe est à l’aise avec les compromis.

Réseau et ingress

• Faites tourner Traefik (ou Caddy) comme proxy de bord. TLS automatique via Let’s Encrypt, sessions persistantes si nécessaire, et canary par service via en‑tête ou cookie.
• Utilisez des réseaux Compose pour isoler des groupes de services. Seul le proxy est publié sur Internet. Tout le reste est interne uniquement.

Déploiements et zéro interruption

• Blue/green par nom de projet : exécutez deux stacks sur le même réseau hôte (par ex., projet 'blue' et 'green'). Au déploiement, démarrez la nouvelle stack, passez les health checks, puis basculez Traefik vers les nouveaux labels et arrêtez l’ancienne. Le rollback est une simple inversion de label.
• Les health checks comptent : utilisez start_period et interval/timeout/retries pour encoder la readiness. Ne confondez pas liveness et readiness.
• Automatisez les déploiements avec un job CI qui fait : build → push → ssh → docker compose pull → montée de la nouvelle couleur → exécution de smoke tests → bascule des labels.

Secrets et configuration

• Privilégiez un gestionnaire de secrets managé (AWS SSM, GCP Secret Manager, 1Password Connect). Au déploiement, générez des fichiers env et montez‑les en lecture seule dans les conteneurs.
• Si vous devez conserver des fichiers .env sur l’hôte, stockez‑les chiffrés au repos avec sops et déchiffrez uniquement en mémoire pendant le déploiement.

Observabilité

• Métriques : node_exporter + cAdvisor → Prometheus → dashboards Grafana. Alertez sur la saturation (CPU steal, pression mémoire), les taux d’erreur et la latence au 95e centile.
• Logs : Docker → Loki via Promtail ou vers le service de logs de votre cloud provider. Conservez 14–30 jours en chaud ; archivez l’historique plus ancien vers du stockage objet.
• Tracing : OpenTelemetry vers un backend managé (Tempo, Honeycomb ou Datadog). Échantillonnez à 5–10 % pour garder des coûts raisonnables.

Sauvegardes et reprise après sinistre

• Postgres : pgBackRest ou un Postgres managé avec PITR. Visez RPO ≤ 5 minutes (expédition des WAL) et RTO ≤ 60 minutes.
• Assets/état : Préférez le stockage objet (S3/compatible). Pour de petits volumes, sauvegardez avec restic chaque nuit. Testez les restaurations mensuellement.
• Snapshottez les VM chaque nuit. Conservez 14 jours de snapshots ; script d’un rebuild vers de nouveaux hôtes.

Posture de sécurité

• Pare-feu : deny par défaut ; seuls l’équilibreur de charge et SSH sont ouverts. Envisagez Cloudflare ou Fastly en frontal pour absorber les DDoS. L’épisode DDoS sur Ubuntu ce mois‑ci rappelle qu’il ne faut pas exposer vos origines.
• SBOM et scan d’images : construisez des images minimales (distroless ou slim), scannez en CI, épinglez les digests dans Compose, et faites tourner vos images de base toutes les deux semaines.
• Exécution : activez des systèmes de fichiers racine en lecture seule quand c’est possible ; montez les volumes avec le minimum de permissions ; réduisez les capabilities Linux.

Là où Compose atteint ses limites (et quoi faire à la place)

Définissez clairement la limite de l’enveloppe. Si l’un de ces besoins apparaît sur votre feuille de route, commencez à planifier un passage :

• Planification multi‑hôtes et auto‑récupération : si vous voulez que les conteneurs se replanifient automatiquement en cas de panne de nœud sans orchestrer vous‑même du blue/green, regardez ECS on Fargate (le moins d’ops) ou Kubernetes (le plus de contrôle).
• Autoscaling horizontal : vous pouvez scripter la montée/descente d’échelle avec Compose, mais si le trafic est très en dents de scie ou si le coût est crucial, les HPA/auto‑scaling ECS Service gagnent.
• Network policies et mTLS par défaut : vous pouvez bricoler avec iptables et des sidecars, mais c’est fragile. Si vous avez besoin d’une isolation réseau fine, migrez.
• Des dizaines d’équipes et de services : l’infra en self-service exige des garde‑fous, des quotas et des ressources modélisées. C’est un problème de plateforme, pas de compose.yaml.
• Planification GPU/ML intensive ou orchestration de batch : utilisez un ordonnanceur conçu pour les accélérateurs et les tâches éphémères.

Les coûts : la partie que la plupart des équipes sous‑estiment

À petite échelle, la « taxe » Kubernetes est principalement du temps humain. Même avec des plans de contrôle managés, attendez‑vous à :

• Socle k8s managé : frais de control plane (70–150 $/mo), passerelles NAT (30–70 $/mo chacune), plus la surcharge des groupes de nœuds. En pratique, la plupart des équipes que nous voyons dépensent 800–2 000 $/mois avant la charge applicative.
• Temps ingénieur : 8–20 heures/mois pour l’hygiène de cluster, les mises à jour et la classe de problèmes « c’est toujours le DNS ». Si votre coût chargé par ingénieur est de 150 $/h, cela représente 1 200–3 000 $/mois.
• Socle Compose : deux VM de taille moyenne à 80–120 $ chacune, une base de données managée 150–400 $, un équilibreur de charge 20–30 $. Soit 350–700 $/mois d’infra et 2–4 heures/mois de soins si vous gardez la stack compacte et disciplinée.

Ce ne sont pas des hypothèses. Nous opérons Compose en production pour des startups traitant 10–30 M de requêtes/mois avec un SLO de 99,9 %, pour 20–40 % de coût infra en moins et 50–70 % de temps ops en moins que leur « k8s de démarrage » précédent. Le compromis : du capacity planning et des modes de panne plus simples que vous devez encoder vous‑même.

Pattern de déploiement concret (qui fonctionne vraiment)

1. Structure du repo : code applicatif + infra/compose avec overrides par environnement (compose.prod.yaml, compose.staging.yaml). Gardez des images versionnées et épinglées par digest.
2. Build : Dockerfiles multi‑étapes, bases distroless/slim, génération de SBOM. Push vers un registre privé.
3. Release candidate : le job CI tag l’image avec le SHA git et écrit un manifeste de release avec les digests d’images.
4. Déploiement : la CI se connecte en SSH aux hôtes cibles, récupère le manifeste de release, démarre la nouvelle couleur avec docker compose up -d, attend les checks de santé, bascule les labels Traefik.
5. Smoke test : exécutez un court e2e sur la route canary (basée en‑tête) ; si c’est propre, promouvez à 100 %.
6. Post‑déploiement : vérifiez les dashboards, budgets d’erreur, et revenez en arrière en inversant les labels si nécessaire.

Évitez les « watchtower auto-updates ». Vous échangez la répétabilité contre la surprise. Vous voulez des déploiements intentionnels, même sur Compose.

Pratiques d’exploitation : patching et réponse aux incidents

Ces dernières semaines l’ont rappelé : les attaquants aiment la longue traîne. Le contournement d’auth cPanel et le DDoS Ubuntu ne se souciaient pas de savoir si les équipes tournaient sur k8s ou Compose ; ils ont puni le patching lent et les origines exposées. Traitez le patching comme un flux de travail de première classe :

• Créneau de patch hebdomadaire : planifiez‑le et annoncez‑le. En mode blue/green, patchez la couleur inactive, basculez, puis patchez l’autre.
• Réalités du noyau : avec des CVE du noyau « sans préavis », considérez les redémarrages comme acquis. Concevez pour. Votre processus blue/green doit faire d’un reboot un non‑événement.
• Un CDN en frontal : absorbez les DDoS volumétriques et rate‑limitez les mauvais acteurs. Terminez le TLS à la périphérie et gardez les origines privées.

Quand planifier la migration (avant que ça ne fasse mal)

N’attendez pas que la douleur vous force à une réécriture de plateforme en 90 jours. Démarrez un radar de migration dès que l’un de ces éléments devient vrai :

• Deux équipes ou plus demandent des environnements en self‑service.
• Vous avez besoin d’autoscaling plus rapide que ce que votre CI/CD peut déployer en nouvelle couleur.
• La sécurité demande des network policies que vous ne pouvez pas appliquer confortablement au niveau hôte.
• Vous franchissez ~30 services et vos fichiers compose ressemblent à une machine de Rube Goldberg.

À ce stade, choisissez un ordonnanceur en fonction de votre cloud et de votre vivier de talents : ECS on Fargate pour le minimum d’ops (surtout sur des stacks centrées AWS), Kubernetes si vous avez besoin de portabilité ou des fonctionnalités d’un écosystème riche, ou Nomad si vous privilégiez la simplicité et pouvez vivre sans l’ubiquité de k8s. Budgétez la migration comme une feature : 6–10 semaines pour une équipe expérimentée, plus si vous refondez aussi le réseau et la CI.

Un exemple réaliste

Une SaaS type fintech de série A : 6 microservices (Go + Node), un worker, une tâche planifiée, Postgres, Redis, 10 M de requêtes/mois (moy. 4 rps, pic 50–100 rps), 2–3 ingénieurs d’astreinte. Cibles : 99,9 % SLO, SOC2, clients US/EU.

• Infra : deux VM c7a.large pour l’app + Postgres managé + Redis sur une petite VM. Traefik sur chaque VM applicative ; l’équilibreur de charge cloud distribue vers les deux.
• Déploiements : blue/green par hôte, inversion de labels via Traefik, 1–2 déploiements/jour.
• Sécurité : SBOM en CI, épinglage par digest des images, secrets depuis SSM, racines en lecture seule, no-new-privileges, NET_RAW supprimé. CDN en frontal, origines privées.
• Ops : 2 h/semaine : patching, vérification des tableaux de bord, test de restauration mensuel. Observabilité vers Grafana + Loki + Tempo.
• Résultats : 99,93 % de disponibilité sur un trimestre ; un incident (15 minutes) dû à une file worker non bornée, corrigé en définissant des limites mémoire Compose et du backpressure.

Où le nearshore s’insère

Si vous choisissez Compose, vous choisissez une surface ops plus petite — bien. Mais les créneaux de patch et les incidents nocturnes arrivent quand même. Une équipe SRE basée au Brazil avec 6–8 heures de chevauchement avec les US peut exécuter le cycle de patch hebdomadaire, gérer les bascules blue/green et traiter les incidents hors heures pendant que votre équipe cœur dort. D’expérience, un engagement SRE nearshore de 0,5–1,0 ETP suffit à garder une stack Compose de production conforme, à jour et ennuyeuse — exactement ce que vous voulez.

Conclusion

Docker Compose en production n’est pas un secret honteux ; c’est un arbitrage assumé. Si vous avez moins de 30 services, un SLO à 99,9 %, et pas besoin d’isolation par tenant ni de replanification multi‑AZ, vous pouvez aller plus vite et dépenser moins avec Compose — à condition de durcir l’hôte, d’automatiser le blue/green, de placer un CDN en frontal, et de traiter le patching comme du travail produit. Quand votre feuille de route exigera un ordonnanceur, vous le saurez. D’ici là, gardez votre stack simple et vos budgets d’erreur au vert.

Points clés

• Compose est viable en production en 2026 pour de petites équipes, des charges prévisibles et des SLO à 99,9 % — si vous l’exécutez comme de la production.
• Utilisez un hôte Linux durci, Traefik/Caddy, blue/green par nom de projet, images épinglées par digest, et de vrais health checks.
• Attendez‑vous à 20–40 % de coûts infra en moins et 50–70 % de temps ops en moins que « le k8s de départ » à petite échelle ; réinvestissez ce temps dans les fonctionnalités.
• La sécurité est un prérequis : pare‑feu deny par défaut, CDN en frontal, racines en lecture seule, capabilities réduites, créneaux de patch hebdos, sauvegardes testées.
• Planifiez une migration quand vous avez besoin d’autoscaling, de network policies fines, d’isolation multi‑tenant, ou quand vous dépassez ~30 services.
• Le SRE nearshore (Brazil) couvre patching et incidents avec 6–8 heures de chevauchement, gardant votre stack Compose ennuyeuse et conforme.