La conception du système décisionnel de pilotage

Une fois le choix de la solution logicielle arrêtée, nous passons à la phase suivante consacrée à la conception proprement dite du système d’informations stratégiques. Dans cette étape, il nous faudra analyser d’abord l’existant, c’est-à-dire le système opérationnel de la banque, avant de passer à la modélisation de l’entrepôt de données et du système décisionnel.

L’originalité du propos d’A. Ducreau [Ducreau, 2004] est d’introduire l’analyse du système opérationnel seulement à ce niveau de la démarche de conception, de manière à savoir si ce système opérationnel répond bien aux besoins en informations décisionnels. Cela nous paraît très judicieux d’autant plus qu’il existe généralement déjà des systèmes d’informations opérationnels dans les banques. Le propos nous semble donc bien adapté au contexte et à la situation de secteur bancaire, notre champ d’étude.

a. Analyse du système d’informations opérationnel

Le principal objectif de cette phase d’analyse des sources de données est donc de permettre une bonne connaissance des informations manipulées dans les bases de données « sources », aussi bien au niveau des formats utilisés pour les représenter physiquement qu’au niveau des relations entretenues par ces bases entre elles. L’étude et l’analyse des MCD et MPD permettent de connaitre de façon approfondie les données, issues du système d’informations opérationnel, disponibles et utilisables par le système d’informations stratégiques en cours de conception.

Toutefois, à l’heure actuelle dans de nombreuses organisations et établissements bancaires, les MCD et MPD ne sont pas actualisés. Nous recommandons dans ce cas l’utilisation des outils de « rétro-conception » ou « reverse engineering⁹⁹ » pour retrouver les MPD puis les MCD des bases de données du système d’informations opérationnel. P. Nourrissier avait notamment travaillé sur le thème du « reverse engineering » dans le cadre de son diplôme de recherche technologique (DRT) [Thiery & David & Nourrissier, 2002] et [Nourrissier, 2004].

Enfin, une étude de la qualité de ces données s’impose, et fera l’objet du paragraphe 4.4.2 ci-dessous.

Par ailleurs, dès lors que la structure des données à utiliser dans le système d’informations stratégiques est bien analysée, il importe de s’interroger sur la forme précise du système d’informations stratégiques à construire : une base métier à destination d’un seul type d’utilisateur (magasin de données) ? ou bien un ensemble de bases métier à destination de différents types d’utilisateurs ?

b. Choix du type de système décisionnel : entrepôt de données ou magasin de données ? Nous arrivons à une étape de notre démarche où nous connaissons désormais les besoins auxquels notre système d’informations stratégiques devra répondre, ainsi que les différents indicateurs que le système à concevoir devra fournir aux utilisateurs finals.

Aussi, les principales contraintes du système en cours de conception sont désormais connues, le choix de la solution technique réalisé, et les bases de données de production devant alimenter le data warehouse (entrepôt de données) ont été analysées. Mais, avant de passer à la phase conceptuelle de modélisation du data warehouse, il se pose la question du choix de la conception d’un magasin de données (data mart) ou d’un entrepôt de données (data warehouse) à concevoir. En d’autres termes, il s’agit de se demander si l’on souhaite concevoir une base métier destinée à un décideur en particulier ou bien un entrepôt de données dans sa totalité.

Nous avions montré précédemment, (Figure 18 : de l'entrepôt de données au système

d'intelligence économique), qu’un système d’informations stratégiques, qui constitue le

noyau d’un système d’intelligence économique, a lui-même pour noyau le data warehouse

ou entrepôt de données. L’entrepôt de données constitue donc le principal fondement d’un système d’informations stratégiques. Et, nous avions retenu comme définition de l’entrepôt de données, celle proposée par [David & Thiery, 2001] : « un entrepôt de données est une base de données organisée pour répondre aux besoins spécifiques de la prise de décision. Cette base contient des informations historiques sur l’entreprise, son fonctionnement et son environnement. Elle est alimentée à partir des bases de production et d’informations externes à l’entreprise. Elle recouvre donc les mêmes types d’informations utilisées dans un contexte d’intelligence économique. Elle est thématique, relative à un domaine intéressant le décideur, possédant une référence temporelle, sûre, c’est à dire dont la qualité a été vérifiée, facile d’accès, non volatile et régulièrement complétée. En fait, l’entrepôt de données est une vue intégrée de l’organisation. Il est le noyau du système d’informations stratégiques ».

[Thiery, 2010] complète cette définition en précisant qu’un entrepôt de données donne naissance par filtrage, non plus par rapport aux dimensions des données, mais par rapport à des profils utilisateurs, à des bases métier : ce sont des sous bases de l’entrepôt de données destinées à une fonction spécifique de l’organisation (fonction « Marketing », fonction « Finances », etc.). Ces bases qui sont non modifiables par les utilisateurs sont alimentées périodiquement et reposent sur une vue multidimensionnelle des données. Aussi, selon [Ducreau, 2004], un entrepôt de données centralise plusieurs thèmes (ou fonctions) de l’entreprise, et chacun de ces thèmes peut être matérialisé par un magasin

de données. Le magasin de données ou data mart étant un entrepôt de données

spécifique, permettant de regrouper de façon thématique et sémantique les données. Dans le cas de notre étude, il s’agira de concevoir un certain nombre de magasins de données autour des profils des utilisateurs finals que nous avions modélisés précédemment, à savoir le client, le conseiller de clientèle, l’analyste du risque de crédit et le décisionnaire.

Par ailleurs, l’entrepôt de données joue le rôle de fédérateur des informations internes et externes pour l’ensemble de l’organisation et, à ce titre, fait appel au maximum des sources disponibles. Tandis que le magasin de données se caractérise essentiellement par le recours à un minimum de sources autour d’un thème ou d’une fonction bien précise.

Au niveau de la structure des données, la conception de l’entrepôt de données se fait à partir d’une modélisation de type normalisé alors que celle du magasin de données recourt à une modélisation de type multidimensionnelle.

Enfin, on peut constituer des magasins de données dépendant les uns des autres ou bien indépendants entre eux, mais pouvant se combiner au sein d’un entrepôt de données. Les magasins de données et les entrepôts de données sont alimentés par diverses sources, internes ou externes à l’organisation. Et, ces sources produisent des données structurées (bases de données, fichiers Excel, etc.) ou non structurées (photos, vidéos, organigrammes, etc.) qui en sont extraites puis intégrées au sein de l’entrepôt suivant un schéma de transformation en un modèle commun.

Le choix de la structure du système d’informations stratégiques étant arrêté, et sachant désormais s’il nous faut modéliser un entrepôt de données ou un magasin de données, il faut maintenant choisir le type de modélisation à effectuer.

c. Modélisation du système d’informations stratégiques : application à la banque

Le choix de la structure du système d’informations stratégiques étant effectué et, même si nous avons choisi de modéliser prioritairement un entrepôt de données plutôt qu’un magasin de données, les méthodes de modélisation restent identiques ; car un magasin de données constitue simplement une vue partielle d’un entrepôt de données.

Rappelons que nous avions précisé précédemment (cf. 4.3.1.3 Les concepts d’entrepôt de

données et de base de données multidimensionnelle) que les données manipulées dans les systèmes décisionnels en général et dans les entrepôts de données en particulier, peuvent revêtir différentes formes ou bien se présenter sous différents états : elles peuvent être détaillées ou historisées ou agrégées ou fortement agrégées. Et, ces différents états ont été explicités à la suite de la Figure 22 : Etats des données dans les entrepôts de données [Ducreau, 2004].

D’une part, avec ces types de données, il nous semble facile de penser que si l’on souhaite obtenir, à chaque niveau d’agrégation, des données sur les différents axes d’analyse, le volume de données final sera gigantesque. Et il sera difficile de gérer des volumes aussi importants, surtout si l’on souhaite obtenir des temps de réponse corrects ou convenables lors de l’interrogation de l’entrepôt.

D’autre part, la modélisation naturelle d’un entrepôt de données, qui est la modélisation rationnelle et normalisée, conduit à un éclatement de données sur plusieurs tables et, par conséquent, peut générer des problèmes lors de l’exploitation de la base de données (redondances, incohérences futures, etc.).

Enfin, la représentation de ces types de données à l’aide du modèle relationnel a pour principaux inconvénients la nécessité de connaitre préalablement le schéma pour pouvoir interroger les bases de données, et des temps de réponse longs du fait que les résultats ne sont pas pré-agrégés mais calculés lors du lancement des requêtes.

Ici, il parait nécessaire d’utiliser d’autres méthodes de modélisation qui sont mieux adaptées à la structure des données contenues dans les entrepôts de données. Les principales méthodes sont le schéma en étoile, le schéma en flocon et le schéma en constellation.

Le schéma en étoile représente une modélisation particulière : la table des faits, qui est la table centrale du schéma, permet de relier les différentes dimensions de la base de données ; ces dimensions n’ont pas de liens directs entre elles, et chaque table correspond à une dimension ou un axe d’analyse.

FIGURE 30:MODELISATION DIMENSIONNELLE DU FAIT "VENTES", SCHEMA EN ETOILE

Comme le montre la Figure 30 : Modélisation dimensionnelle du fait "ventes", schéma en étoile ci-dessus, la table des faits rassemble les données qui se rapportent à chaque dimension. Ainsi, dans cet exemple, on trouve un indicateur dans le fait « vente » (le montant de la vente) et plusieurs attributs dans chacune des dimensions. Par ailleurs, on peut constater que les dimensions (« produit », « client », « vendeur » et « période ») n’ont pas de lien relationnel entre elles : seul le fait « vente » permet de lier les dimensions. Il s’agit ici, en réalité, d’une association à « 4 pattes ».

VENTES id_Produit id_Conseiller date id_Client PNB Marges CLIENT id_Client nom_Client prénom_Client adresse_Client CONSEILLER id_Conseiller nom_Conseiller prénom_Conseiller agence_Conseiller PRODUIT id_Produit désignation prix gamme PERIODE date mois trimestre année

Le schéma en étoile est la structure la plus courante des entrepôts et des magasins de données et présente l’avantage de pouvoir accélérer la performance des requêtes.

Mais, quand ce schéma devient trop volumineux, on recommande un schéma de modélisation en flocon.

Dans le schéma en flocon, les dimensions sont structurées en sous-dimensions et chaque

dimension est organisée en hiérarchie de détails.

FIGURE 31: LE SCHEMA EN FLOCON

Ainsi, dans la Figure 31 : le schéma en flocon ci-dessus, la dimension « période » se décompose en sous-dimensions « Mois » et « Jour de la semaine », tandis que la dimension « Client » se décompose elle, en « Région » et ensuite en « Pays ».

Précisons que le schéma en flocon ci-dessus s’adapte parfaitement à notre domaine d’étude, la banque. Le fournisseur peut être une filiale spécialisée de la banque, à l’exemple de SOGELEASE ou SOGEBAIL qui sont des filiales de la Société Générale dédiées au financement par crédit-bail, ou bien SQUARE HABITAT, l’agence immobilière du Crédit Agricole. Ce fournisseur peut également être une société étrangère à la banque et dont cette dernière commercialise des produits ; c’est le cas, par exemple, pour certains produits d’assurance ou de prévoyance.

Pour ce qui concerne la gamme et les produits bancaires, nous renvoyons plus haut au paragraphe 2.4. LA GAMME DES PRODUITS BANCAIRES dans lequel nous avions présenté ces produits et services.

Enfin, la troisième forme envisageable dans le cadre de la modélisation d’un entrepôt de données est le schéma en constellation.

FIGURE 32: LE SCHEMA EN CONSTELLATION

Ce modèle consiste à fusionner plusieurs modèles en étoile qui utilisent des dimensions communes. Ainsi, comme le montre la Figure 32 : le schéma en constellation ci-dessus, un schéma en constellation comprend donc plusieurs tables de faits et des tables de dimensions qui sont communes ou non à ces tables de faits.

Avec la conception du système décisionnel de pilotage s’achève l’avant-dernière étape de notre démarche de conception d’un entrepôt de données. Cette phase nous a permis, à partir de l’étude du système d’informations opérationnel, de choisir entre un entrepôt de données et un magasin de données, et également d’opter pour un type de modélisation, principalement, entre le schéma en étoile, le schéma en flocon et le schéma en constellation.

Désormais, nous pouvons passer à la dernière phase qui est celle de l’implantation du système d’informations stratégiques.