🐳 Docker & Conteneurs — Le guide complet

Introduction — Pourquoi Docker est incontournable en 2026

Si tu travailles dans l’IT en 2026 et que tu ne maîtrises pas Docker, tu passes à côté d’un outil fondamental. Ce n’est pas une mode passagère — Docker a redéfini la façon dont on construit, distribue et exécute des applications depuis plus de 10 ans maintenant, et son adoption ne fait que croître.

Les chiffres parlent d’eux-mêmes : plus de 20 millions de développeurs utilisent Docker au quotidien. Docker Hub héberge des millions d’images. Pratiquement toute pipeline CI/CD moderne repose sur des conteneurs. Kubernetes, le standard de l’orchestration, s’appuie sur des conteneurs Docker (ou compatibles OCI). Bref, Docker est devenu le socle sur lequel repose l’infrastructure moderne.

Mais concrètement, c’est quoi un conteneur ?

Un conteneur, c’est une unité d’exécution légère et isolée qui embarque tout ce dont une application a besoin pour tourner : le code, les dépendances, les librairies système, la configuration. Contrairement à une machine virtuelle, un conteneur ne virtualise pas un OS complet — il partage le noyau Linux de la machine hôte tout en maintenant une isolation au niveau des processus, du réseau et du système de fichiers.

graph TB
    subgraph Host["Machine Hôte Linux"]
        subgraph Containers["Conteneurs"]
            A["App A
Node 20
Alpine"]
            B["App B
Python 3
Debian"]
            C["App C
Go 1.22
Scratch"]
        end
        Engine["Docker Engine"]
        Kernel["Noyau Linux"]
    end
    Containers --> Engine
    Engine --> Kernel
    style Host fill:#1a2332,stroke:#dc2626,color:#f1f5f9
    style A fill:#1a2332,stroke:#3b82f6,color:#f1f5f9
    style B fill:#1a2332,stroke:#22c55e,color:#f1f5f9
    style C fill:#1a2332,stroke:#f59e0b,color:#f1f5f9
    style Engine fill:#1a2332,stroke:#a855f7,color:#f1f5f9
    style Kernel fill:#1a2332,stroke:#64748b,color:#f1f5f9
    style Containers fill:#0f172a,stroke:#475569,color:#f1f5f9

Résultat : tu démarres un conteneur en millisecondes (pas en minutes comme une VM), tu en exécutes des dizaines sur un laptop, et tu as la garantie que ce qui tourne en dev tournera exactement pareil en prod. Le fameux “ça marche sur ma machine” ? Avec Docker, ça marche partout.

Ce que cette formation va t’apporter

Cette formation Docker est conçue pour t’emmener du niveau zéro à la mise en production, de façon progressive et pratique. Chaque chapitre est pensé pour être suivi dans l’ordre, mais tu peux aussi piocher selon tes besoins si tu as déjà des bases.

À la fin de ce parcours, tu seras capable de :

• Comprendre le fonctionnement interne de Docker (namespaces, cgroups, union filesystem)
• Construire des images Docker optimisées avec des Dockerfiles multi-stage
• Orchestrer des stacks complètes avec Docker Compose
• Déployer en production avec les bonnes pratiques de sécurité et de performance
• Débugger efficacement quand ça plante (et ça va planter, c’est normal)

---

Prérequis

Avant de plonger dans Docker, assure-toi d’avoir ces bases :

Compétences requises

Compétence	Niveau	Pourquoi
Linux / ligne de commande	Intermédiaire	Docker repose sur Linux. Tu dois être à l’aise avec cd, ls, cat, les permissions, les pipes
Réseau TCP/IP	Bases	Comprendre les ports, DNS, HTTP aide énormément pour le networking Docker
Un langage de programmation	Débutant+	Pour écrire les apps que tu vas conteneuriser — peu importe le langage
Git	Bases	Pour versionner tes Dockerfiles et docker-compose.yml

Environnement technique

• Docker Desktop (Mac/Windows) ou Docker Engine (Linux) — version 24+ recommandée
• Un éditeur de code avec support YAML/Dockerfile (VS Code avec l’extension Docker est parfait)
• Un terminal — iTerm2, Windows Terminal, ou le terminal intégré de ton éditeur
• 8 Go de RAM minimum — Docker consomme de la mémoire, surtout avec plusieurs conteneurs

Installation rapide

# Linux (Ubuntu/Debian)
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
# Déconnexion/reconnexion nécessaire pour le groupe

# Vérification
docker --version
docker run hello-world

# macOS — via Homebrew
brew install --cask docker
# Lancer Docker Desktop, attendre que le daemon démarre

docker --version
docker compose version

Durée estimée

Parcours	Durée
Lecture complète	~12 heures
Avec exercices pratiques	~20 heures
Maîtrise approfondie	~40 heures (inclut projets personnels)

Niveau : Débutant → Intermédiaire avancé

---

Parcours de formation

Cette formation se découpe en 10 chapitres progressifs. Chaque chapitre s’appuie sur le précédent — je te recommande de les suivre dans l’ordre la première fois.

graph LR
    Ch1["Ch.1
Intro & Concepts
~3h"] --> Ch2["Ch.2
Dockerfile & Images
~4h"]
    Ch2 --> Ch3["Ch.3
Docker Compose
~3h"]
    Ch3 --> Ch4["Ch.4
Production & Sécurité
~3h"]
    style Ch1 fill:#1a2332,stroke:#3b82f6,color:#f1f5f9
    style Ch2 fill:#1a2332,stroke:#22c55e,color:#f1f5f9
    style Ch3 fill:#1a2332,stroke:#f59e0b,color:#f1f5f9
    style Ch4 fill:#1a2332,stroke:#dc2626,color:#f1f5f9

---

Chapitre 1 — Introduction à Docker et aux conteneurs

📖 Accéder au cours complet — Chapitre 1

De quoi parle ce chapitre ?

Ce premier chapitre pose les fondations. Avant de taper la moindre commande Docker, tu dois comprendre pourquoi les conteneurs existent et comment ils fonctionnent sous le capot. Sans cette compréhension, tu utiliseras Docker comme une boîte noire — et tu seras perdu dès que quelque chose ne marchera pas comme prévu.

On commence par l’histoire : des chroots Unix des années 80 aux namespaces Linux, en passant par LXC et l’arrivée de Docker en 2013. Cette perspective historique n’est pas du remplissage — elle t’aide à comprendre que Docker n’a pas inventé la conteneurisation, il l’a rendue accessible. Et cette nuance est importante quand on compare Docker à ses alternatives (on y reviendra).

Ensuite, on plonge dans les mécanismes Linux qui rendent les conteneurs possibles. Les namespaces fournissent l’isolation (PID, network, mount, user…). Les cgroups contrôlent les ressources (CPU, mémoire, I/O). L’union filesystem (OverlayFS) permet le système de couches des images Docker. Comprendre ces trois piliers, c’est comprendre Docker.

Enfin, on installe Docker proprement sur différents OS et on lance nos premiers conteneurs. Tu verras la différence entre une image et un conteneur, tu comprendras le cycle de vie d’un conteneur, et tu maîtriseras les commandes de base.

Ce que tu vas apprendre

• L’architecture client-serveur de Docker (CLI → daemon → containerd → runc)
• La différence fondamentale entre conteneur et machine virtuelle
• Les namespaces Linux et leur rôle dans l’isolation
• Les cgroups et la gestion des ressources
• Installation et configuration de Docker sur Linux, macOS et Windows
• Les commandes essentielles : run, ps, logs, exec, stop, rm
• Le concept d’image et de registre (Docker Hub)

Extrait de code clé

# Ton premier conteneur — mode interactif
docker run -it ubuntu:24.04 bash

# À l'intérieur du conteneur
cat /etc/os-release    # Ubuntu 24.04 même si ton hôte est sur Fedora
hostname               # Un ID aléatoire — c'est le namespace UTS
ps aux                 # Seul bash tourne — isolation PID
ip addr                # Interface réseau isolée — namespace network
exit

# Lister les conteneurs (y compris arrêtés)
docker ps -a

# Lancer un serveur web en arrière-plan
docker run -d --name mon-nginx -p 8080:80 nginx:alpine
curl http://localhost:8080   # Ta page Nginx servie depuis un conteneur

# Voir les logs en temps réel
docker logs -f mon-nginx

# Entrer dans un conteneur qui tourne
docker exec -it mon-nginx sh

# Nettoyage
docker stop mon-nginx
docker rm mon-nginx

Points clés à retenir

Un conteneur n’est pas une mini-VM. C’est un processus Linux isolé par des namespaces et contrôlé par des cgroups. Cette distinction a des implications pratiques majeures : les conteneurs partagent le noyau de l’hôte, ce qui signifie qu’un bug kernel affecte tous les conteneurs. La sécurité d’un conteneur n’est jamais aussi forte que celle d’une VM — mais en contrepartie, tu gagnes en performance et en densité.

L’architecture Docker est client-serveur. Quand tu tapes docker run, le CLI envoie une requête au daemon Docker (dockerd), qui lui-même délègue à containerd pour la gestion du cycle de vie, puis à runc pour l’exécution effective du conteneur. Cette chaîne est importante à connaître pour le debugging.

---

Chapitre 2 — Dockerfile : construire ses images

📖 Accéder au cours complet — Chapitre 2

De quoi parle ce chapitre ?

C’est ici que les choses deviennent concrètes. Un Dockerfile, c’est la recette de fabrication de ton image Docker. C’est un fichier texte qui décrit, instruction par instruction, comment construire l’environnement d’exécution de ton application. Maîtriser l’écriture de Dockerfiles, c’est la compétence centrale de Docker.

Ce chapitre couvre d’abord les instructions de base : FROM, RUN, COPY, WORKDIR, EXPOSE, CMD, ENTRYPOINT. Chaque instruction crée une couche (layer) dans l’image finale. Comprendre ce système de couches est essentiel pour optimiser tes builds — une couche modifiée invalide le cache de toutes les couches suivantes. L’ordre de tes instructions a donc un impact direct sur la vitesse de tes builds.

On passe ensuite aux techniques avancées. Le multi-stage build est probablement la technique la plus importante à maîtriser. L’idée est simple : tu utilises un premier stage avec tous les outils de compilation (compilateur, dépendances de build), puis tu copies uniquement le binaire ou les artefacts dans une image finale minimale. Résultat : des images qui passent de 1 Go à 50 Mo.

Enfin, on aborde les bonnes pratiques qui font la différence entre un Dockerfile amateur et un Dockerfile production-ready : gestion du .dockerignore, réduction du nombre de couches, choix de l’image de base, gestion des utilisateurs non-root, scan de vulnérabilités.

Ce que tu vas apprendre

• Toutes les instructions Dockerfile et leurs subtilités
• Le système de couches (layers) et le cache de build
• Le multi-stage build pour des images optimisées
• La différence entre CMD et ENTRYPOINT (et quand utiliser quoi)
• Le .dockerignore et pourquoi il est crucial
• Les bonnes pratiques de sécurité (USER non-root, images minimales)
• Le build d’images multi-architecture (ARM64/AMD64)

Extrait de code clé — Multi-stage build

# ============================================
# Stage 1 : Build — on compile l'application
# ============================================
FROM node:20-alpine AS builder

WORKDIR /app

# Copier d'abord les fichiers de dépendances (cache optimal)
COPY package.json package-lock.json ./
RUN npm ci --only=production

# Puis le code source
COPY src/ ./src/
COPY tsconfig.json ./
RUN npm run build

# ============================================
# Stage 2 : Production — image finale minimale
# ============================================
FROM node:20-alpine AS production

# Sécurité : utilisateur non-root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

WORKDIR /app

# Copier uniquement les artefacts nécessaires
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

# Ne jamais tourner en root
USER appuser

# Healthcheck intégré
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1

EXPOSE 3000

CMD ["node", "dist/server.js"]

Exemple avancé — Application Go (image ultra-légère)

# Build
FROM golang:1.22-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server ./cmd/server

# Production — image FROM scratch = 0 dépendance
FROM scratch
COPY --from=build /app/server /server
COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
EXPOSE 8080
ENTRYPOINT ["/server"]

Résultat : une image de ~10 Mo qui contient uniquement ton binaire Go et les certificats SSL. Pas de shell, pas de package manager, pas de surface d’attaque.

Points clés à retenir

L’ordre des instructions dans un Dockerfile est crucial pour le cache. Règle d’or : les choses qui changent le moins souvent en premier, le code source en dernier. Si tu copies ton code avant d’installer les dépendances, chaque modification de code invalide le cache des dépendances et relance un npm install complet. En copiant d’abord package.json, le cache des dépendances survit aux changements de code.

Le multi-stage build n’est pas un luxe, c’est une nécessité. Une image Node.js avec les devDependencies et les outils de build peut facilement peser 1 Go+. Avec un multi-stage, tu descends à 100-200 Mo. Pour du Go ou du Rust avec une image scratch, tu es sous les 20 Mo. En production, la taille compte — elle impacte le temps de déploiement, la bande passante, et la surface d’attaque.

---

Chapitre 3 — Docker Compose : orchestrer ses services

📖 Accéder au cours complet — Chapitre 3

De quoi parle ce chapitre ?

Dans le monde réel, une application ne tourne jamais seule. Tu as une API, une base de données, un cache Redis, peut-être un reverse proxy, un worker de background jobs… Docker Compose te permet de définir et gérer toute cette stack dans un seul fichier YAML. Un docker compose up et tout démarre, connecté, configuré.

Ce chapitre commence par la syntaxe du fichier docker-compose.yml (ou compose.yaml — les deux fonctionnent). Tu vas découvrir comment définir des services, des réseaux, des volumes, des variables d’environnement. On couvre les options les plus utilisées en détail : build, image, ports, volumes, environment, depends_on, healthcheck, restart.

La partie réseau est particulièrement importante. Docker Compose crée automatiquement un réseau bridge pour ta stack, et chaque service est accessible par les autres via son nom de service comme hostname DNS. C’est magique la première fois que tu vois postgres://db:5432 fonctionner sans configuration — mais c’est crucial de comprendre le mécanisme pour débugger quand la résolution DNS échoue.

On aborde aussi les volumes et la persistance des données. Les conteneurs sont éphémères par nature — quand tu supprimes un conteneur, ses données disparaissent. Les volumes Docker résolvent ce problème en montant des répertoires persistants. On verra les différents types (named volumes, bind mounts, tmpfs) et quand utiliser chacun.

Enfin, on traite la gestion des environnements (dev vs staging vs prod) avec les fichiers .env, les overrides (docker-compose.override.yml), et les profils Compose.

Ce que tu vas apprendre

• La syntaxe complète de docker-compose.yml
• Le networking Docker : bridge, host, overlay, et DNS interne
• Les volumes : named, bind mount, tmpfs — et quand utiliser quoi
• La gestion des dépendances entre services (depends_on + healthcheck)
• Les variables d’environnement et les secrets
• Les overrides et profils pour multi-environnement
• Les commandes Compose essentielles : up, down, logs, exec, build

Extrait de code clé — Stack complète

# compose.yaml — Stack web complète
services:
  # --- Application ---
  api:
    build:
      context: .
      dockerfile: Dockerfile
      target: production
    ports:
      - "3000:3000"
    environment:
      NODE_ENV: production
      DATABASE_URL: postgres://app:secret@db:5432/myapp
      REDIS_URL: redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
      cache:
        condition: service_started
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://localhost:3000/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"

  # --- Base de données ---
  db:
    image: postgres:16-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret  # En prod, utilise des secrets Docker
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d myapp"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  # --- Cache ---
  cache:
    image: redis:7-alpine
    command: redis-server --maxmemory 128mb --maxmemory-policy allkeys-lru
    volumes:
      - redis_data:/data
    restart: unless-stopped

  # --- Reverse Proxy ---
  proxy:
    image: traefik:v3.0
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
      - certs_data:/certs
    restart: unless-stopped

volumes:
  postgres_data:
    driver: local
  redis_data:
    driver: local
  certs_data:
    driver: local

Commandes Compose essentielles

# Démarrer toute la stack (build + start)
docker compose up -d --build

# Voir les logs de tous les services (ou d'un seul)
docker compose logs -f
docker compose logs -f api

# Vérifier l'état de santé
docker compose ps

# Exécuter une commande dans un service
docker compose exec db psql -U app -d myapp

# Reconstruire un seul service
docker compose build api
docker compose up -d api   # Redémarrer uniquement l'API

# Arrêter tout (sans supprimer les volumes)
docker compose down

# Arrêter tout ET supprimer les volumes (⚠️ données perdues)
docker compose down -v

# Voir l'utilisation des ressources
docker compose top
docker stats

Points clés à retenir

Le depends_on simple ne garantit pas que le service est prêt — il garantit juste qu’il est démarré. Un conteneur PostgreSQL peut être “started” mais pas encore prêt à accepter des connexions. C’est pour ça que tu dois combiner depends_on avec condition: service_healthy et un healthcheck sur le service dépendant. Sans ça, ton API va crasher au démarrage parce que la DB n’est pas encore prête.

Les bind mounts (./src:/app/src) sont parfaits en développement pour le hot-reload. En production, tu ne veux jamais de bind mount — tout doit être dans l’image. Utilise des named volumes pour la persistance des données (DB, uploads) et rien d’autre.

---

Chapitre 4 — Docker en production

📖 Accéder au cours complet — Chapitre 4

De quoi parle ce chapitre ?

Faire tourner Docker sur ton laptop, c’est facile. Le faire tourner en production de façon fiable, sécurisée et performante, c’est un autre métier. Ce chapitre couvre tout ce qu’il faut savoir pour passer du “ça marche chez moi” au “ça tourne en prod sans me réveiller à 3h du mat’”.

On commence par la sécurité. En production, un conteneur qui tourne en root est un risque. Une image qui contient des CVE connues est un risque. Un socket Docker monté sans protection est un risque. On verra comment scanner ses images, configurer des utilisateurs non-root, utiliser des images distroless, activer les security profiles (AppArmor, seccomp), et gérer les secrets proprement.

Ensuite, la performance et l’observabilité. Tu vas apprendre à limiter les ressources (CPU, mémoire) pour éviter qu’un conteneur consomme tout, à configurer le logging (JSON-file, syslog, Fluentd), à mettre en place des healthchecks qui ont du sens, et à monitorer tes conteneurs avec Prometheus et Grafana.

Le chapitre couvre aussi les stratégies de déploiement : blue-green, rolling update, canary. Comment mettre à jour tes conteneurs sans downtime ? Comment faire un rollback rapide si la nouvelle version a un bug ? On verra les approches avec Docker Compose (pour les stacks simples) et on introduira les concepts qui mèneront naturellement vers Kubernetes pour les stacks plus complexes.

Enfin, on traite la CI/CD avec Docker : construire des images dans une pipeline, les tagger proprement (pas de :latest en prod !), les pousser vers un registre privé, et automatiser les déploiements.

Ce que tu vas apprendre

• La sécurité des conteneurs en production (principes et pratiques)
• Le scan de vulnérabilités (Trivy, Docker Scout, Snyk)
• La gestion des ressources (limites CPU/mémoire, OOM killer)
• Le logging centralisé et l’observabilité
• Les stratégies de déploiement sans downtime
• La CI/CD avec Docker (GitHub Actions, GitLab CI)
• Le tagging sémantique des images
• Les registres privés (Harbor, GitLab Registry, AWS ECR)

Extrait de code clé — Pipeline CI/CD

# .github/workflows/docker.yml
name: Build & Deploy

on:
  push:
    branches: [main]
    tags: ['v*']

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=sha,prefix=

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - name: Scan for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:sha-${{ github.sha }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'

Checklist production

# Scanner les vulnérabilités de ton image
docker scout cves mon-app:latest
trivy image mon-app:latest

# Vérifier qu'on ne tourne PAS en root
docker run --rm mon-app:latest whoami
# Doit retourner un user non-root

# Tester les limites de ressources
docker run --rm -m 256m --cpus="0.5" mon-app:latest

# Vérifier le healthcheck
docker inspect --format='{{json .State.Health}}' mon-conteneur | jq

# Pas de secrets dans l'image !
docker history mon-app:latest  # Vérifier qu'aucun secret n'apparaît

Points clés à retenir

Ne jamais utiliser :latest en production. Ce tag est mutable — il pointe vers une image différente à chaque push. Utilise des tags sémantiques (v1.2.3) ou des digests SHA (@sha256:abc...). Ton déploiement doit être reproductible et auditable.

La sécurité des conteneurs est un sujet en couches (pun intended). L’image de base doit être minimale et à jour. L’application doit tourner en non-root. Les capabilities Linux doivent être réduites au strict minimum. Le réseau doit être segmenté. Les secrets ne doivent jamais être dans l’image ou dans les variables d’environnement en clair — utilise Docker Secrets ou un vault externe.

---

Pourquoi cette formation ?

Cas d’usage concrets

Tu te demandes peut-être si Docker vaut vraiment le coup pour ton cas. Voici des scénarios concrets où Docker fait la différence :

1. Environnement de développement unifié

Tu rejoins une équipe. Le projet utilise PostgreSQL 16, Redis 7, Elasticsearch 8, et une API en Python 3.12. Sans Docker, tu passes une demi-journée à tout installer, à gérer les conflits de versions, à chercher pourquoi ça marche pas sur ton OS. Avec un docker compose up, t’es opérationnel en 2 minutes.

# Cloner le repo et c'est parti
git clone https://github.com/team/project.git
cd project
docker compose up -d
# C'est tout. Même stack que tes collègues.

2. CI/CD reproductible

Ta pipeline de tests doit tourner dans un environnement identique à la prod. Avec Docker, tu construis une image, tu la testes dans la CI, et c’est exactement cette image qui part en production. Pas de “ça marchait en CI mais pas en prod” parce que la version de Node est différente.

3. Microservices et polyglot

Tu as une API en Go, un service de ML en Python, un frontend en Node, un worker en Rust. Chaque service a ses dépendances, sa version de runtime. Docker permet de tout faire cohabiter proprement, chacun dans son conteneur, sans conflits.

4. Scaling horizontal

Ton API prend de la charge ? Tu lances 5 instances du même conteneur derrière un load balancer. C’est aussi simple que docker compose up --scale api=5.

5. Migration et modernisation

Tu as un monolithe legacy en PHP 7. Tu veux migrer progressivement vers des microservices modernes. Docker te permet de conteneuriser le monolithe tel quel, puis d’extraire les fonctionnalités une par une dans de nouveaux services, le tout orchestré par Compose.

Ce qui différencie cette formation

• Orientée pratique — Chaque concept est illustré par du code que tu peux copier-coller et tester immédiatement
• Progressive — Du docker run hello-world jusqu’à la pipeline CI/CD en production
• Opinions fortes — On ne te dit pas “il y a plusieurs approches, choisis la tienne”. On te dit ce qui marche en 2026 et pourquoi
• Contexte Suisse/Européen — Les exemples utilisent des providers comme Infomaniak et Exoscale, pas uniquement AWS
• Gratuite et à jour — Pas de paywall, pas de contenu obsolète de 2019

---

Docker vs les alternatives

Docker n’est pas le seul outil de conteneurisation. Voici un comparatif honnête avec les principales alternatives en 2026 :

Comparatif détaillé

Critère	Docker	Podman	containerd + nerdctl	LXC/LXD (Incus)
Type	Daemon + CLI	Daemonless	Runtime + CLI	Conteneurs système
Rootless	Supporté	Natif	Supporté	Supporté
Compatibilité Docker	—	~95%	CLI similaire	Différent
Docker Compose	Natif	podman-compose	nerdctl compose	Non
Kubernetes	Via containerd	CRI-O	Natif	Non
Écosystème	Énorme	Croissant	Technique	Niche
Idéal pour	Dev + Prod	RHEL/Fedora, sécurité	K8s nodes	VMs légères

Docker

Le standard de facto. L’écosystème le plus riche, la communauté la plus large, la documentation la plus fournie. Docker Desktop a eu ses controverses (changement de licence en 2021), mais Docker Engine reste open-source. En 2026, Docker est toujours le choix par défaut pour la majorité des équipes.

Points forts : Écosystème, documentation, compatibilité universelle, Docker Desktop (DX) Points faibles : Daemon root par défaut, Docker Desktop payant pour les entreprises 250+ employés

Podman

Développé par Red Hat, Podman est l’alternative la plus sérieuse. Son argument principal : pas de daemon. Chaque conteneur est un processus enfant de la commande podman, ce qui simplifie la gestion et améliore la sécurité. Il est aussi rootless par défaut.

Podman est compatible avec la plupart des commandes Docker — tu peux souvent faire alias docker=podman et ça fonctionne. Mais l’écosystème est plus petit, certains outils tiers ne supportent pas Podman, et la compatibilité Compose n’est pas parfaite.

# Podman — syntaxe quasi-identique à Docker
podman run -d --name web -p 8080:80 nginx:alpine
podman ps
podman logs web

Points forts : Daemonless, rootless natif, compatible CLI Docker, intégré à RHEL Points faibles : Écosystème plus petit, Compose imparfait, moins de tooling tiers

containerd + nerdctl

containerd est le runtime de conteneurs utilisé “sous le capot” par Docker et Kubernetes. nerdctl est un CLI compatible Docker qui parle directement à containerd, sans passer par le daemon Docker.

C’est le choix technique le plus “pur” — tu utilises directement le runtime sans couche d’abstraction. Mais c’est aussi le plus austère. Il n’y a pas d’équivalent de Docker Desktop, l’UX est moins polie, et la documentation est plus technique.

Points forts : Léger, pas de daemon Docker, utilisé nativement par K8s Points faibles : Pas de Docker Desktop, documentation plus rare, courbe d’apprentissage

Notre recommandation

Commence par Docker. C’est le standard, l’écosystème est imbattable, la documentation est exhaustive, et 95% des tutos/articles/cours utilisent Docker. Une fois que tu maîtrises Docker, passer à Podman ou nerdctl est trivial — les concepts sont les mêmes, seul l’outillage change.

Si tu es dans un environnement Red Hat / Fedora, Podman mérite un regard sérieux. Si tu gères des nœuds Kubernetes, tu utilises déjà containerd sans le savoir.

---

Ressources complémentaires

Documentation officielle

• Docker Docs — La référence absolue
• Dockerfile reference — Toutes les instructions
• Compose specification — Le format compose.yaml
• Docker Hub — Le registre d’images public

Outils recommandés

• Dive — Analyser les couches de tes images Docker
• Trivy — Scanner de vulnérabilités open-source
• Lazydocker — TUI pour gérer Docker (comme lazygit mais pour Docker)
• Hadolint — Linter pour Dockerfiles

Images de base recommandées

Usage	Image	Taille	Notes
Généraliste	alpine:3.20	~7 Mo	Minimale, musl libc
Node.js	node:20-alpine	~130 Mo	Node LTS sur Alpine
Python	python:3.12-slim	~150 Mo	Debian slim, pas Alpine (problèmes musl)
Go	scratch ou distroless	0-20 Mo	Binaire statique
Java	eclipse-temurin:21-jre-alpine	~170 Mo	JRE uniquement

---

Prêt à commencer ?

Tu as lu cette page, tu sais ce qui t’attend. Maintenant, c’est le moment de passer à la pratique.

Le parcours recommandé :

1. Chapitre 1 — Introduction — Comprendre les fondations et lancer tes premiers conteneurs
2. Chapitre 2 — Dockerfile — Construire tes propres images optimisées
3. Chapitre 3 — Docker Compose — Orchestrer des stacks multi-services
4. Chapitre 4 — Production — Sécuriser et déployer en conditions réelles

🚀 Commencer le Chapitre 1 — Introduction à Docker

---

Cette formation est maintenue activement et mise à jour régulièrement. Dernière mise à jour : mars 2026. Tu as une question ou une suggestion ? Ouvre une issue sur le dépôt GitHub du site.