Semarchy répond à un besoin précis de master data management : certifier des référentiels issus de plusieurs applications, conserver leur traçabilité et les redistribuer aux usages opérationnels comme décisionnels. La valeur du produit se joue moins dans l’interface que dans les règles de rapprochement, de survie et de validation que vous acceptez de maintenir.
- Semarchy xDM place le référentiel maître entre les sources de gestion, telles qu’un ERP ou un CRM, et les outils consommateurs comme Power BI ou Azure Synapse Analytics.
- Le Golden Record n’est pas une copie d’une source : il résulte de règles explicites de standardisation, de dédoublonnage, de rapprochement et de validation.
- Les API SQL et REST permettent une alimentation par lots ou par événements, mais elles ne remplacent pas un mapping documenté ni une recette chiffrée.
- La gouvernance des données dépend de workflows, de rôles et de règles de contrôle visibles, non d’un catalogue seul.
- Un projet Semarchy mal cadré recrée souvent les divergences qu’il devait traiter, cette fois dans un hub central plus difficile à contester.
Ce dossier vise les responsables décisionnels qui doivent raccorder un MDM à un socle analytique existant, notamment Azure et Power BI. Il ne traite ni le paramétrage détaillé d’Azure Kubernetes Service, ni les sujets de protection des données personnelles, qui relèvent respectivement de vos équipes d’infrastructure et de votre DPO.
Quel rôle Semarchy joue-t-il dans une architecture MDM et data intelligence ?
Semarchy xDM est un hub de gestion des données de référence. Il reçoit des données provenant de systèmes producteurs, les contrôle, rapproche les enregistrements qui désignent la même entité, puis fournit une version certifiée aux applications qui en ont besoin. Dans cette architecture data, le produit ne remplace ni l’ERP ni le CRM. Il ne remplace pas davantage l’entrepôt décisionnel. Il sert de point de contrôle sur les données dont la cohérence conditionne les indicateurs.
Le cas le plus courant concerne les clients, produits, fournisseurs, sites ou structures organisationnelles. Un même client peut être créé dans un CRM, facturé dans un ERP et modifié par un outil de support. Les identifiants divergent, les raisons sociales sont abrégées et les adresses suivent des formats distincts. Un modèle sémantique Power BI peut alors compter trois clients là où la direction commerciale en attend un seul. Le MDM ne corrige pas cette situation par magie. Il formalise la règle qui permet de décider si ces lignes doivent être rapprochées.
La data intelligence, dans un périmètre décisionnel, désigne ici la capacité à rendre l’origine, le statut et le niveau de certification d’une donnée visibles. Une mesure de chiffre d’affaires n’acquiert pas de fiabilité parce qu’elle est affichée dans un tableau de bord. Elle devient défendable quand le référentiel client, le périmètre produit et les règles de rattachement sont identifiés. Semarchy apporte cette couche de certification avant la consommation analytique.
Le hub MDM ne doit pas devenir une copie générale du système d’information
Une erreur fréquente consiste à vouloir charger dans le hub chaque table d’un ERP, toutes les traces de commandes et tous les historiques transactionnels. Ce choix augmente le volume, les dépendances et la charge de recette sans améliorer le pilotage. Un MDM doit contenir les attributs nécessaires à l’identification, à la qualification et à la distribution d’une entité maître. La ligne de commande, la facture détaillée ou le mouvement de stock restent en principe dans leurs systèmes transactionnels et dans l’entrepôt qui les historise.
La frontière doit être écrite avant la conception du modèle. Pour un domaine fournisseur, le hub peut conserver l’identité légale, les coordonnées, le statut d’activité, la catégorie d’achat et les liens entre entités. Il n’a pas vocation à devenir le grand livre fournisseurs. Pour un domaine produit, il peut consolider la famille, l’unité de mesure, le statut commercial et les hiérarchies. Les prix, commandes et volumes vendus restent des données de faits, analysées dans leur couche décisionnelle.
Cette séparation est déterminante pour les équipes BI. Une dimension client issue de Semarchy peut alimenter un modèle sémantique Power BI, tandis que les ventes viennent d’un entrepôt ou d’un flux d’intégration distinct. Vous évitez ainsi que chaque rapport applique sa propre règle de dédoublonnage dans une colonne calculée ou dans une requête Power Query. C’est là que les écarts s’installent, puis deviennent difficiles à expliquer au moment de la recette.
| Élément de l’architecture | Responsabilité dans le flux | Donnée attendue | Risque si le rôle est confondu |
|---|---|---|---|
| Système source ERP ou CRM | Créer et mettre à jour les données opérationnelles | Enregistrements locaux et identifiants applicatifs | Un référentiel local est pris à tort pour une référence entreprise |
| Semarchy xDM | Certifier, rapprocher, historiser et distribuer le référentiel | Golden Records, liens de survivance et traçabilité | Des règles métier restent cachées dans les rapports |
| Entrepôt ou Azure Synapse Analytics | Consolider les faits et les historiques analytiques | Transactions, agrégats et dimensions distribuées | Les transactions sont dupliquées dans le hub MDM |
| Power BI | Restituer les indicateurs selon un modèle sémantique contrôlé | Mesures, rapports et filtres documentés | Chaque rapport recalcule un référentiel différent |
Ce tableau reprend le découpage décrit dans l’architecture de référence Microsoft pour Semarchy xDM, consultée le 18 mars 2026. Microsoft y positionne Semarchy comme un hub connecté aux systèmes sources, aux services d’intégration Azure et aux consommateurs analytiques. La documentation ne donne pas un modèle de données prêt à l’emploi : le domaine, les attributs et les règles de certification restent à concevoir.
Avant de déployer un hub, il faut donc vérifier une question moins visible que la technologie choisie : quelle décision métier sera améliorée par un référentiel certifié, et quelle équipe accepte d’en porter les règles ? Sans cette réponse, le MDM accumule des données propres en apparence, mais non arbitrées.
Comment les données deviennent-elles des Golden Records dans Semarchy xDM ?
Le Golden Record est l’enregistrement certifié produit par le processus de consolidation. Il ne s’agit pas de choisir arbitrairement la dernière ligne chargée ni de retenir systématiquement la valeur d’un ERP. Semarchy xDM applique une succession de traitements : ingestion, profilage, standardisation, contrôles de qualité, mise en correspondance, fusion et survivance. Chaque étape doit pouvoir être expliquée à un utilisateur métier qui conteste une valeur.
Les données arrivent par une couche d’intégration des données. La documentation Microsoft mentionne Azure Data Factory, Semarchy xDI ou une solution d’intégration existante. xDM expose aussi des points de terminaison SQL et REST, utilisables pour des flux batch ou des interactions plus immédiates. Le choix du canal ne règle toutefois pas le sujet principal. Un flux REST peut transmettre une donnée erronée avec une latence très faible. Un chargement quotidien peut être parfaitement acceptable si la règle métier porte sur une donnée de référence qui évolue peu.
La qualité des données commence par une règle testable
Les règles de qualité des données doivent être formulées sous une forme contrôlable. « L’adresse doit être propre » ne produit aucune recette. « Le pays est obligatoire pour chaque fournisseur actif et doit appartenir à la table de référence ISO retenue par le domaine » permet un contrôle, un taux d’erreur et une décision de blocage. Semarchy xDM peut appliquer ce type de validation, orienter les anomalies vers un workflow et conserver la correction effectuée par un utilisateur autorisé.
La standardisation intervient avant le rapprochement. Elle peut normaliser une raison sociale, séparer un numéro de voie d’un libellé d’adresse ou transformer des valeurs libres en codes de référence. Le rapprochement compare ensuite les enregistrements susceptibles de désigner la même entité. Les critères peuvent combiner le nom, l’adresse, le numéro d’identification, le pays et un identifiant externe. Une règle basée sur le seul nom produit rapidement de faux positifs. Une règle fondée uniquement sur un identifiant local ne détecte pas les doublons entre applications.
La fusion et la survivance répondent à deux questions différentes. La fusion détermine quels enregistrements sont rattachés à la même entité maître. La survivance choisit quelle valeur est retenue pour chaque attribut certifié. Vous pouvez décider que l’adresse de facturation de l’ERP prévaut sur celle du CRM, tout en donnant priorité au CRM pour le contact commercial. Cette granularité explique pourquoi un MDM ne se limite pas à une table de dédoublonnage.
- Les règles de validation doivent désigner l’attribut contrôlé, la source de référence, la condition d’acceptation et l’action appliquée en cas d’anomalie.
- Les règles de rapprochement doivent être testées sur un échantillon comprenant des doublons connus et des entités volontairement proches mais distinctes.
- Les règles de survivance doivent être validées domaine par domaine, car la source la plus fiable pour une adresse n’est pas nécessairement celle qui porte le bon statut commercial.
- Les corrections manuelles doivent conserver l’auteur, la date, la justification et la possibilité de revenir à l’état précédent si une erreur est détectée.
La documentation d’architecture Microsoft, consultée le 18 mars 2026, décrit un processus de certification combinant enrichissement, validation, rapprochement, fusion et décisions utilisateur. Elle précise également que la traçabilité vers les sources et l’historisation peuvent être conservées. Cette capacité ne dispense pas de définir une durée d’historique, des statuts de publication et un protocole de correction.
Sur un périmètre de 80 000 fiches fournisseurs réparties entre deux applications, un chiffrage de cadrage peut illustrer la charge de validation. Si 2 % des fiches déclenchent une revue manuelle après les règles automatiques, cela représente 1 600 dossiers. Avec une hypothèse de cinq minutes par dossier, le traitement représente environ 133 heures de revue, hors préparation des règles, recette et corrections en source. Ce calcul n’est pas un ratio universel : il dépend du taux de rapprochements ambigus et de la capacité des responsables métier à arbitrer.
Le point de vigilance apparaît toujours au même endroit : la qualité n’est crédible que si les corrections sont renvoyées, ou au moins signalées, aux applications qui ont produit l’erreur. Un Golden Record isolé devient vite un référentiel parallèle.
Quelle architecture data relie Semarchy, Azure, Purview et Power BI ?
L’architecture décrite par Microsoft place Semarchy xDM au centre d’un flux de référence. Les applications émettrices alimentent le hub par Azure Data Factory, Semarchy xDI ou un outil déjà présent dans le système d’information. xDM stocke ses métadonnées et ses hubs de données dans une base SQL managée, puis distribue les données certifiées vers les usages opérationnels et analytiques. Cette distribution peut passer par SQL, REST ou des notifications de changement.
Dans un environnement Azure, la documentation indique que Semarchy xDM peut être exécuté sur Azure Kubernetes Service et s’appuyer sur Azure SQL Database ou PostgreSQL managé pour ses données et métadonnées. Microsoft Entra ID apporte l’authentification et le mécanisme de connexion unique. Azure Key Vault peut stocker les secrets utilisés par les flux ou les connecteurs. Ces composants ne doivent pas être regardés comme une architecture imposée. Ils constituent une référence de déploiement dont il faut vérifier l’adéquation avec vos contraintes d’exploitation.
Le lien avec Purview sert à documenter le flux, pas à certifier le référentiel
Microsoft Purview apporte une couche de visibilité sur les actifs et leurs lignées. L’intégration annoncée avec Semarchy vise la synchronisation des métadonnées xDM afin d’exposer les hubs comme produits de données et de suivre le parcours des référentiels. Cette gouvernance des données est utile quand une équipe finance demande l’origine exacte de la dimension client utilisée dans un tableau de bord de marge.
Purview ne décide pas qu’un fournisseur A et un fournisseur B doivent être fusionnés. Cette décision est portée par le modèle Semarchy, les règles de matching et, pour les cas ambiguës, le workflow métier. Confondre catalogage et certification est une source classique de déception. Le catalogue décrit les actifs et les liens. Le MDM produit et gouverne l’enregistrement certifié.
La connexion à Power BI mérite un traitement séparé. Une dimension distribuée depuis Semarchy peut être chargée dans un modèle sémantique, puis reliée aux faits de vente ou d’achat. Les règles de calcul restent dans le modèle analytique, mais les attributs de référence ne doivent plus être corrigés directement dans un rapport. Lorsqu’un filtre pays s’appuie sur le référentiel certifié, la même nomenclature est utilisée par les rapports qui consomment la dimension publiée.
| Flux | Mécanisme cité par la documentation | Usage décisionnel | Contrôle à prévoir avant mise en production |
|---|---|---|---|
| Sources vers Semarchy xDM | Azure Data Factory, xDI, SQL ou REST | Alimentation des domaines clients, produits ou fournisseurs | Comptage des lignes reçues, rejetées et mises en attente |
| Semarchy xDM vers applications | SQL, REST et notifications de données | Distribution de Golden Records aux outils consommateurs | Comparaison des volumes publiés et effectivement consommés |
| Semarchy xDM vers Purview | Synchronisation des métadonnées | Visibilité sur les hubs et la lignée | Vérification des propriétaires, statuts et descriptions |
| Semarchy xDM vers Power BI | Flux d’intégration ou accès aux données publiées | Dimensions cohérentes dans les modèles sémantiques | Réconciliation des membres, clés et hiérarchies |
La page consacrée aux services cloud d’Informatica permet de comparer un point qui dépasse les fonctions affichées dans une démonstration : le mécanisme d’intégration ne doit pas être choisi sans regarder les flux déjà exploités, les compétences disponibles et la capacité de recette. Remplacer une couche d’intégration stable pour raccorder un MDM ajoute un chantier qui n’est pas toujours justifié.
La question du chiffrement, de la conservation des secrets et de l’accès aux données hors de votre organisation se pose dans cette architecture. Elle relève de votre DPO et de vos responsables sécurité, pas de l’arbitrage fonctionnel entre les règles de survivance. La documentation consultée décrit l’emploi possible de Key Vault et d’Entra ID, sans trancher vos obligations propres.
Une architecture lisible sépare donc l’intégration, la certification, le catalogage et la restitution. Le projet devient difficile à tenir lorsque l’un de ces quatre rôles se retrouve caché dans un flux non documenté.
Quels cas d’usage MDM justifient un déploiement Semarchy ?
Les cas d’usage MDM pertinents ont un point commun : plusieurs systèmes manipulent une même entité, tandis que les équipes ne s’accordent pas sur la version à consommer. Semarchy répond bien à cette situation lorsque le référentiel doit être créé, contrôlé et publié avec une traçabilité visible. Il répond moins bien à un problème limité à une extraction ponctuelle ou à une correction unique de fichier.
Le domaine client est souvent le premier candidat. Une organisation peut disposer d’un CRM pour les prospects, d’un ERP pour la facturation et d’une application de service après-vente pour les incidents. Chacun porte des attributs utiles, mais aucun ne détient seul la vision de référence. Semarchy permet de rapprocher les fiches, de définir une survivance par attribut et de publier un client certifié vers les applications qui en ont besoin.
Les référentiels produit et fournisseur exigent des règles différentes
Le domaine produit pose un problème particulier de hiérarchies. Une référence peut être active dans un catalogue commercial, inactive dans un ERP et encore présente dans des historiques de ventes. Le MDM peut gérer les statuts, les relations de gamme et les attributs utilisés par les dimensions analytiques. Le modèle doit cependant préserver la distinction entre une suppression logique, une fin de commercialisation et une anomalie de chargement. Ces trois situations produisent des effets différents dans les rapports.
Le domaine fournisseur concentre souvent les exigences de contrôle. Les équipes achats veulent une classification fiable, les équipes comptables attendent des coordonnées exactes et les sites locaux peuvent conserver des variantes de nom. Le workflow peut permettre à un utilisateur de proposer une correction, à un responsable de la valider et au hub de garder l’historique de la décision. Ce fonctionnement est particulièrement utile si les règles de fusion ne peuvent pas être entièrement automatisées sans risque de rapprocher deux entités distinctes.
Le référentiel organisationnel constitue un troisième cas solide. Quand les entités juridiques, centres de coûts, sites et directions évoluent dans plusieurs systèmes, les rapports de consolidation peuvent utiliser des hiérarchies incompatibles. Un modèle Semarchy bien conçu porte alors les relations hiérarchiques, les dates de validité et les règles de publication. Le modèle décisionnel consomme une hiérarchie validée au lieu de reconstruire des liens parent-enfant dans chaque jeu de données.
- Délimitez un domaine où les mêmes données sont créées dans au moins deux applications et où l’écart affecte déjà un rapport, un processus ou une décision identifiable.
- Recensez les attributs nécessaires à l’identification, les attributs à certifier et ceux qui doivent rester dans les systèmes sources.
- Écrivez les règles de qualité, de rapprochement et de survivance avant de choisir la forme des écrans de gestion.
- Définissez les responsables des décisions ambiguës et le délai attendu pour chaque étape de workflow.
- Préparez la publication vers les consommateurs avec des contrôles de volume, de clés et de statuts.
Le cas d’usage échoue lorsque l’objectif reste « avoir une vue à 360 degrés » sans liste de décisions, sans propriétaire de données et sans consommateur identifié. Cette formule masque souvent l’absence de périmètre. À l’inverse, un domaine client qui alimente trois rapports stratégiques et deux applications opérationnelles peut justifier un premier lot, à condition que les règles de rapprochement soient validées avant la généralisation.
Semarchy peut aussi servir de backend maître via ses API REST. Ce choix est pertinent pour une application qui doit lire ou modifier un référentiel certifié dans un cadre contrôlé. Il devient risqué si chaque application contourne les workflows pour créer directement ses propres variantes. Une API distribue une règle ; elle ne résout pas l’absence de règle.
Le bon premier périmètre n’est pas celui qui contient le plus d’attributs. C’est celui où la divergence entre sources est connue, mesurable et attribuée à un responsable capable d’arbitrer.
Comment préparer la recette d’un projet Semarchy sans promettre une équivalence fictive ?
La recette d’un MDM ne consiste pas à vérifier que le nombre de lignes en sortie correspond au nombre de lignes en entrée. Après rapprochement, plusieurs fiches sources peuvent former un seul Golden Record. Après séparation d’un faux doublon, le nombre d’entités certifiées peut au contraire augmenter. La comparaison doit donc être organisée par population, statut et règle appliquée, avec des écarts expliqués plutôt qu’effacés.
Le premier livrable utile est un inventaire des flux. Pour chaque source, il faut relever la fréquence, le volume, les attributs alimentés, la clé technique, le propriétaire et le traitement des suppressions. Cette dernière information est régulièrement oubliée. Une source peut désactiver une fiche sans l’effacer, tandis qu’une autre transmet une suppression physique. Sans règle explicite, le hub conserve parfois des enregistrements actifs que les consommateurs ne devraient plus voir.
Un protocole de réconciliation doit être exécuté sur plusieurs populations
La population complète donne une vision des volumes, mais elle ne suffit pas. Il faut isoler les créations récentes, les modifications, les enregistrements rejetés, les fusions automatiques, les fusions manuelles et les cas en attente de validation. Une recette qui ne teste que des fiches propres valide précisément les cas les moins risqués. Or les cas limites déterminent la charge de gestion après mise en production.
Un protocole exploitable peut retenir quatre contrôles. Le premier compare le volume reçu par source au volume intégré, rejeté et placé en anomalie. Le deuxième vérifie que les clés sources permettent de retrouver la lignée de chaque Golden Record. Le troisième teste les règles de survivance sur un échantillon où les sources portent des valeurs contradictoires. Le quatrième compare les dimensions publiées avec celles consommées par le modèle sémantique, notamment les statuts et les hiérarchies.
| Contrôle de recette | Calcul ou vérification | Écart acceptable | Décision si l’écart persiste |
|---|---|---|---|
| Réception des flux | Lignes reçues = intégrées + rejetées + en attente | Zéro ligne non expliquée | Blocage du chargement ou correction du mapping |
| Traçabilité source | Chaque Golden Record testé renvoie à ses identifiants d’origine | Zéro absence de lignée sur l’échantillon critique | Blocage de la publication |
| Survivance | La valeur retenue correspond à la priorité définie par attribut | Écart justifié et documenté seulement | Révision de la règle ou du ranking source |
| Publication analytique | Les clés, statuts et hiérarchies publiés correspondent au modèle attendu | Écart borné par la date de rafraîchissement | Correction du flux ou du modèle sémantique |
Le double run est utile lorsqu’un référentiel existant alimente déjà des tableaux de bord sensibles. Pendant une période définie, l’ancien flux et la distribution issue de Semarchy sont comparés sur les mêmes périmètres. La question n’est pas d’obtenir deux nombres artificiellement identiques. Elle est d’expliquer, par exemple, qu’une baisse de 14 clients actifs résulte de 11 fusions validées et de 3 désactivations selon une règle acceptée. Sans cette ventilation, la direction financière ne peut pas distinguer une amélioration de qualité d’une erreur de chargement.
La charge de recette doit être budgétée séparément de la construction du modèle. Pour un domaine comportant 120 attributs publiés, si 30 attributs sont classés critiques et testés sur 15 cas représentatifs, cela produit 450 contrôles attribut-cas. Avec une hypothèse de quatre minutes de vérification et de consignation par contrôle, la préparation et l’exécution représentent 30 heures, hors recherche des anomalies et arbitrages métiers. Cette estimation est une hypothèse de cadrage explicitement bornée, non un engagement de charge applicable à tous les projets.
La documentation Microsoft consultée le 18 mars 2026 confirme la présence de mécanismes de traçabilité, d’historisation optionnelle et de corrections utilisateur dans le flux Semarchy xDM. Aucun environnement Semarchy n’a été ouvert pour ce dossier ; les éléments techniques exposés s’appuient donc sur cette documentation publique et doivent être vérifiés dans votre version, votre contrat et votre configuration réelle.
Avant d’engager la généralisation à d’autres domaines, sortez un échantillon des enregistrements fusionnés et faites-le valider par les propriétaires métier. C’est sur ces décisions, et non sur une démonstration d’écran, que se joue l’acceptation du référentiel.
Semarchy est-il un ETL ou un outil MDM ?
Semarchy xDM est d’abord une plateforme de master data management. Il peut s’appuyer sur Semarchy xDI, Azure Data Factory ou une autre couche d’intégration pour recevoir et distribuer les données. Le rôle MDM porte sur la certification, le rapprochement, la survivance et la gouvernance du référentiel.
Un Golden Record remplace-t-il les données dans l’ERP et le CRM ?
Non. Le Golden Record consolide une référence certifiée à partir de sources identifiées. Les systèmes opérationnels peuvent rester propriétaires de leurs processus et de leurs données locales. Le projet doit définir quelles corrections sont renvoyées aux sources et lesquelles restent limitées au hub.
Semarchy peut-il alimenter Power BI ?
Oui. Les données certifiées peuvent être distribuées vers les couches analytiques par des mécanismes SQL, REST ou par les flux d’intégration retenus. La recette doit vérifier les clés, statuts et hiérarchies réellement consommés par le modèle sémantique Power BI.
Faut-il déployer tous les domaines de référence en même temps ?
Non. Un premier domaine limité, dont les sources, les responsables et les consommateurs sont connus, réduit le risque. Les domaines client, produit, fournisseur et organisationnel n’ont pas les mêmes règles de rapprochement ni les mêmes workflows.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
