1. Contexte

Le client est l’un des plus grands groupes bancaires d’Europe, constitué de deux entités historiques extrêmement puissantes, chacune :

• avec ses propres systèmes réglementaires,
• ses modèles de données,
• sa culture interne,
• sa gouvernance,
• et ses impératifs opérationnels.

Ce groupe gère :

• plusieurs dizaines de millions de clients en Europe,
• des milliers d'agences,
• des systèmes réglementaires à forte criticité,
• une structure interne quasi-fédérale, où chaque entité fonctionne comme une banque complète.

Un projet stratégique de Master Data Management réglementaire est lancé pour :
➡️ unifier les référentiels sensibles des deux entités,
➡️ harmoniser les données critiques liées au risque, à la conformité, et au reporting européen,
➡️ créer une base unique pour les processus prudentiels.

🎯 La séquence politique décisive

1. Nous avons remporté initialement le projet, grâce à note expertise MDM.
2. Mon entreprise est rachetée par un groupe financier.
3. Le client bancaire perçoit alors cette entreprise comme un potentiel compétiteur.

1. Le projet est retiré pour raisons politiques, malgré le choix initial déjà acté.
2. Quelques mois plus tard…
   ➤ le projet part en dérive,
   ➤ risque réglementaire majeur,
   ➤ panique métier,
   ➤ gouvernance inexistante.
3. Le groupe décide de revenir vers moi, me demandant de reprendre entièrement le contrôle pour sauver le programme.

2. Problématiques

1. Deux entités bancaires majeures, historiquement rivales, devant fusionner leurs référentiels réglementaires.
2. Projet MDM lancé en agile → erreur méthodologique fatale pour ce type d’initiative.
3. Tension politique interne très élevée : résistance, défiance, jeux d’influence.
4. Métiers en panique devant la dérive du projet.
5. Exigences réglementaires européennes strictes (risque, conformité, reporting).
6. Flux massifs et modèles de données complexes → impacts transversaux dans toute la banque.

3. Mon rôle

Directeur de Programme MDM & Directeur de Division (Intégrateur majeur)

Conditions imposées avant d’accepter la reprise :
✔ Reprise totale du programme,
✔ Liberté de reconstituer l’équipe,
✔ Autorité directe sur la gouvernance,
✔ Présence personnelle plusieurs jours par semaine au lancement et tout à long du projet..

Responsabilités :

• Direction complète du programme MDM,
• Gouvernance métier et réglementaire,
• Refonte méthodologique,
• Relation avec les directions générales des deux entités,
• Réassurance des équipes métiers,
• Arbitrages structurels entre les deux référentiels réglementaires,
• Pilotage d’une équipe volumineuse et multisites.

4. Actions menées

A. Décisions immédiates et structurantes

• Abandon total du mode agile (impossible pour un MDM réglementaire).
• Nouvelle gouvernance basée sur :
  • jalons réglementaires,
  • livrables structurés,
  • comité de pilotage multi-entités,
  • reporting exécutif strict.

B. Reconstruction de l’équipe

• Audit complet des équipes internes et de l’intégrateur.
• Remplacement des ressources inadéquates.
• Sélection d’experts senior en MDM, réglementation, data governance.
• Mise en place d’un dispositif de delivery robuste et stable.

C. Assainissement technique

• Refonte de la modélisation MDM centralisée.
• Harmonisation des définitions réglementaires entre les deux entités.
• Mise en place des contrôles de qualité de données.
• Assainissement des flux, stabilité des traitements batch et temps réel.

D. Gestion politique et métier

• Recréation d’un climat de confiance par transparence totale.
• Sessions métier dédiées pour réduire l’anxiété et clarifier le plan de sauvetage.
• Arbitrages structurants au plus haut niveau sur les référentiels réglementaires.

E. Stabilisation et pilotage

• Mise sur rails du programme selon une logique de transformation structurée.
• Respect des délais réglementaires retrouvés.
• Interaction rapprochée avec les directions des deux entités jusqu’à la fin du projet.

5. Transformation réalisée

Business / Réglementaire

• Projet sauvé alors qu’il était en situation de dérive critique.
• Unification des référentiels réglementaires des deux entités.
• Conformité retrouvée et sécurisée.
• Restauration complète de la confiance du groupe envers l’intégrateur.

Technique

• Référentiel MDM robuste, pérenne et toujours en production aujourd’hui.
• Qualité de données élevée et contrôlée.
• Harmonisation complète des processus réglementaires critiques.

Organisationnel

• Fin des blocages politiques initiaux.
• Collaboration entre deux entités historiquement séparées.
• Gouvernance stable adoptée durablement.

KPIs

• Réduction significative des anomalies réglementaires.
• Temps de stabilisation ramené à quelques mois.
• Référentiel unifié adopté par les deux entités sans régression.

6. Leçons apprises

Aligné avec tes articles :

1. Data Governance > Méthode Agile pour le MDM

Un projet MDM réglementaire n’est pas un terrain pour l’agilité improvisée.

2. Les projets réglementaires exigent une structure absolue

Conformément à 20 Reasons Why Data Projects Fail, la gouvernance et la méthodologie sont clés.

3. La politique interne est parfois le plus grand risque

L’unification d’entités puissantes nécessite leadership, neutralité et une vision.

4. On ne sauve pas un MDM, on sauve une organisation

Le MDM n’était que l’outil : c’est la structure interne qui devait être réparée.

‍