Les tableurs sont-ils condamnés par le RDARR ? Ce que dit vraiment le Guide

Excel a mauvaise réputation dans la littérature réglementaire — associé aux erreurs de calcul, aux macros non documentées, aux fichiers qui circulent par email. L'idée reçue veut que BCBS 239 et le Guide RDARR de la BCE cherchent, à terme, à faire disparaître les tableurs des processus de reporting des risques. La réalité, telle que la consultation publique la précise, est plus nuancée.

Ce que dit BCBS 239 dès 2013

Le Principe 3 (Exactitude et intégrité) ne bannit pas les tableurs — il les encadre. Lorsqu'une banque s'appuie sur des processus manuels et des applications de bureau (tableurs, bases de données) et dispose d'unités de risque spécifiques qui utilisent ces applications pour développer leurs propres outils, elle doit mettre en place des mesures d'atténuation effectives — par exemple des politiques et procédures d'informatique utilisateur final — ainsi que d'autres contrôles effectifs appliqués de façon cohérente dans l'ensemble des processus de la banque. (BCBS 239, Principe 3(b))

« Full integration » : un terme qui a demandé clarification

Le Guide RDARR de 2024 va plus loin en exigeant la pleine intégration de l'informatique utilisateur final (EUC) ou des applications développées par les utilisateurs finaux (EUDA) — y compris un inventaire de ces applications — dans les politiques et processus de gestion de la qualité des données. (Guide BCE, section 3.5) L'EBF et l'ESBG ont demandé ce que « pleine intégration » signifie concrètement. La réponse de la BCE clarifie l'intention : il s'agit d'appliquer les mêmes standards et attentes de qualité des données (et les contrôles associés) d'un point de vue fonctionnel et logique — pas de migrer techniquement chaque tableur dans un système central. (Document de retour de consultation de la BCE, mai 2024 — Tableau 5, commentaire 22)

Faut-il traiter tous les tableurs de la même façon ? Non

Une inquiétude légitime portait sur l'ampleur du chantier : une pleine intégration signifie-t-elle des contrôles identiques pour chaque tableur et chaque interface de données ? La BCE répond par la négative — il faut s'attendre à ce que les contrôles de qualité se concentrent sur les points les plus exposés au risque d'être affectés, directement ou indirectement (effets de bord), sur la base d'une analyse technique et fonctionnelle et de l'expérience acquise. Autrement dit : une approche fondée sur le risque, pas un contrôle uniforme. (Document de retour de consultation de la BCE, mai 2024 — Tableau 5, commentaire 25)

Un tableur sans impact peut-il être exclu du périmètre ?

Le German Banking Industry Committee a demandé si un groupe pouvait exclure les applications EUC sans impact significatif sur la collecte, le traitement ou la transformation des données dans les processus de reporting liés à BCBS 239 — rappelant que ces applications ne sont pas par nature liées à la qualité des données, mais souvent utilisées pour faciliter ou raccourcir des processus via l'automatisation. La réponse de la BCE pose un critère clair : dès lors qu'une application EUC modifie une donnée ou une métadonnée (ou permet une modification manuelle) qui alimente ensuite d'autres processus de reporting ou de gestion des risques compris dans le périmètre défini par l'établissement (au sens de la section 3.2), la qualité des données peut être affectée — et cette application doit donc être soumise à des contrôles de qualité et à des rapprochements. L'exclusion n'est donc pas automatique : elle dépend de l'impact réel en aval, pas de la nature de l'outil. (Document de retour de consultation de la BCE, mai 2024 — Tableau 5, commentaire 25)

La BCE n'exige pas la disparition des tableurs

Le point le plus rassurant de tout cet échange vient d'un dialogue avec Raiffeisen Bank International AG. Ce répondant considère l'EUC comme un outil important pour favoriser l'innovation au sein de la banque, avant la mise en œuvre de solutions pérennes, et a demandé à la BCE de confirmer qu'une réduction de l'EUC ne serait pas spécifiquement imposée tant que son cycle de vie est correctement maîtrisé. La réponse de la BCE est nette : dans le contexte du RDARR, une réduction du nombre d'applications EUC n'est pas attendue, selon le texte du Guide. Même pour des données de risque, modèles, outils ou technologies innovants utilisés dans des projets de prototypage ou de recherche et développement, la qualité des données reste tout aussi pertinente — et donc soumise aux mêmes attentes. (Document de retour de consultation de la BCE, mai 2024 — Tableau 5, commentaire 24)

Le terme « EUC » lui-même vient de BCBS 239

L'AFME a jugé la définition de « end-user computing » trop large et a demandé qu'elle soit précisée et son périmètre limité. La BCE n'a pas cédé sur ce point : elle rappelle que le terme « end user computing » est lui-même mentionné dans le Principe 3 de BCBS 239, à propos de l'exemple des applications de bureau. Pas une invention de 2024, donc, mais la reprise d'une notion déjà présente dans le texte fondateur. (Document de retour de consultation de la BCE, mai 2024 — Tableau 5, commentaire 17)

Ce qu'il faut retenir

Ni BCBS 239 ni le Guide RDARR ne mènent une guerre contre Excel. Ce qu'ils ciblent, c'est le tableur non documenté, non contrôlé, dont personne ne sait s'il modifie une donnée critique avant qu'elle n'atteigne un rapport de risque. Un tableur inventorié, dont l'impact réel est évalué, et dont les contrôles sont proportionnés à ce risque réel plutôt qu'uniformes, reste parfaitement acceptable — la BCE va jusqu'à le reconnaître explicitement comme un outil légitime d'innovation, tant que son cycle de vie est maîtrisé.

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