# Édition collaborative : éviter les pertes de données

> Deux personnes modifient la même fiche au même moment, et l'une perd son travail sans le savoir. Ce problème discret touche aussi les outils métier des PME : voici comment le résoudre, en nous appuyant sur un retour d'expérience technique récent.

Article de comm.it publié le 11 octobre 2026.


![Illustration épurée de deux personnes travaillant sur un même document partagé, l'une sur ordinateur au bureau et l'autre sur tablette sur le terrain, dont les modifications colorées convergent harmon](https://commit.insit.net/media/comm.it_edition-collaborative-eviter-les-pertes-de-donnees-7edd5b.png)

## Un problème invisible jusqu'au jour où il coûte cher

Dans une entreprise, on partage une fiche client, un devis, une procédure interne ou un planning. Plusieurs personnes les modifient chaque jour, parfois en même temps. Tant que tout va bien, personne ne se demande comment l'outil gère ces modifications simultanées. Puis un commercial constate que sa note d'appel a disparu, ou un technicien découvre que l'intervention saisie sur le terrain n'apparaît plus dans le dossier.

Ce scénario porte un nom : la **perte de modifications concurrentes**. Il vient d'un choix de conception très répandu, le **« last write wins »** (la dernière écriture l'emporte). Un retour d'expérience publié par les équipes de Notion le décrit très bien. Cet article sert ici de point de départ pour expliquer ce que ces choix techniques impliquent pour vos propres outils, et comment comm.it vous aide à les maîtriser.

**Source :** « How Notion handles concurrent editing with CRDTs », par Angelique Nehmzow, Emma Guo, Fabricio Pontes Harsich et Stephan Boyer, publié sur le blog de Notion.

## Le piège du « last write wins »

Le principe est simple. Le serveur reçoit les mises à jour dans l'ordre où elles arrivent et enregistre la dernière. Si deux personnes ont ouvert le même enregistrement et l'ont modifié chacune de leur côté, seule la version enregistrée en dernier survit. L'autre est écrasée, sans message d'erreur et sans trace.

Les auteurs donnent un exemple parlant. Une utilisatrice ajoute un mot au milieu d'une phrase pendant qu'un collègue en ajoute un autre à la fin. Au lieu d'obtenir une phrase qui combine les deux ajouts, le système n'en garde qu'un. Ils ajoutent un constat important : **plus le nombre de collaborateurs augmente, plus le risque qu'une modification soit écrasée augmente**.

Dans leur cas, le problème était en partie masqué par l'architecture : une page est composée de nombreux **blocs**, chacun stocké dans un enregistrement séparé de la base de données. Deux personnes qui modifient deux blocs différents ne se gênent pas. En revanche, deux personnes qui touchent au même bloc entrent en conflit.

Cette situation se retrouve dans beaucoup de logiciels métier :

- un **CRM** où une fiche contact est enregistrée d'un seul tenant, champ « notes » compris ;
- un **ERP** où une commande ou une nomenclature est modifiée par plusieurs services ;
- un outil interne développé rapidement, qui enregistre le formulaire complet à chaque sauvegarde ;
- un tableau partagé synchronisé entre plusieurs postes.

Dans tous ces cas, la granularité de l'enregistrement détermine la fréquence des conflits. Et la règle de résolution détermine qui perd son travail.

## Le mode hors ligne aggrave le risque

L'article de Notion souligne un point essentiel pour les PME qui ont des équipes mobiles : l'arrivée d'un **mode hors ligne** multiplie le risque de perte. Une personne qui travaille sans connexion peut accumuler des modifications pendant des heures. Si d'autres ont modifié les mêmes éléments entre-temps, la synchronisation au retour du réseau peut effacer tout son travail.

Pensez à un technicien qui intervient dans un sous-sol sans réseau, à un commercial dans le train ou à une équipe sur un chantier. Dès qu'une application métier promet de fonctionner hors connexion, la question de la **fusion des modifications** devient centrale. Une simple règle « le dernier gagne » ne suffit plus.

## Les CRDT : fusionner au lieu d'écraser

Pour résoudre ce problème, les équipes ont adopté un **CRDT** (*Conflict-free Replicated Data Type*). Il s'agit de structures de données qui permettent à plusieurs clients de garder chacun une copie locale des mêmes données, puis de **fusionner les modifications simultanées de façon déterministe**. Tout le monde arrive au même résultat, quel que soit l'ordre dans lequel les modifications sont reçues.

Les auteurs restent prudents sur un point : un CRDT garantit qu'aucune modification n'est perdue, mais pas que l'**intention** de chacun soit toujours parfaitement respectée. Si deux personnes réécrivent exactement la même phrase de deux façons différentes, le résultat fusionné ne correspondra pas forcément à ce que chacune voulait. En revanche, dans un document plus long, les collaborateurs modifient souvent des zones distinctes, et la fusion préserve alors bien les intentions.

### Des identifiants stables pour chaque caractère

La structure choisie s'inspire d'un CRDT de séquence classique, le **Replicated Growable Array (RGA)**. Concrètement :

- chaque caractère inséré reçoit un **identifiant unique et stable** ;
- les opérations d'insertion s'expriment par rapport à ces identifiants (« insérer après tel caractère ») plutôt que par rapport à une position numérique qui change dès que le texte bouge ;
- l'identifiant combine un **identifiant de session**, qui distingue les clients, et une **horloge de Lamport**, un compteur logique qui augmente au fil des opérations ;
- quand deux insertions visent le même endroit, l'ordre est tranché par l'horodatage logique le plus récent, puis par l'identifiant de session en cas d'égalité.

Les suppressions ne retirent pas réellement les caractères. Elles les marquent comme supprimés et les conservent sous forme de **« tombstones »** (pierres tombales). La raison est concrète : une opération encore en transit, ou saisie hors ligne, peut faire référence à un caractère supprimé entre-temps. Sans lui, impossible de savoir où l'appliquer.

Pour limiter le volume, les identifiants ne sont pas attribués caractère par caractère mais par **séquence contiguë** issue d'une même session, avec sa longueur.

### La mise en forme a aussi ses conflits

Un document professionnel ne contient pas que du texte brut. Gras, italique, liens, mentions : ces **annotations** peuvent elles aussi être appliquées en même temps par plusieurs personnes. Si l'une met un passage en gras pendant qu'une autre le met en italique, le résultat attendu est un passage en gras et en italique.

La solution décrite stocke des opérations d'ajout et de retrait d'annotations, avec des **points d'ancrage** placés juste avant ou juste après un caractère. Cette précision permet de distinguer :

- les annotations **extensibles**, comme le gras : si l'on tape à la suite, le nouveau texte reste en gras ;
- les annotations **non extensibles**, comme un lien hypertexte : le texte tapé juste après ne doit pas devenir un lien.

Ce niveau de détail montre que la collaboration en temps réel repose sur des règles fines, pensées pour correspondre à ce que l'utilisateur attend intuitivement.

## Quand un bloc se coupe en deux pendant qu'un autre écrit dedans

Le cas le plus original concerne la **scission de blocs**. Appuyer sur « Entrée » au milieu d'un paragraphe crée un nouveau bloc et répartit le texte entre les deux. Que se passe-t-il si, au même moment, un collègue ajoute du texte à la fin du paragraphe d'origine ? Son ajout doit atterrir dans le nouveau bloc, celui qui contient désormais la fin du texte, même s'il a été saisi dans l'ancien.

Pour y parvenir, les équipes ont introduit plusieurs notions :

- les **« text slices »**, des tranches de texte appartenant à un bloc, qui se divisent lors d'une scission ;
- l'**« arbre de tranches »**, qui organise les tranches d'un même bloc, y compris celles venues d'autres blocs ;
- l'**« instance de texte »**, un identifiant stable qui regroupe toutes les tranches issues d'une même tranche initiale, même après déplacements ;
- une **table de correspondance** entre instances de texte et blocs, mise à jour à chaque fois qu'un bloc reçoit une tranche d'une nouvelle instance.

Les opérations ne visent donc plus un bloc précis, mais une instance de texte. Le serveur consulte la correspondance pour retrouver les blocs concernés.

Cette approche a une limite que les auteurs détaillent : si un bloc est scindé 99 fois, on obtient 100 blocs qui contiennent tous une tranche de la même instance. Pour insérer un seul caractère, il faudrait charger les 100 blocs. La réponse est l'**« étiquette de recherche »** : chaque scission ajoute une lettre (gauche ou droite) à l'étiquette de la tranche. Une opération transporte cette étiquette, et le serveur cherche les blocs dont l'étiquette commence par celle-ci, ce qui tolère aussi les scissions survenues entre-temps. Grâce à un encodage compact, le stockage de ces étiquettes est cinq fois plus efficace qu'une écriture littérale.

## Un déploiement à grande échelle

Selon Notion, ce système est en production depuis juillet 2025 et traite des **millions d'opérations CRDT par minute**. Les auteurs précisent que ce modèle de données soutient aussi le mode hors ligne et la **collaboration avec des agents**, et qu'il sert de fondation à de futures fonctionnalités comme l'affichage de la présence des collaborateurs ou le regroupement de suggestions.

Ce dernier point mérite l'attention : dès lors que des **agents d'IA** modifient les mêmes documents que les humains, la gestion des écritures concurrentes n'est plus un détail technique. C'est une condition pour que l'automatisation ne détruise pas le travail des équipes.

## Ce que cela change pour une PME

Une PME n'a pas besoin de reconstruire un éditeur de texte collaboratif. En revanche, elle utilise, fait développer ou fait évoluer des outils dans lesquels plusieurs personnes, et de plus en plus de processus automatisés, modifient les mêmes données. Les enseignements de cet article s'appliquent directement :

1. **La granularité des données compte.** Enregistrer une fiche entière à chaque modification multiplie les conflits ; enregistrer champ par champ, ou opération par opération, les réduit fortement.
2. **La règle de résolution doit être choisie, pas subie.** « Le dernier gagne » peut convenir à certains champs (un statut, une date), mais pas à des notes, des descriptions ou des historiques.
3. **Le hors ligne exige une vraie stratégie de synchronisation.** Une application mobile pour techniciens ou commerciaux doit savoir fusionner, pas seulement écraser.
4. **L'automatisation et l'IA sont des collaborateurs comme les autres.** Un workflow qui met à jour un CRM ou un agent qui enrichit une fiche peut écraser une saisie humaine s'il n'est pas conçu pour gérer la concurrence.

## Comment comm.it vous accompagne

Chez comm.it, nous intervenons sur l'ensemble de la chaîne : le réseau qui transporte les données, les logiciels cœur de métier qui les stockent, et les automatisations ou agents d'IA qui les manipulent. Cette vision globale est précisément ce qu'exige la question des modifications concurrentes.

### Audit de vos outils collaboratifs et métier

Nous analysons la façon dont vos applications enregistrent les modifications : granularité des enregistrements, règles de résolution, comportement en cas de saisie simultanée ou de reconnexion après une coupure. L'objectif est d'identifier les endroits où des données peuvent disparaître silencieusement, avant que cela ne se produise sur un dossier client important.

### Développement de CRM et d'ERP conçus pour la concurrence

Lorsque nous développons ou faisons évoluer un **logiciel cœur de métier**, nous intégrons dès la conception la gestion des écritures simultanées. Selon les besoins, cela peut passer par :

- un enregistrement **au niveau du champ** plutôt que de la fiche entière ;
- un **verrouillage optimiste** qui détecte un conflit et propose à l'utilisateur de le résoudre ;
- un **historique des modifications** permettant de retrouver une version écrasée ;
- pour les contenus réellement collaboratifs (notes partagées, comptes rendus, descriptions longues), des mécanismes de **fusion** inspirés des principes décrits plus haut.

Toutes les données ne méritent pas la même complexité. Notre rôle est de choisir le bon niveau de sophistication pour chaque type d'information, sans surdimensionner vos outils.

### Applications mobiles et mode hors ligne

Pour les équipes terrain, nous concevons des applications capables de fonctionner sans connexion et de synchroniser proprement au retour du réseau. Les retours d'expérience comme celui de Notion confirment que c'est à ce moment précis que les pertes de données surviennent le plus facilement : nous en faisons un point de vigilance prioritaire.

### Automatisation et agents d'IA qui respectent le travail humain

Nos projets d'**automatisation des processus** et d'**intégration de l'IA** tiennent compte de la concurrence entre machines et humains. Un workflow qui met à jour une fiche doit modifier uniquement les champs qui le concernent, détecter qu'une saisie humaine est en cours ou récente, et tracer ses interventions. Un agent qui propose du contenu peut le faire sous forme de **suggestions** à valider plutôt que d'écritures directes.

### Un réseau fiable pour limiter les situations à risque

Enfin, une bonne partie des conflits naît de connexions instables : Wi-Fi qui décroche, liaison saturée, postes qui se resynchronisent en retard. En tant que spécialiste du **réseau** et du **Wi-Fi** pour les TPE et PME, nous travaillons aussi en amont, pour que vos équipes restent connectées le plus souvent possible et que les synchronisations se fassent dans de bonnes conditions.

## En résumé

L'expérience décrite par les équipes de Notion montre qu'un geste aussi banal que « taper à plusieurs » repose sur des choix techniques exigeants. Pour une PME, les enjeux sont les mêmes à une autre échelle :

- éviter que des modifications soient **écrasées sans prévenir** ;
- permettre le **travail hors ligne** sans risque ;
- faire cohabiter **humains, automatisations et IA** sur les mêmes données ;
- garder la **traçabilité** de qui a modifié quoi.

Ces sujets se traitent au moment de la conception ou de l'évolution de vos outils, bien plus facilement qu'après une perte de données.

> Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

---

*Source : [How Notion handles concurrent editing with CRDTs](https://www.notion.com/blog/how-notion-handles-concurrent-editing-with-crdts)*

---

- [Accueil](https://commit.insit.net/index.html.md)
- [Demander un devis gratuit](https://commit.insit.net/#devis)