Un conflit de synchronisation entre deux logiciels survient quand la même fiche est modifiée des deux côtés avant le passage suivant, ou quand une opération censée créer plusieurs éléments liés (une commande et ses lignes, un client et son adresse de facturation) s'interrompt à mi-chemin. Ce n'est pas un cas rare ou théorique : c'est ce qui se produit tôt ou tard dans toute synchronisation qui tourne assez longtemps, dès qu'un réseau coupe, qu'une API répond mal, ou que deux personnes travaillent sur le même dossier en même temps.
La différence entre une synchronisation fiable et une synchronisation qui finit par corrompre des données ne tient pas à la technologie utilisée. Elle tient à ce qui a été décidé avant le premier déploiement : qui gagne en cas de conflit, comment une opération à moitié faite est rattrapée, qui regarde la file des cas qui bloquent, et comment on prouve d'où vient une valeur le jour où quelqu'un le demande.
Cet article détaille ces mécanismes un par un : le conflit d'écriture et ses stratégies de résolution, les doublons que la synchronisation crée elle-même, l'idempotence qui permet de rejouer sans dupliquer, les erreurs partielles et comment les rendre atomiques, la reprise sur erreur, la détection d'une panne silencieuse, et la traçabilité qui rend le système auditable.
Points clés à retenir
- Un conflit d'écriture se règle avec une règle explicite décidée à l'avance : dernier qui écrit gagne, source qui fait toujours foi, résolution champ par champ, ou file d'arbitrage humain selon la sensibilité du champ
- Les doublons créés par la synchro elle-même viennent presque toujours de la même cause : l'absence d'une clé stable qui identifie un enregistrement de façon certaine d'un passage à l'autre
- L'idempotence est la propriété qui permet de rejouer une opération sans risque : rejouer deux fois le même message ne doit produire qu'un seul effet sur les données
- Une erreur partielle (commande créée sans ses lignes, client sans son adresse) est le pire cas : l'opération doit être rendue atomique ou compensée par une étape d'annulation explicite
- La détection d'une synchronisation tombée en silence est plus critique que la gestion des erreurs bruyantes, parce que personne ne sait qu'il faut intervenir
- La traçabilité (qui a écrit quoi, quand, à partir de quelle source) est la condition pour qu'un comptable ou un auditeur fasse confiance au système
- L'IA aide à détecter les anomalies de volume et à trier la file de mise à l'écart ; le débogage d'un conflit ou d'une erreur partielle reste un travail humain
Le conflit d'écriture : quand la même fiche change des deux côtés
Un conflit d'écriture apparaît dès qu'une même fiche est modifiée dans les deux logiciels entre deux passages de synchronisation. Un commercial change l'adresse de livraison dans le CRM au moment où la comptable corrige la même adresse dans le logiciel de facturation à partir d'un nouveau RIB reçu par email. Les deux modifications sont légitimes. La synchronisation doit pourtant trancher laquelle des deux versions garder, et c'est cette décision qui doit être prise avant que le conflit n'arrive, pas pendant.
La fréquence de synchronisation influence directement la probabilité de ce scénario : plus la fenêtre entre deux passages est large, plus deux personnes ont le temps d'intervenir sur la même fiche avant que l'une des deux versions ne remonte. Notre article sur synchronisation temps réel ou batch : comment trancher détaille ce choix de fréquence, qui reste distinct de la question du conflit lui-même : même en temps réel, deux écritures peuvent arriver à quelques millisecondes d'écart.
Quatre stratégies existent, chacune avec des conséquences réelles sur les données :
- Le dernier qui écrit gagne. La modification la plus récente écrase l'autre. Simple à mettre en place, mais silencieuse : la personne dont la saisie a été écrasée n'en sait rien, et découvre la perte des semaines plus tard.
- Une source fait toujours foi. Pour un champ donné, un des deux logiciels a toujours le dernier mot, quelle que soit la date de modification. C'est le prolongement naturel du choix de propriétaire de la donnée : si le logiciel de facturation est propriétaire de l'adresse de facturation, ses écritures priment toujours sur celles du CRM pour ce champ précis.
- La résolution champ par champ. Plutôt que de trancher au niveau de la fiche entière, chaque champ suit sa propre règle. L'adresse de facturation obéit à la source qui fait foi, la note commerciale interne obéit au dernier qui écrit gagne. Plus fin, donc plus fiable, mais plus long à concevoir et à documenter.
- La mise en file pour arbitrage humain. Pour les champs les plus sensibles, aucune règle automatique n'est appliquée : le conflit est présenté à une personne qui choisit. Le plus sûr, le plus lent, réservé aux cas où une erreur automatique aurait un vrai coût.
| Stratégie | Adaptée à | Conséquence si mal choisie |
|---|---|---|
| Dernier qui écrit gagne | Champs à faible enjeu : note interne, tag, statut d'affichage | Perte silencieuse d'une modification légitime sur un champ sensible |
| Une source fait toujours foi | Champs déjà rattachés à un propriétaire clair (facturation, stock) | Frustration si l'autre outil a un besoin légitime de corriger la donnée |
| Résolution champ par champ | Fiches à fort volume de champs partagés, plusieurs propriétaires | Complexité de conception et de maintenance si la carte des champs change |
| Mise en file, arbitrage humain | Champs à fort enjeu financier ou contractuel | File qui s'accumule si personne n'est désigné pour la vider régulièrement |
À retenir
Le dernier qui écrit gagne est la stratégie la plus demandée parce qu'elle est la plus simple à coder. C'est aussi la plus dangereuse sur un champ sensible, parce qu'elle efface une modification légitime sans que personne ne le remarque avant longtemps.
Les doublons que la synchronisation crée elle-même
Le scénario est classique et revient dans presque tous les projets de connexion entre deux logiciels : un enregistrement existe déjà dans le second système, mais la synchronisation ne le reconnaît pas comme tel. Elle en recrée un nouveau, à côté du premier, à chaque passage.
La cause est presque toujours la même : l'absence d'une clé stable qui identifie un enregistrement de façon certaine d'un logiciel à l'autre. Sans cette clé, le système tente une correspondance approximative (nom, email) qui échoue dès qu'un caractère change, qu'une abréviation diffère, ou qu'un email est mis à jour d'un côté sans l'être de l'autre. Chaque échec de correspondance se traduit par une création, et le doublon s'installe silencieusement.
La correction ne se fait pas après coup, en fusionnant des doublons a posteriori. Elle se fait à la conception : chaque enregistrement reçoit, dès sa création, un identifiant externe stable, transmis explicitement à chaque passage de synchronisation et jamais recalculé par correspondance approximative. Cet identifiant devient la seule clé de rapprochement fiable, indépendante de tout champ métier susceptible de changer.
Notre article sur comment synchroniser deux logiciels sans identifiant commun détaille comment construire cette clé quand aucun des deux systèmes n'en fournit une nativement.
L'idempotence : la propriété qui sauve tout le reste
L'idempotence est la propriété la plus importante d'une synchronisation, et la moins souvent expliquée simplement. Elle tient en une phrase : rejouer deux fois la même opération ne doit produire qu'un seul effet sur les données, jamais deux.
Pourquoi rejoue-t-on une opération ? Parce qu'une synchronisation ne réussit pas toujours du premier coup. Une coupure réseau interrompt l'envoi juste après que le second logiciel a bien enregistré la donnée, mais avant que la confirmation ne revienne. Le système qui a envoyé la donnée ne sait pas si elle est arrivée : il la renvoie, par prudence. Sans idempotence, cette prudence légitime crée un doublon exactement dans le scénario décrit plus haut.
Concrètement, l'idempotence repose sur un identifiant unique attaché à chaque opération, pas seulement à chaque enregistrement. Avant d'appliquer une écriture, le système receveur vérifie si cet identifiant d'opération a déjà été traité. S'il l'a déjà été, l'écriture est simplement ignorée une seconde fois, sans erreur et sans doublon. C'est ce mécanisme qui permet de relancer une synchronisation en échec sans craindre d'aggraver la situation, ce qui rend possible tout ce qui suit dans cet article : la reprise automatique, les tentatives multiples, le rejeu après correction d'un bug.
Les erreurs partielles : le pire cas à gérer
Le cas le plus dommageable n'est pas l'échec complet d'une synchronisation, facile à repérer, mais l'échec partiel : une commande créée dans le système cible, mais sans ses lignes de détail. Un client créé, mais sans son adresse de facturation. La fiche existe, elle a l'air normale au premier coup d'œil, mais elle est incomplète, et personne ne le sait tant que quelqu'un n'ouvre pas le dossier en détail.
Ce problème vient du fait que deux systèmes séparés ne partagent pas la même transaction. Dans une seule base de données, une opération en plusieurs étapes peut être rendue atomique : soit toutes les écritures réussissent, soit aucune n'est appliquée. Entre deux logiciels reliés par API, cette garantie n'existe pas nativement. Chaque appel réussit ou échoue indépendamment des autres.
Deux approches permettent de s'en rapprocher :
- L'écriture en état intermédiaire. La commande est d'abord créée dans un état "en cours de création", invisible aux autres processus, et n'est marquée "confirmée" qu'une fois toutes ses lignes écrites avec succès. Un contrôle périodique repère les commandes restées trop longtemps à l'état intermédiaire, signe d'un échec partiel à traiter.
- La compensation. Quand l'état intermédiaire n'est pas possible techniquement, chaque étape prévoit son annulation. Si les lignes de commande échouent après la création de l'en-tête, une étape de compensation supprime ou désactive automatiquement cet en-tête orphelin, plutôt que de le laisser traîner.
Dans les deux cas, le principe reste le même : une opération qui touche plusieurs objets liés ne doit jamais être considérée comme terminée tant que son dernier élément n'est pas confirmé.
La reprise sur erreur, la détection et la traçabilité
Une fois les conflits, les doublons et les erreurs partielles pris en compte à la conception, il reste à organiser ce qui se passe au quotidien : que faire quand une écriture échoue, comment s'apercevoir qu'un flux entier s'est arrêté, et comment prouver après coup d'où vient une donnée.
File d'attente, tentatives et délai croissant
Une écriture qui échoue une première fois n'est presque jamais définitivement perdue : une API momentanément indisponible, un pic de charge, une coupure réseau de quelques secondes expliquent la majorité des échecs. La bonne pratique consiste à remettre l'opération dans une file d'attente et à retenter, avec un délai qui s'allonge entre chaque essai plutôt qu'un rythme fixe, pour ne pas aggraver un service déjà en difficulté.
Au delà d'un nombre de tentatives défini à l'avance, l'opération sort de la file de reprise automatique et rejoint une file de mise à l'écart, réservée aux cas qui ne passeront probablement pas seuls. Cette file n'a de valeur que si quelqu'un est désigné pour la regarder, à une fréquence fixée à l'avance, pas seulement quand quelqu'un s'en souvient.
Pourquoi le silence est plus dangereux que le bruit
Une synchronisation qui échoue bruyamment, avec une erreur explicite et une alerte, est en réalité la situation la moins risquée : quelqu'un est prévenu, et peut agir. Le vrai danger vient de la synchronisation qui s'arrête sans produire aucune erreur, par exemple parce qu'un déclencheur ne se déclenche plus, ou qu'une tâche planifiée a été désactivée par erreur lors d'une mise à jour.
La détection de ce cas passe par des contrôles de cohérence indépendants du flux lui-même : un comptage croisé des enregistrements des deux côtés à intervalle régulier, une alerte déclenchée par l'absence d'activité plutôt que par la présence d'une erreur. Ces contrôles demandent un peu de travail de conception, mais ils sont ce qui distingue une synchronisation surveillée d'une synchronisation qui s'arrête un jour sans que personne ne s'en aperçoive avant plusieurs semaines.
La traçabilité, condition de confiance
Un comptable, un client qui conteste une facture, ou un auditeur posent tous la même question un jour ou l'autre : d'où vient cette valeur, et qui l'a écrite. Une synchronisation qui ne conserve aucune trace de l'origine de chaque écriture (quel système, à quelle date, quelle était la valeur précédente) ne peut pas répondre à cette question, et perd la confiance nécessaire pour être utilisée sur des données sensibles.
Le journal de synchronisation doit donc consigner, pour chaque écriture, sa source, son horodatage, l'identifiant d'opération qui a permis de garantir son idempotence, et l'ancienne valeur remplacée. Ce journal n'est pas un détail technique secondaire : c'est ce qui rend le système auditable, et donc utilisable pour des données qui touchent à la facturation ou à la conformité.
Ce que l'IA apporte ici, sans surpromettre
Sur ce sujet précis, l'IA n'a pas vocation à remplacer la conception décrite plus haut. Elle intervient en périphérie, sur deux tâches bien identifiées.
La détection d'anomalies sur les volumes et les écarts. Un modèle entraîné sur l'historique des volumes synchronisés repère plus vite qu'un contrôle de seuil fixe qu'un flux habituellement stable a chuté de façon anormale, même si le chiffre reste techniquement dans une fourchette acceptable. Utile en complément des comptages croisés, pas à leur place.
L'aide au tri de la file de mise à l'écart. Quand cette file contient plusieurs dizaines de cas, une IA peut regrouper les échecs par cause probable (même type d'erreur, même champ concerné) et proposer une explication en langage clair pour chacun, ce qui accélère le travail de la personne qui doit ensuite trancher.
Ce que l'IA n'apporte pas, et il faut le dire franchement : le débogage d'un conflit d'écriture ou d'une erreur partielle reste un travail humain. Décider quelle version d'une adresse de facturation est correcte, ou pourquoi une commande précise s'est arrêtée à mi-chemin, engage une responsabilité que personne ne délègue à un modèle. C'est ce type de projet que nous cadrons dans le cadre d'un connecteur sur mesure entre logiciels : concevoir les règles de conflit, la clé de rapprochement et la reprise sur erreur avant d'écrire la première ligne de connecteur, pas après le premier incident.
Pour resituer ce sujet dans une vision plus large de ce qui dégrade une automatisation dans la durée, notre article sur ce qui casse dans une automatisation au bout de deux ans couvre les causes qui touchent une automatisation entière, pas seulement une synchronisation entre deux logiciels. Sur la gestion des erreurs et la reprise en général, hors du cas spécifique de la synchronisation à deux systèmes, notre article que se passe-t-il quand une automatisation se trompe détaille les familles d'erreurs et les garde-fous à poser. Et sur le niveau de contrôle humain à prévoir sur les cas ambigus, notre article où placer la validation humaine dans une automatisation complète cette question de l'arbitrage.
Questions fréquentes sur les conflits et erreurs de synchronisation entre logiciels
Pour aller plus loin
- Synchroniser deux logiciels sans identifiant commun : comment construire une clé de rapprochement fiable quand aucun des deux systèmes n'en fournit une nativement.
- Synchronisation temps réel ou batch : comment trancher : le choix de fréquence qui influence directement la fenêtre d'exposition aux conflits d'écriture.
- Supprimer la double saisie entre deux logiciels métier : choisir la source de vérité et le bon schéma de synchronisation avant la technique.
- Ce qui casse dans une automatisation au bout de deux ans : les causes de dégradation d'une automatisation dans la durée, au delà d'une seule synchronisation.
- Que se passe-t-il quand une automatisation se trompe : les familles d'erreurs et les garde-fous à poser sur une automatisation en général.
- Où placer la validation humaine dans une automatisation : arbitrer entre contrôle systématique et échantillonnage.
- Correspondance des champs entre deux logiciels : une part des conflits vient d'un mapping mal posé en amont, pas seulement de la synchronisation elle-même.
