Dans les projets Data Lake / Lakehouse, le cadrage est la phase la plus sous-estimée… et la plus déterminante. Mais il y a un point qui fait souvent toute la différence, surtout quand on travaille avec des métiers pressés et des organisations complexes :
Ce que le client exprime comme “besoin” est très souvent une solution déguisée.
Et si on valide cette “solution” trop tôt, on construit vite, on livre vite… mais on livre parfois à côté.
Chez BI NEWVISION, je considère que le cadrage commence par une discipline : séparer le besoin réel de la solution proposée, puis choisir la solution en fonction des contraintes, comme on choisirait un moyen de transport.
1) Le problème classique en Data : on demande une solution, pas un besoin
Dans beaucoup de projets Data, la demande initiale ressemble à ceci :
“On veut du temps réel.”
“On veut un Data Lake.”
“On veut Databricks.”
“On veut Cloudera.”
“On veut un Customer 360.”
“On veut centraliser toutes les données.”
“On veut un dashboard unique pour le Sales.”
Dit comme cela, on a l’impression que le besoin est clair.
En réalité, dans la plupart des cas, ce n’est pas le besoin qui est clair, c’est juste la solution que le client a en tête.
Or en Data, c’est précisément là que beaucoup de projets partent dans la mauvaise direction.
Parce que derrière :
“je souhaite du temps réel”
il y a peut-être en réalité :
“je souhaite prendre une décision commerciale avant la fin de la journée”
“je souhaite Databricks”
il y a peut-être en réalité :
“je souhaite industrialiser mes traitements analytiques et sortir de mes scripts dispersés”
“je souhaite Cloudera”
il y a peut-être en réalité :
“je souhaite une plateforme robuste et gouvernée pour la donnée”
“je souhaite un Data Lake”
il y a parfois simplement :
“je souhaite arrêter les silos et fiabiliser mes analyses”
Autrement dit :
le client exprime souvent le “comment”, alors que le cadrage doit d’abord traiter le “pourquoi” et le “pour quoi faire”.
2) Le rôle du cadrage Data : faire émerger le vrai besoin
Le cadrage Data ne consiste pas d’abord à choisir une architecture, un éditeur ou un outil.
Il consiste à répondre proprement à ces questions :
Quel problème métier essaie-t-on réellement de résoudre ?
Quelle décision veut-on améliorer ?
À quel rythme cette décision doit-elle être prise ?
Avec quel niveau de précision ?
Sur quel périmètre ?
Avec quelles contraintes de sécurité, de coût, de gouvernance et d’exploitation ?
C’est seulement après cela que l’on peut commencer à parler de :
batch ou temps réel,
Lakehouse ou entrepôt analytique,
Databricks, Cloudera, AWS, Azure,
data product, dashboard, API, reverse ETL, etc.
En pratique, le cadrage Data sert à éviter trois erreurs majeures :
1. Sur-construire
Mettre en place une solution beaucoup plus complexe que nécessaire.
2. Sous-couvrir le besoin réel
Répondre à la demande formulée, sans résoudre le vrai problème métier.
3. Figer trop tôt un choix technologique
Choisir l’outil avant d’avoir clarifié l’usage, les contraintes et le mode de consommation.
3) Quelques exemples très concrets de “faux besoins” en Data
Exemple 1 — “On veut du temps réel”
C’est probablement l’exemple le plus fréquent.
Quand un client dit :
“on veut du temps réel”,
la première réaction ne devrait pas être :
“Très bien, faisons du streaming.”
La vraie question est :
pourquoi ?
Souvent, après échange, on découvre que le besoin réel est plutôt l’un des suivants :
-
avoir un dashboard mis à jour tous les matins avant 8h,
-
détecter une anomalie dans la journée,
-
mieux suivre l’activité des commerciaux,
-
disposer d’un stock fiable à l’heure près,
-
ou simplement arrêter d’attendre J+2.
Et ces besoins n’ont pas tous la même réponse.
Parfois :
-
du quasi temps réel suffit largement,
-
parfois une alimentation horaire est plus que suffisante,
-
parfois un batch quotidien bien fiabilisé crée déjà énormément de valeur,
-
et parfois oui, le streaming est réellement justifié.
Le rôle du cadrage Data est donc de transformer :
“Je souhaite du temps réel”
en quelque chose comme :
“Je souhaite être capable de prendre une décision opérationnelle dans un délai maximum de 30 minutes après un événement, avec un niveau de fiabilité donné.”
Là, on commence à cadrer sérieusement.
Exemple 2 — “On veut Databricks” ou “On veut Cloudera”
Autre cas classique : la technologie est déjà “pré-choisie” dans le discours du client.
Mais quand un client dit :
“on veut Databricks”,
ou “on veut Cloudera”,
il faut faire très attention :
ce n’est pas forcément un besoin, c’est souvent une projection de solution.
Le vrai besoin peut être :
-
un besoin analytique,
-
un besoin de plateforme mutualisée,
-
un besoin d’industrialisation,
-
un besoin de gouvernance,
-
un besoin d’IA/ML,
-
ou parfois un besoin plus simple de reporting consolidé.
Et selon le besoin réel, la réponse peut être différente.
Cas typiques
Cas A — Le besoin est analytique
Le client veut :
-
consolider plusieurs sources,
-
produire des indicateurs,
-
historiser,
-
servir la BI.
Dans ce cas, la vraie réflexion n’est pas :
“Databricks ou Cloudera ?”
mais :
-
quels volumes ?
-
quelle fréquence ?
-
quelle complexité de transformation ?
-
quelle gouvernance ?
-
quels usages de consommation ?
Cas B — Le besoin est opérationnel
Le client veut :
-
alimenter une application,
-
déclencher des actions,
-
envoyer des données vers un CRM,
-
faire du reverse ETL,
-
supporter des processus métier avec faible latence.
Ici, on n’est plus seulement sur un sujet analytique.
Le cadrage doit clarifier qu’on parle peut-être :
-
d’intégration opérationnelle,
-
d’événementiel,
-
de synchronisation,
-
voire d’architecture orientée services.
Autrement dit, un même mot — “plateforme data” — peut recouvrir des besoins très différents.
Exemple 3 — “On veut un Data Lake”
Là encore, il faut ralentir avant de valider.
Parce qu’un Data Lake peut répondre à plusieurs besoins :
-
centralisation,
-
historisation,
-
data science,
-
mutualisation des traitements,
-
gouvernance à l’échelle,
-
découplage des usages.
Mais parfois, le vrai besoin est beaucoup plus ciblé :
-
“fiabiliser les KPI Sales”,
-
“réconcilier CRM et ERP”,
-
“disposer d’un socle unique pour les analyses commerciales”,
-
“sortir d’Excel et des extractions manuelles”.
Et dans certains contextes, il n’est pas nécessaire de construire immédiatement un Lakehouse complet pour créer de la valeur.
Le cadrage Data sert justement à déterminer :
-
si le besoin justifie un socle plateforme,
-
à quel niveau,
-
dans quel ordre,
-
et avec quelle trajectoire.
4) Ce que doit produire un bon cadrage Data
Un bon cadrage Data doit permettre de reformuler toute demande “solution” en besoin exploitable.
Par exemple :
| Demande exprimée | Besoin réel à clarifier |
|---|---|
| On veut du temps réel | Quelle décision nécessite quelle latence, avec quel impact business ? |
| On veut Databricks | Quel type de traitement, quel niveau d’industrialisation, quelle gouvernance ? |
| On veut un Data Lake | Quel problème de centralisation, d’historisation, de mutualisation ou de gouvernance cherche-t-on à résoudre ? |
| On veut un Customer 360 | Pour quel usage concret : support, sales, marketing, risque, service client ? |
| On veut centraliser toutes les données | Pour quels domaines, quels usages, quelles priorités et quel ROI ? |
Le cadrage ne doit donc pas sortir directement un schéma technique.
Il doit d’abord produire une compréhension structurée du besoin data.
5) Ma démarche de cadrage Data
Dans un projet Data, j’organise généralement le cadrage autour de six questions structurantes.
1. Quel est le besoin métier réel ?
On ne part pas de la donnée.
On part de la décision, du processus ou du problème métier.
Exemples :
-
améliorer le forecast commercial,
-
mieux segmenter le pipe,
-
réduire les écarts entre CRM et ERP,
-
accélérer le pilotage des ventes.
La première reformulation doit être orientée ainsi :
“Je souhaite pouvoir prendre telle décision, ou piloter tel processus, avec tel niveau de confiance.”
2. Le besoin est-il analytique, opérationnel, ou hybride ?
C’est une question fondamentale, souvent oubliée.
Parce qu’en apparence, deux demandes peuvent sembler proches, alors qu’elles relèvent de logiques très différentes.
Besoin analytique
Objectif :
analyser,
consolider,
historiser,
piloter,
mesurer.
Typiquement :
reporting,
BI,
KPIs,
analyses multi-sources,
tendances,
segmentation.
Besoin opérationnel
Objectif :
agir dans le process,
déclencher,
alimenter un système aval,
personnaliser une action,
synchroniser un flux.
Typiquement :
mise à jour CRM,
recommandations en quasi temps réel,
alimentation applicative,
orchestration d’actions métiers.
Besoin hybride
C’est fréquent :
une partie analytique pour comprendre,
une partie opérationnelle pour agir.
Et ce point change beaucoup de choses :
architecture cible,
fréquence,
patterns d’intégration,
gouvernance,
monitoring,
et choix technologiques.
3. Quelle latence est réellement nécessaire ?
C’est ici qu’on démonte beaucoup de faux besoins.
On doit distinguer :
temps réel strict,
quasi temps réel,
intra-journalier,
quotidien,
hebdomadaire.
Et poser des questions simples :
que se passe-t-il si l’information arrive en 5 minutes ? en 1 heure ? le lendemain matin ?
quelle décision serait objectivement dégradée ?
quel est le coût métier d’un retard ?
quel est le coût technique de la latence demandée ?
Très souvent, cette étape évite de construire une architecture beaucoup trop complexe par rapport au besoin réel.
4. Quel niveau de granularité et de qualité est nécessaire ?
Le besoin data n’est pas seulement une question de fréquence.
C’est aussi une question de :
grain,
complétude,
exactitude,
fraîcheur,
stabilité des référentiels,
explicabilité du KPI.
Exemple Sales :
veut-on analyser au niveau opportunité ?
commande ?
facture ?
ligne de facture ?
client ?
commercial ?
territoire ?
Sans cette clarification, on peut techniquement livrer quelque chose… qui ne répond pas à la bonne question.
5. Quel est le bon niveau de solution ?
Une fois le besoin clarifié, on peut enfin réfléchir au bon niveau de réponse.
La solution peut être :
un dataset gouverné,
un dashboard,
un data mart,
un pipeline,
un socle Lakehouse,
un flux événementiel,
une API,
une logique reverse ETL,
ou une combinaison de plusieurs briques.
C’est ici qu’on remet les technologies à leur bonne place :
comme des moyens, pas comme le point de départ.
6. Quelle trajectoire est la plus pertinente ?
Même quand le besoin justifie une vraie plateforme, cela ne veut pas dire qu’il faut tout construire dès le départ.
Le cadrage doit aussi proposer une trajectoire :
ce qu’on fait maintenant,
ce qu’on prépare pour la suite,
ce qu’on reporte,
ce qu’on ne fait pas.
C’est souvent là que se joue la réussite :
créer rapidement de la valeur,
sans figer prématurément,
et sans créer une dette impossible à absorber ensuite.
6) Exemples concrets appliqués à un contexte Sales
Cas 1 — “Je souhaite du temps réel sur le pipe commercial”
Après cadrage, on découvre que :
-
les managers pilotent surtout à la journée,
-
la vraie douleur vient de la mauvaise qualité CRM,
-
et le besoin réel est d’avoir un pipeline fiable à 7h chaque matin.
La bonne solution n’est alors pas forcément du streaming, mais :
-
un batch quotidien robuste,
-
des quality checks,
-
des règles de gouvernance sur le CRM,
-
et un modèle de données clair.
Cas 2 — “Je souhaite Databricks”
Après cadrage, on découvre que :
-
l’organisation veut surtout consolider CRM + ERP,
-
historiser,
-
servir Power BI,
-
et standardiser ses transformations.
Le besoin réel est donc peut-être :
-
une plateforme analytique industrialisée,
-
avec gouvernance,
-
historisation,
-
monitoring,
-
et capacité d’évolution.
Databricks peut être une bonne réponse.
Mais la conclusion ne vient qu’après le cadrage — pas avant.
Cas 3 — “Je souhaite un Customer 360”
Après cadrage, on découvre que :
-
le vrai besoin du Sales n’est pas d’avoir 200 attributs clients,
-
mais de disposer de 12 informations fiables pour préparer les rendez-vous et prioriser les comptes.
La bonne solution devient alors :
-
un Customer 360 ciblé,
-
avec un périmètre utile,
-
une logique d’unification claire,
-
et une trajectoire d’enrichissement progressive.
7) Les erreurs de cadrage Data que je vois le plus souvent
1. Prendre la demande exprimée comme le besoin réel
C’est l’erreur racine.
2. Choisir l’outil trop tôt
Databricks, Cloudera, Azure, AWS… viennent après la clarification du besoin.
3. Confondre besoin analytique et besoin opérationnel
C’est une erreur structurante, qui fait partir l’architecture dans la mauvaise direction.
4. Surévaluer le besoin de temps réel
Le temps réel est souvent demandé parce qu’il “sonne moderne”, pas parce qu’il est réellement nécessaire.
5. Ne pas qualifier le niveau de granularité attendu
On croit parler du même sujet, mais on ne parle pas du même grain.
6. Vouloir tout centraliser avant de prouver la valeur
Le cadrage doit protéger la trajectoire, pas nourrir l’ambition floue.
8) La règle simple que j’utilise
Tant qu’une demande ne peut pas être reformulée comme ceci :
“Je souhaite pouvoir prendre telle décision, ou supporter tel processus, avec tel niveau de fréquence, de granularité, de qualité et de sécurité”
…alors on n’a pas encore réellement cadré le besoin Data.
Conclusion
Le cadrage Data n’est pas l’art de répondre vite à une demande formulée.
C’est l’art de comprendre ce que l’organisation cherche réellement à obtenir, pour construire ensuite la réponse la plus juste.
Dans beaucoup de cas, la vraie valeur du cadrage n’est pas de confirmer la solution imaginée au départ.
C’est au contraire de montrer que :
le besoin n’était pas exactement celui exprimé,
que la latence demandée n’était pas la bonne,
que la technologie citée n’était qu’un moyen,
et que la bonne réponse est souvent plus précise, plus progressive, et plus utile.
C’est exactement là que le cadrage Data prend toute sa valeur :
faire émerger le bon problème avant de construire la solution.
Ensuite, dans l’article 2, on pourra prolonger naturellement avec un sujet clé :
comment cadrer la gouvernance, la sécurité et les responsabilités data une fois le vrai besoin clarifié.
Par Mehdi Tazi, CTO — BI NEWVISION