Author: Stephane

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

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é ?
Business Intelligence, Company, Data Governance, Data Marketing, Data Mining and Data Integration, Data Quality Management, Data Regulations, Data visualisation, Data Warehouse, L'entreprise, Machine Learning, Self-service Analytics, Technology

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

  1. 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é.

  2. Streaming plus facile des données en temps réel : Cela permet des insights plus opportuns et une prise de décision plus rapide.

  3. 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.

  4. 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

  1. Les entrepôts de données peuvent être complexes et coûteux à mettre en place et à maintenir.

  2. 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 :

  1. Lorsqu’il est nécessaire d’avoir des données structurées, historiques pour le reporting et l’analyse.

  2. Lorsque les données de différentes sources doivent être intégrées et cohérentes.

LACS DE DONNEES

Les avancées

  1. 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é.

  2. 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.

  3. 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

  1. 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.

  2. L’ingestion et l’intégration des données peuvent être longues et complexes.

Meilleurs scénarios pour l’implémentation :

  1. Lorsqu’il est nécessaire de stocker de grands volumes de données brutes, non structurées.

  2. 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é ?
Artificial Intelligence, Business Intelligence, Clients, Data Governance, Data Marketing, Data visualisation, L'entreprise, Machine Learning, Self-service Analytics, Technology

Maîtriser Vos Données : l’essence et l’impact du catalogue de données décryptés

Dans le monde hyperconnecté d’aujourd’hui, où les données sont considérées comme le nouvel or, savoir les gérer et les exploiter s’avère essentiel pour les entreprises souhaitant prendre des décisions éclairées et rester compétitives. Le concept de « Data catalog », ou catalogue de données, émerge comme une réponse clé à ce défi, offrant une boussole dans l’océan vaste et souvent tumultueux des données.

Cet article vise à éclairer les enjeux et les avantages des data catalog, ces bibliothèques modernes où les metadonnées ne sont pas seulement stockées, mais rendues compréhensibles et accessibles. À travers l’automatisation de la documentation des metadonnées et la mise en place d’une gouvernance des données collaborative, les catalogues de données transforment la manière dont les organisations accèdent, comprennent et utilisent leurs précieuses informations.

En facilitant la découverte et le partage des données fiables, ils permettent aux entreprises de naviguer avec assurance vers une stratégie véritablement pilotée par les données.

Mais encore…

Un Data catalogue est un outil centralisé conçu pour gérer efficacement les données au sein d’une organisation. Selon Gartner, il maintient un inventaire des données actives en facilitant leur découverte, description et organisation.

L’analogie basique serait de dire qu’il s’agit d’un répertoire, une sorte d’annuaire où les lecteurs trouvent les informations dont ils ont besoin sur les livres et où ils se trouvent : titre, auteur, résumé, édition et avis des autres lecteurs.

Le but d’un data catalogue est de rendre la gouvernance des données collaborative, en améliorant l’accessibilité, l’exactitude et la pertinence des données pour l’entreprise. Il soutient la confidentialité des données et la conformité réglementaire grâce à un traçage intelligent du lignage des données et un suivi de la conformité​​.

Voici 5 raisons pour vos équipes data d'utiliser un data catalogue :

Data analysts / Business Analysts

Ils utilisent le data catalogue pour trouver et comprendre les données nécessaires à leurs analyses. Cela leur permet d’avoir accès rapidement aux données pertinentes, d’appréhender leur contexte et de garantir leur qualité et leur fiabilité pour les rapports et les analyses.

 

Data Scientists

Le data catalogue est essentiel pour localiser les datasets nécessaires à leurs modèles de machine learning et d’intelligence artificielle. Il facilite également la compréhension des métadonnées (provenance des données et les transformations qu’elles ont subies) ce qui est capital pour le pré-traitement des données.

 

Data Stewards (gestionnaires de données)

Ce sont eux qui sont responsables de la qualité, de la disponibilité et de la gouvernance des données. Ils utilisent le data catalogue pour documenter les métadonnées, gérer les standards de données, et surveiller la conformité et l’utilisation des données au sein de l’organisation.

 

Responsables de la conformité et de la sécurité

Le data catalogue les aide à assurer que les données sont gérées et utilisées conformément aux réglementations en vigueur, comme le RGPD pour la protection des données personnelles. Ils peuvent l’utiliser pour suivre l’accès aux données sensibles et auditer l’utilisation des données.

 

Architectes et ingénieurs de données

Ces techniciens s’appuient sur le data catalogue pour concevoir et maintenir l’infrastructure de données. Il leur fournit une vue d’ensemble des données disponibles, de leur structure et de leur interrelation, facilitant ainsi l’optimisation de l’architecture de données et l’intégration de nouvelles sources de données.

Attention il est important de noter que les utilisateurs métiers ne sont pas moins en reste de cet outil. En effet bien qu’ils ne soient pas des utilisateurs techniques, ils profitent du data catalogue pour accéder aux informations et insights nécessaires à la prise de décision. Le répertoire leur permet de trouver facilement les données pertinentes sans nécessiter de connaissances techniques approfondies.

Ce qu'il faut retenir

Un data catalogue sert à :

 

  • Améliorer la découverte et l’accès aux données

 

  • Renforcer la gouvernance des données

 

  • Améliorer de la qualité et de la fiabilité des données

 

  • Faciliter la collaboration entre les équipes

 

  • Optimiser l’utilisation des ressources de données

 

Grâce aux Data catalogues, tout comme nous le faisons désormais avec notre propre solution révolutionnaire DUKE, naviguez dans le paysage complexe des données dès aujourd’hui, offrez-vous le luxe d’accéder efficacement, de gérer et d’exploiter les données pour soutenir la prise de décision éclairée et l’innovation en entreprise.

Faites brillez vos équipes Data dès aujourd’hui et plongez sans plus attendre au cœur de notre projet DUKE

Artificial Intelligence

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!

Company, L'entreprise, Partenaires

La Prime Régionale pour l’Emploi de FEDER, un soutien essentiel pour notre croissance

Le développement d’une entreprise passe par différentes étapes et nécessite souvent le soutien de partenaires et d’organismes pour assurer sa croissance. Récemment, notre société a bénéficié d’une Prime Régionale pour l’Emploi de la part du Fonds Européen de Développement Régional (FEDER) pour la création de trois postes supplémentaires. Cette aide a été déterminante dans le développement de notre équipe et nous sommes heureux de partager notre expérience avec vous.

L’aide financière accordée par le FEDER a été un véritable catalyseur pour notre entreprise. En effet, grâce à cette prime, nous avons pu embaucher trois nouveaux collaborateurs aux compétences diverses et complémentaires. Ces nouvelles recrues ont permis d’étoffer notre équipe et de renforcer notre expertise dans des domaines clés pour notre activité.

Cet appui financier a également eu un impact positif sur notre environnement local. En créant de nouveaux emplois, nous contribuons au développement économique de notre région et à la réduction du chômage. De plus, la Prime Régionale pour l’Emploi nous a incités à recruter des personnes résidant à proximité de notre entreprise, favorisant ainsi la cohésion sociale et le dynamisme de notre territoire.

En outre, cette prime a également contribué à améliorer la qualité de nos services et produits. Les compétences apportées par nos nouvelles recrues nous ont permis d’innover et d’optimiser nos processus internes. Ainsi, notre entreprise est devenue plus compétitive sur le marché, tout en offrant des opportunités de carrière à des personnes talentueuses.

Enfin, cette expérience nous a démontré l’importance de l’accompagnement et du soutien des organismes tels que le FEDER. Cela nous a également encouragés à nous rapprocher d’autres partenaires et à rechercher d’autres opportunités de financement et de développement pour notre société.

En conclusion, la Prime Régionale pour l’Emploi de FEDER a été un tremplin essentiel pour notre entreprise et notre équipe. Grâce à cet appui, nous avons pu créer de nouveaux emplois, renforcer notre expertise, et contribuer au développement économique local. Nous remercions chaleureusement le FEDER pour son soutien et sommes impatients de poursuivre notre croissance en partenariat avec d’autres acteurs de notre écosystème régional.

Business Intelligence, Company, CRM, Data Governance, Data Marketing, Data Mining and Data Integration, Data visualisation, L'entreprise, Machine Learning, Self-service Analytics, Technology

OFFRE D’EMPLOI-CONSULTANT DATA ENGINEER H/F – CDI

En recherche d’un nouveau challenge ?

Votre mission :

Accompagner nos clients dans leurs projets de transformation numérique et d’analyse de données.

Partenaires majeurs des entreprises de l’océan Indien pour leurs projets autour de la donnée, Datanalysis dans le cadre de son expansion recrute un Data Engineer

Véritable actif stratégique des entreprises, la donnée est aujourd’hui au cœur des enjeux de performance économique et concurrentielle. Nos équipes maîtrisent parfaitement son cycle de vie et les leviers pour que cette donnée devienne une information précieuse. Pour nous aider à aller encore plus loin et pour offrir une expertise additionnelle à nos clients, nous recherchons un profil alliant expertises technologiques et savoir-faire métier pour participer à la réalisation des projets de Data.

Intégré dans une équipe de 17 consultants sénior spécialisés en BI Self-Service, en Data visualisation, Machine Learning et IA, votre poste vous amènera sur les tâches suivantes :

  • Conception et mise en place de pipelines de données pour collecter, stocker et traiter les données chez nos clients
  • Optimisation de la performance et de l’évolutivité des systèmes de stockage de données pour améliorer les processus de nos clients
  • Mise en place de processus pour assurer la qualité des données et ainsi aider nos clients à prendre des décisions informées
  • Collaboration avec les équipes de développement pour intégrer les données dans les applications de nos clients
  • Mise en place de systèmes de surveillance pour assurer la disponibilité et l’intégrité des données pour nos clients

Vous aimez relever de nouveaux challenges. Vous savez faire preuve d’engagement pour réussir et évoluez aisément dans un environnement dynamique.

Vous vous intéressez naturellement à vos clients pour savoir dans quelle mesure vous pouvez les aider à résoudre leurs problèmes.

Vous possédez un bon esprit d’analyse et de synthèse, un excellent relationnel.

 

VOUS PROFITEREZ PLEINEMENT DE CE POSTE SI…

 

  • Vous disposez d’une forte appétence pour les nouvelles technologies
  • Expérience professionnelle dans la conception et la mise en place de pipelines de données pour des clients
  • Connaissance des outils de stockage de données tels que Hadoop, Spark, et NoSQL pour les implémenter chez nos clients
  • Connaissance des outils de gestion de données tels que Airflow, NiFi, ou Talend pour les implémenter chez nos clients
  • Bonne connaissance de SQL et des bases de données relationnelles pour les implémenter chez nos clients
  • Bonne connaissance des méthodes d’analyse de données pour les implémenter chez nos clients
  • Bonne capacité à communiquer en anglais et en français pour travailler efficacement avec nos clients
  • Vous faites également preuve également de capacités de gestion de projet, de recueil de besoins

La curiosité, l’intérêt pour le monde de la donnée, de la data visualisation et de l’IA sont des vrais plus.

Enfin, et surtout, vous êtes chaleureux, souriant et dynamique ! Vous aimez rendre service en apportant du soin à la qualité de votre travail.

 

OÙ TRAVAILLEREZ-VOUS ?

Le poste est basé à Saint Paul de la Réunion. Des déplacements sur toute l’île, et potentiellement sur l’île Maurice et Madagascar sont à prévoir.

 

POURQUOI REJOINDRE DATANALYSIS ?

We are data people and we rock, like you !

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/