--- url: 'https://www.corbado.com/fr/blog/webauthn-conditional-ui-remplissage-automatique-passkeys' title: 'Explication technique de la Conditional UI WebAuthn' description: 'La Conditional UI, ou remplissage automatique des clés d''accès, est une fonctionnalité des passkeys. Découvrez comment elle fonctionne et comment l''implémenter.' lang: 'fr' author: 'Vincent Delitz' date: '2026-07-03T07:10:52.023Z' lastModified: '2026-07-03T07:11:02.749Z' keywords: 'Conditional UI, passkeys, clés d''accès, WebAuthn, remplissage automatique, autofill, Conditional Mediation, authentification sans mot de passe' category: 'WebAuthn Know-How' --- # Explication technique de la Conditional UI WebAuthn ## Key Facts - Les **identifiants découvrables (clés résidentes)** sont requis pour la Conditional UI : les authentificateurs ne stockent pas de données spécifiques à l'utilisateur pour les clés non résidentes, ce qui rend le remplissage automatique impossible avec ces dernières. - **`isConditionalMediationAvailable()`** doit être appelé avant de démarrer tout flux de Conditional UI pour éviter les erreurs visibles par l'utilisateur sur les navigateurs ou appareils non pris en charge. - Le jeton **`autocomplete="username webauthn"`** sur un champ de saisie HTML signale au navigateur d'afficher les clés d'accès (passkeys) aux côtés des suggestions de mots de passe dans le menu déroulant de remplissage automatique. - Définir **`mediation: "conditional"`** dans l'appel `navigator.credentials.get()` active le remplissage automatique des clés d'accès sans interrompre les utilisateurs avec une boîte de dialogue modale bloquante. - Un **`AbortController`** est requis pour annuler les requêtes de Conditional UI en cours car les menus de remplissage automatique, contrairement aux invites modales, n'ont pas de bouton d'annulation intégré. ## 1. Introduction Avec l'adoption rapide des clés d'accès (et du protocole WebAuthn sous-jacent), l'authentification est devenue plus sécurisée et conviviale pour de nombreux utilisateurs. L'une des avancées marquantes des clés d'accès a été l'intégration de la Conditional UI, souvent appelée « remplissage automatique des clés d'accès » ou Conditional Mediation (dans la suite, nous conserverons le terme Conditional UI). Malgré son introduction récente et son adoption continue par les navigateurs, il y a un manque notable dans la documentation technique et les conseils d'implémentation pour la Conditional UI. Cet article vise à combler ce vide en expliquant ce qu'est la Conditional UI, comment elle fonctionne et comment résoudre les défis courants lors de son implémentation. ## 2. Qu'est-ce que la Conditional UI ? La Conditional UI représente un nouveau mode pour les processus de connexion par clés d'accès / WebAuthn. Elle affiche de manière sélective les clés d'accès dans une interface utilisateur (UI) uniquement lorsqu'un utilisateur possède un identifiant découvrable (clé résidente), qui est un type de clé d'accès, enregistré auprès de la partie utilisatrice (le service en ligne) et stocké dans l'authentificateur de son appareil (par ex. ordinateur portable, smartphone). Les clés d'accès sont affichées dans un menu déroulant de sélection mélangé aux mots de passe remplis automatiquement, offrant une transition fluide entre les systèmes de mots de passe traditionnels et l'authentification avancée par clés d'accès, car les utilisateurs voient les deux dans le même contexte. Cette approche intelligente garantit que les utilisateurs ne sont pas submergés d'options inutiles et peuvent naviguer dans le processus de connexion plus fluidement. La base de la Conditional UI repose sur trois piliers principaux : 1. **Respect de la vie privée des utilisateurs :** Garantir la vie privée des utilisateurs en empêchant la divulgation des identifiants disponibles ou le manque de consentement de l'utilisateur pour révéler ces identifiants. 2. **Excellente expérience utilisateur même si aucune clé d'accès n'existe :** Permettre aux parties utilisatrices d'implémenter WebAuthn de manière opportuniste, en s'assurant que l'expérience utilisateur reste bonne même si les clés d'accès ne sont pas disponibles. 3. **Transition fluide des mots de passe vers les clés d'accès :** Combiner les clés d'accès avec l'authentification par mot de passe pour adoucir la transition vers les méthodes d'authentification sans mot de passe, en capitalisant sur les paradigmes UX familiers des utilisateurs. ![WebAuthn passkey login conditional ui](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/Web_Authn_passkey_login_conditional_ui_8c8e7b0de5.png) ## 3. Avantages et inconvénients de la Conditional UI ### 3.1 Avantages - **Authentification simplifiée :** Le processus est plus rationalisé et efficace, supprimant les complexités souvent associées à de multiples méthodes d'authentification. - **Réduction des erreurs utilisateur :** En ne présentant que les options pertinentes, les utilisateurs sont moins susceptibles de faire des erreurs lors du processus d'authentification. - **Amélioration de la satisfaction utilisateur :** La suppression des étapes inutiles signifie que les utilisateurs peuvent se connecter plus rapidement et plus facilement, ce qui améliore leur satisfaction. - **Intégration frontend simple :** L'une des fonctionnalités phares de la Conditional UI est sa facilité d'intégration. Les développeurs peuvent l'incorporer de manière transparente dans le frontend avec quelques lignes de code (voir ci-dessous). - **Connexion sans mot de passe et sans nom d'utilisateur :** L'un des énormes avantages est que la Conditional UI promeut non seulement l'authentification sans mot de passe mais aussi une expérience sans nom d'utilisateur ou sans compte. Les utilisateurs sont épargnés de la charge mentale de se rappeler de leur adresse e-mail spécifique ou de leur pseudo d'utilisateur lors de l'inscription. À la place, ils peuvent s'appuyer sur les suggestions du navigateur, qui incluent l'adresse e-mail / le pseudo d'utilisateur associé à la clé d'accès appropriée dans le menu de remplissage automatique. - **Résolution du dilemme d'amorçage :** La transition des systèmes traditionnels nom d'utilisateur-mot de passe vers les clés d'accès peut être intimidante. La Conditional UI aborde ce défi de transition. Les sites web peuvent initier un appel clé d'accès / WebAuthn en même temps qu'une invite de mot de passe classique sans s'inquiéter des éventuelles erreurs de boîte de dialogue modale si un appareil manque des identifiants nécessaires. ### 3.2 Inconvénients - **Courbe d'apprentissage pour les développeurs :** La Conditional UI introduit un nouveau paradigme, ce qui signifie qu'il y a une courbe d'apprentissage impliquée pour les développeurs peu familiers avec ses subtilités. - **Dépendance à l'appareil / au navigateur :** Le succès de la Conditional UI repose sur la compatibilité de l'appareil ou du navigateur de l'utilisateur. Étant donné que tous les navigateurs ou appareils ne la prennent pas en charge actuellement, cela peut limiter son application. - **Les gestionnaires de mots de passe désactivent le remplissage automatique :** Certains gestionnaires de mots de passe modernes et leurs extensions de navigateur modifient le DOM du site web et désactivent ou remplacent la balise autocomplete dans les champs de saisie au profit de leurs propres fonctionnalités de remplissage automatique. Cela peut conduire à une expérience utilisateur incohérente et insatisfaisante. Comme les normes pour la Conditional UI sont relativement nouvelles, nous espérons que les choses s'amélioreront, afin que par ex. deux menus de remplissage automatique ne soient pas superposés ou que celui souhaité ne soit pas du tout affiché. ## 4. Comment fonctionne la Conditional UI ? Dans la suite, nous fournissons une ventilation étape par étape des étapes individuelles d'un flux complet de Conditional UI : ![WebAuthn Conditional UI Process Flow](https://www.corbado.com/website-assets/653274ad0332e7d69c77e199_webauthn_conditional_ui_process_flow_chart_6a1709e56d.png) En général, le flux de processus de la Conditional UI peut être divisé en deux phases. Pendant la phase de chargement de la page, la logique de la Conditional UI se produit en arrière-plan, tandis que dans la phase d'opération utilisateur, l'utilisateur doit activement faire quelque chose. 1. **Vérification de la disponibilité de la Conditional UI :** Le client (navigateur) appelle la fonction `isConditionalMediationAvailable()` pour détecter si la combinaison actuelle navigateur / appareil prend en charge la Conditional UI. Ce n'est que si la réponse est vraie que le processus continue, sinon le processus de la Conditional UI est annulé. 2. **Appeler le point de terminaison de la Conditional UI :** Ensuite, le client appelle le point de terminaison de la Conditional UI du serveur afin de récupérer les PublicKeyCredentialRequestOptions. 3. **Recevoir les PublicKeyCredentialRequestOptions :** Le serveur renvoie les PublicKeyCredentialRequestOptions qui contiennent le défi et d'autres options de serveur WebAuthn (par ex. allowCredentials, extensions, userVerification). 4. **Démarrer l'authentification locale :** En appelant `credentials.get()` avec les PublicKeyCredentialRequestOptions reçues et la propriété `mediation` définie pour être conditionnelle, le processus pour l'authentification locale sur l'appareil démarre. 5. **Afficher la sélection de remplissage automatique :** Le menu de remplissage automatique pour les clés d'accès s'affiche. Le style spécifique dépend du navigateur et de l'appareil (par ex. certains exigent que l'utilisateur place le curseur dans le champ de saisie, d'autres affichent automatiquement le menu au chargement de la page, voir ci-dessous). 6. **Authentification locale de l'utilisateur :** L'utilisateur sélectionne la clé d'accès dans le menu de remplissage automatique qu'il souhaite utiliser et s'authentifie via la boîte de dialogue d'authentification de son appareil (par ex. via Face ID, Touch ID, Windows Hello). 7. **Envoyer la réponse de l'authentificateur au serveur :** Si l'authentification locale de l'utilisateur a réussi, la réponse de l'authentificateur est renvoyée au serveur. 8. **L'utilisateur est connecté et redirigé :** Une fois que le serveur reçoit la réponse de l'authentificateur, il valide la signature avec la clé publique du compte utilisateur correspondant dans la base de données. Si la vérification réussit, l'utilisateur a accès, est connecté et redirigé vers la page de connexion. En suivant ce flux de processus, la Conditional UI offre une expérience d'authentification fluide et conviviale. ## 5. Exigences techniques pour la Conditional UI ### 5.1 Général Pour faire fonctionner la Conditional UI, certains aspects généraux doivent être pris en compte : - **Spécifications des identifiants :** La Conditional UI est spécifiquement conçue pour fonctionner uniquement avec des clés résidentes / identifiants découvrables. La raison sous-jacente est que les authentificateurs ne stockent pas de données spécifiques à l'utilisateur (par ex., nom, nom d'affichage) pour les clés non résidentes / identifiants non découvrables. En conséquence, utiliser ces derniers pour le remplissage automatique des clés d'accès n'est pas possible. - **Filtrage des identifiants :** La fonctionnalité [allowCredentials](https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialrequestoptions-allowcredentials) reste prise en charge, facilitant les sites web qui connaissent déjà l'identité de l'utilisateur (par exemple, si un nom d'utilisateur a été envoyé lors de l'appel initial de médiation parce qu'il pourrait être stocké dans le LocalStorage des navigateurs) pour affiner la liste des identifiants présentés aux utilisateurs lors du remplissage automatique. ### 5.2 Côté client Pour faire fonctionner la Conditional UI côté client, les exigences suivantes doivent être remplies : - **Navigateur compatible :** Assurez-vous que l'utilisateur utilise un navigateur moderne qui prend en charge la Conditional UI (voir [ici](https://caniuse.com/mdn-api_publickeycredential_isconditionalmediationavailable_static) pour la couverture la plus récente des navigateurs). - **JavaScript activé :** JavaScript doit être activé pour faciliter les opérations de la Conditional UI. - **Tester la disponibilité de la Conditional UI :** La partie utilisatrice (le côté serveur) devrait avoir la certitude que la Conditional UI est disponible côté client, lorsqu'elle reçoit l'appel de médiation WebAuthn, pour éviter de déclencher des erreurs visibles par l'utilisateur dans les scénarios où la Conditional UI n'est pas prise en charge. Pour y remédier, il est recommandé d'utiliser la méthode `isConditionalMediationAvailable()` et de vérifier la disponibilité technique de la Conditional UI (voir [ci-dessous](#browser-compatibility-check) pour plus de détails). - **Champ de saisie HTML requis :** Pour que la Conditional UI fonctionne, vous devez avoir un champ de saisie HTML dans votre page web. Si vous n'en avez pas, vous devez fournir un support pour le processus de connexion classique par clé d'accès / WebAuthn qui est déclenché par une interaction utilisateur, comme un clic sur un bouton. - **Supprimer les protocoles de délai d'attente :** Les paramètres de délai d'attente (par ex. l'utilisateur prend beaucoup de temps pour choisir une clé d'accès dans le menu de remplissage automatique) doivent être ignorés dans cette configuration. ### 5.3 Côté serveur Pour faire fonctionner la Conditional UI, certaines exigences côté serveur doivent également être remplies : - **Serveur WebAuthn en cours d'exécution :** Comme nous sommes toujours dans le contexte des clés d'accès / WebAuthn, il est nécessaire d'avoir un serveur WebAuthn en cours d'exécution qui gère les procédures d'authentification. - **Fournir un point de terminaison de démarrage de médiation :** Comparé aux points de terminaison de connexion WebAuthn classiques, il est utile de fournir un autre point de terminaison qui a une fonctionnalité similaire mais peut gérer un identifiant utilisateur facultatif (par ex. adresse e-mail, numéro de téléphone, nom d'utilisateur). ## 6. Conseils de codage pratiques Depuis le déploiement officiel de la Conditional UI fin 2022 et les versions bêta antérieures, nous l'avons testée et avons beaucoup travaillé avec. Dans la suite, nous souhaitons partager avec vous des conseils pratiques qui ont aidé lors de l'implémentation de la Conditional UI. ### 6.1 Exemple complet de Conditional UI Un exemple de code minimaliste et complet pour une méthode de Conditional UI ressemblerait à ceci : ```html Conditional UI ``` ### 6.2 Vérification de la compatibilité du navigateur Implémentez une détection de la Conditional UI qui garantit que la Conditional UI n'est utilisée que lorsque la combinaison actuelle appareil / navigateur la prend en charge. Cela devrait fonctionner sans présenter d'erreurs visibles par l'utilisateur en l'absence de prise en charge de la Conditional UI. L'intégration de la méthode `isConditionalMediationAvailable()` dans l'interface utilisateur répond à cette préoccupation. Si la prise en charge de la Conditional UI est confirmée, le processus de connexion par Conditional UI peut être démarré. ```javascript // source: https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/isConditionalMediationAvailable#examples // Availability of `window.PublicKeyCredential` means WebAuthn is usable. if (window.PublicKeyCredential && PublicKeyCredential.isConditionalMediationAvailable) { // Check if conditional mediation is available. const isCMA = await PublicKeyCredential.isConditionalMediationAvailable(); if (isCMA) { // Call WebAuthn authentication start endpoint let options = await WebAuthnClient.getPublicKeyRequestOptions(); const credential = await navigator.credentials.get({ publicKey: options.publicKeyCredentialRequestOptions, mediation: "conditional", }); /* ... */ } } ``` ### 6.3 Jeton de saisie automatique WebAuthn dans les champs de saisie Le champ de saisie doit recevoir un jeton de remplissage automatique HTML webauthn. Cela signale au client de remplir les clés d'accès à la demande en cours. Outre les clés d'accès, d'autres valeurs de remplissage automatique peuvent également être présentées. Ces jetons de remplissage automatique peuvent être associés à d'autres jetons existants, par ex. : - `autocomplete="username webauthn"` : Outre l'affichage des clés d'accès, cela suggère également le remplissage automatique du nom d'utilisateur. - `autocomplete="current-password webauthn"` : Outre l'affichage des clés d'accès, cela propose également le remplissage automatique du mot de passe. ```html ``` Pour plus de détails, nous recommandons de lire cet article de blog qui fournit plus de détails sur les jetons de remplissage / saisie automatique pour les clés d'accès et les mots de passe. ### 6.4 Propriété de médiation dans l'appel API WebAuthn Pour récupérer les clés d'accès disponibles après avoir reçu l'objet PublicKeyCredentialRequestOptions, la fonction `navigator.credentials.get()` doit être appelée (qui sert à la fois les clés d'accès et les mots de passe). L'objet PublicKeyCredentialRequestOptions doit avoir le paramètre de médiation (mediation) défini sur conditionnel (conditional) pour activer la Conditional UI sur le client. Pour les cas où vous souhaitez plutôt une invite de clé d'accès modale, consultez la médiation immédiate. ```javascript const credential = await navigator.credentials.get({ publicKey: options.publicKeyCredentialRequestOptions, mediation: "conditional", }); ``` ### 6.5 Annulation du flux de Conditional UI S'il n'y a pas de clé d'accès disponible, ou si l'utilisateur ignore les clés d'accès suggérées et saisit son e-mail, le flux de la Conditional UI est arrêté. Cela souligne l'importance de toujours prendre en charge également la connexion classique par clé d'accès / WebAuthn via une modale. Un point critique à souligner ici est la nécessité potentielle d'interrompre une requête de Conditional UI en cours. Contrairement aux expériences modales, les menus de remplissage automatique n'ont pas de bouton d'annulation. Selon la conception de WebAuthn, une seule [requête d'identifiant active](https://github.com/w3c/webappsec-credential-management/issues/206) doit être en cours à un moment donné. La norme WebAuthn suggère d'utiliser un [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) pour annuler un processus WebAuthn, applicable aux processus de connexion réguliers et de Conditional UI (voir [ici](https://w3c.github.io/webauthn/#sctn-sample-aborting) pour plus de détails). Dans la télémétrie de production, ce chemin d'annulation est souvent un résultat attendu du flux de contrôle, et non une défaillance du système. Si vous observez de grands volumes d'erreurs, vous devez classer les cas attendus par rapport aux cas inattendus selon le type d'opération et le timing avant de les traiter comme des régressions (voir les erreurs WebAuthn). Le processus de connexion par Conditional UI est activé dès qu'un utilisateur arrive sur la page. La tâche initiale devrait être de créer un objet `AbortController` à portée globale. Cela agira comme un signal pour votre client afin de terminer la demande de remplissage automatique, surtout si l'utilisateur décide de suivre le processus régulier de connexion par clé d'accès. Assurez-vous que l'`AbortController` peut être invoqué par d'autres fonctions et est réinitialisé si le processus de la Conditional UI doit redémarrer. Utilisez la propriété signal dans l'appel `navigator.credentials.get()`, en incorporant le signal de votre `AbortController` comme valeur. Cela signale à la fonction clé d'accès / WebAuthn que la requête doit être interrompue si le signal est annulé. N'oubliez pas de configurer un nouvel `AbortController` chaque fois que vous déclenchez la Conditional UI. L'utilisation d'un `AbortController` déjà annulé entraînera une annulation instantanée de la fonction clé d'accès / WebAuthn. Les étapes restantes s'alignent sur un processus régulier de connexion par clé d'accès. Ci-dessous, vous voyez un exemple de code des étapes mentionnées : ```html Conditional UI ``` En l'absence de prise en charge de la Conditional UI, dirigez les utilisateurs vers le processus classique de connexion par clé d'accès. Offrir ce chemin est important pour les utilisateurs s'appuyant sur des clés de sécurité matérielles (par ex. YubiKeys) ou ceux contraints d'utiliser des clés non résidentes / identifiants non découvrables en raison des contraintes de l'authentificateur. ### 6.6 La Conditional UI dans les applications natives Lorsque vous développez une application native, par ex. pour iOS ou Android, la Conditional UI fonctionne également. Peu importe si vous l'implémentez de manière native dans Flutter, Kotlin ou Swift, ou si vous décidez d'utiliser les Chrome Custom Tabs (CCT) ou SFSafariViewController ou SFAuthenticationSession / ASWebAuthenticationSession. Les deux approches prennent en charge la Conditional UI. #### 6.6.1 La Conditional UI dans les applications iOS En général, nous n'avons trouvé presque aucune documentation sur la façon d'implémenter la prise en charge de la Conditional UI pour les applications iOS. Lors de nos recherches, cependant, nous avons découvert deux façons d'ajouter la prise en charge de la Conditional UI à une application iOS, car l'expérience utilisateur différera également. **Type A : Superposition / Popup sur presque tout l'écran** Le premier type A montre une superposition / popup qui s'étend sur presque tout l'écran. Ici, vous verrez toutes les clés d'accès disponibles pour cette partie utilisatrice. Un exemple marquant qui implémente la Conditional UI de cette manière est KAYAK. La superposition / popup apparaît automatiquement, lorsque l'utilisateur ouvre le bon écran. ![Conditional UI iOS App Popup](https://www.corbado.com/website-assets/65fd93a0a95c16b286ab7bc1_conditional_ui_ios_app_popup_00d4f8124a.jpg) **Type B : Remplissage automatique du clavier** Le second type B affiche une clé d'accès appropriée dans la section de remplissage automatique du clavier (où des mots de passe sont également suggérés pour le remplissage automatique). Cliquer sur la valeur suggérée effectuera l'authentification Face ID et vous permettra de vous connecter. Dans la version actuelle de l'application iOS du panel développeur Corbado, nous l'avons implémenté de cette manière (voir le message de connexion par clé d'accès pour `` avec le nom d'utilisateur WebAuthn). Pour qu'il s'affiche, l'utilisateur doit appuyer dans le champ de saisie : ![Conditional UI iOS app Keyboard Autofill](https://www.corbado.com/website-assets/65fd93ae3406831e812dcae2_conditional_ui_ios_app_keyboard_autofill_98e9550aab.jpg) Cette fonctionnalité de remplissage automatique des clés d'accès dans la section du clavier peut rencontrer des problèmes lorsque l'iOS est fraîchement installé car apparemment une sorte de mise en cache se produit en arrière-plan et recherche toutes les clés d'accès disponibles pour cette partie utilisatrice. Cliquer sur l'icône de clé à droite de la clé d'accès suggérée mène au site connu pour le choix des mots de passe / clés d'accès sous iOS : ![Conditional UI iOS app Keyboard Autofill Details](https://www.corbado.com/website-assets/65fd952b9e058d8bf2ae011c_conditional_ui_ios_app_keyboard_autofill_details_582133a5e0.jpg) Veuillez noter que nous n'avons pas trouvé de documentation officielle, et nos informations sont basées sur nos expériences et hypothèses plutôt que sur une preuve concrète de l'implémentation adéquate. #### 6.6.2 La Conditional UI dans les applications Android Sur Android, l'histoire de la Conditional UI est un peu plus claire, car il n'y a qu'un seul type pour la Conditional UI / remplissage automatique de clés d'accès qui exploite l'API Credential Manager d'Android (voir la documentation [ici](https://developer.android.com/training/sign-in/passkeys)). Parce que les fournisseurs Android peuvent différer, surveillez les erreurs de clés d'accès du Credential Manager séparément des modèles d'échec WebAuthn uniquement sur navigateur. Ouvrir la page où la Conditional UI est implémentée affiche l'écran suivant, où vous trouverez différentes façons de vous connecter : ![Conditional UI Android app ](https://www.corbado.com/website-assets/65fd953866efb99383ecadff_conditional_ui_android_app_d9744622dc.jpg) Cliquer sur **More saved sign-ins** (Plus de connexions enregistrées) fournit plus d'options pour choisir la connexion (y compris l'authentification multi-appareils et la sélection d'une plateforme de synchronisation de clés d'accès différente, par ex. Samsung Pass ou 1Password) : ![Conditional UI Android app details](https://www.corbado.com/website-assets/65fd954176d4bacee21bd397_conditional_ui_android_app_details_bb2b567121.jpg) ## 7. Exemples de Conditional UI sur différents appareils / navigateurs Pour illustrer à quoi ressemble la Conditional UI pour l'utilisateur final, nous avons ajouté plusieurs captures d'écran d'un menu de remplissage automatique de la Conditional UI en utilisant [https://passkeys.eu](https://passkeys.eu). ### 7.1 La Conditional UI sous Windows 11 (22H2) + Chrome 118 ![Conditional UI Windows Chrome](https://www.corbado.com/website-assets/653274d5f112bcb90551666f_conditional_ui_windows_chrome_f6be9c714b.png) ### 7.2 La Conditional UI sous macOS Ventura (13.5.1) + Chrome 118 ![Conditional UI macOS Chrome](https://www.corbado.com/website-assets/653274ef4711bafab8f9337e_conditional_ui_macos_chrome_b577291109.png) ### 7.3 La Conditional UI sous macOS Ventura (13.5.1) + Safari 16.6 ![Conditional UI macOS Safari](https://www.corbado.com/website-assets/6532750a0dd891b360beef99_conditional_ui_macos_safari_e27787adb9.png) ### 7.4 La Conditional UI sous Android 13 + Chrome 118 ![Conditional UI Android Chrome](https://www.corbado.com/website-assets/6532752344d30f53cb09b9b6_conditional_ui_android_chrome_25ff68bcb5.jpg) ### 7.5 La Conditional UI sous iOS 17.1 + Safari 17.1 ![Conditional UI iOS Safari](https://www.corbado.com/website-assets/65327537f112bcb90551b96b_conditional_ui_ios_safari_87cd12b54e.PNG) ## 8. La Conditional UI dans les cas particuliers Jetons un coup d'œil à quelques scénarios courants dans les applications de la vie réelle. ### 8.1 La Conditional UI si aucune clé d'accès n'est disponible Si aucune clé d'accès n'est enregistrée pour un site, la Conditional UI se comportera différemment selon le navigateur et le système d'exploitation. #### 8.1.1 La Conditional UI sans clés d'accès sur Chrome sous macOS Sur **Chrome sous macOS**, cliquer dans le champ de saisie affiche un menu déroulant de remplissage automatique vide : ![conditional ui no passkey macos chrome](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_no_passkey_macos_chrome_8cb107283f.png) #### 8.1.2 La Conditional UI sans clés d'accès sur Safari sous macOS Sur **Safari sous macOS**, aucun menu déroulant n'est affiché - juste une icône discrète dans le champ de saisie : ![conditional ui no passkey macos safari](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_no_passkey_macos_safari_1be2b7f264.png) #### 8.1.3 La Conditional UI sans clés d'accès sur Android ou iOS Sur **Android ou iOS**, l'interface de remplissage automatique n'apparaît que si l'utilisateur appuie dans le champ et que l'OS trouve des identifiants correspondants. Cette variabilité est intentionnelle et fait partie du modèle de confidentialité de WebAuthn : les sites web ne peuvent pas détecter si l'utilisateur possède une clé d'accès à moins que l'utilisateur n'en sélectionne activement une. ### 8.2 La Conditional UI et multiples gestionnaires d'identifiants / fournisseurs de clés d'accès Si un utilisateur a installé plusieurs fournisseurs de clés d'accès (par ex. Trousseau iCloud, Google Password Manager, 1Password), le navigateur ou l'OS va généralement utiliser par défaut le gestionnaire d'identifiants principal de l'utilisateur. Pour une liste des différents fournisseurs de clés d'accès / gestionnaires d'identifiants prenant en charge les clés d'accès, nous vous recommandons de consulter le [lien GitHub](https://passkeydeveloper.github.io/passkey-authenticator-aaguids/explorer/) suivant. #### 8.2.1 La Conditional UI et multiples gestionnaires d'identifiants sous Android Sur Android, le Credential Manager expose différents fournisseurs comme Samsung Pass ou 1Password. 1. En cliquant sur le champ de saisie de l'identifiant utilisateur, ce menu apparaît où l'utilisateur peut sélectionner une clé d'accès. ![conditional ui multiple credential managers android choose passkey](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_multiple_credential_managers_android_choose_passkey_1f5be7736f.png) 2. Si l'utilisateur a cliqué sur "Plus de clés d'accès" dans l'écran précédent, une présélection d'autres fournisseurs de clés d'accès / gestionnaires d'identifiants et de clés d'accès apparaît : ![conditional -ui multiple credential managers android choose sign in](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_multiple_credential_managers_android_choose_sign_in_d91c861fca.png) 3. Si l'utilisateur a cliqué sur "Plus de connexions enregistrées" dans l'écran précédent, une liste complète de choix disponibles apparaît où l'utilisateur peut sélectionner une clé d'accès. ![conditional ui multiple credential managers android choose sign in details](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_multiple_credential_managers_android_choose_sign_in_details_e9d9526da9.png) #### 8.2.2 La Conditional UI et multiples gestionnaires d'identifiants sous iOS Sur iOS, l'icône de clé ouvre la liste complète des clés d'accès de diverses sources. 1. Dans un premier temps, sur iOS 18+, la Conditional UI classique avec le fournisseur de clés d'accès par défaut apparaît. ![conditional ui multiple credential managers ios](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_multiple_credential_managers_ios_4c1fd3eaa7.png) 2. Lors du clic sur l'icône de clavier, le menu de sélection suivant apparaît. ![conditional ui multiple credential managers ios select provider](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_multiple_credential_managers_ios_select_provider_737870e35b.png) 3. Après avoir sélectionné un gestionnaire d'identifiants / fournisseur de clés d'accès, l'utilisateur peut sélectionner la clé d'accès à utiliser. ![conditional ui multiple credential managers ios select passkey](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/conditional_ui_multiple_credential_managers_ios_select_passkey_568b192b3f.png) > En tant qu'application ou site web, vous ne pouvez pas contrôler quel gestionnaire d'identifiants est utilisé - l'OS > gère ce choix pour préserver > la vie privée des utilisateurs. ## 9. Conclusion Les clés d'accès, avec leur capacité de Conditional UI / remplissage automatique, constituent la nouvelle façon de s'authentifier en ligne. Alors que nous passons à une ère où les mots de passe sont de plus en plus remplacés par des clés d'accès, le besoin de mécanismes de transition robustes et conviviaux est indéniable. Cet article a aidé à comprendre comment implémenter correctement la Conditional UI, une grande aide dans le processus de transition, et sur quels aspects porter une attention particulière. ## Foire aux questions ### Comment vérifier si un navigateur prend en charge la Conditional UI avant de lancer le flux de remplissage automatique des clés d'accès ? Appelez `PublicKeyCredential.isConditionalMediationAvailable()` et ne continuez que si cela renvoie true (vrai). Cette vérification évite des erreurs visibles par l'utilisateur sur les combinaisons de navigateurs et d'appareils non prises en charge. La méthode doit être évaluée à chaque chargement de page avant d'appeler `navigator.credentials.get()` avec `mediation: "conditional"`. ### Pourquoi la Conditional UI fonctionne-t-elle uniquement avec des identifiants découvrables et non avec toutes les clés d'accès ? Les authentificateurs ne stockent les données spécifiques à l'utilisateur, telles que le nom et le nom d'affichage, que pour les clés résidentes (identifiants découvrables). Les clés non résidentes ne conservent pas ces informations, le menu de remplissage automatique ne peut donc pas renseigner les détails du compte à sélectionner par l'utilisateur. ### Que se passe-t-il dans la Conditional UI lorsqu'un utilisateur n'a pas de clé d'accès enregistrée pour un site ? Le comportement varie selon la plateforme. Chrome sous macOS affiche une liste déroulante de remplissage automatique vide, Safari sous macOS affiche uniquement une icône discrète dans le champ de saisie, et sur Android ou iOS, l'interface de remplissage automatique n'apparaît que si l'OS trouve des identifiants correspondants après que l'utilisateur a appuyé sur le champ. Cette variabilité est intentionnelle et fait partie du modèle de confidentialité de WebAuthn : les sites web ne peuvent pas détecter si une clé d'accès existe à moins que l'utilisateur n'en sélectionne activement une. ### Comment annuler une requête de Conditional UI en cours lorsqu'un utilisateur passe à la connexion par clé d'accès modale ? Créez un `AbortController` à portée globale et passez son signal à `navigator.credentials.get()`. Appelez `.abort()` sur le contrôleur lorsque l'utilisateur initie un flux de connexion modale. Instanciez toujours un nouvel `AbortController` chaque fois que la Conditional UI redémarre, car la réutilisation d'un contrôleur déjà annulé provoque l'annulation immédiate de la requête WebAuthn. ### La Conditional UI fonctionne-t-elle dans les applications natives iOS et Android ou uniquement dans les navigateurs web ? La Conditional UI fonctionne à la fois dans les applications natives iOS et Android. iOS prend en charge deux variantes : une popup en superposition plein écran et une suggestion de remplissage automatique au clavier. Android utilise l'API Credential Manager, qui peut afficher les clés d'accès de multiples fournisseurs tels que Samsung Pass ou 1Password.