Power BI ne lit pas une maquette. Il joint des tables. Pour relier un objet de la maquette à un coût, à une tâche de planning ou à un relevé de chantier, il faut une colonne commune présente des deux côtés. Cette clé n'existe presque jamais, et c'est là que 90 % des projets s'arrêtent.
La première erreur est de le ranger parmi les outils BIM. Power BI n’a aucune notion de maquette, d’objet ou de classe. Il sait faire une chose, très bien : mettre en relation des tableaux qui viennent d’endroits différents.
C’est précisément pour cela qu’il est intéressant ici. Les questions qui comptent sur un projet ne se répondent jamais avec une seule source. « Où en est-on ? » suppose de croiser ce qui est modélisé, ce qui est planifié, ce qui est commandé et ce qui est posé. Ces quatre informations vivent dans quatre systèmes, et aucun ne les réunit.
Plusieurs chemins existent pour amener des données de maquette jusque-là : un connecteur d’éditeur reliant le logiciel de modélisation au tableau de bord, des services tiers qui exposent le contenu d’un fichier d’échange par classe, ou l’export de nomenclatures. Le choix du chemin est secondaire. Ce qui décide de la réussite se joue avant, et se joue ailleurs.
Ne demandez pas « comment connecter la maquette à Power BI ? », demandez « quelle colonne existe à la fois dans la maquette et dans l’autre système ? ». Si la réponse est aucune, le connecteur ne servira à rien : vous aurez deux tableaux côte à côte, sans moyen de les relier.
Une relation entre deux tables suppose une colonne commune, présente des deux côtés, du même type. C’est une contrainte de l’outil, pas une préférence de méthode : sans elle, il n’y a simplement pas de jointure possible.
Prenons comme exemple une question ordinaire : « quel est le coût des équipements de ventilation effectivement posés au niveau 2 ? ». Elle paraît simple. Elle exige de croiser trois sources.
La maquette sait quels équipements existent et à quel niveau. Le système de coûts sait ce que vaut chaque article. L’application de suivi de chantier sait ce qui est posé. Pour répondre, il faut relier les trois. Or la maquette identifie ses objets par un identifiant interne que personne d’autre ne connaît, le système de coûts raisonne par code d’article, et le suivi de chantier par local et par lot. Trois systèmes, trois vocabulaires, aucune colonne commune.
Aucun outil de visualisation ne résout cela. La clé se décide en amont : un identifiant porté par les objets de la maquette et repris dans les autres systèmes, ou au minimum un code de classification et un code de zone partagés. C’est une décision de convention, prise avant la modélisation, exactement comme pour le phasage et pour les quantitatifs.
Ouvrez deux tableaux issus des deux systèmes que vous voulez croiser, côte à côte. Trouvez-vous une colonne qui, ligne à ligne, désigne la même chose des deux côtés ? Si oui, le reste est du travail d’outillage. Si non, aucun tableau de bord n’existera, quel que soit le budget engagé, et le problème est à traiter dans la convention BIM.
Chaque source apporte une information que les autres n’ont pas, et chacune impose sa propre condition de raccordement.
Aucune de ces clés ne se crée dans Power BI. Toutes se décident en amont, dans la convention et dans le paramétrage des outils, avant que la première donnée soit produite. Un tableau de bord n’est pas un projet de fin de chantier : c’est une conséquence de décisions prises au démarrage.
Un tableau de bord alimenté à la main meurt en quelques semaines. Ce n’est pas une question de motivation : c’est mécanique, et le mécanisme est connu.
Le point que beaucoup découvrent trop tard : l’actualisation faite dans l’application de bureau ne se transmet pas une fois le rapport publié. Pour que les destinataires voient des données à jour, il faut publier vers le service en ligne et y configurer une actualisation planifiée, dont la fréquence dépend de la licence. Une licence standard autorise un nombre limité d’actualisations quotidiennes, les licences supérieures davantage.
Si personne ne peut garantir une actualisation automatique, ne construisez pas le tableau de bord : produisez un rapport ponctuel, daté, et assumez-le comme tel. Un rapport honnêtement daté vaut mieux qu’un tableau de bord qui prétend être à jour et ne l’est pas.
L’outil est excellent dans son registre. Les déceptions viennent presque toujours de trois attentes mal placées.
Pour chaque graphique envisagé, demandez quelle décision il permet de prendre, et par qui. Un indicateur dont personne n’est destinataire finira par disparaître de l’écran, et il aura coûté le même travail de préparation qu’un indicateur utile.
La difficulté d’un tableau de bord de projet n’est jamais graphique. Elle est structurelle, et elle se règle bien avant l’ouverture du logiciel.
Trois idées à emporter. Power BI joint des tables, il ne lit pas de maquette : sa valeur vient du croisement de sources que rien d’autre ne réunit. Tout dépend d’une colonne commune, un identifiant ou des codes partagés présents des deux côtés, qui se décident dans la convention et jamais dans l’outil de visualisation. Enfin, un tableau de bord non actualisé automatiquement est condamné : à défaut de pouvoir garantir l’actualisation, mieux vaut assumer un rapport daté qu’entretenir l’illusion du temps réel.
Les décisions dont dépend toute cette chaîne se prennent dans la convention BIM et se vérifient au bon moment grâce à la checklist de démarrage. Les deux usages qui reposent sur les mêmes clés sont le BIM 4D et le BIM 5D. Pour que les objets soient joignables, tout commence par modéliser proprement. Et pour écrire massivement ces clés sur des centaines d’objets plutôt qu’à la main, Dynamo.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
On attend du 5D qu'il chiffre. Il ne chiffre pas. Il extrait des quantités géométriques, et le standard IFC lui-même livre deux valeurs différentes pour le même mur. Entre ce que la maquette mesure et ce que l'entreprise facture, il reste une convention que presque personne n'écrit.
Une maquette peut être irréprochable à l'écran et inutilisable en aval. Elle peut être visuellement grossière et parfaitement exploitable. La propreté d'un modèle ne se juge pas en le regardant : elle se juge à ce que les autres peuvent en faire.
Arrêtez de subir les 13 onglets : ce guide vous montre à quoi sert chaque module, comment ils s'alimentent entre eux, et la différence décisive entre l'échéancier (Schedule) et les plans de travail (Plan).