Projet Webmaster
Gestion de projets web ntic

Du concept au projet informatique - De la maîtrise d’oeuvre à la maîtrise d’ouvrage

Web-ntic MOE MOA > Etudes > Nouvelle approche du decisionnel

Nouvelle approche du decisionnel

vendredi 21 mars 2003, par km

L’informatique décisionnelle porte un concept : le Datawarehouse ou " entrepôt de données ". L’infocentre d’hier devient Datawarehouse aujourd’hui. Que se cache-t-il derrière cette terminologie ?

L’informatique décisionnelle porte un concept : le Datawarehouse ou " entrepôt de données ". L’infocentre d’hier devient Datawarehouse aujourd’hui. Que se cache-t-il derrière cette terminologie ?

Avant tout, comme souvent, la bataille marketing fait rage à l’heure actuelle et tous les acteurs majeurs cherchent à se positionner sur ce nouveau marché car les enjeux sont importants. Le décisionnel trouve là une seconde jeunesse ou plutôt, sort de l’enfance. La difficulté pour l’utilisateur final est de comprendre les concepts, l’intérêt et ce qui se cache derrière ce brouillage marketing.
Cette étude tentera d’abord de répondre à ces questions et se focalisera par la suite sur une classe d’outils nécessaires à la mise en place d’un Datawarehouse : les outils d’alimentation de l’entrepôt de données.

Eclaircissons d’abord le concept : " Datawarehouse ", littéralement " entrepôt de données ", terme dont on attribue la paternité à W.H. Inmon, auteur de plusieurs ouvrages sur le sujet et aujourd’hui leader charismatique de Prism Solutions. Le Datawarehousing se caractérise par une approche méthodologique spécifique de l’informatique décisionnelle et surtout par un postulat de base issu d’un constat simple : les données de l’informatique de production ne se prêtent pas à une exploitation optimale dans un cadre décisionnel. C’est à dire que non seulement il est indispensable de séparer les deux mondes mais surtout, et ce qui est nouveau, il faut repenser les schémas de données en vue d’une exploitation dans un cadre d’aide à la décision. De surcroît, cette vision doit être globale, propre à l’entreprise toute entière. En fait, la problématique cachée derrière cela est l’unification des différents gisements de données de l’entreprise en un entrepôt de données global organisé pour l’aide à la décision.
Définissons de manière un peu plus précise, ce qui caractérise les données d’un Datawarehouse (cette définition est énoncée par Bill Inmon dans ses ouvrages et est admise par tous aujourd’hui) :

  • Les données doivent être orientées sujet (ici, on entend sujet d’analyse, on parle aussi parfois de dimension). Par exemple, si l’on souhaite analyser le comportement des clients d’une société d’assurances, les données doivent être organisées autour de la vision propre à l’entreprise d’un client. L’image inventée par le Meta Group, est d’ailleurs significative en opposant le Datawarehouse aux systèmes de production considérés comme des " Data Jails ", littéralement " prisons de données " !
  • Elles doivent de plus être non volatiles. C’est à dire en lecture seule, avec une conservation de l’historique et de leur évolution. Lorsque l’on cherche à analyser un comportement ou l’évolution de tel ou tel phénomène, il est primordial de conserver un historique complet des données le concernant. Par exemple, un des plus gros Datawarehouse en production actuellement (Walmart, un grand distributeur américain) conserve l’historique des ventes de ses 2000 magasins sur 65 semaines, ce qui représente en volume plus de 2 Teraoctets (To).
  • Celles-ci doivent de plus être épurées ou transformées (les anglo-saxons utilisent la terminologie Data Quality). Cette opération sous-entend en fait plusieurs procédés :
  • Un filtrage et une validation des données (les valeurs incohérentes doivent être rejetées).
  • Un codage : une donnée représentée différemment d’un système de production à un autre impose le choix d’une représentation unique. Par exemple, la donnée " sexe " peut être représentée par un seul caractère sur un système donné (" H/F ") ou uniquement par un bit 0 ou 1 sur un autre.

Une conséquence directe, le Datawarehousing est un processus : il faut le percevoir comme mouvant et en perpétuelle évolution. " Il faut s’attendre à ce que votre Datawarehouse double de volume toutes les nuits ! " déclare Rob Armstrong, d’AT&T GIS en charge du projet Walmart. Sous cet angle, on peut finalement voir le Datawarehouse comme une architecture décisionnelle capable à la fois de gérer l’hétérogénéité et le changement et dont l’enjeu final est de " Transformer les données en informations " directement exploitables par les utilisateurs du métier concerné.

L’enjeu : l’émergence d’un nouveau marché

Le battage médiatique dans la presse spécialisée traduit un constat clair : ce marché intéresse tout le monde et la complexité inhérente à la mise en place d’un tel projet conduit forcément à des alliances et des accords de partenariat. Chacun annonce d’ailleurs à l’heure actuelle sa stratégie propre autour du Datawarehouse. Constructeurs, éditeurs de base de données ou d’outils et intégrateurs collaborent donc et essayent de se positionner sur ce nouveau créneau. Pour exemple, on peut citer les offres des éditeurs SGBD au centre du débat avec Oracle Warehouse, Sybase Warehouse Works, ou la stratégie Datawarehouse d’Informix.
Les enjeux financiers et marketing derrière cette nouvelle approche du décisionnel sont donc énormes. Par ailleurs, la convergence d’un certain nombre de facteurs amène à penser que ce marché risque d’exploser dans les années à venir. Dans la suite, nous allons vous exposer les raisons qui nous conduisent à penser que le marché du décisionnel, transcendé par les apports du Datawarehouse, peut devenir majeur à court terme.

Justification marketing

Ceux qui comme nous croient fermement à l’efficacité des solutions client-serveurs ne peuvent que voir d’un bon oeil l’arrivée d’un concept tel que le Datawarehousing. En effet, l’approche Datawarehouse peut être vue comme un nouveau vecteur de promotion des architectures client-serveur fondées sur les systèmes ouverts. Typiquement, la plate-forme privilégiée pour l’hébergement de la base décisionnelle fédératrice (i.e. l’entrepôt de données) est une machine parallèle dotée d’un SGBD relationnel sous Unix. De plus, les outils d’analyses des données ou d’administration du Datawarehouse fonctionnent quasiment tous en mode client-serveur. Cette approche réconcilie en quelque sorte les mondes mainframe et systèmes ouverts puisque il n’y a pas de notion de rupture dans la méthodologie proposée : les systèmes de production restent inchangés et on ne leur enlève pas d’importance, on ajoute simplement un composant décisionnel dans le système d’informations de l’entreprise. Finalement, une nouvelle voie pour le modèle client-serveur est de train de se créer et la vague Datawarehouse pourrait bien contribuer au raz de marée annoncé du modèle client-serveur. Ainsi, selon le Gartner Group, le marché du Datawarehouse devrait atteindre 6,9 milliards de dollards US en 1999. Une étude d’un autre organisme, le Meta-Group, confirme cette tendance en indiquant que plus de 90 % des services informatiques envisageraient de mettre en place un Datawarehouse dans les trois ans à venir ! (Echantillon de 2000 entreprises américaines référencées dans American Fortune)

Justification technique

Le Datawarehouse, pourquoi maintenant ? Aussi pour des raisons technologiques. En effet, cette approche a aujourd’hui les moyens techniques de se concrétiser. Une convergence d’innovations technologiques permet maintenant d’envisager la mise en oeuvre de tels projets. Pêle-mêle, on peut citer les progrès dans les domaines suivants :

  • Matériel : Machines parallèles (SMP et MPP).
  • Logiciel : Les moteurs relationnels s’adaptent à ces nouvelles architectures. Des offres dédiées à ce domaine sont en cours de constitution.
  • Interopérabilité : La communication entre divers systèmes hétérogènes se banalise et progresse constamment (bien que la standardisation soit lente à s’organiser sur ce point).

Le problème induit par le concept de Datawarehouse est la gestion d’énormes volumes de données (des centaines de Gigaoctets, l’ambition étant de démocratiser rapidement le milliard d’octets ou Teraoctet), donc pour l’utilisateur la nécessité d’avoir à sa disposition une formidable puissance de calcul pour pouvoir exprimer ses requêtes sur ses volumes de données et des outils appropriés. Dans ce contexte, les machines massivement parallèles, jusqu’alors confinées dans le monde du calcul scientifique, trouvent là une opportunité supplémentaire d’entrer dans le monde de la gestion en proposant la puissance de calcul demandée. Un tel système appliqué à l’aide à la décision doit offrir la capacité de répondre, dans des délais raisonnables, à des requêtes complexes auparavant insolubles.

Toutefois, il faut pouvoir utiliser au mieux une machine multi-processeurs, donc adapter les logiciels à cet environnement parallèle. L’application centrale dans ce type de projet est évidemment la base de données : on constate que tous les principaux éditeurs de bases de données relationnelles proposent des versions parallélisées de leur moteur. Ainsi, on peut citer Informix OnLine Dynamic Server XPS (pour machines massivement parallèles), Oracle Parallel Server, Sybase System 11 et enfin IBM DB2/Parallel Edition.
D’autres technologies complémentaires bien adaptées au monde du Datawarehouse sont en train d’émerger comme de nouvelles techniques d’indexation de données (comme par exemple, Sybase IQ Accelerator) ou de recherche textuelle adaptées aux très gros volumes de données (comme Oracle TextServer).
Enfin, des outils spécifiques arrivent sur le marché et adressent un domaine fonctionnel particulier du Datawarehouse : notamment, l’accès aux données ou la problématique d’alimentation du Datawarehouse (même si beaucoup d’entre eux viennent du monde de la migration de données). Toutefois, l’intégration de ces différentes briques logicielles reste faible et aucun environnement de développement vraiment complet et adapté au décisionnel n’existe encore aujourd’hui.

Justification économique

La dernière et certainement la plus importante des raisons du succès futur des Datawarehouses est l’avantage concurrentiel réel apporté par ce type de système et les bénéfices directs perçus par l’utilisateur.

L’entreprise actuelle croule sous les données. Cette surabondance (certains parlent de déluges) a comme conséquence directe un rejet par saturation. Pourtant ces données représentent une mine d’informations. Le problème est de mettre en place les moyens permettant d’une part de comprendre la valeurs de ces informations et d’autre part d’y accéder de manière efficace pour prendre les meilleures décisions.
Transformer ces données en connaissance est un processus complexe. L’objectif à atteindre est de recomposer les données disponibles pour en donner :

  • une vision intégrée et transversales aux différentes fonctions de l’entreprise,
  • une vision métier au travers de différents axes d’analyse,
  • une vision agrégée ou détaillé suivant le besoin de l’utilisateur.

Le Datawarehouse vise à fédérer cette connaissance. L’ambition avouée : proposer un outil décisionnel s’appuyant sur les informations pertinentes pour l’entreprise, c’est à dire centrées sur le métier de l’utilisateur. Ainsi, ce type d’outil va permettre d’anticiper et dans l’idéal de prévoir les évolutions de son marché à partir des données historiques accumulées : En d’autres termes, être plus réactif, pour être plus compétitif et plus efficace ! La justification financière n’est pas toujours évidente au départ, lorsqu’on souhaite lancer un projet de ce type. Pour chiffrer le retour sur investissement, un dès moyen possible peut être de chiffrer les coûts engendrés par les limitations du système actuel. La société américaine Ertl, fabricante de jouets, (220 M$ de CA) a justifier ainsi son besoin de mise en oeuvre d’un Datawarehouse par le chiffre édifiant suivant : supprimer les 18 000 heures par an, passées à créer des rapports et éditions à la main ! Aujourd’hui, Ertl ne regrette pas sa décision et est arrivée à ses fins.

En fait, l’ambition avouée par tous est de créer un nouveau type d’applications décisionnelles destinées à devenir un outil de pilotage et d’analyse central pour l’entreprise. En d’autres termes, devenir un facteur critique de succès et par suite se rendre indispensable, ce que les anglo-saxons traduisent souvent par " business critical ".

Le secteur de la grande distribution aux Etats-Unis fournit un certain nombre d’exemples à ce propos. Ainsi, les premiers projets mis en place ont permis par exemple d’analyser le comportement de la clientèle en fonction de différents critères (la période, les offres promotionnelles, les emplacements dans les rayonnages...). Des succès célèbres comme Walmart ou Mervyn’s (500 Go), gros distributeurs américains, ont contribué au lancement du concept de Datawarehousing. Carol Pecoraro, directeur du projet chez Mervyn’s, déclare " Nous passons aujourd’hui seulement 10% de notre temps à rassembler les données et 90 % à les utiliser, contrairement au passé ! ".

Le problème avec de tels systèmes est souvent d’évaluer a priori le potentiel informationnel qu’il contient : pour cette raison, B. Inmon conseille une démarche itérative de mise en oeuvre avec une première phase de constitution rapide autour d’un premier sujet donné. Ainsi, les utilisateurs appréhendent directement les apports d’un tel outil et surtout, donnent leur sentiment sur la pertinence des données mises à leur disposition. De cette manière, la conception peut être corrigée et enrichie par les remarques des utilisateurs. Dans son ouvrage, Bill Inmon décrit cette approche par cette formule intéressante : " Donnez moi ce que je veux, je vous dirait alors ce que je voulais vraiment ! "

Mise en oeuvre d’un DataWarehouse

Notre but n’est pas de décrire en détail une méthodologie complète, ni un cahier des charges de réalisation exhaustif mais plutôt de donner un aperçu de la complexité cachée derrière toute problématique de Datawarehousing. Nous essaierons en fait de sensibiliser le lecteur à l’approche de mise en oeuvre d’un tel projet.
Une fois les concepts de base énoncés, décrivons un canevas minimal nécessaire à la mise en place d’un projet de Datawarehousing :

  • Définitions des objectifs :
    D’abord, délimiter le champs du domaine visé paraît primordial souvent dans le cadre d’une logique itérative de prototype. Donc, la première étape est de savoir ce que l’on veut analyser (les ventes, les coûts de fonctionnements,...), ce qui revient la plupart du temps à choisir un domaine métier ou une activité particulière de l’entreprise. Ensuite, il faut définir les critères primaires intéressants (les ventes en fonction du temps, de la localisation, des types de produits...) sachant que ceux-ci s’enrichiront au fil de l’imagination des utilisateurs du système. Enfin, et c’est souvent la où le bât blesse, un plan budgétaire et un cadre temporel doivent être fixés.
  • Conception du modèle de données :
    Une fois le domaine ciblé, la tâche suivante consiste à concevoir un modèle de données orienté vers le sujet choisi ; c’est à dire, sélectionner les informations intéressantes pour le domaine et les organiser. D’abord, un constat : L’expérience montre que les méthodes traditionnelles de conception ne sont pas adaptées à la problématique du Datawarehouse. Des méthodologies spécifiques (modèle en étoile, modèle en flocons), conçues pour le décisionnel, sont en cours de formalisation aujourd’hui et apparaissent progressivement issues des premières implémentations aux Etats-Unis.
  • Implémentation proprement dite : Cette phase comprend la matérialisation technique proprement dite du projet. Elle sous-entend une complexité importante et doit de ce fait être découpée de manière précise :
  • Définition de l’architecture matérielle et logicielle du système décisionnel (choix des outils et des techniques).
  • Identification des sources de données attaquées. Cette opération sous-entend la découverte des données pertinentes dans la masse d’informations de l’entreprise.
  • Alimentation de la base centrale.
  • Définition de la stratégie de diffusion. L’architecte du Datawarehouse a le choix entre deux grandes topologies de conception de son système décisionnel :
  • L’entrepôt centralisé. Dans ce cas, l’entrepôt de données est accessible directement par les utilisateurs.
  • Le Datawarehouse distribué. Ici, la base centrale n’est pas forcément accédée directement mais est relayée par n bases locales, plus proches des utilisateurs, organisées en fonction de leurs sujets d’intérêt directs. Ces magasins de données (Data Marts dans la littérature anglo-saxonne) sont soit obtenues par réplication directe d’une partie de l’entrepôt central, soit réorganisées plus finement en fonction du sujet d’analyse (avec un niveau d’agrégation des données plus important). Par exemple, si le Datawarehouse central stocke le détail des ventes sur soixante mois, on peut imaginer un magasin de données ne gérant que les données concernant les ventes agrégées par semaine.
  • Mise en place de l’environnement d’analyse. Cette phase concerne le choix et l’installation des outils clients pour l’analyse des données (ce qui implique souvent la préparation des vues sur les données pour les utilisateurs). Une pléthore d’offres arrive sur ce marché et complique sérieusement ce choix (outils Relationnel OLAP, SIAD, outils statistiques...).
  • Diffusion et mise en exploitation : L’objectif final étant bien sur de mettre à disposition le système auprès des utilisateurs finals, plusieurs approches peuvent être envisagées comme nous l’avons vu précédemment. Soit l’accès à la base décisionnelle globale est direct, soit les utilisateurs accèdent, non pas à l’entrepôt entier, mais à des " magasins de données ". Les Data Marts sont des sous-ensembles du Datawarehouse, correspondants à un sujet d’intérêt donné et destinés en général à une population métier ciblée (par exemple : on peut imaginer un Datawarehouse global pour une multinationale et des Data Marts spécialisés par pays).
  • Administration : La maintenance de très gros volumes de données impose la définition de procédures et stratégies tout à fait particulières. Par exemple, sauvegarder plusieurs centaines de Gigaoctets, voire quelques Teraoctets devient un problème à part entière. Le chargement périodique des données en est un autre (problématique nouvelle liée aux très grands volumes de données manipulés). Qui plus est, ces coûts de maintenance forment souvent la partie immergée de l’iceberg et ne doivent jamais être négligés.
Mise en oeuvre d'un Datawarehouse

Mise en oeuvre d’un Datawarehouse

L’environnement de développement décisionnel universel n’existant pas encore, on assiste à une myriade d’offres sur le marché, répondant chacune à une partie du puzzle Datawarehouse. Par conséquent, créer une base décisionnelle nécessite forcément un travail d’intégration et d’assemblage de technologies souvent diverses. Afin de fixer les idées, voici par exemple, un aperçu des principales classes d’outils susceptibles de trouver une place dans un contexte de Datawarehousing :

  • Candidats privilégiés :
  • Outils de recherche et d’exploration de données. Leur but est avant tout d’identifier les bonnes données parmi les systèmes opérationnels de l’entreprise. Au passage, cela leur permet souvent de repérer les informations incohérentes donc de préparer leur " nettoyage ".
  • Outils d’alimentation (extraction, transfert, épuration, transformation, alimentation). Ce sont les environnements spécialistes de la migration de données.
  • Plate-forme de stockage du DataWarehouse. Centrée sur les données, celle ci se compose typiquement d’un moteur relationnel hébergé sur un serveur haut de gamme évolutif. Lorsque les volumes de données l’imposent, le parallélisme des traitements devient nécessaire. Les machines multi-processeurs trouvent alors un terrain d’expression rêvé.
  • Outils d’analyse de données (infocentre, EIS, ROLAP). Dans cet ensemble, on retrouve les interfaces destinées aux utilisateurs et spécialisés dans l’analyse et la valorisation des données.
  • Challengers :
  • Outils middleware et d’interopérabilité (passerelles). Ces produits de connectivité peuvent être de bons candidats pour intervenir en complément dans certains contextes de mise en place de Datawarehouse.
  • Réplicateurs et pompes de données. Généralement, fonctionnellement limités pour alimenter la base centrale, ils deviennent intéressants pour gérer les flux de données entre l’entrepôt et les magasins de données.
  • Outils de conception (Upper Case). Les méthodes de conception spécifiques au décisionnel sont encore aujourd’hui à l’état expérimental. Donc, les outils actuels sont forcément mal adaptés mais peuvent servir de support ou d’aide de premier niveau à la conception du modèle global de l’entreprise.
Les outils du Datawarehouse

Les outils du Datawarehouse

Un exemple : BANK of BOSTON

Enfin, la mise en place d’un projet de ce type a souvent des effets de bord sur les systèmes opérationnels. Plus exactement, le travail effectué sur la qualité des données lors de la conception du Datawarehouse, permet de mettre en lumière les anomalies des systèmes de production. A partir de ce moment, la décision d’engager des actions correctives dans les systèmes transactionnels peut être envisagée sur la base des travaux réalisés pour le Datawarehouse. Rob Mattison, considéré comme le père du concept de Data Mining , désigne cette possibilité par le terme backflush.

Les écueils à éviter

Le lancement d’un projet de Datawarehousing est une entreprise d’envergure et comme tout projet d’envergure, il convient de bien être conscient des principaux dangers inhérents à ce genre d’aventure :

  • Le premier est de ne pas sous-estimer la complexité d’un tel projet (gérer l’hétérogénéité, épurer les données, valoriser les données, présenter les données, maîtriser le changement) et donc il est clair qu’une démarche rigoureuse s’avère indispensable. Le problème central est celui de l’administration des données et des méthodologies afférentes à ce domaine peuvent efficacement seconder la structuration d’un tel projet. La dimension organisationnelle dans ce genre d’entreprise est cruciale et d’ailleurs souvent un facteur d’échec. Rob Mattison dans son livre (éditeur Mc Graw Hill) centré sur ce sujet parle de Data Discipline et propose une procédure rigoureuse recensant les différentes étapes et actions à ne pas omettre pour mener à bien un projet de Datawarehousing.
  • Ensuite, la nouveauté du domaine implique de bien s’entourer pour pouvoir mener à bien un projet de cette envergure. Le marché étant en cours de constitution, peu de compétences sont disponibles à ce jour et il faut choisir ses partenaires technologiques avec précaution. La bataille marketing actuelle n’aidant pas à la clarté des débats, le recours à des consultants spécialisés est souvent une solution intéressante.
  • Enfin, il faut bien être conscient des investissements importants (financier, humain...) nécessaires à la mise en oeuvre d’un tel outil décisionnel et par la suite, être ambitieux sur l’objectif et les retours attendus (le système doit devenir un avantage concurrentiel pour l’entreprise).
    (Source institut EDS Prometheus URL=http://www.prometheus.eds.fr/)



Partagez cette page



Répondre à cet article et accéder au Forum Nouvelle approche du decisionnel

Imprimer Nouvelle approche du decisionnel