Ce que change réellement l'arrivée des passkeys pour une entreprise
Il y a des sujets techniques qui restent confinés aux salles serveur pendant des années, puis qui débarquent un matin sur le bureau d'un dirigeant sans prévenir. Les passkeys font partie de ceux-là. Depuis dix-huit mois, la question revient dans les comités de direction, souvent amenée par un DSI, parfois par un assureur, de plus en plus souvent par un client grand compte qui pose ses conditions.
Et là, première surprise : personne ne sait vraiment qui doit s'en occuper.
Le mot de passe n'est pas remplacé, il est contourné
Commençons par lever un malentendu tenace. Une passkey ne remplace pas le mot de passe au sens où un nouveau format viendrait se substituer à l'ancien. Elle change carrément la nature de l'opération d'authentification.
Avec un mot de passe, vous envoyez un secret à un serveur qui le compare à ce qu'il a stocké. Avec une passkey, votre appareil signe un défi cryptographique et renvoie une preuve. Aucun secret ne circule. Aucun secret n'est stocké côté serveur. Il n'y a plus rien à voler dans votre base de données, ou plutôt : ce qu'il y a à voler n'a aucune valeur pour un attaquant.
Cette distinction paraît théorique. Elle ne l'est pas du tout, et elle détermine à peu près tout le reste du raisonnement, y compris le budget.
Deux chantiers distincts que l'on confond systématiquement : l'authentification de vos clients, l'authentification de vos salariés
Voilà l'erreur la plus fréquente, et elle coûte cher.
Quand un dirigeant dit « on va passer aux passkeys », il parle en général de deux choses radicalement différentes sans en avoir conscience. D'un côté, l'authentification des utilisateurs finaux sur son site ou son application : les clients, les adhérents, les prospects. De l'autre, l'authentification de ses propres collaborateurs sur les outils internes : messagerie, ERP, CRM, accès administrateur, banque en ligne.
Ce ne sont pas les mêmes technologies dans le détail. Ce ne sont surtout pas les mêmes prestataires, pas les mêmes budgets, pas les mêmes délais. Un projet CIAM (authentification client) et un projet IAM interne se pilotent séparément, avec des interlocuteurs qui ne se croisent pratiquement jamais.
Confondre les deux dans un même cahier des charges, c'est s'assurer des devis incomparables et une négociation qui patine pendant trois mois.
Pourquoi le sujet arrive maintenant sur votre bureau (Apple, Google, Microsoft, banques, assureurs cyber)
Le calendrier n'a rien d'un hasard. Les trois grands systèmes d'exploitation ont terminé leur travail d'intégration. iOS, Android, Windows et macOS savent tous créer, stocker et synchroniser des passkeys nativement. Les navigateurs suivent. La barrière technique côté utilisateur est tombée.
Simultanément, les banques ont commencé à pousser l'authentification forte sur leurs portails professionnels. Les assureurs cyber, eux, posent des questions de plus en plus précises dans leurs questionnaires de souscription. Et certains donneurs d'ordre du secteur industriel ou de la santé exigent désormais un niveau d'authentification résistant au phishing chez leurs fournisseurs, contractuellement.
Autrement dit : le sujet ne vient plus de la technique. Il vient de vos partenaires commerciaux et de vos assureurs. C'est ce qui change tout dans la manière de le traiter.
Comprendre la mécanique en cinq minutes, sans être technicien
Clé publique, clé privée : l'analogie du cadenas et de la serrure
Imaginez que vous distribuiez à tous vos correspondants un cadenas ouvert, dont vous seul possédez la clé. N'importe qui peut fermer le cadenas. Vous seul pouvez l'ouvrir.
La cryptographie asymétrique fonctionne exactement sur ce principe, en inversant un peu les rôles. Votre appareil génère une paire : une clé privée qui ne quitte jamais le matériel, et une clé publique qu'il transmet au site. Quand vous voulez vous connecter, le site vous envoie un défi aléatoire. Votre appareil le signe avec la clé privée. Le site vérifie la signature avec la clé publique qu'il détient.
Si la signature est valide, c'est que vous possédez bien la clé privée. Vous êtes authentifié. Sans que rien de secret n'ait transité sur le réseau.
Ce qui est stocké sur votre serveur, ce qui ne l'est jamais
Point crucial pour le dirigeant qui pense en termes de risque : votre base de données ne contient que des clés publiques. Des chaînes de caractères totalement inutiles à qui les dérobe.
Ce qui n'est jamais stocké chez vous : la clé privée, bien sûr, mais aussi et surtout la donnée biométrique. L'empreinte digitale ou le visage de votre client ne quittent jamais son téléphone. Ils servent uniquement à déverrouiller localement la clé privée. Vous ne les voyez pas, vous ne les recevez pas, vous ne les hébergez pas.
Cette précision vaut de l'or quand votre DPO commence à s'inquiéter. Nous y reviendrons.
WebAuthn, FIDO2, CTAP : à quoi correspondent les sigles que votre prestataire va employer
Votre interlocuteur technique va employer ces trois acronymes, souvent dans la même phrase, parfois de manière un peu approximative. Voici la traduction.
WebAuthn est l'interface de programmation que votre navigateur expose au site web. C'est la partie visible, celle que votre développeur intègre.
CTAP gère le dialogue entre le navigateur et l'authentificateur, qu'il s'agisse d'une puce dans votre ordinateur ou d'une clé USB branchée.
FIDO2, c'est simplement le nom du parapluie qui recouvre les deux. Un standard porté par l'Alliance FIDO, un consortium qui rassemble à peu près tout le monde dans l'industrie.
Si un prestataire vous propose une solution « propriétaire » qui ne s'appuie sur aucun de ces standards, la discussion peut s'arrêter là. Vous seriez enfermé pour dix ans.
Passkey synchronisée vs passkey liée à l'appareil : la distinction qui décide de tout le reste
Deux familles cohabitent, et le choix entre elles structure tout votre projet.
La passkey synchronisée se réplique dans le cloud du fournisseur : trousseau iCloud, gestionnaire Google, Windows Hello via un compte Microsoft. L'utilisateur change de téléphone, sa passkey le suit. Expérience fluide, perte d'appareil beaucoup moins dramatique, adoption grand public bien meilleure.
La passkey liée à l'appareil, elle, ne bouge jamais. Elle vit dans la puce sécurisée du matériel ou dans une clé physique. Sécurité maximale, aucune dépendance à un cloud tiers. Mais si l'appareil disparaît, la passkey disparaît avec.
Pour un site e-commerce grand public, la synchronisée s'impose sans discussion. Pour un accès administrateur à votre infrastructure de production, la seconde reste largement préférable. La plupart des projets sérieux mélangent les deux selon la population concernée. Un prestataire qui ne vous pose pas cette question dès le premier atelier ne connaît pas suffisamment le sujet.
Les bénéfices concrets, chiffres et cas d'usage à l'appui
Phishing : la seule protection structurelle, et pourquoi la MFA par SMS ne l'est pas
Le phishing reste le premier vecteur de compromission en entreprise, année après année, rapport après rapport. Et la plupart des dispositifs censés le contrer ne font que ralentir l'attaquant.
Prenez la double authentification par SMS. Un employé reçoit un mail imitant le portail de l'entreprise. Il saisit son mot de passe sur le faux site. Le site pirate le rejoue immédiatement sur le vrai portail, qui déclenche l'envoi du code. L'employé, en confiance, recopie le code sur le faux site. L'attaquant le récupère et entre. Toute l'opération prend quinze secondes et fonctionne sur des dizaines de milliers de personnes chaque jour.
Avec une passkey, ce scénario est structurellement impossible. Pourquoi ? Parce que la clé est liée cryptographiquement au nom de domaine. Sur votre-banque-securite.com au lieu de votre-banque.fr, l'appareil ne propose rien. Il ne trouve aucune clé correspondante. Il n'y a rien à recopier, rien à transmettre, rien à intercepter.
La protection ne repose pas sur la vigilance de l'utilisateur. Elle repose sur la mathématique. C'est là toute la différence, et elle est immense.
Taux de conversion et abandon de panier : ce que gagne un tunnel sans mot de passe
Changeons d'angle, parce que la sécurité ne finance pas toujours un projet. La conversion, si.
Sur un tunnel d'achat classique, la création de compte est un point de fuite documenté depuis quinze ans. L'utilisateur doit inventer un mot de passe, respecter des règles de complexité absurdes, parfois confirmer son adresse mail avant de continuer. Chaque étape supprime des acheteurs.
Avec une passkey, l'inscription tient en un geste biométrique. Une pression sur le lecteur d'empreinte, et le compte existe. Les entreprises qui ont publié leurs chiffres après un déploiement font état de gains de connexion réussie très substantiels, avec des temps d'authentification divisés par trois ou quatre selon les parcours.
Attention toutefois : ces chiffres proviennent d'acteurs qui ont travaillé leur interface au millimètre et communiquent sur leurs succès. Sur un site moyen, avec une base clients hétérogène et un budget UX limité, les résultats seront plus modestes. Espérez une amélioration réelle, pas un miracle.
Coût caché du support : les tickets « mot de passe oublié » et leur volume réel
Voilà l'argument que les directions financières entendent le mieux, et curieusement celui que les prestataires oublient le plus souvent de mettre en avant.
Ouvrez votre outil de ticketing. Filtrez sur les demandes de réinitialisation. Le volume surprend presque toujours. Dans une PME de deux cents personnes, ce poste représente couramment plusieurs dizaines d'interventions par mois, avec un coût unitaire qui grimpe vite dès qu'un technicien doit vérifier l'identité du demandeur au téléphone.
Ajoutez-y le temps perdu par le collaborateur bloqué. Puis, côté client, les paniers abandonnés parce que le mot de passe ne revenait pas et que le mail de réinitialisation tardait.
Ce calcul-là, personne ne le fait spontanément. Faites-le avant votre premier rendez-vous prestataire. Il changera votre position dans la négociation.
Credential stuffing, bases de données compromises, réutilisation de mots de passe : les risques qui disparaissent
La réutilisation des mots de passe est une plaie que quinze ans de sensibilisation n'ont pas refermée. Vos clients emploient le même mot de passe chez vous et sur le forum piraté en 2019. Vos salariés aussi, malgré la charte informatique qu'ils ont signée.
Le credential stuffing exploite mécaniquement cette réalité : des robots rejouent des millions de couples identifiant/mot de passe volés ailleurs, jusqu'à ce que ça passe. Le taux de succès est faible, à peine quelques dixièmes de pourcent. Sur dix millions de tentatives, ça fait quand même beaucoup de comptes.
Une passkey rend l'exercice sans objet. Il n'y a pas de secret réutilisable. Chaque clé est unique à un site donné, générée localement, jamais partagée. La réutilisation devient techniquement impossible, pas simplement déconseillée.
Les limites que peu de prestataires évoquent spontanément
Le parc utilisateur : navigateurs anciens, terminaux professionnels verrouillés, postes partagés
Le discours commercial dira que « tout le monde est compatible ». Vérifiez.
Vos statistiques d'audience contiennent la réponse. Selon votre secteur, la part de navigateurs incompatibles varie énormément. Un site destiné aux professionnels de santé, aux collectivités ou à certaines industries traîne des postes verrouillés par une DSI prudente, avec des versions figées depuis longtemps. Un site grand public urbain aura un parc bien plus récent.
Autre écueil, plus sournois : les postes partagés. Un accueil, un atelier, une caisse. Trois personnes se relaient sur le même ordinateur. À qui appartient la passkey enregistrée dessus ? La question n'a pas de réponse élégante, et elle bloque plus de déploiements qu'on ne l'imagine.
Le scénario de la perte d'appareil et la question du compte de secours
Un client perd son téléphone. Que se passe-t-il ?
Avec une passkey synchronisée, pas grand-chose : il se connecte à son nouvel appareil avec son compte Apple ou Google, la passkey redescend, il continue sa vie. C'est le scénario confortable.
Avec une passkey liée à l'appareil, c'est autre chose. Il faut un mécanisme de récupération. Et ce mécanisme devient immédiatement le maillon faible de votre dispositif. Si la récupération passe par un lien envoyé par mail, vous avez reconstruit une porte dérobée exactement aussi vulnérable au phishing que le mot de passe que vous veniez de supprimer.
Un prestataire compétent vous fera passer une bonne partie de l'atelier de cadrage sur cette seule question. S'il l'expédie en cinq minutes, méfiance.
L'enfermement dans un écosystème (iCloud, Google Password Manager) et la portabilité réelle
Sujet inconfortable, souvent contourné.
Quand un utilisateur crée une passkey sur iPhone, elle se range dans le trousseau iCloud. S'il passe ensuite à Android, la migration n'est pas encore le geste trivial qu'on aimerait. Des travaux sont en cours du côté de l'Alliance FIDO pour normaliser l'export, avec des avancées réelles, mais l'expérience utilisateur reste perfectible à ce jour.
Conséquence pratique : vous devez conserver au moins un chemin de connexion alternatif pendant longtemps. Beaucoup plus longtemps que ce que le calendrier commercial de votre prestataire ne le suggère.
Le cas des comptes partagés en entreprise, angle mort du modèle
Le compte Instagram de l'entreprise. L'accès au logiciel de facturation partagé entre deux comptables. La boîte contact@ que trois personnes consultent.
Ces comptes existent partout, et ils sont philosophiquement incompatibles avec le modèle des passkeys, qui lie une identité à un appareil personnel. Les gestionnaires de mots de passe d'entreprise commencent à proposer du partage de passkeys, avec des résultats inégaux selon les éditeurs.
La vraie réponse n'est pas technique, elle est organisationnelle : arrêter les comptes partagés, passer à des accès nominatifs avec délégation de droits. Sauf que ça, c'est un chantier en soi, avec ses résistances internes. Autant le savoir avant de s'engager.
Qui fait quoi : la cartographie des prestataires du marché
L'éditeur de votre CMS ou de votre plateforme e-commerce
Première question à poser, avant tout appel d'offres : que fait déjà mon socle ?
Sur WordPress, des extensions traitent le sujet avec une qualité variable, et il faut regarder de près le sérieux du mainteneur avant de confier l'authentification de sa base clients à un plugin. Du côté des plateformes SaaS, plusieurs acteurs majeurs proposent désormais le passwordless nativement, sans développement de votre part.
Si votre socle couvre déjà le besoin, votre projet se réduit à du paramétrage et de la conduite du changement. Le budget n'a plus rien à voir. Vérifiez ce point en premier, ça évite de payer une intégration pour une fonctionnalité déjà incluse dans votre abonnement.
Le fournisseur d'identité (CIAM) : Auth0, Okta, Keycloak, Ory, solutions souveraines
C'est ici que se joue l'essentiel des projets d'envergure. Un fournisseur d'identité gère l'authentification à votre place : votre application lui délègue la vérification et récupère une identité confirmée.
Le marché se scinde en deux familles. D'un côté les plateformes commerciales, Auth0 ou Okta en tête, facturées à l'utilisateur actif mensuel, avec un temps de mise en œuvre court et une documentation excellente. De l'autre les briques open source, Keycloak ou Ory, gratuites en licence mais qui exigent une compétence d'exploitation réelle en interne ou chez votre infogéreur.
Le calcul entre les deux dépend moins de votre budget que de vos volumes. Une plateforme commerciale reste économique jusqu'à un certain seuil d'utilisateurs actifs, au-delà duquel la facture mensuelle dépasse largement le coût d'exploitation d'une solution auto-hébergée. Faites la simulation sur trois ans, pas sur la première année.
Notons au passage l'existence d'alternatives européennes, qui répondent à des exigences de souveraineté de plus en plus fréquentes dans les marchés publics et le secteur santé.
L'agence web ou l'ESN qui intègre
Elle branche les tuyaux. Elle modifie vos parcours d'inscription et de connexion, gère la coexistence entre l'ancien et le nouveau système, adapte votre design.
Compétence indispensable, mais gardez en tête ce que l'agence ne fait généralement pas : la stratégie d'identité, la politique de récupération de compte, l'arbitrage entre les types de passkeys. Ces décisions vous appartiennent, éventuellement conseillé par un architecte spécialisé. Une agence web qui prend seule ces décisions à votre place sort de son domaine de compétence.
L'infogéreur et l'administrateur Microsoft 365 / Google Workspace
Pour tout le volet interne, c'est lui votre interlocuteur. Et bonne nouvelle : les suites bureautiques que vous payez déjà intègrent le nécessaire.
Microsoft Entra ID permet une authentification sans mot de passe complète pour vos collaborateurs, y compris via Windows Hello et les clés physiques. Google Workspace propose l'équivalent. Dans les deux cas, la fonctionnalité est disponible selon votre niveau de licence, souvent sans surcoût.
Un déploiement interne bien mené sur une PME de cinquante à cent postes se compte en jours de prestation, pas en mois. C'est de très loin le meilleur rapport résultat/investissement de tout ce dossier. Commencez par là.
Le prestataire cybersécurité et l'auditeur : où il intervient, où il n'intervient pas
Le pentester vérifie que votre implémentation ne comporte pas de faille exploitable, en particulier sur ce fameux parcours de récupération. Le consultant en gouvernance vérifie la cohérence avec votre politique de sécurité et vos obligations réglementaires.
Ni l'un ni l'autre n'intègre. Ne leur demandez pas de développer, ce n'est pas leur métier et ce serait un mauvais achat.
En revanche, un audit après déploiement représente une dépense modérée pour une garantie sérieuse. Sur un projet critique, ne faites pas l'impasse.
Le cas particulier des solutions clés en main déjà compatibles (Shopify, Stripe, Salesforce…)
Certaines plateformes ont pris de l'avance et proposent le passwordless en standard. Si votre activité repose sur l'une d'elles, votre chantier se limite à activer, tester et communiquer auprès de vos utilisateurs.
Cas de figure fréquent, souvent ignoré, et qui peut vous économiser un projet entier. Un après-midi de vérification dans la documentation de vos outils actuels, avant de lancer quoi que ce soit. Ça vaut vraiment le détour.
Combien ça coûte, vraiment
Les trois modèles de facturation : licence par utilisateur actif, forfait d'intégration, régie
Trois logiques, et elles ne se comparent pas directement.
La licence à l'utilisateur actif mensuel concerne les plateformes CIAM. Elle est prévisible, mais grimpe avec votre succès. Lisez attentivement la définition contractuelle d'un « utilisateur actif » : selon les éditeurs, un client qui se connecte une fois dans le mois compte autant qu'un utilisateur quotidien, ce qui change radicalement la facture d'un site saisonnier.
Le forfait d'intégration couvre les travaux de votre agence. Périmètre fermé, prix ferme. Exigez le détail des livrables, sinon la reprise du parcours de récupération de compte sortira du forfait au pire moment.
La régie facture des jours-hommes. Souple, adaptée aux projets flous, mais dérive vite sans pilotage. À réserver aux phases d'exploration.
Ordres de grandeur selon la taille du projet et le socle technique existant
Trois situations types, avec les réserves d'usage : ces fourchettes varient selon votre région, la maturité de votre système et l'appétit commercial de votre prestataire.
Activation d'une fonctionnalité existante sur une plateforme SaaS compatible : quelques jours de prestation, essentiellement du paramétrage, des tests et de la communication utilisateur. Quelques milliers d'euros.
Intégration sur un site avec un fournisseur d'identité : le chantier classique. Comptez plusieurs semaines de travail selon la complexité de vos parcours, auxquelles s'ajoute l'abonnement mensuel. Le budget se situe généralement dans une fourchette à cinq chiffres.
Refonte complète d'un système d'identité sur un applicatif ancien, avec migration d'une base clients importante : là, on parle d'un projet à part entière qui s'étale sur plusieurs mois et mobilise plusieurs profils.
Le volet interne, lui, reste beaucoup plus abordable. C'est l'anomalie heureuse de ce dossier.
Le poste que tout le monde sous-estime : la migration des comptes existants et l'accompagnement au changement
Créer un parcours passkey pour les nouveaux inscrits : simple. Faire adopter la passkey à quarante mille comptes existants : c'est un tout autre métier.
Il faut concevoir des invitations qui ne ressemblent pas à du phishing, ce qui n'est pas une mince affaire quand on demande à quelqu'un de cliquer sur un lien pour changer sa méthode de connexion. Prévoir des relances. Traiter les cas particuliers. Former le support, qui va recevoir des appels de personnes perdues devant une demande d'empreinte digitale inattendue.
Ce poste représente régulièrement un tiers du budget réel du projet. Il n'apparaît presque jamais dans les devis initiaux. Demandez-le explicitement, ligne par ligne.
Ce que vous économisez en face, et sur quel horizon
Trois postes d'économie, avec des horizons très différents.
Le support baisse dès les premiers mois, proportionnellement au taux d'adoption. Effet mesurable rapidement, et facile à documenter dans votre outil de ticketing.
La conversion s'améliore progressivement, à mesure que la part de vos utilisateurs équipés grandit. Effet plus lent, plus difficile à isoler d'autres facteurs.
Le risque évité, enfin. Impossible à chiffrer honnêtement, puisqu'il s'agit d'un incident qui n'a pas eu lieu. Mais quand vous mettez en regard le coût moyen d'une compromission de compte administrateur et le budget d'un déploiement passkey sur vos vingt comptes sensibles, l'arbitrage devient assez évident.
Choisir son prestataire : la grille de sélection
Les questions techniques à poser, et les réponses qui doivent vous alerter
Cinq questions suffisent à distinguer un prestataire expérimenté d'un opportuniste.
Comment gérez-vous la perte d'appareil ? Une réponse floue, ou un simple « on envoie un mail de récupération », signale une réflexion superficielle.
Quelle proportion de mon parc utilisateur sera incompatible, et qu'est-ce qu'on leur propose ? Un prestataire qui répond « aucun problème, tout le monde est compatible » n'a pas regardé vos statistiques.
Recommandez-vous des passkeys synchronisées ou liées à l'appareil, et pourquoi ? S'il ne connaît pas la distinction, arrêtez l'entretien.
Comment mesure-t-on l'adoption ? Sans instrumentation, pas de pilotage possible.
Que se passe-t-il si nous voulons changer de fournisseur d'identité dans trois ans ? La réponse doit être précise et écrite.
Vérifier une référence : demander à voir un parcours d'inscription en production
Une maquette ne prouve rien. Demandez une URL réelle, un site en ligne, et créez un compte vous-même depuis votre propre téléphone.
Vous verrez immédiatement ce qu'une présentation commerciale ne montre jamais : le nombre de clics réels, la clarté des messages système, le comportement quand la biométrie échoue, la lisibilité du repli proposé.
Si le prestataire ne peut montrer aucune réalisation en production, vous serez son terrain d'apprentissage. Ce n'est pas rédhibitoire, mais négociez le prix en conséquence.
Réversibilité, propriété des données d'identité, clause de sortie
Votre base d'identités constitue un actif stratégique. Le contrat doit prévoir son export dans un format documenté et exploitable, à tout moment, sans facturation dissuasive.
Vérifiez aussi les délais de préavis et les conditions de résiliation. Certains contrats CIAM comportent des engagements pluriannuels qui deviennent inconfortables quand vos volumes évoluent différemment de ce qui était prévu.
Hébergement, RGPD, données biométriques : ce qui relève de la conformité et ce qui n'en relève pas
Reprenons ce point, parce qu'il génère beaucoup d'inquiétude inutile.
Vous ne traitez aucune donnée biométrique. L'empreinte reste sur l'appareil de l'utilisateur, sous le contrôle du système d'exploitation. Vous n'en recevez rien. Votre analyse d'impact n'a donc pas à traiter la biométrie comme une donnée sensible que vous collecteriez, et c'est une bonne nouvelle pour votre DPO.
Ce qui relève effectivement de votre responsabilité : les identifiants de clés que vous stockez, les métadonnées de connexion, les journaux. Données personnelles classiques, avec les obligations habituelles de durée de conservation et de localisation.
Sur l'hébergement, la question de la localisation européenne se pose comme pour tout traitement. Certains marchés, notamment publics, l'imposent formellement.
Signaux d'alerte : le prestataire qui promet la suppression totale des mots de passe dès la phase 1
Celui-là, fuyez.
Aucun déploiement sérieux ne supprime les mots de passe la première année. La coexistence est la règle, pas l'exception. Vous garderez un chemin alternatif pour les utilisateurs sur matériel incompatible, pour les cas de récupération, pour les scénarios que personne n'avait anticipés.
Un prestataire qui promet le grand soir dès le premier trimestre, soit ne l'a jamais fait, soit vous vend ce que vous voulez entendre. Dans les deux cas, ça finit mal.
Le déroulé d'un projet de déploiement réaliste
Phase 1 : audit du parc, des parcours et des dépendances techniques
Deux à quatre semaines, selon la complexité de votre système.
On analyse la répartition réelle de vos navigateurs et terminaux. On cartographie tous les points d'entrée de votre application, y compris ceux que plus personne ne documente : l'API mobile, le portail partenaires, l'ancienne interface que trois clients historiques utilisent encore.
C'est ici qu'on découvre les surprises. Toujours. Le module de connexion développé sur mesure en 2017 par un prestataire disparu depuis. La synchronisation avec l'ERP qui repose sur un mot de passe technique en clair dans un fichier de configuration.
Cette phase paraît coûteuse pour ce qu'elle produit. Elle évite les mauvaises surprises qui coûtent dix fois plus cher en phase de réalisation.
Phase 2 : passkey en option, en coexistence avec l'existant
La passkey apparaît comme une possibilité supplémentaire, jamais comme une obligation. Le mot de passe continue de fonctionner exactement comme avant.
Objectif de cette phase : valider techniquement en conditions réelles, sur des utilisateurs volontaires, sans risquer de bloquer qui que ce soit. Une population pilote bien choisie, quelques centaines de personnes, vous apprendra plus que six mois d'atelier.
Phase 3 : incitation progressive et mesure de l'adoption
La passkey devient l'option mise en avant. On propose sa création après une connexion réussie, au moment où l'utilisateur est déjà authentifié et détendu.
Le placement de cette proposition fait toute la différence. Trop tôt dans le parcours, elle est perçue comme un obstacle. Trop discrète, personne ne la voit. C'est un travail d'itération, pas de conception initiale, et il faut prévoir le budget de ces ajustements.
Phase 4 : bascule des populations sensibles (admins, direction, comptabilité)
Pour ces comptes-là, la passkey devient obligatoire.
Population restreinte, enjeu maximal, accompagnement individuel possible. C'est paradoxalement la phase la plus simple à exécuter, et celle qui apporte le plus de sécurité réelle. Certaines organisations la font passer en premier, avant même le volet client. Approche parfaitement défendable.
Les indicateurs à suivre mois par mois
Quatre chiffres suffisent à piloter, à condition de les regarder vraiment.
Le taux d'utilisateurs disposant d'au moins une passkey. La part des connexions effectuées par passkey, qui est l'indicateur d'usage réel. Le volume de tickets de réinitialisation, qui doit décroître. Le taux d'échec du parcours de création, qui révèle les frictions d'interface.
Un tableau de bord mensuel, une revue trimestrielle. Pas besoin de plus.
Le volet interne : sécuriser les comptes d'entreprise
Commencer par les comptes à privilèges plutôt que par tout le monde
Si vous ne deviez retenir qu'une recommandation de tout cet article, ce serait celle-ci.
Vos comptes administrateur, votre direction, votre comptabilité. Dix, vingt, cinquante personnes selon votre taille. Ce sont exactement les comptes que les attaquants visent, et exactement ceux dont la compromission fait le plus de dégâts.
Quelques jours de travail. Un coût dérisoire au regard du reste. Un bénéfice immédiat et mesurable. Pourquoi commencer par un chantier de six mois sur cinquante mille clients quand cette action-là est disponible tout de suite ?
Clés physiques (YubiKey et équivalents) : quand elles restent indispensables
Pour les accès les plus critiques, la clé matérielle garde toute sa pertinence. Elle ne dépend d'aucun cloud, ne se synchronise nulle part, ne se copie pas.
Comptez le prix d'une clé sérieuse, et surtout prévoyez-en deux par personne : une principale, une de secours rangée dans un coffre. Perdre son unique clé un vendredi soir, c'est une expérience dont on se souvient longtemps.
Le sur-mesure a du bon : réservez ce dispositif aux administrateurs d'infrastructure, aux accès bancaires et aux fonctions de direction. Pas besoin d'équiper tout le monde.
Onboarding et offboarding : ce qui change dans vos procédures RH
À l'arrivée, l'enrôlement de la passkey s'ajoute à la remise du matériel. Geste simple, mais qui doit figurer dans la procédure écrite, sinon il sera oublié une fois sur trois.
Au départ, c'est plus subtil. Révoquer la passkey côté annuaire suffit à couper l'accès, mais la clé reste présente sur l'appareil personnel de l'ancien collaborateur si vous avez autorisé le BYOD. Inoffensive, mais votre procédure doit le mentionner explicitement, ne serait-ce que pour rassurer lors du prochain audit.
Et les clés physiques doivent être restituées. Ajoutez-les à la liste du matériel, à côté du badge et de l'ordinateur portable.
Le gestionnaire de mots de passe ne disparaît pas pour autant
Contre-intuitif, mais net : vous en aurez encore besoin.
Tous vos outils ne supporteront pas les passkeys. Le vieux logiciel métier, le portail fournisseur, l'extranet du transporteur. Ces accès continueront de vivre sur des mots de passe pendant des années.
Le gestionnaire reste donc en place, avec un périmètre qui se réduit progressivement. Certains éditeurs proposent d'ailleurs de stocker les passkeys aussi, ce qui offre l'avantage d'une gestion unifiée et l'inconvénient d'une dépendance supplémentaire. Arbitrage à faire selon votre culture interne.
Ce que vous pouvez internaliser, ce qu'il faut confier
Les compétences réellement nécessaires en interne
Vous n'avez pas besoin d'un cryptographe. Vous avez besoin de quelqu'un qui comprend suffisamment le sujet pour piloter le prestataire et arbitrer.
Concrètement : saisir la différence entre les deux types de passkeys, savoir lire un taux d'adoption, poser les bonnes questions sur la récupération de compte. Un responsable informatique curieux acquiert ce niveau en quelques semaines de lecture.
Ce qui ne s'improvise pas, en revanche, c'est l'exploitation d'une brique open source auto-hébergée. Là, il faut une vraie compétence, disponible et pérenne.
Le piège de l'implémentation maison
Un développeur talentueux peut coder une implémentation WebAuthn. La documentation est publique, les bibliothèques existent.
C'est précisément ce qui rend le piège dangereux.
Le standard évolue. Les navigateurs changent de comportement à chaque version majeure. Les cas limites, les erreurs de vérification d'attestation, les subtilités de gestion des identifiants d'utilisateur : autant de détails qui séparent une implémentation qui fonctionne d'une implémentation qui résiste.
Et le jour où ce développeur quitte l'entreprise, plus personne ne maintient le cœur de votre authentification. C'est un risque disproportionné pour une économie qui, au final, se révèle modeste. Passez par une bibliothèque éprouvée ou un fournisseur d'identité. Vraiment.
Maintenir dans la durée : mises à jour du standard, évolutions des navigateurs
Un déploiement passkey n'est pas un projet qui se termine. Il faut suivre les évolutions du standard, tester à chaque version majeure de navigateur, adapter aux nouveaux comportements des systèmes d'exploitation.
Prévoyez un contrat de maintenance qui couvre explicitement cette veille. Quelques jours par an suffisent, mais ils doivent être contractualisés, sinon ils ne seront jamais faits.
Questions fréquentes des dirigeants
Faut-il attendre encore un an ou deux ?
Pour le volet interne, non. La technologie est mûre, vos outils la supportent déjà, le coût est faible. Attendre n'apporte rien.
Pour le volet client, la réponse dépend de votre secteur. Si vos concurrents proposent déjà une connexion sans mot de passe, l'écart d'expérience se voit. Si votre base clients est âgée ou peu équipée, un peu de patience se défend.
Mais faites au moins l'audit maintenant. Il vous dira si vous êtes déjà compatible sans le savoir, ce qui arrive plus souvent qu'on ne le croit.
Mes clients vont-ils comprendre et adopter ?
Ils utilisent déjà le mécanisme sans le nommer. Déverrouiller son téléphone avec son visage, valider un paiement avec son empreinte : c'est exactement le même geste.
La difficulté n'est pas dans l'usage, elle est dans la transition. Le moment où l'on demande à quelqu'un de changer une habitude établie. D'où l'importance d'un message clair, sans jargon, et d'une possibilité de refuser sans conséquence.
Parlez de « connexion par empreinte » ou de « connexion sans mot de passe ». Le mot « passkey » ne dit rien à personne en dehors du secteur.
Que dit mon assureur cyber, que demande mon donneur d'ordre grand compte ?
Les questionnaires d'assurance cyber se sont considérablement durcis. L'authentification forte sur les comptes à privilèges y figure désormais systématiquement, et les niveaux d'exigence montent d'année en année.
Du côté des donneurs d'ordre, les clauses de sécurité dans les contrats fournisseurs deviennent précises. Certains secteurs, la santé et la défense en tête, imposent déjà des exigences d'authentification résistante au phishing.
Sortez votre dernier questionnaire d'assurance et relisez la section authentification. Vous saurez tout de suite où vous en êtes, et si le sujet est urgent ou pas.
Et si mon prestataire actuel me dit que ce n'est pas prioritaire ?
Deux explications possibles, et il faut savoir laquelle s'applique.
Soit il a raison. Votre parc n'est pas prêt, vos priorités sont ailleurs, le rapport coût/bénéfice ne penche pas encore. Un bon prestataire dit non quand c'est justifié, et c'est plutôt bon signe.
Soit il ne sait pas faire et préfère ne pas l'avouer.
Comment trancher ? Demandez-lui un argumentaire écrit. S'il vous explique précisément pourquoi, avec des chiffres tirés de votre propre contexte, faites-lui confiance. S'il reste vague et change de sujet, allez chercher un deuxième avis.
Conclusion : arbitrer entre urgence réelle et effet de mode
Les passkeys ne relèvent pas du gadget. La technologie est solide, adossée à un standard ouvert, portée par tous les acteurs majeurs. Elle règle un problème réel, celui du phishing, que rien d'autre n'avait résolu structurellement en vingt ans.
Mais elle ne justifie pas de tout arrêter pour s'y consacrer.
La démarche raisonnable tient en trois mouvements. D'abord, sécuriser vos comptes à privilèges en interne : action rapide, peu coûteuse, bénéfice immédiat. Ensuite, vérifier si votre plateforme le propose déjà nativement, ce qui vous éviterait peut-être un projet entier. Enfin seulement, envisager le déploiement côté clients, en fonction de votre secteur, de votre parc et de la pression de vos partenaires.
Quant au prestataire, retenez la distinction essentielle : votre infogéreur pour l'interne, votre agence ou un fournisseur d'identité pour le client. Deux mondes séparés, deux budgets, deux calendriers. Les mélanger dans un même dossier, c'est la meilleure façon de ne rien faire avancer.
Le mot de passe ne disparaîtra pas cette année. Ni la suivante. Mais il n'est plus la seule option, et cette liberté nouvelle mérite qu'on s'y intéresse sérieusement, sans précipitation ni fascination.
