Deux personnes modifient le même document sans réseau, puis leurs appareils se reconnectent. Les CRDT permettent de réunir leurs changements automatiquement, sans qu’un serveur impose systématiquement une version unique.
Cette approche sert notamment à la synchronisation, à la collaboration et aux applications hors ligne. Pour comprendre son intérêt, il faut regarder comment la réplication des données peut rester cohérente malgré des modifications simultanées.
A retenir :
- Modifications distribuées sans serveur central toujours disponible
- Fusion automatique des changements compatibles
- Collaboration hors ligne plus robuste
- Règles métier nécessaires pour traiter les conflits
CRDT : comprendre leur fonctionnement concret
Quand plusieurs appareils changent une même donnée, les CRDT remplacent l’arbitrage permanent par des règles de fusion précises. Chaque copie peut évoluer localement, puis échanger ses mises à jour avec les autres.
Réplication des données et cohérence éventuelle
Selon les travaux de Shapiro et ses coauteurs, un CRDT est conçu pour converger lorsque les répliques échangent leurs modifications. La cohérence éventuelle signifie que des copies temporairement différentes finissent par retrouver un état commun.
Imaginons Lina et Karim qui éditent une liste de courses dans le métro, sans connexion. Lina ajoute du café sur son téléphone tandis que Karim retire le pain sur sa tablette. À la reconnexion, les appareils échangent leurs changements et appliquent les règles prévues par la structure de données.
Cette méthode ne signifie pas que toutes les opérations sont toujours fusionnées sans discernement. Elle garantit plutôt que les copies convergent de façon prévisible, si les règles du CRDT sont correctement définies et les mises à jour propagées.
Deux grandes familles de CRDT
Pour choisir une solution, les développeurs distinguent généralement les structures qui échangent leur état de celles qui propagent leurs opérations. Dans les deux cas, le modèle doit préserver les propriétés nécessaires à la convergence.
Un compteur distribué peut additionner des changements enregistrés sur plusieurs appareils. Un ensemble peut, lui, suivre des ajouts et des suppressions selon une règle explicite. Selon Shapiro et ses coauteurs, ces structures s’appuient sur des propriétés mathématiques qui rendent leur fusion indépendante de l’ordre d’arrivée des mises à jour.
Les différences sont utiles lors du choix d’une architecture, car elles influencent les échanges réseau, la mémoire utilisée et le comportement attendu. Voici un repère simplifié, sans attribuer de performances chiffrées à une famille entière.
Familles et usages courants :
Famille
Principe général
Exemple d’usage
CRDT à état
Échange d’états répliqués
Compteur partagé
CRDT à opérations
Propagation des opérations
Ajout dans un ensemble
CRDT séquentiel
Organisation d’éléments ordonnés
Document collaboratif
CRDT de registre
Gestion de valeurs concurrentes
Préférence synchronisée
CRDT et édition simultanée : des usages réels
Une fois les règles de convergence comprises, leur intérêt apparaît dans les outils que plusieurs personnes utilisent en même temps. Les CRDT sont particulièrement adaptés lorsque la connexion est intermittente ou que la réactivité locale compte.
Collaboration dans les documents partagés
Dans un éditeur collaboratif, deux personnes peuvent insérer du texte au même endroit avant que leurs appareils ne communiquent. Une structure adaptée conserve les ajouts et leur ordre, au lieu de remplacer silencieusement le travail d’une personne.
Selon Shapiro et ses coauteurs, les structures répliquées peuvent converger sans coordination préalable permanente. Cela favorise l’édition simultanée, mais ne décide pas à la place de l’équipe comment traiter une modification incompatible avec une règle métier.
Par exemple, un outil de gestion de tâches peut recevoir simultanément la suppression d’une tâche et son changement de responsable. La fusion technique doit alors s’accompagner d’un choix produit : conserver l’élément, signaler une anomalie ou appliquer une priorité définie.
Situations où les CRDT sont utiles :
- Édition partagée de notes ou de documents
- Applications mobiles utilisables sans connexion
- Listes et tableaux modifiés par plusieurs comptes
- Jeux synchronisant des états entre appareils
Applications hors ligne et resynchronisation
Pour une application hors ligne, l’utilisateur doit pouvoir continuer à travailler sans attendre le serveur. Les changements restent enregistrés localement, puis la synchronisation les transmet lorsque le réseau revient.
Cette expérience évite qu’une coupure bloque une note ou une saisie de terrain. Elle exige néanmoins de gérer les comptes, les autorisations, la suppression de données et la propagation fiable des modifications entre appareils.
Résolution de conflits : limites et choix techniques
La convergence règle une partie des désaccords entre copies, mais elle ne comprend pas le sens de chaque action. Une application doit donc définir les conflits que la fusion automatique peut résoudre et ceux qui réclament une décision humaine.
Quand la fusion automatique ne suffit pas
Deux changements peuvent être techniquement compatibles tout en contredisant une règle importante. Si deux personnes réservent la dernière place disponible, une simple fusion des modifications ne garantit pas que l’entreprise respecte sa capacité réelle.
La résolution de conflits doit alors tenir compte des règles métier, comme l’ordre de validation ou la priorité d’un responsable. Les CRDT ne remplacent ni les contrôles d’accès ni les transactions nécessaires aux opérations sensibles.
Pour distinguer les bons cas d’usage, on peut examiner le type de donnée, la connectivité attendue et le coût d’une erreur. Ce diagnostic évite de choisir une architecture distribuée uniquement parce qu’elle paraît plus moderne.
Critères de choix pour un projet :
- Fréquence des modifications concurrentes
- Possibilité d’un travail sans réseau
- Conséquences d’une fusion incorrecte
- Volume et durée de conservation des données
CRDT ou base de données distribuée classique
Les CRDT peuvent constituer une brique de bases de données distribuées, mais les deux notions ne sont pas synonymes. Une base distribuée englobe aussi le stockage, les requêtes, la sécurité et la disponibilité du service.
Le choix dépend du comportement recherché, et non d’une supériorité universelle. Un système centralisé peut rester plus simple lorsque les utilisateurs sont toujours connectés et que les opérations doivent être validées dans un ordre strict.
Comparaison selon les besoins du produit :
Besoin
CRDT
Approche centralisée
Travail hors ligne
Adapté à des changements locaux
Dépend généralement du serveur
Convergence des copies
Fondée sur des règles de fusion
État commun géré par le serveur
Arbitrage métier complexe
Logique applicative souvent nécessaire
Contrôle central plus direct
Déploiement initial
Modèle de données à concevoir soigneusement
Architecture parfois plus simple
Le bon choix se joue donc entre autonomie locale et contrôle central, selon les conséquences concrètes d’un conflit. Lorsqu’une application doit rester utilisable malgré les coupures, les CRDT offrent une manière structurée de préserver les modifications.
Source : Marc Shapiro, Nuno Preguiça, Carlos Baquero et Marek Zawirski, « A comprehensive study of Convergent and Commutative Replicated Data Types », INRIA, 2011.