L'openBIM est le moyen, pas l'objectif. L'objectif officiel du Grand-Duché est détaillé dans la maturité BIM niveau 2 au Luxembourg et ses impacts pratiques.

Photographie futuriste d'un chantier de construction cyberpunk la nuit, baigné de lumières néon bleues et cyan.

En bref : le Luxembourg a choisi l'openBIM par décision structurelle, pas par idéalisme : le Guide d'application BIM du CRTI-B s'appuie sur les schémas IFC, et Digital Building LU vise la maturité niveau 2, donc la collaboration par modèles séparés et non par modèle unique centralisé. Les trois obstacles que l'on entend le plus souvent, incompatibilité des logiciels, complexité de l'IFC et immaturité des outils, ne résistent pas à l'examen. Ce qui bloque réellement, c'est le paramétrage des exports et l'absence de contrôle avant livraison.

Que dit réellement le Guide BIM luxembourgeois sur l'openBIM ?

Le Guide d'application BIM du CRTI-B tient en 31 pages publiées en 2017, et il structure encore les projets BIM au Grand-Duché. Il ne prescrit pas un logiciel, il prescrit des formats d'échange ouverts et un système de niveaux d'information, le GID, décomposé en Géométrie, Information et Documentation. Le détail de ce système est décrypté dans notre analyse du référentiel GID.

Ce choix n'a rien d'idéologique. Le portail Digital Building LU cible la maturité BIM de niveau 2, c'est-à-dire des maquettes disciplinaires séparées échangées dans un format ouvert et coordonnées sur une plateforme commune. Le niveau 3, avec son modèle unique partagé en temps réel, supposerait que tous les acteurs travaillent sur la même plateforme. Sur un marché où les PME sont nombreuses et où Revit, ArchiCAD, Tekla et AutoCAD MEP coexistent, cette hypothèse est irréaliste. L'openBIM est donc le compromis qui correspond au tissu économique réel du secteur luxembourgeois.

Reste que le cadre existe depuis 2017 et que l'adoption progresse lentement. Luxinnovation le reconnaissait fin 2025 : l'adoption du BIM reste faible au Luxembourg malgré un cadre porteur. C'est précisément cet écart entre le cadre et la pratique qui alimente les mythes qui suivent.

Mythe 1 : « nos logiciels ne sont pas compatibles avec l'IFC »

C'est l'objection la plus fréquente, et c'est la plus facile à démonter. Revit, ArchiCAD, Tekla, Allplan et AutoCAD MEP exportent tous en IFC, et certifient pour la plupart leur export auprès de buildingSMART. La question n'est pas de savoir si le logiciel sait exporter, mais si l'export a été paramétré.

Un export IFC par défaut sort une géométrie correcte et des données à peu près vides : classifications absentes, property sets non mappés, noms d'instances génériques du type « Basic Wall », étages nommés « Level 1 » au lieu du code de projet. Le fichier s'ouvre partout, il est simplement inutilisable pour la coordination. Le problème n'est pas l'interopérabilité du format, c'est la configuration d'un mapping qui prend une demi-journée à établir et qui se réutilise ensuite sur tous les projets du bureau.

Mythe 2 : « faire de l'openBIM, c'est exporter en IFC »

Exporter est la partie facile. L'openBIM commence quand quelqu'un définit ce que le fichier doit contenir, et quand cette exigence est vérifiée avant livraison. Sans cette étape, chaque acteur exporte selon ses propres réglages et la coordination se transforme en négociation permanente sur la qualité des données.

C'est là que le BEP joue son rôle : il fixe la convention de nommage, les property sets attendus, la classification retenue et la fréquence des échanges. Et c'est là que l'IDS, publié en version 1.0 par buildingSMART le 1er juin 2024, change la donne : il traduit ces exigences en règles vérifiables par une machine, avec un résultat binaire. Le passage du PDF d'exigences au fichier de règles est détaillé dans le guide pratique de la validation IFC par IDS.

Mythe 3 : « il faut attendre que les outils progressent »

Attendre est confortable, mais les schémas nécessaires sont publiés depuis longtemps. IFC2X3 date de 2006 et reste le format le plus répandu sur les projets du Benelux. IFC4 est disponible depuis 2013, IFC4X3 étend la couverture aux infrastructures. Le format n'est pas le facteur limitant.

Ce qui manque, ce sont les habitudes de contrôle. Une maquette livrée sans audit préalable arrive chez le coordinateur avec ses défauts, et la correction se fait alors en fin de phase, au moment le plus coûteux. Vérifier un fichier avant de l'envoyer prend quelques minutes avec un audit IFC automatisé, et évite la boucle de reprise complète.

Ce qui bloque réellement sur les projets luxembourgeois

Sur la base des maquettes que je vois passer en coordination MEP, quatre causes reviennent, et aucune n'est technologique.

  • Le BEP est un document de conformité, pas un document de travail. Rédigé pour être joint à l'offre, il n'est plus rouvert après le kick-off. Personne ne vérifie que les conventions annoncées sont appliquées.
  • Le mapping d'export n'est établi par personne. Chaque modeleur exporte avec les réglages par défaut de son logiciel, et le résultat varie d'un lot à l'autre sur un même projet.
  • Le contrôle arrive après la livraison. Les écarts sont découverts par le coordinateur au lieu d'être détectés par le producteur avant l'envoi, ce qui transforme un correctif de cinq minutes en aller-retour de plusieurs jours.
  • Les fiches GID restent dans des PDF. Les exigences existent, elles sont publiques et précises, mais elles sont consultées en réunion à la main plutôt que traduites en règles applicables au moment de la modélisation.

Par où commencer concrètement

Trois actions produisent un effet mesurable en moins d'un mois, sans changer de logiciel ni attendre une évolution du cadre normatif.

  • Figer un mapping d'export IFC par discipline et le documenter dans le BEP. Une demi-journée de travail, réutilisable sur tous les projets suivants.
  • Traduire les trois ou quatre exigences les plus critiques du BEP en fiche IDS. Commencer petit : les entités de contexte et une classification suffisent pour un premier cycle.
  • Imposer un audit avant livraison, pas après. Le producteur contrôle son propre fichier, corrige, puis livre. Le coordinateur ne fait plus que confirmer.

L'openBIM au Luxembourg n'échoue pas par manque de norme, ni par insuffisance des logiciels. Il échoue quand personne n'a écrit, sur un projet donné, ce qu'un fichier IFC doit contenir pour être exploitable. Le cadre est là depuis 2017. Ce qui manque encore, c'est l'habitude de le rendre vérifiable.

À propos de l'auteur.

Renaud Climent est BIM Coordinator MEP, plus de 10 ans de terrain au Luxembourg et en Belgique. 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