Le commerce corrige le nom d’un client dans le CRM. La finance restaure la raison sociale légale depuis l’ERP. Le support ajoute une adresse sur son outil de tickets et le portail laisse le client modifier son téléphone. Le lendemain, une synchronisation complète écrase deux corrections. Le problème devient visible : les quatre équipes avaient de bonnes raisons d’agir, mais aucune règle ne disait quelle décision devenait opposable.
Choisir une source de vérité ne consiste pas à élire une base unique pour tout l’objet « client ». Une identité légale, une relation commerciale, un contact, une préférence et une adresse de facturation ont des cycles de vie et des autorités différents. L’unicité doit porter sur la décision et parfois sur le champ, pas sur le logo du logiciel le plus central.
Le vrai enjeu apparaît lorsque lecture et écriture sont confondues. Une équipe peut avoir besoin d’afficher une valeur sans la posséder. Elle peut proposer une correction sans pouvoir la valider. Une donnée dérivée peut être calculée depuis plusieurs sources sans devenir modifiable partout. Contre-intuitivement, ces distinctions réduisent davantage les conflits qu’une synchronisation plus rapide.
Une démarche de développement web sur mesure peut rendre ces responsabilités visibles dans les contrats, interfaces et reprises. Ce guide aide à attribuer l’autorité, traiter les conflits et conserver une provenance compréhensible lorsque plusieurs métiers contribuent au même dossier.
Définir une vérité par décision
Une donnée est « vraie » pour un usage et une période. L’adresse de livraison choisie pour une commande ne remplace pas nécessairement l’adresse habituelle du client. Le statut de risque calculé ce matin ne vaut pas comme décision de crédit définitive. Le contrat nomme donc le concept, l’événement qui le rend opposable et les consommateurs autorisés.
Le système de référence conserve l’état et l’historique d’une décision. Le système d’enregistrement capture une action. Le système d’engagement peut porter l’expérience. Ces rôles peuvent coïncider, mais pas toujours. Une interface portail peut enregistrer une demande de changement dont l’ERP ou le CRM rend ensuite le verdict.
Refuser la vérité par habitude
« L’ERP est maître » ou « le CRM possède le client » ne suffit pas. L’équipe doit expliquer pourquoi ce système possède la règle, la qualité et l’autorité. Si l’ERP ne connaît pas les préférences de contact, il ne doit pas les écraser parce qu’il exporte la fiche la nuit.
Cartographier les usages avant les systèmes
La cartographie part des actes : créer une organisation, qualifier un prospect, valider une identité, changer une adresse, fermer un compte, fusionner un doublon ou calculer un segment. Pour chaque acte, elle note acteur, contexte, preuve, effet et systèmes qui lisent le résultat. Cette méthode révèle que deux champs proches répondent parfois à des décisions différentes.
Les dossiers réels comptent davantage que le modèle théorique. Sélectionnez créations, corrections, fusions, erreurs et départs. Reconstituez qui a changé quoi, sur quelle base et quelle valeur a finalement été utilisée. Les tableurs de contrôle et les appels au support signalent les zones où l’autorité est déjà disputée.
Le coût caché se trouve dans les vérifications croisées, corrections répétées et campagnes d’email pour savoir « quelle valeur garder ». Mesurer ces gestes permet de prioriser. Une ambiguïté sur un champ rarement utilisé peut attendre ; une adresse ou un statut qui bloque chaque commande mérite une décision immédiate.
Attribuer la propriété champ par champ
La matrice indique concept, champ, système propriétaire, lecteurs, interface d’édition, validateur, fraîcheur et règle de suppression. Elle traite aussi les relations : rattachement d’un contact, appartenance à un groupe, délégation ou contrat. Un même objet peut donc avoir plusieurs propriétaires sans devenir incohérent.
La propriété repose sur la capacité à rendre une décision. Le juridique ou l’ERP peut posséder la raison sociale vérifiée ; le CRM, le statut commercial ; le client, une préférence de notification. Une copie locale garde la valeur et sa version, mais une correction repart vers le propriétaire par un cas d’usage explicite.
Chaque propriétaire nomme un responsable métier et une équipe opérationnelle. Le premier arbitre le sens ; la seconde maintient le service et la qualité. Sans ce double ancrage, un catalogue de données peut indiquer un nom sans fournir personne capable de trancher pendant un incident.
Séparer proposition, validation et publication
Lorsqu’une équipe agit depuis un système non propriétaire, elle crée une proposition. Celle-ci contient valeur actuelle, valeur proposée, version lue, motif, auteur et pièces éventuelles. Le propriétaire accepte, refuse ou demande une précision. L’interface montre « en validation » au lieu d’appliquer une correction optimiste puis de l’écraser.
Les propositions à faible risque peuvent être acceptées automatiquement selon une règle versionnée. Ce raccourci ne supprime pas l’autorité : il formalise une délégation. Les champs sensibles utilisent une séparation de rôles. Une personne peut proposer une fusion sans être autorisée à modifier l’identité légale.
Renvoyer le verdict à tous les contributeurs
Le système propriétaire publie accepté, refusé ou remplacé, avec version et motif. Les copies se mettent à jour depuis ce verdict. Si le retour se perd, la proposition reste consultable par son identifiant. Une simple réplication bidirectionnelle ne remplace pas ce workflow, car elle ne distingue pas demande et décision.
Stabiliser identité et correspondances
Chaque système conserve son identifiant local et une table relie les objets. Un email, un nom ou un numéro affiché ne sert pas de clé universelle. La correspondance porte source, cible, statut, date et version. Une ambiguïté entre deux candidats suspend le rapprochement au lieu de fusionner automatiquement.
La fusion garde l’identifiant absorbé comme alias vers le survivant. Les événements tardifs et documents historiques restent résolvables. Une scission est une nouvelle décision, avec redistribution explicite des relations. Supprimer une ligne de mapping pour « nettoyer » peut rendre tout l’historique incompréhensible.
La création concurrente demande une règle. Un service d’identité peut attribuer un identifiant global, ou chaque système crée puis soumet un rapprochement. Le choix dépend du contexte, mais l’issue doit éviter que deux équipes deviennent chacune propriétaire d’un doublon.
Détecter et résoudre les conflits
Une écriture inclut la version lue. Si l’état a changé, elle ne remplace pas aveuglément la valeur récente. Pour HTTP, les ETag et la précondition If-Match suivent la sémantique du RFC 9110. Elles détectent la concurrence ; la règle métier décide ensuite quoi faire.
Les stratégies diffèrent par champ : propriétaire strict, union contrôlée, valeur maximale validée, fusion assistée ou compensation. « Dernière écriture gagnante » ne convient que si la criticité, la chronologie et le sens rendent cette règle légitime. Une date d’arrivée réseau ne doit pas choisir une identité légale.
Le conflit devient un dossier avec valeurs, versions, origines, effets bloqués et responsable. Le support peut fournir le contexte, mais le rôle métier tranche. Un seuil local déclenche une action lorsque les conflits vieillissent ou se concentrent sur une règle : suspendre une écriture, repasser en proposition ou corriger le mapping.
Par exemple, si deux corrections d’adresse partent de la même version, alors la seconde ne doit pas écraser la première. Elle rejoint une comparaison ou revient en proposition selon le champ. Un seuil d’âge défini avec les opérations déclenche l’escalade avant que la commande dépendante ne soit promise.
Traiter les données calculées et enrichies
Une donnée dérivée possède formule, entrées, version et date de calcul. Son propriétaire est celui de la règle, pas forcément celui des sources. Le score de priorité calculé par le CRM ne doit pas être édité dans l’ERP. Une dérogation éventuelle est un objet séparé, avec motif et durée.
Le lignage relie le résultat aux données et activités qui l’ont produit. Le modèle PROV-O du W3C fournit un vocabulaire pour décrire entités, activités et agents ; il peut inspirer la traçabilité sans obliger à adopter tout le standard dans l’application.
La fraîcheur fait partie du résultat. Un segment calculé hier peut rester acceptable pour une campagne et insuffisant pour une décision de crédit. Le consommateur connaît la date et la qualité. Recalculer automatiquement ne résout pas une entrée ambiguë ; il diffuse seulement plus vite le problème.
Cas concret : une fiche client disputée
Cas hypothétique : un groupe possède un client dans le CRM, l’ERP et le portail. Le commerce modifie le nom d’usage, la finance met à jour la raison sociale après un justificatif, et le client change son adresse de livraison. L’intégration nocturne copie l’objet ERP complet vers les deux autres systèmes et efface les modifications légitimes.
La cible sépare identité légale, nom commercial, adresse de facturation, adresses de livraison et préférences. L’ERP possède la raison sociale et la facturation ; le CRM, le nom commercial ; le portail permet au client de proposer ou gérer les adresses autorisées. Chaque flux transporte seulement les champs concernés et leur version.
Une correction légale publie un événement dédié. Une adresse ajoutée crée une relation avec l’organisation et un statut de validation. Une fusion conserve les anciens identifiants. Le support recherche le client et voit pour chaque champ valeur, source, date, proposition en attente et dernier verdict.
Le pilote porte sur cent comptes multi-sites. Les seuils locaux suivent écrasements, conflits vieillissants, correspondances ambiguës et temps d’explication. Toute fuite de périmètre ou perte d’historique ferme l’extension. Le succès n’est pas l’égalité parfaite des fiches, mais l’accord sur les décisions réellement partagées.
Implémenter contrats, versions et provenance
Les API exposent des cas d’usage : proposer un changement, valider, fusionner, fermer. Elles n’offrent pas un PATCH universel sur tous les champs sans autorité. Chaque commande porte acteur, périmètre, version et clé idempotente. Chaque résultat publie le verdict et les valeurs opposables.
Les événements sont étroits et nommés par le fait. Ils comportent identifiant, version, origine, corrélation et date d’effet. Les consommateurs tolèrent répétition et ordre variable selon les partitions. Une réponse tardive ne remplace pas une version plus récente.
La base protège les invariants possibles : unicité dans un périmètre, références valides et versions. Les règles métier restent dans les services qui possèdent le contexte. Le schéma évolue par étapes compatibles ; les consommateurs disposent d’une période pour comprendre les nouveaux champs.
Projeter et superviser les verdicts
Dans le backend PHP et Symfony, l’API expose les commandes de proposition et de validation ; Doctrine protège versions et droits. Un worker Messenger diffuse les verdicts vers le CRM et l’ERP, tandis que le cache conserve provenance et fraîcheur. Les tests d’intégration et la CI couvrent concurrence, fusion et ordre avant chaque déploiement.
L’instrumentation associe entrée, sortie, dépendance et corrélation dans l’observabilité. La journalisation conserve contrat, décision et version sans répliquer inutilement les données sensibles. Le runbook attribue les responsabilités de reprise, le seuil de repli et la réconciliation ; le rollback ferme une écriture sans perdre les propositions en attente.
Observer les écarts et organiser la reprise
Une balance compare valeurs propriétaires et projections sans forcer l’égalité sur les champs locaux. Elle signale absence, version en retard, conflit, mapping inconnu ou valeur impossible. Chaque écart reçoit une catégorie et une action. Le rapprochement se fait par identifiant stable, pas par similarité approximative en production.
Le tableau suit propositions en attente, conflits, âge des projections, fusions non propagées et corrections manuelles. Les métriques sont reliées à des objets métier. Le support peut geler un champ ou un flux sans arrêter toutes les mises à jour. L’action est auditée et limitée.
Le retour arrière conserve les décisions déjà acceptées. Désactiver une nouvelle autorité ne signifie pas recopier toutes les valeurs depuis l’ancien système. L’équipe qualifie les messages en attente et choisit replay, compensation ou résolution manuelle selon leur version.
Pour qui l’autorité des données devient-elle nécessaire ?
Le sujet concerne métiers propriétaires, produit, données, équipes applicatives, sécurité, intégration et support. Les métiers attribuent l’autorité. Le produit conçoit les parcours de proposition. Les équipes data documentent sens et lignage. L’intégration transporte verdicts et versions. Le support valide l’explication.
Pour une donnée purement locale, aucune synchronisation n’est nécessaire. Pour une donnée partagée mais rarement modifiée, un workflow manuel peut être suffisant. Plus les équipes et effets se multiplient, plus la propriété et la version doivent être explicites. Le volume seul ne justifie pas un MDM.
Erreurs fréquentes sur les sources maîtres
Déclarer un système maître pour tout l’objet
Cette simplification ignore les cycles de vie distincts. Attribuez les décisions et les champs, puis construisez une vue agrégée qui conserve leur provenance.
Confondre écran d’édition et propriété
Une équipe peut saisir depuis son outil sans rendre la décision. Utilisez une commande ou une proposition adressée au propriétaire, avec un retour visible.
Fusionner sur un score de similarité
La similarité aide à proposer des candidats, mais une fusion irréversible exige des preuves et un rôle. Les identifiants absorbés restent connus après la décision.
Décider le modèle d’autorité
Bloc de décision. Utilisez un propriétaire unique lorsque la décision appartient clairement à un métier. Utilisez proposition et validation lorsque plusieurs équipes contribuent mais qu’une autorité tranche. Utilisez un calcul dérivé lorsque la valeur résulte de règles. Utilisez une fusion assistée lorsque l’identité reste ambiguë.
Différez l’ouverture d’une écriture si le champ n’a pas de propriétaire, si la version n’est pas disponible ou si la fusion ne conserve pas l’historique. Refusez la bidirectionnalité symétrique pour les champs sensibles. Priorisez les données qui engagent argent, accès, contrat ou communication client.
- Un champ partagé possède une autorité et un verdict.
- Une copie locale porte provenance, version et fraîcheur.
- Un conflit visible vaut mieux qu’un écrasement silencieux.
- Une donnée calculée ne devient pas une saisie concurrente.
Plan d’action en six semaines
Semaines 1 et 2 : cartographier et attribuer
Choisissez vingt dossiers et dix champs disputés. Reconstituez usages, décisions, sources et corrections. Construisez la matrice par champ et nommez les propriétaires. Listez les mappings, fusions et données dérivées. Le premier livrable est un ensemble d’arbitrages validés, pas une architecture générale.
Semaines 3 et 4 : contractualiser et comparer
Ajoutez versions, propositions, verdicts et provenance sur un périmètre. Les nouveaux flux fonctionnent en observation ; une balance compare sans écrire. La recette provoque concurrence, message tardif, fusion et mapping ambigu. Le support retrouve chaque décision.
Semaines 5 et 6 : ouvrir et gouverner
Activez quelques champs et équipes. Mesurez écrasements évités, conflits, délai de validation et corrections. Jouez la coupure d’un flux puis la reprise. Étendez seulement si les propriétaires tiennent leur rôle et si les copies peuvent être reconstruites depuis les verdicts.
Le bilan relie chaque conflit à sa cause, au champ, au temps d’arbitrage et à l’effet bloqué. D’abord, l’équipe ferme les écrasements silencieux ; ensuite, elle réduit les mappings ambigus ; puis elle ouvre de nouveaux contributeurs. Une écriture dont le propriétaire reste contesté est différée, même si le transport fonctionne.
La tranche documente entrées, sorties, dépendances et responsabilités pour chaque champ ouvert. L’instrumentation vérifie le seuil de conflits ; le monitoring suit propositions et versions ; le rollback ferme l’écriture sans perdre les verdicts. Le runbook décrit la réconciliation avant toute reprise de messages.
- Partir des actes métier et des dossiers contestés.
- Attribuer autorité, proposition et calcul par champ.
- Tester versions, conflits, fusions et retours tardifs.
- Étendre depuis les preuves de fonctionnement et de support.
Guides complémentaires pour les données partagées
Encadrer les deux sens
Le guide de la synchronisation bidirectionnelle approfondit propositions, conflits et prévention des boucles.
Préparer les données incertaines
La préparation des données ERP aide à profiler, rapprocher et mettre en quarantaine sans fusion aveugle.
- Attribuer l’autorité avant d’ouvrir une nouvelle écriture.
- Conserver version et provenance dans chaque projection.
- Traiter la fusion comme une décision, jamais comme un nettoyage technique.
Conclusion : rendre chaque modification explicable
Une source de vérité n’est pas le système qui écrase les autres. C’est l’endroit où une décision précise devient opposable, versionnée et retrouvable.
La propriété par champ, les propositions et la provenance permettent à plusieurs équipes de contribuer sans transformer chaque outil en maître concurrent. Les conflits deviennent des dossiers, pas des pertes silencieuses.
La qualité se vérifie quand deux corrections arrivent ensemble, lorsqu’un identifiant fusionne ou qu’un retour tarde. Le système doit expliquer quelle valeur reste valable, qui peut trancher et comment reconstruire les copies.
Dawap peut cadrer ces responsabilités et construire les contrats dans une stratégie de développement web sur mesure. Le résultat attendu est une collaboration plus fluide, parce que chaque équipe sait ce qu’elle lit, ce qu’elle propose et ce qu’elle possède réellement.
