---
title: "Ce que vous emportez en quittant un fournisseur d'authentification"
summary: "Changer de fournisseur de connexion sans réinitialiser les mots de passe est possible si l'export a les hashes. Ce qu'il doit contenir, ce qu'EAuth importe."
author: "Samuel Krauss"
author_title: "Founder"
publisher: "Elchi Studios"
published: 2026-10-03
updated: 2026-10-09
url: https://elchi.dev/fr/journal/ce-que-vous-emportez-en-quittant-un-fournisseur-d-auth
language: fr
translation_of: https://elchi.dev/en/journal/what-you-take-with-you-when-you-leave-an-auth-provider
tags: ["eauth","migration","passwords"]
words: 1224
---

# Ce que vous emportez en quittant un fournisseur d'authentification

*Par Samuel Krauss, Founder. Publié le 3 octobre 2026.*

> Changer de fournisseur de connexion sans réinitialiser les mots de passe est possible si l'export a les hashes. Ce qu'il doit contenir, ce qu'EAuth importe.

Ce que vaut un fournisseur de connexion, vous le découvrez le jour où vous voulez le quitter. Si l'export contient les hashes des mots de passe de vos utilisateurs, vous les déplacez et personne ne s'en aperçoit. Sinon, chacun de vos utilisateurs reçoit un mail « merci de définir un nouveau mot de passe » d'une entreprise dont il n'a jamais entendu parler, et une partie d'entre eux ne revient jamais. Cet article parle du premier type d'export, parce que c'est celui que donne EAuth, et de ce qu'il faut vérifier avant de vous inscrire où que ce soit.

## Pourquoi le hash suffit

Un hash de mot de passe n'est pas le mot de passe. C'est le résultat d'une fonction lente et salée que le fournisseur stocke à la place du mot de passe, et il ne sert qu'à une chose : vérifier un candidat. Le remettre au fournisseur suivant lui donne exactement ce qu'avait l'ancien, pas plus, et le fournisseur suivant vérifie les mots de passe de la même manière. Le mot de passe de l'utilisateur ne voyage jamais, et personne ne l'apprend.

C'est pourquoi un fournisseur n'a aucune raison de sécurité de retenir les hashes. Il a une raison commerciale.

## Ce que l'export doit contenir

Demandez un fichier avec, pour chaque compte, l'adresse e-mail, si elle a été confirmée, le nom affiché et le hash du mot de passe sous une forme de chaîne standard qui indique quelle fonction l'a produit. Argon2id au format PHC ressemble à `$argon2id$v=19$m=65536,t=3,p=2$...` ; bcrypt commence par `$2a$`, `$2b$` ou `$2y$` ; scrypt et PBKDF2-SHA256 ont leurs propres formes, comme `$scrypt$` et le `pbkdf2_sha256$` de Django. Un hash sans ses paramètres est inutilisable : la forme compte autant que les octets.

Savoir si l'adresse a été confirmée compte plus qu'il n'y paraît. Un fournisseur qui reçoit un compte marqué comme non confirmé ne devrait pas simplement lui faire confiance, et EAuth ne le fait pas : nous y reviendrons plus bas.

Il vous faut aussi le reste du compte : à quelles organisations appartient une personne et avec quel rôle, les invitations en attente, quels comptes se connectent par le fournisseur d'identité d'une entreprise plutôt que par un mot de passe, et les consentements que chaque personne a donnés à votre application. Les seconds facteurs sont l'exception, et il vaut la peine de savoir pourquoi avant de les demander : une passkey est liée par conception au domaine du fournisseur et ne fonctionnerait nulle part ailleurs, et un secret TOTP gagne à être enregistré à nouveau plutôt que copié d'une base de données à une autre. Après une migration, les utilisateurs réenregistrent leur second facteur, où qu'ils aillent.

## Ce qu'EAuth exporte

Dans la console, le propriétaire et les admins d'une application trouvent **Export everything** sur sa page **Users**. L'application est téléchargée en un seul fichier JSON : ses réglages, son équipe, ses webhooks, ses organisations avec leurs membres, les rôles, les invitations en attente et la connexion single sign-on, les consentements, et chaque compte avec son hash de mot de passe tel qu'il est stocké. Aucun secret ne voyage avec : ni le client secret, ni les secrets de signature des webhooks, ni les clés privées des connexions single sign-on. Ce sont des identifiants de notre service, pas vos données.

Le hash est en Argon2id au format PHC pour toute personne qui s'est connectée chez nous, ou celui avec lequel elle a été importée si elle ne l'a pas encore fait. Chaque compte indique aussi si son adresse est confirmée, s'il a un second facteur, combien de passkeys il possède et, pour les comptes single sign-on, par quel fournisseur d'identité il se connecte. C'est la liste des personnes à qui demander de réenregistrer leur second facteur, prête avant le déménagement. Nos conditions disent l'essentiel en une phrase, au point 7.3 : les hashes figurent dans l'export sous leur forme d'origine, pour que vous puissiez migrer vers un autre fournisseur sans forcer vos utilisateurs à réinitialiser leur mot de passe. Pour nous, pouvoir partir est une fonctionnalité, pas un risque.

L'export d'une seule personne, pour une demande au titre de l'art. 15 ou 20 du RGPD, se trouve sur la page de cette personne dans la console et ne contient aucun identifiant : ce que l'on sait de la personne, pas ce qui permettrait de se connecter à sa place.

## Ce qu'EAuth importe

Dans l'autre sens, c'est la même porte. L'import accepte un tableau JSON ou un CSV avec `email`, `password_hash` et, en option, `display_name` et `email_verified`, jusqu'à 100 000 comptes et 25 MB par fichier, et reconnaît Argon2id, bcrypt, scrypt et PBKDF2-SHA256 à la forme du hash : pas besoin d'une colonne pour dire lequel. La console vérifie d'abord le fichier entier et montre ce qu'elle a trouvé, combien de comptes et dans quels formats ; rien n'est écrit avant votre confirmation. Un fichier avec une seule ligne fautive est refusé en bloc, avec la ligne et la raison, tout comme une ligne dont l'adresse a déjà un compte dans votre application, parce qu'une base d'utilisateurs à moitié importée est pire que pas de base du tout.

Les comptes importés se connectent avec leur ancien mot de passe dès la fin de l'import. Lors de cette première connexion, le mot de passe est hashé à nouveau avec Argon2id : une base d'utilisateurs arrivée en bcrypt quitte bcrypt une personne à la fois, sans que personne n'ait rien à faire. La console signale les comptes qui sont encore sur leur hash importé. Rien ne part vers votre webhook lors d'un import : votre système connaît déjà ces personnes.

Deux exceptions. Un compte importé avec `email_verified` à false, ou sans cette colonne, doit confirmer son adresse lors de sa première connexion, avant que votre application ne le reçoive : depuis le 3 octobre, aucune application ne reçoit de compte dont personne n'a confirmé l'adresse, importé ou non. Marquez comme vérifié ce que l'ancien fournisseur avait vérifié, pas davantage. Et un mot de passe de moins de 12 caractères ou de plus de 256 permet toujours de se connecter, mais n'est pas hashé à nouveau, parce qu'il sort des longueurs qu'EAuth accepte pour un nouveau mot de passe ; ce compte garde son hash importé jusqu'à ce que la personne change de mot de passe, et la mention reste dans la console.

## Une chose à savoir sur bcrypt

bcrypt n'utilise que les 72 premiers octets d'un mot de passe. Un utilisateur dont le mot de passe est plus long se connectait sur ces 72 octets chez le fournisseur précédent et continue ainsi jusqu'à sa première connexion à EAuth, où le mot de passe entier est hashé avec Argon2id. Une petite amélioration que personne n'a à demander, et une raison de ne pas s'étonner qu'une phrase de passe de 90 caractères fonctionnait avant et fonctionne toujours.

## Avant de vous inscrire où que ce soit

Lisez la clause d'export des conditions avant la liste des fonctionnalités. Si les conditions ne disent rien des hashes, partez du principe que la réponse est non. S'il y a une clause et qu'elle dit « sur demande » ou « sous réserve d'examen », attendez-vous à un délai qui se compte en semaines, au moment où vous pouvez le moins vous le permettre. La clause qu'il vous faut dit : à tout moment, sans avoir à demander, dans un format documenté, hashes compris.

## Sources

1. [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), OWASP, consulté le 2026-10-03
2. [PHC Strings](https://c2sp.org/phc-strings), C2SP, consulté le 2026-10-03
3. [RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications](https://www.rfc-editor.org/rfc/rfc9106), IETF, consulté le 2026-10-03