La fin de partie du mot de passe
Le mot de passe est un secret partagé entre un humain, un navigateur, une base de données et — trop souvent — un attaquant. Cette architecture est structurellement indéfendable : 81 % des intrusions vérifiées passent encore par des credentials volés ou faibles (rapport Verizon DBIR), et les bases `haveibeenpwned` dépassent désormais 14 milliards de comptes. Aucune politique de complexité, aucune rotation, aucun gestionnaire de mots de passe ne change cette équation fondamentale.
La seule propriété qui tienne en 2026 est la résistance au phishing par conception. Un secret qui ne quitte jamais l'appareil authentifié, qui est lié cryptographiquement à un domaine précis, et qui ne peut être rejoué sur un site imiteur ne peut pas être volé par un faux email de connexion. C'est exactement ce que spécifie FIDO2 / WebAuthn (W3C Recommendation, RTS PSD2 pour le paiement en Europe).
Le standard est enfin mature. Apple, Google et Microsoft ont aligné leurs plateformes sur WebAuthn Level 3 depuis 2023, les passkeys synchronisés entre appareils sont en production depuis iOS 16.4, macOS 13.5, Android 14 et Windows 11 22H2. La courbe d'adoption suit : plus de 12 milliards de comptes exposent une option passkey côté Google, Microsoft et Apple au second semestre 2024. Pour une PME française en 2026, la question n'est plus « est-ce prêt ? » mais « combien de temps encore accepte-t-on le mot de passe ? ».
NIS2 (transposée en droit français pour octobre 2024) et le futur eIDAS 2 renforcent l'obligation de moyens. Pour les entités essentielles et importantes, l'authentification forte résistante au phishing n'est plus une bonne pratique : c'est une exigence réglementaire auditable. Le statu quo n'est plus une option défendable.
Passkeys en production : device-bound vs synchronisés
Un passkey est une paire de clés cryptographiques. La clé privée est stockée dans un authenticateur (TPM, Secure Enclave, carte à puce FIPS 140), la clé publique est enregistrée auprès du fournisseur de service (RP — Relying Party). L'authentification produit une signature sur un challenge incluant l'origine exacte (`rp.id`), ce qui rend l'attaque par phishing structurellement impossible.
Deux familles cohabitent. Les passkeys synchronisés (Apple iCloud Keychain, Google Password Manager, Microsoft account, gestionnaires tiers comme 1Password ou Dashlane) offrent une expérience sans couture entre les appareils personnels de l'utilisateur. Les passkeys `device-bound` (clés résidant dans un module matériel non exportable : YubiKey, Titan, carte à puce) offrent un niveau d'assurance plus élevé (souvent AAL3 selon NIST 800-63B) au prix d'une récupération manuelle.
Côté UX, la promesse se tient : Face ID sur iOS/macOS, Touch ID sur Mac, Windows Hello sur PC, empreinte digitale sur Android. L'authentification devient un geste, pas une saisie. Les taux de réussite de login dépassent 90 % sur les déploiements internes mesurés par Apple et Google, contre 60-70 % pour un flux mot de passe + TOTP.
La récupération reste le point dur. Une organisation doit décider explicitement de sa stratégie : réenregistrement assisté via un appareil toujours connecté (Apple, Google), authentificateur de secours administré (YubiKey de backup stocké en coffre), mécanisme de réactivation via help-desk avec preuve d'identé forte. Ce volet — et non la cryptographie — est ce qui détermine la réussite d'un déploiement passkeys en entreprise. Prévoyez un runbook dédié, des métriques de couverture et un exercice semestriel de récupération.
Zero Trust applicatif : ne jamais faire confiance au réseau
Zero Trust n'est pas un produit. C'est un principe d'architecture : aucune requête n'est jamais considérée comme légitime parce qu'elle provient « de l'intérieur ». Chaque appel d'API, chaque lecture de données, chaque ouverture de session doit être authentifié, autorisé et inspecté — indépendamment du réseau d'origine. Le VPN devient progressivement obsolète comme périmètre de confiance ; il reste utile comme canal chiffré, pas comme garantie d'identité.
Au niveau applicatif, cela se traduit par des sessions courtes : access token JWT de 5 à 15 minutes maximum, signature asymétrique (RS256, ES256, EdDSA), revendications minimales (`sub`, `iss`, `aud`, `exp`, `iat`, `scope`) et rotation du refresh token à chaque usage (refresh token rotation avec réutilisation détectée). Côté stockage, le jeton d'accès reste en mémoire (ou cookie `httpOnly` + `secure` + `sameSite=lax`), jamais en `localStorage`.
Le `session binding` renforce encore : un device fingerprint cryptographique est émis à l'authentification et inclus dans les jetons suivants via DPoP (Demonstrating Proof-of-Possession, RFC 9449) ou mTLS. Un token volé devient inutilisable hors de l'appareil d'origine. Pour les opérations sensibles (changement de MFA, accès administrateur, virement), une ré-authentification step-up est demandée via une seconde invocation WebAuthn.
La détection d'anomalies complète le dispositif. Connexions depuis un nouvel ASN, vélocité anormale, échecs répétés sur un identifiant, géolocalisation impossible (distance Paris-Singapour en 30 minutes) : chaque signal alimente un moteur de risque qui déclenche un challenge additionnel, une notification à l'utilisateur ou un blocage temporaire. Des outils comme Auth0 Anomaly Detection, Cloudflare WAF, WorkOS Risk Score ou Supabase Auth hooks permettent d'industrialiser ces règles sans réinventer un SIEM.
MFA fatigue : le cas Uber et l'après push-bombing
Septembre 2022, Uber : un attaquant obtient le mot de passe d'un employé (acheté sur le dark web), puis déclenche un déluge de notifications MFA push. Épuisé, l'employé finit par accepter l'une d'elles. L'attaquant pénètre l'infrastructure, accède à des secrets stockés dans un fichier PowerShell, compromet GCP, AWS, SentinelOne, Duo, Slack. Coût réel : 148 millions de dollars d'impact déclaré, mise sous contrôle réglementaire pendant deux ans, responsables individuellement poursuivis.
Cette attaque — dite `push-bombing` ou MFA fatigue — fonctionne parce que le second facteur push n'est pas phishing-resistant et n'implique aucune preuve de contexte. Les correctifs sont aujourd'hui standards. Le `number matching` impose à l'utilisateur de saisir un code affiché à l'écran sur son téléphone : sans cette action active, le push n'est jamais validé. Microsoft Entra ID l'a activé par défaut depuis 2023, Duo et Okta suivent.
La hiérarchie des facteurs est claire. Résistants au phishing : FIDO2 / WebAuthn (passkeys, clés matérielles), puis — dans une moindre mesure — les notifications avec `number matching` et `phishing-resistant` contextuels. Non résistants mais acceptables : TOTP (Google Authenticator, Authy, 2FAS). À déprécier dès que possible : SMS et voix (SIM swap, interception SS7, coût, UX dégradée, non-conformité PSD2 pour les paiements forts).
Le risque étant par nature adaptatif, l'authentification doit l'être aussi. Risk-based authentication (RBA) : un appareil reconnu accède via passkey seul ; un nouvel appareil doit passer un step-up ; une connexion improbable déclenche un challenge explicite. NIS2, la directive européenne, encourage explicitement cette approche contextuelle. Côté produit, cela se traduit par moins de frottement pour l'utilisateur légitime et plus de frictions pour l'attaquant — exactement l'inverse du MFA push classique.
SSO comme socle : l'IdP est le nouveau périmètre
Dans un environnement B2B moderne, un employé accède à 80 à 130 applications SaaS en moyenne (enquête Productivité 2024). La prolifération des comptes locaux — chacun avec son mot de passe, son MFA, son processus de départ — est devenue ingérable et dangereuse. Le SSO (Single Sign-On) n'est plus une fonctionnalité premium : c'est l'architecture de référence, avec l'Identity Provider (IdP) comme nouveau périmètre de sécurité.
Deux protocoles dominent. SAML 2.0 (OASIS 2005), encore omniprésent en entreprise : XML signé, `Assertion`, `Response`, binding HTTP-POST ou Redirect. Plus moderne, OpenID Connect (OIDC) repose sur JSON, JWT, des flux OAuth 2.1 standardisés (Authorization Code + PKCE obligatoire pour les SPA/mobile). Pour tout nouveau déploiement en 2026, OIDC est le défaut ; SAML reste l'interopérabilité minimale attendue côté clients enterprise.
Pour un SaaS B2B, exposer le SSO sur le tier entreprise n'est pas optionnel. Okta, Microsoft Entra ID (ex Azure AD), Google Workspace, JumpCloud, WorkOS et Auth0 sont les références côté IdP corporate. Côté SaaS, le pattern moderne est multi-tenant : chaque organisation cliente connecte son IdP, le fournisseur isole les identités via `tenant_id` + `org_id` dans les claims, et la résolution utilisateur se fait par mapping d'email ou d'attributs stables (`sub`, `employeeNumber`).
SCIM 2.0 (RFC 7643 et 7644) complète l'histoire. Il automatise le provisioning et le déprovisionning : une entrée dans l'annuaire client crée instantanément le compte SaaS, un départ (JIT ou manuel) le désactive. C'est le mécanisme qui évite les comptes orphelins — l'une des premières choses qu'un auditeur NIS2 ou ISO 27001 viendra vérifier. Un SaaS B2B sérieux en 2026 implémente SCIM en lecture et en écriture ; c'est la ligne de démarcation entre un outil professionnel et un outil grand public glissé dans l'entreprise.
La feuille de route 2026 d'une PME française
Trimestre 1 : déployer les passkeys pour les collaborateurs internes. Choix d'une plateforme (WorkOS, Auth0, Supabase Auth + WebAuthn, ou Cloudflare Access), activation des passkeys synchronisés côté Apple/Google/Microsoft en première vague, distribution d'une YubiKey de backup aux comptes sensibles (administrateurs, finance, sécurité). Objectif mesurable : 90 % des connexions employés sans mot de passe à 90 jours.
Trimestres 2-3 : exposer le SSO SAML et OIDC pour les clients B2B. Industrialiser le multi-tenant, publier la documentation d'intégration (metadata XML, discovery OIDC, attributs attendus), recruter 3-5 clients pilotes sur Okta et Entra ID. Implémenter SCIM 2.0 en parallèle pour automatiser le lifecycle. C'est aussi le moment de mettre en place le `number matching` sur les notifications MFA restantes et de désactiver SMS sauf cas documentés.
Année 1 : déprécier progressivement le TOTP et le push classique. Le `passwordless-first` devient l'UX par défaut sur les nouvelles connexions. Mise en place d'un risk score applicatif, journalisation structurée des authentifications (user_id, device_id, ip, asn, geoloc, risk_score, mfa_method) envoyée vers le SIEM. Préparer la suppression du `password-only fallback` : un utilisateur sans passkey enregistré doit en créer un via un flux d'enrôlement, plus via un mot de passe de secours.
Mois 18 : retirer totalement l'option « connexion par mot de passe seul ». Le mot de passe survit uniquement comme facteur de secours dégradé, protégé par un MFA FIDO2 et un contrôle help-desk. À ce stade, la surface d'attaque par credential stuffing est réduite à néant, l'expérience utilisateur s'améliore (moins de support, connexions plus rapides), et l'entreprise est en conformité avec les attentes NIS2 pour les entités importantes. La communication interne et externe accompagne ce changement : c'est un projet produit, pas seulement un projet sécurité.
Le piège du statu quo
La première objection entendue en mission : « Nous n'avons pas encore subi d'incident. » C'est exactement la posture qui transforme une fuite de credentials en incident majeur. Le coût marginal d'un déploiement passkeys progressif (un trimestre d'effort concentré côté produit + IT) est dérisoire comparé au coût d'un incident type Uber : amendes NIS2 jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires, notification CNIL sous 72 heures, perte de confiance clients B2B souvent irréversible.
La deuxième objection : « Nos clients ne demandent pas le SSO. » Vrai aujourd'hui, faux dans 18 mois. Tout RSI d'une ETI française de plus de 200 collaborateurs a désormais une politique `no-SSO, no-purchase`. La maturité SSO des directions informatiques clients s'est densifiée depuis 2023 ; un SaaS qui n'offre pas SAML/OIDC perd des deals, surtout sur les marchés régulés (banque, santé, défense, industrie).
La troisième objection : « C'est trop tôt pour supprimer le mot de passe. » La réalité technique dit l'inverse : les passkeys sont supportés par 100 % des navigateurs modernes (Chrome, Safari, Firefox, Edge), par les trois écosystèmes mobiles dominants, et les IdP majeurs (Okta, Auth0, WorkOS, Supabase, Microsoft Entra) exposent des APIs stables. Le risque technique réel en 2026 n'est pas dans le standard, il est dans le runbook de récupération et dans la conduite du changement.
Chez VALRY LABS, nous recommandons systématiquement aux PME et ETI de traiter cette migration comme un projet produit à part entière : sponsor exécutif identifié, budget dédié, métriques publiées (taux de connexions passwordless, nombre de comptes sans facteur résistant au phishing, incidents évités), rétrospective trimestrielle. Traiter l'authentification comme une dette technique à rembourser lentement est l'erreur la plus coûteuse que nous voyons sur le terrain.