Niveau 🟢 débutant
Durée estimée : 15 min · Prérequis : Le moindre privilège
.gitignore et des fichiers .env pour garder les secrets hors du dépôtUn secret commité dans Git, c'est une photo publiée puis supprimée sur un réseau social :
supprimer la publication ne supprime pas les copies déjà faites entre-temps. L'historique Git
fonctionne pareil — un fichier retiré au commit suivant reste consultable indéfiniment dans les
commits précédents, à qui sait chercher.
Un secret — mot de passe, clé privée, jeton d'API, adresse MAC (comme le rappelle
M3) — n'a jamais sa place dans un dépôt Git, même privé.
Pourquoi « même privé » n'est pas une garantie suffisante : un dépôt privé peut devenir
public par erreur de configuration, être cloné avant ce changement, être sauvegardé ailleurs
(ordinateur personnel, service tiers), ou son accès être élargi à d'autres personnes plus tard.
L'historique Git, lui, n'oublie rien : même un fichier supprimé au commit suivant reste
lisible dans l'historique, par quiconque a accès au dépôt et sait où chercher (git log,
git show sur un ancien commit).
⚠️ Un secret commité une seule fois doit être considéré comme compromis, définitivement —
même s'il est supprimé au commit suivant. La seule remédiation complète est de changer le
secret lui-même (nouveau mot de passe, nouvelle clé), pas de le retirer du dépôt. Retirer un
commit contenant un secret réécrit l'historique, mais ne garantit rien sur ce qui a déjà pu
être cloné ou consulté entre-temps.
Comment garder les secrets hors du dépôt, en pratique :
.gitignore — un fichier qui liste les motifs de noms de fichiers que Git doit ignorer*.env, secrets/.env — des fichiers de variables d'environnement (mots de passe, jetons)compose.yaml (vu en.env.example, lui, peut être versionné : il documente lesmot_de_passe: hunter2, on documente « mot de passe défini à l'installation, changé auSi un secret finit malgré tout dans l'historique : la priorité absolue est de changer ce
secret immédiatement, indépendamment de toute réécriture d'historique. Un mot de passe qui a
transité par un dépôt — même privé, même supprimé au commit suivant — doit être changé, sans
exception.
🧪 Concrètement, sur notre exemple, un incident réel. Une adresse MAC — une donnée qui
tombe sous cette même règle, au même titre qu'un mot de passe — est restée en clair dans un
fichier de suivi de sprint de ce dépôt, avant d'être retirée. Le dépôt étant privé et
l'incident détecté rapidement, il n'y a pas eu de divulgation réelle — mais la leçon tirée a
été formulée clairement :
« on ne doit pas avoir à faire attention, le contrôle doit être outillé. » C'est directement
ce qui a motivé l'écriture d'un script de vérification automatique, plutôt que de compter sur
la seule vigilance humaine pour ne plus reproduire l'erreur — l'esprit même de l'outil
git secrets --scanprésenté plus haut.
Une fois qu'un secret a franchi la ligne vers un commit, la seule action qui compte réellement
est de le changer — retirer le commit ne suffit jamais à lui seul.
cat .gitignore
# VĂ©rifie que les motifs *.env, secrets/, etc. y figurent bien
git log -p --all -- "*.env"
# Recherche, dans TOUT l'historique du dépôt, si un fichier .env a
# un jour été commité -- une vérification à faire une fois, surtout
# sur un dépôt déjà ancien
git secrets --scan
# (si l'outil git-secrets est installé) scanne l'historique à la
# recherche de motifs ressemblant Ă des secrets -- automatise ce
# que "verifier-anonymat.sh" fait pour ce wiki spécifiquement
git log --all --full-history -- "*.env" "secrets/*"
Ne doit renvoyer aucun résultat sur un dépôt propre — la moindre ligne affichée signale un
secret potentiellement passé par l'historique, à traiter en priorité (changer le secret
concerné).
| SymptĂ´me | Cause probable | Solution |
|---|---|---|
Croire qu'un git rm suivi d'un commit efface un secret de l'historique |
Confusion entre suppression du fichier actuel et effacement de l'historique | L'historique conserve tous les commits précédents ; seul un secret changé cesse d'être un risque |
.env versionné par erreur en début de projet |
.gitignore ajouté après coup, trop tard |
Vérifier .gitignore dès la création du dépôt, avant le premier commit sensible |
| Documenter un mot de passe réel « pour ne pas l'oublier » | Confusion entre documenter la méthode et documenter la valeur | Documenter l'emplacement et la procédure, jamais la valeur elle-même |
.gitignore et les fichiers .env (non versionnés) sont les outils de base pour garder les.env.example avec des valeurs factices peut être versionné ; jamais le .env réel.Parce qu'un dépôt privé peut devenir public par erreur, être cloné avant un tel changement, ou
être sauvegardé ailleurs — et l'historique Git conserve tout, y compris ce qui a été supprimé
depuis.
Changer ce mot de passe immédiatement — c'est la seule remédiation complète, indépendamment de
toute réécriture de l'historique Git.
Un fichier .env.example, avec des valeurs factices qui documentent les variables attendues —
jamais le fichier .env réel contenant les vraies valeurs.
Sur un dépôt Git à disposition (le tien, ou un dépôt de test), vérifie le contenu de
.gitignore et exécute git log -p --all -- "*.env" pour confirmer qu'aucun fichier .env
n'est jamais entré dans l'historique.
.gitignore ·
.env
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.