Guide du paysage des outils data pour les développeurs

• Cette vue d’ensemble du paysage data aide les développeurs logiciel qui débutent dans le domaine à ne pas seulement mémoriser les noms des outils, mais à comprendre le rôle de chacun et leurs liens à travers les étapes de collecte / stockage / traitement / exploitation des données
• Les métiers de la data se divisent globalement en profils analyse / science / engineering / machine learning, qui traitent des problèmes et des outils différents, du SQL et de la BI jusqu’aux modèles statistiques et notebooks, à l’infrastructure de pipelines, et au déploiement de modèles en production
• Les systèmes de stockage se répartissent entre les data warehouses, qui offrent rapidité d’analyse et simplicité d’usage, les data lakes, moins coûteux et plus flexibles, et les lakehouses, qui ajoutent le format tabulaire, l’ACID et la gestion de schéma
• Le traitement des données s’étend des transformations SQL avec dbt au traitement local avec pandas et DuckDB, au batch distribué avec Spark, et au stream processing avec Kafka et Flink, tandis qu’un orchestrateur comme Airflow gère l’ordre d’exécution des tâches indépendantes et la reprise après échec
• Les données traitées servent non seulement aux tableaux de bord, mais aussi aux ventes et au support, aux analyses ad hoc, au machine learning, aux fonctions analytiques intégrées au produit et à la vente de données ; à mesure que l’échelle augmente, le catalogue / la couche sémantique / le lignage / la gouvernance deviennent les fondations essentielles pour préserver le sens des données et les responsabilités associées

---

Ce qu’un développeur doit connaître

• Il s’agit d’un guide d’ensemble pour développeurs, rédigé par un ingénieur logiciel arrivé dans une entreprise data sans bagage préalable, afin de comprendre l’usage des outils et leur interaction avec les notebooks
• Ce texte ne traite ni de la création de tableaux de bord, ni des bases de la statistique, ni de l’exploitation d’un cluster Spark, ni des comparaisons approfondies entre produits d’une même catégorie
• Il distingue les étapes du cycle de vie prises en charge par chaque outil en suivant le parcours des données, de leur origine à leur traitement, leur stockage et leur affichage

Les quatre types de métiers de la data

• Dans la pratique, les frontières entre rôles sont floues, surtout dans les petites entreprises ou équipes, mais on peut les diviser en quatre catégories pour comprendre l’ensemble du paysage
• Le profil analyse interprète les données avec SQL et des tableurs, puis visualise les insights
  • Les rôles typiques sont Data analyst et BI analyst, avec des outils comme Tableau et Excel
  • Exemple : consulter les données clients, calculer le taux de churn par région, puis créer un tableau de bord Tableau et proposer une campagne de rétention
• Le profil science traite, via les statistiques, les modèles et les expérimentations, des questions plus profondes ou prédictives que le simple reporting
  • Le rôle typique est Data scientist, qui utilise surtout Python, pandas, scikit-learn et des notebooks
  • Il peut explorer les facteurs de churn, construire un modèle de probabilité de départ client, puis concevoir et analyser un test A/B pour une campagne de rétention
• Le profil engineering collecte, nettoie et standardise les données source, les charge dans un warehouse ou un lake, et exploite les outils data et les bases de données
  • Le rôle typique est Data engineer, avec Python, Apache Spark, les bases de données, les warehouses et le cloud
  • Il peut étendre un résultat d’analyse en pipeline de reverse ETL réexécutable, ou intégrer des données de transaction issues de plusieurs sources tout en gérant schémas, requêtes et contrôles qualité
• Le profil machine learning construit et opère des modèles d’IA, des modèles de classification jusqu’aux LLM
  • Cette catégorie regroupe ML scientist et ML engineer ; comme son écosystème d’outils est vaste, le texte ne l’aborde pas en détail
  • Il assemble les données d’entraînement d’un modèle de recommandation, entraîne et ajuste le modèle, le déploie via API, puis surveille les prédictions et le réentraîne en fonction des changements de comportement

ETL et ELT

• ETL (Extract-Transform-Load) désigne le flux général qui consiste à extraire les données source, les nettoyer ou les combiner à d’autres données, puis charger le résultat dans une destination
• L’ordre des étapes n’est pas figé ; elles peuvent se répéter ou se chevaucher
• ELT consiste à charger d’abord les données source dans le warehouse, puis à les transformer à l’intérieur et à stocker le résultat dans des tables séparées
  • Cela peut augmenter les coûts à cause du stockage et du calcul supplémentaires
  • Comme les données brutes sont conservées, on peut les retraiter plus tard d’une autre manière

Formats de fichier et en mémoire

• CSV est facile à transmettre pour de petits volumes de données et peut être ouvert par la plupart des logiciels bureautiques, ce qui le rend adapté aux utilisateurs non techniques
• Apache Parquet est un format de fichier orienté colonne qui offre un fort taux de compression et permet de stocker et transférer efficacement de gros volumes de données
  • Pris en charge par la plupart des outils data, il sert de format commun entre outils
  • Apache ORC résout des problèmes similaires
• Apache Avro est un format binaire orienté ligne utilisé pour le transport d’enregistrements, notamment en stream processing
• Apache Arrow est le standard de fait des formats en mémoire, optimisé pour le traitement et les transferts zero-copy
  • Parquet vise les petits fichiers et le scan des éléments nécessaires, tandis qu’Arrow se concentre sur le calcul effectif en exploitant les instructions CPU/GPU et le cache
  • Arrow consomme davantage de mémoire, mais permet un transfert efficace des données entre des outils comme pandas et DataFusion en Rust
  • Il peut être utilisé comme backend optionnel de pandas, et Polars comme DataFusion ont été conçus dès l’origine sur Arrow

Data warehouse

• Un data warehouse ressemble à des bases de données comme PostgreSQL ou MySQL, mais il est optimisé pour les charges analytiques
• Une base OLTP comme MySQL convient pour retrouver une seule ligne utilisateur par ID, tandis qu’un warehouse OLAP est adapté aux agrégations par colonne, comme le total des ventes annuelles par région
• Historiquement, il servait de dépôt final pour des données structurées et nettoyées, mais avec l’ELT il peut aussi devenir le premier point de chargement des données brutes
• Comme le format de stockage et le moteur de requête sont étroitement couplés, il offre des requêtes BI et reporting rapides, mais c’est aussi le type de stockage le plus coûteux des trois
• Parmi les produits disponibles : Snowflake, BigQuery, Redshift
• Côté open source et auto-hébergé : ClickHouse, Apache Doris, StarRocks
• Pour un petit projet, une base de données traditionnelle peut suffire

Data lake

• Un data lake ressemble davantage à un vaste dossier cloud où l’on stocke, avec un traitement minimal, des données structurées, semi-structurées et non structurées comme des CSV, Parquet, JSON, e-mails ou images
• On peut le construire en stockant des fichiers sur Amazon S3, Google Cloud Storage, Azure Blob Storage, avec des règles de nommage, de partitionnement et des politiques d’accès
• S’il est mal géré, il peut devenir un marécage de données (data swamp) difficile à retrouver ou à exploiter
• Parmi les options managées : Azure Data Lake et les fonctions data lake de Snowflake
• Pour interroger les données sans les rechercher, télécharger ni parser directement, il faut un catalogue de métadonnées et un moteur de requête
  • Le catalogue enregistre les noms de tables, les schémas et la correspondance avec les fichiers
  • Le moteur de requête utilise ces métadonnées pour lire les fichiers pertinents et exécuter des requêtes en SQL ou dans d’autres langages
• Parmi les catalogues : Hive Metastore, AWS Glue Data Catalog, Unity Catalog
• Parmi les moteurs de requête : Apache Spark, Trino, Amazon Athena

Data lakehouse

• Un data lakehouse ajoute des fonctionnalités proches d’un warehouse sur un lake peu coûteux et flexible
• Le composant clé, le format de table, gère le mode de stockage entre le moteur de requête et les données brutes
  • Avec ACID, il gère les écritures concurrentes, les erreurs pendant l’écriture et la corruption des données
  • Même les données semi-structurées nécessitent un schéma, et les données totalement non structurées ne bénéficient pas des avantages du format de table
  • Il prend en charge l’évolution du schéma et la gestion des versions
  • Il peut accélérer les requêtes grâce aux index et à l’optimisation du partitionnement
  • Certaines implémentations prennent en charge le time travel, qui permet d’interroger un snapshot à un moment donné
• Comme il repose sur un lake, il peut être moins coûteux qu’un warehouse et n’est pas lié à un moteur de requête précis, mais il faut aussi inclure les coûts de calcul séparés, ce qui rend une comparaison tarifaire directe difficile
• Les principaux formats de table sont Apache Iceberg, Delta Lake et Apache Hudi
• Parmi les services managés, on trouve Lakehouse for Apache Iceberg de Google, Databricks et IBM watsonx.data

Sources et ingestion des données

• Les données proviennent de bases de données applicatives comme PostgreSQL ou Mongo, d’API externes comme Stripe, d’événements d’analyse navigateur, d’appareils IoT, etc.
• Elles peuvent être traitées immédiatement après extraction, ou, dans une approche ELT, les données brutes peuvent d’abord être stockées dans un lake, un lakehouse ou un warehouse selon leur forme, leur volume et l’infrastructure
• Les scripts dédiés sont flexibles, mais obligent à réimplémenter du code de connexion répétitif comme l’authentification, la pagination ou la gestion des erreurs
• Les outils d’ingestion de données gèrent ce travail répétitif en configurant des connecteurs entre sources et destinations
  • Comme les données extraites doivent d’abord être chargées quelque part, ils tendent facilement vers des flux ELT
  • Les produits représentatifs sont Fivetran, Airbyte et dlt
• La capture de données modifiées (CDC) détecte les insertions, modifications et suppressions dans les logs de réplication de la base de données sans interroger les tables en boucle
  • Elle est utilisée en interne par les outils d’ingestion pour les sources de type base de données
  • Debezium est largement utilisé comme composant open source autonome

Langages de traitement des données

• Python est le langage de facto du travail sur les données grâce à sa vaste communauté et à son écosystème de bibliothèques natives
  • Même les outils développés dans d’autres langages proposent souvent des bindings Python ; Apache DataFusion, basé sur Rust, en est un exemple
• numpy fournit des tableaux multidimensionnels haute performance et sert de base à de nombreuses bibliothèques
• pandas est le standard de facto, avec des Series 1D et des DataFrame 2D
  • On peut visualiser avec seaborn ou Plotly et créer des applications interactives avec streamlit
  • On peut exécuter des requêtes SQL avec DuckDB ou appliquer des techniques de machine learning de scikit-learn
• R est utilisé dans le monde académique, Java et Scala dans des frameworks big data comme Spark, et Julia ainsi que Rust servent aussi pour le travail sur les données, mais restent moins diffusés que Python
• SQL est largement utilisé pour les requêtes et transformations dans les warehouses, mais sa syntaxe varie légèrement selon l’environnement d’exécution

Traitement batch et temps réel

• Le traitement batch traite régulièrement de gros lots de données, comme l’agrégation des ventes du mois dernier, et convient aux tâches dont les résultats peuvent attendre plusieurs heures ou plusieurs jours
• Le traitement en temps réel fonctionne en flux, avec traitement dès l’arrivée, ou via des micro-batches, par exemple toutes les 20 secondes
• Les pipelines où la rapidité du résultat est essentielle, comme la détection de bots, utilisent le traitement en temps réel pour identifier et bloquer les utilisateurs le plus vite possible

Transformations basées sur SQL

• dbt et SQLMesh définissent les transformations avec des instructions SQL select et les compilent pour qu’elles s’exécutent sur le moteur de requête réel
• Ces deux outils ne traitent pas eux-mêmes les données et assurent l’orchestration des transformations
• Par rapport à des scripts Python personnalisés, ils standardisent la manière de transformer les données et permettent de découper les tâches complexes en petits modèles avec dépendances
• Le ref de dbt référence un modèle au lieu d’un nom de table codé en dur et l’exécute dans le bon ordre selon le graphe de dépendances
• Les résultats sont généralement stockés dans le même warehouse, lakehouse ou lake que les données sources, mais peuvent aussi être envoyés vers d’autres destinations selon la configuration du moteur de requête

DataFrame locaux et DuckDB

• Un DataFrame est une abstraction de tableau 2D pour manipuler des données tabulaires, et en Python, pandas est l’implémentation la plus utilisée
• Parmi les autres implémentations, on trouve Polars pour Python et Rust, DataFusion pour Rust, DataFrames.jl pour Julia, data.frame pour R et tablesaw pour Java
• pandas, data.frame et tablesaw suivent un mode eager, où les opérations s’exécutent immédiatement
• Le LazyFrame de DataFusion et de Polars empile les opérations dans un plan logique puis les exécute lors de .collect()
  • Le plan peut être optimisé avant exécution, ce qui peut le rendre plus rapide
• Les bibliothèques locales sont limitées par la mémoire et le CPU
  • pandas traite toutes les données en mémoire et reste donc limité par la taille de la RAM
  • Le streaming de Polars peut gérer des données plus volumineuses que la RAM, mais certaines opérations doivent tout de même charger le jeu de travail en mémoire
• DuckDB est une base de données OLAP in-process souvent décrite comme un « SQLite pour l’analytique »
  • Il permet d’interroger en SQL des CSV, des fichiers Parquet et des DataFrame pandas en local sans infrastructure séparée

Traitement distribué à grande échelle

• Au-delà des limites d’une machine unique, les données sont découpées en plusieurs morceaux pour être traitées en parallèle sur un cluster, avec une montée en charge horizontale selon la charge de travail
• Apache Hadoop est un outil emblématique des débuts, mais il est aujourd’hui considéré comme legacy et reste surtout visible dans des environnements anciens
• Apache Spark est aujourd’hui le standard de facto pour le chargement, la transformation, la parallélisation et l’optimisation des données
  • PySpark fournit une API DataFrame et une couche compatible avec pandas
  • SparkR a récemment été abandonné, et des bindings Java et Scala sont également proposés
  • Il peut lire et écrire dans de nombreux stockages, ce qui lui permet d’être utilisé à la fois comme moteur de requête sur data lake et pour des tâches de transformation à grande échelle
• Dask étend du code Python vers un cluster en restant proche des API familières de pandas et numpy
• Ray est un framework de calcul distribué généraliste, particulièrement utilisé pour l’entraînement ML
• Apache Flink traite aussi le batch, mais est surtout axé sur le traitement de flux

Event streaming et Kafka

• Le traitement de flux convient aux cas où un résultat immédiat est nécessaire, comme la détection de fraude à la carte bancaire, ou à des tâches comme la validation d’événements de web analytics à leur arrivée, leur enrichissement avec de la géolocalisation IP, puis leur insertion dans ClickHouse
• En traitant les données dès leur arrivée, il n’est pas toujours nécessaire de conserver séparément les payloads bruts jusqu’au prochain batch
• Apache Kafka est une plateforme distribuée et tolérante aux pannes d’event streaming qui reçoit, stocke et met à disposition des événements produits par des producteurs pour que des consommateurs les lisent
  • Contrairement à une file de messages, les événements ne sont pas supprimés quand un consommateur les confirme, et plusieurs consommateurs peuvent les relire tant que les règles de rétention ne sont pas expirées
  • Kafka lui-même ne traite pas les données ; ce traitement est assuré par des workers séparés agissant comme consommateurs
• Kafka Connect relie Kafka à des systèmes externes comme des bases de données
• Kafka Streams est une bibliothèque Java/Scala pour effectuer des transformations avec état, des agrégations par fenêtre et des jointures au-dessus de Kafka
  • Elle s’exécute embarquée dans une application et fonctionne uniquement avec Kafka
• Parmi les autres plateformes d’event streaming, on trouve Apache Pulsar, Redpanda et AWS Kinesis Data Streams

Moteurs de traitement de flux

• Apache Flink reçoit la définition des sources d’événements et de la logique de traitement, puis prend en charge le déploiement sur cluster, la montée en charge et la reprise après incident
• Le pipeline peut inclure du filtrage, du mapping de champs, des agrégations par fenêtre, de la déduplication et une sortie vers d’autres topics Kafka ou des bases de données
• Une fois déployé, le job continue de traiter les nouveaux événements au lieu de se terminer comme un batch
• Parmi les autres options, on trouve Spark Structured Streaming, Google Cloud Dataflow et Azure Stream Analytics

Orchestration des tâches

• Quand les transformations dbt, les jobs Spark et les scripts personnalisés se multiplient, un orchestrateur assemble les étapes individuelles en un pipeline unique
• En définissant chaque tâche et ses dépendances dans du code, le plus souvent en Python, on crée un DAG, ou graphe orienté acyclique
• L’orchestrateur ne traite pas lui-même les données ; il coordonne l’exécution de scripts Spark, le lancement de transformations dbt, des requêtes HTTP, etc.
• On peut utiliser des plannings, des événements Kafka, des exécutions manuelles depuis l’interface, des requêtes HTTP ou des déclencheurs créés par plugin
• Il peut exécuter en parallèle les tâches indépendantes, ne relancer que les étapes en échec, puis reprendre à partir de ce point
• Comme il est conçu pour du traitement batch, avec des exécutions qui ont un début et une fin, il est mal adapté aux pipelines de flux persistants ; dans ce cas, on s’appuie plutôt sur le moteur de traitement lui-même, comme Flink
• Les produits représentatifs sont Apache Airflow, Dagster, Prefect et Luigi
  • Luigi est plus ancien et moins populaire aujourd’hui

Observabilité et supervision de la qualité

• L’observabilité des données se divise entre l’état du pipeline et la qualité des données elles-mêmes
  • La supervision du pipeline vérifie s’il s’exécute, s’il échoue et combien de temps il prend
  • La supervision des données vérifie la fraîcheur, les anomalies de volume et les changements de schéma non annoncés
• Pour les pipelines, on peut utiliser des outils généraux d’observabilité applicative comme Prometheus, Grafana, ELK, ainsi que les fonctions intégrées des orchestrateurs
• Les contrôles de qualité des données peuvent être mis en œuvre avec Great Expectations, où l’on définit explicitement les formats attendus, et avec les dbt tests
• Les produits automatisés apprennent les patterns de données normales puis détectent les anomalies ; Monte Carlo, Bigeye et Metaplane en sont des exemples

Chargements répétés dans les pipelines

• La destination finale du chargement dans un ETL est un warehouse, un data lake ou un lakehouse, mais les données ne sont pas stockées une seule fois en fin de pipeline ; elles sont souvent enregistrées plusieurs fois sous différentes formes
• L’architecture médaillon divise le niveau de préparation des données en trois couches au sein du même stockage
  • Bronze correspond aux données brutes arrivées telles quelles depuis la source
  • Silver correspond à des données nettoyées et standardisées, après correction des types, déduplication, fusion de sources, etc.
  • Gold correspond à des données agrégées et modélisées pour un usage précis, comme un dashboard ou un rapport
• Les analystes interrogent surtout les tables Gold, tandis que les ingénieurs peuvent redescendre jusqu’à Bronze pour déboguer un pipeline

Modélisation dimensionnelle

• Si la structure médaillon représente le niveau de préparation des données, la modélisation dimensionnelle définit la forme des tables dans le warehouse
• Cette approche, popularisée par Ralph Kimball dans The Data Warehouse Toolkit, distingue les tables de faits et les tables de dimensions
• Une table de faits stocke un événement ou une mesure par ligne, comme une commande, un paiement ou une page vue
  • Elle est longue et étroite, contient beaucoup de valeurs numériques et de clés étrangères vers des tables de dimensions, et continue de grossir
• Une table de dimensions stocke le contexte dans lequel l’événement s’est produit, comme le client, le produit ou la date
  • Elle est plus large et évolue relativement lentement
• Quand les tables de dimensions entourent la table de faits centrale, on obtient un schéma en étoile
  • Il existe aussi le schéma en flocon, plus normalisé, sans rapport avec le produit Snowflake
• Le grain définit ce que représente une ligne : une commande, une ligne de commande ou le total quotidien de commandes par client
• Un data mart est une partie du warehouse conçue pour une équipe ou un sujet précis, comme le marketing ou la finance, et se situe généralement dans la couche Gold
• Toutes les équipes ne suivent pas strictement cette approche ; certaines créent aussi une seule grande table largement dénormalisée selon l’usage, en tirant parti des warehouses modernes rapides et du faible coût du stockage

OLAP temps réel pour les applications

• Pour les dashboards internes, les tables Gold du warehouse suffisent, mais lorsqu’il faut servir de nombreux utilisateurs avec une latence de l’ordre de la milliseconde, le temps de requête et le coût par requête peuvent devenir inadaptés
• Les données nécessitant une forte concurrence et des réponses rapides, comme l’analytics orientée utilisateur, la supervision interne en temps réel, les classements, les contenus populaires ou la mesure d’usage, sont déplacées vers une base de données OLAP temps réel
• Apache Druid, Apache Pinot, ClickHouse et Apache Doris en font partie, ClickHouse étant largement utilisé

Reverse ETL

• Le reverse ETL renvoie vers des outils opérationnels comme un CRM les données traitées dans le warehouse
• Si l’on calcule la valeur vie client à partir de données Stripe puis qu’on l’envoie dans HubSpot, l’équipe commerciale peut immédiatement repérer les clients à forte valeur
• Les outils spécialisés relient tables et colonnes aux champs de destination et gèrent les échecs, les retries, la limitation de débit, les alertes et la synchronisation incrémentale
• Parmi les options, on trouve Airbyte Data Activation, Fivetran Activations, Hightouch et RudderStack
  • Fivetran Activations s’appelait Census avant son acquisition

Catalogues de données et couche sémantique

• Les catalogues de données destinés aux humains stockent la source des données, leur propriétaire, les politiques d’accès et les informations de recherche, et donnent un contexte métier aux tables et aux colonnes
  • Leur objectif est différent de celui d’un metastore pour moteur de requêtes
  • Unity Catalog, DataHub et OpenMetadata en sont des exemples représentatifs
• La couche sémantique conserve les définitions standard des entités métier, des relations et des métriques
  • Elle unifie par exemple l’origine d’un modèle client dans les tables et colonnes, les marchés inclus dans l’EMEA, ou encore si les remboursements sont exclus du chiffre d’affaires
  • Lorsqu’un outil de BI ou un agent IA sélectionne les bonnes entités et métriques, elle les convertit en requêtes nécessaires ou fournit les informations requises pour générer ces requêtes
• Le LookML de Looker, Cube, dbt Semantic Layer et les fonctions sémantiques de Unity Catalog en sont des exemples

Data lineage

• La data lineage suit la façon dont les données sont transformées au fil des pipelines
• Elle peut être collectée automatiquement à partir des DAG d’orchestrateurs, de l’analyse du SQL de transformation, ainsi que des événements et métadonnées émis par les jobs de traitement
• Au niveau des tables, elle enregistre par exemple que gold.orders est créé à partir de silver.orders et silver.customers
• Au niveau des colonnes, elle peut aller jusqu’à tracer que customers.life_time_value est calculé à partir de orders.total et subscription_payments.amount
• Elle sert à évaluer l’impact en aval de la suppression d’une colonne, à analyser la cause racine d’une métrique erronée ou à assurer la conformité sur l’usage des informations permettant d’identifier une personne
• Unity Catalog, DataHub et OpenMetadata prennent en charge la visualisation de la lineage, mais l’ensemble du pipeline doit fournir les données de traçage via des connecteurs ou des événements manuels
• Au lieu de formats propres à chaque fournisseur, on peut utiliser le standard OpenLineage, pris en charge par plusieurs catalogues et outils de traitement

Tableaux de bord BI et rapports

• Les tableaux de bord et les rapports sont le débouché le plus courant des pipelines de données, et dans les petites entreprises ils peuvent même constituer pratiquement le seul cas d’usage
• Les outils de BI se connectent aux entrepôts de données, lakehouses et bases de données applicatives pour permettre de créer des graphiques et des tableaux de bord sans écrire de code
• L’essentiel est le self-service, qui permet aux utilisateurs non techniques de créer ou d’explorer des graphiques directement dans l’interface sans devoir solliciter un analyste à chaque fois
• Ils peuvent envoyer des rapports planifiés par e-mail ou sur Slack, ou déclencher des alertes quand une métrique dépasse un seuil
• Tableau et Power BI sont largement utilisés dans les grandes entreprises et mettent l’accent sur des visualisations puissantes et flexibles
• Looker est davantage orienté vers les organisations techniques autour de sa couche sémantique LookML
• Metabase peut être mis en place rapidement, y compris en auto-hébergement, et reste accessible aux utilisateurs non techniques
• Looker Studio est un produit distinct qui n’utilise pas LookML et offre moins de fonctionnalités que Looker, et il a récemment repris le nom de Data Studio

Analyse opérationnelle

• L’analyse opérationnelle fournit des données à l’intérieur des applications utilisées au quotidien par des métiers non analytiques, plutôt que pour des rapports destinés à la direction
• Exemples d’usage :
  • synchroniser des agrégats d’usage vers HubSpot afin que l’équipe commerciale fasse de l’upsell auprès des bons clients
  • synchroniser les commandes récentes, tickets de support et forfaits vers Zendesk afin que l’équipe support dispose du contexte client
  • créer une application interne montrant, pour l’équipe customer success, l’état d’adoption du produit par client
• Le reverse ETL est une méthode de diffusion représentative, mais une application interne Customer 360 qui interroge directement l’entrepôt relève aussi de l’analyse opérationnelle

Analyse ad hoc, analyse exploratoire et notebooks

• L’analyse ad hoc étudie à partir des données existantes des questions ponctuelles, comme les causes d’une baisse des inscriptions ou les cohortes ayant entraîné des remboursements
• L’analyse exploratoire consiste à examiner les données sans question prédéfinie afin d’en tirer des insights
• Comme les opérations suivantes dépendent des résultats et sont plus complexes que de simples filtres ou agrégations, les outils de reporting classiques peuvent ne pas suffire
• On peut utiliser Python avec pandas ou Polars, l’interface SQL d’un entrepôt, Spyder, RStudio, etc.
• Les notebooks combinent dans un même fichier des cellules Markdown, du code, du SQL, et placent des sorties d’images, de graphiques interactifs et de tableaux à côté du code
  • Ils se prêtent bien à une exploration progressive en observant les résultats d’exécution et à la présentation des conclusions
  • Jupyter, Google Colab, Deepnote et marimo en sont des exemples représentatifs
  • Des plateformes comme Databricks et Snowflake proposent aussi leurs propres notebooks

Consommation des données par le machine learning

• Le ML est un domaine à part entière, avec ses feature stores, ses outils d’entraînement, de suivi et de déploiement, mais il constitue aussi un débouché majeur des données
• Au-delà des LLM, il existe des modèles spécialisés pour la prédiction du churn, la recommandation, la prévision de la demande ou la segmentation client, et ils nécessitent des données d’entraînement préparées avant une mise en production
• Les data scientists ou ML engineers récupèrent depuis l’entrepôt des features comme le nombre de commandes sur les 30 derniers jours ou le nombre de jours depuis la dernière connexion pour entraîner et déployer des modèles
• Les résultats de prédiction sont ensuite réutilisés dans l’analyse opérationnelle, comme un score de churn dans le CRM, ou dans des recommandations produit destinées aux utilisateurs

Analyse embarquée

• L’analyse embarquée fournit à l’intérieur d’une application des analyses comme les produits populaires, les régions des clients ou le classement dans les recherches pour des vendeurs sur une marketplace
• S’il ne faut que cinq graphiques prédéfinis et quelques filtres limités, on peut implémenter soi-même les requêtes, l’UI et la bibliothèque de graphiques
• Si les utilisateurs doivent effectuer des requêtes complexes, on peut utiliser des outils de BI comme Metabase, Looker ou Tableau, ou des produits centrés sur l’embarqué comme Sisense et Luzmo
• L’application hôte gère l’authentification et l’autorisation, tandis que l’outil embarqué prend en charge l’UI de requête et le rendu des graphiques

Vendre les données elles-mêmes comme produit

• Les données peuvent devenir le produit lui-même, au-delà de leur rôle de matière première pour des fonctionnalités
• On peut par exemple collecter, transformer et indexer les données de plusieurs blockchains de cryptomonnaies pour vendre un accès à des analystes, ou collecter des résultats de recherche Google pour les vendre à des experts SEO
• Vendre des données et un accès en requête exige des pipelines robustes pour une collecte en temps voulu, ainsi que de hautes performances de requêtage

Gouvernance des données

• La gouvernance des données gère qui peut accéder à des données sensibles comme les informations permettant d’identifier une personne ou les données de santé, ainsi que les journaux d’accès
• Elle couvre aussi la propriété des données, le traitement de la vie privée comme le droit à l’oubli, la localisation physique du stockage et la durée de conservation
• Elle peut s’appuyer sur des techniques comme les rôles et contrôles d’accès de l’entrepôt, les informations de propriété dans le catalogue ou le suivi de l’usage des PII via la lineage
• Ce n’est pas seulement une question technique : la part des personnes et des processus y est importante, et le sujet est étroitement lié aux équipes juridiques, conformité et sécurité
• L’ensemble du paysage data peut être vu comme un flux allant de la collecte à la source jusqu’au stockage, au traitement puis à l’exploitation, et chaque catégorie continue de voir apparaître davantage d’outils et de choix détaillés