Comment ouvrir un fichier .db : visionneuses SQLite pour Windows, macOS et Linux

Tu double-cliques sur un fichier .db et ton ordinateur soit ne fait rien, soit ouvre la mauvaise appli, soit t'affiche un mur de texte illisible. Si c'est pour ça que tu es ici, la réponse courte est la suivante : un fichier .db est presque toujours une base de données SQLite, et il existe quatre façons pratiques d'en ouvrir une — la ligne de commande sqlite3, DB Browser for SQLite, DBeaver, ou un panneau d'administration local-first comme BaseVolt. Lequel tu veux dépend de si tu jettes un œil aux données une seule fois ou si tu travailles vraiment avec.

Mais « presque toujours » fait un vrai travail dans cette phrase, donc avant de te tendre un outil, passons trente secondes à confirmer ce que tu as vraiment. L'extension .db n'est pas un standard — c'est une convention, et plein d'autres logiciels l'utilisent aussi. Ouvrir un fichier non-SQLite avec un outil SQLite est la raison la plus fréquente pour laquelle les gens pensent qu'un outil est cassé alors qu'il ne l'est pas.

Voici comment vérifier, puis on passera en revue chaque façon d'ouvrir le fichier.

D'abord, confirme qu'il s'agit bien de SQLite

Chaque fichier de base de données SQLite commence par les mêmes 16 octets : la chaîne ASCII SQLite format 3 suivie d'un octet nul. C'est ce qu'on appelle l'en-tête magique, et c'est ainsi que SQLite lui-même reconnaît ses propres fichiers. Si ces octets sont là, tu as une base de données SQLite quel que soit le nom du fichier. S'ils n'y sont pas, tu n'en as pas.

Sur macOS ou Linux, le moyen le plus rapide de vérifier est la commande file :

file mydata.db
# mydata.db: SQLite 3.x database, last written using SQLite version 3045000

file lit l'en-tête magique pour toi et te le dit tout de suite. S'il indique SQLite 3.x database, c'est réglé — c'est un fichier SQLite. S'il indique autre chose — data, Microsoft Access, Paradox, Zip archive, ASCII text — alors tu as affaire à un format complètement différent.

Si tu veux voir les octets bruts toi-même, sur macOS ou Linux :

head -c 16 mydata.db
# SQLite format 3

Ou avec xxd :

xxd -l 16 mydata.db
# 00000000: 5351 4c69 7465 2066 6f72 6d61 7420 3300  SQLite format 3.

Sur Windows, PowerShell peut faire la même chose sans outils supplémentaires :

Get-Content -Path .\mydata.db -Encoding Byte -TotalCount 16 | ForEach-Object { [char]$_ }
# S Q L i t e   f o r m a t   3

Si l'en-tête est là, félicitations — tout ce qui suit s'applique à toi. S'il n'y est pas, continue à lire un instant, car il y a quelques imposteurs courants.

Que faire si ce n'est pas du SQLite

Un fichier nommé something.db qui n'est pas une base de données SQLite est généralement l'un de ceux-ci :

Une base de données Microsoft Access. Les fichiers Access sont généralement en .mdb ou .accdb, mais les gens les renomment en .db tout le temps. Si file le signale comme une base de données Microsoft Access, il te faut Access ou un outil qui comprend le format Jet/ACE — pas un outil SQLite.
Une base de données Paradox. Le Paradox de Borland utilisait .db pour ses fichiers de table, et on les retrouve dans de vieux logiciels de bureau. Chaque .db est une table, et il te faut un lecteur Paradox ou un pilote ODBC.
Une base de données d'application propriétaire. Certaines applis de bureau, surtout les plus anciennes, déversent leur état dans un fichier avec une extension .db en utilisant leur propre format. Celles-ci ne s'ouvrent avec rien d'autre que l'appli qui les a écrites, et parfois même pas.
Un fichier SQLite avec un nom non standard. Le cas inverse : ton fichier peut être du SQLite mais nommé .sqlite, .sqlite3, .db3, .s3db, ou sans extension du tout. SQLite se moque du nom de fichier. Si l'en-tête magique est présent, c'est du SQLite quel que soit le nom.

Ce dernier point mérite d'être souligné : .db, .sqlite, .sqlite3 et .db3 ne sont que des conventions. Le format de fichier est identique. L'extension n'existe que pour aider les humains et pour permettre à ton système d'exploitation de choisir une application par défaut. Si ton fichier est du SQLite mais nommé data.txt, un outil SQLite l'ouvrira quand même — tu devras juste peut-être pointer l'outil explicitement vers le fichier plutôt que de double-cliquer.

Quatre façons d'ouvrir un fichier .db

Maintenant qu'on sait que c'est du SQLite, voici les quatre outils que j'utilise vraiment, à peu près dans l'ordre de « le plus rapide à attraper » à « le plus utile pour un travail suivi ». Chacun a une forme différente, et le bon dépend de si tu fais une requête ponctuelle ou si tu vis dans cette base de données un moment.

1. La ligne de commande `sqlite3`

Le shell sqlite3 est l'implémentation de référence, il est livré avec la plupart des systèmes de type Unix, et c'est le moyen le plus rapide de répondre à une question sur une base de données sans rien installer. La documentation officielle est sur sqlite.org/cli.html, et ça vaut le coup d'y jeter un œil si tu utilises la CLI plus qu'occasionnellement.

S'il n'est pas déjà installé :

macOS : il est préinstallé. Ouvre simplement le Terminal et tape sqlite3.
Linux : installe-le depuis ton gestionnaire de paquets — sudo apt install sqlite3 sur Debian/Ubuntu, sudo dnf install sqlite sur Fedora.
Windows : télécharge les outils précompilés depuis le site de SQLite, ou utilise winget install SQLite.SQLite ou le paquet sqlite3 de Chocolatey.

Pour ouvrir un fichier, passe-le en argument. Si le fichier n'existe pas, SQLite en crée un vide — donc fais attention à taper le nom correctement, sinon tu obtiendras silencieusement une nouvelle base de données vide :

sqlite3 mydata.db

Une fois dedans, tu es dans un shell interactif. Certaines commandes commencent par un point — ce sont des méta-commandes gérées par le shell lui-même, pas du SQL envoyé à la base de données. L'essentiel :

-- List all tables in the database
.tables

-- Show the CREATE statement for every table (the full schema)
.schema

-- Show the schema for one table
.schema users

-- Make the output readable (boxed table instead of pipe-delimited)
.mode box

-- Turn on column headers
.headers on

-- Now run an actual query
SELECT id, email, created_at FROM users ORDER BY created_at DESC LIMIT 10;

-- Get the row count of a table
SELECT COUNT(*) FROM users;

-- Exit
.quit

Le mode de sortie par défaut est list, qui entasse tout dans des lignes séparées par des barres verticales et qui s'enroule horriblement quand tes colonnes sont larges. Passer à .mode box est la plus grande amélioration du confort d'utilisation dans la CLI (.mode column est plus compact mais tronque les valeurs longues).

Quelques méta-commandes de plus qui valent leur place :

-- Import a CSV into an existing table
.mode csv
.import data.csv users

-- Export a query result to a file
.output results.txt
SELECT * FROM orders WHERE total > 100;
.output stdout

-- Show how the database is configured (page size, journal mode, etc.)
.dbinfo

-- Back up the database to another file while it's open
.backup backup.db

La CLI est imbattable pour la vitesse et le scripting — tu peux y envoyer des requêtes par pipe depuis des scripts shell et des tâches cron. Sa faiblesse, c'est tout le reste. Parcourir les données est désagréable, modifier une valeur signifie écrire un UPDATE et réussir sa clause WHERE, et il n'y a aucune notion de relation ou de vue. C'est un outil de précision : je l'attrape constamment pour l'inspection et l'automatisation, rarement pour un vrai travail sur les données.

2. DB Browser for SQLite

Si tu veux un outil graphique et que seul SQLite t'intéresse, DB Browser for SQLite est le point de départ évident. Il est gratuit, open source, multiplateforme (Windows, macOS, Linux), et il existe depuis assez longtemps pour être vraiment stable. Tu peux le récupérer sur sqlitebrowser.org.

Le flux de travail est simple : lance-le, clique sur « Open Database », choisis ton fichier .db, et tu obtiens une interface à onglets avec quatre zones principales — Database Structure (le schéma, les tables, les index, les vues), Browse Data (une grille des lignes de n'importe quelle table), Edit Pragmas (mode journal, clés étrangères et les autres réglages) et Execute SQL (un éditeur de requêtes).

Ce qu'il fait bien :

La navigation. La vue grille est rapide et lisible, avec une zone de filtre par colonne. Rien que ça le rend meilleur que la CLI pour regarder des données.
L'édition légère. Tu peux double-cliquer sur une cellule et modifier une valeur directement, puis écrire la modification sur le disque. Utile pour corriger une faute de frappe ou une ligne bancale.
L'inspection du schéma. L'onglet Database Structure te montre exactement ce qui est défini, ce qui est idéal pour une base de données que tu as héritée et que tu ne comprends pas.
L'exécution de requêtes ponctuelles. L'onglet Execute SQL a la coloration syntaxique et sauvegarde ton historique de requêtes.

Les limites valent la peine d'être connues avant de t'y engager :

C'est une visionneuse/un éditeur, pas une interface d'administration. Tu ne peux pas construire de vue personnalisée, de dashboard ou de tableau kanban. Ce que tu vois, c'est ce que l'outil décide de te montrer.
Il est réservé à SQLite. Si tu travailles aussi avec PostgreSQL ou MySQL, il te faudra un second outil.
L'édition directe est impitoyable. Quand tu modifies une cellule et valides, ça écrit directement dans le fichier. Pas d'annulation, pas d'aperçu, pas de « tu es sûr ? ». Sur une base de données qui compte, c'est un vrai risque.
Les relations sont limitées. Il montre les clés étrangères qui existent dans le schéma, mais il ne t'aide pas à travailler avec des relations qui n'ont jamais été formalisées — ce qui, comme je l'ai déjà écrit, est le cas de la plupart des bases de données SQLite du monde réel.
Il peut retenir un verrou d'écriture. Comme tout outil qui ouvre la base de données en écriture, DB Browser peut bloquer ton application si tu le laisses ouvert sur le même fichier. On en reparle dans la section de dépannage.

Pour une tâche ponctuelle du type « qu'y a-t-il dans ce fichier ? », DB Browser est excellent. Pour un travail suivi, il a tendance à donner l'impression d'une appli de bureau qui a dix ans — parce que c'en est une, et elle n'a pas beaucoup changé depuis.

3. DBeaver

DBeaver est un client SQL polyvalent — il parle à SQLite, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server et des dizaines d'autres via une seule interface. Il est gratuit (Community Edition) et open source, et tu peux le récupérer sur dbeaver.io. Si tu utilises déjà une demi-douzaine de moteurs de base de données, avoir un seul client pour tous est vraiment précieux, et c'est pourquoi DBeaver a un public aussi fidèle. (Voir la page de comparaison DBeaver pour une analyse plus complète.)

Ouvrir un fichier SQLite se fait en deux étapes, et c'est sur la deuxième que les gens bloquent :

Crée une nouvelle connexion et choisis SQLite comme pilote.
Pointe-la vers ton fichier .db.

Comme DBeaver est construit sur l'écosystème Java, il parle à SQLite via un pilote JDBC. La Community Edition télécharge généralement le pilote pour toi la première fois que tu te connectes, mais si tu es hors ligne ou derrière un pare-feu, tu devras fournir le JAR du pilote toi-même. C'est le point de friction le plus courant avec DBeaver et SQLite, et ça vaut le coup de le savoir avant de commencer.

Une fois connecté, DBeaver t'en donne beaucoup :

Un véritable éditeur de requêtes avec autocomplétion, formatage et plusieurs onglets de résultats.
La navigation dans le schéma dans une arborescence, avec tables, colonnes, index et contraintes.
L'édition de données dans une grille, avec la possibilité de générer le SQL de tes modifications avant de les exécuter.
Des diagrammes ER qui visualisent les tables et leurs clés étrangères.
L'export et l'import dans une large gamme de formats — CSV, JSON, SQL, et plus.

Le compromis, c'est que DBeaver a la forme d'un IDE. C'est une grosse application, elle met du temps à démarrer, l'interface a beaucoup de surface, et elle est conçue pour les gens qui vivent dans les bases de données toute la journée. Si tout ce que tu veux, c'est regarder le contenu d'un seul fichier .db, DBeaver est un bien gros outil pour le boulot.

L'autre chose sur laquelle être honnête : comme DB Browser, DBeaver est un client de base de données, pas un panneau d'administration. Il te montre les tables brutes. Il ne te donne pas de vues galerie, de tableaux kanban ou de dashboards, et il ne t'aidera pas à travailler avec des relations qui ne sont pas dans le schéma.

4. Un panneau d'administration local-first (BaseVolt)

La quatrième option est une catégorie plus récente, et c'est celle que j'ai fini par utiliser le plus pour le vrai travail. Un panneau d'administration local-first est une appli de bureau qui tourne entièrement sur ta machine, pointe vers ta base de données et te donne une interface soignée pour parcourir et modifier — le genre d'interface que tu devrais normalement construire toi-même ou obtenir en téléversant tes données vers un SaaS.

BaseVolt est celui que j'utilise, donc je vais le décrire concrètement. C'est une appli de bureau local-first pour macOS (Apple Silicon) et Windows. Elle tourne entièrement sur ta machine, fonctionne hors ligne, chiffre tes identifiants localement et n'envoie jamais tes données nulle part — tout reste sur localhost. Elle se connecte directement à PostgreSQL, MySQL, SQLite et Cloudflare D1, donc le même outil couvre toute ta stack.

Pour un fichier .db en particulier, le flux de travail est presque insultant de brièveté. Tu installes l'appli, tu cliques sur « Add Data Source », et tu la pointes vers le fichier. C'est tout. Pas de connection string, pas de migration, pas de config, pas de changement de schéma. Pour une base de données typique, tu as un dashboard fonctionnel en environ trois secondes. Il y a une démo live sur demo.basevolt.app si tu veux la voir avant d'installer quoi que ce soit.

Ce que tu obtiens une fois qu'elle est ouverte :

Plusieurs vues. Une vue grille pour la navigation standard dans les tables, une vue galerie pour le contenu riche ou chargé en images, une vue kanban où tu regroupes les enregistrements par n'importe quel champ (statut, priorité, assigné) et un dashboard pour les graphiques et les statistiques.
Les relations. Elle détecte automatiquement les relations du schéma avec un LLM et visualise les clés étrangères, donc tu peux naviguer d'une ligne parente vers ses enfants et revenir. Surtout, elle te permet aussi de définir des relations qui n'existent pas dans le schéma — les liens implicites que la plupart des bases de données SQLite ont mais n'ont jamais formalisés. Ça compte parce que, comme je l'ai expliqué dans le guide des clés étrangères, SQLite ne peut même pas ajouter une clé étrangère à une table existante sans une reconstruction complète.
Une personnalisation non destructive. Tu peux renommer des champs, formater des valeurs et joindre des tables dans l'interface sans altérer ton schéma. Ton code applicatif qui lit le même fichier ne remarquera rien.
Un serveur MCP intégré sur localhost, ce qui veut dire que Claude Desktop, Cursor, Windsurf et Codex peuvent interroger ta base de données directement via l'appli. L'IA parle à BaseVolt, BaseVolt parle à ton fichier — rien ne part vers un tiers.

Les compromis honnêtes : c'est une appli de bureau, donc ce n'est pas un dashboard web partagé pour une équipe par défaut (l'offre Pro ajoute la synchronisation multi-appareils), et c'est un outil plus récent que DB Browser ou DBeaver, donc il a moins de recul. Mais pour le boulot précis de « j'ai un fichier .db et je veux vraiment travailler avec », c'est l'outil que j'attrape. Tu peux voir la liste des fonctionnalités sur la page des fonctionnalités, et l'offre Hobby est gratuite à vie avec deux sources de données et sans compte requis, donc l'essayer ne coûte rien.

Tableau comparatif

Voici comment les quatre se comparent. « Modifier des enregistrements » concerne le confort et la sécurité avec lesquels on change des données, pas seulement si c'est techniquement possible.

Outil	Plateforme	Effort d'installation	Idéal pour	Modifier des enregistrements
CLI `sqlite3`	Windows, macOS, Linux	Aucun sur macOS/Linux ; petit téléchargement sur Windows	Inspection rapide, scripting, automatisation	`UPDATE`/`DELETE` manuels uniquement ; pas de filet de sécurité
DB Browser for SQLite	Windows, macOS, Linux	Petit téléchargement	Parcourir un seul fichier SQLite, édition légère	Édition directe des cellules ; pas d'annulation, écrit immédiatement
DBeaver	Windows, macOS, Linux	Téléchargement plus gros ; configuration du pilote JDBC	Développeurs utilisant déjà un client SQL multi-moteurs	Édition en grille avec aperçu du SQL généré
BaseVolt	macOS (Apple Silicon), Windows	Petit téléchargement	Travail suivi : vues, relations, dashboards	Édition en ligne avec couche d'interface non destructive

Il n'y a pas de gagnant unique ici. Si je dois répondre à une seule question sur un fichier, j'utilise la CLI. Si j'ouvre la base de données de quelqu'un d'autre pour la première fois, DB Browser. Si j'ai déjà DBeaver qui tourne pour Postgres, j'y ajoute SQLite. Et si je vais travailler avec cette base de données plus que quelques minutes — parcourir, filtrer, construire des vues, naviguer dans les relations — j'utilise BaseVolt.

Comment inspecter un fichier .db sans interface graphique

Parfois tu ne veux rien installer. Tu es sur un serveur, en SSH ou dans un conteneur, et tu as juste besoin de savoir ce qu'il y a dans le fichier. La CLI sqlite3 gère tout ça, et quelques one-liners couvrent l'essentiel de ce que tu voudrais.

Lister toutes les tables :

sqlite3 mydata.db ".tables"

Obtenir le schéma complet — chaque instruction CREATE :

sqlite3 mydata.db ".schema"

Obtenir le schéma d'une table :

sqlite3 mydata.db ".schema users"

Le nombre de lignes de chaque table en une seule fois :

sqlite3 mydata.db "SELECT name FROM sqlite_master WHERE type='table';" | while read t; do
  echo -n "$t: "
  sqlite3 mydata.db "SELECT COUNT(*) FROM \"$t\";"
done

Lister les tables avec leur nombre de colonnes et un coup d'œil rapide :

sqlite3 -header -column mydata.db "PRAGMA table_info(users);"

Vérifier la taille de page et l'encodage du fichier :

sqlite3 mydata.db "PRAGMA page_size; PRAGMA encoding;"

Vérifier l'intégrité (utile si tu soupçonnes une corruption) :

sqlite3 mydata.db "PRAGMA integrity_check;"

Un PRAGMA integrity_check; qui renvoie ok signifie que la structure interne du fichier est cohérente. S'il renvoie autre chose, le fichier est endommagé — ce qui est l'une des rares situations où une interface graphique ne t'aidera pas et où tu voudras restaurer depuis une sauvegarde.

La seule chose que tu ne peux pas facilement faire sans interface graphique, c'est voir les relations entre les tables. Le schéma te dira quelles clés étrangères existent, mais il ne te dira pas quelles colonnes devraient être liées. Pour ça, un outil qui peut visualiser et te laisser définir des relations vaut l'installation.

Dépannage : quand un fichier .db ne s'ouvre pas

La plupart du temps, ouvrir un fichier .db fonctionne tout simplement. Quand ça ne marche pas, c'est généralement l'un de ces cinq problèmes.

« Database is locked »

C'est l'erreur la plus courante, et elle est presque toujours auto-infligée. SQLite n'autorise qu'un seul writer à la fois. Si un autre processus — ton application, un serveur de dev en cours d'exécution, ou un autre outil graphique — détient actuellement un verrou d'écriture sur le fichier, ta nouvelle connexion ne peut pas en obtenir un, et tu obtiens database is locked (ou SQLITE_BUSY).

La solution est de trouver et de fermer l'autre connexion. Quelques choses à vérifier :

Ton application tourne-t-elle encore et garde-t-elle la base de données ouverte ?
As-tu le fichier ouvert dans un autre outil SQLite — DB Browser, DBeaver, la CLI — dans une fenêtre différente ?
Un processus précédent a-t-il planté sans libérer le verrou ?

Si un processus a planté et laissé un verrou obsolète, le fichier de verrou est généralement le coupable. En mode WAL (write-ahead logging), SQLite conserve deux fichiers annexes à côté de ta base de données : mydata.db-wal (le journal d'écriture anticipée) et mydata.db-shm (mémoire partagée). Ils sont normaux et attendus — ce n'est pas de la corruption, et tu ne devrais pas les supprimer tant qu'un processus a la base de données ouverte. Si tu es certain que rien n'a le fichier ouvert et que le verrou persiste, supprimer les fichiers -shm et -wal (après avoir confirmé qu'aucun processus ne les utilise) permettra à SQLite de les reconstruire à la prochaine ouverture.

Une nuance importante : les lecteurs ne se bloquent pas entre eux, et en mode WAL un lecteur ne bloque pas un writer. Si tu obtiens database is locked sur une lecture, c'est généralement un writer qui détient le verrou — une transaction longue, ou une application qui a ouvert la base de données en mode rollback-journal plutôt qu'en WAL. Si ton application définit PRAGMA journal_mode = WAL; à la connexion, tu verras beaucoup moins de ces erreurs.

Le fichier est vide ou fait 0 octet

Un fichier .db de 0 octet n'est pas une base de données — c'est un fichier vide. Ça arrive plus souvent qu'on ne le pense : une appli crée le fichier au premier lancement puis plante avant d'écrire quoi que ce soit, un téléchargement échoue à mi-chemin, ou une opération de copie ne produit silencieusement rien.

Un fichier vide n'a pas d'en-tête magique, donc chaque outil soit renverra une erreur, soit proposera d'y créer une nouvelle base de données. Si tu es sûr que les données devraient être là, le fichier est probablement perdu — cherche une sauvegarde, un fichier .db-wal qui contient encore des données non validées, ou un fichier .db-journal. Si un fichier -wal existe à côté d'une base de données de 0 octet, les pages validées peuvent encore être récupérables, mais tu devras l'ouvrir avec SQLite et le laisser récupérer plutôt que de supprimer les fichiers annexes.

Le fichier est chiffré et s'ouvre en charabia

Certaines applications chiffrent leurs bases de données SQLite avec SQLCipher, qui est un fork de SQLite ajoutant un chiffrement transparent. Une base de données SQLCipher chiffrée est un fichier valide, mais ses 16 premiers octets ne sont pas l'en-tête magique de SQLite — c'est le sel de chiffrement. Donc file ne le reconnaîtra pas, et un outil SQLite standard soit refusera de l'ouvrir, soit t'affichera du charabia binaire.

Si tu sais que le fichier est chiffré avec SQLCipher, il te faut soit une version de la CLI compatible SQLCipher, soit un outil qui prend en charge SQLCipher, plus la clé de chiffrement. SQLite standard ne peut pas le lire, et aucun renommage ni tentative de persuasion n'y changera rien. Si tu ne sais pas que le fichier est chiffré, c'est l'un des modes de défaillance les plus déroutants : le fichier est réel et non vide, mais rien ne veut le lire.

Le fichier n'est pas du tout du SQLite

Retour à notre point de départ. Si file indique autre chose que SQLite 3.x database, tu as affaire à un format différent — Access, Paradox, un blob propriétaire, ou un fichier texte ou archive que quelqu'un a renommé. Aucun outil SQLite ne l'ouvrira. Identifie d'abord le format (la commande file te le dit généralement), puis trouve un outil pour ce format.

Ouvrir un fichier `.db` provenant d'une appli mobile ou d'une appli Electron

Ça revient assez souvent pour mériter sa propre note. Si le fichier .db vient d'une appli iOS ou Android, ou d'une appli de bureau Electron (Slack, Discord, VS Code, et d'innombrables autres sont Electron), c'est très probablement une vraie base de données SQLite — et elle s'ouvrira très bien dans n'importe lequel des outils ci-dessus. Quelques mises en garde :

Il peut être chiffré. Certaines applis utilisent SQLCipher. Voir ci-dessus.
Il peut utiliser le mode WAL avec des fichiers annexes. Si tu n'as copié que le fichier .db et laissé le fichier -wal derrière, il peut te manquer les écritures les plus récentes. Copie les trois fichiers (.db, .db-wal, .db-shm) ensemble si tu veux un instantané cohérent.
Le schéma est celui de l'appli, pas le tien. Tu peux le lire, mais le modifier directement peut casser l'appli. Traite la base de données d'une appli tierce comme étant en lecture seule, sauf si tu sais exactement ce que tu fais.
Les applis iOS utilisent parfois un emplacement différent. Sur iOS, la base de données vit à l'intérieur du bac à sable de l'appli, et y accéder nécessite généralement un extracteur de sauvegarde ou un appareil jailbreaké. C'est au-delà de la portée de cet article, mais c'est pourquoi « je n'arrive pas à trouver le fichier » est une plainte courante.

Quand utiliser quoi

Un guide de décision rapide, basé sur ce que tu essaies vraiment de faire :

Tu as juste besoin de répondre à une question sur le fichier. Utilise la CLI sqlite3. Pas d'installation, pas de complications.
Tu ouvres une base de données inconnue pour voir ce qu'elle contient. Utilise DB Browser for SQLite. Les onglets structure et navigation sont le chemin le plus rapide pour comprendre un fichier hérité.
Tu utilises déjà DBeaver pour d'autres bases de données. Ajoute-lui SQLite et garde un seul client pour tout.
Tu vas travailler avec cette base de données de façon répétée. Utilise un panneau d'administration local-first. Le temps que tu passes à l'installer est rentabilisé dès la première fois que tu as besoin d'une vue filtrée, d'une table jointe ou d'un tableau kanban — et tu obtiens tout ça sans modifier ton schéma, ce qui compte pour les raisons exposées dans le guide du panneau d'administration SQLite local.
Tu es sur un serveur ou en SSH. La CLI est la seule option réaliste, et les one-liners ci-dessus couvrent l'inspection et la maintenance.
Tu as besoin de visualiser les relations. Utilise un outil qui les montre — soit les diagrammes ER de DBeaver pour les clés qui existent dans le schéma, soit BaseVolt pour les relations à la fois formelles et implicites.

Si tu n'es pas sûr, commence par la CLI pour confirmer que le fichier est du SQLite et voir ses tables, puis passe à une interface graphique une fois que tu sais que tu vas y passer du temps.

En résumé

Un fichier .db est presque toujours une base de données SQLite, et le confirmer est la première étape — vérifie l'en-tête magique SQLite format 3 avec file ou les 16 premiers octets, et s'il n'y est pas, détermine ce que tu tiens vraiment avant de blâmer l'outil. Les extensions .db, .sqlite, .sqlite3 et .db3 sont toutes le même format ; le nom ne te dit rien.

Une fois que tu sais que c'est du SQLite, choisis ton outil en fonction de ce que tu fais :

La CLI sqlite3 pour l'inspection rapide, le scripting et le travail sur serveur. Apprends .tables, .schema et .mode box et tu l'utiliseras pour toujours.
DB Browser for SQLite pour parcourir un seul fichier et faire des modifications légères. Gratuit, simple et réservé à SQLite.
DBeaver si tu vis déjà dans un client SQL multi-moteurs et que la configuration JDBC ne te dérange pas.
Un panneau d'administration local-first comme BaseVolt quand tu veux vraiment travailler avec les données — vues grille, galerie, kanban et dashboard, navigation dans les relations, et une couche d'interface non destructive qui laisse ton schéma tranquille.

Et quand quelque chose ne s'ouvre pas, c'est presque toujours l'une de cinq choses : un verrou détenu par un autre processus, un fichier vide, un chiffrement SQLCipher, un format non-SQLite, ou une base de données copiée à laquelle il manque son fichier annexe -wal. Savoir à laquelle tu as affaire transforme une impasse frustrante en correction de deux minutes.

Si tu veux voir l'approche panneau d'administration avant de t'engager, il y a une démo live sur demo.basevolt.app, et tu peux récupérer l'appli depuis la page de téléchargement — gratuite, sans compte requis, et elle tourne entièrement sur ta machine.

Si tu as trouvé ça utile, j'écris sur les bases de données, le local-first et les parties peu glamour de la construction d'outils pour développeurs. Retrouvez-moi sur X.