La synchronisation bidirectionnelle exige des règles d’écriture
Si CRM et ERP peuvent écrire, chaque champ partagé exige une règle de conflit. Le dernier message reçu n’est pas forcément la dernière décision métier.
Une connexion peut transférer des données dans les deux sens. Cela ne signifie pas que chaque champ devrait être écrasé librement des deux côtés. Les champs partagés exigent une règle reliant droit de modification, version de départ et traitement des conflits. Sinon, un message techniquement nouveau peut réintroduire une valeur métier ancienne.
Un message tardif peut reposer sur des données anciennes
Un éditeur de logiciels fictif synchronise CRM et ERP. L’ERP confirme l’adresse de facturation, le CRM gère le contact projet. Cette séquence inventée montre l’effet possible d’une mise à jour globale :
Heure | Opération | Version des données |
|---|---|---|
| Le CRM lit la fiche client. |
|
| L’équipe ERP confirme une nouvelle adresse de facturation. |
|
| Le CRM renvoie un contact projet modifié avec l’ancienne adresse. | Le message contient encore |
Le message arrive plus tard, mais son adresse vient d’un état antérieur. Si l’intégration accepte toute la fiche sans contrôle, la modification confirmée peut disparaître. Ici, v7 et v8 désignent la même fiche ERP ; des compteurs locaux indépendants de systèmes différents ne sont pas directement comparables.
Reconnaître la version de départ et décider du conflit
Microsoft décrit un contrôle de concurrence optimiste pour Dataverse : une application peut détecter si la fiche serveur a changé entre lecture et écriture. Le contrôle disponible et son activation dépendent du produit et de son interface.
Détecter un écart ne décide pas encore quelle adresse est correcte pour le métier. Dans cet exemple, l’ancienne adresse doit attendre une clarification ou être traitée comme une réécriture non autorisée. Renvoyer simplement l’ancienne valeur rejetée avec un nouvel identifiant contournerait le contrôle de version sans résoudre l’écart métier. Un contrôle de version isolé ne rend pas non plus atomiques toutes les étapes entre plusieurs systèmes.
Quand les deux côtés peuvent écrire
Si les deux équipes doivent réellement modifier les mêmes informations, une solution bidirectionnelle peut convenir. Champs permis, modifications et décisions de conflit doivent alors être explicites. La documentation dual-write de Microsoft montre par exemple des sens différents selon la correspondance de colonnes ; un réglage global n’est pas une nécessité métier.
Transférer différents champs dans différents sens peut aussi suffire. Dans l’exemple, le nouveau contact projet doit être accepté selon sa règle, sans réécrire l’ancienne adresse de facturation sans contrôle. Les deux valeurs concernent le même client mais exigent des décisions d’écriture différentes.
Sources
À lire aussi
Tous les articles
Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés