Le débat « SQL contre NoSQL » est mal posé. Ce ne sont pas deux concurrents dont l'un gagnerait : ce sont deux familles d'outils qui résolvent des problèmes différents. La vraie question n'est pas laquelle est la meilleure, mais ce que coûte une donnée incohérente dans votre application.
Les deux familles, en une phrase chacune
Une base relationnelle — PostgreSQL, MySQL — range les données dans des tables aux colonnes définies à l'avance, et garantit que les relations entre elles restent valides. Vous ne pouvez pas créer une commande rattachée à un client inexistant : la base refuse.
Une base documentaire — MongoDB et ses semblables — stocke des documents dont la forme peut varier d'un enregistrement à l'autre. Elle n'impose pas de structure et ne vérifie pas les relations : c'est votre code qui en répond.
La question qui tranche : que coûte une incohérence ?
Si une donnée fausse dans votre système signifie un paiement perdu, un stock erroné, une facture incorrecte ou un billet vendu deux fois, prenez une base relationnelle. Les garanties transactionnelles ne sont pas un luxe d'ingénieur : elles sont ce qui empêche une opération interrompue à mi-chemin de laisser le système dans un état absurde.
Si une donnée incomplète signifie simplement un affichage approximatif — un historique de navigation, un journal d'événements, un cache, un contenu éditorial dont la forme varie — la souplesse d'une base documentaire se paie sans douleur.
C'est le critère principal. Les autres viennent ensuite.
Les critères secondaires, dans l'ordre
La forme de vos données. Des entités stables et reliées entre elles — clients, commandes, produits, factures — correspondent naturellement à des tables. Des objets hétérogènes, dont les champs diffèrent selon les cas, s'accommodent mieux de documents.
La nature de vos recherches. Si vous allez croiser des informations venues de plusieurs entités — « le chiffre d'affaires par région et par trimestre pour les clients inscrits cette année » — le relationnel fait cela en une requête. En documentaire, cela se traduit par du code applicatif, à écrire et à maintenir.
Le volume réel. La performance est l'argument le plus avancé et le moins souvent pertinent. Une base relationnelle correctement indexée gère sans effort des millions de lignes. La plupart des projets qui invoquent la montée en charge n'atteindront jamais le volume où la question se pose.
Ce que l'équipe sait faire. Une technologie maîtrisée par une seule personne devient un risque le jour où cette personne n'est plus disponible. SQL est un langage ancien, enseigné partout, et transférable.
Trois cas concrets
Une boutique en ligne : relationnel. Stocks, commandes, paiements et clients sont reliés, et une incohérence se traduit directement en argent perdu ou en litige.
Un site éditorial ou un média : l'un ou l'autre fonctionne. Les gestionnaires de contenu les plus répandus s'appuient sur du relationnel et cela ne les gêne pas. Le choix se fera sur l'écosystème et l'hébergement disponibles, pas sur la base elle-même.
Un flux d'événements ou de mesures — journaux, capteurs, suivi d'activité : documentaire ou base spécialisée. Les écritures sont massives, la structure varie, et une perte marginale est sans conséquence.
Ce qu'on oublie presque toujours
Les bases relationnelles modernes stockent et interrogent nativement des documents. PostgreSQL manipule du JSON avec indexation ; MySQL également. Autrement dit, vous pouvez avoir la souplesse documentaire là où vous en avez besoin, sans renoncer aux garanties ailleurs. Cela suffit à résoudre la grande majorité des cas qui semblaient imposer un changement de famille.
Deuxième oubli, plus coûteux : la sauvegarde et la restauration. La question à se poser n'est pas « quelle base choisir » mais « ai-je déjà testé une restauration complète ». Une sauvegarde jamais restaurée n'est pas une sauvegarde.
En résumé
| Votre situation | Choix raisonnable |
|---|---|
| Argent, stocks, réservations, facturation | Relationnel |
| Entités stables et reliées | Relationnel |
| Besoins d'analyses croisées | Relationnel |
| Documents de forme variable | Documentaire, ou JSON en relationnel |
| Journaux, mesures, gros volumes d'écriture | Documentaire ou base spécialisée |
| Doute, et équipe réduite | Relationnel — c'est le choix le plus réversible |
Dans le doute, commencez en relationnel. Non par conservatisme, mais parce que c'est l'option la moins coûteuse à quitter : les données y sont structurées, donc exportables vers n'importe quoi d'autre. L'inverse n'est pas vrai.
Ce type d'arbitrage se prend au moment de la conception, et ses conséquences durent des années — c'est l'une des raisons pour lesquelles le choix de qui construit l'application compte autant que le choix de la technologie.