« On va mettre ça en NoSQL » ressemble à une décision d’architecture, mais ne choisit presque rien. Une base clé-valeur, une base de documents, une famille de colonnes et une base graphe n’optimisent pas les mêmes accès. Le bon point de départ reste la question qu’on pose et les garanties exigées.

Une base relationnelle normalise les entités, impose des contraintes et permet des jointures. Son moteur tient un journal, verrouille ou versionne les lignes et utilise des index pour trouver les données. NoSQL retire ou déplace certaines de ces capacités afin de répartir, grossir ou simplifier un type d’accès.

Comparer deux modèles pour un panier

En SQL, on pourrait garder :

• Panier(Id, Client, Version);
• LignePanier(PanierId, ProduitId, Quantite, Prix);
• une clé étrangère et une transaction pour modifier entête et lignes.

Dans une base de documents, le panier complet peut être un document JSON indexé par PanierId. Une lecture ramène tout le panier sans jointure. Ajouter un article réécrit une partie du document. Ce modèle fonctionne bien tant que le panier reste petit et qu’on ne doit pas analyser toutes les lignes de tous les paniers de cent façons.

La clé de partition décide où vit le document. Utiliser ClientId regroupe les paniers d’un client, mais un énorme client peut créer une partition chaude. Changer cette clé après des milliards de documents est coûteux. Le modèle physique doit donc partir des requêtes et de la distribution attendue.

Cohérence, disponibilité et réparation

Dans un cluster répliqué, une écriture peut être confirmée après un seul nœud ou après plusieurs. Attendre plusieurs copies réduit le risque de lire une ancienne valeur, mais augmente la latence et peut refuser l’écriture pendant une partition réseau. Accepter localement maintient la disponibilité, puis demande une règle de résolution si deux côtés modifient la même clé.

Pour un panier, « dernier écrit gagne » peut supprimer un article ajouté sur un autre appareil. Conserver une version, fusionner les lignes ou demander une révision protège mieux l’intention. Pour un solde bancaire, une cohérence éventuelle sans contrôle serait beaucoup plus risquée.

Les index secondaires ne sont pas toujours gratuits ni immédiatement cohérents. Une requête ad hoc que SQL optimiserait peut demander un traitement externe. Les sauvegardes doivent capturer métadonnées du cluster, données et configuration; copier les fichiers d’un seul nœud en marche ne garantit pas une restauration cohérente.

La sécurité ne se limite pas au port réseau. Plusieurs produits jeunes supposent un réseau de confiance. Il faut authentification, chiffrement, rôles, audit et exposition minimale. Une console d’administration ouverte transforme la facilité de déploiement en facilité de suppression.

Je ferais un prototype avec le volume et les pannes, pas seulement cent documents. Je mesurerais écriture, lecture, rééquilibrage, perte d’un nœud et restauration. Si les relations et transactions dominent, SQL reste probablement le choix le plus simple. Si un accès stable à de très gros agrégats domine, une famille NoSQL peut être excellente — une fois la famille choisie pour une raison précise.