MANAGEMENT & SYSTÈMES D ’ INFORMATION
II faut mettre
en œuvre un
plan de contrôle
permanent
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.
ne laisse guère le choix que de pro
cé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 tran
sactions ou les indicateurs de pilo
tage. Elles sont omniprésentes et
ont des utilisateurs particulièrement
nombreux. Leur production est en
revanche beaucoup plus probléma
tique : 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égi
timement 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 qua
lité: 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 don
née, à des interprétations erronées et
donc à des reportings trompeurs ou à
des mauvaises décisions. La confu
sion 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 informa
tion pour laquelle elle n’était pas pré
vue, au risque d’en polluer les autres
usages. Lorsque BâleIII 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 pro
duits ad hoc qui sont venus brouiller
la classification des produits.
Etpuis, s’agissant de la matière pre
mière de la production bancaire, on
aurait pu s’attendre à trouver dans
les banques le même niveau d’assu
rance et de contrôle qualité sur leurs
produits informationnels que n’en
déploient les industriels fabricants
de produits matériels. On en est sou
vent assez loin : les préoccupations
de qualité des données sont rare
ment très présentes dans les projets
de transformation bancaires, tandis
que la mise en œuvre de contrôles
systématiques permettant d’iden
tifier les non-qualités avant qu’elles
aient bloqué un processus ou cho
qué 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 enre
gistrées dans des bases de données
informatiques chargées d’en faci
liter la manipulation : cette implé
mentation ne peut qu’accentuer les
imprécisions et les redondances des
besoins métier exprimés. Le pas
sage du concept bancaire au modèle
applicatif peut même rajouter des
causes spécifiques de non-qualité.
Les contraintes techniques inévi
tables (optimisation des traitements
et des performances) tendent en effet
à induire une multiplication des ins
tances de la même donnée dans le
SI sans que les moyens soient pris
pour garantir, sinon une stricte éga
lité de leurs valeurs à tout moment,
du moins que les différents usages
manipuleront bien des valeurs cohé
Revue Banque N" 775 SEPTEMBRE 20 14
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 for
melle 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éfi
nition ainsi que de formuler les exi
gences 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 recense
ment 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 don
né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émenta
tion 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 applica
tive 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 cou
rante des données (création, mise à