Majuscule, minuscule, chiffre, caractère spécial… la formation a bien fonctionné, les collaborateurs savent construire un mot de passe robuste. Reste à leur apprendre l’étape suivante, plus déroutante : ne plus utiliser de mot de passe.
Un sujet sans propriétaire
Sur le terrain, la prise de conscience porte moins sur le mot de passe en lui-même que sur le hameçonnage, ce qui n’est pas tout à fait la même chose. C’est le constat de Sébastien Lonjon, fondateur d’Abbeal, cabinet qui place des ingénieurs au sein des systèmes d’information de ses clients en France, au Québec et au Japon : du MFA a été déployé un peu partout, les RSSI ayant compris depuis trois ans que le facteur d’authentification est la porte d’entrée numéro un. Le passwordless, lui, figure sur les feuilles de route 2027 ou 2028 chez les plus avancés. Ailleurs, il reste à l’état d’intention.
La lenteur n’est pas budgétaire, précise-t-il, elle tient à une absence de propriétaire : l’authentification est répartie entre l’infrastructure qui tient l’annuaire, les équipes applicatives qui gèrent chacune leur bout et le support qui ramasse à la fin. Personne n’en porte le budget ni les indicateurs. Un sujet sans propriétaire ne devient pas un projet, il devient une ligne de risque reconduite chaque année en comité, dont tout le monde convient qu’il faudra bien s’occuper un jour.
Il faut aussi se souvenir d’où vient le mot de passe : personne ne l’a choisi. C’est ce qui reste quand 200 applications ont chacune décidé dans leur coin, pendant 20 ans. On ne le supprime pas d’un coup, résume Lonjon, « on le dissout et ça prend le temps que ça prend ». Ce que confirme, avec un vocabulaire différent, Cyril Polac, directeur France chez NordVPN : la résistance au changement sur ce terrain est humaine avant d’être technique. 30 ans que l’on répète le même discours aux utilisateurs ; la technologie a beau être prête, expliquer que taper un mot de passe n’est plus nécessaire ne suffit pas à convaincre que la sécurité, elle, n’a pas disparu avec le geste. Les chiffres donnent raison à cette lecture : en décembre 2021, seuls 2,6 % des utilisateurs de Twitter avaient volontairement activé l’authentification à deux facteurs, alors qu’elle était disponible et gratuite.
Ce qui déclenche vraiment le passage à l’action
Ce qui déclenche réellement le passage à l’action, dans l’ordre de fréquence observé par Abbeal, n’est d’ailleurs presque jamais la conformité. Un incident, le sien ou celui d’un concurrent direct, débloque en trois semaines des budgets qu’aucune analyse de risque n’avait débloqués en trois ans. Une exigence imposée par un grand compte à ses fournisseurs peut aligner 200 PME en 18 mois, plus efficacement que n’importe quelle communication institutionnelle. Le renouvellement d’une assurance cyber ou un audit transforme un questionnaire d’assureur en cahier des charges de sécurité de fait. La réglementation – NIS 2 ou Dora en première position – crée le budget sans créer l’urgence : elle donne une date, pas une peur.
Le déclencheur, souligne Sébastien Lonjon, détermine ensuite le périmètre du projet et une bonne partie des échecs vient de là. Un incident produit un projet rapide et étroit, centré sur les administrateurs et les accès à privilèges. Une exigence client produit un projet large et lent, parce qu’il faut embarquer tout le monde. Lancer un périmètre large dans l’urgence d’un incident est la combinaison qui fait le plus mal : l’organisation se plante après avoir dépensé.
Ce qui résiste au phishing et ce qui n’est qu’un vernis
Le terme passwordless recouvre en réalité deux définitions bien distinctes, et la confusion entre les deux fausse une bonne partie des arbitrages. Dans le premier cas, un utilisateur s’authentifie via son empreinte digitale ou par reconnaissance faciale à Windows Hello ou équivalent : il n’a techniquement pas saisi de mot de passe mais il existe toujours un secret stocké côté serveur, que la biométrie protège localement. Si cette couche échoue, comme cela est arrivé à Windows Hello lors d’une mise à jour en octobre 2022, le mot de passe revient en solution de secours. Dans le second cas, celui du FIDO2, l’authentification ne partage aucun secret avec le service : une paire de clés publique et privée est générée à l’inscription, la clé privée reste dans un coffre matériel sur l’appareil, seule la clé publique voyage. Même en cas de violation côté serveur, il n’y a rien à voler.
C’est cette distinction, plus que le nom commercial passkey, qui doit trier les usages en entreprise. Sébastien Lonjon range les méthodes selon un seul critère qui explique presque tout : la résistance au phishing.
D’un côté, les mécanismes liés cryptographiquement au domaine, qu’un site imitateur ne peut donc pas obtenir : les passkeys et le FIDO2 au sens strict, les clés de sécurité physiques type YubiKey, qui offrent le niveau d’assurance le plus élevé et restent le seul modèle vraiment défendable pour les comptes à privilège et les certificats sur carte à puce, dont le secteur public, la santé et la défense ne se sont d’ailleurs jamais séparés. Avec le recul, ils ont eu raison.
De l’autre côté, ce qui ne résiste pas au phishing sans pour autant être inutile : le TOTP, ces codes à six chiffres qu’un attaquant peut intercepter et relayer en temps réel ; la notification push, vulnérable à ce que l’on appelle la fatigue de validation – quand l’utilisateur finit par valider une demande pour avoir la paix, une technique documentée dans le piratage d’Uber en septembre 2022, où l’attaquant a bombardé le téléphone d’un prestataire de demandes d’authentification avant de se faire passer, avec succès, pour le support technique afin d’obtenir une validation – ; l’OTP par SMS, exposé au détournement de carte SIM ; le lien magique par e-mail, qui ne fait au fond que déménager le mot de passe dans la boîte e-mail, dont la sécurité devient celle de tout le compte.
Un identifiant qu’on ne peut jamais retirer
Deux cas sont régulièrement classés à tort dans cette liste. La biométrie d’abord, qui n’est pas un facteur transmis. Une empreinte ne circule pas sur le réseau, elle déverrouille localement une clé qui, elle, reste sur l’appareil. Le SSO ensuite, qui n’est pas une méthode d’authentification mais une réduction du nombre d’authentifications : il ne rend rien plus sûr en soi, il concentre le risque sur un point unique. Un SSO adossé à un mot de passe reste un mot de passe, il est simplement désormais capable d’ouvrir 40 applications au lieu d’une.
systèmes d’information de la DGFiP et
P-DG de Libralis © DR
Cette logique de révocabilité n’est pas propre à l’entreprise. Alain Issarni, ancien directeur des systèmes d’information de la DGFiP puis de la Cnam, la formule à propos de l’identité numérique en général mais l’argument transpose intégralement : un identifiant statique, comme la photocopie d’une carte d’identité, ne peut jamais être retiré de la circulation une fois qu’il a fuité, quand bien même le document d’origine resterait valable. « Vous ne pouvez pas dire : cette carte d’identité, j’ai décidé de la supprimer », résume-t-il. À l’inverse, un système fondé sur des fournisseurs distincts ou sur une clé qui ne quitte jamais l’appareil peut être neutralisé sans emporter tout le reste : il suffit d’arrêter d’utiliser le maillon compromis. C’est exactement la logique que l’on retrouve dans l’architecture FIDO2, où une clé privée qui ne circule jamais ne peut pas fuiter de la même manière qu’un mot de passe partagé.
Trois couches qui bloquent
Sur le terrain, ce qui bloque un déploiement n’est presque jamais l’infrastructure d’authentification proprement dite : les fournisseurs d’identité modernes gèrent le FIDO2 nativement, ce n’est plus un sujet. Le blocage se loge dans trois couches, de la plus facile à la plus pénible à traiter, détaille Sébastien Lonjon. En premier, le legacy applicatif : tout ce qui ne parle ni OIDC ni SAML, clients lourds, applications liées directement à l’annuaire, écrans mainframe, superviseurs industriels… Prise une par une, aucune de ces situations n’est insurmontable ; c’est le nombre de cas particuliers qui fait le coût, pas leur difficulté. Vient ensuite le référentiel d’identité lui-même, qu’on découvre toujours trop tard : un annuaire vieux de 15 ans a accumulé des comptes orphelins, des comptes de service dotés de droits interactifs, des comptes génériques que plus personne ne sait rattacher à une personne physique, etc. « Beaucoup de projets passwordless sont en réalité des projets de nettoyage d’annuaire qui n’osent pas dire leur nom », note Lonjon et c’est là que part le premier tiers du budget. Reste le compte partagé, dont personne ne parle et qui constitue pourtant le vrai mur : une passkey est liée à une personne et, partout où un poste est partagé (un atelier, un accueil, un plateau d’appels avec des équipes qui tournent), le modèle ne tient plus. Il faut alors réinventer l’usage, pas seulement l’authentification.
L’âge du parc, pas la taille de l’entreprise
Cyril Polac observe le même phénomène depuis une autre fenêtre, celle des entreprises qui équipent leurs collaborateurs : plus une organisation est ancienne, plus elle porte de mots de passe et de VPN hérités, des dispositifs qui tournent depuis 15 ou 20 ans sans jamais avoir été repensés, et c’est cette dette technique, plus que la taille de l’entreprise, qui détermine la difficulté du chantier. Une conclusion que rejoint Lonjon en des termes presque identiques : ce n’est pas la taille de l’entreprise qui compte, c’est l’âge de son parc applicatif. Une société de 200 employés créée en 2015, entièrement en SaaS, peut basculer en un trimestre. Un cabinet de 40 personnes assis sur un logiciel métier de 2006 n’y arrivera pas cette année, quel que soit son budget. Paradoxalement, le grand groupe dispose d’un avantage : il a déjà un fournisseur d’identité, une équipe identité et un processus d’arrivée des collaborateurs sur lequel greffer l’enrôlement. La structure intermédiaire, elle, doit construire cette capacité en même temps qu’elle mène la migration, ce qui en fait le segment le plus difficile, indépendamment de toute question de maturité ou de culture.
Pour cadrer le projet, mieux vaut ignorer l’inventaire applicatif officiel, qui décrit ce qui a été déclaré un jour et non ce qui est réellement utilisé, et partir des journaux d’authentification du fournisseur d’identité, de l’annuaire et du proxy. Trois semaines de collecte suffisent à obtenir une photographie honnête, qui diverge systématiquement de l’inventaire déclaré. Les applications se répartissent alors en quatre paniers : celles déjà fédérées en OIDC ou SAML, où le FIDO2 est presque gratuit ; celles fédérables moyennant du travail applicatif ; celles qu’on peut encapsuler derrière un proxy d’authentification sans toucher au code et l’irréductible, où l’on gardera un mot de passe mais dans un coffre, sur un périmètre isolé et surveillé. Le point qui change vraiment la conduite du projet consiste ensuite à mesurer la population plutôt que les applications : la bonne question n’est pas quel pourcentage du parc applicatif est compatible mais quelle proportion des utilisateurs n’a besoin, dans une journée normale, que d’applications du premier panier. C’est en général 60 voire 70 % des effectifs, et c’est là que se trouve la phase 1, celle qui produit un résultat visible en un trimestre et finance la suite.
Le jour de la coupure
Reste la question de la coupure elle-même, sans doute le point le plus sensible de tout le dossier : tant que le mot de passe fonctionne encore en solution de repli, l’attaquant utilise le repli. Ajouter une passkey sans fermer l’ancien chemin ne fait quasiment rien gagner sur le phishing, le gain arrive le jour de la coupure, pas le jour du déploiement. Or, c’est précisément le moment que les organisations repoussent, parce que couper fait mal et que personne ne veut être celui qui bloque 300 personnes un lundi matin. D’où la nécessité, dès le cadrage, d’une date de coupure par population et de quelqu’un mandaté pour la tenir.
Le parcours de récupération de compte constitue le second point sensible et le plus sous-estimé : on a beau poser une porte blindée, si le support peut la rouvrir par téléphone sur simple demande, l’attaquant appelle le support. Ce n’est pas théorique, c’est exactement par ce biais – l’ingénierie sociale sur un centre d’assistance – que plusieurs compromissions majeures de ces dernières années sont entrées, à l’image du cas Uber cité plus haut. La règle qui en découle est simple à énoncer et coûteuse à appliquer : l’enrôlement et la récupération doivent être au moins aussi solides que l’authentification qu’on déploie, avec un enrôlement en présentiel ou via un facteur déjà fort, des facteurs de secours dès le premier jour et une réinitialisation qui exige une vérification renforcée.
Ce changement de nature se retrouve au support, où le volume de tickets baisse pendant que leur complexité grimpe. La réinitialisation de mot de passe pèse couramment entre 20 et 40 % des tickets de premier niveau : ce volume disparaît, remplacé par des cas plus longs à traiter (téléphone perdu, passkey qui refuse de se synchroniser entre un appareil personnel et un poste professionnel, biométrie dégradée, utilisateur bloqué à l’étranger), chacun exigeant une vérification d’identité qui ne se scripte pas comme une réinitialisation. Cyril Polac décrit le même basculement depuis le poste support : le ticket type passe de « j’ai oublié mon mot de passe » à « mon capteur biométrique ne fonctionne plus » ou « je n’arrive pas à synchroniser ma clé », la perte d’un appareil étant le scénario le plus redouté. Un cas mérite d’être traité en amont plutôt que découvert en cours de crise : celui du collaborateur qui refuse d’utiliser son téléphone personnel pour authentifier ses accès professionnels. Une position légitime, fréquente et parfois juridiquement fondée. Sans réponse à lui apporter, en pratique, le déploiement s’arrête sur ce refus et il s’arrêtera devant les représentants du personnel plutôt que devant la DSI.
Le trousseau, nouvelle dépendance
Ce point de blocage humain rejoint, en creux, une question de dépendance plus large. Le protocole n’est pas le problème : WebAuthn est un standard ouvert du W3C, implémenté par tous les grands acteurs, y compris européens. La dépendance se loge dans le trousseau, c’est-à-dire l’endroit où les clés sont stockées et synchronisées. Si les passkeys des collaborateurs vivent dans un trousseau iCloud ou dans un gestionnaire Google, la récupération de compte, la portabilité et la capacité à révoquer dépendent d’un compte personnel que l’entreprise n’administre pas. Le problème est d’abord opérationnel avant d’être politique : le jour où un collaborateur quitte l’entreprise en mauvais termes, les clés d’accès au système d’information se trouvent dans un compte qui lui appartient. Cyril Polac formule une inquiétude comparable à propos des grands fournisseurs américains : jusqu’ici, la dépendance portait sur un identifiant que l’entreprise contrôlait, même mal, quand les mots de passe finissaient sur un post-it ; avec les passkeys d’écosystème, elle porte sur un trousseau détenu par un tiers.
La sortie existe et n’a rien d’exotique : passkeys liées à l’appareil, clés physiques ou trousseau d’entreprise hébergé en interne. On garde le standard, on change celui qui tient le trousseau. Le tout a un coût – soit entre 25 et 70 euros par personne pour une clé physique – plus la logistique de distribution et de remplacement alors que la passkey d’écosystème est gratuite et déjà installée : c’est un arbitrage économique, rarement posé comme tel devant un comité. Dans les faits, personne de sérieux ne retient un modèle unique : passkeys d’écosystème pour la population générale – un risque acceptable et documentable – et clés liées à l’appareil pour les administrateurs et les accès à privilèges, sans discussion. Côté fournisseurs d’identité, l’alternative européenne existe et elle est solide, notamment portée par Keycloak et les acteurs français qui l’hébergent. Côté trousseau grand public, en revanche, l’offre européenne reste faible, un manque qu’il vaut mieux nommer que maquiller.
Un dernier constat, venu du bureau d’Abbeal à Tokyo, mérite de clore ce dossier. Le Japon a déployé très tôt une identité numérique nationale adossée à des certificats, avec authentification par carte à puce sans contact : sur ce terrain, la nation est en avance. Dans le même pays, la même année, une partie des intégrations entre logiciels de gestion d’entreprise fonctionne pourtant encore en stockant l’identifiant et le mot de passe de l’utilisateur pour se connecter à sa place à un service tiers, sans jeton, sans expiration, un mot de passe en clair chez un tiers, dans des produits professionnels vendus à des entreprises aujourd’hui. Le niveau d’authentification réel d’une organisation n’est donc pas fixé par ses standards mais par ses pratiques d’intégration. Une entreprise française peut très bien déployer des passkeys sur le poste de travail et laisser, juste derrière, des connecteurs interapplicatifs qui rejouent des identifiants stockés. Ce point aveugle n’apparaît sur aucun tableau de bord de sécurité, ce qui n’en fait pas un détail.
Charlotte Rabatel
