Sync bidirectionnelle
Définition
Synchronisation dans les deux sens entre deux outils : un changement dans le CRM met à jour la base, et inversement. Plus complexe qu'une sync simple, à cadrer pour éviter les conflits.
Comment ça marche
Une synchronisation bidirectionnelle (two-way sync) maintient les mêmes données à jour entre deux systèmes, dans les deux sens. Si un commercial modifie une fiche client dans HubSpot, la modification se propage automatiquement vers le SaaS interne ; si le SaaS interne change cette fiche, HubSpot est mis à jour à son tour. Techniquement, chaque système notifie l'autre via webhook ou polling à chaque modification, et un mécanisme de déduplication empêche les boucles infinies (HubSpot notifie le SaaS qui notifie HubSpot...). Les données partagent généralement un identifiant commun (id externe) qui sert de référence pour le matching.
À quoi ça sert
La sync bidirectionnelle sert quand deux outils sont utilisés par des équipes différentes mais doivent voir les mêmes données à jour. CRM côté commercial + outil de support côté SAV : un statut client changé d'un côté doit apparaître de l'autre. ERP côté finance + e-commerce côté marketing : un stock modifié manuellement doit refléter sur le site, et inversement. Outil de projet côté équipe + facturation côté admin : une heure loggée dans le tracker doit alimenter la facturation. Pour les équipes pluridisciplinaires utilisant des outils différents, c'est ce qui évite les ressaisies et les désynchronisations.
Les défis techniques
Trois défis principaux. Les boucles infinies : A met à jour B, B notifie A, A notifie B, et ainsi de suite. On les casse avec des champs métadonnées (timestamp de dernière modification, source de la modification) ou des verrous courts. Les conflits : si A et B modifient la même donnée au même moment, lequel gagne ? Stratégie last-write-wins, ou merge intelligent par champ, ou résolution manuelle pour les conflits critiques. Les suppressions : supprimer dans A doit-il supprimer dans B, ou garder en archive ? Cette décision dépend du métier, et doit être documentée explicitement.
Quand l'utiliser
On choisit la sync bidirectionnelle quand : deux équipes différentes modifient les mêmes données dans leurs outils respectifs et doivent voir les changements de l'autre, le métier ne tolère pas une source de vérité unique (chaque outil a sa raison d'être), les modifications sont fréquentes des deux côtés. C'est un investissement réel : compter 2-3 semaines pour une vraie sync bidirectionnelle robuste sur des données métier complexes, plus la maintenance régulière.
Quand ne pas l'utiliser
On évite la sync bidirectionnelle pour 80% des besoins. Dans la plupart des cas, une source de vérité unique suffit : choisir le système maître (par exemple le CRM), répliquer en lecture seule vers les autres systèmes via sync unidirectionnelle. C'est 10 fois plus simple à implémenter et maintenir, et ça évite tous les problèmes de conflits. La sync bidirectionnelle se justifie seulement quand le besoin métier l'exige clairement. Si on hésite, c'est probablement pas nécessaire : on commence en sync unidirectionnelle, on ajoute la deuxième direction si le manque devient bloquant.
Les outils
Les ETL classiques (Hightouch, Census, Polytomic) excellent dans la sync unidirectionnelle data warehouse → outils. Pour la sync bidirectionnelle entre outils métier, les options sont plus limitées : Whalesync est spécialisé là-dessus, Make et Zapier peuvent le faire en deux scénarios opposés mais demandent une attention particulière sur la déduplication. Pour les cas critiques, on code souvent une sync custom en interne : une fonction serverless qui écoute les webhooks des deux côtés et synchronise via API, avec une table de mapping et des logs détaillés.
Les pièges à éviter
Le piège classique de la boucle infinie : on déploie sans testing, ça boucle, ça génère des millions d'événements en quelques heures et fait planter les deux systèmes. On teste rigoureusement en sandbox avant. Le piège du conflit silencieux : deux modifications simultanées, last-write-wins choisit la mauvaise, le commercial pense que sa modif a été acceptée mais l'autre est appliquée. On loge les conflits explicitement et on alerte. Le piège du schéma divergent : HubSpot a un champ "Status" avec 5 valeurs, le SaaS interne a 7 valeurs. Le mapping doit être documenté et maintenu, sinon on perd des données silencieusement. Et toujours prévoir un mode "désactivé" pour pouvoir arrêter la sync en urgence si elle pose problème.