Résumé exécutif

L'argument classique en faveur de l'openBIM était l'interopérabilité : ouvrir un modèle sans dépendre d'un éditeur. C'est juste, mais insuffisant — et c'est pourquoi beaucoup d'organisations le considèrent encore comme un sujet technique mineur. Le basculement réel est ailleurs : l'ensemble IFC + IDS + BCF + bSDD est devenu un mécanisme de contrôle vérifiable sur ce qui est livré. Avec l'approbation de l'IDS comme standard en juin 2024 [3], il existe pour la première fois une façon reproductible d'exprimer des exigences d'information et de vérifier automatiquement si un modèle les respecte, avec des résultats identiques quel que soit le logiciel de vérification. Pour un client ou un entrepreneur général, cela transforme une exigence contractuelle en quelque chose d'auditable plutôt que de discutable.

Le problème réel et ce qui change

Un EIR rédigé dans Word exige des « modèles avec une information suffisante pour la maintenance ». Six mois plus tard, personne ne peut démontrer objectivement si cette exigence a été respectée. Le désaccord se règle par négociation, pas par vérification. C'est ce vide — des exigences non vérifiables — que ferme l'openBIM actuel.

Quatre éléments méritent d'être distingués, car ils sont souvent confondus :

L'IFC est le schéma de données, norme internationale ouverte sous ISO 16739-1:2024 dans sa version 4.3 [1][2], qui dans cette édition a étendu sa couverture aux infrastructures : ponts, routes, voies ferrées, voies navigables et installations portuaires [2].
L'IDS définit, sous une forme interprétable par machine, quelle information doit contenir un modèle ; il est étroitement lié au schéma IFC et permet une interprétation univoque avec des résultats identiques dans tous les logiciels de vérification [3]. Son périmètre est alphanumérique — propriétés, quantités, classifications, matériaux et relations —, pas géométrique [3].
Le BCF transporte les incidents : des sujets référencés à des éléments précis via leurs GUID IFC, avec un point de vue, des commentaires, un statut et un responsable assigné, disponible à la fois en fichier et via une API REST [4].
Le bSDD distribue les définitions — classifications, propriétés, valeurs, unités — que l'IFC et l'IDS peuvent référencer [5].

La différence avec le discours openBIM d'il y a dix ans, c'est que l'enjeu n'est plus « pouvoir ouvrir le fichier », mais pouvoir prouver la conformité.

Pourquoi maintenant

D'abord, parce que l'échafaudage normatif est complet : l'IFC 4.3 a été ratifié comme norme ISO en 2024 [1][2] et l'IDS a atteint le statut de standard officiel en juin 2024 [3]. Auparavant, les exigences se partageaient dans des formats non interprétables par machine, comme des tableurs ou des PDF.

Ensuite, parce qu'il existe une infrastructure de vérification indépendante des éditeurs. L'IFC Validation Service émet un jugement de conformité du fichier par rapport au standard — syntaxe STEP, schéma et règles normatives — et sert de base aux vérifications ultérieures, bien qu'il ne vérifie pas à lui seul les exigences d'un projet spécifique [6]. Les métriques agrégées génèrent en outre des scorecards publiques sur le comportement réel de chaque outil, construites uniquement à partir de fichiers téléversés par les utilisateurs, et non par les éditeurs [7].

Enfin, par pression contractuelle : lorsque le client peut vérifier automatiquement, l'exigence devient opposable.

Comment ça fonctionne et où ça s'applique

Le cycle de contrôle a une forme stable : le client définit ses exigences d'information selon le cadre de l'ISO 19650 [8] → ces exigences sont exprimées sous forme d'un ou plusieurs fichiers IDS référençant des classifications et propriétés du bSDD [3][5] → l'équipe projet les utilise pendant la production, pas seulement à la fin → le modèle est exporté en IFC et passe d'abord par une validation de conformité au standard [6], puis par une vérification contre l'IDS → les non-conformités sont communiquées comme des sujets BCF assignés à des responsables précis [4] → le modèle corrigé est revérifié et le résultat est consigné.

Applications concrètes :

Vérification des livrables par jalon : remplacer la révision manuelle par un rapport de conformité reproductible.
Qualification des sous-traitants : exiger que leurs modèles passent l'IDS du projet transforme une promesse commerciale en preuve objective.
Coordination MEP documentée : les incidents circulent en BCF en référençant les GUID, si bien que l'historique de qui a détecté quoi et quand survit à un changement de logiciel [4].
Transfert vers l'exploitation : le propriétaire définit dans l'IDS l'information dont il a besoin pour la maintenance et la vérifie avant réception, au lieu de découvrir des lacunes un an plus tard.
Sélection d'outils : les scorecards permettent d'évaluer le support réel de l'IFC à partir de données d'usage, pas de documents commerciaux [7].

Impact sur l'entreprise et les équipes

Pour le propriétaire, l'effet est un déplacement du risque : ce qui était accepté par confiance devient vérifié. Pour l'entrepreneur et le consultant BIM, l'effet est double : l'exigence augmente, mais celui qui sait faire fonctionner le mécanisme peut démontrer la qualité de sa livraison au lieu de se contenter de l'affirmer.

Dans les équipes, la vérification cesse d'être une tâche de clôture pour devenir un contrôle continu pendant la production, et le BIM Manager se met à rédiger et maintenir des spécifications IDS, une compétence différente de la configuration de gabarits. L'indépendance vis-à-vis des plateformes passe d'un argument idéologique à une clause de négociation : si les livrables sont vérifiables dans un format ouvert, changer de logiciel cesse d'être un événement traumatisant.

Freins, risques et niveau de maturité

Le premier frein est l'ambiguïté des versions : l'IFC 4.3 (ISO 16739-1:2024) coexiste avec l'IFC 4 ADD2 TC1 et l'IFC 2x3, encore largement utilisés [1]. Un contrat qui exige « IFC4 » sans préciser la révision invite au conflit, car les versions diffèrent par leurs entités, leurs jeux de propriétés et leurs règles de sérialisation. Le deuxième est le périmètre de l'IDS, qui couvre l'information alphanumérique et non les aspects géométriques [3] : s'y fier pour vérifier la constructibilité ou les tolérances serait une erreur de méthode. Le troisième est l'implémentation inégale des logiciels, raison pour laquelle existent le service de validation et les scorecards [6][7]. S'y ajoutent la résistance organisationnelle — l'openBIM oblige à expliciter des accords que beaucoup d'entreprises préfèrent garder implicites — et le coût initial de définir des exigences auparavant rédigées en langage vague.

Maturité : consolidée sur certains marchés, en croissance ailleurs. Le constat : une base normative complète et ratifiée par l'ISO [2], une infrastructure publique de validation [6][7] et des marchés avec exigence contractuelle systématique, mais une adoption de l'IDS encore récente, le standard ayant à peine deux ans.

Comment se préparer

Préciser la version du schéma dans le contrat (par exemple IFC 4.3 conforme à l'ISO 16739-1:2024), jamais « IFC » seul [1][2].
Transformer l'EIR en au moins un fichier IDS opérationnel, même s'il ne couvre qu'un sous-ensemble critique d'éléments ; un IDS partiel et utilisé vaut mieux qu'un IDS exhaustif et théorique [3].
Référencer les propriétés et classifications du bSDD plutôt que de définir des nomenclatures propriétaires non documentées [5].
Intégrer la validation dans le cycle de production, en commençant par l'IFC Validation Service comme contrôle de base, puis en ajoutant la vérification contre l'IDS [6].
Standardiser l'usage du BCF pour les incidents, avec des statuts et des responsables définis, afin que l'historique de coordination reste indépendant de la plateforme [4].

Perspective d'avenir et conclusion

L'évolution probable est que les exigences vérifiables par machine deviennent une pratique contractuelle courante sur les projets publics et chez les grands clients privés, tout comme la livraison en IFC est passée d'exception à clause standard. Il est raisonnable d'anticiper que la vérification se combine avec une assistance par IA pour rédiger et interpréter les spécifications, le mécanisme déterministe restant l'autorité finale. Le calendrier de l'IFC5, encore à l'état alpha [9], demeure spéculatif.

La conclusion inverse le raisonnement habituel : l'openBIM n'est pas une concession à la communauté ni une préférence technique, c'est le seul mécanisme disponible pour qu'une exigence d'information soit opposable sans dépendre de celui qui la vérifie. Qui maîtrise l'IDS, le BCF et la validation IFC ne fait pas preuve de purisme : il contrôle la définition de « livré et conforme ». Dans un secteur où une grande partie des conflits contractuels naît d'attentes non vérifiables, ce contrôle a une valeur économique directe.

Questions fréquentes

L'openBIM signifie-t-il abandonner Revit ou un autre logiciel natif ? Non. Cela signifie que les livrables et leur vérification s'appuient sur des formats ouverts. L'outil de production reste une décision propre à chaque équipe.

L'IDS remplace-t-il le plan d'exécution BIM ? Non. Le PEB continue de définir les processus, rôles et responsabilités selon le cadre de l'ISO 19650 [8] ; l'IDS exprime la partie des exigences d'information qui peut être vérifiée automatiquement [3].

Un modèle valide dans l'IFC Validation Service respecte-t-il le contrat ? Pas nécessairement. Ce service vérifie la conformité au standard IFC et sert de base aux vérifications ultérieures, pas de vérification des exigences spécifiques d'un projet [6].

Sources et références

[1] buildingSMART International. « Industry Foundation Classes (IFC) » — versions officielles et état de l'IFC 4.3 / IFC5.

[2] ISO. ISO 16739-1:2024 — Industry Foundation Classes (IFC), Part 1: Data schema (édition ajoutant la couverture des infrastructures).

[3] buildingSMART International. « Information Delivery Specification (IDS) », standard officiel depuis le 1er juin 2024.

[4] buildingSMART International. « BIM Collaboration Format (BCF) » et la spécification BCF-API (famille OpenCDE).

[5] buildingSMART International. « buildingSMART Data Dictionary (bSDD) ».

[6] buildingSMART Technical. « IFC Validation Service » — critères de conformité et périmètre.

[7] buildingSMART International. « Software Certification Program » — scorecards générées à partir de fichiers téléversés par les utilisateurs.

[8] ISO. ISO 19650-1:2018 et ISO 19650-2:2018 — Information management using BIM.

[9] buildingSMART International. Dépôt IFC5-development (état alpha).