Introduction

Une étude[1] réalisée, pour le compte de l’éditeur Report One, en 2013, soit il y a plus de dix ans, posait le cadre de l’usage de l’informatique décisionnelle en PME. L’étude en question mettait en évidence un marché en progression de 30% par an entre 2008 et 2013. Une appétence forte donc pour ce domaine mais, comme le souligne l’enquête « le phénomène [restait] nouveau et il [fallait] encore démocratiser l’outil ».

Par ailleurs, et c’est peut-être le point qui nous intéressera le plus dans cette série d’articles, car il explique, en partie du moins, l’origine du projet décisionnel sur lequel nous allons nous attarder, « Les solutions historiques comme Business Object, […] etc. sont trop compliquées pour ces entreprises ».

En effet, en 2014, donc peu de temps après la publication de l’enquête susmentionnée, la société que nous nommerons Pythagore Immobilier, bénéficie d’un système d’information relativement mature en matière d’outils de gestion. Ainsi, dans la mesure où la plupart des processus métier sont informatisés et que, par conséquent, les informations relatives à ces différents processus sont stockées dans les bases de données, il apparait prégnant pour certaines directions d’exploiter au mieux cette matière première, de transformer la donnée en information puis l’information en connaissance, de se doter d’un système d’aide à la décision. Nous voilà dans le creuset de l’informatique décisionnelle au sein de Pythagore Immobilier. Un creuset dont le but est de transformer les données en indicateur clé de performance (KPI : Key Performance Indicators), pierres angulaires de la prise de décision.

Dans le domaine de l’informatique décisionnelle ces indicateurs clé de performance peuvent, comme le précise l’étude précitée, être le fruit des solutions « du marché » telles que Business Object, Power BI ou Tableau, pour ne citer qu’elles. Mais nous verrons que certains utilisateurs souhaitent des outils plus interactifs, plus dynamiques, plus « simples » et surtout, totalement alignés sur leur perception du sujet et leur façon d’explorer les informations, en d’autres termes des outils spécifiques.

Telle fut le cas au sein de Pythagore où la direction commerciale, qui, au lancement du projet, englobe également la communication et le marketing, a rapidement rejeté l’hypothèse de la solution Business Object, pourtant utilisée par d’autres services, et a plébiscité une solution développée en interne.  

L’idée du portail de restitution de données est ainsi née et avec cette idée c’est une architecture décisionnelle complète qui s’enracinera progressivement dans le système d’information de Pythagore Immobilier.  

L’objectif initial du projet auquel nous allons nous intéresser était de mettre à disposition de la direction commerciale un système d’aide à la décision et de suivi facile à prendre en main permettant de couvrir les 5 rapports / tableaux de bords faisant partie de « l’expression des besoin » initiale.  Nous verrons que le périmètre final du projet sera bien plus vaste.

De nouveaux besoins fonctionnels, impératifs techniques et l’évolution perpétuelle du système d’information, viendront très rapidement et régulièrement, tout au long de ces 10 années du projet, alourdir celui-ci et occasionneront quelques versions que nous pouvons qualifier de majeures et de très nombreuses versions mineures.

A travers cette série d’articles nous tenterons de nous interroger sur la pertinence de la mise en œuvre d’un outil spécifique de restitution de donnée, développé en interne, au sein d’une PME. Nous essayerons également d’analyser les différentes problématiques techniques et humaines qui en découlent ainsi que les avantages et inconvénients d’un tel système. Par ailleurs il nous a semblé pertinent de mettre en lumière l’aspect mouvant d’un système d’aide à la décision qui évolue en fonction des adaptations continues du système d’information.

C’est, nous semble-t-il, la richesse principale de ce travail : nous offrir un recul nécessaire pour analyser l’impact de près de 10 ans d’ajustements, de modifications, de changements, qu’ils soient organisationnels, techniques ou fonctionnels sur une architecture décisionnelle.

Dans la première partie nous souhaitons avant tout définir le cadre général de ce projet puis aborder de manière relativement détaillée la réponse immédiate à ce besoin naissant d’outil de restitution de données, outil qui a été conçu et produit, comme nous le verrons, « en temps masqué » mais qui devait néanmoins être déployé « le plus rapidement possible ». Afin de répondre « le plus rapidement possible » à un besoin peu détaillé, non documenté, non formalisé, flou, en constante évolution nous verrons que la maitrise d’œuvre du projet a dû faire des choix radicaux et aller à l’essentiel en matière de stockage de données nécessaires au système décisionnel, par exemple, en mettant en œuvre un infocentre.

Comme nous le constaterons cette réponse immédiate sera un véritable succès d’un point de vue fonctionnel, mais ce succès fonctionnel et l’adhésion forte des salariés au portail de restitution, développé par la direction des systèmes d’information, qui s’enrichira progressivement d’un grand nombre de fonctionnalités, mettra également en évidence les limites du système déployé ainsi que celles de la gestion du projet en elle-même. L’une des limites sera le temps. En effet la gestion d’un projet en « temps masqué » a des conséquences, des conséquences sur la qualité intrinsèque
de ce qui est livré mais surtout des conséquences en matière de risque.

La deuxième partie sera ainsi consacré d’une part aux différentes évolutions fonctionnelles et d’autre part aux évolutions techniques indispensables pour faire face aux problématiques naissantes. En effet ce projet, conduit au départ de manière « confidentielle », sortira, dès le déploiement des rapports prévus dans le périmètre initial, de sa confidentialité. De nouveaux services souhaiteront bénéficier du portail de restitution. L’architecture décisionnelle ainsi produite s’ouvrira très rapidement à d’autres domaines de l’entreprise : la direction des ventes, le « top management », la comptabilité ou encore le contrôle de gestion. En parallèle de ces évolutions fonctionnelles, l’utilisation de plus en plus large du portail fera surtout apparaitre les limites des choix techniques, en matière d’entreposage de données notamment, de la première version. Une évolution technique s’imposera alors et se traduira par la mise en œuvre d’un « entrepôt de données ».

La troisième partie sera ainsi essentiellement consacrée à la conception et la mise en production d’une telle architecture grâce à SQL Server Intégration Service puis sa migration vers la solution Talend. Nous nous interrogerons ici sur la légitimité au sein de Pythagore Immobilier du terme « entrepôt de données » communément utilisé pour désigner la collection de données mise en œuvre. Une collection de données qui se rapproche, peut-être, davantage d’un magasin de données. Quoi qu’il en soit, il sera question d’une architecture de stockage de données spécifique qui devra permettre la direction des systèmes d’information de Pythagore de répondre aux très lourdes problématiques de performance du portail décisionnel.

Enfin, la dernière partie nous donnera l’occasion de mettre en évidence une forme de culture du « développement web – métier » qui s’est progressivement imposé à la DSI de Pythagore, culture directement issue des différents travaux effectués sur le portail de restitution. Une culture qui permettra à la DSI de faire face aux très nombreuses évolutions organisationnelles, ainsi que de produire de nombreux modules supplémentaires dédiés à informatique décisionnelle. Des modules de suivi, d’extraction de données, de contrôle qui répondront aux besoins nouveaux qui seront le fruit d’évolutions organisationnelles propres à la société ou bien qui seront les conséquences du rachat récent de la société Pythagore Immobilier par le groupe Platon. Un rachat qui aura de très nombreuses conséquences en matière d’extraction, de chargement et de restitution de données et qui donnera à l’« entrepôt de données » une place de plus en plus centrale. C’est pour cette raison
qu’il nous a semblé opportun, en fin de cette partie, de mettre en évidence le rôle majeur de la couche « stockage de données » dans une architecture d’aide à la décision. En effet nous verrons que le rôle d’un entrepôt de données n’est, peut-être, pas uniquement d’accélérer les traitements pour améliorer les performances. Son rôle est peut-être aussi (surtout ?) de structurer les données pour devenir un véritable pivot, une véritable pierre angulaire, qui, comme le précisent J. Akoka, I. Comyn-Wattiau et N.Prat, « permet de faire face aux changements du marché et de l ’entreprise ».