Comment décider quel système est la source de vérité pour chaque donnée métier

Intégrer un CRM, un ERP, un site e-commerce, un outil de service client et des applications internes ne résout pas à lui seul les problèmes de données. Cela peut même les amplifier lorsque chaque application conserve une version différente d’un client, d’un prix ou d’une commande. La question décisive n’est pas de savoir quels systèmes sont connectés, mais quel système fait autorité pour chaque donnée et dans quelles conditions.

Une source de vérité ne doit pas nécessairement être une plateforme unique pour toute l’entreprise. C’est une décision prise par entité et par attribut : l’ERP peut gouverner le stock et les factures ; le site e-commerce, le panier et le statut de paiement visible par l’acheteur ; le CRM, l’activité commerciale ; et l’outil de support, les dossiers de service client. L’objectif est que toute personne et tout processus sachent où créer, où modifier, où consulter et comment résoudre les divergences.

La source de vérité n’est pas seulement l’endroit où la donnée est stockée

Un système peut contenir une copie d’une donnée sans en être la source de vérité. Par exemple, le CRM peut afficher le solde d’un client provenant de l’ERP. Si un commercial modifie ce solde dans le CRM, il a modifié une réplique, et non nécessairement la donnée valide pour la finance.

Pour attribuer l’autorité, il est utile de distinguer quatre responsabilités souvent confondues :

• Source de création : système qui génère pour la première fois l’enregistrement et son identifiant métier.
• Source de mise à jour : système autorisé à modifier un attribut précis.
• Source de consultation : interface depuis laquelle les utilisateurs ou services doivent lire la valeur, même s’il s’agit d’une copie synchronisée.
• Responsable opérationnel : équipe qui définit les règles, la qualité, les autorisations et les décisions en cas d’exception.

Cette séparation évite les règles simplistes telles que « le CRM est le référentiel des clients ». Un client n’est pas un bloc indivisible : raison sociale, adresse de livraison, limite de crédit, consentement commercial, responsable commercial et préférences de contact peuvent relever de propriétaires différents. L’autorité doit être définie au niveau de l’attribut lorsque le processus l’exige.

Il faut également distinguer la vérité opérationnelle de la vérité historique. Le prix actuel d’un produit peut résider dans l’ERP ou dans une plateforme de catalogue, mais le prix appliqué à une commande déjà confirmée doit être conservé comme un instantané de cette commande. Le recalculer à partir du tarif en vigueur détruit la traçabilité et peut modifier des rapports ou des réclamations.

Constituez l’inventaire avant de concevoir les synchronisations

Avant de choisir des connecteurs, des webhooks ou des intégrations bidirectionnelles, établissez un inventaire des données qui circulent entre les systèmes. Ne commencez pas par les écrans : commencez par les entités, leurs attributs, les processus qui les modifient et les effets de chaque changement.

Une matrice d’autorité simple doit inclure au minimum :

• L’entité et l’attribut : par exemple, produit/SKU, produit/stock disponible ou client/e-mail.
• Le système de création, le système de mise à jour et les systèmes de consultation.
• L’événement qui provoque le changement : création, paiement confirmé, retour, ajustement de stock ou clôture d’un dossier.
• L’identifiant interne et, le cas échéant, les identifiants externes.
• Le sens de synchronisation, la fréquence et le mécanisme : événement, traitement planifié ou consultation à la demande.
• La règle de conflit, le responsable de la revue et le journal d’audit.

Classez ensuite chaque champ selon sa nature. Les données de référence, comme un catalogue de produits, nécessitent souvent un contrôle éditorial. Les données transactionnelles, comme les commandes et les factures, doivent être immuables ou modifiables au moyen d’événements clairement définis, tels qu’une annulation ou un avoir. Les données dérivées, comme la valeur vie estimée d’un client, ne devraient pas écraser les données opérationnelles : elles requièrent une formule, une origine et une date de calcul.

Des questions qui imposent une décision utile

• Quelle équipe est responsable si la donnée est erronée et provoque un incident ?
• Quel processus doit valider le changement : commercial, logistique, fiscal ou service client ?
• Quelle est la conséquence de l’acceptation d’une valeur ancienne pendant quelques minutes ou quelques heures ?
• La valeur peut-elle être reconstruite à partir d’événements ou doit-elle être conservée comme un état ?
• Quel utilisateur possède le contexte et les autorisations nécessaires pour la corriger sans créer de risque de conformité ou de risque financier ?

S’il n’existe pas de réponse explicite, il n’existe pas d’autorité définie ; il n’y a qu’une habitude d’utilisation qui échouera lorsque le volume augmentera ou qu’une autre application sera ajoutée.

Attribuez l’autorité selon le type de donnée et le processus métier

Il existe des modèles fréquents, mais aucune règle universelle. La bonne décision dépend du système qui exécute le processus et en assume les conséquences.

• Clients : le CRM gouverne souvent les opportunités, le responsable commercial et l’activité de vente. L’ERP peut faire autorité pour les données fiscales, les conditions de paiement et la limite de crédit. Le site e-commerce peut recueillir des adresses et des préférences liées à un achat, qui devront être validées avant de remplacer des données fiscales.
• Produits : un outil de catalogue, l’ERP ou un système interne peuvent créer les SKU et les attributs produits. Le site e-commerce enrichit souvent les descriptions commerciales, les images et la visibilité par canal. Définissez les champs qui relèvent de chaque domaine afin qu’une importation n’efface pas le contenu éditorial.
• Prix : le tarif en vigueur doit avoir une source autorisée. Les promotions peuvent avoir un propriétaire distinct si leur moteur applique des règles spécifiques. Le montant d’une commande confirmée ne doit pas être mis à jour lorsque le tarif change.
• Commandes : le site e-commerce peut créer la commande et enregistrer l’intention d’achat ; l’ERP peut faire autorité pour la préparation, l’expédition, la facturation et les retours. Utilisez des statuts ayant une signification précise plutôt qu’un champ ambigu unique tel que « terminé ».
• Stock : le système qui enregistre les réceptions, les réservations, les ajustements et les expéditions doit gouverner le stock vendable. Publier une copie dans le site e-commerce est courant, mais laisser le site e-commerce ajuster le stock sans règle contrôlée entraîne des surventes et des rapprochements manuels.
• Consentements : l’autorité doit être le système qui enregistre la preuve nécessaire : canal, finalité, date, origine et retrait. Copier une simple valeur booléenne sans contexte réduit la capacité à démontrer ce qui s’est produit.
• Dossiers de service client : l’outil de support peut gouverner l’historique du dossier, tandis qu’un retour approuvé ou un remboursement doit déclencher un processus dans le système financier ou opérationnel concerné.

Dans un scénario hypothétique, un site e-commerce crée la commande et émet un événement de paiement confirmé. L’ERP crée l’ordre opérationnel et met à jour ses statuts logistiques. Le CRM reçoit un résumé de l’achat pour la segmentation, mais ne peut pas modifier la commande. Le service client consulte les deux systèmes et ouvre une demande de retour ; l’ERP confirme le mouvement et renvoie le résultat. Cette matrice réduit la tentation de faire écrire tous les systèmes dans tous les autres.

Choisissez un modèle d’intégration qui limite les conflits

La synchronisation unidirectionnelle est l’option par défaut lorsqu’une autorité est clairement établie : le système maître publie et les consommateurs reçoivent. Elle est plus simple à diagnostiquer, protège la source et minimise les boucles de mise à jour.

La synchronisation bidirectionnelle n’est raisonnable que si trois conditions sont réunies : chaque système possède des attributs différents, les règles de modification sont explicites et des mécanismes de conflit et de traçabilité existent. Ce n’est pas une solution pour « tout maintenir identique » ; cette promesse cache généralement des décisions non résolues.

• Événements : adaptés aux changements importants tels qu’une commande créée, un paiement confirmé, un stock ajusté ou une facture émise. Ils doivent inclure un identifiant, un type d’événement, une date, une version et une origine.
• Traitements planifiés : utiles pour rapprocher des changements perdus, traiter des chargements historiques ou diffuser des informations qui ne requièrent pas d’immédiateté.
• Consultation à la demande : appropriée si le consommateur a besoin de la valeur actuelle et si la latence est acceptable. Elle évite le stockage de copies, mais introduit une dépendance à la disponibilité et aux performances.
• Réplique de lecture : nécessaire pour l’analytique, la recherche ou la rapidité de l’interface. Elle doit être traitée comme une projection, et non comme un lieu de modification.

Concevez les consommateurs de sorte que les événements soient idempotents : le traitement deux fois du même message ne doit ni dupliquer une commande ni appliquer deux ajustements. Conservez une clé d’événement ou une version par entité. Lorsqu’une mise à jour ancienne arrive, le consommateur doit la détecter au lieu de remplacer silencieusement une valeur plus récente.

Définissez les conflits, les identifiants et l’historique avant qu’ils ne surviennent

Une règle selon laquelle « la dernière mise à jour l’emporte » paraît objective, mais elle est risquée si les horloges ne sont pas synchronisées, si un système réessaie des messages ou si une importation massive utilise une date trompeuse. Ne l’employez que pour des attributs à faible risque et lorsque l’horodatage représente réellement le moment métier.

Pour les données critiques, privilégiez les priorités par domaine et les transitions d’état valides. Par exemple, une commande payée ne devrait pas repasser à l’état « en attente » parce qu’une synchronisation en retard a envoyé un statut antérieur. Un retour peut nécessiter une revue humaine si la demande du support contredit le statut logistique de l’ERP.

Chaque entité partagée a besoin d’une stratégie d’identification :

• Un identifiant stable dans le système d’origine et des références externes stockées sans réutilisation.
• Des règles de rapprochement pour les migrations et les créations manuelles, en particulier pour les clients et les contacts.
• Une protection contre les doublons : l’e-mail peut être utile, mais n’identifie pas toujours de manière unique une personne ou une entreprise.
• Un historique des changements indiquant l’ancienne valeur, la nouvelle valeur, l’origine, l’acteur ou le processus, ainsi que le moment du changement.

Évitez de remplacer des enregistrements lors de l’importation de données. Une opération de mise à jour doit connaître la version qu’elle modifie et les champs qu’elle est autorisée à toucher. Lorsque l’incertitude est élevée, dirigez le cas vers une file de revue au lieu de fusionner automatiquement deux clients ou d’écraser une adresse.

Signaux d’alerte et liste de contrôle pour approuver une intégration

Certains symptômes révèlent clairement une architecture dépourvue de source de vérité : des équipes qui corrigent la même donnée dans plusieurs outils, des rapports dont les totaux sont incompatibles, des intégrations qui « synchronisent tout », des champs sans description de leur origine, ou des incidents résolus avec des exportations et des feuilles de calcul. C’est également un signal d’alerte lorsque personne ne peut expliquer pourquoi une valeur a changé ni ce qui se produira si elle est modifiée.

Avant d’approuver une nouvelle intégration, validez cette liste de contrôle :

1. Chaque attribut transféré dispose-t-il d’une source de création, de mise à jour et de consultation documentée ?
2. Le système qui peut écrire et ceux qui peuvent seulement lire sont-ils définis ?
3. Existe-t-il un identifiant stable et une règle pour les créations en double ?
4. Le sens de synchronisation répond-il à un besoin précis ?
5. Les événements comprennent-ils une version, une origine et la capacité de réessayer sans risque ?
6. Les statuts et les transitions invalides sont-ils définis ?
7. Une règle de conflit et un responsable des exceptions sont-ils prévus ?
8. Un historique suffisant est-il conservé pour enquêter sur les changements et rapprocher les défaillances ?
9. Les retards, doublons, indisponibilités temporaires et changements arrivant dans le désordre ont-ils été testés ?

La meilleure intégration n’est pas celle qui réplique le plus de données, mais celle qui préserve l’autorité du processus. Commencez par une petite matrice couvrant les entités qui créent le plus de friction, transformez-la en décision opérationnelle partagée et utilisez-la comme exigence pour tout nouveau système. Les intégrations cessent alors d’être des conduits opaques pour devenir une partie maîtrisée de l’architecture métier.