Depuis la version 124 d’Edge sur Windows 11 Pro, plusieurs utilisateurs constatent que le gestionnaire « Wallet » n’affiche plus le mot de passe enregistré pour le domaine microsoft.com, alors même que l’auto‑remplissage continue de fonctionner. Voici un guide détaillé pour comprendre, diagnostiquer et contourner cette anomalie.
Problème rencontré
Sur un système Windows 11 Pro exécutant Microsoft Edge 124.0.2478.67, le gestionnaire de mots de passe intégré—désormais baptisé « Wallet »—liste normalement l’ensemble des identifiants synchronisés via le compte Microsoft Account. Pourtant, dans ce scénario précis :
- Le domaine
microsoft.comn’apparaît pas dansedge://wallet/passwords; - La fonction d’auto‑remplissage injecte malgré tout l’identifiant et le mot de passe corrects dans les formulaires de connexion Microsoft ;
- Les effacements de cache/cookies ou la réinitialisation du mot de passe Microsoft n’ont aucun effet.
En d’autres termes, les informations d’authentification sont bien stockées et chiffrées quelque part—localement ou dans le cloud Microsoft Sync—mais l’interface graphique refuse de les afficher.
Explications probables
1. Restriction spécifique au compte Microsoft
Microsoft applique parfois des politiques de security hardening qui limitent la visibilité des secrets liés à ses propres services. Le mot de passe de votre Microsoft Account pourrait être considéré comme trop sensible pour être révélé en clair—even après déverrouillage du Wallet via Windows Hello.
2. Politique de synchronisation ou de chiffrement évolutive
Depuis Edge 118, les équipes Microsoft testent un mode de zero‑knowledge reveal : les identifiants critiques restent chiffrés côté serveur et ne sont déchiffrables que par le module Autofill local, pas par l’UI. Si votre profil a basculé sur cette branche (déploiement par vagues, feature flags), vous pouvez rencontrer l’anomalie avant la majorité des utilisateurs.
3. Bug introduit dans une version récente
Des retours concordants sur les canaux Stable et Insider (Dev, Canary) tendent à prouver qu’il s’agit plus d’un défaut de rendu qu’une volonté produit : la base de données Login Data contient bien l’entrée microsoft.com mais la requête SQL de l’UI l’exclut à tort. Un correctif peut donc arriver rapidement.
Solutions et pistes proposées
| Action | Finalité | Commentaire |
|---|---|---|
| Envoyer un feedback à Microsoft | Confirmer s’il s’agit d’un changement voulu ou d’un bug. | Ouvrez Alt + Shift + I ou « … > Aide et commentaires > Envoyer des commentaires ». Joignez une capture de edge://wallet/passwords et la version exacte du navigateur. |
| Surveiller les notes de mise à jour | Être alerté dès qu’un correctif est publié. | Consultez régulièrement les release notes des branches Canary, Dev, Beta puis Stable. Les patch‑notes mentionnent souvent les corrections liées à Wallet. |
| Tester avec un autre profil ou appareil | Écarter la piste d’une base locale corrompue. | Créez un nouveau profil Edge ou connectez‑vous sur un autre PC/VM Windows 11. Si le mot de passe réapparaît, la corruption est locale ; sinon, c’est global au compte. |
| Vérifier les stratégies d’entreprise | Confirmer qu’aucune GPO/MDM ne masque certains mots de passe. | Entrez edge://policy. Les stratégies PasswordManagerEnabled ou HideAutoFillPasswords doivent être Not Set. |
| Exporter puis réimporter les mots de passe | Reconstituer la base pour contourner un index brisé. | Dans edge://settings/passwords cliquez sur ••• > Exporter. Après vérification, réimportez le fichier CSV. Edge vous demandera l’authentification Windows Hello. |
| Utiliser temporairement un gestionnaire externe | Accéder visuellement au mot de passe en attendant le correctif. | Par exemple Keepass ou Bitwarden ; supprimez la doublure dès qu’Edge résout le problème pour éviter les incohérences. |
Procédure de diagnostic approfondi
Si vous souhaitez aller plus loin que les actions précédentes, voici un workflow de troubleshooting détaillé :
- Inspecter la base locale
Edge stocke les identifiants dans la base SQLite%localappdata%\Microsoft\Edge\User Data\Default\Login Data.
– Fermez toutes les fenêtres Edge.
– Copiez le fichier dans un répertoire de travail.
– Ouvrez‑le avec l’outil DB Browser for SQLite.
– Interrogez la tablelogins:SELECT origin_url, username_value FROM logins WHERE origin_url LIKE '%microsoft.com%';Si l’entrée existe, l’UI est fautive ; sinon, Edge ne la synchronise plus. - Vérifier les feature flags
Allez dansedge://flagset cherchez « Edge Password Manager Redesign » ou « Wallet unified passwords view ». Désactivez temporairement ces options et relancez Edge. - Regarder la console DevTools
Ouvrez DevTools (F12) sur la pageedge://wallet/passwords, onglet Console. Les erreursSQLConstraintFailedouUncaught (in promise) DOMExceptionpeuvent indiquer un filtre involontaire. - Examiner le journal Sync internals
Accédez àedge://sync-internals.
Dans l’onglet Type Info, vérifiez l’état du nœudPASSWORDS: il doit être Running et non Throttled.
Conseils pratiques pour minimiser l’impact
- Créer un alias Outlook.com dédié
Utilisez l’alias comme identifiant principal pour Microsoft 365 ou Xbox, afin de pouvoir stocker un mot de passe visible distinct du mot de passe maître de votre compte. - Générer un mot de passe d’application (si MFA activé)
Les mots de passe d’applications ne déclenchent pas la même politique de masquage et restent visibles dans Wallet, ce qui facilite leur gestion. - Filtrer vos environnements de test
Maintenez au moins un Edge Canary isolé sur une VM : vous recevrez les correctifs plus tôt sans risquer vos données de production.
Pourquoi l’auto‑remplissage fonctionne‑t‑il encore ?
Edge suit le standard W3C WebAuthn & Credential Management. Les mots de passe sont stockés dans Login Data mais l’UI tire sa liste d’une API interne. Lorsque l’UI échoue ou filtre une entrée, le module Autofill, lui, lit directement la base et déchiffre le secret via CryptProtectData (ou DPAPI‑NG si vous utilisez Windows Hello). Cette architecture explique pourquoi le remplissage automatique survit à la plupart des erreurs d’interface.
Historique des incidents similaires
• Juin 2023 : la Preview 115 d’Edge Canary masquait toutes les entrées *.microsoft.com après l’introduction du nouvel affichage « Password Health ». Un correctif a été déployé deux semaines plus tard.
* Janvier 2024 : un lot de comptes Entra ID (Azure AD) synchronisés via le canal Dev a subi un filtre sur les domaines internes, rapidement résolu dans la build 121.0.2288.0.
* Août 2025 : l’incident présent est la troisième occurrence et semble lié à l’activation mondiale du regroupement « Wallet 2.0 ».
Questions fréquentes (FAQ)
Mon mot de passe est‑il perdu ?
Non. Tant que l’auto‑remplissage fonctionne, vos données chiffrées sont intactes.
Puis‑je forcer l’affichage du mot de passe via une extension ?
Non. Les extensions Chrome/Edge n’ont pas accès aux clés DPAPI nécessaires pour déchiffrer les secrets.
La suppression de la ligne microsoft.com et sa recréation règle‑t‑elle le souci ?
Dans la plupart des tests, l’entrée réapparaît masquée après synchronisation. Le problème vient du filtre, pas de l’enregistrement lui‑même.
Conclusion
L’absence d’affichage du mot de passe Microsoft dans le gestionnaire Wallet d’Edge résulte très probablement d’une combinaison entre un durcissement de la sécurité et un bogue d’interface. Les données restent sûres et opérationnelles pour l’auto‑remplissage, mais leur visibilité est temporairement restreinte. La meilleure démarche consiste à :
- remonter un feedback détaillé à Microsoft ;
- suivre attentivement les notes de version des builds Canary puis Stable ;
- appliquer les solutions de contournement (export CSV, profil test, gestionnaire externe) si vous avez besoin d’accéder au mot de passe en clair.
L’expérience passée montre qu’un correctif arrive généralement dans les semaines suivant la détection. En attendant, conservez une copie chiffrée de votre mot de passe dans un outil dédié ou via un alias temporisé.