08.10.2026 · Signal Titans Editorial

Richard Hipp voulait une base de données sans serveur qui puisse tomber en panne. SQLite tourne aujourd’hui presque partout.

D. Richard Hipp à gauche, au-dessus d'une ville aux toits rouges, avec une icône minimaliste d'une base de données qui devient un simple fichier.

En 2000, D. Richard Hipp écrivait un logiciel de contrôle des avaries pour un destroyer lance-missiles de la marine américaine, le DDG-79 Oscar Austin, en tant que sous-traitant d'un projet de Bath Iron Works. L'application stockait ses données dans une base Informix qui fonctionnait comme un serveur distinct. Quand ce serveur était indisponible, le logiciel ne pouvait pas fonctionner. Les utilisateurs voyaient une boîte de dialogue indiquant l'impossibilité de se connecter, et c'est l'équipe de l'application qui était mise en cause.

La réaction de Hipp est devenue l'une des questions de conception les plus lourdes de conséquences du logiciel moderne : pourquoi un tel programme aurait-il besoin d'un serveur de base de données ?

Une base de données qui n'est qu'une bibliothèque

La plupart des bases de données de l'époque suivaient le modèle client-serveur. Le moteur fonctionnait comme un processus à part, souvent sur sa propre machine, et les applications dialoguaient avec lui par une connexion. Cette architecture est excellente pour de nombreux systèmes partagés et multi-utilisateurs. Mais elle crée aussi une dépendance. Si le serveur, le réseau ou la configuration tombe en panne, l'application tombe avec eux.

L'alternative de Hipp consistait à placer le moteur SQL à l'intérieur même de l'application. Plus de processus serveur à installer, démarrer, administrer ou avec lequel perdre le contact. Le programme lirait et écrirait un fichier ordinaire sur le disque, grâce à une bibliothèque liée directement dans son propre code.

Une interruption du financement public a laissé Hipp sans contrat pendant quelques mois, et un collègue lui a suggéré d'écrire enfin le moteur qu'il décrivait sans cesse. Selon Hipp, le premier code a été versé dans le dépôt le 29 mai 2000. La première version publique a suivi en août 2000. Cette version initiale stockait ses données avec GDBM, le gestionnaire de bases de données de GNU. SQLite 2.0, publié en 2001, a remplacé GDBM par une couche de stockage en B-tree écrite par Hipp lui-même et a ajouté les transactions.

Pourquoi le domaine public a compté

Comme la version 1.0 dépendait de GDBM, elle relevait de fait de la GPL. Lorsqu'il a écrit le nouveau moteur de stockage, Hipp a choisi de n'utiliser aucune licence open source. Le code et la documentation de SQLite ont été versés dans le domaine public.

Cette décision a abaissé les barrières pour les entreprises à un degré rare. Un fabricant pouvait intégrer SQLite dans un téléphone, un navigateur ou un système automobile sans négocier de licence ni suivre de clauses d'attribution. Pour les organisations dont les juristes veulent malgré tout un document formel, la société de Hipp, Hwaci, vend une « Warranty of Title », une garantie juridique que les auteurs avaient le droit de verser le code dans le domaine public. L'argent finance le développement. Le code, lui, reste libre.

D'un projet annexe aux téléphones

Le premier intérêt commercial sérieux est venu de l'industrie mobile. Hipp raconte que Motorola l'a appelé vers 2001 ou 2002 pour utiliser SQLite dans un système d'exploitation de téléphone, et qu'il a demandé environ 80 000 dollars, une somme qui représentait alors tout pour lui. AOL le voulait aussi. Symbian a ensuite comparé plusieurs moteurs de bases de données pour sa plateforme mobile et a choisi SQLite.

Symbian a alors soulevé une inquiétude sérieuse : un projet maintenu par si peu de personnes avait un « bus factor » faible. La réponse a été le SQLite Consortium. Sur les conseils de Mitchell Baker, de Mozilla, il a été structuré de sorte que les membres financent le développement tandis que les développeurs gardent le contrôle du code. Mozilla, Symbian et Adobe figuraient parmi les membres fondateurs.

Vers 2005, Hipp a vu un premier prototype d'Android lors d'une séance de débogage. Il a dit plus tard qu'il avait su que la plateforme deviendrait énorme. Android a fini par installer SQLite sur chaque appareil où il tournait.

Apprendre à tester comme dans l'aéronautique

Le déploiement massif a fait apparaître un autre problème : les bogues atteignaient des millions d'appareils. Le tournant est venu de Rockwell Collins, qui a fait découvrir à Hipp DO-178B, une norme utilisée pour les logiciels aéronautiques critiques pour la sécurité. Elle exige notamment une couverture de tests MC/DC de 100 %, c'est-à-dire montrer que chaque condition de chaque décision influence à elle seule le résultat.

Hipp a consacré environ un an, à raison de longues semaines de travail, à porter les tests de SQLite à ce niveau. Il a dit qu'ensuite, les rapports de bogues venus d'Android avaient pratiquement cessé.

La culture du test reste le trait le plus frappant de SQLite. La documentation du projet indique qu'avec la version 3.42.0, la bibliothèque comptait environ 155 800 lignes de C, tandis que les tests et scripts de test représentaient environ 590 fois plus de code. Les suites simulent volontairement des manques de mémoire, des erreurs d'E/S, des plantages et des coupures de courant en pleine écriture, puis vérifient que le fichier de base de données n'a pas été corrompu.

Jusqu'où une petite idée a voyagé

Le projet SQLite se présente, avec beaucoup de précautions, comme probablement le moteur de base de données le plus déployé. Sa documentation cite parmi ses utilisateurs tous les appareils Android et iOS, tous les Mac et toutes les installations de Windows 10/11, ainsi que les principaux navigateurs web. Elle estime qu'il y a probablement plus de mille milliards de bases SQLite en service. Ce chiffre est déduit du nombre de smartphones et non mesuré, mais même comme estimation grossière, il place SQLite parmi les composants logiciels les plus utilisés au monde.

Ce moteur ne remplace pas les bases client-serveur dans tous les cas. Les grands systèmes multi-utilisateurs à forte concurrence ont toujours de bonnes raisons d'utiliser un serveur dédié. La documentation de SQLite le dit elle-même. Sa force est ailleurs : pour l'immense nombre d'applications qui ont besoin d'un stockage structuré fiable sur un seul appareil, le serveur le plus robuste s'est révélé être l'absence de serveur.

La leçon de conception

Hipp ne cherchait pas à construire la base de données la plus répandue au monde. Il voulait supprimer un mode de défaillance d'une application embarquée sur un navire. L'idée qui a duré : considérer une dépendance comme un risque avant de la considérer comme une fonctionnalité.

Beaucoup de problèmes logiciels se résolvent en ajoutant un composant : un cache, un service, une file d'attente, un serveur. L'histoire de SQLite rappelle que le geste le plus durable consiste parfois à se demander quel composant on peut retirer, puis à tester ce qui reste comme si des vies en dépendaient.