« Mettre le client au centre. » Cette phrase revient de plus en plus autour des CRM. Elle sonne bien, mais dans plusieurs systèmes le client est déjà partout : ventes, comptabilité, marketing et service. C’est justement le problème.

Une entreprise imaginaire compte 10 000 fiches dans les ventes, 10 400 en comptabilité et 9 700 dans sa liste marketing. Additionner ces nombres ne donne pas le nombre de clients, parce que chaque base possède ses identifiants et son interprétation. Client 1842 dans les ventes n’a aucun lien naturel avec Compte 99107 dans la facturation.

Il faut d’abord un modèle qui sépare les concepts :

Organisation ──< Adresse
      │
      ├──< Contact ──< MoyenContact (courriel, téléphone)
      │
      └──< CompteSource (Système, IdExterne)

Une entreprise peut avoir plusieurs succursales et contacts. Deux divisions à la même adresse ne sont pas forcément un doublon. Le tableau CompteSource conserve les identifiants de chaque application et les relie à l’identité CRM sans forcer les systèmes existants à adopter le même numéro dès demain.

Le rapprochement automatique produit des candidats, pas une vérité. Je peux normaliser la casse, les accents, les abréviations et le format du téléphone, puis calculer un score. Par exemple :

nom exact normalisé       40 points
adresse et code postal    30 points
téléphone                 20 points
courriel                  10 points

>= 80  : liaison automatique
50-79  : revue humaine
< 50   : fiches séparées

Ce barème doit être mesuré sur de vrais cas. « ABC Inc. » et « A.B.C. Incorporated » peuvent être la même organisation; deux Jean Tremblay ne le sont pas nécessairement. Une fusion erronée est souvent plus dommageable qu’un doublon : elle mélange factures, communications et peut exposer les données d’un client à un autre.

Même après la liaison, chaque attribut a besoin d’un système maître. La comptabilité peut posséder l’adresse de facturation légale, les ventes le contact commercial et le CRM les préférences de communication. Une règle de survivance précise quelle source gagne, dans quelles conditions et si une modification doit être renvoyée aux autres systèmes.

Le flux pourrait être :

1. le CRM reçoit un changement avec l’identifiant source et l’heure;
2. il valide le format et trouve l’identité liée;
3. il applique la règle du champ, pas une règle globale « le CRM gagne »;
4. il écrit une nouvelle version avec provenance;
5. il publie le changement aux systèmes abonnés;
6. chaque cible confirme l’identifiant et la version appliquée.

Une intégration par lot doit être rejouable. Si le fichier du soir s’arrête à la ligne 8 000, le reprendre ne devrait ni dupliquer les contacts ni écraser une donnée plus récente. Je conserverais un numéro de version ou une date de modification source et refuserais un événement plus vieux que celui déjà appliqué. Les rejets vont dans une file de correction avec raison, pas dans un trou silencieux.

La suppression mérite une règle particulière. Effacer physiquement une fiche dans un système peut la faire réapparaître au prochain import d’un autre. Un statut Fusionné vers 4182 ou Inactif conserve la correspondance et l’historique. Une fusion doit être réversible tant qu’elle n’a pas été confirmée dans toutes les cibles.

Le portrait 360 degrés concentre aussi des données sensibles. Les droits doivent limiter qui voit les notes, factures ou préférences. Les exports marketing respectent le consentement et sa source. Un journal de fusion conserve qui a relié quoi, mais les données ne doivent pas être copiées dans chaque log d’intégration.

Je commencerais par un attribut très banal : « si le client change d’adresse aujourd’hui, où l’écrit-on, qui l’approuve et quels systèmes la reçoivent? » Puis je suivrais dix changements de bout en bout et testerais une panne au milieu. Un CRM devient le centre lorsqu’il possède des identifiants, une provenance et des règles de conflit; le beau cercle dans le diagramme vient après.