Il ne faut pas envoyer un mot de passe par e-mail parce que l'e-mail ne remet pas, il recopie : la clé reste en clair dans la boîte du destinataire, sur son téléphone, dans les historiques et dans les sauvegardes, sans expiration et sans savoir qui l'a vue. La bonne façon de la partager est un lien à usage unique qui affiche le contenu une fois et l'efface, avec vérification du destinataire et traçabilité de la remise.
Où finit réellement un mot de passe envoyé par e-mail
La messagerie est conçue pour l'inverse de ce dont vous avez besoin ici : pour que le message arrive, se conserve et puisse être retrouvé. En écrivant une clé dans le corps du message, vous créez des copies dans des endroits sur lesquels vous n'avez aucun contrôle. Voici ceux qu'on oublie le plus souvent :
| Où ça reste | Combien de temps | Qui peut finir par le lire |
|---|---|---|
| Votre dossier « Envoyés » | Jusqu'à ce que quelqu'un l'efface : personne ne l'efface | Vous, et quiconque accède à votre compte |
| La boîte du destinataire | Indéfiniment | Cette personne et toute personne ayant accès à sa session |
| Son téléphone et son portable | Tant que le compte est configuré | Qui prend l'appareil déverrouillé, ou le vole |
| Les sauvegardes du serveur | Ce que dit votre politique de conservation : mois ou années | L'administration système et qui restaure une sauvegarde |
| Transferts et fils de réponses | Pour toujours, et en augmentation | Toute personne rejoignant le fil ensuite |
| Archivage et eDiscovery | La durée légale de conservation | Juridique, conformité et auditeurs externes |
S'y ajoute ce qu'on ne voit pas. Un identifiant partagé ainsi n'a ni propriétaire, ni date, ni inventaire. Le jour où cette personne change d'entreprise, où le prestataire cesse de l'être ou où survient un incident, personne ne sait quelles clés il faudrait renouveler, parce que personne ne sait combien ont été distribuées ni à qui.
Et ce n'est pas un risque théorique. Le Verizon Data Breach Investigations Report 2026 situe l'abus d'identifiants dans 39 % de toutes les violations analysées à un moment ou un autre de la chaîne d'attaque : la technique la plus répandue du rapport, même si en tant que vecteur d'accès initial elle est tombée à 13 % contre 22 % l'année précédente, dépassée par l'exploitation de vulnérabilités.
Pourquoi les équipes continuent
Pas par négligence. Par absence d'alternative au moment précis où elle est nécessaire. Quelqu'un doit donner au technicien qui arrive cet après-midi le mot de passe du FTP, transmettre au client le code PIN du certificat, ou remettre à la personne qui arrive demain ses accès du premier jour. Ce qu'il a sous la main, c'est l'e-mail et la messagerie. Ce qu'il n'a pas sous la main, c'est tout le reste.
Le schéma se répète avec tout outil interdit sans substitut : c'est la même histoire que pour le shadow AI en entreprise et pour les services grand public d'envoi de fichiers. Interdire sans fournir d'alternative utilisable ne change pas le comportement : cela le rend seulement invisible pour vous.
La seule mesure publique pertinente de cette habitude a déjà quelques années, mais elle reste parlante : dans le Workplace Password Malpractice Report de Keeper, une enquête auprès de 1 000 salariés américains menée en février 2021, 62 % déclaraient avoir partagé un mot de passe professionnel par SMS ou par e-mail. Prenez-la pour ce qu'elle est — ancienne et sur un seul marché — et comparez-la à ce que vous trouverez dans vos propres « Envoyés » en cherchant le mot « mot de passe ».
Un test d'une minute. Cherchez dans votre boîte professionnelle « mot de passe », « identifiants », « code d'accès » ou « login ». Comptez combien de résultats sont encore valides aujourd'hui. Ce chiffre est votre point de départ, et c'est généralement celui qui convainc la direction.
Ce que disent les textes (et pourquoi ça échoue en audit)
Aucun texte ne dit littéralement « n'envoyez pas de mots de passe par e-mail ». Quatre le disent sans le nommer :
Exige des mesures techniques et organisationnelles adaptées au risque et cite expressément le chiffrement et la capacité de garantir la confidentialité de manière permanente. Si l'identifiant que vous distribuez donne accès à des données personnelles, le canal par lequel vous le distribuez entre dans le champ de l'article. Du texte en clair sans expiration y est difficile à défendre.
C'est le contrôle qui traite expressément de l'attribution et de la distribution des informations d'authentification, y compris l'obligation de les remettre par un canal sûr et de ne pas les transmettre en clair. C'est littéralement l'opération dont parle cet article, et l'un des constats les plus faciles à documenter en audit de certification : il suffit de demander les e-mails de création de trois comptes.
Adoptée le 21 juillet 2022, elle fixe les exigences minimales d'authentification par mot de passe pour les traitements de données personnelles : une cible d'entropie minimale de 80 bits lorsque le mot de passe est utilisé sans mesure de sécurité complémentaire, et des règles claires sur le stockage et la communication des secrets, qui ne doivent pas circuler en clair.
Le guide de l'ANSSI complète la recommandation de la CNIL avec quatre réflexes : mener une analyse de risque, privilégier l'authentification multifacteur, adapter la robustesse du mot de passe à son contexte d'usage, et utiliser un gestionnaire de mots de passe. Trois de ces quatre réflexes supposent que l'identifiant arrive à son destinataire autrement que par un e-mail en clair.
Dit autrement : le jour de l'audit, personne ne vous demandera si vous avez un outil. On vous demandera comment vous remettez les identifiants, qui les a vus et ce qu'ils sont devenus. Avec l'e-mail, les trois réponses sont « je ne sais pas ». À cela s'ajoute l'article 21 de la directive NIS2, qui inscrit les politiques de cryptographie, les communications sécurisées et l'authentification multifacteur parmi les mesures de gestion des risques exigées des entités concernées.
Les bricolages qui ne fonctionnent pas
Avant d'arriver à la solution, il vaut la peine d'écarter les quatre choses que tout le monde essaie d'abord. Aucune n'est absurde ; toutes laissent le problème intact pour l'essentiel.
Les deux messages arrivent dans la même boîte, sur le même téléphone et dans la même sauvegarde. Cela ne protège que du mauvais destinataire, et si l'autocomplétion vous a trahi une fois, elle vous trahit généralement deux fois. La persistance, qui est le vrai problème, ne change pas d'un iota.
Le chiffrement de bout en bout protège le transport, pas la persistance. Le message reste dans l'historique des deux téléphones et dans les sauvegardes cloud des deux. C'est en outre un canal personnel hors du contrôle de l'entreprise : quand la personne part, l'historique part avec elle, vous ne pouvez ni l'effacer ni prouver ce qui a été partagé.
Cela déplace le problème : il faut maintenant remettre le mot de passe du ZIP, soit exactement l'opération à résoudre. Par le même canal, vous n'avez rien gagné. Et il y a des effets de bord : le chiffrement hérité du ZIP (ZipCrypto) est faible, beaucoup de filtres de messagerie bloquent les pièces jointes chiffrées précisément parce qu'ils ne peuvent pas les analyser, et les noms de fichiers restent visibles.
Et il en faut un : c'est la pièce qui conserve, génère et remplit les identifiants dans la durée — l'ANSSI le recommande explicitement. Mais il résout le stockage partagé au sein d'un groupe qui utilise le même outil. Dès qu'il faut remettre quelque chose à quelqu'un qui n'est pas dans votre gestionnaire — prestataire, client, le technicien du jour —, le gestionnaire ne joue aucun rôle et les gens reviennent à l'e-mail. Les deux pièces sont complémentaires : le gestionnaire conserve, le canal à usage unique remet.
Ce qui fonctionne : le secret à usage unique
L'idée est simple et vieille de plus d'une décennie : au lieu d'envoyer la donnée, vous envoyez une référence qui expire à l'usage. Vous saisissez le mot de passe dans un formulaire ; le système le chiffre et vous renvoie une URL avec un identifiant aléatoire ; vous envoyez cette URL comme vous voulez. À l'ouverture par le destinataire, le contenu s'affiche et le contenu chiffré est supprimé de la base de données. Ensuite, ce qui circule par e-mail est un lien déjà consommé.
Le vrai changement n'est pas cryptographique, il porte sur la persistance : vous passez d'une copie indéfinie dans une demi-douzaine d'endroits à un lien qui ne sert plus à rien. Et au passage, vous gagnez ce que l'e-mail ne vous a jamais donné : savoir que c'est lu, quand et depuis où.
- · La clé est écrite à six endroits
- · Elle n'expire jamais
- · Vous ne savez pas si quelqu'un l'a lue
- · Vous ne pouvez pas la révoquer
- · Vous ne pouvez rien prouver
- · Ce qui circule est un lien consommable
- · Il expire même si personne ne l'ouvre
- · Accusé de lecture avec IP et navigateur
- · Détruit à la main en un clic
- · La chronologie des événements subsiste
Il y a un piège bien connu, à connaître avant de choisir un outil : les filtres anti-maliciels de la messagerie et les aperçus de liens de nombreux clients suivent les liens d'eux-mêmes. Si le service révèle le secret au simple fait de visiter l'URL, le secret est consommé avant d'arriver et le destinataire reçoit un lien mort. C'est pourquoi un service bien conçu exige une action explicite de la personne — en général une requête POST — pour révéler le contenu.
Les dix exigences que doit remplir le canal
La liste sert aussi bien à évaluer un service public gratuit qu'un module intégré à votre plateforme. S'il manque l'une des cinq premières, ce n'est pas un canal de remise d'identifiants, c'est un joli formulaire.
- Chiffrement au repos avec une clé distincte par secret. Pour qu'une ligne compromise ne compromette pas le reste.
- Suppression réelle à la lecture. Le contenu est supprimé, pas marqué comme lu. Posez explicitement la question.
- Expiration même si personne n'ouvre. Un secret jamais ouvert doit mourir seul, pas rester en attente.
- Ouvrir l'URL ne le consomme pas. Protection face aux antivirus de messagerie et aux aperçus.
- Vérification du destinataire. Code à usage unique vers son e-mail ou son mobile, ou phrase secrète remise par un autre canal, pour qu'un transfert ne vaille rien.
- Mode à connaissance nulle. L'option que même le prestataire ne puisse pas déchiffrer, la clé étant dérivée de la seule phrase secrète.
- Accusé de lecture. Savoir quand il a été ouvert, depuis quelle IP et avec quel navigateur.
- Journal d'audit exportable. Création, envoi, ouverture, tentatives échouées, blocage et destruction.
- Données dans l'Union européenne et contrat de sous-traitance. Si le service est gratuit et personnel, il n'y a aucun contrat opposable au titre du RGPD.
- Preuve téléchargeable. Mieux qu'une capture d'écran le jour où il faudra démontrer la remise.
Plusieurs services publics remplissent les cinq premières. En pratique, les cinq dernières sont ce qui sépare un outil grand public d'un outil d'entreprise.
Comment Dokuflex le résout
Les secrets à usage unique sont un module de plus de la plateforme, avec les mêmes utilisateurs, droits et journaux que ceux dont vous disposez déjà. Vous collez le texte — ou générez un mot de passe de 20 caractères sans lettres qui se confondent à la dictée —, choisissez l'expiration et la protection, puis copiez le lien ou laissez Dokuflex l'envoyer par e-mail certifié ou par SMS.
Trois détails font la différence face à un service gratuit :
- Une vraie connaissance nulle. Avec phrase secrète, la clé de chiffrement est dérivée d'elle seule, avec PBKDF2-HMAC-SHA256 et 150 000 itérations. Ni la phrase ni son empreinte ne sont conservées. Personne, nous compris, ne peut l'ouvrir. Et nous le disons avant de vendre : si la phrase est perdue, le contenu est irrécupérable.
- Un certificat de garde en PDF. Signé avec le certificat de votre organisation et horodaté. Il porte l'empreinte SHA-256 du contenu, le mode de protection, les lectures consommées et la chronologie complète. Il ne porte pas le contenu, à dessein.
- Chez vous. La donnée reste dans votre Dokuflex, sous votre contrat et avec vos données dans l'Union européenne, pas sur le serveur d'un tiers que votre entreprise n'a jamais contracté.
S'il s'agit de fichiers et non de texte, la pièce sœur est l'envoi sécurisé de fichiers. Et si l'objectif est de réduire le nombre de mots de passe en circulation, la voie de fond est ailleurs : les passkeys et le SSO avec double facteur, pour que la plupart des accès n'aient plus besoin d'une clé à distribuer.
Questions fréquentes
Est-il interdit d'envoyer un mot de passe par e-mail ?+
Aucun texte ne l'interdit sous ce nom. Ce qui peut être enfreint, c'est l'article 32 du RGPD, qui exige des mesures techniques adaptées au risque lorsque l'identifiant protège des données personnelles, et le contrôle A.5.17 de l'ISO/IEC 27001, qui impose de remettre les informations d'authentification par un canal sûr. La CNIL, dans sa recommandation de 2022, demande d'ailleurs que le secret ne soit jamais transmis en clair. Lors d'un audit de certification, un e-mail contenant la clé dans le corps du message est une non-conformité facile à documenter.
Envoyer le mot de passe dans un second e-mail séparé, ça aide ?+
Non. Les deux e-mails arrivent dans la même boîte, sur le même téléphone et dans la même sauvegarde : qui accède à l'un accède à l'autre. Séparer identifiant et mot de passe ne protège que du cas précis de l'envoi à la mauvaise adresse, et même pas de façon fiable : si l'autocomplétion s'est trompée une fois, elle se trompe généralement deux fois.
Et par WhatsApp, qui est chiffré ?+
Le chiffrement de bout en bout règle le transport, pas la persistance. Le message reste dans l'historique des deux téléphones, dans les sauvegardes cloud des deux, et à la vue de quiconque prend un appareil déverrouillé. C'est en outre un canal personnel que l'entreprise ne contrôle pas : quand la personne part, l'historique part avec elle, vous ne pouvez ni l'effacer ni prouver ce qui a été partagé.
Un ZIP protégé par mot de passe règle-t-il le problème ?+
Il le déplace. Il faut maintenant remettre le mot de passe du ZIP, c'est-à-dire exactement l'opération que vous vouliez résoudre, et par le même canal vous n'avez rien gagné. S'y ajoute que le chiffrement hérité du ZIP (ZipCrypto) est faible, que beaucoup de filtres de messagerie bloquent les pièces jointes chiffrées précisément parce qu'ils ne peuvent pas les analyser, et que les noms de fichiers restent visibles.
Un gestionnaire de mots de passe ne suffit-il pas ?+
Il est indispensable, mais il couvre autre chose. Un gestionnaire conserve, génère et remplit des identifiants dans la durée, au sein d'un groupe qui l'utilise. Le problème apparaît au moment de remettre quelque chose à quelqu'un qui n'est pas dans votre gestionnaire : un prestataire externe, un client, le technicien d'un jour. C'est là que les gens reviennent à l'e-mail. Le bon dispositif comprend les deux pièces : le gestionnaire pour conserver, un canal à usage unique pour remettre.
Qu'est-ce qu'un secret à usage unique ?+
C'est un lien qui affiche un contenu une seule fois puis l'efface. Vous saisissez le mot de passe dans un formulaire, le système le chiffre et vous renvoie une URL avec un identifiant aléatoire ; vous envoyez cette URL comme vous voulez. À l'ouverture par le destinataire, le contenu s'affiche et le contenu chiffré est supprimé de la base. Ensuite le lien ne sert plus à rien, et ce qui circule par e-mail est un lien déjà consommé.
L'antivirus de la messagerie peut-il ouvrir le lien et consommer le secret ?+
C'est l'échec le plus courant des services gratuits : les filtres anti-maliciels et les aperçus de liens des clients de messagerie suivent les URL d'eux-mêmes et consomment le secret avant qu'il n'atteigne son destinataire. Un service bien conçu exige une action explicite de l'utilisateur pour révéler le contenu, en général une requête POST, de sorte que suivre l'URL ne révèle ni ne détruit rien.
Que faut-il exiger d'un service de secrets à usage unique ?+
Dix choses : chiffrement au repos avec une clé distincte par secret ; suppression réelle du contenu à la lecture, pas un simple indicateur ; expiration configurable même si personne n'ouvre ; l'ouverture de l'URL ne doit pas le consommer ; vérification du destinataire par code ou phrase secrète ; un mode à connaissance nulle où même le prestataire ne peut pas déchiffrer ; accusé de lecture ; journal d'audit exportable ; hébergement dans l'Union européenne avec contrat de sous-traitance ; et une forme de preuve téléchargeable pour le jour où il faudra démontrer la remise.
Sources
- Règlement (UE) 2016/679 (RGPD) : article 32, sécurité du traitement.
- CNIL : recommandation relative aux mots de passe et autres secrets partagés, délibération n° 2022-100 du 21 juillet 2022 (cible de 80 bits d'entropie sans mesure complémentaire).
- ANSSI : recommandations relatives à l'authentification multifacteur et aux mots de passe.
- ISO/IEC 27001:2022 : contrôle A.5.17, informations d'authentification.
- Directive (UE) 2022/2555 (NIS2) : article 21, mesures de gestion des risques.
- NIST SP 800-63B-4 (2025) : exigences sur les mots de passe côté vérificateur.
- Verizon Data Breach Investigations Report 2026 : l'abus d'identifiants apparaît dans 39 % des violations à un moment de la chaîne ; comme vecteur d'accès initial il tombe à 13 % contre 22 % l'année précédente, dépassé par l'exploitation de vulnérabilités (31 %).
- Keeper, Workplace Password Malpractice Report (février 2021, 1 000 salariés américains) : 62 % ont partagé un mot de passe professionnel par SMS ou e-mail. Donnée ancienne et sur un seul marché, citée uniquement pour illustrer l'habitude.
Que le chemin facile soit aussi le chemin sûr
Réservez 20 minutes avec les trois cas où vos équipes distribuent des identifiants aujourd'hui. Nous mettons en place avec vous le lien à usage unique, la vérification du destinataire et le certificat de remise. Sans engagement.