--- url: 'https://www.corbado.com/fr/blog/acces-badge-physique-passkeys-guide-technique' title: 'Accès par badge physique et Passkeys : Guide technique' description: 'Comment utiliser les badges physiques pour une authentification sans mot de passe en intégrant les badges des employés avec les passkeys. Une analyse approfondie des architectures pour un accès unifié.' lang: 'fr' author: 'Vincent Delitz' date: '2025-08-20T15:37:11.226Z' lastModified: '2026-03-25T10:05:30.425Z' keywords: 'badge physique, accès par badge, accès par carte, accès aux portes, badge RFID' category: 'Authentication' --- # Accès par badge physique et Passkeys : Guide technique ## 1. Introduction : La convergence de l'accès physique et numérique La sécurité moderne se définit par la disparition des anciennes frontières. Pendant des décennies, les organisations ont fonctionné avec une distinction claire entre la sécurité physique (gardiens, serrures et badges d'accès) et la cybersécurité ou sécurité logique (pare-feux, mots de passe et protocoles réseau). Ces deux domaines étaient gérés en silos distincts, avec des équipes, des politiques et des objectifs séparés. \_Aujourd'hui, cette séparation n'est plus viable. La prolifération des systèmes physiques connectés au réseau, des caméras de sécurité aux serrures de porte intelligentes en passant par les systèmes de CVC, a créé un environnement cyber-physique profondément interconnecté. Cette convergence signifie qu'une vulnérabilité dans un domaine peut entraîner une défaillance catastrophique dans l'autre. Une [cyberattaque](https://www.corbado.com/fr/glossary/cyberattaque) peut déverrouiller des portes physiques, et une carte d'accès volée peut mener à une intrusion dans une salle de serveurs. Par conséquent, une stratégie de sécurité globale et unifiée n'est plus une tendance avant-gardiste, mais une exigence fondamentale pour toute posture de sécurité robuste, stimulant d'importants investissements dans des plateformes unifiées. Cette nouvelle réalité représente un défi pour l'**authentification des employés**. Qu'ils soient au bureau, à distance ou en mode hybride, les employés ont besoin d'accéder à un [portefeuille](https://www.corbado.com/fr/blog/garantie-portefeuille-numerique) d'applications cloud et [SaaS](https://www.corbado.com/blog/saas-companies-integrate-passkeys) en pleine expansion. Ce modèle d'accès distribué crée une surface d'attaque vaste et complexe. Le couple traditionnel nom d'utilisateur/mot de passe, même renforcé par une [authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) multifacteur (MFA) héritée comme les codes SMS, reste le maillon faible — un vecteur principal pour le [phishing](https://www.corbado.com/glossary/phishing), le [credential stuffing](https://www.corbado.com/glossary/credential-stuffing) et les attaques par prise de contrôle de compte. En réponse, le secteur évolue vers une [authentification sans mot de passe](https://www.corbado.com/fr/faq/banques-passkeys) et résistante au [phishing](https://www.corbado.com/glossary/phishing). Les prévisions du marché estiment que le marché de l'[authentification sans mot de passe](https://www.corbado.com/fr/faq/banques-passkeys) passera de plus de 18 milliards de dollars en 2024 à plus de 60 milliards d'ici 2032, 87 % des entreprises ayant déjà déployé ou étant en train de déployer des passkeys pour leurs employés. Au milieu de cette évolution technologique se trouve un atout puissant et souvent négligé : le badge d'employé physique. Omniprésente dans presque toutes les moyennes et grandes organisations, cette simple carte est la clé pour débloquer un avenir numérique plus sécurisé et plus fluide. L'objectif central de cet article est de fournir une analyse neutre et profondément technique des modèles d'architecture disponibles pour intégrer ces badges physiques avec une [authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) basée sur les passkeys. Plus précisément, cette analyse se concentre sur les applications [SaaS](https://www.corbado.com/blog/saas-companies-integrate-passkeys) développées sur mesure dans un contexte professionnel, où la dépendance à un fournisseur d'identité (IdP) d'entreprise traditionnel et sur site n'est pas une certitude. Les sections suivantes décortiqueront trois approches distinctes pour cette intégration, en évaluant leurs composants techniques, leurs modèles de sécurité et les compromis essentiels entre eux. ## 2. Décomposition des technologies de base Avant de concevoir un système unifié, il est essentiel d'avoir une compréhension fine de ses composants fondamentaux. Les capacités du jeton physique et les mécanismes de l'identifiant numérique dictent les voies d'intégration possibles. Ne pas apprécier les différences nuancées entre un simple identifiant et un véritable authentifiant cryptographique peut conduire à des décisions architecturales erronées. ### 2.1 Le spectre des capacités des badges Les badges d'employés ne forment pas un bloc monolithique ; leur technologie sous-jacente couvre un large éventail de complexité et de sécurité. Comprendre où se situe un badge spécifique dans ce spectre est la première étape pour déterminer son rôle potentiel dans un système d'[authentification](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) moderne. Les tableaux suivants fournissent une ventilation détaillée de cette évolution. #### 2.1.1 Spectre d'évolution : Badges NFC et cartes à puce | Étape d'évolution | Type de technologie | Méthode d'interface | Capacité cryptographique | Compatibilité WebAuthn | Rôle dans l'authentification | Cas d'utilisation type | | ------------------------------- | ----------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------- | -------------------------- | ---------------------------------------------- | ----------------------------------------------------------- | | 1. Tags UID passifs | RFID basse fréquence / NFC de base | Sans contact (RF) | Aucune – UID statique uniquement | ❌ Non | Identifiant uniquement | Accès à une porte de bureau par correspondance d'UID | | 2. UID sécurisé (NFC renforcé) | NFC haute fréquence (MIFARE DESFire, iCLASS SE) | Sans contact (RF) | Chiffrement de base, protection de l'UID | ❌ Non | Identifiant avec résistance à la falsification | Transports publics, PACS sécurisé | | 3. Cartes à puce (non FIDO) | JavaCard / PIV / CAC | Avec contact (ISO 7816) ou sans contact (ISO 14443) | Opérations cryptographiques (ex. RSA, ECC, AES) via applets PKCS#11 ou PIV | ❌ Non natif pour WebAuthn | Utilisé avec un middleware pour 2FA, PKI | Cartes d'identité gouvernementales, VPN d'entreprise | | 4. Cartes à puce FIDO2 | Cartes à puce compatibles FIDO2 (identifiant unifié) | Contact (USB-C, SmartCard), Sans contact (NFC) | Cryptographie asymétrique (paire de clés WebAuthn dans un élément sécurisé) | ✅ Oui | Authentifiant nomade | Connexion sans mot de passe aux applications web | | 5. Authentifiants de plateforme | Matériel sécurisé intégré (TPM, Secure Enclave) | Interne – API du navigateur/de l'appareil | Cryptographie asymétrique | ✅ Oui | Authentifiant de plateforme | macOS Touch ID, Windows Hello | | 6. Cartes hybrides | FIDO2 multiprotocole + PKI + NFC | Double interface : USB + NFC | Plusieurs conteneurs d'identifiants (FIDO2, PIV) | ✅ Oui | PKI et WebAuthn | Lieux de travail hautement sécurisés, secteur de la défense | | 7. Synchronisation des passkeys | Identifiants de plateforme synchronisés dans le cloud | Bluetooth, API de l'appareil local | Cryptographie asymétrique (gestion de la confiance symétrique) | ✅ Oui | Authentifiant de plateforme synchronisé | Apple Passkeys via iCloud, Google Password Manager | #### 2.1.2 Concepts clés de progression | Dimension | Premières cartes NFC/à puce | Cartes à puce modernes / dispositifs Passkey | | --------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------------- | | Rôle d'authentification | Identification uniquement | Authentification avec preuve cryptographique | | Modèle de sécurité | Identifiant statique (vulnérable au clonage/skimming) | Clé privée stockée de manière sécurisée, non exportable | | Modèle de confiance du dispositif | Le système doit faire confiance au lecteur d'UID | Le système vérifie la preuve cryptographique | | Conformité aux standards | Propriétaire ou hérité (ex. MIFARE Classic, PIV) | Standards ouverts (WebAuthn, FIDO2) | | Dépendance à l'infrastructure | PACS avec correspondance d'UID, potentiellement sans internet | Coordination du navigateur, de la RP et de l'authentifiant | | Complexité matérielle | Puce passive à faible coût, sans logique interne | Élément sécurisé, OS embarqué, coprocesseur cryptographique | #### 2.1.3 Modèles d'interaction par génération | Génération | Interaction par contact (Tap) | Insérée dans un lecteur | Biométrie requise | PIN requis | Middleware de l'OS nécessaire | Prêt pour WebAuthn | | ----------------------------------- | ----------------------------- | ----------------------- | ----------------- | ---------- | ----------------------------- | ------------------ | | Gen 1 (RFID/NFC) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | | Gen 2 (NFC sécurisé) | ✅ | ❌ | ❌ | Optionnel | Propriétaire | ❌ | | Gen 3 (JavaCard / PIV) | ❌ | ✅ | ❌ | ✅ | ✅ (PKCS#11, Windows CSP) | ❌ | | Gen 4 (Carte FIDO2) | ✅ | ✅ | Optionnel | Optionnel | ❌ | ✅ | | Gen 5 (Authentifiant de plateforme) | ❌ | ❌ | ✅ | Optionnel | Intégré | ✅ | #### 2.1.4 Implications stratégiques | Facteur | Badges NFC hérités | JavaCard / PIV | Cartes à puce FIDO2 | | ------------------------------------ | ------------------ | -------------------------------- | ------------------------------ | | Coût par unité | Faible (1–5 €) | Moyen (10–30 €) | Élevé (20–60 €) | | Intégration avec le SaaS | Médiocre | Dépendante d'un middleware | WebAuthn natif | | Prise en charge du sans mot de passe | ❌ | ❌ (sauf via un proxy) | ✅ | | Conformité aux standards | Faible | Conforme PIV/NIST | Conforme FIDO2/WebAuthn | | Risque de dépendance | Faible | Moyen (dépendance au middleware) | Faible (standard ouvert) | | Lecteur matériel requis | Lecteur RFID/NFC | Lecteur de carte à puce | Lecteur de carte à puce ou NFC | #### 2.1.5 Résumé du parcours d'évolution Les organisations qui passent de systèmes d'accès basés sur l'UID à des jetons d'authentification sécurisés suivent généralement ce parcours : 1. **Badge UID de base** → utilisé uniquement pour l'accès physique. 2. **Badge NFC sécurisé** → ajoute le chiffrement pour le contrôle d'accès, mais n'est toujours pas adapté à l'authentification numérique. 3. **Carte à puce PKI (PIV)** → ajoute l'accès basé sur un certificat numérique (VPN, e-mails signés), nécessite un middleware. 4. **Carte à puce FIDO2** → permet la connexion [sans mot de passe](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe) via WebAuthn, peut également se combiner avec des fonctions d'accès physique. 5. **Passkeys de plateforme** → une vision d'avenir où les jetons physiques deviennent facultatifs, mais la convergence est mieux servie lorsqu'un seul appareil gère à la fois l'accès physique et logique. Cette analyse détaillée clarifie la distinction entre un simple identifiant et un authentifiant cryptographique, qui est le concept le plus important de cette analyse. Un badge RFID de base ne peut fournir qu'un UID, qui peut au mieux servir d'indice de nom d'utilisateur pour _lancer_ un flux d'authentification. Il ne peut pas participer au défi-réponse cryptographique qui est au cœur de WebAuthn. Une [carte à puce FIDO2](https://www.corbado.com/fr/blog/meilleures-cartes-a-puce-fido2), à l'inverse, est conçue précisément à cet effet. C'est cette différence fondamentale qui donne naissance aux trois modèles architecturaux distincts qui suivent. Les options 1 et 2 sont essentiellement des solutions de contournement conçues pour s'adapter aux limitations des badges à identifiant unique, tandis que l'option 3 représente l'intégration native d'un véritable authentifiant. ## 3. Analyse approfondie de l'architecture : Trois voies d'intégration Avec une compréhension claire des technologies sous-jacentes, nous pouvons maintenant explorer les trois principaux modèles architecturaux pour intégrer les badges physiques à l'authentification par passkey pour une application [SaaS](https://www.corbado.com/blog/saas-companies-integrate-passkeys) destinée aux employés. Chaque voie présente un ensemble unique de compromis en matière de sécurité, de [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)ût, d'expérience utilisateur et de complexité. ### 3.1 Le coffre-fort centralisé (Le badge comme clé d'un passkey) Ce modèle est conceptuellement le plus abstrait. Le badge physique ne stocke pas de passkey lui-même. Au lieu de cela, il fonctionne comme un jeton à faible niveau d'assurance utilisé pour autoriser un service centralisé à effectuer une authentification à haut niveau d'assurance au nom de l'utilisateur. La clé privée du passkey n'est pas détenue par l'utilisateur, mais est stockée et gérée dans un module matériel de sécurité (HSM) [exploit](https://www.corbado.com/glossary/exploit)é par un fournisseur de "coffre-fort d'identifiants" (Credential Vault). #### 3.1.1 Flux architectural 1. **Action de l'utilisateur et identification :** Un employé passe son badge RFID/NFC standard sur un lecteur connecté à son poste de travail. Le lecteur capture l'UID statique du badge. 2. **Requête vers le coffre-fort :** Un composant côté client envoie l'UID à un point de terminaison d'API propriétaire hébergé par le fournisseur du coffre-fort d'identifiants. 3. **Lancement de WebAuthn côté serveur :** Le service du coffre-fort reçoit l'UID, recherche le compte utilisateur associé, puis lance une cérémonie d'[authentification WebAuthn](https://www.corbado.com/fr/blog/webauthn-mediation-immediate-expliquee) avec l'application SaaS cible (la [partie de confiance](https://www.corbado.com/fr/glossary/relying-party)) _au nom de l'utilisateur_. L'application SaaS renvoie un défi d'authentification standard. 4. **Signature basée sur le HSM :** Le service du coffre-fort transmet ce défi à son HSM interne. Le HSM stocke de manière sécurisée le composant de clé privée du passkey de l'utilisateur pour cette application SaaS spécifique. Le HSM effectue l'opération de signature cryptographique sur le défi et renvoie la signature résultante au service du coffre-fort. La clé privée ne quitte jamais le périmètre sécurisé du HSM. 5. **Finalisation de l'authentification et émission du jeton :** Le service du coffre-fort termine le flux WebAuthn en renvoyant le défi signé à l'application SaaS. L'application SaaS vérifie la signature à l'aide de la clé publique de l'utilisateur (qu'elle a en sa possession) et, en cas de succès, émet un jeton de session d'authentification (par exemple, un JSON Web Token). 6. **Livraison de la session :** Le service du coffre-fort transmet ce jeton de session au navigateur de l'utilisateur, qui peut alors l'utiliser pour établir une session authentifiée avec l'application SaaS, complétant ainsi la connexion. #### 3.1.2 Analyse - **Avantages :** - **Tire parti de l'infrastructure existante :** Le principal attrait de ce modèle est sa capacité à fonctionner avec les badges RFID/NFC les plus courants et les moins chers déjà déployés dans une organisation, évitant ainsi un renouvellement matériel [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)ûteux et perturbateur. - **Expérience utilisateur très fluide :** Il peut offrir une véritable connexion "tap-and-go". Du point de [vue](https://www.corbado.com/blog/vuejs-passkeys) de l'utilisateur, un simple contact du badge sur le lecteur le connecte directement à l'application, ce qui représente une friction extrêmement faible. - **Gestion centralisée :** Tous les identifiants passkey sont créés, stockés et gérés au sein de l'écosystème du fournisseur. Cela peut simplifier les tâches administratives comme la révocation et l'application des politiques. - **Inconvénients :** - **Système propriétaire et en boucle fermée :** Cette architecture transforme de fait le badge et le fournisseur de coffre-fort en un nouveau fournisseur d'identité (IdP) propriétaire. L'organisation devient profondément dépendante de ce seul fournisseur pour une fonction essentielle. De tels systèmes "en boucle fermée" sont intrinsèquement rigides et créent une forte dépendance vis-à-vis du fournisseur, rendant les migrations futures difficiles et [co](https://www.corbado.com/fr/blog/conformite-cybersecurite)ûteuses. - **Exigence de confiance extrême :** La sécurité de l'ensemble du système repose sur la fiabilité et la compétence du fournisseur de coffre-fort. Étant donné que les HSM du fournisseur détiennent les clés privées de tous les utilisateurs pour toutes les applications, une compromission du fournisseur serait catastrophique. - **Coût et complexité élevés :** Ce n'est pas une solution simple. Elle nécessite soit de construire, soit de souscrire à un service très complexe et critique qui inclut une infrastructure HSM coûteuse, des logiciels sophistiqués et des opérations à haute disponibilité. - **Écart par rapport aux principes de WebAuthn :** Ce modèle rompt fondamentalement avec le principe de base de WebAuthn, qui est l'authentification côté client, possédée par l'utilisateur. L'authentifiant est côté serveur, ce qui est un anti-modèle pour l'authentification web générale. Comme indiqué dans la requête initiale, cette approche n'est généralement pas recommandée pour s'authentifier auprès d'une application SaaS web standard. ### 3.2 Le pont de bureau (Le badge comme indice d'authentification) Ce modèle représente un compromis pragmatique. Il utilise le badge simple existant non pas pour s'authentifier, mais pour fluidifier et accélérer un flux WebAuthn standard. Un logiciel installé sur l'ordinateur de l'utilisateur agit comme un "pont" entre le lecteur de badge physique et le navigateur web. #### 3.2.1 Flux architectural 1. **Action de l'utilisateur et détection locale :** Un employé passe son badge RFID/NFC de base sur un lecteur USB standard connecté à son poste de travail. 2. **Agent d'écoute local :** Un service d'arrière-plan léger ou un daemon s'exécutant sur le système d'exploitation (par exemple, en utilisant l'API PC/SC) est à l'écoute des événements du lecteur de [carte à puce](https://www.corbado.com/fr/glossary/carte-a-puce). Il détecte le passage du badge et lit l'UID de la carte. 3. **Communication agent-extension :** Cet agent local communique l'UID capturé à une extension de navigateur compagnon. Ceci est généralement réalisé à l'aide de l'API Native Messaging Host du navigateur, qui permet à une extension en bac à sable d'échanger des messages avec une [application native](https://www.corbado.com/fr/blog/applications-natives-passkeys) pré-enregistrée. 4. **Pré-remplissage du nom d'utilisateur et lancement du flux :** L'extension de navigateur contient une logique pour mapper l'UID reçu à un nom d'utilisateur spécifique. À la réception de l'UID, elle injecte le nom d'utilisateur correspondant dans le formulaire de connexion de l'application SaaS. Les formulaires de connexion modernes peuvent également utiliser l'attribut `autocomplete="webauthn"` sur les champs de saisie pour signaler au navigateur qu'un flux passkey peut être initié pour l'utilisateur auto-rempli. L'extension peut alors déclencher par programmation le début du processus d'authentification par passkey. 5. **Cérémonie WebAuthn standard :** À partir de ce moment, une cérémonie d'[authentification WebAuthn](https://www.corbado.com/fr/blog/webauthn-mediation-immediate-expliquee) entièrement standard a lieu. Le navigateur invite l'utilisateur à utiliser son authentifiant passkey enregistré. Il peut s'agir de l'authentifiant de plateforme de l'ordinateur (par exemple, [Windows Hello](https://www.corbado.com/glossary/windows-hello), macOS Touch ID) ou d'un authentifiant nomade distinct (comme une [YubiKey](https://www.corbado.com/glossary/yubikey) ou même le téléphone de l'utilisateur). L'utilisateur effectue le geste d'authentification (par exemple, une analyse d'empreintes digitales), et la connexion est terminée selon le flux standard. Le rôle du badge est maintenant terminé. #### 3.2.2 Analyse - **Avantages :** - **Authentification conforme aux standards :** L'avantage le plus significatif est que l'authentification cryptographique réelle est un flux WebAuthn pur et sans modification. Le modèle de sécurité repose sur les principes éprouvés de [FIDO2](https://www.corbado.com/glossary/fido2), et non sur une solution de contournement propriétaire. Le passage du badge est purement une amélioration de l'expérience utilisateur. - **Tire parti du matériel existant :** Comme l'option 1, cette approche fonctionne avec le parc existant de badges RFID/NFC de base et de lecteurs USB peu coûteux. - **Expérience utilisateur améliorée :** Bien qu'il ne s'agisse pas d'une connexion en un seul geste, elle réduit considérablement la friction. L'utilisateur n'a pas à se souvenir et à taper son nom d'utilisateur, ce qui raccourcit le processus de connexion et réduit les risques d'erreur. - **Inconvénients :** - **Déploiement et maintenance des logiciels :** Le principal inconvénient est la charge opérationnelle. Cette architecture nécessite le déploiement, la configuration et la maintenance de deux logiciels distincts — un agent natif au niveau de l'OS et une extension de navigateur — sur _chaque poste de travail des employés_. Cela peut représenter un fardeau important pour les services informatiques, qui doivent gérer les mises à jour, résoudre les problèmes de compatibilité avec les différentes versions d'OS et de navigateurs, et s'occuper des correctifs de sécurité. - **Fragilité de l'architecture :** Le canal de communication entre le pilote matériel, l'agent natif et l'extension de navigateur est un pont développé sur mesure. Cette "colle" peut être fragile et susceptible de se rompre lorsque le système d'exploitation ou le navigateur publie des mises à jour, ce qui entraîne une expérience utilisateur médiocre et peu fiable. - **Solution incomplète :** Ce n'est pas une solution "tap-and-go". L'utilisateur doit toujours effectuer une deuxième action distincte pour finaliser l'authentification avec son passkey réel. Le passage du badge n'automatise que la première étape du processus de connexion. ### 3.3 L'identifiant unifié (Le badge comme authentifiant FIDO2) C'est l'architecture la plus directe, la plus sécurisée et la plus conforme aux standards. Dans ce modèle, le badge de l'employé est lui-même une [carte à puce](https://www.corbado.com/fr/glossary/carte-a-puce) compatible [FIDO2](https://www.corbado.com/glossary/fido2). C'est un véritable authentifiant cryptographique qui peut participer directement à la cérémonie WebAuthn sans aucun logiciel intermédiaire. #### 3.3.1 Flux architectural 1. **Navigation de l'utilisateur :** Un employé se rend sur la page de connexion de l'application SaaS. L'application est configurée pour prendre en charge l'authentification par passkey. 2. **Lancement de WebAuthn :** L'utilisateur clique sur un bouton "Se connecter avec un passkey", ou l'interface utilisateur conditionnelle (Conditional UI) du navigateur (remplissage automatique) détecte automatiquement les passkeys disponibles et les présente dans une invite non modale. Le JavaScript du navigateur appelle `navigator.credentials.get()` pour démarrer la cérémonie d'authentification. 3. **Interaction avec l'authentifiant :** Le navigateur, via le système d'exploitation, invite l'utilisateur à présenter sa clé de sécurité. L'employé passe son badge [FIDO2](https://www.corbado.com/glossary/fido2) sur un lecteur NFC intégré ou l'insère dans un lecteur de [carte à puce](https://www.corbado.com/fr/glossary/carte-a-puce) connecté. 4. **Signature cryptographique sur la carte :** Le navigateur envoie le défi de l'application SaaS au badge. L'élément sécurisé à l'intérieur du badge utilise sa clé privée stockée en interne et non exportable pour signer le défi. Selon la politique de la [partie de confiance](https://www.corbado.com/fr/glossary/relying-party) et les capacités de la carte, cette étape peut également nécessiter une vérification de l'utilisateur, comme la saisie d'un code PIN sur le poste de travail ou le placement d'un doigt sur un capteur biométrique intégré à la carte elle-même. 5. **Finalisation de l'authentification :** Le badge renvoie la réponse signée au navigateur, qui la transmet au serveur SaaS. Le serveur vérifie la signature, et l'utilisateur est connecté de manière sécurisée. L'ensemble du processus est orchestré par le navigateur et le système d'exploitation à l'aide de protocoles FIDO standardisés. #### 3.3.2 Analyse - **Avantages :** - **Sécurité et conformité aux standards les plus élevées :** C'est l'approche de référence ("gold standard") pour l'accès unifié. Elle utilise les standards FIDO2 et WebAuthn exactement comme ils ont été conçus, offrant la protection la plus forte possible contre le [phishing](https://www.corbado.com/glossary/phishing) et les attaques de l'homme du milieu. L'utilisateur est en possession physique du jeton matériel contenant sa clé privée. - **Simplicité et robustesse de l'architecture :** Ce modèle est élégant dans sa simplicité. Il n'y a pas d'agents personnalisés, d'extensions de navigateur ou de ponts propriétaires à développer et à maintenir. Le flux d'authentification repose sur les API et les pilotes très robustes et bien entretenus intégrés dans les systèmes d'exploitation et les navigateurs modernes. - **Véritable convergence de la sécurité :** Cette architecture tient la promesse d'un identifiant véritablement unifié. Un seul jeton physique gérable est utilisé pour accorder l'accès à la fois aux espaces physiques (portes) et aux ressources logiques (applications), simplifiant l'expérience utilisateur et le modèle de sécurité. - **Inconvénients :** - **Coût matériel important :** Le principal obstacle à cette approche est l'investissement initial. Elle nécessite de remplacer l'ensemble du parc de badges RFID/NFC de base d'une organisation par des cartes à puce compatibles FIDO2, plus coûteuses. Selon l'infrastructure existante, cela peut également nécessiter la mise à niveau des lecteurs de porte physiques pour qu'ils soient compatibles avec les nouvelles cartes. - **Gestion complexe du cycle de vie des identifiants :** Gérer le cycle de vie complet des identifiants cryptographiques pour un grand nombre d'employés est plus complexe que de gérer une simple liste d'UID. Les processus d'émission sécurisée, de rotation des clés, de renouvellement des certificats (si la PKI est également utilisée), et surtout de révocation et de récupération, deviennent plus critiques et complexes. - **Nuances de l'expérience utilisateur :** Bien que très sécurisée, l'expérience utilisateur peut introduire différents points de friction. Si la carte nécessite un code PIN pour la vérification de l'utilisateur, elle réintroduit un facteur "ce que vous savez" qui doit être mémorisé. L'action physique d'insérer une carte dans un lecteur peut être perçue comme moins fluide qu'un simple contact sans fil, selon le matériel spécifique déployé. La décision entre ces trois voies architecturales n'est pas simplement technique ; c'est une décision stratégique qui équilibre des priorités concurrentes. L'option 1 privilégie une expérience utilisateur transparente et l'utilisation du matériel existant, mais le fait en créant une dépendance propriétaire coûteuse et à haut risque qui s'écarte des standards ouverts. L'option 2 tire également parti du matériel existant et améliore l'expérience utilisateur tout en respectant les standards d'authentification, mais elle déplace le coût et la complexité vers le problème difficile et souvent sous-estimé de la gestion des logiciels sur chaque terminal. L'option 3 privilégie la sécurité, la robustesse et l'adhésion aux standards ouverts par-dessus tout, acceptant un coût matériel initial plus élevé en échange d'une architecture plus simple et plus pérenne avec une charge de maintenance à long terme plus faible. Il n'y a pas de choix universellement "correct" ; la voie optimale dépend de la tolérance au risque, du budget, de l'infrastructure existante et des capacités de support informatique spécifiques d'une organisation. ## 4. Un cadre comparatif pour la prise de décision en entreprise Choisir la bonne architecture nécessite une comparaison claire et directe de ces compromis. Cette section fournit un cadre pour distiller l'analyse complexe dans un format exploitable pour les responsables techniques et pour aborder les défis pratiques et concrets de la mise en œuvre. ### 4.1 Un cadre stratégique La voie optimale pour une organisation dépend de ses principaux moteurs business. - **Si votre principal moteur est de minimiser les dépenses d'investissement initiales et de tirer parti de votre parc de badges existant,** alors l'**Option 2 (Pont de bureau)** est le choix le plus pragmatique. Elle offre une amélioration tangible de l'expérience utilisateur et adopte un noyau d'authentification conforme aux standards sans nécessiter un investissement matériel important. Cependant, cette voie ne doit être choisie que si l'organisation dispose d'une capacité de gestion des terminaux mature et robuste, car le succès de ce modèle dépend de la capacité à déployer et à maintenir de manière fiable les logiciels côté client nécessaires. - **Si votre principal moteur est d'atteindre le plus haut niveau de sécurité, de s'aligner sur les meilleures pratiques du secteur et de construire une architecture pérenne et à faible maintenance,** alors l'**Option 3 (Identifiant unifié)** est le clair vainqueur sur le plan stratégique. Cette approche embrasse pleinement les standards ouverts, élimine les logiciels personnalisés fragiles et offre la protection la plus forte contre le phishing. Le coût matériel initial est un investissement dans la sécurité et la simplicité opérationnelle à long terme. - **Si votre principal moteur est d'offrir une expérience de connexion "magique", fluide et en un geste, par-dessus toute autre considération,** alors l'**Option 1 (Coffre-fort centralisé)** est la seule qui le fournisse vraiment. Cependant, cette voie doit être abordée avec une extrême prudence. Elle introduit un risque stratégique important par la dépendance vis-à-vis d'un fournisseur et exige un niveau de confiance exceptionnellement élevé dans l'architecture de sécurité et les opérations du fournisseur. Pour la plupart des applications web ouvertes et SaaS, la nature propriétaire et en boucle fermée de ce modèle en fait un choix moins souhaitable par rapport aux alternatives basées sur des standards. ### 4.2 Gestion du cycle de vie et intégration Une stratégie de passkeys réussie va bien au-delà du flux de connexion ; elle doit couvrir l'ensemble du cycle de vie de l'identité. Le choix de l'architecture a des implications profondes sur la manière dont les utilisateurs sont intégrés, comment l'accès est révoqué et comment les comptes sont récupérés. - **Attribution et intégration :** Pour un nouvel employé, le processus diffère considérablement. Dans les options 1 et 2, l'intégration implique l'émission d'un badge standard, puis la création d'une entrée dans une base de données qui mappe l'UID du badge au compte de l'utilisateur. Dans l'option 3, le processus est une cérémonie d'enregistrement FIDO2 formelle, où le nouveau badge compatible FIDO2 est utilisé pour générer un passkey qui est ensuite enregistré auprès de l'application SaaS. Ce processus est plus sécurisé mais aussi plus complexe à gérer à grande échelle. - **Révocation (départ d'un employé) :** Lorsqu'un employé quitte l'entreprise, son accès physique est toujours révoqué dans le système de contrôle d'accès physique (PACS) central. Pour l'accès logique, les étapes sont les suivantes : - **Option 1 :** Le fournisseur de coffre-fort doit être immédiatement averti pour désactiver ou supprimer l'identifiant stocké dans son HSM. - **Option 2 :** Le passkey réel de l'utilisateur (par exemple, celui stocké dans le TPM de son ordinateur portable via [Windows Hello](https://www.corbado.com/glossary/windows-hello)) doit être révoqué dans les paramètres de l'application SaaS. Le mappage de l'UID du badge devient sans objet une fois que le passkey sous-jacent est désactivé. - **Option 3 :** La clé publique associée au badge FIDO2 de l'employé doit être supprimée de son profil utilisateur dans l'application SaaS, rendant le badge inutilisable pour la connexion. - **Récupération (badge perdu ou volé) :** C'est un mode de défaillance critique qui doit être planifié. Les implications varient considérablement : - Dans les options 1 et 2, un badge perdu est moins critique pour l'accès logique, car il ne s'agit que d'un identifiant. Le risque principal est l'accès physique non autorisé. L'utilisateur peut toujours se connecter en utilisant son authentifiant passkey réel. - Dans l'**Option 3**, un badge perdu peut être un problème majeur. Si le badge FIDO2 est le _seul_ passkey enregistré pour le compte de l'utilisateur, celui-ci est complètement bloqué. Cela souligne une meilleure pratique essentielle pour tout déploiement de passkeys en entreprise : **il faut exiger ou fortement encourager les utilisateurs à enregistrer plusieurs authentifiants.** Une politique robuste imposerait qu'un employé enregistre à la fois son badge FIDO2 (comme authentifiant principal au quotidien) et une solution de secours, comme son authentifiant de plateforme (Windows Hello/[Face ID](https://www.corbado.com/faq/is-face-id-passkey)) ou son téléphone, à utiliser pour la [récupération de compte](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe). En fin de compte, un déploiement réussi de passkeys n'est pas seulement un projet d'authentification ; c'est un projet de gestion des identités et des accès (IAM). L'architecture technique du flux de connexion ne peut être conçue de manière isolée. Elle doit être étroitement intégrée à une stratégie complète de provisionnement, de gestion et de déprovisionnement des identités et de leurs identifiants associés tout au long de leur cycle de vie. Cette vision globale est essentielle pour atténuer les risques tels que le blocage de compte et assurer le succès et la sécurité à long terme du système. ## 5. Conclusion : L'avenir est unifié, standardisé et sans mot de passe Le parcours pour intégrer les badges d'accès physique avec l'authentification numérique moderne est une manifestation claire de deux tendances puissantes qui se croisent : la convergence de la sécurité physique et de la cybersécurité, et la migration inéluctable de l'ensemble du secteur pour abandonner les mots de passe. Comme ce guide l'a détaillé, les organisations ont le choix entre trois voies architecturales distinctes, chacune présentant un compromis fondamental. - Le **coffre-fort centralisé** offre une expérience utilisateur transparente au prix d'une dépendance propriétaire et d'un risque stratégique important. - Le **pont de bureau** offre une voie pragmatique et à faible coût vers une meilleure expérience utilisateur tout en maintenant les standards de sécurité, mais introduit une charge de maintenance logicielle considérable. - L'**identifiant unifié** offre le plus haut niveau de sécurité et de robustesse en adhérant strictement aux standards ouverts, mais nécessite un investissement matériel initial important. Bien que chaque voie représente un pas vers un avenir plus sécurisé et [sans mot de passe](https://www.corbado.com/fr/blog/comment-passer-totalement-sans-mot-de-passe), la trajectoire à long terme de la sécurité d'entreprise favorise les solutions basées sur des standards ouverts et interopérables. Les architectures qui adoptent nativement FIDO2 et WebAuthn — comme l'illustre le modèle de l'identifiant unifié et, dans une certaine mesure, le pont de bureau — fournissent la base la plus robuste et la plus pérenne. Elles permettent aux organisations de construire des systèmes de sécurité de premier ordre qui tirent parti d'un écosystème concurrentiel de matériel et de logiciels, libérés des contraintes de la plateforme en boucle fermée d'un seul fournisseur. Pour toute organisation qui construit la prochaine génération d'applications professionnelles, adopter ces standards ouverts n'est pas seulement un choix technique ; c'est un engagement stratégique en faveur d'un monde numérique plus sécurisé, plus flexible et plus interopérable.