Quelle est la place de l'écoconception dans le datawarehousing ?

Pour y répondre, nous avons interviewé Damien Marzlin, membre du collectif IT’s on us. Damien est architecte d’entreprise, il accompagne les organisations dans la réduction des impacts environnementaux du numérique et forme à l’écoconception de services numériques.

Pour commencer Damien, peux-tu nous expliquer ce qu’est le datawarehouse ?

C’est un entrepôt de données : un endroit où une entreprise recueille beaucoup de données qui viennent de différentes sources. Ces données une fois collectées et mélangées, permettent d’en tirer une valeur analytique.

Les organisations peuvent être amenées à utiliser une datawarehouse pour les aider à prendre des décisions ou parce qu’elles sont contraintes par un cadre légal de fournir des rapports.

Par exemple, chez Auchan, nous devons produire une déclaration de performance extra-financière (DPEF) , nous croisons donc des données de ventes, RH, RSE, …

Quel est le lien entre datawarehouse et écoconception de services numériques ?

Le datawarehousing est un service numérique composé de logiciels, d’équipements utilisateurs, de centre de données, d’équipements réseau. Bien souvent, il y a plusieurs applications, car plusieurs domaines métiers, qu’il faut concevoir, développer et héberger. Aussi, dans un datawarehouse il y a plusieurs étages : un premier pour la collecte, un deuxième où on normalise la donnée, un troisième où on transforme la donnée en valeur et un dernier qui permet de visualiser. Ces applications répondent a un ou plusieurs actes métiers qui doivent être écoconçus.

À quoi faut-il penser pour les écoconcevoir ?

Questionner le besoin

Le datawarehouse produit des reporting, des KPIs … qui vont être utilisés par des gens. Il est important de questionner le besoin. Comme pour tous les projets informatiques, il faut donc s’assurer que ce qui est produit répond à un réel besoin utilisateur.

Bien souvent, je constate lors dans mes missions, que ce qui est produit n’est pas utile pour les équipes. Soit parce que dès le départ le projet est mal cadré, soit parce que le projet a pris trop de temps et l’information n’est plus nécessaire. Parfois, on produit des rapports journaliers alors qu’un rapport hebdomadaire aurait suffi.

Correctement requêter

Avant il fallait réfléchir à la bonne configuration des serveurs, mais depuis qu’on a des environnements cloud ou du On-Premise on n’a plus de contrainte et donc on se pose moins de question. C’est ainsi plus facile, techniquement possible et économiquement viable, de manipuler des téraoctets de données. Ce qui a pour effet de consommer beaucoup de RAM (mémoire vive ou mémoire à court terme) et de CPU (capacité de calcul).

De manière générale, je constate que les bonnes sources d’information sont récupérées dans le datawarehouse.
En revanche, régulièrement je vois des requêtes récupérant une grosse quantité de données pour ensuite les filtrer et/ou les transformer en dehors de la requête : directement dans le code du programme sans utiliser le moteur de requêtage. Ceci charge toutes les données et entraine donc une grosse montée en RAM. Le CPU est fortement utilisé également. Ces lourds traitements peuvent être évités en exploitant les capacités du serveur de base de données ; qui est prévu pour cela.

Comment éviter la dérive ?

Un projet de datawarehousing, n’est pas qu’un projet technique, il faut intégrer dans l’équipe, et dès le début, une personne responsable de l’expérience utilisateur. Son rôle sera de comprendre ce que vivent les utilisateurs (via des interviews, de l’observation par exemple) et d’identifier la problématique à laquelle il faut répondre. Se contenter de demander quel est le besoin des utilisateurs peut mener à un projet qui finalement ne sera pas utile. Si le projet est terminé, ce qui a été produit lui doit continuer à vivre. Il faut donc penser à mettre en place des points de contrôle après la mise en production, pour s’assurer de l’utilité réelle des évolutions fonctionnelles. Vous pouvez vous appuyer sur les équipes support de l’utilisation du datawarehouse. Quels sont les échanges qu’ils ont avec les utilisateurs? Sont-ils satisfaits ou non ? Vous pouvez également aller sur le terrain pour échanger et observer l’usage qui est fait ou encore envoyer une enquête de satisfaction à intervalle régulier.

Un autre point clé est d’avoir un spécialiste en modélisation de données et en requêtage et de le faire intervenir le plus tôt possible. C’est un savoir qui se perd, car cela attire moins les développeurs et développeuses. Il est important d’entretenir cette compétence. Si ce profil n’existe pas dans votre équipe, rien que le fait de faire des revues de code peut déjà apporter des bénéfices. Dans une équipe agile, on peut, par exemple, ajouter à la Definition Of Done (DOD) un critère comme « les requêtes SQL ne font pas de produit cartésien » ou encore « la manipulation de données parait nominale ». Finalement, on parle ici de qualité de code.

Si vous souhaitez commencer une démarche de réduction des impacts environnementaux de votre projet de datawarehousing, découvrez notre offre de service et contactez-nous.

Vous pouvez également vous appuyer sur le référentiel Green IT : 74 bonnes pratiques clés pour un numérique plus responsable.