Migrer depuis Auth0 sans déconnecter tout le monde
Par L’équipe Alt Auth
La raison pour laquelle les équipes restent chez un fournisseur d’authentification qu’elles ont dépassé tient rarement au produit. C’est la migration : la peur d’une fenêtre de maintenance, d’envoyer à chaque client un e-mail de réinitialisation, qu’une intégration oubliée casse un vendredi. Cette peur est en grande partie infondée si le transfert est correctement échelonné.
Étape un : double écriture, lecture unique
Commencez par créer chaque utilisateur dans le nouveau système au moment où il s’authentifie sur l’ancien. Votre application fait toujours confiance à l’ancien fournisseur ; le nouveau accumule discrètement une table d’utilisateurs identique. Après un cycle de facturation complet, vous aurez couvert la grande majorité des utilisateurs actifs sans que personne ne s’en aperçoive.
Étape deux : basculer le chemin de lecture
Orientez les nouvelles sessions vers le nouveau fournisseur, en gardant l’ancien comme solution de repli pour ceux qui ne sont pas encore migrés. Comme les deux émettent des jetons signés, votre application peut vérifier l’un ou l’autre pendant le chevauchement. C’est la seule étape réellement risquée, et elle est réversible en une seule modification de configuration.
Étape trois : traiter la queue
- Exportez les comptes dormants restants et importez-les par CSV.
- Ces utilisateurs passeront par la récupération de mot de passe à leur premier retour — un parcours normal, pas un e-mail de réinitialisation de masse.
- Gardez l’ancien tenant actif, en lecture seule, pendant un cycle supplémentaire avant de l’annuler.
- Ce n’est qu’ensuite que vous supprimez de votre application le chemin de vérification de secours.
L’ensemble de la séquence s’exécute en arrière-plan pendant des semaines. Pas de fenêtre, pas d’e-mail à tous les clients, et aucun moment où une connexion échoue parce que la bascule a eu lieu en plein milieu d’une requête.