Un bug vieux de 16 ans découvert dans la base de données au cœur de nos smartphones

En août 2026, l’entreprise de logiciels de réseau Tailscale a publié un rapport d’autopsie (postmortem) révélant que sa base de données principale avait subi 19 corruptions inexpliquées au cours des six mois précédents. Chaque incident entraînait de brèves pannes de réseau pour une partie des utilisateurs, exigeant chaque fois plus d’une heure de restauration. Après des mois d’investigations minutieuses, les ingénieurs ont fini par dénicher le coupable : une condition de concurrence tapie depuis au moins 16 ans dans le moteur de base de données le plus déployé au monde.

Tailscale conçoit des outils permettant de relier des appareils en réseau privé sécurisé. Même si vous n’en avez jamais entendu parler, cette histoire vous concerne directement : le logiciel de base de données au centre du mystère tourne en ce moment même sur votre smartphone.

Le logiciel omniprésent dont vous n’avez jamais entendu parler

Présentons d’abord le protagoniste. SQLite est la base de données la plus utilisée de la planète, présente selon les chiffres officiels sur des milliards d’appareils. Vos applications de messagerie, vos outils bancaires, vos navigateurs web et vos jeux y stockent quotidiennement leurs données.

La grande particularité de SQLite réside dans son architecture “embarquée” (Embedded). Alors qu’une base de données d’entreprise s’apparente au coffre-fort d’une banque nécessitant des gardiens dédiés et un bâtiment distinct (des serveurs dédiés), SQLite ressemble à une petite cassette portative que chaque application transporte avec elle. Pas besoin d’installation, pas de gestionnaire de service à administrer, aucune maintenance. Les développeurs y déposent leurs données et peuvent l’oublier pendant des décennies.

Cette simplicité d’utilisation en a fait le socle invisible du monde numérique. Utilisée par des milliards d’appareils effectuant d’innombrables requêtes, sa fiabilité a été éprouvée maintes et maintes fois, réduisant le risque d’erreur à des probabilités infinitésimales — à tel point que son créateur lui-même pensait certaines parties du code exemptes de tout bug.

Une faille dissimulée dans les fondations

Depuis 2022, Tailscale conservait toutes ses données essentielles dans SQLite parce qu’il s’agissait d’une “technologie ennuyeuse” (Boring Technology) — un terme élogieux dans le jargon technique signifiant que l’outil est prévisible et sans mauvaise surprise. Du début de l’année 2023 jusqu’à l’été 2025, aucun problème n’était à déplorer.

Puis, en août 2025, le système de sauvegarde automatisé a soudainement émis une alerte : un fichier de base de données était corrompu. L’équipe a réparé le fichier et cherché la cause, sans rien trouver. Puis une deuxième corruption est survenue, puis une troisième… jusqu’à atteindre 19 incidents en l’espace de six mois. En ingénierie des systèmes à grande échelle, si la probabilité d’un événement rare est supérieure à zéro, l’augmentation du volume et du nombre de transactions finit par transformer l’exception en routine.

Le plus déroutant était l’absence totale de point commun entre ces 19 incidents : aucun serveur identique, aucun groupe d’utilisateurs spécifique, aucune plage horaire particulière, ni aucune charge de travail similaire. Les ingénieurs n’avaient aucun indice et s’avéraient incapables de reproduire le bug en laboratoire.

”D’abord les carnets, ensuite le grand livre” : Le mode WAL

Pour comprendre l’enquête, il faut connaître un mode de fonctionnement particulier de SQLite appelé WAL (Write-Ahead Log, ou journal d’écriture préalable).

Imaginez un grand livre de comptabilité. Le mode classique consiste à ouvrir directement le grand livre pour y inscrire chaque transaction. Le mode WAL fonctionne différemment : les nouvelles opérations sont d’abord rapidement notées sur un bloc de feuillets volants. Une fois qu’une certaine quantité de feuillets est accumulée, ils sont tous retranscrits dans le grand livre. Les feuillets volants constituent le fichier WAL, le grand livre représente le fichier de base de données principal, et l’action de retranscription porte le nom de checkpoint (point de contrôle).

Fig. : Les nouvelles données sont d’abord écrites dans le fichier WAL, puis transférées vers le fichier de base de données principal. Source : tailscale.com

Les avantages sont évidents : écrire sur un feuillet est bien plus rapide que de modifier un lourd registre, et la retranscription peut se faire de manière asynchrone lors des périodes de calme. De plus, les personnes qui consultent le grand livre ne gênent pas celles qui rédigent de nouveaux feuillets. De nombreuses applications en quête de performance utilisent ce mode. Tailscale l’utilisait également, mais avait pris une décision radicale : déclencher les checkpoints de manière manuelle et extrêmement fréquente pour faciliter les sauvegardes. Cette décision allait devenir la mèche de tout le drame.

Condition de concurrence : La collision de deux opérations

Le mécanisme du bug se résume en une phrase : au moment où la retranscription s’effectuait, une nouvelle écriture a eu lieu simultanément, perturbant l’ordre des opérations. C’est ce qu’on appelle en informatique une condition de concurrence (race condition).

Voici ce qui s’est passé en détail. Le processus de checkpoint a compté 10 feuillets dans le fichier WAL et a commencé à les copier dans le grand livre. Au beau milieu de cette retranscription, une autre opération a ajouté un nouveau feuillet et a réinitialisé le compteur de numérotation des feuillets — d’où le nom attribué au bug : “WAL-Reset”. Le processus de checkpoint, ignorant cette réinitialisation, a continué de copier en se basant sur l’ancienne numérotation. Résultat : une page de données qui n’avait pas encore été retranscrite a été considérée à tort comme “déjà copiée” et a été ignorée.

Fig. : Le processus de checkpoint copie les pages de données du WAL vers le fichier de base de données principal. Source : tailscale.com

Cette écriture comptable a disparu sans laisser de trace. Pire encore, d’autres pages du grand livre conservaient des références (des index) pointant vers cette donnée envolée, poussant SQLite à déclarer l’ensemble de la base de données “corrompue”. Les ingénieurs de Tailscale ont découvert plus tard un chiffre contradictoire dans leurs journaux : le fichier WAL ne contenait à ce moment-là que 10 pages de données, mais le checkpoint affichait fièrement en avoir copié 20. Ces 10 pages supplémentaires n’étaient qu’un mirage causé par la réutilisation de l’ancienne numérotation — l’indice capital qui a permis de résoudre l’énigme.

Pourquoi le bug est-il resté caché 16 ans ?

L’équipe officielle de SQLite estime que ce bug existait dans le code depuis au moins 16 ans. S’il est resté indétectable aussi longtemps, c’est parce que ses conditions de déclenchement étaient follement restrictives : il fallait une combinaison précise de versions de bibliothèques, une transaction d’écriture survenant à la microseconde exacte au milieu d’un checkpoint, ainsi qu’un comportement spécifique du système de fichiers de l’OS. La probabilité que ces trois facteurs se rencontrent en usage classique était, selon le créateur de SQLite, “pratiquement impossible en utilisation normale”.

Pour valider le correctif, les développeurs de SQLite ont même dû insérer une logique de test spéciale au cœur du code pour forcer artificiellement la collision — une mesure exceptionnelle qu’ils n’avaient jamais prise pour aucun autre bug.

La plupart des utilisateurs emploient la configuration par défaut et ne croiseront jamais ce problème. Tailscale l’a rencontré 19 fois parce que sa stratégie de checkpoints à ultra-haute fréquence a démultiplié les probabilités de collision. L’événement “impossible” est devenu chez eux une certitude statistique.

Comment les détectives ont résolu l’affaire

Parmi les nombreux récits d’incidents techniques, cette analyse brille par une rigueur rare.

Pendant les premiers mois, la recherche piétinait. L’examen du code interne ne révélait aucune erreur et le problème restait impossible à reproduire. Une période de calme de six semaines sans le moindre incident est même survenue — prouvant une fois de plus que l’absence de panne ne garantit pas la guérison d’un système. L’équipe a alors pris une décision forte : enregistrer chaque commande de modification de la base de données dans un fichier journal séparé.

Ce journal s’est avéré déterminant. Lors des deux incidents suivants, le rejeu des journaux a révélé une anomalie inédite : une écriture dûment validée devenait ultérieurement “invisible”. Une transaction s’évaporait sans émettre le moindre message d’erreur — une aberration totale dans l’univers des bases de données relationnelles.

C’est alors que l’équipe de développement officielle de SQLite est entrée dans la bataille (Tailscale ayant souscrit un contrat de support commercial). Ensemble, ils ont conçu un outil de diagnostic sur mesure baptisé tmstmpvfs shim (un shim désigne une couche de surveillance entourant un composant existant). L’architecture de SQLite se divise schématiquement en trois niveaux : la couche haute interprète les commandes SQL, la couche intermédiaire découpe les données en blocs, et la couche basse se charge d’écrire physiquement sur le disque — cette couche basse s’appelle le VFS (Virtual File System). Le shim est venu envelopper le VFS pour enregistrer chaque lecture et écriture sur disque à la manière d’une caméra de surveillance haute vitesse installée devant un coffre-fort.

Fig. : L’interface de stockage de plus bas niveau de SQLite enveloppée dans une couche de surveillance (shim). Source : tailscale.com

Une fois la caméra installée, il ne restait plus qu’à attendre le prochain incident. L’attente fut courte. Dès la panne suivante, les enregistrements complets ont été transmis aux développeurs principaux de SQLite, et la condition de concurrence a été prise la main dans le sac : en plein milieu du checkpoint, une écriture réinitialisait le WAL sans que le checkpoint ne s’en aperçoive.

Presque simultanément, un autre front apportait une confirmation décisive. La société Antithesis, spécialisée dans les tests logiciels, est parvenue à reproduire le bug de manière indépendante grâce au property-based testing (tests basés sur les propriétés). En générant automatiquement d’immenses séquences d’opérations aléatoires d’écritures et de checkpoints simultanés, l’outil a surveillé deux règles absolues : “une écriture validée ne doit jamais être perdue” et “la base de données ne doit jamais être corrompue”. L’outil a détecté la faille sur les anciennes versions et validé le bon comportement sur les nouvelles. Ce qu’aucun esprit humain n’aurait pu imaginer, la machine l’a découvert par épuisement combinatoire.

Le correctif et une fausse alerte

La réparation elle-même n’a nécessité qu’une seule modification dans le code : l’ajout d’une vérification explicite dans la fonction de checkpoint pour s’assurer qu’aucun autre thread n’avait réinitialisé l’état du WAL, interrompant proprement le processus le cas échéant. La correction a été publiée avec la version 3.51.3 de SQLite.

Mais l’histoire réservait un dernier rebondissement. Lorsque Tailscale a déployé la version corrigée, les tableaux de bord de surveillance ont viré au rouge sang avec des alerte de corruption en masse. Il s’agissait heureusement d’une fausse alerte : une anomalie d’index ancienne et mineure, générée par de précédentes versions, avait été mise en lumière par une optimisation de la nouvelle mouture. L’équipe de SQLite a immédiatement retiré cette version pour publier un build propre ne contenant que le correctif du WAL-Reset. Tailscale a de son côté ajusté la structure de ses données pour contourner le problème secondaire. Réparer un bug en fait souvent émerger un autre — une réaction en chaîne classique en ingénierie logicielle.

La démarche s’est conclue par une étape cruciale. Afin de confirmer que le bug s’était bel et bien produit dans leur environnement réel, Tailscale a ajouté une alerte enregistrant chaque collision entre une écriture et une réinitialisation de WAL. Après deux mois de silence radio, l’alarme a retenti — apportant la preuve irréfutable que le bug vieux de 16 ans avait tenté de frapper à nouveau en production, mais avait été neutralisé par le correctif. Au cours des quatre mois suivants, plus aucune corruption de base de données n’a été constatée.

Les composants les plus fiables méritent les contrôles les plus stricts

Ce récit offre une leçon précieuse pour l’ingénierie logicielle. SQLite fait partie des logiciels les plus respectés au monde ; aucune entreprise ne remet en question sa fiabilité au moment d’initier un projet. C’est pourtant cette confiance aveugle qui a permis à un bug critique de sommeiller pendant 16 ans sur des milliards d’appareils. Lorsque les fondations flanchent, tout l’édifice supérieur vacille, et personne ne pense à examiner le sol.

L’attitude transparente des ingénieurs de Tailscale a suscité le respect de toute la communauté technique. Dans les commentaires, le mot le plus récurrent était “refreshing” (rafraîchissant) : loin de rejeter la faute sur autrui, l’entreprise a souscrit un support officiel, financé le développement d’outils de débogage open source et partagé ses découvertes avec l’ensemble des développeurs.

Voir une entreprise financer des outils de diagnostic sur mesure pour un projet open source reste trop rare dans le monde d’aujourd’hui. Pour les utilisateurs ordinaires, cette histoire rappelle que derrière les logiciels invisibles qui fonctionnent sans relâche au fond de nos téléphones se trouvent des ingénieurs passionnés, prêts à traquer pendant six mois un dysfonctionnement “pratiquement impossible”.

Un bug vieux de 16 ans a enfin été éliminé. Mais où se cache le prochain ? Peut-être attend-il silencieusement au cœur de l’application à laquelle vous faites le plus confiance.

Liens de référence :

• Tailscale : Autopsie du bug WAL-Reset de SQLite
• Antithesis : Breaking the WAL
• Discussion HN (item?id=49272832)