Ajouter la MFA à une application prototype sans casser les connexions

Pourquoi la MFA casse si souvent les connexions des prototypes

Ajouter la MFA à une application prototype n’est pas « un écran en plus ». Ça change les règles sur qui peut entrer, ce qui se passe quand quelque chose tourne mal, et le nombre de cas limites que votre flux de connexion doit gérer.

Les bases de code de prototype ont souvent une authentification fragile : sessions et tokens mélangés, source de vérité utilisateur floue, et des raccourcis comme sauter la vérification par email ou réutiliser des codes à usage unique. La MFA expose vite ces raccourcis. Un petit décalage (horloge TOTP désynchronisée, enregistrements utilisateurs dupliqués, ou une course entre « vérifier le mot de passe » et « créer la session ») peut verrouiller de vrais utilisateurs.

« Ne pas casser les connexions » signifie plus que « le chemin heureux fonctionne ». Les gens doivent toujours pouvoir se connecter depuis des appareils et navigateurs anciens, il faut une façon sûre de revenir si le second facteur est perdu, et votre charge support ne doit pas exploser avec des tickets « je suis bloqué ».

Avant de changer quoi que ce soit, mesurez votre ligne de base pour savoir si la MFA aide ou nuit. Suivez quelques chiffres pendant plusieurs jours : taux de réussite de connexion, abandon par étape (mot de passe saisi, invite de code affichée, code accepté), événements de verrouillage et complétions de réinitialisation de mot de passe, et temps médian pour se connecter.

Décidez aussi qui vous protégez en priorité. Forcer la MFA pour tout le monde immédiatement augmente fortement la friction et le support. Un point de départ plus sûr est de cibler les comptes à haut risque comme les administrateurs, l’accès facturation, et toute personne pouvant modifier les réglages de sécurité. Cela vous donne des données réelles sans transformer toute votre connexion en exercice d’urgence.

Notions de base sur la MFA et où l’insérer dans votre flux de connexion

La MFA (authentification multi‑facteurs) signifie prouver que c’est bien vous avec deux types de preuves différents. Généralement c’est un mot de passe (quelque chose que vous savez) plus un code ou une confirmation d’appareil (quelque chose que vous avez). Le « second facteur » est ce contrôle supplémentaire. Le « step‑up auth » signifie que vous ne demandez la MFA que pour une action risquée, comme changer un email ou consulter la facturation. La « récupération » est votre plan de secours si vous perdez le facteur.

L’endroit le plus sûr pour brancher la MFA dans un prototype est après la réussite de la première étape de connexion. Cela préserve votre flux de mot de passe ou OAuth existant.

Où la MFA se place dans le flux

Pour une connexion par mot de passe : l’utilisateur saisit email et mot de passe, vous les vérifiez, puis vous vérifiez si la MFA est activée. Si c’est le cas, vous demandez un TOTP ou une confirmation par passkey avant de créer la session complète.

Pour une connexion OAuth (Google, GitHub, etc.) : vous terminez le callback du provider, vous associez ou créez l’utilisateur, puis vous appliquez la MFA avant d’émettre votre cookie de session ou token.

L’idée clé : ne « connectez » pas à moitié et n’espérez pas récupérer si la MFA échoue. Décidez exactement quand l’utilisateur est pleinement authentifié, et faites de la MFA une part de cette décision.

Ce qui change dans votre base de données

Gardez les données MFA séparées des données de mot de passe, et traitez‑les comme sensibles.

Vous aurez typiquement besoin d’un simple flag d’activation et d’un timestamp d’enregistrement, de la méthode choisie (TOTP, passkey, aucune) et des métadonnées spécifiques à la méthode, et du minimum nécessaire pour vérifier de futurs challenges (par exemple, un secret TOTP chiffré au repos ou des identifiants de credential pour les passkeys). Ajoutez des hachages de codes de récupération (pas le texte brut), un indicateur “utilisé” par code, et éventuellement un champ comme last_mfa_verified_at si vous comptez appliquer des règles de step‑up.

Ce qu’il faut logger pour le dépannage

De bons logs vous permettent de déboguer des verrouillages sans divulguer de secrets. Enregistrez des événements comme « MFA challenge créé », « vérification MFA échouée », et « code de récupération utilisé », ainsi que l’ID utilisateur, le timestamp, l’IP et l’user agent. Ne logguez pas les codes TOTP, les secrets, les codes de récupération en clair ou les tokens OAuth complets.

Choisir TOTP ou passkeys pour un prototype

Si vous ajoutez la MFA à un prototype, le choix se fait généralement entre TOTP (codes d’authentificateur) et passkeys (authentification biométrique ou basée sur l’appareil). Les deux peuvent fonctionner, mais échouent différemment.

TOTP est le classique « saisissez un code à 6 chiffres ». Les utilisateurs scannent un QR avec une application d’authentification, puis saisissent un code au moment de la connexion. De votre côté, vous stockez un secret partagé par utilisateur (chiffré au repos) plus quelques champs d’audit comme la date d’activation et la dernière utilisation. Modes d’échec communs : l’utilisateur perd son téléphone, l’horloge de l’appareil est désynchronisée, ils s’enregistrent deux fois et écrasent le secret, ou l’app permet par erreur une connexion sans vérifier le second facteur.

Les passkeys paraissent plus simples. Les utilisateurs approuvent avec Face ID, empreinte, ou un code de l’appareil. Vous stockez une clé publique et un credential ID, pas un secret partagé. Les échecs se déplacent : dépendance à l’appareil (pas d’accès au device), configuration inter‑appareils confuse, ou « ça marche sur mon laptop mais pas sur mon téléphone » si les passkeys ne se synchronisent pas comme l’utilisateur l’attend.

Une règle pratique est simple. Choisissez TOTP quand vous avez besoin d’un accès prévisible multi‑appareils (administrateurs, support, outils B2B) et que vous ne pouvez pas compter sur des appareils modernes. Choisissez passkeys si vous voulez la connexion la plus fluide pour les consommateurs modernes et acceptez que la récupération nécessite plus d’attention. Supportez les deux si vos utilisateurs sont mixtes, mais gardez l’interface claire : recommandez un défaut (« Utilisez une passkey sur cet appareil ») et proposez l’autre comme secours évident (« Utilisez une application d’authentification à la place »).

Exemple : une start‑up de deux personnes qui expédie un panneau admin interne pourrait choisir TOTP d’abord (ça marche partout), puis ajouter les passkeys plus tard sans changer la politique pour les comptes admin.

Flux d’enrôlement qui évite les verrouillages

Le plus grand risque pendant l’enrôlement est d’activer la MFA trop tôt. Si vous basculez le flag « MFA activée » avant que l’utilisateur ait prouvé qu’il peut réellement l’utiliser, un flux de prototype peut le piéger dans une boucle : « Entrez le code » alors qu’il n’a pas d’authentificateur fonctionnel, une invite passkey qui n’apparaît jamais, ou une session perdue.

Un pattern sûr consiste à traiter l’enrôlement comme un test et à n’activer la MFA qu’après une vérification réussie. Cette règle unique évite la plupart des verrouillages.

Un schéma d’enrôlement à l’épreuve des verrouillages

Gardez le flux linéaire et tolérant. Commencez l’enrôlement pendant que l’utilisateur est pleinement connecté (session fraîche). Laissez‑le configurer le facteur (scanner un QR TOTP ou créer une passkey), puis vérifiez immédiatement une fois (saisir un code TOTP ou compléter l’approbation passkey). Juste après, affichez les codes de récupération et demandez une confirmation explicite comme « Je les ai sauvegardés ». Ce n’est qu’alors que vous marquez la MFA comme activée et affichez un écran de succès clair.

Un bon texte réduit les tickets support. Soyez précis : « Scannez ce QR dans Google Authenticator ou 1Password. Ensuite entrez le code à 6 chiffres pour confirmer. Si vous fermez cet onglet avant de confirmer, la MFA ne sera pas activée. »

Cas limites à gérer en amont

Le TOTP échoue souvent à cause de la dérive d’horloge. Si un code est rejeté, dites aux utilisateurs de vérifier que l’heure du téléphone est réglée automatiquement, et autorisez une seconde tentative avant de forcer un redémarrage.

Les passkeys peuvent échouer si l’appareil manque ou si l’invite est bloquée. Proposez un chemin de secours pendant l’enrôlement : « Impossible d’utiliser une passkey maintenant ? Utilisez une application d’authentification à la place. » Assurez‑vous que les codes de récupération fonctionnent même si l’appareil de passkey est perdu.

Codes de récupération : création, stockage et régénération

Les codes de récupération sont l’option « casser la vitre » quand la MFA échoue : téléphone perdu, application d’authentification effacée, ou passkey indisponible. Ce sont des clés de secours, pas une méthode de connexion quotidienne. Affichez‑les juste après un enrôlement MFA réussi, et indiquez clairement que c’est le seul moment pour les sauvegarder.

Gardez l’ensemble assez petit pour que les gens l’enregistrent réellement. Dix codes à usage unique est un bon compromis pour un prototype : ça couvre quelques jours difficiles sans devenir une longue liste que les utilisateurs ignorent. Proposez copier et télécharger, mais exigez une vérification forte (mot de passe ou MFA actuelle) avant d’afficher ou régénérer les codes.

La plus grosse erreur est de stocker les codes de récupération en clair. Ne conservez que des versions hachées (comme pour les mots de passe) et gardez un enregistrement utilisé vs inutilisé afin que chaque code fonctionne une seule fois puis soit brûlé.

Un modèle de stockage sûr est simple : générez 8–10 codes aléatoires, stockez chaque code comme un hash plus un used_at (null tant que non utilisé), rate‑limitez les tentatives et bloquez temporairement le formulaire de récupération après des échecs répétés, et logguez l’utilisation d’un code de récupération comme événement de sécurité.

La régénération doit être stricte. Lorsqu’un utilisateur génère de nouveaux codes, invalidez immédiatement tous les anciens, même ceux non utilisés. Prévenez clairement : « Vos anciens codes de récupération ne fonctionneront plus maintenant. » Pour plus de sécurité, autorisez la régénération seulement après une vérification forte (MFA actuelle ou une connexion vérifiée récemment), afin qu’un voleur de mot de passe ne puisse pas remplacer tranquillement les codes.

Déployer la MFA en phases avec des chemins de secours clairs

Essayer d’imposer la MFA d’un coup crée souvent une vague de verrouillages. Un déploiement par étapes réduit le risque et montre où les vrais utilisateurs rencontrent des problèmes.

Un plan en phases qui convient à la plupart des petites apps :

• Opt‑in : incitez les utilisateurs à activer la MFA après la connexion, avec une option claire pour passer.
• Obligatoire pour admins et staff : protégez d’abord les comptes à plus haut risque.
• Obligatoire pour tous : seulement après que l’enrôlement et la récupération sont stables.
• Step‑up uniquement : utilisez la MFA seulement pour des actions risquées (changer l’email, exporter des données, voir la facturation), même si la connexion reste par mot de passe.

Chaque phase a besoin d’un fallback sûr, sinon le support est submergé. Visez au moins deux façons de revenir : une option en self‑service et une option humaine.

Chemins de secours qui préviennent les verrouillages

Planifiez-les avant d’imposer quoi que ce soit. Les codes de récupération sont le minimum. Un facteur de secours aide aussi (TOTP plus passkey, ou deux passkeys). Si vous offrez des réinitialisations assistées par le support, définissez des vérifications d’identité claires et un délai avant de retirer la MFA. Une courte période de grâce après l’enrôlement peut réduire les faux verrouillages, mais gardez‑la limitée (par exemple « passer une fois ») pour qu’elle ne devienne pas une contournement permanent.

Feature flags et communication

Utilisez un feature flag pour déployer d’abord aux comptes internes, puis à de petits cohortes (5 %, 20 %, 50 %). Surveillez le taux d’achèvement d’enrôlement, le taux d’échec des challenges MFA, et les tickets « je n’ai pas accès ».

Dites aux utilisateurs ce qui change et quoi faire s’ils perdent l’accès. Un message court dans l’app vaut mieux qu’une longue annonce : « On vous demandera un code supplémentaire la semaine prochaine. Sauvegardez vos codes de récupération maintenant. »

Rendre les réinitialisations et modifications de compte sûres pour la MFA

La façon la plus simple de contourner la MFA est de la contourner via des changements de compte. Traitez les réinitialisations et modifications de profil comme des événements de sécurité, pas comme de simples formulaires.

La réinitialisation de mot de passe ne doit pas désactiver la MFA

Les réinitialisations sont attractives pour les attaquants car les boîtes mail se font compromettre. Après une réinitialisation réussie, gardez la MFA activée et exigez une vérification step‑up à la prochaine connexion. Si vous autorisez la réinitialisation de la MFA, faites‑en une action séparée qui nécessite un challenge MFA (ou un code de récupération) après la mise en place du nouveau mot de passe.

Une bonne règle : changer le mot de passe peut aider quelqu’un à retrouver l’accès, mais ne doit pas donner le pouvoir de supprimer la MFA.

Protéger les modifications à haut risque avec des vérifications step‑up

Certaines modifications doivent toujours exiger « prouvez que c’est bien vous », comme le changement d’email, l’enrôlement d’un nouvel appareil, la suppression ou le remplacement d’une méthode MFA, le changement de numéro de téléphone (si vous utilisez le SMS comme secours) et les modifications de facturation.

Si un utilisateur met à jour son email, envoyez une confirmation à l’ancien email et gardez l’ancien actif jusqu’à confirmation. Si l’ancien email n’est pas accessible, exigez des codes de récupération et une revue support courte.

Sessions, appareils mémorisés et tokens

« Se souvenir de cet appareil » est acceptable, mais gardez‑le limité. Fixez des durées claires (souvent 14–30 jours), exigez une réauth pour les actions risquées même sur un appareil mémorisé, et rendez la révocation prévisible : déconnexion globale après changement de mot de passe, re‑vérification ou révocation des sessions quand la MFA est activée ou remplacée, et une liste « sessions actives » simple avec un bouton révoquer.

Pour les tokens API et intégrations, décidez s’ils sont liés à une session utilisateur (alors la MFA doit contrôler la création et les changements de scope) ou des clés long‑terme (alors comptez sur des scopes stricts, expirations et rotation plutôt que forcer la MFA à chaque appel).

Erreurs courantes qui causent des verrouillages et des incendies de support

La plupart des problèmes MFA ne viennent pas des algorithmes. Ils surviennent parce que les chemins « et si je ne peux pas me connecter ? » n’ont jamais été finalisés.

Erreur 1 : Activer la MFA avant que la récupération soit réelle

Les équipes publient l’invite MFA mais laissent les codes de récupération inexacts, introuvables ou cassés sur mobile. Le résultat est des verrouillages instantanés.

Avant de basculer un flag, testez la récupération de bout en bout avec un compte neuf et un scénario « téléphone perdu » : générez des codes, utilisez‑en un, régénérez, et confirmez que les anciens codes ne fonctionnent plus.

Erreur 2 : Traiter les secrets comme des données normales

Les graines TOTP et les codes de récupération ne sont pas comme un nom d’utilisateur. S’ils sont stockés en clair, copiés dans des logs, ou réaffichés plus tard, une fuite se transforme en prises de compte.

Stockez seulement ce qu’il faut, protégez‑le comme un mot de passe, et n’affichez jamais à nouveau les codes de récupération après la configuration. Si les utilisateurs en ont besoin, qu’ils régénèrent.

Erreur 3 : « Le support peut juste contourner »

Un contournement manuel de la MFA paraît utile jusqu’à ce qu’il devienne le chemin le plus simple pour accéder aux comptes. Si vous avez besoin d’un contournement, rendez‑le limité dans le temps, exigez des étapes de vérification, et laissez une trace d’audit révisable.

Erreur 4 : Gestion TOTP faible

Les échecs TOTP viennent souvent de la dérive d’horloge, de la réutilisation et de l’absence de limites de débit. Accepter le même code deux fois, ou accepter une fenêtre temporelle trop large, facilite le brute force et le replay.

Restez simple : autorisez une petite fenêtre temporelle mais bloquez la réutilisation dans cette fenêtre, rate‑limitez les tentatives, utilisez des verrouillages temporaires (pas des briques permanentes), et affichez des erreurs claires pour « incorrect » vs « expiré ».

Erreur 5 : Supposer que les passkeys se comportent pareil partout

Les passkeys peuvent échouer de façon surprenante : changements d’appareil, différences de support navigateur, ou utilisateurs sans credential synchronisé. Si votre appli exige des passkeys sans secours, vous verrouillerez de vraies personnes.

Gardez un secours clair (TOTP ou codes de récupération) et testez au moins sur un appareil iOS, un appareil Android et un navigateur desktop.

Liste de contrôle rapide avant de lancer la MFA

Une habitude ennuyeuse vous sauve plus tard : assurez‑vous de pouvoir voir ce qui se passe et revenir en arrière rapidement.

Vérifications pré‑lancement (pour pouvoir récupérer vite)

Confirmez que vous pouvez annuler le changement MFA (feature flag, switch de config, ou un déploiement rapide). Activez les logs d’audit pour les événements clés comme enroll, verify, fail, lockout, recovery‑code use, et disable. Sauvegardez la table utilisateur (et toutes les tables liées à la MFA) et entraînez‑vous à restaurer sur une copie sûre. Vérifiez que le suivi d’erreurs capture les erreurs d’auth avec assez de détails pour déboguer sans logger de secrets ni de codes. Testez la révocation de session afin que lorsque les réglages MFA changent, les anciennes sessions soient re‑vérifiées ou déconnectées.

Ensuite, testez les parcours utilisateurs de bout en bout. Ne vous arrêtez pas à « code accepté ». Suivez le chemin complet jusqu’au premier écran après connexion.

Parcours utilisateurs et vérifications de sécurité

Jouez un petit ensemble de scénarios :

• Un nouvel utilisateur enrôle la MFA, puis se connecte sur un deuxième appareil.
• Un utilisateur existant active la MFA, se déconnecte, puis se reconnecte avec appareil mémorisé activé et désactivé.
• Téléphone perdu : un code de récupération fonctionne une fois, puis l’utilisateur régénère les codes et se réenrôle.
• Les flux de changement d’email et de réinitialisation exigent la MFA (ou un step‑up sûr) avant d’être effectifs.
• Résistance aux abus : limites de débit sur les tentatives de mot de passe et de codes MFA, plus des verrouillages temporaires qui ne bloquent pas définitivement le compte.

Préparez‑vous pour le premier ticket support avec un script court : quoi demander, quoi vérifier dans les logs, et quand escalader.

Exemple de déploiement pour une application prototype simple

Imaginez un petit SaaS prototype : les utilisateurs se connectent par email/mot de passe, et il y a une zone admin pour la facturation, la gestion des utilisateurs et les outils support. Vous voulez plus de sécurité, mais sans risquer de bloquer vos collègues.

Commencez par protéger les comptes les plus à risque (admins), puis étendez à tout le monde une fois le flux maîtrisé.

Phase 1 : TOTP optionnel pour les admins

Activez le TOTP uniquement pour les comptes admin, et laissez‑le optionnel au départ. Placez la sollicitation dans les réglages admin, pas au milieu d’une connexion pressée.

Un setup simple : l’admin s’enrôle au TOTP, l’app affiche les codes de récupération une fois, l’admin confirme un code TOTP, et la prochaine connexion demande mot de passe + TOTP. Si le TOTP échoue, un code de récupération les fait rentrer.

Assurez‑vous qu’il existe toujours un moyen de revenir. Si un admin ne peut pas compléter la MFA, il doit pouvoir se connecter avec mot de passe et contacter le support (temporairement) plutôt que d’être bloqué.

Phase 2 : Passkeys pour les utilisateurs réguliers, TOTP en secours

Une fois les admins stables, proposez les passkeys aux utilisateurs réguliers comme option la plus simple. Gardez TOTP disponible comme backup pour ceux qui ne peuvent pas utiliser les passkeys (appareils anciens, ordinateurs partagés).

Déployez doucement : proposez « Ajouter une passkey » après la connexion, puis plus tard rendez la MFA par défaut pour les nouvelles inscriptions.

Un vrai échec, géré proprement

Un utilisateur perd son téléphone et ne peut plus accéder au TOTP. Il se connecte par email/mot de passe, choisit « Utiliser un code de récupération », et entre. Juste après, vous lui demandez d’enrôler une nouvelle passkey (ou un nouveau TOTP) et de régénérer les codes de récupération. Ne retirez l’ancienne méthode MFA que lorsque la nouvelle est confirmée.

Prochaines étapes et quand demander de l’aide

Si vous voulez la MFA sans casser les connexions, commencez par un petit plan que votre équipe peut partager : qui obtient la MFA en premier, comment quelqu’un se connecte si la MFA échoue, et ce qui définit le succès (moins de connexions risquées, pas plus de tickets support).

Faites un petit déploiement interne avec de vrais comptes, de vrais appareils et des conditions réelles (nouveau téléphone, téléphone perdu, dérive d’heure, mode vie privée du navigateur). Gardez le pilote assez petit pour pouvoir surveiller chaque échec et le corriger rapidement.

Décidez de quelques points par écrit avant de basculer : périmètre phase 1, options de secours, ce que vous logguez et revoyez, qui peut réinitialiser ou outrepasser et quelles preuves il faut, et quand l’application deviendra obligatoire (et comment les utilisateurs seront prévenus). Après le déploiement, surveillez la friction tôt. Les pics d’erreurs « code invalide » pointent souvent vers la dérive d’heure, un texte confus, ou des utilisateurs qui enrôlent le mauvais appareil. Les pics d’utilisation de codes de récupération peuvent indiquer que l’enrôlement passkey ou TOTP n’est pas durable.

Demandez de l’aide quand vous voyez des verrouillages répétés, une propriété floue des workflows de réinitialisation, ou des signes que votre code d’auth est fragile (secrets codés en dur, sessions inconsistantes, ou contournements étranges). Si vous avez hérité d’un prototype généré par IA, FixMyMess (fixmymess.ai) peut réaliser un audit de code gratuit pour identifier les risques de verrouillage et les endroits précis où votre flux d’auth actuel peut contourner ou casser la MFA avant que vous ne l’imposiez à tout le monde.