Une fusion peut-elle casser votre architecture de données ? Ce que dit BCBS 239
Peu d'événements mettent une architecture de données à l'épreuve comme une fusion-acquisition. Du jour au lendemain, deux systèmes, deux taxonomies, deux jeux d'identifiants clients doivent cohabiter — ou fusionner. BCBS 239 ne traite pas ce sujet comme un cas particulier : il l'intègre dès 2013 dans l'exigence même d'architecture de données.
Le Principe 2 de BCBS 239 : une architecture pensée pour résister
Le Principe 2 (Architecture de données et infrastructure IT) exige qu'une banque conçoive, construise et maintienne une architecture de données et une infrastructure IT qui soutiennent pleinement ses capacités d'agrégation des données de risque et ses pratiques de reporting des risques — non seulement en temps normal, mais aussi en période de tensions ou de crise, tout en respectant les autres principes. Le texte va plus loin : les capacités d'agrégation des données de risque et les pratiques de reporting doivent être directement prises en compte dans les processus de planification de la continuité d'activité de la banque, et faire l'objet d'une analyse d'impact sur l'activité. Une banque doit établir des taxonomies et une architecture de données intégrées à l'échelle du groupe bancaire, incluant des informations sur les caractéristiques des données (métadonnées), ainsi que l'usage d'identifiants uniques et/ou de conventions de nommage unifiées pour les entités juridiques, les contreparties, les clients et les comptes. (BCBS 239, Principe 2)
Pas besoin d'un modèle de données unique — la note qui change tout
Un point du texte, glissé en note de bas de page, prend une importance particulière dans un contexte de fusion : les banques n'ont pas nécessairement besoin d'un modèle de données unique — il doit en revanche exister des procédures de rapprochement automatisées et robustes lorsque plusieurs modèles sont utilisés en parallèle. (BCBS 239, Principe 2, note 16) Concrètement : l'entité acquise n'a pas à voir ses systèmes forcés dans le moule du système du groupe acquéreur du jour au lendemain — mais l'absence de rapprochement automatisé et fiable entre les deux, elle, n'est pas une option.
Qui porte la responsabilité, selon le Guide RDARR de 2024
Le Guide de la BCE rend cette exigence beaucoup plus opérationnelle en nommant explicitement les fusions-acquisitions comme un déclencheur de vigilance RDARR. La fonction centrale de gouvernance des données doit notamment participer aux processus de gestion du changement ayant un impact matériel sur le RDARR — au nombre desquels figurent explicitement les fusions ou acquisitions d'entités juridiques importantes, aux côtés de l'externalisation de fonctions à des tiers, du lancement de nouveaux produits ou outils, et des autres initiatives de changement informatique. (Guide BCE, section 3.3)
La fonction de validation indépendante n'est pas en reste : elle doit réaliser des évaluations régulières couvrant toutes les composantes des processus RDARR — infrastructure IT, traçabilité des données, taxonomie des données — y compris la supervision des fusions-acquisitions, au même titre que les fonctions externalisées, les initiatives de changement informatique et les lancements de nouveaux produits. (Guide BCE, section 3.3)
Taxonomies et traçabilité : ce qui doit être réévalué au moment de la fusion
La consultation publique a permis à la BCE de préciser un point resté implicite dans le texte du Guide : en cas de fusion, la manière dont la taxonomie de données est mise en œuvre, le data lineage lui-même, et tout besoin éventuel d'ajuster l'architecture de données dans la nouvelle entité issue de la consolidation doivent être évalués pendant le processus de consolidation, avec les changements nécessaires apportés en conséquence — pas après coup, une fois l'intégration achevée. (Document de retour de consultation de la BCE, mai 2024 — Tableau 5, commentaire 5)
Des responsabilités qui se multiplient, pas qui se diluent
Le Principe 2 exige aussi que les rôles et responsabilités relatifs à la propriété et à la qualité des données de risque soient clairement établis, à la fois pour les fonctions métier et IT. Les propriétaires (fonctions métier et IT), en partenariat avec les gestionnaires de risques, doivent garantir des contrôles adéquats tout au long du cycle de vie de la donnée et pour l'ensemble des aspects de l'infrastructure technologique — le rôle du propriétaire métier incluant de s'assurer que la donnée est correctement saisie par l'unité de front office concernée, tenue à jour et alignée avec les définitions de données. (BCBS 239, Principe 2) Après une fusion, ce n'est pas une exigence qui s'assouplit : c'est une exigence qui s'applique à un nombre de points d'entrée de données mécaniquement plus élevé — d'où l'insistance du Guide RDARR sur une gouvernance et une validation actives dès la phase de consolidation, plutôt qu'une remise en ordre a posteriori.
Ce qu'il faut retenir
BCBS 239 n'a jamais traité les fusions-acquisitions comme un cas exceptionnel dispensant temporairement de ses exigences : l'architecture de données doit résister aux restructurations, au même titre qu'aux périodes de tensions de marché. Le Guide RDARR de 2024 en tire une conséquence organisationnelle claire : la fonction de gouvernance des données et la fonction de validation indépendante doivent toutes deux être impliquées dès qu'une fusion ou une acquisition d'entité importante est engagée — pas seulement après que les systèmes ont déjà commencé à cohabiter.
Cet article est établi à partir de trois documents : les 14 principes BCBS 239 du Comité de Bâle (janvier 2013), le Guide RDARR de la BCE (mai 2024), et le document de retour de la BCE sur la consultation publique du Guide RDARR (mai 2024).