Author : Romain RICHER

« Pourtant, ça marche sur ma machine ! » Cette phrase, tout développeur l’a prononcée un jour, dépité, en découvrant que son application refuse de fonctionner sur l’ordinateur d’un collègue ou sur le serveur de production. C’est précisément ce problème que Docker est venu résoudre. Devenu en quelques années un incontournable du développement moderne, Docker repose sur une idée simple mais puissante : le « conteneur ». Cet article vous explique ce qu’est Docker, le problème qu’il résout, et comment il fonctionne — sans jargon inutile.

Les informations reflètent la situation en 2026. Les concepts présentés (conteneur, image, Dockerfile) sont stables ; seules les versions et certains détails techniques évoluent.

Le problème que Docker résout

Un logiciel ne fonctionne jamais tout seul : il a besoin d’un environnement précis — une certaine version d’un langage, des bibliothèques, des outils système, des réglages de configuration. Or cet environnement diffère d’un ordinateur à l’autre. Résultat : une application qui tourne parfaitement sur le poste du développeur peut planter ailleurs, simplement parce qu’une version diffère ou qu’une bibliothèque manque. C’est le fameux « ça marche sur ma machine », source de frustrations sans fin.

Traditionnellement, il fallait réinstaller et reconfigurer manuellement tout cet environnement sur chaque machine cible, une opération fastidieuse et source d’erreurs. Docker propose une autre approche : empaqueter l’application avec tout son environnement dans une unité standardisée qui fonctionnera à l’identique partout.

L’analogie du conteneur maritime

Le nom « Docker » et son logo (une baleine portant des conteneurs) ne sont pas un hasard. L’idée s’inspire directement des conteneurs de transport maritime. Avant leur invention, charger un bateau était un casse-tête : chaque marchandise avait sa forme, sa taille, ses contraintes. Le conteneur standardisé a tout changé : peu importe ce qu’il y a à l’intérieur (des voitures, des fruits, des meubles), la boîte a toujours les mêmes dimensions et peut être manipulée par n’importe quel port, grue ou camion dans le monde.

Docker applique ce principe au logiciel. Un conteneur informatique emballe une application et tout ce dont elle a besoin dans une « boîte » standardisée. Peu importe ce qu’il y a dedans, cette boîte se manipule et s’exécute de la même façon partout : sur le portable du développeur, sur un serveur de test, ou en production dans le cloud. Fini les mauvaises surprises liées à l’environnement.

Qu’est-ce que Docker, concrètement ?

Docker est une plateforme de conteneurisation : un outil qui permet d’empaqueter un logiciel avec ses dépendances dans un conteneur, puis d’exécuter ce conteneur sur n’importe quelle machine équipée de Docker. L’application dispose, à l’intérieur du conteneur, de tout ce qu’il lui faut pour fonctionner — et elle s’exécute de manière isolée, sans interférer avec le reste du système ni avec les autres conteneurs.

Cette combinaison — empaquetage standardisé + isolation + portabilité — est ce qui a rendu Docker si populaire. On peut ainsi faire tourner plusieurs applications aux besoins différents sur un même serveur, chacune dans son conteneur, sans qu’elles se marchent sur les pieds.

Conteneur ou machine virtuelle ?

On compare souvent Docker aux machines virtuelles (VM), car les deux servent à isoler des environnements. Mais leur fonctionnement diffère profondément, et c’est un point clé pour comprendre l’intérêt de Docker.

Une machine virtuelle simule un ordinateur complet : elle embarque son propre système d’exploitation entier, par-dessus celui de la machine hôte. C’est puissant, mais lourd : chaque VM pèse plusieurs gigaoctets et met souvent plusieurs minutes à démarrer.

Un conteneur Docker, lui, ne réembarque pas tout un système d’exploitation : il partage le noyau de la machine hôte, et n’emporte que ce qui est propre à l’application. Résultat : il est bien plus léger (quelques mégaoctets à quelques centaines) et démarre en quelques secondes. Là où un serveur ne ferait tourner que quelques VM, il peut héberger des dizaines de conteneurs. Cette légèreté est la grande force de Docker. À noter en contrepartie : l’isolation d’un conteneur est un peu moins étanche que celle d’une VM, puisque le noyau est partagé — d’où l’importance des bonnes pratiques de sécurité.

Les concepts essentiels : image, conteneur, Dockerfile

Trois notions reviennent sans cesse quand on parle de Docker. Une bonne analogie est celle de la cuisine :

• L’image est la recette : un modèle figé (en lecture seule) qui contient tout le nécessaire pour faire tourner l’application — le code, les bibliothèques, les dépendances. Une image est immuable : pour la modifier, on en construit une nouvelle version.
• Le conteneur est le plat cuisiné à partir de la recette : une instance de l’image en cours d’exécution. À partir d’une même image, on peut lancer autant de conteneurs identiques qu’on veut. Le conteneur, lui, est éphémère : on le lance, l’arrête, le supprime facilement.
• Le Dockerfile est la liste des instructions pour préparer la recette : un simple fichier texte qui décrit, étape par étape, comment construire l’image.

Un Dockerfile ressemble à ceci (exemple simple pour une application Python) :

FROM python:3.12-slim        # on part d'une image de base
WORKDIR /app                 # dossier de travail dans le conteneur
COPY . .                     # on copie les fichiers de l'application
RUN pip install flask        # on installe les dépendances
CMD ["python", "app.py"]     # commande lancée au démarrage

Chaque ligne ajoute une « couche » à l’image. À partir de ce fichier, Docker construit une image réutilisable, qui produira toujours le même environnement.

Où sont stockées les images ? Le registre

Les images Docker se partagent via des registres (registries). Le plus connu est Docker Hub, une bibliothèque publique où l’on trouve des milliers d’images officielles prêtes à l’emploi : un serveur web, une base de données, un langage de programmation… Plutôt que de tout construire soi-même, on part souvent d’une image existante qu’on personnalise. Les entreprises utilisent aussi des registres privés pour héberger leurs propres images de façon sécurisée.

Quelques commandes pour rendre concret

Sans entrer dans un tutoriel complet, voici les commandes emblématiques qui rythment l’usage quotidien de Docker :

docker build -t mon-app .    # construire une image à partir d'un Dockerfile
docker run -d mon-app        # lancer un conteneur à partir de l'image
docker ps                    # lister les conteneurs en cours d'exécution
docker images                # lister les images disponibles localement
docker stop mon-conteneur    # arrêter un conteneur
docker rm mon-conteneur      # supprimer un conteneur

On construit une image (build), on la lance (run), on surveille (ps), on arrête et on nettoie. Ce cycle simple suffit pour démarrer.

À quoi ça sert au quotidien ?

Docker s’est imposé dans de nombreux contextes :

• Fiabiliser les environnements : garantir que l’application se comporte de façon identique du poste du développeur jusqu’à la production.
• Les architectures « microservices » : découper une grosse application en petits services indépendants, chacun dans son conteneur.
• L’intégration continue : dans les chaînes de tests et de déploiement automatisés, où l’on a besoin d’environnements reproductibles à la demande.
• Tester rapidement un outil : lancer une base de données ou un logiciel en une commande, sans l’installer durablement sur sa machine.

Docker est aussi la porte d’entrée vers des technologies plus avancées d’« orchestration » (comme Kubernetes), qui gèrent des centaines de conteneurs répartis sur de nombreuses machines. Mais tout commence par la maîtrise du conteneur.

En résumé

• Docker résout le problème du « ça marche sur ma machine » en empaquetant l’application avec son environnement.
• Un conteneur est une boîte standardisée, légère et isolée, qui s’exécute à l’identique partout.
• Contrairement à une machine virtuelle, un conteneur partage le noyau de l’hôte : il est bien plus léger et démarre en secondes.
• Trois notions clés : l’image (la recette), le conteneur (le plat), le Dockerfile (les instructions).
• Les images se partagent via des registres comme Docker Hub, et quelques commandes suffisent pour démarrer.

Docker a transformé la façon de construire et de déployer les logiciels, en apportant une portabilité et une fiabilité qui manquaient cruellement auparavant. Que vous soyez développeur débutant ou simplement curieux de comprendre un mot que vous entendez partout, retenez l’essentiel : Docker, c’est l’art de mettre une application dans une boîte standardisée qui fonctionne partout de la même façon. Un principe simple, aux conséquences considérables.

Une fois compris ce qu’est Git et le versionning, reste à le manier au quotidien. Bonne nouvelle : quelques commandes suffisent pour 90 % du travail courant. Ce guide passe en revue les commandes Git essentielles, dans l’ordre logique d’un projet — de sa création à la collaboration —, avec des exemples concrets.

Configurer Git (une seule fois)

Avant tout, on indique son identité, qui apparaîtra dans l’historique des modifications :

git config --global user.name "Votre Nom"
git config --global user.email "vous@exemple.com"

L’option --global applique ce réglage à tous vos projets. À faire une fois sur une nouvelle machine.

Démarrer un projet : init et clone

Deux façons de commencer. Soit on crée un dépôt dans un dossier existant :

git init

Soit on récupère un projet existant depuis un serveur distant (GitHub, GitLab…) :

git clone https://github.com/utilisateur/projet.git

git clone télécharge tout le projet et son historique complet, et configure automatiquement le lien vers le dépôt distant.

Le cycle de base : status, add, commit

C’est le cœur du travail quotidien, un cycle qu’on répète sans cesse. D’abord, voir où on en est :

git status

Cette commande affiche les fichiers modifiés, ajoutés ou supprimés. C’est le réflexe à avoir en permanence. Ensuite, on sélectionne les modifications à enregistrer avec git add :

git add fichier.txt      # un fichier précis
git add .                # tous les fichiers modifiés

Cette étape place les changements dans la « zone de préparation » (staging). Enfin, on enregistre ces changements dans l’historique avec un message descriptif :

git commit -m "Ajout de la page de contact"

Le message doit être clair et concis : il explique quoi et pourquoi. Un bon historique de commits est précieux pour comprendre l’évolution d’un projet.

Consulter l’historique : log et diff

Pour parcourir les commits passés :

git log            # historique complet
git log --oneline  # version condensée, un commit par ligne

Et pour voir précisément ce qui a changé dans les fichiers, avant de les valider :

git diff

git diff montre les différences ligne par ligne entre votre travail en cours et le dernier commit — indispensable pour relire ses modifications avant de les enregistrer.

Travailler avec un dépôt distant : push et pull

Ces deux commandes synchronisent votre travail avec le serveur (GitHub, GitLab…). Envoyer vos commits locaux vers le distant :

git push

Récupérer les modifications des autres depuis le distant :

git pull

Le réflexe collaboratif : faire un git pull avant de commencer à travailler (pour partir de la dernière version), et un git push après avoir validé ses commits (pour partager son travail).

Les branches : branch, checkout, merge

Les branches permettent de développer en parallèle sans toucher à la version principale. Créer une branche et s’y déplacer :

git branch ma-fonctionnalite     # créer la branche
git checkout ma-fonctionnalite   # s'y déplacer

Les versions récentes de Git proposent un raccourci qui fait les deux d’un coup :

git switch -c ma-fonctionnalite

Une fois le travail terminé sur la branche, on revient sur la principale et on fusionne :

git checkout main
git merge ma-fonctionnalite

Git réunit alors les modifications de la branche dans la principale. Si deux personnes ont modifié les mêmes lignes, Git signale un conflit à résoudre manuellement — un cas courant en équipe, qu’il ne faut pas craindre.

Corriger : annuler des modifications

Git offre plusieurs filets de sécurité. Annuler les modifications non encore validées d’un fichier (revenir au dernier commit) :

git checkout -- fichier.txt

Retirer un fichier de la zone de préparation (annuler un git add) :

git reset fichier.txt

Ces commandes sont à manier avec attention : elles peuvent supprimer du travail non enregistré. En cas de doute, un git status et un git diff préalables permettent de vérifier ce qu’on s’apprête à annuler.

Récapitulatif des commandes

En résumé

Le quotidien avec Git tient dans un cycle simple : git status pour voir, git add pour préparer, git commit pour enregistrer, puis git push et git pull pour se synchroniser avec l’équipe. Les branches (branch, checkout, merge) permettent de travailler en parallèle. Ces quelques commandes couvrent l’essentiel du travail ; les maîtriser, c’est gagner en autonomie sur tout projet de code. Pour comprendre les concepts derrière ces commandes, revenez à notre article Git et GitLab expliqués.

Dès qu’on travaille sur du code — seul ou en équipe — une question se pose vite : comment suivre les modifications, revenir en arrière en cas d’erreur, et travailler à plusieurs sans s’écraser mutuellement ? La réponse tient en un mot : le versionning (ou gestion de versions). Et l’outil qui domine le domaine s’appelle Git. Ce guide explique ce qu’est le versionning, comment Git fonctionne dans les grandes lignes, et ce que viennent faire GitLab et GitHub par-dessus.

Qu’est-ce que le versionning ?

Le versionning consiste à enregistrer l’historique des modifications d’un ensemble de fichiers au fil du temps. Chaque fois qu’on sauvegarde une étape, on crée une « version » à laquelle on pourra toujours revenir. Concrètement, cela apporte trois choses essentielles :

• Un historique complet : qui a changé quoi, quand, et pourquoi.
• La possibilité de revenir en arrière : annuler une modification qui a cassé quelque chose, retrouver une version qui fonctionnait.
• Le travail collaboratif : plusieurs personnes modifient les mêmes fichiers, et l’outil fusionne les changements intelligemment.

Sans versionning, on se retrouve vite avec des fichiers nommés projet_final.zip, projet_final_v2.zip, projet_vraiment_final.zip — une méthode fragile et ingérable à plusieurs. Git résout exactement ce problème.

Git, un système distribué

Créé en 2005 par Linus Torvalds (le créateur de Linux), Git est aujourd’hui le standard du versionning. Sa particularité est d’être distribué : chaque développeur possède sur sa machine une copie complète du projet et de tout son historique, pas seulement la dernière version.

Cela a des conséquences pratiques majeures : on peut travailler hors ligne, consulter tout l’historique sans connexion, et le projet n’est pas perdu si un serveur central tombe (chaque copie est une sauvegarde complète). C’est ce qui distingue Git des anciens systèmes centralisés comme SVN.

Les notions clés de Git

Quelques concepts reviennent sans cesse. En comprendre le principe suffit pour saisir la logique de Git :

Le commit est le cœur du système : à chaque étape importante, on « fige » l’état du projet avec un message décrivant le changement. L’ensemble des commits forme l’historique, qu’on peut parcourir, comparer ou restaurer.

Les branches : travailler en parallèle

La force de Git tient beaucoup à ses branches. Une branche permet de développer une nouvelle fonctionnalité (ou corriger un bug) à l’écart de la version principale, sans risquer de la casser. Une fois le travail terminé et testé, on fusionne la branche dans la principale.

Ce mécanisme rend le travail à plusieurs fluide : chacun développe sur sa branche, et les contributions sont réunies proprement. C’est aussi ce qui permet de mener plusieurs chantiers en parallèle sur un même projet.

Git, GitHub, GitLab : quelle différence ?

C’est la confusion la plus fréquente. Distinguons clairement :

• Git est le logiciel de versionning, qui tourne sur votre machine. Il fonctionne parfaitement tout seul, en local.
• GitHub et GitLab sont des plateformes en ligne qui hébergent des dépôts Git et ajoutent des services autour : interface web, gestion des droits, suivi des tâches, revue de code, automatisation…

Autrement dit, Git est le moteur ; GitHub et GitLab sont des services bâtis dessus. On peut utiliser Git sans eux, mais ils facilitent grandement le travail d’équipe et le partage. GitHub est le plus connu (surtout pour l’open source) ; GitLab se distingue par ses fonctionnalités d’intégration continue et la possibilité de l’héberger soi-même — un atout en entreprise.

À quoi servent ces plateformes ?

Au-delà de l’hébergement, GitLab et GitHub apportent des outils devenus essentiels :

• La revue de code (merge/pull requests) : proposer des changements, les faire relire et commenter avant de les intégrer.
• Le suivi des tâches et bugs (issues).
• L’intégration continue (CI/CD) : lancer automatiquement des tests et des déploiements à chaque modification.

Ces fonctions transforment un simple outil de versionning en véritable plateforme de collaboration autour du code.

En résumé

Le versionning enregistre l’historique d’un projet et permet de revenir en arrière et de travailler à plusieurs sans conflit. Git en est l’outil de référence : distribué (chacun a une copie complète), organisé autour des commits et des branches. GitHub et GitLab sont des plateformes qui hébergent des dépôts Git et ajoutent revue de code, suivi des tâches et automatisation. Comprendre cette architecture est la première étape ; la suivante est de manier les commandes Git au quotidien, que nous détaillerons dans un article dédié. Nous consacrerons un article dédié aux commandes Git essentielles (clone, commit, push, branch, merge…) pour passer à la pratique.