On croit souvent qu’un dépôt Git privé met les secrets à l’abri. C’est faux. Dès qu’un mot de passe figure dans le code, considérez-le exposé : un dépôt privé n’est privé que jusqu’au jour où un poste se fait compromettre, ou qu’un accès oublié ouvre la porte. Le caractère privé du dépôt ne protège pas la donnée. Il retarde juste le moment où elle s’échappe.
Sortir les mots de passe du code, c’est les centraliser dans un coffre dédié et les injecter à l’exécution, pour qu’aucun secret ne dorme en clair dans les sources ni dans l’historique Git.
Et la donnée s’échappe par tous les côtés. Un mot de passe de base écrit en clair dans les sources, j’en croise encore régulièrement, sur des projets de toutes tailles, et c’est l’une des premières causes de fuite que je rencontre. Le secret se loge aux pires endroits : dans le code, lisible par bien plus de monde que vous n’imaginez ; dans un commit passé par accident, où il s’installe pour de bon, car effacer le fichier ne le retire pas de l’historique ; dans des fichiers de configuration recopiés sur des postes, dans des sauvegardes, parfois recrachés tels quels dans les journaux applicatifs. À chaque copie, une occasion de fuite en plus, et personne pour la suivre.
La parade tient en deux mouvements simples. D’abord, ranger les secrets dans un coffre dédié, un gestionnaire qui décide qui lit quoi, garde une trace des accès, et sait faire tourner une clé sans qu’on aille fouiller dix serveurs. HashiCorp Vault, le gestionnaire de votre fournisseur cloud, peu importe la marque ; ce qui compte, c’est qu’il existe un endroit unique et auditable. Ensuite, l’application reçoit ses secrets au démarrage, par variables d’environnement fournies par l’orchestrateur (l’outil qui lance et pilote les conteneurs, type Kubernetes) ou par un appel direct au coffre, au moment précis où elle en a besoin. Rien ne s’écrit durablement en clair sur un disque.
L’argument qui emporte vraiment la décision, c’est la rotation. Un secret périmé ou compromis, vous le changez à un seul endroit, et toutes les applications récupèrent la nouvelle valeur. Sans coffre, faire tourner un mot de passe partagé vire à la chasse au trésor : il en reste toujours un d’oublié, et c’est celui-là qui casse la production un dimanche soir. Une fois la rotation outillée, passer de « jamais » à « tous les trimestres » ne coûte presque plus rien.
Reste le cas, fréquent, du projet déjà en route. Là, je commence par fouiller : le code, l’historique Git, les fichiers de conf qui traînent. Un secret exhumé d’un vieux commit se traite comme déjà lu par un inconnu, même si rien ne le prouve. La priorité est donc de le remplacer, pas de le cacher. Retirer la ligne de l’historique viendra après, quand le dépôt le justifie, jamais à la place de la rotation.
Je repense à une PME qui avait recopié la même clé d’API (le jeton secret qui authentifie un service auprès d’un autre) dans une douzaine de services, au fil des déploiements, sans jamais en tenir la liste. Le jour où il a fallu la révoquer en urgence (un prestataire qui partait avec l’accès dans la tête), l’équipe a passé une journée entière à la traquer fichier par fichier, en priant pour n’en oublier aucun. Quinze jours plus tard, les mêmes clés étaient dans un coffre. La fois suivante où il a fallu en changer une, ç’a été l’affaire de cinq minutes et d’un café. Voilà ce que change un coffre : un secret qu’on pilote au lieu de lui courir après.