Analyse de données : transformer les données en décisions défendables

L'analyse de données part souvent d'une question simple, qui se précise à mesure que les éléments probants apparaissent. Pourquoi les ventes ont-elles chuté dans une région ? La baisse était-elle concentrée sur un produit, un segment de clientèle ou une période en particulier ? Un autre changement est-il survenu au même moment ?

Répondre à ces questions implique de définir l’objet de l’investigation, de collecter et de préparer les données pertinentes, de choisir une méthode appropriée et d’interpréter la signification réelle du résultat. La démarche est rarement linéaire : un premier constat oriente souvent vers une autre variable, met au jour une hypothèse implicite ou suggère une question plus pertinente. Josh Klahr, Head of Product Management for Analytics chez Snowflake, résume ainsi l’objectif : « L’impact réel naît de la réduction de la distance entre l’exploration et l’action. »

Dans une grande organisation, produire ces informations de façon fiable dépend des données sous-jacentes. Les analystes doivent savoir si la source est à jour, si les enregistrements concordent d’un système à l’autre et si des termes tels que chiffre d’affaires, client actif ou attrition (churn) sont définis de manière cohérente dans l’ensemble des systèmes et des outils.

L’analyse de données est le processus consistant à collecter, nettoyer, transformer et interpréter des données pour répondre à une question et étayer une décision. Une analyse peut par exemple expliquer pourquoi la fidélisation client a reculé, identifier les produits qui contribuent le plus à la croissance de la marge, ou déterminer si une modification du parcours d'onboarding a eu un effet sur la conversion.

Cette dernière étape, étayer une décision, permet de distinguer l’analyse du reporting. Le reporting se contente généralement de décrire ce qui s’est passé. L’analyse va plus loin : elle explore les relations, les causes ou les implications derrière le résultat.

Un rapport trimestriel peut, par exemple, montrer que le volume de demandes au support a augmenté de 18 %. Une analyse chercherait à déterminer où cette hausse s'est produite, quelles catégories de demandes y ont contribué, et si l'évolution s'explique par un effet saisonnier, le lancement d'un produit ou un autre facteur. Le résultat fournit suffisamment de contexte pour qu’une équipe décide des suites à donner, le cas échéant.

Le processus est également itératif. Les premiers travaux sur un jeu de données font souvent apparaître une variable manquante, un segment inattendu ou un problème dans la question de départ. Les analystes reviennent alors aux données sources, reformulent la question et reprennent l’investigation.

Tout au long de ce processus, l’analyse hérite de l’état des données sous-jacentes. Si les données d’entrée donnent une image faussée de l’activité, le résultat sera lui aussi faussé.

Découvrez les dernières fonctionnalités de BI optimisée par l’IA et d’analyse interactive, avec une démo qui vous montre comment accéder rapidement à des informations approfondies :

L’analyse de données part d’une question définie et suit les faits jusqu’à une conclusion susceptible d’éclairer une décision.

La data science s’étend souvent à l’expérimentation et au machine learning. Un data scientist qui travaille sur des données de fidélisation client peut, par exemple, développer un modèle qui estime quels clients risquent de partir, puis tester les variables qui améliorent ses performances.

La répartition exacte des rôles varie selon les organisations, en particulier au sein des petites équipes.

La plupart des analyses de données suivent six grandes étapes :

1. Définir la question
2. Collecter les données pertinentes
3. Nettoyer et préparer les données
4. Analyser les données
5. Interpréter les résultats
6. Communiquer les conclusions

Dans la pratique, les analystes font des allers-retours entre ces étapes. Un constat établi à la cinquième étape peut, par exemple, révéler des données manquantes dès la deuxième, tandis que la préparation des données peut montrer que la question de départ doit être resserrée.

1. Définir la question

Une question bien formulée donne à l’analyse un périmètre et un objectif clairs. Par exemple, la question « Pourquoi le taux de renouvellement a-t-il baissé chez les clients ETI au dernier trimestre ? » précise une population, un résultat et une période à analyser.

La question doit également être clairement reliée à une décision. Si une équipe se demande, par exemple, s'il faut repenser un parcours d'onboarding, elle doit savoir sur quel résultat cette refonte est censée agir et quels éléments probants justifieraient de l'engager.

Sans ce lien, une analyse risque de faire émerger indéfiniment des tendances intéressantes, sans jamais établir quel résultat justifierait d'agir ou d'approfondir l'examen.

2. Collecter les données pertinentes

Une fois la question bien définie, les analystes identifient les données nécessaires pour y répondre. Une analyse de la fidélisation peut, par exemple, croiser les données d'abonnement, les événements d'utilisation du produit et les attributs clients issus du CRM.

Les analystes doivent également savoir d'où proviennent les données, quelle période elles couvrent, à quelle fréquence elles sont actualisées et quelles transformations leur ont déjà été appliquées. Ces informations sont particulièrement importantes lorsque plusieurs systèmes contiennent des données similaires, car chacun peut comporter un champ portant le même libellé tout en appliquant des règles différentes pour le renseigner.

3. Nettoyer et préparer les données

La préparation représente souvent une grande partie du travail. Les analystes traitent les valeurs manquantes, harmonisent les formats, examinent les enregistrements en double, effectuent les jointures entre jeux de données et agrègent les observations au niveau approprié. Ces tâches exigent une part étonnamment importante de jugement analytique.

Imaginons qu'une table de clients contienne trois enregistrements pour la même organisation. Lequel représente le client ? L'enregistrement le plus récent est peut-être le bon, à moins qu'il ne faille fusionner les trois. Les considérer comme trois clients distincts fausse les décomptes, les moyennes et tous les indicateurs en aval qui reposent sur le nombre de clients.

Les valeurs nulles posent un problème similaire. Une valeur vide peut signifier zéro, inconnu, non applicable ou simplement manquant. La remplir de façon incorrecte fausse l’analyse.

C'est lors de la préparation que les hypothèses sur ce que représentent les enregistrements se traduisent concrètement dans le jeu de données exploité par les analystes. Le nettoyage et la mise en forme des données conditionnent donc directement l'exactitude des résultats.

4. Analyser les données

Une fois les données préparées, les analystes choisissent les méthodes d'analyse adaptées à la question posée : agrégation, analyse exploratoire des données, régression, analyse de cohortes, expérimentations contrôlées ou autres techniques statistiques.

L'exploration commence souvent de façon simple : les analystes examinent des distributions, des médianes, des percentiles et des visualisations qui font apparaître des tendances que la vue agrégée ne laissait pas deviner.

Si le panier moyen augmente de 6 %, par exemple, une vue par segment peut montrer que la plupart des clients dépensent autant qu'avant, et qu'un petit groupe de grands comptes est à l'origine de toute la hausse.

5. Interpréter les résultats

L’interprétation consiste à déterminer ce que le résultat observé permet réellement de conclure. Les analystes doivent garder à l'esprit qu'une corrélation entre deux variables ne prouve pas que l'une est la cause de l'autre, et qu'une tendance apparente disparaît parfois lorsque les données sont ventilées par segment de clientèle, zone géographique ou période.

Les explications alternatives méritent elles aussi d’être examinées. Si l'attrition augmente après une modification tarifaire, un analyste peut chercher à savoir si un incident sur le produit est survenu au cours de la même période, si la hausse se concentre parmi les clients concernés par le nouveau tarif ou si la définition de l'attrition a été modifiée en amont. Cette investigation renvoie souvent l’analyste aux étapes précédentes, avec une question plus ciblée.

6. Communiquer les conclusions

Le résultat final d’une analyse doit fournir à son audience suffisamment d’informations pour agir. Pour un dirigeant, il peut s’agir d’une recommandation étayée par quelques indicateurs soigneusement sélectionnés. Un responsable métier aura peut-être besoin de plus de détails sur les clients, produits ou processus à l’origine du résultat, ainsi que sur la réponse opérationnelle qu’il suggère. Un autre analyste pourra avoir besoin de la méthodologie, des hypothèses et des données sources nécessaires pour reproduire le résultat.

L’incertitude ne doit pas être minimisée. Si les éléments de preuve pointent dans une direction mais laissent une importante variable de confusion non résolue, l’audience doit le savoir avant de prendre une décision.

Quatre catégories d’analyse couvrent la plupart des questions que les organisations posent à leurs données.

• L’analyse descriptive examine ce qui s’est passé. Le chiffre d’affaires par trimestre, le délai moyen de livraison ou le trafic du site web par canal en sont des exemples courants.
• L’analyse diagnostique cherche à comprendre pourquoi un résultat s’est produit. Si le chiffre d’affaires a baissé, le travail de diagnostic peut comparer les régions, les produits, les segments de clientèle ou les canaux de vente afin d’identifier l’origine du changement.
• L’analyse prédictive estime ce qui est susceptible de se produire ensuite, souvent à partir de tendances historiques et de modèles statistiques ou de machine learning. Les prévisions de demande et les prédictions d’attrition entrent dans cette catégorie.
• L’analyse prescriptive évalue les actions possibles en fonction des résultats attendus et des contraintes. Un système logistique peut, par exemple, s'appuyer sur les prévisions de la demande, les niveaux de stock et les coûts de transport pour recommander la répartition des stocks.

Ces types d’analyse ne sont généralement pas séquentiels. Les organisations en combinent souvent plusieurs, selon la décision à prendre ou le problème à traiter. Un distributeur peut, par exemple, recourir à l'analyse descriptive pour suivre les ventes de la veille, à l'analyse diagnostique pour comprendre une baisse inattendue dans une région, et à l'analyse prédictive pour prévoir la demande du mois suivant.

La qualité des données sous-jacentes à chaque analyse se répercute en aval. Si la classification des clients est erronée dans le reporting descriptif, un modèle prédictif entraîné sur cette classification hérite du même problème. Dès lors que les résultats du modèle orientent les actions futures, les conséquences d'une erreur peuvent se répercuter sur de nombreuses décisions.

Le choix de la méthode part généralement de la question, puis se précise en fonction des données disponibles, des hypothèses requises par chaque technique et de l’usage prévu du résultat. Parmi les méthodes d'analyse de données les plus courantes figurent les tests A/B, la régression, l'analyse de clusters, l'analyse de cohortes, l'analyse de séries temporelles et l'analyse de sentiment.

Comparaison

Les tests A/B comparent les résultats entre groupes dans des conditions contrôlées. Les équipes produit et marketing les utilisent souvent pour tester des changements d’interfaces, de tarification, de messages ou d’expériences client. La taille de l'échantillon, l'affectation aléatoire et les corrections pour comparaisons multiples déterminent le degré de confiance que les analystes peuvent accorder à l'écart observé.

Relation

La régression examine comment les variables sont liées entre elles. La régression linéaire offre un point de départ relativement simple, tandis que d’autres approches de régression s’adaptent à différents types de résultats et de relations. Un analyste peut utiliser la régression pour étudier la relation entre tarification et demande, ou entre utilisation du produit et fidélisation.

Regroupement

L'analyse de clusters regroupe les observations qui présentent des caractéristiques similaires. L'analyse de cohortes suit des groupes qui partagent un même point de départ ou une même caractéristique, par exemple des clients acquis au cours d'un même mois. Analyser la fidélisation par cohorte d'acquisition peut, par exemple, révéler des évolutions que masque un taux de fidélisation moyen global.

Évolution dans le temps

L’analyse de séries temporelles examine des observations enregistrées sur une succession de périodes. Elle est largement utilisée pour la prévision, la détection de tendances et la planification des capacités, et des facteurs tels que la saisonnalité influent sur la manière dont les analystes interprètent les évolutions observées.

Analyse de texte et de sentiment

L’analyse de sentiment et les méthodes d’analyse de texte associées extraient des tendances du langage non structuré, notamment les avis clients, les conversations avec le support et les réponses aux enquêtes.

Une analyse peut être méthodologiquement solide et aboutir malgré tout à une conclusion erronée si les données sous-jacentes sont incomplètes, obsolètes ou mal interprétées. Avant de se fier à un résultat, les analystes doivent s'assurer que les enregistrements correspondent aux bonnes entités et aux bons événements, qu'ils couvrent la période pertinente et qu'ils peuvent être rattachés à leur source.

Vérifier que les données reflètent la réalité

L'exactitude dépend d'abord de la fidélité avec laquelle les enregistrements représentent les entités ou les événements sous-jacents. Un identifiant client mal mis en correspondance peut, par exemple, attribuer une activité au mauvais compte, et une modification de schéma en amont peut changer le sens d'un champ.

La complétude et la cohérence ont elles aussi une incidence sur l'exactitude. Des enregistrements manquants peuvent biaiser une comparaison, tandis que des valeurs contradictoires d'un système source à l'autre obligent l'analyste à deviner quelle version retenir.

Adapter la fraîcheur des données à la question posée

La fraîcheur indique si les données sont suffisamment à jour pour la décision qu'elles doivent éclairer, et le seuil acceptable varie considérablement d'un cas d'usage à l'autre. La détection des fraudes peut reposer sur des événements survenus au cours des dernières secondes, alors qu'un rapport hebdomadaire sur les effectifs n'a besoin que d'une actualisation hebdomadaire. Définir la fréquence d'actualisation attendue donne aux analystes un critère concret pour juger si un jeu de données est obsolète.

Utiliser la traçabilité des données pour comprendre l’origine d’un résultat

La traçabilité montre comment les données circulent depuis leur source, à travers les transformations successives, jusqu'aux modèles, tableaux de bord et rapports en aval. Cette traçabilité rend le rapprochement plus systématique. Lorsque deux analyses divergent, les analystes peuvent remonter la traçabilité pour déterminer si elles partaient de sources différentes, appliquaient des transformations différentes ou divergeaient au niveau d’un champ particulier.

Vérifier l’impact en aval avant toute modification des données

La traçabilité des données permet également l’analyse d’impact dans l’autre sens. Avant de modifier une table ou une colonne en amont, une équipe data peut identifier les modèles, les tableaux de bord et les rapports qui en dépendent.

La traçabilité au niveau des tables offre une vue d'ensemble des objets concernés, tandis que la traçabilité au niveau des colonnes montre le parcours d'un champ précis. Cette distinction prend toute son importance lorsqu'une modification de schéma laisse une table accessible, mais change le sens ou le format d'une colonne utilisée en aval.

Avant de présenter une analyse aux parties prenantes, un analyste doit pouvoir répondre à trois questions essentielles : d’où proviennent les données ? Sont-elles suffisamment à jour ? Qui d’autre en dépend ?

Imaginez une revue trimestrielle où l’équipe commerciale annonce 14,2 millions de dollars de chiffre d’affaires tandis que la finance en déclare 13,7 millions.

Aucune des deux équipes n’a nécessairement commis d’erreur de calcul. Un calcul peut exclure les remboursements quand l’autre les inclut. L’un peut se baser sur la date de commande, l’autre sur la date de comptabilisation du chiffre d’affaires. Les deux requêtes s’exécutent correctement, et pourtant l’organisation se retrouve avec deux valeurs rattachées au même terme métier.

Une couche sémantique donne à ces termes une définition partagée. Elle stocke la logique métier des métriques, dimensions et relations : la signification du chiffre d’affaires, les clients considérés comme actifs, le mode de calcul de l’attrition et les liens entre entités métier. Analystes et outils en aval appliquent ainsi les mêmes règles.

La headless BI étend cette couche au-delà d'une seule interface de reporting. Notebooks, tableaux de bord, applications et interfaces d'IA peuvent tous s'appuyer sur la même logique métier, dès lors que les indicateurs et les dimensions gouvernés sont accessibles indépendamment de l'interface utilisateur.

Pour traduire une question métier en une logique de requête correcte, le SQL généré par l'IA a besoin de contexte. Le modèle doit savoir quelles tables et quels champs correspondent aux concepts de la question, quelles relations unissent ces tables, quelle granularité la requête doit adopter et quelles définitions d'indicateurs ou quels filtres s'appliquent. Un schéma physique fournit une partie de ces informations, mais il rend rarement compte du sens métier. Le contexte sémantique fournit explicitement ces définitions et ces relations, offrant au modèle un ensemble de choix plus restreint lorsqu’il génère la requête.

Ce contexte peut faire une différence mesurable lorsque l’IA doit raisonner sur plusieurs sources de données. Lors d'une expérimentation interne menée par Snowflake sur des questions qui mobilisaient plusieurs Semantic Views, l'ajout d'informations explicites sur les clés de jointure, la granularité des tables et la cardinalité a amélioré de 20 % l'exactitude des réponses finales, tout en réduisant le nombre d'appels d'outils et la latence globale.¹

Les analytics engineers contribuent de plus en plus à la maintenance des modèles sémantiques, généralement aux côtés d'experts métier garants des définitions. Par exemple, c'est la direction financière qui détermine ce que recouvre le chiffre d'affaires, tandis que l'équipe data traduit cette définition en une logique réutilisable et veille à ce que les analyses en aval y restent conformes.

L’IA générative réduit une partie du travail manuel entre la question posée et l’interrogation des données. Les interfaces en langage naturel, le SQL généré et les synthèses automatiques permettent aux utilisateurs non techniques d'explorer directement les données. L'attention des analystes se porte alors davantage sur le cadrage des questions, la préservation du contexte métier et la validation des résultats.

Les requêtes en langage naturel élargissent l’accès à l’analyse

Les utilisateurs métier peuvent de plus en plus poser leurs questions avec leurs propres mots, plutôt que de traduire chaque demande en SQL ou d'attendre la création d'un nouveau tableau de bord. Les interfaces en langage naturel rendent l’analyse exploratoire plus accessible, même si le système doit encore faire correspondre le langage de l’utilisateur aux bonnes tables, relations, filtres et métriques.

L’IA accélère la génération de requêtes et les analyses complémentaires

Pour les analystes, le SQL généré peut réduire le temps consacré à l’écriture et à la révision des requêtes courantes. Les systèmes d'IA peuvent aussi synthétiser les résultats, faire ressortir des tendances et répondre aux questions de suivi à mesure que l'analyse progresse.

Le jugement humain reste essentiel : l’analyste doit déterminer si la requête reflète réellement la question métier. Une requête techniquement valide peut reposer sur une granularité inadaptée, joindre des tables de manière incorrecte ou appliquer une définition d'indicateur non conforme à la norme de l'organisation.

Les analystes consacrent plus de temps à valider et à cadrer le travail

À mesure que l'IA prend en charge une part croissante de la rédaction des requêtes, les analystes peuvent se consacrer davantage à la formulation des questions, à la maintenance de la logique métier et à la vérification des résultats produits par la machine.

Le processus de revue comprend des vérifications analytiques bien connues : la requête préserve-t-elle le bon niveau de granularité ? Les filtres correspondent-ils à la population visée ? Le résultat concorde-t-il avec une source de référence ? Existe-t-il d’autres explications possibles à la tendance observée ?

À l'échelle d'une grande entreprise, les analystes travaillent souvent sur des données qui ont transité par de multiples sources, transformations et processus métier. Snowflake offre un environnement commun pour analyser ces données, tout en maintenant la gouvernance, le contexte métier et les flux de travail assistés par l'IA au plus près des données sous-jacentes.

Snowflake Horizon Catalog assure la gouvernance de l'ensemble des données utilisées pour l'analyse, notamment grâce au suivi de la qualité des données et à la traçabilité. Grâce à la traçabilité au niveau des tables et des colonnes, les équipes peuvent remonter des résultats analytiques jusqu'à leurs sources et aux transformations appliquées, ou identifier les ressources en aval qui dépendent d'un champ en amont.

Pour partager le contexte métier, Snowflake Horizon Context réunit les indicateurs, les définitions, les relations et les autres métadonnées au sein d'une couche de contexte gouvernée, au service de l'IA, de la Business Intelligence (BI) et des applications. Les Semantic Views stockent directement dans Snowflake des concepts métier tels que les indicateurs, les dimensions et les relations entre entités, tandis que Horizon Context peut également intégrer du contexte issu des outils de BI et d'autres sources. L'objectif est de réduire le nombre d'endroits où les équipes recréent chacune de leur côté la logique d'un même indicateur.

L’analyse assistée par IA s’appuie sur ce contexte. Les Cortex Agents peuvent répondre à des questions en langage naturel sur les données structurées grâce aux Semantic Views, tout en exploitant des sources non structurées et en prenant en charge des tâches analytiques en plusieurs étapes.

Pour les utilisateurs métier, Snowflake CoWork offre une interface conversationnelle pour explorer les données de l’entreprise, poser des questions complémentaires et exploiter les graphiques, tableaux et rapports générés. CoWork, anciennement Snowflake Intelligence, peut également mener des recherches approfondies dans les informations de l’entreprise et conserver les résultats analytiques sous forme d’artefacts réutilisables.

Les analystes qui travaillent directement en SQL peuvent aussi utiliser les fonctions Cortex AI pour analyser du texte, des images, de l’audio et d’autres contenus non structurés ou multimodaux aux côtés des données structurées. Les flux de travail analytiques habituels s'étendent ainsi à des informations qui nécessitaient auparavant un pipeline de traitement des données distinct.

Combinées, ces fonctionnalités relient des données gouvernées, une traçabilité de bout en bout, des définitions métier partagées et une analyse assistée par l'IA, toutes ancrées dans un même contexte.

L'analyse de données aide les organisations à passer d'une question à des éléments probants exploitables. Des résultats fiables exigent des questions bien cadrées, des techniques adaptées, des données à jour et traçables, ainsi que des définitions métier qui restent cohérentes d'une équipe et d'un outil à l'autre. À mesure que l'IA prend en charge une part croissante de la génération de requêtes et du travail exploratoire, ces fondations offrent aux équipes des repères plus clairs pour déterminer les réponses qui méritent leur confiance.

_{1. Données issues d'une expérimentation interne menée par Snowflake, qui a mesuré l'exactitude des réponses finales sur un ensemble de requêtes mobilisant plusieurs Semantic Views. L'amélioration est mesurée par rapport à une configuration de référence conforme aux bonnes pratiques. Méthodologie complète ici. Les résultats individuels peuvent varier.}