Histoire d’un datawarehouse

21 mars 2003

Elseneur [1] est une grande entreprise de services qui a envisagé, en 1996, de se doter d’un datawarehouse à finalité commerciale (voir "Le système informatique d'aide à la décision"). Ce premier projet était destiné à fournir à la force de vente les moyens d’évaluer les parts de marché et de fournir au marketing un outil d’analyse du comportement des clients susceptible d’alimenter la segmentation.

Les sources disponibles étaient des données détaillées fournies par les médiateurs actifs sur ce marché et les commandes des clients. L’enjeu était d’alimenter des analyses : positionnement concurrentiel de l’entreprise ; comportements d’achat ; effets de la fidélisation ; qualité du service ; rentabilité des campagnes marketing ; segmentation des clients ; ventes en partenariat ; canaux de distribution, etc.

Il existait à Elseneur un ou plusieurs infocentres [2] pour chaque application opérationnelle, mais ils étaient cloisonnés, peu ergonomiques, peu évolutifs, et ne répondaient pas à tous les besoins.

L’exploitation des commandes des clients supposait que l’on sût identifier le client. C’est facile s’il est abonné ; sinon, il faut estimer son identifiant à partir des éléments d’identification qu’il fournit éventuellement lors de la commande (nom, prénom, nom de l'entreprise, numéro de téléphone, numéro de la carte bleue etc.). La construction du référentiel des clients était donc une affaire délicate.

Les utilisateurs potentiels du datawarehouse étaient les personnels des directions régionales, ceux qui mettent au point les contrats avec les clients, ceux qui définissent la politique en matière de prix, le marketing, les économistes etc.

Une première tentative a échoué : les spécifications manquaient de précision et l’entreprise n’avait pas accordé les moyens nécessaires pour passer à la réalisation. Le projet de datawarehouse était plus verbal que pratique. 

Il fut relancé par une autre équipe en 1997. Il a démarré effectivement en 1998, la mise en service débutant en 2002. Le datawarehouse commercial d’Elseneur aura finalement coûté de l’ordre de 25 millions d’euros. Il est destiné à plus de mille utilisateurs internes à l’entreprise. On doit prévoir de l’ordre de 10 000 connexions par semaine à terme. Le datawarehouse commercial est aujourd’hui considéré comme une des réussites du SI d’Elseneur.

La solution technique articule plusieurs progiciels : l’un pour les extractions et les traitements, un autre pour la production des tableaux, enfin un SGBD. La « base détail » du datawarehouse est alimentée par les applications opérationnelles ; des agrégats sont produits selon les nomenclatures que fournissent les référentiels.

L’exploitation du datawarehouse est une usine informatique. Elle demande chaque mois 80 heures de CPU pour le traitement mensuel, 120 pour le traitement hebdomadaire, 200 pour le traitement quotidien. La base de données occupe 2 téraoctets et utilise 1 000 tables de référence. Le traitement comporte chaque mois  200 passages de chaînes différentes : il faut les orchestrer, traiter les alertes, réaliser des reprises etc. Pour maîtriser cette usine, il a fallu concevoir une « chorégraphie » des opérateurs précise et bien minutée. Les programmeurs ont donc dû s’astreindre à produire un code exploitable et bien documenté.

La réalisation

La longueur du délai de réalisation s’explique par certaines difficultés : la direction du projet à la maîtrise d’œuvre a été d’abord déficiente. Pendant un an et demi elle a piétiné en produisant des développements jetables. Le chef de projet ambitionnait d’organiser la production à la place des opérateurs ; les scripts ne comportaient pas de points de reprise, ce qui impliquait de tout refaire chaque fois que l’on rencontrait une difficulté. Il a fallu par la suite, après un changement de responsable, tout reconstruire sur des bases plus solides.

Cependant l’informatique s’est enlisée en s’efforçant d’assurer une large couverture fonctionnelle tout en stabilisant la technique. La maîtrise d’ouvrage a exigé en 2001 un « moratoire » du développement : il fallait cesser de développer de nouveaux modules tant que les modules existants n’étaient pas en état de marche. Ce moratoire a donné un coup d’arrêt à la fuite en avant et mis l’informatique au défi de réussir en se concentrant sur la stabilisation de l’existant.

Les opérateurs ont eu d’abord un réflexe de recul devant l’utilisation de progiciels qui étaient nouveaux pour eux. Il a fallu, avec l’accord du directeur de l’informatique, instaurer une relation directe entre la maîtrise d’ouvrage et les opérateurs. Cette relation a été finalement bien appréciée par les opérateurs et elle a permis de débloquer la situation. Aujourd’hui la production est en place, le taux d’erreur est nul, les opérateurs sont fiers du succès de l’opération.

Il était prévu de ne déployer le datawarehouse que sur des PC « lourds » dont étaient dotés les analystes mais cela a posé des problèmes pour la télédistribution. Sur ces PC « lourds » il était d’ailleurs difficile de faire cohabiter le datawarehouse avec d’autres applications. Ces questions ont été résolues par la suite en offrant un accès par le PC « léger » et standard de l’entreprise.

Ainsi le volume de l’application, conjugué au manque de maîtrise des technologies, a retardé sa mise en œuvre jusqu’au début de 2002. Ce retard a suscité une perte de confiance des utilisateurs auxquels on avait annoncé une mise en place en deux mois ( ! ). Comme toujours pendant qu’un projet est bloqué, les MOA se sont activées à peaufiner les spécifications et il en est résulté une surenchère des demandes fonctionnelles. 

En outre la lenteur de la réalisation a incité des analystes à fournir aux utilisateurs des CD-Rom contenant les données sur les parts de marché retraitées : ce n’était qu’une solution partielle, mais elle a occupé le terrain pendant un temps et risqué de démobiliser les énergies consacrées au datawarehouse.

Définition fonctionnelle

L’alimentation

Le datawarehouse est alimenté par plusieurs sources[3]. Il ne peut fonctionner que si les applications qui l’alimentent fonctionnent, ainsi que le processus d’alimentation. Son alimentation à partir des diverses applications doit donc être sécurisée. Un des apports indirects du datawarehouse est de rendre visibles les défauts des applications qui l’alimentent et d’inciter ainsi à les corriger. La correction des données incombe aux applications opérationnelles ; cependant la maîtrise d’ouvrage du datawarehouse était aussi celle des applications commerciales : elle a donc pu assumer elle-même la responsabilité de la qualité des sources.

Les traitements

Les données que fournit le datawarehouse sont brutes, sans redressement ni correction des anomalies (erreurs, données manquantes) qui peuvent exister dans les sources. Si une anomalie est détectée, il est demandé à l’application source de la corriger. La maîtrise d’ouvrage estime en effet qu’il n’appartient pas au datawarehouse de corriger les erreurs des sources, de corriger les doublons etc.

Elseneur tolère dans ses applications opérationnelles jusqu’à 2 % de doublons et cette tolérance s’applique donc aussi au datawarehouse. Un datawarehouse qui traite les données concernant 5 millions d’individus sous diverses périodicités (mensuelle, hebdomadaire, quotidienne) doit être de type industriel. Ce datawarehouse non corrigé vise à assister les décisions opérationnelles. Les économistes qui voudront l’utiliser pour leurs études devront, si nécessaire, redresser eux-mêmes les données.

Les spécifications

Le datawarehouse ne procède pas par croisement entre les diverses sources, sauf en ce qui concerne les clients et les recettes : chaque source est exploitée pour elle-même, séparément des autres sources.

Le datawarehouse a été réalisé et mis en service progressivement, après avoir été découpé en 40 modules tous exploitables. Un chantier de cohérence a été mené parallèlement à la réalisation des modules qui doivent tous utiliser les mêmes référentiels et la même méthode de conduite du changement (déploiement, formation, FAQ etc.)

Les utilisateurs ont tendance à tout demander parce qu’il leur est difficile d’expliciter ce qu’ils attendent du datawarehouse ; le risque est alors qu’une forte proportion des tableaux produits ne soit jamais utilisée. Pour la version 1, on a donc d’abord défini pour chaque module au plus dix tableaux ; puis on a défini l’univers de données qui permettra de les produire (une fois cet univers défini, il permet en général de produire aussi quelques autres tableaux). On procède ainsi à l’inverse de la démarche qui construit d’abord un hypercube puis le met à disposition.

Les utilisateurs peuvent, s’ils ont besoin de tableaux non prévus, demander que l’on exécute des requêtes : l’expérience montre que cette possibilité est peu utilisée. Une version 2 du module sera si nécessaire réalisée après un an pour corriger les lacunes de la version 1.

Le datawarehouse d’Elseneur ne comporte pas d’hypercube. a d’abord travaillé avec un progiciel qui construit des hypercubes ; mais ce produit n’est plus maintenu et les hypercubes posaient des problèmes de  volumétrie et de stabilité de la chaîne d’exploitation. Il a été décidé d’utiliser un autre progiciel qui produit des tableaux et exécute des requêtes, mais ne fournit pas d’hypercube.

Faut-il regretter les hypercubes ? Les utilisateurs les trouvaient compliqués, et l’on estime à Elseneur que les éditeurs qui faisaient des hypercubes y ont renoncé.

La définition des règles de gestion a été l’un des points délicats des spécifications fonctionnelles. Quand on veut construire des séries chronologiques, il faut en effet répondre à des questions du type : « le chiffre d’affaires doit-il tenir compte des ristournes ou non ? », traiter les effets de change, savoir comment traiter les contrats dont dépendent des prix spécifiques etc.

Les référentiels

Auparavant Elseneur n’avait de référentiel que pour ses produits. Les référentiels mis en place par le système d’information pour les clients (qu’il s’agisse d’individus ou d’entreprises) et pour les distributeurs ont été un atout crucial pour la réalisation du datawarehouse.

Une partie du travail était déjà faite : les identifiants des distributeurs étaient déjà définis. Pour identifier les entreprises françaises, Elseneur a retenu le numéro SIRET ; pour les individus et les entreprises étrangères, l’identifiant est généré par le système.

Le traitement des changements de périmètre est assuré par des mécanismes de réaffectation de portefeuille et de reprise d’historique.

Nota Bene : On ne sait pas traiter le rattachement d’un individu à une entreprise. Il s’agit en effet d’un lien déclaratif. Comment le tenir à jour ? quels en seraient les usages ? quels seraient les droits qui lui seraient attachés ? si une entreprise achète des services pour un consultant en mission auprès d’elle, à quelle entreprise rattacher cet individu ? le rattachement d’un individu à une entreprise pose non seulement des problèmes techniques, mais des problèmes conceptuels qui n’ont pas de réponse actuellement ; il serait vain de s’acharner à l’informatiser.

La suite

Il reste à achever la mise en place du datawarehouse commercial ; puis Elseneur pourra envisager la réalisation d’un datawarehouse d’entreprise, étendu aux fonctions production, maintenance, GRH, finance, stratégie.

Elseneur envisage de compléter la solution actuelle en ajoutant les progiciels SAS pour des analyses de données et SAP pour les analyses financières. Il sera également envisageable de construire des datamarts spécifiques par extraction du datawarehouse d’entreprise.