SQL ou NoSQL : lequel apprendre en premier

Pourquoi cette question arrive si tôt

Presque tous les débutants tombent sur cette bifurcation dans leurs premières semaines d'apprentissage des bases de données, généralement parce qu'un tutoriel ou une offre d'emploi mentionne les deux termes sans expliquer ce qui les sépare réellement. La réponse honnête est que « SQL contre NoSQL » est une formulation légèrement trompeuse — SQL est un langage de requête, tandis que « NoSQL » est une étiquette fourre-tout pour plusieurs designs de bases de données réellement différents qui s'accordent surtout sur le fait de ne pas être le modèle relationnel traditionnel. Comprendre ce pour quoi chacun est réellement optimisé répond à la question de lui-même.

Ce qu'une base relationnelle (SQL) suppose sur vos données

Une base relationnelle — PostgreSQL, MySQL, SQLite — part d'une hypothèse centrale : vos données sont composées de choses distinctes avec des relations bien définies entre elles. Une table customers, une table orders, une table order_items, chacune avec des colonnes fixes, et des liens explicites entre elles — le customer_id d'une commande pointant vers une ligne précise de customers. La base impose elle-même ces liens et leur cohérence : elle refusera de créer une commande pour un client qui n'existe pas, refusera de laisser deux mises à jour se corrompre l'une l'autre si elles se produisent au même instant, et garantira qu'une opération à plusieurs étapes (transférer de l'argent du compte A vers le compte B) se termine entièrement ou pas du tout, sans jamais laisser les données à moitié modifiées. Cet ensemble de garanties a un nom — ACID (Atomicité, Cohérence, Isolation, Durabilité) — et c'est pourquoi les bases relationnelles restent le choix par défaut pour tout ce qui touche à l'argent, aux stocks, ou à toute donnée où « ceci ne doit jamais être même légèrement faux » compte plus que la vitesse d'écriture brute.

SQL, le langage de requête, est la façon dont vous parlez réellement à ce type de base, et il vaut la peine de l'apprendre indépendamment d'un produit précis car le langage lui-même change à peine entre PostgreSQL, MySQL et SQL Server — SELECT name FROM customers WHERE country = 'FR' fonctionne, avec seulement de légères différences de dialecte, sur les trois.

Ce que « NoSQL » recouvre réellement

L'étiquette regroupe plusieurs approches réellement différentes qui ne partagent quasiment rien, sauf de ne pas être le modèle relationnel rigide qui impose les relations :

Les bases orientées documents (MongoDB, Firestore) stockent chaque enregistrement comme un document flexible, façon JSON, plutôt qu'une ligne à colonnes fixes — un document produit peut avoir un champ color et un autre non, sans schéma forçant chaque ligne à se ressembler. Cette flexibilité est réellement utile quand la forme de vos données varie beaucoup ou change souvent, et pénible quand vous devez réellement garantir la cohérence entre des données liées, car la base elle-même n'impose plus ces relations à votre place.

Les bases clé-valeur (Redis, DynamoDB) sont le modèle le plus simple de tous : vous stockez une valeur sous une clé et la récupérez par cette clé exacte, avec pratiquement aucun langage de requête au-delà de « get » et « set ». Ce qu'elles perdent en flexibilité, elles le regagnent en vitesse brute — c'est pourquoi Redis apparaît constamment comme couche de cache devant une base primaire plus lente, et pourquoi le stockage de session (la minuscule donnée qui dit « ce navigateur est connecté en tant qu'utilisateur 4471 ») vit presque toujours dans quelque chose en forme clé-valeur plutôt que dans une table relationnelle complète.

Les bases en familles de colonnes (Cassandra, HBase) sont conçues pour un type de problème précis et exigeant : d'énormes volumes d'écriture répartis sur de nombreuses machines, où le même schéma de requête tourne en continu (enregistrer chaque relevé d'un million de capteurs IoT, chaque minute, indéfiniment) et où la base doit continuer à passer à l'échelle simplement en ajoutant des machines plutôt qu'en ayant besoin d'une seule machine plus grosse.

Les bases orientées graphe (Neo4j) existent pour la raison inverse des bases documents — non pas parce que les relations ne comptent pas, mais parce qu'elles comptent tellement que les parcourir (« trouver tous les amis d'amis de cette personne, à trois sauts ») doit être l'opération centrale de la base plutôt que quelque chose ajouté via des jointures.

La vraie différence derrière tout ça : la stratégie de mise à l'échelle

La raison profonde pour laquelle les bases NoSQL existent n'est pas que les bases relationnelles seraient dépassées — c'est que les bases relationnelles passent traditionnellement à l'échelle en obtenant une seule machine plus grosse (scaling vertical), ce qui finit par atteindre un plafond difficile à dépasser, tandis que la plupart des designs NoSQL ont été conçus dès le départ pour passer à l'échelle en ajoutant des machines ordinaires (scaling horizontal), répartissant les données entre elles plutôt que d'exiger qu'une seule machine gère tout. Ce compromis coûte généralement quelque chose : la plupart des systèmes NoSQL relâchent certaines des garanties ACID qu'une base relationnelle offre gratuitement, acceptant une cohérence à terme — une brève fenêtre où différentes machines peuvent momentanément ne pas être d'accord sur la valeur actuelle d'une donnée — en échange de la capacité à continuer de passer à l'échelle en ajoutant du matériel plutôt qu'en se heurtant à un mur.

Alors, lequel apprendre en premier

SQL. Non pas parce que les bases NoSQL seraient moins légitimes, mais parce que le modèle relationnel et SQL lui-même vous enseignent le vocabulaire de fond contre lequel tout le reste se définit — vous ne pouvez pas vraiment apprécier ce pour quoi une base documents est optimisée tant que vous ne comprenez pas ce à quoi elle renonce délibérément par rapport aux relations et jointures imposées. SQL est aussi simplement plus universellement exigé : l'immense majorité des postes backend, des rôles d'analyse de données, et même de nombreux rôles frontend qui touchent une API finissent par croiser une requête SQL quelque part, tandis qu'une base NoSQL précise a bien plus de chances d'être quelque chose que vous apprenez sur le tas, pour le système spécifique que votre employeur utilise. Apprenez la modélisation relationnelle et SQL jusqu'à ce qu'interroger et concevoir des tables normalisées vous semble naturel, et le paysage NoSQL cessera de ressembler à un mur de noms de produits inconnus pour devenir un ensemble de compromis précis et compréhensibles par rapport à la base que vous maîtrisez déjà.