Module 2 : Analyse des besoins utilisateurs

2.1 Méthodologie d'analyse des besoins

L'analyse des besoins constitue la pierre angulaire de tout projet de pipeline de données réussi. Cette étape fondamentale permet d'aligner les solutions techniques avec les attentes réelles des utilisateurs finaux, évitant ainsi le développement de systèmes sophistiqués mais inadaptés. Dans le contexte des pipelines de données, cette analyse revêt une importance particulière en raison de la diversité des profils utilisateurs et de la complexité des cas d'usage.

La méthodologie d'analyse des besoins pour les pipelines de données s'articule autour de plusieurs techniques complémentaires. Les entretiens individuels avec les parties prenantes constituent généralement le point de départ de cette démarche. Ces échanges permettent d'établir une relation de confiance et d'explorer en profondeur les attentes, les contraintes et les frustrations des utilisateurs face aux systèmes existants. Pour être efficaces, ces entretiens doivent être menés avec une approche semi-directive, combinant questions ouvertes pour favoriser l'expression libre et questions fermées pour préciser certains aspects techniques. Il est crucial d'adapter le niveau de technicité du langage au profil de l'interlocuteur : un data scientist pourra discuter d'algorithmes et de formats de données, tandis qu'un manager métier s'exprimera davantage en termes d'objectifs business et d'indicateurs de performance.

Les ateliers collectifs complètent utilement les entretiens individuels en permettant la confrontation des points de vue et l'émergence d'un consensus. Des techniques comme le "design thinking" ou les "user story mapping" peuvent être particulièrement pertinentes pour structurer ces sessions et favoriser la créativité collective. Ces ateliers permettent également d'identifier les interdépendances entre les besoins de différentes équipes et de prioriser collectivement les fonctionnalités attendues.

L'observation des pratiques actuelles constitue une autre source précieuse d'informations. Observer comment les utilisateurs interagissent avec les systèmes existants permet de détecter des besoins implicites, souvent non exprimés lors des entretiens. Cette approche ethnographique révèle les contournements, les frustrations quotidiennes et les opportunités d'amélioration qui échappent parfois à la conscience des utilisateurs eux-mêmes.

L'analyse des documents existants (rapports, tableaux de bord, requêtes SQL fréquemment utilisées) complète ce dispositif en fournissant des indications concrètes sur les données effectivement exploitées et les transformations appliquées. Cette analyse documentaire permet également d'identifier le vocabulaire métier et les conventions de nommage en vigueur, éléments essentiels pour assurer la cohérence et l'adoption future du pipeline.

La formalisation des besoins constitue l'étape suivante de cette méthodologie. Les besoins fonctionnels décrivent ce que le système doit faire : quelles données doivent être collectées, quelles transformations doivent être appliquées, quels formats de sortie sont attendus. Ces besoins doivent être exprimés de manière précise et vérifiable, idéalement sous forme de user stories suivant le format "En tant que [rôle], je veux [fonctionnalité] afin de [bénéfice]". Par exemple : "En tant que data scientist, je veux accéder aux données de transactions des 3 dernières années avec une granularité journalière afin d'entraîner mon modèle de prévision des ventes."

Les besoins non-fonctionnels, souvent négligés mais tout aussi importants, concernent les qualités attendues du système : performance, disponibilité, sécurité, maintenabilité. Dans le contexte des pipelines de données, ces aspects incluent notamment la fraîcheur des données (à quelle fréquence doivent-elles être mises à jour ?), les volumes à traiter (combien de données, avec quelle croissance anticipée ?), les temps de réponse acceptables (en particulier pour les pipelines temps réel) et les exigences de confidentialité (quelles données sont sensibles et nécessitent des protections particulières ?).

La priorisation des exigences constitue la dernière étape de cette phase d'analyse. Face à la multiplicité des besoins exprimés et aux contraintes de ressources, il est rarement possible de tout satisfaire immédiatement. Des techniques comme la matrice MoSCoW (Must have, Should have, Could have, Won't have) ou le framework RICE (Reach, Impact, Confidence, Effort) peuvent aider à structurer cette priorisation. Cette étape doit impliquer à la fois les utilisateurs finaux, pour garantir que les priorités reflètent bien les besoins métier, et les équipes techniques, pour intégrer les contraintes de faisabilité et les dépendances techniques.

2.2 Spécificités des besoins data

Les projets de pipelines de données présentent des spécificités qui les distinguent d'autres types de projets informatiques. Ces particularités doivent être prises en compte lors de l'analyse des besoins pour garantir la pertinence et l'efficacité des solutions développées.

La diversité des types de données et des formats constitue l'une des principales spécificités à considérer. Les pipelines modernes doivent souvent intégrer des données structurées (tables relationnelles, fichiers CSV), semi-structurées (JSON, XML, logs) et non structurées (textes, images, vidéos). Chaque type présente des défis spécifiques en termes d'extraction, de validation et de transformation. Lors de l'analyse des besoins, il est essentiel d'identifier précisément non seulement les sources de données, mais aussi leurs caractéristiques intrinsèques : schéma (fixe ou évolutif), encodage, conventions de nommage, valeurs spéciales (comme les valeurs nulles ou les codes d'erreur).

Les formats de données peuvent varier considérablement selon les systèmes sources et les cas d'usage. Certains formats sont optimisés pour le stockage (comme Parquet ou Avro), d'autres pour l'échange (JSON, XML) ou pour l'analyse (CSV, tables relationnelles). L'analyse des besoins doit clarifier les formats d'entrée disponibles et les formats de sortie attendus, ainsi que les éventuelles conversions nécessaires. Cette analyse doit également anticiper les évolutions potentielles des formats, particulièrement dans les environnements où les systèmes sources sont en constante évolution.

La question de la fréquence de mise à jour et de la fraîcheur des données est cruciale dans la conception des pipelines. Certains cas d'usage nécessitent des données en temps réel ou quasi-réel (monitoring opérationnel, détection de fraude), tandis que d'autres peuvent se satisfaire de mises à jour quotidiennes, hebdomadaires ou même mensuelles (reporting financier, analyses de tendances à long terme). L'analyse des besoins doit préciser ces exigences pour chaque flux de données et chaque cas d'usage, en tenant compte des contraintes techniques des systèmes sources (certaines bases de données peuvent limiter la fréquence des extractions pour préserver leurs performances) et des attentes des utilisateurs finaux.

La fraîcheur des données ne se limite pas à la fréquence de mise à jour ; elle concerne également le délai acceptable entre la génération d'une donnée et sa disponibilité pour analyse. Ce délai, souvent appelé "data freshness" ou "data staleness", peut être critique pour certaines applications. Par exemple, un système de recommandation en ligne peut nécessiter d'intégrer les actions récentes de l'utilisateur en quelques secondes, tandis qu'un rapport mensuel peut tolérer un délai de plusieurs heures. L'analyse des besoins doit quantifier précisément ces exigences pour dimensionner correctement l'architecture du pipeline.

La volumétrie des données et les performances attendues constituent une autre spécificité majeure des projets de pipelines. L'analyse doit quantifier non seulement les volumes actuels (nombre d'enregistrements, taille des données), mais aussi leur croissance anticipée. Cette projection est essentielle pour concevoir des solutions évolutives et éviter les surprises désagréables quelques mois après la mise en production. Les performances attendues doivent également être spécifiées en termes de temps de traitement, de débit (throughput) et de latence, en fonction des cas d'usage.

Les contraintes de performance varient considérablement selon les contextes : un pipeline alimentant un tableau de bord consulté quotidiennement par quelques managers peut se permettre un temps de traitement de plusieurs heures, tandis qu'un pipeline supportant une application interactive doit répondre en quelques secondes ou moins. Ces exigences influenceront directement les choix architecturaux et technologiques, d'où l'importance de les clarifier dès la phase d'analyse des besoins.

2.3 Cartographie des transformations

La cartographie des transformations constitue une étape essentielle de l'analyse des besoins pour un pipeline de données. Cette démarche vise à documenter de manière exhaustive le parcours des données, depuis leur extraction des systèmes sources jusqu'à leur mise à disposition pour les utilisateurs finaux, en détaillant toutes les transformations intermédiaires.

L'identification des sources de données représente le point de départ de cette cartographie. Pour chaque source, plusieurs caractéristiques doivent être documentées : le système d'origine (base de données relationnelle, API, fichiers plats, etc.), les modalités d'accès (requêtes SQL, appels API, extraction de fichiers), les contraintes techniques (limites de débit, fenêtres de maintenance) et les aspects de gouvernance (propriétaire des données, autorisations nécessaires). Cette documentation doit également préciser la qualité attendue des données sources : sont-elles déjà validées et nettoyées, ou nécessitent-elles un traitement préalable ? Existe-t-il des problèmes connus (doublons, valeurs manquantes, incohérences) qui devront être gérés par le pipeline ?

Pour les sources de données critiques, il peut être pertinent de réaliser un profiling préliminaire pour quantifier précisément la distribution des valeurs, la proportion de données manquantes ou aberrantes, et identifier d'éventuelles anomalies non anticipées. Ces informations permettront de dimensionner correctement les étapes de nettoyage et de validation du pipeline.

La définition des transformations nécessaires constitue le cœur de cette cartographie. Ces transformations peuvent être regroupées en plusieurs catégories :

Les transformations de nettoyage visent à améliorer la qualité des données brutes : suppression ou correction des valeurs aberrantes, gestion des valeurs manquantes, élimination des doublons, standardisation des formats (dates, nombres, chaînes de caractères). Ces transformations sont particulièrement importantes lorsque les données proviennent de systèmes hétérogènes ou de saisies manuelles.

Les transformations de structure modifient l'organisation des données sans altérer leur contenu sémantique : pivotement (passage d'un format ligne à un format colonne ou inversement), dénormalisation ou normalisation, découpage ou fusion de champs. Ces transformations adaptent la structure des données aux besoins spécifiques des cas d'usage, privilégiant tantôt la performance des requêtes, tantôt la cohérence du modèle.

Les transformations d'enrichissement ajoutent de la valeur aux données brutes : calcul de métriques dérivées, agrégations, classification, segmentation, jointure avec des données de référence. Ces transformations transforment les données brutes en informations actionnables, directement exploitables par les utilisateurs finaux.

Les transformations de conformité assurent le respect des règles métier et des contraintes réglementaires : anonymisation ou pseudonymisation des données personnelles, application de règles de filtrage ou de masquage, vérification de la cohérence inter-champs. Ces transformations sont particulièrement importantes dans les secteurs fortement régulés comme la finance ou la santé.

Pour chaque transformation identifiée, la cartographie doit préciser les règles métier sous-jacentes, les algorithmes ou formules à appliquer, et les comportements attendus face aux cas particuliers ou aux exceptions. Cette documentation servira de référence lors de l'implémentation et facilitera la maintenance future du pipeline.

La modélisation des données de sortie complète cette cartographie en décrivant précisément le format, la structure et la sémantique des données produites par le pipeline. Cette modélisation doit être alignée avec les besoins des utilisateurs finaux et les cas d'usage identifiés. Elle peut prendre différentes formes selon le contexte : modèle relationnel pour un data warehouse, schéma JSON ou Avro pour des données semi-structurées, ontologie pour des graphes de connaissances.

La modélisation doit également spécifier les métadonnées associées aux données de sortie : descriptions des champs, unités de mesure, plages de valeurs valides, relations entre entités, informations de provenance (data lineage). Ces métadonnées sont essentielles pour garantir une utilisation correcte et efficace des données par les utilisateurs finaux.

Une représentation visuelle de cette cartographie, sous forme de diagramme de flux de données ou de data lineage, facilite la communication avec les différentes parties prenantes et permet de valider collectivement la compréhension des transformations nécessaires. Cette visualisation peut également servir de base pour la conception technique du pipeline et pour sa documentation future.

2.4 Étude de cas : Analyse des besoins pour une équipe BI et Data Science

Pour illustrer concrètement la méthodologie d'analyse des besoins dans le contexte des pipelines de données, considérons le cas d'une entreprise de commerce en ligne qui souhaite améliorer son infrastructure de données pour mieux servir son équipe BI et ses data scientists. Cette entreprise, que nous appellerons E-Commerce Plus, dispose de plusieurs systèmes sources : une base de données transactionnelle pour les commandes et les clients, une plateforme de gestion de contenu pour le catalogue produit, un outil de CRM pour les interactions clients, et des logs de navigation sur le site web.

Le scénario initial révèle plusieurs problématiques : les équipes BI et Data Science passent un temps considérable à extraire et préparer les données avant de pouvoir les analyser ; les rapports sont souvent basés sur des données obsolètes ; certaines analyses nécessitent des jointures complexes entre différentes sources, réalisées manuellement et de façon inconsistante ; enfin, les data scientists peinent à accéder à l'historique complet des données pour leurs modèles prédictifs.

La première étape de l'analyse consiste à mener des entretiens avec les différentes parties prenantes. Les analystes BI expriment leur besoin de tableaux de bord actualisés quotidiennement, présentant des KPIs commerciaux (chiffre d'affaires, panier moyen, taux de conversion) avec des possibilités de filtrage par catégorie de produits, segment client et période. Ils soulignent l'importance de la cohérence des données entre les différents rapports et la nécessité d'accéder rapidement à des données agrégées sans avoir à écrire des requêtes complexes.

Les data scientists, quant à eux, expriment des besoins différents : accès aux données brutes non agrégées, conservation d'un historique long (au moins 3 ans), possibilité de joindre facilement les différentes sources de données, et accès à des données comportementales détaillées (parcours de navigation, temps passé sur chaque page, produits consultés mais non achetés). Ils mentionnent également leur préférence pour des formats de données compatibles avec leurs outils d'analyse (Python, R) et la nécessité d'une documentation claire sur la signification des variables et les éventuelles transformations appliquées.

Les entretiens avec les équipes IT révèlent des contraintes techniques importantes : la base de données transactionnelle est fortement sollicitée pendant les heures d'ouverture et ne peut supporter des requêtes analytiques lourdes ; les logs de navigation représentent un volume considérable (plusieurs Go par jour) et sont actuellement peu structurés ; enfin, certaines données du CRM contiennent des informations personnelles qui doivent être traitées conformément au RGPD.

Suite à ces entretiens, un atelier collectif est organisé pour confronter les différents points de vue et établir une vision commune. Cet atelier permet d'identifier des synergies potentielles entre les besoins BI et Data Science, notamment concernant la nécessité d'un référentiel client unifié et d'une vision consolidée des interactions client à travers les différents canaux.

L'analyse documentaire des rapports existants et des requêtes fréquemment utilisées permet de préciser les transformations nécessaires : calcul de métriques dérivées (taux de conversion, valeur vie client), agrégations temporelles (jour, semaine, mois, trimestre), jointures entre transactions et données produits pour l'analyse du panier moyen par catégorie, segmentation des clients selon leur comportement d'achat.

Sur la base de ces informations, les besoins fonctionnels sont formalisés sous forme de user stories, par exemple :

• "En tant qu'analyste BI, je veux accéder à un tableau de bord quotidien du chiffre d'affaires par catégorie de produits et segment client, afin d'identifier les opportunités de croissance et les segments sous-performants."
• "En tant que data scientist, je veux disposer d'une table unifiée contenant l'historique des achats, des consultations produits et des interactions client sur 3 ans, afin de développer un modèle de propension à l'achat."

Les besoins non-fonctionnels sont également documentés : fraîcheur des données (mise à jour quotidienne pour les tableaux de bord BI, hebdomadaire pour les jeux de données d'entraînement des modèles), volumétrie (environ 10 000 transactions par jour, 1 million de sessions web), temps de réponse (moins de 5 secondes pour les requêtes BI courantes), et exigences de confidentialité (anonymisation des données clients pour les environnements de développement).

La priorisation collective des besoins, réalisée selon la méthode MoSCoW, identifie comme prioritaires ("Must have") la consolidation des données transactionnelles et produits pour les tableaux de bord BI, ainsi que l'accès à un historique structuré des transactions pour les modèles prédictifs. L'intégration des logs de navigation et l'enrichissement avec des données externes sont classés comme "Should have", tandis que certaines fonctionnalités avancées (recommandations en temps réel, analyse de sentiment des avis clients) sont reportées à une phase ultérieure ("Could have").

La cartographie des transformations nécessaires est ensuite élaborée. Pour les données transactionnelles, elle inclut le nettoyage des adresses client, la standardisation des codes produits, le calcul de métriques dérivées (marge, contribution au chiffre d'affaires) et l'enrichissement avec des données de catégorisation produit. Pour les logs de navigation, elle prévoit l'extraction de patterns de comportement (séquences de pages visitées, temps passé par section) et la jointure avec les données transactionnelles pour reconstituer le parcours client complet.

Le modèle de données de sortie est conçu pour répondre aux différents besoins identifiés : un modèle en étoile pour les analyses BI, avec des tables de faits (transactions, sessions web) et des dimensions (clients, produits, temps), et des tables dénormalisées pour les data scientists, optimisées pour l'analyse prédictive.

Cette étude de cas illustre l'importance d'une analyse approfondie et structurée des besoins pour concevoir un pipeline de données qui réponde efficacement aux attentes des différentes parties prenantes, tout en tenant compte des contraintes techniques et organisationnelles. Elle souligne également la nécessité d'une approche collaborative, impliquant à la fois les producteurs et les consommateurs de données, pour garantir l'alignement du pipeline avec les objectifs métier de l'organisation.