SQLite — DevIA Notes

À quoi ça sert

Quand on dit « base de données », on imagine en général un gros serveur PostgreSQL ou MySQL : un processus qui tourne en permanence sur un port, auquel ton application se connecte par le réseau. SQLite, c'est l'inverse de ça.

Pas de serveur — SQLite est une bibliothèque (du C), pas un processus. Ton application l'embarque et lit/écrit directement dans le fichier de la base.
Une base = un fichier — maBase.db. Tu veux faire un backup ? Tu copies le fichier. Tu veux donner la base à quelqu'un ? Tu lui envoies le fichier.
Zéro configuration — pas d'utilisateurs, pas de permissions, pas de port. La sécurité, c'est celle des permissions du fichier sur le disque.
Standard SQL — la quasi-totalité de la syntaxe SQL que tu apprendrais sur PostgreSQL marche ici (avec quelques différences sur les types et les fonctions de date).

C'est tellement pratique que SQLite est l'une des bibliothèques les plus déployées au monde : Android et iOS l'utilisent pour stocker tes contacts, tes SMS, tes photos. Firefox stocke tes favoris dedans. Python l'inclut dans la stdlib. Tu en as déjà des centaines sur ta machine sans le savoir.

En une phrase

SQLite, c'est SQL sans serveur : la simplicité d'un fichier, la puissance des requêtes SQL.

Un exemple d'usage

Tu écris une petite appli Python qui suit tes lectures : titre, auteur, date où tu l'as fini, note sur 10. Trois choix s'offrent à toi :

Un fichier JSON — facile au début, mais dès que tu veux « les livres notés ≥ 8 lus en 2026, triés par date », tu réinventes du SQL en Python lent et bugué.
PostgreSQL — costaud, mais il faut installer un serveur, créer un user, ouvrir un port, mémoriser un mot de passe… pour 200 lignes de données.
SQLite — un fichier livres.db à côté de ton script. Tu écris SELECT * FROM livres WHERE note >= 8 et c'est terminé.

SQLite est le bon choix dès que :

Une seule machine accède à la base (ton PC, le serveur d'une appli web modeste).
Le volume reste raisonnable (jusqu'à ~100 Go en pratique, la limite théorique est 281 To).
Les lectures dominent largement, ou les écritures sont peu fréquentes.

Cas typiques : prototype d'application, cache local d'un script, configuration évoluée, base d'un outil CLI, dev local d'une API qui ira en prod sur PostgreSQL, fichiers de format propriétaire (Anki, Obsidian, et bien d'autres logiciels stockent leurs données en SQLite sans le dire à l'utilisateur).

À l'inverse, dès que plusieurs serveurs doivent écrire en parallèle dans la même base, ou que tu fais beaucoup d'écritures concurrentes, tu passes à PostgreSQL ou MySQL.

How-to : démarrer avec SQLite

Trois chemins, dans l'ordre où je les recommande pour apprendre :

CLI sqlite3 — pour comprendre ce qui se passe dans une base sans aucune couche Python par-dessus.
Module Python sqlite3 (stdlib, zéro install) — pour utiliser la base depuis ton code.
DB Browser for SQLite — une interface graphique pour explorer une base existante visuellement.

1. La CLI `sqlite3`

Le binaire est souvent déjà installé sur Linux et macOS. On vérifie :

bash

sqlite3 --version

Si la commande n'est pas trouvée :

Linux (Debian/Ubuntu) : sudo apt install sqlite3
macOS : déjà présent, sinon brew install sqlite
Windows : télécharger le binaire sur sqlite.org/download.html (section Precompiled Binaries for Windows)

On crée une base et une table. Si le fichier n'existe pas, il est créé au premier écrit :

bash

sqlite3 livres.db

Tu es maintenant dans le shell SQLite (prompt sqlite>). On crée la table et on insère deux lignes :

sql

CREATE TABLE livres (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    titre TEXT NOT NULL,
    auteur TEXT,
    note INTEGER
);

INSERT INTO livres (titre, auteur, note) VALUES
    ('Le Nom de la Rose', 'Umberto Eco', 9),
    ('Dune', 'Frank Herbert', 10);

SELECT * FROM livres WHERE note >= 9;

Quelques commandes spéciales du shell (préfixées par un point, pas du SQL) — utiles pour explorer une base :

sqlite shell

.tables           -- liste les tables
.schema livres    -- montre le CREATE TABLE
.headers on       -- afficher les noms de colonnes
.mode column      -- formatage en colonnes alignées
.quit             -- sortir du shell

2. Le module Python `sqlite3`

Inclus dans la stdlib — rien à installer, juste import sqlite3. Le code minimal pour ouvrir une base, écrire, lire :

python

import sqlite3

# ouvre (ou crée) le fichier
con = sqlite3.connect("livres.db")
cur = con.cursor()

# création de la table si elle n'existe pas déjà
cur.execute("""
    CREATE TABLE IF NOT EXISTS livres (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        titre TEXT NOT NULL,
        auteur TEXT,
        note INTEGER
    )
""")

# insertion avec paramètres — JAMAIS d'interpolation Python (cf. encadré)
cur.execute(
    "INSERT INTO livres (titre, auteur, note) VALUES (?, ?, ?)",
    ("Dune", "Frank Herbert", 10),
)
con.commit()   # sans commit, l'écriture n'est pas persistée

# lecture
for row in cur.execute("SELECT titre, note FROM livres WHERE note >= ?", (9,)):
    print(row)

con.close()

⚠ Toujours utiliser ?, jamais f-string

La tentation du débutant :

cur.execute(f"SELECT * FROM users WHERE nom = '{nom}'")   # ❌ DANGER

Si nom vient d'un utilisateur, il peut contenir '; DROP TABLE users;--. C'est l'injection SQL, une des failles les plus anciennes et les plus exploitées du web.

La bonne version utilise un placeholder ? :

cur.execute("SELECT * FROM users WHERE nom = ?", (nom,))   # ✅ sûr

SQLite gère lui-même l'échappement et traite le contenu de nom comme une donnée, jamais comme du SQL.

3. DB Browser for SQLite (interface graphique)

Pour ouvrir une base à la souris : tableaux, requêtes ad-hoc, édition de cellules. Pratique pour explorer une base récupérée d'ailleurs.

Site officiel : sqlitebrowser.org
Linux (Debian/Ubuntu) : sudo apt install sqlitebrowser
macOS : brew install --cask db-browser-for-sqlite
Windows : installeur depuis le site officiel.

Dans VS Code, l'extension SQLite Viewer (qwtel.sqlite-viewer) permet de cliquer sur un .db dans l'explorateur et de voir les tables sans quitter l'éditeur.

Aide-mémoire

CLI sqlite3

sqlite3 ma_base.db        # ouvrir/créer une base
.tables                          # lister les tables
.schema [nom_table]              # voir le CREATE TABLE
.headers on                      # afficher les noms de colonnes
.mode column                     # colonnes alignées
.read script.sql                 # exécuter un fichier .sql
.backup ma_base.bak              # backup à chaud (consistant)
.quit                            # sortir

python (sqlite3 stdlib)

import sqlite3

with sqlite3.connect("app.db") as con:
    cur = con.cursor()
    cur.execute("INSERT INTO t VALUES (?, ?)", (a, b))
    rows = cur.execute("SELECT * FROM t WHERE x = ?", (val,)).fetchall()
    # commit automatique en sortie de bloc with

SQLite et le reste de l'écosystème

SQLAlchemy — l'ORM Python de référence. SQLite est son moteur de prédilection pour démarrer (chaîne de connexion sqlite:///app.db). Tu écris ton code une fois, tu peux ensuite passer à PostgreSQL en changeant la seule chaîne de connexion.
FastAPI — pour le dev local d'une API, SQLite + SQLAlchemy permet de coder sans serveur de BD à installer. On bascule en PostgreSQL au déploiement.
pandas — pd.read_sql("SELECT ...", con) avec une connexion sqlite3 charge directement le résultat d'une requête en DataFrame. Très pratique pour analyser une base existante.

Pour aller plus loin

Site officiel : sqlite.org — documentation complète, FAQ, et le célèbre essai Appropriate Uses For SQLite qui détaille avec honnêteté quand l'utiliser et quand ne pas l'utiliser.
Mode WAL (Write-Ahead Logging) : PRAGMA journal_mode=WAL; — améliore nettement la concurrence lecture/écriture. Recommandé dès qu'une appli web utilise SQLite.
Limites en concurrence : une seule écriture à la fois (verrou global sur la base). Les lectures parallèles fonctionnent très bien. Si tu fais beaucoup d'INSERT/UPDATE concurrents depuis plusieurs processus, c'est le signal qu'il faut passer à PostgreSQL.