Une cliente perd son téléphone pendant un déplacement. Elle doit télécharger une facture, mais sa clé d'accès habituelle n'est plus disponible. Le support reçoit une demande urgente, accompagnée du nom de l'entreprise et d'informations que l'on trouve sur ses réseaux sociaux. À cet instant, la sécurité du portail dépend du parcours de récupération autant que du bouton de connexion.
Les passkeys déplacent une partie du travail d'authentification vers les appareils et leurs fournisseurs. Pour une entreprise qui modernise son portail, cette évolution mérite un projet produit complet : comprendre les situations de perte, expliquer les choix disponibles et permettre une reprise sans donner au support un pouvoir de contournement illimité.
La synchronisation change le problème, elle ne le fait pas disparaître
Une passkey liée à un appareil et une passkey synchronisée ne créent pas le même parcours de secours. Dans le premier cas, un autre authentificateur enregistré peut être nécessaire. Dans le second, retrouver l'accès au fournisseur de synchronisation peut permettre de retrouver la clé, selon les conditions de ce fournisseur.
Le guide de déploiement de la FIDO Alliance distingue ces situations et recommande une récupération adaptée au risque. Il demande notamment d'anticiper l'enregistrement de nouveaux appareils et la perte d'accès au compte du fournisseur. Ce document est une base de conception ; il ne garantit pas le comportement de chaque combinaison de navigateur, appareil et gestionnaire.
Votre équipe doit donc savoir quelle expérience elle propose réellement. Une démonstration réalisée sur le téléphone du développeur ne prouve pas qu'un client bloqué pourra reprendre son activité sur un ordinateur partagé ou un appareil neuf.
Dessiner trois histoires avant de développer
La première histoire concerne une personne qui a perdu un appareil mais possède encore une session ou un authentificateur utilisable. Le portail peut l'aider à enregistrer un nouvel accès, avec une vérification appropriée. Il faut distinguer cette opération de la simple modification d'une préférence de profil.
La deuxième histoire concerne la perte de tous les accès disponibles. Le support doit suivre une procédure explicite, avec des preuves adaptées au compte et une décision traçable. Une donnée connue publiquement ne devient pas une preuve d'identité parce qu'elle figure déjà dans votre CRM.
La troisième concerne une entreprise cliente dont l'administrateur quitte son poste. Il s'agit aussi d'un changement d'habilitation organisationnelle. Récupérer une identité personnelle ne suffit pas à déterminer qui peut administrer les factures ou inviter de nouveaux collaborateurs.
Ces histoires produisent des besoins différents. Les rassembler sous un unique bouton « réinitialiser » rend les responsabilités difficiles à comprendre et les erreurs difficiles à corriger.
Ce que la CNIL apporte au cadrage français
La recommandation MFA publiée par la CNIL le 1er avril 2025 traite notamment de la minimisation des données, des durées de conservation et des rôles des acteurs de l'authentification. Son périmètre ne couvre pas toute la gestion des comptes et des habilitations.
Pour un projet en France, cette distinction aide à poser deux conversations séparées. La première concerne les données nécessaires à l'authentification. La seconde concerne les pouvoirs accordés dans le portail. Votre responsable de la protection des données doit participer au choix des preuves conservées et de leur durée ; accumuler des justificatifs « au cas où » n'est pas un objectif technique.
Le prestataire doit expliquer où arrivent les pièces éventuellement demandées, qui les consulte et comment elles sont supprimées. Les tickets de support, leurs pièces jointes et leurs exports font partie de cette discussion.
Reprendre le scénario du téléphone perdu
Imaginons un portail de maintenance destiné à des clients professionnels. La cliente peut consulter ses interventions et modifier des coordonnées de paiement. Après la perte du téléphone, un opérateur de support propose de remplacer son accès.
Une conception utile sépare la consultation d'informations courantes et la reprise des opérations sensibles. Elle prévoit une notification vers les canaux déjà enregistrés, une revue des accès encore actifs et une confirmation de la modification. Les éventuelles restrictions temporaires doivent être expliquées à la personne concernée et adaptées au risque du service.
L'opérateur ne devrait pas improviser le niveau de preuve en fonction de l'urgence exprimée. Son écran doit montrer l'étape autorisée, l'état de la demande et les personnes habilitées à décider. Le journal doit permettre de comprendre la décision sans conserver inutilement le contenu intégral des échanges.
Tester aussi ce qui doit cesser de fonctionner
Une récupération réussie ne se limite pas à une nouvelle connexion. Il faut vérifier le sort de l'ancien accès et des sessions existantes. La révocation d'une passkey enregistrée et la fermeture d'une session sont deux opérations à concevoir explicitement dans votre application.
- ▸Vérifier la reprise avec un second appareil déjà enregistré.
- ▸Tester une récupération sans aucun accès disponible.
- ▸Refuser une demande qui ne satisfait pas les preuves attendues.
- ▸Contrôler les droits du support et les validations supplémentaires.
- ▸Vérifier le comportement des anciens accès après la décision.
- ▸Tester les messages, les erreurs et l'accessibilité du parcours.
Utilisez des comptes de test et des situations simulées. Un exercice avec le support révèle souvent des informations que la seule équipe de développement ne possède pas : contrats collectifs, délégations temporaires, clients sans smartphone professionnel ou besoins d'assistance linguistique.
Organiser une migration que les clients comprennent
Expliquez au client ce qu'il enregistre, comment il peut ajouter un autre accès et ce qu'il doit faire en cas de perte. Évitez de promettre que toute clé sera automatiquement récupérable. Conservez un parcours d'assistance compatible avec les appareils réellement utilisés par votre public.
Les premiers indicateurs utiles sont les inscriptions interrompues, les demandes de récupération et les erreurs par parcours. Ils doivent aider à améliorer le service, sans transformer la télémétrie en collecte de renseignements superflus.
Notre guide sur le cadrage et la recette d'un logiciel métier aide à formuler ces résultats attendus. Pour relier l'authentification à un projet de portail, découvrez le développement logiciel sur mesure, puis décrivez votre parcours de connexion et de récupération. TuniCyberLabs peut examiner ce besoin avec votre équipe à distance.