Le secret le mieux échangé est celui qu’on n’échange pas

Chaque projet commence par le même rituel : « tu peux m’envoyer les accès ? ». Et chaque équipe improvise une réponse, souvent la mauvaise. Un mot de passe dans un e-mail, une clé d’API dans un canal Slack, un fichier .env en pièce jointe : le secret vient de quitter tout périmètre de contrôle, pour toujours.

Avant de chercher un meilleur canal, posons la vraie question : ce secret a-t-il besoin d’exister sous cette forme ? Les mécanismes d’identité fédérée (OIDC entre une CI et un cloud, rôles IAM, identités de charge de travail) remplacent le secret statique par une preuve d’identité éphémère. Pas de clé à transmettre, pas de clé à faire fuiter, pas de clé à faire tourner. Quand cette option existe, elle gagne : le reste de cet article ne concerne que les secrets qui doivent réellement circuler entre des personnes.

Les canaux qui disqualifient

Certains canaux sont disqualifiés d’office, sans débat possible :

l’e-mail, répliqué sur des serveurs que personne ne contrôle, indexé, archivé, transféré ;
la messagerie d’équipe, dont l’historique est consultable par les admins, exporté lors des migrations, et conservé bien après le départ des membres ;
le ticket ou le document partagé, qui survivra au projet et réapparaîtra dans une recherche plein texte trois ans plus tard ;
le SMS et les messageries personnelles, qui mélangent périmètre privé et professionnel.

Le point commun : la persistance non maîtrisée. Un canal d’échange de secret acceptable garantit exactement l’inverse, c’est-à-dire le chiffrement de bout en bout et la disparition.

Ce qui fonctionne, du plus simple au plus outillé

Pour un échange ponctuel, un lien à usage unique et à durée de vie courte, généré par un outil auditable, fait le travail : le destinataire ouvre, le secret s’efface. On valide la réception par un second canal (un appel, un message), ce qui confirme au passage que le bon destinataire a bien consommé le lien.

Pour une collaboration durable, l’échange ponctuel ne suffit plus : il faut un espace partagé. Un gestionnaire de mots de passe d’équipe avec des coffres par périmètre reste la solution la plus accessible ; un gestionnaire de secrets centralisé (avec journalisation des accès et politiques par rôle) devient pertinent dès que l’infrastructure le justifie. Le critère de choix est le même dans les deux cas : peut-on savoir qui a accédé à quoi, et retirer un accès en une action ?

Le schéma vaut la peine d’être répété : le message de notification ne contient jamais le secret. Il dit seulement où le récupérer, avec ses propres droits.

Le moindre privilège n’est pas une paranoïa, c’est un budget

Chaque secret transmis est une dette : quelqu’un devra s’en souvenir, le faire tourner, le révoquer. On réduit cette dette à la source :

des secrets par environnement, jamais le même jeton en préproduction et en production ;
des secrets par personne ou par service, jamais de compte partagé « team » dont plus personne ne sait qui le détient ;
des portées minimales : une clé en lecture seule pour un besoin en lecture seule ;
des durées de vie courtes par défaut, l’expiration étant la meilleure des rotations.

L’historique Git n’oublie jamais

La fuite la plus fréquente ne passe par aucun canal d’échange : elle est commitée. Un .env ajouté « temporairement », une URL de connexion dans un fichier de configuration, une clé dans un test. L’historique est une mémoire éternelle et distribuée : chaque clone en emporte une copie.

La défense se joue en couches. Un .gitignore strict sur les fichiers d’environnement. Un scanner de secrets en pre-commit et dans la CI, qui bloque avant la publication. Et une règle absolue le jour où un secret atteint malgré tout l’historique : la purge ne suffit jamais, on considère le secret compromis et on le fait tourner immédiatement. Réécrire l’historique sert à limiter l’exposition future, pas à annuler la fuite.

La sortie fait partie de l’échange

Un processus d’échange de secrets se juge à son offboarding. Le départ d’un membre de l’équipe, la fin d’une mission, la résiliation d’un prestataire déclenchent la même mécanique : révocation des accès nominatifs, rotation des secrets partagés auxquels la personne a eu accès, vérification du journal. Si cette liste est douloureuse à établir, c’est que les secrets ont été distribués sans être inventoriés, et l’inventaire est précisément ce qu’un coffre fournit gratuitement.

La checklist que nous appliquons

Peut-on remplacer ce secret par une identité éphémère ? Si oui, le faire.
Aucun secret en clair dans un e-mail, un chat, un ticket ou un document.
Échange ponctuel : lien à usage unique, notification hors bande.
Collaboration durable : coffre partagé, accès par rôle, journalisation.
Un secret par environnement, par personne, à portée et durée minimales.
Scanner de secrets en pre-commit et en CI.
Secret dans l’historique = secret compromis : rotation immédiate.
Offboarding scripté : révoquer, faire tourner, vérifier le journal.

Rien de tout cela n’est coûteux. Ce qui coûte, c’est le jeton oublié dans un canal Slack qui donne encore accès à la production deux ans après la fin du projet.