English
FrançaisDécider qui possède quoi
« Bidirectionnel » ne veut pas dire que chaque champ circule dans les deux sens. Pour une clinique dentaire : le logiciel de gestion possède les rendez-vous, l'historique des soins et les notes cliniques ; GoHighLevel possède le consentement marketing, la source du lead, les tags et l'historique des conversations ; les coordonnées appartiennent au système que le patient a mis à jour en dernier, l'autre étant notifié. Nous écrivons ce tableau de propriété avant de toucher à une API, et il règle 90 pour cent de la conception.
Synchroniser sur événement, traiter le reste par lots
Là où l'un ou l'autre système propose des webhooks, les changements se synchronisent en quelques secondes : une réservation dans le logiciel du cabinet apparaît dans GoHighLevel et déclenche les rappels ; un nouveau lead dans GoHighLevel apparaît dans le logiciel du cabinet comme patient potentiel. Là où il n'y a pas de webhooks, une tâche planifiée vérifie toutes les quelques minutes les changements depuis la dernière exécution. Les opérations en masse (chargement initial, corrections) tournent par lots la nuit avec limitation de débit, selon les schémas de l'article code sur mesure autour de votre CRM.
Règles de conflit
Deux systèmes seront parfois en désaccord. « Le dernier qui écrit gagne » paraît simple et détruit discrètement des données quand les horloges diffèrent ou qu'un traitement par lots s'exécute en retard. Notre règle par défaut : le système propriétaire l'emporte pour ses champs, toujours. Pour les champs partagés comme le numéro de téléphone, la modification humaine la plus récente l'emporte sur toute écriture automatique, et le perdant est consigné dans une note pour que rien ne disparaisse en silence.
Les familles partagent des e-mails. Les entreprises partagent des téléphones. Faire correspondre les contacts par e-mail ou téléphone crée des fiches fusionnées très difficiles à séparer ensuite. Stockez l'identifiant de l'autre système sur chaque fiche et faites la correspondance dessus. Repliez-vous sur e-mail plus nom seulement pour le chargement initial, avec une liste de relecture pour tout cas ambigu.
Identifiants stables
Chaque contact GoHighLevel porte un champ personnalisé contenant l'identifiant de la fiche du système métier, et inversement. Toutes les synchronisations suivantes se font sur ces identifiants. C'est la seule décision qui évite les doublons, et elle doit être prise avant que la première fiche ne bouge.
Le rapport nocturne
Chaque nuit, une tâche compte les fiches des deux côtés, en échantillonne cinquante et les compare champ par champ, puis envoie un court rapport : décomptes, écarts et fiches non synchronisées avec la raison. La dérive est détectée le lendemain matin plutôt que trois mois plus tard. Le rapport reprend l'idée de l'étape de rapprochement de notre méthode de migration, exécutée en continu.
Commencer dans un seul sens
Nous lançons presque toujours d'abord dans un seul sens : du système métier vers GoHighLevel, pour que le marketing dispose de données propres. Ce n'est qu'après quelques semaines de fonctionnement propre que nous activons le sens inverse, champ par champ. Le bidirectionnel dès le premier jour, c'est là que la plupart des projets de synchronisation se font leur réputation.
L'essentiel à retenir
- Chaque champ a exactement un système propriétaire. L'autre côté est en lecture seule pour ce champ.
- Synchronisez les changements au fil de l'eau là où l'API le permet ; traitez le reste par lots planifiés.
- Écrivez la règle de conflit avant d'écrire du code : « le dernier qui écrit gagne » est rarement la bonne.
- Stockez l'identifiant de chaque système de l'autre côté, et ne faites jamais correspondre sur le nom ou l'e-mail seuls.
- Un rapport de rapprochement nocturne repère la dérive avant un client.