En bref : une enquête publiée par Construction Management indique que 83 % des répondants utilisent encore les tableurs comme principal outil d’analyse et que 72 % passent plus de trois heures à rassembler et préparer les données avant de décider. Ces chiffres concernent les répondants et leur périodicité n’est pas précisée. Pour les équipes BIM du Luxembourg et du Benelux, la priorité consiste donc à cartographier les sources, les responsabilités et les clés d’échange avant d’ajouter Power BI, une automatisation ou un LLM.
Soyons clairs : un tableau de bord peut être propre, rapide et totalement trompeur. Sur un projet de construction, la donnée traverse souvent un logiciel chantier, un export Excel, une correction finance et une présentation avant d’atteindre la personne qui décide. Chaque reprise ajoute une version, une règle implicite ou un code projet différent. À la fin, il ne reste plus un pilotage fiable, mais une reconstitution manuelle difficile à auditer.
Pourquoi un dashboard ne répare-t-il pas la donnée ?
L’enquête publiée le 30 juillet 2026 par Construction Management avec Access Construction pose un constat précis : parmi ses répondants, 83 % utilisent encore les tableurs comme outil principal d’analyse. Ce pourcentage décrit les personnes interrogées, et non l’ensemble du secteur de la construction. Sans extrapoler, il met néanmoins un chiffre sur une situation courante dans les projets AEC : l’outil de restitution a changé, mais la préparation reste manuelle.
Un dashboard agrège ce qu’il reçoit. Si deux applications utilisent des identifiants de projet différents, si le statut « terminé » ne couvre pas la même réalité côté chantier et côté finance, ou si une date est ressaisie à la main, le graphique consolide des ambiguïtés. Une visualisation plus lisible ne crée ni propriétaire de donnée, ni règle de validation, ni historique fiable. Elle rend seulement la divergence plus agréable à consulter.
Le BIM rencontre exactement le même problème lorsqu’une maquette, un registre d’issues et un planning avancent avec des référentiels séparés. L’IFC facilite l’échange de modèles, mais il ne décide pas quel attribut fait foi ni qui le maintient. Le GID au Luxembourg structure des informations utiles, tandis qu’un environnement commun de données inspiré d’ISO 19650 organise les états et les responsabilités. Aucun standard ne compense toutefois une clé projet absente ou un export dont personne ne connaît la date de rafraîchissement.
La plomberie de données vient avant le reporting
Le deuxième chiffre de l’enquête est encore plus parlant : 72 % des répondants consacrent plus de trois heures à rassembler et préparer les données avant la décision. La source ne permet pas d’établir si cette durée se répète chaque jour, chaque semaine, chaque mois ou selon un autre rythme. Présenter ces trois heures comme une périodicité établie serait donc trompeur. Le fait vérifiable porte sur le seuil déclaré par les répondants, pas sur sa fréquence.
Ce temps de préparation cache plusieurs opérations. Il faut retrouver le bon export, aligner les noms de colonnes, corriger les formats de date, supprimer les doublons et demander pourquoi un total diffère de celui de la veille. Le travail n’apparaît généralement pas dans le dashboard final. Il est pourtant le coût réel de la décision, avec un risque supplémentaire : la correction manuelle peut devenir une règle métier sans documentation.
Dans une équipe BIM, la chaîne peut relier la maquette de coordination, les fichiers IFC reçus, les remarques BCF, le planning, les quantités et le suivi financier. Une rupture entre deux maillons force le coordinateur à reconstruire le contexte avant chaque revue. Ajouter un LLM au-dessus de ce montage accélère la formulation d’une réponse, mais ne rend pas sa provenance plus fiable. Un modèle de langage peut résumer une donnée incohérente avec beaucoup d’assurance.
Le vrai sujet est la traçabilité de la décision. Une valeur doit pouvoir être reliée à une source, à un responsable, à une date de mise à jour et à une règle de transformation. Ces quatre informations transforment un chiffre décoratif en donnée exploitable. Elles donnent aussi une base concrète pour choisir ce qui mérite une automatisation BIM.
Comment auditer un flux avant de l’automatiser ?
Commencez par une décision réelle, par exemple valider l’avancement d’une zone, arbitrer une collision ou confirmer une quantité. Remontez ensuite le chemin de chaque donnée utilisée jusqu’à son système d’origine. Cette cartographie doit montrer les exports, les copies, les corrections et les validations humaines. Un flux de cinq étapes documenté vaut mieux qu’une architecture cible de cinquante cases que personne ne maintient.
Pour chaque source, quatre questions suffisent à ouvrir l’audit. Elles obligent à parler du fonctionnement réel plutôt que de la démonstration commerciale d’un outil. Les réponses peuvent tenir sur une page si le périmètre reste limité à une décision. Les zones vides signalent immédiatement les risques de qualité ou de responsabilité.
- Propriétaire : qui répond de la définition et de la qualité de cette donnée ?
- Mise à jour : quel événement déclenche le rafraîchissement, et comment son horodatage est-il conservé ?
- Clé commune : quel identifiant relie le projet, la zone, l’objet ou l’issue entre les systèmes ?
- Décision : quelle action concrète dépend de cette information, et avec quel niveau de confiance attendu ?
Cette grille évite de vouloir connecter toutes les applications en même temps. Si une source n’alimente aucune décision identifiable, son intégration peut attendre. Si deux sources déterminent le même arbitrage avec des règles différentes, le conflit doit être résolu avant tout développement. Le BIM Workflow Generator de BIMsmarter peut servir de support pour formaliser les étapes et rendre visibles les passages manuels avant de choisir une automatisation.
Que faut-il mesurer au Luxembourg et en Belgique ?
Le contexte Benelux mérite une mesure locale plutôt qu’un copier-coller de pourcentages issus d’une enquête sectorielle. Pendant quatre semaines, une équipe peut relever le temps consacré à rechercher, nettoyer, rapprocher et valider les données pour deux décisions récurrentes. Elle peut aussi compter le nombre de fichiers intermédiaires et les corrections après diffusion. Ces indicateurs ne prétendent pas représenter le marché ; ils décrivent le processus audité.
Le premier indicateur utile est le délai entre la disponibilité de la source et la décision. Le deuxième est la part de ce délai occupée par une manipulation manuelle, tandis qu’un troisième peut suivre le nombre d’identifiants non appariés entre IFC, BCF, planning et finance. Au Luxembourg, le GID et les conventions projet peuvent fournir des repères communs si leur usage est défini. En Belgique, les mêmes principes restent valables, mais les référentiels contractuels et les responsabilités doivent être vérifiés projet par projet.
Il faut également distinguer qualité technique et qualité métier. Un fichier peut respecter son format tout en contenant un statut obsolète ; un IFC peut s’ouvrir sans porter l’information requise pour la décision. ISO 19650 aide à cadrer les exigences d’information, les responsabilités et les états de validation. Le contrôle pertinent relie donc chaque exigence à un usage, plutôt qu’à une simple présence de champ.
Une feuille de route en cinq étapes
Une PME de construction n’a pas besoin de remplacer tout son système pour progresser. Elle doit sélectionner une décision coûteuse, mesurer son processus actuel, stabiliser les définitions puis automatiser la rupture la plus répétitive. Cette approche produit une preuve locale avant d’engager un chantier d’intégration plus large. Elle limite aussi le risque de construire une nouvelle couche dépendante d’un seul fichier Excel.
- Choisir une décision : cibler un arbitrage fréquent dont le retard ou l’erreur a un effet observable.
- Tracer les sources : documenter les applications, exports, fichiers intermédiaires et validations.
- Aligner les définitions : fixer les identifiants communs, statuts, dates et unités.
- Tester un contrôle : détecter automatiquement les doublons, valeurs manquantes ou divergences sur un périmètre réduit.
- Automatiser avec preuve : conserver la source, l’horodatage et la règle appliquée dans le résultat.
Power BI devient alors une couche de lecture, non un atelier permanent de réparation. Un LLM peut interroger des informations dont le périmètre et la fraîcheur sont explicités. Les équipes BIM gardent une piste d’audit quand une quantité, un statut ou une issue change. Le gain ne vient pas seulement d’un clic supprimé ; il vient de la réduction des discussions sur la version correcte.
Un pilote doit rester assez petit pour être contrôlé. Deux sources, une clé commune et une décision récurrente forment déjà un périmètre valable. Après quatre semaines, l’équipe compare le délai de préparation, le nombre de reprises manuelles et les anomalies détectées avant diffusion. Si ces mesures ne progressent pas, ajouter une connexion ou une IA ne corrigera pas le diagnostic.
La donnée fiable est un choix d’organisation
Les 83 % et 72 % publiés par Construction Management ne sont ni un verdict sur tout le secteur ni une mesure spécifique au Luxembourg. Ils servent de signal pour examiner les heures et les risques cachés sous les couches de reporting. La bonne réponse consiste à produire ses propres mesures sur un flux limité, puis à documenter les responsabilités. C’est moins spectaculaire qu’un nouveau dashboard, mais beaucoup plus utile au projet.
Le point de départ est simple : pas de dashboard ni d’IA avant d’avoir nommé les sources, les propriétaires, les clés communes et la décision visée. BIM, IFC, GID et ISO 19650 donnent un cadre solide lorsqu’ils sont reliés à un processus observé. Tant que le flux reste opaque, il faut le rendre vérifiable avant d’ajouter un outil.
À propos de l'auteur.
Renaud Climent est BIM Coordinator MEP au Luxembourg et en Belgique : 15 ans d'expérience dans le bâtiment, dont 5 en coordination BIM. Cursus complet CRTI-B (Bases, Référent, Modeleur, Coordinateur), formé Solibri, BIMcollab et Revit MEP, certifié en IA. Fondateur de BIMsmarter.eu, il code ses propres outils pour automatiser les tâches BIM chronophages. Contact : contact@bimsmarter.eu