Projet de data analyse : les étapes pour bien décider

La donnée ne produit pas spontanément de bonnes décisions. Une base remplie, un tableau coloré ou un modèle prédictif sophistiqué ne valent rien s’ils ne répondent pas à un problème précis, avec des chiffres contrôlés et une personne prête à agir. Le déroulé d’un projet de data analyse est donc moins une ligne droite qu’une série de vérifications : à chaque étape, on peut confirmer le cap, le réviser ou arrêter avant de dépenser davantage.

Partir de la décision métier, pas des données disponibles

La première question n’est pas : quelles données possédons-nous ? C’est : quelle décision doit devenir meilleure, plus rapide ou moins risquée ? Une direction commerciale peut vouloir prioriser les prospects, un service client réduire les délais de réponse, une équipe logistique repérer les ruptures de stock. Ces objectifs appellent des analyses différentes.

Transformez le besoin vague en une question opérationnelle. Par exemple, remplacer « comprendre nos clients » par « quels profils commandent à nouveau dans les 90 jours, et quelle action leur proposer ? ». Définissez simultanément le périmètre : population concernée, période observée, pays ou points de vente, équipe utilisatrice et exclusions.

Un bon cadrage fixe aussi un indicateur de résultat, son niveau de départ et une cible réaliste. Si le sujet porte sur les retards de livraison, précisez si le KPI est le pourcentage de commandes livrées après la date promise, le retard moyen ou le nombre de réclamations. Deux indicateurs proches peuvent raconter deux histoires opposées.

Nommez un sponsor métier, qui arbitre les priorités, et un référent opérationnel, qui connaît les processus réels. Le data analyst apporte la méthode ; il ne peut pas deviner ce qu’un chiffre signifie dans l’activité. Prévoyez un point de validation à la fin de chaque phase plutôt qu’une livraison surprise après plusieurs semaines.

Vérifier la faisabilité des données et le cadre RGPD

Avant de promettre un résultat, réalisez un inventaire concret des sources : logiciel métier, fichiers tableurs, base de données, outil web, capteurs, enquête, journal d’événements ou données fournies par un partenaire. Pour chacune, relevez le propriétaire, la fréquence de mise à jour, l’historique disponible, le format, le volume, les clés de rapprochement et les règles d’accès.

La question décisive est souvent celle de l’identifiant. Peut-on relier un client entre le système de vente et le service après-vente ? Une référence produit a-t-elle la même forme dans tous les outils ? Sans clé fiable, on obtient parfois des rapprochements séduisants mais faux. Il faut alors créer une table de correspondance, changer le périmètre ou renoncer à certaines jointures.

Évaluez la qualité avant de bâtir des graphiques : taux de champs vides, doublons, valeurs impossibles, ruptures dans les séries chronologiques et changements de définition. Une donnée de chiffre d’affaires peut être inutilisable si elle mélange commandes, factures, remboursements et taxes sans règle claire.

Les données personnelles imposent un examen supplémentaire. Le RGPD demande notamment de définir une finalité, de limiter les informations à ce qui est nécessaire, de sécuriser les accès et de fixer une durée de conservation. Les données de santé, les informations biométriques, les opinions, les données relatives à des mineurs ou les croisements très intrusifs réclament une vigilance renforcée.

Documentez la base légale applicable, les catégories de données, les destinataires et les droits des personnes lorsque le projet traite des données personnelles. Une analyse d’impact relative à la protection des données peut être nécessaire pour les traitements susceptibles d’engendrer un risque élevé. Travaillez, dès que possible, sur des données agrégées, pseudonymisées ou anonymisées selon le besoin réel.

Organiser la collecte, l’extraction et la traçabilité du projet data

La collecte n’est pas un simple téléchargement. Il faut pouvoir répondre à ces questions plusieurs mois plus tard : d’où vient ce chiffre, quand a-t-il été extrait, selon quelle règle et qui l’a modifié ? Sans cette traçabilité, une anomalie devient coûteuse à diagnostiquer et les résultats perdent leur crédibilité.

Choisissez le mode d’accès le moins fragile. Un export manuel peut suffire pour un diagnostic ponctuel ; il devient dangereux pour un suivi hebdomadaire, car les filtres et les manipulations changent facilement. Pour un usage récurrent, privilégiez une extraction planifiée, avec une requête versionnée, une interface de programmation ou un pipeline documenté.

Conservez une copie brute en lecture seule, séparée de la table de travail. Datez les extractions et notez le fuseau horaire, la période couverte, les filtres appliqués ainsi que les fichiers exclus. Si les chiffres évoluent après une correction dans l’outil source, cette information doit être visible : un chiffre corrigé n’est pas nécessairement une erreur, mais il doit être explicable.

Le bon outil dépend du problème, de la fréquence et des compétences disponibles, pas d’un effet de mode.

Ne collectez pas « au cas où ». Chaque colonne augmente le travail de nettoyage, le risque de confidentialité et les possibilités d’interprétation abusive. Une analyse courte avec dix variables bien définies vaut mieux qu’un entrepôt incompris de centaines de champs.

Nettoyer, documenter et contrôler la qualité des données

La préparation représente souvent la part la plus longue d’un projet de data analyse. Son but n’est pas de rendre les données belles : il consiste à les rendre cohérentes avec ce qu’elles prétendent mesurer. Une date au mauvais format, une unité mélangée ou un statut mal codé suffit à fausser un résultat global.

Commencez par profiler chaque variable : type de donnée, nombre de valeurs distinctes, minimum, maximum, répartition, part de valeurs nulles et exemples de libellés. Pour les catégories, recherchez les variantes : « Paris », « PARIS », « Paris », ou un code postal utilisé à la place d’une ville. Pour les dates, vérifiez les jours futurs, les dates antérieures à la création du système et les inversions entre jour et mois.

Traitez les doublons avec prudence. Deux lignes identiques peuvent être une saisie répétée, mais aussi deux achats distincts enregistrés à la même minute. Définissez donc la clé d’unicité avec le métier : numéro de commande, ligne de facture, identifiant client et date, ou combinaison différente selon le cas.

Les valeurs manquantes ne doivent jamais disparaître silencieusement. Elles peuvent signifier « non renseigné », « non applicable », « inconnu », une panne de collecte ou une valeur confidentielle volontairement masquée. Mesurez leur fréquence par période, canal ou population : l’absence d’information peut elle-même signaler un dysfonctionnement utile à analyser.

Créez enfin un dictionnaire de données. Il indique pour chaque champ sa définition métier, son format, son unité, sa source, son responsable, sa fréquence de mise à jour et les transformations appliquées. Ce document évite qu’un « client actif » signifie une chose pour le commerce et une autre pour la finance.

Explorer les données sans confondre corrélation et causalité

Une fois le jeu de données fiable, l’analyse exploratoire cherche les faits qui comptent. Regardez d’abord les niveaux globaux, puis les évolutions dans le temps, les répartitions, les segments et les exceptions. Une moyenne seule cache souvent de fortes différences entre produits, territoires, types de clients ou périodes.

Travaillez par hypothèses explicites. « Les retards augmentent-ils pour certains transporteurs ? », « les utilisateurs qui abandonnent présentent-ils les mêmes signaux ? », « la marge est-elle tirée par quelques références ? ». Pour chaque hypothèse, précisez la population, la période et la mesure, afin d’éviter de tirer des conclusions de comparaisons incohérentes.

Méfiez-vous des effets de calendrier. Un pic peut venir d’une promotion, d’un jour férié, d’un changement de prix, d’une rupture de stock, d’un incident informatique ou d’une modification du mode de comptage. Comparez des périodes comparables et signalez les changements de processus connus.

Évitez aussi le biais de sélection. Analyser uniquement les clients ayant répondu à une enquête ne décrit pas tous les clients. Étudier les ventes validées sans les commandes annulées peut masquer un problème de conversion. Les exclusions doivent être listées, justifiées et, si possible, quantifiées.

Choisir l’analyse ou le modèle au juste niveau de complexité

Le bon niveau de sophistication est celui qui améliore une décision de manière mesurable. Un tableau de bord descriptif répond à « que s’est-il passé ? ». Une analyse de diagnostic cherche « pourquoi cela semble-t-il se produire ? ». Une prévision estime « que peut-il arriver ? ». Une recommandation tente d’indiquer « quelle action choisir ? ». Ces usages ne requièrent ni les mêmes données ni le même niveau de risque.

Avant de construire un modèle prédictif, comparez-le à une référence simple : moyenne historique, règle métier, tendance saisonnière ou priorisation manuelle. Si le modèle ne fait pas mieux, s’il n’est pas compris ou s’il arrive trop tard pour agir, il n’a pas sa place en production.

Validez les résultats sur des données non utilisées pendant la construction. Pour une série temporelle, le test doit respecter le temps : entraîner sur le passé et évaluer sur une période ultérieure. Sinon, le modèle peut bénéficier indirectement d’informations du futur, un défaut appelé fuite de données.

Choisissez des mesures adaptées au coût de l’erreur. Dans une détection de fraude, rater un cas et alerter à tort n’ont pas la même conséquence. Dans une prévision de demande, regardez l’erreur moyenne, mais aussi les périodes critiques et l’impact sur le stock. Présentez toujours les incertitudes, les cas où l’outil fonctionne moins bien et les populations sous-représentées.

Restituer des résultats actionnables et faire décider

Une restitution réussie ne déverse pas tous les graphiques produits. Elle répond en quelques minutes à quatre questions : que constate-t-on, pourquoi est-ce plausible, que faut-il faire et quelles limites faut-il garder en tête ? Le lecteur doit pouvoir vérifier les définitions, puis décider sans interpréter seul des chiffres ambigus.

Construisez une histoire courte. Commencez par la décision et l’indicateur principal. Ajoutez ensuite les deux ou trois facteurs les plus utiles, les segments concernés, la recommandation et l’effet attendu. Les détails techniques, règles de nettoyage et résultats complets doivent rester accessibles en annexe ou dans la documentation.

Chaque visualisation doit avoir une fonction. Une courbe montre une évolution, des barres comparent des catégories, une distribution révèle une dispersion, un tableau permet de contrôler un détail. Évitez les axes tronqués sans avertissement, les couleurs décoratives et les camemberts remplis de catégories minuscules.

Prévoyez l’intégration dans le travail réel : qui consulte le résultat, à quelle fréquence, dans quel rituel, et avec quel pouvoir de décision ? Un score de risque n’a de valeur que s’il déclenche une vérification, un appel, une offre ou une priorisation. Définissez aussi les cas où l’humain peut ignorer la recommandation et la raison qu’il doit enregistrer.

Industrialiser, surveiller et faire vivre le projet data

Un projet pilote prouve qu’une idée peut fonctionner. Un projet durable garantit que le résultat reste exact, disponible et utilisé. Pour passer de l’un à l’autre, formalisez les responsabilités : propriétaire de la donnée, responsable technique, utilisateur métier, personne chargée de la validation des changements et circuit de traitement des incidents.

Planifiez la fréquence de rafraîchissement selon la décision, pas selon une préférence technique. Une actualisation mensuelle convient à une analyse de marge ; un indicateur opérationnel peut demander un rythme quotidien ou plus court. Un rafraîchissement trop fréquent augmente les coûts et les risques sans améliorer l’action.

Surveillez au minimum les volumes, la fraîcheur, le taux de données manquantes, les échecs d’extraction et les écarts anormaux avec les périodes précédentes. Pour un modèle, surveillez aussi la dérive : les comportements changent, les règles métier évoluent et les performances se dégradent. Versionnez les données, les règles de calcul et le modèle afin de pouvoir expliquer un résultat passé.

Si le projet déraille, ne corrigez pas uniquement le graphique final. Remontez à la source : définition du KPI, changement de processus, rupture de collecte, transformation erronée ou mauvais usage du résultat. Un journal d’incidents, des seuils d’alerte et une revue périodique transforment cet apprentissage en amélioration durable. Le meilleur projet data est celui que l’organisation sait vérifier, contester et faire évoluer sans repartir de zéro.