Pour une banque, la qualité de ses données est essentielle. La satisfaction de ses clients en dépend, qui attendent légitimement un service à zéro défaut. Elle conditionne l’efficacité de ses processus dont l’automatisation (Straight Through Processing) est mise en défaut par des données manquantes ou erronées, multipliant les besoins de coûteux ajustements manuels et autres traitements d’exception. Elle est au cœur de la pertinence de son pilotage qui doit pouvoir déceler au plus tôt les inflexions de tendances sans être leurré par des variations sans fondement. Enfin, sans elle, l’image de la banque est en risque auprès des analystes et des régulateurs qui exigent une communication de plus en plus détaillée et scrutent les moindres incohérences dans les chiffres publiés.
Le recours à des algorithmes sophistiqués de modélisation des risques détermine en outre complètement la consommation de ressources rares (fonds propres, actifs liquides) des banques et donc leur potentiel de rentabilité et de croissance. Or la pertinence de ces algorithmes est conditionnée par l’existence et la qualité des données qu’ils utilisent comme inputs. Le principe de prudence oblige d’ailleurs les banques à dégrader leur méthode d’évaluation des risques, en cas de défaut sur les données, en recourant à des méthodes plus grossières qui induisent un surcoût en capital ou en actifs liquides. Ce phénomène confère de fait un prix à la qualité des données : il ne s’agit visiblement pas d’une simple commodité !
Entre exigences réglementaires et opportunités du Big Data
L’actualité vient encore renforcer cette importance. Côté superviseurs, le Comité de Bâle a pris la peine de formuler au début de l’année dernière les principes de bonne gestion des données qui nourrissent les reportings de pilotage des
La BCE, de son côté, a inauguré la phase préparatoire de sa future responsabilité de superviseur unique des grandes banques de la zone euro en lançant une Asset Quality Review qui s’est attachée à qualifier dans le détail la qualité des données enregistrées par les banques pour décrire leurs engagements et leurs sûretés.
Mais l’actualité, c’est aussi la vague de transformation numérique qui met soudain en lumière le fantastique potentiel de valeur renfermé par les gisements de données dont les banques ne sont pas les dépositaires les moins dotés. La course aux usages innovants de type Big Data les conduit à élargir sans cesse le spectre des données manipulées, quitte à gommer les frontières naguère infranchissables entre données structurées et données non structurées ou entre données internes et données externes, et à accroître aussi ainsi les enjeux de qualité associés.
Des dérives nuisibles à la qualité des données
Or la qualité des données n’est pas naturelle dans une grande organisation, moins encore dans une grande banque. De multiples phénomènes s’y combinent pour conduire à une qualité médiocre des données, sans que personne ne s’en sente légitimement responsable.
Les données de qualité sont celles qui sont bien définies, utilisées fréquemment et que leurs utilisateurs ont la capacité et le loisir de corriger sans délai. Malheureusement, c’est un cas assez minoritaire. Pour de nombreuses données, la chaîne est longue entre les producteurs et les utilisateurs. Les uns et les autres sont en outre souvent multiples pour une même donnée et ne travaillent pas directement ensemble, intégrés à des processus disjoints, de vente, de production, de marketing, de pilotage ou encore de reporting… voire à des entités légales distinctes.
Les données de reporting ne sont fréquemment contrôlées qu’une fois par trimestre, à l’occasion de l’arrêté des comptes. Bien souvent, la contrainte des délais de publication ne laisse guère le choix que de procéder à des corrections à chaud, en aval des chaînes de production sans pouvoir diagnostiquer, ni a fortiori corriger à la source, les causes des anomalies relevées.
Les données de référence constituent un enjeu emblématique de qualité. Elles décrivent des réalités internes (organisation, nomenclatures…) ou externes (tiers, titres…) préexistantes aux activités bancaires proprement dites et servent à référencer les transactions ou les indicateurs de pilotage. Elles sont omniprésentes et ont des utilisateurs particulièrement nombreux. Leur production est en revanche beaucoup plus problématique : il n’est pas rare que personne ne s’en sente responsable ou qu’elles fassent l’objet de plusieurs gestions indépendantes difficiles à réconcilier. Le cas des tierces personnes morales est un classique du genre : chaque enseigne ou ligne métier gère légitimement ses clients corporate, mais la mesure des risques portés par le groupe face à chaque contrepartie requiert une consolidation a posteriori qui peut se révéler très complexe, même avec des outils de Master Data Management. Les enjeux du pilotage de la liquidité ont récemment révélé le même type de situation pour la gestion des titres.
Autre cas de dérive nuisible à la qualité : le foisonnement des usages « parasites » des données qui ont le mérite d’exister. La recherche de la facilité – qu’on ne saurait blâmer – peut conduire à des malentendus graves sur la signification d’une donnée, à des interprétations erronées et donc à des reportings trompeurs ou à des mauvaises décisions. La confusion entre les douteux comptables et les défauts bâlois en est un exemple. Pire, une forme de parasitage peut même venir corrompre le contenu même de la donnée, la dévoyer pour lui faire porter, à moindre coût (du moins à court terme), une information pour laquelle elle n’était pas prévue, au risque d’en polluer les autres usages. Lorsque Bâle III a imposé un reporting sur les différents appels de marge associés aux transactions passés avec une contrepartie ou par une chambre de compensation, il a ainsi été tentant de collecter ces informations comme des pseudo-transactions affublées de codes produits ad hoc qui sont venus brouiller la classification des produits.
Et puis, s’agissant de la matière première de la production bancaire, on aurait pu s’attendre à trouver dans les banques le même niveau d’assurance et de contrôle qualité sur leurs produits informationnels que n’en déploient les industriels fabricants de produits matériels. On en est souvent assez loin : les préoccupations de qualité des données sont rarement très présentes dans les projets de transformation bancaires, tandis que la mise en œuvre de contrôles systématiques permettant d’identifier les non-qualités avant qu’elles aient bloqué un processus ou choqué un utilisateur, voire un client, est encore exceptionnelle.
Des contraintes techniques inévitables
Les données bancaires sont enfin pour l’essentiel modélisées et enregistrées dans des bases de données informatiques chargées d’en faciliter la manipulation : cette implémentation ne peut qu’accentuer les imprécisions et les redondances des besoins métier exprimés. Le passage du concept bancaire au modèle applicatif peut même rajouter des causes spécifiques de non-qualité. Les contraintes techniques inévitables (optimisation des traitements et des performances) tendent en effet à induire une multiplication des instances de la même donnée dans le SI sans que les moyens soient pris pour garantir, sinon une stricte égalité de leurs valeurs à tout moment, du moins que les différents usages manipuleront bien des valeurs cohérentes. Le risque est grand dans cette situation que les utilisateurs, voire même les informaticiens, ne sachent plus quelle instance de la donnée doit faire foi.
La nécessité d’une gouvernance des données
Seul un système de gouvernance formelle des données et un réseau actif de professionnels de la qualité des données sont de nature à apporter des solutions à ces types de difficultés.
Gouvernance parce que la première clé vers la maîtrise de la qualité des données est une attribution claire des responsabilités. Chaque donnée doit avoir un propriétaire, responsable d’établir et de communiquer sa définition ainsi que de formuler les exigences de qualité et les conditions d’utilisation associées (au nom des utilisateurs). Mais, compte tenu du nombre de données concernées (je n’ai connaissance d’aucun recensement en la matière mais l’ordre de grandeur du nombre d’articles dans le dictionnaire de données virtuel d’une grande banque est sans doute à 5 chiffres), un niveau intermédiaire de pilotage par grand domaine de données semble incontournable. C’est à ce niveau que seront modélisés la structuration des données en objets et le réseau de relations entre les objets. C’est aussi à ce niveau que pourra être exercé un contrôle de cohérence et mis en œuvre un effort de simplification. C’est enfin sur cette base que pourra être mise sous contrôle l’implémentation dans les applications en veillant à la traçabilité depuis les concepts jusqu’aux enregistrements physiques et en explicitant pour chaque donnée sa « source d’or », l’instance applicative unique qui fait foi, ainsi que les exigences d’asservissement de ses éventuelles copies.
Garantir la qualité des données
Il faut ensuite que la gestion courante des données (création, mise à jour, suppression…) soit entourée, lorsque le besoin en est exprimé, de toutes les précautions de nature à en garantir la qualité. Or la plupart des données bancaires sont de fait gérées à travers des processus bancaires (gestion des contrats, gestion de la relation client, production d’indicateurs de pilotage ou de reportings…) et confiés à des banquiers qui ne sont pas des spécialistes de l’assurance qualité. Il est donc important que les dispositifs de production de données (équipes, organisations, processus, systèmes) jugés critiques en termes de qualité soient dotés de spécialistes qui sauront mettre en œuvre les leviers efficaces : formation des utilisateurs sur les définitions et exigences, sur l’utilisation de sources externes, workflows de validation, enrichissement des contrôles interactifs de saisie… Ces spécialistes d’assurance qualité seront notamment des contributeurs obligés aux décisions de lancement de nouveaux produits ou plus généralement à toutes les revues de projets transformations ayant un impact sur les données à gérer ou sur leurs usages.
Troisième élément requis pour maîtriser la qualité des données : il faut se doter d’instruments de mesure de la qualité des données qui permettent d’objectiver le degré de satisfaction des exigences et de déceler le plus tôt possible les non-qualités, avant qu’elles aient créé un incident dans un traitement ou fait réagir un utilisateur interne ou externe. Cela signifie qu’il faut définir et mettre en œuvre un plan de contrôle permanent, automatisé et/ou humain, pour chaque donnée dont la qualité est jugée suffisamment sensible pour ne pas être abandonnée à un simple traitement réactif en cas d’incident ou de réclamation.
Cette objectivation est essentielle pour mettre en œuvre un véritable pilotage de la qualité des données qui focalise les moyens sur la résolution des anomalies vraiment pénalisantes sans tomber dans le piège de la sur-qualité ni se laisser ballotter par les aléas du dialogue de sourds entre utilisateurs et producteurs des données.
Une nouvelle dimension transverse dans le pilotage de la banque
Pris un à un, les éléments de réponse au défi de la qualité des données bancaires ne sont donc pas bien sorciers, mais leur mise en œuvre simultanée requiert une transformation importante dans les grandes banques. Les données sont en effet irréductiblement transverses à l’organisation : transverses aux structures juridiques et aux lignes métier bien sûr, mais transverses aussi aux filières de pilotage (finance, risques, conformité…), transverses enfin aux approches processus et, transverses aux SI, même les mieux urbanisés. Sans dispositif ni gouvernance ad hoc, cette transversalité soulève de véritables difficultés pour faire émerger des définitions partagées, pour mutualiser des dispositifs de production de données de référence ou pour définir des indicateurs de qualité globaux. Il ne s’agit de rien de moins que d’introduire une nouvelle dimension transverse dans le pilotage de la banque. Cette transformation ne peut être engagée avec quelques chances de succès sans être portée par un champion fortement soutenu par la direction générale. C’est le rôle de celui que les Anglo-Saxons identifient sous le nom de Chief Data Officer et dont les banques françaises commencent également à se doter.
