Qualité des données : ce qu'attendent le Comité de Bâle et la BCE
« La banque doit assurer la qualité de ses données de risque » : formulé ainsi, l'objectif semble presque trop général pour être vérifiable. Mais BCBS 239, puis le Guide RDARR de la BCE, ne s'arrêtent pas à cette généralité — ils décrivent des mécanismes précis, contrôlables un par un.
Principe 3 : exactitude et intégrité
Le Comité de Bâle exige qu'une banque puisse générer des données de risque exactes et fiables, répondant aux exigences de précision aussi bien en temps normal qu'en période de tensions, avec une agrégation largement automatisée pour minimiser le risque d'erreurs. Concrètement, le texte fixe plusieurs exigences minimales : des contrôles sur les données de risque aussi robustes que ceux appliqués aux données comptables ; lorsque des tableurs ou bases de données bureautiques sont utilisés par des équipes de risque pour développer leurs propres outils, des mesures d'atténuation effectives doivent être en place — notamment des politiques d'informatique utilisateur final ; les données de risque doivent être rapprochées des sources de la banque, y compris les données comptables lorsque c'est pertinent ; et une banque devrait tendre vers une source unique et faisant autorité pour les données de risque, pour chaque type de risque. (BCBS 239, Principe 3)
Autre exigence structurante : disposer d'un « dictionnaire » des concepts utilisés, afin que la donnée soit définie de manière cohérente dans toute l'organisation. Les superviseurs attendent des banques qu'elles documentent et expliquent l'ensemble de leurs processus d'agrégation, qu'ils soient automatisés ou manuels — avec, pour chaque ajustement manuel, une explication de son bien-fondé, une description de sa criticité pour l'exactitude de l'agrégation, et des actions proposées pour en réduire l'impact. (BCBS 239, Principe 3)
Principe 4 : exhaustivité
Une banque doit pouvoir capturer et agréger toutes les données de risque matérielles à l'échelle du groupe, y compris les expositions hors bilan, disponibles par ligne d'activité, entité juridique, type d'actif, secteur, région et autres regroupements pertinents. Là où des données ne seraient pas entièrement complètes, l'impact ne doit pas être critique pour la capacité de la banque à gérer ses risques — et les superviseurs attendent que toute exception soit identifiée et expliquée. (BCBS 239, Principe 4)
L'architecture de données intégrée selon la BCE
Le Guide RDARR de 2024 rend ces deux principes opérationnels. Il exige une architecture de données intégrée, documentée au niveau du groupe, incluant des taxonomies de données — en particulier un dictionnaire des principales définitions métier et un référentiel de métadonnées — couvrant les entités juridiques importantes, les lignes d'activité, les risques matériels et leurs rapports associés, les indicateurs clés de risque et leurs éléments de données critiques, ainsi que les modèles inclus dans le périmètre. La gestion de ces taxonomies doit inclure : des définitions de données uniformes avec une propriété clairement établie ; des règles de validation autorisant des valeurs ou plages de valeurs spécifiques ; et une traçabilité (data lineage) complète et à jour, au niveau de chaque attribut de donnée, depuis la capture jusqu'à l'extraction, la transformation et le chargement. (Guide BCE, section 3.4)
Le dispositif de qualité à l'échelle du groupe
La section du Guide consacrée à la gestion de la qualité des données à l'échelle du groupe liste six éléments attendus. D'abord, des contrôles de qualité des données couvrant a minima l'exactitude/intégrité, l'exhaustivité et l'actualité, depuis les systèmes du front office jusqu'à la couche de reporting, automatisés autant que possible, complétés par un rapprochement périodique avec les sources de la banque. Ensuite, des indicateurs de qualité de données couvrant ces mêmes dimensions, incluant des seuils de tolérance et des processus de correction documentés en cas de dépassement, communiqués périodiquement à l'organe de direction avec une analyse de leur impact sur la mesure des risques. (Guide BCE, section 3.5)
Troisième élément : un registre à jour et complet des problèmes et limites de qualité des données, comprenant une évaluation de leur gravité, une analyse de cause racine, une analyse d'impact quantitatif sur les zones de risque et d'activité concernées, des processus et responsabilités clairement définis pour la remédiation et l'escalade, des délais de remédiation, et une date de remédiation effective dûment justifiée. Quatrième élément : l'intégration complète de l'informatique utilisateur final dans les politiques et processus de gestion de la qualité des données, avec une vue d'ensemble de ces applications. Cinquième élément : des dispositifs encadrant tout ajustement manuel — principe des quatre yeux, documentation rigoureuse, traçabilité des modifications et validations — jusqu'à ce que les étapes concernées soient intégrées dans un environnement informatique contrôlé et audité. Enfin, sixième élément : une prise en compte adéquate des risques de qualité des données dans l'ICAAP et l'ILAAP, ces problèmes pouvant conduire à une sous-estimation des risques et devant être compensés par une marge de conservatisme supplémentaire. (Guide BCE, section 3.5)
Deux textes, un même fil conducteur
Onze ans séparent les deux documents, mais le fil conducteur est le même : une donnée de risque n'est utile que si son origine, sa transformation et ses limites sont traçables et documentées. Ce que BCBS 239 formulait en 2013 comme un principe général — source unique faisant autorité, dictionnaire de données, documentation des ajustements manuels —, la BCE le décline en 2024 en une check-list opérationnelle : taxonomies, registre des anomalies, seuils de tolérance chiffrés, intégration des tableurs aux dispositifs de contrôle.
Cet article est établi exclusivement à partir de deux documents : les 14 principes BCBS 239 du Comité de Bâle (janvier 2013) et le Guide RDARR de la BCE (mai 2024), tous deux accessibles sur la page Ressources.