Qui fait quoi ? Data owner, data producer et délégation de l'organe de direction

Sur les 308 commentaires reçus par la BCE lors de la consultation publique de son Guide RDARR, deux questions reviennent avec une insistance particulière : qui, très concrètement, est le « data owner » ? Et l'organe de direction peut-il déléguer ses responsabilités RDARR sans s'en trouver déchargé ? Le document de retour sur la consultation, publié par la BCE en même temps que la version finale du Guide, y répond avec un luxe de détails absent du texte final lui-même.

« Data owner » : une fonction, pas une personne au sommet

Plusieurs fédérations bancaires (EBF, EACB, DZ BANK, entre autres) ont demandé à la BCE de préciser ce qu'elle entend exactement par « data owner » — un terme central du Guide, notamment de sa section 3.3 sur le dispositif de gouvernance des données. La réponse de la BCE est sans ambiguïté : le data owner, tel que compris par le Guide, est la fonction responsable de la saisie de l'information dans le système informatique de la banque, tandis que le data producer est l'employé qui effectue concrètement cette saisie. Le data owner se situe normalement dans la fonction responsable de la capture des données dans les systèmes de front-end — et ne doit pas être positionné trop haut dans l'organisation. (Document de retour de consultation de la BCE, mai 2024 — Tableau 4, commentaires 7 et 9)

Cette précision n'est pas anodine : plusieurs répondants s'inquiétaient qu'un data owner défini de façon trop large finisse par porter une responsabilité intenable sur l'intégralité d'un processus « de bout en bout ». La BCE explique pourquoi elle maintient la responsabilité au plus près de la source : si les corrections de données remontent vers des rôles qui ne capturent pas eux-mêmes l'information dans les systèmes, les erreurs finissent par être corrigées plus loin dans la chaîne plutôt qu'à la source — ce qui impose des interventions manuelles récurrentes, exactement ce que le Guide cherche à éliminer. (Document de retour de consultation de la BCE, mai 2024 — Tableau 4, commentaire 7)

Le cas des données dérivées

Un répondant a soulevé un cas concret : la personne qui calcule un indicateur final comme la valeur en risque (VaR) est-elle responsable de la qualité des données depuis l'enregistrement de la transaction jusqu'au calcul de la VaR ? La BCE répond par la négative. Lorsque des données sont recalculées puis stockées — des « données dérivées » — la fonction responsable du calcul devient propriétaire de cette nouvelle information stockée, mais pas des données sous-jacentes utilisées pour le calcul. Différents data owners, chacun concentré sur une section de la chaîne, ont donc leur propre responsabilité sur les données qu'ils capturent ou génèrent — le tout articulé par des accords de niveau de service entre data owners, et entre data owners et data users, qui définissent les exigences de qualité à chaque étape. (Document de retour de consultation de la BCE, mai 2024 — Tableau 4, commentaire 9)

« Data steward » : un terme finalement écarté

Le projet de Guide employait par endroits, en alternative, le terme de « data steward ». Un répondant (EBF) a suggéré une répartition plus fine : au data owner la définition de la donnée, l'usage qui en est fait et les exigences de qualité par usage ; au data steward l'animation opérationnelle de la qualité des données sur son périmètre. La réponse de la BCE tranche dans l'autre sens : elle n'a pas l'intention de définir davantage de rôles et de responsabilités dans le Guide — en conséquence, le terme « data steward » a été retiré de la version finale. (Document de retour de consultation de la BCE, mai 2024 — Tableau 4, commentaire 14 — amendement apporté)

Le terme « key risk data », jugé source de confusion avec « risk data » tout court, a connu le même sort et a également été supprimé de la version finale. (Document de retour de consultation de la BCE, mai 2024 — Tableau 4, commentaire 3 — amendement apporté)

Qui classe une donnée comme « critique » ?

Autre point disputé : le Guide place le data owner en position centrale pour la classification des données critiques — une approche qu'un répondant (EBF) jugeait peu logique compte tenu de la diversité des usages possibles d'une même donnée dans une grande banque. La BCE clarifie sa position : le Guide parle d'une « contribution » du data owner, ce qui signifie que celui-ci, en tant que principal responsable de la qualité de la donnée, doit être impliqué et informé — sans pour autant exclure un rôle, potentiellement plus large, pour les data users ou l'unité de gouvernance des données. Lors de la classification, les data owners doivent donc s'assurer d'un alignement avec les autres parties prenantes concernées, comme les data users ou les report owners. (Document de retour de consultation de la BCE, mai 2024 — Tableau 4, commentaire 11 — amendement apporté)

L'organe de direction : une responsabilité qui ne se délègue pas entièrement

Le second grand point de friction porte sur la marge de manœuvre de l'organe de direction. Le Guide (section 3.1) demande à l'organe de direction de sélectionner au moins un de ses membres pour porter la responsabilité RDARR. Plusieurs répondants (ESBG, UniCredit Spa) craignaient qu'une responsabilité individuelle assignée à un ou deux membres nuise à la vision d'ensemble et fragmente artificiellement une responsabilité qui devrait rester collective, tout en limitant indûment la capacité des banques à s'organiser comme elles l'entendent.

La BCE maintient sa position, mais l'explique en détail : BCBS 239 est un sujet qui concerne l'ensemble de la banque et implique une responsabilité collective de l'organe de direction. Désigner un ou deux membres spécifiques de l'organe de direction, dans sa fonction de direction, facilite en pratique la mise en œuvre du dispositif et garantit qu'une attention suffisante est portée à la gouvernance des données au niveau de l'organe de direction. Nommer le directeur des risques (CRO) — seul ou avec le directeur financier (CFO) — est présenté comme une solution pragmatique lorsque cette nomination se fait au niveau de l'organe de direction. Lorsqu'il n'est pas possible de nommer un membre de l'organe de direction dans sa fonction de direction, un ou deux cadres dirigeants peuvent être désignés, à condition de disposer d'une ligne de reporting directe et d'un accès à l'organe de direction dans sa fonction de direction. (Document de retour de consultation de la BCE, mai 2024 — Tableau 2, commentaire 4 — amendement apporté)

Le point le plus important, cependant, est celui-ci : quelle que soit la solution retenue, cette délégation ne décharge en aucune façon l'organe de direction de sa responsabilité collective. Conformément aux principes généraux de gouvernance, l'effectivité du dispositif de gouvernance des données interne d'un établissement doit continuer à faire l'objet d'une évaluation périodique et indépendante. (Document de retour de consultation de la BCE, mai 2024 — Tableau 2, commentaire 4)

Et la délégation à des comités ?

Une question voisine portait sur la délégation à des comités du conseil (comité des risques, par exemple) plutôt qu'à des membres individuels. La BCE répond que cette question relève de la gouvernance générale, non spécifique au RDARR, et que la délégation à des comités est en principe considérée comme adéquate : les comités doivent soutenir et conseiller l'organe de direction sur des domaines spécifiques, et faciliter le développement de dispositifs de gouvernance solides. Les établissements doivent simplement veiller à une répartition claire des tâches entre comités spécialisés, avec des lignes de reporting et une allocation des responsabilités bien définies, cohérentes et documentées. Là encore, la BCE rappelle la limite : déléguer à des comités ne libère en aucune façon l'organe de direction, dans sa fonction de surveillance, de son obligation de remplir collectivement ses devoirs et responsabilités. (Document de retour de consultation de la BCE, mai 2024 — Tableau 2, commentaire 5)

Ce que ces clarifications changent, concrètement

Aucune de ces précisions ne modifie l'architecture du Guide telle que décrite dans ses 7 sections. Mais pour un établissement qui construit ou ajuste son dispositif RDARR, elles répondent à des questions très concrètes que le texte final, à lui seul, ne tranche pas explicitement : où s'arrête la responsabilité d'un data owner sur une donnée recalculée en aval ? Peut-on nommer un cadre dirigeant plutôt qu'un membre du conseil ? La délégation à un comité suffit-elle ? Le document de retour de consultation constitue, sur ces points précis, la source la plus autorisée après le Guide lui-même — puisqu'il documente la position de la BCE au moment même où elle a tranché.

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).