Toute une base de données dans un seul fichier

Deux façons de ranger une base de données

Quand on parle de « base de données », on imagine souvent un gros logiciel qui tourne quelque part sur un serveur. C'est une des deux familles, mais pas la seule.

Une base « serveur », comme PostgreSQL, est un programme qui tourne en permanence, à l'écoute. Pour lui poser une question, tu te connectes à lui à distance, comme on appelle un service. Il faut le démarrer, le configurer, lui ouvrir une porte sur le réseau. C'est puissant, mais c'est lourd à mettre en place.

Une base « fichier », elle, vit dans un seul fichier sur ton disque (souvent terminé par .db ou .sqlite). Aucun serveur à démarrer, rien à configurer : ta base, c'est ce fichier. Tu le copies sur une clé USB, tu l'envoies par courriel, tu le glisses dans un projet, et il contient tout : les tables, les lignes, les index.

La vedette de cette famille s'appelle SQLite, et tu en as probablement des dizaines de copies sur toi en ce moment sans le savoir :

• Ton téléphone (Android comme iOS) range tes contacts, tes messages et tes réglages dans des bases SQLite.
• Ton navigateur web s'en sert pour ton historique et tes favoris.
• On en trouve dans des avions, des appareils photo, des voitures, des objets connectés.

Avec des milliards de copies en circulation, SQLite est probablement la base de données la plus installée de la planète. Tu vis entouré de petites bases fichiers sans jamais les voir.

Et le plus beau : c'est déjà dans ton Python

Voici le pont direct avec ce que tu fais en classe. Python contient SQLite en standard, dans un module qui s'appelle sqlite3. Tu n'as donc rien à installer : ça marche tout de suite, même dans Colab. Une vraie base de données, accessible en quelques lignes.

Voici un programme complet, du début à la fin : on ouvre un fichier de base, on crée une table, on y range des planètes, puis on les ressort.

import sqlite3

# On se connecte a un FICHIER de base. S'il n'existe pas, Python le cree.
connexionBase = sqlite3.connect("exoplanetes.db")
curseur = connexionBase.cursor()

# On cree une table : une colonne par caracteristique.
curseur.execute("""
    CREATE TABLE IF NOT EXISTS planetes (
        nom        TEXT,
        masseTerre REAL
    )
""")

# On ajoute des lignes. Le ? evite les erreurs et les pieges.
curseur.execute("INSERT INTO planetes VALUES (?, ?)", ("Kepler-22 b", 2.1))
curseur.execute("INSERT INTO planetes VALUES (?, ?)", ("Proxima b", 1.3))

# On enregistre vraiment les changements dans le fichier.
connexionBase.commit()

# On interroge : donne-moi les planetes plus massives que la Terre.
curseur.execute("SELECT nom, masseTerre FROM planetes WHERE masseTerre > 1.0")

for ligne in curseur.fetchall():
    print(ligne)

# On ferme proprement.
connexionBase.close()

Quand ce programme se termine, il a laissé derrière lui un fichier exoplanetes.db dans ton dossier. Relance le programme demain : tes données sont toujours là. Tu viens de fabriquer ta première vraie base de données persistante, sans serveur et sans installation.

Le ? dans les requêtes, c'est une bonne habitude : on glisse les valeurs séparément plutôt que de les coller dans le texte SQL. Ça évite les bogues et les failles de sécurité.

Base fichier ou base serveur : laquelle choisir ?

Aucune des deux familles n'est meilleure : tout dépend de ton besoin. Voici comment elles se comparent.

À côté de SQLite, deux autres formats fichiers méritent ton attention pour les données scientifiques, là où les volumes deviennent énormes :

• Parquet : un fichier qui range les données par colonnes au lieu de par lignes. C'est ultra-efficace quand tu veux lire seulement quelques colonnes parmi des millions de mesures. DuckDB, l'autre base fichier du tableau, adore lire le Parquet à toute vitesse.
• HDF5 : le format de prédilection en physique et en astronomie pour stocker de gigantesques tableaux de nombres (images de télescope, simulations) dans un seul fichier organisé.

Retiens l'idée des colonnes : pour les grosses données scientifiques, ranger par colonnes (Parquet) plutôt que par lignes change tout côté vitesse. Tu reverras ça au jour des grandes quantités de données.

Pousser l'idée plus loin : tout un site dans des fichiers

Si une base de données peut tenir dans des fichiers, pourquoi pas un site web complet ? C'est le pari des CMS à fichiers plats (en anglais, flat-file). Un CMS, c'est l'outil qui gère le contenu d'un site. D'habitude, il range ses articles dans une base serveur : WordPress, par exemple, stocke tout dans une base MySQL.

Un CMS à fichiers plats fait l'inverse : chaque page est un simple fichier texte, en général écrit en Markdown (le même langage que tes calepins), coiffé d'un petit en-tête de métadonnées. Le dossier de fichiers est la base de données. Aucune base serveur, nulle part.

# article-mars.md  -  un seul fichier = une page du site
---
titre: "Mars, la planète rouge"
date: 2026-06-17
auteur: "La classe de sciences"
---

# Le contenu, en Markdown, juste en dessous :
Mars possède **deux lunes**, Phobos et Déimos.
Son rayon est d'environ 3389 km.

Cette mode revient en force parce qu'elle a de vraies qualités : on sauvegarde tout en copiant un dossier, on suit l'historique avec Git, il n'y a pas de base à pirater, et le site est ultra-rapide. C'est l'idée de SQLite (mes données dans un fichier) poussée jusqu'au site entier.

Au fond, c'est le même réflexe que la séparation du sens et de l'apparence : le contenu vit dans des fichiers porteurs de sens, et un thème vient l'habiller par-dessus. D'ailleurs, le site de ce cours n'est qu'un ensemble de fichiers déposés sur un serveur.

À toi de jouer

Et pense à la suite : ton jeu de données d'exoplanètes du Projet 3 n'est pas obligé de rester un simple fichier CSV. Il pourrait vivre dans un fichier .sqlite bien rangé, que tu interroges en quelques lignes de sqlite3, pour filtrer, trier et croiser tes planètes sans jamais charger tout le tableau à la main.