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. Restreindre l'apprentissage de Power BI, Tableau ou SQL à la simple reproduction de tutoriels constitue pourtant une erreur stratégique.
L'expérience démontre qu'une compétence ne devient pérenne que lorsque le raisonnement général demeure visible derrière la syntaxe du logiciel.
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 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 sans jamais infantiliser ces professionnels ni nier leur expertise.
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.
L'outil donne l'efficacité immédiate. Le concept donne l'autonomie durable.
Il s'avère donc crucial de structurer l'apprentissage en explicitant le passage entre trois niveaux de réflexion :
-
Le problème métier
Que cherche-t-on concrètement à comprendre, décider ou contrôler ?
-
L'opération générale
Faut-il filtrer, regrouper, croiser ou classer l'information ?
-
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 syntaxes, une seule logique métier
Il ne s'agit pas ici de critiquer Power BI — qui reste aujourd'hui l'outil le plus utilisé du marché — 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.
1. Effectuer une simple soustraction
L'opération la plus basique que l'on puisse imaginer : déduire le profit des ventes pour obtenir le coût. Idéalement, soustraire devrait rester visuellement reconnaissable comme « ventes moins profit ».
SUM(Ventes - Profit)
[Ventes] - [Profit]
SUM(VentesMagasins[Ventes]) - SUM(VentesMagasins[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
L'intention est tout aussi limpide : additionner les profits, additionner les ventes, puis diviser les deux totaux. L'essentiel réside dans le calcul d'un ratio de masses, et non d'une moyenne de taux calculés ligne par ligne.
SUM(Profit) / SUM(Ventes)
SUM([Profit]) / SUM([Ventes])
DIVIDE(SUM(VentesMagasins[Profit]), SUM(VentesMagasins[Ventes]))
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 ici la fonction DIVIDE pour gérer les éventuelles divisions par zéro, ce qui est une excellente convention technique, mais en aucun cas un concept mathématique nouveau.
3. Isoler les ventes d'un territoire défini
L'opération consiste ici à filtrer les lignes concernant une zone géographique précise (par exemple, la Bretagne), puis à en additionner les ventes.
SUM(CASE WHEN Region = 'Bretagne' THEN Ventes END)
IF [Région] = "Bretagne" THEN [Ventes] END
CALCULATE(SUM(VentesMagasins[Ventes]), VentesMagasins[Région] = "Bretagne")
La syntaxe de Tableau brille ici par son épure : l'agrégation (SUM) est optionnelle lors de la création de la formule, rendant le calcul ligne à ligne parfaitement limpide. SQL associe classiquement la condition et l'agrégation. DAX emprunte une approche conceptuellement différente : CALCULATE réévalue une mesure 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'un fichier à l'autre.
Ce n'est pas seulement la syntaxe qui masque le mécanisme : c'est aussi le nom de la fonction. WHERE dit où. IF dit si. 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
Le besoin consiste à évaluer un taux de profit via un branchement conditionnel (une valeur négative indique une perte, etc.).
CASE WHEN taux_profit < 0 THEN 'Perte'
WHEN taux_profit < 0.10 THEN 'Faible'
ELSE 'Satisfaisante' END
IF [Taux de profit] < 0 THEN "Perte"
ELSEIF [Taux de profit] < 0.10 THEN "Faible"
ELSE "Satisfaisante" END
SWITCH(TRUE(),
[Taux de profit] < 0, "Perte",
[Taux de profit] < 0.10, "Faible",
"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.
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é.
Le risque le plus insidieux en analyse de données n'est pas l'erreur manifeste. C'est la question que l'utilisateur renonce à creuser parce que la mécanique logicielle lui semble soudainement trop laborieuse.
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 avec bien plus de fulgurance et 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 en demeure toujours le maître intellectuel.
Sur le blog
- 01 Pourquoi passer à Power BI fait grandir vos équipes
- 02 Apprenez les fondamentaux de la BI, pas des recettes techniques
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 →