Conception : Spécifications des restitutions (ce que j’envisage de vous proposer)
- Introduction
- Cadre général du projet décisionnel
- Conception : Étude Préalable
- Conception : Collecte des besoins (spécifications très peu détaillées)
- Conception : Analyse des besoins
- Conception : Analyse des indicateurs
- Conception : L’importance de la qualité des données
- Conception : Spécifications des restitutions (ce que j’envisage de vous proposer)
« J’ai l’impression d’avoir compris votre besoin, je suis en mesure d’extraire toutes les données dont vous avez besoin et voilà comment j’imagine le rapport final » … Tel pourrait être le titre de ce chapitre. La spécification des restitutions est une phase importante dans le développement logiciel et peut être à plus forte raison encore dans un projet d’informatique décisionnelle ; la restitution en elle-même étant centrale dans ce type de projets.
Compte tenu de l’aspect quelque peu répétitif des différents rapports qui ont été maquettés nous n’allons pas détailler le contenu des différentes maquettes, contenu qui a déjà été abordé dans les phases précédentes. L’objectif est ici surtout de d’évoquer brièvement la méthodologie utilisée pour la production des maquettes.
L’idée principale de cette phase est de rendre « palpable » le résultat que nous envisageons de produire. Aussi, dans cette phase du projet, étant donné le manque d’une expression des besoins précise et exhaustive, et malgré les différents échanges qui ont suivi la phase de collecte des besoins, il apparait important de se rapprocher le plus possible de cet attendu. Afin de tendre vers cet objectif l’ensemble des maquettes de cette première phase du projet ont été réalisées avec le logiciel NVU qui permet, via une approche WYSIWYG[1], de produire rapidement des pages html (voir la figure ci-dessous pour un exemple de maquette réalisée avec le logiciel NVU).
![](https://infonum.necara.fr/wp-content/uploads/2024/06/Exemple-de-maquette-realisee-avec-le-logiciel-NVU.png)
Les 5 pages HTML, représentant les 5 rapports initiaux, ainsi produites ont été présentées au groupe projet. Assez logiquement, compte tenu du nombre de « navettes » durant les phases précédentes, la structure des tableaux a été presque immédiatement validée à quelques réglages près notamment en termes de tri des lignes et des colonnes.
En revanche cette phase de présentation a élégamment fait naitre de nouveaux besoins : « plus d’interactivité et plus
d’immersion ! »
De manière plus concrète cela se traduit par les demandes suivantes :
- Au survol des différents champs de résultats (réservations, contacts), afficher la répartition par Responsable de compte.
- Ajouter 2 nouvelles icones pour chaque agence qui au survol permettront d’obtenir, pour l’agence en question, la répartition, par vendeur, des réservations et des contacts.
- Au clic sur l’origine, l’agence, le nombre de contacts et nombre de réservations afficher une nouvelle page de détail dont la structure, le contenu et les résultats seront variables en fonction du point d’entrée.
Un véritable sous-projet vient de naitre au sein même du projet tel qu’initialement défini. Ceci impacte fortement d’une part la complexité du projet et d’autre part les délais nécessaires à sa réalisation. Face à cette situation la maitrise d’œuvre propose ç la maitrise d’ouvrage l’allotissement du projet. Il s’agissait d’une approche pertinente qui permettait de traiter les nouveaux besoins dans une deuxième version. Cette proposition a été rejetée par la direction commerciale qui a souhaité avoir dès le départ une version complète du portail intégrant ces différentes fonctionnalités.
Il serait bien trop long est assez redondant d’exposer ici le travail d’analyse et de maquettage des nouvelles fonctionnalités demandées, dans la mesure où, du moins dans sa philosophie générale, il a été très similaire à ce qui a été exposé dans ces premières pages. Aussi nous aborderons ces points plus en détail dans la partie « Mise en œuvre ». Nous retiendrons à ce stade qu’un nouveau travail d’échange et de « navettes » entre la MOE, le webmarketing et la communication a permis d’obtenir, au bout de quelques semaines, un « go » définitif sur la phase de conception (toujours aussi informel) et de passer à l’étape plus technique et moins fonctionnelle qui a commencé par la mise en œuvre de l’architecture technique retenue, qui s’est poursuivi par les développements avec une présence forte des langages SQL et PHP et des sprints régulier en guise de validation et de tests.
Une nouvelle étape portée en toute autonomie par la maitrise d’œuvre avec une forte dose de confiance de la part de la MO.
Autonomie et confiance offrent souplesse et liberté mais dans le cas de ce projet, mené en « temps masqué », cela est également synonyme de charge quotidienne considérable pour le service informatique qui doit porter ce projet lourd et structurant en parallèle des différents chantiers déjà en cours. Cette situation entraînera des conséquences immédiates et lourdes sur la façon dont sera conduit ce projet de portail de restitution : seul le résultat comptera ! Elle fera également apparaitre de graves risques que nous verrons au dans le chapitre dédié.
![](https://infonum.necara.fr/wp-content/plugins/elementor/assets/images/placeholder.png)
Comme souvent les causes sont multifactorielles :
– Tout d’abord, de manière certainement un peu inavouée au départ, l’envie personnelle du RSI d’explorer le domaine de l’informatique décisionnelle par une voie différente, par une voie qui « permet aussi de montrer qu’en matière de restitution de données tout est possible, qu’il n’y a aucune limite, qu’en termes de présentation de données comme de leur extraction il est possible de tout faire pour se rapprocher le plus fidèlement possible des processus métier de l’entreprise et produire des outils « idéaux » qui correspondent à 100% au besoin, même si celui-ci s’affine tout au long du projet »: l’envie d’un challenge personnel en somme. »
– Le deuxième facteur majeur est celui de l’organisation générale de l’entreprise au moment du lancement de ce projet. Le service informatique était alors rattaché à la Direction Générale sans aucun lien hiérarchique avec la Direction Commerciale. Cependant le directeur commercial était, en même temps, l’un des actionnaires principaux de l’entreprise. Ainsi, le service informatique, dépendait dans les faits d’une direction bicéphale. Un premier cerveau animé par la raison un deuxième par l’innovation et l’agilité.