SQL ou NoSQL : comment choisir sans se tromper sur son premier projet

Le moment où tu te bloques

Imagine ton premier vrai projet. Une petite application. Des utilisateurs qui se connectent. Chaque utilisateur a des projets, chaque projet a des tâches. Rien d'exotique.

Tu ouvres trois tutoriels. Le premier range tout dans MongoDB en quelques lignes. Le deuxième crée des tables MySQL avec des clés étrangères. Le troisième te parle de Firebase. Tu te dis que si trois personnes compétentes font trois choix différents, c'est toi qui rates quelque chose.

Tu ne rates rien. Ces personnes résolvent des problèmes voisins, mais pas identiques. Et très souvent, elles choisissent par habitude, pas après une analyse. Le piège, c'est de copier un choix sans comprendre la raison derrière. C'est le même mécanisme que le syndrome du tutoriel infini : tu accumules des décisions empruntées au lieu de prendre les tiennes.

Ce choix pèse lourd dans ta tête pour une raison simple : il touche les fondations. Changer de langage sur une page, tu le fais en une heure. Changer de base de données quand le projet tourne déjà, ça ressemble à déménager une maison habitée. D'où la peur de se tromper. La bonne nouvelle, c'est que cette peur est exagérée, à condition de partir sur des bases saines.

Avant de comparer des technos, on va clarifier un point que beaucoup zappent : ces deux mondes ne stockent pas la donnée de la même manière, et ce n'est pas un détail.

La seule question qui compte

Commençons par poser les mots, sans jargon.

Ce que veut dire SQL

SQL, c'est le monde des bases relationnelles. Tes données vivent dans des tables, comme des feuilles de calcul reliées entre elles. Chaque table a un schéma, c'est-à-dire une structure fixe : des colonnes, chacune avec un type défini (un texte, un nombre, une date). Les tables se relient par des références. Une commande pointe vers un utilisateur, un utilisateur peut avoir plusieurs commandes.

On les interroge avec le langage SQL, qui se lit presque comme une phrase. Les moteurs les plus courants sont PostgreSQL, MySQL et SQLite. Tous parlent SQL, mais ce sont des programmes différents, à ne pas confondre avec le langage lui-même.

Ce que veut dire NoSQL

NoSQL n'est pas une seule techno. C'est un terme parapluie qui veut dire "pas seulement du relationnel". Il regroupe plusieurs familles très différentes :

• Document (MongoDB) : tu stockes des documents proches du format JSON, souples, qui peuvent contenir des objets imbriqués.
• Clé-valeur (Redis) : une clé pointe vers une valeur, point. Très rapide, parfait pour du cache ou des sessions.
• Colonnes (Cassandra) : pensé pour de très gros volumes répartis sur plusieurs machines.
• Graphe (Neo4j) : pour les données fortement connectées, comme un réseau d'amis ou de recommandations.

Mettre tout ça dans un seul sac face à "SQL" n'a pas beaucoup de sens. C'est déjà un premier indice que la question de départ est mal posée.

Trois critères pour trancher

1. Tes données ont-elles des relations ? Des utilisateurs liés à des commandes, liées à des produits. Si oui, le relationnel est taillé pour ça. Il sait relier ces morceaux sans que tu dupliques l'information partout.

2. Ta structure est-elle stable ? Un schéma fixe protège ta donnée des erreurs : impossible d'enregistrer une commande sans montant. C'est une force du relationnel. Si au contraire chaque enregistrement a une forme différente et imprévisible, le document devient pertinent.

3. Comment vas-tu lire la donnée ? Si tu lis souvent un objet entier d'un coup, le document brille. Si tu croises sans cesse des données entre elles ("toutes les commandes payées ce mois-ci"), le relationnel répond en une requête.

Un mythe à casser tout de suite : NoSQL ne veut pas dire "pas de modélisation". Même avec MongoDB, tu dois réfléchir à la structure de tes données. Et de l'autre côté, PostgreSQL sait stocker du JSON souple nativement. La frontière est moins nette qu'on te le vend.

Un mot sur la cohérence et la montée en charge

Deux notions reviennent sans arrêt dans ce débat. Autant les démystifier.

La cohérence, d'abord. Les bases relationnelles offrent des garanties dites ACID. En clair, la base refuse toute opération qui laisserait tes données dans un état bancal. Si tu débites un compte et crédites un autre, soit les deux mouvements se font, soit aucun. Pour une application qui manipule de l'argent ou des stocks, c'est une protection précieuse.

La montée en charge, ensuite. Quand le trafic grimpe, le relationnel grossit surtout en passant sur une machine plus puissante. Certaines bases NoSQL sont pensées dès le départ pour s'étaler sur des dizaines de machines. C'est un avantage réel, mais à une échelle que ton premier projet n'atteindra pas avant longtemps.

Le même besoin, deux modèles

Rien ne vaut un exemple. Prenons des utilisateurs et leurs commandes, modélisés des deux façons.

Version relationnelle (SQL)

Deux tables, reliées par une référence :

CREATE TABLE users (
  id         SERIAL PRIMARY KEY,
  email      TEXT UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT now()
);
 
CREATE TABLE orders (
  id      SERIAL PRIMARY KEY,
  user_id INTEGER REFERENCES users(id),
  total   NUMERIC(10, 2) NOT NULL,
  status  TEXT NOT NULL
);

Pour récupérer les e-mails des clients ayant une commande payée :

SELECT users.email, orders.total
FROM orders
JOIN users ON users.id = orders.user_id
WHERE orders.status = 'paid';

Version document (NoSQL)

Ici, les commandes vivent à l'intérieur de l'utilisateur :

{
  "_id": "u_123",
  "email": "sami@example.com",
  "orders": [
    { "total": 49.90, "status": "paid" },
    { "total": 12.00, "status": "pending" }
  ]
}

Le compromis saute aux yeux. Lire tout ce qui concerne un utilisateur ? Le document est imbattable, tout est au même endroit. Mais demande "la moyenne des commandes payées ce mois-ci, tous utilisateurs confondus", et le modèle document se met à lutter, là où le relationnel répond d'une seule requête.

Et quand la forme de tes données varie

Tu n'as pas besoin de choisir un camp pour gérer des données souples. PostgreSQL range du JSON dans une simple colonne, ce qui te donne la flexibilité du document sans quitter le relationnel :

ALTER TABLE orders
  ADD COLUMN metadata JSONB;
 
-- on range ici des champs libres et variables
UPDATE orders
SET metadata = '{"source": "mobile", "coupon": "ETE40"}'
WHERE id = 1;

Résultat, la majorité de tes données reste structurée et fiable, et le champ qui doit rester libre l'est aussi. Beaucoup de projets croient avoir besoin de NoSQL alors qu'une colonne JSON aurait largement suffi.

Quand le relationnel gagne

• Boutique en ligne, factures, comptabilité, réservations : des données reliées, avec un besoin fort de cohérence.
• La plupart des applications de gestion classiques, celles qui créent, lisent, modifient et suppriment des enregistrements.
• Tout ce qui demande des statistiques croisées et des rapports.

Pour ce type de besoin, une base relationnelle est le choix par défaut sûr. Si tu vises un poste de développeur backend, c'est aussi la compétence la plus demandée : savoir modéliser et interroger une base SQL. C'est ce qu'on travaille en profondeur dans notre formation SQL et bases de données relationnelles, du schéma jusqu'aux requêtes qui croisent plusieurs tables.

Quand le NoSQL est le bon outil

• Document : un contenu dont la forme varie beaucoup d'un enregistrement à l'autre, comme un catalogue de produits très hétérogènes.
• Clé-valeur : du cache, des sessions, des files d'attente. Souvent en complément d'une base SQL, pas à sa place.
• Un gros volume d'écriture en continu : journaux, événements, mesures en temps réel.
• Des données fortement connectées, où la base graphe devient pertinente.

Le scénario le plus fréquent en pratique : une base relationnelle comme magasin principal, et un Redis pour le cache le jour où la performance le réclame. Les deux cohabitent sans souci. C'est d'ailleurs ce que tu rencontres quand tu connectes une base à une application complète, comme dans notre parcours fullstack avec Next.js et base de données.

Les pièges classiques

Voici les erreurs qui reviennent le plus souvent chez ceux qui choisissent leur première base.

Comment décider en trois minutes

Si tu hésites encore, déroule ces questions dans l'ordre :

1. Mes données ont-elles des relations claires entre elles ? Si oui, relationnel.
2. Ai-je besoin que la base refuse les données incohérentes, surtout sur de l'argent ou des stocks ? Si oui, relationnel.
3. Ai-je un cas précis et identifié de cache, de très gros volume d'écriture ou de données en graphe ? Si oui, ajoute l'outil NoSQL correspondant, en complément.
4. Dans le doute, pars sur PostgreSQL ou MySQL. C'est le pari le plus sûr pour un premier projet.

La réponse honnête pour un premier projet est presque toujours la même : prends une base relationnelle, PostgreSQL ou MySQL, apprends à modéliser et à écrire du SQL, et ajoute du NoSQL le jour où un besoin précis le réclame. Tu acquiers une compétence qui te servira partout, et tu ne te bloques pas.

Le bon choix n'est pas le plus impressionnant. C'est celui que tu comprends.

Questions fréquentes