Arrêtez de modéliser vos données. Commencez par modéliser vos décisions.

Le modèle dominant : data-first

Si vous avez déjà participé à un projet BI, vous reconnaîtrez ce déroulé. Le consultant arrive, cartographie les sources de données, construit un modèle en étoile (tables de faits, tables de dimensions), crée des mesures DAX sophistiquées, développe une dizaine de dashboards, forme les utilisateurs, et s'en va. Le tout en 9 à 14 mois.

C'est l'approche data-first. Elle part du bas — les données brutes — pour remonter vers le haut — la décision. C'est la méthode enseignée dans toutes les certifications Microsoft, promue par tous les cabinets, appliquée dans tous les appels d'offres. Et elle échoue dans la majorité des cas.

Ces chiffres sont des ordres de grandeur issus de notre expérience cumulée sur des dizaines de projets BI menés chez des opérateurs télécom, des groupes industriels et des institutions financières en Europe. Les études sectorielles (Gartner, Forrester) convergent sur le même constat : une majorité de projets BI ne produisent pas la valeur métier attendue. Le pattern que nous observons est constant : le modèle de données est techniquement impeccable et fonctionnellement surdimensionné. Le consultant a construit un cube analytique qui permet 400 combinaisons de filtres, mais le DG a besoin de 3 vues et il les veut en 2 secondes sur son téléphone.

L'inversion : Decision-First Design

L'approche que nous avons développée en 20 ans de pratique inverse la chaîne. On ne part pas des données. On part des décisions.

Comment ça fonctionne : le cas d'un groupe agroalimentaire

Prenons un cas concret. Un groupe agroalimentaire — 8 filiales, 4 usines de transformation, un réseau de distribution dans 3 pays, 200 références produits, 800 collaborateurs. Le DG pilote depuis le siège et a besoin de visibilité sur l'ensemble de la chaîne, de l'achat de matière première à la marge nette par produit.

Un cabinet classique commencerait par cartographier les 14 sources de données du groupe : l'ERP comptable, les fichiers Excel de suivi de production, la base commerciale, les données logistiques de chaque entrepôt, les relevés bancaires, les fichiers RH. Il construirait un modèle en étoile unifié, avec des dizaines de tables de dimensions (produits, clients, fournisseurs, sites, périodes, devises). Et 9 mois plus tard, il livrerait 10 dashboards couvrant finance, production, commercial, logistique et RH.

Nous commençons autrement. Nous commençons par une heure avec le DG.

Étape 1 : identifier les 5 décisions vitales

Après une heure d'entretien, voici ce qui ressort. Le DG de ce groupe agroalimentaire prend régulièrement cinq décisions critiques — et pour chacune, il manque de visibilité.

Cette matrice tient sur une feuille A3. Elle est le cahier des charges réel du projet. Pas 78 pages de spécifications fonctionnelles. Une matrice : décision × donnée × source × fréquence. Chaque cellule est validée par le DG lui-même, pas par un chef de projet intermédiaire.

Étape 2 : le contrat de données

Chaque décision génère ce que nous appelons un « contrat de données » — la liste minimale de données nécessaires pour que cette décision soit éclairée. Pas les données « utiles ». Pas les données « intéressantes ». Les données sans lesquelles la décision se prend à l'aveugle.

Pour la décision « faut-il réapprovisionner Bouaké ou San Pedro ? », le contrat est précis : stock en temps réel par référence et par site (source : module inventaire de l'ERP), cadence de production des 7 derniers jours (source : fichier Excel rempli par les chefs d'usine), commandes clients confirmées pour les 14 prochains jours (source : base commerciale). Trois sources. Pas quatorze.

Le modèle de données est alors construit pour servir ces 5 contrats, et uniquement ces 5 contrats. Résultat : au lieu de 340 mesures DAX et 12 dashboards, on produit 45 mesures et 4 dashboards. Mais ces 4 dashboards répondent exactement aux questions que le DG pose chaque semaine.

Étape 3 : le dashboard comme arbre de décision

C'est ici que la différence visuelle devient frappante. Un dashboard data-first pour ce groupe agroalimentaire afficherait un graphique de tendance du chiffre d'affaires global, une table de détail par filiale, des filtres par produit, période et zone géographique. C'est exhaustif. C'est informatif. Et le DG ne sait pas quoi en faire à 8h du matin avant sa réunion de direction.

Un dashboard decision-first affiche autre chose : un signal vert/orange/rouge par usine. Le DG voit en 3 secondes qu'il y a un orange sur Bouaké. Il clique. Il voit que le stock de la gamme huile couvre 4 jours et que 3 commandes sont en attente. Il voit la recommandation : transférer 12 tonnes depuis San Pedro ou passer commande fournisseur. Il décide. En 30 secondes, pas en 30 minutes.

Le premier dashboard informe. Le second fait agir. La différence n'est pas esthétique — elle est structurelle. Le dashboard data-first a été conçu par un consultant qui pense en mesures et en dimensions. Le dashboard decision-first a été conçu par quelqu'un qui a compris que le DG veut savoir une seule chose à 8h du matin : y a-t-il un problème, et si oui, que faire ?

Pourquoi l'industrie ne travaille pas comme ça

Soyons honnêtes : il y a des raisons légitimes pour lesquelles le modèle data-first domine. D'abord, il est plus sûr. Un consultant qui construit un modèle de données exhaustif ne prend pas le risque de « rater » une demande future. En couvrant tout, il se protège contre l'imprévisible — et dans les grandes organisations avec de multiples parties prenantes, cette prudence a du sens. Ensuite, le data-first a des mérites réels dans certains contextes : quand l'organisation ne sait pas encore ce qu'elle cherche, quand l'objectif est l'exploration de données, ou quand un data warehouse unifié est un prérequis technique pour d'autres projets (data science, IA, reporting réglementaire).

Mais il faut aussi reconnaître une réalité économique. Le modèle data-first est plus rentable pour le consultant. Un modèle complet avec 340 mesures DAX nécessite des mois de travail spécialisé. Chaque mesure est une journée de facturation. Chaque dashboard est un livrable qui justifie le prix du projet. Le fait que 10 de ces 12 dashboards ne seront jamais ouverts n'est un problème pour personne — le contrat a été respecté, les spécifications ont été livrées.

L'approche decision-first est moins rentable à court terme pour le consultant. 45 mesures au lieu de 340, c'est 3 fois moins de jours facturés. 4 dashboards au lieu de 12, c'est un projet qui semble « petit » sur un CV de cabinet. Et l'entretien avec le DG — cette heure cruciale qui détermine tout le reste — n'est pas une prestation facturable dans les grilles tarifaires classiques. C'est un investissement en compréhension que la plupart des cabinets ne valorisent pas.

Nous avons fait un choix différent. Non pas parce que le data-first est « mauvais » — mais parce que dans la majorité des projets que nous avons observés, le besoin réel du décideur est ciblé, pas exhaustif. Et répondre à un besoin ciblé avec un outil ciblé produit plus de valeur qu'un outil exhaustif que personne n'utilise. Le client qui utilise ses 4 dashboards quotidiennement est un client qui revient pour la phase 2. Celui dont le projet est mort dans un tiroir est un client perdu — et une référence qu'on ne peut pas citer.

D'où vient cette approche

Le Decision-First Design n'est pas né d'une théorie. Il est né d'un constat répété pendant 20 ans de conseil en Europe. Chez un opérateur télécom français, nous avons livré un modèle de données de 200 mesures pour le département marketing. Six mois plus tard, le directeur marketing utilisait 4 mesures. Les 196 autres avaient été construites pour répondre à des spécifications validées par un chef de projet, pas par le directeur marketing lui-même.

Chez un groupe industriel suisse, le CFO avait un dashboard de 15 pages. Il n'en ouvrait qu'une seule — celle qui montrait le cash consolidé par filiale et la distance au covenant bancaire. Le reste était du bruit. Quand nous lui avons demandé « quelle décision prenez-vous avec ce dashboard ? », il a répondu : « je vérifie si je dois appeler la banque cette semaine ou non. » Une décision. Un chiffre. Tout le reste n'existait que pour justifier le budget du projet.

C'est cette accumulation d'expériences — des projets ambitieux dont la valeur se concentrait toujours dans 10 à 20% des livrables — qui nous a conduits à inverser la logique. Au lieu de tout construire et espérer que le décideur y trouve son compte, on identifie d'abord ce dont le décideur a besoin, et on ne construit que ça.

Nous avons passé la première partie de notre carrière à construire des modèles de données parfaits. Nous passons la seconde à ne construire que ce qui sera utilisé. C'est plus difficile, paradoxalement — parce que la contrainte la plus exigeante n'est pas technique, elle est intellectuelle : comprendre la décision avant de toucher aux données.

Les trois tests du Decision-First Design

Chaque élément du système — chaque table, chaque mesure DAX, chaque visuel — doit passer trois tests avant d'être construit.

Le test de la décision. Quelle décision cette mesure éclaire-t-elle ? Si la réponse est « elle donne de la visibilité » ou « c'est une best practice », elle ne passe pas le test. Une mesure qui ne sert pas une décision identifiée est une mesure qu'on ne construit pas.

Le test du lundi matin. Si le DG ouvre ce dashboard lundi à 8h, saura-t-il en moins de 10 secondes s'il y a un problème ? Si la réponse est non — s'il doit cliquer, filtrer, interpréter, comparer avant de comprendre — le design est à revoir. L'information critique doit sauter aux yeux.

Le test de l'action. Une fois le problème identifié, le dashboard propose-t-il une action ? Pas forcément une recommandation automatique — mais au minimum une navigation vers le détail nécessaire pour agir. Si le DG voit un rouge sur Bouaké mais doit ouvrir Excel pour comprendre pourquoi, le dashboard a échoué à la dernière étape.

L'impact mesurable

Sur les projets où nous avons appliqué le Decision-First Design en Europe, nous observons des écarts significatifs par rapport aux projets conduits en data-first. Ces chiffres sont des moyennes issues de notre portefeuille de missions — pas d'une étude académique. Nous les partageons comme repères, pas comme promesses.

Le dernier chiffre mérite une explication. Dans un projet data-first, le lien entre un dashboard et une décision spécifique n'est généralement pas documenté — parce qu'il n'a pas été conçu. Dans notre approche, chaque dashboard est rattaché à des décisions identifiées dès la conception. Cela rend le ROI mesurable : on peut compter combien de décisions sont effectivement prises en s'appuyant sur le dashboard, et lesquelles se prennent encore à l'ancienne.

Le résultat le plus frappant n'est pas technique. C'est comportemental. Quand un dashboard est conçu pour une décision précise, le décideur l'ouvre. Tous les jours. Sans qu'on ait besoin de le relancer. Parce qu'il sait exactement pourquoi il l'ouvre et ce qu'il va y trouver. Le dashboard n'est plus un outil de reporting — c'est un réflexe de pilotage.

Et si votre DG ne sait pas formuler ses décisions ?

C'est la question la plus fréquente. Et c'est justement là que réside l'expertise. La plupart des dirigeants ne formulent pas spontanément leurs décisions en termes exploitables pour un projet BI. Ils disent « je veux de la visibilité sur les ventes » ou « il me faut un dashboard financier. » C'est à nous de traduire ces demandes en décisions concrètes.

Comment ? En posant les bonnes questions. Pas « quels KPIs voulez-vous ? » — cette question génère des listes interminables. Mais « quelle est la dernière décision que vous avez prise cette semaine avec un sentiment d'incertitude ? » Ou « si vous pouviez avoir une réponse instantanée à une seule question chaque matin, ce serait laquelle ? » Ou encore « quel chiffre vérifiez-vous systématiquement avant votre comité de direction ? »

Ces questions extraient les décisions réelles, pas les décisions théoriques. Et c'est sur cette réalité que nous construisons.

C'est aussi pour cette raison que notre diagnostic de 5 jours commence toujours par cet entretien. Pas par une cartographie technique. Pas par un inventaire de données. Par une heure avec la personne qui prend les décisions. Parce que si on ne sait pas quelle décision on veut éclairer, le meilleur modèle de données du monde restera un exercice intellectuel. Et si on le sait, 45 mesures bien choisies valent plus que 340 mesures livrées par habitude.