Module 1 — SQL vs NoSQL : le même cas d'usage, deux bases réelles
Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 8 minutes
Le choix qui compte vraiment
Section titled “Le choix qui compte vraiment”Ce site a déjà un cours SQL complet et un cours PostgreSQL dédié — ce module ne répète pas cette base, il la met en perspective face à une alternative NoSQL, sur un même cas d’usage réel, pour rendre tangible une question que beaucoup d’ingénieurs DevOps doivent trancher : quand une base relationnelle s’impose, et quand un document flexible est le meilleur choix.
Le même catalogue, stocké dans les deux mondes
Section titled “Le même catalogue, stocké dans les deux mondes”import psycopg2
conn = psycopg2.connect(host="localhost", port=5433, user="devops", password="devops", dbname="inventaire")cur = conn.cursor()cur.execute(""" CREATE TABLE IF NOT EXISTS produits ( id SERIAL PRIMARY KEY, nom VARCHAR(100) NOT NULL, prix NUMERIC(10,2) NOT NULL, stock INTEGER NOT NULL )""")cur.executemany( "INSERT INTO produits (nom, prix, stock) VALUES (%s, %s, %s)", [("Clavier mécanique", 89.90, 12), ("Souris sans fil", 29.90, 34), ("Écran 27\"", 249.00, 5)],)conn.commit()
cur.execute("SELECT nom, prix, stock FROM produits WHERE stock < 20 ORDER BY stock")Exécution réelle contre un vrai conteneur PostgreSQL 16 :
PostgreSQL — produits en stock faible : Écran 27" prix= 249.00 stock=5 Clavier mécanique prix= 89.90 stock=12Le même catalogue, dans MongoDB :
from pymongo import MongoClient
client = MongoClient("mongodb://localhost:27017/")db = client.inventairedb.produits.insert_many([ {"nom": "Clavier mécanique", "prix": 89.90, "stock": 12, "switches": "brown"}, {"nom": "Souris sans fil", "prix": 29.90, "stock": 34, "dpi": 1600, "couleurs": ["noir", "blanc"]}, {"nom": "Écran 27\"", "prix": 249.00, "stock": 5, "resolution": "2560x1440", "hz": 144},])MongoDB — mêmes produits, champs différents selon le document : {'nom': 'Clavier mécanique', 'prix': 89.9, 'stock': 12, 'switches': 'brown'} {'nom': 'Souris sans fil', 'prix': 29.9, 'stock': 34, 'dpi': 1600, 'couleurs': ['noir', 'blanc']} {'nom': 'Écran 27"', 'prix': 249.0, 'stock': 5, 'resolution': '2560x1440', 'hz': 144}Ce que cette exécution rend visible
Section titled “Ce que cette exécution rend visible”La différence n’est pas de performance brute — les deux bases ont répondu instantanément sur ce volume. La différence qui compte est structurelle, et elle saute aux yeux dans ce résultat réel :
- PostgreSQL impose un schéma fixe : chaque ligne de
produitsa exactement les mêmes colonnes (nom,prix,stock). Un clavier et un écran, aussi différents soient-ils dans la réalité, sont contraints au même moule. Impossible d’ajouterswitchessans une migration de schéma (ALTER TABLE) qui s’appliquerait à tous les produits, même ceux qui n’ont pas de switches. - MongoDB accepte des documents de forme différente dans la même collection : le clavier a un champ
switches, la souris adpietcouleurs(un tableau), l’écran aresolutionethz— sans qu’aucun des trois documents ne soit invalide ou incomplet. Aucune migration nécessaire pour ajouter un champ propre à un seul type de produit.
Alors, quand choisir quoi ?
Section titled “Alors, quand choisir quoi ?”| Utiliser PostgreSQL (SQL) quand… | Utiliser MongoDB (NoSQL) quand… |
|---|---|
| Les données ont une structure stable et connue à l’avance | La structure varie d’un enregistrement à l’autre, ou évolue souvent |
| Les relations entre entités comptent (clients ↔ commandes ↔ lignes de commande) et doivent rester cohérentes | Les données sont naturellement des documents autonomes (un profil produit, un événement) |
| Des garanties transactionnelles fortes sont requises (ACID : un virement bancaire ne doit jamais être à moitié effectué) | La priorité est la vitesse d’écriture et la scalabilité horizontale sur de très gros volumes |
| L’équipe a besoin de requêtes complexes (jointures, agrégations) — voir le cours SQL | Les accès se font surtout par clé, sans besoin de croiser plusieurs collections |
Le piège à éviter dans les deux sens : choisir NoSQL parce que « c’est plus moderne » sans avoir de besoin réel de flexibilité de schéma revient à perdre les garanties d’intégrité que PostgreSQL offre gratuitement ; à l’inverse, forcer un schéma relationnel rigide sur des données intrinsèquement hétérogènes (comme un catalogue produit multi-catégories, chacune avec ses propres attributs) mène à des tables avec des dizaines de colonnes nullables — un signe classique qu’un modèle documentaire aurait été plus naturel.
Automatiser les deux depuis le même script
Section titled “Automatiser les deux depuis le même script”L’exemple de ce module a délibérément utilisé un seul script Python parlant aux deux bases (psycopg2 pour PostgreSQL, pymongo pour MongoDB) — dans une vraie automatisation DevOps (migration, synchronisation, script de seed pour un environnement de test), il est fréquent qu’un seul outil doive interagir avec plusieurs systèmes de stockage différents. Les bibliothèques clientes Python de chaque base exposent des API différentes, mais le principe reste identique à celui vu dans le module Python pour le DevOps : une fonction dédiée par système, orchestrée par un script principal qui reste lisible.