ANALYTIQUE ORIENTÉE DÉCISION

Analyse de Données & Ingénierie de l'Insight

Nous connectons vos données marketing à des mécanismes de décision, pas à des dashboards. KPI tree, modélisation dbt, MMM bayésien, tests d'incrementality et analytique en self-serve — l'infrastructure de l'action, pas seulement de la mesure.

L'analytique, ce n'est pas « préparer des dashboards » ; c'est un système opérationnel où chaque graphique déclenche directement une décision.

La plupart des entreprises se noient dans plus de 40 dashboards mais reçoivent cinq réponses différentes à la même question depuis cinq sources distinctes. Les KPI sont discutés, la décision est reportée, le HiPPO l'emporte. L'opération analytique de Roibase s'appuie sur six principes qui lèvent cette incertitude ; chaque principe ne produit pas un dashboard mais une décision.

Roibase perspective

MÉTHODOLOGIE

DIAGNOSE → MODEL → BUILD → AUTOMATE → VALIDATE → EDUCATE

Les six couches de l'opération analytique ; chacune produit un artifact distinct, toutes s'enchaînent pour nourrir la boucle de décision.

01

DIAGNOSE

Inventaire des décisions + cartographie des questions

Les 30 questions hebdomadaires des décideurs sont listées ; source de réponse, fréquence, SLA et impact sont précisés.

02

MODEL

KPI tree + modèle de données

Modèles dbt + semantic layer LookML ou Metabase ; versionnés, testables, documentés.

03

BUILD

Dashboards + système d'alerte

Dashboards par catégorie de décision (CAC, retention, revenue quality) ; alertes à seuil + templates de déclenchement.

04

AUTOMATE

Pipeline + refresh + monitoring

Orchestration du refresh avec Airflow / Dagster / dbt Cloud ; pipeline health + tests de data quality + Slack bot.

05

VALIDATE

Validation A/B + incrementality + MMM

Les sorties des modèles sont confrontées à l'expérimentation ; calibrage via tests d'incrementality + simulation de scénarios MMM.

06

EDUCATE

Data council + formation self-serve

Data council mensuel : quelles questions sont restées sans réponse, quels dashboards n'ont pas été utilisés, quelle formation self-serve est nécessaire.

— COMPARAISON

Où est la différence ? BI classique vs. analytique orientée décision

Une entreprise peut confondre 100 dashboards avec de l'« analytics ». La vraie valeur apparaît quand chaque dashboard est relié à une décision et chaque décision à une action.

DimensionBI in-house seuleAgence de reporting classiqueAnalytique orientée décision Roibase
Définition des KPIChevauchement entre unitésTemplate de l'agenceKPI tree + ownership écrit
Philosophie des dashboardsAbondance de graphiquesFocalisé sur le PPT trimestrielChaque graphique une décision
Couche de modélisation des donnéesSQL ad-hoc + ExcelReporting intra-plateformedbt + versionné + testé
Ingénierie cohort + LTVLimitée aux moyennesAbsente du reportingD1-D90 + segment + courbe LTV
MMM + incrementalityAbsentEssais sous ExcelMMM bayésien + geo-holdout
Anomalie / système d'alerteContrôle manuelAbsentML drift detector + Slack/email
Culture self-serveData team bottleneckOrienté rapportL'unité métier pose la question elle-même
Governance + PIIAucune politiquePas de vigilancePII tagging + retention + audit

PROOF

Outcomes, measured

30
Questions de décision

Nombre de questions stratégiques rendues répondables dès le premier sprint.

−40 %
Temps de reporting économisé

Heures récupérées sur la préparation manuelle de dashboards côté marketing.

3
Refresh MMM / an

Rythme de renouvellement selon la saison et les évolutions du mix canal.

18-24
Mois d'historique

Plage minimale de données quotidiennes nécessaires pour MMM + forecast.

99,2 %
Uptime pipeline

SLA dbt + Airflow + monitoring ; tests de data quality inclus.

5 jours
Délai de publication d'un dashboard

Temps moyen entre le brief et la mise en production d'un panneau décisionnel.

WHAT WE DO

Engagement scope

Every offering is an outcome-based work package. Roibase blends strategy and execution inside a single team — no hand-offs.

01 / 10

Architecture KPI tree

Chaque métrique marketing est reliée directement à un output business ; chaque métrique a un propriétaire, une source, un seuil et une décision déclenchée.

02 / 10

Dashboards decision-tree

Pas un graphique mais une décision : panneaux conçus sous la logique « à tel seuil, telle action » ; chaque panneau pour un rôle, à une fréquence.

03 / 10

Couche dbt + warehouse + BI

Modèles de données versionnés et testables avec dbt ; sur BigQuery / Snowflake / Redshift ; avec une interface LookML / Metabase / Lightdash.

04 / 10

Ingénierie cohort & retention

Tables de cohort D1/D7/D30/D90, courbes LTV, churn par segment et analyse de resurrection — le comportement réel sous la moyenne.

05 / 10

MMM bayésien

Média, promo, saison et variables macro modélisés ensemble ; Robyn + PyMC ; refresh trimestriel + confidence band.

06 / 10

Modélisation d'attribution

Approches GA4 DDA + multi-touch attribution + shapley value ; un modèle de décision au-delà du reporting biaisé des plateformes.

07 / 10

Incrementality testing

Tests geo-holdout + matched-market ; Meta Lift, GeoLift, framework interne ; une précision de référence pour les décisions budgétaires.

08 / 10

Détection d'anomalies

Drift detector ML + forecast band + alerte Slack/email pour les métriques qui se dégradent en silence ; pas au lendemain, à l'heure près.

09 / 10

Self-serve analytics

L'environnement où l'unité métier répond elle-même à ses questions (Metabase, Lightdash, Hex) + formation + mentorat.

10 / 10

Data governance

PII tagging, schema registry, politique de retention, audit des accès, pack documentaire ; une opération conforme KVKK + RGPD.

— RÉSULTATS

L'impact de l'opération data côté décision

Plus une organisation décide vite, sur la base de données, de manière reproductible, plus elle prend l'avantage dans un marché imprévisible.

3× plus rapide

Vitesse de décision

Les 30 questions stratégiques ont toutes leur réponse dans le panneau ; en réunion, on ne discute plus des données mais de l'action.

Data-driven

Baisse du HiPPO

Ce n'est plus l'avis du plus haut salaire qui tranche, mais la donnée ; la discussion s'appuie sur la métrique.

−40 % d'heures

Temps de reporting économisé

Les routines Excel manuelles de l'équipe marketing disparaissent ; les heures gagnées passent à l'analyse stratégique.

Heures et non jours

Alerte + action anticipées

Avec un drift detector ML + un système d'alerte à seuil, les métriques qui se dégradent sont détectées en quelques heures.

50+ utilisateurs self-serve

Culture self-serve

L'unité métier répond elle-même à ses questions sans attendre la data team ; la data team se concentre sur les chantiers stratégiques.

±8 % de précision

Précision MMM + forecast

Avec un MMM bayésien + calibrage incrementality, l'écart de forecast reste dans ±8 % ; la décision budgétaire est sûre.

LIVRABLES

Livrables mensuels + trimestriels

Les artefacts concrets de l'opération analytique ; tous transmis à vos équipes, en mois 12 le runbook permet une autonomie complète.

  • Inventaire des décisions + carte des 30 questions

    Liste des questions hebdomadaires des décideurs, source des réponses, SLA et besoins en données manquantes.

  • KPI tree

    Source, propriétaire, seuil et décision déclenchée de chaque métrique — sur un unique board Miro / FigJam, versionné.

  • Repo + modèles dbt

    Projet dbt versionné et testable ; couche staging / intermediate / marts, documentation incluse.

  • Semantic layer (LookML / modèles Metabase)

    La couche de metric definitions communes derrière les questions que l'unité métier pose.

  • Pack de dashboards

    15 à 25 premiers panneaux organisés par catégorie de décision (CAC, retention, revenue quality) ; chacun par rôle + fréquence.

  • Système d'alerte à seuil

    Drift detector ML + forecast band + intégration Slack/email ; alerte en quelques heures dès qu'une métrique se dégrade.

  • Rapport cohort + retention

    Tables D1/D7/D30/D90 + courbes LTV + analyse de churn par segment + taux de resurrection.

  • Modèle MMM + rapport

    MMM bayésien (Robyn/PyMC) ; contribution canal + saturation + adstock + confidence band.

  • Protocole de test d'incrementality

    Framework de test geo-holdout et matched-market ; templates de planification + exécution + analyse.

  • Runbook de data governance

    PII tagging, schema registry, politique de retention, audit des accès — conforme KVKK + RGPD.

  • Synthèse mensuelle du data council

    Questions répondues, questions restées, dashboards utilisés, liste priorisée pour le mois suivant.

  • Support de formation self-serve

    Vidéos de formation Metabase / Lightdash / Hex pour l'unité métier + glossaire SQL / jargon + jeu de données d'entraînement.

— PÉRIMÈTRE

Ce qui est inclus, ce qui ne l'est pas

Les limites de l'opération analytique sont nettes. Voir le périmètre à l'avance élimine les attentes erronées et le scope creep.

Ce que couvre cette prestation

  • Inventaire des décisions + premier sprint sur 30 questions
  • KPI tree + ownership écrit + document versionné
  • Mise en place du repo dbt + couches staging/intermediate/marts
  • Intégration warehouse (BigQuery / Snowflake / Redshift / Databricks)
  • Semantic layer LookML ou Metabase
  • Premiers 15-25 dashboards + ajouts trimestriels
  • Détection d'anomalies ML + système d'alerte à seuil
  • Analytics cohort + LTV + retention — mise à jour trimestrielle
  • MMM bayésien (3 refresh par an)
  • Protocole + exécution de tests d'incrementality
  • Runbook de data governance (PII, retention, audit)
  • Data council mensuel + flux de formation self-serve

Éléments non inclus (périmètre optionnel)

  • BI finance / comptabilité (côté ERP, conseil séparé)
  • Coût de compute / licence warehouse (contrat client)
  • Entraînement de modèles ML custom (hors forecasting)
  • Infrastructure de streaming temps réel (Kafka, Kinesis — périmètre séparé)
  • Conseil data privacy / juridique (avec avocat partenaire)
  • Renouvellements de licences d'outils BI
  • Achats de données tierces (panel, survey)
  • Opérations marketing elles-mêmes (PPC / SEO / CRO prestations distinctes)

HOW WE WORK

Processus : du diagnostic semaine 1 à la gouvernance mois 6+, une opération analytique

01

Semaines 1-2 — Inventaire des décisions + audit

Liste des 30 questions stratégiques, inventaire des dashboards existants, santé des sources de données et diagnostic SLA.

02

Semaine 3 — KPI tree + schéma

KPI tree écrit, metric definitions, ownership ; schéma warehouse + couche staging arbitrés.

03

Semaines 4-5 — Modèles dbt + premiers dashboards

dbt staging + intermediate + marts ; publication des 5-8 premiers dashboards ; stakeholder review.

04

Semaines 6-8 — Alerte + cohort + refresh

Système d'alerte à seuil, rapports cohort + retention, pipeline de refresh dbt Cloud / Airflow.

05

Mois 3 — Entraînement MMM + premier résultat

MMM bayésien sur 18 mois d'historique ; contribution canal + saturation + première recommandation de révision budgétaire.

06

Mois 4 — Protocole de test d'incrementality

Framework geo-holdout ou matched-market ; premier test en production, résultat 4 à 6 semaines plus tard.

07

Mois 5 — Data council + formation self-serve

Lancement de la routine mensuelle du data council ; flux de formation self-serve Metabase / Lightdash pour l'unité métier.

08

Mois 6+ — Refresh trimestriel + governance

Refresh MMM trimestriel, cycle de tests d'incrementality, audit de data governance ; transfert complet possible au mois 12.

— BOÎTE À OUTILS

La stack analytique du warehouse au BI

Nous travaillons de manière agnostique sur l'outillage ; il existe néanmoins à chaque couche des choix ouverts qui produisent le plus de valeur. Nous nous adaptons à votre stack existante.

WAREHOUSE

BigQuery (économique, on-demand)Snowflake (enterprise, compute séparé)Redshift (dans une stack AWS)Databricks (usage à forte composante ML)Postgres (petite-moyenne échelle)

MODÉLISATION & TRANSFORM

dbt (core + cloud)Dataform (natif GCP)Coalesce (visual)Airflow / Dagster (orchestration)Fivetran / Stitch / Airbyte (ingestion)

BI & VISUAL

Looker (semantic layer LookML)Metabase (self-hosted self-serve)Lightdash (BI dbt-native)Tableau (enterprise)Hex / Mode (notebook-driven)Looker Studio (quick-win)

ML & MMM

Robyn (MMM open source de Meta)PyMC / Pyro (modélisation bayésienne)scikit-learn (drift detection)Prophet (forecasting)GeoLift (incrementality)Monte Carlo / Great Expectations (data quality)

QUESTIONS

Frequently asked

Pour certaines entreprises, oui ; en dessous de 10 dashboards, sans cross-table join, sur des opérations mono-canal, Looker Studio est une solution pratique. Mais dès qu'on dépasse 30 dashboards, avec un modèle de données versionné et un besoin d'accès role-based, Looker / Metabase / Lightdash deviennent nécessaires.

— GLOSSAIRE

Terminologie analytique

Entre équipes, quand un même terme renvoie au même concept, la discussion accélère la décision ; quand il renvoie à autre chose, il alimente le doute.

01
KPI Tree
Hiérarchie arborescente des métriques qui se décomposent depuis l'output business principal vers le bas ; chaque nœud déclenche une décision.
02
dbt
Data build tool — framework de transformation de données SQL, versionné et testable ; standard de l'analytics engineering.
03
Semantic Layer
Couche commune de metric definitions + business logic derrière l'outil BI ; avec LookML, Metabase models, Cube, etc.
04
Cohort
Groupe d'utilisateurs partageant une caractéristique (date d'inscription, canal d'acquisition) ; son comportement est analysé dans le temps.
05
LTV (Lifetime Value)
Valeur totale sur la durée de vie d'un client ; gross margin × retention × fréquence de commande × valeur de panier.
06
Retention
Pourcentage d'utilisateurs acquis encore actifs dans une fenêtre donnée (D1, D7, D30, M1, M3). En SaaS et mobile games c'est une lecture directe du product-market fit ; une courbe de cohorte qui s'aplatit est la signature d'un produit sain.
07
Churn
Pourcentage d'utilisateurs qui quittent la base client active sur une fenêtre donnée. En subscription il frappe directement le MRR ; en e-commerce c'est l'inverse du repeat rate. On distingue voluntary (annulé) et involuntary (échec paiement) ; on le baisse via onboarding, pricing et messaging lifecycle.
08
MMM (Marketing Mix Modeling)
Modèle statistique bayésien qui estime la contribution des canaux ; nécessite 18 à 24 mois d'historique.
09
Incrementality
Conversions additionnelles qui n'auraient pas eu lieu sans un canal ; mesurée par tests geo-holdout, indépendamment de l'attribution.
10
Anomaly Detection
Famille de techniques qui repèrent automatiquement les valeurs hors plage attendue dans des métriques temporelles (KPI, conversion, latence, signal de fraude). On utilise STL decomposition, Prophet, isolation forest, modèles OoD neuronaux ; cerveau de l'alerting et des dashboards d'observabilité.
11
Self-Serve Analytics
Environnement où l'unité métier répond elle-même à ses questions sans attendre la data team ; avec Metabase, Lightdash, Hex.
12
Data Governance
Ensemble des politiques de qualité, de contrôle des accès, de gestion des PII, de retention et d'audit ; conformité KVKK/RGPD.
13
ETL / ELT
Extract → Transform → Load (ancien) vs Extract → Load → Transform (moderne). Approches pour déplacer la donnée de la source au warehouse. L'ELT s'appuie sur le compute bon marché des DW cloud ; dbt + BigQuery/Snowflake/Databricks est le standard actuel.
14
Data Lake
Stockage central pour toutes les données structurées et non structurées (logs, images, vidéo, raw events) sans imposer de schéma. Sur S3, GCS ou ADLS en Parquet/Iceberg/Delta Lake ; complète le warehouse et fonde l'architecture lakehouse.
15
Stream Processing
Traiter la donnée en flux d'événements temps réel plutôt qu'en batchs. Stacks courants : Kafka + Flink/Spark Streaming/Kinesis + ksqlDB ; cas d'usage : fraud detection, personnalisation temps réel, télémétrie IoT, anomaly alerting.
16
Data Contract
Contrat préalable entre producteurs et consommateurs de données sur schéma, sémantique, SLA et ownership. Outillé avec dbt + Great Expectations + JSON Schema ; le mur le plus fiable contre la surprise « un modèle downstream vient de casser ».
17
LLM (Large Language Model)
Modèle de langage généraliste avec des milliards de paramètres transformer, pré-entraîné sur d'immenses corpus de texte. GPT-5, Claude, Gemini, Llama ; moteur pour chat, code, résumé, traduction, retrieval et tâches d'agent — spécialisé par fine-tuning ou prompt engineering.
18
Transformer
Architecture de réseau de neurones introduite dans "Attention Is All You Need" (2017) qui capte les relations à longue distance dans les données séquentielles via self-attention. Successeur des RNN et LSTM ; substrat de tout LLM moderne (GPT, Claude, Llama, Gemini) et modèles vision (ViT).
19
Embedding
Représentation vectorielle haute dimension d'un mot, phrase, image ou utilisateur — la similarité sémantique se mesure par proximité de vecteurs. Monnaie commune pour la recommandation, semantic search, RAG, clustering et anomaly detection ; OpenAI ada, Cohere et sentence-BERT sont des producteurs courants.
20
RAG (Retrieval-Augmented Generation)
Architecture où le LLM récupère, avant de générer la réponse, des documents pertinents depuis une base externe (vector DB, doc store) et les injecte dans le contexte. Réduit l'hallucination et constitue la voie standard pour donner au modèle un accès "open-book" à des données fraîches/privées — trio embedding + retriever + LLM.
21
Vector Database
Base de données qui stocke des embeddings dans un espace vectoriel haute dimension et trouve des vecteurs similaires en millisecondes via des algorithmes ANN (Approximate Nearest Neighbor). Pinecone, Weaviate, Qdrant, pgvector, Chroma ; le vrai moteur du retrieval dans RAG.
22
Fine-tuning
Processus de réentraîner un foundation model pré-entraîné sur des données étiquetées supplémentaires (souvent petites) pour une tâche ou un domaine spécifique. Full fine-tune, LoRA/QLoRA et instruction-tuning sont les variantes courantes ; substrat des cas "assistant custom" sur ChatGPT & co.
23
LoRA (Low-Rank Adaptation)
Technique de fine-tuning paramètre-efficace qui ajoute de petites matrices "adapter" au lieu de mettre à jour tous les poids du foundation model. Entraîne ~0,1-1 % des paramètres, réduit la mémoire GPU de 70 %+ ; le swap d'adapter par tâche rend le serving multi-task pratique.
24
RLHF (Reinforcement Learning from Human Feedback)
Étape finale du pipeline d'entraînement d'un LLM qui aligne les sorties du modèle avec les préférences d'évaluateurs humains. Un reward model + algorithme PPO/DPO pousse le modèle vers "utile, honnête, inoffensif" ; base de l'alignment de ChatGPT.
25
Hallucination
Lorsqu'un LLM invente avec assurance une source, un fait ou une citation inexistante. Cause : le modèle répond avec la même confiance à des questions hors-distribution de ses données d'entraînement ; atténué par RAG, citation grounding et self-consistency — jamais éliminé totalement.
26
Prompt Engineering
Discipline qui consiste à concevoir systématiquement le prompt (instruction + contexte + exemples + format) pour que le LLM produise la sortie voulue. Few-shot, chain-of-thought, role assignment, output schema, system prompt ; couche "comment lui parler" de toute app IA en prod.
27
Context Window
Nombre de tokens (entrée + sortie) qu'un LLM peut traiter en un appel. Va de 8K-128K (GPT-4) à 200K (Claude) et 1M+ (Gemini) ; capacité décisive pour l'analyse de documents longs, la conversation multi-tour et l'agent state — RAG est la voie alternative pour "étendre" le contexte.
28
Function Calling / Tool Use
Capacité d'un LLM à invoquer une fonction externe (API, requête BDD, code-runner) via JSON structuré au lieu de texte libre. OpenAI tools, Anthropic tool_use ; protocole officiel par lequel les agents touchent au monde réel.
29
AI Agent
Construction logicielle qui utilise un LLM comme moteur de décision et exécute des tâches multi-étapes en autonomie via tool calling + mémoire + boucle plan-execute. ReAct, AutoGPT, agents Claude/GPT, LangGraph ; architecture "rechercher → planifier → exécuter des tools → atteindre le but".
30
Foundation Model
Grand modèle pré-entraîné sur des données larges et diverses à l'échelle internet, transférable à des tâches downstream — LLMs, modèles vision (CLIP, ViT), multimodaux (GPT-4o, Gemini). On bâtit dessus des applications via fine-tuning, prompt engineering ou RAG.
31
Multimodal AI
Système IA dans lequel un même modèle comprend et génère sur plusieurs modalités — texte + image + audio + vidéo. GPT-4o, Gemini, Claude 3.5 vision ; substrat de cas cross-modal comme OCR, image captioning, vidéo Q&A, transcription audio et agents screen-aware.
32
NLP (Natural Language Processing)
Sous-discipline de l'IA centrée sur la capacité d'un ordinateur à comprendre, générer et transformer le langage naturel (turc, anglais, etc.). Tokenization, POS tagging, NER, analyse de sentiment, traduction automatique ; les LLMs sont aujourd'hui les outils généralistes les plus puissants.
33
Token
Plus petite unité textuelle traitée par un LLM — peut être un mot, un sous-mot ou un seul caractère. Un tokeniser (BPE, WordPiece, SentencePiece) convertit le texte en tokens ; le pricing OpenAI et les limites de context window se comptent en tokens (1 mot anglais ≈ 1,3 token).
34
Temperature
Paramètre qui contrôle la « randomness » de la distribution de sortie d'un LLM — 0 = toujours le token le plus probable (déterministe), 1+ = plus créatif/varié. Valeurs courantes : 0-0,3 pour code/JSON/numérique, 0,7-1,2 pour narration/brainstorm ; ajusté avec top_p.
35
Semantic Search
Approche de recherche qui renvoie des résultats fondés sur le sens en comparant les embeddings de la requête et des documents, plutôt que des mots-clés. Indépendant de l'orthographe, capte les synonymes ; moteur de retrieval de RAG — bâti sur vector DB + ANN.
36
Inference
Phase où un modèle IA entraîné produit prédictions/génération sur données live (l'opposé du training). Latence, throughput, coût par requête et la stack de model serving (vLLM, TGI, Triton) ; ~90 % du côté production du MLOps.
37
OLTP (Online Transaction Processing)
Approche de base de données optimisée pour des lectures/écritures à fort volume, par ligne, faible latence. PostgreSQL, MySQL, MongoDB ; stockage standard derrière les backends d'app live — panier e-commerce, session utilisateur, réservation.
38
OLAP (Online Analytical Processing)
Approche BDD colonnaire optimisée pour des requêtes analytiques à grande échelle. BigQuery, Snowflake, Redshift, ClickHouse ; scanne des millions de lignes en secondes pour agrégation, GROUP BY et time-series — infra du BI et des dashboards.
39
ACID
Les quatre garanties des BDD transactionnelles : Atomicity (tout ou rien), Consistency (les règles tiennent), Isolation (les ops concurrentes ne se voient pas), Durability (les données commitées persistent). Contrat noyau des RDBMS comme PostgreSQL, MySQL, Oracle.
40
BASE
Le jeu de garanties relâché des systèmes distribués/NoSQL : Basically Available, Soft state, Eventual consistency. L'opposé d'ACID — accepte une inconsistance brève contre availability + scale. Philosophie de DynamoDB, Cassandra, Riak.
41
Sharding
Découper une BDD selon une clé (user_id mod 16, plage temporelle) et stocker chaque shard sur un serveur distinct. Méthode de scaling horizontal ; les JOINs cross-shard deviennent impraticables, et le choix du shard-key est une décision architecturale irréversible.
42
Replication
Maintenir une copie vivante de la BDD sur plusieurs serveurs — pour répartir la charge de lecture (read replicas) et fournir un failover. Async (Postgres streaming) est laggy mais rapide, sync est consistant mais lent ; chaque stratégie est un tradeoff.
43
Eventual Consistency
Dans un système distribué, une mise à jour a besoin de temps pour se propager à toutes les réplicas — pendant une courte fenêtre, différents nœuds peuvent renvoyer des valeurs différentes. Default DynamoDB et Cassandra ; pas pour le banking, idéal pour le social.
44
CDC (Change Data Capture)
Pattern qui capte les événements INSERT/UPDATE/DELETE d'une BDD en temps réel et les pousse vers les systèmes downstream (warehouse, search index, cache). Debezium, Kafka Connect ; sur replication slots + log tailing, alternative moderne au polling.
45
Star Schema
Approche de modélisation warehouse où une table de faits centrale (ex. orders) est entourée de tables de dimension (customer, product, date) en étoile. Les requêtes BI ont besoin de peu de JOINs = rapides ; architecture canonique pour BigQuery, Snowflake.
46
Materialized View
Objet de BDD qui écrit physiquement sur disque le résultat d'une requête SELECT et le cache. Pré-calcule une agrégation complexe au lieu de la recalculer à chaque fois ; la stratégie de refresh (manuel, planifié, incrémental) est le tradeoff.
47
Normalization
Processus de découper un schéma BDD en tables liées pour éliminer redondance et anomalies de mise à jour (1NF, 2NF, 3NF, BCNF). Standard pour l'OLTP ; garantit que chaque update se passe à un seul endroit — au prix de plus de JOINs.
48
Denormalization
Fusionner délibérément des tables normalisées et accepter la redondance contre la performance de requête. Standard pour l'OLAP / data warehouse ; réduit le coût des JOINs, le risque d'incohérence est géré via ETL/CDC.
49
Time-series Database
BDD optimisée pour des écritures à fort volume de métriques horodatées (CPU, capteurs IoT, tickers finance) et des requêtes sur intervalle temporel. InfluxDB, TimescaleDB, Prometheus, ClickHouse ; downsampling + retention policy sont les features clés.
50
Iceberg / Hudi / Delta Lake
Projets open-source qui ajoutent une couche « table format » sur l'object storage (S3, GCS), apportant schema evolution, ACID, time-travel et concurrent writers. Les trois moteurs standard de l'architecture lakehouse.
51
Data Quality
Discipline qui mesure un dataset sur exactitude, complétude, cohérence, fraîcheur et unicité. Great Expectations, Monte Carlo, Soda automatisent les tests ; seule vraie défense contre le « garbage in, garbage out ».
52
Data Lineage
Graphe traçable de chaque étape de transformation qu'un point de donnée traverse, de la source (event brut) à l'utilisateur final (KPI dashboard). Atlan, OpenMetadata, dbt docs ; réponse déterministe à « d'où vient ce KPI » plus impact analysis.
53
Data Mesh
Structure de data products self-serve par domaine (marketing, finance, product) au lieu d'une équipe data centrale. Bâtie sur domain ownership + product thinking + federated governance ; réponse au problème de la « data team bottleneck » à l'échelle.
54
Data Catalog
Catalogue central qui indexe chaque actif de données d'une organisation (table, dashboard, modèle ML, colonne) avec recherche, descriptions et ownership. Atlan, Collibra, OpenMetadata, Amundsen ; réponse à « cette donnée existe-t-elle, qui en est propriétaire ? ».
55
Schema Evolution
Capacité d'un format de données (Avro, Parquet, JSON) à évoluer dans le temps sans casser les consommateurs existants quand on ajoute des champs. Exige de la discipline sur backward + forward compatibility, champs optionnels et defaults ; critique pour CDC, event sourcing, lakehouse.
56
AWS DynamoDB
BDD serverless NoSQL key-value + document d'AWS. Latence à un chiffre ms à des milliards de requêtes/sec, partitioning automatique, point-in-time recovery, global tables (multi-région). Idéale pour backends de jeu, télémétrie IoT, sessions, leaderboards.
57
GCP Spanner
BDD relationnelle de Google, scalable globalement, ACID-compliant, horizontalement scalable. Syntaxe SQL + scale type DynamoDB + transactions type PostgreSQL ; uptime multi-région 99,999 % ; fait tourner Google Ads/Maps, idéale pour la fintech.
58
Azure Cosmos DB
BDD NoSQL multi-modèle, à l'échelle globale, de Microsoft Azure. APIs SQL, MongoDB, Cassandra, Gremlin (graph) et Table sur le même moteur ; cinq niveaux de consistance (strong → eventual) ; latence et throughput sous SLA.
59
Prometheus
Couche métrique du stack monitoring cloud-native. Scraping pull-based depuis les endpoints /metrics ; PromQL pour les requêtes time-series ; Alertmanager pour les règles d'alerte. Standard de-facto sur Kubernetes et les architectures microservices modernes.
60
Grafana
Plateforme open-source de visualisation de données et de dashboards. Unifie 100+ sources (Prometheus, Loki, Elasticsearch, CloudWatch, Postgres…) dans un seul panel ; alerting, annotations, templating ; pilier des écrans NOC d'équipes SRE.
61
Jaeger
Plateforme CNCF de distributed tracing. Capture chaque hop d'une requête utilisateur entre microservices sous forme de spans ; visualise les goulets de latence, dépendances manquantes et propagations d'erreur. 100 % compatible OpenTelemetry.
62
OpenTelemetry (OTel)
Projet CNCF unifiant l'observabilité (metrics, logs, traces) sous un standard vendor-neutral unique. SDK et auto-instrumentation rendent le code portable entre Datadog, New Relic, Honeycomb, Jaeger — fini le vendor lock-in.
63
ELK Stack
Elasticsearch + Logstash + Kibana — stack open-source d'agrégation, indexation et visualisation de logs. Logstash ingère, Elasticsearch indexe en full-text search, Kibana fait les dashboards. Loki + Grafana gagne du terrain à l'échelle, mais ELK reste très répandu.
64
SLI (Service Level Indicator)
Indicateur numérique de la santé d'un service — taux de succès, latence p99, disponibilité. Base de mesure d'un SLO ; réponse objective à « quel % de requêtes < 200 ms ? ». Concept fondamental du SRE Book de Google.
65
SLO (Service Level Objective)
Valeur cible interne qu'un SLI doit atteindre — ex. « latence p99 < 200 ms sur 99,9 % d'une fenêtre de 30 jours ». Réponse de l'ingénierie à « jusqu'où la fiabilité est suffisante » ; fondation de l'error budget.
66
SLA (Service Level Agreement)
Contrat externe entre prestataire et client ; reflet légal d'un SLO. Une violation déclenche pénalités (remboursements/credits). Règle : SLA < SLO < SLI — l'ingénierie vise plus strict que la garantie publique.
67
Error Budget
La « quantité d'échec autorisée » qui découle d'un SLO. SLO 99,9 % = 0,1 % d'error budget = ~43 min de downtime/mois. Budget restant → prendre des risques (releases) ; budget épuisé → mode stabilisation. Équilibre SRE innovation/fiabilité.
68
Diffusion Model
Famille de modèles génératifs qui apprennent à ajouter du bruit aux données puis à inverser le processus. Architecture-clé des générateurs image/vidéo modernes (Stable Diffusion, Midjourney, DALL-E 3, Sora). S'entraîne beaucoup plus stablement que les GAN et produit des sorties plus variées.
69
GAN (Generative Adversarial Network)
Modèle génératif où deux réseaux de neurones — Generator (faux) et Discriminator (juge vrai/faux) — s'entraînent en s'affrontant. Introduit par Ian Goodfellow en 2014 ; techno derrière les premiers deepfakes, les portraits StyleGAN, la super-résolution. Aujourd'hui largement éclipsé par les diffusion models.
70
CLIP (Contrastive Language-Image Pre-training)
Modèle OpenAI de 2021 qui aligne images et captions dans un même espace d'embeddings — l'embedding de « photo de chat » atterrit près des vraies photos de chat. Conditionneur text-to-image de Stable Diffusion ; base de la classification image zero-shot et de la recherche visuelle.
71
ControlNet
Architecture de 2023 qui ajoute un signal de conditionnement aux diffusion models. Pilote la génération via des références comme pose, depth map, canny edges ou scribbles, permettant des contrôles précis (« cette pose mais d'autres vêtements »). L'un des add-ons les plus utilisés de l'écosystème Stable Diffusion.
72
Adapter Tuning
Approche de fine-tuning qui insère de petites couches « adapter » dans un grand modèle de langage au lieu de ré-entraîner tous les paramètres. Variantes populaires : LoRA, QLoRA, IA³ ; <1 % des paramètres d'origine sont entraînés, le coût GPU s'effondre.
73
PEFT (Parameter-Efficient Fine-Tuning)
Terme parapluie regroupant les approches qui entraînent un petit sous-ensemble de paramètres plutôt qu'un fine-tuning complet d'un LLM 70B. LoRA, prompt tuning, prefix tuning, adapter tuning sont toutes du PEFT. La librairie peft d'HuggingFace est l'outil standard.
74
Quantization (LLM)
Technique qui compresse les poids float32/float16 d'un modèle en int8, int4 voire int2. Mémoire ÷ 4-8, inférence ×2-3, perte de qualité généralement faible. Llama.cpp, le format GGUF et les algorithmes AWQ/GPTQ forment l'outillage classique.
75
Knowledge Distillation
Technique qui transfère le comportement d'un grand modèle « teacher » vers un petit modèle « student ». En ciblant les probabilités douces du teacher, le student atteint une précision quasi identique avec bien moins de paramètres. L'astuce derrière DistilBERT, TinyLlama, Phi-3.
76
Mixture of Experts (MoE)
Architecture qui, au lieu d'un modèle monolithique, route chaque token vers une sélection éparse (un ou deux) de petits sous-modèles « experts ». Utilisée dans Mixtral 8x7B, GPT-4, DeepSeek ; réduit le nombre de paramètres actifs tout en gardant la capacité et baissant le coût d'inférence.
77
Speculative Decoding
Technique qui accélère l'inférence LLM : un petit modèle « draft » propose plusieurs tokens à l'avance, le grand modèle « target » les vérifie en parallèle et accepte les bons. Accélération ×2-3 sans perte de qualité. Standard dans vLLM et llama.cpp.
78
KV Cache
Optimisation qui garde en mémoire les matrices Key et Value calculées pour les tokens précédents dans les couches d'attention transformer. Chaque nouveau token ne calcule que son K/V au lieu de rejouer l'historique. Inférence ×10-100, mais goulot mémoire sur contexte long.
79
Attention Head
L'un des multiples petits mécanismes d'attention exécutés en parallèle dans un Transformer. Chaque head se concentre sur un aspect différent de l'entrée — syntaxe, position, dépendances longue distance. GPT-4 utilise 96+ heads par couche ; brique de la multi-head attention.
80
BPE Tokenizer (Byte-Pair Encoding)
Algorithme de tokenisation qui découpe le texte en sous-mots les plus fréquents — ex. « tokenization » → « token » + « ization ». GPT, LLaMA, Mistral utilisent des variantes BPE (tiktoken, SentencePiece) ; vocabulaire fixe (~32K-128K), problème d'OOV résolu.
81
DPO (Direct Preference Optimization)
Alternative plus simple au RLHF. Au lieu de la complexité reward model + PPO, fait une régression logistique directe sur des paires « préférée vs rejetée ». Stanford 2023 ; plus stable, moins d'hyperparamètres, méthode d'alignement choisie dans Llama 3 et beaucoup d'autres.
82
Constitutional AI
Méthode introduite par Anthropic en 2022 qui aligne un modèle avec une « constitution » écrite (liste de principes éthiques) plutôt que des reviewers humains. Le modèle critique et améliore ses propres sorties contre la constitution ; fondation de l'alignement de Claude, aussi appelée RLAIF.
83
Chain-of-Thought (CoT)
Technique de prompting qui demande au LLM de « penser pas à pas » et d'écrire son raisonnement intermédiaire avant la réponse. Introduite par un papier Google de 2022 ; améliore drastiquement maths, logique et questions multi-étapes. « Let's think step by step » est la phrase magique. Fondation des reasoning models (o1, DeepSeek-R1).
84
Few-Shot Prompting
Technique fournissant 2-5 exemples (paires input → output) dans le prompt pour que le LLM applique le même pattern à un nouvel input. Adaptation rapide sans fine-tune — « réponds comme dans ces exemples ». Solution la plus pratique pour la classification labellisée et l'extraction formatée.
85
Zero-Shot Prompting
Approche prompting où la tâche est décrite directement au LLM sans exemple — ex. « traduis ce texte en allemand ». S'appuie uniquement sur la connaissance issue du pre-training ; avec les modèles frontière (GPT-4, Claude) c'est suffisant pour la plupart des tâches.
86
Grounding (LLM)
Technique qui « ancre » la réponse d'un LLM dans une source de connaissance externe — documents, base de données ou recherche web. Le contexte récupéré remplace la mémoire paramétrique pure ; les hallucinations chutent, les citations deviennent possibles, le savoir reste à jour en temps réel.
87
Structured Output (LLM)
Capacité à forcer la sortie d'un LLM à respecter un JSON schema, un modèle Pydantic ou une regex. OpenAI structured outputs, Anthropic tool use, vLLM grammar-constrained sampling. Clé du passage du texte libre à un flux de données déterministe prêt pour la production.
88
Tool Use (Agent)
Capacité d'un LLM à appeler des outils externes — recherche web, code interpreter, calculatrice, APIs custom. Via le protocole function calling, le modèle renvoie « nom d'outil + paramètres », le runtime exécute et réinjecte le résultat. Cœur des architectures agent (Claude Agent SDK, AutoGen, LangGraph).
89
Cross-Modal Embedding
Embeddings qui représentent différentes modalités (texte, image, audio) dans un même espace vectoriel. CLIP pour image+texte, ImageBind pour texte+image+audio+vidéo+depth+thermique+IMU. Critique pour la recherche multimodale (« trouve un copy similaire à cette photo »), le cross-modal retrieval et l'ajout de media en RAG.
90
Hybrid Search (BM25 + Vector)
Stratégie de retrieval qui combine la recherche par mots-clés classique (BM25/lexical) avec la similarité vectorielle. BM25 gagne sur l'exact-match (IDs, codes produit) ; les vecteurs sur le sémantique (« comment je retourne ça » → « politique de retour »). Référence du RAG moderne.
91
Data Fabric
Architecture intégrée qui unifie des sources de données distribuées (cloud, on-prem, SaaS) en une seule couche de données logique. Métadata-driven et AI-augmented ; alternative « intégration centralisée » au modèle d'ownership distribué du data mesh. Talend, Informatica, IBM Cloud Pak sont les produits clés.
92
Medallion Architecture
Pattern d'organisation de data lake popularisé par Databricks — couches Bronze (brut), Silver (nettoyé, conformé) et Gold (business-ready, agrégé). Chaque couche s'appuie sur la précédente, séparant proprement lineage, qualité et reprocessing.
93
Apache Spark
Moteur distribué de traitement de données en mémoire. Successeur 10-100× plus rapide de Hadoop MapReduce ; rassemble SQL, streaming, ML (MLlib) et graphe (GraphX) sous une seule API. Cœur de Databricks, managé sur AWS EMR, GCP Dataproc, Azure HDInsight ; PySpark en fait l'outil principal du data engineer.
94
Apache Flink
Moteur de traitement true streaming (événement par événement). Face au micro-batch de Spark Streaming : latence milliseconde, exactly-once et traitement stateful. Anime la détection de fraude et d'anomalies en temps réel chez Alibaba, Uber et Netflix.
95
Kafka Connect
Framework de connecteurs source/sink d'Apache Kafka. Fait du CDC ou de l'ingestion batch depuis 100+ systèmes (Postgres, MySQL, S3, Elasticsearch, Snowflake…) vers Kafka et exporte en streaming vers des systèmes externes. Le catalogue 1 000+ de Confluent fait référence.
96
Singer
Protocole open-source d'intégration de données issu de Stitch (aujourd'hui Talend), qui déplace des streams JSON entre des « taps » (extract) et des « targets » (load). Framework ELT modulaire et indépendant ; cœur des plateformes ELT open-source comme Meltano.
97
Apache Airflow
Plateforme d'orchestration de workflows dont les DAG (graphes acycliques dirigés) sont définis en Python. Créée chez Airbnb en 2014, donnée à l'Apache Foundation. Scheduling, retries, gestion des dépendances, UI web ; standard de-facto des data pipelines.
98
Dagster
Framework moderne d'orchestration de données basé sur les assets. Là où Airflow est centré sur les tâches, Dagster est centré sur les « data assets » — avec lineage, type-checking, software-defined assets et testing intégrés. Intégrations natives avec dbt, Fivetran, Snowflake.
99
Prefect
Outil moderne et pythonique d'orchestration de données aux DAG dynamiques. Résout la limite des DAG statiques d'Airflow — les flows changent à runtime — avec exécution hybride (cloud + self-hosted) et policies de retry granulaires. Très populaire pour les pipelines ML.
100
Snowflake
Data warehouse managé cloud-native. Compute (warehouse) et storage sont totalement découplés et scalent indépendamment. SQL sur données semi-structurées (JSON, Parquet), data sharing sécurisé, time travel (jusqu'à 90 jours) ; sérieuse alternative à BigQuery et Redshift.
101
BigQuery
Data warehouse serverless, columnar, à l'échelle pétaoctet de Google Cloud. Tarification au slot ; entraînement de modèles ML en SQL (BQML) ; cible d'export native de GA4 ; optimisations geo, JSON et PARTITION/CLUSTER intégrées. Cœur du stack analytics GCP.
102
Databricks
Plateforme lakehouse fondée par les créateurs d'Apache Spark. Combine couches Bronze/Silver/Gold (medallion), Delta Lake, MLflow, Unity Catalog et workspaces notebooks dans un seul produit. Pensée pour la collaboration data engineer + analyst + ML engineer ; native sur AWS, Azure, GCP.
103
Apache Iceberg
Format de table open à l'échelle pétaoctet (origine Netflix). Ajoute ACID, schema evolution, time travel, hidden partitioning et branching au-dessus de Parquet. Supporté par Snowflake, Databricks, BigQuery, Trino ; la réponse standard au vendor lock-in des data warehouses.
104
Delta Lake
Format de table open développé par Databricks, rival d'Apache Iceberg. ACID, time travel, schema enforcement, MERGE/UPDATE/DELETE ; intégration la plus étroite côté écosystème Spark. Format par défaut côté Databricks de l'architecture lakehouse.
105
Parquet
Format de stockage columnar — chaque colonne dans ses propres blocs. Seules les colonnes utiles sont lues, predicate pushdown supporté, Snappy/Zstd offrent une forte compression. Format par défaut pour Spark, Iceberg, Delta, Snowflake ; analytique 10-100× plus rapide que CSV/JSON par lignes.
106
Apache Avro
Format de sérialisation binaire avec schémas définis en JSON. Schema evolution solide (forward/backward compat) ; particulièrement populaire pour les payloads Kafka. S'utilise avec un Schema Registry ; pendant row-oriented de Parquet.
107
Schema Registry
Service qui stocke, versionne et vérifie la compatibilité de schémas Avro/Protobuf/JSON de façon centralisée. Composant du stack Kafka Confluent ; applique le contrat producer-consumer et attrape les breaking changes avant la prod.
108
Window Function (SQL)
Fonctions SQL qui calculent sur un ensemble de lignes (« window »). ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, SUM/AVG OVER (PARTITION BY…). À la différence de GROUP BY, les lignes ne sont pas agrégées — chacune garde son résultat. Indispensables pour les séries temporelles, les classements et les totaux glissants.
109
ELT (Extract, Load, Transform)
L'inverse de l'ETL classique : les données brutes sont chargées d'abord dans le warehouse/lake et y sont transformées via SQL/dbt. Avec le storage cloud-DWH bon marché et un compute puissant, ELT est devenu le paradigme par défaut ; il rapproche la logique de transformation des analystes.
110
Feature Store
Plateforme qui stocke et sert centralement les features (historique + temps réel) consommées par les modèles ML. Résout le training-serving skew en dérivant les vues offline (batch) et online (low-latency) d'une seule définition. Outils principaux : Feast, Tecton, Hopsworks.
111
MLOps
Discipline qui automatise la boucle développement-entraînement-déploiement-monitoring-ré-entraînement des modèles ML. DevOps appliqué au ML — experiment tracking (MLflow), model registry, CI/CD pour modèles, drift detection, pipelines de retraining.
112
OpenLineage
Standard ouvert pour les événements de data lineage (LF AI & Data). Permet à Airflow, Spark, dbt, Flink et d'autres d'émettre des événements de lineage au même format. Intégré dans Marquez, Datakin, Astronomer ; vecteur vendor-neutral du flux de métadonnées.
113
Great Expectations
Framework open-source de qualité / validation des données. Des milliers de checks prêts à l'emploi comme « expect_column_values_to_be_unique » ou « expect_column_mean_to_be_between » ; s'intègre aux pipelines Airflow/dbt et génère automatiquement des data docs HTML.
114
Apache Atlas
Outil open-source de gestion des métadonnées et data governance issu de l'écosystème Hadoop. Contrôle d'accès par tags, graphes de lineage, glossaire métier et classifications (PII/PCI). Standard dans le stack Hortonworks/Cloudera ; alternatives modernes : Amundsen, DataHub.
115
Lambda Architecture (Data)
Architecture de données qui fusionne résultats temps réel et batch. La speed layer (Storm/Flink) fournit des résultats approximés à faible latence ; la batch layer (Spark/Hadoop) calcule des résultats précis mais lents ; la serving layer les fusionne. À ne pas confondre avec AWS Lambda ; évolue aujourd'hui vers l'architecture Kappa.
116
Differential Privacy
Cadre mathématique qui permet un accès sûr aux statistiques de population tout en protégeant les enregistrements individuels. Un bruit calibré est ajouté aux résultats de requête ; un attaquant ne peut pas dire si les données d'une personne donnée sont dans le set. Utilisé par le clavier iOS d'Apple, Google Play, le US Census 2020.
117
Federated Learning
Technique qui entraîne le modèle localement sur les appareils des utilisateurs et n'envoie au serveur central que les mises à jour de gradients ou de poids — jamais les données brutes. Auto-suggest de Google Gboard, Siri d'Apple et ML privacy-preserving sur la santé sont les cas canoniques.
118
On-Chain Analytics
Discipline d'extraction d'insights à partir des données publiques de transactions d'une blockchain — activité wallet, concentration de token holders, flux d'exchange, tracking smart money, volume NFT. Dune Analytics (SQL on-chain), Nansen (adresses labellisées), Glassnode, Arkham en plateformes-clés.
119
Oracle (Blockchain)
Service-pont qui apporte des données off-chain fiables — prix, météo, résultats sportifs, capteurs IoT — vers des smart contracts on-chain. Chainlink est le plus utilisé ; Pyth, Band, RedStone sont des alternatives. Infrastructure vitale pour les liquidations DeFi, l'assurance et les marchés de prédiction.
120
Brand Lift Study
Étude qui mesure l'effet d'une campagne sur des métriques de marque — ad recall, brand awareness, message association, purchase intent — en comparant un groupe contrôle à un groupe exposé. Meta, YouTube et TikTok le proposent en natif ; CPM typique 5-15 $.
121
Incrementality Test
Test qui compare les conversions induites par les pubs à une baseline « si la campagne n'avait pas tourné » pour mesurer la part vraiment incrémentale. Méthodes : PSA placebo ads, ghost bidding, geo holdouts ; soigne l'illusion « toute conversion est à moi » de l'attribution classique. Gold standard du ROI paid media moderne.
122
Geo Holdout Test
Quasi-expérience qui mesure l'impact incrémental en coupant les pubs dans une géographie précise (ex. New York) et en les gardant ailleurs. Sans cookies, sans identifiant, ATT-proof ; la méthode matched-markets / synthetic control est le standard de la marketing science moderne.
123
MTA (Multi-Touch Attribution)
Modèle qui répartit un crédit pondéré entre tous les touchpoints (pub, email, organic, direct) ayant contribué à une conversion. Méthodes : linear, time-decay, position-based, data-driven. La fin des cookies et l'ATT ont fragilisé la précision du MTA ; le combiner à MMM + incrementality est le stack moderne le plus sain.
124
Data-Driven Attribution (DDA)
Modèle d'attribution qui apprend par machine learning la contribution marginale de chaque touchpoint plutôt que de tout donner au last click. Default Google Ads + GA4 ; basé Shapley ; compare équitablement les canaux à la même étape du funnel. A remplacé les modèles rule-based classiques.
125
View-Through Conversion (VTC)
Conversion d'un utilisateur qui a vu la pub — sans cliquer — et a converti plus tard. En display et vidéo, 30-60 % des conversions peuvent être VTC ; mal interprété, on sur- ou sous-estime le canal. La différence avec l'attribution click-only est critique.
126
Attribution Window
Fenêtre de temps pendant laquelle une conversion est créditée à une pub après un clic ou une vue. Ancienne norme : 7-day click + 1-day view ; avec iOS 14.5, le défaut ATT est devenu 7-day click + 1-day view + same-day view. Plus la fenêtre rétrécit, moins les canaux semblent toucher de conversions.
127
Retention Curve (S-Curve)
Pattern attendu d'une rétention de cohorte qui plateau à un moment. Dans une app saine la courbe s'aplatit après ~90 jours ; dans une app virale ou habit-forming elle reste horizontale ; si elle continue de descendre, le PMF est faible. La « smiling curve » d'Andrew Chen sert de référence moderne.
128
Activation Rate
Part des utilisateurs nouvellement inscrits qui réalisent la première action de valeur. Slack suit « les 40 % qui envoient un premier message », Notion « les 50 % qui créent une première page », Spotify « les 85 % qui jouent une première chanson ». L'activation est l'indicateur le plus direct du PMF + onboarding et corrèle fort avec la LTV.
129
TTV (Time-to-Value)
Temps qu'il faut à un utilisateur pour vivre la première vraie valeur (aha moment). Linear : 30 secondes ; Figma : 5 minutes ; Slack : une semaine. Plus le TTV est court, plus la rétention est élevée ; étoile polaire unique de l'onboarding moderne.
130
Activation Metric (Aha-Moment Metric)
Seuil data-driven du type « si l'utilisateur fait N actions en T temps, il retient ». Facebook : « 10 amis en 14 jours », Slack : « 2K messages », Twitter : « 30 follows ». Tout l'onboarding est optimisé là-dessus ; étoile polaire de l'équipe growth.
131
pLTV (Predictive LTV)
Utiliser le machine learning sur les premiers événements (sign-up, premier achat, session day-1, IAP) pour prédire la LTV à 30/90/365 jours. Solution standard d'attribution iOS post-SKAdNetwork ; AppsFlyer, Adjust et Singular ont intégré pLTV dans leurs stacks d'optimisation.
132
Uplift Modeling
Approche ML qui identifie dans quels segments d'utilisateurs une intervention — coupon, push, email — crée un impact net additionnel réel. Trouve le segment « persuadable » pour ne pas embêter le reste. Algorithmes : T-learner, X-learner, causal forest. ROI campagnes CRM ×2-3.
133
Crashlytics / Sentry Mobile
Plateformes qui capturent crashes mobile, ANR et erreurs JS, et les regroupent avec stack trace, données device et breadcrumbs. Firebase Crashlytics (Google, gratuit), Sentry, Bugsnag, Embrace en options principales. Objectif Crash-Free Users 99,5 %+ ; sous 99 % le rating App Store dévisse.
134
Mobile APM (Application Performance Monitoring)
Plateforme qui mesure la performance de l'app sur des appareils réels : startup time, rendu écran, requêtes réseau, mémoire, batterie, ANR. Firebase Performance, New Relic Mobile, Embrace, Datadog Mobile RUM en options. Révèle les problèmes UX qui ne sont pas des crashes.
135
Headless BI
Moteur analytics sans couche de visualisation propre qui expose tous les calculs de métriques et dimensions via API et GraphQL. Cube, GoodData, AtScale en tête ; l'output est consommé par Tableau, Looker, Notion, Hex, Excel ou une app React custom. Paradigme moderne qui casse la monogamie d'outil BI.
136
Metric Layer
Variante metric-only du semantic layer — abstraction qui garde les définitions de métriques « source unique » en YAML ou SQL. Spectacles de Slack, Minerva d'Airbnb, dbt Semantic Layer en exemples. Si « active user » fait 15 % en marketing et 10 % en finance, le drift commence ici.
137
Data Activation
Processus qui pousse les insights du warehouse vers les systèmes opérationnels — CRM, plateformes pub, helpdesk, messagerie in-app. Le reverse ETL est la tuyauterie technique ; pont entre « data analytics » et « marketing automation ». Census, Hightouch et Polytomic sont les outils leaders.
138
Composable CDP
Approche qui place le warehouse (Snowflake, BigQuery) au centre plutôt que d'acheter un CDP single-vendor (Segment, mParticle), et n'y branche que les couches nécessaires — audience, activation temps réel, identity resolution. Hightouch + Census + RudderStack + Snowplow forment le stack typique.
139
Operational Analytics
Principe : les insights analytiques ne doivent pas rester dans un dashboard mais déclencher des actions dans les systèmes opérationnels. « Cet utilisateur est inactif depuis 7 jours » s'affiche dans un flow win-back Klaviyo et non dans un graphique. Face business du reverse ETL ; version moderne de l'« actionable analytics ».
140
Looker LookML
Le DSL de data modeling type YAML de Looker. Les tables deviennent des « views », les relations des « explores », les métriques des « measures » ; approche BI code-centric qui génère du SQL. Tous les analystes parlent la même langue, version control et workflows Git tournent — la lingua franca des équipes data modernes.
141
Mode Analytics
Plateforme BI qui fusionne SQL, notebooks Python et dashboards dans un seul produit (rachetée par ThoughtSpot en 2023). Sweet spot du data analyst : SQL pour les requêtes, Python pour le ML, puis dashboard partageable. La face power-user face au tout-GUI de Tableau.
142
Hex (Notebook BI)
Plateforme analytics fondée en 2020 qui regroupe SQL, Python et apps interactives no-code au même endroit. UI notebook + Magic AI + builder d'apps partageables ; espace commun pour data scientists, analystes et stakeholders business. Étoile montante du BI hybride moderne.
143
Sigma Computing
Plateforme BI moderne qui pose une interface tableur sur Snowflake ou BigQuery. Les utilisateurs font des pivots, formules et what-if à la Excel sans écrire de SQL — mais le moteur reste warehouse-native. Concurrent solide de Looker côté finance et ops.
144
Streamlit
Framework open-source basé Python qui permet d'envoyer une app web interactive en 100 lignes de script (racheté par Snowflake en 2022). Voie par défaut du data scientist pour internal tools, prototypes et démos ML ; Plotly Dash et Gradio en concurrents proches.
145
Snowflake Streams & Tasks
Le duo Snowflake change-data-capture (Streams) + exécution SQL planifiée (Tasks). Un Stream met les inserts/updates/deletes d'une table en file par offset ; une Task les traite par cadence. Les pipelines ELT gagnent une automatisation native Snowflake sans Airflow.
146
dbt Tests
Assertions de qualité de données écrites contre les modèles dbt : not_null, unique, accepted_values, relationships et SQL custom. Exécutés en CI ; ils valident la data avant chaque build de modèle. La test-suite s'enrichit via dbt-utils et Great Expectations.
147
dbt Snapshots
Implémentation dbt-native du Slowly Changing Dimension Type 2. Pour une table source mutable (ex. orders.status change), chaque snapshot run conserve l'historique via les colonnes dbt_valid_from/to. Base de l'audit history et des requêtes « à quoi ça ressemblait à telle date ».
148
Materialization Strategy (Table / View / Incremental / Ephemeral)
Comment un modèle dbt est stocké dans le warehouse. View : pas chère mais recalcule à chaque requête — petite data. Table : rebuild complet — petite/moyenne. Incremental : ajoute seulement les nouvelles lignes — grosse data. Ephemeral : inline en CTE, pas de sortie persistante.
149
SCD (Slowly Changing Dimension)
Pattern pour stocker l'historique de dimensions qui évoluent lentement — client, produit, employé. Type 1 : seule la dernière valeur ; Type 2 : nouvelle ligne à chaque changement avec valid_from/to (historique conservé) ; Type 3 : une colonne previous-value. Avec un DWH moderne + dbt Snapshots, SCD2 est le défaut.
150
Idempotent Pipeline
Pipeline ETL/ELT qui, exécutée sur le même input, produit le même output et ne crée pas d'effets secondaires en rejeu. Garantie que les backfills, retries et late-arriving data ne corrompent pas le dataset. Obtenue via MERGE, dédoublonnage par primary key et transactions.
151
Backfill Strategy
Plan pour rejouer une pipeline sur des données historiques. On paramètre la plage de dates, on recalcule les partitions par batches ; pipeline idempotente + writes atomiques + concurrency control sont obligatoires. Un mauvais backfill = perte de données en prod — répéter d'abord en staging.
152
dbt Layers (Staging / Intermediate / Marts)
Le pattern de modeling recommandé en 3 couches pour un projet dbt. Staging : table 1:1 nettoyée par source (rename, cast, dedup). Intermediate : briques de la logique métier. Marts : couche finale dim/fact business-ready. Apporte cohérence, reuse et un DAG propre.
153
Source Freshness
Fonction dbt qui surveille depuis combien de temps chaque table source a été mise à jour. La commande « dbt source freshness » déclenche des seuils warning et error (p. ex. 12 h warn, 24 h error) et attrape les data stale même quand la pipeline n'a pas cassé. Le chien de garde opérationnel.
154
OBT (One Big Table)
Alternative de modeling au star schema — dénormaliser toutes les dimensions dans la fact table pour produire une seule table large de 50-200+ colonnes. Sur des warehouses columnar comme Snowflake/BigQuery les joins coûtent ; OBT est plus rapide pour les analystes et souvent optimal en perf.
155
Cube.js
Moteur headless-BI open-source. Génère du SQL, met en cache, expose des APIs REST/GraphQL et s'assoit sur Snowflake, BigQuery ou Postgres. Permet à un développeur front-end de livrer ses propres dashboards ; l'alternative developer-friendly à Tableau / Looker.
156
Snowpark
API DataFrame de Snowflake pour Python, Scala et Java. Permet ML training, transforms complexes, UDF et stored procedures sans sortir les données du warehouse. Modin et pandas-on-Snowflake donnent aux data scientists un confort local familier ; mouvement moderne vers le zéro data movement.
157
Polars
Bibliothèque DataFrame multi-threadée, columnar (Arrow) écrite en Rust. 5-30× plus rapide que pandas avec lazy evaluation et optimisation de requêtes intégrée. Le remplaçant moderne de pandas pour l'analyste ; bindings Python, R, JS, Rust.
158
DuckDB
Base OLAP columnar in-process — pendant analytics de SQLite, avec MotherDuck en extension cloud. Un fichier, un process ; requête des DataFrames pandas ou des Parquet directement en SQL. Avale 1 milliard de lignes sur un laptop en 30 secondes ; compagnon quotidien de l'analyste moderne.
159
LLM Eval Harness
Framework de test qui mesure automatiquement la performance d'un LLM sur de nombreuses tâches. Exemples : HELM, lm-eval-harness, BigBench, HELM Lite — il lance les benchmarks standards comme MMLU, HumanEval, GSM8K, ARC. Infrastructure obligatoire pour un lancement de modèle ou un test de régression.
160
Prompt Eval
Test set qui mesure systématiquement la qualité d'un prompt précis. 50-500 paires input × output attendu scorées automatiquement (LLM-as-judge, BLEU, ROUGE, exact match). Indispensable pour attraper les régressions quand un prompt prod bouge ; PromptLayer, Langfuse, Braintrust en outils courants.
161
Golden Dataset
Test set vérifié manuellement et utilisé comme vérité terrain. Les inputs et outputs attendus de l'eval harness y vivent ; après chaque update LLM, le modèle est scoré dessus. Taille typique : 200-2 000 exemples validés par un expert domaine.
162
Faithfulness (RAG)
Mesure de la fidélité d'une réponse RAG au contexte récupéré. Si le LLM hallucine hors du contexte, la faithfulness chute ; un LLM-as-judge vérifie phrase par phrase « y a-t-il un appui dans le contexte ? ». Métrique-clé des frameworks RAGAS et TruLens.
163
Answer Relevance (RAG)
Score qui mesure à quel point la réponse du LLM est pertinente pour la requête utilisateur. Repère les réponses correctes mais hors-sujet — « il fait beau aujourd'hui, mais Paris est la capitale de Paris ». Mesuré par cosine similarity (answer embedding ↔ query embedding) ou LLM-as-judge.
164
Context Precision / Recall (RAG)
Les deux métriques de qualité de retrieval en RAG. Precision : combien des chunks récupérés étaient vraiment pertinents ; Recall : combien des chunks vraiment pertinents ont été récupérés. Faible precision = bruit, faible recall = perte d'info. Mesurées automatiquement par RAGAS, ARES, etc.
165
Model Routing
Couche intelligente qui envoie une question à différents LLMs selon difficulté, latence ou budget. Les questions simples partent vers Haiku/3.5-mini, les complexes vers Opus/4.5. OpenRouter, Portkey, Martian vendent du routing-as-a-service ; coût moyen ÷ 5-20.
166
Cascading Models
Pipeline où un petit modèle bon marché tente d'abord ; si la confiance est sous le seuil ou que la validation échoue, on escalade à un modèle plus gros et plus cher. Variante fail-over du model routing ; dans une vraie appli LLM, 80 % du trafic se règle à 20 % du coût sans perte de qualité.
167
RAG Reranker
Deuxième étape qui réordonne les top-50 chunks issus du vector retrieval via un LLM-as-judge ou un cross-encoder. Cohere Rerank, BGE-Reranker, Jina Reranker en outils courants ; precision +20-40 %, métrique retrieval-faithfulness améliorée.
168
Chunk Strategy
Comment on découpe un document pour le RAG. Options : fixed-size (ex. 512 tokens), recursive character (paragraphe/phrase), semantic chunking (segmentation par embeddings) et markdown-aware. Mauvais chunking = retrieval precision faible ; taille du chunk et overlap pilotent directement la qualité RAG.
169
Embedding Drift
Quand les embeddings des requêtes utilisateurs réelles en production s'éloignent dans le temps de la distribution d'embeddings du corpus RAG. Le slang, les produits et les termes nouveaux creusent le drift, le retrieval recall chute. Solution : régénération trimestrielle des embeddings + réindexation new-data-aware.
170
HNSW Index (Hierarchical Navigable Small World)
L'algorithme d'index ANN (Approximate Nearest Neighbor) utilisé par la plupart des vector DBs. Graphe multi-couches qui livre une latence à la milliseconde sur des milliards d'embeddings. Défaut dans Pinecone, Weaviate, Qdrant, Milvus et pgvector.
171
ANN (Approximate Nearest Neighbor)
Classe d'algorithmes qui trouvent les voisins « assez bons » plutôt que l'exact, en échangeant précision contre vitesse et mémoire. Exemples : HNSW, IVF, PQ, ScaNN ; à 95 % de recall, la latence baisse jusqu'à ×1 000. Moteur du vector search.
172
Model Card
Carte standard (introduite par Google en 2019) documentant le but, les données d'entraînement, la performance, les limites, les enjeux éthiques et les scénarios fair-use d'un modèle IA. Aujourd'hui obligatoire à chaque lancement de foundation model ; fondation du développement IA transparent.
173
AI Observability
Plateforme qui supervise les apps LLM en production sur traces, coût, latence et métriques qualité. Outils : Langfuse, LangSmith, Helicone, Arize Phoenix, WhyLabs ; chaque appel LLM (prompt, réponse, tokens, coût, score d'éval) est loggé. Successeur LLM-natif de l'APM classique.
174
Matchmaking (ELO / MMR)
Algorithme qui apparie les joueurs selon le skill dans les jeux PvP. Variantes : ELO (héritage des échecs), Glicko, TrueSkill, MMR (Match-Making Rating). Compromis entre smurf-protection pour les nouveaux et skill-relax pour les longues queues ; cœur de League of Legends, Valorant, Dota 2.
175
ARPDAU (Average Revenue Per Daily Active User)
Revenu moyen par utilisateur actif quotidien. Mobile casual 0,05-0,20 $, mid-core 0,20-0,80 $, hardcore RPG 1 $+. Étoile polaire des décisions live ops ; couplé au pLTV, il pose le budget paid acquisition.
176
Whales / Dolphins / Minnows
Segments de dépense en F2P. Whales : top 1 % à 1 000 $+ ; Dolphins : 5-10 % à 50-1 000 $ ; Minnows : 15-30 % à 1-50 $ ; Free-riders : 60-80 % qui ne paient jamais. Distribution de Pareto : les whales font 70 %+ du revenu — les perdre est fatal.
177
Scope 1 / Scope 2 / Scope 3 Emissions
Classification en trois seaux des émissions carbone par le GHG Protocol. Scope 1 : émissions directes (chaudières d'usine, véhicules de l'entreprise). Scope 2 : électricité, chaleur ou froid achetés. Scope 3 : supply chain + cycle de vie produit — la plus grosse part, 75-85 %. Squelette du reporting ESG.
178
Carbon Footprint
Total des émissions de gaz à effet de serre causées par une personne, un produit, une entreprise ou un événement sur son cycle de vie (en CO₂-équivalent). Fabriquer un iPhone : ~70 kg CO₂e ; un vol transatlantique : ~1,6 t. En reporting ESG = Scope 1 + 2 + 3.
179
Carbon Offset
Investissement dans des projets externes pour compenser les émissions — reforestation, renouvelables, capture de méthane, direct air capture. Le voluntary carbon market valait ~2 Md $ en 2024 mais reçoit de fortes critiques de greenwashing ; Verra, Gold Standard et ICVCM en labels qualité. Outil controversé vers le Net Zero.
180
CDP (Carbon Disclosure Project)
Plateforme mondiale où les entreprises divulguent leurs émissions climat, eau et forêt selon un format standard. 24 000 entreprises et 1 100 villes ont reporté en 2024 ; le scoring A-D met la pression sur les investisseurs institutionnels et les clients. Apple, Microsoft, Unilever en tête ; les obligations supply-chain se propagent vite.
181
ESG Reporting (Environmental, Social, Governance)
Reporting standardisé de la performance environnement, social et gouvernance d'une entreprise. CSRD (UE), SEC Climate Rule (US) et recommandations TCFD forment le parapluie global ; SASB, GRI et CDP les frameworks opérationnels. Depuis 2024, 50 000+ entreprises UE sont obligées sous CSRD.
182
CSRD (Corporate Sustainability Reporting Directive)
Directive UE en vigueur à partir de 2024 qui impose le reporting durabilité à 50 000+ grandes entreprises — banques, assurances, sociétés avec 250+ salariés et 40 M €+ de CA. Bâtie sur les standards ESRS, double materiality (impact entreprise sur environnement + environnement sur entreprise) et assurance tierce.
183
Net Zero
Objectif au niveau entreprise ou pays de réduire les émissions au minimum et compenser le résiduel par des offsets ou removals. Validé par Science Based Targets (SBTi) ; cible globale 2050. Diffère de carbon-neutral : Net Zero est plus strict — il retire le résiduel au lieu de simplement le compenser.
184
Carbon Neutral vs Net Zero
Carbon-neutral : les émissions sont neutralisées par des offsets, pas de réduction réelle exigée ; Net Zero : on réduit d'abord agressivement, puis on neutralise le reste par des removals (pas que des offsets). Cibles : Microsoft 2030 Carbon Negative, Apple 2030 Net Zero, Google 2030 24/7 carbon-free energy.
185
PUE (Power Usage Effectiveness)
Métrique d'efficacité électrique d'un data center — total facility power divisé par IT equipment power. Idéal 1,0 ; 2,0 = une unité supplémentaire de cooling/lighting par unité IT. Les hyperscalers (Google, AWS, Azure) sont en moyenne à 1,10-1,15 ; les DCs enterprise on-prem à 1,5-2,0. KPI sustainability clé.
186
Green Software Foundation
Projet Linux Foundation fondé par Microsoft, Accenture, GitHub et ThoughtWorks qui standardise le développement logiciel durable. Maintient le standard SCI (Software Carbon Intensity), la certification Green Software Practitioner et le catalogue Green Software Patterns. Le guide sustainability des équipes dev modernes.
187
SCI (Software Carbon Intensity)
Standard ISO/IEC 21031 qui mesure les émissions CO₂-équivalent par unité fonctionnelle de logiciel. Formule : énergie × carbon intensity de la région + embodied emissions. La réponse standard à « combien de carbone coûte cet appel API ? » — fondation des métriques green-software modernes.
188
Renewable Energy Credit (REC)
Certificat échangeable qui représente 1 MWh d'énergie renouvelable. Plutôt qu'installer des panneaux, une entreprise achète des RECs et reporte son électricité comme renouvelable ; Green-e aux États-Unis, GO (Garanties d'Origine) en Europe. Principal véhicule derrière les engagements RE100.
189
PPA (Power Purchase Agreement)
Contrat direct à long terme (10-25 ans) et prix fixe pour acheter de l'électricité renouvelable directement au producteur. Colonne vertébrale des stratégies carbon-free des hyperscalers (Google, Amazon, Microsoft) ; volume mondial corporate PPA en 2024 estimé à plus de 50 GW.
190
LCA (Life Cycle Assessment)
Méthodologie ISO 14040 qui quantifie l'impact environnemental complet d'un produit, des matières premières → production → usage → fin de vie. Scope cradle-to-grave ou cradle-to-cradle. Le « 70 kg de footprint carbone iPhone » d'Apple est une sortie LCA.
191
Circular Economy
Modèle économique qui remplace la chaîne linéaire « produire-utiliser-jeter » en concevant des produits réutilisables, réparables et recyclables dès le départ. Pionnier : la Ellen MacArthur Foundation ; IKEA Buyback, Patagonia Worn Wear et Apple Self-Service Repair en exemples concrets.
192
Greenwashing
Lorsqu'une entreprise paraît plus verte via le marketing que ne le justifie sa vraie performance émissions. La CMA (UK), la FTC (US) et la CSRD UE encadrent désormais le greenwashing juridiquement ; Shell, BP, Volkswagen ont payé des amendes en millions au fil des ans. Ligne rouge éthique de la communication sustainability.
193
Carbon Border Adjustment Mechanism (CBAM)
La « taxe carbone à l'import » de l'UE, pleinement en vigueur en 2026. Les importateurs d'acier, ciment, aluminium, engrais, hydrogène, électricité vers l'UE paient ce que ces biens auraient payé au titre de l'ETS UE s'ils avaient été produits dans l'UE. Première grande tarification qui restructure les supply chains par intensité d'émissions.
194
EPR (Extended Producer Responsibility)
Régulation qui rend le producteur responsable des coûts de fin de vie et de recyclage de ses produits. Exemples : directive emballages UE, LOM en France, VerpackG en Allemagne, Sıfır Atık en Turquie. Un producteur de bouteilles, vêtements ou électronique paie une taxe environnementale par unité vendue.
195
Sustainable Procurement
Intégrer des critères environnementaux et sociaux dans les décisions d'achat de l'entreprise. Code of Conduct fournisseurs, rating sustainability EcoVadis, exigences de matière recyclée, certification fair-trade. La majorité des émissions Scope 3 naissent là ; cœur opérationnel du reporting CSRD moderne.
196
TCFD (Task Force on Climate-related Financial Disclosures)
Framework publié en 2017 par le Financial Stability Board du G20, qui intègre risques et opportunités climatiques au reporting financier. Quatre piliers : Governance, Strategy, Risk Management, Metrics & Targets. PRA UK, Nouvelle-Zélande et Japon l'ont rendu obligatoire. Volet climat du reporting ESG.
197
SBTi (Science Based Targets initiative)
Organisme indépendant qui valide si les objectifs de réduction d'émissions d'une entreprise s'alignent à la trajectoire science-based 1,5 °C / well-below-2 °C de l'Accord de Paris. 5 000+ entreprises validées — Microsoft, IKEA, Unilever, Nike, Maersk entre autres. Tampon obligatoire de toute revendication Net-Zero crédible.
198
EV Charging Network (Tesla Supercharger / Ionity / Electrify America)
Infrastructure de charge rapide pour véhicules électriques. Le réseau Supercharger de Tesla compte 50 000+ stations dans le monde et utilise le standard NACS ; Ionity (consortium BMW + VW + Mercedes) couvre l'Europe ; Electrify America couvre les US. Depuis 2024, Tesla a ouvert NACS aux autres marques EV, accélérant la consolidation du standard.
199
North Star Framework
Framework popularisé par Sean Ellis et Amplitude qui définit l'unique métrique « valeur pour le client » d'une entreprise. Spotify : « time spent listening » ; Airbnb : « nights booked » ; Slack : « messages sent in active workspaces ». Boussole de toute décision growth et produit.
200
Driver Tree
Analyse qui éclate une métrique cible (ex. revenue) en ses drivers sous-jacents. Cousin proche du KPI tree, plus causal — réponse structurée à « pour faire monter l'ARR, on pousse les new logos ou l'expansion ? ». Outil classique de problem-solving chez McKinsey et Bain.
201
Executive Dashboard
Dashboard d'une page pour la C-suite et le board, avec 7-12 métriques top. KPIs business-decision-grade : MRR, NRR, CAC, magic number, runway, rule of 40 ; revue hebdo. Formats classiques sur Tableau Executive, Looker C-suite, Mode Reports.
202
Operational Dashboard
Dashboard pour des décisions opérationnelles heure-par-heure ou jour-par-jour — tendance CPM marketing, file de tickets support, backlog ops. Refresh en temps réel ou quasi ; alerting et drill-down pivot obligatoires. Courant dans Looker Studio, Power BI, Grafana.
203
Drill-Down
Comportement d'analyse en click-through depuis une métrique agrégée vers le détail — « revenue total » → « par région » → « par produit » → « par SKU » → « par transaction ». Feature star self-service des OLAP cubes et BI modernes (Power BI, Tableau, Looker).
204
Slice & Dice
Découper et analyser des données multidimensionnelles selon différentes dimensions. « Slice » fige une dimension et analyse le reste ; « Dice » filtre deux dimensions ou plus pour bâtir un sous-ensemble. Comportement basique de la pivot table, hérité du vocabulaire OLAP cube.
205
Pivot Table
L'invention d'Excel en 1993 — drag-and-drop de données multidimensionnelles en lignes, colonnes, valeurs et filtres. Ancêtre du BI moderne ; Tableau, Power BI, Looker, Hex portent le mental-model pivot table dans leur UX. La lingua franca de l'analyse de données.
206
Funnel Visualization
Afficher un flux de conversion en funnel chart qui se rétrécit étape par étape — Awareness → Consideration → Purchase → Retention — pour repérer les drop-offs à chaque pas. Mixpanel, Amplitude, Heap et GA4 livrent des funnel reports natifs ; visual cœur pour CRO, produit et marketing.
207
Cohort Heatmap
Matrice qui visualise la rétention par cohorte (semaine 0 → semaine N) via intensité de couleur. Axe Y : semaine de signup ; axe X : semaine post-signup ; couleur : taux de rétention. Donne d'un coup d'œil PMF, qualité d'onboarding et impact des changements produit récents.
208
Sankey Diagram
Visualisation qui représente des flux — user journeys, flux énergétique, chemins de conversion — en rubans d'épaisseur proportionnelle. Idéal pour le behavior flow Google Analytics, l'analyse de churn et les journeys d'attribution. Construit avec d3.js, Plotly ou le custom visual Sankey de Power BI.
209
Bullet Chart
Graphique minimaliste conçu par Stephen Few qui affiche cible KPI, performance actuelle et tier bands sur une seule ligne horizontale. Bien plus lisible qu'un gauge ou un speedometer. Classique sur les dashboards executive ; Tableau et Power BI offrent un custom visual.
210
Data Storytelling
Approche « raconte une histoire puis appuie-la sur la donnée » au lieu d'envoyer chiffres et graphiques au public. Le livre « Storytelling with Data » de Cole Nussbaumer Knaflic est le manifeste ; comble le « so what ? » avec les décideurs. Mise en œuvre : Tableau Story, Power BI bookmarks, Notion narrative.
211
Self-Service Analytics
Modèle où les utilisateurs métier construisent leurs propres requêtes et dashboards sans dépendre d'un analyst. Looker LookML, Tableau Ask Data, Power BI Q&A, ThoughtSpot search-driven en leaders ; semantic layer + data governance + formation indispensables. Objectif « démocratisation » du BI moderne.
212
Power BI
Plateforme BI de Microsoft — intégrée profondément à Excel, BI entreprise la plus utilisée. Power Query (ETL), DAX (langage de formule), Power BI Service (cloud + collaboration). Microsoft Fabric renforce la data engineering et l'intégration AI Copilot.
213
Tableau
Le « standard d'or visuel » du BI — l'outil drag-and-drop le plus puissant pour des charts saisissants. Sorti de Stanford en 2003, racheté par Salesforce en 2019 pour 15,7 Md $. Le trio Tableau Desktop + Server + Cloud reste plus flexible et plus artistique que Power BI.
214
ThoughtSpot
Pionnier du BI search-driven — l'utilisateur tape « show me revenue by region last quarter » en langage naturel et la plateforme génère SQL + chart. SpotIQ propose des auto-insights ML, ce qui le place en tête du BI AI-augmented. A racheté Mode Analytics pour 200 M $ en 2023.
215
Microsoft Fabric
Plateforme analytics lancée par Microsoft en 2023 qui combine Power BI, Synapse, Data Factory, Real-Time Analytics et Copilot dans un seul SaaS. OneLake vise un « lakehouse pour les masses » et est rival direct de Snowflake et Databricks.
216
Real-Time Dashboard
Dashboard qui se rafraîchit en secondes et montre « ce qui se passe maintenant ». Combo WebSocket + SQL streaming + push notifications. Plateformes de trading, gaming live ops, files de support temps réel, monitoring IoT. Stacks courants : Grafana, Tinybird, Materialize, ClickHouse + Apache Pinot.
217
Embedded Analytics
Afficher des dashboards BI directement dans une app SaaS. Sigma, Mode, Looker Embedded et Cube + frontend React custom dominent. Infra de toute app qui doit montrer la donnée client (Shopify analytics, Stripe Sigma, HubSpot reports) ; feature PLG moderne.
218
Slowly Refreshed Dashboard (Daily / Weekly)
Dashboard qui n'a pas besoin de temps réel et se rafraîchit après un batch ETL quotidien ou hebdo — revue marketing weekly, clôture finance mois, rapports cohortes de rétention. Bon choix pour le coût compute et la simplicité analytique ; classique face à l'anti-pattern « premature real-time ».
219
Anomaly Alerting
Alerte qui se déclenche quand une métrique dévie statistiquement de son pattern saisonnier et de sa tendance. Prophet, Datadog Watchdog, Anodot, MonteCarlo, Sigma Anomaly Detection remplacent les seuils manuels par des alertes dynamiques ML-driven. Capacité centrale de la data observability moderne.
220
Forecasting (Prophet / SARIMA / LSTM)
Prédire des valeurs futures à partir de l'historique. Outils : Prophet (Meta, business-friendly avec seasonality), SARIMA (stats classiques), modèles LSTM et Transformer (deep learning), librairie Darts. Domaine ML central pour le sales forecasting, le demand planning et le capacity planning.
221
Data Catalog (Atlan / Alation / Collibra)
Plateforme qui rend tous les data assets — tables, dashboards, modèles ML, métriques — découvrables et documentés pour l'entreprise. Lineage, tags, business glossary, data quality, ownership dans une seule UI. La « Wikipedia » de l'équipe data moderne.
222
AI-Powered BI (Copilot / Sigma AI / Tableau Pulse)
Set de features BI nouvelle génération : requêtes en langage naturel, insights auto, narratives explicatives de chart. Power BI Copilot, Tableau Pulse + Tableau GPT, Sigma AI et ThoughtSpot Sage répondent à « pourquoi le revenue a baissé la semaine passée ? » par root-cause automatique et redessinent le rôle d'analyst.
223
Edge AI
Faire tourner des modèles IA sur l'appareil — téléphone, caméra, drone, capteur IoT — plutôt qu'en cloud. Apporte basse latence, préservation de la privacy et fonctionnement offline ; requiert modèle quantisé + NPU + runtime. Anime voitures autonomes, AR/VR et smart cameras.
224
TinyML
Modèles ML assez petits pour tenir sur des MCUs avec des kilooctets de RAM. Outils : TensorFlow Lite Micro, Edge Impulse, Arduino Nano 33 BLE Sense ; couvre keyword spotting, motion detection et anomaly detection. Apporte de l'IA sur des appareils IoT sur pile qui tiennent des années.
225
Digital Twin
Réplique virtuelle d'un objet physique — moteur d'avion, usine, ville, corps humain — synchronisée en temps réel via les données capteur. Combine simulation, monitoring et predictive maintenance. Siemens, NVIDIA Omniverse, Microsoft Azure Digital Twins et Bentley iTwin dominent les plateformes.
226
People Analytics
Discipline qui applique ML et statistiques aux données employé. Couvre prediction d'attrition, qualité de hiring, efficacité manager, analyse de gap DEI et tendances de sentiment. Visier, ChartHop, Lattice, Culture Amp et Workday Adaptive Planning en tête ; le pied data-driven des RH.
227
eNPS (Employee Net Promoter Score)
Score type NPS pour « recommanderais-tu cette boîte comme employeur ? ». De -100 à +100 ; +30 c'est bien, +50 excellent. Delivered via survey annuelle + pulse trimestriel sur Culture Amp, Officevibe, 15Five, Lattice. Thermomètre une-question de l'engagement.
228
Pulse Survey
Le successeur moderne du sondage engagement annuel — un mini-sondage de 5-10 questions envoyé chaque semaine ou toutes les deux semaines. Pulse engagement temps réel qui arrive direct sur le dashboard manager. Outils : Officevibe, 15Five, Lattice, Culture Amp ; réponse agile + actionable au monstre annuel 80 questions.
229
EHR (Electronic Health Record)
Dossier numérique et partageable de la santé du patient — historique médical, labo, imagerie, prescriptions. Aux US, Epic et Cerner totalisent 85 %+ de part de marché ; en Europe, DocPlanner et Doctolib ; en Turquie, e-Nabız et MEDULA. L'interopérabilité et la privacy (HIPAA, GDPR, KVKK) sont au cœur du secteur.
230
ClimateTech
Solutions tech contre la crise climatique — mitigation et adaptation. Capture carbone (Climeworks DAC), hydrogène vert, fusion (Commonwealth Fusion, Helion), batteries grid-scale (Form Energy), climate-risk modelling (Jupiter). Investissement global ClimateTech > 40 Md $ en 2024 ; Sequoia, Lowercarbon, Breakthrough Energy en fonds leaders.
231
Carbon Capture (DAC / CCS)
Technologie qui capture le CO₂ depuis l'atmosphère ou directement depuis le flue gas industriel. Direct Air Capture (Climeworks Orca, Carbon Engineering) et Carbon Capture & Storage (CCS) pour les fumées d'usine. Coût 300-1 000 $/tonne ; l'advance market commitment de 1 Md $ de Frontier vise à le ramener à 100 $.

— DIAGNOSTIC RAPIDE

Êtes-vous prêt pour une opération analytique ?

Un guide interactif qui vous indique le niveau de programme adapté en quatre questions. Un résultat en 30 secondes avec des réponses oui / non.

01 / 04

Avez-vous actuellement plus de 10 dashboards ou rapports Excel actifs ?

L'abondance de dashboards est un symptôme classique d'un manque de décision.

— LET'S BEGIN

Vos dashboards déclenchent-ils des décisions, ou ne sont-ils qu'un décor ?

Diagnostic analytique de 60 minutes : votre inventaire KPI actuel, le graphe de dépendance des dashboards, la santé des sources de données et une recommandation de roadmap 90 jours — sur un seul panneau.