Apprendre Docker sans se noyer : la séquence minimale pour développeur web

Tu as installé Docker Desktop il y a six mois. Tu as lancé deux ou trois docker run pour tester. Tu as vu passer des commandes que tu n'as pas comprises. Et depuis, à chaque fois qu'un README mentionne Docker, tu sens un petit serrement, et tu cherches une alternative pour ne pas avoir à t'y mettre.

Toi, tu sais que Docker est partout. Sur les offres d'emploi, dans les pipelines CI, dans les projets open source que tu veux contribuer, dans les déploiements en prod. Tu sais que c'est un trou dans ta boîte à outils. Mais chaque fois que tu ouvres la documentation officielle ou une vidéo "Docker complete tutorial", tu te retrouves devant huit heures de contenu qui couvre Kubernetes, Swarm, les networks overlay, le multi-stage build, et tu refermes l'onglet.

Le problème, ce n'est pas Docker. C'est la manière dont on l'enseigne. La plupart des ressources s'adressent à des futurs ingénieurs DevOps. Toi, tu fais du web. Tu n'as pas besoin d'apprendre Docker en entier. Tu as besoin d'un sous-ensemble précis, celui qui te rend autonome sur ton boulot quotidien.

Cet article te donne cette séquence minimale. Six concepts, dans le bon ordre. Tu peux les avoir en main en deux semaines à temps partiel, sans regarder une seule vidéo de huit heures.

Le problème : tu essaies d'apprendre Docker comme un sysadmin

Les ressources Docker grand public partent du principe que tu vas devenir l'ops d'une équipe. Elles te font passer par l'histoire des conteneurs, la différence avec les VMs, les détails du noyau Linux, les cgroups, les namespaces. C'est intéressant, mais c'est complètement inutile pour un développeur web qui veut juste pouvoir bosser sur un projet dockerisé.

Tu n'as pas besoin de savoir comment Docker isole les processus. Tu as besoin de savoir lancer un projet existant, modifier un Dockerfile, déboguer un conteneur qui plante, et faire tourner ta base de données locale dans un container.

Le deuxième piège, c'est de vouloir tout apprendre avant d'utiliser. Tu lis la doc, tu prends des notes, tu mémorises les options de docker run. Tu n'utilises jamais. Trois semaines plus tard, tu as tout oublié.

Docker s'apprend en l'utilisant sur un vrai projet. Tu lances, ça plante, tu cherches, tu comprends, tu retiens. Une heure de pratique vaut huit heures de tutoriel.

Le principe : six briques, dans cet ordre exact

Voici les six concepts à maîtriser, dans l'ordre où ils s'apprennent le mieux. Ne saute pas une étape, ne change pas l'ordre. Chaque brique repose sur la précédente.

1. Image et conteneur (les deux mots qui changent tout)

Une image est une recette figée. Un conteneur est cette recette en train de tourner. Tu peux lancer dix conteneurs depuis la même image. C'est exactement la relation entre une classe et un objet en programmation orientée objet.

Tu vois passer ces deux mots à chaque commande Docker. Si tu les confonds, rien ne fait sens. Si tu les distingues, tout devient logique.

2. Les cinq commandes vitales

Tu n'as pas besoin de connaître les soixante commandes Docker. Tu as besoin de cinq.

docker ps              # liste les conteneurs en cours
docker ps -a           # liste tous les conteneurs, meme arretes
docker logs <nom>      # affiche les logs d'un conteneur
docker exec -it <nom> sh   # ouvre un shell dans un conteneur
docker stop <nom>      # arrete un conteneur

Avec ces cinq commandes, tu peux survivre à 90% des situations quotidiennes. Le reste s'apprend en cherchant au moment où tu en as besoin.

3. Lire et écrire un Dockerfile minimal

Le Dockerfile est la recette de l'image. Sept ou huit instructions suffisent pour 95% des cas web. Voici l'exemple pour une app Node :

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

Six instructions. FROM définit l'image de base. WORKDIR fixe le dossier de travail. COPY recopie tes fichiers. RUN exécute une commande au moment du build. EXPOSE documente le port utilisé. CMD définit la commande qui se lance au démarrage. C'est tout.

4. Les volumes (sinon tes données disparaissent)

Un conteneur est éphémère. Quand tu le supprimes, tout ce qu'il contenait part avec lui. Pour garder tes données (fichiers uploadés, base de données, cache), tu utilises un volume, qui est un espace de stockage géré par Docker.

docker run -v ./data:/app/data mon-app

Cette ligne dit "monte mon dossier local ./data dans le conteneur à l'emplacement /app/data". Tes fichiers survivent à la suppression du conteneur. C'est suffisant pour ton usage quotidien.

5. Docker Compose (le vrai outil de tous les jours)

Si tu retiens une seule chose après l'image et le conteneur, retiens Docker Compose. C'est l'outil que tu vas utiliser 80% du temps. Il te permet de décrire plusieurs services dans un seul fichier, et de tout lancer avec une commande.

services:
  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - dbdata:/var/lib/postgresql/data

volumes:
  dbdata:

Ce fichier décrit une app web et une base PostgreSQL. La commande docker compose up lance les deux. docker compose down les arrête. docker compose logs -f app affiche les logs.

Quasiment tous les projets dockerisés que tu vas rencontrer en réalité utilisent Compose. Apprendre Compose te débloque sur 90% des situations.

6. Le débogage de base

Trois réflexes te débloquent sur 95% des problèmes :

• Le conteneur ne démarre pas : tu lis docker logs <nom>. Dans 80% des cas, l'erreur est explicite.
• Tu veux comprendre ce qui se passe dans un conteneur en vie : docker exec -it <nom> sh t'ouvre un shell à l'intérieur.
• Tu veux voir ce qui tourne et ce qui ne tourne pas : docker ps -a liste tout.

Avec ces trois réflexes, tu cesses de ramer dès qu'un conteneur ne se comporte pas comme prévu.

Le plan en deux semaines

Voici la trajectoire concrète pour intégrer ces six briques, en supposant que tu y consacres une heure par jour.

Jours 1 à 3 : tu installes Docker Desktop, tu lances docker run hello-world, puis docker run -p 8080:80 nginx et tu ouvres ton navigateur sur localhost:8080. Tu joues avec les cinq commandes vitales. L'objectif : que les mots image et conteneur deviennent naturels.

Jours 4 à 6 : tu prends un de tes projets perso (Node, Python, PHP, peu importe) et tu écris un Dockerfile pour le faire tourner dedans. Tu vas galérer, tu vas chercher, tu vas comprendre. C'est exactement le but. À la fin, tu as une image qui fonctionne et tu sais pourquoi.

Jours 7 à 10 : tu ajoutes une base de données à ton projet (PostgreSQL, MySQL, MongoDB), et tu écris un docker-compose.yml qui lance app + base. Tu apprends les volumes pour garder tes données entre les redémarrages.

Jours 11 à 14 : tu utilises Docker pour un usage réel. Tu remplaces ta base locale par une base en container, tu fais tourner un Redis ou un MailHog pour le dev, tu clones un projet open source qui utilise Docker et tu le lances. À la fin de ces deux semaines, Docker fait partie de ta routine.

Pièges classiques à éviter

Vouloir apprendre Kubernetes en même temps

Kubernetes est un outil d'orchestration qui gère des conteneurs Docker à grande échelle. Ce n'est pas le niveau suivant après Docker, c'est un autre métier. Tu peux passer dix ans à faire du web sans toucher Kubernetes une seule fois.

Concentre-toi sur Docker et Docker Compose. Tu verras Kubernetes le jour où tu en auras réellement besoin, ce qui arrive beaucoup plus tard que tu ne le crois.

Construire des images de 2 Go

Tu pars d'une image Ubuntu complète, tu installes Node, Python, Java "au cas où". Ton image fait 2 Go. Chaque rebuild prend cinq minutes. Tu te lasses très vite.

Tu utilises systématiquement les images de base les plus légères : node:20-alpine, python:3.12-slim, php:8.3-fpm-alpine. Tu passes de 2 Go à 200 Mo sans rien sacrifier.

Mettre COPY . . en début de Dockerfile

Tu copies tout ton projet avant d'installer les dépendances. Résultat : chaque modification d'un fichier source invalide le cache, et tes builds prennent une éternité.

Tu copies d'abord package.json (ou requirements.txt, composer.json), tu installes les dépendances, puis tu copies le reste. Le cache des dépendances est conservé tant que tu ne touches pas au fichier de dépendances. Builds dix fois plus rapides.

Oublier le .dockerignore

Tu construis ton image et elle embarque ton dossier node_modules, ton .git, tes fichiers .env, tes logs. Image lourde, build lent, risque de sécurité.

Un .dockerignore minimal couvre déjà 80% des problèmes : node_modules, .git, .env*, *.log, dist/ selon le projet.

Stocker des secrets en clair dans le Dockerfile

Tu mets ton mot de passe de base ou ta clé API directement dans le Dockerfile avec un ENV API_KEY=.... Ce secret se retrouve dans l'image, et tous ceux qui ont accès à l'image l'ont.

Les secrets passent par des variables d'environnement injectées au runtime, ou par un système de gestion de secrets si tu es en prod. Jamais en dur dans le Dockerfile.

Croire que Docker garantit la sécurité

Docker isole les processus, il ne sécurise pas magiquement ton appli. Un conteneur qui tourne en root reste un conteneur qui tourne en root. Une appli web vulnérable dans un container est toujours vulnérable.

Docker est un outil de packaging et d'exécution, pas un bouclier. La sécurité reste ton boulot. Le réflexe à prendre : créer un utilisateur non-root dans ton Dockerfile et l'utiliser pour le runtime. La logique est la même que celle du principe Fail Fast appliqué à la conf : par défaut, tu refuses, tu n'autorises que ce qui est strictement nécessaire.

Ce que tu peux ignorer (pour l'instant)

Pour qu'un plan d'apprentissage tienne, il faut aussi savoir ce qu'on n'apprend pas. Voici la liste des concepts qui peuvent attendre, même s'ils sont fascinants.

Multi-stage builds : utiles pour produire des images de production très légères, à apprendre quand tu déploies une vraie appli. Pas avant.

Docker networks personnalisés : Compose gère le réseau pour toi dans 99% des cas. Tu verras les networks custom le jour où tu auras un besoin précis.

Registres privés : si tu n'as pas d'image à publier, tu n'as pas besoin de comprendre Docker Hub privé, GHCR, ECR, GCR. Docker Hub public te suffit pour pull les images officielles.

Docker Swarm : pratiquement disparu en 2026. Tu peux l'ignorer totalement.

Kubernetes : on l'a dit, c'est un autre univers. Tu peux ne jamais l'apprendre et avoir une excellente carrière de développeur web.

Pour aller plus loin

Si tu veux comprendre pourquoi Docker s'est imposé et ce qu'il change dans le quotidien d'un dev, l'article Pourquoi Docker est devenu incontournable couvre le contexte général. Une fois Docker en main, l'étape logique est de l'intégrer dans une pipeline d'intégration continue, sujet que tu peux explorer dans les ressources sur GitHub Actions.

Côté formation, la formation Docker pour développeurs web est calibrée exactement sur cette séquence : six briques, exercices pratiques, sans détour par les sujets DevOps avancés. La formation CI/CD avec GitHub Actions prend la suite logique en montrant comment utiliser tes images Docker dans une pipeline. Pour la ligne de commande, qui revient à chaque manipulation Docker, la formation Linux et ligne de commande pour développeurs donne les bases qui rendent tout plus fluide.

Questions fréquentes