Bases NoSQL : document, clé-valeur, colonnes, graphe et CAP

45 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 12 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

« NoSQL » désigne les bases qui ne suivent pas le modèle relationnel : elles rangent les données en documents, en paires clé-valeur, en colonnes larges ou en graphes, et la plupart sont conçues pour se répartir entre plusieurs machines. Ce n'est pas une famille unique mais quatre, qui répondent à des besoins différents. Cette leçon apprend à les distinguer, à dire ce qu'elles cèdent en échange de leur souplesse, et à lire le choix que fait tout système réparti quand le réseau se coupe, résumé par le théorème CAP.

Ce que vous allez apprendre

Distinguer les familles document, clé-valeur, colonnes larges et graphe
Dire ce qu'une base NoSQL échange contre sa souplesse et sa répartition
Expliquer le choix CAP d'un système réparti pendant une coupure réseau
Reconnaître quand une base relationnelle reste le meilleur choix

Quelles sont les quatre familles NoSQL ?

Les quatre familles se distinguent par la forme des données qu'elles rangent, et cette forme décide des questions qu'on peut leur poser efficacement. Une base clé-valeur répond très vite à « donne-moi la valeur de cette clé », et à presque rien d'autre ; une base graphe répond à « qui est relié à qui », ce qu'une base relationnelle fait mal. Le tableau les range avec un exemple de produit et un usage typique.

Famille	Forme des données	Exemples	Usage typique
Document	documents structurés, souvent en JSON	MongoDB, Couchbase	catalogue produit aux attributs variables
Clé-valeur	une clé, une valeur opaque	Redis, DynamoDB, etcd	sessions, configuration, compteurs
Colonnes larges	lignes aux colonnes nombreuses et variables, réparties	Cassandra, ScyllaDB, HBase	journaux d'événements à très gros volume
Graphe	nœuds et relations	Neo4j	recommandations, réseaux de relations

Un même produit peut appartenir à plusieurs familles selon son usage. Redis est une base clé-valeur, mais on le rencontre surtout comme cache, une famille que traite une autre leçon de ce module. Sur un schéma, on lit donc la forme des données et la question posée, pas le nom du produit.

Qu'échange une base NoSQL contre sa souplesse ?

La plupart des bases NoSQL cèdent une partie des garanties relationnelles pour gagner en souplesse de schéma et en répartition horizontale. Pas de schéma imposé : un document peut porter des champs que le précédent n'avait pas. Répartition native : les données se découpent entre de nombreuses machines, et la base monte en charge horizontalement, ce qu'une base relationnelle fait difficilement.

Le prix se paie sur les garanties. Les jointures sont absentes ou limitées, il faut donc ranger les données dans la forme où on les lira. Les transactions couvrant plusieurs enregistrements sont absentes ou restreintes selon les produits. Et la cohérence est souvent éventuelle par défaut : une lecture peut renvoyer une valeur ancienne pendant que la modification se propage entre les nœuds.

Que dit le théorème CAP ?

Le théorème CAP dit qu'un système réparti, quand le réseau se coupe entre ses nœuds, doit choisir entre rester cohérent et rester disponible. Les trois lettres désignent la cohérence (Consistency : toute lecture voit la dernière écriture), la disponibilité (Availability : toute requête reçoit une réponse) et la tolérance au partitionnement (Partition tolerance : le système continue malgré une coupure entre ses nœuds).

La formule répandue « choisissez deux propriétés sur trois » est trompeuse. La coupure réseau n'est pas un choix, elle finit toujours par arriver dès que le système est réparti. La vraie question se pose donc pendant une coupure, et elle n'a que deux réponses, que le schéma met côte à côte.

Pendant une coupure, le nœud 2 ne sait pas ce que le nœud 1 vient d'écrire : il refuse (CP) ou répond avec une valeur peut-être ancienne (AP). Source · SVG

Un système CP refuse de servir une partie des requêtes pour ne jamais renvoyer une donnée fausse : le nœud isolé cesse d'accepter les écritures. Un système AP continue de répondre partout, en acceptant que des lectures soient anciennes et que des écritures contradictoires doivent être réconciliées après la coupure. En dehors des coupures, un système peut offrir cohérence et disponibilité à la fois ; l'extension PACELC ajoute qu'il arbitre alors entre cohérence et latence.

Comment lire le choix CAP d'un produit ?

Beaucoup de bases réparties ne sont ni CP ni AP une fois pour toutes : elles laissent régler la cohérence requête par requête. Cassandra, par exemple, permet de demander qu'une écriture soit confirmée par un seul nœud, par une majorité ou par tous : plus on en exige, plus la cohérence est forte et plus la disponibilité et la latence en souffrent. Lire une architecture, c'est donc chercher ce réglage, pas seulement le nom du produit.

Une base relationnelle sur une seule machine n'entre pas dans ce débat : elle n'a pas de partition possible, elle est simplement indisponible quand elle tombe. Le choix CAP apparaît dès qu'elle est répliquée et qu'une bascule automatique doit décider, pendant une coupure, quel nœud a le droit d'écrire.

Que garder, que sauvegarder, que craindre ?

Une base NoSQL porte des données métier au même titre qu'une base relationnelle : la souplesse du modèle ne réduit en rien le besoin de sauvegarde. La réplication entre nœuds y est souvent native et nombreuse, ce qui donne l'illusion d'une donnée à l'abri. Elle protège de la perte d'un nœud, pas d'une suppression ou d'une corruption propagée à toutes les copies.

Question de la grille	Ce qu'il faut regarder
État porté	données métier, souvent réparties entre de nombreux nœuds
À sauvegarder	les données, par instantanés cohérents de tout le cluster
Réplication	native ; nombre de copies et niveau de cohérence à vérifier
Montée en charge	horizontale, en ajoutant des nœuds
Mode de panne typique	nœuds en désaccord après une coupure, rééquilibrage qui sature le réseau
Signal à surveiller	latence par niveau de cohérence, nœuds absents, volume de données à resynchroniser

Ce que le NoSQL changerait dans la boutique

La boutique n'a pas besoin de remplacer sa base relationnelle : ses commandes exigent des transactions. Une base document pourrait en revanche porter le catalogue, dont chaque produit a des attributs différents, taille pour un vêtement et puissance pour un appareil. Le cache de sessions, une base clé-valeur dans les faits, est traité dans sa propre leçon.

Ce découpage, une famille par forme de données, s'appelle parfois persistance polyglotte. Il a un coût : chaque base ajoutée est une brique de plus à rendre disponible, à sauvegarder et à surveiller, avec ses propres modes de panne. Une boutique de taille modeste gagne souvent à tout garder dans une seule base relationnelle, qui sait aussi stocker des documents JSON.

Une base NoSQL : ce qu'elle apporte, ce qu'elle coûte

Une base NoSQL échange des garanties contre de la souplesse et de la répartition, et le bon choix dépend de ce que l'application ne peut pas perdre. Le tableau pose ce compromis pour le catalogue de la boutique.

Ce qu'on gagne	Ce qu'on paie
un schéma souple pour des produits aux attributs variés	des données rangées pour une lecture précise, peu de jointures
une montée en charge horizontale native	une cohérence souvent éventuelle à comprendre et régler
une réplication intégrée entre nœuds	une brique de plus à exploiter et à sauvegarder
des écritures très rapides à grande échelle	des transactions limitées entre enregistrements

Qui prend le relais pour installer et exploiter ces bases ?

Cette leçon décrit le rôle architectural des familles NoSQL ; leur mise en service relève des guides spécialisés. La section Les serveurs de base de données présente les familles et leurs produits ; le guide Données managées traite le choix entre service managé et base auto-gérée ; la leçon Répliquer, sauvegarder et basculer une base explique ce que la réplication des offres cloud protège ; le guide Synchrone, asynchrone et eventual consistency positionne les grandes bases cloud face au choix CAP.

Pièges de lecture courants

Ces confusions reviennent devant une base NoSQL, et elles viennent surtout d'un nom de famille pris pour une garantie :

Croire que NoSQL veut dire sans schéma du tout : l'application en impose un, simplement hors de la base.
Lire « deux sur trois » dans CAP : la coupure arrive, le choix porte sur cohérence ou disponibilité.
Prendre la réplication native pour une sauvegarde.
Classer un produit dans une seule famille : Redis est base clé-valeur et cache selon l'usage.
Remplacer une base transactionnelle par une base sans transactions pour des données qui en exigent.

À retenir

NoSQL regroupe quatre familles : document, clé-valeur, colonnes larges et graphe, chacune liée à une forme de données.
Elles échangent des garanties relationnelles contre la souplesse et la répartition horizontale.
CAP : pendant une coupure, un système réparti choisit entre cohérence (CP) et disponibilité (AP).
Beaucoup de bases laissent régler la cohérence requête par requête.
La réplication native ne remplace pas la sauvegarde.
Des données qui exigent des transactions restent dans une base relationnelle.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin