Data Regulations – Datanalysis – Mettons vos données en action

Business Intelligence, Data Governance, Data Marketing, Data Mining and Data Integration, Data Quality Management, Data Regulations, Data visualisation, Machine Learning, Self-service Analytics

02 septembre 20240

DATA: Les 7 pièges à éviter, Ep 5/7 – Aberrations analytiques

L’intuition et l’analyse ne sont pas mutuellement exclusives

Dans notre quête pour tirer le meilleur parti des données, nous tombons souvent dans le piège de considérer l’intuition et l’analyse comme des approches mutuellement exclusives. Cependant, comme nous le verrons dans cet épisode sur les aberrations analytiques, l’intuition joue un rôle crucial dans le processus d’analyse des données.

Piège 5A: la fausse dichotomie intuition/analyse

Il fut un temps où l’on entendait des publicités vantant le passage de l’intuition à l’analyse dans la prise de décision. Cette vision est erronée. L’intuition n’est pas obsolète à l’ère des données – elle est en réalité plus précieuse que jamais.

L’intuition est l’étincelle qui fait fonctionner le moteur de l’analyse. Elle nous aide à :

Savoir POURQUOI les données sont importantes
Comprendre CE QUE les données nous disent (et ne nous disent pas)
Savoir OÙ chercher ensuite
Savoir QUAND arrêter l’analyse et passer à l’action
Savoir QUI a besoin d’entendre les résultats et COMMENT les communiquer

Piège 5B: les extrapolations exubérantes

Prédire l’avenir à partir des données peut être risqué. L’extrapolation des tendances actuelles peut conduire à des erreurs importantes si nous ne tenons pas compte des limites naturelles ou des changements potentiels.

Par exemple, si nous examinons l’espérance de vie en Corée du Nord et du Sud de 1960 à 1980, nous pourrions être tentés de prédire une augmentation continue et linéaire. Cependant, la réalité s’est avérée bien différente, notamment pour la Corée du Nord qui a connu une baisse significative dans les années 1990.

Piège 5C: les interpolations mal avisées

Lorsque nous travaillons avec des données chronologiques, nous devons être prudents dans nos interprétations entre les points de données. Un graphique en pente simple reliant deux points dans le temps peut masquer des fluctuations importantes entre ces points.

Par exemple, considérons l’espérance de vie dans certains pays entre 1960 et 2015. Un simple graphique en pente montrant le changement entre ces deux années pourrait donner l’impression d’une augmentation régulière et constante. Cependant, cette représentation simplifiée masquerait des périodes de conflit, de difficultés économiques ou de progrès rapides en matière de santé publique qui ont eu un impact significatif sur l’espérance de vie au fil des années.

Prenons le cas du Cambodge, du Timor-Leste, de la Sierra Leone et du Rwanda. Un graphique en pente simple montrerait une augmentation de l’espérance de vie entre 1960 et 2015, mais occulterait complètement les périodes tragiques de guerre et de génocide que ces pays ont connues. Par exemple, l’espérance de vie au Cambodge est tombée à moins de 20 ans en 1977 et 1978, un fait crucial qui serait complètement ignoré dans une simple interpolation entre 1960 et 2015.

Ce graphique montre l’évolution réelle de l’espérance de vie dans ces pays, révélant les fluctuations dramatiques masquées par une simple interpolation linéaire.

Piège 5D: les prévisions farfelues

Les prévisions, en particulier celles à long terme, peuvent être particulièrement sujettes aux erreurs. Un exemple frappant est celui des prévisions de chômage faites par différentes administrations présidentielles américaines. Ces prévisions ont tendance à montrer un retour rapide à un taux « normal » de 4 à 6%, indépendamment de la situation économique réelle.

Ce phénomène s’explique par plusieurs facteurs. Tout d’abord, il y a une pression politique pour présenter des perspectives optimistes. Ensuite, il existe une tendance naturelle à supposer que les situations extrêmes ou inhabituelles se corrigeront d’elles-mêmes rapidement. Enfin, les modèles de prévision sont souvent basés sur des données historiques et peuvent ne pas bien prendre en compte les changements structurels de l’économie.

Par exemple, lors de la crise financière de 2008, les prévisions de chômage faites juste avant ou au début de la crise n’ont pas réussi à anticiper l’ampleur et la durée de l’augmentation du chômage. De même, les prévisions faites au plus fort de la crise ont souvent sous-estimé le temps nécessaire pour que le taux de chômage revienne à des niveaux pré-crise.

Ce graphique montre comment différentes administrations présidentielles ont systématiquement prévu un retour rapide à un taux de chômage « normal », même face à des réalités économiques très différentes.

Piège 5E: les mesures moroniques

Il est crucial de s’assurer que les mesures que nous utilisons sont pertinentes et significatives. Trop souvent, nous nous concentrons sur des mesures faciles à obtenir plutôt que sur celles qui sont vraiment importantes pour comprendre un phénomène ou prendre des décisions.

Dans le domaine du sport, par exemple, de nombreuses mesures traditionnelles peuvent être trompeuses. Prenons le cas du basket-ball professionnel : la vitesse moyenne d’un joueur sur le terrain peut sembler être une mesure intéressante, mais elle ne reflète pas nécessairement l’impact réel du joueur sur le jeu.

LeBron James, l’un des meilleurs joueurs de tous les temps, a été critiqué lors des playoffs de 2018 pour avoir la vitesse moyenne la plus basse sur le terrain. Cependant, cette mesure ne tenait pas compte de son impact réel sur le jeu, mesuré par des statistiques plus pertinentes comme le Player Impact Estimate (PIE).

Ce graphique montre la relation entre la vitesse moyenne et le PIE des joueurs de NBA. On peut voir que LeBron James (point en haut à gauche) a un PIE très élevé malgré une vitesse moyenne relativement basse, illustrant pourquoi la vitesse moyenne seule est une mesure inadéquate de la performance d’un joueur.

Ce cas illustre l’importance de choisir des mesures qui reflètent réellement ce que nous cherchons à évaluer, plutôt que de nous contenter de mesures faciles à obtenir mais potentiellement trompeuses.

CONCLUSION

Dans cet article, nous avons exploré le cinquième type d’erreur que nous pouvons rencontrer lorsque nous utilisons les données pour éclairer le monde qui nous entoure : les aberrations analytiques. Nous avons vu comment l’intuition et l’analyse peuvent travailler de concert, et comment éviter les pièges des extrapolations exubérantes, des interpolations mal avisées, des prévisions farfelues et des mesures moroniques.

Dans le prochain article, nous allons explorer le 6ème type d’erreur de notre série : les gaffes graphiques. Nous verrons comment les erreurs dans la visualisation des données peuvent conduire à des interprétations erronées et des décisions mal informées.

Cette série d’articles est fortement inspirée par le livre « Avoiding Data Pitfalls – How to Steer Clear of Common Blunders When Working with Data and Presenting Analysis and Visualizations » écrit par Ben Jones, Founder and CEO de Data Literacy, édition WILEY. Nous vous recommandons vivement cette excellente lecture pour approfondir votre compréhension des pièges liés aux données et comment les éviter !

Vous trouverez tous les sujets abordés dans cette série ici : https://www.datanalysis.re/blog/business-intelligence/data-les-7-pieges-a-eviter-intro/

Cet article vous a inspiré ?

Discutons-en !

Business Intelligence, Company, Data Governance, Data Marketing, Data Mining and Data Integration, Data Quality Management, Data Regulations, Data visualisation, Data Warehouse, Machine Learning, Technology

14 mars 20240

SQL basique: quézako ?

Pendant très longtemps réservé aux personnes averties et techniques du service informatique, le SQL n’était pas à la portée de n’importe quelle entité ou service d’une société. Rôle exclusivement réservé au service IT de l’entreprise auparavant. Désormais, la vulgarisation de « l’informatique » a permis à de nombreux services d’accéder aux données de leur entreprises via le SQL pour interroger leurs bases de données tels que les départements marketing, la comptabilité, le contrôle de gestion, les ressources humaines et bien d’autres encore !

Vous êtes une entreprise spécialiste du commerce électronique, de la santé, du retail ou tout simplement une PME / PMI? Vous avez un ensemble de données stockées dans une base de données?

Il est indispensable de connaître les éléments basiques du langage de requêtes structurées (SQL) pour vous permettre d’avoir rapidement des réponses à vos interrogations.

DEFINITION

Le SQL, ou Structured Query Language (Langage de Requête Structurée), est un langage de programmation spécialement conçu pour la gestion et la manipulation de bases de données relationnelles.

Il offre une interface standardisée permettant aux utilisateurs de communiquer avec les bases de données, d’effectuer des opérations telles que l’insertion, la mise à jour, la suppression et la récupération de données de manière efficace.

LES BASES DU SQL

Rappelons que le SQL n’est rien d’autre qu’un moyen de lire le contenu d’une base de données relationnelle pour remonter les informations dont un utilisateur a besoin pour répondre à un besoin.

STRUCTURATION DES DONNEES

Le SQL se base sur le modèle relationnel, qui organise les données sous forme de tables. Chaque table est composée de colonnes (champs) représentant des attributs spécifiques, et de lignes contenant les enregistrements

La structure des tables :

Dans le monde du SQL, la structure des tables est cruciale. Chaque table est définie par des colonnes, où chaque colonne représente un attribut particulier des données que vous stockez. Par exemple, une table « employés » pourrait avoir des colonnes telles que « nom« , « prénom« , « âge« , etc. Ces tables sont reliées par des clés, qui peuvent être des identifiants uniques pour chaque enregistrement, facilitant ainsi les relations entre différentes tables.

Les principales opérations (ou commandes / requêtes SQL basiques)

SELECT : Utilisé pour extraire des données d’une ou plusieurs tables. La clause SELECT permet de spécifier les colonnes à récupérer, les conditions de filtrage et l’ordre de tri. Cette clause est l’une des plus fondamentale du SQL. La clause WHERE, souvent utilisée avec SELECT, permet de filtrer les résultats en fonction de conditions spécifiques. Par exemple, vous pourriez vouloir récupérer uniquement les employés dont l’âge est supérieur à 30 ans, ou comme dans l’exemple ci-dessous uniquement les employés du service des ventes.

SELECT nom, prenom FROM employes WHERE service = ‘Ventes‘;

INSERT : Permet d’ajouter de nouvelles lignes dans une table

INSERT INTO clients (nom, prenom, email) VALUES (‘Doe’, ‘John’, ‘john.doe@email.com‘);

UPDATE : Permet d’ajouter de nouvelles lignes dans une table

UPDATE produits SET prix = prix * 1.1 WHERE categorie = ‘Electronique‘;

DELETE : Permet de supprimer des lignes d’une table en fonction de certaines conditions

DELETE FROM commandes WHERE date_commande < ‘2023-01-01‘;

Filtrage et tri

Pour filtrer les résultats, le SQL utilise la clause WHERE, permettant de spécifier des conditions pour sélectionner les données. De plus, la clause ORDER BY permet de trier les résultats selon une ou plusieurs colonnes.

Le filtrage et le tri sont des opérations essentielles dans le langage SQL, permettant de récupérer des données spécifiques et de les organiser de manière significative. Explorons ces concepts avec des exemples pratiques

Filtrage avec la Clause WHERE

La clause WHERE est utilisée pour filtrer les résultats d’une requête en spécifiant des conditions. Cela permet de sélectionner uniquement les données qui répondent à ces critères.

–Sélectionner les employés avant un salaire supérieur à 50000

SELECT nom, prenom, salaire

FROM employes

WHERE salaire > 50000;

Dans cet exemple, seuls les employés dont le salaire est supérieur à 50000 seront inclus dans les résultats.

Filtrage avec la Clause ORDER BY

La clause ORDER BY permet de trier les résultats d’une requête en fonction d’une ou plusieurs colonnes. Vous pouvez spécifier l’ordre de tri (croissant ou décroissant)

–Sélectionner les clients et trier par ordre alphabétique du nom

SELECT nom, prenom, email

FROM clients

ORDER BY nom ASC;

Dans cet exemple, les résultats seront triés par ordre alphabétique croissant du nom du client

Filtrage et Tri peuvent être combiné également, à savoir la combinaison entre la clause WHERE et la clause ORDER BY pour filtrer les résultats en même temps

–Sélectionner les produits de la catégorie ‘Electronique’ et trier par prix décroissant

SELECT nom_produit, prix

FROM produits

WHERE categorie = ‘Electronique’

ORDER BY prix DESC;

Il existe d’autres filtrages et tri avec des opérateurs mais cela devient du SQL qui n’est plus basique mais devient pour un public plus averti.

En comprenant ces concepts de filtrage et de tri, vous serez en mesure d’extraire des données spécifiques de vos bases de données SQL de manière ciblée et organisée.

Les jointures

Les jointures sont essentielles pour combiner des données provenant de plusieurs tables.

Les types courants de jointures incluent INNER JOIN, LEFT JOIN, RIGHT JOIN et FULL JOIN, chacun offrant des méthodes spécifiques pour associer des lignes entre différentes tables.

Exemple de jointure simple :

SELECT client.nom, commandes.date

FROM clients

INNER JOIN commandes ON clients.id_client = commandes.id_client;

Les types de jointures :

INNER JOIN : Renvoie les lignes lorsque la condition de jointure est vraie dans les deux tables.

LEFT JOIN (ou LEFT OUTER JOIN) : Renvoie toutes les lignes de la table de gauche et les lignes correspondantes de la table de droite.

RIGHT JOIN (ou RIGHT OUTER JOIN) : L’inverse du LEFT JOIN.

FULL JOIN (ou FULL OUTER JOIN) : Renvoie toutes les lignes lorsque la condition de jointure est vraie dans l’une des deux tables.

Contraintes pour l’intégrité des données et Index pour optimiser les performances

Les contraintes jouent un rôle crucial dans la garantie de l’intégrité des données. Les clés primaires assurent que chaque enregistrement dans une table est unique, tandis que les clés étrangères établissent des liens entre différentes tables. Les contraintes d’unicité garantissent qu’aucune valeur dupliquée n’est autorisée dans une colonne spécifiée

Les index sont des structures de données qui améliorent les performances des requêtes en accélérant la recherche de données. En créant un index sur une colonne, vous facilitez la recherche, mais il est essentiel de les utiliser judicieusement, car ils peuvent également augmenter la taille de la base de données

Conclusion

Le SQL est un outil puissant et universel pour travailler avec des bases de données relationnelles. Comprendre ses bases permet aux développeurs et aux analystes de données d’interagir de manière efficace avec les systèmes de gestion de bases de données, facilitant ainsi la manipulation et la récupération d’informations cruciales. Que ce soit pour des tâches simples ou des opérations plus complexes, le SQL reste un incontournable dans le domaine de la gestion de données

Il offre une panoplie d’outils pour interagir avec les bases de données relationnelles de manière puissante et flexible. En comprenant ces concepts de base, vous serez mieux équipé pour manipuler efficacement les données, créer des rapports personnalisés et répondre à des questions complexes à partir de vastes ensembles de données. Que vous soyez un développeur, un analyste de données ou un administrateur de base de données, la maîtrise du SQL est un atout inestimable dans le monde de la gestion de données.

Cet article vous a inspiré ?

Discutons-en !

06 mars 20240

Entrepôts de Données vs Lacs de Données : plongée comparative dans le monde de la Technologie

Dans le monde de la technologie, en constante évolution, deux termes font des vagues :

les Entrepôts de Données (Data Warehouses) et les Lacs de Données (Data Lakes).

Tous deux sont des outils puissants pour le stockage et l’analyse des données, mais ils servent à des fins différentes et possèdent des forces et faiblesses uniques. Plongeons dans le monde des données pour explorer ces deux géants technologiques.

Les Entrepôts de Données existent depuis un certain temps, offrant un moyen structuré et organisé de stocker des données. Ils sont comme une bibliothèque bien organisée, où chaque livre (donnée) a sa place. Les avancées récentes les ont rendus encore plus efficaces. Par exemple, la convergence des lacs de données et des entrepôts de données a mené à une approche plus unifiée du stockage et de l’analyse des données. Cela signifie moins de mouvements de données et plus d’efficacité – un double avantage !

De plus, l’intégration de modèles d’apprentissage automatique et de capacités d’IA a automatisé l’analyse des données, fournissant des insights plus avancés. Imaginez avoir un bibliothécaire personnel qui non seulement sait où chaque livre se trouve mais peut aussi prédire quel livre vous aurez besoin ensuite !

Cependant, chaque rose a ses épines. Les entrepôts de données peuvent être complexes et coûteux à mettre en place et à maintenir. Ils peuvent également avoir du mal avec les données non structurées ou le traitement des données en temps réel.

Mais ils brillent lorsqu’il est nécessaire d’avoir des données structurées, historiques pour le reporting et l’analyse, ou lorsque les données de différentes sources doivent être intégrées et cohérentes.

D’autre part, les lacs de données sont comme un vaste océan de données brutes, non structurées. Ils sont flexibles et évolutifs, grâce au développement du Data Mesh. Cela permet une approche plus distribuée du stockage et de l’analyse des données. De plus, l’utilisation croissante de l’apprentissage automatique et de l’IA peut automatiser l’analyse des données, fournissant des insights plus avancés.

Cependant, sans une gestion adéquate, les lacs de données peuvent devenir des « marécages de données », avec des données devenant désorganisées et difficiles à trouver et à utiliser.

L’ingestion et l’intégration des données peuvent également être longues et complexes. Mais ils sont le choix par excellence lorsqu’il est nécessaire de stocker de grands volumes de données brutes, non structurées, ou lorsque le traitement des données en temps réel ou quasi temps réel est requis.

En profondeur

ENTREPOTS DE DONNEES

Les avancées

Convergence des lacs de données et des entrepôts de données : Cela permet une approche plus unifiée du stockage et de l’analyse des données, réduisant le besoin de mouvements de données et augmentant l’efficacité.
Streaming plus facile des données en temps réel : Cela permet des insights plus opportuns et une prise de décision plus rapide.
Intégration de modèles d’apprentissage automatique et de capacités d’IA : Cela peut automatiser l’analyse des données et fournir des insights plus avancés.
Identification et résolution plus rapides des problèmes de données : Cela améliore la qualité et la fiabilité des données.

Les limites

Les entrepôts de données peuvent être complexes et coûteux à mettre en place et à maintenir.
Ils peuvent ne pas convenir aux données non structurées ou au traitement des données en temps réel.

Meilleurs scénarios pour l’implémentation :

Lorsqu’il est nécessaire d’avoir des données structurées, historiques pour le reporting et l’analyse.
Lorsque les données de différentes sources doivent être intégrées et cohérentes.

LACS DE DONNEES

Les avancées

Développement du Data Mesh : Cela permet une approche plus distribuée du stockage et de l’analyse des données, augmentant la scalabilité et la flexibilité.
Utilisation croissante de l’apprentissage automatique et de l’IA : Cela peut automatiser l’analyse des données et fournir des insights plus avancés.
Outils favorisant une approche structurée de développement-test-publication pour l’ingénierie des données : Cela peut améliorer la qualité et la fiabilité des données.

Les limites

Les lacs de données peuvent devenir des « marécages de données » s’ils ne sont pas correctement gérés, avec des données devenant désorganisées et difficiles à trouver et à utiliser.
L’ingestion et l’intégration des données peuvent être longues et complexes.

Meilleurs scénarios pour l’implémentation :

Lorsqu’il est nécessaire de stocker de grands volumes de données brutes, non structurées.
Lorsque le traitement des données en temps réel ou quasi temps réel est requis.

En conclusion, les entrepôts de données et les lacs de données ont tous deux leurs avantages et limites. Le choix entre eux dépend des besoins spécifiques et des circonstances de l’organisation.

C’est comme choisir entre une bibliothèque et un océan – les deux ont leur charme, mais le choix dépend de ce que vous recherchez. Ainsi, que vous soyez un passionné de technologie ou un leader d’entreprise, comprendre ces deux outils peut vous aider à prendre des décisions éclairées dans le monde de la technologie.

Après tout, dans le monde des données, la connaissance, c’est le pouvoir !

Cet article vous a inspiré ?

Discutons-en !

Artificial Intelligence, Business Intelligence, Data Governance, Data Marketing, Data Mining and Data Integration, Data Quality Management, Data Regulations, Data visualisation

21 juin 20230

DATA: Les 7 pièges à éviter, Ep 4/7 – Erreurs statistiques – Les faits sont des choses têtues, mais les statistiques sont malléables

« Il y a des mensonges, des maudits mensonges et des statistiques » B.Disraeli

Pourquoi un tel dégoût pour un domaine qui, selon le Merriam-dictionnaire Webster, est simplement « une branche des mathématiques traitant de la collecte, de l’analyse, de l’interprétation et de la présentation de masses de données numériques. »1 Pourquoi le domaine de la statistique est-il sous un jour si négatif par tant de personnes ?

Il y a quatre raisons principales à cela

C’est un domaine complexe. Même les concepts de base ne sont pas accessibles aisément et sont très difficile à expliquer
Même les experts les mieux intentionnés peuvent mal appliquer les outils à leur disposition
La troisième raison derrière toute cette haine est que ceux qui ont un agenda peuvent facilement créer des statistiques pour mentir lorsqu’ils communiquent avec nous
La dernière raison est que les statistiques peuvent souvent sembler froides et distantes, rendant l’appropriation très complexes par le public

Les Déboires descriptifs

Les statistiques descriptives ont pour objectif de résumer les principales caractéristiques d’un ensemble de données. Cependant, un usage incorrect ou inapproprié peut conduire à des conclusions trompeuses. Un exemple typique est l’utilisation de la moyenne pour résumer une distribution, sans tenir compte de la variabilité ou de l’asymétrie. Une autre erreur courante est de présenter des pourcentages sans expliquer l’effectif total, ce qui peut induire en erreur sur l’ampleur réelle d’un phénomène. Il est donc crucial de comprendre les hypothèses et les limites de chaque mesure descriptive pour l’utiliser correctement.

Prenons l’exemple de l’analyse des salaires au sein d’une entreprise. Si l’on se contente de regarder la moyenne des salaires, on pourrait conclure que l’entreprise rémunère bien ses employés. Cependant, si les salaires de la direction sont très élevés comparativement au reste des employés, la moyenne serait biaisée à la hausse. Il serait plus pertinent d’utiliser la médiane qui donne le salaire du milieu, ou encore de regarder la distribution complète des salaires pour avoir une vue plus précise.

Cette erreur est très bien décrite ici avec des chats :

Les Incendies inférentiels

Toujours une explication féline :

L’inférence statistique vise à tirer des conclusions sur une population à partir d’un échantillon de cette population. Cependant, ce processus est sujet à des erreurs. Les erreurs d’échantillonnage et les erreurs de type I et II sont courantes. De plus, les erreurs peuvent être exacerbées par la confusion entre corrélation et causalité. Il est essentiel d’avoir une solide compréhension des principes de l’inférence statistique pour éviter ces pièges.

Imaginons une étude de santé publique cherchant à établir un lien entre une habitude alimentaire particulière (comme manger bio) et un meilleur état de santé général. Si l’étude conclut à une corrélation positive, cela ne signifie pas forcément que manger bio cause un meilleur état de santé. Il pourrait y avoir des facteurs de confusion, comme le niveau de revenu ou le mode de vie, qui influencent à la fois l’habitude alimentaire et l’état de santé. Ici, on peut tomber dans le piège de confondre corrélation et causalité.

L'Échantillonnage glissant

L’échantillonnage est une étape cruciale dans tout processus de collecte de données. Pourtant, de nombreuses erreurs peuvent survenir à ce stade. L’échantillon peut ne pas être représentatif de la population cible, en raison de biais de sélection ou de non-réponse. De plus, la taille de l’échantillon peut être insuffisante pour détecter un effet. Il est donc essentiel de planifier soigneusement l’échantillonnage pour obtenir des résultats fiables.

Considérons une enquête de satisfaction client menée par une entreprise de commerce en ligne. Si l’entreprise ne sollicite que les avis des clients qui ont fait un achat récent, elle risque d’obtenir une image faussée de la satisfaction globale de sa clientèle. En effet, les clients insatisfaits peuvent avoir cessé de faire des achats et donc ne pas être inclus dans l’échantillon. C’est un exemple de biais de sélection.

L'insensibilité à la taille de l'échantillon

Une erreur courante dans l’analyse de données est d’ignorer l’impact de la taille de l’échantillon sur les résultats. Une taille d’échantillon importante peut rendre significatif un effet très faible, tandis qu’une taille d’échantillon trop petite peut ne pas avoir la puissance suffisante pour détecter un effet existant. De plus, la signification statistique ne signifie pas nécessairement une signification pratique. Ainsi, il est important de considérer la taille de l’échantillon dans l’interprétation des résultats.

Supposons que vous meniez une étude pour évaluer l’effet d’un médicament sur la baisse de la tension artérielle. Si vous avez un très grand échantillon de patients, vous pourriez constater une baisse statistiquement significative de la tension artérielle. Cependant, cette baisse peut être très faible, disons 0.1 mm Hg, une valeur cliniquement insignifiante malgré sa significativité statistique. C’est un exemple où la taille de l’échantillon peut rendre un effet faible significatif. D’un autre côté, si l’échantillon est trop petit, on peut passer à côté d’un effet réel. Il est donc important de considérer l’importance clinique ou pratique en plus de la significativité statistique.

En approfondissant cette question, Ben Jones (voir auteur ayant inspiré cet article) a réussi à trouver des chiffres sur le taux de cancer du rein ainsi que les données démographiques pour chaque comté américain, et il a créé un tableau de bord interactif (figure ci-dessous) pour illustrer visuellement le fait que Kahneman, Wainer et Zwerlink sont faire assez clairement dans les mots.

Remarquez quelques éléments dans le tableau de bord. Sur la carte choroplèthe (remplie), les comtés orange les plus foncés (taux élevés par rapport au taux global des États-Unis) et les comtés bleus les plus foncés (taux faibles par rapport au taux global des États-Unis) sont souvent côte à côte.

De plus, notez comment dans le nuage de points sous la carte, les marques forment une forme d’entonnoir, avec des comtés moins peuplés (à gauche) plus susceptibles de s’écarter de la ligne de référence (le taux global des États-Unis), et des comtés plus peuplés comme Chicago, L.A. , et New York sont plus susceptibles d’être proches de la ligne de référence globale.

Une dernière observation : si vous survolez un comté avec une petite population dans la version interactive en ligne, vous remarquerez que la moyenne

le nombre de cas par an est extrêmement faible, parfois 4 cas ou moins. Une petite déviation – même juste 1 ou 2 cas – dans une année suivante tirera un comté du bas de la liste vers le haut, ou vice versa.

Dans le prochain article, nous allons explorer le 5eme type d’erreur que nous pouvons rencontrer lorsque nous utilisons les données pour éclairer le monde qui nous entoure : Les aberrations analytiques.

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!

Data Governance, Data Regulations

25 septembre 20180

GDPR and Data Governance: A hand in hand affair

The introduction of GDPR should not be seen as a burden for companies but rather as an opportunity to review all the data governance policies that are in place. Companies should be able to find the right balance between GDPR and their data governance structure.

Companies could create a competitive edge by not only addressing how they manage the personal data but for all the data they hold. If companies get it right, they could discover new business opportunities waiting to be exploited.

As we all know by now, the GDPR gives every EU citizen the right to know and decide how their personal data is being used, stored, protected, transferred and deleted.

Those companies that put data privacy at the forefront of their business strategy would be the ones who are clearly and efficiently managing their customer data in a fair and transparent way. Hence giving them the competitive edge based on privacy.

One of the requirements of GDPR is to document what personal data is held, where it came from and who is it shared with. By really understanding the data they hold, companies could be made aware of the data they can gather, as well as analyse and apply this data to boost sales or marketing efforts.

Companies should ensure that their data governance structure will support the GDPR requirements. Policies and procedures need to be created or re-assessed to help keep corporate data consistent and ensure that it meets the information needs of business users. It is also an opportunity to review data management practices.

The GDPR requirements combined with a robust data governance structure could give organisations the opportunity to become a data-driven company based on building tools, abilities, and a culture that acts on data hence really making an internal transformation around data.

Data Regulations

10 septembre 20180

20 Fun Facts about GDPR ?

GDPR is short for General Data Protection Regulation.
GDPR are rules for the protection of personal data inside and outside the EU.
The aim of GDPR is to give residents control over their personal data and unify the regulations within the whole Union.
GDPR went into effect on May 25 ,2018.
Seven key guiding principles to process personal data.
GDPR covers aspects of data security, rights and freedoms of EU data subjects, regulatory compliance and risks, data governance and control of data.
GDPR is enforced by the supervisory authority in each member state.
GDPR affects any and every organization across the world that does business with people in EU member states.
It makes organizations directly accountable for what they do and don’t do with sensitive EU citizen data. This also includes governments agencies and other public associations.
There are a lot of processes and procedures to document!!
Technology plays a very important role.
GDPR allows for a 360 degree view of data subjects and a single source of truth.
Certain organisations that process data may be required to appoint a Data Privacy Officer.
The GDPR imposes a set of serious penalties on data controllers and processors for non-compliance.
The GDPR maximum penalty is 4% of global annual turnover or €20 million – whichever is higher.
A written warning can be sent to organisations in cases of first and non-intentional non-compliance.
Fines under GDPR of up to 10€ million or 2% of annual worldwide turnover will be imposed on organisations that don’t uphold the obligations of data controllers.
If an organisation incurs a data breach, they should notify the relevant authorities within 72 hours.
Implementing the GDPR is not an option, but a legal requirement, which needs a high degree of commitment and resources.
GDPR can offer numerous opportunities with a well-designed internal data protection framework.