Apprenez les fondamentaux de la BI, pas des recettes techniques

Les dirigeants, les directeurs financiers et les responsables de formation partagent une attente parfaitement légitime : rendre les équipes immédiatement opérationnelles sur les outils de données de l'entreprise. Limiter l'apprentissage de Power BI, Tableau ou SQL à la simple reproduction de tutoriels constitue pourtant une erreur stratégique : elle crée une illusion de compétence.

Le risque n'est pas que les collaborateurs « ne sachent pas utiliser l'outil ». C'est qu'ils produisent des chiffres qu'ils ne savent pas auditer – et qu'ils ne détectent pas l'erreur quand elle survient.

L'épreuve de vérité pédagogique

Enseigner le data management et le pilotage de la performance à l'Université Paris Dauphine PSL ainsi qu'à l'Université Jean Moulin Lyon 3 offre un excellent test pédagogique. Face à des étudiants en master – formation initiale ou continue – qui abordent ces matières sans formation informatique préalable, le verdict est sans appel : si la complexité de la syntaxe masque la logique, ces derniers se contentent de reproduire une formule sans en comprendre la finalité, ni savoir comment la transposer.

Dans l'entreprise, le problème se présente sous un jour différent, bien que l'enjeu demeure identique :

• Un contrôleur de gestion peut maîtriser la marge et le budget à la perfection sur Excel, sans avoir jamais étudié l'architecture des bases de données.
• Un manager opérationnel peut connaître son processus dans les moindres détails sans pour autant savoir comment les systèmes croisent formellement l'information, à quel niveau de détail exact s'opère un calcul, ou comment le logiciel délimite son périmètre d'analyse invisible.

Il ne s'agit nullement d'une faiblesse professionnelle : ces mécaniques ne relèvent tout simplement pas de leur métier d'origine. Une formation en entreprise rassemble des profils aux niveaux techniques disparates, mais riches d'expériences métier fortes. L'enjeu d'une pédagogie réussie est alors de rendre ces logiques d'assemblage de données accessibles tout en valorisant leur solide expertise professionnelle.

L'outil est éphémère, les fondamentaux demeurent

Les logiciels restent, bien entendu, indispensables : ils offrent une prise directe sur le réel et permettent d'agir rapidement sur les données. Former les équipes sur l'outil déployé au sein de l'organisation répond incontestablement à un besoin immédiat.

Cependant, l'environnement technologique est mouvant : une version change, un outil est remplacé, une entreprise migre vers un nouvel écosystème. À l'inverse, les règles de croisement de données, le choix du niveau de détail, les logiques de consolidation et la perception visuelle, eux, restent durablement mobilisables.

Il s'avère donc crucial de structurer l'apprentissage en explicitant le passage entre trois niveaux de réflexion :

1. Le problème métier

   Que cherche-t-on concrètement à comprendre, décider ou contrôler ?

2. L'opération générale

   Faut-il filtrer, regrouper, croiser ou classer l'information ?

3. La mise en œuvre

   Comment Power BI, Tableau ou SQL traduisent-ils cette opération dans leur langage ?

Une recette technique devient une véritable compétence professionnelle lorsque le collaborateur est capable d'expliquer l'opération réalisée et de reconstruire ce raisonnement ailleurs.

Quatre opérations, trois langages, une seule logique

Il ne s'agit pas ici de critiquer Power BI – un outil largement déployé dans les entreprises et les directions financières – ni de désigner un vainqueur. Comparer ces environnements permet, en toute candeur, de distinguer le raisonnement métier, qui reste stable, de la grammaire et de la charge visuelle propres à chaque outil.

Pour chaque exemple, l'opération générale est nommée : c'est elle que la formation doit ancrer durablement, indépendamment du logiciel.

1. Ventes moins profit

Opération générale : soustraire deux totaux. L'opération la plus basique : déduire le profit des ventes pour obtenir le coût. Idéalement, la syntaxe devrait rester visuellement reconnaissable comme « ventes moins profit ».

Ici, la différence de fluidité saute aux yeux. Là où SQL et Tableau conservent une syntaxe épurée s'approchant du langage naturel, l'écriture sous forme de mesure dans DAX alourdit visuellement le calcul. Sauf à effectuer un calcul de colonne en amont, l'utilisateur est contraint d'invoquer à deux reprises le formalisme des agrégations (SUM) et d'accoler le nom complet de la table (VentesMagasins) devant chaque champ. Un calcul pourtant simplissime devient immédiatement verbeux.

2. Calculer un taux de profit

Opération générale : diviser deux agrégats – et non faire une moyenne de ratios ligne par ligne. L'intention est tout aussi limpide : additionner les profits, additionner les ventes, puis diviser les deux totaux. Cette distinction n'est pas anodine : une moyenne de taux ligne par ligne donnera un résultat différent, et souvent erroné.

Si SQL et Tableau illustrent la division de manière directe, on observe de nouveau que l'écriture en DAX impose de rappeler le nom de la table, alourdissant la lecture. Par ailleurs, DAX utilise la fonction DIVIDE pour gérer les éventuelles divisions par zéro – ce qui est une bonne convention pour éviter les erreurs silencieuses, mais qui alourdit la syntaxe sans rien révéler de plus sur l'opération réalisée.

3. Ne garder que les ventes d'une région donnée

Opération générale : filtrer un périmètre, puis agréger. L'opération consiste à restreindre l'analyse à une zone géographique précise (ici, la Bretagne), puis à sommer les ventes correspondantes.

C'est ici Tableau qui offre la syntaxe la plus directe : l'agrégation (SUM) est optionnelle lors de la création de la formule, rendant le calcul ligne à ligne parfaitement limpide. SQL associe quant à lui la condition et l'agrégation au sein d'une même expression. DAX emprunte une approche conceptuellement différente : CALCULATE réévalue une expression en redéfinissant le périmètre d'analyse. Cette mécanique n'est pas intuitivement supérieure ; elle exige d'être comprise car elle suppose de maîtriser la façon dont les filtres se propagent d'une table à l'autre à travers les relations du modèle.

Ce n'est pas seulement la syntaxe qui masque le mécanisme : c'est aussi le nom de la fonction.

IF … THEN … dit si… alors… CALCULATE dit… calcule – ce que font tous les calculs. Le nom ne révèle rien de l'opération réelle, qui est pourtant simple : restreindre le périmètre avant d'agréger. Un apprenant qui découvre CALCULATE n'a aucun indice dans le nom lui-même qu'il est en train d'apprendre un filtre conditionnel.

4. Catégoriser un résultat

Opération générale : branchement conditionnel – si ... alors ... sinon. Le besoin consiste à évaluer un taux de profit et à lui attribuer une catégorie selon plusieurs seuils (valeur négative, valeur faible, valeur satisfaisante).

SQL et Tableau rendent le schéma universel en français et en informatique « condition-résultat » (si ... alors ... sinon) immédiatement lisible. SWITCH(TRUE()) souffre du même problème de nom que CALCULATE : « permuter » évoque un interrupteur ou un échange, pas un branchement conditionnel. Et « permuter vrai » – c'est-à-dire permuter sur la valeur vraie – ne dit rien du raisonnement qu'il encode. Si l'apprenant ne sait pas, de lui-même, que cet idiome est un substitut aux IF imbriqués, le nom ne l'y aidera pas.

DAX marque ici un progrès réel sur Excel : les noms de champs apparaissent explicitement (VentesMagasins[Ventes]), ce qui facilite la lecture et l'audit. Par rapport aux six niveaux de SI() qui ouvraient cet article, c'est le jour et la nuit. Mais si la syntaxe s'est enfin modernisée, la dernière étape reste la même : rendre le calcul tellement limpide dans les esprits qu'il devient transposable partout.

La charge cognitive : l'ennemi de l'analyse

La quête d'une notation simple ne relève pas de l'esthétisme. Comme le rappellent les travaux de John Sweller sur la charge cognitive, notre mémoire de travail est limitée.

Lorsqu'un professionnel doit épuiser son attention à chercher une fonction, fermer une parenthèse, lire des préfixes de tables à rallonge ou décrypter un menu complexe, cette ressource mentale fait cruellement défaut pour vérifier s'il n'a pas généré de lignes en double ou pour interpréter judicieusement un écart chiffré.

Une véritable compétence implique de conserver la capacité d'enquêter, de contrôler et d'ajuster son raisonnement.

L'ambition d'une formation durable

Dans l'entreprise, une formation aux outils de Business Intelligence doit impérativement permettre aux équipes de :

• Partir d'une question métier avant de sélectionner une fonction technique.
• Identifier l'opération générale dissimulée sous la syntaxe du logiciel.
• Comprendre comment les données s'assemblent, se détaillent et se consolident pour asseoir la fiabilité des chiffres.
• Auditer le résultat obtenu et anticiper les éventuels effets de bord.
• Reconstruire la même logique analytique dans n'importe quel autre environnement.

Cette philosophie ne diminue en rien la valeur intrinsèque de Power BI, bien au contraire. Une équipe qui maîtrise la façon dont l'information circule et se calcule appréhendera ses fonctions avancées plus rapidement et avec davantage de discernement.

La bonne formation ne prône ni l'abstraction déconnectée de la pratique, ni l'usage exclusif du logiciel privé de compréhension. L'enjeu n'est pas d'enseigner moins de logiciels, mais de s'assurer que l'analyste peut toujours expliquer ce qu'il a calculé, le vérifier, et le reconstruire ailleurs.

Michel Baldellon est consultant en pilotage de la performance et fondateur de Check'nDo. Il enseigne le data management et le contrôle de gestion à l'Université Paris Dauphine PSL et à l'Université Jean Moulin Lyon 3. En savoir plus →