La base de données "History" de Chrome est corrompue

Votre historique n'est pas stocké dans un quelconque format propriétaire — c'est une base de données SQLite qui réside dans le répertoire de profil de Chrome : sous Windows %LOCALAPPDATA%\Google\Chrome\User Data\Default\History, sous macOS ~/Library/Application Support/Google/Chrome/Default/History et sous Linux ~/.config/google-chrome/Default/History (Chromium utilise ~/.config/chromium/…, Edge …/Microsoft/Edge/…, Brave …/BraveSoftware/Brave-Browser/…). Le fichier s'appelle History sans extension, et c'est pour cela que beaucoup de gens ne réalisent pas qu'ils peuvent l'ouvrir dans n'importe quel outil SQLite — renommez une copie en History.db et DB Browser for SQLite la lira immédiatement.

À l'intérieur se trouvent les tables qui composent votre registre de navigation. urls conserve une ligne par page que vous avez visitée — ses colonnes sont id, url, title, visit_count, typed_count, last_visit_time et hidden. visits est la chronologie : chaque ligne possède une clé étrangère url qui pointe de nouveau vers urls.id, un visit_time, un from_visit qui désigne la visite précédente (c'est ainsi que se reconstruisent les chaînes précédent/suivant) et un masque de bits transition dont l'octet de poids faible est le type principal (LINK = 0, TYPED = 1, AUTO_BOOKMARK = 2, RELOAD = 8). À leurs côtés se trouvent keyword_search_terms, downloads et downloads_url_chains, segments/segment_usage (qui alimentent les raccourcis de la page Nouvel onglet) et une petite table meta avec les lignes version et last_compatible_version qui indiquent à Chrome quel schéma il regarde.

Un détail fait trébucher tous ceux qui exportent leur historique : les horodatages ne sont pas du temps Unix. last_visit_time et visit_time sont stockés en microsecondes depuis le 1601-01-01 00:00:00 UTC (l'époque de Chrome/WebKit). Pour lire l'un d'eux comme une date normale, vous divisez par 1 000 000 et vous soustrayez 11 644 473 600 secondes. La récupération conserve les entiers bruts exactement tels qu'ils se trouvent sur le disque, si bien que les dates survivent à la reconstruction — il vous suffit de les convertir ensuite.

Une base de données SQLite est un tableau plat de pages de taille fixe — Chrome utilise la valeur par défaut de 4096 octets. La page 1 porte l'en-tête et le schéma ; chaque table, y compris urls et visits, est un arbre-B dont les pages internes pointent vers les pages feuilles qui contiennent vos lignes réelles. Chrome exécute la base de données History en mode WAL (write-ahead logging), si bien qu'à côté vous verrez normalement des fichiers frères nommés History-wal et History-shm ; les versions plus anciennes et certains profils laissent à la place un journal d'annulation (rollback journal) appelé History-journal.

Cette machinerie de fichiers annexes est justement l'endroit par où le dommage se faufile. Si la machine perd le courant, que le disque se remplit ou que Chrome est tué en plein checkpoint, une frame du WAL peut n'être réécrite qu'à moitié dans le fichier principal — une seule page interne se retrouve avec un pointeur de cellule incohérent ou un nombre de pages qui ne correspond pas à la taille du fichier. SQLite suit ce pointeur, tombe sur quelque chose qui n'est pas une page d'arbre-B valide et s'arrête avec Error: database disk image is malformed (11) — code de résultat SQLITE_CORRUPT. Lancez PRAGMA integrity_check et vous verrez les détails : des lignes comme *** in database main ***, Page 214: btreeInitPage() returns error code 11, row 1803 missing from index urls_url_index ou wrong # of entries in index visits_url_index.

L'essentiel : le moteur s'arrête à la première incohérence, mais les pages qu'il n'a jamais atteintes sont généralement parfaites, et vos lignes reposent toujours intactes dans leurs pages feuilles. C'est la même histoire que l'index moov manquant d'une vidéo ou le répertoire central cassé d'un ZIP — c'est la carte qui s'est brisée, pas les données. Voilà pourquoi une reconstruction au niveau des pages récupère autant là où ouvrir le fichier normalement ne récupère rien.

On ne répare pas un fichier History corrompu sur place — on lit tout ce qui est encore décodable et on l'écrit dans une base de données toute neuve, exactement comme le fait la commande .recover de SQLite elle-même. Le scanner lit chaque page localement, reconstruit le schéma à partir des définitions qui ont survécu, puis parcourt l'arbre-B de chaque table et décode les enregistrements auto-descriptifs de ses pages feuilles. Les lignes que la chaîne de pointeurs ne peut plus atteindre sont retrouvées par un balayage brut des pages, et tout ce qui se décode mais ne correspond à aucune table connue est écrit dans une table lost_and_found plutôt que jeté.

En pratique, cela ramène l'essentiel de votre historique : la table urls (adresses, titres de page, visit_count, last_visit_time), la chronologie visits avec ses types de transition et ses chaînes from_visit, et — là où leurs pages sont intactes — keyword_search_terms, downloads et les données de segments. Si vous avez encore le fichier annexe History-wal, ajoutez-le dans l'emplacement optionnel après avoir déposé le fichier principal : ses frames validées (committed) sont superposées avant l'analyse, de sorte que la reconstruction reflète la dernière transaction validée plutôt que le dernier checkpoint — souvent les toutes dernières heures de navigation. Le résultat est un fichier SQLite neuf et ouvrable que vous téléchargez ; renommez-le en History, déposez-le dans le dossier du profil pendant que Chrome est fermé, et votre historique réapparaît, ou interrogez-le simplement dans n'importe quelle visionneuse SQLite.

La récupération renvoie ce qui est physiquement présent ; elle ne peut pas inventer ce qui a été écrasé. Les lignes qui ont été tronquées à la fin du fichier, ou dont les pages ont été réutilisées après une suppression, ont disparu — aucun outil ne peut les ramener. La plus grande perte avec Chrome en particulier, c'est le temps : quand Chrome ouvre un fichier History qu'il considère comme corrompu, il le supprime fréquemment et en crée un neuf et vide sur-le-champ, de sorte que l'original endommagé est écrasé sur place. Si cela s'est déjà produit, fermez Chrome immédiatement et récupérez depuis une sauvegarde ou une copie de l'ancien History/History-wal — le fichier vide qui l'a remplacé n'a rien à l'intérieur à trouver.

Deux réserves plus mineures, dites clairement. Les valeurs récupérées reviennent sous leur classe de stockage sur disque, si bien que l'affinité déclarée d'une colonne peut ne pas être réappliquée — les horodatages restent les bons entiers en microsecondes, il vous suffit de les convertir vous-même. Et les données récupérées d'une base de données corrompue sont toujours suspectes : la documentation de SQLite elle-même le dit, et comme un balayage brut lit aussi les pages de la liste libre (freelist), une URL supprimée auparavant peut de temps en temps refaire surface. Le rapport de récupération indique table par table ce qui est ressorti et ce qui a été extrait par le balayage brut. Rien de tout cela n'a besoin d'un serveur : le fichier History — qui est une carte de tous les endroits où vous êtes allé — est lu depuis votre disque et reconstruit dans votre onglet, et vous pouvez surveiller l'onglet Réseau pour confirmer que 0 octet ne sort.