Docker expliqué en 15 minutes : guide visuel pour débutants

J’ai passé deux jours entiers à débugger une API qui fonctionnait parfaitement sur mon laptop. Les logs étaient propres. Les tests passaient. Chaque endpoint répondait exactement comme la spec le prévoyait.

Puis j’ai déployé sur le serveur de staging et tout s’est effondré. Une librairie système manquante. Une version différente de Python. Une variable d’environnement qui existait sur ma machine et nulle part ailleurs. Deux jours envolés, parce que mon laptop et le serveur parlaient des dialectes légèrement différents de Linux.

Mon collègue m’a regardé tourner en rond tout un après-midi, puis m’a envoyé un message Slack d’une seule ligne : “T’as essayé Docker ?”

C’était il y a trois ans. Je n’ai plus jamais eu de problème “ça marche sur ma machine” depuis.

Le problème que Docker résout vraiment

Voici ce qui se passe sans Docker. Vous écrivez du code sur votre machine. Votre machine a un système d’exploitation spécifique, des versions précises de langages et de librairies, des fichiers de configuration dans des répertoires bien précis. Votre code dépend de tout ça, silencieusement, que vous le réalisiez ou non.

Puis quelqu’un d’autre essaie de lancer votre code. Un OS différent. Des versions de librairies différentes. Des dépendances manquantes. Ça casse d’une manière qui n’a rien à voir avec votre logique métier.

Docker résout ce problème en empaquetant votre application avec tout ce dont elle a besoin pour tourner — la couche OS, les librairies, le runtime, la config, tout — dans une unité portable unique appelée conteneur. Ce conteneur s’exécute de la même façon partout. Votre laptop, celui de votre collègue, un serveur de CI, une VM dans le cloud. Le même comportement, à chaque fois.

Ce n’est pas de la magie. C’est juste du packaging cohérent. Mais le packaging cohérent s’avère résoudre un nombre énorme de problèmes du monde réel.

Conteneurs vs machines virtuelles : appartements vs maisons

Si vous avez entendu parler des machines virtuelles, vous vous demandez peut-être en quoi les conteneurs sont différents. L’analogie que j’utilise, c’est les appartements contre les maisons.

Une machine virtuelle, c’est comme une maison. Elle a ses propres fondations, sa propre plomberie, son propre système électrique. C’est totalement autonome et totalement isolé, mais c’est lourd. Il faut beaucoup de terrain (RAM, CPU, disque) pour en construire une, et démarrer une nouvelle maison prend du temps.

Un conteneur, c’est comme un appartement. Vous partagez les fondations et la plomberie de l’immeuble (le noyau de l’OS hôte), mais votre appartement reste le vôtre. Vous avez vos propres meubles, votre propre agencement, vos propres affaires. Vous emménagez vite, vous déménagez vite, et l’immeuble peut accueillir bien plus d’appartements que de maisons.

En pratique : une VM peut mettre une minute à démarrer et consommer un gigaoctet de RAM avant même que votre app ne se lance. Un conteneur démarre en secondes et n’utilise que la mémoire dont votre app a réellement besoin.

Les deux ont leur place. Mais pour la plupart des workflows de développement et de déploiement, les conteneurs vous donnent 90 % de l’isolation pour 10 % du coût.

Images vs conteneurs : la recette et le gâteau

Ça piège tous les débutants, alors soyons clairs.

Une image Docker est un modèle. C’est un template en lecture seule qui décrit tout ce qu’il faut pour exécuter votre application — l’OS de base, les paquets installés, votre code, la commande de démarrage. Voyez ça comme une recette.

Un conteneur Docker est une instance en cours d’exécution de cette image. C’est le vrai gâteau que vous avez préparé à partir de la recette. Vous pouvez faire plusieurs gâteaux à partir d’une seule recette. Chaque gâteau est indépendant — vous pouvez en manger un, glacer l’autre différemment, jeter le troisième. La recette reste la même.

Quand vous lancez docker run, vous prenez une image et vous créez un conteneur à partir d’elle. Quand ce conteneur s’arrête, l’image est toujours là, intacte, prête à en créer un autre.

Vous pouvez aussi partager des images. Docker Hub, c’est comme un livre de recettes public — des millions d’images pré-construites pour des bases de données, des serveurs web, des langages de programmation, et plus encore. Au lieu d’écrire une recette en partant de zéro, vous en prenez une déjà testée et vous construisez dessus.

Votre premier Dockerfile : un exemple concret

Un Dockerfile, c’est simplement un fichier texte qui décrit comment construire une image. En voici un vrai pour une application Node.js simple :

# Partir de l'image officielle Node.js 20
FROM node:20-alpine

# Définir le répertoire de travail dans le conteneur
WORKDIR /app

# Copier d'abord les fichiers package (optimisation du cache de couches)
COPY package.json package-lock.json ./

# Installer les dépendances
RUN npm ci

# Copier le reste du code de l'application
COPY . .

# Indiquer à Docker le port que votre app écoute
EXPOSE 3000

# La commande à exécuter au démarrage du conteneur
CMD ["node", "server.js"]

Chaque ligne est une instruction. FROM choisit votre point de départ. COPY importe des fichiers. RUN exécute des commandes pendant le build. CMD dit ce qui se passe quand le conteneur se lance.

Pour construire cette image et la lancer :

# Construire l'image et la taguer "my-app"
docker build -t my-app .

# Lancer un conteneur à partir de cette image
docker run -p 3000:3000 my-app

Le -p 3000:3000 fait correspondre le port 3000 de votre machine au port 3000 à l’intérieur du conteneur. Ouvrez http://localhost:3000 et voilà votre app, qui tourne dans un conteneur.

Je me souviens de la première fois que j’ai fait ça. Ça me semblait excessif pour un simple serveur Node. Puis j’ai partagé cette même image avec mon équipe et tout le monde tournait avec exactement le même setup en moins d’une minute. Pas de README avec douze étapes d’installation. Pas de “assure-toi d’avoir Node 20, pas 18.” Juste docker run.

Docker Compose : quand un seul conteneur ne suffit pas

La plupart des vraies applications ne sont pas un seul conteneur. Vous avez une webapp, une base de données, peut-être un cache, peut-être une file de messages. Docker Compose vous permet de définir tout ça dans un seul fichier et de tout démarrer avec une seule commande.

Voici un docker-compose.yml pour une webapp avec une base de données PostgreSQL :

version: "3.8"

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/myapp
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=myapp
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Puis vous lancez :

docker compose up

Les deux conteneurs démarrent, ils peuvent communiquer entre eux par nom de service (db résout vers l’IP du conteneur de base de données), et les données de la base persistent dans un volume pour survivre aux redémarrages.

Avant Docker Compose, mettre en place un environnement de développement local avec une base de données signifiait installer PostgreSQL sur votre machine, créer le bon utilisateur et la bonne base, espérer que la version correspondait à la production. Maintenant, c’est un fichier et une commande.

Quand NE PAS utiliser Docker

Je suis clairement un fan. Mais Docker n’est pas la réponse à tout.

Scripts simples et outillage local. Si vous écrivez un script Python que vous seul utiliserez, le conteneuriser ajoute de la complexité sans grand bénéfice. Utilisez juste un environnement virtuel.

Applications graphiques. Docker est conçu pour les charges serveur et les outils en ligne de commande. Vous pouvez techniquement lancer des apps graphiques dans des conteneurs, mais c’est pénible et rarement rentable.

Quand vous ne comprenez pas ce qu’il y a dedans. J’ai vu des équipes tirer des images aléatoires de Docker Hub et les exécuter en production sans lire le Dockerfile. C’est comme manger un plat qu’un inconnu vous tend sur un parking. Au minimum, utilisez des images officielles et vérifiez ce qu’elles contiennent.

Charges bare-metal critiques en performance. Le surcoût est minime, mais il n’est pas nul. Pour la plupart des applications, vous ne le remarquerez jamais. Pour du trading haute fréquence ou du traitement audio en temps réel, peut-être.

Docker brille quand vous avez besoin de reproductibilité, de portabilité et d’isolation. Pour tout le reste, évaluez honnêtement. Si Docker vous semble résoudre un problème que vous n’avez pas, c’est probablement le cas.

La pratique quotidienne de 15 minutes

Apprendre Docker en lisant, c’est comme apprendre à nager en regardant YouTube. Il faut mettre les mains dans l’eau.

Voici ce que je ferais pendant les deux prochaines semaines, quinze minutes par jour :

Jours 1-3. Tirez des images et lancez des conteneurs. docker run -it ubuntu bash vous donne un shell Linux jetable. Explorez. Installez des trucs. Quittez. C’est parti. C’est ça, la beauté du truc.

Jours 4-6. Écrivez des Dockerfiles pour des projets que vous avez déjà. Même simples. L’acte de décider ce dont votre app a besoin pour tourner vous apprend plus que n’importe quel tutoriel.

Jours 7-9. Utilisez Docker Compose pour mettre en place un environnement multi-conteneurs. Une webapp avec une base de données, c’est le projet classique pour commencer.

Jours 10-14. Cassez des choses exprès. Supprimez des volumes, changez les images de base, modifiez les mappings de ports. Débugger Docker vous apprend Docker plus vite que de tout réussir du premier coup.

Si vous voulez une approche structurée pour construire ce genre d’habitude d’apprentissage quotidienne, j’ai écrit sur ce processus dans comment construire une habitude d’apprentissage de 15 minutes qui fonctionne vraiment.

Docker est aussi votre porte d’entrée dans l’écosystème cloud au sens large — orchestration avec Kubernetes, pipelines CI/CD, infrastructure as code. Si ce chemin vous intéresse, voici par où commencer pour apprendre le cloud computing en partant de zéro.

FAQ

Faut-il connaître Linux pour utiliser Docker ?

Ça aide, mais vous n’avez pas besoin d’être un administrateur Linux. La plupart du travail avec Docker implique des commandes basiques — copier des fichiers, installer des paquets, définir des variables d’environnement. Si vous savez naviguer dans un terminal, vous pouvez utiliser Docker. Cela dit, comprendre comment les processus, les systèmes de fichiers et le réseau fonctionnent sous Linux facilitera grandement le débogage sur le long terme.

Docker est-il gratuit ?

Docker Engine est open source et gratuit. Docker Desktop (l’application graphique pour Mac et Windows) est gratuit pour un usage personnel, éducatif et pour les petites entreprises. Les grandes entreprises ont besoin d’un abonnement payant pour Docker Desktop, mais vous pouvez toujours utiliser les outils en ligne de commande directement sans lui.

Quelle est la différence entre Docker et Kubernetes ?

Docker fait tourner des conteneurs. Kubernetes les orchestre à grande échelle. Si Docker c’est comme conduire une voiture, Kubernetes c’est comme gérer une flotte de camions de livraison — décider quel camion va où, remplacer ceux qui tombent en panne, monter en charge pendant les pics. Vous n’avez pas besoin de Kubernetes tant que vous ne faites pas tourner beaucoup de conteneurs sur plusieurs serveurs. Commencez par Docker. Kubernetes viendra après.

Est-ce que Docker fonctionne sur Windows ?

Oui. Docker Desktop pour Windows utilise WSL 2 (Windows Subsystem for Linux) sous le capot, et ça marche bien. Je l’ai utilisé sur des machines Windows pour le développement et l’apprentissage sans problèmes majeurs. Assurez-vous juste que WSL 2 est activé et que vous avez assez de RAM — Docker peut être gourmand.

Envie de construire de vraies compétences cloud en partant de zéro, un concept à la fois ? Découvrez SkillRealm Learn →