Entrepôt de données et pilotage chez Informatique Banque Populaire

Ludovic FAVARETTE est responsable de la maîtrise d'ouvrage des projets pilotage et décisionnel chez i-BP.

Au service de 17 Banques Populaires régionales, i-BP (informatique-Banque Populaire) est née du rapprochement de 4 centres informatiques créés entre 1968 et 1988

Présente sur 8 sites (Dijon, Lyon, Perpignan, Toulouse, Nantes, Saint-Quentin, Paris et Morangis) l'entreprise i-BP rassemble plus de 1000 collaborateurs dont près de 90% sont ingénieurs et techniciens.

Après une formation en gestion, puis une spécialisation en systèmes d’information, Ludovic rejoint la SGCIB en 2000, puis en 2004 la société informatique-Banque Populaire, où il prend en charge ses premiers projets décisionnels. Chef de projet, puis responsable assistance à la maîtrise d'ouvrage, il est aujourd'hui responsable de la maitrise d’ouvrage de l'ensemble des projets de pilotage et d'aide à la décision conduits par i-BP pour le compte de ses Banques Populaires clientes.

Ludovic FAVARETTE : Je m’appelle Ludovic FAVARETTE, je travaille pour i-BP (Informatique Banque Populaire) et suis responsable de la maîtrise d’ouvrage. Cette présentation sera effectuée avec Rémy VAZILLE, responsable décisionnel côté BPCE. La présentation sera orientée BPCE (Banque Populaire Caisse d’Épargne). Je laisse la parole à Rémy qui présentera l’organisation du groupe et fera une introduction sur le décisionnel BPCE. Je reprendrai ensuite la main pour me concentrer sur ce qui a été développé côté i-BP.

Rémy VAZILLE : Le groupe BPCE est le fruit du rapprochement, qui a eu lieu l’année dernière, entre les Banques Populaires et les Caisses d’Épargne. Il est devenu le deuxième groupe bancaire en France avec environ 37 millions de clients. Il est intéressant de noter l’organisation assez originale du groupe. Celui-ci comporte 3 étages : un premier étage comprenant nos maisons mères (20 Banques Populaires et 17 Caisses d’Épargne), banques de plein droit ; un deuxième étage comprenant un organe central, BPCE SA ; et un dernier étage comprenant les différentes filiales du groupe, dont la plus importante et la plus connue est Natixis, mais également de grandes marques comme le Crédit Foncier, la Banque Palatine et un certain nombre d’établissements en Outre Mer et à l’international.

En termes d’organisation, un groupe décentralisé comme le nôtre suppose plusieurs formes de pratiques de pilotage. Schématiquement, l’organe central pilote la communication financière et les échanges avec le régulateur ainsi qu’un certain nombre d’analyses et de production de chiffres auprès du marché. Dans notre rôle d’animation, des éléments de benchmark, de partage de bonnes pratiques entre les établissements du groupe peuvent également être distribués. Un certain niveau de pilotage stratégique s’applique également pour l’état-major. Dans chaque établissement, chaque maison mère et chaque filiale, il existe un pilotage d’établissement très fort permettant d’avoir une vision de leurs performances.

Quel est le rôle de chacun dans cette organisation un peu complexe ? La BPCE a en charge la partie pilotage qui se trouve au-dessus. i-BP, dont Ludovic est le responsable côté décisionnel, gère le pilotage des 20 Banques Populaires ; GSE Technologies offre le même service pour les 17 Caisses d'Épargne. Comme dans tout système de pilotage, des solutions communautaires sont mises à disposition des utilisateurs. Dans chaque banque et dans chaque Caisse d'Épargne, certaines personnes font également du pilotage dans leurs propres infrastructures.

Quelques principes :
Lorsque le groupe a été créé, la tentation a été assez forte d’organiser l’accès aux données côté organe central avec des entrepôts de données par établissement en faisant un grand data warehouse groupe avec nos référentiels et nos indicateurs côté groupe pour, ensuite, monter un certain nombre de data marts et des solutions de reporting. Nos utilisateurs côté organe central auraient été très heureux, bénéficiant ainsi d’un accès à des données de détail assez massives, aux data marts et aux tableaux de bord. Cela étant, dans nos maisons mères ou nos filiales, l’utilisateur, lorsqu’il analyse ses propres données au niveau établissement, remonte consulter ce que l’on peut lui distribuer. Il s’agit d’une attitude classique. Si l’organe central aurait ainsi eu l’avantage de bénéficier d’un gros data warehouse et de données de terrain, la probabilité, pour l’utilisateur, de retrouver la même chose dans son pilotage d’établissement et son pilotage groupe aurait néanmoins été assez faible. Nous avons donc, un peu contre nature, décidé de fonctionner autrement, en faisant disparaître cette brique et en faisant redescendre nos référentiels et nos indicateurs groupe. Dans ce monde rouge et bleu, je dois mettre du violet pour proposer des choses consolidées, agréger des données dans des couches de data marts sur la base de ces indicateurs groupe. Côté organe central, l’utilisateur a la possibilité de se connecter à ces data marts. En outre, l’accès direct aux entrepôts de données des différents établissements lui est ouvert. L’utilisateur, côté établissement, a ainsi l’avantage de se retrouver avec des référentiels et des informations identiques. Au niveau du groupe, nous avons moins de stockage de données dans la mesure où nous évitons de les répliquer, ce qui s’avère intéressant au niveau de la baisse des coûts.
Nous réduisons très fortement les délais. Les problématiques de réplication de données supposent en effet qu’elles soient copiées, ce qui entraîne des rejets et un délai de plusieurs jours voire de quelques semaines. Nous déclinons tous les indicateurs groupe et référentiels en local, ce qui nous permet d’avoir une seule vérité des données, donc une continuité d’analyse entre le pilotage au niveau groupe et le pilotage au niveau de chaque établissement. A un indicateur correspond toujours un même chiffre, que ce soit au niveau du total du groupe ou au niveau de l’agence bancaire directement. La satisfaction des utilisateurs est évidemment plus importante.

Je passe la main à Ludovic qui parlera de l’expérience Banque Populaire, de la constitution de cet entrepôt de données multi-entités au niveau de la banque.

Ludovic FAVARETTE : Cet entrepôt de données a été développé sur la technologie Teradata. J’essaierai, dans un premier temps, de vous exposer la logique de la Banque Populaire avec 20 clients, 21 désormais. i-BP met à disposition de ceux-ci un data warehouse unique ayant la même structure que le data warehouse dupliqué 21 fois, et contenant des données propres à chacune des banques régionales. Notre système décisionnel porte également toute la partie CRM qui, en termes d’accès aux données, s’appuie sur un accès logique aux données du data warehouse. Chaque banque a la possibilité de développer ce que l’on appelle des « privatifs » (modélisation de données propres). Il s’agit soit de l’accès à de la donnée externe que la banque vient intégrer dans son environnement décisionnel, soit de la remodélisation des données présentes dans le data warehouse visant à faciliter l’accès aux utilisateurs métiers. Les privatifs sont représentés au moyen de modélisations différentes. En effet, par nature, chaque banque fait ce qu’elle souhaite. Il n’y a donc pas de possibilité d’union entre les différents privatifs des banques. L’intérêt fort qui a pu être mis en œuvre grâce à Teradata est la partie fusion de l’ensemble des 21 data warehouse présents dans les couloirs de production des banques, grâce à la création de ce que l’on appelle des « vues logiques », qui permettent d’avoir accès, côté groupe ou i-BP, à une vision consolidée des données de l’ensemble des banques. Nous avons 21 établissements, avec des data warehouse structurés de la même façon. Au niveau du groupe, il est possible d’accéder à une vision consolidée des données des 21 banques. Par exemple, si 21 structures de table contiennent des référentiels prêts pour chacune des banques, l’on retrouvera, au niveau groupe, avec un identifiant banque, les données des 21 banques. Si cela peut paraître assez simple, il s’agit, pour nous, de quelque chose de stratégiquement intéressant. Comme l’a dit Rémy, avant d’avoir cette vision groupe consolidée de façon logique, nous étions obligés de transférer les données et de générer beaucoup d’activité en termes de surveillance, de volume, de délai. Désormais, grâce à la mise en place de ces vues logiques, lorsque les traitements mensuels sont terminés pour l’ensemble des banques, nos collègues côté groupe ont désormais accès aux mêmes données que les banques régionales, en temps réel, comme les banques.

S’agissant de ce dont on dispose dans les couloirs de production de chaque banque, nos données sont, comme sur chaque système décisionnel, récupérées en provenance du SI opérationnel ou de plates formes associées (progiciels). Un ODS, sas de mise en format technique des données est alimenté, contrairement à ce qui est préconisé au niveau des bonnes pratiques côté décisionnel. En d’autres termes, des données provenant de sources hétérogènes sont positionnées dans un format identique au niveau de Teradata.

La première couche à valeur ajoutée est la couche entrepôt, consistant en une sorte d’ODS historisé. Notre structuration de données est encore applicative et non modélisée en étoile. Les données seront historisées sur une granularité fine au niveau contrat, client, opération et sur une profondeur historique minimale de deux ans outre l’année en cours.

La deuxième couche à valeur ajoutée métiers est la couche appelée « vue métiers ». Elle porte mal son nom, car il ne s’agit nullement de vues mais de tables physiques. Les données sont dupliquées. En outre, il s’agit plutôt d’orientation fonctionnelle de la donnée que de métiers. Prenons l’exemple d’un entrepôt comprenant une trentaine de tables avec des données sur des commissions. Lorsqu’un contrôleur de gestion souhaite obtenir une vision sur l’ensemble des commissions perçues pour un client, il a deux possibilités. Soit il passe par l’entrepôt, ce qui l’oblige à développer une requête avec une trentaine de jointures. Soit il va dans la couche vue métiers où un objet vient d’être créé, qui a la granularité client, avec autant de colonnes que de commissions perçues pour ce client. C’est de la préparation de données pure et simple, sur de la granularité fine (client, contrat, opération).
La troisième couche est une couche magasin assez classique data mart, avec de l’agrégation de données, où l’on ne parle plus de client, mais de segment de clientèle, ni de contrat mais de produit.
Sur les deux dernières couches (métiers et magasin), des vues logiques ont été positionnées pour l’accès des utilisateurs au niveau organe central. Cela a également été fait au niveau entrepôt, mais en raison de l’énorme volumétrie, seuls quelques experts de l’équipe de Rémi VAZILLE ont la possibilité d’y accéder.

Côté métiers, le SI décisionnel, i-BP, est un SI multi établissement : 21 clients sont présents sur cette plate-forme. C’est également un SI multi métiers, où l’on retrouve l’ensemble des métiers de la banque, à l’exception de la RH : finance, risques, marketing, partie commerciale (tableaux de suivis commerciaux et animations commerciales), production, crédit, épargne, audit et accès pour des informatiques internes. En termes d’outils, nous utilisons la base de données Teradata ; Genio de OpenText comme ETL. S’agissant des outils de reporting, que nous partageons avec BPCE, nous sommes sur COGNOS suite 4. Enfin, SAS 9.2 est utilisée au niveau des outils d’analyse statistique. Nous disposons également d’un requêteur SQL Teradata, fourni avec la base de données. Il est important de le préciser, car les utilisateurs finaux, notamment ceux qui font de l’analyse ad-hoc, utilisent de manière importante ces requêteurs SQL, avec ensuite, une mise en forme au moyen des outils bureautiques classiques.

Je laisse Rémy, l’un de nos plus gros clients, vous expliquer les utilisations qui peuvent être faites, par les utilisateurs métiers côté BPCE, de ces données mises à disposition à partir de notre système décisionnel appelé informationnel.