CRDT : comment synchroniser les données sans serveur pour arbitrer les conflits

Imaginez deux utilisateurs éditant le même document sur des plans différents, sans Internet. Chacun change le même champ. Lorsqu'ils atterrissent et que les appareils se synchronisent, quelqu'un doit décider quelle version gagne. La réponse traditionnelle était simple et brutale : la dernière sauvegarde écrase la précédente. L'autre perd son emploi et ne s'en rend même pas compte.

C’est le problème central de toute application locale. Les données résident d’abord sur l’appareil, la modification s’effectue hors ligne et la réconciliation intervient plus tard. La question n’est pas de savoir s’il y aura conflit, mais plutôt de savoir comment fusionner deux vérités divergentes sans perdre d’informations et, idéalement, sans s’en remettre à un serveur central faisant office de juge. Les CRDT sont la réponse mathématique la plus élégante dont nous disposons à cela.

Qu'est-ce qu'un CRDT, sans mysticisme

CRDT signifie Type de données répliquées sans conflit. Le nom fait plus peur que le concept. En pratique, il s’agit d’une structure de données conçue pour que plusieurs copies puissent être éditées indépendamment et, lorsqu’elles se rencontrent, elles convergent automatiquement vers le même état final, sans coordination préalable.

Le mot-clé est convergence. Peu importe l'ordre dans lequel les modifications arrivent, ni le nombre de fois où la même modification est appliquée, ni le nombre de sauts qu'elle a parcourus à travers le réseau. Si deux appareils voient le même ensemble d’opérations, ils finissent par être identiques. Cette garantie est mathématique et non une promesse de bonne volonté du code.

Pour y parvenir, les opérations d'un CRDT doivent avoir trois propriétés. Ils sont commutatifs, donc l’ordre ne change pas le résultat. Ils sont associatifs, donc le regroupement n'a pas d'importance. Et ils sont idempotents, donc appliquer deux fois la même chose ne cause pas de dégâts. Les structures qui respectent ces règles forment ce que les mathématiques appellent des semi-réseaux, et c'est de là que vient la garantie de convergence.

Pourquoi cela résout le problème du local d'abord

Sans CRDT, la synchronisation hors ligne nécessite un arbitre. Normalement, un serveur qui reçoit toutes les versions, applique n'importe quelle règle, souvent la fameuse dernière écriture, gagne et renvoie la vérité officielle. Cela a deux coûts. Les données perdues en écrasement et la dépendance à un point central toujours en ligne pour résoudre toute divergence.

Les CRDT dissolvent cette dépendance. La fusion étant déterministe et intégrée à la structure elle-même, n’importe quel périphérique peut fusionner avec n’importe quel autre, dans n’importe quelle topologie. Deux téléphones portables peuvent se synchroniser directement via Bluetooth, trois répliques peuvent s'emboîter dans un maillage, et le résultat est le même qu'avec un serveur coordonnant le tout. Le serveur, lorsqu’il existe, devient simplement un relais commode, et non une autorité.

Cela change la nature de la demande. L'utilisateur n'attend pas une réponse du réseau pour voir sa modification appliquée, car la vérité locale est déjà valide. La synchronisation s'effectue en arrière-plan et ne revient jamais en disant "votre travail a été supprimé". C’est ce qui rend l’expérience des applications en tant qu’éditeurs collaboratifs modernes si fluide, et c’est la base technique de toute architecture sérieuse axée sur le local.

Les saveurs CRDT que vous retrouverez

Deux grands styles dominent. Les CRDT basés sur l'état échangent la structure entière entre les répliques et utilisent une fonction de fusion pour les combiner. Ils sont simples à raisonner, mais pèsent lourdement sur le réseau lorsque les données augmentent. Les opérations basées sur les opérations propagent uniquement les modifications individuelles, ce qui est plus économique, mais nécessite une couche de livraison d'opérations fiable.

Au-dessus de ces styles se trouve un catalogue de types prêts à l'emploi. Compteurs qui ajoutent des incréments à partir de plusieurs répliques sans en perdre. Des ensembles qui savent mélanger des ajouts et des suppressions de manière cohérente, comme OR-Set. Et le cas le plus convoité, le texte séquentiel, où chaque caractère reçoit un identifiant unique et triable afin que les insertions concurrentes ne se superposent pas. Des algorithmes comme Yjs et Automerge regroupent tout cela dans des bibliothèques que vous utilisez sans réimplémenter la théorie.

La bonne nouvelle pour les décideurs en architecture est que vous rédigez rarement un CRDT à partir de zéro. Vous choisissez la bibliothèque, modélisez vos données sur les types qu'elle propose et bénéficiez de la convergence en cadeau. Le travail intellectuel consiste à cartographier le domaine avec ces structures, et non à prouver des théorèmes.

Là où les CRDT brillent vraiment

Ils sont imbattables lorsque la règle de fusion est véritablement neutre, c'est-à-dire lorsque conserver les deux modifications est toujours le comportement correct. Le texte collaboratif en est l’exemple parfait : si deux personnes tapent des paragraphes différents, vous voulez les deux paragraphes, point final. Les listes, les tableaux Kanban, les notes, les dessins vectoriels et la plupart des outils de productivité collaboratifs entrent dans cette catégorie.

Ils brillent également dans les scénarios où la connectivité est mauvaise ou de nature intermittente. Applications de terrain, collecte de données dans des zones reculées, appareils qui passent des heures hors ligne. Dans les applications offline-first, CRDT est ce qui vous permet de travailler en toute confiance : rien ne sera perdu lors de la prochaine synchronisation. La convergence automatique est exactement la garantie qu’exigent ces contextes.

Et ils brillent lorsque vous souhaitez éliminer le serveur du chemin critique. Architectures peer-to-peer, maillages locaux, synchronisation entre appareils appartenant à un même utilisateur sans passer par le cloud. Tout cela est viable car l’intelligence de fusion réside dans les données et non dans l’infrastructure.

Là où ce n'est pas la bonne réponse

Voici la partie qui est souvent balayée sous le tapis. Les CRTD convergent vers un état valide, mais pas nécessairement vers l'état que votre entreprise considère comme correct. La convergence n’est pas synonyme de règles métier satisfaites. Si deux personnes réservent le dernier siège sur un vol hors ligne, CRDT fusionnera volontiers les deux réservations et vous aurez une garantie mathématique de surréservation.

Les conflits qui nécessitent une décision sémantique n’ont pas leur place dans le CRDT. L'équilibre qui ne peut pas être négatif, l'unicité d'un domaine, l'approbation qui en invalide un autre, tout invariant qui a besoin d'un « non, cela ne peut pas arriver » veut un véritable arbitre. Dans ces cas-là, la règle métier doit trancher le conflit, et essayer de le transmettre à la couche de données produit des bugs subtils et coûteux.

Il y a aussi le coût de la mémoire et du stockage. Pour garantir la convergence, de nombreux CRDT stockent des métadonnées qui augmentent avec l'historique des modifications. Suppression des pierres tombales d'éléments, des identifiants par caractère, des vecteurs de version. Sans stratégies de compactage, une structure apparemment petite peut gonfler dans des proportions surprenantes. Tous les problèmes ne deviennent pas CRDT à moindre coût, et tous les problèmes ne devraient pas le faire.

Ma recommandation en tant que CTO est pragmatique. Utilisez CRDT où la fusion est naturellement additive et le gain d'expérience est réel. Lorsque l'exactitude dépend d'un invariant métier, acceptez un arbitre, qu'il s'agisse d'un serveur, d'une file d'attente de commandes ou d'un flux de résolution explicite présenté à l'utilisateur. L’erreur la plus courante consiste à traiter le CRDT comme une solution miracle et à découvrir la surréservation en production.