feat: new article datawarehouse

Co-authored-by: margauxEscande <margaux.escande@itsonus.fr>
Co-committed-by: margauxEscande <margaux.escande@itsonus.fr>

src/_pages/blog/article/ecoconception_et_datawarehousing.md

@@ -0,0 +1,58 @@
+---
+title: Quelle est la place de l'écoconception dans la datawarehousing ?
+description: TODO
+date: 2023-01-09
+tags:
+  - écoconception
+  - datawarehouse
+
+authors:
+  - Damien Marzlin
+  - Margaux Escande
+draft: true
+layout: article.njk
+---
+
+*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. Il est actuellement en mission chez Auchan.*
+
+## Pour commencer Damien, peux-tu nous expliquer ce qu'est la datawarehouse ?
+
+C'est 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
+
+La datawarehouse est un service numérique. 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 peuvent et je dirais même doivent être écoconçues.
+
+## A quoi faut-il penser pour les écoconcevoir ?
+
+**Questionner le besoin**
+
+La 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 aussi, on produit des rapports journalier alors qu'un rapport hebdomadaire aurait suffit.
+
+**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-Premises on n'a plus de contrainte et donc on se pose moins de question. C'est donc 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 la datawarehouse. En revanche, régulièrement je vois des requêtes du type "select * from .." (comprendre "récupère toutes les données") et seulement ensuite on filtre pour récupérer une infime partie. Pas besoin d'être informaticien ou informaticienne pour comprendre le problème. Ou encore, je vois la création de tables intermédiaires pour calculer des tables intermédiaires et ensuite calculer. Cela se traduit par une grande quantité de lignes de code et donc de la puissance machine inutile.
+
+De plus, comme nous perdons la maîtrise de ce qui est fait par ces différents services, nous ne sommes plus en mesure d'évaluer correctement les impacts environnementaux de cette activité.
+
+## Comment éviter la dérive ?
+
+**Un projet de datawarehousing, n'est pas 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. Simplement demander 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. 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és c'est d’**avoir un spécialiste en modélisation de données et en requêtage et de la 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 datawarehouse](https://www.itsonus.fr/nos_services/reduire_impacts_numerique/), découvrez notre offre de service et contactez nous.
+
+Vous pouvez également vous appuyer sur les 74 bonnes pratiques et si vous utilisez des services cloud, voici des informations pour [Google](https://cloud.google.com/carbon-footprint?hl=fr#section-6) et pour [Microsoft](https://www.microsoft.com/fr-fr/sustainability/emissions-impact-dashboard?activetab=pivot_2:primaryr12)