Pourquoi ces deux outils

Une précision avant de commencer

Il n'existe pas de documentation officielle qui compare directement les Dev Containers et pre-commit — et pour cause : ce sont deux outils indépendants, faits par des équipes différentes, qui ne se citent pas l'un l'autre. Ce module est une synthèse pratique, pas une source officielle. L'objectif est simplement de vous donner un moyen clair de vous rappeler lequel des deux résout quel problème, avant de les manipuler dans les modules suivants.

Le problème que résolvent les Dev Containers

Scénario : vous développez une application Node.js en local. Un nouveau coéquipier clone le dépôt, installe les dépendances, et... rien ne marche comme chez vous. Après une heure de débogage, la cause apparaît : il a Node 18 installé, vous avez Node 20, et une dépendance du projet se comporte différemment selon la version.

C'est le problème classique du « ça marche chez moi ». Chaque développeur a sa propre machine, avec ses propres versions d'outils installées au fil du temps, souvent partagées entre plusieurs projets qui ont des besoins différents.

Un Dev Container décrit, dans un fichier versionné avec le code, l'environnement exact dans lequel le projet doit tourner : quelle image de base, quelle version de langage, quels outils système. Quand vous ouvrez le projet dans ce Dev Container, VS Code lance un conteneur construit à partir de cette description — le même conteneur pour vous, pour votre coéquipier, et pour n'importe qui d'autre qui ouvre le projet plus tard. Le « chez moi » et le « chez vous » deviennent littéralement le même environnement.

Le problème que résout pre-commit

Autre scénario : un développeur presse, en fin de journée, colle une clé d'API dans un fichier de configuration pour tester rapidement quelque chose, puis fait git commit sans y repenser. Le secret part dans l'historique git. Même s'il est supprimé au commit suivant, il reste consultable dans l'historique — un vrai problème de sécurité.

Autre variante, plus banale : un fichier est commité avec des espaces en fin de ligne, ou une erreur de syntaxe évidente qu'un simple linter aurait attrapée en une seconde.

pre-commit est un outil qui exécute une liste de vérifications automatiques (appelées hooks) juste avant que git accepte un commit. Si une vérification échoue — un secret détecté, une erreur de syntaxe, du texte mal formaté — le commit est refusé avant d'entrer dans l'historique. Le développeur corrige, puis recommit. Rien de cassé ne part jamais dans le dépôt partagé.

Deux outils, deux moments différents

Une façon simple de garder la distinction en tête :

• Dev Containers agit pendant que vous travaillez — il définit l'environnement dans lequel vous écrivez et exécutez le code.
• pre-commit agit au moment où vous validez votre travail — il vérifie ce que vous êtes sur le point d'enregistrer dans l'historique.

Ce sont deux garde-fous complémentaires, pas deux options concurrentes. Dans les modules suivants, vous allez manipuler les deux séparément : d'abord ouvrir et lire un Dev Container (modules 3 et 4), puis installer pre-commit et voir un commit bloqué en pratique (modules 5 et 6).