Connecter son CRM à son produit : la décision à prendre avant l'intégration

Le branchement marche en démonstration. Trois mois plus tard, un commercial modifie une fiche dans le CRM, quelqu'un modifie la même dans le produit, et personne ne sait laquelle des deux fait foi. C'est là que ça casse, pas dans le code.

Connecter un CRM à son produit n'est presque jamais un problème technique. C'est une question de gouvernance de la donnée, déguisée en projet d'intégration. Tant qu'on ne l'a pas tranchée, chaque outil de synchronisation ne fait que déplacer la confusion plus vite.

Cet article donne la méthode que nous appliquons avant chaque intégration. Elle tient en trois décisions, et elle évite la plupart des reprises coûteuses six mois plus tard.

Elles fonctionnent toutes le premier jour. Elles ne vieillissent pas du tout pareil, et c'est le seul critère qui compte vraiment.

Avant l'outil, avant le budget, répondez à ceci : pour chaque information partagée, quel système a raison quand les deux ne sont pas d'accord ?

La réponse n'est pas globale, elle est champ par champ. En général, le produit fait foi sur ce qu'il observe et le CRM fait foi sur ce qu'un humain a saisi. Un statut d'abonnement vient du produit. Un nom de contact commercial vient du CRM. Mélanger les deux logiques produit des écrasements silencieux.

Remarquez qu'aucune ligne n'est bidirectionnelle. Ce n'est pas un hasard : une fois la source de vérité posée, le besoin de synchroniser dans les deux sens disparaît presque toujours. Et c'est une bonne nouvelle, parce que le bidirectionnel est ce qui coûte le plus cher.

Dans un sens, vous propagez un changement. Dans les deux, vous devez arbitrer des conflits, et un conflit n'a pas de bonne réponse automatique.

Concrètement : deux modifications du même champ à quelques secondes d'écart, laquelle gagne ? La plus récente ? Alors une correction faite par un humain sera écrasée par une mise à jour automatique arrivée après. Le système fait exactement ce qu'on lui a demandé, et la donnée est fausse.

Quand c'est vraiment nécessaire, cela se traite avec un horodatage par champ et une règle de préséance écrite. C'est faisable, mais cela doit être un choix assumé, pas une case cochée parce qu'elle était dans le cahier des charges.

Quatre choses, et elles arrivent toutes après la mise en ligne.

Le troisième est le plus insidieux. Une intégration propage les créations et les mises à jour, très rarement les suppressions, et personne ne s'en aperçoit tant que quelqu'un ne demande pas pourquoi un client parti depuis un an reçoit encore des emails.

Le quatrième n'est pas seulement technique. Si une personne demande l'effacement de ses données, votre réponse doit couvrir le CRM, le produit, et tout ce qui a été copié entre les deux. Une intégration multiplie les endroits où la donnée existe, donc les endroits où il faudra la supprimer.

La méthode tient en quatre étapes, et la première ne demande aucun développeur.

C'est la même logique d'avancer une demande à la fois que celle de l'abonnement de développement illimité : un chantier fini vaut mieux que quatre à moitié faits.

Brancher un CRM à son produit est un projet court quand la gouvernance de la donnée a été tranchée avant, et un chantier sans fin quand elle ne l'a pas été. La technique suit toujours, elle ne décide jamais.

Alors commencez par le tableau des sources de vérité, une heure à deux personnes. Puis vérifiez le connecteur natif, puis branchez une seule donnée dans un seul sens. Vous aurez une intégration qui tient, et une idée nette de ce que la suivante coûtera.

“Une intégration ne synchronise pas des données. Elle applique une décision que quelqu'un a prise, ou qu'il a oublié de prendre.”

Deux articles pour prolonger : l'équipe tech externalisée et l'abonnement de développement illimité.