L'engouement pour les projets décisionnels - Business Intelligence (BI), en anglais - est
sans précédent, car le volume de données produites par une entreprise double tous les
cinq ans. Des données qu'il faut trier puis agréger sous la forme d'indicateurs de gestion
synthétiques pour pouvoir prendre des décisions pertinentes.
« Vous pilotez un avion de nuit. Comment atterrissez-vous sans écran de contrôle ? »,
résume Jean-Michel Bras, secrétaire général d'Aexxdis, spécialiste de la logistique des
produits de santé (120 collaborateurs), qui propose des tableaux de bord métier à
l'ensemble des professionnels avec qui l'entreprise travaille.
Les outils des éditeurs propriétaires - Business Objects, Cognos, Hyperion, SAS,
Teradata, etc. - coûtent cher, car ils sont souvent facturés au nombre d'utilisateurs ou de
connexions simultanées. Les entreprises se tournent donc vers des outils open source
pour réduire les coûts de licence, de 20 à 50 % du coût total d'un projet décisionnel.
« Nous ne nous sommes même pas intéressés aux outils propriétaires tant ils sont
chers », illustre Frédéric Jourden, directeur marketing de Xinek (cinq employés), un
service de recommandation d'achat en réseau, qui utilise Pentaho pour la restitution
(tableau de bord, etc.) et MySQL pour son entrepôt de données (stockage des données).
Cependant, parce qu'elles ne sont pas aussi bien finies que les suites propriétaires, « les
suites open source requièrent parfois un effort de participation du client dans le
développement. Mais elles permettent en contrepartie de lui construire une solution sur
mesure », indique Michael Bienstein, responsable BI open source chez BearingPoint et
membre actif des projets olap4J et Mondrian.
Pour accélérer les déploiements, des éditeurs, tels Pentaho et Jasper-Soft, et des
intégrateurs comme Engineering (SpagoBI) proposent donc des suites presque complètes
intégrant ETL, moteur Olap, serveur de rapports, etc. Idem du côté des bases de
données. Si PostgreSQL et MySQL ne rivalisent pas avec Teradata, elles répondent
cependant aux contraintes de nombreux projets.
L'utilisation : mieux piloter son activité
Propriétaire ou libre, le besoin fonctionnel de l'entreprise se résume toujours à « disposer
d'informations pertinentes pour mieux vendre et faire les bons choix stratégiques ».
Aexxdis a, par exemple, déployé un portail métier proposant des tableaux de bord aux
personnes extérieures à l'entreprise et une navigation multidimensionnelle (Olap) en
interne. L'ensemble du projet repose sur des briques open source : Pentaho, PostgreSQL,
OpenLDAP, etc.
« Le management capte et analyse ainsi plus rapidement l'information structurante, ce
qui améliore le processus de décision en termes de qualité et de délai. Nos clients
disposent quotidiennement d'une quarantaine d'indicateurs et de sources d'informations
à travers un portail décisionnel sécurisé », détaille Jean-Michel Bras. Chez Xinek, Pentaho
permet de mieux comprendre l'audience du service en ligne pour proposer des cibles à
forte valeur ajoutée aux annonceurs qui rémunèrent l'entreprise en fonction des ventes
générées
Bien qu'étant un service public, le Secrétariat pour les affaires régionales de la préfecture
de région Midi-Pyrénées (SGAR, 55 employés) a suivi exactement la même démarche
(PostgreSQL, SpagoBi) afin que « les préfets des huit départements disposent de
tableaux de bord efficaces pour juger la performance des engagements pris dans le cadre
de la LOLF », explique Philippe Ourliac, chargé de mission TIC au sein du SGAR.
Le projet comprend trois datamarts stockant des indicateurs pour 34 missions,
130 programmes et 50 budgets opérationnels. C'est surtout le coût des outils
propriétaires qui explique son choix. « Avec 340 contributeurs, les coûts de licence
faisaient exploser notre budget. L'open source nous affranchit de ces coûts tout en
augmentant notre indépendance vis-à-vis d'un fournisseur », résume Philippe Ourliac. A
l'image de Sabre (système de réservation de voyages aériens) et de Swissport (gestion
des aéroports suisses, 21 000 employés), les grandes entreprises recourent plutôt à l'
open source pour rationaliser et réduire le coût de certains projets décisionnels.
« Notre base de données Teradata était surdimensionnée tant sur un plan fonctionnel
que financier. Nous avons donc opté pour MySQL », illustre Michael Benzinger, chez
Sabre. L'entreprise a créé un entrepôt de données de plus de 4 To en trois semaines, en
ne prenant en charge que le coût du matériel : 62 500 dollars au total.
De son côté, Swissport souhaitait « réduire le nombre d'outils de reporting en interne et
tirer plus de valeur ajoutée des données que nous produisons toute l'année », explique
Uwe Geercken, son responsable informatique.
La mise en oeuvre : l'ouverture facilite la cohabitation
Un projet décisionnel est souvent découpé en deux lots. L'entrepôt de données
(datawarehouse) agrège certaines données de production selon un schéma en étoile à n
dimensions métier : client, produit, etc. Contrairement à une base traditionnelle,
certaines données peuvent être dupliquées pour des raisons de performance.
La couche de restitution comprend, elle, les nombreuses briques techniques qui
permettent à l'utilisateur de visualiser les indicateurs, de créer des rapports et de
naviguer au sein des dimensions métier des données. Jusqu'à présent, aucune entreprise
ne se lançait directement dans un projet décisionnel d'envergure en s'appuyant
entièrement sur des outils open source.
Le risque technique était trop important, et, malgré leur coût de licence élevé, les outils
propriétaires satisfaisaient souvent les utilisateurs en termes de couverture fonctionnelle,
de stabilité et de performances. Sabre n'a donc remplacé Teradata par MySQL que pour
une partie seulement de son entrepôt de données. L'entreprise continue à utiliser des
outils de restitution propriétaires, « parfaitement adaptés à nos besoins », explique
Michael Benzinger.
De son côté, Swissport utilise Hyperion comme outil de restitution sur l'un de ses projets
et MySQL pour stocker les données. L'entrepôt est alimenté par une moulinette Java
« bientôt remplacée par l'ETL open source de Talend », explique Uwe Geercken. Bien
qu'ils soient faciles à mixer avec des outils propriétaires, les outils open source possèdent
quelques particularités à prendre en compte.
« Ils intègrent moins d'assistants, mais de plus en plus de démonstrations complètes à
partir desquelles on peut démarrer son projet, note Jean-Michel Bras. Ces outils offrent
des perspectives nouvelles, notamment dans le prototypage rapide des bases de
données », ajoute-t-il. Un point de vue partagé par le SGAR. « Il facilite le prototypage
tant au niveau des données que de l'interface utilisateur », confirme Philippe Ourliac.

Que le projet soit propriétaire, open source ou mixte, sa mise en oeuvre répond aux
mêmes étapes : « Définition des besoins fonctionnels, création du datamart [modèle en
étoile, NDLR], alimentation via un ETL, restitution des informations et indicateurs au sein
des interfaces choisies en fonction des utilisateurs, en accès statique et dynamique »,
énumère Jean-Michel Bras, d'Aexxdis.
Et le pragmatisme est de rigueur en termes d'architecture. « Notre ETL transfère les
données de la base de production [Oracle, NDLR], la nuit dans notre entrepôt de données
[MySQL, NDLR], car nous n'avons, pour l'instant, qu'un seul fuseau horaire à gérer »,
illustre Frédéric Jourden, de Xinek.
Les ressources nécessaires : faire appel à un spécialiste
Mis à part Swissport et Sabre qui possèdent un service informatique important, toutes les
PME font appel à un ou plusieurs prestataires. Le SGAR s'est appuyé sur Altic qui possède
à la fois des compétences en décisionnel (modélisation en étoile, etc.), et maîtrise les
outils open source associés. Même démarche pour Xinek qui a fait appel à Smile. Aexxdis
est passé par deux prestataires : Carra Consulting pour la maîtrise d'oeuvre et la
conception du projet, et Code Lutin pour sa réalisation.
« Nous voulions aller vite. Or, on ne s'improvise pas expert en décisionnel open source »,
résume Jean-Michel Bras, d'Aexxdis. Son projet s'est déroulé au forfait pour éviter toute
surprise budgétaire. « Nous n'avons eu qu'à budgéter l'application et participer aux
derniers réglages. Une solution efficace, confortable, avec des coûts maîtrisés », estimet-
il.
Aujourd'hui, pour cette entreprise, une journée/homme par mois suffit pour la
maintenance technique et applicative. Elle dispose, en revanche, de bonnes compétences
Java/JavaEE en interne, base de tous les outils décisionnels open source. « Le plus
difficile dans un projet décisionnel, c'est de modéliser la structure de données de
l'entrepôt », explique Frédéric Jourden, de Xinek.
C'est en effet à ce niveau que les choix métier les plus importants ont lieu : quelles
données de production conserver ou non ? Quels axes métier retenir pour le modèle en
étoile ? Etc. Autant de questions qui nécessitent de monopoliser des ressources en
interne. C'est pourquoi, de plus en plus de prestataires et d'entreprises privilégient un
mode itératif. « Notre projet a débuté fin 2005 et se poursuit toujours », illustre Jean-
Michel Bras.
Quant au budget, il est essentiellement constitué des coûts de conseil, de réalisation et
de production. Il est très variable selon les projets. Le projet de Xinek a, par exemple,
nécessité 100 jours/homme au total (50 000 euros) pour créer trois cubes et dix-neuf
rapports statiques sous Pentaho et MySQL.
Les Ecueils : l'engagement des utilisateurs
Globalement, les entreprises rencontrent peu de problèmes techniques lors de la mise en
oeuvre des projets. En revanche, les prestataires open source spécialistes du décisionnel
et les spécialistes du décisionnel utilisant des outils open source sont encore rares.
Heureusement, les logiciels se démocratisent vite. A l'image d'Anaska, plusieurs
organismes proposent déjà des programmes de formation, sur l'ETL open source de
Talend par exemple.
De toute façon, « les principaux écueils ne sont pas techniques, mais humains :
nouveauté pour les utilisateurs, compréhension des concepts de l'informatique décisionnelle, mise au point d'indicateurs métier pertinents, etc. », rappelle Philippe
Ourliac. « La personnalisation d'une solution open source demande un certain
engagement que les utilisateurs ne sont plus forcément prêts à faire. Ils ont pris de
mauvaises habitudes avec des solutions déjà packagées », complète-t-il.

[FONT=Courier][COLOR=blue]

La conduite d’un projet en Business Intelligence suit les règles classiques de la conduite d’un
projet informatique. Nous soulignons ici un ensemble de points particulièrement sensibles, à
l’origine de la plupart des défaillances et échecs de projets d’informatique décisionnelle :
• L’ambition des projets dès leur première édition est souvent trop élevée, avec des
projets trop complexes voulant à la fois reprendre l’existant et ajouter de nombreuses
nouvelles fonctionnalités. Un entreprise dispose toujours de rapports (même parfois
très fastidieux à produire) avant l’arrivée de la Business Intelligence. Si les utilisateurs
ont des difficultés a recevoir des résultats équivalents à l’existant avec le passage à la
Business Intelligence lors de la première mise en place, l’insatisfaction sera élevée. Il est
toujours préférable de suivre une démarche itérative : Réaliser un premier lot de
services moins ambitieux mais qui aboutit en quelques mois, puis enrichir
progressivement et en continu les services apportés. Il y a parfois loin entre le discours
et la mise en pratique de démarches itératives.
• L’expérience et la compétence de l’équipe. Même si la conduite de projet suit des
règles classiques, quelques expériences spécifiques sur le décisionnel sont souvent
essentielles dans une équipe projet. Modéliser un système décisionnel ne s’improvise
pas et peut être particulièrement complexe et spécifique.
• L’expression de besoins manque parfois de précision. Les indicateurs demandés restent
parfois trop « macroéconomiques ». Par exemple, définir l’indicateur « Chiffre
d’Affaires » ne définit pas pour autant les règles de gestion nécessaires pour obtenir
cet indicateur, avec le traitement de ses exceptions et de ses parfois nombreux cas
particuliers. Il ne faut pas oublier que le système décisionnel joue un peu un effet de
loupe sur le système d’information général. On va retrouver dans le système
décisionnel des difficultés attachées au système d’information lui-même, incohérences
en terme de données… Ces difficultés apparaissent souvent au moment de la recette du
système décisionnel et sont souvent attachés à une faiblesse de l’expression des
besoins détaillée.

Le but de l'OLAP (On-Line Analytical Processing) est de permettre une analyse multidimensionnelle sur des bases de données volumineuses afin de mettre en évidence une analyse particulière des données (il est l'objet d'un questionnement particulier).
Grâce à l'OLAP, les utilisateurs peuvent créer des représentations multidimensionnelles (appelées hypercubes ou « cubes OLAP ») selon les critères qu'ils définissent afin de simuler des situations
DW : ensemble de donnees (internes et externes) d’entreprise accessibles par les utilisateurs à travers les vues « metier ».
Son rôle : transformer les donnees en information , générer du nusiness.
Le data werhousse permet de :
Réagir plus vite que la concurrence
Prendre des décisions justes
Mieux contôler les côuts et les risques
Elargir l’offre
Cibler mieux le client
Choix typologique
DW virtuel
Lot des data Marts
DW sans accées utilisateur
Accées directe à DW et certains DM
Comment faire
Top-Down
Bottom-up
Hybride(mixte)
Difficultés
Données hétérogènes (multitude d’environnements techniques ,de structures, de formats)
Différents règles de gestion
Différents niveaux de synchronisation
Différentes plages de disponibilité
Mythes
DW contient seulement des données agrégées.
DW contient toutes les données d’entreprise.
DW doit être construit d’un seul coup
DW est massivement utilisé
DW n’est plus utilisé après le changement du business

2 Composants constituant un datawarehouse
Les composants de la majorité des entrepôts de données sont expliqués ci-dessous.



2.1 Données sources
Les data sources se rapporte à n'importe quel dépôt d'information qui contient des données d'intérêt à l'utilisation ou à l’analyse de gestion. Cette définition couvre les bases de données d'unité centrale (par exemple IBM DB2, ISAM, Adabas, Teradata, etc.), les bases de données de serveur de client (par exemple Teradata, IBM DB2, base de données d'oracle, Informix, serveur de Microsoft SQL, etc.), les bases de données de PC (par exemple Microsoft Access, Alpha, Five), les tableurs (par exemple Microsoft Excel) et n'importe quel autre stock électronique de données. Des données doivent être passées de ces systèmes à l'entrepôt de données sur une base de transaction-par-transaction pour les entrepôts en temps réel de données ou sur un cycle régulier (par exemple quotidiennement ou hebdomadaire) pour les entrepôts de données hors ligne.

2.2 Transformation de données
La couche de transformation de données reçoit des données des points d'émission de données, les nettoie, les normalise, et les charge dans le répertoire de données. Ceci s'appelle souvent les données d'"échafaudage" pendant que les données traversent souvent une base de données provisoire tandis qu'elles sont transformées. Cette activité des données de transformation peut être exécutée ou par code manuellement créé ou par un type spécifique de logiciel. Indépendamment de la nature du logiciel utilisé, les types suivants d'activités se produisent pendant la transformation de données :

- comparer des données de différents systèmes pour améliorer la qualité des données : par exemple la date de naissance pour un client peut être blanc dans un système mais contenir des données valides dans un deuxième système. Dans ce cas, l'entrepôt de données maintiendrait la date de naissance la zone du deuxième système.

- normalisant des données de différents systèmes par exemple si un système se rapporte au "mâle" et à la "femelle", mais une seconde se rapporte seulement à "M" et à "F", ces codes devraient être normalisés)

- exécutant d'autres fonctions de ménage de système telles que fichiers de détermination de changement (ou les "delta") pour réduire les moments de chargement de données, produisant ou trouvant des clés de remplacement pour les données etc...

2.3 Le datawarehouse
L'entrepôt de données est généralement une base de données relationnelle. Il doit être organisé pour tenir l'information dans une structure que les supports questionnent. La plupart des entrepôts de données tiennent l'information pendant au moins 1 année et parfois peuvent atteindre demi de siècle, selon la condition de conservation de données de définie par l’entreprise. En conséquence ces bases de données peuvent devenir très grandes.

2.4 Rapports de données
Les données dans le datawarehouse doivent être à la disposition du personnel de l'organisation, exemple la force de vente. Il y a un nombre très grand nombre d'applications qui exécutent cette fonction. Exemple de logiciel de reporting:

- Business Intelligence Tools : Applications qui simplifient le processus de rapport de données basé sur le datawarehouse. Exemple : Brio Designer, Hyperion Intelligence

- Outils OLAP : OLAP traite les données dans les structures multidimensionnelles et permet aux utilisateurs de choisir quelles dimensions ils désirent pour la visualisation

- Les outils d'extraction de données : sont des logiciels qui permettent aux utilisateurs d'exécuter des calculs mathématiques et statistiques détaillés sur des données détaillées de datawarehouse pour détecter des tendances,
identifier des configurations et analyser des données.

Pour alimenter une base à partir d’une variété de référentiels dans l’entreprise, on utilise une gamme d’outils appelés ETL,pour « Extract, Transform, Load ».
Comme le nom l’indique, ces outils permettent d’extraire des données à partir de différentes sources, de les transformer légèrement, et de les charger dans une nouvelle base, qui sera ici le datawarehouse.
Un ETL permet d’éviter la réalisation de programmes batch répétitifs, souvent semblables, dont il faudra également assurer la maintenance. Le principe est que l’intégration d’un nouveau flux de données ne requiert aucun développement, et s’opère par une simple configuration interactive : on choisit les éléments de données dans la référentielle source, on les transformations simples qu’ils doivent subir, et on la destination de la donnée dans le datawarehouse.

Cycle de vie d'un ETL

Kettle est un ETL open source qui permet de concevoir et exécuter des opérations de manipulation et de transformation de données.
Grâce à un modèle graphique à base d’étapes, il est possible de créer sans programmation des processus composés d’imports et d’export de données et de différentes opérations de transformation, telles que des conversions, des jointures,l’application de filtres, ou même l’exécution de fonctions javascript.
Kettle est devenu open source à partir de la version 2.2 et a rapidement intégré le projet de plateforme décisionnelle Pentaho qui l’a renommé depuis en Pentaho Data Integration.

• Les transformations : traitements effectués au niveau d'une ou plusieurs bases de données comprenant des opérations de lecture, de manipulation et d'écriture.
• Les tâches : traitements de plus haut niveau, combinant des actions telles que l'exécution d'une transformation
Kettle peut se connecter sur un grand nombre de bases de données, dont Oracle, Sybase, MySQL, PostgreSQL, Informix ou SQLServer et peut également utiliser des données provenant de fichiers textes, XML et Excel.
Les transformations et les tâches sont créées par ‘glisser déposer’ des différentes étapes du processus. Des assistants sont disponibles à chaque étape et permettent par exemple de générer automatiquement les requêtes de lecture et de création de tables.

Kettle se compose de 3 applications :
• Spoon : environnement graphique de création et d'exécution de transformations et de tâches.
• Pan : application en ligne de commande permettant de lancer l'exécution d'une transformation donnée.
• Kitchen : application en ligne de commande permettant de lancer l'exécution d'une tâche donnée.
Pan et Kitchen sont utilisées pour planifier l’exécution des transformations et des tâches.

 Dans le contexte de l'aide à la décision, Kettle va servir à constituer un datawarehouse, en réalisant l'importation des données depuis différentes sources, leur consolidation et leur mise en forme.
 L'utilisation de Kettle présente plusieurs avantages par rapport à des solutions à base de scripts:
 La création de flux de données complexes est extrêmement simple
 La maintenance est beaucoup plus aisée car tous les flux de données sont visibles d'un simple coup d'oeil.
 Kettle pourra également trouver sa place dans tout projet non décisionnel qui a besoin d'exécuter périodiquement des traitements sur certaines données ou des synchronisations entre différentes bases.