Les mots de passe enregistrés dans Chrome peuvent disparaître de l’interface après une mise à jour sans que les données soient réellement effacées. Le fichier Login Data du profil Chrome local conserve souvent les entrées chiffrées, même quand le gestionnaire de mots de passe affiche une liste vide. Avant toute manipulation, la distinction entre perte d’affichage et perte de données oriente la récupération.
Fichier Login Data et chiffrement App-Bound : pourquoi Chrome masque vos mots de passe
Chrome stocke les identifiants dans une base SQLite nommée Login Data, située dans le dossier du profil utilisateur (sous Windows : %LocalAppData%\Google\Chrome\User Data\Default). Chaque entrée est chiffrée via DPAPI, liée au compte Windows actif.
Les versions récentes de Chrome ajoutent une couche supplémentaire, l’App-Bound encryption (v20). Ce mécanisme attache le déchiffrement au binaire Chrome lui-même. Si une mise à jour corrompt le fichier Local State (qui contient la clé de chiffrement app-bound), Chrome ne peut plus lire les mots de passe, même s’ils existent physiquement dans Login Data.
Nous observons régulièrement cette situation après des mises à jour majeures : le profil local est intact, les entrées sont présentes dans la base, mais l’interface du gestionnaire reste vide. Le problème n’est pas une suppression, c’est un échec de déchiffrement.
Vérifier passwords.google.com avant de toucher au profil local
Le premier réflexe technique n’est pas d’ouvrir Chrome, mais de consulter le coffre cloud. Rendez-vous sur passwords.google.com depuis n’importe quel navigateur, connecté au même compte Google que celui utilisé dans Chrome.
Si vos identifiants apparaissent dans le coffre en ligne, la donnée Google est intacte. Le problème se limite au profil local ou à la synchronisation. Deux cas de figure :
- La synchronisation Chrome est active mais bloquée : déconnectez puis reconnectez le compte Google dans les paramètres Chrome (Paramètres > Vous et Google > Désactiver, puis réactiver la synchronisation).
- La synchronisation était désactivée : les mots de passe n’existaient qu’en local, dans le fichier Login Data. La récupération passe par la manipulation du profil décrite ci-dessous.
- Le coffre cloud est vide alors que vous aviez des mots de passe : la synchronisation n’a jamais été activée, ou une passphrase de synchronisation bloque le transfert. Vérifiez dans Paramètres > Vous et Google > Synchronisation si une passphrase personnalisée est configurée.
Récupération via le profil Chrome local sous Windows
Cette procédure s’applique quand les mots de passe ne sont ni dans le coffre cloud ni dans l’interface Chrome, mais potentiellement encore dans Login Data.
Étape préalable : fermer tous les processus Chrome
Ouvrez le Gestionnaire des tâches et terminez chaque processus Google Chrome. Le fichier Login Data est verrouillé tant qu’une instance tourne.
Manipuler le dossier de profil
Accédez à %LocalAppData%\Google\Chrome\User Data. Renommez le fichier Local State (par exemple en Local State.bak). Renommez le dossier Default en Default.bak.
Relancez Chrome : il crée automatiquement un nouveau profil vierge avec un nouveau Local State et un nouveau dossier Default. Fermez Chrome à nouveau.
Copiez le fichier Login Data depuis Default.bak vers le nouveau dossier Default. Relancez Chrome. Si le fichier Login Data n’était pas corrompu et que la clé de chiffrement DPAPI est toujours valide (même session Windows, même utilisateur), les mots de passe réapparaissent dans le gestionnaire.
Quand le déchiffrement échoue
Si les mots de passe ne réapparaissent pas après cette manipulation, le problème vient de l’App-Bound encryption. Les entrées chiffrées en v20 sont orphelines : la clé liée à l’ancienne version du binaire Chrome ne correspond plus. Il n’existe pas de contournement officiel pour reconnecter ces entrées.
Dans ce cas, les données locales sont irrécupérables par cette méthode. La seule option reste le coffre cloud ou un export CSV antérieur.
Exporter en CSV après récupération : sécuriser avant le prochain incident
Si la manipulation a fonctionné et que vos identifiants sont de nouveau visibles, exportez-les immédiatement. Allez dans Paramètres > Saisie automatique et mots de passe > Gestionnaire de mots de passe Google, puis sélectionnez Exporter.
Chrome génère un fichier CSV en clair contenant l’ensemble des identifiants. Ce fichier doit être stocké dans un emplacement chiffré (volume VeraCrypt, coffre-fort numérique, gestionnaire de mots de passe tiers). Ne le laissez jamais sur le bureau ou dans un dossier non protégé.
Nous recommandons de programmer cet export après chaque ajout significatif de mots de passe. Un export CSV récent rend toute corruption de profil indolore, puisque vous pouvez réimporter les données dans un profil neuf ou dans un gestionnaire dédié.
Mise à jour Chrome de juillet 2024 : le bug du gestionnaire de mots de passe
Un incident documenté a touché le gestionnaire de mots de passe Chrome sur Windows dans la nuit du 24 juillet 2024. Un bug dans le code d’une mise à jour a rendu les mots de passe inaccessibles pendant près de 18 heures. Google a déployé un correctif, mais les utilisateurs qui avaient réinstallé Chrome entre-temps ont parfois perdu leur profil local.
Ce type d’incident renforce un constat : déléguer le stockage de tous ses identifiants au navigateur crée un point de défaillance unique. Un gestionnaire de mots de passe indépendant (Bitwarden, KeePass, 1Password) n’est pas affecté par les mises à jour Chrome et conserve sa propre base chiffrée.
La disparition de mots de passe après mise à jour Chrome relève dans la majorité des cas d’un problème de profil local, pas d’une suppression côté serveur. Vérifier le coffre cloud en premier, manipuler Login Data en second, et maintenir un export CSV à jour couvre les scénarios les plus fréquents. Pour les entrées chiffrées en App-Bound encryption v20 sans clé valide, la récupération locale reste une impasse technique que Google n’a pas documentée.
