Un développeur pousse .env.production « temporairement » pour débloquer un collègue. Dépôt privé — puis fork consultant, fuite dans les journaux GitHub Actions, ou dépôt passé public par erreur. Clés AWS et Stripe actives dans l'historique git pour toujours. Annuler le commit ne révoque pas ce que les robots ont déjà indexé.
Les secrets de déploiement — clés API, mots de passe base de données, jetons messagerie — ne vivent pas dans le dépôt. Point. La question opérationnelle est où ils vivent et comment ils tournent sans panique.
Règles non négociables
Mettez .env* dans .gitignore et vérifiez en intégration continue qu'un commit échoue si un motif de secret est détecté. Maintenez un .env.example sans valeurs — documentation des clés requises seulement. Planifiez la rotation après départ, fuite suspecte ou fin de prestation. Appliquez le moindre privilège : clé AWS limitée à une action, pas administrateur global. N'envoyez jamais de secrets dans les URLs, Sentry, ou tickets de suivi.
| Anti-modèle | Remplacement |
|---|---|
.env dans git | Secrets forge + fichier serveur |
| Clé prod en staging | Comptes test dédiés |
| Secret dans image Docker | Injection runtime |
| Partage clé par messagerie | Coffre partagé d'équipe |
Par environnement
En local, chaque développeur garde un .env personnel, jamais commité. En intégration continue, utilisez les secrets chiffrés GitHub ou GitLab ; injectez au déploiement par SSH ou API plateforme. En production serveur, un fichier /var/www/.env avec permissions réservées au compte de déploiement, ou fichier d'environnement systemd hors racine web. Sur plateforme managée, les variables d'environnement chiffrées du tableau de bord avec piste d'audit. Couplez avec CI/CD petit projet sans journaliser l'environnement en mode verbose.
Détection proactive
Scannez avec gitleaks ou trufflehog en pré-commit ou en CI. Activez la détection de secrets GitHub si le dépôt devient public. Auditez trimestriellement qui a accès aux clés production.
Rotation sans interruption
Utilisez les clés API à double activation quand le fournisseur le permet (Stripe par exemple). Pour la base : utilisateur secondaire, bascule de chaîne de connexion, révocation de l'ancien. Documentez l'ordre — testez d'abord en préproduction.
Le sommet : le dépôt privé n'est pas un coffre
Voir gestion clés KMS pour les charges sensibles au-delà du .env.
Décider et avancer sans angle mort
Scannez d'abord l'historique git avec gitleaks ou équivalent. Révoquez et faites tourner toute clé exposée ou douteuse — pas seulement le dernier commit. Centralisez les secrets d'intégration continue et maintenez un .env.example à jour. Séparez strictement les identifiants préproduction et production. Formez l'équipe : jamais de secret dans un ticket ou un chat. Comparez les hébergeurs plateforme avec gestion de secrets documentée via l'annuaire.
Questions fréquentes
.env commité par erreur ?
Révoquez et faites tourner immédiatement — annuler le commit git est insuffisant, l'historique conserve le secret.
Secrets en CI ?
Secrets chiffrés de la forge, jamais d'affichage dans les journaux — même en débogage.
Même .env staging et prod ?
Non — clés test et clés live séparées, comptes cloud distincts si possible.
Vault obligatoire ?
Non pour une petite équipe ; secrets forge plus .env serveur suffisent souvent jusqu'à une dizaine de secrets partagés.
Ne plus cacher les clés dans le dépôt, c'est accepter que git n'est pas un coffre — et que la rotation est une fonctionnalité, pas une punition.