---
url: 'https://www.corbado.com/fr/blog/cles-dacces-brave-browser'
title: 'Clés d''accès dans le navigateur Brave (2026) : Ce qui fonctionne et ce qui casse'
description: 'Brave suit principalement Chromium pour les clés d''accès, mais les conflits avec Android, Windows Hello et les gestionnaires de mots de passe créent des frictions.'
lang: 'fr'
author: 'Vincent Delitz'
date: '2026-07-03T07:07:54.177Z'
lastModified: '2026-07-03T07:08:26.535Z'
keywords: 'clés d''accès dans brave, navigateur brave, webauthn, windows hello, gestionnaire de mots de passe, clés d''accès android'
category: 'WebAuthn Know-How'
---

# Clés d'accès dans le navigateur Brave (2026) : Ce qui fonctionne et ce qui casse

## Key Facts

- **Le chemin du code WebAuthn est celui de Chromium, presque intact.** Le dépôt `brave/brave-core` contient exactement **une** personnalisation visible liée à WebAuthn : un remplacement de chaîne qui renomme l'étiquette « Incognito » de Chrome en « Private » dans la boîte de dialogue d'enregistrement de la clé d'accès. Aucun correctif C++ ne touche le chemin du code WebAuthn.
- **24 problèmes ouverts sur les clés d'accès/WebAuthn** se trouvaient dans `brave/brave-browser` en avril 2026, selon des recherches de problèmes GitHub pour `passkey` et `WebAuthn`. Les problèmes ouverts étiquetés avec « passkey » sont passés d'environ 2 par an en 2022-2023 à 6 ouverts en 2025.
- **L'utilisation inter-navigateurs sur macOS fonctionne.** Une clé d'accès créée sur macOS peut être stockée dans le Trousseau iCloud et est utilisable dans Safari, Chrome et d'autres navigateurs de la plateforme Apple sur les appareils partageant le même identifiant Apple.
- **Les versions Android dé-Googleisées cassent.** Sans les Services Google Play, l'enregistrement et l'authentification par clé d'accès échouent souvent sur Android. Suivi dans le problème #45415 (ouvert depuis avril 2025).
- **Windows Hello ne peut pas être totalement supprimé.** Désactiver `brave://password-manager/settings` n'empêche pas Windows de proposer Hello comme authentificateur de plateforme WebAuthn. Suivi dans le problème #51858 (ouvert en janvier 2026).
- **L'interception par les extensions est la régression la plus active.** Le problème #37762 - où l'interface utilisateur native des clés d'accès supplante les invites de Bitwarden et 1Password - a été ouvert en avril 2024 et recevait encore des rapports de bugs le 25 mars 2026.
- **La solution de contournement via l'indicateur `web-authentication-new-passkey-ui` a disparu** dans la version 146 (Chromium 146), selon un rapport d'utilisateur sur le problème `brave/brave-browser` #37762 daté du 25-03-2026.

## 1. Introduction : Prise en charge des clés d'accès dans Brave aujourd'hui

La prise en charge des clés d'accès par Brave est proche de Chromium au niveau du code, mais l'expérience utilisateur diverge à quelques endroits importants. En avril 2026, le dépôt plus large `brave/brave-browser` comportait encore 24 problèmes ouverts correspondant à `passkey` ou `WebAuthn`, tandis que [`brave/brave-core`](https://github.com/brave/brave-core) affichait une seule personnalisation visible spécifique à WebAuthn. Les principaux points de rupture sont l'interception par les extensions, les invites Windows Hello et les flux Android sur les appareils dé-Googleisés.

Brave déploie les clés d'accès via le même chemin de code WebAuthn que le projet Chromium en amont et délègue le stockage des identifiants au système d'exploitation. Cette architecture donne à Brave une apparence standard sur le papier, mais le comportement réel dépend toujours des systèmes environnants tels que les extensions de gestionnaires de mots de passe, Windows Hello et les Services Google Play. Les sections ci-dessous séparent ces modes de défaillance afin que chaque comportement spécifique à la plateforme puisse être compris en lui-même.

## 2. En quoi la pile WebAuthn de Brave diffère-t-elle de celle de Chromium ?

L'implémentation de WebAuthn dans Brave est en fait l'implémentation de Chromium avec un seul changement de texte visible dans l'interface utilisateur. Le dépôt [`brave/brave-core`](https://github.com/brave/brave-core) contient une seule personnalisation liée à WebAuthn - un remplacement de chaîne qui renomme « Incognito » en « Private » dans la boîte de dialogue d'enregistrement - et aucun correctif C++ touchant à la logique principale de WebAuthn. Cela signifie que Brave hérite de la pile de clés d'accès Chromium que Google a publiée à partir de Chromium 115 en juin 2023.

Ceci est important pour deux raisons. Premièrement, les fusions normales en amont signifient que les correctifs WebAuthn et les ajouts de fonctionnalités arrivent généralement sans que Brave n'entretienne une implémentation de clés d'accès profondément dérivée (fork). Vous pouvez inspecter le seul remplacement de chaîne directement dans [`brave/brave-core`](https://github.com/brave/brave-core/blob/master/components/webauthn_strings_override.grdp). Dans les mappages AAGUID, le chemin de l'authentificateur de navigateur Chromium est couramment identifié comme `b5397666-4885-aa6b-cebf-e52262a439a2`, étiqueté « Chromium Browser » dans notre liste de référence. Deuxièmement, la plupart des échecs signalés - interception d'extensions, conflits de remplissage automatique et dépendance d'Android aux Services Google Play - apparaissent dans des systèmes adjacents tels que le remplissage automatique, les permissions, Shields ou l'intégration Wallet. Ils entourent le flux WebAuthn plutôt que de le remplacer.

## 3. Une clé d'accès créée sur macOS peut-elle être utilisée dans Safari sur un autre appareil Apple ?

Oui, mais seulement si la clé d'accès est sauvegardée dans le Trousseau iCloud. Sur macOS, Brave utilise la pile WebAuthn de Chromium et peut stocker une nouvelle clé d'accès soit dans l'authentificateur de plateforme Apple, soit dans une autre cible de stockage présentée dans l'invite de création. Une clé d'accès sauvegardée dans le Trousseau iCloud se synchronise via l'identifiant Apple et devient disponible dans Safari, Chrome et d'autres navigateurs compatibles WebAuthn sur les appareils Apple qui partagent cet identifiant Apple.

Une fois que macOS confirme que Brave est autorisé à accéder au Trousseau iCloud, le navigateur peut utiliser les mêmes clés d'accès synchronisées que celles que voit Safari. Cette invite de permission est le moment pratique où la portabilité inter-navigateurs sur les appareils Apple devient réelle plutôt que théorique.

![macOS demande si le navigateur Brave peut accéder aux clés d'accès sauvegardées dans le Trousseau iCloud, ce qui permet aux mêmes identifiants synchronisés de fonctionner sur Safari, Chrome et Brave sur les appareils Apple partageant le même identifiant Apple.](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/access_icloud_8252555e93.png)

Brave sur macOS peut également participer aux flux d'authentification multi-appareils (CDA). Si l'utilisateur autorise l'accès au Bluetooth, Brave peut découvrir et communiquer avec les appareils à proximité pendant le CDA, ce qui rend l'approbation des clés d'accès par téléphone largement transparente depuis le navigateur de bureau.

![Brave sur macOS demande l'accès au Bluetooth avant l'authentification multi-appareils, permettant la découverte d'appareils à proximité et des flux d'approbation de clés d'accès par téléphone plus fluides.](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/bluetooth_brave_macos_c51dd36600.png)

Une clé d'accès sauvegardée dans le stockage d'un profil de navigateur ou dans un stockage local uniquement ne devient pas automatiquement disponible dans Safari sur un autre appareil Apple. Cette différence est importante car la synchronisation de l'authentificateur de plateforme au niveau du système d'exploitation et la synchronisation du profil de navigateur suivent des règles différentes. Brave ne fournit pas la synchronisation des clés d'accès du Gestionnaire de mots de passe Google de Chrome, donc seul le chemin du Trousseau iCloud offre une portabilité inter-navigateurs de type Apple sur les appareils Apple.

## 4. Pourquoi les clés d'accès ne fonctionnent-elles pas de manière fiable sur Android sans les Services Google Play ?

Le Credential Manager d'Android ne fait pas lui-même partie des Services Google Play. Sur Android 14 et ultérieur, Chromium peut utiliser le chemin du Credential Manager système, tandis que les versions Android plus anciennes s'appuient plus lourdement sur la couche FIDO2 soutenue par les Services Google Play. Dans la pratique, Brave hérite toujours de l'échec documenté dans le problème #45415 : sur GrapheneOS, CalyxOS, /e/OS et d'autres versions Android dé-Googleisées sans le chemin requis des Services Play, l'enregistrement et l'authentification par clé d'accès peuvent expirer (time out). En avril 2026, cela restait une lacune de compatibilité ouverte pour les utilisateurs Android soucieux de leur vie privée.

Ce comportement est documenté dans le [problème `brave/brave-browser` #45415](https://github.com/brave/brave-browser/issues/45415), ouvert en avril 2025 et toujours ouvert un an plus tard. La [documentation du Credential Manager](https://developer.android.com/training/sign-in/passkeys) de Google distingue l'API du Credential Manager de la dépendance d'authentification optionnelle des Services Play utilisée sur les anciennes versions d'Android, et le guide Android plus large note qu'Android 14+ peut fonctionner avec des gestionnaires de mots de passe activés. Le fil de discussion note également que le même mode de défaillance affecte plus largement les navigateurs basés sur Chromium, tandis que les navigateurs basés sur Firefox ne sont pas affectés de la même manière. Le rapporteur initial a souligné que GrapheneOS a corrigé la dépendance dans son propre fork Chromium, [Vanadium](https://github.com/GrapheneOS/Vanadium), donc une correction en aval semble techniquement possible - elle n'a tout simplement pas eu lieu.

Plusieurs utilisateurs ont confirmé indépendamment le comportement dans ce fil de discussion. Un test particulièrement propre en décembre 2025 a utilisé le même appareil avec deux profils : les clés d'accès ne fonctionnaient dans Brave que sur le profil avec les Services Play activés, tandis que Vanadium et Cromite fonctionnaient sur les deux. En avril 2026, aucun mainteneur de Brave n'avait répondu dans le fil de discussion. Pour le public Android de Brave soucieux de la confidentialité - qui comprend un nombre disproportionné d'utilisateurs dé-Googleisés - cela laisse une lacune très visible. Firefox sur Android utilise sa propre pile WebAuthn et ne dépend pas des Services Play de la même manière. Aujourd'hui, la solution de contournement pratique consiste à utiliser Firefox pour les flux de clés d'accès sur Android sans les Services Play, ou à se rabattre sur une clé de sécurité matérielle avec un client compatible. Pour le paysage plus large des défaillances sur Android, consultez Erreurs de clés d'accès dans les applications natives. Pour les spécificités des Services Google Play et du Credential Manager, consultez Codes d'erreur de clé d'accès Android & Google Play Services.

## 5. Pourquoi les invites de clés d'accès Windows Hello apparaissent-elles même lorsque je les désactive ?

Désactiver le paramètre « proposer d'enregistrer les clés d'accès » de Brave n'empêche pas Windows Hello d'apparaître pendant les flux WebAuthn. Une fois qu'un site appelle WebAuthn et que Windows Hello est configuré, Windows annonce Hello comme un authentificateur de plateforme et Brave n'expose aucun contrôle destiné à l'utilisateur qui le bloque. En janvier 2026, la suppression de Windows Hello restait non résolue pour les utilisateurs qui voulaient Hello pour déverrouiller l'appareil mais pas pour les clés d'accès.

Le [problème #51858](https://github.com/brave/brave-browser/issues/51858), ouvert en janvier 2026, et le plus long [fil de discussion communautaire 646042](https://community.brave.app/t/brave-prompts-for-windows-hello-passkeys-even-when-disabled/646042) décrivent la même chose. Le rapporteur original a essayé des modifications du registre, des stratégies de groupe, des bascules d'indicateurs et des installations propres - rien de tout cela n'a changé le comportement.

La raison technique décrite dans le fil de discussion 646042 est simple : les paramètres du gestionnaire de mots de passe du navigateur contrôlent le propre comportement de remplissage automatique du navigateur, pas la limite WebAuthn entre la page et le système d'exploitation. Windows expose Hello de manière indépendante, et la discussion n'identifie pas de configuration documentée et prise en charge qui préserve Windows Hello pour le déverrouillage de l'appareil tout en le bloquant totalement en tant qu'authentificateur de plateforme WebAuthn.

Aujourd'hui, le seul moyen fiable de supprimer ces invites est de désactiver entièrement l'inscription à Windows Hello, ce qui entre manifestement en conflit avec la façon dont la plupart des gens veulent déverrouiller leur appareil. Edge se comporte différemment car il est plus étroitement intégré à la couche de gestion des identifiants de Windows et expose des contrôles que les forks de Chromium n'ont pas actuellement. Pour un aperçu plus large du comportement des clés d'accès sur Windows, consultez Clés d'accès sur Windows 11.

## 6. Faut-il stocker les clés d'accès nativement ou dans votre gestionnaire de mots de passe ?

Le stockage natif des clés d'accès est l'option la plus simple au sein d'un seul écosystème, tandis que les extensions de gestionnaires de mots de passe restent la seule couche de synchronisation multiplateforme largement exploitable. Le Trousseau iCloud fonctionne bien sur les appareils Apple, Windows Hello fonctionne sur Windows et les coffres-forts basés sur des extensions tels que 1Password ou Bitwarden restent la seule option réaliste pour les utilisateurs qui souhaitent que les clés d'accès soient disponibles nativement de manière cohérente sur Windows, macOS, Linux et Android. L'authentification multi-appareils (CDA, ou transport hybride via un code QR et Bluetooth) peut toujours faire le lien entre les appareils au moment de la connexion, mais elle ne synchronise pas l'identifiant lui-même et ne le rend pas disponible localement partout par défaut. Le compromis est la fiabilité : les flux natifs sont plus simples, les flux d'extensions sont plus portables et la CDA est mieux comprise comme un chemin de secours plutôt que comme une stratégie de stockage.

La décision se résume principalement à trois choses : combien de plateformes vous utilisez, à quel point vous faites confiance aux flux d'extensions et où vous gardez déjà vos identifiants. Si vous restez principalement dans un seul écosystème OS - tout Apple, ou tout Windows - la voie de l'authentificateur de plateforme natif est l'option la plus propre. Dans cette configuration, Brave se comporte un peu comme Chrome ou Safari. Si vous avez besoin que les clés d'accès vous suivent sur Windows, macOS, Linux et Android, une extension de gestionnaire de mots de passe tierce telle que 1Password, Bitwarden, Dashlane ou Proton Pass reste la seule couche de synchronisation globalement viable.

La complication est que, depuis avril 2024, des rapports continuent d'affluer selon lesquels l'interface utilisateur native des clés d'accès pirate par intermittence les flux pilotés par des extensions. Les utilisateurs dans le [problème #37762](https://github.com/brave/brave-browser/issues/37762) décrivent des boîtes de dialogue d'authentification de l'OS apparaissant alors que Bitwarden ou 1Password devrait posséder l'identifiant. En mars 2026, l'ancienne solution de contournement - désactiver `brave://flags/#web-authentication-new-passkey-ui` - n'était plus disponible car l'indicateur avait été supprimé dans la version 146.

| Emplacement de stockage | Synchronisation inter-OS | Utilisation inter-navigateurs | Posture de récupération | Risque connu |
| ----------------------- | ---------------------- | ------------------------- | ------------------- | ---------------------------------- |
| Trousseau iCloud | Apple uniquement | Navigateurs Apple | Identifiant Apple | Aucun |
| Windows Hello | Non (lié à l'appareil) | Même appareil Windows | Déverrouillage appareil / PIN | La boîte de dialogue Hello ne peut pas être désactivée |
| Gestionnaire de mots de passe Google | Où GPM est disponible | Surfaces Chrome + Android | Compte Google | Non exposé dans les profils Brave ici |
| 1Password / Bitwarden | Complète | Complète (extension) | Compte du coffre-fort | Interception native intermittente |
| Clé de sécurité matérielle | Liée à l'appareil | N'importe quel navigateur | Possession physique | Aucun |

En pratique, le modèle adopté par de nombreux utilisateurs soucieux de la confidentialité en 2026 est hybride : utiliser l'authentificateur de plateforme OS pour les connexions quotidiennes au sein d'un écosystème, utiliser une extension de gestionnaire de mots de passe là où la portabilité multiplateforme compte et garder une clé de sécurité matérielle à portée de main pour les comptes de grande valeur.

## 7. Quels sont les points de friction liés aux clés d'accès signalés par les utilisateurs en 2026 ?

Les problèmes de clés d'accès ouverts dans Brave en 2026 se regroupent autour de trois thèmes récurrents : l'interception par les extensions, les défaillances d'Android sur les appareils dé-Googleisés et les problèmes de clé de sécurité sur ordinateur de bureau. En avril 2026, le dépôt plus large montrait toujours 24 problèmes ouverts correspondant à `webauthn` ou `passkey`, ce qui suggère que la friction est concentrée, et non aléatoire.

Le groupe le plus actif est l'interception par les extensions, où l'interface utilisateur native des clés d'accès peut supplanter les invites de 1Password, Bitwarden ou Dashlane. La compatibilité Android sans les Services Google Play est le deuxième problème récurrent, et la détection des clés de sécurité sur ordinateur de bureau est le troisième. Les fils de discussion les plus souvent référencés ici sont [`#37762`](https://github.com/brave/brave-browser/issues/37762), [`#50561`](https://github.com/brave/brave-browser/issues/50561), [`#45415`](https://github.com/brave/brave-browser/issues/45415), [`#15650`](https://github.com/brave/brave-browser/issues/15650), [`#43043`](https://github.com/brave/brave-browser/issues/43043), [`#34441`](https://github.com/brave/brave-browser/issues/34441), [`#33237`](https://github.com/brave/brave-browser/issues/33237) et [`#51858`](https://github.com/brave/brave-browser/issues/51858). Les fils actifs pointent dans la même direction sans avoir besoin de nombreuses citations directes.

Plusieurs de ces problèmes ont reçu de nouveaux commentaires au cours des 90 derniers jours, ce qui en fait des régressions actives plutôt que des curiosités historiques. Pour les développeurs qui construisent des flux de clés d'accès, la conclusion est claire : testez explicitement les flux pilotés par des extensions dans Brave et proposez des solutions de repli judicieuses lorsque les appels WebAuthn échouent. Pour les utilisateurs, la leçon est tout aussi pratique : gardez une clé de sécurité matérielle ou un autre facteur de récupération configuré sur vos comptes importants.

## 8. Conclusion

L'histoire des clés d'accès dans Brave est propre au niveau du code et désordonnée au niveau de l'expérience utilisateur. Le chemin WebAuthn est en fait celui de Chromium, avec un seul remplacement de chaîne confirmant à quel point l'implémentation reste proche du code en amont. Sur les plateformes Apple, la portabilité des clés d'accès fonctionne exactement comme les utilisateurs s'y attendent, car le Trousseau iCloud détient l'identifiant. La véritable friction se situe ailleurs : l'interception par les extensions (#37762), la suppression de Windows Hello (#51858) et la dépendance d'Android aux Services Google Play (#45415). Jusqu'à ce que ces problèmes soient résolus, les développeurs devraient tester Brave séparément au lieu de supposer une parité avec Chrome, et les utilisateurs devraient conserver une solution de secours robuste - idéalement une clé de sécurité matérielle - pour leurs comptes importants.

## 9. À propos de Corbado

Corbado construit une infrastructure de clés d'accès pour la connexion des consommateurs et fournit une plateforme d'intelligence des clés d'accès pour les équipes qui doivent exploiter des clés d'accès et des systèmes d'authentification à grande échelle. Nous publions des analyses techniques sur le comportement de WebAuthn et des clés d'accès sur les navigateurs et les systèmes d'exploitation en nous basant sur des déploiements réels, une inspection directe du code source et une lecture attentive des spécifications sous-jacentes. Les questions ou corrections sont toujours les bienvenues.

## 10. Foire aux questions

### 10.1 Une clé d'accès créée dans Brave sur macOS peut-elle être utilisée dans Safari sur un autre appareil Apple ?

Oui, mais seulement si Brave sauvegarde la clé d'accès dans le Trousseau iCloud. Sur macOS, Brave utilise la pile WebAuthn de Chromium et peut stocker une nouvelle clé d'accès dans le Trousseau iCloud ou dans une autre cible de stockage affichée dans l'invite de création. Une clé d'accès sauvegardée dans le Trousseau iCloud se synchronise via l'identifiant Apple et devient disponible dans Safari, Chrome et d'autres navigateurs sur les appareils Apple qui partagent cet identifiant Apple. Une clé d'accès sauvegardée dans le stockage d'un profil de navigateur ou dans un stockage local uniquement ne devient pas automatiquement disponible dans Safari sur un autre appareil Apple.

### 10.2 Pourquoi les clés d'accès échouent-elles dans Brave sur Android sans les Services Google Play ?

Brave sur Android peut échouer sans les Services Google Play, mais la raison est plus spécifique que « Le Credential Manager fait partie des Services Play ». Le Credential Manager d'Android est un système et une API Jetpack, tandis que les versions Android plus anciennes s'appuient davantage sur la couche FIDO2 soutenue par les Services Google Play. En pratique, Brave hérite toujours de l'échec documenté dans le problème `brave/brave-browser` #45415 : sur GrapheneOS, CalyxOS ou d'autres versions d'Android dé-Googleisées sans le chemin requis des Services Play, la boîte de dialogue de clé d'accès ne s'ouvre jamais et l'enregistrement ou l'authentification expirent (time out).

Pour le paysage plus large des défaillances sur Android, consultez Erreurs de clés d'accès dans les applications natives. Pour les spécificités des Services Google Play et du Credential Manager, consultez Codes d'erreur de clé d'accès Android & Google Play Services.

### 10.3 Brave synchronise-t-il les clés d'accès entre les appareils comme le fait Chrome ?

Non. Brave ne fournit pas d'équivalent à la synchronisation des clés d'accès du profil de navigateur de Chrome via le Gestionnaire de mots de passe Google. Les clés d'accès créées dans Brave sont stockées dans l'authentificateur de plateforme du système d'exploitation sous-jacent - Trousseau iCloud sur Apple, Windows Hello sur Windows et Credential Manager Android sur Android - et se synchronisent uniquement via ce compte de système d'exploitation. Si vous souhaitez une synchronisation cohérente entre les appareils, vous dépendez du fournisseur du système d'exploitation ou d'une extension de gestionnaire de mots de passe tierce.

### 10.4 Pourquoi Brave demande-t-il des clés d'accès Windows Hello même lorsque je désactive les options de clés d'accès dans les paramètres ?

La bascule `brave://password-manager/settings` de Brave contrôle uniquement si Brave propose de sauvegarder les clés d'accès lui-même. Elle n'empêche pas Windows d'annoncer Windows Hello comme un authentificateur de plateforme WebAuthn à la page. Le site appelle WebAuthn, Windows présente Hello et Brave n'a pas de commutateur intégré au navigateur pour supprimer la boîte de dialogue de l'OS. Le comportement est suivi dans le problème `brave/brave-browser` #51858.

### 10.5 Dois-je stocker les clés d'accès dans le flux natif de Brave ou dans mon gestionnaire de mots de passe ?

Utilisez le flux OS natif de Brave (Trousseau iCloud ou le Gestionnaire de mots de passe Google via la plateforme) si vous restez dans un seul écosystème et que vous souhaitez le moins de pièces mobiles possible. Utilisez une extension de gestionnaire de mots de passe tierce telle que 1Password ou Bitwarden si vous avez besoin que les clés d'accès vous suivent de manière cohérente sur Windows, macOS, Linux et Android, ou si vous y gardez déjà vos secrets. Depuis 2024, l'interface utilisateur native de Brave a intercepté à plusieurs reprises les flux de clés d'accès d'extensions, il vaut donc la peine de vérifier que l'extension possède toujours l'invite.

### 10.6 Combien de problèmes ouverts sur les clés d'accès et WebAuthn le dépôt brave/brave-browser compte-il actuellement concernant le comportement des clés d'accès de Brave ?

En avril 2026, `brave/brave-browser` avait 24 problèmes ouverts correspondant aux recherches `passkey` ou `WebAuthn`. Les problèmes ouverts étiquetés avec « passkey » sont passés d'environ 2 par an en 2022-2023 à 6 ouverts en 2025. Pour Brave, les thèmes dominants sont l'interception par les extensions sur ordinateur de bureau, la suppression de Windows Hello et la dépendance aux Services Google Play d'Android.