Data science, data mining, BI : du bruit à la décision (2026)

Les définitions (celles qui évitent les quiproquos en réunion)

On mélange beaucoup de mots, puis on s’étonne de ne pas se comprendre.

Glossaire :

• Data science : /glossaire/d#data-science
• Data mining : /glossaire/d#data-mining
• Big data : /glossaire/b#big-data
• Business intelligence : /glossaire/b#business-intelligence
• Analyse prédictive : /glossaire/a#analyse-predictive
• Dataset : /glossaire/d#dataset
• Pipeline IA : /glossaire/p#pipeline-ia

La version “Pierre, fais-moi simple” :

• BI : “je veux voir ce qui se passe” (reporting, dashboards, KPI).
• Data science : “je veux comprendre et décider” (hypothèses, analyses, causalité parfois, recommandations).
• Data mining / ML : “je veux prédire / classer / segmenter” à partir d’exemples.
• Big data : “j’ai un problème d’échelle” (volume, vitesse, variété) qui change l’architecture.

La carte du territoire (BI, data engineering, data science, ML)

Si vous voulez une photo claire :

• Data engineering : collecte, stockage, transformations, qualité, lineage.
• BI : métriques, dashboards, self-serve, gouvernance des KPI.
• Data science : analyses, exploration, expérimentation, recommandations.
• ML/data mining : modèles qui prédisent/classent/segmentent.
• Ops : monitoring, coûts, incidents, conformité.

Et oui : ce sont des disciplines différentes. On peut les faire dans une petite équipe, mais on ne peut pas faire croire que “un notebook” remplace tout.

CRISP-DM : la méthode qui évite le “on va juste entraîner un modèle”

CRISP‑DM est un cadre historique mais incroyablement utile, parce qu’il force l’ordre des questions : business d’abord, données ensuite, modèles ensuite, déploiement ensuite.¹

Ce n’est pas sexy. Justement : ça marche.

Les 6 étapes (traduction 2026)

1. Business understanding
   Que veut-on améliorer ? ROI, réduction des escalades, délais, fraude, conversion…

2. Data understanding
   Quelles données existent ? Sont-elles fiables ? Sont-elles accessibles ?

3. Data preparation
   Nettoyage, jointures, anonymisation si besoin, features/embeddings, jeux train/test.

4. Modeling
   Baseline, itérations, tuning si nécessaire.

5. Evaluation
   Métriques + cas critiques + validation métier (sinon, vous jouez).

6. Deployment
   Monitoring, drift, retraining, rollback, gouvernance.

Big data : quand ça devient un problème d’architecture (pas un mot de brochure)

Le big data n’est pas “quand c’est gros”. C’est quand l’échelle change vos choix.

Trois situations typiques :

1. Volume : trop de données pour traiter sur une seule machine.
2. Vitesse : besoin de streaming / quasi temps réel.
3. Variété : données hétérogènes (logs, texte, images, events).

Et là, vous sortez l’artillerie : compute distribué, stockage optimisé, orchestration.

Apache Spark est une référence de traitement distribué (batch/stream) et documente son écosystème et ses modes d’exécution.²

Knowledge graph : quand votre problème est “des relations”, pas “des lignes”

Il y a un cas où BI + tables atteignent vite leurs limites : quand vos données sont surtout des relations.

Exemples :

• qui travaille avec qui (organigramme),
• quel produit dépend de quel autre (catalogue),
• quelles exceptions contredisent quelle règle (conformité),
• quel document fait référence à quel article (juridique).

Dans ces cas, un knowledge graph (graphe de connaissance) peut devenir une représentation naturelle : des nœuds, des relations, et des chemins.

Glossaire : /glossaire/k#knowledge-graph

Et oui : en IA conversationnelle, un graphe peut compléter un RAG. La recherche vectorielle récupère “des passages proches”, le graphe récupère “des relations exactes” (et parfois plus explicables).

Business intelligence : le royaume des KPI (et de la politique interne)

La BI, c’est ce moment où une métrique devient une décision.

Et c’est là que ça se complique, parce que :

• tout le monde veut “son” KPI,
• personne n’aime quand la métrique baisse,
• et un dashboard peut mentir par omission (ou par mauvaise définition).

La BI sérieuse impose :

• définitions partagées (glossaire de métriques),
• gouvernance (qui possède le KPI),
• et traçabilité (d’où vient ce chiffre).

Côté outils :

• commercial : Power BI, Tableau, Looker…
• open source : Metabase, Apache Superset…

Metabase se positionne comme BI “simple” et documente ses fonctions de questionnement et dashboards.³ Superset (open source) documente aussi son approche dashboards + exploration.⁴

Analyse prédictive : quand vous passez de “voir” à “anticiper”

L’analyse prédictive, c’est le pont entre BI et ML :

• BI : “ce mois-ci, le churn augmente.”
• prédictif : “quels clients vont churn dans 30 jours ?”

Et là, vous retombez sur des briques ML classiques :

• classification (churn oui/non),
• scoring (probabilité),
• segmentation (clusters de profils),
• détection d’anomalies.

L’important n’est pas le modèle. L’important est de brancher la prédiction à une action :

• qui contacte le client ?
• quel message ?
• quel coût ?
• quel impact attendu ?

Sinon, vous fabriquez une prédiction “vraie”… qui ne change rien.

La stack data 2026 (pragmatique) : ingestion → transformation → orchestration → BI/ML

Une stack moderne ressemble souvent à ceci :

1. Ingestion : events, logs, exports, APIs.
2. Stockage : data warehouse/lake (selon besoins).
3. Transformation : modèles de données, tests, documentation.
4. Orchestration : planification, dépendances, retries, observabilité.
5. Consommation : BI, ML, produits (APIs), et, de plus en plus, IA conversationnelle.

Airflow est un outil d’orchestration de workflows (DAG) largement documenté et utilisé pour planifier/exécuter des pipelines de données.⁵ dbt documente une approche “analytics engineering” : transformer dans le warehouse avec tests et documentation.⁶

Qualité des données : le sujet ennuyeux qui fait (ou défait) le ROI

On peut dire ce qu’on veut : la plupart des “problèmes IA” en entreprise sont des problèmes de données.

Pas au sens “il manque des data”. Au sens :

• la définition change selon l’équipe,
• la donnée est partielle,
• les champs sont remplis “à la main” avec des conventions invisibles,
• et personne ne sait quel pipeline a produit ce chiffre.

Le résultat, c’est une usine à débats :

“Le modèle ne marche pas.”

Non. Le monde n’est pas stable, et votre pipeline ne le décrit pas correctement.

Concrètement, la qualité data en 2026, ce n’est pas uniquement “nettoyer”. C’est :

• tests (formats, ranges, nulls),
• contrats (ce qui est garanti, ce qui ne l’est pas),
• lineage (d’où vient la donnée),
• versioning (quand un calcul change),
• monitoring (quand une source dérive).

ROI : quand la BI rencontre l’IA (et quand ça devient mesurable)

La BI vous dit “où ça se passe”. L’IA (au sens large) vous dit “quoi faire”.

Et le ROI apparaît quand :

1. vous avez une décision,
2. vous avez un coût d’erreur,
3. vous avez une action,
4. et vous mesurez avant/après.

Glossaire : ROI IA : /glossaire/r#roi-ia

Exemple (support) :

• Avant : 40% des tickets escaladent, AHT élevé.
• Après : routing + réponses assistées, escalade réduite (sur un périmètre), AHT baisse.

Le point clé : ne promettez pas “X%”. Promettez un mécanisme mesurable.

Conversation analytics : transformer du texte en dataset (sans perdre le sens)

Les conversations (chat/call/mail) sont une matière première très riche… et très dangereuse à analyser naïvement.

Pourquoi ? Parce que :

• le langage est ambigu,
• le contexte compte,
• et le même mot peut vouloir dire autre chose selon le produit, la région, la saison.

Le bon pattern est progressif :

1. structurer un minimum (intents, entités, tags),
2. faire de l’analyse sur échantillons,
3. puis industrialiser (pipelines + monitoring).

1

Définir le “grain”

Message ? Conversation ? Ticket ? Appel ? Votre BI et votre data science doivent parler la même unité d’analyse.

2

Structurer (intents, entités, événements)

Même si vous utilisez des LLM, gardez une couche structurée : intent, canal, escalade, statut, résolution. Sans structure, vous ne pouvez pas mesurer.

3

Créer un jeu de vérité terrain

200–1000 exemples annotés (raisonnablement) battent un million d’exemples “non qualifiés”. Le but : valider des hypothèses, pas faire joli.

4

Construire vos KPI conversationnels

Taux de résolution, escalade, temps, “unknown intents”, satisfaction, coût par conversation. Puis versionnez vos définitions.

5

Mettre une boucle d’amélioration

Chaque semaine : top escalades, nouveaux thèmes, erreurs critiques. Puis actions produit (FAQ, parcours, tooling, training).

Données sensibles : anonymisation, gouvernance et “souveraineté” (sans drama)

Les données conversationnelles sont souvent pleines de PII :

• noms,
• emails,
• numéros de contrat,
• infos santé (parfois),
• et détails personnels que personne n’a demandé… mais que les gens écrivent quand même.

Donc, avant de rêver “insights”, vous devez décider :

• qui a accès,
• combien de temps on garde,
• comment on anonymise,
• et comment on audite.

Sinon, vous allez découvrir la conformité “par surprise”, et c’est rarement agréable.

Et si vous avez des contraintes fortes (secteurs régulés, données sensibles), le débat “cloud vs on-prem” revient vite. Le bon compromis est souvent hybride : traiter ce qui est sensible dans votre périmètre, externaliser le reste quand c’est acceptable, et tracer chaque choix.

Et l’IA conversationnelle dans tout ça ?

Si vous opérez des chatbots/callbots/mailbots, vous produisez un trésor : des conversations.

Vous pouvez faire :

• BI : volumes, AHT, escalades, intents, satisfaction,
• data science : comprendre les drivers (où ça casse, pourquoi),
• ML : classifier les intents, détecter les anomalies, prédire la charge,
• LLM : résumer, extraire, générer des insights.

Mais attention : une conversation est du texte (avec contexte), pas un tableau Excel.

La bonne approche est hybride :

• extraction structurée (champs, intents),
• • analyse qualitative sur échantillons,
• • boucles de feedback (et pas “on a un dashboard donc c’est bon”).

Pour la partie monitoring produit : Monitoring & analytics chatbot.

Checklist : “projet data” qui ne finit pas en PowerPoint

• Objectif business écrit (1 phrase, 1 owner).
• Dataset réaliste (pas uniquement du propre).
• Baseline simple + validation propre.
• Pipeline versionné (sources, transformations, tests).
• Monitoring (dérive, qualité, coûts).
• Une action branchée à la sortie (sinon ça reste académique).

FAQ

Questions frequentes

Data science et BI : je dois choisir ?+

Non. La BI stabilise la mesure (KPI) ; la data science explore et recommande. En général, la BI rend visible le problème, la data science aide à le résoudre.

Big data : à partir de quand ça vaut le coup ?+

Quand l’échelle change vos contraintes : vous ne tenez plus en batch sur une machine, vous avez besoin de streaming, ou vous devez traiter une variété de sources à grande échelle. Si votre problème est “KPI flou” ou “données sales”, commencez par ça.

Le meilleur outil (Airflow/dbt/BI) ?+

Celui que votre équipe peut exploiter, documenter et faire évoluer. Un outil “parfait” sans owner devient une dette. Un outil “bon” avec des conventions et du monitoring devient un avantage.

Je commence par BI ou par ML ?+

Par la mesure. Une BI simple mais fiable (KPI, définitions, sources) vous donne une base. Ensuite, vous choisissez où le ML/predictif crée une action mesurable. Sans mesure, vous ne saurez pas si vous avez gagné.

Data mining : c’est juste un autre mot pour ML ?+

Pas exactement. Le data mining couvre une démarche de découverte de patterns (segmentation, règles, anomalies), parfois avec ML, parfois avec statistiques. En entreprise, le plus important est l’usage : que fait-on du pattern découvert ?

Knowledge graph ou vector DB : je prends quoi ?+

Si votre besoin est “retrouver des passages pertinents malgré des paraphrases”, la vector DB est souvent un bon point de départ (RAG). Si votre besoin est “reconstituer des relations exactes” (qui dépend de quoi, quelles exceptions, quelles références), un knowledge graph est plus naturel. Dans beaucoup de systèmes, les deux se complètent.

Sources et references

1. [1]CRISP-DM 1.0 (process guide, PDF).
2. [2]Apache Spark — Documentation.
3. [3]Metabase — Documentation.
4. [4]Apache Superset — Documentation.
5. [5]Apache Airflow — Documentation.
6. [6]dbt — Documentation.