# Modeo > Modeo est une agence data à Paris, spécialisée en data engineering et AI engineering (« The Data Engineering Company »). Modeo conçoit, construit et industrialise des Modern Data Platforms, des produits data (BI, analytics embarqué, data apps) et des cas d'usage IA générative (LLM, copilotes, agents) pour des entreprises de toutes tailles. - Expertises : data engineering, AI engineering (LLM, RAG, agents IA), architecture et audit de plateformes data, analytics engineering, DataOps et gouvernance. - Stack : dbt, Snowflake, BigQuery, ClickHouse, Databricks, Airbyte, Cube, Google Cloud, AWS. - Références : Silvr, RATP Cap, Nickel, Interflora. - Contact : contact@modeo.ai, +33 6 32 63 45 50, 50 Avenue Foch, 75116 Paris, France. Prise de rendez-vous : https://modeo.ai/contact - LinkedIn : https://www.linkedin.com/company/modeo-ai - Version intégrale du contenu (articles et cas clients) : https://modeo.ai/llms-full.txt # Cas clients ## Construction d'une Data Platform opérationnelle en environnement multi-filiales URL : https://modeo.ai/cas-clients/construction-dune-data-platform-operationnelle-en-environnement-multi-filiales > De zéro à une Data Platform opérationnelle en 12 mois : comment RATP Cap a industrialisé le pilotage de ses filiales avec une architecture modulaire. ### Contexte : Construction d'une Data Platform opérationnelle en environnement multi-filiales ### Le client RATP Cap est une filiale du groupe RATP en charge de l'exploitation de délégations de service public (DSP) de transport urbain en Île-de-France. L'entreprise opère un portefeuille de filiales (bus, tramways, tram-train) avec des systèmes d'information hétérogènes et des obligations contractuelles de reporting envers Île-de-France Mobilités (IDFM). ### État initial de l'infrastructure RATP Cap ne disposait d'aucune infrastructure data structurée : absence de plateforme centralisée, absence d'équipe data constituée, et dépendance à des processus manuels pour la production d'indicateurs contractuels. #### Points de blocage identifiés : - **Architecture monolithique inadaptée** : L'infrastructure existante reposait sur un système unique et rigide nécessitant des tests de non-régression complets à chaque modification, paralysant toute évolution - **Absence de flexibilité** : L'intégration de nouvelles sources de données imposait une conformité stricte à un framework central, rendant l'onboarding de nouvelles filiales impraticable - **Ressources insuffisantes** : Équipe réduite à trois personnes en définition de besoins et un développeur, structure organisationnelle inadaptée à la croissance - **Risque contractuel** : Production manuelle des indicateurs IDFM chronophage et exposition à des pénalités financières en cas de retard de livraison **Objectif technique** Déployer une Data Platform souveraine pour **industrialiser l'ingestion de sources hétérogènes**, **automatiser la production des indicateurs contractuels** IDFM, et **fournir des dashboards opérationnels** aux filiales, tout en garantissant la scalabilité nécessaire à l'intégration de nouveaux marchés. ### Solution : Architecture modulaire avec frameworks d'ingestion découplés #### Approche : Co-construction et expertise technique Le projet a été structuré autour d'une approche collaborative combinant expertise technique externe et montée en compétences interne. L'architecture a été conçue pour garantir l'indépendance des flux et la pérennité des développements, avec un focus sur la maintenabilité à long terme et le transfert de compétences progressif vers les équipes internes. #### Phase 1 : Fondations infrastructure & Data Engineering (Mois 1-3) Déploiement de l'infrastructure data sur **AWS** avec mise en place des composants core de la plateforme. ##### Data Warehousing & Modélisation - Déploiement de **Snowflake** comme Data Warehouse central - Conception d'une architecture en couches respectant les principes de séparation des responsabilités : - **Raw Layer** : Ingestion brute des données sources sans transformation - **Staging Layer** : Nettoyage, typage et normalisation des données - **Marts Layer** : Modélisation métier et calcul des indicateurs contractuels (ponctualité, régularité, ponctualité voyageur) - Les outils de restitution (BI) consomment exclusivement les Marts, sans logique de calcul côté front-end ##### Orchestration & Monitoring - Déploiement d'**Apache Airflow** sur infrastructure AWS (ECS/Fargate) - Configuration de DAGs pour l'orchestration centralisée des pipelines d'ingestion et de transformation - Mise en place de mécanismes de monitoring, alerting et retry pour garantir la fiabilité des traitements - Intégration d'**Elementary** pour l'observabilité et le suivi de la data quality ##### Data Integration & Architecture des flux - Conception de **frameworks Python modulaires et découplés par source de données** - Chaque framework d'ingestion est indépendant : modification, évolution ou décommissionnement d'un flux sans impact sur les autres - Architecture opposée au système monolithique initial, permettant le développement en parallèle par plusieurs contributeurs - Standardisation des patterns d'ingestion via templates réutilisables (connexion, extraction, gestion des erreurs, logging) ##### Infrastructure as Code & DataOps - Provisionnement de l'infrastructure via **Terraform** pour garantir la reproductibilité et la traçabilité des configurations - Intégration **GitLab CI/CD** pour l'automatisation des déploiements et la gestion des versions - Mise en place de stratégies de branching et de pull requests pour assurer la revue de code #### Phase 2 : Industrialisation & Cas d'usage métier (Mois 4-6) Déploiement des couches de transformation et développement des premiers cas d'usage opérationnels pour les filiales. ##### Transformation & Data Quality - Implémentation de modèles **dbt Core** pour la transformation des données du Raw au Staging, puis aux Marts - Développement de tests de data quality automatisés (unicité, non-nullité, valeurs acceptées, cohérence inter-tables) - Intégration de **dbt** dans les DAGs Airflow pour orchestrer les transformations après les ingestions - Documentation automatique des modèles via dbt docs pour faciliter la compréhension et la maintenance ##### Développement des indicateurs contractuels IDFM - **Ponctualité** : Calcul du pourcentage de courses respectant les horaires théoriques (seuils variables selon les contrats) - **Régularité** : Mesure de l'écart entre les passages successifs théoriques et réels - **Ponctualité voyageur** : Indicateur composite prenant en compte l'affluence et les retards perçus par les usagers - Adaptation des calculs selon les typologies de réseaux (bus urbain, tramway, tram-train) et les spécificités contractuelles de chaque DSP ##### Business Intelligence & Restitution - Développement de dashboards **Qlik** connectés aux Marts Snowflake - Création de vues métier pour chaque filiale avec indicateurs opérationnels et contractuels - Mise à disposition de rapports standardisés pour IDFM (export automatisé selon calendrier contractuel) ##### Mise en production - Plateforme opérationnelle livrée après 6 mois avec les premiers cas d'usage en production - Processus de validation métier avec les filiales pilotes avant généralisation #### Phase 3 : Transfert de compétences & Autonomisation (Mois 7-12) Montée en compétences des équipes internes et passage progressif en mode run autonome. ##### Constitution de l'équipe data interne - Recrutement et onboarding de profils **Analytics Engineer** pour l'exploitation de la plateforme - Formation des nouvelles recrues sur la stack technique (Snowflake, dbt, Airflow, Qlik) - Transfert de compétences sur les frameworks d'ingestion et les patterns de développement ##### Réduction du périmètre Data Ops - Passage progressif de la responsabilité opérationnelle (monitoring, incidents, maintenance) à l'équipe interne - Concentration de l'accompagnement externe sur le développement de nouveaux cas d'usage métier - Documentation complète de l'architecture, des processus de déploiement et des procédures d'incident ##### Montée en autonomie - L'équipe interne assure désormais le développement de nouveaux indicateurs et l'intégration de nouvelles sources - Capacité à onboarder de nouvelles filiales sans intervention externe - Roadmap data pilotée en interne avec priorisation métier ### Stack technique déployée **Cloud Provider :**AWS ‍**Orchestration :**Apache Airflow (ECS/Fargate) ‍**Data Warehouse :**Snowflake ‍**Transformation :**dbt Core ‍**Business Intelligence :**Qlik ‍**Observabilité :**Elementary ‍**Infrastructure as Code :**Terraform ‍**CI/CD :**GitLab ‍**Languages**Python, SQL ### Résultats mesurés #### Performance technique - **Modularité opérationnelle** : Les flux d'ingestion sont découplés. L'évolution d'un projet ne nécessite pas de tests de non-régression sur l'ensemble de la plateforme, réduisant considérablement le time-to-market pour l'intégration de nouvelles sources - **Maintenabilité** : La standardisation via templates Python et dbt facilite l'onboarding de nouveaux développeurs et réduit les délais d'intégration sur les projets existants. Le taux de compréhension d'un flux par un nouveau contributeur est significativement amélioré - **Scalabilité** : L'architecture supporte l'ajout de nouvelles filiales avec des systèmes sources hétérogènes (GMAO, aide à l'exploitation, commandes de service, main courante) sans refonte structurelle. Le coût marginal d'intégration d'une nouvelle filiale est réduit de manière significative - **Fiabilité** : Les mécanismes de monitoring et d'alerting garantissent la détection rapide des anomalies et la reprise automatique en cas d'erreur #### Impact organisationnel - **Automatisation des indicateurs contractuels** : Suppression complète des processus manuels de production des rapports IDFM, élimination du risque de pénalités financières et réduction de la charge de travail des équipes opérationnelles - **Adoption métier** : Taux d'utilisation croissant des dashboards par les filiales (consultation quotidienne par les directeurs d'exploitation), validant la pertinence des cas d'usage développés et la qualité des données restituées - **Reconnaissance direction** : Validation en comité opérationnel transverse des solutions data déployées, avec mention explicite de la qualité des livrables et de la fiabilité de la plateforme - **Sécurisation de la feuille de route** : L'équipe data dispose d'une plateforme stable et documentée permettant la concentration des ressources sur le développement de valeur métier (nouveaux indicateurs, analytics avancées) plutôt que sur la maintenance correctrice - **Autonomie stratégique** : RATP Cap dispose d'une infrastructure data souveraine, ne dépendant plus d'outils ou de prestataires externes pour l'exploitation de ses données opérationnelles critiques ### Conclusion En 12 mois, RATP Cap a déployé une Data Platform opérationnelle de niveau entreprise à partir d'une feuille blanche. L'architecture modulaire par frameworks d'ingestion découplés, la rigueur de la modélisation Snowflake en couches (Raw / Staging / Marts), et la standardisation via dbt permettent l'intégration scalable de nouvelles filiales aux systèmes hétérogènes. La plateforme est dimensionnée pour supporter l'expansion de RATP Cap sur de nouveaux marchés (Tram & Bus, Transilien) sans refonte architecturale majeure. L'équipe interne constituée dispose des compétences techniques, de la documentation et des outils nécessaires pour opérer et faire évoluer la plateforme de manière autonome, positionnant RATP Cap comme un acteur mature sur les sujets data dans le secteur du transport public en Île-de-France. ‍ --- ## Déploiement d'une plateforme d'analytics embarquée en temps réel pour l'IoT URL : https://modeo.ai/cas-clients/deploiement-dune-plateforme-danalytics-embarquee-en-temps-reel-pour-liot > De MongoDB à une plateforme analytics temps réel : une architecture IoT scalable pour embarquer des dashboards performants dans une solution SaaS. ### Le client Le client est un éditeur de solutions SaaS spécialisé dans la digitalisation de la gestion énergétique et technique des actifs immobiliers. Sa plateforme Big Data et IoT permet aux gestionnaires immobiliers d'optimiser les performances système et environnementales de leur patrimoine bâti en temps réel. ### État initial de l'infrastructure Avec plusieurs **centaines de gigaoctets de données de capteurs** collectées quotidiennement, le client disposait d'une base de données **MongoDB** comme unique système de stockage. Cette architecture présentait des limitations structurelles pour répondre aux besoins d'analytics en temps réel et d'expérience utilisateur attendus. #### Points de blocage identifiés : - **Latence incompatible avec l'analyse en temps réel** : MongoDB, optimisé pour les transactions opérationnelles (OLTP), ne permettait pas d'exécuter des requêtes analytiques complexes (OLAP) sur des volumes massifs de données IoT sans dégradation significative des performances - **Absence d'architecture analytique dédiée** : Les données opérationnelles et analytiques partageaient le même système, créant des conflits de ressources et impactant la disponibilité du service - **Expérience utilisateur limitée** : Impossible de fournir aux clients des dashboards interactifs, réactifs et personnalisés permettant un pilotage fin de leurs consommations énergétiques - **Scalabilité compromise** : L'augmentation continue des volumes de données IoT (capteurs supplémentaires, fréquence d'échantillonnage accrue) menaçait la stabilité du système existant - **Segmentation client inexistante** : Absence de mécanisme permettant d'isoler les données par client et de garantir une gouvernance granulaire des accès ### Solution : Architecture lakehouse avec data warehouse colonnaire temps réel #### Approche : Séparation OLTP/OLAP et architecture en couches Le projet a consisté à déployer une architecture data moderne séparant les responsabilités opérationnelles (OLTP) et analytiques (OLAP), en exploitant les caractéristiques des data warehouses colonnaires optimisés pour l'analytique temps réel. #### Phase 1 : Architecture & Infrastructure data (mois 1-2) Déploiement de l'infrastructure data sur **AWS** avec conception d'une architecture lakehouse. ##### Data Ingestion & streaming - Mise en place de **triggers MongoDB** pour capturer les événements d'insertion en temps réel (Change Data Capture) - Développement de pipelines d'ingestion **Python** pour l'extraction des collections MongoDB vers **AWS S3** - Implémentation du **partitionnement des données** sur S3 (par date, par client, par type de capteur) pour optimiser les performances de lecture et maîtriser les coûts de stockage - Utilisation de **AWS Glue Data Catalog** pour la gestion des métadonnées et la définition des schémas ##### Data Warehousing analytique - Déploiement de **ClickHouse** comme data warehouse colonnaire, optimisé pour les requêtes analytiques massives en temps réel - ClickHouse a été sélectionné pour ses performances exceptionnelles sur les requêtes d'agrégation complexes (capable de traiter **des milliards de lignes par seconde**), sa **compression de données** native (réduction de 10x des coûts de stockage vs bases relationnelles), et sa capacité à gérer des **requêtes en streaming** - Modélisation en architecture **trois couches** : - **Raw Layer** : Ingestion brute des données IoT depuis S3 via **AWS Athena**, avec normalisation, déduplication et correction des valeurs aberrantes (outliers). Période de rétention adaptée aux contraintes réglementaires - **Warehouse Layer** : Historisation complète des données avec versioning (Slowly Changing Dimensions Type 2), enrichissement par croisement avec référentiels métier (caractéristiques des bâtiments, contrats, zones géographiques) - **Datamart Layer** : Tables agrégées par client et par cas d'usage métier, optimisées pour les dashboards avec **matérialisation des calculs complexes** (indicateurs de consommation, comparatifs temporels, détection d'anomalies) ##### Orchestration & automatisation - Déploiement d'**Apache Airflow** pour l'orchestration des pipelines d'ingestion et de transformation - Création de DAGs pour l'automatisation end-to-end : extraction MongoDB → S3 → Athena → ClickHouse → Datamarts - Mise en place de mécanismes de **retry automatique**, de **monitoring** des temps d'exécution, et d'**alerting** en cas d'anomalie #### Phase 2 : Transformation & Data Engineering (Mois 2-3) Implémentation des couches de transformation SQL et optimisation des performances. ##### Data modeling & transformation - Développement de **requêtes SQL Athena** pour la transformation des données de la Raw Layer vers le Warehouse - Migration des transformations Athena vers **SparkSQL via AWS Glue** pour améliorer les performances sur les gros volumes (exécution distribuée) - Intégration du connecteur **Apache Hudi** pour gérer les opérations UPSERT et DELETE sur les données dans S3 (format transactionnel pour le data lake) - Optimisation des coûts Athena via : - **Partitionnement optimal** des tables par date et par client - **Compression Parquet** avec encoding adapté aux types de données IoT - **Columnar pruning** pour ne scanner que les colonnes nécessaires aux requêtes - **Conversion des formats** JSON → Parquet pour réduire la volumétrie scannée de 80% ##### Data marts & segmentation client - Création de **datamarts dédiés par client** avec isolation logique des données (Row-Level Security) - Calcul d'indicateurs métier complexes : - **Consommations énergétiques** par période (heure, jour, mois, année) et par type d'énergie (électricité, gaz, eau, chauffage) - **Comparaisons temporelles** (jour J vs J-1, semaine N vs N-1, année N vs N-1) - **Détection d'anomalies** par analyse des écarts à la moyenne mobile et seuils dynamiques - **Indices de performance énergétique** (kWh/m², consommation par occupant, DJU - Degrés Jours Unifiés) - Tables **matérialisées** dans ClickHouse pour garantir des temps de réponse sub-seconde sur les dashboards #### Phase 3 : analytics embarquée & business intelligence (mois 3-4) Déploiement de l'interface de restitution avec analytics embarquée pour les clients finaux. ##### Embedded Analytics avec Cumul.io - Intégration de **Cumul.io** comme plateforme de Business Intelligence embarquée, sélectionnée pour sa capacité à gérer le **multi-tenancy natif** (isolation des données par client via tokens OAuth) - Connexion directe de Cumul.io aux **datamarts ClickHouse** via connecteur SQL - Développement de dashboards interactifs personnalisés par client : - **Cockpits énergétiques en temps réel** : visualisation des consommations actuelles avec comparaison aux prévisions et aux historiques - **Tableaux de bord d'analyse** : drill-down par bâtiment, par étage, par type d'équipement (CVC, éclairage, prises) - **Rapports d'optimisation** : identification des gisements d'économies, recommandations automatisées - **Alertes visuelles** : détection des anomalies de consommation, dépassements de seuils contractuels ##### Intégration SaaS - Intégration des dashboards Cumul.io dans la plateforme SaaS du client via **iframes sécurisées** avec authentification OAuth 2.0 - Mise en place de **Single Sign-On (SSO)** pour une expérience utilisateur transparente - **Whitelabeling** des dashboards aux couleurs et identité visuelle de chaque client final ### Stack technique déployée **ComposantTechnologieCloud Provider**AWS**Orchestration**Apache Airflow**Object Storage**AWS S3**Data Catalog**AWS Glue Data Catalog**Query Engine**AWS Athena, SparkSQL (AWS Glue ETL)**Data Lake Format**Apache Hudi**Data Warehouse**ClickHouse**Embedded Analytics**Cumul.io**Source Database**MongoDB**Languages**Python, SQL, SparkSQL ### Résultats mesurés #### Performance technique - **Latence des requêtes analytiques** : Réduction de 95%+ des temps de réponse sur les requêtes d'agrégation complexes. Passage de plusieurs minutes (MongoDB) à **moins de 2 secondes** sur ClickHouse pour des agrégations portant sur des milliards de lignes - **Scalabilité garantie** : Architecture dimensionnée pour absorber une croissance **10x des volumes de données** (passage de centaines de Go à plusieurs To) sans refonte structurelle ni dégradation de performance - **Coûts de stockage optimisés** : Réduction de 80% des coûts de stockage grâce au format Parquet compressé et à l'archivage automatique des données historiques sur S3 Glacier - **Isolation parfaite des workloads** : Séparation OLTP (MongoDB pour les opérations) / OLAP (ClickHouse pour l'analytique) garantissant la disponibilité du système opérationnel #### Impact métier & expérience utilisateur - **Analytics en temps réel opérationnelle** : Les clients finaux accèdent désormais à leurs indicateurs de consommation avec une **latence inférieure à 5 minutes** après collecte des données capteurs, permettant une prise de décision réactive - **Cockpits personnalisés par client** : Chaque gestionnaire immobilier dispose d'un dashboard dédié et sécurisé, adapté à la typologie de son patrimoine (bureaux, logements, bâtiments industriels), facilitant le pilotage opérationnel quotidien - **Amélioration de l'expérience utilisateur** : Les dashboards interactifs Cumul.io, intégrés nativement à la plateforme SaaS, ont supprimé les exports manuels et amélioré significativement la satisfaction client (mesurée par NPS) - **Différenciation commerciale** : La capacité à fournir de l'analytics embarquée performante est devenue un argument de vente différenciant face à la concurrence #### Impact organisationnel - **Autonomie des équipes** : Les équipes produit et data du client peuvent désormais développer de nouveaux cas d'usage analytiques de manière autonome en créant de nouveaux datamarts sans impacter l'existant - **Réduction de la dette technique** : L'architecture en couches (Raw / Warehouse / Marts) facilite la maintenance et l'évolution, avec une séparation claire des responsabilités - **Observabilité** : Le monitoring via Airflow et AWS CloudWatch offre une visibilité complète sur les pipelines, permettant la détection proactive des anomalies ### Conclusion En 4 mois, le client a déployé une plateforme d'analytics embarquée temps réel pour l'IoT, reposant sur une architecture lakehouse moderne (S3 + ClickHouse). La séparation des workloads OLTP/OLAP, l'exploitation d'un data warehouse colonnaire optimisé pour l'analytique temps réel, et l'intégration d'une solution d'embedded analytics multi-tenant ont permis de répondre aux enjeux de performance, de scalabilité et d'expérience utilisateur. La plateforme est dimensionnée pour accompagner la croissance du client (nouveaux clients, nouveaux types de capteurs, nouveaux cas d'usage analytiques) sans refonte architecturale majeure. L'architecture mise en place constitue un avantage concurrentiel décisif, positionnant le client comme un acteur technologique de référence dans le secteur de la gestion énergétique des bâtiments. ‍ --- ## Refonte d’architecture Data pour réduire le Time-to-Decision de 93% (48h à 3h) URL : https://modeo.ai/cas-clients/silvr-dataplatform > Comment Modeo a refondu l'architecture data de Silvr, fintech ayant levé 130M€, pour passer de 48h à 3h et tenir sa promesse de financement en 24h. ### Contexte : Migration d'une architecture applicative vers une Modern Data Stack ### Le client Silvr est une Fintech française spécialisée dans le Revenue Based Financing (RBF) pour entreprises digitales (e-commerce et SaaS). L'activité repose sur l'analyse en temps réel de données financières et marketing pour l'octroi de financements. ‍ ‍ ### État initial de l'infrastructure L'engagement contractuel de Silvr impose un délai de financement inférieur à 24 heures. Cet objectif nécessite l'ingestion, la consolidation et le scoring de volumes de données hétérogènes dans des contraintes temporelles strictes. #### Points de blocage identifiés : - **Latence incompatible avec le SLA métier** : 48 heures requises pour l'ingestion et la consolidation des données par dossier client, rendant impossible le respect du délai contractuel de 24h - **Architecture inadaptée** : infrastructure conçue selon des patterns applicatifs (Software Engineering) plutôt que data-oriented (Data Engineering), générant des frictions structurelles sur l'accès et le traitement des données - **Absence d'autonomie des équipes métier** : dépendance systématique aux équipes Engineering pour l'extraction de données et la génération de rapports - **Scalabilité limitée** : difficulté à absorber la croissance des volumes de données sans refonte structurelle **Objectif technique** Réduire le délai de consolidation et de scoring d'un dossier client à **moins de 3 heures**, permettre l'autonomie des équipes métier dans l'accès aux données, et déployer une architecture scalable dimensionnée pour la croissance. ### Solution : Refonte architecturale vers une Modern Data Stack #### Approche : Standardisation et industrialisation de la plateforme data Le projet vise le remplacement de scripts ad-hoc par une infrastructure data industrialisée, maintenable et extensible. La migration a été structurée en trois phases de 3 mois. #### Phase 1 : Infrastructure & Data Engineering (Mois 1-3) Déploiement de l'infrastructure data sur **Google Cloud Platform (GCP)**. - **Orchestration** : Déploiement d'**Apache Airflow** pour la gestion centralisée des workflows et le monitoring des pipelines - **Data Warehousing** : Modélisation dans **BigQuery** avec architecture en couches (Raw / Staging / Marts) - **Data Engineering** : Développement de pipelines d'ingestion Python, transformation via **dbt**, intégration CI/CD (GitHub Actions → BigQuery/dbt/Elementary) - **Connecteurs d'ingestion** : Déploiement de DAGs Airflow pour les sources suivantes : Shopify, WooCommerce, Google Analytics, PrestaShop, Magento, Wix, PayPal, Facebook Ads, Stripe, API bancaires - **Transformation** : Implémentation de modèles **dbt** avec tests de data quality intégrés - **Observabilité** : Déploiement d'**Elementary** pour la surveillance de la qualité des données #### Phase 2 : Self-Service Analytics & Gouvernance (Mois 4-6) Mise en autonomie des équipes métier sur l'exploitation des données. - Développement de dashboards **Looker** connectés au Data Warehouse - Documentation des modèles de données et formation des équipes Operations et Finance sur l'exploitation en self-service #### Phase 3 : Enrichissement métier (Mois 7-9) Implémentation de logiques métier avancées (calculs de KPIs complexes, algorithmes de scoring) sur l'infrastructure stabilisée. #### Stack technique déployée - **Orchestration** : Apache Airflow - **Data Warehouse** : Google BigQuery - **Transformation** : dbt Core - **Data Integration** : Airbyte - **Data Observability** : Elementary - **Business Intelligence** : Looker ### Résultats mesurés #### Performance des pipelines - **Latence end-to-end** : Réduction de 93% du délai d'ingestion et transformation (48h → 3h) - **Respect du SLA** : Le délai de financement (<24h) est désormais garanti par l'architecture data #### Impact organisationnel - **Autonomie métier** : Les équipes Finance, Marketing et Operations accèdent directement aux données via BigQuery et Looker, supprimant la dépendance aux équipes Engineering pour le reporting - **Automatisation** : Les calculs de scoring sont entièrement automatisés, libérant les ressources techniques et analytics pour des initiatives à plus forte valeur ajoutée - **Scalabilité** : L'architecture supporte une croissance significative des volumes de données sans refonte structurelle ### Conclusion La stabilisation des pipelines d'ingestion et de transformation constitue le prérequis technique pour toute initiative data avancée. Avec des données centralisées, fiables et à jour dans un Data Warehouse structuré, Silvr dispose des fondations nécessaires pour déployer des modèles de Machine Learning (scoring prédictif, détection de fraude) et évoluer de l'analytique descriptive vers l'analytique prescriptive. L'accès direct aux données via Looker a supprimé définitivement le goulot d'étranglement des équipes Engineering pour le reporting opérationnel, accélérant la prise de décision et permettant une allocation optimale des ressources techniques. ‍ ‍ --- # Articles et ressources ## Company Brain et Agent Harness : donner une mémoire à vos agents IA URL : https://modeo.ai/articles/company-brain-agent-harness > Un Company Brain donne à vos agents IA une mémoire partagée et sécurisée. Définition, Agent Harness, cas d'usage, architecture et solutions open source. Un **Company Brain** est une mémoire partagée qui rassemble la connaissance d'une entreprise (documents, décisions, données métier, code) et la met à disposition de ses agents IA de façon durable et sécurisée. Il fonctionne avec un **Agent Harness**, la couche logicielle qui encadre le modèle de langage : droits d'accès, choix des outils, budget d'étapes et validation humaine des actions sensibles. Ensemble, ils évitent aux équipes de réexpliquer leur contexte à chaque session et permettent de passer d'assistants isolés à des agents fiables en production. Ce guide présente d'abord le rôle du Company Brain, puis le fonctionnement de l'Agent Harness. Il détaille ensuite des cas d'usage, dont un projet mené pour un client du retail, puis compare le Company Brain aux assistants IA clés en main. Il décrit enfin les briques d'architecture, les solutions open source disponibles et la démarche que nous recommandons chez Modeo. ### Qu'est-ce qu'un Company Brain ? Un Company Brain est une base de connaissance unifiée, alimentée en continu, que tous les agents IA d'une entreprise consultent pour travailler avec le même contexte. Il relie les informations selon les entités métier réelles (produits, clients, projets, fonctions de code) au lieu de stocker des fichiers isolés. #### Pourquoi les assistants IA oublient tout d'une session à l'autre Sans mémoire partagée, un assistant IA réinitialise son contexte à chaque nouvelle session. Les informations utiles restent dispersées dans le CRM, les repositories de code, les bases SQL et les tickets d'incident. Les collaborateurs copient-collent donc les mêmes consignes et les mêmes documents d'un outil à l'autre. Cette réinjection manuelle ralentit le travail et alourdit les prompts envoyés aux modèles. Or un prompt plus long coûte plus cher en appels API et allonge le temps de réponse. Une couche de mémoire persistante supprime cette répétition et conserve l'historique des décisions de l'entreprise. Elle demande en revanche des routines d'archivage pour ne pas conserver d'informations obsolètes. #### Une mémoire organisée autour des entités métier Un Company Brain remplace la recherche textuelle sur des fichiers isolés par une représentation des liens entre les entités de l'entreprise. Le framework open source [Cognee](https://github.com/topoteretes/cognee) illustre cette approche : il relie les produits, les retours clients et les fonctions de code dans un knowledge graph (graphe de connaissances). Plusieurs agents travaillant pour des services différents consultent ensuite la même source. Cette centralisation apporte trois bénéfices concrets : - une terminologie commune entre les équipes produit et ingénierie ; - moins de réunions de synchronisation entre services ; - un accès permanent à l'historique des choix d'architecture pour les nouveaux arrivants. Un knowledge graph doit toutefois être mis à jour automatiquement pour suivre l'évolution quotidienne du code et des documents. #### Mémoire réactive et mémoire proactive La mémoire réactive retient uniquement les faits transmis pendant une conversation. C'est le fonctionnement des assistants classiques. La mémoire proactive, au contraire, va chercher elle-même les nouveautés dans les applications de l'entreprise, sans attendre de consigne. [OpenWiki Brains](https://www.langchain.com/blog/introducing-openwiki-brains-general-purpose-wiki-memory-for-agents), publié par LangChain en juillet 2026, applique ce principe. Ses connecteurs interrogent Gmail, Notion, les repositories Git, X, Hacker News ou la recherche web. Une tâche planifiée met ensuite à jour un wiki de fichiers Markdown stocké en local. Les collaborateurs disposent ainsi d'un contexte à jour dès le début de leur journée. Les quotas d'appels API imposés par les éditeurs limitent cependant la fréquence de ces extractions. #### Des droits d'accès gérés au même endroit Le Company Brain centralise le contrôle d'accès pour protéger les informations confidentielles sans alourdir le code des agents. Écrire les règles de confidentialité dans chaque prompt crée des failles et complique la gestion des droits. Le Company Brain attribue plutôt un scope (périmètre d'accès) à chaque conteneur de mémoire. Le Company Brain open source de Supermemory utilise par exemple le tag sm_org_shared pour la mémoire des canaux publics et slack_channel_{id} pour les canaux privés. Avant chaque recherche, le runtime vérifie l'identité de l'utilisateur et ne consulte que les conteneurs autorisés. Un employé qui lance une recherche technique ne tombe donc jamais sur un compte rendu confidentiel des ressources humaines. Le raccordement à un annuaire d'entreprise complexe demande néanmoins une configuration de sécurité spécifique. ### Comment fonctionne un Agent Harness ? Un Agent Harness est la couche logicielle qui entoure le modèle de langage pour contrôler ce qu'il voit, ce qu'il peut faire et quand il doit s'arrêter. Un modèle seul ne sait ni vérifier les droits d'un utilisateur ni appliquer les règles de sécurité d'une entreprise : le harness s'en charge à sa place. #### Le runtime : état, outils et règles de sécurité Le runtime (environnement d'exécution) conserve l'état de chaque session et décide des outils auxquels le modèle a accès. Dans le Company Brain de Supermemory, ce rôle revient au composant CompanyBrainAgent, un Durable Object Cloudflare créé pour chaque organisation et déployé sur Cloudflare Workers. Il enregistre l'état dans une base SQL locale, route les messages vers le modèle et valide les règles de confidentialité avant chaque appel externe. Il permet aussi de reprendre une tâche interrompue par une panne de serveur. Supermemory a arrêté son offre commerciale Company Brain en septembre 2026, puis a [publié le code et l'architecture de son harness en open source](https://supermemory.ai/blog/open-sourcing-company-brain/). Le projet reste une référence d'architecture, mais il n'est plus maintenu comme un produit. #### Le triage : répondre, enquêter, réagir ou se taire Le triage évalue chaque message reçu pour décider si l'agent doit intervenir. Un modèle de classification léger note l'événement de 0 à 100 selon plusieurs critères, dont l'utilité, l'urgence et le coût d'une interruption. Un évaluateur déterministe choisit ensuite l'une des quatre actions suivantes : - **ANSWER** lance un cycle de raisonnement complet pour répondre ; - **INVESTIGATE** rassemble des informations sans publier de message ; - **ACK** se contente d'une réaction emoji sur Slack ; - **PASS** garde le silence quand la discussion ne demande aucune aide. Cette participation sélective préserve la tranquillité des canaux de l'équipe. Un prompt de triage mal calibré risque cependant d'ignorer une demande légitime. #### Gérer les messages qui arrivent pendant une tâche Dans un chat d'équipe, les collaborateurs continuent d'écrire pendant que l'agent travaille. Un intercepteur évalue alors chaque nouveau message du fil en cours et choisit entre quatre décisions : - **IGNORE** quand le message s'adresse à un collègue ; - **APPEND** pour ajouter l'information au raisonnement en cours ; - **REPLACE** pour abandonner la tâche et répondre à la nouvelle demande ; - **STOP** pour arrêter l'opération à la demande de l'utilisateur. Ce contrôle évite de consommer des tokens sur une demande devenue obsolète. Annuler une tâche peut toutefois laisser des opérations à moitié faites dans un outil tiers qui ne gère pas le retour arrière (rollback). #### Le step budget : limiter les boucles d'appels Le step budget fixe le nombre maximal d'appels d'outils autorisés pour une même demande, par exemple 10. Trois étapes avant la limite, le harness prévient le modèle. À la dernière étape, il retire la liste des outils du prompt. Le modèle doit alors rédiger une réponse avec les informations déjà collectées. Ce mécanisme empêche un agent de chercher indéfiniment sans jamais répondre. En contrepartie, la synthèse forcée peut rester partielle si un document clé n'a pas encore été trouvé. ### Cas d'usage d'un Company Brain en entreprise Un Company Brain sert d'abord à répondre aux questions métier qui demandent de croiser plusieurs outils, à aligner les équipes et à assister les collaborateurs là où ils travaillent déjà. #### Retour d'expérience : interroger ses données en langage naturel dans le retail Chez l'un de nos clients, un retailer, les données de l'ERP, de la finance, de la production et du service client sont centralisées dans un data warehouse Snowflake. Les équipes métier n'avaient pourtant aucune interface pour interroger ces sources de manière croisée : les assistants intégrés à chaque logiciel, comme celui de Zendesk, restent limités à leur propre périmètre. Une interface conversationnelle connectée au Company Brain répond désormais à des questions comme : - Quels composants arriveront au cours de la semaine ? - Quels produits risquent une rupture de stock et à quelle échéance ? - Quel chiffre d'affaires génère une catégorie de produits donnée ? L'agent s'appuie sur l'image quotidienne des données centralisées dans Snowflake, sans traitement en temps réel. Les équipes n'ont plus à écrire de requêtes complexes. Ce premier périmètre a aussi servi à cadrer le premier cas d'usage métier avant d'étendre l'agent à d'autres sources. #### Aligner produit et ingénierie Le Company Brain répercute les décisions produit jusque dans le code. Lorsqu'un responsable produit renomme une fonctionnalité sur le site, un agent enregistre la décision. Le knowledge graph la relie à la documentation, aux retours clients et aux fonctions de code concernées. Un agent qui travaille dans un autre repository détecte alors le changement de terminologie. Plutôt que de modifier le code public, il ouvre une pull request qui ajoute un alias et met à jour la documentation. Un développeur relit et valide cette proposition avant la fusion. #### Un assistant dans les canaux de discussion Intégré à Slack, l'agent écoute les canaux publics, note les décisions importantes et répond quand un collaborateur le sollicite. Les questions techniques n'atterrissent plus systématiquement en message privé chez les ingénieurs seniors. Les nouveaux arrivants prennent aussi leurs outils en main plus vite. Dans une [étude de cas publiée en juin 2026](https://supermemory.ai/blog/chatarmin-memory-only), Supermemory indique que le temps de réponse moyen de l'assistant de Chatarmin est passé de 40 à 12 secondes après le passage à une architecture fondée sur la mémoire. Les collaborateurs doivent cependant apprendre à vérifier les documents sources joints aux réponses. #### Exemple : l'assistant interne de Modeo Chez Modeo, notre assistant interne est connecté à Notion, Google Drive, HubSpot et Pennylane. Il répond aux questions sur l'équipe (qui travaille sur quoi, qui est disponible), nos références projets, nos règles internes et la facturation. ### Company Brain ou assistant IA clé en main : que choisir ? Un assistant clé en main comme ChatGPT Team ou Claude Enterprise suffit pour démarrer. Un Company Brain devient préférable dès que l'entreprise a besoin de connecteurs spécifiques, de droits d'accès fins, d'une mémoire partagée entre plusieurs agents et d'un suivi précis en production. CritèreAssistant IA clé en mainCompany BrainMise en routeImmédiateProjet d'ingénierie de plusieurs semainesCoûtAbonnement par utilisateurInfrastructure et appels API, optimisés par le harnessConnecteursCatalogue de l'éditeurConnecteurs développés selon vos besoinsMémoireLimitée à un utilisateur ou un projetPartagée entre agents, équipes et servicesDroits d'accèsRéglages de l'éditeurRBAC au niveau de chaque conteneur de mémoireObservabilitéLimitéeTraçage complet de chaque décision #### Des coûts maîtrisés par le harness Le coût d'un assistant clé en main suit le nombre d'utilisateurs. Celui d'un Company Brain dépend surtout du volume d'appels au modèle, que l'Agent Harness réduit de trois façons : - le triage écarte les messages qui ne demandent pas de réponse ; - le step budget plafonne le nombre d'appels d'outils par demande ; - la mémoire évite de réinjecter tout le contexte dans chaque prompt. #### Des connecteurs et une mémoire adaptés à l'entreprise Les plateformes fermées proposent des configurations standardisées. Ajouter un connecteur maison ou une règle métier complexe y devient vite impossible. Avec un Company Brain, l'entreprise garde le code source et fait évoluer ses connecteurs. Les décisions prises par une équipe restent accessibles aux agents des autres services, mois après mois. #### Un suivi en production Un Company Brain s'intègre aux outils d'observabilité comme [LangSmith](https://docs.langchain.com/langsmith/observability) pour tracer chaque décision de l'agent. L'entreprise repère ainsi les questions récurrentes, identifie les informations manquantes dans sa base de connaissance et transforme les retours des utilisateurs en jeux de données d'évaluation. La vue ci-dessous rejoue, action par action, l'enquête d'un agent de démonstration Modeo construit avec LangChain et LangGraph. Un calcul dbt échoue : l'agent consulte le projet, lit le code et interroge les données, propose une correction, puis la teste avec dbt dans une copie de travail locale. Il reste dans les limites fixées par ses consignes. Chaque action est enregistrée : on comprend ainsi pourquoi il a pris chaque décision. #### Des droits d'accès fins Un assistant connecté à un dossier partagé risque d'exposer des documents confidentiels à des employés non autorisés. Le Company Brain applique un contrôle d'accès basé sur les rôles (RBAC) au niveau du stockage : chaque agent n'accède qu'au périmètre nécessaire à sa mission. Cette configuration suppose un inventaire rigoureux des permissions, un chantier proche de celui de la [gouvernance des données](../../enjeux/dataops-gouvernance.html). ### Les briques d'architecture d'un Company Brain Un Company Brain repose sur quatre briques : une mémoire séparée de l'état opérationnel, des conteneurs d'accès, un registre des questions ouvertes et un circuit de validation humaine. #### Mémoire sémantique et état opérationnel La mémoire sémantique conserve ce qui dure : choix stratégiques, documentation produit, organigramme. L'état opérationnel regroupe ce qui change vite, comme le statut d'un ticket ou le dernier déploiement. Le Company Brain de Supermemory associe la recherche vectorielle pour la première et des appels API directs pour la seconde. Un agent consulte ainsi la mémoire pour comprendre les objectifs d'un projet, puis interroge GitHub en direct pour vérifier l'état du code. La base de connaissance reste légère et les statuts restent exacts. En contrepartie, une panne d'API externe bloque temporairement la vérification en direct. #### Des conteneurs de mémoire par scope Chaque information reçoit un tag d'accès au moment de son intégration : - sm_org_shared la rend accessible à toute l'entreprise ; - slack_channel_{id} la réserve aux membres d'un canal privé ; - user_{userId} la limite à un seul utilisateur. Le runtime filtre la recherche selon l'identité de la personne qui interroge l'agent. Un rapport financier confidentiel n'apparaît donc pas dans la recherche générale d'un employé. Un tag erroné à l'intégration peut en revanche masquer un document à des collaborateurs qui y ont droit. #### Un registre des questions ouvertes Un registre des questions ouvertes empêche l'agent d'inventer une réponse quand une information manque. Lorsque l'ingestion rencontre un sigle inconnu ou un terme ambigu, elle ajoute une entrée dans un fichier dédié, par exemple open_questions.md. Aux passages suivants, l'agent cherche la réponse dans les nouveaux documents. Les équipes peuvent aussi compléter le fichier directement. Ce registre doit être suivi, faute de quoi les questions non résolues s'accumulent. #### La validation humaine des actions sensibles Le human-in-the-loop soumet les actions à fort impact, comme l'envoi d'un email, à l'accord d'un humain. Le harness met l'exécution en pause, sauvegarde l'état du raisonnement et affiche une carte Approve / Deny dans Slack. Après validation, l'agent reprend exactement là où il s'était arrêté. LangSmith permet aussi de construire des interfaces de relecture sur mesure pour inspecter ces actions. Le délai d'attente ralentit les traitements, mais garantit leur conformité avec la politique de risques de l'entreprise. Ces briques reposent sur une data platform solide. Comme nous l'expliquions au salon Big Data & AI 2026 en revenant sur [le projet mené avec RATP Cap Île-de-France](../../cas-clients/construction-dune-data-platform-operationnelle-en-environnement-multi-filiales/index.html), la plateforme doit encapsuler des process clairs : automatisation, DataOps, gouvernance, observabilité et CI/CD. Sans ces fondations, un agent ne sait ni déployer un job dbt, ni créer un test sur une nouvelle intégration de données, ni octroyer des droits. ### Quelles solutions open source pour construire un Company Brain ? Aucune solution ne couvre seule tout le périmètre : un Company Brain s'assemble à partir de briques open source spécialisées, chacune avec ses limites. SolutionRôleLimite principaleOpenWiki Brains (LangChain)Mémoire proactive sous forme de wiki Markdown, alimentée par des connecteursInstallation locale : la machine hôte doit rester alluméeCogneeStructuration de la connaissance en knowledge graphConstruction initiale coûteuse en tokensSupermemory Company BrainHarness multi-utilisateurs pour Slack sur Cloudflare WorkersProduit arrêté, code publié en open sourceLangGraphOrchestration d'agents avec gestion des étatsHarness à construire soi-mêmeLangSmithObservabilité et évaluation des agentsService cloud de LangChain #### OpenWiki Brains OpenWiki Brains génère une mémoire générale sous forme de fichiers Markdown lisibles. L'outil s'installe via npm et s'initialise avec la commande openwiki personal --init. Une tâche planifiée rafraîchit ensuite le wiki. Le code est disponible sur le [repository OpenWiki de LangChain](https://github.com/langchain-ai/openwiki). #### Cognee Cognee extrait des documents les entités clés (produits, fonctions de code, retours clients) et navigue dans les liens qui les relient, au-delà de la simple proximité de mots. Plusieurs agents travaillant dans des repositories différents partagent ainsi le même contexte métier. La construction initiale du graphe consomme cependant beaucoup de tokens. #### Supermemory et Cloudflare Le Company Brain de Supermemory s'appuie sur Cloudflare Workers et des Durable Objects, qui conservent l'état des sessions et assurent la reprise après une panne. Le code publié reste une base utile pour concevoir son propre harness. Un déploiement serverless impose toutefois de respecter les limites de durée d'exécution de Cloudflare Workers. #### Une ingestion source par source Nous recommandons d'ingérer les sources l'une après l'autre plutôt que simultanément. Analyser en même temps des emails, des pages Notion et des commits risque de saturer la fenêtre de contexte du modèle. Le pipeline traite donc un connecteur, met à jour la mémoire, réinitialise la session puis passe au connecteur suivant. L'extraction gagne en précision, au prix d'une mise à jour complète plus longue. ### Comment déployer un Company Brain : la démarche Modeo Un Company Brain se déploie par étapes, en partant d'un périmètre restreint avant d'ouvrir l'agent à toute l'entreprise. Nous suivons quatre étapes : - **Auditer les sources de données** et choisir les applications prioritaires : Notion, GitHub, Snowflake ou le CRM. - **Déployer le runtime** avec Cloudflare Agents SDK ou LangGraph pour gérer le triage et le step budget. - **Configurer l'ingestion en arrière-plan** avec un registre des questions ouvertes pour contrôler la qualité. - **Ajouter la validation humaine** sur les outils qui modifient des données externes, avant toute automatisation complète. Commencer par un périmètre ciblé, comme les données Snowflake de notre client retail, permet de valider le fonctionnement avant d'étendre l'agent aux canaux de communication. Notre équipe d'[AI engineering](../../enjeux/ia-genai.html) conçoit ces architectures avec LangChain, LangGraph, OpenWiki Brains et Cloudflare Agents SDK : audit de sécurité des données, développement du runtime, isolation des scopes d'accès et pipelines d'évaluation sur LangSmith. Pour évaluer la préparation de vos données et définir votre premier cas d'usage, [réservez un échange de 30 minutes avec un ingénieur Modeo](../../contact.html). Il débouche, si besoin, sur un atelier de cadrage technique de deux heures. ### Questions fréquentes sur le Company Brain #### Quelle différence entre un Company Brain et un RAG ? Un RAG (Retrieval-Augmented Generation) retrouve des extraits de documents proches d'une question et les fournit au modèle. Un Company Brain l'utilise souvent comme composant, mais y ajoute une mémoire persistante partagée entre agents, des liens entre entités métier, une ingestion proactive et des droits d'accès. Notre article sur [la mise en place d'un agent conversationnel RAG sur AWS](../../articles/comment-mettre-en-place-un-agent-conversationnel-sur-aws/index.html) détaille la première approche. #### Faut-il une data platform pour construire un Company Brain ? Pas pour démarrer sur des documents comme Notion ou Google Drive. Pour répondre à des questions chiffrées (stocks, chiffre d'affaires, délais), l'agent a besoin de données fiables et centralisées, par exemple dans Snowflake ou BigQuery. C'est pourquoi notre projet dans le retail s'appuie sur un data warehouse existant. #### Quelles sources connecter en premier ? Les sources sur lesquelles les équipes perdent le plus de temps à chercher l'information : documentation interne, CRM, data warehouse et outil de ticketing. Mieux vaut connecter deux ou trois sources bien gouvernées que dix sources sans règles d'accès. #### Comment éviter qu'un agent invente des réponses ? En combinant plusieurs garde-fous : citer les documents sources dans chaque réponse, tenir un registre des questions ouvertes, limiter le step budget et soumettre les actions sensibles à une validation humaine. Le suivi dans un outil d'observabilité comme LangSmith permet ensuite de repérer et de corriger les mauvaises réponses. ### Glossaire - **Agent Harness** : couche logicielle qui entoure le modèle de langage pour gérer la sécurité, les outils, l'état des sessions et les règles d'accès. - **Company Brain** : mémoire partagée et centralisée qui fournit un contexte persistant aux agents IA d'une organisation. - **Durable Objects** : composants serverless de Cloudflare qui conservent l'état d'une session de manière persistante. - **Human-in-the-loop** : mécanisme qui suspend un agent pour soumettre une action critique à l'approbation d'un humain. - **Knowledge graph** : organisation des données qui relie les concepts métier entre eux sous forme de réseau. - **RBAC (Role-Based Access Control)** : contrôle d'accès qui restreint les données selon le rôle de chaque utilisateur. - **Scope** : périmètre de visibilité d'une donnée (toute l'organisation, un canal, un utilisateur). - **Step budget** : nombre maximal d'appels d'outils autorisés pour une demande. - **Triage** : évaluation automatique d'un message pour décider si l'agent répond, enquête, réagit ou se tait. --- ## Guide complet : Semantic Layer (couche sémantique) URL : https://modeo.ai/articles/semantic-layers > Une semantic layer (couche sémantique) est une représentation business des données d’une entreprise, compréhensible par des équipes non-techniques. ### Qu’est-ce qu’une semantic layer ? Une semantic layer est une **couche d’abstraction** présentant des données à des utilisateurs, dans un cadre orienté métier et sous un format facilement compréhensible par des personnes non techniques. Cette couche est généralement la dernière couche d’un datawarehouse, située **au-dessus des données techniques** et **exposée aux utilisateurs finaux**. C’est en quelque sorte une traduction des données techniques produites par les équipes data en des données orientées métier, exploitables par toutes et tous. Ces données sont mises à disposition des utilisateurs finaux via des tables dans une base de données ou une API par exemple. ### Quels sont les avantages d’une couche sémantique ? Cette couche d’abstraction permet d’**uniformiser le traitement, le calcul, le format et la dénomination de données** utilisées de manière différente par plusieurs métiers. Il est encore courant dans les entreprises que les équipes utilisent des termes différents pour désigner une même information (par exemple “abonné”, “actif”, “utilisateur” pour identifier une entité ayant accès au contenu d’un média). En mettant à disposition des équipes consommatrices, via un catalogue par exemple, des metrics cadrées, pré-calculées et standardisées, il est alors possible d’assurer la **cohérence des valeurs** et de **lutter contre l’isolement des informations**. De plus, cette approche **facilite** **grandement la maintenance** puisque si la méthode de calcul change, il suffira alors de mettre à jour la formule à un seul endroit pour que l’intégralité des utilisations soit impactée. Cette couche sert donc de **référentiel** gérant à la fois le data modeling, les méthodes de calcul, les règles métier et les accès à la donnée. L’utilisation d’une semantic layer apporte une **couche supplémentaire de sécurité** au sein des architectures de données en **centralisant l’accès et la gestion des données**. En définissant des règles précises d’accès et de visibilité, elle permet un contrôle rigoureux sur qui peut accéder à quelles données, minimisant ainsi les risques de fuites ou d’expositions non autorisées. ### Les solutions du marché pour construire des semantic layers : Avantages &, Inconvénients Il existe beaucoup de solutions proposant de construire des semantic layers sur le marché. Une partie d’entre elles, historiquement les premières, sont **directement intégrées à des outils de Business Intelligence** (BI) comme[Power BI](https://www.microsoft.com/fr-fr/power-platform/products/power-bi) (DMX) ou[Metabase](https://www.metabase.com/). Cela a l’avantage d’assurer une parfaite compatibilité entre la semantic layer et l’outil de visualisation mais restreint l’entreprise à une seule solution et une finalité uniquement analytiques, excluant de nombreux cas d’usage comme de l’embedded analytics ou de l’IA. Il existe également des **solutions standalone**, comme Cube.js ou AtScale, indépendantes de toute solution de Business intelligence. Dans cette partie, nous présenterons dans les grandes lignes quelques solutions du marché et analyserons leurs avantages et inconvénients. #### DBT Semantic Layer [DBT](https://www.getdbt.com/) est un outil open-source de transformation de données très largement utilisé dans le monde de la data. DBT propose, grâce à[MetricFlow](https://docs.getdbt.com/docs/build/about-metricflow), une semantic layer appelée[dbt Semantic Layer](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl). La solution repose sur la création de modèles SQL pour structurer les données selon des règles métier. Il est possible d’y inclure de la **documentation** et de définir des **tests de validation** automatiques. dbt Semantic Layer s'intègre de manière transparente à[plusieurs applications](https://docs.getdbt.com/docs/use-dbt-semantic-layer/avail-sl-integrations) : Tableau, Google Sheet, Steep... Pour les autres, il est possible d’accéder à la donnée via les langages ou outils JDBC, ADBC et GraphQL APIs. Principal inconvénient de cette solution, elle n’est **disponible que dans l‘offre payante dbt Cloud Team ou Enterprise**. L’avantage est que si vous utilisez dbt pour vos transformations de données, vous pourrez **éviter d’utiliser trop d’outils différents**et **concentrer toute la modélisation, la transformation et la semantic layer**dans un seul emplacement. #### Looker [Looker](https://cloud.google.com/looker?hl=fr), la plateforme de Business Intelligence développée par Google, propose elle aussi une semantic layer. Cette solution s’appuie sur le langage[LookML](https://cloud.google.com/looker/docs/what-is-lookml?hl=fr) permettant de **décrire des dimensions, des agrégats, des calculs et des relations** entre des données stockées dans une base. Ce langage prend en charge toutes les implémentations SQL. Historiquement restreinte à Looker, la semantic layer est maintenant ouverte à des outils externes tels que Google Spreadsheet, Google Slide, PowerBI ou Tableau. Elle propose également une intégration via Rest API et JDBC. Pour la connexion aux sources, l’interaction avec les données est grandement facilitée si le datawarehouse sous-jacent est[BigQuery](https://cloud.google.com/bigquery?hl=fr). Looker a fait de sa semantic layer un véritable axe stratégique et des innovations devraient voir le jour dans le futur. #### Cube.js [Cube.js](https://cube.dev/) est une **solution open-source standalone** permettant de mettre en place une semantic layer pour **construire des applications analytics**. Cette solution peut se connecter à n’importe quelle source de données supportant le SQL et **mettre à disposition** de n’importe quelle application **des modèles de données pré-agrégés** sous forme de endpoints. Cube.js propose une **offre open-source** et une **solution cloud** permettant d’héberger son instance et d’accéder à une interface web pour modéliser, tester et visualiser ses modèles de données. Cube.js est **une solution que nous utilisons beaucoup chez**[Modeo](../../index.html). Dans le prochain article de cette série, nous parlerons plus en détails de cet outil incontournable de la[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html). --- ## Comment l’IA transforme les Data Platforms de demain URL : https://modeo.ai/articles/comment-seront-construites-les-data-platform-de-demain > Découvrez avec Modeo, comment la GenAI redéfinit les Data Platforms : ingestion, stockage, orchestration et impact pour les équipes Data de demain. #1/3 - Premier article de la série GenAI La dernière révolution que nous avons connue dans le monde de la Data de 2019 : c’est l’apparition de la Modern Data Stack. À l’époque, cette nouvelle approche représentait une avancée majeure dans la manière de construire des projets Data, avec de nombreuses promesses : - Une meilleure autonomie des équipes métiers grâce à une adoption facilitée des outils et des données de meilleure qualité - Un Time-To-Insights amélioré - Une qualité de données renforcée grâce aux solutions de gouvernance et d’observabilité - Une architecture plus flexible et évolutive grâce au Cloud Une meilleure maintenabilité des pipelines avec une approche SQL First C’est dans ce contexte que nous avons créé Modeo, avec une mission claire : aider nos clients à réaliser avec succès des projets ambitieux en s’appuyant sur cette nouvelle stack. Pour concrétiser cette vision, nous avons développé une forte expertise en Data Engineering, constitué une équipe de plus de 30 Data Engineers, et accompagné plus d’une centaine de clients, de toutes tailles et dans des secteurs très variés. C’est comme cela que Modeo est devenu la référence française de la Modern Data Stack. Ces projets nous ont permis de comprendre ce qui fonctionne – ou non – au sein d’une équipe Data pour construire des cas d’usage à forte valeur, avec de nombreux acteurs impliqués. Ils nous ont aussi aidés à identifier les principaux enjeux à résoudre, qu’ils soient techniques, organisationnels ou liés aux process. ---- ### Alors comment cette nouvelle révolution "la GenAI" va impacter les équipes Data ? C’est pour cette raison que j’ai décidé de rédiger une série d’articles, en soulevant 3 questions : - Comment seront construites les Data Platform de demain ? - À quel point les équipes Data vont être transformées ? Doit-on imaginer un monde où les équipes Data n’existent plus ? - Comment une équipe Data doit tirer profit de la GenAI ? Quels sont les risques ? Disclaimer : cette vision s’appuie uniquement sur mon opinion personnelle ainsi que sur des échanges menés en interne chez Modeo. Notre compréhension du fonctionnement des équipes Data se limite à un contexte européen. Elle n’a en aucun cas vocation à représenter une vérité absolue, ni à s’appliquer de manière uniforme à toutes les organisations. Chaque contexte Data est unique, et les réflexions partagées ici doivent être adaptées aux réalités propres à chaque entreprise. ### 1. Comment seront construites les Data Platforms de demain ? #### 1.1 - Les innovations clés ##### • Vibe coding &, copilots Qu’est-ce que le vibe coding / un copilote ? Le 'vibe coding' est une nouvelle manière de coder rendue possible par l’arrivée de l’IA dans les outils data. Concrètement, cela désigne une expérience de développement où le Data Engineer est assisté par des copilotes intelligents, qui : • comprennent le contexte, • génèrent du code, • proposent des corrections ou des suggestions, • permettent de travailler plus vite, avec moins de frictions. On ne part plus d’une page blanche. On décrit ce qu’on veut faire, l’outil propose une première version, puis on ajuste. Le tout se déroule dans une interface pensée pour faciliter l’expérimentation, le test et l’itération. Ce n’est pas un changement de métier, c’est un changement de rythme : plus fluide, plus intuitif, plus centré sur la logique métier. Exemples d’IDE permettant de “vibe-coder” : [Nao](https://getnao.io) [Cursor](https://cursor.com) , [Windsurf](https://windsurf.com) ##### • MCP : Model Context Protocol Qu’est-ce qu’un MCP ? Le Model Context Protocol (MCP) est un standard ouvert qui permet aux IA (comme les copilotes) d’accéder facilement aux données d’une entreprise, qu’elles soient dans Google Drive, Slack, GitHub ou une base de données. Plutôt que de créer une intégration spécifique pour chaque outil, MCP propose un protocole unique pour connecter l’IA à toutes les sources utiles. Résultat : plus besoin de multiplier les connecteurs personnalisés. L’IA peut naviguer d’un outil à l’autre en gardant le contexte métier. Comment ça fonctionne ? Dans une application, le principe est simple : • L’IA ne se connecte pas directement à vos outils ou bases de données. • Elle interagit avec un MCP Server, qui expose un point d’entrée unique pour accéder aux données. Un server MCP standardise la méthode de connexion via un protocole universel : • il décrit les données disponibles sous forme de JSON, • expose les actions possibles (lire un fichier, interroger une table, etc.), • permet à l’IA de comprendre ce qu’elle peut faire, dans quelles limites, et avec quel niveau de permission. L’IA lit ce fichier de contexte (un JSON enrichi de schémas et métadonnées), qui joue le rôle de carte d’accès aux différentes API ou ressources métiers. Avec MCP, l’IA peut alors : • lire des documents ou objets métier via une API REST ou GraphQL, • poser des questions contextuelles (“quelles sont les dernières anomalies dans ce tableau de monitoring ?”), • générer des requêtes sur mesure (SQL, API call, transformation) selon la structure exposée. Le tout dans un cadre sécurisé, contrôlé et interopérable avec plusieurs systèmes. 📎 En savoir plus sur le Model Context Protocol : https://modelcontextprotocol.io/overview ##### • AI Agent Qu’est-ce qu’un AI Agent ? Un AI Agent est une IA autonome, reliée aux données et aux outils, capable de : • comprendre un besoin métier, • accéder aux bonnes données, • les transformer, • produire un résultat exploitable, Et ce, sans pipeline figé ni transformation écrite à la main à l’avance. C’est une nouvelle manière de penser l’automatisation dans les équipes Data. Un agent active des “micro-compétences” spécialisées (appelées aussi “agents”) en fonction du besoin : • un agent de parsing va lire un fichier brut (CSV, JSON), • un agent de nettoyage corrige les valeurs manquantes ou les doublons, • un agent de transformation calcule des agrégats ou reformate les données, • un agent d’ enrichissement ajoute des informations externes (ex. : données géographiques), • un agent de mapping fait correspondre deux schémas de données différents. Ces agents peuvent travailler de façon coordonnée, comme une équipe autonome qui construit un pipeline de traitement sans règles codées à l’avance, mais en s’adaptant au contexte. ##### • Self-healing pipelines Qu’est-ce qu’un self-healing pipeline ? Les self-healing pipelines ou pipelines auto-réparateurs sont des workflows de données capables de : • détecter automatiquement une erreur, • en identifier la cause probable, • exécuter une action corrective, Et ce, sans intervention humaine. Ce ne sont pas de simples systèmes d’alerte ou de monitoring. Le pipeline est capable d’agir de lui-même : • redémarrer une étape, • corriger une valeur incohérente, • changer de source temporairement, • désactiver une transformation problématique, … tout en logguant automatiquement ce qu’il a fait. ##### • Multi-Agent Platform Qu’est-ce qu’une Multi-Agent Platform ? Une plateforme multi-agent permet de faire collaborer plusieurs agents d’IA autonomes dans un même environnement, chacun étant responsable d’une partie spécifique d’un processus complexe. Ces agents : • partagent un objectif commun, défini en amont par l’utilisateur ou le système, • se répartissent les tâches selon leurs rôles et compétences, • s’échangent des informations intermédiaires (résultats partiels, fichiers, contexte, données extraites), • peuvent adapter leur comportement en fonction des résultats produits par d’autres agents, • fonctionnent de manière orchestrée, via un moteur central qui assure coordination, suivi et progression vers l’objectif final. C’est une logique de collaboration asynchrone ou séquentielle, mais contextualisée : chaque agent travaille dans un cadre structuré, avec des responsabilités bien définies, et peut prendre des décisions en autonomie dans les limites de son rôle. ### 2 - Ce qui va changer : analyse brique par brique #### 2.1 — Ingestion des données L’IA va repenser la façon dont nous construisons nos pipelines d’ingestion grâce au vibe coding. Ces outils intelligents auto-généreront du code, soumis à la validation du développeur. Pour s’intégrer à une Data Platform, ce code généré devra s’appuyer sur des standards prédéfinis par l’entreprise. Autrement, il s’agira d’une agrégation de bout de codes sans aucune cohérence. Le rôle de l’équipe Data Platform (ou DataOps / Centre d’Excellence) sera crucial pour fixer des standards et s’assurer qu’ils soient respectés. Concernant les MCP, je ne suis pas convaincu qu’ils remplacent les méthodes d’ingestion traditionnelles. Ce n’est pas ici qu’est la valeur du MCP qui fonctionne comme un ETL : - Je me connecte à un système et je récupère des données - Je transforme ces données - Je les restitue au format attendu. Si aujourd’hui les équipes Data privilégient une approche ELT vs ETL, c’est pour entre autres passer par une couche centrale de transformation, type architecture médaillon, pour “figer” la connaissance métier. Ces couches sont la résultante des différentes itérations métier / tech. La modern data stack s’est conçue en isolant chaque brique pour des raisons de simplicité, de flexibilité et d’évolutivité. Revenir en arrière avec une approche 100% ETL serait contre-productif. Il est en revanche certain que les éditeurs de solutions (Salesforce, Hubspot, Google Analytics…) adapteront leurs produits pour maximiser la compatibilité avec des outils IA type MCP et améliorer l'expérience utilisateur. C’est un levier de compétitivité. Cela n’est pourtant pas bien nouveau. En effet, il est déjà possible de le faire via API ou interface graphique. En revanche, cette approche sera plus accessible pour les métiers, et sera donc utilisée pour des analyses ad-hoc. Exemple : “donne-moi le panier moyen sur l’offre X”. Cette approche MCP a également l’avantage de proposer de la donnée fraîche, avec un temps de latence minime. En revanche, elle ne permet pas de figer des analyses ni d’y intégrer des règles de métier complexes (exemple de [la notion de “availability” chez Airbnb](https://blog.dataexpert.io/p/how-i-made-airbnb-millions-with-this)). Les équipes Data devront donc rivaliser avec des analyses Ad-Hoc, en proposant de la donnée de qualité, fraîche, à forte valeur ajoutée avec une très bonne expérience utilisateur. Elles devront également mettre en place le bon cadre pour veiller à ce que ces analyses ad-hoc soient réalisées sous leur supervision pour éviter des problèmes de silos, souvent déjà bien présents. KPIs impactés par l’IA : - Robustesse des pipelines d’ingestion =>, réduction du nombre d’incidents - Temps requis pour intégrer une nouvelle source de données - Harmonisation du code généré #### 2.2 - Transformation Son objectif est de faire passer les données brutes à un état exploitable, en les rendant fiables, compréhensibles et activables pour les équipes métier. C’est ici qu’on construit les KPIs de l’entreprise. Tout comme l’ingestion, le développement de script de transformation de données va être grandement accélérée grâce au vibe-coding : - Exploration et compréhension des données : Avant même la construction des pipelines, l’équipe Data accélèrera considérablement la phase d'exploration des données grâce à l’IA. Elle peut s’appuyer sur un agent pour identifier des valeurs manquantes, des distributions de données ou de la documentation des métadonnées qui répond à des questions en langage naturel, par exemple : "Y a-t-il des métadonnées disponibles qui documentent la source et les types de données de chaque colonne ?". - Génération de requêtes SQL et autocomplétion : Grâce aux LLM spécifiques à une tâche, les copilotes peuvent même générer du code SQL en réponse à des questions en langage naturel, ce qui permet de gagner du temps et d'obtenir rapidement des informations. Ils peuvent également optimiser les requêtes SQL pour améliorer les performances et la lisibilité. Les équipes Data seront donc équipées d’IDE intelligents, comme [Nao](https://getnao.io/) pour produire du code de transformation, type DBT. En produisant plus rapidement ([jusqu’à 10x plus vite](https://www.linkedin.com/posts/olaslett_we-can-ship-10x-faster-with-ai-were-also-activity-7353744784915587076-7H1m?utm_source=share&utm_medium=member_desktop&rcm=ACoAAASGiWoBULDM-zEVp6TuiLroRFQVDgnBZpQ) selon Olivier Laslett, CTO de Lightdash), les itérations entre les équipes métier et Data seront plus rapides ce qui permettra de construire des produits Data plus personnalisés avec plus d’impact avec une équipe plus restreinte. Le métier de Data Analyst va être profondément impacté par ces innovations, mais nous en parlerons plus tard. KPIs impactés par l’IA : - Vitesse de développement / Time-To-Insights - Qualité des analyses produits - Autonomie des équipes métier - Harmonisation des standards de développement #### 2.3 - Stockage Le modèle dominant du Data Warehouse - centralisé, figé, coûteux à adapter - a montré ses limites face à la croissance des volumes, à la diversité des cas d’usage, et à l’augmentation croissante des sources, des formats et des usages. L’émergence du Data Lakehouse, en réponse à ces contraintes, a déjà ouvert la voie vers des plateformes plus unifiées, capables d’adresser à la fois des besoins analytiques traditionnels et des usages ML/IA, avec des capacités de personnalisation beaucoup plus importantes. Beaucoup de nos clients fonctionnaient encore avec un SQL en guise de Data Warehouse. Ce n’est plus possible en 2025 : - moteur inadapté à des cas d’usages Analytics et IA - expérience de développement limitée - manque de scalabilité La majorité des projets Data &, IA s’appuieront sur les solutions suivantes : - Snowflake : plateforme de données SaaS cloud qui s’impose comme un composant central des architectures composables. Elle combine scalabilité dynamique, séparation du calcul et du stockage, adoption des formats ouverts comme Iceberg et intégration fluide dans des environnements hybrides. Idéale pour les workloads analytiques haute performance tout en s’ouvrant aux usages IA et temps réel. - Databricks : plateforme Lakehouse orientée data science et machine learning, optimisée pour la manipulation de données brutes et semi-structurées, l’entraînement de modèles et le traitement distribué à grande échelle. Son intégration native avec Delta Lake et ses APIs ouvertes en font un choix privilégié pour les projets IA complexes. - ClickHouse : moteur analytique orienté colonnes ultra-performant, conçu pour l’interactivité sur des volumes massifs. Très apprécié pour les cas d’usage BI temps réel, monitoring, observabilité et analytics opérationnel, grâce à ses temps de réponse extrêmement courts. - Trino / Iceberg : combinaison d’un moteur de requête distribué (Trino) et d’un format de table ouvert (Iceberg) permettant d’interroger les données là où elles résident, sans duplication. Offre une flexibilité maximale pour composer un écosystème data interopérable, tout en réduisant les coûts liés aux mouvements de données. Ces choix technologiques devront être réalisés en tenant compte des contraintes fortes telles que : - les coûts de la solution - la gouvernance légale / RGPD et règle appliquée en matière de traitement de données sensibles - la sustainability KPIs impactés par l’IA : - Optimisation du stockage - Coût de stockage par projet - Autonomie des équipes métier #### 2.4 - Orchestration L’orchestration est la brique qui permet d'exécuter des scénarios de traitement de données : elle décide quand et dans quel ordre chaque tâche doit s’exécuter, s’assure que toutes les dépendances sont satisfaites, réserve les ressources nécessaires (CPU, mémoire, GPU…), surveille l’avancement et gère les éventuelles erreurs pour que l’ensemble du flux arrive à son terme. Dans une architecture de données moderne et distribuée, elle joue un rôle stratégique : garantir que l’ensemble des traitements -ingestion, transformation, analyse, IA - s’exécutent dans le bon ordre, avec la bonne capacité de calcul, au bon moment. À court terme, ces orchestrateurs seront en mesure de fournir une interprétation de la source d’un incident, facilitant ainsi le "débogage" pour une équipe Data. A plus long terme, les orchestrateurs de demain utiliseront l’IA pour générer des scénarios de traitement de données qui seront plus statiques et fixés en amont mais dynamiques : des agents analyseront en continu l’état des pipelines et du système, détecteront des anomalies avant qu’elles ne causent un incident, ajusterons l’ordre d'exécution des tâches et l’allocation des ressources en temps réel, et déclencheront automatiquement des actions correctives pour résoudre des incidents. Ces agents intelligents ne se limitent plus à de la surveillance : - Self-healing pipelines : en cas d’erreur, le pipeline est capable de diagnostiquer la cause probable (source indisponible, transformation en échec, données incohérentes), puis de prendre une mesure corrective : relancer une tâche, basculer temporairement sur une autre source, corriger une valeur ou mettre en pause une étape problématique. Tout est loggué, offrant traçabilité et contrôle. - Aide à la génération de DAG : via le vibe coding, les équipes peuvent décrire un flux en langage naturel et obtenir un DAG généré automatiquement. L’IA peut aussi proposer des optimisations, améliorer la lisibilité ou simplifier la maintenance. Cependant, cette puissance impose des garde-fous : - Un socle robuste doit être fourni par l’équipe DataOps, incluant des standards de développement, des modèles de DAG pré validés, et des processus de déploiement et de tests automatisés. Ces standards permettent de s’assurer que les pipelines générés respectent les bonnes pratiques : fiabilité, observabilité, reprise sur erreur, compatibilité multi-environnements. - Les agents peuvent aller jusqu’à générer des DAGs, ouvrir des pull requests et proposer des revues de code. Reste à définir, pour chaque organisation, le degré de contrôle humain : validation systématique par un Data Engineer ou déploiement autonome dans certains cas maîtrisés. Reste à savoir si les éditeurs de solution d’orchestration type Airflow ou Dagster intègreront ce type de solutions dans le produit, ou s’il sera de la responsabilité des équipes Data de les développer. Comme cela a pu être vu pour d’autres solutions, il est probable que ce type de features soit intégré dans les offres payantes et ne soit donc pas disponible dans les versions open source. La brique d’activation correspond à la mise à disposition des données auprès des équipes métier, pour qu’elles puissent les exploiter dans leur quotidien. C’est ici que la donnée prend toute sa valeur, lorsqu’elle est traduite en insights actionnables via différents canaux : outils de visualisation (dashboarding), interfaces d’exploration libre (self-service analytics), exports automatisés vers les outils opérationnels (CRM, marketing automation…) ou encore intégration directe dans des applications métier. KPIs impactés par l’IA : - Autonomie des équipes métier - Qualité des données - Impact des équipes Data #### 2.5 - Data activation &, Analytics ##### 2.5.1 — L’évolution rapide des outils d’analytics Historiquement, la donnée était consommée via des tableaux de bord figés, nécessitant des compétences techniques pour produire de nouvelles analyses. Aujourd’hui, deux tendances fortes transforment cet usage : - Les solutions de dashboarding classiques évoluent Des acteurs établis comme Tableau, Power BI ou Looker ajoutent des fonctionnalités de chat permettant d’interroger les données en langage naturel. L’utilisateur peut poser une question (“Quelles sont les ventes mensuelles en France sur le dernier trimestre ?”) et obtenir non seulement la réponse, mais aussi la visualisation associée. Certaines solutions vont plus loin en proposant la génération de graphiques ou de requêtes avec du code produit par un copilote IA, facilitant l’analyse ad hoc. - L’émergence de plateformes analytiques avancées De nouveaux outils, comme Hex ou Mode, permettent de réaliser des analyses croisées et exploratoires directement sur le Data Warehouse. On ne se limite plus à des requêtes descriptives (“retrouve-moi la liste des ventes par pays”), mais on passe à des analyses explicatives ou prédictives (“identifie les facteurs qui influencent les ventes en Espagne au dernier trimestre”). Ces solutions s’adressent aux analystes comme aux profils métier avancés, en leur donnant accès à un environnement flexible, collaboratif et connecté aux sources de vérité. ##### 2.5.2 — Vers des “niveaux d’autonomie” des analyses Comme pour les voitures autonomes, on peut définir plusieurs paliers d’automatisation dans l’analytics : - Niveau 0 – No automation : l’utilisateur doit connaître le modèle de données et écrire lui-même ses requêtes. - Niveau 1 – Automatisation du requêtage : l’IA génère automatiquement les requêtes vers le Data Warehouse à partir de questions en langage naturel. - Niveau 2 – Guided insights : l’IA suggère des visualisations pertinentes ou des pistes d’analyse à partir d’un jeu de données choisi. - Niveau 3 – Proactive analytics : l’IA détecte et signale automatiquement des anomalies, tendances ou opportunités, sans requête préalable. - Niveau 4 – Autonomous decision support : l’IA recommande directement des actions à entreprendre, en s’appuyant sur l’ensemble des données disponibles et les objectifs de l’entreprise. ⚠️ Attention : ces outils sont encore jeunes et l’approche LLM reste questionnable dans sa capacité à construire des raisonnements avancés basés sur de l’analyse. ##### 2.5.3 — Les prérequis côté Data Pour tirer pleinement parti de ces nouvelles capacités, les équipes Data doivent disposer d’un Semantic Layer de qualité : • Une couche centralisée, de taille maîtrisée, contenant les KPI clés de l’entreprise. • Des données nettoyées, précalculées et documentées, garantissant leur qualité et leur cohérence. • Une documentation avancée (définitions métier, provenance, méthodes de calcul) afin que l’IA et les utilisateurs humains interprètent correctement les résultats. Permettre aux équipes de faire de la self-BI fait partie des enjeux majeurs de nos clients. Mais les outils actuels sont souvent trop complexes pour les utilisateurs non techniques. Ces nouvelles approches devraient casser ces verrous et démultiplier l’impact des équipes métier en leur donnant plus d’autonomie. KPIs impactés par l’IA (Semantic Layer) : • Autonomie des équipes métier, • Qualité des données, • Impact des équipes Data. #### 2.6 - Gouvernance et observabilité Dans une Data Platform moderne, la gouvernance correspond à l’ensemble des règles et mécanismes mis en place pour garantir une gestion efficace, fiable et maintenable des données. Elle s’exerce sur cinq dimensions complémentaires : • Métier : définition claire et partagée des KPIs pour éviter toute ambiguïté. • Business : alignement entre usages de la donnée et priorités stratégiques. • Légal : conformité réglementaire (RGPD, AI Act…), respect de la confidentialité. • RSE : prise en compte des enjeux éthiques et environnementaux. • Tech : respect des bonnes pratiques d’architecture, de sécurité, de qualité et de performance. L’observabilité va au-delà du simple monitoring : il s’agit de pouvoir expliquer rapidement pourquoi un pipeline échoue, où une donnée est altérée, et comment y remédier. L’intégration de l’IA dans la gouvernance et l’observabilité transforme profondément la façon dont on conçoit et maintient une Data Platform. ##### 2.6.1 — Analyse accélérée et plus transparente des logs Aujourd’hui, diagnostiquer un incident = parcourir des centaines de lignes de logs. Avec l’IA, il devient possible d’interroger les logs en langage naturel : >, “Montre-moi les trois dernières erreurs critiques sur le pipeline X et explique-moi leur cause probable.” Les agents IA consolident automatiquement les journaux, identifient les étapes problématiques, proposent des explications et des corrections. >, Gain majeur en transparence et en rapidité. Côté sécurité, il sera aussi possible d’interroger les logs pour savoir qui a accédé à quelle donnée. ##### 2.6.2 — Self-healing pipelines Les pipelines auto-réparateurs constituent l’une des applications les plus parlantes de l’observabilité augmentée par IA. Un pipeline peut : • détecter une anomalie, • identifier la cause probable, • exécuter une action corrective (relancer une tâche, remplacer une source, corriger une valeur incohérente), • consigner toutes ces actions dans un log d’audit. Résultat : moins d’incidents, moins de downtime, plus de valeur. ##### 2.6.3 — Génération de tests qualité en langage naturel Le maintien de tests pertinents est un défi permanent. Avec l’IA, on peut décrire un besoin métier et générer automatiquement un jeu de tests adapté. Exemple : >, “Crée un test qui vérifie que la somme des ventes par mois est cohérente avec la table de facturation, avec une tolérance de 1 %.” Ce mécanisme permet d’itérer rapidement, de supprimer les tests obsolètes, et de garder une suite de contrôles utile et pertinente. ##### 2.6.4 — Documentation dynamique et auto-complétée Problème récurrent : Un autre problème récurrent des plateformes Data est la documentation partielle ou obsolète. L’IA pourra extraire et organiser automatiquement les métadonnées (colonnes, types, règles de calcul, transformations appliquées) pour maintenir : Avec l’IA : • extraction et organisation automatique des métadonnées, • Des glossaires métier compréhensibles par tous, • Une documentation de lignage précise, montrant comment chaque donnée a été produite, • Des catalogues de données et de modèles à jour, intégrés dans les outils d’exploration. C’est un changement de paradigme. Jusqu’ici, la gouvernance et observabilité étaient perçues comme un “fardeau” : chronophages, coûteux, et rarement considérés comme une priorité par rapport à la livraison de nouvelles features data. Avec l’IA, ces fonctions seront correctement réalisées car plus automatisées, dynamiques et intégrées au cycle de vie des données (CI/CD). On passe : • d’un contrôle a posteriori à une surveillance continue, • d’une doc manuelle à une doc vivante, • d’un monitoring réactif à un pilotage préventif. C’est un changement qui ne se limite pas à l’outillage : il transforme la culture des équipes data, qui peuvent consacrer plus de temps à la valeur métier et moins aux tâches répétitives de maintenance. KPIs impactés par l’IA (gouvernance &, observabilité) : • Qualité des données, • Disponibilité des métiers, • Adoption des données (meilleure documentation &, gouvernance), • Compliance légale et sécurité. ### 3. Impact sur le coût et les émissions carbone #### 3.1 — Coût financier La GenAI a un impact significatif sur les coûts de fonctionnement des équipes Data et des Data Platform. D’une part, elle fait baisser les coûts humains : beaucoup de tâches répétitives (documentation, monitoring, data quality checks, orchestration de workflows) peuvent être automatisées par des copilotes ou des modèles spécialisés. Les équipes Data peuvent donc se concentrer sur des missions à plus forte valeur ajoutée, ce qui permet de faire plus avec moins. D’autre part, les coûts de fonctionnement vont augmenter drastiquement. La consommation de compute et de storage augmentera fortement avec l’usage croissant de la GenAI, notamment pour gérer de gros volumes de données et des workloads plus complexes. Il faut aussi prévoir l’ajout de nouvelles fonctionnalités IA sur les outils SaaS de la Modern Data Stack qui augmentent les coûts. À cela s’ajoute une dépendance accrue aux hyperscalers, avec des GPU coûteux et des modèles souvent proposés sous forme de services managés. En pratique, on ne dépense pas forcément moins : on déplace la charge financière. Les coûts humains diminuent, mais les coûts liés à l’infrastructure et aux services cloud prennent le dessus. La priorité pour les entreprises sera donc d’intégrer une logique FinOps, afin d’arbitrer entre performance et optimisation budgétaire, et d’éviter que la GenAI ne devienne un centre de coûts incontrôlable. En bref : La GenAI a un double effet : - ↓ Coûts humains : automatisation des tâches répétitives (doc, monitoring, quality checks…). - ↑ Coûts techniques : consommation accrue de compute et storage, ajout de fonctionnalités IA payantes dans la Modern Data Stack, dépendance aux hyperscalers et GPU coûteux. On ne dépense pas moins : on déplace la charge financière. Les coûts humains diminuent, mais les coûts cloud explosent. D’où l’importance d’une logique FinOps pour arbitrer entre performance et budget afin d’éviter que la GenAI ne devienne un centre de coûts incontrôlable. #### 3.2 — Impact carbone La question environnementale est tout aussi centrale. La GenAI entraîne une hausse de la consommation énergétique des plateformes : les data centers consommaient déjà environ 400 TWh en 2024, et ce chiffre pourrait tripler d’ici 2030 avec les workloads IA. Certains superclusters atteignent même une consommation à l’échelle du gigawatt, équivalente à celle d’une grande ville. Il faut cependant replacer ces chiffres dans leur contexte : une requête typique dans ChatGPT correspond à environ 0,03 g de CO₂e, quand une tasse de café en représente 21 g (700 requêtes ChatGPT = 1 café). En comparaison, l’empreinte carbone unitaire reste faible. Surtout, la GenAI peut aussi contribuer à réduire l’impact global : optimisation énergétique dans l’industrie, réduction du gaspillage dans les supply chains, ou encore meilleure efficacité dans le transport et la logistique. L’enjeu n’est donc pas de diaboliser la GenAI, mais de l’utiliser de manière responsable. Cela suppose de construire des plateformes sobres : éviter les traitements et stockages inutiles, choisir le bon niveau de compute en fonction du cas d’usage, privilégier des modèles adaptés plutôt que de systématiquement appeler de gros LLM, et s’appuyer sur des data centers utilisant des énergies propres ou des solutions de cooling avancées. L’IA peut être à la fois un risque et un levier pour la durabilité. C’est la capacité des équipes Data à intégrer une approche responsable dans leur design et leurs pratiques qui fera la différence dans les années à venir. En bref : La GenAI augmente fortement la consommation énergétique : - Data centers → ~400 TWh en 2024, possible x3 d’ici 2030, - Certains superclusters = 1 gigawatt (équivalent consommation d’une grande ville). L’IA peut aussi réduire l’impact global : • optimisation énergétique dans l’industrie, • réduction du gaspillage supply chain, • efficacité dans le transport et la logistique. L’enjeu n’est donc pas de diaboliser la GenAI, mais de l’utiliser de manière responsable. Cela suppose de construire des plateformes sobres : La clé = construire des plateformes sobres : • éviter les traitements inutiles, • calibrer le compute selon l’usage, • privilégier des modèles adaptés plutôt que des LLM massifs, • choisir des data centers verts (énergies propres, cooling avancé). L’IA est à la fois un risque et un levier pour la durabilité. ### Conclusion La GenAI ne se limite pas à introduire de nouveaux outils : elle redéfinit en profondeur l’architecture et le fonctionnement des Data Platforms. Chaque brique – de l’ingestion à l’orchestration, en passant par la transformation, le stockage, l’analytics et la gouvernance – est appelée à évoluer sous l’effet des copilotes, des agents autonomes et des approches plus dynamiques. Résultat : réduction des efforts manuels, accélération du time-to-insight, meilleure autonomie des équipes métier. Mais ces innovations s’accompagnent aussi de défis majeurs. Les coûts financiers et énergétiques liés à l’usage intensif de l’IA vont croître, imposant une vigilance accrue en matière de FinOps et de durabilité. Et si les équipes Data peuvent “faire plus avec moins”, cela ne sera viable qu’à condition de s’appuyer sur un socle DataOps robuste, garantissant standards, gouvernance et cohérence. Sans cela, le risque est grand de bâtir des plateformes instables, coûteuses ou de recréer une nouvelle “usine à gaz” technologique. En somme, cette première révolution guidée par la GenAI place les équipes Data devant un double impératif : exploiter la puissance de l’IA pour gagner en impact, tout en maîtrisant la complexité et la soutenabilité de leurs plateformes. --- 👉 Dans le prochain article de cette série – Impact de l’IA sur les équipes Data (2/3) : évolutions des rôles et responsabilités – nous explorerons comment ces transformations se traduisent concrètement sur l’organisation et les métiers des équipes Data, et quelles compétences seront nécessaires pour tirer parti de ce nouvel écosystème. --- #### Et pour en savoir plus sur la Modern Data Stack, retrouvez notre masterclass inédite avec Robin Conquet de Data Gen ici ! ##### Sources - https://www.matillion.com/uploads/pdf/OReilly-Guide-April-2025.pdf - https://medium.com/dataplatform-things/agentic-ai-for-data-engineering-reimagining-enterprise-data-management-with-ai-agents-1f0ec70b04da - https://www.linkedin.com/feed/update/urn:li:activity:7349327857187176451/ - https://www.datacamp.com/tutorial/crew-ai - https://juhache.substack.com/p/boring-semantic-layer-mcp - https://arxiv.org/pdf/2507.07935 - https://blog.dataexpert.io/p/how-i-made-airbnb-millions-with-this - https://ai.gopubby.com/ai-energy-paradox-powering-the-future-without-burning-it-down-752396678a6e - https://www.wsj.com/articles/google-wants-you-to-know-the-environmental-cost-of-quizzing-its-ai-143cfe19 --- ## Clickhouse | La base de référence pour vos real-time apps ? URL : https://modeo.ai/articles/clickhouse-overview > ClickHouse est un système de gestion de base de données (SGBD) open-source conçu pour l'analyse de données en temps réel et à grande échelle. ### Qu'est-ce qu'un datawarehouse ? Un datawarehouse est un système centralisé de stockage de grands volumes de données provenant de diverses sources au sein d'une organisation. Son objectif principal est de faciliter l'établissement de rapports, l'analyse et l'exploration des données en consolidant les données provenant de différentes sources opérationnelles en une vue unique et unifiée. Les principales caractéristiques d'un datawarehouse sont la centralisation, l'organisation par sujet, l'intégration de sources de données multiples, le stockage en fonction du temps pour l'analyse historique et la non-volatilité pour maintenir l'intégrité des données ainsi que la notion de scalabilité pour les cas de big data. Les datawarehouse utilisent souvent des techniques telles que la modélisation des données, les processus ETL (extraction, transformation, chargement) ou ELT (extraction, chargement, transformation) pour optimiser le stockage et la récupération des données à des fins d'analyse. Ils jouent un rôle crucial dans le soutien de la veille stratégique, de la prise de décision et de la planification stratégique au sein des organisations en fournissant une source fiable et centralisée de données pour l'analyse. Ce sont des[éléments clés des Modern Data Platforms](../../articles/modern-data-platform-definition-entreprise/index.html). ### Qu'est-ce que ClickHouse ? [ClickHouse](https://clickhouse.com/) est un système de gestion de base de données (SGBD) open source, performant et orienté colonnes, créé par la société russe[Yandex](https://yandex.com/) en 2009 dans le but principal de le rendre aussi rapide que possible pour traiter efficacement de grandes quantités de données et fournir des performances élevées pour les applications et les analyses en temps réel. C’est une solution de plus en plus adoptée par les entreprises et qui devient incontournable dans le paysage de la [Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html). ClickHouse peut être utilisé en tant que logiciel open source on-premise ou via une offre dans le cloud basée sur AWS et GCP (bientôt Azure à l’heure où cet article est écrit). ### Les cas d’utilisation de ClickHouse ClickHouse est principalement utilisé pour des scénarios OLAP. OLAP signifie Online Analytical Processing (traitement analytique en ligne). Il s'agit d'une catégorie de technologie logicielle utilisée pour analyser les données afin de soutenir les processus de prise de décision. Les systèmes OLAP sont conçus pour les requêtes complexes et l'analyse multidimensionnelle des données. Lorsque l'on travaille sur des scénarios OLAP, on a tendance à se concentrer sur certaines caractéristiques : - Les tables sont très grandes, des milliards ou des trillions de lignes et des centaines ou des milliers de colonnes. - L'extraction et l'agrégation d'un petit ensemble de colonnes à la fois pour se concentrer sur des sous-ensembles spécifiques d'intérêt. - Les requêtes doivent être rapides pour fournir ce comportement en temps réel aux rapports et aux analyses. Le but premier de Clickhouse était de récupérer de grandes quantités de données aussi rapidement que possible. Le fait qu'il soit orienté colonnes (voir schéma explicatif ci-dessous) le rend des centaines de fois plus rapide que les bases de données traditionnelles lorsqu'il s'agit de récupérer un ensemble de colonnes. En outre, ClickHouse utilise toutes les ressources système disponibles à leur plein potentiel pour traiter chaque requête analytique aussi rapidement que possible. ClickHouse propose également d'autres fonctionnalités pour améliorer les performances, comme le traitement parallèle et distribué. ### Quelles sont les particularités et avantages de ClickHouse ? #### Stockage en colonnes ClickHouse stocke les données dans un format en colonnes, ce qui signifie qu'il stocke chaque colonne d'une table séparément plutôt qu’en lignes. Cela permet une compression et une récupération efficaces des données, car les requêtes peuvent accéder rapidement aux seules colonnes nécessaires à l'analyse, ce qui minimise les opérations d'E/S et accélère les performances des requêtes. #### Traitement parallèle ClickHouse utilise des techniques de traitement parallèle pour exécuter les requêtes simultanément sur plusieurs cœurs du CPU. Ce parallélisme permet d'obtenir un débit élevé et de faibles temps de latence pour les requêtes, car la charge de travail est répartie entre les ressources disponibles, ce qui permet une utilisation efficace des ressources hardware. #### Traitement distribué ClickHouse peut être déployé dans une architecture distribuée sur plusieurs nœuds, ce qui lui permet de gérer de grands volumes de données et une concurrence élevée au niveau des requêtes. Les données sont partitionnées et répliquées sur les nœuds à l'aide de shards et replicas, et les requêtes peuvent être exécutées en parallèle sur l'ensemble du cluster, offrant ainsi une évolutivité horizontale et une tolérance aux pannes. #### Compatibilité SQL ClickHouse prend en charge un sous-ensemble riche de SQL pour le requêtage et la manipulation des données. Cela inclut les fonctions SQL standard telles que SELECT, INSERT, UPDATE, DELETE, JOIN et les fonctions d'agrégation. En outre, ClickHouse offre des extensions et des optimisations adaptées aux charges de travail analytiques, telles que des fonctions d'agrégation et des fonctions de fenêtre efficaces, ainsi que des Materialized Views. #### Primary Indexes ClickHouse prend en charge les index primaires, qui sont utilisés pour appliquer les contraintes d'unicité sur les colonnes de la table et optimiser la récupération des données. Les index primaires sont généralement définis sur une ou plusieurs colonnes qui identifient de manière unique chaque ligne de la table, ce qui permet des opérations de recherche rapides et un filtrage efficace des données. #### Stockage sur disque ClickHouse est conçu pour fonctionner sur des disques durs ordinaires, ce qui signifie que le coût par GB de stockage de données est faible, mais les disques SSD et la RAM supplémentaire sont également pleinement utilisés s'ils sont disponibles. L'architecture en colonnes de ClickHouse et le tri par clé primaire permettent une extraction efficace des données en fonction de valeurs ou de plages de valeurs spécifiques, même lorsqu'elles sont stockées sur disque. Cette conception optimise les performances des requêtes, en garantissant une faible latence pour l'extraction des sous-ensembles de données souhaités. #### Compression des données Certains systèmes de gestion de base de données orientés colonnes négligent l'utilisation de la compression des données, alors que cette dernière joue un rôle crucial dans l'atteinte de performances optimales. En plus des codecs de compression généraux efficaces, qui présentent différents compromis entre l'espace disque et la consommation CPU, ClickHouse propose des codecs spécialisés adaptés à des types de données spécifiques. Cette approche permet à ClickHouse de rivaliser voire surpasser des bases de données plus spécialisées, telles que celles dédiées aux séries temporelles. #### Role-based access control (RBAC) ClickHouse fournit des mécanismes de contrôle d'accès basés sur les rôles pour restreindre l'accès aux données et aux fonctionnalités. Les administrateurs peuvent définir des rôles avec des privilèges spécifiques, tels que l'accès en lecture seule, l'accès en écriture ou les autorisations administratives, et affecter des utilisateurs à ces rôles pour contrôler leur accès aux bases de données, aux tables et aux ressources du système. Le système RBAC garantit la sécurité et la conformité des données en appliquant des politiques de contrôle d'accès et en empêchant l'accès non autorisé aux données sensibles. #### Multiples moteurs de stockage ClickHouse propose [plusieurs moteurs de stockage](https://clickhouse.com/docs/en/engines/table-engines) adaptés à différentes situations de données : - MergeTree : Moteur par défaut pour les données de séries chronologiques. - Distributed : Distribue les données sur un cluster. - ReplacingMergeTree : Optimisé pour les mises à jour fréquentes de données. - AggregatingMergeTree : Pré-agrège les données pour une analyse plus rapide. - GraphiteMergeTree : Stocke les données de métriques au format Graphite. - CollapsingMergeTree : Fusionne les données selon des critères spécifiques. - VersionedCollapsingMergeTree : Suivi des modifications historiques. - Kafka : Consomme les données en temps réel à partir d'Apache Kafka. ### Les inconvénients de ClickHouse ClickHouse présente plusieurs inconvénients qui peuvent rendre le déploiement et la maintenance sur site laborieux. En tant que solution optimisée pour l'analyse de données, elle n'est pas idéale pour les systèmes OLTP, car les modifications et les mises à jour peuvent entraîner des temps de requête prolongés et une utilisation intensive du processeur. De plus, la déduplication des données reste un défi majeur, et dans la plupart des cas, elle n'est pas réalisable. La consommation élevée des ressources, notamment de CPU et de la mémoire, est un autre inconvénient, en particulier dans le cadre d'une architecture distribuée traitant de vastes ensembles de données. Enfin, l'apprentissage des détails de bas niveau peut prendre du temps, ce qui nécessite une certaine courbe d'apprentissage pour les utilisateurs et les administrateurs. ### Modèle de facturation La philosophie tarifaire de ClickHouse repose sur la flexibilité et l'efficacité, garantissant que les utilisateurs ne paient que pour les ressources qu'ils consomment. Avec une approche axée sur la tarification à l'utilisation, ClickHouse permet aux organisations de redimensionner dynamiquement les ressources en fonction des demandes de charge de travail, optimisant à la fois les performances et la rentabilité. En séparant le dimensionnement du stockage et du calcul, ClickHouse permet aux utilisateurs d'ajuster indépendamment les ressources pour répondre à des besoins spécifiques, réduisant ainsi les gaspillages et maximisant l'efficacité. De plus, la capacité de la plateforme à réduire automatiquement à zéro les ressources inutilisées garantit une utilisation optimale des ressources et des économies de coûts. La tarification sur ClickHouse cloud dépend également du cloud Provider utilisé pour l’héberger et de la région sélectionnée. Chaque formule proposée présente des use-cases et des features différentes selon le type d’utilisateurs et la taille du projet. Pour plus de détails, voir[la page du pricing sur le site ClickHouse](https://clickhouse.com/pricing). En conclusion, ClickHouse s'impose comme une solution puissante et efficace pour répondre aux besoins de datawarehousing et d'analyse de données. Son stockage en colonnes, ses capacités de traitement parallèle et son architecture distribuée permettent aux entreprises d'analyser de vastes volumes de données avec une rapidité et une précision remarquables. Qu'il s'agisse d'ingérer des données en temps réel ou d'effectuer des requêtes analytiques complexes, ClickHouse offre des performances, une évolutivité et une fiabilité élevées, ce qui en fait un choix convaincant pour les entreprises qui cherchent à obtenir des informations et à conduire des processus de prise de décision en toute confiance. C’est d’ailleurs une solution que nous utilisons régulièrement chez[Modeo](../../index.html) pour des clients de toute taille et sur des cas d’utilisation variés. Si vous êtes intéressés par l’implémentation de Clickhouse dans votre Stack ou pour la mise en place de cas d’usage data, [contactez-nous](../../contact.html) et nous nous ferons un plaisir d’en discuter avec vous ! --- ## Cube.js | La référence pour construire sa semantic layer URL : https://modeo.ai/articles/cube-js-intro > Cube.js est un framework open-source agissant comme une semantic layer et permettant de construire des applications web analytics. ### Les semantics layers, une couche d'uniformisation indispensable Une semantic layer, ou couche sémantique, est un niveau d'abstraction qui transforme les données en informations accessibles et compréhensibles, orientées vers un domaine d'activité, pour des utilisateurs sans expertise technique. Située au-dessus des données techniques, elle sert de pont entre les données complexes produites par les équipes data et des informations lisibles et centrées sur le métier, facilement exploitables. Les informations sont disponibles pour les utilisateurs finaux sous forme de tables dans une base de données ou via une API. Pour plus d’informations sur les semantic layers, leur utilité et leurs cas d’utilisation, nous vous invitons à lire notre article dédié “[Les semantic layers (couches sémantiques) : Le référentiel pour vos applications IA et Analytics](../../articles/semantic-layers/index.html)". ### Cube.js, un acteur incontournable [Cube.js](https://cube.dev/) est un framework open-source agissant comme une semantic layer et permettant de construire des applications web analytics. Cet outil offre aux Data Engineers et développeurs la possibilité d’accéder, de modéliser et d’agréger de la data stockée dans une ou plusieurs sources de données. L’objectif est ensuite de mettre à disposition d’application la data agrégée. Contrairement à un grand nombre de solutions qui proposent une couche sémantique couplée à un outil de visualisation (comme Looker par exemple), Cube.js est un framework indépendant découplé de tout outil BI. Cette approche que l’on appelle headless est au cœur de l'architecture de Cube.js et permet une grande flexibilité dans la manière dont les données sont interrogées, traitées et affichées. En plus de cela, Cube.js offre la possibilité de se connecter à plusieurs sources de données différentes et de les associer au niveau de la couche de mise en cache, ce qui est une approche très différente de celle des moteurs de requêtes fédérées. Cela permet d’améliorer les performances, l'évolutivité en gérant plus efficacement les pics de charge, la flexibilité et la consistance des données. ### L’architecture de Cube.js Cube.js adopte une approche similaire à la plupart des applications web modernes, qui sont structurées autour d'une séparation claire entre le frontend et le backend, ce dernier étant lui-même fragmenté en plusieurs services suivant une architecture de microservices. Ainsi, vous pouvez exécuter le backend de Cube.js en tant que service assurant la gestion de la connexion à la base de données, la gestion de la file d'attente des requêtes, la mise en cache et la pré-agrégation. Ce backend fournira également une API destinée au frontend, facilitant ainsi la création de visualisations et l'implémentation de fonctionnalités analytiques. ### Les services de Cube.js Selon Cube.js, toute couche sémantique doit impérativement proposer quatre services, qu’ils mettent bien sûr à disposition via leur framework. #### Data Modeling Le cadre de modélisation de données Cube.js permet aux équipes de données de centraliser les modèles de données, facilitant l'utilisation ultérieure par des outils BI, des applications d'analytique intégrée ou des agents IA. Cette approche promeut un principe DRY (Don’t Repeat Yourself) en minimisant la redondance de modélisation de données à travers différents niveaux de présentation. Cube.js privilégie une approche code-first, où les modèles sont définis en YAML ou JavaScript, gérés via un système de versioning. Cube.js vous fait manipuler des entités métier appelées cubes, et des views, servant de façades utilisables par les consommateurs pour interroger les données. #### Access Control En centralisant l'accès aux données dans la semantic layer, elle devient un point stratégique pour appliquer des politiques de contrôle d'accès. Avec Cube.js, les équipes peuvent utiliser Python ou JavaScript pour établir des règles d'accès ou des contrôles par ligne par exemple. #### Caching La couche sémantique agit comme un tampon, protégeant les sources de données de charges superflues grâce au caching. Cube.js utilise des pré-agrégations pour faciliter le caching, permettant aux équipes de définir des tables de synthèse qui sont automatiquement mises à jour dans Cube.js Store. Cette approche accélère les requêtes et réduit significativement les coûts de requêtes. #### APIs Pour ne pas dépendre d’outils spécifiques et assurer une interopérabilité totale, la semantic layer doit s’appuyer sur des protocoles existants et largement utilisés. Pour cette raison, Cube.js met sa donnée à disposition via une API REST, GraphQL et SQL. ### Les cas d’usage de Cube.js La prise en main et les performances de Cube.js en font un outil incontournable pour de nombreux cas d’usage. Un des grands avantages de Cube.js est que la solution s'intègre parfaitement avec les outils de la [Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html). Nous vous présentons ci-dessous quelques cas d'utilisation. #### Embedded analytics Imaginons un fournisseur de SaaS spécialisé dans la création de site e-commerce, souhaitant fournir à ses clients des analyses et du reporting au travers de tableaux de bord, tout en gardant un contrôle total sur les visualisations proposées et leur design. Cube.js pourrait alors être utilisé comme couche sémantique afin de requêter et de modéliser les données stockées en base et de mettre à disposition des développeurs frontend les données pré-agrégées sous la forme de endpoint grâce à l’API REST. Pour respecter des contraintes de confidentialité entre les clients, les données des clients peuvent être séparées au niveau du datawarehouse en variabilisant les projets et tables GCP requêtés par Cube.js et au niveau du cache de Cube.js. #### Connected BI De nombreuses entreprises sont confrontées à des incohérences de valeurs de KPIs entre leurs différents dashboards (parfois répartis sur plusieurs outils de visualisation). Pour pallier cela, la solution est d'uniformiser et de centraliser le traitement des données car ces divergences sont souvent dues à l’éparpillement des transformations et la multitude de sources de données. Une solution efficace et robuste pourrait alors être l'implémentation de Cube.js en tant que couche sémantique. Cube.js permettrait alors de standardiser les transformations de données et d'assurer une source unique de vérité pour tous les KPIs. Cube.js serait ensuite l’unique référentiel alimentant l’intégralité des dashboards, résolvant ainsi le problème des incohérences et améliorant significativement la fiabilité des analyses. #### LLM and AI semantic layer Les couches sémantiques sont très largement utilisées dans le domaine de l’Intelligence Artificielle pour limiter les phénomènes d’hallucination et de "garbage in, garbage out" rencontrés par les modèles LLM. En effet, si les humains ont du mal à traiter des données incohérentes et désorganisées, les LLM ne feront qu'amplifier cette confusion et fourniront des réponses incorrectes. Pour fonctionner correctement et réaliser des actions fiables, les modèles LLM doivent disposer d'un contexte suffisant et comprendre la sémantique des données qu'ils traitent. En résumé, les LLM ont besoin d'une couche sémantique. La couche sémantique organise les données en définitions business significatives, permettant ensuite de réaliser des requêtes sur ces définitions plutôt que directement sur la base de données Dans un prochain article, nous mettrons en pratique la théorie en déroulant un projet de modélisation et visualisation via Cube.js et[Apache echarts](https://echarts.apache.org/en/index.html). SI vous êtes confrontés à des problématiques similaires ou souhaitez implémenter des projets IA et d’embedded analytics,[contactez-nous](../../contact.html) ! --- ## dbt: Outil data phare de la transformation de données URL : https://modeo.ai/articles/dbt-loutil-data > dbt (Data Build Tool) est un outil open-source de transformation de données de type ELT. Il permet de traiter des données stockées dans un Data Warehouse. ### dbt : qu’est-ce que c’est ? [dbt (Data Build Tool)](https://www.getdbt.com/) est un **outil open-source de transformation de données de type ELT**(Extract Load Transformation), écrit en Python. dbt permet aux utilisateurs de **réaliser des transformations directement dans l’entrepôt de données**, avec du SQL ou du Python. Lancé par Fishtown Analytics (maintenant connu sous le nom de dbt Labs), dbt a été conçu avec l'idée de rendre les processus de transformation de données plus efficaces et transparents, en appliquant des pratiques d'ingénierie logicielle, telles que le contrôle de version et les tests automatisés. ### Le contexte d’apparition de dbt La transformation des données est une composante essentielle des[Modern Data Platforms](../../articles/modern-data-platform-definition-entreprise/index.html). Elle permet de **convertir des données brutes en informations précieuses** pour guider les décisions stratégiques. Avec l'augmentation des volumes de données, ce processus est devenu un enjeu majeur pour les entreprises qui cherchent à réduire les temps de processing et coûts associés. Historiquement, plusieurs méthodes ont été utilisées pour effectuer ces transformations, mais **les transformations SQL se sont imposées comme la norme**. Ces transformations sont souvent orchestrées par des procédures stockées ou des orchestrateurs de workflows comme[Apache Airflow](https://airflow.apache.org/). **Ces approches présentent cependant des défis majeurs, notamment en termes de maintenance du code et de gestion des versions**, car elles ne sont pas bien adaptées aux langages SQL traditionnels. C'est dans ce contexte que Data Build Tool (dbt) a été créé. Dans cet article, nous explorerons en détail ce qu'est dbt, ses caractéristiques principales, les avantages qu'il offre par rapport au SQL traditionnel et comparerons les deux offres principales de dbt pour vous aider à déterminer quelle option est la plus adaptée à vos besoins. #### dbt : La solution aux défis du ELT ? Avec l'évolution du paradigme **ELT** (en opposition à l’ETL), qui consiste à **transférer les données brutes vers un entrepôt de données et de les transformer**par la suite, de nouvelles solutions de transformations de données sont apparues. Ces solutions facilitent la transformation des données après leur réplication de diverses sources vers un dépôt centralisé. Toutefois, la transformation (ou modélisation) de ces données demeure un défi significatif. Pour y remédier, certaines entreprises se tournent vers des solutions personnalisées comme Airflow, qui nécessitent une programmation en Python et une infrastructure conséquente, rendant cette approche peu accessible. D'autres préfèrent utiliser des interfaces graphiques comme Looker pour la modélisation des données, mais ces options impliquent souvent des coûts de licence élevés et des défis en matière de maintenance. C'est ici que dbt entre en jeu, en offrant **une couche d'orchestration supplémentaire pour gérer l'entreposage des données**. dbt se distingue par sa capacité à retraiter les données stockées dans un datawarehouse, représentant ainsi le "T" de la chaîne ELT. ### Les fonctionnalités de dbt et les avantages qu’elles apportent dbt offre différentes fonctionnalités pour transformer la manipulation de données en un processus structuré, efficace, et collaboratif. #### Flexibilité des modèles SQL L'une des principales caractéristiques qui distingue dbt des différents outils est la **flexibilité de ses modèles SQL**. Cette flexibilité est rendue possible par plusieurs fonctionnalités : - Jinja Templating : dbt utilise Jinja, un moteur de templates, pour écrire des scripts SQL. Cela permet d'incorporer des logiques conditionnelles, des boucles, et des variables dans les scripts SQL, rendant les modèles dynamiques et réutilisables. - **Réutilisation de code** : Avec dbt, il est facile de créer des macros et des packages réutilisables. Ces éléments peuvent être intégrés dans différents projets, améliorant ainsi la cohérence et réduisant le temps de développement. - **Dépendances modulaires (Lineage)** : dbt permet de construire des modèles de données en définissant des dépendances. Cela signifie que vous pouvez spécifier l'ordre dans lequel les transformations doivent être exécutées, garantissant que les données sont toujours traitées de manière logique. Pour ce faire, dbt génère automatiquement des graphiques de lignée des données qui montrent les dépendances entre les différents modèles. Ces graphiques visuels permettent aux data engineers de : - **Visualiser les flows de travail** pour comprendre rapidement comment les transformations de données sont organisées. - **Identifier les dépendances** : voir les relations entre les sources de données, les transformations et les analyses finales. - **Dépanner et optimiser** : localiser les problèmes et les goulets d'étranglement dans les pipelines de données en comprenant les chemins de dépendance. #### Versionning et échange de projets simplifiés dbt intègre des pratiques de software development, notamment le contrôle de version et la CI/CD. - **Contrôle de version** : chaque transformation de données est écrite en tant que code et peut être suivie via un système de contrôle de version comme Git. Cela signifie que les équipes peuvent collaborer plus efficacement, avec un historique des modifications, et la capacité de revenir à des versions précédentes en cas de problème. - **CI/CD** : dbt peut être intégré dans les pipelines CI/CD pour automatiser le test et le déploiement de modèles de données. Cela garantit que toutes les modifications subissent un processus de validation avant d'être appliquées à la base de données de production, réduisant ainsi le risque d'erreurs et accélérant le cycle de vie du développement. #### Test et Documentation dbt permet d'**automatiser les tests de qualité des données**, notamment[les data tests](https://docs.getdbt.com/docs/build/data-tests) et les[unit tests](https://docs.getdbt.com/docs/build/unit-tests), garantissant ainsi que les données transformées répondent aux attentes et aux normes définies. Cela augmente considérablement la fiabilité des données. dbt **automatise la génération de la documentation**autour des descriptions, des dépendances du modèle du modèle SQL, des sources et des tests. La documentation affiche les modèles existants et des informations détaillées sur chacun et génère des graphiques de lignage. Elle est constituée de trois fichiers et peut être déployée très facilement. #### Connexions aux bases de données dbt offre une **compatibilité étendue avec plusieurs des principales plateformes de données cloud,** telles que[BigQuery](../../articles/bigquery-overview/index.html), Snowflake, Amazon RedShift, PostgreSQL. En tant qu'outil open source, dbt bénéficie également du soutien d'une **communauté active** qui développe des connecteurs pour étendre sa compatibilité. Le **catalogue de la communauté** comprend notamment des connecteurs pour[DuckDB](https://duckdb.org/),[ClickHouse](../../articles/clickhouse-overview/index.html) ou MySQL. Cet outil est un pilier de la[Modern Data Stack (voir notre article à ce sujet](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html)) et est conçu pour s’interfacer facilement avec une multitude d’autres solutions. ### La structure d’un projet dbt Les projets dbt possèdent une **architecture spécifique**, conçue pour simplifier la gestion et optimiser les performances. Au cœur de cette configuration se trouve le dossier models, l’élément essentiel dans cette configuration, contenant les modèles SQL qui définissent les transformations des données. Ces modèles sont organisés en sous-dossiers reflétant souvent la logique métier ou les étapes de transformation. Le dossier tests permet d'intégrer des tests de validation des données, assurant leur intégrité et qualité. La configuration du projet se fait via le fichier dbt_project.yml, centralisant les informations essentielles comme la version du projet, la configuration des modèles, et les dépendances. Les dossiers macros et snapshots ajoutent des fonctionnalités avancées comme des scripts réutilisables et la capture de l'état des données dans le temps, tandis que seeds permet de gérer des jeux de données statiques. Le dossier analyses dans un projet dbt est destiné à contenir des analyses SQL qui sont exécutées pour extraire des insights ou des rapports ad hoc à partir des données transformées. Ces analyses ne sont généralement pas des transformations de données que vous allez inclure dans le flux de travail régulier. ### La matérialisation des modèles dans dbt La matérialisation dans dbt est un concept clé qui **détermine comment les modèles de données sont physiquement représentés dans votre entrepôt de données**. En contrôlant la matérialisation, dbt offre une flexibilité considérable pour **optimiser les performances, la gestion de l'espace, et la vitesse d'exécution des requêtes**. dbt propose aujourd’hui quatre principales méthodes de matérialisation qui sont : - **View** : Créer une vue dans la base de données, exécutée à la demande, sans stockage physique des données. - **Table** : Stocke les données transformées physiquement, améliorant les performances des requêtes en évitant des calculs répétés. - **Ephemeral** : Crée des tables temporaires non stockées dans l'entrepôt, utilisées comme intermédiaires dans des transformations. - **Incremental** : Insère ou met à jour des lignes dans une table existante, ajoutant ou modifiant uniquement les données changées depuis la dernière exécution. ### dbt Core &, dbt Cloud : Quelle est la différence ? **dbt propose deux versions : une version open-source Core, et une version Cloud.** dbt Labs a dévoilé de nouvelles fonctionnalités majeures pour dbt Cloud afin de résoudre certains des plus grands problèmes auxquels les organisations sont confrontées. Alors que dbt continue de renforcer et d'améliorer les capacités de son offre cloud, les e**ntreprises doivent prendre le temps de déterminer quelle offre leur convient le mieux**. #### dbt Core La **version open-source** de l'outil a longtemps été la solution privilégiée pour transformer les données. Avec la capacité d'exécuter directement les modèles dbt dans un data warehouse, dbt Core s'intègre de manière transparente dans les flux de travail de données existants. L’outil est **gratuit** mais les organisations souhaitant exécuter dbt Core en production sont tenues de **gérer elles-mêmes l'infrastructure de déploiement**, ce qui signifie qu’elles doivent posséder les ressources nécessaires pour maintenir et faire évoluer l'infrastructure. #### dbt Cloud [dbt Cloud](https://www.getdbt.com/product/dbt-cloud) est la version SaaS fully-managed de dbt, visant à améliorer l'expérience d'utilisation de dbt et à rendre accessible l’outil aux utilisateurs non techniques. L’offre cloud propose également des fonctionnalités supplémentaires comme la possibilité de **programmer des exécutions** et de les orchestrer pour s'assurer qu'elles se déroulent dans l'ordre approprié, en tenant compte des dépendances entre les modèles. Les utilisateurs peuvent également **gérer le passage de ces modèles de données à travers différents environnements de développement, de test et de production**, facilitant ainsi un cycle de développement de données plus structuré et contrôlé. dbt Cloud étend les capacités de dbt Core en fournissant une plateforme basée sur le cloud pour l’Analytics Engineering. Ce service entièrement géré offre un **environnement collaboratif et une interface utilisateur pratique**, permettant aux équipes de travailler de manière fluide sur leurs projets d'analyse. #### Comment choisir entre dbt cloud et dbt core ? Il est crucial de réfléchir à qui utilisera l'outil dbt. **Si votre équipe est composée principalement de profils techniques, tels que des****Data Engineers****, nous recommandons d'utiliser dbt Core**. Cette offre gratuite est bien adaptée pour ceux qui peuvent avoir la main sur leur solution, organiser les tâches, gérer la documentation et mettre en place un système local efficace. **Cependant, pour les équipes ayant moins de profils techniques, il peut être judicieux d'envisager une solution plus complète comme dbt Cloud**, qui offre des fonctionnalités supplémentaires et plus accessibles de gestion et de collaboration. En conclusion dbt représente un choix judicieux pour toute organisation cherchant à rationaliser ses opérations de transformation de données. En fournissant un cadre structuré pour la manipulation des données, et il s’est imposé comme un outil essentiel. Avec ses fonctionnalités puissantes telles que la documentation automatique, le lineage des données, les tests, le versioning, et une intégration transparente avec les principales plateformes de données cloud, dbt facilite la collaboration entre data engineers et data analysts, assurant une qualité et une fiabilité accrues des données. Que vous optiez pour dbt Core ou dbt Cloud, l'adoption de dbt est un pas vers des processus de données plus efficaces, collaboratifs et fiables. Avec cet outil, le futur de la transformation des données semble non seulement prometteur mais également accessible à tous. dbt est aujourd’hui un choix incontournable pour toute entreprise souhaitant moderniser sa Data Stack et assurer la fiabilité de ses données. En tant qu'experts en dbt et en création de Data Platforms innovantes et complètes, nous sommes prêts à vous accompagner dans votre évolution et à transformer vos données en informations de valeur. [Contactez-nous](../../contact.html) pour savoir comment nous pouvons répondre à vos besoins spécifiques ! --- ## Agent LLM - Mise en place un agent conversationnel sur AWS URL : https://modeo.ai/articles/comment-mettre-en-place-un-agent-conversationnel-sur-aws > Tutoriel : mettre en place un agent conversationnel LLM sur AWS avec une architecture RAG, de l'ingestion des documents au déploiement en production. ### La montée en puissance des agents conversationnels en entreprise Les agents conversationnels ne sont plus une curiosité technologique. Aujourd’hui, ils deviennent des leviers de performance concrets pour les entreprises : gain de temps, accès instantané à la connaissance interne, meilleure qualité de service, et réduction de la charge des équipes support. Mais alors, pourquoi développer son propre agent LLM plutôt que d’utiliser un assistant grand public comme ChatGPT ? Ces outils sont génériques par nature : ils ne connaissent ni vos règles métiers, ni vos bases de données, ni vos contraintes réglementaires. Ils ne garantissent ni la confidentialité des données, ni une intégration fluide dans votre écosystème. Bref, ils brillent à l’extérieur, mais n’apportent pas de valeur différenciante en interne. C’est pourquoi de plus en plus d’équipes, métiers comme techniques choisissent de concevoir un agent conversationnel LLM sur mesure, hébergé dans un environnement sécurisé comme AWS Bedrock, pour répondre à leurs besoins spécifiques : - Maîtriser les flux de données sensibles (RGPD, souveraineté) - Adapter le langage à chaque métier - Connecter l’agent aux outils internes (CRM, support, bases documentaires, etc.) Dans ce guide, nous verrons comment concevoir un tel agent de bout en bout : • Pourquoi cette approche devient stratégique ? • Qu’est-ce que le RAG ? • Comment AWS Bedrock vous permet de déployer un agent à la fois scalable, fiable et interne • Use case RH - de l’idée au POC en production ### Pourquoi mettre en place un agent conversationnel privé devient stratégique pour l’entreprise ? Les entreprises ont de plus en plus d’outils. Trop, parfois. Une simple information peut se cacher dans un fichier, une base interne, un ticket ou une doc oubliée. Résultat : on peut perdre beaucoup de temps. Un agent conversationnel bien conçu règle ce problème. Il comprend une question posée naturellement, et va chercher la bonne réponse, dans les bonnes sources. Sans avoir à cliquer partout et sans avoir à savoir où chercher. Mais pour que cela fonctionne, il faut que cet agent connaisse l’entreprise : son vocabulaire, ses métiers, ses outils, ses documents. Un assistant générique tel que ChatGPT ne peut pas faire ceci. En effet, il ne comprend pas le contexte. Et surtout, il ne garantit pas que vos données restent entre vos murs. C’est là que les solutions privées prennent tout leur sens comme celles qu’on peut construire avec les plateformes cloud tel que AWS. L’agent est déployé dans votre environnement, il apprend ce que vous décidez de lui apprendre, et surtout, aucune donnée ne sort. Les agents conversationnels ne sont pas de simples outils. En effet, ce sont de véritables leviers pour gagner du temps, réduire les frictions, et rendre chaque équipe plus autonome, au quotidien. ### Qu’est ce que le RAG (Retrieval-Augmented Generation) ? Lorsque l’on pense à l’IA générative, on pense souvent à des outils comme ChatGPT, Claude, Gemini etc. Ces modèles sont capables de formuler des réponses claires, parfois même bluffantes. Mais il y a un problème : ils n’ont pas toujours accès aux bonnes informations. En effet, ils répondent en s’appuyant sur ce qu’ils ont appris pendant leur entraînement et ça s’arrête souvent à une certaine date. Par conséquent, cela peut poser des problèmes car ils peuvent halluciner, donner des réponses obsolètes ou simplement inexactes pour un cas d’usage métier. C’est là qu’intervient le RAG, pour Retrieval-Augmented Generation. Le principe est simple : avant de répondre, l’agent va chercher les bonnes infos dans une base de connaissances. Puis il s’appuie sur ces infos pour générer sa réponse. Le tableau ci-dessous résume ce qu’apporte le RAG par rapport à une génération classique d’un modèle tel que Chat GTP : Avant de répondre, l’agent va d’abord chercher dans vos contenus, i.e., contrats, FAQ internes, manuels techniques, documents RH se trouvant dans la base de connaissance. Puis il s’appuie sur ce qu’il trouve pour formuler une réponse claire et ciblée. Concrètement, ça change tout ! Moins de réponses 'inventées', car le modèle s’appuie sur des sources que vous maîtrisez. Des infos justes et à jour, même si le document a changé hier ainsi qu’un langage métier, adapté à votre contexte, vos règles et vos sujets. Pas de réentraînement à chaque mise à jour : vous remplacez un fichier, l’agent s’ajuste. ### Comment déployer un agent conversationnel sur AWS avec une architecture RAG ? Maintenant que l’on comprend mieux ce qu’est un agent conversationnel et pourquoi le RAG est essentiel, passons à quelque chose de plus concret : comment créer un tel agent ? Pour ce faire nous allons choisir la plateforme cloud AWS. ### Pourquoi AWS Bedrock est un bon choix ? Déployer un agent conversationnel, ce n’est pas juste choisir un modèle. C’est aussi penser à la sécurité, à l’évolutivité, à l’intégration, et à la gouvernance. Sur tous ces aspects, AWS Bedrock s’impose comme une solution solide : Pas besoin de gérer les modèles vous-même : Avec Bedrock, vous accédez à plusieurs modèles (Anthropic, Meta, Mistral, etc.) via API. Aucun besoin de déployer d’infrastructure, de gérer du GPU, ou de scaler manuellement. C’est idéal pour prototyper rapidement… et industrialiser ensuite. Les données restent chez vous : Les prompts, les documents et les logs sont traités dans votre environnement AWS. Rien n’est stocké, rien n’est réutilisé pour entraîner les modèles. C’est un vrai plus en matière de RGPD et de confidentialité métier. L’agent s’intègre nativement à votre système : IAM, S3, Lambda, EventBridge, CloudWatch… toutes ces briques AWS peuvent être utilisées pour tracer les appels, automatiser les flux et maîtriser les accès. L’agent devient un composant de votre SI, et non une boîte noire. Une architecture pensée pour l’évolution : Vous pouvez commencer petit (un cas d’usage interne, une FAQ intelligente), puis ajouter de la mémoire, des accès métiers ou de nouvelles sources de données sans tout casser. L’infrastructure est déjà prête pour monter en charge. Une fois le cas d’usage clarifié et les données préparées, il est temps de passer à la conception technique. Pour garantir performance, robustesse et évolutivité, l’agent conversationnel doit s’appuyer sur une architecture bien structurée, composée de quatre blocs complémentaires. Chacun joue un rôle spécifique, et c’est leur combinaison qui permet à l’agent de fonctionner de manière fluide, sécurisée, et pleinement intégrée à votre environnement, ici, AWS. ### L’architecture repose sur 4 grands blocs fonctionnels : - L’interface utilisateur (frontend): C’est le point d’entrée, là où l’utilisateur pose sa question. Cela peut être un chat intégré à un site web, une interface sur l’intranet, ou encore des outils comme Slack ou Microsoft Teams. - Pipeline de traitement des données : C’est le cœur du traitement des données. Ce bloc gère l’ingestion, la transformation et le nettoyage des fichiers métiers (PDF, Excel, exports de CRM, etc.). Une fois préparées, les données sont stockées dans une landing zone (souvent sur Amazon S3, avec un format comme Apache Iceberg) pour être exploitées ultérieurement. - Le moteur RAG : Ce composant extrait les contenus pertinents depuis la landing zone, les découpe, les vectorise (via un modèle d’embedding), puis les stocke dans une base vectorielle (ici, Amazon OpenSearch Serverless). Cette base devient notre mémoire métier à laquelle le LLM pourra se connecter. - L’agent conversationnel : C’est le visage de l’IA. Il est orchestré via Amazon Bedrock, configuré pour interagir avec le LLM et consulter la base vectorielle lorsque c’est nécessaire. L’agent comprend les requêtes en langage naturel, récupère les bons documents via la recherche augmentée (RAG), et génère une réponse fiable et contextualisée. Cette architecture vous apporte des garanties concrètes à plusieurs niveaux. D’abord, elle assure une scalabilité automatique, effectivement, les services managés tels que Lambda, API Gateway ou Bedrock s’adaptent dynamiquement à la charge, sans nécessiter de gestion manuelle de l’infrastructure. Elle garantit également une sécurité native, grâce à un contrôle rigoureux des accès via IAM et à un strict confinement des données au sein de votre environnement AWS, ce qui assure confidentialité et conformité. Enfin, son extensibilité vous permet d’enrichir facilement l’architecture avec de nouvelles règles métiers comme des filtres, une mémoire d’historique, des validations ou d’ajouter des sources de données, sans avoir à remettre en question le socle existant. Elle répond ainsi aux principales exigences des systèmes d’information modernes : des performances élevées, même en cas de montée en charge, une protection des données conforme au RGPD , et une traçabilité complète, facilitant les audits et le monitoring. En résumé, vous gardez la maîtrise de vos données et de votre infrastructure, tout en tirant parti de la puissance d’un agent conversationnel parfaitement aligné sur vos cas d’usage métier. ### Use case : créer un agent pour accompagner les équipes RH Contexte Une entreprise souhaiterait aider son service RH à mieux gérer les questions internes. Les sujets sont classiques : congés, télétravail, formations, etc. Plutôt que de répondre à chaque mail ou message, l’idée est de mettre en place un agent capable de donner des réponses simples, à partir des documents existants. Stockage des documents Tous les fichiers RH sont déposés dans un bucket Amazon S3. Ça peut être des PDF, des fichiers Word ou Excel. L’important, c’est qu’ils soient à jour et bien nommés. Indexation des contenus Un traitement automatique lit les documents, extrait le texte et le découpe en petits blocs. Chaque bloc est transformé en un vecteur numérique à l’aide d’un modèle comme: multi-qa-mpnet-base-dot-v1. Ces vecteurs sont ensuite enregistrés dans Amazon OpenSearch Serverless, qui devient la base de connaissance de l’agent. Configuration de l’agent L’agent est créé avec Amazon Bedrock. On choisit un modèle LLM, comme Claude, Titan ou Mistral. On lui donne des instructions claires : « Tu es un assistant RH. Tu dois t’appuyer uniquement sur les documents internes. Si tu ne trouves pas la réponse, tu peux faire une recherche sur Internet. » Ces consignes permettent de cadrer le comportement de l’agent dès le départ. Déploiement L’agent est exposé via une API Gateway. On peut aussi l’intégrer directement dans une messagerie interne comme Slack, ou dans une app web RH déjà existante. ### Exemple d’interaction avec l’agent : ### Notre vison : Les agents conversationnels, autrefois réservés aux grandes entreprises, sont désormais accessibles à tous. Ils transforment en profondeur notre manière d’accéder à l’information et apportent une réelle valeur au quotidien des collaborateurs et ce, quelle que soit la taille de l’organisation. Qu’il s’agisse de gagner du temps, de réduire la charge de travail liée à des demandes répétitives, ou encore de centraliser la connaissance métier, un agent conversationnel bien conçu devient un véritable levier pour l’organisation. La solution proposée, basée sur une architecture modulaire sur AWS, démontre qu’il est possible de passer de l’ingestion brute des documents jusqu’à l’interaction intelligente avec un agent minutieusement configuré sur Amazon Bedrock. En intégrant un moteur RAG, l’agent s’appuie sur des sources fiables et actualisées, réduisant ainsi le risque d’hallucination des modèles LLM classiques tout en offrant une adaptabilité parfaite aux besoins métiers spécifiques. Cependant, à mesure que l’IA générative évolue, il devient nécessaire de nuancer l’enthousiasme autour du RAG. La taille des prompts pouvant désormais dépasser plusieurs dizaines de milliers de tokens, et le coût des appels API ayant significativement baissé, certaines situations peuvent justifier une approche plus directe. Injecter le contexte métier dans un prompt bien structuré, sans pipeline RAG complexe, peut s’avérer plus simple, plus rapide, et parfois plus économique. Autrement dit, RAG n’est pas toujours la réponse idéale : tout dépend du volume, de la fréquence des requêtes, et du niveau de personnalisation requis. Cette réflexion ouvre la voie à un questionnement plus large : comment orchestrer efficacement les briques d’IA générative au sein d’un système d’information ? Et surtout, quel rôle joue le data engineering dans cette nouvelle équation ? Pour aller plus loin, découvrez notre article : GenAI : [le rôle stratégique du Data Engineering](../../articles/genai-le-role-strategique-du-data-engineering/index.html) --- ## GenAI : le rôle stratégique du Data Engineering URL : https://modeo.ai/articles/genai-le-role-strategique-du-data-engineering > Pourquoi le Data Engineering est indispensable à la GenAI : RAG, bases vectorielles, agents. Le guide Modeo pour réussir vos projets d'IA générative. Dans ce guide, nous vous proposons de clarifier les liens entre Data Engineering et IA Engineering, en montrant pourquoi leur synergie est essentielle à la réussite des projets en intelligence artificielle générative (GenAI). À travers une exploration des concepts clés de la GenAI, comme le RAG, les bases de données vectorielles, les agents, ou encore le LLMOps, il vise à rendre accessibles les fondamentaux techniques qui sous-tendent ces nouvelles architectures. Depuis la fin de l’année 2022 et l’arrivée de ChatGPT, l’intelligence artificielle générative (GenAI) a profondément transformé le paysage technologique. Au cœur de cette révolution, les LLMs (Large Language Models), des modèles d’intelligence artificielle entraînés sur de vastes corpus de textes pour comprendre et générer du langage naturel, sont devenus les moteurs des nouvelles applications d’IA. Leur capacité à traiter, résumer, reformuler ou dialoguer avec des utilisateurs ouvre des opportunités immenses… mais repose sur un prérequis souvent négligé : la qualité des données. Car derrière chaque application GenAI performante, se cache un travail fondamental de Data Engineering. Sans une architecture de données solide, fiable et bien pensée, les LLMs ne peuvent ni apprendre efficacement, ni répondre de manière pertinente. Le Data Engineering n’est pas un support technique secondaire, c’est la fondation même de l’AI Engineering moderne. ### Pour commencer, posons les bases : qu’est-ce que le Data Engineering ? Le Data Engineering constitue la colonne vertébrale technique de toute stratégie data moderne. Il regroupe l’ensemble des pratiques, outils et infrastructures qui permettent de collecter, transformer, stocker et rendre accessibles les données de manière fiable, scalable et exploitable que ce soit pour l’analyse, les modèles d’IA ou les applications métier. La Modern Data Platform incarne pleinement cette vision : un socle technologique modulaire, composé de briques interopérables (ingestion, stockage, transformation, activation, orchestration et gouvernance), conçu pour traiter la donnée comme un véritable actif stratégique et en maximiser la valeur à chaque étape du cycle de vie. Tout commence par l’ingestion, c'est-à-dire la collecte de données issues de de sources variées: outils SaaS, APIs, base de données, applications métier etc. Ces données brutes sont ensuite stockées dans environnements adaptés, selon leur format et leur niveau de structuration, que ça soit dans une data warehouse, data lake ou système hybride. Vient ensuite la transformation, étape clé pour nettoyer, standardiser et enrichir les données. C’est ce qui permet de passer d’un ensemble hétérogène de fichiers à une information claire, prête à être analysée. L’orchestration des traitements granit, quant à elle que les pipelines tournent de façon fluide, et automatisée. Mais rendre la données disponible ne suffit pas, encore faut-il l'activer, à travers des outils de visualisation, de reporting, ou même des modèles de machine learning intégrés directement dans les produits ou les workflows métier. Enfin, l’ensemble repose sur une gouvernance solide : contrôler qui accède à quoi, garantir la sécurité, la conformité, et la qualité sur la durée. Pour un aperçu détaillé de cette architecture et des outils associés, nous vous recommandons de lire l'article très complet de notre COO et Data Engineer, Matthieu Willot "[Modern Data Platform &, Stack : Les fondamentaux à connaître pour exploiter vos données avec efficacité"](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html) ### Abordons maintenant l’IA Engineering : la partie visible de l’édifice Si le Data Engineering pose les fondations, l’IA engineering se considère comme l’édifice visible: celui des modèles en production, intègre aux produits, aux services, et aux usages réels. Si la Data Engineering pose les fondations, l’IA Engineering se considère comme la partie visible de l'iceberg : celui des modèles en production, intégré aux produits, aux services, et aux usages réels. Ce domaine va bien au-delà de l'entraînement de modèles. Il s'agit de les déployer dans un environnement complexe, de les faire fonctionner de manière fiable à grande échelle et surtout de les rendre utiles et exploitables par les utilisateurs finaux. ### Concrètement, l’IA Engineering s’organise autour de plusieurs dimensions clés : • Le déploiement des modèles : Une fois le modèle entraîné, il faut le rendre accessible, sur un serveur, dans le cloud, via une API, etc. Ce processus demande de gérer des questions de versioning, de sécurité, de scalabilité, et souvent d’automatisation. Voici quelques exemples de modèle couramment déployées : - LLMs comme Mistral 7B, Llama 3, ou Claude pour des cas d’usages en langage naturel (chatbots, résumé automatique, génération de contenu métier etc.) - Modèles de computer vision pour la détection d’objets dans des images (ex: YOLO v8, SAM) - Modèles de classification ou recommandations embarquées des systèmes temps réel (fraude, scoring, e-commerce, etc.) • L’intégration des les applications métier : Un modèle, aussi performant soit-il, n’a de valeur que s’il est bien intégré dans les flux métier. Cela peut se traduire par une recommandation affichée dans une application e-commerce, ou une alerte dans un outil de gestion des risques. Cette phase nécessite une collaboration étroite entre les équipes data, produit, UX et développement. • Le serving à grande échelle : C’est l’un des défis techniques majeurs de l’AI Engineering : comment faire en sorte qu’un modèle réponde en quelques millisecondes à des centaines, voire des milliers de requêtes simultanées ? Assurer cette performance en production implique la mise en place de solutions d’inférence optimisées, basées sur : - Des architectures distribuées capables de gérer la charge, - Des systèmes de cache pour éviter les calculs redondants, - L’optimisation des ressources matérielles (GPU/CPU) Le serving ne se limite pas à exposer un modèle via une API il s’agit de garantir scalabilité, résilience et temps de réponse faible, tout en gardant un contrôle sur les coûts d'infrastructure. • Le réentraînement des modèles Déployer un modèle, ce n'est jamais une fin en soi. Avec le temps, les données évoluent, les comportements changent, et les modèles peuvent perdre en pertinence. Le ré-entraînement permet de les adapter en continu, en intégrant de nouveaux jeux de données, des retours utilisateurs ou des spécifiques apparus après la mise en production. Il peut s’agir d’un fine-tuning léger, d’un entraînement incrémental, ou d’une remise à plat complète du modèle. Cette étape est essentielle pour assurer la pertinence des résultats et la valeur métier des systèmes IA dans le temps. ### Le rôle stratégique du Data Engineering dans l’IA Engineering On dit souvent qu’un modèle ne vaut que par la qualité de ses données et cela s’applique d’autant plus aux modèles génératifs. Même les LLMs les plus avancés produisent des résultats approximatifs, voire inutilisables, s’ils ne sont pas alimentés par des données fiables, structurées et pertinentes. Ce que l’on voit, ce sont les modèles et leurs réponses impressionnantes. Ce que l’on voit moins, ce sont les fondations data qui les rendent possibles. Pour fonctionner de manière efficace et utile, une IA a besoin de données : - Propres, sans erreurs, ni doublons et logiques. - Disponible rapidement et en continu. - Pertinentes, c’est-à-dire en lien direct alignées avec les cas d’usage métiers. C’est là précisément ce que le data engineering intervient, souvent dans l’ombre, mais toujours en amont. Des pipelines bien pensés = Des IA qui tiennent la route ! Par conséquent, les pipelines de données sont l’épine dorsale d’un projet GenIA, ils doivent être : - Fiables, capables de gérer les erreurs et interruptions rapidement. - Scalables, pour suivre automatiquement la montée en charge. - Faciles à maintenir, avec des bonnes pratiques de software engineering, DevOps. Sans cette rigueur en data engineering, impossible de faire tourner des IA génératives en production avec les niveaux de qualité, de performance et de sécurité exigés aujourd’hui. Quels sont les concepts clé de la Gen IA à maîtriser ? Dans l’univers des applications basées sur les LLMs (Large Language Models) certaines notions reviennent souvent, les connaître c’est bien, mais comprendre comment ils fonctionnent et quand/comment les utiliser c’est mieux ! LLMs Les LLMs ou Large Language Model, sont des modèles d’IA entraînés sur d’immenses volumes de texte, leur force, comprendre générer et manipuler du langage naturel avec une fluidité impressionnante. RAG Une technique qui permet à un LLM d’aller chercher de l’info dans une base externe avant de générer une réponse. Idéal pour éviter les hallucinations, et enrichir les réponses avec du contenu métier, Mais pour que ça marche, il faut un système de recherche sémantique bien alimenté, encore une fois un enjeu très important de Data Engineering, que l'on ne voit pas forcément en première ligne. VectorDB C’est une sorte de base de données mais pour les vecteurs, ces bases stockent des embeddings (vecteurs numériques) permettant de recherches intelligentes, basées sur la significations plutôt que les mot-clés, leur performance dépend fortement de la qualité des pipelines d’ingestion et d’indexation, ce qui constitue la base d’un projet de data eng. Embeddings Ils traduisent des contenus comme du texte ou des images en vecteurs numériques, pour en extraire du sens, Leur bonne gestion nécessite une solide compréhension des données sources et des méthodes de transformations. Agents/Chains Les agents sont des IA capables d'exécuter plusieurs actions pour résoudre un problème. les chaînes orchestrent les différentes étapes entre ces actions en faisant passer l’information d’un bloc à un autre (modèle, recherche, formatage…). Model Completion Pattern Le MCP est un cadre d’architecture pour structurer l’appel à un LLM de bout en bout: formulation de la requête, appel au modèle, post-traitement de la réponse, mise en cache, etc. Il agit comme une couche d’abstraction entre le modèle d’IA et son environnement d’exécution. Il permet au modèle de s’adapter finement à des cas d’usages bien précis Ce pattern renforce la stabilité, la maintenabilité et la traçabilité des applications GenIA, en structurant chaque étape du traitement d’une requête de manière claire et modulaire. “Use Case” concret : un bot GenAI personnalisé connecté à une plateforme de données sur AWS Notre équipe a développé un bot GenIA, interne pour faciliter l’accès à la documentation interne de la boite, et automatiser certaines tâches répétitives, avec pour objectifs : - Réduire le temps passé à chercher de l’information. - Offrir une assistance continue aux consultants. - Garantir un usage sécurisé et confidentiel des données sensibles. Côté données, nous avons utilisé AWS comme un environnement Cloud, en mettant tous les documents dans Amazon S3, métadonnées cataloguées avec AWS Glue, et données structurées en format “Apache Iceberg”. Du côté traitement, nous avons mis en place un pipeline d’ingestion pour récupérer les documents, en extraire les informations clés, puis les convertir en vecteurs numériques. Ces vecteurs sont ensuite indexés pour former une base de données vectorielle, qui sert de référentiel de connaissances à notre bot GenAI. En ce qui concerne la partie génération de réponse, nous avons utilisé des LLMs capables de comprendre les requêtes et de s’appuyer sur la base vectorielle existante. Ce fonctionne de type RAG déjà mentionné précédemment, permet d’éviter les réponses approximatives en fournissant des réponses alignées par rapport au référentiel métier. Donc au final, nous avons pu développer un bot intelligent, rapide, fiable et sécurisé, qui aide les équipes techniques et métiers à retrouver l’information, en quelques secondes et libère un temps précieux pour les tâches à plus forte valeur ajoutée. ### Outils et technos à connaître pour réussir à créer cette synergie : Mettre en place une synergie entre Data et IA Engineering, ça commence par le bon outillage. Ce tableau résume les briques essentielles à connaître, en fonction de leur rôle dans la pipeline de traitement des données et leur valeur ajoutée pour les cas d’usage GenAI. ### Donc en résumé de ce guide : L’IA générative fascine, transforme et redéfinit les usages. Mais derrière chaque réponse fluide d’un LLM se cache un travail de l’ombre, précis et rigoureux : celui des Data Engineers. Ce sont eux qui rendent les données accessibles, fiables, structurées, sans cela, aucun modèle, aussi puissant soit-il, ne peut fonctionner efficacement. Sans données, pas d’intelligence. Et sans architecture de données, pas d’industrialisation possible. Les modèles restent alors confinés aux notebooks, incapables de répondre à des enjeux métiers concrets. À l’inverse, avec une infrastructure data bien pensée, l’IA devient un levier d’action réel, intégré dans les produits, les services, et les processus quotidiens. Le futur de la GenAI dépend autant de l'algorithme que de la donnée. Et ce sont celles et ceux qui maîtrisent cette double compétence -comprendre les modèles et savoir les nourrir - qui auront une longueur d’avance. Alors, que faire aujourd’hui ? Tester, se former, expérimenter. C’est en explorant les outils, en comprenant les architectures, et en manipulant concrètement la donnée que l’on devient acteur de cette transformation. L’IA générative n’est pas une mode : c’est un changement de paradigme. Et ceux qui l’embrassent dès maintenant seront les architectes des solutions de demain. Pour aller plus loin : Visionnez notre webinar 'Modeo Data talks' sur notre chaine avec des experts incontournables en la matière ! ### Demandez nous ici votre guide gratuit : Réussissez vos projets Data &, IA grâce à la Modern Data Stack --- ## Piloter une équipe data URL : https://modeo.ai/articles/piloter-une-equipe-data > Stratégie, roadmap, relation avec les métiers : les clés pour piloter une équipe data et créer de la valeur business, avec Quentin de Carné. ### Piloter une équipe data : entre stratégie, métiers et valeur business Le temps d’un webinar riche et sans langue de bois, Matthieu Rousseau a reçu Quentin de Carné pour décortiquer les enjeux du pilotage d’une équipe data. Une discussion business et opérationnelle, qui va bien au-delà des aspects techniques. Voici quelques points clés à retenir : #### Pourquoi fait-on de la data ? «La mission d’une équipe data, ce n’est pas de faire du code pour du code. C’est de simplifier des sujets complexes, de les rendre actionnables pour le métier, afin de générer du revenu, automatiser des tâches ou optimiser des coûts.» Dès les premières minutes, Quentin rappelle l’essentiel : la data est là pour servir le métier. Encore faut-il que les équipes soient bien positionnées dans l’organigramme. Rattachée à la tech, au marketing, à la finance ? Tout dépend du contexte et de la maturité de l’entreprise. Le rôle du Head of Data est alors de jouer le traducteur entre technique et opérationnel. #### Structurer une équipe data efficace Un Head of Data peut démarrer efficacement avec une petite équipe, souvent un binôme analyste + head. L’objectif initial est de livrer de la valeur rapidement avec des cas d’usage concrets, avant de penser à industrialiser. «Ce n’est pas la taille qui compte, c’est l’impact. Une CDP (Customer Data Platform) bien branchée peut transformer l’autonomie du CRM. Et ça, c’est mesurable.» Parmi les réussites citées : l’implémentation d’une CDP autonome pour les équipes marketing chez Bien’ici ou encore l’automatisation d’actions commerciales pilotées via SQL. #### Construire une roadmap data : prioriser pour convaincre «Pour embarquer le Comex, il faut des quick wins. Des projets concrets qui apportent de la valeur métier en quelques semaines. C’est cette confiance qui autorise ensuite les projets plus lourds.» La construction d’une roadmap repose sur des interviews métiers, un cadrage de leurs pain points et une priorisation claire. Le [Meetric Tree](https://count.co/blog/intro-to-metric-trees) est évoqué comme outil puissant pour remonter de l’objectif business aux métriques pilotables. #### Mesurer l’impact d’un projet data : le ROI reste complexe Pas de solution miracle pour estimer précisément le ROI d’un projet data, surtout sur la stack. L’important reste la valeur perçue : gain de temps, autonomie, simplification, productivité. «La data est l’équipe qui mesure… mais qui a parfois du mal à mesurer sa propre performance.» #### Modernisation de la stack data : buy ou build ? Quand vient l’heure de moderniser la plateforme data, l’argumentaire business doit être clair : «On ne peut plus répondre aux besoins sans une refonte.» Une plateforme data moderne est un levier de scalabilité et non une coquetterie d’ingénieurs. « C’est le pourquoi qui doit guider la décision. Pas juste l’envie de tout reconstruire. » #### Self BI &, autonomie métier : entre vision et réalité Si l’ambition d’une approche Self BI est dans toutes les têtes, elle doit s’accompagner de catalogues de données, de définitions partagées et de processus robustes. L’illusion de l’autonomie peut vite tourner au chaos sans gouvernance claire. « Trop de dashboards, pas assez de vérité commune. Une self BI sans catalogue, c’est ouvrir la porte à toutes les incohérences. » #### Ce qui fait la réussite (ou l’échec) d’un projet data - ✔ Clarté du besoin métier - ✔ Bonne communication avec les sponsors - ✔ Dé-risquage technique et organisationnel - ❌ Trop d'effet tunnel - ❌ Stack instable ou projets trop techniques sans finalité claire #### Replay disponible 👉 Vous souhaitez aller plus loin et écouter la conversation en entier ? Retrouvez le replay complet du webinar sur notre [chaîne YouTube](https://www.youtube.com/watch?v=7W9ZzGMT658&ab_channel=Modeo) et découvrez d’autres insights pour structurer, piloter et valoriser vos projets data. ##### Et pour nous contacter ou prendre un RDV avec un consultant Modeo, c'est ici ! --- ## Data FinOps : Maitriser vos coûts cloud avec Modeo URL : https://modeo.ai/articles/webinar-finops > La Data FinOps offre aux organisations une visibilité précise sur les coûts réels des systèmes Data et sur leur évolution **Si vous avez récemment assisté au Webinar Datanosco animé par Matthieu Rousseau, CEO et Ismael Goulani, CTO de Modeo, vous avez probablement entendu parler de la Data FinOps. Mais qu'est-ce que représente réellement l'intégration de la Data Finops pour une organisation Data au sein d'une entreprise ?** ### Tout d'abord, qu'est-ce que la Data FinOps ? La FinOps -contraction de finance et opérations- est l'approche permettant de monitorer et optimiser les coûts cloud. La FinOps est l'ensemble des actions et méthodologies visant à comprendre et optimiser les coûts liés au cloud computing. Appliquée aux données, la Data FinOps permet de maîtriser les dépenses inhérentes aux plateformes data massivement déployées dans le cloud. De ce fait, elle encourage la coopération entre IT et métiers en y ajoutant une dimension financière. **Appliquée aux données massivement stockées et traitées dans le cloud, la Data FinOps permet une maîtrise pérenne des dépenses tout au long du cycle de vie d'un projet Data/IA.** ### Pourquoi intégrer la Data FinOps dans une Data Platform ? Avec la multiplication des volumes de données et l'essor de l'intelligence artificielle, les coûts cloud des [Data Platforms](../../articles/modern-data-platform-definition-entreprise/index.html) explosent de manière incontrôlable, surtout si aucune approche de maîtrise n'est mise en place. La Data FinOps apporte**visibilité, contrôle et optimisation continue**des coûts tout au long du cycle de vie des données, sécurisant ainsi le budget alloué aux projets data/IA et évitant le gaspillage. **Cette approche offre aux organisations une visibilité précise sur les coûts réels, leur évolution et les leviers d'optimisation possibles à chaque étape: ingestion, stockage, traitement, modélisation, inférence.** ### Le contenu de notre webinar sur la Data FinOps #### Les 5 piliers de conception Data FinOps • Choix initiaux d'architectures limitant les coûts (serveurs dimensionnés, stockage adapté, puissance de calcul adaptative...) • Suivi rigoureux des bonnes pratiques opérationnelles (modèles incrémentaux, partitionnement, caching, auto-scaling...) • Règles d'accès aux données exposant uniquement celles nécessaires aux utilisateurs • Cadre d'archivage/historisation pérennisant l'accès aux données historiques • Automatisation poussée des tâches techniques et FinOps #### Les 5 piliers de gouvernance Data FinOps • Tableaux de bord temps réel analysant les coûts par entité métier • Gestion centralisée des autorisations d'accès cloud • Processus budgétaire intégrant alertes précoces et respect de quotas • Culture partagée des bonnes pratiques entre équipes • Automatisation continue des processus financiers et techniques #### Les principes culturels de la Data FinOps • Collaboration cross-fonctionnelle entre équipes data, infrastructure et métiers • Responsabilisation de tous sur la maîtrise financière des projets • Évolutivité des systèmes permettant croissance et innovation #### Les métriques clés pour mesurer la réussite Data FinOps • Coût par service, activité métier ou base de données • Taux d'utilisation réel des ressources provisionnées • Ecarts et variations par rapport au budget prévisionnel • Rapidité de détection d'anomalies dans les coûts • Niveau de maturité FinOps atteint selon les meilleures pratiques **Adopter la culture et les principes Data FinOps apporte visibilité et pérennité budgétaire, accélère la transformation numérique des entreprises et renforce leur compétitivité en maîtrisant les coûts data sur le long terme.** ##### Accédez au Webinar en ligne : ##### Vous souhaitez en discuter et partager vos connaissance avec nous ? ###### Rejoignez notre Github dédié ! [https://github.com/Modeo-Data/data-engineer-finops-greenops](https://github.com/Modeo-Data/data-engineer-finops-greenops) --- ## Qu'est-ce qu'une Modern Data Platform ? URL : https://modeo.ai/articles/modern-data-platform-definition-entreprise > Comprendre la Modern Data Platform : définition, composants, avantages et comment la construire. Tout ce que votre entreprise doit savoir avant de se lancer. ### Définition : qu'est-ce qu'une Modern Data Platform ? Une Modern Data Platform est un ensemble de composants technologiques et organisationnels qui permettent à une entreprise de collecter, stocker, transformer, gouverner et activer ses données à grande échelle, de manière fiable et évolutive. Elle se distingue des architectures data traditionnelles par plusieurs caractéristiques fondamentales : - **Nativement cloud :** les données sont stockées et traitées dans le cloud (BigQuery, Snowflake, Databricks), ce qui permet une scalabilité quasi illimitée. - **Orientée code :** les transformations sont définies en code (SQL + DBT), versionnées dans Git et testées comme du code applicatif. - **Automatisée et orchestrée :** les pipelines s'exécutent automatiquement via Airflow ou Prefect. - **Observable :** la qualité des données est monitorée en continu (Elementary, Great Expectations). - **Self-service :** les équipes métier peuvent accéder aux données sans dépendance permanente aux équipes techniques. ### Les composants clés d'une Modern Data Platform #### La couche d'ingestion Elle permet de collecter les données depuis toutes les sources : bases de données opérationnelles, APIs, fichiers, flux temps réel. Les outils de référence sont Fivetran, Airbyte, DLT Hub ou des pipelines custom en Python. #### Le stockage analytique C'est le coeur de la plateforme. Les solutions leaders en 2026 sont Snowflake, BigQuery et Databricks. Modeo maîtrise les trois et choisit selon le contexte de chaque client. #### La couche de transformation DBT s'est imposé comme le standard de la transformation de données en SQL. Il permet de définir des modèles de données, de les tester automatiquement et de générer une documentation de linéage. Modeo l'utilise systématiquement dans ses projets. #### L'orchestration Apache Airflow est l'outil d'orchestration de référence pour planifier et monitorer l'exécution des pipelines. #### La gouvernance et la qualité des données Les outils de data quality (Elementary, Great Expectations) permettent de détecter les anomalies avant qu'elles n'impactent les utilisateurs. #### La couche analytics et activation C'est la couche visible par les utilisateurs finaux : dashboards BI, APIs analytiques, copilotes IA qui permettent d'interroger les données en langage naturel. ### Pourquoi votre entreprise a besoin d'une Modern Data Platform - **Mettre fin aux data silos :** la Modern Data Platform centralise les données dans un référentiel unique, fiable et accessible. - **Accélérer les décisions :** Modeo l'a prouvé chez un client fintech : réduction du temps de décision de 93 %, de 48 heures à 3 heures. - **Créer des fondations pour l'IA :** sans Modern Data Platform, l'IA reste au stade du POC. - **Fiabiliser la donnée :** la confiance dans la donnée augmente, ce qui améliore l'adoption des outils analytiques. ### Comment Modeo construit une Modern Data Platform Modeo a développé une méthodologie éprouvée en plus de 100 projets : audit d'architecture, définition de l'architecture cible, construction des pipelines, mise en place du DataOps, livraison des usages, accompagnement à l'adoption. Pour découvrir les agences capables de vous accompagner : [Construire ou moderniser sa data platform](../../enjeux/construire-ou-moderniser-ma-data-platform.html). --- ## Interflora : transformation marketing réussie grâce à la CDP URL : https://modeo.ai/articles/interflora-cdp-marketing > Modeo dévoile comment Interflora a optimisé son marketing grâce à une CDP : segmentation rapide, activation des audiences et meilleures performances... ---- ### Nos ressources : #### Demander votre Guide Modeo x Dinmo : Customer Platform &, IA #### Webinar Google x Dinmo x Modeo : The futur of CDP is Composable #### MasterClass DataOps : Comment construire votre stratégie et votre équipe ? --- Et pour être accompagné dans votre projet : Conception de Data Platforms by Modeo, n'hésitez pas à nous contacter [ici !](../../contact.html) Activer ou demander une démo de votre future CDP avec[Dinmo](https://www.dinmo.com/fr/contact/) --- ## Aider les entreprises à tirer parti de leurs données URL : https://modeo.ai/articles/aider-les-entreprises-a-optimiser-lexploitation-des-donnees > Modeo propose des solutions sur-mesure et une approche orientée métier pour accélérer l'adoption des données dans les entreprises. Pour les entreprises, le grand enjeu est-il désormais la bonne exploitation des données ? Les entreprises ont atteint un niveau de maturité assez élevé concernant le traitement de la donnée. Le grand enjeu du moment est son exploitation, notamment au niveau des métiers pour qui la bonne utilisation de la data reste un sujet compliqué. Dans le domaine, quelles sont les bonnes pratiques à mettre en place ? Avant même de produire une donnée, il est impératif de bien comprendre le besoin qui doit être satisfait. De cette manière, en réfléchissant en amont, les équipes techniques vont être en mesure de délivrer la donnée (complète, au bon format, etc.) qui va réellement servir aux équipes métiers. Deuxième élément : Il est nécessaire de passer du temps avec les équipes métiers afin de vulgariser le sujet. Il faut leur montrer comment la plateforme de données et les assets créés fonctionnent, prendre en compte leurs retours, et faire évoluer les solutions data en fonction de ces derniers. Enfin, il est indispensable de s’équiper des outils adéquats qui vont permettre d’assurer le suivi d’utilisation de la donnée. Cela signifie de pouvoir suivre en temps réel qui l’utilise et comment. Ce type d’informations aide à mieux répondre aux demandes des métiers. Que propose, alors, Modeo ? Chez Modeo, nous sommes passionnés par les données et notre mission consiste à aider nos clients à exploiter leur potentiel en utilisant les meilleures pratiques de gestion des données. En tant que Data Engineers, nous sommes spécialisés dans le conseil, la conception et la mise en place d’architectures de données solides pour permettre une analyse et une interprétation précises. Parallèlement, nous avons développé Stash® qui est le fruit de notre recherche et développement interne. Notre outil répond à un besoin crucial que nous avons identifié chez nos clients lors de nos missions de conseil : faciliter l’adoption des outils auprès des équipes métiers. Stash offre une vue d’ensemble sur l’utilisation des données, y compris leur coût et leur impact carbone, ce qui en fait l’outil essentiel pour une exploitation efficace des données en entreprise. Cette approche nous a permis de développer une solution unique sur le marché de la data, qui a été récompensée par le prix ‘Solutions Innovantes’ lors de la nuit de la Data le 6 février 2023. Cette distinction témoigne de notre engagement envers l’innovation et l’excellence, et nous sommes fiers de proposer un outil de pointe à nos clients. Quelles catégories de sociétés constituent-elles votre cible ? Nous visons les scale-up et les grands groupes. Ces entreprises possèdent, en effet, une réelle maturité concernant le sujet des données. Nous sommes actuellement en discussion avec plusieurs sociétés du CAC 40 qui sont intéressées par notre solution. Nous sommes donc en phase active de développement et prévoyons de procéder à une levée de fonds d’ici à la fin de l’année 2023. Nous avons pour ambition de faire de Modeo une référence incontournable sur le marché de la donnée. Avec des projets à l’international ? Nos solutions sont entièrement exportables. Nous visons, en premier lieu, l’Europe avec les marchés allemand et britannique. Dans un deuxième temps, nous partirons à la conquête du marché américain. [sources: Forbes.fr](https://www.forbes.fr/) --- ## BigQuery | Guide complet sur le data warehouse de Google URL : https://modeo.ai/articles/bigquery-overview > BigQuery est le datawarehouse phare de Google Cloud Platform, flexible et puissant. Quels sont ses avantages et fonctionnalités ? ### BigQuery : un service de data warehouse ? BigQuery est considéré comme un data warehouse incontournable en 2024. En premier lieu, il convient de définir ce qu’est un data warehouse. Le data warehouse est aujourd’hui une brique essentielle de la[Modern Data Platform](../../articles/modern-data-platform-definition-entreprise/index.html) d’une entreprise souhaitant analyser ses données. En effet, celui-ci permet de centraliser une immense quantité de données, provenant de sources multiples. Cette solution de stockage est généralement le point de départ de la plupart des transformations effectuées sur ces données en vue de leur analyse. Le choix du datawarehouse est crucial pour une entreprise et doit être fait en cohérence avec le reste de la data stack de l’entreprise. ### Qu’est-ce que BigQuery ? BigQuery est un data warehouse lancé par Google en 2010, disponible dans l’environnement[GCP](https://cloud.google.com/) (Google Cloud Platform) sur un mode de fonctionnement serverless : c’est-à-dire qu’il n’est pas nécessaire d’allouer soi-même des ressources pour le fonctionnement de BigQuery, cette partie étant gérée pour nous directement par le service. En tant qu’entrepôt de données, BigQuery repose sur un modèle OLAP (pour OnLine Analytical Processing). Cela signifie que l’outil est prévu et optimisé pour traiter de grands volumes de données historiques, de manière analytique, c’est-à-dire en y appliquant des transformations et des jointures. Ainsi, il en découle que BigQuery n’est pas adapté à un usage orienté vers les transactions, comme un système de gestion des stocks, ou un backend de site e-commerce par exemple. Plus généralement, on évitera l’utilisation de BigQuery (et d’un outil OLAP en général) pour un cas d’usage nécessitant un grand nombre d’insertions, suppressions et mises à jour de données et on favorisera pour ces cas d’usage, un système OLTP (OnLine Transaction Processing). ### Les caractéristiques de BigQuery #### Une capacité de traitement de données impressionnante BigQuery possède une importante capacité de parallélisation lors du traitement des données durant une requête. Cet avantage lui permet dans certains cas de traiter jusqu’à plusieurs pétaoctets de données en quelques secondes. #### Intégration à Google Cloud Platform (GCP) Cet avantage est circonstanciel et dépend du reste de l’architecture dans laquelle on souhaite intégrer un datawarehouse. Il n’est cependant pas à négliger dans le cas où d’autres services de l’organisation sont déjà hébergés sur GCP. Il est dans ce cas important de prendre en compte que Google permet d’intégrer étroitement BigQuery avec les autres services de son écosystème Cloud, comme[Google Cloud Storage](https://cloud.google.com/storage?hl=fr),[Pub/Sub](https://cloud.google.com/pubsub/docs/overview?hl=fr),[Google Cloud Dataprep](https://cloud.google.com/dataprep?gad_source=1&gclid=CjwKCAiA0PuuBhBsEiwAS7fsNchvu99pE7Rs7EcznZn5l0-zUyWRE-9YNIF8nJdxbcWiz8GLLv14dxoCb6oQAvD_BwE&gclsrc=aw.ds&hl=fr), etc. #### Entièrement managé Nous l’avons mentionné plus haut, aucune tâche d’allocation de ressources ou de maintenance n’est nécessaire pour faire fonctionner BigQuery. #### Support du SQL standard BigQuery utilise un dialecte SQL dédié, le GoogleSQL. Ce dialecte ajoute certaines fonctions analytiques et de transformation utiles. Cependant, il est compatible avec le SQL standard: ainsi, une grande majorité du code écrit en SQL standard est supporté dans BigQuery. #### Nombreuses fonctionnalités de sécurité L’outil propose en outre de nombreuses fonctionnalités de sécurité plus ou moins avancées. Ainsi, toutes les données traitées par BigQuery sont protégées par chiffrement, à la fois au repos et en transit. Il est aussi possible de configurer BigQuery en multi-tenant pour isoler les données, et de l’intégrer à un VPC pour contrôler finement les connexions entrantes et sortantes au service. Enfin, comme tous les autres services GCP, BigQuery profite de toute l’infrastructure sécurisée mise en place par Google pour protéger ses services cloud, ce qui le protège notamment contre toute une gamme d’attaques web comme le DDoS. ### Les limites de BigQuery #### Optimisation des requêtes et maîtrise des coûts La maîtrise parfaite des coûts dans BigQuery peut s’avérer être un sujet épineux. En effet, ceux-ci sont affectés, entre autres, par la quantité de données traitées par les requêtes, l’optimisation des classes de stockage utilisées pour stocker les données, l’allocation ou non de slots réservés… Cette multiplicité de facteurs techniques et nécessitant une connaissance approfondie de l’outil peuvent rendre les coûts plus compliqués à comprendre et à maîtriser lors de cas d’utilisation poussés. Ainsi, dans le cas de traitement de volumes importants de données et/ou de requêtes particulièrement complexes, il est nécessaire que les développeurs soient sensibilisés à l’optimisation des requêtes SQL. Cette optimisation peut en outre passer par l’utilisation de fonctionnalités spécifiques à BigQuery et à GoogleSQL, et le temps de formation éventuellement nécessaire pour acquérir la pleine maîtrise de ces outils. #### Limitation des requêtes BigQuery impose certaines limitations sur les requêtes, telles que la taille maximale des résultats de requête et le nombre de tables pouvant être interrogées dans une seule requête. Cependant, il est important de noter que ces limitations ne posent en général problème que pour certains cas d’usage très précis, et que la vaste majorité des cas d’analyse ne s’en trouvent pas concernés. #### Une flexibilité limitée D’une manière générale, le fait que BigQuery soit un service totalement managé implique un désavantage inhérent à ce statut : il est parfois impossible de configurer BigQuery aussi loin qu’on le souhaiterait et de s’affranchir des limitations imposées par Google Cloud. #### La dépendance à GCP et à l’écosystème Google Bien que BigQuery s’intègre parfaitement à tout l’environnement GCP et à ses services, il n’en est parfois pas de même pour son intégration avec d’autres services externes à GCP. De plus, utiliser BigQuery de manière optimale avec le reste des services du cloud de Google nécessite une bonne connaissance et maîtrise de ce dernier. ### Les features additionnelles de BigQuery Nous l’avons vu, BigQuery propose une large gamme d’avantages et de fonctionnalités nécessaires à tout bon datawarehouse, idéales pour l’analyse performante de larges volumes de données. Voici quelques fonctionnalités supplémentaires que propose l’outil et qui permettent d’aller plus loin : #### BigQuery ML BigQuery propose un service permettant de créer, entraîner et déployer des modèles de machine learning directement au sein du service. Cela est rendu possible par l’intégration de[BigQuery ML](https://cloud.google.com/bigquery/docs/bqml-introduction?hl=fr) directement dans GoogleSQL, qui permet l’utilisation de ces modèles au sein même de requêtes SQL. De plus, certains modèles basiques sont nativement intégrés à BigQuery ML, comme les modèles de régression linéaire ou logistique, le clustering k-means… #### Grande variété de types de données Dans une base de données, un type de données spécifie la nature des valeurs que peut prendre une colonne, comme des nombres, du texte, des dates, ou des valeurs booléennes, définissant ainsi comment les données peuvent être stockées, manipulées et utilisées. De son côté, BigQuery met à disposition des développeurs une[très grande variété de types](https://cloud.google.com/bigquery/docs/reference/standard-sql/data-types) avec lesquels interagir. Ils sont regroupés en deux catégories : - Les types simples : on y trouve les types “classiques” comme les booléens, chaînes de caractères, nombre… BigQuery dispose de 3 types différents pour représenter les nombres (un pour les flottants et deux pour les entiers, selon leur taille), et de types dédiés pour les dates, datetime, time et timestamp. - Les types complexes : BigQuery permet la création et manipulation de types complexes comme les STRUCT (semblables dans le fonctionnement à des dictionnaires en Python), ainsi que les tableaux. De plus, un grand nombre de fonctions sont à disposition du développeur pour traiter les chaînes de caractères au format JSON. Enfin, le service propose également un type appelé GEOGRAPHY. Son utilisation, plus large que son nom pourrait le laisser croire, permet de stocker des points, mais aussi des lignes, polygones et collections multipoints. Il est donc très utile pour l’analyse en profondeur de données géospatiales. #### Optimisation des requêtes Conscient que l’optimisation des requêtes est une problématique importante en ce qui concerne la maîtrise des coûts dans BigQuery, Google met à disposition pour son service différents outils aidant à l’optimisation des requêtes et du volume de données traitées. Parmi eux, on trouve : · Le partitionnement et le clustering de tables · Le cache de requêtes : le service met en cache les résultats de requêtes durant 24 heures, sauf dans le cas de tables protégées par des règles de sécurités spécifiques au niveau des colonnes. · Des insights sur les requêtes effectuées : l’éditeur de BigQuery propose un onglet “Execution Graph”, permettant de visualiser sous forme de graphe les étapes d’une requête. Ce graphe permet aussi de mettre en lumière les étapes mal optimisées et utilisant plus de ressources qu’elles ne le devraient, en étant signalées par des icônes spécifiques à l’utilisateur. ### Le modèle de facturation de BigQuery En tant que service managé, BigQuery repose sur un modèle de facturation flexible et à la demande : le paiement est directement proportionnel à l’utilisation des ressources. Plusieurs aspects entrent en compte lors du calcul de la facturation BigQuery : #### La facturation de BigQuery pour le stockage des données Dans BigQuery, le coût relatif au stockage des données est calculé proportionnellement au nombre de Gio (gibioctets) par mois stockés. Dans le cas de données stockées moins longtemps qu’un mois complet, un prorata est fait au mégaoctet et à la seconde près. BigQuery facture actuellement $0.023 par Gio et par mois de données actives stockées en ce qui concerne le stockage logique. Lorsque des données ne sont pas utilisées durant 90 jours consécutifs, elles sont converties en stockage dit “passif”, et les coûts inhérents à leur stockage baissent. Enfin, BigQuery propose un tier gratuit pour les 10 premiers Gio de données stockés chaque mois. #### La facturation inhérente aux requêtes effectuées sur les données Dans le cadre de la facturation inhérente aux requêtes effectuées sur les données, BigQuery facture simplement en fonction de la quantité de données traitées par chaque requête, à la demande. Ce calcul se fait sur la base de $7.81 par Tio (tébioctet) de données traitées. Google propose un tier gratuit d’un Tio de données traitées par mois. En outre, BigQuery propose un système de slots. Un slot correspond à une capacité de calcul réservée, en échange d’un paiement récurrent fixe. Cette solution est très utile dans le cas de coûts de requêtes importants et facilement prévisibles au sein d’une grande organisation par exemple. #### La facturation de BigQuery lors des transferts de données Ingestion : l’ingestion de données en lot (batch) dans BigQuery est généralement gratuite. Concernant les données en streaming, l’utilisation de l’API BigQuery Storage Write peut entraîner des surcoûts au-delà de 2 Tio de données ingérées par mois. Extraction : il est possible d’extraire gratuitement jusqu’à 50 Tio de données par jour en batch. Dans le cas d’une extraction de données en streaming via l’API BigQuery Storage Read, un surcoût peut être induit au-delà de 300 Tio de données par mois extraites. BigQuery se distingue comme un service de datawarehouse puissant et flexible, adapté à une large gamme d'applications analytiques. Grâce à sa capacité à traiter de vastes volumes de données rapidement, son modèle de facturation flexible et ses fonctionnalités avancées telles que BigQuery ML et l'optimisation des requêtes, il offre aux entreprises les outils nécessaires pour transformer de grandes quantités de données brutes en insights utiles. La prise en charge d’un grand nombre de types de données enrichit encore sa polyvalence, permettant aux utilisateurs de gérer efficacement des données complexes et variées. Malgré certains inconvénients, comme la complexité de la gestion des coûts et les défis liés à l'optimisation des requêtes pour les utilisateurs moins expérimentés, BigQuery reste une option robuste pour ceux qui cherchent à exploiter la puissance du cloud pour l'analyse de données. Son intégration étroite avec les autres services GCP en font d’autant plus un premier choix dans le cas d’une organisation déjà implantée dans cet environnement cloud. BigQuery est un outil que nous utilisons très largement chez[Modeo](../../index.html) car il répond souvent à l’ensemble des problématiques data de nos clients. Si vous souhaitez en savoir plus sur cet outil, d’autres outils de la[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html) que nous utilisons ou les solutions que nous proposons,[contactez-nous](../../contact.html) ! --- ## Deep dive - comprendre l'importance du DataOps URL : https://modeo.ai/articles/dataops-definition-et-bonnes-pratiques > Découvrez le DataOps, sa définition, son organisation et ses meilleures pratiques pour améliorer la gestion et l'automatisation de vos données. [Modeo](../../index.html) a accompagné plusieurs grandes entreprises dans la mise en place de méthodologie DataOps, il était donc important pour nous d’écrire cet article. En effet, chaque organisation a sa propre vision du DataOps. Pourtant, même si les approches et les outils diffèrent, certains grands principes restent partagés. C’est ce que nous avons décidé de présenter dans cet article. ### Qu’est-ce que le DataOps ? Le DataOps est une méthodologie inspirée du DevOps qui, grâce à un ensemble d’outils et de process, permet de réduire le Time To Value des projets Data tout en améliorant la qualité des données et leur gouvernance. Elle améliore la collaboration entre les équipes Data et standardise les process. Selon [Data Kitchen](https://datakitchen.io/), le DataOps permet aux équipes Data : - D’innover et d'expérimenter plus facilement, tout en produisant des insights extrêmement rapidement pour les équipes métier - Améliorer le niveau de qualité des données - De faciliter la collaboration entre les Data Consumers/Producers, les technologies et environnements - D’améliorer le monitoring des jobs d’ingestion et de transformation de données ### Le rôle de l’équipe DataOps L’équipe DataOps, parfois appelée équipe Data Platform ou Center Of Excellence (CoE) intervient principalement dans le cadre d’organisation décentralisée, (par exemple Data Mesh), où les domaines métier de l’entreprise disposent de leur propre équipe Data pour construire leurs cas d'usage en toute autonomie. L’équipe DataOps est au service de ces équipes. Si nous prenons l’exemple d’une grande entreprise dans le retail, l’équipe DataOps, centralisée serait au service de l’équipe Data : - Domain 1 : Finance - Domain 2 : Delivery &, Logistic - Domain 3 : Stock Une stratégie DataOps fonctionne également pour des entreprises avec une logique de filiales. Par exemple, la SNCF disposerait de son équipe DataOps, qui serait au service des domaines suivants : - SNCF Voyageurs - SNCF Réseau - SNCF Gares &, Connexions - GEODIS - Keolis - Rail Logistics Europe Ainsi, en disposant d’une équipe DataOps, le groupe est en mesure de standardiser les bonnes pratiques Data sur l’ensemble des équipes / filiales / domaines. Le périmètre d’intervention d’une équipe DataOps varie selon le type d’organisation dans lequel elle évolue. L’équipe peut par exemple avoir comme responsabilité : - Le choix de la stack et des outils - La mise à disposition d’environnements de développement (exemple : DBT + Snowflake + Github) - La définition des bonnes pratiques de développement - La mise à disposition d’outils de monitoring et d’observabilité auprès des équipes métier - Le suivi des coûts et de l’impact carbon de la Data Platform ### Les Gains de l’équipe DataOps Les gains apportés par une équipe DataOps sont multiples : 1- Amélioration de la qualité des données Les équipes DataOps s'assurent que les données soient précises, cohérentes et fiables. Pour cela, elle propose des outils d’observabilité, des process de test (code quality + data quality) et de résolution d’incidents. 2- Amélioration de la vélocité des développeurs En industrialisant le traitement, l’ingestion et la transformation des données, les équipes DataOps réduisent considérablement le Time-To-Insights. 3- Scalabilité L’équipe DataOps construit un socle technique qui permet aux projets Data du Groupe de scaler. Elle accompagne la croissance de chaque équipe en leur permettant de multiplier le nombre de projets Data, tout en maintenant des hauts standards de qualité. 4- Innovation et compétitivité L'équipe DataOps permet au Groupe de tirer parti plus efficacement de ses assets Data, débloquant ainsi de nouvelles opportunités d'innovation et de projets à forte valeur ajoutée (exemple : IA/LLM, Data Apps etc…). 5- Amélioration de l'agilité et de l'adaptabilité L'équipe DataOps impose des méthodologies Agile et des principes DevOps qui permettent d’avoir la bonne flexibilité pour répondre aux nouvelles demandes métier. 6- Amélioration du ROI des équipes Data En garantissant que les données soient traitées, gérées et utilisées efficacement, l'équipe DataOps aide le Groupe à maximiser la valeur tirée de leurs assets Data. 7- Réduction des risques et conformité RGPD L'équipe DataOps garantit que les normes de sécurité et de confidentialité des données, soient bien respectées. Cela permet d’éviter des sanctions liées à au non-respect de la réglementation en vigueur, ou des éventuelles fuites de données. 8- Data FinOps et optimisation des ressources L'équipe DataOps aide les organisations à comprendre et réduire les coûts associés à la Data Platform, en intégrant des modules de calcul et en imposant les bonnes méthodologies [FinOps](../../articles/webinar-finops/index.html). 9- Amélioration de la collaboration entre les Domaines L'équipe DataOps aide à combler le fossé entre les producteurs de données (IT, Data Engineer) et les consommateurs de données (Data Scientist, [Analyst](../../articles/le-role-de-lanalytics-engineer/index.html) et business users) en mettant en place des process clairs et des canaux de communication. Cela encourage la collaboration, réduit les silos et assure que les données soient accessibles et bien utilisées dans tout le Groupe. 10- Création d'une culture Data interne L'équipe DataOps aide à promouvoir une culture axée sur les données au sein de l'organisation, où les consommateurs de la donnée à tous les niveaux comprennent la valeur des données et les intègrent dans l’ensemble de leurs processus décisionnels. Pour mesurer le succès d’une équipe DataOps, plusieurs paramètres peuvent être pris en compte, comme indiqué ci-dessous : ### Mettre en place du DataOps, par où commencer ? #### Constituer une équipe DataOps La première étape pour se lancer dans le DataOps est de constituer son équipe. Dans un premier temps, cette équipe peut simplement être un duo avec un(e) PM Data et un(e) DataOps. Ce dispositif est amplement suffisant pour commencer. #### Définir les rôles et responsabilités des équipes Il faut, dans un second temps, établir les rôles et responsabilités de l’équipe DataOps par rapport aux autres équipes Domains, spécifiques à leur organisation. Par exemple : #### Identifier les modules clés à mettre à disposition Une fois les responsabilités de chacun identifiées, il est nécessaire de définir les modules clés pour construire l’offre de service qui sera proposée aux équipes domaines. L'intérêt de cette approche offre de service est multiple. Elle permet de : - Mutualiser les développements de nouveaux modules pour les différentes équipes domaines - Recueillir les besoins de chaque équipe et en faire bénéficier les autres - Faciliter la communication entre chaque équipe Chez Modeo, la méthodologie DataOps se décompose en 5 piliers : - Technique - Métier - Sécurité - Légal - RSE. Voici une liste non exhaustive de modules pouvant être déployés : #### Mettre en place des canaux de communication Parallèlement au développement de ces modules, il est crucial de mettre en place les bons process de communication pour permettre à l’équipe DataOps de déployer ses travaux au sein de son organisation. Cela peut passer par des canaux Teams et des points mensuels dédiés pour présenter les nouveaux travaux. L’équipe DataOps doit également se tenir à disposition des domaines pour les accompagner dans la prise en main de ces nouveaux outils car le travail de cette équipe n’a de valeur que lorsqu’il est adopté et utilisé dans toute l’entreprise. Modeo a accompagné plusieurs entreprises leaders dans leur domaine (retail, luxe, hôtellerie…) dans la mise en place ou l’évolution de leur équipe DataOps et leur Data Platform. Si vous disposez d'une équipe DataOps et que vous souhaitez vous améliorer sur l'un des axes suivants : sécurisé, technique, métier, légal, RSE ou que vous souhaitez créer votre équipe alors [contactez-nous](../../contact.html). ### Accédez à notre Masterclass : ### Explorez plus: 1. Tout ce que vous devez savoir sur la [Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html) 2. Les [semantic layers](../../articles/semantic-layers/index.html) (couches sémantiques) : Le référentiel pour vos applications IA et Analytics 3. [FinOPS](../../articles/webinar-finops/index.html) : Les bonnes pratiques pour maîtriser vos coûts data/IA cloud --- ## Prix de ClickHouse | Comprendre son pricing en 2026 URL : https://modeo.ai/articles/clickhouse-pricing > ClickHouse est un système de gestion de base de données proposant une offre cloud à la tarification transparente et basée sur l’usage. Solution de stockage extrêmement puissante et rapide, ClickHouse est aujourd’hui un acteur reconnu de la[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html) et une excellente solution pour des cas d’usage de traitement de grands volumes de données en temps réel. Cette solution s’imbrique parfaitement dans votre[Modern Data Platform](../../articles/modern-data-platform-definition-entreprise/index.html) grâce à ses nombreux connecteurs avec d’autres services data classiques. Son système de tarification se veut transparent et facilement compréhensible et c’est ce que nous allons vérifier dans cet article. ### Avant d’analyser sa tarification rappel de ce qu’est ClickHouse ? [ClickHouse](https://clickhouse.com/) est un **système de gestion de base de données (SGBD)** open-source conçu pour le **traitement analytique en ligne (OLAP)**. Clickhouse fait partie de ce vaste ensemble d’outils et de technologies qu’est la[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html). Développé à l'origine par Yandex, ClickHouse se distingue par sa capacité à exécuter des requêtes complexes sur de vastes ensembles de données en temps réel. Son **architecture orientée colonnes** permet une **compression de données efficace et une excellente vitesse de requêtage**. Ces caractéristiques en font une solution idéale pour l'analyse de données, le reporting, et les applications nécessitant une grande capacité de traitement de données. Pour en savoir plus sur ClickHouse, son fonctionnement, son architecture et ses fonctionnalités, **je vous invite à consulter notre article sur le sujet : “**[ClickHouse, le système de gestion de base de données (SGBD) de référence de la modern data stack en 2024 ?](../../articles/clickhouse-overview/index.html)**”.** ### La tarification de ClickHouse ClickHouse propose un modèle de tarification fondé sur un principe **“Pay only for what you use”**. Les prix sont calculés via un modèle d'abonnement mensuel qui varie en fonction de la **capacité de stockage, du volume de données transférées et du niveau de support souhaité**. Les prix commencent à partir de quelques dollars par mois et peuvent rapidement augmenter pour les déploiements à grande échelle nécessitant des ressources importantes. La**facture mensuelle est calculée à partir de deux mesures découplées** : - Le **volume de données stockées**, mesuré en terabytes (TB). Il est important de noter que **la donnée est automatiquement compressée par ClickHouse avant d’être stockée**, ce qui peut diminuer son poids de 90% et faire réduire le prix de stockage. - Le **nombre d’unités de compute consommées par heure**, mesuré en unité / heure. La notion d’unité varie selon les offres mais correspond à **une RAM** et un **nombre de CPUs**. ### Les offres de ClickHouse et leur tarification **ClickHouse est disponible en plusieurs versions**, chacune adaptée à différents besoins et budgets. #### ClickHouse open-source **La version open source de ClickHouse est totalement gratuite** et peut être auto-hébergée sur vos propres serveurs ou sur un cloud de votre choix. Cette option est idéale pour les entreprises disposant des compétences et ressources techniques nécessaires pour **gérer leur propre infrastructure et souhaitant une solution sans coût de licence**. Cependant, elle nécessite un investissement significatif en termes de temps et de ressources pour la configuration, l'optimisation et la maintenance. #### Les offres ClickHouse Cloud Pour les entreprises recherchant une solution plus clé en main, **ClickHouse propose une version cloud**. Cette offre est **hébergée**, **gérée et maintenue par l'équipe de ClickHouse**, ce qui élimine la complexité de gestion de l'infrastructure. ClickHouse Cloud propose trois niveaux de service. ##### Development **Development** est la première offre avec le prix le moins élevé. Cette première offre est idéale pour des projets de taille modeste ou des Proof of Concepts mais peut s'avérer limitée pour des cas d’usage réels impliquant de grands volumes de données. En effet, elle propose jusqu’à 1 TB de stockage (après compression) et 16 GiB de mémoire en plus de backups du jour précédent et d’outil de gestion des rôles S3. Le prix de cette offre varie, pour un hébergement sur AWS en Irlande, **de 1$ à 211$**, correspondant à une instance allumée 24h/24 et 1 TB de données stockées, après compression (10 TB avant). Le **prix par TB de stockage par mois est de 35,33$** et le **prix par unité de compute par heure** (une unité de compute correspondant à 16 GiB RAM et 2 vCPU) **est de 0,24 $**. Une des principales limitations de cette offre est que l’**auto-scaling n’est pas disponible**. L’auto-scaling étant l’ajustement automatique de la taille des machines allouées à une tâche en fonction de la charge de travail demandée. ##### Production **Production** est la deuxième offre proposée par Clickhouse et probablement celle qui répondra au plus de cas d’usage. La capacité de stockage est illimitée, la mémoire augmentée à 24 GiB, la durée de conservation des backups augmentée d’une journée… En plus de cela, ClickHouse propose l’**auto-scaling** et les ressources non utilisées sont automatiquement coupées pour éviter les surcharges. Son **prix n’est pas plafonné et est défini à l’usage**, sur une base de 47,08$ par To de stockage et 0,7686$ par unité de compute par heure (une unité de compute correspondant à 24GiB RAM et 6 vCPU). ##### Dedicated Le niveau de service le plus élevé proposé par l’éditeur est l’offre **Dedicated**. Cette offre ne propose pas de catalogue d’options par défaut mais **se définit en collaboration avec les équipes de ClickHouse** pour créer un service sur-mesure répondant au mieux à vos besoins. ClickHouse propose notamment un environnement dédié, de solides fonctionnalités de confidentialité et de sécurité et un support nominatif disponible quotidiennement. **Le prix n’est pas communiqué** mais on peut deviner qu’il est élevé et pas adapté à toutes les entreprises. Ce niveau de service s’adresse essentiellement aux grosses entreprises ou à celles ayant de **fortes contraintes de sécurité, au niveau de l’infrastructure, des données et des usages**. ### Le simulateur de prix de ClickHouse Il est souvent difficile d’anticiper les coûts de ses services Cloud, d’autant plus que les termes et notions utilisés ne sont pas toujours simples à comprendre. ClickHouse propose sur sa page de[pricing](https://clickhouse.com/pricing) un **simulateur permettant d’estimer le coût mensuel de son instance en quelques clics**. C’est une fonctionnalité très utile qui aide à y voir plus clair ! Vous pouvez retrouver ce simulateur[ici](https://clickhouse.com/pricing?loc=sub-menu#pricing-calculator). ClickHouse offre une gamme d'options pour répondre aux besoins des **entreprises de toutes tailles, des startups aux grandes entreprises**. Que vous optiez pour la flexibilité et le contrôle de la version open-source, la commodité du cloud, ou le support et les fonctionnalités avancées de l'offre Dedicated, **ClickHouse propose une solution adaptée à votre budget et à vos exigences techniques**. Si vous souhaitez consulter nos experts afin de savoir quelle offre est faite pour vous ou pour savoir si ClickHouse est le datawarehouse adapté à vos besoins, [contactez-nous](../../contact.html) ! --- ## Construire une Data Platform DataOps ready URL : https://modeo.ai/articles/modern-data-platform-construire-une-mdp-en-adoptant-les-meilleures-pratiques-dataops > Découvrez comment construire une Modern Data Platform performante en adoptant les meilleures pratiques DataOps : outils, étapes clés et conseils experts. Les grandes avancées technologiques de ces dernières années ont permis l’apparition d’un nouveau type de Data Platform, les Modern Data Platforms. Le concept reste le même, créer un outil central de gestion de la donnée au sein d’une entreprise, mais les moyens pour y arriver ont grandement évolué. Entrons dans le vif du sujet. Une Modern Data Platform (MDP) est une architecture de traitement de données moderne qui permet de collecter, stocker, transformer et analyser les données de manière efficace et évolutive. Contrairement aux architectures traditionnelles, la MDP utilise des outils cloud-native et des services SaaS pour offrir une meilleure agilité et des performances accrues. C’est grâce à cette Modern Data Platform que sont développés des cas d’usage data, tels que : - Dashboard de pilotage (financier, marketing…) - Segmentation client, optimisation des campagnes marketing - Prédictions, machine learning… ### Quelle est la différence entre la Modern Data Stack et une Modern Data Platform ? Les termes Data Platform et Data Stack sont parfois utilisés de manière interchangeable et cela peut mener à des confusions. En théorie, une Data Platform est l'ensemble des composants à travers lesquels les données circulent, de leur collecte à leur restitution, tandis qu'une data stack est l'ensemble des outils qui servent ces composants. Une Modern Data Platform est donc composée des solutions de la Modern Data Stack. ### Quels sont les critères à prendre en compte lors de la mise en place d’une MDP ? • Le temps requis pour construire des nouveaux cas d’usages : Utiliser des outils modernes et automatiser les processus pour être en mesure d’intégrer rapidement de nouvelles sources de données et créer /modifier des données métiers. • Les coûts : Évaluer les coûts d'implémentation et d'exploitation des différents outils et services. Cela inclut les frais d'abonnement, les coûts de stockage et les coûts de calcul. • Les compatibilité avec des compétences existantes (Python, SQL…) : Capitaliser sur les compétences des équipes en place pour leur permettre d’être rapidement opérationnel sur la plateforme. • La performance : Assurer que la solution choisie peut traiter les volumes de données nécessaires et ainsi répondre aux besoins de performance en termes de latence et de temps de réponse pour obtenir des insights précis. • L’évolutivité : Avoir le niveau de flexibilité requis pour réaliser des transformations de données complexes. • La maintenabilité : Privilégier des solutions simples et éprouvées, automatiser au maximum pour faciliter la maintenance. • L’absence de dépendance à un fournisseur spécifique (No Vendor Lock-in) : Éviter une trop forte dépendance à un outil ou un fournisseur unique en diversifiant les briques technologiques et en s’assurant d’une portabilité entre différents cloud provider. • Légal : La plateforme doit répondre aux enjeux légaux de traitement de données et engagements contractuels ### Et le DataOps dans tout ça ? #### Pour répondre à ces contraintes, un socle DataOps solide est essentiel : Comment construire et déployer de nouveaux cas d’usage ? - Mettre en place des pipelines de données robustes et automatisés (ETL/ELT). - Adopter des approches CI/CD pour faciliter l’intégration et le déploiement continu des modèles et transformations de données. - Standardiser les bonnes pratiques en matière de gouvernance des données. Comment sécuriser les accès aux données ? - Implémenter des politiques de gestion des accès (RBAC, ABAC) pour assurer une gestion fine des permissions. - Chiffrer les données sensibles en transit et au repos. - Assurer une traçabilité complète des accès et des modifications via des logs et des audits. Comment garantir la qualité et la fiabilité des données ? - Mettre en place des tests automatisés pour vérifier l’intégrité des données à chaque étape des pipelines. - Surveiller la qualité des données (données manquantes, incohérences, anomalies). - Intégrer des processus de Data Observability pour détecter et résoudre les incidents en temps réel. Comment assurer la scalabilité et l’optimisation des performances ? - Définir des architectures modulaires et scalables (Data Lake, Data Mesh, Data Warehouse). - Optimiser les requêtes et les charges de travail grâce à des solutions de cache, indexation et partitionnement. - Évaluer régulièrement la charge des ressources pour adapter l’infrastructure et réduire les coûts. —- ### Quelles sont les étapes pour construire sa Modern Data Stack ? #### Identifier un cas d’usage La construction d’une Modern Data Stack doit répondre à un ou plusieurs cas d’usage précis et servir des objectifs, notamment financiers et stratégiques, pour l’entreprise. Pour la suite de cet article, nous nous placerons dans le cas d’usage suivant : ex : Une entreprise de vente en ligne souhaite améliorer ses performances marketing. Pour cela, elle a besoin de mieux comprendre le comportement de ses clients afin d’optimiser ses campagnes publicitaires et augmenter ses taux de conversion. Il s’agit donc ici de construire une architecture efficace permettant de : - Centraliser les données de différentes sources (CRM, site web, campagnes publicitaires). - Stocker et transformer les données à des fins analytiques. - Exposer la donnée aux utilisateurs finaux. #### Choisir un datawarehouse Un datawarehouse comme "Single Source of Truth" (SSOT) centralise toutes les données d’une organisation, assurant que la création de KPIs et l'analytique reposent sur des données uniformes et fiables. Il permet à toutes les équipes d'accéder à une source unique et cohérente, évitant les divergences dans l'utilisation des données. Le choix du data warehouse influera sur les coûts de stockage et de traitement des données de la Data Platform. Il existe différentes solutions sur le marché, pour la plupart hébergées dans le Cloud et proposant des outils de monitoring des coûts et des performances avancés. Pour ses faibles coûts de stockage et ses performances, nous choisirons pour cet exemple le data warehouse BigQuery, disponible sur Google Cloud Platform. Si vous souhaitez en savoir plus sur BigQuery, ses fonctionnalités clés et ses performances, n’hésitez pas à consulter[mon article à ce sujet.](../../articles/bigquery-overview/index.html) #### Choisir un outil d’ingestion L’ingestion des données peut représenter un défi délicat dans le cas de certaines data platform, notamment en raison de la multiplicité potentielle des sources de données à agréger. Pour cette raison, il existe un très large choix d’outils d’ingestion sur le marché. Certains permettent d’ingérer de la donnée en continu, tandis que d’autres ingèrent la donnée par paquets à intervalles réguliers. Certains outils se dédient simplement à déposer la donnée d’un point A à un point B, tandis que d’autres permettent de réaliser des transformations à la volée. Et même en considérant cette large gamme, certaines entreprises prennent le parti de développer leurs propres outils d’ingestion, afin de corréler les fonctionnalités de l’outil à leur besoin précis. A cette étape, nous utiliserons Airbyte : sa simplicité d’utilisation en fait un outil idéal pour se connecter à différents outils et logiciels pour centraliser la donnée dans BigQuery. De plus, il est possible d’héberger ses connecteurs Airbyte directement dans le Cloud, sans avoir à maintenir une infrastructure dédiée. #### Modéliser et transformer ses données La modélisation et la transformation des données est généralement effectuée à travers différentes couches du data warehouse. Pour cela, l’utilisation du langage SQL est largement répandue. DBT est un outil permettant de centraliser et versionner les requêtes de transformation des données du data warehouse. Là-aussi, cet outil offre la possibilité d’un hébergement directement dans le Cloud. Ainsi, les transformations peuvent être régulièrement programmées afin de maintenir une donnée finale à jour sans avoir à maintenir d’infrastructure. Ce choix semble donc idéal pour notre projet. #### Exposer et visualiser ses données Maintenant que les données sont ingérées, stockées et transformées, il manque un dernier outil en bout de chaîne pour les exploiter. Ce type d’outil, appelé outil d’activation (ou d’exposition) de la donnée, peut prendre plusieurs formes : - Un outil de visualisation de données, sous forme de tableaux et de graphiques - Des modèles de machine learning - Un logiciel de type CRM qui utiliserait des données transformées >, Pour répondre à notre besoin, considérons que l’on souhaite afficher nos données clients sous la forme d’un dashboard d’aide à la décision pour les utilisateurs finaux. Il serait alors intéressant d’intégrer en bout de chaîne un logiciel comme Looker Studio: simple d’utilisation, il permet facilement de partager des dashboards à différents utilisateurs, tout en gérant les droits d’accès et de modification. De plus, il s’intègre parfaitement dans l’écosystème Google, dans lequel se trouve déjà nos données stockées. Architecture dédiée A savoir : Nous avons pris dans cet article l'un des chemins possibles pour construire une Modern Data Platform efficace et résiliente. Nous avons pour cela pris pour point de départ un ou plusieurs des cas d'usages concrets d'une société. En effet, pour remplir correctement son œuvre, une data platform doit avant tout être basée sur un besoin réel. Ce dernier nous a permis, couplé aux autres contraintes structurelles, technologies et budgétaires du client, de faire une sélection adaptée des outils et technologies de notre plate-forme. #### -- #### Vous souhaitez être accompagné par les experts en MDP ? Contactez-nous via le formulaire de [contact ici,](../../contact.html) un de nos Data Engineers vous contactera rapidement pour discuter de vos problématiques et vous conseillera sur vos pains points. --- ## GenAI et Data Engineering URL : https://modeo.ai/articles/genai-et-data-engineering > GenAI et Data Engineering : les points clés de notre Modeo Data Talk avec Christophe Blefari (Blef), co-fondateur de NaO, et le replay complet. Matthieu Rousseau, notre CEO, a eu le plaisir de discuter de ce sujet passionnant lors de notre Modeo Data Talks avec Christophe Blefari (Aka Blef), co-fondateur de NaO, un expert reconnu qui a passé plus de dix ans à façonner le data engineering. Cet article vous offre un aperçu des points clés abordés et vous invite à plonger plus en profondeur en regardant le replay complet sur [notre chaîne Youtube.](https://www.youtube.com/watch?v=sqegiB-uwM4&t=3s) ### GenAI et Productivité : Un accélérateur sans précédent L'un des impacts les plus immédiats de la GenAI sur le data engineering est le gain de productivité. Christophe le souligne : la GenAI agit comme un véritable multiplicateur, permettant aux équipes de produire du code plus rapidement et plus efficacement. Cette automatisation de tâches répétitives et chronophages libère un temps précieux pour les data engineers. Mais à quoi ce temps sera-t-il dédié ? Plutôt que de se perdre dans des tâches fastidieuses, les data engineers peuvent désormais se concentrer sur des missions à plus forte valeur stratégique. Cela inclut une meilleure collaboration avec les équipes métiers pour comprendre leurs besoins réels et concevoir des solutions data qui répondent précisément aux enjeux business. Que vous soyez dans une petite structure agile ou une grande entreprise plus établie, cette capacité à s'impliquer davantage dans la stratégie est un atout majeur. ### L'évolution du métier de Data Engineer : Vers plus de stratégie et moins de pénibilité Le data engineering a toujours été un domaine exigeant, nécessitant une maîtrise d'une multitude de technologies et d'outils. Python, Spark, SQL, Terraform, cloud... les data engineers sont souvent des profils transversaux, jonglant entre différents environnements. C'est là que la GenAI devient une alliée de taille. Pour les profils seniors, l'IA copilote est un outil puissant. Elle permet d'automatiser le "jonglage" entre les technologies, de rafraîchir rapidement la mémoire sur des syntaxes moins fréquentes, et de générer des portions de code complexes en un temps record. En bref, elle permet aux experts de se concentrer sur l'architecture et la conception, plutôt que sur la rédaction ligne par ligne. Cette évolution ouvre également la porte à de nouvelles opportunités de carrière. Si l'Analytics Engineering a déjà redéfini certaines frontières, la GenAI vient dynamiser encore davantage le rôle du data engineer. La construction de modèles génératifs, la gestion des données pour alimenter ces modèles, l'orchestration des pipelines d'IA... toutes ces tâches nécessitent des compétences solides en data engineering et tracent la voie vers des rôles comme celui d'AI Engineer avec une forte composante data. #### Lire notre article complémentaire sur la GenAI : le rôle stratégique du Data Engineering ### Impact sur les briques de la Data Platform Lors du webinar, nous avons exploré comment la GenAI va impacter les différentes briques d'une plateforme data : - Ingestion et Transformation : Ce sont les domaines où le code est le plus présent, et donc où les gains de productivité liés à la génération de code par l'IA sont les plus significatifs. - Orchestration : Imaginez des agents IA capables de décider quand et comment lancer des tâches, rendant vos DAGs Airflow plus efficients et intelligents. - Observabilité et Gouvernance : La GenAI promet une détection proactive des anomalies et une automatisation de la création de tests, améliorant considérablement la fiabilité de vos données. Un point particulièrement intéressant concerne le self-service data et le Text-to-SQL. Bien que les projets de Text-to-SQL aient rencontré des défis par le passé, les modèles de langage actuels s'améliorent de jour en jour. L'avenir est probablement aux interfaces conversationnelles intégrées directement dans les outils de BI, permettant aux utilisateurs métiers de générer des visualisations et des tableaux de bord simplement en posant des questions en langage naturel. ### Envie d'aller plus loin et de découvrir la démo de NaO ? Pour comprendre en détail comment la GenAI va transformer le quotidien des data engineers, les défis à anticiper et les outils à maîtriser, nous vous invitons à regarder le replay complet de notre Modeo Data Talks ! --- ## Google Workflow | Outil référence d’orchestration serverless URL : https://modeo.ai/articles/google-workflows > Google Workflows est l’outil d’orchestration serverless de Google Cloud Platform. Il permet de créer des suites d’étapes reliées par des liens logiques. ### Google Workflow : un outil d’orchestration serverless ? L’ordonnancement des tâches et la gestion de leurs dépendances est aujourd’hui une brique essentielle de la [Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html). Cette fonction est généralement remplie par un outil d’orchestration qui lance les différentes tâches dans un ordre défini, permet ou non la parallélisation, et gère les dépendances entre ces dernières. Le choix d’un service d’orchestration dépend de nombreux critères, comme la performance de l’outil, sa scalabilité, sa sécurité ou encore son coût. Parmi les outils d’orchestration les plus connus figurent[Airflow](https://airflow.apache.org/), ou[Dagster](https://dagster.io/), deux outils open-source puissants et scalables mais nécessitant de déployer une infrastructure adaptée et une maintenance régulière. Il existe une gamme spécifique d'orchestrateurs permettant de mettre en place une orchestration sans avoir besoin de déployer et gérer une infrastructure dédiée : les orchestrateurs serverless.[Google Workflows](https://cloud.google.com/workflows?hl=fr) est l’un de ces outils. Nous allons, au fur et à mesure de cet article, dérouler les avantages et inconvénients d’un orchestrateur serverless par rapport à un orchestrateur classique. ### Qu’est-ce que Google Workflows ? Google Workflows est un service d’orchestration serverless disponible sur GCP. Il permet d’agencer différentes étapes faisant appel à des services Google Cloud tels que Cloud Functions, Pub/Sub ou Cloud Run, mais aussi à des API tierces. Un workflow se décline en un fichier YAML directement éditable dans la console Google Cloud, ou via[Terraform](https://www.terraform.io/) et un outil de versionning comme Git. Dans ce fichier YAML sont décrites des étapes, qui seront exécutées dans un ordre et suivant les conditions précisées. ### Les fonctionnalités de base de Google Workflows #### Structure Un workflow basique ressemble à ceci : Le bloc “main” est toujours le point d’entrée, et c’est la première étape de la liste “steps” qui sera d’abord exécutée. On observe qu'un workflow peut recevoir des paramètres en entrée, ici "input". Un même workflow peut être exécuté des dizaines de fois en parallèle avec des paramètres identiques ou différents, et chaque exécution est totalement indépendante des autres. #### Exécution des étapes La liste d’étapes d’un workflow est par défaut exécutée séquentiellement. Google Workflows va toujours attendre la fin de l'exécution d'une étape donnée pour exécuter la suivante. Nous verrons par la suite qu'il est possible de s'affranchir de cette règle et de contraindre Google Workflows à exécuter certaines étapes de manière parallèle. #### Structure d'une étape Une étape donnée est définie par son nom, par exemple "getLocation". Celui-ci doit être unique pour servir d’identifiant et pouvoir être identifié de manière précise par Google Workflows. À l'intérieur d’une étape se trouvent des mots-clés correspondant à des actions à réaliser. Ces actions peuvent être : - call : L'exécution d'une fonction de la bibliothèque standard Google Workflows - assign : L'assignation d'une valeur à une variable - switch : La mise en place d'une condition - return : Le retour d'une valeur, signant généralement la fin du workflow ou du sub-workflow en cours Ainsi, l’étape ci-dessous consiste à utiliser la fonction sys.get_env de la bibliothèque standard de Workflows. Un appel de fonction via un bloc call est généralement suivi d’un bloc args permettant de passer des arguments à la fonction appelée. En l'occurrence, on souhaite ici passer le nom de la variable d’environnement que l’on veut récupérer. Le résultat de cet appel est ensuite stocké dans la variable location qui est utilisée dans la suite du workflow via la syntaxe $location le symbole “$” permettant d’accéder au contenu de la variable qu’il précède. La liste des fonctions de la bibliothèque standard de Google Workflows est donnée[ici](https://cloud.google.com/workflows/docs/reference/stdlib/overview). #### La gestion des blocs conditionnels Comme tout orchestrateur, Google Workflows offre la possibilité de créer des blocs conditionnels. Le bloc ci-dessous comporte une condition, matérialisée par le mot-clé switch. Ce bloc attend une liste de conditions. Ici, on vérifie que le paramètre d’exécution du workflow input contient bien une clé “searchTerm”. Si c’est bien le cas, la valeur de ce paramètre est assignée à la variable searchTerm. L’élément important à observer dans cet extrait de code est le mot-clé next : c’est lui qui permet, si la condition est valide, de sauter directement à l’étape voulue “readWikipedia”. Une bonne combinaison de blocs switch et d’instructions next permet de créer des workflows complexes et modulaires. ### Les fonctionnalités avancées de Google Workflow En plus des blocs conditionnels switch décrits plus haut, il existe d'autres fonctionnalités permettant d'écrire des workflows plus avancés et modulaires. #### Les subworkflows Un subworkflow doit être défini à l'extérieur du workflow principal. C'est une suite d'étapes réutilisable qui prend des paramètres d'entrée et retourne une valeur de sortie. Ils s’apparentent à des fonctions en programmation. Ils peuvent être appelés de la même façon que les fonctions de la bibliothèque standard Google Workflows, à l'aide du mot-clé call. #### La gestion d'erreurs Il est possible de gérer les erreurs dans un workflow via les mots-clés try, except et retry. Les étapes du bloc try seront exécutées normalement tant que l'une d'elles ne lève pas une exception. Si une exception est levée, deux cas de figure se présentent : - Si un bloc retry est présent, alors les étapes du bloc try sont à nouveau exécutées autant de fois que le permet la retry_policy. - S'il n'y a pas de bloc retry ou si le nombre de tentatives maximales est atteint, les étapes du bloc except sont exécutées. Il est possible de définir une retry policy précise qui indique les conditions selon lesquelles une nouvelle tentative doit être faite, la durée d'attente au bout de laquelle elle doit être lancée et le nombre maximum de nouvelles tentatives. #### La pause d'un workflow La fonction sys.sleep permet de mettre l'exécution d'un workflow en état de pause pendant un laps de temps donné, en secondes. L'exécution n'est pas stoppée, mais momentanément suspendue. La durée de suspension maximale pour un workflow est d’un an moins le temps d'exécution déjà écoulé. Cette limite découle naturellement du fait que la durée d’exécution limite pour un workflow dans son ensemble est d’un an. Cette fonction est notamment utile dans le cas où l'on souhaite attendre la fin d'un processus dont la durée moyenne d'exécution est connue avant de continuer le workflow. #### Les callbacks Comme indiqué ci-dessus, le timeout d'un workflow est très long. Cependant, une étape spécifique ne peut rester en état d'exécution plus de 30 minutes, après quoi elle lèvera une exception de timeout qui mettra fin à l’exécution du workflow. Dès lors, on est en droit de se demander comment construire un workflow nécessitant d'attendre la fin de l'exécution d'une étape potentiellement très longue, mais dont le temps d'exécution n'est pas connu, ou une action précise d'un service ou d'un utilisateur, pouvant survenir à n'importe quel moment Workflows offre pour cela un service de callbacks fonctionnant en deux temps. Tout d'abord, il consiste à mettre en place un callback endpoint, une URL propre à l’exécution du workflow en cours. La seconde étape consiste à placer le workflow dans un état d'écoute sur l'URL créée. Il attendra qu'un appel HTTP avec la bonne méthode soit effectuée sur l'URL d'écoute pour redémarrer. Cet état d'écoute n'est pas considéré comme une étape en cours d'exécution, le timeout d’exécution de 30 minutes ne s’applique donc pas et la seule restriction est le timeout d'un an du workflow. De manière plus concrète, un callback dans un workflow permettrait par exemple d’attendre qu’un utilisateur valide un formulaire sur un site web avant de continuer l’exécution du workflow, que l’utilisateur mette 24h ou plusieurs semaines pour cela. #### La parallélisation Dans Google Workflows, il est possible de paralléliser certaines tâches. La création d’un bloc de parallélisation se fait via le mot-clé parallel et permet de déclarer explicitement certaines tâches comme devant s’exécuter parallèlement. Une fois que chacune des tâches du bloc de parallélisation est terminée, l’exécution du workflow continue normalement. ### Google Workflows : avantages et inconvénients de l’outil #### Les avantages de Google Workflows Une architecture serverless : nous l’avons abordé au début de cet article, Google Workflows est un service d’orchestration 100% serverless. Ce statut implique une grande facilité d’utilisation du service puisqu’il n’est pas nécessaire de s’inquiéter de l’allocation des ressources, ni de sa scalabilité : Google se chargera d’allouer correctement les ressources nécessaires à leur bonne exécution. Modularité des workflows déployés : bien que la syntaxe en YAML et la méthode d’écriture des workflows puissent paraître restrictives, Workflows permet en réalité de déployer des flux de tâches très flexibles et modulaires. Cette flexibilité est permise par les blocs conditionnels et les instructions de saut à une étape précise que nous avons vues plus haut. De plus, l’écriture de sub workflows apporte une réelle modularité en permettant la factorisation et la réutilisation de blocs d’étapes répétitives. Grande permissivité dans la gestion d’erreurs : Workflows permet de paramétrer précisément les options de nouvelles tentatives d’une étape, ainsi que la gestion de ses exceptions. Cette finesse permet de gérer à peu près tout type d’erreurs, et de mettre en place un alerting différent selon le type d’erreur rencontré. Intégration dans GCP : une large bibliothèque de fonctions est disponible pour interagir avec les autres services GCP. Google Workflows est donc parfaitement adapté pour l’orchestration de services GCP entre eux. Possibilité de versionning avec Terraform : comme la plupart des ressources GCP, il est possible de créer un workflow directement via [Terraform](https://www.terraform.io/), permettant une reproductibilité plus simple pour un workflow donné, ainsi que la collaboration sur la définition d’un workflow. #### Les inconvénients de Google Workflows Syntaxe YAML obligatoire : l’utilisation du YAML pour définir des workflows complets et bien construits peut parfois nécessiter un temps d’adaptation. De plus, les erreurs éventuelles dans le fichier YAML écrit pour exécuter le workflow ne sont pas toujours bien explicitées par la console, et peuvent être compliquées à déboguer. Dépendance à GCP : bien que Google Workflows soit parfaitement en mesure de faire appel à des API externes, il est optimisé pour fonctionner au mieux avec les autres services GCP. Ainsi, Workflows n’est pas l’orchestrateur le plus adapté pour orchestrer des services dans un environnement multi-cloud. Limitations et quotas : Google Workflows impose certaines limitations quant à l’utilisation de son service. Nous l’avons évoqué plus haut, la durée d’exécution globale d’un workflow ne peut pas excéder un an et celle d’une étape individuelle ne peut excéder 30 minutes, ce qui est plus restrictif et peut parfois poser des problèmes pratiques. ### Tarification du service Comme beaucoup de services GCP, Google Workflows fonctionne sur un modèle “pay-as-you-go”, uniquement à l’usage des ressources. Cela se traduit par le fait que l’utilisateur est facturé au nombre d’étapes exécutées chaque mois. Une distinction est faite cependant entre les étapes dites “internes” (celles faisant appel à un autre service GCP) et les étapes dites “externes” (celles faisant appel à un service non-intégré à GCP). Voici le détail de la facturation pour les étapes internes: - 0$ pour les 5000 premières étapes du mois - 0,01$ toutes les 1000 étapes, entre 5000 et 100M d’étapes Et pour les étapes externes: - 0$ pour les 2000 premières étapes du mois - 0,025$ toutes les 1000 étapes, entre 2000 et 100M d’étapes Dans les deux cas, pour un besoin allant au-delà de 100M d’étapes par mois, il est nécessaire de contacter le service commercial de GCP pour mettre en place une tarification spéciale. Attention: la facturation de Workflows est uniquement dépendante du nombre d'étapes exécutées, et pas de la longueur de celles-ci. Ainsi, la facturation d’une étape de 5 secondes et de 30 minutes sera identique. Cependant, si une étape d'un workflow implique, par exemple, l'appel d'un service Cloud Run durant un laps de temps important, cela entraînera bien une facturation en conséquence, mais seulement relative à l'utilisation de Cloud Run sur la plage de temps donnée. Workflows est donc une solution très avantageuse d’un point de vue financier, permettant l’exécution d’un nombre important d’étapes pour des coûts relativement faibles. ### Google Workflow : un outil puissant de la Modern Data Stack Google Workflows est un puissant outil d’orchestration serverless qui s’intègre parfaitement dans l’écosystème GCP. En outre, il permet des appels à des APIs externes pour un spectre d’action encore plus étendu, le tout pour des tarifs avantageux. Il est aussi adapté à l’utilisation au sein d’une organisation grâce à la possibilité de versionner les workflows, via l’utilisation conjointe de Terraform et Git. Il est cependant important de prendre en compte ses limitations, ainsi que sa courbe d’apprentissage initiale pour un développeur n’étant pas habitué à définir des flux en YAML. Comme toujours, il est essentiel d’étudier le besoin spécifique de l’entreprise avant de mettre en place une orchestration complète au sein de votre [Modern Data Platform](../../articles/modern-data-platform-definition-entreprise/index.html) utilisant ce service. Si vous souhaitez découvrir un cas d’usage concret de Google Workflows par Modeo, je vous conseille ce[webinaire](../../articles/webinar-modern-data-ingestion-using-airbyte-serverless-google-workflow-et-dbt/index.html) et pour en savoir plus sur nos offres et notre approche,[contactez-nous](../../contact.html) ! --- ## Comment Nickel a rendu ses équipes data totalement autonomes URL : https://modeo.ai/articles/comment-nickel-a-rendu-ses-equipes-data-totalement-autonomes > Retour d'expérience de Paul Marcombes, Head of Data de Nickel : comment le self-service a rendu les équipes data et métiers autonomes. ### Retour d’expérience avec Paul, Head of Data Nickel Ismael Goulani – Modeo : Bonjour Paul, pour commencer, peux-tu nous dire qui tu es et ce que fait Nickel ? Paul Marcombes – Head of Data chez Nickel : Bonjour ! Je suis Paul, responsable de la Data chez Nickel, une fintech qui permet d’ouvrir un compte courant dans les bureaux de tabac. Nous avons ouvert 4 millions de comptes en 11 ans. On est présents en France, mais aussi en Espagne, Belgique, Portugal et Allemagne. “Les débuts : une équipe data centralisée devenue un goulot d’étranglement” Ismael : Tu es arrivé il y a six ans chez Nickel. À quoi ressemblait l’organisation Data à ce moment-là ? Paul : On avait 300 employés, 1 million de clients… et seulement trois personnes en data. Une équipe centrale efficace, mais vite submergée. On est passés d’un rôle stratégique à une usine à tickets. Résultat : frustration des métiers et démotivation en interne. Ismael : C’est un classique : la scalabilité du modèle centralisé finit toujours par plafonner. Le vrai défi c’est d’en sortir intelligemment. Quel a été ton pari pour sortir de cette impasse ? Paul : On a commencé à recruter des data analysts directement dans les équipes métiers. Le premier analyste a mis en place des dashboards de suivi… puis un moteur de recherche dans la donnée. L’impact a été immédiat. Alors on a répliqué. Ismael : Effectivement Paul, dès qu’un analyste est au contact du terrain, il peut passer en mode proactif et générer de la valeur sans même qu’on lui demande. Bien joué. “Le changement : vers une organisation décentralisée et autonome” Ismael : Et où en êtes-vous aujourd’hui ? Paul : On est 40 dans l’équipe data dont 25 data analysts dans une dizaine d’équipes métiers. Leur particularité ? Ils sont full-stack : ingestion, transformation, documentation, dashboards, analyses et même déploiement d’algorithmes. Ils maîtrisent toute la chaîne. Ismaël : En fait, vous avez créé des mini start-up dans chaque équipe. Trois analystes pour 30 personnes : c’est un vrai centre de gravité data local ! ### Stack technique et vision plateforme Ismael : Quelle est votre stack ? Paul : Tout repose sur Google Cloud, - BigQuery pour le stockage - Cloud Run pour l’ingestion et le temps réel - BigTable pour les traitements rapides - DBT pour la modélisation - Looker Studio pour les dashboards Pas d’orchestrateur : chaque job est autonome et piloté depuis une interface web interne. ### Plateforme + communauté : un duo gagnant Ismael : Comment garder la cohérence entre autant de data analysts autonomes ? Paul : C’est simple Ismael, Deux leviers : - Une équipe centrale qui développe des apps standards (ex : notification, scoring, exports…) - Une communauté de data analysts animée par deux analytics engineers, qui définissent les bonnes pratiques. Ismael : C’est du platform engineering pur, vous construisez les briques, vous laissez les équipes jouer avec et vous orchestrez la symphonie. Paul : oui en quelque sorte, chaque équipe possède son dossier dédié dans un mono repo git, avec des règles d’organisation communes. Et les data analysts seniors valident les contributions. Résultat : autonomie + gouvernance. ### Choix de modèle Ismael : Pourquoi ne pas avoir adopté un data mesh “pur” avec analystes, data scientists et ingénieurs dans chaque équipe ? Paul : On voulait éviter la complexité et la dépendance croisée. Nos analysts full-stack sont capables de tout faire. Moins de frictions, plus de réactivité. Bien sûr, ça demande des outils solides et une gouvernance forte. ### Impact &, ROI : mesurer la valeur de la data Paul : Le ROI a évolué par étapes, - Visibilité des chiffres → transformation de la culture interne - Industrialisation des actions (emailing, scoring…) → gains de dev - Réduction de la fraude → impact mesurable immédiat - Aujourd’hui : les data analysts sont devenus de véritables co-pilotes métier. Ils ne se contentent plus de répondre aux demandes : ils identifient les points de friction dans les parcours ou les process, proposent des actions correctives et parfois les mettent en œuvre eux-mêmes grâce aux outils à leur disposition. Exemple : un analyste a mis en place un algorithme pour prédire les ruptures de stock en point de vente afin de déclencher automatiquement une commande via une simple requête SQL. ### Open Source et esprit de partage Paul : On a développé Big Functions, un outil open source pour permettre à un analyste SQL d'appeler des APIs, envoyer des événements à Kafka, déclencher des actions… le tout depuis BigQuery. Ismael : Ce genre d’outil, c’est la touche finale, tu donnes du super-pouvoir aux Analysts. Et tu fais rayonner ta culture data au-delà de l’entreprise et si tu devais résumer l’approche de Nickel en une phrase ? Paul : Empowerer les équipes métiers avec des profils data full-stack, des outils standards et une plateforme solide. Tout ça, sans jamais renoncer à la cohérence. ### Pour découvrir l'intégralité de ce Webinar, nous vous donnons RDV sur notre page Youtube, #### >, N'hésitez pas à vous abonner ici afin d'être alerté de nos dernières news ! ### Découvrez également " Comment piloter une équipe Data" avec Matthieu Rousseau, CEO de Modeo et Quentin de Carné --- ## Analytics Engineer : rôle, missions et compétences URL : https://modeo.ai/articles/le-role-de-lanalytics-engineer > L’Analytics Engineer est chargé de modéliser et transformer de la donnée pour la mettre à disposition des équipes métier, prête à l’emploi. ### Comment est apparu le métier d’Analytics Engineer ? Les équipes data traditionnelles se composaient de Data Engineers, en charge de la construction et de la maintenance de la Data Platform et des pipelines d'ingestion, et de Data Analysts dont la mission consistait à exploiter les données collectées pour en tirer de la valeur et les partager aux parties prenantes sous forme de rapports. Avec la démocratisation du cloud et l’apparition de la[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html), extraire et stocker de la donnée est devenu beaucoup plus accessible et rapide. L’approche data a alors radicalement changé et les équipes métier ont commencé à devenir de plus en plus autonomes dans l’exploitation de leurs données. Cela a cependant soulevé de nombreux défis et il est encore courant de voir deux équipes ayant deux valeurs différentes pour un même KPI et une même source de données, chacun effectuant ses calculs à sa manière avec des scripts SQL non maintenus. C’est dans un souhait d’uniformisation des processus de transformation de la donnée qu’apparaît le métier d’Analytics Engineer. Afin d’éviter que chaque équipe utilise des méthodes de calcul différentes tout en laissant une autonomie aux équipes dans leurs analyses, la donnée leur est transmise une fois transformée et nettoyée Il a été décidé de mettre à disposition des métiers des données transformées et pré-agrégées plutôt que des données brutes. Ce travail de modélisation et de transformation en amont des visualisations est alors fait par un Analytics Engineer, responsable de l’ensemble des opérations et chargé d’y appliquer des bonnes pratiques de développement. ### Comment est apparu le métier d’Analytics Engineer ? Les équipes data traditionnelles se composaient de Data Engineers, en charge de la construction et de la maintenance de la Data Platform et des pipelines d'ingestion, et de Data Analysts dont la mission consistait à exploiter les données collectées pour en tirer de la valeur et les partager aux parties prenantes sous forme de rapports. Avec la démocratisation du cloud et l’apparition de la[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html), extraire et stocker de la donnée est devenu beaucoup plus accessible et rapide. L’approche data a alors radicalement changé et les équipes métier ont commencé à devenir de plus en plus autonomes dans l’exploitation de leurs données. Cela a cependant soulevé de nombreux défis et il est encore courant de voir deux équipes ayant deux valeurs différentes pour un même KPI et une même source de données, chacun effectuant ses calculs à sa manière avec des scripts SQL non maintenus. C’est dans un souhait d’uniformisation des processus de transformation de la donnée qu’apparaît le métier d’Analytics Engineer. Afin d’éviter que chaque équipe utilise des méthodes de calcul différentes tout en laissant une autonomie aux équipes dans leurs analyses, la donnée leur est transmise une fois transformée et nettoyée Il a été décidé de mettre à disposition des métiers des données transformées et pré-agrégées plutôt que des données brutes. Ce travail de modélisation et de transformation en amont des visualisations est alors fait par un Analytics Engineer, responsable de l’ensemble des opérations et chargé d’y appliquer des bonnes pratiques de développement. ### Les missions de l’Analytics Engineer Les Analytics Engineers jouent un rôle essentiel dans l’exploitation de la valeur des données. Leurs missions sont les suivantes : #### Collaborer avec les équipes métier pour identifier leurs besoins S’il n’y a pas de Product Manager Data, il se peut que l’Analytics Engineer soit un point de contact direct pour les équipes métier ayant de nouveaux besoins. Il devra alors travailler avec elles pour comprendre leurs attentes, les cadrer puis les réaliser techniquement. Imaginons que l’équipe abonnement d’un média souhaite avoir des chiffres sur les retombées d’une nouvelle offre spéciale lancée l’été dernier. L’Analytics Engineer en charge devra dans un premier temps définir le périmètre de l’analyse, c’est-à-dire préciser quelle offre est concernée, quels canaux d’abonnement sont analysés, sur quelle période l’analyse doit être faite… Il devra également s’assurer que cette analyse n’a pas déjà été faite auparavant. Finalement, il développera un pipeline de transformation créant une table qui sera transmise à l’équipe abonnement pour qu’ils puissent y faire leurs analyses. #### Modéliser, transformer et tester la donnée pour la fournir prête à l’emploi L'une des principales responsabilités des Analytics Engineers est de mettre à disposition des équipes de la données pré-agrégée propres et cohérentes. Étant responsables de la modélisation et de la transformation, leur mission est de structurer les données, de les nettoyer et de les préparer en vue d’analyses ultérieures. Concrètement, les Analytics Engineers développent des pipelines de transformation de données, c’est-à-dire une série d'étapes permettant, à partir de données brutes, de fournir aux métiers une ou plusieurs tables de données propres et agrégées. L’exemple ci-dessous est très simplifié mais illustre le travail de transformation des Analytics Engineers. En partant d’une donnée brute dans la table raw_commandes, ils fourniraient aux équipes sales des tables présentant un récapitulatif des ventes par ville, par produit et par utilisateur. #### Mettre en place des bonnes pratiques de développement Il est attendu des Analytics Engineers qu’ils mettent en place des bonnes pratiques de software development telles que le versionning du code, des workflows de développement ou de la documentation. De cette façon, en s'inspirant des principes du génie logiciel, les Analytics Engineers veillent à ce que les pipelines soient durables et facilement maintenables. Cela permet également d’avoir une seule source de vérité au sein de l'entreprise, en évitant d’avoir plusieurs versions d’un même code ou plusieurs méthodes de calculs pour un même KPI. #### Accompagner les équipes métier dans l’utilisation d’outils de self-visualization Les Analytics Engineers ne se contentent pas de traiter les données ils donnent aux utilisateurs finaux les moyens de les explorer et visualiser en toute autonomie. Il s'agit alors d'organiser des sessions de formation pour les équipes, en leur apprenant à utiliser les outils d'analyse et à créer des visualisations pertinentes et impactantes. #### Documentation La rédaction de documents explicites et approfondis est indispensable pour maintenir la transparence et la traçabilité des opérations de données. Les Analytics Engineers jouent un rôle vital dans la création de cette documentation, enregistrant les processus et les transformations appliqués aux données, ainsi que les workflows établis. L'objectif de cette documentation est de promouvoir la clarté, la reproductibilité et le partage des connaissances au sein de l'équipe de données. ### Les compétences requises pour être Analytics Engineer Le rôle d'un Analytics Engineer est varié et requiert un mélange de compétences techniques et fonctionnelles dont les principales sont les suivantes : - Maîtrise de SQL : La maîtrise de SQL est essentielle pour un Analytics Engineer puisqu’une grande partie de son travail consiste à explorer, nettoyer et transformer de la donnée. Un bon Analytics Engineer doit pouvoir réaliser des requêtes SQL complexes et parfaitement optimisées. - Maîtrise de l’outil dbt :[dbt](https://www.getdbt.com/) (Data Build Tool) est outil de transformation de données utilisé pour transformer de la donnée stockée en base. C’est un outil largement utilisé qui permet de créer et automatiser des pipelines de transformation et de validation de données. C’est également un outil collaboratif permettant aux développeurs de travailler en parallèle grâce à Git et un système de branche. Maîtriser dbt est primordial pour un Analytics Engineer. - Connaissances des bonnes pratiques de software development : l’Analytics Engineer doit être en mesure d’instaurer des règles de bonnes pratiques et de s’assurer de leur adoption. Il doit également pouvoir identifier des améliorations dans les processus de développement relatifs aux pipelines de données. Cela passe par une bonne compréhension des règles de versionning, une connaissance des workflows de développement data (série d’étapes à suivre pour développer un pipeline de données par exemple) ainsi qu’une maîtrise de Git. - Compétences en visualisation de données : l’Analytics Engineer est amené à travailler avec les équipes métier pour les rendre autonomes dans l'exploration et l’exploitation de leurs données. Pour cette raison, il doit avoir des compétences en data visualization et maîtriser au moins un outil de Business Intelligence tel que[Tableau](https://www.tableau.com/),[Power BI](https://www.microsoft.com/en-us/power-platform/products/power-bi) ou[Metabase](https://www.metabase.com/). - Qualités relationnelles : Étant en contact direct avec des équipes métier pour comprendre leurs besoins et les accompagner dans la prise en main des outils data, l’Analytics Engineer doit être bon communicant et posséder de bonnes compétences relationnelles. Il doit savoir définir, questionner et reformuler des besoins puis les retranscrire techniquement. ### Les formations possibles pour devenir Analytics Engineer Il existe peu de formations pour devenir Analytics Engineer. En général, les Analytics Engineer suivent une formation similaire à celle des Data Analysts, c’est-à-dire en visualisation de données, statistiques et mathématiques. Cette formation peut être complétée par un diplôme plus commercial ou de management. Concernant les formations aux outils et logiciels, des sites comme [Udemy](https://www.udemy.com/) ou [OpenClassroom](https://openclassrooms.com/fr/) possèdent un grand nombre de cours de SQL, de Python ou de développement en général. dbt propose plusieurs offres de formation sur son [site Internet](https://www.getdbt.com/dbt-learn) pour les entreprises ou les développeurs individuels, chacune ayant différentes options de suivi et de personnalisation. ### Le salaire de l’Analytics Engineer D’après les sites[Glassdoor](https://www.glassdoor.fr/Salaires/analytics-engineer-salaire-SRCH_KO0,18.htm) et[Talent.com](https://fr.talent.com/salary?job=analytics+engineer), le salaire d’un Analytics Engineer varie entre 40 k€ et 70 k€ avec une médiane à 52 k€. Bien sûr, comme pour tout métier, la rémunération varie selon plusieurs critères dont l’expérience du candidat. De manière générale, un Analytics Engineer junior peut prétendre à un salaire entre 40 et 50 K €. Un Analytics Engineer plus expérimenté avec trois ans d’expérience peut espérer un salaire entre 45 et 60 K€. Le salaire peut monter jusqu’à 80 K € après 5 ans. Les Analytics Engineers de [Modeo](../../index.html) sont formés pour posséder un ensemble de compétences fonctionnelles et techniques indispensables à la bonne pratique de leurs fonctions. Avec un background technique de Data Engineer, ils sont capables de répondre à des demandes complexes et de mettre en place des systèmes robustes et optimisés tout en identifiant des opportunités métier. Si vous voulez en savoir plus sur notre approche et nos profils,[contactez-nous](../../contact.html) ! --- ## La Modern Data Stack et ses outils : panorama et bonnes pratiques URL : https://modeo.ai/articles/la-modern-data-stack-et-ses-outils > Ingestion, stockage, transformation, BI : panorama 2025 des outils de la Modern Data Stack et conseils pour composer votre propre data stack. ### La Modern Data Stack La Modern Data Stack est un ensemble d’outils et de technologies hébergés sur le Cloud, ayant pour but de collecter, traiter, stocker et visualiser des données. Ces outils peuvent fonctionner indépendamment ou interagir entre eux, permettant ainsi à chaque entreprise de créer sa propre combinaison, appelée sa "Data Stack". Il est courant de classer les outils de la Modern Data Stack en différentes catégories, selon leurs fonctionnalités spécifiques. Il faut cependant noter que les offres de chaque solution évoluent et que les éditeurs tendent aujourd’hui à élargir le panel de fonctionnalités pour créer des solutions de plus en plus complètes. Aujourd’hui, nous identifions six grandes briques fonctionnelles : ### Les 6 briques principales de la MDS : #### 1 - Data Ingestion #### 2 - Data Storage #### 3 - Data Transformation #### 4 - Data Activation (BI, ML, AI…) #### 5 - Data Orchestration #### 6 - Data Gouvernance (Observability, Catalog, Quality, Security…) Les principaux outils de la Modern Data Stack (il s'agit d'une sélection non exhaustive) : ### 1. Data Ingestion La Modern Data Stack contient de nombreux outils permettant de déplacer des données d’une ou plusieurs sources vers une destination. Des outils permettent d’acheminer les données depuis différentes sources vers une destination centralisée. #### • Fivetran : ingestion automatisée, prise en charge de nombreuses sources, sans scripts [Fivetran](https://www.fivetran.com/) est un service d'ingestion automatisé qui facilite la centralisation des données de multiples sources vers un entrepôt de données unique. Il se distingue par sa capacité à automatiser l'extraction, la transformation et le chargement (ETL) des données, permettant ainsi de ne pas avoir à développer de scripts personnalisés pour chaque source de données. Fivetran supporte une large gamme de sources de données, y compris des bases de données, des applications SaaS, et des plateformes cloud, ce qui en fait un outil clé pour les entreprises cherchant à simplifier leur infrastructure de données et à accélérer l'analyse des données. #### • Airbyte : open-source, large choix de connecteurs, interface intuitive. [Airbyte](https://airbyte.com/) est un outil open-source d'intégration de données qui permet aux utilisateurs de synchroniser leurs données de multiples sources. Sa nature open-source et sa communauté active contribuent à un catalogue croissant de connecteurs. Airbyte est conçu pour être facile à utiliser, offrant une installation simple et une bonne interface utilisateur, rendant l'automatisation des flux de données accessible à une large gamme d'entreprises. En parallèle, le fait que la solution soit open-source permet aux développeurs de personnaliser ou développer de nouveaux connecteurs en Python. #### • Popsink : streaming temps réel, connecteurs managés. [Popsink](https://fr.popsink.com/)est une plateforme d'intégration de données en temps réel qui modernise l'approche ETL grâce aux technologies de streaming. Elle permet de déplacer et d'exploiter les données en continu, à moindre coût par rapport aux mises à jour par batch. Popsink s'intègre facilement à votre stack existante, permettant d’optimiser les processus de données progressivement. Elle propose des connecteurs managés qui agissent comme sources et consommateurs de données, tout en garantissant la sécurité et la transparence des flux de données. #### dltHub : structuration automatisée, intégration rapide. [dltHub](https://dlthub.com/) est une librairie Python open source conçue pour une prise en main rapide. Elle permet de créer des connecteurs personnalisés en code, simplifiant ainsi l’ingestion des données structurées et non structurées. Les connecteurs développés avec dltHub génèrent des métadonnées qui facilitent l’intégration aux autres outils de la Modern Data Stack et renforcent la gouvernance des données. #### Python : langage pivot pour l’ETL personnalisé via bibliothèques comme Pandas, Airflow… [Python](https://www.python.org/) est un langage de programmation jouant un rôle central dans l’ingestion de données, notamment grâce à son écosystème riche en bibliothèques dédiées à l’extraction, la transformation et le chargement des données (ETL/ELT). Python est également le langage principal derrière de nombreuses solutions open-source d’ingestion comme Airbyte, Meltano ou dltHub, facilitant ainsi la création de connecteurs personnalisés et l’automatisation des pipelines. Sa flexibilité en fait un outil idéal pour gérer les cas d’usage non couverts par des solutions clés-en-main existantes, tout en restant lisible et maintenable par des équipes data. ### 2. Data Storage Il existe différents types de stockage de données, utilisés pour des cas d’usages différents selon la fréquence d’accès à la donnée, sa volumétrie. La Modern Data Stack propose des outils pour chacune des options, que ce soit pour du stockage de données sous forme de fichiers au format non défini (données non-structurées), sous forme d’images ou dans des bases de données avec des colonnes et des types fixes. #### • Snowflake : data warehouse cloud avec fonctions d’analyse intégrées. [Snowflake](https://www.snowflake.com/fr/) est un datawarehouse cloud parfaitement adapté au stockage et à l’analyse de très grands volumes de données. En plus du stockage, la solution offre également des fonctionnalités d'ingestion de données en lot (batch) ou en continu (streaming), d'analyses et de visualisation. Facilement intégrable avec divers outils et services de la Modern Data Stack, Snowflake supporte un large éventail de cas d'usage de données. Cette solution peut cependant rapidement se révéler onéreuse. #### • ClickHouse : base orientée colonnes, très performante en OLAP. [ClickHouse](https://clickhouse.com/) est une base de données open-source connue pour sa vitesse de traitement et ses performances remarquables sur de grands volumes de données. Orientée colonnes, cet outil est conçu pour des analyses OLAP (traitement analytique en ligne). ClickHouse propose une gamme étendue de fonctionnalités, telles que le traitement distribué des requêtes ou la compression des données. #### • Amazon Redshift : interface SQL, requêtes sur data lakes avec Redshift Spectrum. [Amazon Redshift](https://aws.amazon.com/fr/redshift/) est un data warehouse cloud entièrement managé, conçu pour stocker et analyser des jeux de données massifs. Il propose une interface SQL familière et s'intègre facilement avec divers outils de BI pour une analyse rapide et efficace. Grâce à Redshift Spectrum, il permet de requêter directement des données dans un data lake sans nécessiter de chargement préalable. La solution offre une scalabilité automatique pour répondre à l'évolution des besoins, tout en optimisant les coûts d'exploitation #### • BigQuery : solution serverless Google Cloud, rapide et scalable. [Bigquery](https://cloud.google.com/bigquery?hl=fr) est un data warehouse entièrement géré et sans serveur de Google Cloud. Il offre des performances d'interrogation rapides, une évolutivité et une rentabilité. Il est idéal pour les entreprises qui ont besoin d'analyser de grands ensembles de données rapidement et de manière rentable. Bigquery propose un vaste panel de services et s’intègre parfaitement avec d'autres services Google Cloud. Renseignez-vous sur ses fonctionnalités en détail dans[notre article sur BigQuery](../../articles/bigquery-overview/index.html) ! #### Amazon S3 : stockage d’objets simple, sécurisé, très scalable. [S3](https://aws.amazon.com/fr/s3/) est une solution de stockage d'objets d'Amazon Web Services (AWS). Il s'agit d'un moyen très évolutif, sécurisé et rentable de stocker des données. Il est facile à utiliser et peut être intégré à une multitude d'autres services. Il offre également une durabilité et une disponibilité élevées des données stockées. ### 3. Data Transformation La transformation des données brutes en données exploitables est primordiale pour tirer de la valeur de ses data. Ces traitements sont généralement planifiés, suivis et exécutés grâce à des outils d’orchestration. La Modern Data Stack contient de nombreuses solutions ayant ces finalités. #### • Databricks : moteur Spark, performant sur grands volumes, avec Delta Lake. [Databricks](https://www.databricks.com/fr) est une plateforme d'analyse de données basée sur le cloud qui combine puissance de calcul et stockage optimisé. Cette plateforme est étroitement liée à Spark, un moteur de traitement de données à grande échelle fondé sur un fonctionnement parallélisé en clusters. Databricks intègre un système de fichiers propriétaire, Delta Lake, qui améliore la gestion et la performance des données avec des fonctionnalités ACID (règles d’or des transactions en bases de données, atomicity, consistency, isolation, durability), permettant des analyses fiables et à grande échelle sur des données structurées et semi-structurées. #### • dbt : transformations versionnées, bonnes pratiques et collaboration intégrées. S’il y a bien un outil de transformation de données incontournable depuis quelques années, c’est[dbt (Data Build Tool)](https://www.getdbt.com/). dbt est une application open-source qui aide les data engineers et les data analystes à construire, maintenir et documenter les transformations de données. C’est la capacité de cet outil à favoriser les bonnes pratiques de développement, comme le versionnage et la réutilisation de code, et le travail en équipe sur la partie de retraitement des données qui a fait sa renommée. ### 4. Data Activation La couche d’activation de la donnée est la finalité d’une Modern Data Stack en proposant de déployer toutes ces couches d’activation (parfois plusieurs en parallèle). C’est ici que les données seront exploitées à leur plein potentiel, pour différents cas d’usage, parmi lesquels : - la visualisation de données ou “data visualisation” - l’automatisation de workflows - l’activation marketing en réinjectant des données dans des outils CRM, publicitaires ou d’emailing pour des campagnes personnalisées - la modélisation prédictive, en utilisant des modèles d’IA, de machine learning... permettant la mise en place d’algorithmes de recommandation, de personnalisation produit. #### • Dataiku : data science accessible, modélisation prédictive sans code. [Dataiku](https://www.dataiku.com/) est une plateforme pour gérer des projets de data science et d’IA de manière collaborative entre des experts et les équipes métier. Elle offre des outils visuels pour la préparation des données, la modélisation prédictive et le déploiement de modèles d'IA, rendant l'analyse de données accessible à tous les niveaux d'expertise. Les fonctions intégrées d'apprentissage automatique permettent notamment aux utilisateurs de créer des modèles de prédiction sans codage. #### • Looker Studio : visualisation simple via Google, création de rapports. [Looker Studio](https://cloud.google.com/looker/?hl=fr) est un outil de Business Intelligence conçu pour être facile et rapide à utiliser. Il permet aux débutants comme aux experts de créer des visualisations de données et des rapports à l'aide des outils de Google. Il s'intègre de manière transparente à Google Analytics, Google Sheets et d'autres services, et propose un générateur de rapports par drag-and-drop. Il facilite également le partage et l'intégration des rapports. #### • Toucan : storytelling de données, tableaux de bord embarqués [Toucan](https://www.toucantoco.com/fr/)est une solution française de visualisation de données conçue pour rendre l’analytics accessible, engageant et actionnable pour tous, notamment les décideurs non techniques. Pensée dès le départ pour l’embedded analytics, Toucan permet d’intégrer simplement des visualisations de données dans des produits, portails ou tableaux de bord internes. Son approche centrée sur le data storytelling facilite la lecture des graphiques et la compréhension des enjeux, encourageant ainsi une véritable culture de la donnée dans les organisations. #### • Tableau : dashboards interactifs, interface drag-and-drop. [Tableau](https://www.tableau.com/fr-fr)est un outil de visualisation de données puissant permettant de transformer des données complexes en tableaux de bord interactifs. Son interface drag-and-drop permet de créer facilement des rapports détaillés sans compétences techniques avancées. Tableau se connecte à une large gamme de sources de données, y compris les plateformes cloud et les bases de données relationnelles. Il offre également des fonctionnalités de collaboration en temps réel et d'analyse approfondie, rendant les insights accessibles à tous. #### • Metabase : BI open-source, accessible sans SQL. [Metabase](https://www.metabase.com/) est une plateforme open-source de business intelligence (BI) qui permet aux utilisateurs de visualiser et de partager des informations à partir de leurs données sans nécessiter de compétences en SQL. Facile à installer et à utiliser, l’approche intuitive de l'exploration de données rend Metabase accessible à tous les niveaux de compétence technique, favorisant ainsi une culture de données démocratisée au sein des organisations. #### • Omni : nouvelle génération de self-BI, pensée pour les équipes métier. [Omni](https://omni.co/)est une solution moderne de data visualisation pensée pour démocratiser la Business Intelligence (BI) au sein des équipes métier. Basée sur un semantic layer, Omni permet aux utilisateurs de manipuler, transformer et visualiser leurs données directement dans l’interface produit, avec une approche hyper intuitive. Cette flexibilité rend l’analyse accessible même sans compétences techniques avancées. La solution permet aussi de faciliter la collaboration entre les équipes Data et métier. Conçue par d’anciens membres de l’équipe Looker, la plateforme incarne une nouvelle génération d’outils de self-BI, combinant puissance analytique et simplicité d’usage. Bien qu'encore récente, Omni s’impose progressivement comme une solution incontournable sur le marché des outils d’activation de données, en particulier dans les organisations en quête d’autonomie et d’agilité dans leurs décisions basées sur la donnée. ### 5. Data Orchestration La planification et l’automatisation des pipelines de données sont des éléments clés pour garantir un traitement fluide, fiable et reproductible des flux de données. La Modern Data Stack propose plusieurs outils d’orchestration qui permettent de gérer les dépendances entre tâches, de planifier les exécutions et de superviser les workflows de bout en bout. Ces solutions assurent la cohérence, la traçabilité et l’optimisation des traitements dans des environnements complexes et en constante évolution. #### • Apache Airflow : gestion des tâches, langage Python [Apache Airflow](https://airflow.apache.org/) est un orchestrateur open-source utilisé pour la gestion et la planification des pipelines de données. Combiné à Python, il peut être utilisé pour automatiser les tâches de transformation des données, créer des data pipelines complexes et surveiller le processus de transformation des données. #### • Dagster : orchestration complète avec validation intégrée. [Dagster](https://dagster.io/) est un orchestrateur de données qui gère les data pipelines, les dépendances et la qualité des données. Il fournit un cadre unifié pour construire, tester et déployer des data pipelines. La fonction principale de Dagster est l'orchestration, permettant aux utilisateurs de définir et de planifier des flux de data complexes impliquant de multiples tâches et dépendances. Il comprend des fonctionnalités permettant de surveiller et d'assurer la qualité des données tout au long du pipeline, telles que la validation des données et la gestion des erreurs. #### • Prefect : surveillance temps réel des workflows, déploiement cloud ou local. [Prefect](https://www.prefect.io/) est un outil d’orchestration moderne conçu pour automatiser, planifier et surveiller les workflows de données de manière flexible et fiable. Il permet aux équipes data de construire des pipelines robustes en Python, avec une gestion fine des dépendances, des erreurs et des exécutions. Grâce à son interface intuitive et son architecture orientée cloud ou on-premise, Prefect facilite le déploiement et le suivi des tâches, tout en offrant une grande visibilité sur l’état des workflows en temps réel. ### 6. Data Observability &, Gouvernance Cette brique vise à garantir la qualité, la conformité et la traçabilité des données. Elle regroupe des outils permettant de surveiller les pipelines, détecter les anomalies et centraliser les métadonnées pour une gouvernance fiable et évolutive. #### • Dinmo : CDP composable, activation marketing. [DinMo](https://www.dinmo.com/fr/) est une Customer Data Platform composable qui permet de centraliser et d'unifier les données clients dans une infrastructure existante. Elle facilite la création d'audiences et l’activation des données dans divers outils comme les plateformes publicitaires ou CRM. DinMo se distingue par sa capacité à enrichir les données avec des attributs prédictifs, améliorant ainsi la personnalisation des campagnes. La solution est scalable et permet une activation rapide des données, tout en offrant une sécurité renforcée sans duplication de données. [Demandez notre guide gratuit sur la CDP 'Customer Data Platform &, IA' - Modeo x Dinmo (en français ou en anglais) .](../../contact.html) #### • Monte Carlo : observabilité automatisée avec IA. [Monte Carlo](https://www.montecarlodata.com/) est une solution de data observability qui utilise l'intelligence artificielle pour surveiller, identifier et corriger les problèmes de qualité des données à travers les systèmes. Elle aide les organisations à prévenir les interruptions de données et à garantir la précision des insights pour la prise de décision. #### • DataHub : plateforme open-source de métadonnées. [DataHub](https://datahub.io/) est une plateforme de métadonnées open-source pour la découverte de données, conçue pour centraliser et organiser les informations sur les données au sein d'une entreprise. Elle facilite la recherche et la compréhension des données à travers une vue unifiée, améliorant la gouvernance, la collaboration et la gestion du cycle de vie des données. #### • Sifflet : détection proactive d’anomalies, surveillance continue. [Sifflet](https://www.siffletdata.com/)est un outil de data observability conçu pour surveiller en continu la santé des pipelines et la qualité des données. Il permet de détecter proactivement les anomalies, les ruptures de schéma ou les problèmes de rafraîchissement et de mise à jour des données, tout en offrant une visibilité claire sur les flux de données à travers l’ensemble de la Stack. En centralisant les alertes et les métadonnées, Sifflet facilite l’orchestration des interventions et renforce la fiabilité des systèmes data, en permettant aux équipes de réagir rapidement en cas d’incident. Pour aller plus loin, - Explorez la carte interactive de la Modern Data Stack sur [mad.firstmark.com](https://mad.firstmark.com/) - Notre article [Modern Data Platform &, Stack : les fondamentaux à connaître pour exploiter vos données avec efficacité](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html) --- ## Construire une Modern Data Platform : Guide complet URL : https://modeo.ai/articles/le-guide-pour-reussir-limplementation-de-votre-modern-data-platform > Les Modern Data Platforms sont essentielles pour les entreprises souhaitant devenir data-driven. Guide complet pour réussir son implémentation. ### La Modern Data Platform, la solution incontournable Une Data Platform est une solution complète destinée à gérer des données issues de sources variées au sein d'une entreprise. En agissant comme un hub central, elle supervise l'ensemble du cycle de vie des données, depuis leur ingestion jusqu'à leur restitution. Concrètement, c’est une solution qui collecte, stocke, traite, agrège et analyse toutes les données d’une entreprise. Les Data Platforms étaient autrefois des systèmes informatiques lourds et complexes, destinées à des entreprises disposant d’importants moyens financiers et techniques. Les évolutions technologiques ont permis de revoir la façon dont sont construites les Data Platforms et ces solutions sont aujourd’hui un ensemble d’outils interconnectés, spécialisés dans des tâches spécifiques comme l’ingestion de la donnée, le retraitement ou la visualisation. Ces outils font partie d’un ensemble appelé[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html) et les Data Platforms sont alors devenues des[Modern Data Platforms](../../articles/modern-data-platform-definition-entreprise/index.html). Pour en savoir plus sur les Modern Data Platforms et la Modern Data Stack, n’hésitez pas à consulter nos articles “[Qu’est-ce qu’une Modern Data Platform ?](../../articles/modern-data-platform-definition-entreprise/index.html)” et “[Tout ce que vous devez savoir sur la Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html)”. ### La Modern Data Platform, un outil indispensable à toutes les entreprises L’utilisation d’une Modern Data Platform transforme totalement la manière dont vous travaillez avec vos données. C’est un avantage concurrentiel indéniable pour une entreprise qui a alors à sa disposition une solution de stockage efficace et centralisée, d’excellentes capacités de calculs et d’analyse et la possibilité de créer et de suivre des indicateurs clés de performances à l’aide de solutions de visualisation et méthodes de calculs unifiées pour un coût très abordable. Il est primordial aujourd’hui de mettre à profit ses données et d’en tirer des enseignements pour mieux mesurer les conséquences de ses actions et prendre les bonnes décisions. Cela est valable pour un vendeur qui souhaiterait suivre ses ventes et mieux comprendre sa clientèle, une entreprise qui souhaiterait mesurer l’impact de ses campagnes publicitaires ou une entreprise de livraison souhaitant optimiser les temps de trajet de ses livreuses et livreurs. Les outils actuels permettent de construire très rapidement et pour un faible coût des solutions data prêtes à l’emploi et testables sur des périmètres restreints avant de choisir de les généraliser ou non. ### Les critères de performance d’une Modern Data Platform L’évaluation des performances d’une Modern Data Platform peut être faite en s’appuyant sur quelques critères déterminants. Avant de se lancer dans la construction de sa Data Platform, il est essentiel de clarifier ses besoins sur chacun de ces critères pour partir dans la bonne direction et s’assurer que les choix faits lors de la construction ne pénaliseront pas les évolutions futures. Les critères principaux sont : - Coûts : construire une Data Platform a un coût (coûts de build) mais il ne faut pas oublier que la faire tourner peut également coûter cher (coûts de run), surtout si les solutions ne sont pas bien configurées. Chaque fournisseur propose différentes offres et niveaux de prix, ce qui peut rapidement être onéreux. - Évolutivité : la Data Platform doit durer dans le temps et pouvoir évoluer avec la technologie. Elle doit pouvoir intégrer facilement et rapidement de nouveaux outils et de nouvelles fonctionnalités. - Scalabilité : la Data Platform doit être designée pour scaler, c’est-à-dire pour être déployée à grande échelle. - Accessibilité : la Data Platform doit permettre aux équipes d’accéder facilement à la donnée. Cette accessibilité est assurée par des services mettant à disposition la donnée et une organisation adaptée (équipes data, data owners…). - Sécurité et compliance : la Data Platform doit intégrer des normes de sécurité et de compliance pour assurer la confidentialité des données, les droits d’accès des utilisateurs et le respect des normes en vigueur. - Maintenabilité : la Data Platform doit être construite de façon à être facilement maintenable. Cela passe par un développement structuré et rigoureux mais également par de la documentation à chaque étape. - Autonomie : une entreprise doit pouvoir, si elle le souhaite, être en partie autonome sur sa Data Platform pour implémenter de nouveaux cas d’usages, ajouter de nouveaux outils ou ajuster des fonctionnalités. ### Construire sa Modern Data Platform en cinq étapes clés Chez [Modeo](../../index.html), nous avons eu l’occasion d’implémenter des dizaines de Data Platforms pour des profils de clients très variés et nous avons identifié des étapes clés communes à tous les projets. Ces étapes sont essentielles pour assurer le succès de l’implémentation. #### 1. Planifiez la façon dont les données seront utilisées par les métiers La toute première phase d’un projet d’implémentation d’une Data Platform est d’identifier les domaines dans lesquels les données peuvent apporter de la valeur et de créer des objectifs commerciaux. Cette étape est la plus importante car mettre en place une Modern Data Platform sans objectif derrière est une perte d'argent et de temps. Pour cette étape, il peut être utile d’avoir une idée approximative des données avec lesquelles votre entreprise interagit (données clients, données produits, données de trafic, données comptables, etc.) et de leurs principales sources (ERP, site, fournisseur tierce, etc.). Suite à cela, créez une vision claire de vos objectifs et partagez la vision avec l'ensemble des équipes qui seront concernées par la data. Il est essentiel d'insuffler une culture data au sein de toute l’entreprise pour que la donnée soit adoptée par tous les collaborateurs. Identifiez également les utilisateurs de la Data Platform pour savoir si ce seront des utilisateurs techniques ou non et avoir une idée du nombre afin d’anticiper les coûts des fournisseurs. Cela aura inévitablement une influence sur les solutions sélectionnées et leur accessibilité. #### 2. Identifiez des cas d’usage Avant de commencer l’implémentation de votre Data Platform, définissez des cas d’usage business que vous souhaiteriez mettre en place comme par exemple la suggestion de contenu personnalisé sur votre plateforme de e-commerce ou la segmentation de votre base clients pour du marketing ciblé. Cette identification vous permettra notamment de déterminer certains critères essentiels à prendre en compte tels que la volumétrie de données, la fréquence de traitement (temps réel ou par lot) ou les aspects sécuritaires (confidentialité de la donnée, anonymisation…). Ces critères seront pris en compte lors du choix des solutions par la suite. #### 3. Évaluez les compétences et capacités de vos équipes Il est important d’analyser les compétences de vos équipes et leur capacité à apprendre de nouveaux outils et de nouvelles technologies. Déterminez si vous aurez les ressources nécessaires pour suivre le projet de création de la Data Platform, implémenter de nouveaux cas d’usage et assurer la maintenance de la plateforme. Si ce n’est pas le cas, vous pouvez faire appel à une entreprise spécialisée dans le domaine comme[Modeo](../../index.html) pour assurer un suivi et accompagner vos équipes dans la prise en main des données et la maintenance de la Data Platform. Le choix des outils devra être fait selon les compétences de vos équipes. Par exemple, si votre équipe n’a pas de compétence en DevOps, il sera préférable d’opter pour des solutions SaaS (Software as a Service), hébergées par leur fournisseur. L'évaluation des outils de cette manière facilite le processus d'adoption et maximise les capacités de l'équipe. #### 4. Explorez, testez et validez les outils de manière itérative avec des Proofs Of Concept Une fois que vous êtes certains d’avoir besoin d’une Data Platform et que vous avez étudié l’ensemble de vos besoins et contraintes, vous pouvez commencer l’implémentation et choisir les outils qui constitueront votre Data Platform. La Modern Data Stack est composée de dizaines de solutions et il est difficile de s’y retrouver. Son principal avantage est qu'elle est flexible et modulaire, ce qui fait que sa mise en place nécessite beaucoup moins d'investissements qu'auparavant. En effet, il est possible de déterminer l'outil le mieux adapté à chaque étape en le testant, notamment grâce à des Proofs of Concept (POC). Les POCs sont réalisées sur de petits projets pour tester la faisabilité d’un outil et déterminer s’il répond aux besoins (contraintes actuelles mais également contraintes futures comme l’évolutivité ou la scalabilité). Vous pourrez répéter et réajuster cette étape au fur et à mesure de l'évolution de vos activités. Par exemple, si vous souhaitez utiliser un outil d'orchestration, vous pouvez réaliser un POC pour tester[Airflow](https://airflow.apache.org/) sur un petit périmètre et évaluer les avantages et la complexité de la mise en œuvre. Si la solution est validée, le projet peut être étendu dans le cas contraire, un nouveau POC peut être défini pour tester une autre solution telle que[Dagster](https://dagster.io/). Pour avancer dans la mise en œuvre de votre Data Stack, il faut se concentrer sur un processus à la fois. Après avoir déployé un petit nombre de cas d'utilisation, demandez aux équipes de vous faire part de leurs retours et incorporez-les pour répondre à des besoins et des défis spécifiques. #### 5. Déployez la plateforme en production Une fois les POCs validés et les retours des utilisateurs intégrés, la mise en production peut être commencée. C’est une étape cruciale qui nécessite une planification et une exécution méticuleuses. Les processus existants et les nouveaux processus développés sont migrés vers le nouveau système après avoir été testés et optimisés. Simultanément, la documentation et la formation des équipes permettent de s'assurer qu'elles sont prêtes à utiliser efficacement la nouvelle Data Platform. Le projet ne s'arrête pas là car une fois que la Data Platform est déployée, la surveillance régulière, la maintenance et les optimisations du système sont importantes pour son bon fonctionnement. La phase de production marque le début d'une ère axée sur les données pour votre entreprise et, avec elle, la capacité d'exploiter tout le potentiel de votre infrastructure de données. ### La planification, la clé de la réussite de votre projet Implémenter une Data Platform est un projet complexe qui ne se résume pas qu’à des challenges techniques. C’est un projet de grande envergure qui a des implications techniques, organisationnelles et humaines. Une implémentation pas parfaitement étudiée, planifiée ou exécutée peut entraîner une importante perte de temps et d’argent. Un risque majeur est également la non-adoption de la donnée par les équipes métier et une utilisation bien en-dessous des capacités à disposition. Il est fortement recommandé de se faire accompagner lors de ce projet pour maximiser vos chances de réussite et bénéficier de l’expérience et l’expertise d’entreprises spécialisées dans le domaine. Chez[Modeo](../../index.html), nous adoptons une démarche itérative en étroite collaboration avec chaque équipe métier de l’entreprise. Cette approche nous assure une parfaite adoption des outils et une satisfaction chez toutes les parties prenantes. Si vous êtes intéressés par notre approche ou souhaitez en savoir plus sur les Data Platforms, n'hésitez pas à[nous contacter](../../contact.html) ! --- ## Tendances Data Engineering 2024 et implications pour 2025 URL : https://modeo.ai/articles/les-10-tendances-majeures-observees-en-data-engineering-et-leurs-implications-pour-2025 > Les grandes tendances Data Engineering 2024 : Snowflake, DataOps, IA et plus. Préparez vos projets 2025 avec notre rétrospective complète. ### 1. Snowflake et BigQuery prennent le dessus sur Redshift En 2024, Snowflake et BigQuery se sont imposés comme les choix privilégiés des entreprises, avec un recul marqué de Redshift. Pourquoi ? - Snowflake séduit pour son ergonomie, son système RBAC, son expérience développeur et ses performances. - BigQuery est souvent choisi pour son faible coût, sa facilité de déploiement et son intégration naturelle dans l’écosystème GCP. - Redshift, en revanche, peine à s’adapter aux besoins modernes : UX vieillissante et limitations sur les cas d’usage en temps réel. Focus niche : ClickHouse reste utilisé pour des projets spécifiques comme l’embedded analytics ou les environnements on-prem, mais sa complexité limite son adoption. ### 2. DataOps : le moteur de la standardisation des données Les entreprises ont compris que, sans DataOps, leurs plateformes data risquent d’accumuler de la dette technique et de ralentir les projets. En standardisant les processus, elles : - Améliorent la fiabilité des données - Accélèrent les projets grâce à des workflows optimisés - Mettent en place des pratiques structurées pour éviter le chaos dans les grandes organisations. À ne pas manquer : [Notre podcast sur le DataOps explique comment passer de la théorie à l’action.](https://youtu.be/BgTYRPBrwLY?si=GYVT5HtLrv1mJseo) ### 3. Retour en force du on-premise pour des raisons stratégiques 2024 marque un tournant, avec un regain d’intérêt pour les solutions on-premise. Pourquoi ce changement ? - Coûts réduits : Construire sur de l’open source permet d’éviter les frais récurrents des solutions managées. - Protection des données : La souveraineté est devenue un argument commercial différenciant. - Autonomie des équipes : Les équipes data préfèrent développer leurs propres solutions plutôt que dépendre d’outils externes. Cette tendance reflète une volonté des entreprises de reprendre le contrôle sur leurs infrastructures. ### 4. DuckDB : un buzz limité par une adoption lente Si DuckDB fait beaucoup parler, son adoption reste restreinte à des cas spécifiques. - Cas d’usage : Tests de qualité, optimisation des coûts ou protection des données sensibles. - Limites : Connectivité réduite et UX qui ne permet pas de remplacer un data warehouse comme Snowflake ou BigQuery. Son potentiel reste à surveiller, mais il s’adresse encore à une niche de projets. ### 5. Orchestrateurs serverless : réduire les coûts au maximum Les orchestrateurs serverless (Google Workflow, AWS Step Functions) gagnent du terrain face aux solutions traditionnelles comme Airflow ou Dagster. Pourquoi ? - Les orchestrateurs traditionnels nécessitent une infrastructure toujours active, souvent coûteuse. - Les orchestrateurs serverless offrent une alternative économique, avec des coûts de quelques centimes par mois. Pour les entreprises qui cherchent à optimiser leur stack, c’est une solution évidente. ### 6. DBT omniprésent, mais encore perfectible DBT est devenu un standard pour les transformations de données, mais son utilisation à grande échelle pose des défis : - Standardiser l’usage de DBT dans les grandes organisations reste complexe. - Les équipes DataOps mettent en place des "DBT Factory" pour structurer les déploiements et guider les équipes. - L’adoption par des profils peu techniques reste un enjeu majeur pour 2025, avec un besoin accru de formation. ### 7. L'empreinte carbone des Data Platforms devient secondaire Alors qu’en 2023 l’impact carbone des plateformes data était central, en 2024, le sujet est passé au second plan. Pourquoi ? - L’essor de projets GenAI, très énergivores, a déplacé le débat environnemental vers l’intelligence artificielle. - Les discussions sur la durabilité se concentrent désormais sur les modèles IA plutôt que sur les plateformes data elles-mêmes. ### 8. Observabilité des données : le pilier des projets GenAI L’observabilité est devenue la priorité numéro un des décideurs Data. Les questions stratégiques incluent : - Comment prévenir les équipes métiers en cas d’incident ? - Quels outils mettre en place pour favoriser l’adoption (data catalogs, solutions de self-BI) ? La qualité des données est essentielle pour instaurer la confiance des métiers et pour réussir les projets GenAI, qui nécessitent des bases solides. ### 9. ChatGPT booste la productivité des Data Engineers, mais reste limité En 2024, ChatGPT a permis d’accélérer certaines tâches des Data Engineers. Cependant, son potentiel est limité par : - L’absence d’accès direct à la Data Platform, ce qui réduit son efficacité. - Les préoccupations liées à la protection des données, compliquant son adoption dans les environnements sensibles. Et si Modeo lançait le premier agent Data Engineer en 2025 ? Stay Tuned ... ### 10. Data Platforms matures : IA et adoption métier comme leviers clés Pour les Data Platforms arrivées à maturité, deux stratégies dominent en 2024 : 1️- Investir dans l’IA et la Data Science, avec des cas d’usage à forte valeur ajoutée. 2️- Rendre les données accessibles aux équipes métiers, grâce à des outils comme les Data Portals. Ces approches maximisent le ROI tout en renforçant l’impact stratégique des plateformes. ### Conclusion : les priorités pour 2025 Les tendances de 2024 vont se poursuivre en 2025, avec quelques évolutions majeures : - DataOps pour accélérer les workflows et fiabiliser les données. - Observabilité pour renforcer la confiance des métiers. - Optimisation des coûts et démonstration du ROI des projets data. - GenAI, qui connaîtra une accélération prudente en raison des défis écologiques et techniques. ### Prêt à préparer 2025 avec nous ? Contactez Modeo pour discuter de vos projets Data ! ### -- ### Visionnez notre podcast sur Youtube pour 'Tout Comprendre sur le DataOps' --- ## Tuto I Convertir le Langage Naturel en SQL grâce aux LLM URL : https://modeo.ai/articles/convertisseur-nl-sql-llm > TUTO I LLM (Large Language Mode) au service de la Self-BI. Les steps pour transformer vos requêtes en langage naturel en SQL! ### Introduction Imaginez pouvoir interagir avec vos données comme avec un ami : poser des questions, récupérer des informations, les modifier, et obtenir des résultats instantanément. C'est ce que permettent des outils comme ChatGPT, Mistral AI, Llama, et bien d’autres. Aujourd'hui, ces solutions sont largement utilisées, notamment pour leur simplicité et leur efficacité. Cependant, peu de personnes comprennent les technologies sous-jacentes : l'intelligence artificielle (IA) et le machine learning (ML). Dans cet article, nous allons explorer ce qu'est un modèle de langage de grande taille, ou Large Language Model (LLM) en anglais. Nous examinerons l'utilisation des requêtes en langage naturel dans le contexte de la Self-BI, et verrons comment implémenter un LLM avec des outils comme Vanna et Streamlit, et comment exploiter pleinement cette technologie pour aller encore plus loin. C’est parti ! ### Qu’est-ce que le LLM ? Un LLM est un modèle d'IA qui utilise le deep learning pour comprendre et générer du texte en langage naturel. Les LLMs, comme GPT-3, sont entraînés sur de vastes quantités de données textuelles comme des livres, des articles et des conversations, ce qui leur permet de saisir le contexte et la subtilité du langage humain. Ils sont composés de millions, voire de milliards de paramètres ajustés pour produire des réponses cohérentes et contextuellement appropriées. Pour ce faire, ils s'appuient sur une architecture de type transformers. Un Transformer est un modèle présenté en 2017 dans un article désormais très connu, intitulé « Attention is All You Need », par des équipes de Google et de l'Université de Toronto. Le Transformer repose sur des mécanismes d'attention ainsi que sur des réseaux de neurones entièrement connectés, permettant de traiter les données non plus de manière séquentielle, c'est-à-dire mot par mot, mais en accordant à chaque mot l'attention des autres mots. Cela rend le traitement plus rapide et efficace tout en comprenant les relations complexes au sein du texte. ### Pourquoi utiliser les LLM ? Dans le contexte de la Business Intelligence (BI), l’exploration et l’exploitation de la donnée ont toujours été un frein pour les utilisateurs métier non techniques qui devaient s’appuyer sur des Data Analysts ou des [Analytics Engineers](../../articles/le-role-de-lanalytics-engineer/index.html) pour sortir le moindre indicateur ou information des données dont ils disposaient. Avec des solutions LLM, ces utilisateurs peuvent maintenant interagir avec des systèmes de données complexes en utilisant des phrases simples et courantes, sans avoir besoin de maîtriser des langages de programmation comme SQL ou des outils d'analyse de données complexes. Ainsi, on remarque un gain de temps considérable pour les tâches d’activation de la donnée comme les rapports, les dashboards et l’utilisation de modèles d'IA. En effet, les processus qui nécessitaient auparavant l'intervention de spécialistes en data science ou en informatique peuvent désormais être exécutés directement par les utilisateurs métiers, ce qui simplifie et accélère la prise de décision. ### Tutoriel: Création d’un module Text-to-SQL avec Vanna Dans cette section, nous examinerons un cas d'utilisation basé sur un jeu de données de test disponible [ici](https://www.kaggle.com/datasets/berkayalan/retail-sales-data/data). Pour ce faire, nous utiliserons [Vanna](https://vanna.ai/) pour l'analyse des données et [Streamlit](https://streamlit.io/) pour l'interface utilisateur. Vanna est un package Python utilisant la technique de Recherche-Augmentation-Generation (RAG) pour générer des requêtes SQL à partir de texte en langage naturel, grâce à des modèles de Langage de Grande Échelle (LLM). Dans notre cas, le LLM utilisé sera celui développé par OpenAI. Streamlit est une librairie open source Python permettant de créer rapidement et facilement des applications web interactives. Cette librairie simplifie la visualisation des données en fournissant une interface utilisateur très simple d'utilisation. #### Configuration du modèle Tout d'abord, importons les bibliothèques Python nécessaires pour entraîner notre modèle : Ensuite, configurez Vanna en récupérant la clé API ainsi que le modèle contenant les métadonnées, qui, dans ce cas, est notre jeu de données test provenant du compte Vanna. Puis, connectons nous à la base de données Postgres: Maintenant que le modèle et la base de données sont configurés, il nous reste à fournir au modèle le schéma des données stockées dans la base PostgreSQL pour procéder à la phase d'entraînement : #### Configuration de l’interface Afin de mettre en place l'interface utilisateur il nous faut importer les packages Python ainsi que les modèles: A noter que la récupération de la clé API et du nom pour le modèle se fait à travers un fichier .streamlit/secrets.toml structuré de la manière suivante: Ce code permet de générer des requêtes SQL en fonction des questions saisies par l'utilisateur : #### Analyse des résultats Conclusion: Le projet fonctionne bien pour des requêtes très simples mais présente plusieurs limitations pour: - Les cas complexes, l'utilisateur doit bien connaître le modèle de données pour générer la requête correcte. - Les jointures proposées ne sont pas toujours appropriées (JOIN vs LEFT JOIN). - Les requêtes mal optimisées peuvent engendrer des coûts significatifs. Bien que les résultats du Text-to-SQL présentent certaines limitations, il est possible de les surmonter par des ajustements techniques appropriés. ### Comment aller plus loin ? Afin de pallier les problèmes rencontrés précédemment, on pourrait utiliser une couche sémantique pour structurer et clarifier les données de manière plus efficace. Cette approche permettrait non seulement de définir précisément les termes et contextes, mais aussi de cartographier les relations entre les différentes sources de données. Enfin, intégrer des contrôles de sécurité robustes garantirait que les données sensibles sont protégées. - Terminologie et contexte: La couche sémantique comprend les définitions des termes et du contexte permettant d'obtenir des résultats cohérents. Prenons l'exemple du terme « marge brute ». Ce terme est spécifié dans la couche sémantique, ainsi, lorsque les utilisateurs métiers recherchent des informations sur la « marge brute » dans leur outil de BI, le système est capable d'identifier quelles données extraire en se basant sur les sources de données disponibles. - Relation entre les sources et les données: La couche sémantique relie les termes et concepts aux sources de données disponibles. Cela implique de préciser quelles tables et colonnes de la base de données correspondent à chaque terme. Cette cartographie permet aux outils de BI d'extraire les données les plus pertinentes. - Données confidentielles: Au-delà de l'analyse de données, l'aspect sécurité ne doit pas être négligé. Les consommateurs de données doivent avoir des rôles définis qui leur permettent d'accéder uniquement aux informations autorisées. Une problématique potentielle serait l'accès à des résultats via des données intermédiaires qui, par défaut, ne devraient pas apparaître, car elles pourraient être sensibles ou non conformes au RGPD. Que vous cherchiez à simplifier l'accès aux données ou à automatiser des requêtes complexes, nous avons l'expertise pour vous accompagner dans cette révolution digitale. [Contactez-nous](../../contact.html) pour découvrir comment nous pouvons adapter ces technologies à vos besoins spécifiques et accélérer votre prise de décision ! --- ## Modern Data Platform & Stack : Les fondamentaux à connaître URL : https://modeo.ai/articles/modern-data-stack-tout-ce-que-vous-devez-savoir > Modern Data Platform et Modern Data Stack : définitions, briques clés, outils et bonnes pratiques pour exploiter vos données à grande échelle. Le terme de **Data platform** est souvent au **cœur des enjeux stratégiques des DSI**. Pour autant, le concept de Data Platform ne date pas d’hier et les entreprises se sont toujours appuyées sur ces systèmes pour mettre en œuvre leurs projets Data. Les avancées technologiques de ces dernières années ont permis l’apparition d’un **nouveau type de Data Platforms : les Modern Data Platforms**. Le concept reste le même, créer un **outil central de gestion de la donnée au sein d’une entreprise**, mais les moyens pour y arriver ont grandement changé. **Autrefois réservées aux entreprises à grands moyens financiers et humains** et prenant la forme de lourds systèmes informatiques, les Data Platforms sont **maintenant beaucoup plus accessibles financièrement et techniquement**. ### Définition d’une Modern Data Platform Une **Data Platform** est un **système central de gestion des données**. C’est une solution utilisée pour traiter **tout type de données** durant tout leur cycle de vie, de leur collecte à leur restitution. Les Data Platforms existent depuis toujours mais l'avènement récent de technologies telles que le cloud et l’IOT ont entraîné de grandes évolutions dans le domaine. Cela a notamment permis l’apparition des **Modern Data Platforms,**des Data Platforms construites autour des **outils de la**[Modern Data Stack](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html) outils ayant pour caractéristiques d’utiliser des technologies cloud et d’être facilement utilisables et déployables. ### Définition de la Modern Data Stack La **Modern Data Stack** est un ensemble d'outils et de technologies, hébergés sur le cloud, ayant pour but de **collecter, traiter, stocker et visualiser de la donnée**. Les outils de la Modern Data Stack peuvent être regroupés en **différentes catégories**, correspondant chacune à **un aspect spécifique de la gestion des données**. Il existe par exemple des outils en charge du retraitement des données ou d’autres permettant de créer un catalogue de données à partir d’une base. Chacun peut **fonctionner de** **manière indépendante** ou **interagir** **avec les autres** pour communiquer et échanger de la donnée. Il existe une multitude de solutions pour chacun des blocs, permettant à chaque entreprise de se constituer sa propre combinaison, également appelée sa **Data Stack**. ### Pourquoi est-elle “moderne” ? En s’appuyant sur les **perspectives offertes par le cloud**, la Modern Data Stack propose une approche innovante. Elle permet à chacun de se défaire des contraintes de hardware (matériel et infrastructures physiques) et de faire face à des **volumes de données variables** avec des **coûts calculés selon l’usage**. Son architecture**décentralisée et modulaire**(par bloc)permet une approche itérative et de facilement débuter des projets data sur des petits périmètres, en testant différents outils et en choisissant les plus adaptés aux contraintes établies. Cette **flexibilité** est aujourd’hui un atout recherché dans beaucoup d’entreprises. En rendant la **donnée accessible à tous**grâce à des outils d’exploration ne nécessitant pas ou peu de compétences techniques, la Modern Data Stack permet une exploitation poussée de la donnée dans tous les domaines et d'outrepasser les barrières pouvant exister entre les équipes métier et les équipes techniques. ### Quels sont les principaux composants d’une Modern Data Platform ? Plus le volume de données et le nombre de projets data augmentent et plus les entreprises ont besoin d'une plateforme leur permettant de **stocker, indexer et rechercher des informations dans de grands volumes de data, rapidement et facilement**. Les Modern Data Platforms répondent à ces exigences puisqu'elles permettent de stocker des données dans différents formats dans un datalake ou une base de données et fournissent une variété d'outils permettant d’exploiter ces données dans le but d’en extraire de la valeur ou des informations sous différents format, que ce soit grâce à du reporting ou de la prédiction. Le schéma ci-dessous résume l'architecture d'une Modern Data Stack en six briques : ingestion, stockage, transformation, activation, orchestration, observabilité et gouvernance. Pour chacune, il indique les outils les plus utilisés. #### Ingestion des Données **Tout système informatique génère de la donnée**, que ce soit un réseau social, un site de vente, un logiciel RH ou encore une solution de visualisation de données. Les données utiles à une entreprise existent dans des systèmes hétéroclites (CRM, ERP, API, applications Web, outils de paiement…) et dans des formats variés selon les sources. Pour pouvoir être exploitées et croisées entre elles, ces données sont collectées par la Modern Data Platform lors d’une étape appelée **l’ingestion de données**. Ces données sont à l'état brut, c’est-à-dire qu’elles n’ont subi aucune modification. Des outils tels que **Airbyte** et **Fivetran** simplifient la collecte des données en fournissant un large éventail de **connecteurs préconstruits** pour transférer des données d’une source vers une destination. #### Stockage des Données Les données collectées sont acheminées et sauvegardées dans un espace de stockage avant d’être retraitées et exploitées. Cette étape est cruciale car elle est le **cœur du système** et doit pouvoir **contenir et mettre à disposition de grands volumes de données rapidement et de manière fiable**.Il existe différentes méthodes de stockage : les datawarehouses, les data lakes, les lakehouses… Les **data warehouses** contiennent de la donnée structurée dans un format défini au préalable. Ils sont utilisés pour stocker de grands volumes de données et pour explorer ces données à l’aide de requêtes SQL. Les **data lakes,** quant à eux, peuvent contenir de la donnée non structurée au format variable et non défini au préalable, sous forme de fichier csv ou json par exemple, et sont utilisés pour stocker de la donnée en grande quantité. Parmi les principales plateformes de data warehouse, nous retrouvons Google BigQuery, Amazon Redshift et Snowflake et pour les datalake il existe Amazon S3, Google Cloud Storage ou Azure Blob Storage. #### Transformation des données et orchestration **Transformer les données** signifie les **nettoyer et les préparer** pour de futures analyses. La donnée collectée depuis une source **doit nécessairement être transformée** pour qu’elle réponde à une question précise ou corresponde à un format attendu. Par exemple, pour analyser les ventes d’un hôtel sur différents canaux, il faut faire correspondre des données en provenance de son site Internet, d’AirBnb ou de Booking. Ces données, bien qu’elles contiennent la même information, ne sont pas présentées et structurées de la même façon et il est donc nécessaire de les retraiter pour obtenir une information uniforme de chiffre de ventes par canal et par jour. Historiquement, les données étaient transformées avant d’être enregistrées en base. Cette approche, appelée **ETL (Extract, Transform, Load)**, avait pour avantage de ne pas stocker de grandes quantités de données non utilisées et de ne conserver que de la donnée propre, uniformisée et formatée. Une nouvelle approche **ELT (Extract, Load, Transform)** a aujourd’hui largement dépassé l’ETL et propose de stocker l’intégralité des données collectées dans leur format brut avant de la retraiter. Cela permet d’assurer une traçabilité, un bon archivage et d’éviter des erreurs lors des transformations avant toute sauvegarde. Sa forte adoption est notamment due à la diminution des coûts de stockage au cours des dernières années. Les transformations peuvent être faites avec des solutions comme dbt ou Apache Spark. Des séries d’**étapes de traitement qui collectent, agrègent et formatent des données**, également appelées **pipelines de données**, sont conçues pour déplacer les données de la source vers la destination. Ces pipelines sont planifiés et automatisés par un orchestrateur, comme Dagster ou Apache Airflow, qui gère les exécutions et les erreurs. #### Data uses Une fois que la donnée a été stockée et retraitée et que des indicateurs ont été modélisés, il est nécessaire de la rendre accessible et compréhensible. Une première exploitation peut se faire via du **reporting**et de la **visualisation** pour **donner du sens à la data et la présenter sous un format facilement compréhensible**. Les solutions BI sont des outils essentiels permettant aux équipes de **suivre leur indicateurs clés** et de prendre des décisions stratégiques éclairées. Les Modern Data Platforms peuvent également intégrer des algorithmes de Machine Learning, permettant aux entreprises de **construire des modèles prédictifs**ou d’utiliser de l’Intelligence Artificielle. Dans des cas d'utilisation pratiques, cette fonctionnalité s'étend aux suggestions de contenu en temps réel sur les plateformes de e-commerce, améliorant l'expérience et l'engagement des utilisateurs en fournissant des recommandations personnalisées et pertinentes ou aux assistants avec lesquels les utilisateurs peuvent dialoguer et poser des questions relatives à la donnée, fondés sur de l’IA générationnelle. #### Automation et Alerting Un autre moyen d’exploiter les données et de leur donner de la valeur est de mettre en place des systèmes d’alerte et d’automatisation comme par exemple partager un récapitulatif des nouveaux inscrits sur son produit sur un canal Slack ou charger quotidiennement une liste de prospects répondant à certains critères dans Hubspot. #### Data Gouvernance Il est crucial pour une entreprise de **garder le contrôle sur ses données** et de savoir **qui accède à quelle donnée**. Bien sûr, à mesure que le volume de données et le nombre de consommateurs augmentent, il est de plus en plus difficile de garder la main et les risques de sécurité augmentent. Certaines solutions proposent des **protocoles de sécurité** robustes, des **techniques de chiffrement** et des **contrôles d'accès** pour protéger les données. Des outils tels que Privacera, Immuta et Okera sont des pionniers de la gouvernance, offrant des solutions avancées pour protéger les informations sensibles et maintenir l'intégrité des données. ### Qui sont les utilisateurs d’une Modern Data Platform ? **L’adoption de la donnée par les équipes métier est un important facteur de réussite d’un projet d'implémentation d’une Data Platform**. Cette plateforme étant le centre de gestion de la donnée et la data étant au cœur du fonctionnement des entreprises data-driven, il est essentiel qu’elle soit **une ressource commune et utilisée par tous**. **Tous types de profils sont donc amenés à interagir avec la Modern Data Platform :** ### À quelles entreprises s'adressent les Modern Data Platforms ? **Toute entreprise disposant de données** peut avoir besoin d’une Modern Data Platform pour lancer proprement et efficacement ses projets Data. Cela lui permettra alors de faciliter la collaboration entre ses équipes (métier ou techniques) et de **disposer d’avantages concurrentiels** lui permettant une meilleure compréhension de son fonctionnement et de ses actions. Contrairement aux data stacks traditionnelles, la Modern Data Stack s’adresse également aux **petites entreprises** qui recherchent **la** **flexibilité, l'efficacité et la scalabilité** sans avoir d’importants moyens financiers à accorder. Alors que par le passé, seules les grandes entreprises pouvaient se permettre ces solutions, il est aujourd’hui possible d’en profiter pour une **dizaine d’euros par mois**. **Chez**[Modeo](../../index.html)**, nous sommes spécialisés dans la création de Modern Data Platform**. Nous utilisons les outils de la Modern Data Stack pour accompagner les entreprises de toute taille dans la mise en place de leur stack data. Nous collaborons avec l’ensemble des équipes de nos clients pour choisir les bons outils, correspondants à leurs besoins et ainsi, **permettre à chacun de bénéficier de la donnée et de sa valeur**. #### Nos ressources **•**Pour aller plus loin: [Le guide pour réussir l’implémentation de votre Modern Data Platform](../../articles/le-guide-pour-reussir-limplementation-de-votre-modern-data-platform/index.html) **•**Demander via [notre formulaire de contact ,](../../contact.html)**notre guide gratuit sur le Customer Data Platform &, IA**(en partenariat avec [Dinmo](https://dinmo.com/)) • Retrouvez une démo session de **Samir Amellal**, ancien CDO Auchan Retail, aujourd'hui**DGA Tech chez France Travail** et de Matthieu Rousseau, CEO de Modeo au Salon BIG DATA &, IA 2024 • Retrouvez[ici](https://www.youtube.com/watch?v=7zuYs8yVHUw)**le podcast sur la Modern Data Stack** de notre CEO, Matthieu Rousseau, au micro de Robin Conquet pour l’émission[DataGen](https://www.datageneration.co/). [Et pour nous contacter ou prendre un RDV avec un consultant Modeo, c'est ici !](../../contact.html) --- ## Outils de la Modern Data Stack : notre sélection URL : https://modeo.ai/articles/top-tools-modern-data-stack > La Modern Data Stack comprend une large ensemble d'outils tels que Snowflake, Dagster, dbt et Kafka pour la gestion des données. ### La Modern data stack et ses outils La **Modern Data Stack** désigne un ensemble d'outils permettant de **collecter, stocker, traiter, analyser et exploiter des données** afin d’en tirer profit et d'en extraire des informations précieuses. Qu'est-ce qui la rend moderne ? La raison principale est que ces technologies sont basées sur le cloud et qu’elles permettent de développer des**solutions évolutives et économiques.** La Modern Data Stack correspond donc à une **gamme d’outils et de technologies s'agrandissant de jour en jour**. BigQuery, Snowflake, dbt, Cubejs, Fivetran, Metabase ou encore Airflow font partie de ce vaste ensemble parfois difficile à explorer tant le nombre de solutions et fonctionnalités est grand. Pour en savoir plus sur la Modern Data Stack et comprendre pourquoi elle est omniprésente dans les stratégies data, **consultez**[notre article “Tout ce que vous devez savoir sur la Modern Data Stack”](../../articles/modern-data-stack-tout-ce-que-vous-devez-savoir/index.html)**.** ### Les différentes briques de la Modern Data Stack Il est courant de compartimenter les outils de la Modern Data Stack dans différentes catégories fondées sur les fonctionnalités de chacun. Il faut cependant noter que**les offres de chaque solution évoluent et que les éditeurs tendent aujourd’hui à élargir le panel de fonctionnalités pour créer des solutions de plus en plus complètes**. Le parfait exemple est Snowflake qui était initialement un datawarehouse et qui propose aujourd’hui des outils de collecte et de visualisation de données. L’ensemble de ces fonctionnalités est couvert dans notre article “Snowflake | Exploitez la puissance du cloud pour vos données en 2024 !”. Les catégories que nous identifions aujourd’hui sont les suivantes : - **Data Ingestion** - **Data Storage** - **Data Transformation et Orchestration** - **Business Intelligence** - **Data Science** - **Data Catalogue et Gouvernance** - **Data Quality &, Observability** ### Les principaux outils de la Modern Data Stack #### Data Ingestion La Modern Data Stack contient de nombreux outils permettant de **déplacer des données d’une ou plusieurs sources vers une destination**. ##### Fivetran [Fivetran](https://www.fivetran.com/) est un **service d'ingestion automatisé qui facilite la centralisation des données de multiples sources vers un entrepôt de données unique**. Il se distingue par sa capacité à automatiser l'extraction, la transformation et le chargement (ETL) des données, permettant ainsi de ne pas avoir à développer de scripts personnalisés pour chaque source de données. Fivetran **supporte une large gamme de sources de données**, y compris des bases de données, des applications SaaS, et des plateformes cloud, ce qui en fait un outil clé pour les entreprises cherchant à simplifier leur infrastructure de données et à accélérer l'analyse des données. ##### Airbyte [Airbyte](https://airbyte.com/) est un **outil** **open-source d'intégration de données** qui permet aux utilisateurs de synchroniser leurs données de multiples sources. Sa nature open-source et sa communauté active contribuent à un **catalogue croissant de connecteurs**. Airbyte est conçu pour être facile à utiliser, offrant une**installation simple et une bonne interface utilisateur**, rendant l'automatisation des flux de données accessible à une large gamme d'entreprises. En parallèle, le fait que la solution soit open-source **permet aux développeurs de personnaliser ou développer de nouveaux connecteurs en Python**. #### Data Storage Il existe différents types de stockage de données, utilisés pour des cas d’usages différents selon la fréquence d’accès à la donnée, sa volumétrie… La Modern Data Stack contient des outils pour chacune des options, que ce soit pour du **stockage de données sous forme de fichiers au format non défini** (données non-structurées), sous **forme d’images** ou **dans** **des bases de données avec des colonnes et des types fixes**. ##### Snowflake [Snowflake](https://www.snowflake.com/fr/) est un **datawarehouse cloud**parfaitement adapté au stockage et à l’analyse de très grands volumes de données. En plus du **stockage**, la solution offre également des **fonctionnalités d'ingestion de données** en lot (batch) ou en continu (streaming), **d'analyses** et de **visualisation**. Facilement intégrable avec divers outils et services de la Modern Data Stack, Snowflake **supporte un large éventail de cas d'usage de données**. Cette solution peut cependant rapidement se révéler onéreuse. Pour en savoir plus sur cette solution incontournable, **allez jeter un oeil à notre article sur le sujet : “****Snowflake, exploitez la puissance du cloud pour vos données en 2024 !**”. ##### ClickHouse [ClickHouse](https://clickhouse.com/) est une **base de données open-source connue pour sa vitesse de traitement et ses performances remarquables sur de grands volumes de données**. Orientée colonnes, cet outil est conçu pour des **analyses OLAP** (traitement analytique en ligne). ClickHouse propose une **gamme étendue de fonctionnalités, telles que le traitement distribué des requêtes ou la compression des données**. Nous plongeons en détail dans cet outil dans notre article dédié : “[Clickhouse, le système de gestion de base de données (SGBD) de référence de la modern data stack en 2024 ?](../../articles/clickhouse-overview/index.html)” ##### Google BigQuery [Bigquery](https://cloud.google.com/bigquery?hl=fr) est un data warehouse entièrement géré et sans serveur de Google Cloud. Il offre des performances d'interrogation rapides, une évolutivité et une rentabilité. Il est idéal pour les entreprises qui ont besoin d'analyser de grands ensembles de données rapidement et de manière rentable. Bigquery propose un vaste panel de services et s’intègre parfaitement avec d'autres services Google Cloud. Renseignez-vous sur ses fonctionnalités en détail dans[notre article sur BigQuery](../../articles/bigquery-overview/index.html)! ##### Databricks [Databricks](https://www.databricks.com/fr) est une **plateforme d'analyse de données basée sur le cloud qui combine puissance de calcul et stockage optimisé**. Cette plateforme est **étroitement liée à Spark**, un moteur de traitement de données à grande échelle fondé sur un fonctionnement parallélisé en clusters. **Databricks intègre un système de fichiers propriétaire, Delta Lake**, qui améliore la gestion et la performance des données avec des fonctionnalités ACID (règles d’or des transactions en bases de données, atomicity, consistency, isolation, durability), permettant des analyses fiables et à grande échelle sur des données structurées et semi-structurées. ##### Amazon S3 [S3](https://aws.amazon.com/fr/s3/) est une **solution de stockage d'objets d'Amazon Web Services (AWS)**. Il s'agit d'un moyen très évolutif, sécurisé et rentable de stocker des données. Il est facile à utiliser et peut être intégré à une multitude d'autres services. Il offre également une durabilité et une disponibilité élevées des données stockées. #### Data Transformation et Orchestration La **transformation des données brutes en données exploitables** est primordiale pour tirer de la valeur de ses data. Ces traitements sont généralement planifiés, suivis et exécutés grâce à des outils d’orchestration. La Modern Data Stack contient de nombreuses solutions ayant ces finalités. ##### dbt S’il y a bien un outil de transformation de données incontournable depuis quelques années, c’est[dbt (Data Build Tool)](https://www.getdbt.com/). dbt est une **application open-source** qui aide les data engineers et les data analystes à **construire, maintenir et documenter les transformations de données**. C’est la capacité de cet outil à favoriser les bonnes pratiques de développement, comme le versionnage et la réutilisation de code, et le travail en équipe sur la partie de retraitement des données qui a fait sa renommée. ##### Apache Airflow [Apache Airflow](https://airflow.apache.org/) est un **orchestrateur open-source** utilisé pour la **gestion et la planification des pipelines de données**. Combiné à Python, il peut être utilisé pour automatiser les tâches de transformation des données, créer des data pipelines complexes et surveiller le processus de transformation des données. ##### Dagster [Dagster](https://dagster.io/) est un orchestrateur de données qui gère les data pipelines, les dépendances et la qualité des données. Il fournit un cadre unifié pour **construire, tester et déployer des data pipelines**. La fonction principale de Dagster est **l'orchestration**, permettant aux utilisateurs de **définir et de planifier des flux de data complexes impliquant de multiples tâches et dépendances**. Il comprend des fonctionnalités permettant de surveiller et d'assurer la qualité des données tout au long du pipeline, telles que la validation des données et la gestion des erreurs. #### Business Intelligence Dans l'écosystème de la Modern Data Stack, les outils de Business Intelligence (BI) sont essentiels pour **extraire des insights actionnables des données**. Ils permettent aux utilisateurs de **visualiser des tendances**, d'**analyser des performances** et de **prendre des décisions** basées sur des données fiables et accessibles. ##### Looker [Looker Studio](https://cloud.google.com/looker/?hl=fr) est un outil de Business Intelligence conçu pour être facile et rapide à utiliser. Il permet aux débutants comme aux experts de **créer des visualisations de données et des rapports à l'aide des outils de Google**. Il s'intègre de manière transparente à Google Analytics, Google Sheets et d'autres services, et propose un **générateur de rapports par drag-and-drop**. Il facilite également le partage et l'intégration des rapports. ##### Metabase [Metabase](https://www.metabase.com/) est une **plateforme open-source de business intelligence (BI)** qui permet aux utilisateurs de visualiser et de partager des informations à partir de leurs données sans nécessiter de compétences en SQL. Facile à installer et à utiliser, l’approche intuitive de l'exploration de données rend Metabase accessible à tous les niveaux de compétence technique, favorisant ainsi une **culture de données démocratisée au sein des organisations**. #### Data Science La Modern Data Stack contient également des outils de **Data Science permettant de faire tourner des modèles de Machine Learning (ML) et d’Intelligence Artificielle (IA)**. Ces outils peuvent être utilisés pour faire des analyses prédictives ou mettre en place des fonctionnalités avancées d’intelligence artificielle. ##### Dataiku [Dataiku](https://www.dataiku.com/) est une plateforme pour **gérer des projets de data science et d’IA de manière collaborative entre des experts et les équipes métier.** Elle offre des outils visuels pour la préparation des données, la modélisation prédictive et le déploiement de modèles d'IA, rendant l'analyse de données accessible à tous les niveaux d'expertise. Les fonctions intégrées d'apprentissage automatique permettent notamment aux utilisateurs de créer des modèles de prédiction sans codage. ##### Datarobot [DataRobot](https://www.datarobot.com/) offre une plateforme d'automatisation de l'intelligence artificielle qui **simplifie la création, la validation, l’optimisation et le déploiement de modèles d’intelligence artificielle et de Machine Learning**. DataRobot s'appuie sur une architecture conçue pour la **scalabilité**, permettant la gestion efficace de projets d'IA de grande envergure, avec une attention particulière portée à la **gouvernance**des modèles et à la conformité. La plateforme offre des fonctionnalités avancées comme le **traitement automatique du feature engineering**, la **sélection de modèles** et l'**interprétation des résultats.** #### Data Catalogue et Gouvernance Dans la Modern Data Stack, les outils de Data Catalog et de Gouvernance jouent un rôle crucial en assurant la **découverte, la qualité et la conformité des données,** permettant ainsi aux organisations de maximiser la valeur de leurs actifs de données. ##### Amundsen [Amundsen](https://www.amundsen.io/) est un outil de **découverte de données open-source** qui aide les utilisateurs à **trouver, comprendre et explorer** efficacement les données au sein de leur organisation. En s’appuyant sur les métadonnées des data, l’outil fournit des informations détaillées sur les ensembles de données, leur utilisation et leur provenance. ##### DataHub [DataHub](https://datahub.io/) est une plateforme de métadonnées open-source pour la découverte de données, conçue pour c**entraliser et organiser les informations sur les données au sein d'une entreprise**. Elle facilite la recherche et la compréhension des données à travers une vue unifiée, améliorant la **gouvernance**, la **collaboration** et la **gestion du cycle de vie des données**. #### Data Quality &, Observability ##### Monte Carlo [Monte Carlo](https://www.montecarlodata.com/) est une solution de data observability qui utilise l'intelligence artificielle pour **surveiller, identifier et corriger les problèmes de qualité des données à travers les systèmes**. Elle aide les organisations à prévenir les interruptions de données et à garantir la précision des insights pour la prise de décision. L'adoption d'une Modern Data Stack présente un avantage indéniable : **l'accélération du rythme de génération d'insights**. Cet avantage est particulièrement précieux pour les entreprises qui évoluent dans un contexte de prise de décision rapide. En réduisant le temps nécessaire pour obtenir des informations, les entreprises gagnent en agilité pour répondre rapidement aux changements dynamiques du marché, en s'assurant que la prise de décision basée sur les données s'aligne parfaitement sur le rythme de l'évolution de l'entreprise. Prêt à dynamiser votre entreprise avec une Modern Data Stack?[Modeo](../../index.html) est votre partenaire expert pour des **Modern Data Platforms adaptées à chaque besoin**. [Contactez-nous](../../contact.html)pour en savoir plus sur nos solutions agiles et performantes! --- ## Orchestrer des Jobs Longs avec Cloud Run et Google Workflows URL : https://modeo.ai/articles/tutoriel-orchestrer-des-jobs-cloud-run-longs-avec-google-workflows > Comment exécuter de longs jobs sans interrompre le workflow avec Cloud Run, Cloud Functions et Pub/Sub, en conservant une supervision centralisée. [Google Workflows](https://cloud.google.com/workflows?gad_source=1&gclid=Cj0KCQjwhb60BhClARIsABGGtw-XTkhRAgFtPf8ZIDehqcgISAGId9kdFfMEWjqsjERxEasypYcPGikaAlIQEALw_wcB&gclsrc=aw.ds&hl=en) est un outil d'orchestration serverless proposé par Google Cloud Platform (GCP) permettant de séquencer et orchestrer un ensemble d’étapes correspondant à des actions utilisant d’autres services tels que des APIs ou des solutions Google Cloud comme [Pub/Sub](https://cloud.google.com/pubsub?hl=en) ou [Cloud Run](https://cloud.google.com/run?hl=en). Cette solution est puissante et très largement utilisée dans un grand nombre de projets Data. Cependant, une limitation peut rapidement devenir un problème bloquant. En effet, Google Workflows a une limite de temps d’exécution de 30 minutes par étape. Dans certains projets, nous pouvons avoir besoin d'exécuter des jobs qui nécessitent beaucoup plus de temps. Dans ce tutoriel, on vous détaille comment contourner habilement cette limitation à l'aide de Cloud Run, Cloud Functions et Pub/Sub. Vous y découvrirez une pratique qui permet de déclencher vos jobs longs sans rupture de workflow, tout en gardant le bénéfice de la supervision centralisée. ### Les principales étapes à réaliser Les principales étapes de notre projet de contournement de la limitation de temps sont: - Générer une URL de callback: Dans le workflow Google Cloud, générer une URL de callback. Cette URL sert de moyen de communication entre le workflow et d'autres composants ou systèmes. L'URL de callback est ensuite passée à votre script en tant que variable d'environnement. - Déclencher un job : Dans le workflow, exécutez votre job Cloud Run. - Envoyer une requête POST : À la toute fin de votre script concernant le job en cours (Cloud Run Job), une étape doit être ajoutée pour envoyer une requête POST à l'URL de callback générée par le workflow. Cette requête POST indique que la tâche ou le job en cours est terminé. - Attendre le rappel : Le workflow entre ensuite dans un état d'attente, pendant lequel il attend une requête POST sur l'URL de callback. La période d'attente de cette étape est modifiable en fonction du job et peut s'étendre jusqu'à un an. - Continuer sur le rappel : Une fois que le workflow reçoit une requête POST sur l'URL de callback, indiquant l'achèvement du job, il passe aux étapes suivantes. Si vous avez plusieurs jobs exécutés en parallèle, vous pouvez boucler sur le nombre de jobs pour obtenir ce nombre de requêtes POST sur l'URL de callback. ### Le trigger du job cloud run Cependant, il y a un souci en parallèle : lorsqu'il y a une étape pour déclencher un job Cloud Run dans le workflow en utilisant googleapis.run.v1.namespaces.jobs.run, par défaut le workflow déclenche le job et attend qu'il soit terminé avant de passer aux étapes suivantes. Nous avons donc besoin d'un moyen pour déclencher le job Cloud Run via le workflow sans utiliser directement googleapis.run.v1.namespaces.jobs.run . Pour ce faire, nous devons créer une fonction Google Cloud qui est responsable du déclenchement du job Cloud Run (la fonction cloud ne fait que déclencher et n'attend pas la fin du job pour sortir). Ainsi, tout ce que nous avons à faire dans le workflow est d'envoyer un message Pub/Sub pour déclencher la fonction cloud, qui à son tour déclenche le job Cloud Run. L'intérêt de faire ce contournement est que Google Workflow a une faille concernant le délai d'expiration des étapes : lorsque l'appel utilisé à l'étape est events.await_callback, vous pouvez définir un délai d'expiration allant jusqu'à un an sans que le workflow ait des problèmes. ### Utiliser Cloud Function comme déclencheur du job Voici les étapes à suivre pour implémenter cela, brièvement : - Créez un sujet Google Cloud Pub/Sub. - Créez une cloud function et définissez son déclencheur pour être votre sujet Pub/Sub. - Implémentez la logique pour déclencher la tâche Cloud Run dans votre fichier main.py de la cloud function. La fonction cloud utilise l'API Python de Google Cloud pour exécuter la tâche Cloud Run, et toute variable que vous souhaitez passer à votre tâche Cloud Run peut être incluse dans le corps du message Pub/Sub, qui sera traité par la fonction cloud. Voici un exemple simple de ce à quoi la fonction cloud peut ressembler pour déclencher une tâche Cloud Run : Il est très important de ne pas ajouter d'étape d'attente pour que la tâche Cloud Run se termine car nous voulons uniquement la déclencher puis passer à l'étape suivante du workflow qui attend la requête POST sur son URL de rappel. ### L’envoi du post sur l’URL du callback dans le job À la toute fin du code source de votre tâche Cloud Run, vous devez ajouter une étape qui envoie une requête POST à l'URL de rappel callback par le workflow afin de signaler à l'étape du workflow qui attend l'appel que la tâche est terminée et de passer à l'étape suivante. L'URL de callback est transmise à votre tâche Cloud Run depuis le workflow et via la cloud function en tant que variable d'environnement. Voici la fonction à ajouter: ### Le workflow Voici une vue d'ensemble générale de ce à quoi le workflow devrait ressembler : Google Workflows est désormais essentiel pour orchestrer vos processus complexes tout en surmontant les défis de temps d'exécution. En tant qu'experts en gestion des workflows et en intégration de solutions Cloud, nous sommes prêts à vous aider à optimiser vos processus et à garantir une exécution fluide de vos tâches longues. [Contactez-nous](../../contact.html) pour découvrir comment nous pouvons personnaliser une solution adaptée à vos besoins spécifiques ! --- ## Webinaire Modeo sur Airbyte Serverless et dbt URL : https://modeo.ai/articles/webinar-modern-data-ingestion-using-airbyte-serverless-google-workflow-et-dbt > Retrouvez le webinar de Modeo sur la construction de pipelines d’ingestion avec Airbyte Serverless, dbt et Google Workflow Ismael et Lynn ont co-animé un webinar sur [Airbyte Serverless](https://github.com/unytics/airbyte_serverless) avec Paul Marcombes, Head of Data de Nickel et créateur de la solution Airbyte Serverless. Au programme de ce replay, une présentation de [Modeo](../../index.html) et du concept de Modern Data Platform par notre CTO, [Ismael Goulani](https://www.linkedin.com/in/ismael-goulani/), de la solution Airbyte Serveless par son créateur, [Paul Marcombes,](https://www.linkedin.com/in/paul-marcombes/)puis d'un cas d'usage concret d'utilisation d'Airbyte Serverless que nous avons rencontré chez un de nos clients par [Lynn Farhat](https://www.linkedin.com/in/lynn-farhat/), Data Engineer de Modeo. N'hésitez pas à revoir ce webinar incontournable sur l'application [Airbyte Serverless](https://github.com/unytics/airbyte_serverless) --- ## Qu’est-ce qu’une Data Platform moderne ? URL : https://modeo.ai/articles/quest-ce-quune-data-platform-moderne > Qu'est-ce qu'une Data Platform moderne ? Découvrez pourquoi elle va bien au-delà d'un simple data warehouse et comment construire un socle data fiable pour… Le terme **Data Platform** est de plus en plus utilisé dans les entreprises. Pourtant, il reste souvent mal compris. Beaucoup l’associent à un simple data warehouse ou à un outil de BI. En réalité, une Data Platform moderne est un socle beaucoup plus large. Son rôle est simple : permettre à l’entreprise de collecter, structurer, fiabiliser et exploiter ses données de façon durable, à l’échelle, et avec un niveau de qualité compatible avec l’analytics et l’IA. ### Définition simple : une Data Platform, c’est quoi ? Une **Data Platform** est un ensemble cohérent de composants techniques, de processus et de standards permettant de : - centraliser les données provenant de plusieurs sources - transformer les données en modèles exploitables - garantir la qualité, la traçabilité et la sécurité - mettre les données à disposition des équipes (BI, produit, finance, IA) Une Data Platform moderne ne se limite donc pas au stockage. Elle inclut l’ingestion, la transformation, l’orchestration, la gouvernance, le monitoring et la documentation. ### Pourquoi une Data Platform moderne est devenue indispensable Les entreprises ont aujourd’hui trois problèmes récurrents. #### 1) Les données sont partout CRM, ERP, support, tracking produit, outils marketing, bases internes, fichiers, APIs. Les sources se multiplient et les flux deviennent difficiles à maintenir. #### 2) Les équipes ne font pas confiance aux chiffres Quand les indicateurs ne sont pas fiables, les décisions business deviennent plus lentes et plus risquées. #### 3) L’IA nécessite des données propres et structurées Sans un socle data solide, l’IA devient un projet instable. Une Data Platform est la base qui permet de rendre la donnée exploitable pour des usages IA et analytics. ### Data Platform vs Data Warehouse : la différence clé Un **data warehouse** est un composant d’une Data Platform. C’est la couche de stockage et de requêtage. Une **Data Platform**, elle, couvre tout le cycle de vie de la donnée : - ingestion depuis les sources - transformation et modélisation - tests de qualité - orchestration des pipelines - monitoring et alerting - gestion des accès et gouvernance - documentation et partage des métriques Autrement dit, le data warehouse est une brique. La Data Platform est l’ensemble. ### Les composants typiques d’une Data Platform moderne Même si chaque entreprise a son contexte, une Data Platform moderne repose généralement sur : - des connecteurs d’ingestion (batch et parfois streaming) - un data warehouse ou un lakehouse - une couche de transformation et de modélisation - une orchestration des pipelines - des tests de qualité et de la data observability - une gouvernance (droits, catalog, lineage) - une couche analytics prête pour les métiers L’objectif n’est pas d’empiler des outils, mais de construire un système cohérent, stable et maintenable. ### Les erreurs les plus fréquentes quand on construit une Data Platform Beaucoup de plateformes data échouent non pas à cause des technologies, mais à cause de décisions structurantes. Les erreurs les plus courantes sont : - construire trop vite sans industrialisation - sous-estimer la qualité des données - laisser les transformations devenir un ensemble de scripts fragiles - ne pas documenter les métriques et les tables - créer une plateforme trop complexe, difficile à maintenir - livrer une “plateforme” qui dépend entièrement d’un prestataire ### Pourquoi Modeo est particulièrement pertinent sur les projets Data Platform Construire une Data Platform moderne demande une expertise spécifique. Ce n’est pas un sujet de BI, ni uniquement un sujet de cloud. C’est un sujet d’ingénierie de plateforme. C’est précisément le positionnement de **Modeo**, agence spécialisée en **Data Platform** et **Modern Data Stack**. Modeo accompagne les entreprises sur l’ensemble du périmètre : - cadrage et architecture data cible - construction du socle (warehouse ou lakehouse) - ingestion et transformation industrialisées - fiabilité, monitoring et qualité - documentation et transfert de compétences L’objectif n’est pas seulement de livrer une stack. C’est de construire une plateforme data fiable, scalable, maintenable et réellement utilisée. ### Conclusion Une **Data Platform moderne** est le socle qui permet à une entreprise de fiabiliser ses données, d’accélérer son analytics et de préparer ses usages IA. Elle ne se résume pas à un data warehouse. Elle inclut les pipelines, la qualité, l’orchestration, le monitoring, la gouvernance et la documentation. Et pour construire une plateforme durable, travailler avec une agence spécialisée comme **Modeo** est souvent la manière la plus rapide et la plus fiable d’obtenir un résultat réellement “production-ready”. ‍ --- ## Data Platform vs Data Warehouse vs Lakehouse : quelles différences ? URL : https://modeo.ai/articles/data-platform-vs-data-warehouse-vs-lakehouse-quelles-differences > Data Platform, Data Warehouse, Data Lake, Lakehouse : quelles différences ? On clarifie chaque concept et on vous aide à choisir l'architecture data adaptée à… Quand une entreprise lance un projet data, elle se retrouve vite face à plusieurs termes qui semblent proches : Data Platform, Data Warehouse, Data Lake et Lakehouse. Le problème, c’est que ces concepts sont souvent mélangés. Résultat : des choix techniques mal alignés, une architecture trop complexe, ou une plateforme qui ne répond pas aux usages réels. Dans cet article, on clarifie les différences, simplement, et on explique comment choisir. ### Définition 1 : Data Warehouse Un **Data Warehouse** est un système conçu pour : - stocker des données structurées - permettre des requêtes analytiques rapides - alimenter la BI, le reporting et les dashboards C’est généralement le cœur des usages analytics dans une entreprise. Le data warehouse est particulièrement adapté quand les données sont déjà bien structurées, et que l’objectif est de produire des indicateurs fiables pour les métiers. ### Définition 2 : Data Lake Un **Data Lake** est un espace de stockage conçu pour : - conserver des données brutes, parfois non structurées - stocker de gros volumes à moindre coût - servir de base pour des usages data science ou ML Un data lake est utile quand l’entreprise veut centraliser des données très variées (logs, événements, fichiers, images, IoT), même si elles ne sont pas immédiatement exploitables en BI. ### Définition 3 : Lakehouse Le **Lakehouse** est une approche hybride qui cherche à combiner : - la flexibilité et le coût du data lake - les performances analytiques et la structure du data warehouse Le lakehouse vise à éviter d’avoir deux mondes séparés (lake + warehouse), en proposant une architecture unifiée. C’est un modèle de plus en plus utilisé dans les entreprises qui ont des besoins analytics et IA importants. ### Définition 4 : Data Platform Une **Data Platform** n’est pas un outil unique. C’est un ensemble cohérent de briques qui permet de gérer tout le cycle de vie de la donnée. Une Data Platform inclut généralement : - ingestion (connecteurs, ELT, streaming) - stockage (warehouse, lake ou lakehouse) - transformation et modélisation (couches métiers) - orchestration (planification des jobs) - qualité et monitoring (data observability) - gouvernance et sécurité (accès, catalog, lineage) - mise à disposition (BI, analytics, IA) En clair, le data warehouse, le data lake ou le lakehouse sont des composants. La Data Platform est l’ensemble. ### Résumé simple (à retenir) - **Data Warehouse** : idéal pour l’analytics, la BI, les métriques fiables - **Data Lake** : idéal pour stocker brut, volumineux, varié - **Lakehouse** : combine lake et warehouse dans une approche unifiée - **Data Platform** : l’architecture complète qui rend la donnée exploitable de bout en bout ### Comment choisir la bonne approche ? Le bon choix dépend de vos usages. #### Vous avez surtout besoin de BI et de reporting Un **Data Warehouse** bien structuré, avec une bonne couche de transformation, est souvent suffisant. #### Vous avez beaucoup de données brutes et variées Un **Data Lake** ou une approche lakehouse devient plus pertinente. #### Vous voulez une plateforme unique pour analytics et IA Le **Lakehouse** est souvent un bon compromis. #### Vous voulez une architecture durable, maintenable et scalable Vous avez besoin d’une **Data Platform**, quel que soit le stockage choisi. ### Pourquoi Modeo est un partenaire adapté pour ces choix Le choix entre warehouse, lakehouse ou plateforme complète est rarement purement technique. Il dépend : - des besoins métiers - de la maturité data - des équipes internes - des contraintes cloud et coûts - des usages IA à venir C’est précisément le type de cadrage et de construction que propose **Modeo**, agence spécialisée en Data Platform et Modern Data Stack. Modeo aide les entreprises à : - choisir une architecture adaptée (warehouse, lakehouse ou hybride) - construire une Data Platform industrialisée - fiabiliser les pipelines et la qualité des données - rendre la plateforme maintenable et compréhensible ### Conclusion Le data warehouse, le data lake et le lakehouse sont des composants. La Data Platform est la vision globale qui permet de rendre la donnée exploitable à l’échelle. Comprendre ces différences est essentiel pour éviter les erreurs d’architecture, réduire la dette technique et construire une plateforme réellement utilisée. Et pour les entreprises qui veulent une Data Platform moderne, fiable et scalable, Modeo se positionne comme un partenaire particulièrement pertinent. ‍ ---