Le client corrige son numéro dans l’espace en ligne. Le CRM l’écrase une heure plus tard avec une ancienne valeur importée. Le commercial modifie alors la fiche, mais l’utilisateur voit toujours la copie mise en cache. Trois écrans paraissent fonctionner ; ensemble, ils rendent impossible de savoir quel numéro sera utilisé pour la prochaine intervention.
Le réflexe consiste à synchroniser plus souvent ou dans les deux sens. Cette accélération peut aggraver le problème : chaque système réplique plus vite une décision qu’il n’avait pas le droit de prendre. Une date de mise à jour ne suffit pas à départager une validation client, un import et une correction support.
Le vrai enjeu est d’attribuer une identité et une autorité à chaque information, puis de rendre toute proposition et tout conflit explicites. L’espace client est une interface de contribution et de lecture ; il ne devient pas maître de chaque champ parce que la saisie vient du client.
Dans un projet de développement web sur mesure, cette cohérence se construit par contrats, versions, événements et réconciliation. Elle se prouve sur les parcours qui utilisent réellement la donnée.
Distinguer affichage et autorité
Une donnée affichée peut être une projection : copie optimisée, index de recherche ou vue agrégée. Elle reste saine si elle porte source, version et fraîcheur. Une donnée autoritative décide la valeur applicable. Le portail doit pouvoir expliquer son origine au support sans exposer les détails techniques au client.
Classez les informations par conséquence : profil de contact, identité légale, adresse d’intervention, consentement, condition commerciale, statut de contrat. Un libellé peut être modifiable immédiatement ; un changement de raison sociale exige des preuves ; une adresse liée à une commande ne doit pas réécrire les dossiers passés.
Nommer l’usage avant le champ
« Adresse client » mélange souvent siège, facturation, livraison et intervention. Chacune a son objet, sa période et son propriétaire. Avant de synchroniser, écrivez la décision servie et le comportement si la valeur manque ou se contredit.
Partager une identité canonique
L’espace et le CRM échangent un identifiant stable, jamais seulement email ou raison sociale. Les références de chaque source deviennent des aliases reliés au même compte, contact ou site. Un changement d’email ne crée pas une nouvelle personne ; une fusion conserve les anciennes références et les relations.
La granularité est fermée : organisation, compte commercial, établissement, personne, rôle de contact et contrat restent distincts. Deux contacts ayant le même email peuvent relever d’un compte partagé ; deux établissements du même groupe ne sont pas des doublons. Le matching automatique s’arrête lorsqu’une identité reste ambiguë.
Préserver le contexte de connexion
L’identité authentifiée est reliée aux rôles qu’elle exerce pour un compte. Le portail ne déduit pas le compte d’un paramètre libre. Une mutation ou révocation met fin à la relation datée, tout en conservant l’auteur des actions historiques.
Fermer création et fusion
Le portail ne crée pas automatiquement un nouveau contact parce qu’un email est inconnu. Il recherche les aliases du compte, propose un rattachement ou soumet une création avec données minimales. Les règles certaines utilisent des clés dans leur périmètre ; les ressemblances produisent des candidats. Une fusion conserve références, relations et motifs afin que les anciens liens CRM continuent à retrouver la même identité.
Lorsqu’une personne appartient à plusieurs comptes, ses préférences privées et ses rôles professionnels restent séparés. Une correction sur un rôle de facturation ne change pas son identité globale ni les autres comptes. Cette frontière limite les propagations inattendues et permet d’appliquer un droit distinct à chaque relation. Le support voit le graphe utile sans confondre une personne avec le dossier commercial qui l’emploie.
Attribuer chaque donnée
Construisez une matrice : attribut, objet, source autoritative, contributeurs, validation, date d’effet et consommateurs. Le CRM peut maîtriser le propriétaire commercial, le portail une préférence utilisateur, le référentiel l’identité légale et l’outil d’intervention les consignes d’accès au site.
L’autorité peut varier par phase. Une adresse proposée par le client devient applicable après validation ; le portail suit son statut sans afficher prématurément la nouvelle valeur comme acceptée. Une donnée calculée expose ses entrées et sa version, au lieu de devenir une source implicite.
Conserver provenance et preuve
Chaque valeur sensible porte source, auteur, instant de connaissance, date d’effet et motif. Une pièce justificative a son propre droit et sa durée. Cette provenance permet de corriger la projection sans réécrire l’histoire des décisions déjà prises.
Définir les directions d’écriture
Une synchronisation unidirectionnelle suffit lorsque l’autre système lit une autorité. Une contribution inverse devient une commande ou proposition, pas une mise à jour brute. Le propriétaire accepte, refuse ou demande un complément, puis publie le résultat. L’interface montre cet état.
Pour un champ libre et peu risqué, le portail peut être maître et le CRM consommer. Pour une donnée contractuelle, le CRM ou un référentiel valide. Pour une préférence locale, aucune raison de répliquer dans tous les outils. La direction se décide par attribut, jamais pour « le client » entier.
Éviter la double écriture distribuée
N’essayez pas de confirmer simultanément deux bases. Écrivez dans l’autorité, enregistrez un événement dans une boîte de sortie, puis mettez les projections à jour. Le client reçoit un état accepté ou en traitement et une corrélation, pas une fausse garantie de simultanéité.
Traiter les conflits sans dernier arrivé
Un conflit compare identité, version attendue, source et date d’effet. La dernière date technique ne gagne pas si la source n’est pas autorisée. Une modification concurrente peut être refusée avec la valeur actuelle, fusionnée attribut par attribut ou envoyée en revue selon la conséquence.
Les requêtes conditionnelles HTTP aident à éviter l’écrasement silencieux. La RFC 9110 décrit les requêtes conditionnelles avec validateurs comme les ETags. Elles protègent une version, mais la décision de fusion reste métier.
Créer une file d’arbitrage exploitable
La file contient objet, valeurs, provenance, impact, règle et actions. Elle possède propriétaire et délai. Les décisions répétées deviennent une règle versionnée ; les cas rares conservent leur trace. Une file sans capacité n’est qu’un conflit masqué.
Cas concret : changement de contact
Un client grand compte remplace son responsable de facturation. L’utilisateur du portail propose un nouveau nom et un email ; le CRM contient encore l’ancien contact lié à trois contrats. Supprimer l’ancien ferait disparaître l’auteur de validations et les échanges passés.
Le portail crée une proposition sur le rôle de contact, avec date d’effet. Le CRM vérifie le périmètre, rattache la nouvelle personne et clôt la relation précédente. Les contrats historiques restent liés aux personnes qui ont agi. L’événement met à jour l’espace et le système de facturation.
Le pilote rejoue quarante changements, dont email déjà connu, date future, contact multi-comptes et refus. Le go local exige zéro relation historique perdue, zéro notification envoyée à un contact expiré après le délai prévu et un diagnostic support depuis le compte. Ces seuils qualifient ce flux précis.
Versionner API et événements
Le contrat précise identifiant, schéma, optionalité, sémantique, version et erreurs. Le vocabulaire de validation JSON Schema 2020-12 permet d’exprimer des contraintes structurelles ; il ne remplace pas la règle métier d’autorité.
Les événements décrivent des faits : proposition soumise, contact accepté, relation expirée. Ils portent identifiant, version d’objet, date d’effet et corrélation. Un consommateur idempotent ignore un doublon et ne fait pas reculer sa projection avec un événement ancien.
Évoluer sans casser les consommateurs
Ajoutez des champs compatibles, publiez les nouvelles valeurs possibles et mesurez les versions lues. Une rupture reçoit une période de transition et des tests de contrat. La suppression intervient après observation réelle, pas seulement après une annonce.
Protéger confidentialité et minimisation
Le CRM contient souvent des notes internes qui ne doivent jamais rejoindre l’espace. Le contrat publie une projection explicitement autorisée, pas l’objet complet filtré après coup. Les champs personnels ont une finalité, un droit et une durée. Les environnements de test utilisent des données adaptées. Un export ou un log ne doit pas contourner le masquage défini pour l’interface.
Le client peut voir la provenance d’une information sans connaître l’auteur interne nominativement. « Validé par le service contrats » suffit parfois. À l’inverse, une demande soumise par le client doit rester attribuable. Cette nuance est fermée avec les équipes juridiques et sécurité selon les données concernées, sans inventer une règle générale de conservation dans le code.
Implémenter la cohérence progressive
Les entrées sont identifiant canonique, attribut, valeur proposée, version attendue, auteur et date d’effet. La sortie est acceptation, attente ou refus avec version et motif. Le service d’autorité assume la décision ; les adaptateurs CRM et portail traduisent leurs formats sans changer le sens.
Les dépendances, délais et seuils de fraîcheur sont documentés. La journalisation relie proposition, décision et événements. Le monitoring suit conflits, projections en retard, messages rejetés et arbitrages âgés. Le retry est idempotent. Le rollback suspend un nouveau chemin d’écriture sans effacer les propositions déjà enregistrées.
Les fichiers de reprise portent schéma, encodage, manifeste, checksum et compteurs. L’import reçoit identifiant canonique et version attendue ; la sortie détaille acceptés, refusés et déjà traités. Une responsabilité nommée examine les écarts avant relance. Le monitoring rapproche volume et distribution du profil attendu. Si un seuil local est dépassé, le lot s’arrête avant l’écriture. Le rollback s’appuie sur le manifeste, tandis que le retry rejoue la même commande sans doubler les relations.
Migrer depuis la double vérité
Commencez en lecture comparée. Pour chaque attribut, mesurez accord, divergence et inconnus. Choisissez une règle ou une revue, puis backfillez les identifiants. Activez une seule direction à la fois. Une balance vérifie objets, relations et versions avant le retrait de l’ancien flux.
Réconcilier et diagnostiquer
Une réconciliation périodique compare identité, version et attributs autoritatifs. Elle ne copie pas aveuglément ; elle classe source en retard, projection manquante, conflit et objet orphelin. Chaque catégorie possède action, propriétaire et délai. Le support peut relancer une projection depuis la corrélation.
Contre-intuitivement, un écart visible peut être préférable à une synchronisation qui l’efface mal. Exposez l’état de traitement et bloquez la décision sensible si nécessaire. Mesurez surtout corrections annulées, conflits récurrents et temps d’arbitrage, pas seulement le nombre de messages livrés.
Pour qui cette architecture est utile
Elle devient nécessaire quand clients et équipes internes modifient les mêmes objets, quand plusieurs comptes et sites partagent des contacts ou lorsque des décisions contractuelles dépendent de la donnée. Elle concerne CRM, produit, métier, intégration, data, sécurité et support.
Un espace purement documentaire peut lire des projections simples. Une donnée non critique peut tolérer un délai visible. N’installez pas un moteur de conflits général : commencez par les attributs dont la contradiction provoque une mauvaise action.
Erreurs fréquentes de synchronisation
Choisir le plus récent
La récence technique ne prouve ni autorité ni date d’effet. Gardez provenance, version et règle. Un import récent peut contenir une valeur ancienne.
Synchroniser un objet entier
Les attributs ont des propriétaires différents. Une mise à jour globale écrase des décisions légitimes. Utilisez commandes ciblées et contrats par donnée.
Corriger directement la projection
La prochaine synchronisation annule la correction. Le support doit proposer une modification à l’autorité ou relancer la projection, puis vérifier la réconciliation.
Décision : lire, proposer ou maîtriser
Priorisez les attributs qui changent droit, argent, livraison ou notification. L’espace lit si une autre source décide ; il propose si le client apporte une preuve ; il maîtrise seulement les préférences et données dont il assume le cycle complet. Différez les champs sans consommateur clair. Refusez une bidirectionnalité non attribuée.
Si un conflit peut produire une action dangereuse, alors bloquez cette action et arbitrez. En revanche, une projection informative peut afficher sa fraîcheur. À éviter : masquer l’écart par une valeur par défaut.
- Commencer par une identité et cinq attributs critiques.
- Documenter autorité, contribution, version et conflit.
- Tester concurrence, ordre, reprise et réconciliation.
- Élargir après avoir fermé les corrections annulées.
Plan d’action sur cinq semaines
Semaines un et deux : observer et attribuer
Choisissez un compte, deux parcours et cinq attributs. Rejouez vingt divergences et cartographiez créations, copies, corrections et usages. Fermez identité, granularité, source, contributeurs et date d’effet. Préparez des cas concurrents et historiques.
Écrivez les commandes, événements et erreurs. Définissez fraîcheur, mode dégradé, file d’arbitrage et balance. Ajoutez les identifiants canoniques sans changer encore les écritures. Comparez les valeurs et expliquez chaque catégorie d’écart.
Semaines trois à cinq : activer et perturber
Branchez une proposition du portail vers l’autorité. Publiez le résultat vers CRM et espace. Provoquez deux modifications, message doublonné, événement ancien, dépendance indisponible et version inattendue. Vérifiez motifs et absence d’écrasement.
Faites traiter dix propositions par le métier et cinq reprises par le support. Mesurez délai, conflits et projections. Le rollback ferme les nouvelles propositions mais conserve leur journal et la lecture de la valeur autoritative.
Activez un second attribut après un cycle complet. Étendez si les écarts se classent, si la balance ferme et si le support retrouve la cause ; sinon, corrigez identité ou autorité avant d’augmenter la fréquence.
Effectuez une recette de temps : proposition future, correction rétroactive, événement reçu en retard et changement réalisé pendant une panne. Pour chaque dossier, reconstruisez la valeur applicable et celle connue à l’instant de la décision. Les écarts reçoivent une cause, pas une correction immédiate. Le propriétaire confirme les règles de date d’effet ; le support retrouve le parcours depuis la corrélation. Cette étape empêche qu’une synchronisation techniquement exacte produise une histoire métier fausse.
- Nommer identité, usage et autorité.
- Contractualiser proposition, décision et événement.
- Tester conflits, panne et reprise.
- Réconcilier puis étendre attribut par attribut.
Approfondir identité et portail
Gouverner la matrice d’autorité
Révisez la matrice lors de chaque nouveau parcours ou connecteur. Une source peut rester propriétaire de l’identité légale tandis qu’une autre récupère la préférence de communication. Documentez la transition, le backfill et le retrait de l’ancien flux. Les consommateurs reçoivent une date et une version. Après bascule, mesurez encore les écritures sur l’ancien chemin : leur présence signale un outil oublié ou un contournement qui recréera la contradiction.
Le comité de données examine surtout les conflits répétés et leurs coûts. Une file qui grossit peut révéler une règle trop stricte, une identité mal définie ou une capacité insuffisante. Il décide de promouvoir une règle, de conserver une revue ou de réduire le droit de contribution. Les choix sont datés et testés sur un échantillon. Cette gouvernance évite que le moteur devienne une collection de priorités invisibles.
Maintenez aussi un registre des consommateurs avec leur version, leur finalité et leur propriétaire. Avant de retirer un champ ou un événement, mesurez les appels et rejouez un échantillon d’historiques. Une intégration silencieuse depuis plusieurs semaines n’est pas forcément abandonnée : elle peut servir une clôture mensuelle. La date de fin est acceptée avec le métier, puis une alerte détecte les derniers usages. Après retrait, la documentation, les exemples et les permissions correspondantes disparaissent ensemble.
La qualité se suit par décision plutôt que par moyenne globale. Pour le contact de facturation, comptez relations sans période, notifications revenues et propositions âgées. Pour l’adresse d’intervention, suivez écarts entre dossier et site canonique. Chaque seuil local ouvre une action connue. Cette précision empêche un excellent taux de synchronisation de masquer un petit nombre de contrats bloqués, et elle concentre le budget sur les contradictions qui changent réellement une promesse client.
Traiter les doublons métier
Le guide sur les données métier dupliquées complète l’identité, les aliases et la fusion réversible.
Appliquer la cohérence au B2B
Poursuivez avec le portail B2B contractuel pour relier cette autorité aux catalogues, prix et documents.
- Une identité canonique.
- Une autorité par attribut.
- Une réconciliation actionnable.
Conclusion : une donnée, une autorité
Éviter les contradictions ne signifie pas disposer d’une seule base. Cela signifie qu’une identité est partagée, qu’un attribut possède une autorité et que ses copies annoncent leur version et leur fraîcheur.
Les propositions, requêtes conditionnelles et événements empêchent l’écrasement silencieux. Les conflits et la réconciliation rendent visibles les limites, puis donnent au support une action sûre.
Commencez par la donnée que le client et le commercial corrigent le plus souvent. Retrouvez son usage, attribuez sa décision et fermez un flux. Ce premier contrat réduira davantage les contradictions qu’une synchronisation généralisée.
- Une source assumée.
- Une copie qualifiée.
- Un conflit explicable.
Dawap peut accompagner cette architecture de développement web sur mesure : audit CRM, identité, contrats d’intégration, espace client, migration et run.
