Data visualisation

Business Intelligence, Data visualisation, Self-service Analytics, Stage, Technology

LE STORYTELLING de Sephora Panchbaya

Passionnée par l’analyse de données, à la recherche d’un stage et investie dans un projet très innovant au sein de son école, sa candidature a très rapidement retenu notre attention. Aucun regret! Nous avons partagé ces derniers mois à ses côtés…pépite !
Elle vous en dit plus :

À la sortie de mon BAC S, j’ai fait une première année de cours préparatoires en mathématiques et physique dans l’optique de devenir ingénieure. Un an après, j’ai réalisé que les cours théoriques ne me convenaient plus et que je voulais faire autre chose.

Je me suis donc dirigée vers Epitech, une école en 5 ans qui forme des experts en technologies de l’information et je me suis orientée vers le développement de jeux vidéo. Après la première année, je me suis rendu compte que ce monde n’était pas pour moi non plus.

Ayant un fort attrait pour les mathématiques et les statistiques, j’ai pendant longtemps cherché ce que je pourrai faire dans l’avenir.

Je me suis donc penchée sur le domaine de l’analyse de données. J’ai toujours trouvé fascinant tout ce qui pouvait être révélé lorsque l’on prenait le temps de comparer et d’analyser des données. Cependant, il est aussi facile de les manipuler pour leur faire dire ce que l’on souhaite.

Pour pouvoir me conforter dans cette idée, j’ai souhaité réaliser un stage au cœur de ce domaine pour ma 3e année. C’est là que j’ai rencontré Datanalysis, une petite entreprise réunionnaise et à fond dans l’innovation.

Durant les 4 mois qui ont suivi, j’ai pu m’intégrer très vite à leur équipe, découvrir leur monde et ce qu’ils y font.

J’ai pu réaliser diverses missions en interne qui m’ont permis d’acquérir énormément de connaissances dans ce domaine en peu de temps et de manière autonome. J’ai par exemple, appris à maîtriser Tableau Software, un outil majeur dans la visualisation de données mais également plein d’autres outils qui me seront très utiles dans l’avenir.

A la suite de ce stage, je m’envolerai vers une université d’Irlande pour me spécialiser dans la Data Analytics !

Nous sommes fiers d’avoir pu travaillé à ses côtés et de lui avoir fait découvrir l’accessibilité et la transparence des données. Nous encourageons tous les futurs étudiants, les passionnés, les déterminés ou même personnes en reconversion à découvrir ce « monde » qui nous entoure !

Découvrir notre playground !
Artificial Intelligence, Business Intelligence, Data Governance, Data Marketing, Data visualisation, Machine Learning, Self-service Analytics, Technology

DATA : les 7 pièges à éviter. Ep 3/7 – Erreurs Mathématiques : comment sont calculées les données ?

Nous avons tous un jour exprimé notre incrédulité quant à l’intérêt des mathématiques dans notre vie quotidienne. A quoi ce sujet dense et complexe pouvait bien servir ? Et bien, dans un monde où les données sont présentes partout et infusent chaque décision stratégique des organisations, les mathématiques sont d’une importance vitale (nda : elles l’ont toujours été !)

Dans nos projets d’analyse de données, les erreurs mathématiques peuvent arriver dès lors qu’un champ calculé est créé pour générer des informations supplémentaires à partir de notre jeu de données initial. Ce type d’erreur peut être retrouvé par exemple lorsque :

  • On réalise des agrégations (somme, moyenne, médiane, minimum, maximum, comptage, comptage distinct etc.) à différents niveaux de détail
  • Nous faisons des divisions pour produire des ratios ou des pourcentages
  • Nous travaillons avec des unités différentes

Il s’agit évidemment d’une infime partie des types d’opérations où des erreurs peuvent se glisser. Mais au regard de notre expérience, ce sont les causes principales de problème que nous rencontrons.

Et, dans chacun de ces cas, il ne faut pas être un ingénieur ou scientifique de génie pour les corriger. Un peu d’attention et pas mal de rigueur sont nécessaires !

1. Les erreurs de traitement d’unité

Dans cet article, nous n’allons pas trop nous attarder sur cette erreur fréquente. En effet, il existe un nombre important d’articles et d’anecdotes qui illustrent parfaitement et en détail ce type de problématique (dont nous avons également parlé dans l’article précédent).

L’exemple le plus fameux, et coûteux, est le crash de la sonde « Mars Orbiter ». Si vous voulez en savoir plus alors cela sera par ici : Mars Climate Orbiter – Wikipedia

Vous pouvez arguer qu’aucun d’entre nous ne fait partie de la NASA et doit poser une sonde sur une planète lointaine et donc ne pas être concerné. Et bien, vous pouvez à votre mesure, vous retrouver nez à nez avec ce type d’erreur lorsque vous manipulez des données temporelles (heures, jours, secondes, minutes, années), financières (différentes devises), ou que vous gériez des stocks (unités, kilos, palettes, barres etc.).

2. Aggravation des agrégations

Nous agrégeons des données lorsque nous regroupons des enregistrements qui ont un attribut en commun. Il y a toutes sortes de regroupements de ce genre que nous traitons dans notre monde dès lors que nous pouvons établir des liens hiérarchiques ; le temps (jour, semaine, mois, années), la géographie (villes, région, pays), les organisations (employés, équipes, sociétés) etc.

Les agrégations sont un outil puissant pour appréhender le monde, mais attention, elles comportent plusieurs facteurs de risque :

  • Les agrégations résument une situation et ne présentent pas les informations détaillées. Tous ceux qui ont participé à une formation sur la datavisualisation avec nos équipes sont familiers du quarter d’Anscombe :

Le résumé statistique est un exemple typique de ce que peuvent masquer des agrégats. Dans cet exemple les quatre jeux de données ont exactement les mêmes sommes, moyennes et déviation standards sur les deux coordonnées (X,Y). Lorsque l’on représente chacun des points sur des courbes, il est aisé de constater que les 4 histoires sont significativement différentes.

Dès lors que des données sont agrégées, nous essayons de résumer une situation. Il faut toujours se rappeler que ce résumé masque les détails et le contexte qui l’expliquent. Alors soyez prudent lorsque, lors d’une discussion, vos interlocuteurs ne parlent que de valeurs moyenne, de sommes ou de médiane sans entrer dans le détail de ce qui a pu engendrer ce scénario précis.

  • Les agrégations peuvent également masquer les valeurs manquantes et induire en erreur. En effet, selon la façon dont nous représentons des informations, il est possible que le fait que des données soient manquantes ne soit pas clairement visibles de prime abord.

Prenons par exemple un jeu de données dans lequel nous observons pour une compagnie aérienne le nombre d’impacts d’oiseaux sur des avions.

Notre objectif est de déterminer le (ou les) mois de l’année où le plus d’incidents ont été relevés. Cela donne :

Le mois de juillet semble être le mois où le nombre d’impacts décomptés a été le plus important. Toutefois, si nous regardons le détail par année, nous nous rendons compte que l’agrégation choisie pour répondre à notre interrogation ne permettait pas de déterminer que les saisies pour l’année 2017 s’arrêtaient lors de ce fameux mois de juillet :

La réponse à notre question était donc le mois d’Août si nous excluons les données de l’année pour laquelle nous n’avions pas tous les enregistrements.

  • Totaux et agrégations :

Dernier exemple de problématiques liées aux agrégations que nous allons découvrir dans cet article. Il s’agit d’une des erreurs « favorites » de l’auteur de cet article. D’aucun pourrait même parler de spécialité !

Elle intervient lorsqu’il est nécessaire de compter les individus distincts dans une population donnée. Mettons que nous regardons notre base client et cherchons à savoir combien d’individus uniques sont présents dans celle-ci.

Le comptage des id distincts pour l’ensemble de la société nous donne un décompte de nos clients uniques :

Mais si l’on regarde par ligne de produit et affichons une somme sans y prêter attention :

Nous trouvons 7 clients de plus !

Cela arrive simplement car il existe dans la clientèle de la société étudiée des clients qui prennent à la fois des prestations ET des licences, et qui finissent par être comptés deux fois dans le total !

Il s’agit d’un problème ayant des solutions simples dans tous les logiciels modernes de datavisualisation et de BI mais celui-ci à tendance à se cacher au détour d’une série de calculs et d’agrégations, causant des écarts parfois surprenants en bout de chaîne.

3. Panique à bord, un ratio !

Nous allons illustrer ce point avec un exemple sorti de l’un des dashboards que nous avons fait pour un de nos clients. Avec toute notre expertise, il nous arrive aussi de sauter à pieds joints dans ce type d’erreurs :

Et oui, il s’agit d’un taux d’occupation qui excède « légèrement » les 100% !

Comment est-ce possible ? Un simple oubli !

La somme des divisions n’est pas égale à la division des sommes…

En effet, dans ce cas précis, nous avions un jeu de données similaire à celui ci-dessous :

Est-ce que le taux d’occupation est égal à :

  • La somme des taux d’occupation individuels ? FAUX !

Cela nous donne un total de 30 % + 71 % + 100 % + 50 % + 92 % +70 % soit 414 %.

Et c’est exactement l’erreur que nous avons faite sur un jeu de données encore plus vaste…

  • Ou le ratio du total des passagers sur le total de la capacité disponible ? 125/146 = 86%. C’est plus juste !

Remarque : la moyenne des taux d’occupation individuels serait également fausse.

En résumé, dès lors que l’on manipule un ratio, il s’agit de diviser le total des valeurs du numérateur et du dénominateur pour éviter ce type de soucis.

Il s’agit dans ce cas précis d’un seul exemple d’erreur liée au ratio. Des mentions honorables peuvent être attribuées au traitement des valeurs NULL dans un calcul, ou à la comparaison de ratios qui ne sont pas calculés avec les mêmes dénominateurs.

Dans le prochain article, nous allons explorer le 4ème type d’obstacle que nous pouvons rencontrer lorsque nous utilisons les données pour éclairer le monde qui nous entoure :

Les dérapages statistiques. (Spoilers : « There are lies, damned lies and statistics » B.Disraeli)

Cet article est inspiré fortement par le livre ” Avoiding Data pitfalls – How to steer clear of common blunders when working with Data and presenting Analysis and visualisation” écrit par Ben Jones, Founder and CEO de Data Litercy, édition WILEY. Nous vous recommandons cette excellente lecture!

 Pour retrouver l’intégralité des sujets qui seront abordés au cours de cette série par ici : https://www.datanalysis.re/blog/business-intelligence/data-les-7-pieges-a-eviter-intro/

Business Intelligence, Clients, Company, CRM, Data Governance, Data Marketing, Data Mining and Data Integration, Data Quality Management, Data visualisation, Data Warehouse, Machine Learning, Self-service Analytics

DATA: les 7 pièges à éviter. Ep 2/7 – Erreurs techniques : comment sont créées les données?

Après avoir défini quelques concepts primordiaux au regard de la donnée, nous pouvons nous plonger dans les sujets techniques qui peuvent être source d’erreur. Cet article traite des problématiques liées au process permettant d’obtenir les données qui seront par la suite exploitées. Il s’agit de la construction des fondations de nos analyses.

Et il est évident que nous ne souhaitons pas bâtir un château de cartes sur du sable !

Pour rester dans cette métaphore de la construction, si des problèmes de cette nature existent, ceux-ci seront cachés et peu visibles dans l’édifice final. Il est donc nécessaire d’apporter un soin particulier lors des étapes de collecte, de traitement, de nettoyage des données. Ce n’est pas pour rien que l’on estime que 80% du temps passé sur un projet de data science est consommé sur ce type de tâches. 

Afin d’éviter de tomber dans ce piège et de limiter la charge nécessaire à la réalisation de ces opérations qui peuvent être fastidieuses, il faut accepter trois principes fondamentaux :

  • Virtuellement tous les jeux de données ne sont pas propres et doivent être nettoyés et mis en forme
  • Chaque transition (formatage, jointure, liaison, etc.) lors des étapes de préparation est source potentiel d’une nouvelle erreur
  • Il est possible d’apprendre des techniques pour éviter la création des erreurs issues des deux premiers principes.

Accepter ces principes n’enlève pas l’obligation de passer par ce travail préalable à toute analyse mais, bonne nouvelle : savoir identifier ces risques et apprendre au fur et à mesure de nos projets, permet de limiter la portée de ce deuxième obstacle.

1. Le piège des données sales.

Les données sont sales. Je dirais même plus, toutes les données sont sales (voir premier principe énoncé précédemment), problématique de formatage, de saisie, d’unités incohérentes, de valeurs NULL etc.

Quelques exemples de ce piège sont très connus

Nous pouvons citer le crash de la sonde Mars Climate Orbiter de la NASA en 1999, par exemple. Une erreur à 125 millions de dollars qui a été causée par un double système d’unité : unités impériales et unités issues du système métriques. Cela a occasionné un calcul erroné qui a joué sur la puissance envoyée aux propulseurs de la sonde et à la destruction de celle-ci.

Heureusement, toutes les erreurs de cette nature ne vont pas nous coûter autant d’argent ! Mais elles auront malgré tout des impacts significatifs sur les résultats et le ROI des analyses que nous sommes amenés à mener.

Ainsi, chez DATANALYSIS, nous menons actuellement plusieurs projets spécifiquement sur la qualité de données dans le cadre de sujet de DATA Marketing et nous faisons face à deux types de sujet :

  • La validation des données qui visent à essayer d’améliorer la qualité de celle-ci grâce aux traitements des données, en :

-Normalisant les champs (numéro de téléphone, email etc.) : +262 692 00 11 22 / 00262692001122 / 06-92-00-11-22 correspondent à la même ligne et nous pouvons grâce à des traitements adaptés automatiser une grande partie de ce travail ;

– Complétant des champs vides grâce aux autres données présentes dans la table. Nous pouvons par exemple déduire le pays de résidence à partir des indicatifs téléphoniques, des codes postaux, des villes etc.

 

  • La déduplication, en :

-Cherchant à identifier grâce à des règles adaptées des lignes potentiellement identiques. Deux enregistrements ayant le même mail, ou le même numéro de téléphone, ou le même identifiant pour les entreprises ;

-Cherchant grâce à des algorithmes de calcul de distance à définir les valeurs proches en termes d’orthographe, de prononciation, de caractères communs etc.

Au regard de ces quelques exemples et de nos propres expériences, il est possible de constater que ce type d’erreur provient principalement des processus de saisie, de collecte ou de « scrapping » des données qu’ils soient mis en œuvre automatiquement ou par des humains. Ainsi outre les solutions que l’on peut mettre en œuvre dans les traitements de préparations de données, l’amélioration de ces étapes préalables permettra également d’améliorer grandement la qualité des données à traiter, et cela passe par l’éducation, la formation et la définition de règles et de normes clairement connues et partager (la data gouvernance n’est jamais loin).

Enfin, il convient également de se demander au regard de cette étape, quand nous pouvons considérer comme suffisamment propre. En effet, nous pouvons toujours faire plus et mieux, mais souvent les coûts engendrés peuvent dépasser les retours espérés.

2. Le piège des transformations des données

Dans le monde informatique, il existe une image visant à résumer ce type de problématique :

Souvent l’erreur se situe entre l’écran et le siège !

Et oui, même les meilleurs data scientists, data analysts ou data engineers peuvent se tromper dans les étapes de nettoyage, de transformation et de préparation des données.

Fréquemment, nous manipulons plusieurs fichiers issus de différentes sources, de différentes applications, ce qui multiplie les risques liés aux problématiques de données sales et les risques lors de la manipulation des fichiers en eux-mêmes :

  • Niveaux de granularités différents
  • Jointure sur des champs dont les valeurs ne sont pas exactement identiques (ST-DENIS vs SAINT DENIS par exemple)
  • Périmètre couverts différents sur les fichiers.

Et ce problème peut être également rendu plus complexe en fonction des outils utilisés dans le cadre de nos analyses :

  • Dans Tableau par exemple nous pouvons faire des jointures, des relations ou des liaisons de données pour lier plusieurs jeux de données entre eux. Chaque type d’opération a ses propres règles, contraintes.
  • Dans Qlik, il est nécessaire de bien comprendre comment fonctionne le moteur associatif et les règles de modélisation associées qui diffèrent de celles d’un modèle décisionnel traditionnel.

Il s’agit dans ce cas souvent de contraintes techniques liées au métier même de préparation de données et prendre le temps d’appréhender les risques et les processus en place permettra de gagner un temps important sur la mise à disposition d’analyse de données fiables et performantes.

Dans le prochain article, nous allons explorer le 3ème type d’obstacle que nous pouvons rencontrer lorsque nous utilisons les données pour éclairer le monde qui nous entoure : Les Erreurs Mathématiques

Cet article est inspiré fortement par le livre ” Avoiding Data pitfalls – How to steer clear of common blunders when working with Data and presenting Analysis and visualisation” écrit par Ben Jones, Founder and CEO de Data Litercy, édition WILEY. Nous vous recommandons cette excellente lecture!

 Pour retrouver l’intégralité des sujets qui seront abordés au cours de cette série par ici : https://www.datanalysis.re/blog/business-intelligence/data-les-7-pieges-a-eviter-intro/

Artificial Intelligence, Business Intelligence, Clients, Company, Data Governance, Data Marketing, Data Mining and Data Integration, Data visualisation, Machine Learning

DATA : les 7 pièges à éviter. Ep 1/7 – Erreurs Epistémologiques : comment pense-t-on aux données ?

Commençons par définir ce qu’est l’épistémologie.

L’épistémologie (du grec ancien ἐπιστήμη / epistémê « connaissance vraie, science » et λόγος / lógos « discours ») est un domaine de la philosophie qui peut désigner deux champs d’étude : l’étude critique des sciences et de la connaissance scientifique (ou de l’œuvre scientifique).

Autrement dit, il s’agit de la manière dont nous construisons nos connaissances.

Dans le monde de la donnée, il s’agit d’un sujet central et critique. En effet, nous avons été familiarisés avec le processus de transformation de la donnée, en informations, en connaissance et en élément de sagesse :

Ici le problème trouve sa source dans la manière dont nous considérons notre point de départ : les données ! En effet, l’utilisation de celle-ci et sa transformation au cours des étapes suivantes relèvent de procédés et processus conscients et maîtrisés :

==>Je nettoie ma donnée, la traite dans un ETL / ELT, la stocke, la visualise, communique mon résultat et le partage etc. Cette maîtrise nous donne le contrôle sur la qualité des étapes. Toutefois, on aura tendance à se lancer dans ce travail de transformation de notre ressource primaire en omettant un point crucial, source de notre premier obstacle :

LA DONNEE N’EST PAS UNE REPRESENTATION EXACTE DU MONDE REEL !

En effet, il est excessivement simple de travailler avec des données en pensant aux données comme étant la réalité elle-même et pas comme des données collectées à propos de la réalité. Cette nuance est primordiale :

  • Ce n’est pas la criminalité, mais les crimes déclarés
  • Ce n’est pas le diamètre d’une pièce mécanique mais le diamètre mesuré de cette pièce
  • Ce n’est pas le sentiment du public par rapport à un sujet mais le sentiment déclaré des personnes qui ont répondu à un sondage

Entrons dans le détail de cet obstacle avec quelques exemples :

1. Ce que nous ne mesurons pas (ou ce que nous ne mesurions pas)

Regardons ensemble ce dashboard présentant l’ensemble des impacts de météorites sur la Terre entre -2500 et 2012. Pouvez vous identifiez ce qu’il y a d’étranges ici ?

Les météorites semblent avoir évité soigneusement certaines parties de la planète, une large part de l’Amérique du Sud, de l’Afrique, de la Russie, du Groenland etc. Et si l’on se concentre sur le graphique montrant le nombre de météorites par années, que celles-ci ont eu tendance à tomber plutôt dans les 50 dernières années (et presque pas sur l’ensemble de la période couvrant -2055 à 1975).

Est-ce qu’il s’agit bien de la réalité ? Ou plutôt de défauts dans la manière dont les données ont été collectées

  • Nous avons commencé à collecter systématiquement ces informations récemment et nous basons sur l’archéologie pour essayer de déterminer les impacts du passé. L’érosion et le temps faisant leurs œuvres, les traces de la grande majorité des impacts ont ainsi disparu et ceux-ci ne peuvent donc plus être comptabilisés (et non, les météorites n’ont pas commencé à pleuvoir en 1975).
  • Pour qu’un impact de météorite soit intégré dans une base de données, il faut que celui-ci soit enregistré. Et pour cela, il faut une observation, et donc un observateur et que celui-ci sache à qui remonter cette information. Deux biais impactant largement la collecte et permettant d’expliquer les larges zones de Terre qui semblent avoir été épargnées par la chute de météorite.

2. Le système de mesure ne fonctionne pas

Parfois, la cause de cet écart entre la donnée et la réalité peut être expliqué par un défaut du matériel de collecte. Malheureusement, tout ce qui est fabriqué par un être humain en ce bas monde est susceptible d’être défaillant. Cela vaut pour les capteurs et les instruments de mesure évidemment.

Que s’est-il passé les 28 et 29 avril 2014 sur ce pont ? Il semblerait qu’il y ait un énorme pic de traversée du pont de Fremont par des vélos mais uniquement dans un seul sens (courbe bleue).

Source : 7 datapitfalls – Ben Jones

Série temporelle du nombre de vélos traversant le pont de Fremont

On pourrait penser qu’il s’agissait d’une magnifique journée d’été et que tout le monde est passé sur le pont en même temps ? D’une course de vélos n’empruntant celui-ci que dans un sens ? Que tous les pneus de toutes les personnes ayant traversé le pont à l’aller ont crevé avant le retour ?

Plus prosaïquement, il s’avère que le compteur bleu avait un défaut ces jours précis et ne comptait plus correctement les traversées du pont. Un simple changement de batterie et du capteur et le problème a été résolu.

Maintenant, posez vous la question du nombre de fois où vous avez pu être induit en erreur par des données issues d’un capteur ou d’une mesure défaillante sans que cela n’ait été perçu ?

3. Les données sont trop humaines

Et oui, nos propres biais humains ont un effet important sur les valeurs que nous enregistrons lors de la collecte d’informations. Nous avons par exemple tendance à arrondir les résultats des mesures :

Source : 7 datapitfalls – Ben Jones

Si l’on s’en fit à ses données, le changement des couches se fait plus régulièrement toutes les 10 minutes (0, 10, 20, 30, 40, 50) et parfois sur certains quarts d’heure (15, 45). Cela serait assez incroyable n’est-ce pas ?

Il s’agit bien d’un récit incroyable. En effet, il faut se pencher ici sur la manière dont les données ont été collectées. En tant qu’être humain, nous avons cette tendance à arrondir les informations lorsque nous les enregistrons, notamment lorsque nous regardons une montre ou une horloge : pourquoi ne pas indiquer 1:05 lorsqu’il est 1 :04 ? ou encore plus simple 1:00 car c’est plus simple encore ?

On retrouvera ce type de simplification humaine dans toutes les collectes de mesures : poids, tailles, etc.

4. Le Cygne Noir !

Dernier exemple que nous souhaitons mettre en avant ici, et ce que l’on appelle l’effet « Cygne Noir ». Si nous pensons que les données dont nous disposons sont une représentation exacte du monde qui nous entoure et que nous pouvons en sortir des affirmations à graver dans le marbre ; alors nous nous trompons fondamentalement sur ce qu’est une donnée (cf. précédemment).

Le meilleur usage des données est d’apprendre ce qui n’est pas vrai à partir d’une idée préconçue et de nous guider dans les questions que nous devons nous poser pour en apprendre plus ?

Mais revenons à notre cygne noir :

Avant la découverte de l’Australie, toutes les observations de cygne jamais faite pouvaient conforter les européens que tous les cygnes étaient blancs, à tort ! En 1697, l’observation d’un cygne noir a remis intégralement en question cette préconception commune.

Et le lien avec les données ? De la même manière que l’on aura tendance à croire qu’une observation répétée est une vérité générale ; à tort ; on peut être amener à inférer que ce que nous voyons dans les données que nous manipulons peut s’appliquer de manière générale au monde qui nous entoure et à toute époque. C’est une erreur fondamentale dans l’appréciation des données.

5. Comment se prémunir de l’erreur épistémologique ?

Il suffit pour cela d’une légère gymnastique mentale et d’un peu de curiosité :

  • Comprendre clairement comment ont été définies les mesures
  • Comprendre et représenter le processus de collection des données
  • Identifier les limites et erreurs de mesure possibles dans les données utilisées
  • Identifier les changements dans la méthode et les outils de mesure dans le temps
  • Comprendre les motivations des personnes ayant collecté les données

Dans le prochain article, nous allons explorer le 2ème type d’obstacle que nous pouvons rencontrer lorsque nous utilisons les données pour éclairer le monde qui nous entoure : Les Erreurs Techniques 

Cet article est inspiré fortement par le livre « Avoiding Data pitfalls – How to steer clear of common blunders when working with Data and presenting Analysis and visualisation” écrit par Ben Jones, Founder and CEO de Data Litercy, edition WILEY. Nous vous recommandons cette excellente lecture!

Pour retrouver l’intégralité des sujets qui seront abordés au cours de cette série par ici : https://www.datanalysis.re/blog/business-intelligence/data-les-7-pieges-a-eviter-ep-1-7/

Business Intelligence, Data Governance, Data Marketing, Data Mining and Data Integration, Data visualisation

DATA : les 7 pièges à éviter. L’introduction.

DATA ! DATA ! Partout des DATA !

De nos jours, la donnée est partout, mise en avant dans tous les nouveaux projets et toutes les stratégies d’entreprise. C’est la clé de la performance dans une époque pleine d’incertitudes. Chez Datanalysis, nous en sommes les premiers convaincus car il s’agit d’un outil puissant et accélérateur de performance… lorsque celle-ci est bien utilisée, bien comprise et bien maîtrisée !

Dans cette nouvelle série d’articles, nous allons donc parler du grand méchant loup ; du diable qui se cache dans le détail (ou qui se révèle parfois au grand jour) et évoquer avec vous les 7 principaux types de pièges posés par la donnée et son usage. Nous tâcherons autant que possible de les illustrer par un exemple de notre propre expérience car en tant qu’experts nous avons eu la chance de faire face dans nos missions à chacun d’entre eux…

Remarque : Ces pièges sont ceux évoqués dans le livre de Ben Jones, « 7 data pitfalls » que nous vous conseillons chaudement !

Trêve de suspense, dévoilons à présent les 7 familles de péchés capitaux de la DATA que nous allons explorer plus en détail pendant les 7 prochaines semaines :

1. Erreurs Epistémologiques : comment pense-t-on aux données ?

Souvent nous utilisons les données avec le mauvais état d’esprit ou des préconceptions erronées. Ainsi, si nous nous attaquons à un projet d’analyse en pensant que les données sont une représentation parfaite de la réalité ; que nous établissons des conclusions définitives sur la base de prédiction sans les remettre en question ; ou que nous cherchons dans les informations disponibles tout ce qui pourrait confirmer une opinion déjà faite ; alors nous pouvons créer des erreurs critiques dans les fondations même de ces projets.

2. Erreurs Techniques : comment sont traitées les données ?

Les enjeux techniques et technologies sont souvent une source importante d’erreurs dans le monde de la donnée. Une fois que l’on a identifié les informations dont on a besoin se dresse devant nous une série importante d’obstacles à franchir. Est-ce que mes capteurs sont fonctionnels ? Est-ce que mes traitements ne génèrent pas des doublons ? Est-ce que mes données sont propres ou bien mises à niveau ? Des enjeux complexes dans nos projets ! En effet, ne dit-on pas qu’un data analyst passe la majeure partie de son temps et de son énergie à préparer et nettoyer ses données ?

3. Erreurs Mathématiques : comment sont calculées les données ?

Et voilà, vous savez maintenant à quoi vous servent vos cours de mathématiques de vos années d’école, de collège et de lycée ! Il y en a pour tous les niveaux et pour tous les goûts ! Que celui qui n’a jamais associé des données qui ne sont pas au même niveau de détail, qui ne s’est pas trompé dans le calcul de ses ratios, ou qui n’a pas oublié qu’il ne faut pas mélanger carottes et bananes, nous jette la première pierre !

4. Erreurs Statistiques : comment les données sont mises en relation ?

Comme le dit l’adage, « Il y a des mensonges, des maudits mensonges et des statistiques ». Il s’agit là du piège le plus complexe à appréhender car de sacrées compétences sont nécessaires pour en bien comprendre les enjeux. Toutefois, dans un monde où le machine learning, le datamining et l’IA sont rois, c’est une famille d’erreurs qui ne fait que devenir plus fréquente !

Les mesures de tendance centrale ou de variation que nous utilisons nous égarent-elles ? Est-ce que les échantillons sur lesquels nous travaillons sont représentatifs de la population que nous voulons étudier ? Est-ce que nos outils de comparaison sont valides et significatifs statistiquement ?

5. Aberrations analytiques : comment sont analysées les données ?

Règle d’or: nous sommes tous des analystes (que l’on porte ce titre ou non).

Dès lors que nous utilisons des données pour prendre des décisions alors nous sommes des analystes et nous sommes donc sujets à prendre des décisions sur des analyses aberrantes. Connaîssez-vous par exemple les ‘vanity metrics’ ? Ou avez-vous déjà fait des extrapolations qui ne font aucun sens au regard des données utilisées ?

Ces deux derniers sujets nous tiendront encore plus à cœur que les précédents car nous sommes gaga de Data Visualisation et donc nous avons un grand nombre d’exemples de gaffes graphiques ou de ratés esthétiques !

6. Gaffes graphiques : comment sont visualisées les données ?

Contrairement aux erreurs statistiques ou aux aberrations analytiques, les gaffes graphiques sont bien connues et facilement identifiables. Pourquoi ? Parce que celles-ci se voient (et souvent de loin). Avons-nous choisi un type de graphique adapté à notre analyse ? Est-ce que l’effet que je souhaite montrer est clairement visible ?

7. Dangers esthétiques : le beau peut être l’ennemi du bien ?

Quelle différence avec les gaffes graphiques ?

Ici nous parlons du design général du produit final et des interactions que nous avons définies dans celui-ci pour que l’auditoire que nous cherchons à convaincre aient l’expérience la plus ergonomique et esthétique possible ! Est-ce que le choix des couleurs qui a été fait rend l’analyse confuse ou au contraire la simplifie ? Est-ce que nous avons utilisé de notre créativité pour rendre nos dashboards agréables à l’œil et avons-nous utilisé l’esthétique pour apporter de l’impact à l’analyse qui est faite ? Est-ce que le produit final est simple à utiliser, ergonomique ou les interactions sont complexes et poussives ?

Etes-vous prêts à nous suivre dans les méandres de tout ce qui peut mal se passer sur vos projets d’analyse de données et ainsi ne pas tomber dans ces pièges ?

Alors à la semaine prochaine !

Cet article vous a inspiré ?