Consultant Informatica MDM : vérifier le réglage du match et du trust

Tout l'entretien Informatica MDM tourne autour d'un objet : la fiche de référence unique, le golden record, construite à partir des clients, fournisseurs ou articles envoyés par plusieurs applications. Le consultant charge ces sources dans le hub, règle la façon dont les doublons sont repérés et fusionnés, décide quelle source fait foi pour chaque attribut et diffuse le résultat vers l'ERP et le CRM. Selon le client, il travaille sur la version installée (Multidomain MDM) ou sur la version SaaS de la plateforme cloud IDMC.

Le mot MDM sur un CV recouvre des réalités très différentes. Un data steward a validé des fusions à l'écran. Un développeur ETL a alimenté les tables d'atterrissage sans toucher au paramétrage du hub. Un vrai consultant Informatica MDM sait pourquoi deux clients distincts ont été fusionnés hier soir, comment le défaire, et quelle règle modifier pour que cela ne recommence pas.

Multidomain MDM ou IDMC : la version, comme le domaine concerné, se règle avec le manager avant l'entretien. Un consultant fort sur les clients peut découvrir les articles, où les règles de rapprochement n'ont rien à voir.

Le hub Informatica MDM, pièce par pièce

Multidomain MDM (le hub)

La version installée chez le client, sur une base Oracle, SQL Server ou PostgreSQL. Le hub stocke les données de référence dans des base objects, garde la trace de chaque source dans des tables de références croisées (XREF) et conserve l'historique des fusions. Le paramétrage se fait dans la Hub Console. C'est encore la version la plus citée dans les missions de maintenance.

Stage, load et tables d'atterrissage

Les données arrivent dans des landing tables, passent par un job de stage qui nettoie, standardise et détecte ce qui a changé, puis par un job de load qui met à jour les base objects. Les lignes refusées partent dans des tables de rejet. Un consultant confirmé sait lire ces rejets et l'ordre de chargement entre tables parentes et filles.

Match et merge

La partie la plus délicate du paramétrage. Le hub calcule des clés de recherche floues sur le nom ou l'adresse, compare les fiches candidates avec des règles exactes ou approximatives, puis fusionne automatiquement ou propose la fusion à un data steward. Des règles trop larges collent des clients différents, des règles trop strictes laissent passer les doublons. Faites raconter un réglage concret.

Trust et règles de validation

Le trust dit quelle source l'emporte pour chaque colonne, avec un niveau qui peut baisser avec l'âge de la donnée. Les règles de validation abaissent ce niveau quand une valeur est douteuse, par exemple un code postal mal formé. C'est ce mécanisme qui compose le golden record, attribut par attribut.

Interfaces de stewardship (IDD, Customer 360, Provisioning Tool)

Les data stewards travaillent dans une application web. L'ancienne interface IDD cède la place aux applications fondées sur des business entities, configurées dans le Provisioning Tool, comme Customer 360. Les circuits d'approbation s'appuient sur le moteur de workflow ActiveVOS. Vérifiez que la personne a configuré ces écrans, pas seulement utilisé.

API et diffusion (SIF, Business Entity Services, message triggers)

Les applications lisent et écrivent dans le hub par des API SOAP ou REST. Les message triggers publient un message dans une file JMS à chaque création ou fusion, ce qui permet de prévenir l'ERP ou le CRM sans extraction complète. La gestion des identifiants entre systèmes est le sujet à creuser.

Hierarchy Manager

Le module qui gère les liens entre fiches : une filiale et sa maison mère, un client et son foyer, un article et sa gamme. Les relations sont elles-mêmes des objets avec leurs dates de validité. On le croise surtout sur les référentiels clients et tiers des grands comptes.

MDM SaaS sur IDMC (Customer 360, Product 360, Supplier 360)

La version cloud, sur la plateforme IDMC d'Informatica, qui appartient désormais à Salesforce. Le modèle, le match et les applications se configurent dans une console web, l'alimentation passe par Cloud Data Integration et le nettoyage par Cloud Data Quality. Les projets de passage de la version installée vers le SaaS se multiplient dans les offres.

En ESN ou en cabinet, le consultant Informatica MDM passe souvent d'un hub existant à reprendre à un projet de construction, et chaque client a son propre domaine : clients en banque et assurance, fournisseurs dans l'industrie, articles dans la distribution. Chez un client final, on lui demande de tenir le run, de régler les fusions qui posent problème et de faire évoluer le modèle sans casser les applications abonnées. Les missions de migration vers Customer 360 SaaS ou Supplier 360 SaaS demandent de connaître les deux versions. Les certifications Informatica valident la connaissance du produit, pas la qualité d'un réglage de match sur des données réelles.

Les savoir-faire à contrôler chez un consultant Informatica MDM

• Modélisation du hub et des base objects
• Chargement stage et load
• Règles de match et de merge
• Trust, validation et nettoyage
• Applications de stewardship et workflows
• API, diffusion et passage au SaaS

Match, trust, chargement : cinq questions pour un consultant Informatica MDM

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Après la mise en production d'une nouvelle règle de match, des clients qui n'ont rien à voir ont été fusionnés automatiquement. Que faites-vous ?

   Une bonne réponseArrêter l'automerge sur cette règle, la basculer en fusion manuelle ou la désactiver, puis défaire les fusions erronées (unmerge) en partant des XREF. Ensuite l'analyse : colonnes comparées trop pauvres (un nom sans date de naissance ni adresse), clé floue trop large, niveau de recherche trop exhaustif, valeurs vides ou génériques (« INCONNU ») qui se ressemblent. La règle corrigée est testée sur un échantillon et validée par le métier avant de revenir en production.

   Signal d'alerte« Je baisse un peu le seuil et je relance » sans défaire les fusions, ou aucune idée qu'une fusion peut être annulée.

2. Question 2 · confirmé

   L'ERP et le CRM envoient deux adresses différentes pour le même client. Comment le hub décide-t-il laquelle va dans le golden record ?

   Une bonne réponsePar le trust configuré sur la colonne : chaque source a un niveau maximal et minimal, avec une décroissance selon l'âge de la valeur, et la valeur la plus fiable au moment du calcul l'emporte. Des règles de validation abaissent le trust d'une valeur douteuse (code postal invalide, adresse non normalisée). Les valeurs des deux sources restent dans les XREF. La personne précise que, sans trust sur une colonne, c'est la mise à jour la plus récente qui gagne.

   Signal d'alerte« La dernière source chargée gagne » comme seule réponse, ou une correction à la main de chaque cas par un steward.

3. Question 3 · confirmé

   Le chargement de cette nuit a rejeté 15 000 lignes sur un base object. Où cherchez-vous, et dans quel ordre ?

   Une bonne réponseD'abord les tables de rejet du stage et du load, avec le message d'erreur de chaque ligne, et le détail du job dans le Batch Viewer. Les causes courantes : une colonne obligatoire vide, une clé source en double dans le même lot, une référence vers une fiche parente pas encore chargée parce que l'ordre des jobs est mauvais, une fonction de nettoyage en erreur. La personne corrige la cause, puis relance le stage et le load sur les lignes concernées.

   Signal d'alerte« Je relance le job » sans regarder les rejets, ou une correction directe par SQL dans les tables du base object.

4. Question 4 · confirmé

   Les acheteurs doivent créer des fournisseurs dans le hub, avec une validation par la comptabilité avant diffusion. Comment le configurez-vous ?

   Une bonne réponseUne business entity Fournisseur avec ses objets enfants, un écran de saisie configuré dans le Provisioning Tool, et un workflow ActiveVOS qui crée une tâche de revue pour la comptabilité. La fiche reste en attente (état pending) et n'est diffusée qu'après approbation. Les droits sont donnés par rôle : les acheteurs créent, la comptabilité approuve. La personne vérifie que la recherche de doublons se fait avant la création.

   Signal d'alerteUne saisie dans l'ERP puis un chargement nocturne, sans contrôle, ou des fiches créées directement en SQL dans le hub.

5. Question 5 · senior

   Le client veut passer de Multidomain MDM installé à Customer 360 SaaS. Qu'est-ce qui ne se reprend pas tel quel ?

   Une bonne réponseLe modèle doit être redéfini en business entities dans la console SaaS, les règles de match et de trust sont reparamétrées et réglées à nouveau sur des données réelles, l'alimentation passe par Cloud Data Integration au lieu des landing tables, les développements Java spécifiques (user exits) et les appels SIF sont réécrits, les écrans personnalisés sont refaits. La personne prévoit la reprise des XREF et de l'historique de fusion, une période en parallèle et une comparaison des résultats de match entre les deux systèmes.

   Signal d'alerte« On exporte les tables et on les recharge » sans parler du match ni des applications abonnées.

Recruter un consultant Informatica MDM : vos questions

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.