1. Les limites du modèle relationnel classique et l’émergence du NoSQL

Bien que le modèle relationnel soit irremplaçable pour les transactions bancaires et les règles d’intégrité complexes, l’explosion du web à grande échelle a révélé des contraintes : schémas rigides difficiles à faire évoluer en continu, difficultés de mise à l’échelle horizontale (Scale-Out) sur des centaines de serveurs et inadéquation pour les données non structurées.

2. Le théorème CAP d’Eric Brewer

Dans un système informatique distribué avec partitionnement réseau, il est mathématiquement impossible de garantir simultanément les trois propriétés suivantes :

• Consistance (Consistency) : Tout client lisant le système voit instantanément la mise à jour la plus récente, quelle que soit la réplique interrogée.
• Disponibilité (Availability) : Chaque requête reçoit une réponse réussie (sans erreur), même si certaines machines sont ralenties.
• Tolérance au partitionnement (Partition Tolerance) : Le système continue d’opérer malgré la rupture ou la latence des communications réseau entre les nœuds.

Le réseau étant par nature sujet à des pannes (P est inévitable), tout système distribué doit choisir entre la Consistance (CP, comme MongoDB configuré pour l’écriture majoritaire) ou la Disponibilité (AP, comme Apache Cassandra ou DynamoDB sous consistance éventuelle – BASE).

3. Les grandes familles de bases NoSQL

• Orientées Documents (MongoDB, CouchDB) : Données représentées sous forme de documents JSON/BSON arborescents et auto-descriptifs sans schéma préalable fixe.
• Clé-Valeur (Redis, Valkey) : Dictionnaires ultra-rapides stockés directement en mémoire vive RAM pour des accès sous la milliseconde.
• Orientées Colonnes larges (Cassandra, ScyllaDB) : Conçues pour l’ingestion massive de séries temporelles et télémétrie IoT.
• Orientées Graphes (Neo4j) : Optimisées pour naviguer instantanément le long de relations hautement interconnectées (réseaux sociaux, détection de réseaux de fraude).