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 à