Un commercial corrige l’adresse de livraison dans le CRM. Quelques secondes plus tard, l’ERP renvoie sa copie précédente et annule la correction. Le commercial recommence, un opérateur corrige à son tour, puis les deux systèmes publient chacun un nouvel événement. Le problème devient visible : tout paraît disponible des deux côtés, mais personne ne sait quelle valeur sera utilisée par la prochaine commande.
La synchronisation bidirectionnelle est souvent demandée comme une commodité : « les utilisateurs doivent pouvoir modifier partout ». Elle crée en réalité un système distribué où deux applications, deux délais et parfois deux équipes peuvent prendre une décision concurrente. Le transport n’est que la partie visible ; le coût réside dans la propriété, les conflits, les reprises et l’explication après incident.
Le vrai enjeu est de déterminer si les deux outils produisent légitimement une nouvelle vérité sur le même concept. Contre-intuitivement, afficher une donnée dans les deux applications ne justifie pas de l’écrire dans les deux sens. Une vue agrégée, une commande de modification ou un retour de statut suffit souvent et garde une chronologie lisible.
Dans une architecture de développement web sur mesure, chaque écriture doit avoir un motif, un propriétaire et une issue vérifiable. Ce guide aide à choisir le bon modèle, puis à construire une bidirectionnalité limitée lorsque le métier l’exige vraiment.
Vérifier si les deux sens sont réellement nécessaires
Partir des actes métier
L’équipe liste les actions, pas les objets : créer un prospect, qualifier un compte, bloquer un client, corriger une adresse, valider une condition de paiement, confirmer une livraison. Pour chacune, elle demande qui possède le contexte et l’autorité. Si le CRM propose une modification que la finance doit accepter dans l’ERP, le retour n’est pas une écriture symétrique : c’est un verdict d’acceptation ou de refus.
La bidirectionnalité devient justifiée lorsque deux acteurs ont des décisions légitimes, distinctes et impossibles à concentrer dans une seule interface. Par exemple, le commerce enrichit les contacts pendant que l’ERP maintient le statut financier ; les deux systèmes peuvent alors échanger des champs différents sans conflit. Elle est beaucoup plus risquée lorsque chacun modifie le même champ sans règle temporelle ou métier.
Calculer le coût d’une ambiguïté
Une matrice relie chaque écriture à son effet : information, engagement client, stock, facture ou droit d’accès. Plus l’effet est irréversible, plus la propriété doit être stricte. Une note commerciale en conflit peut attendre ; une limite de crédit ou un statut de blocage ne doit pas converger selon le dernier message arrivé.
Les signaux faibles apparaissent avant l’incident : utilisateurs qui rechargent l’écran pour vérifier, exports servant de référence, champs désactivés « temporairement » ou corrections effectuées deux fois. Leur coût se mesure en dossiers repris, délai de traitement et décisions retardées. Si l’équipe ne peut pas expliquer une correction concurrente, ajouter le second sens augmente la dette.
Attribuer la propriété au bon niveau
Écrire une matrice champ par champ
« Le CRM possède le client » n’est pas une règle exploitable. Le CRM peut posséder le contact et l’opportunité, l’ERP le compte de facturation, un référentiel groupe l’identité légale. La matrice indique système propriétaire, systèmes lecteurs, interface d’édition, validateur et événement qui rend la valeur opposable. Elle couvre aussi suppression, fusion et fermeture.
Un champ dérivé ne reçoit pas nécessairement un propriétaire d’écriture. Le segment client peut être calculé depuis plusieurs signaux et republié comme résultat. Autoriser chaque application à le modifier crée une compétition entre règle et saisie. L’équipe choisit alors soit le calcul comme vérité, soit une dérogation explicite avec durée, motif et owner.
Séparer proposition et application
Lorsqu’un acteur doit agir depuis le système non propriétaire, il envoie une proposition de changement. Celle-ci possède identifiant, valeur attendue, version lue et motif. Le propriétaire accepte, refuse ou demande une précision, puis renvoie son verdict. L’utilisateur voit l’état « en attente » plutôt qu’une correction optimiste ensuite écrasée.
Ce workflow paraît plus long qu’une copie immédiate, mais réduit les reprises sur les champs sensibles. Il permet aussi d’appliquer une autorisation différente entre proposer et valider. Pour les champs à faible risque, une acceptation automatique peut exister, à condition que la règle reste observable et que le résultat final soit renvoyé.
Échanger des événements explicites
Nommer le fait plutôt que la table
Un événement CustomerUpdated transporte trop peu de sens. BillingAddressChangeRequested, BillingAddressChanged et BillingAddressChangeRejected portent des intentions différentes. Le contrat précise identifiant métier, corrélation, origine, version d’objet, date de décision et champs concernés. Il ne déverse pas toute la fiche à chaque modification.
Les consommateurs doivent tolérer un événement répété et, selon l’infrastructure, un ordre non garanti entre partitions. Une date technique ne suffit pas pour trancher : l’événement conserve la version du domaine ou une séquence par agrégat. Les champs nouveaux sont optionnels tant que tous les consommateurs ne les comprennent pas, et toute rupture passe par une version ou une période de coexistence.
Relier commande, événement et réponse
La commande exprime ce qu’un système demande ; l’événement confirme ce qui s’est produit. Les confondre conduit un producteur à déclarer une réussite avant que le propriétaire ait validé. La corrélation relie les deux, et la causalité indique quel événement a déclenché le suivant. Cette chaîne permet de repérer un écho qui revient à son origine.
Le journal ne doit pas servir de base métier parallèle. Il conserve les métadonnées nécessaires au diagnostic, tandis que chaque système garde son état local. Une politique de rétention et de masquage protège les données sensibles. Le support retrouve la chronologie depuis un identifiant client sans consulter des payloads bruts hors de son périmètre.
Stabiliser identités et correspondances
Ne pas synchroniser sur un libellé
Chaque objet possède un identifiant stable dans son système et une table de correspondance vers les autres. Un email, un nom ou un numéro de commande affiché peut changer ou ne pas être unique. La table garde origine, identifiant cible, période de validité et statut de fusion. Elle permet à un ancien événement de retrouver son contexte après migration.
La création concurrente demande une règle précise. Si CRM et ERP peuvent créer un compte, une clé métier validée ou un service d’identité doit rapprocher avant publication. À défaut, chaque création reçoit un identifiant global et entre dans une file de résolution. Fusionner automatiquement sur une similarité transforme un retard de synchronisation en perte de relation.
Une suppression se représente souvent par un état fermé ou anonymisé, non par la disparition de la correspondance. Les événements tardifs peuvent ainsi être refusés proprement. La politique distingue aussi fusion et redirection : l’identifiant absorbé reste connu et pointe vers le survivant, avec une date qui permet d’expliquer les historiques.
Résoudre les conflits sans écraser
Détecter avant de décider
Une écriture inclut la version lue. Si l’objet a changé depuis, le propriétaire refuse la mise à jour ou demande une fusion guidée. Pour une API HTTP, les préconditions If-Match et les ETag suivent la sémantique définie dans le RFC 9110. Elles empêchent une écriture aveugle, sans déterminer à elles seules quelle valeur métier doit gagner.
La résolution dépend du champ : propriété stricte, maximum validé, union contrôlée, fusion manuelle ou compensation. « Dernière écriture gagnante » n’est acceptable que si les horloges, la faible criticité et le sens du champ le permettent. Sur une limite de crédit, une date d’arrivée n’a aucune légitimité métier.
Rendre le conflit visible à la bonne personne
Le conflit est un état durable avec valeurs, versions, origine, effet bloqué et owner. L’interface montre la différence et l’action autorisée, plutôt qu’un message « erreur de synchronisation ». Le support peut relancer une dépendance, mais seul le rôle métier arbitre une condition commerciale ou une identité ambiguë.
Un seuil local déclenche une revue lorsque les conflits vieillissent ou se concentrent sur une règle. Le seuil dépend de la capacité et de l’impact ; il doit commander une action, par exemple désactiver l’écriture d’un champ ou revenir au sens unique. Augmenter la file manuelle sans corriger la cause ne constitue pas une montée en charge.
Prévenir boucles, doublons et échos
Reconnaître son propre changement
Lorsqu’un système applique une valeur reçue, il ne doit pas la republier comme une nouvelle décision locale. Il conserve origine, identifiant de cause et empreinte de la transformation. Si une règle locale enrichit réellement la valeur, le nouvel événement indique cette causalité. Un simple drapeau « synchronisé » ne suffit pas lorsque plusieurs mises à jour se chevauchent.
Chaque consommateur enregistre la clé idempotente et son verdict. Après timeout, le producteur peut retenter sans créer un second effet. Une boîte de sortie transactionnelle relie la mise à jour locale à la publication : l’état et le message sont persistés dans la même transaction logique, puis un worker publie. Cela limite la fenêtre où la donnée change sans événement.
Borner retries et compensations
Les erreurs transitoires rejoignent une file de retry avec temporisation ; les rejets métier sortent de la boucle et attendent une décision. Le monitoring distingue tentative, traitement unique et effet confirmé. Sinon, un pic de retries ressemble à une activité saine et masque une dépendance en panne.
Une compensation annule l’effet métier selon une règle explicite, elle ne supprime pas l’historique. Si une commande a déjà produit un document, revenir à l’ancienne valeur peut exiger un avoir ou une nouvelle version. Le runbook précise le point de non-retour et le rôle capable d’autoriser la compensation.
Choisir une alternative plus lisible
Préférer lecture distante, commande ou réplication ciblée
Une interface peut afficher en temps réel la donnée du propriétaire sans la recopier, si disponibilité et latence le permettent. Elle peut aussi conserver un cache en lecture avec fraîcheur visible. Pour modifier, une commande adressée au propriétaire garde la décision centrale. Ces modèles offrent l’expérience attendue sans créer deux sources concurrentes.
Une réplication unidirectionnelle avec retour de statut couvre beaucoup de besoins. Le CRM envoie le contact, l’ERP renvoie l’identifiant comptable et le statut de création. Ce sont deux flux, mais pas une édition symétrique du même champ. La distinction réduit drastiquement le nombre de conflits à traiter.
Le batch reste pertinent pour des données volumineuses peu urgentes, à condition d’exposer sa fraîcheur. L’événementiel convient aux décisions qui doivent se propager vite. Mélanger les deux sans chronologie produit des écrasements ; l’équipe définit alors une fenêtre de gel ou une règle de priorité entre snapshot et deltas.
Cas concret : une adresse corrigée deux fois
Une convergence qui semble réussie
Cas concret hypothétique : à 10 h 00, un commercial corrige l’adresse dans le CRM depuis la version 41. À 10 h 01, la finance corrige la raison sociale dans l’ERP depuis une copie plus ancienne qui contient encore l’adresse précédente. Si chaque système repousse l’objet complet, l’ERP écrase l’adresse, puis le CRM republie la sienne. Les deux outils alternent sans conflit visible.
Le contrat par champ résout le cas. Le CRM envoie seulement l’adresse avec version et motif ; l’ERP applique la raison sociale localement. Si l’adresse est sous propriété ERP, le CRM crée plutôt une demande. La recette retarde volontairement les messages, répète un événement et perd une réponse. Elle réussit lorsque l’état final, les deux décisions et l’absence de double effet sont retrouvables par une personne extérieure au développement.
Pour qui la bidirectionnalité est-elle justifiée ?
Elle concerne les organisations où deux métiers doivent réellement contribuer au même dossier depuis des interfaces spécialisées : commerce et finance, terrain et siège, portail partenaire et back-office. Produit, propriétaires des données, intégration, sécurité, exploitation et support doivent participer. L’architecte ne peut pas décider seul quelle valeur est opposable.
Pour une petite équipe, une interface unique ou une commande vers le propriétaire est souvent préférable. Pour un écosystème ancien impossible à centraliser immédiatement, une bidirectionnalité limitée peut servir de transition, avec date de sortie et champs bornés. Le volume ne la justifie pas ; l’autorité métier distribuée, oui.
Erreurs fréquentes de synchronisation
La première erreur synchronise des objets entiers lorsque trois champs suffisent. La deuxième choisit le dernier horodatage sans horloge ni règle métier. La troisième confond retry et nouvelle commande. La quatrième perd les identifiants après fusion. La cinquième applique une mise à jour reçue puis la republie comme une décision locale.
Autres pièges : masquer un conflit par une valeur par défaut, autoriser le support à trancher sans rôle, ouvrir les deux sens avant d’instrumenter le premier et tester uniquement dans l’ordre nominal. Enfin, un tableau qui montre deux valeurs égales ne prouve pas la synchronisation : il faut retrouver versions, causalité et effet.
Mettre en œuvre un flux reprenable
Contractualiser entrée, sortie et dépendances
L’entrée est une commande ou un événement versionné ; la sortie est un verdict corrélé et un état local. Chaque dépendance possède timeout, retry borné et circuit de repli. La journalisation conserve origine, causalité, version lue et idempotence. Le monitoring mesure latence utile, événements en attente, conflits et effets confirmés, pas seulement appels HTTP réussis.
Un worker ne dispose que des droits nécessaires au champ concerné. Il valide le contrat, contrôle la version, applique la décision puis persiste le verdict. En cas de rejet, il ne réessaie pas indéfiniment. Le runbook nomme l’owner, le seuil de pause et le moyen de reprendre depuis la dernière sortie opposable.
Simuler concurrence et désordre
La recette envoie deux modifications depuis la même version, inverse l’ordre, répète le premier message et interrompt le consommateur après l’effet. Elle vérifie qu’une seule décision gagne selon la règle, que l’autre devient un conflit explicable et que le retry retrouve le verdict sans second effet. Une panne de mapping doit isoler le champ concerné sans bloquer tous les objets indépendants.
Le repli désactive un sens ou un champ au moyen d’une configuration versionnée. Les messages en attente restent conservés et qualifiés ; ils ne sont rejoués qu’après analyse de leur ancienneté. Si leur contexte n’est plus valide, une compensation ou une résolution manuelle remplace le replay aveugle.
Décider avec des signaux métier
Le pilotage rapproche taux de conflits, âge de la file, corrections répétées et parcours bloqués. Une hausse de latence sans impact peut attendre ; quelques conflits sur une condition de paiement peuvent suspendre le second sens. Le seuil est qualifié avec le métier et lié à une action : réduire le périmètre, repasser en proposition ou corriger une règle.
Le coût caché apparaît dans les gestes de vérification. Si les utilisateurs consultent deux écrans avant chaque décision, la convergence technique n’a pas créé de confiance. Le support doit pouvoir retrouver un dossier par identifiant métier, voir la chronologie et indiquer la prochaine action sans privilège excessif. Cette autonomie est un critère d’extension.
Plan d’action en six étapes
Étapes 1 et 2 : actes et propriété
L’équipe inventorie les actions que chaque population doit accomplir, puis attribue la propriété champ par champ. Elle supprime les écritures symétriques sans justification et distingue proposition, décision et information. Le premier livrable contient identités, versions et effets irréversibles. Il est validé par les métiers qui portent réellement ces décisions.
Étapes 3 et 4 : contrats et conflits
Les événements sont nommés par intention, corrélés et idempotents. Un prototype traite une seule famille de changements avec conflit visible. La recette provoque ordre inversé, réponse perdue et correction concurrente. L’équipe vérifie aussi le retour utilisateur : attente, acceptation et refus doivent être compréhensibles depuis chaque interface.
Étapes 5 et 6 : exploitation et extension
Le monitoring relie messages et dossiers métier. Support et exploitation jouent la reprise avec leurs droits réels. Le comité observe un cycle, mesure conflits et gestes parallèles, puis décide de conserver, limiter ou étendre. Une extension porte sur des champs nommés, jamais sur « l’objet client » entier.
Le rapport garde hypothèses, alternatives refusées, seuils et date de revue. D’abord, fermer le sens métier ; ensuite, construire un premier flux reprenable ; puis prouver la concurrence avant d’ouvrir le retour. Si la propriété reste discutée, la décision correcte est de différer la bidirectionnalité et d’offrir une proposition contrôlée.
- D’abord, nommer l’acte et le système qui rend sa sortie opposable.
- Ensuite, limiter le contrat aux champs nécessaires et versionnés.
- Puis, tester conflits, doublons, ordre et reprise avec le support.
- Enfin, décider l’extension selon l’impact métier, pas le débit de messages.
Guides complémentaires pour sécuriser les flux
Préparer les fondations
La préparation des données ERP stabilise identité et mapping, tandis que le guide de l’idempotence détaille les reprises sans double effet.
Vérifier le run
Les tests de workflows complexes structurent les scénarios dégradés, et l’observabilité métier relie la chronologie technique aux décisions.
- Relire la propriété avant d’ajouter un nouveau sens.
- Contrôler version et causalité avant toute écriture.
- Conserver un repli vers proposition ou sens unique.
Conclusion : garder un sens à chaque écriture
Une synchronisation bidirectionnelle réussie ne rend pas deux bases identiques : elle permet à deux métiers de contribuer sans perdre l’autorité ni la chronologie. Propriété par champ, versions, conflits et idempotence transforment une copie fragile en décisions explicables.
La priorité consiste à supprimer la symétrie inutile. Une lecture distante, une proposition ou un sens unique avec retour de statut offre souvent la même valeur avec moins de dette. Lorsque les deux sens restent nécessaires, ils doivent être limités et éprouvés sous concurrence réelle.
Dawap peut cadrer ces responsabilités et construire les flux dans une stratégie de développement web sur mesure. L’objectif n’est pas de faire circuler davantage de messages, mais de permettre à chaque utilisateur et à chaque opérateur de savoir pourquoi une valeur a changé, qui peut la corriger et comment reprendre sans l’écraser.
