SQLite Cheat Sheet : les commandes à connaître
Cheat sheet SQLite : toutes les commandes CLI essentielles pour créer des tables, insérer et lire des données, importer un CSV et configurer les PRAGMA.

SQLite est une base de données qui tient dans un seul fichier. Pas de serveur à démarrer, pas d’utilisateurs à configurer, pas de port à ouvrir. Tu crées un fichier .db, et c’est ta base de données.
C’est le moteur le plus déployé au monde. Tous les smartphones Android et iOS l’utilisent en interne. Les navigateurs stockent l’historique et les cookies dedans. VS Code s’en sert pour ses extensions. SQLite est partout, justement parce qu’il ne demande rien d’autre que lui-même.
Pour les projets perso, les scripts de traitement de données, les prototypes ou les petites apps web, c’est imbattable. Pas besoin de Docker, pas besoin d’un service PostgreSQL qui tourne en arrière-plan. Une seule commande suffit pour commencer :
sqlite3 ma-base.db
Ce cheat sheet regroupe les commandes que j’utilise le plus souvent, des dot commands de l’interpréteur jusqu’aux fonctions JSON.
Ouvrir et gérer une base #
Les commandes qui suivent se tapent dans un terminal (l’application Terminal sur macOS, un terminal Bash sous Linux/WSL, ou PowerShell sous Windows), pas dans un éditeur de texte. Il faut que sqlite3 soit installé au préalable : sqlite3 --version dans le terminal confirme sa présence, sinon direction la documentation officielle de téléchargement.
Ouvrir ou créer une base (le fichier est créé s’il n’existe pas) :
sqlite3 ma-base.db
Ouvrir en lecture seule :
sqlite3 -readonly ma-base.db
Sortir de l’interpréteur :
.quit
Cette CLI nue suffit pour l’essentiel, mais elle n’est pas le seul point d’entrée. Selon l’environnement de travail, d’autres outils rendent la même chose plus confortable.
Autres façons d’interagir avec SQLite #
Voici ceux que j’utilise selon le contexte, du plus intégré à l’éditeur au plus visuel.
Extension VS Code #
Si le fichier .db traîne déjà dans un projet ouvert dans VS Code, pas besoin de sortir du terminal. L’extension SQLite Viewer affiche le contenu d’un fichier .db, .sqlite ou .sqlite3 dans un onglet, avec navigation par table et tri des colonnes en cliquant simplement sur le fichier dans l’explorateur.
Pour écrire des requêtes directement dans l’éditeur avec autocomplétion, SQLTools + son driver SQLite est plus complet : connexion persistante, historique des requêtes, export des résultats.
PowerShell et CMD (Windows) #
Sous Windows, sqlite3.exe fonctionne identiquement en PowerShell et en CMD, à condition que l’exécutable soit dans le PATH. Le plus simple pour l’installer est winget :
winget install SQLite.SQLite
Une fois installé, l’usage est le même qu’en bash :
sqlite3.exe ma-base.db "SELECT * FROM utilisateurs;"
Information
PowerShell interprète différemment les guillemets doubles dans certains cas. Si une requête contient des apostrophes SQL ('valeur'), pas de souci : ce sont les guillemets doubles autour de la requête entière qui posent parfois problème avec des caractères spéciaux. En cas d’erreur de parsing, tester la même commande depuis CMD pour isoler le problème.
Bash sous WSL #
Sous WSL, sqlite3 s’installe comme sur n’importe quelle distribution Linux :
sudo apt install sqlite3
Le point d’attention avec WSL, c’est l’emplacement du fichier. Une base ouverte depuis le système de fichiers Windows monté (/mnt/c/...) est nettement plus lente qu’une base sur le système de fichiers Linux natif (~/ ou /home/...), à cause de la traduction des appels système entre les deux mondes. Pour un usage occasionnel ça ne se voit pas, mais sur une base volumineuse avec beaucoup d’écritures, la différence est notable.
DB Browser for SQLite (interface graphique) #
Pour une exploration visuelle sans taper de SQL, DB Browser for SQLite (souvent abrégé DB4S) est l’outil le plus simple à installer. Disponible pour Windows, macOS et Linux, il permet de parcourir les tables, éditer des cellules à la main, importer un CSV en quelques clics et visualiser le schéma sans écrire une seule requête.
C’est l’outil que je recommande à quelqu’un qui découvre SQLite : la CLI vient ensuite, une fois qu’on a compris la structure d’une base en la manipulant visuellement.
Une fois à l’aise avec la structure d’une base, la CLI sqlite3 va plus vite qu’une interface graphique pour l’inspecter. Elle propose pour ça des commandes spéciales, propres à l’interpréteur et absentes du langage SQL standard : les dot commands.
Commandes méta (dot commands) #
Ces commandes commencent par un point et s’exécutent dans l’interpréteur sqlite3.
Lister les tables :
.tables
Voir le schéma d’une table :
.schema nom_table
Voir le schéma de toutes les tables :
.schema
Afficher les noms de colonnes dans les résultats :
.headers on
Voir les bases attachées :
.databases
Modes d’affichage #
Le mode .mode box est le plus lisible en console (SQLite >= 3.37) :
.mode box
Résultat avec .mode box :
┌────┬───────┬───────────────────┐
│ id │ nom │ email │
├────┼───────┼───────────────────┤
│ 1 │ Alice │ alice@example.com │
│ 2 │ Bob │ bob@example.com │
└────┴───────┴───────────────────┘
Les autres modes disponibles :
| Mode | Rendu |
|---|---|
.mode box | Unicode avec bordures (recommandé, >= 3.37) |
.mode table | ASCII avec + et | |
.mode column | Colonnes alignées sans bordure |
.mode markdown | Tableau Markdown |
.mode csv | Séparateur virgule |
.mode json | Tableau JSON |
.mode line | Une clé=valeur par ligne |
Avec beaucoup de colonnes, .mode box provoque des chevauchements. .mode line affiche une valeur par ligne, sans risque de débordement :
.mode line
Résultat avec .mode line :
id = 1
nom = Alice
email = alice@example.com
id = 2
nom = Bob
email = bob@example.com
Limiter la largeur des colonnes (les valeurs trop longues sont tronquées) :
.width 4 15 25
Scroll horizontal dans le terminal sans chevauchement :
sqlite3 ma-base.db ".mode box" ".headers on" "SELECT * FROM nom_table;" | less -S
Créer et modifier des tables #
Créer une table :
CREATE TABLE utilisateurs (
id INTEGER PRIMARY KEY AUTOINCREMENT,
nom TEXT NOT NULL,
email TEXT UNIQUE,
created_at TEXT DEFAULT (datetime('now'))
);
Ajouter une colonne :
ALTER TABLE utilisateurs ADD COLUMN actif INTEGER DEFAULT 1;
Renommer une table :
ALTER TABLE utilisateurs RENAME TO users;
Supprimer une table :
DROP TABLE IF EXISTS users;
Insérer des données #
Insérer une ligne :
INSERT INTO utilisateurs (nom, email) VALUES ('Alice', 'alice@example.com');
Insérer plusieurs lignes en une requête :
INSERT INTO utilisateurs (nom, email) VALUES
('Bob', 'bob@example.com'),
('Carol', 'carol@example.com');
Ignorer les doublons sur une contrainte UNIQUE :
INSERT OR IGNORE INTO utilisateurs (nom, email) VALUES ('Alice', 'alice@example.com');
Upsert (insérer ou mettre à jour si conflit) :
INSERT INTO utilisateurs (email, nom) VALUES ('alice@example.com', 'Alice B.')
ON CONFLICT(email) DO UPDATE SET nom = excluded.nom;
Lire des données #
Sélectionner toutes les lignes :
SELECT * FROM utilisateurs;
Filtrer par condition :
SELECT nom, email FROM utilisateurs WHERE actif = 1;
Paginer les résultats :
SELECT * FROM utilisateurs ORDER BY nom ASC LIMIT 10 OFFSET 20;
Compter les lignes :
SELECT COUNT(*) FROM utilisateurs;
Dédupliquer :
SELECT DISTINCT nom FROM utilisateurs;
Mettre à jour et supprimer #
Mettre à jour une ligne :
UPDATE utilisateurs SET actif = 0 WHERE email = 'bob@example.com';
Supprimer une ligne :
DELETE FROM utilisateurs WHERE id = 3;
Vider une table sans la supprimer :
DELETE FROM utilisateurs;
Index #
Créer un index :
CREATE INDEX idx_email ON utilisateurs(email);
Index unique :
CREATE UNIQUE INDEX idx_email_unique ON utilisateurs(email);
Voir les index d’une table :
PRAGMA index_list(utilisateurs);
Jointures #
INNER JOIN (seulement les lignes qui ont une correspondance) :
SELECT u.nom, c.titre
FROM utilisateurs u
JOIN commandes c ON c.user_id = u.id
WHERE u.actif = 1;
LEFT JOIN avec agrégation (toutes les lignes de gauche, même sans correspondance) :
SELECT u.nom, COUNT(c.id) AS nb_commandes
FROM utilisateurs u
LEFT JOIN commandes c ON c.user_id = u.id
GROUP BY u.id;
Fonctions utiles #
Dates #
Date et heure actuelles :
SELECT datetime('now');
Date relative :
SELECT date('now', '-7 days');
Extraire l’année et le mois :
SELECT strftime('%Y-%m', created_at) AS mois FROM utilisateurs;
Texte #
Mettre en majuscules et mesurer la longueur :
SELECT upper(nom), length(nom) FROM utilisateurs;
Recherche par préfixe :
SELECT * FROM utilisateurs WHERE nom LIKE 'A%';
Recherche par sous-chaîne :
SELECT * FROM utilisateurs WHERE nom LIKE '%ice%';
JSON (SQLite >= 3.38) #
Extraire une valeur JSON :
SELECT json_extract(meta, '$.ville') FROM utilisateurs;
Modifier une valeur JSON :
UPDATE utilisateurs SET meta = json_set(meta, '$.score', 42) WHERE id = 1;
Transactions #
BEGIN;
INSERT INTO utilisateurs (nom) VALUES ('Dave');
UPDATE stats SET total = total + 1;
COMMIT;
Annuler une transaction en cours :
ROLLBACK;
Import / Export #
Importer un fichier CSV. À exécuter dans l’interpréteur sqlite3 :
.mode csv
.import donnees.csv nom_table
Exporter une table en CSV :
sqlite3 -separator ',' ma-base.db "SELECT * FROM utilisateurs;" > export.csv
Exporter toute la base en SQL :
sqlite3 ma-base.db .dump > backup.sql
Restaurer depuis un dump SQL :
sqlite3 nouvelle-base.db < backup.sql
PRAGMA courants #
Activer les clés étrangères (désactivées par défaut) :
PRAGMA foreign_keys = ON;
Attention
Les clés étrangères sont désactivées par défaut dans SQLite. Il faut les activer à chaque connexion, elles ne persistent pas entre sessions.
Vérifier l’intégrité de la base :
PRAGMA integrity_check;
Statistiques de pagination :
PRAGMA page_count;
PRAGMA page_size;
Mode WAL pour de meilleures performances en lecture concurrente :
PRAGMA journal_mode = WAL;
Exécuter une requête sans ouvrir l’interpréteur #
Requête simple :
sqlite3 ma-base.db "SELECT * FROM utilisateurs LIMIT 5;"
Avec en-têtes et colonnes alignées :
sqlite3 -column -header ma-base.db "SELECT * FROM utilisateurs;"
Quand ne pas utiliser SQLite #
SQLite couvre la majorité des projets, mais il y a des situations où un vrai serveur s’impose.
Évite SQLite si plusieurs processus écrivent en même temps de façon intensive. Le mode WAL aide à séparer lectures et écritures, mais SQLite sérialise quand même les écritures. Pour une API avec de nombreuses requêtes simultanées, PostgreSQL est plus adapté.
Évite-le aussi si la base est sur un partage réseau (NFS, CIFS, Samba). Les verrous fichier ne fonctionnent pas de façon fiable dans ces environnements et exposent à des corruptions silencieuses.
Enfin, SQLite ne propose pas de système d’utilisateurs ni de permissions par table. Si tu dois cloisonner l’accès aux données entre plusieurs rôles, tu as besoin d’un serveur de base de données.
Pour les projets qui démarrent sur SQLite et évoluent vers plus de concurrence, LibSQL et Turso offrent une compatibilité totale avec un passage vers le distribué sans réécriture du code.
Conclusion #
SQLite est la base de données que j’ouvre en premier quand je ne sais pas encore si le projet mérite une infrastructure. La plupart du temps, elle suffit. Un fichier versionnable, aucune dépendance à installer, une CLI qui fonctionne partout.
Si tu veux aller plus loin, la documentation officielle SQLite est l’une des mieux écrites du monde du logiciel libre.
Sources et références #
Cet article vous a plu ? Un like aide à le faire connaître.
Catégories
Commentaires
Top !
Aucun compte requis. Votre commentaire est relu avant publication.
Ce site est protégé par reCAPTCHA. La politique de confidentialité et les conditions d'utilisation de Google s'appliquent.



