On présente le débat comme un choix technique entre formats. C'est un écran de fumée. La question réelle est : qui contrôlera votre information dans vingt ans ? Et sa réponse honnête n'est presque jamais « tout l'un » ou « tout l'autre », mais « où placer la frontière entre les deux ».
Le débat est presque toujours présenté par des gens qui vendent quelque chose. D’un côté, l’openBIM promis comme une interopérabilité sans friction. De l’autre, le closed BIM vanté comme une fluidité sans faille. Les deux promesses sont fausses, et pour la même raison.
L’openBIM désigne une façon de travailler fondée sur des standards ouverts, indépendants de tout éditeur : un format d’échange d’objets, un format d’échange de remarques, un format d’expression des exigences. Ce n’est pas un logiciel, c’est un cadre, porté par une organisation à but non lucratif.
Le closed BIM désigne une façon de travailler à l’intérieur d’un même écosystème logiciel, où tout le monde utilise les outils d’un même éditeur et échange dans son format natif.
L’openBIM n’est pas une interopérabilité magique : un échange ne fonctionne que si les règles de modélisation sont alignées en amont, le format n’y change rien. Le closed BIM n’est pas sans coût : sa fluidité se paie en dépendance à un fournisseur unique. Tant qu’on croit l’un ou l’autre de ces deux discours, on n’a pas commencé à réfléchir.
Sous le débat technique, il y a une question de gouvernance que personne n’aime poser franchement : à qui appartient la capacité de lire, exploiter et faire vivre votre information dans la durée ?
Un projet dure deux ans, un bâtiment cinquante. Le choix du closed BIM lie la lisibilité de votre information à la pérennité commerciale d’un éditeur, à sa politique de licence, à sa politique de versions. Tant que vous payez et que le logiciel existe, tout va bien. Le jour où l’un des deux change, votre information est prisonnière d’un format que vous ne contrôlez pas.
L’openBIM déplace ce pouvoir. En livrant dans des formats ouverts, documentés et indépendants, vous gardez la capacité de relire votre information même si l’éditeur disparaît, augmente ses prix ou abandonne une gamme. Ce n’est pas une question de qualité de modèle, c’est une question de qui détient les clés.
Posez la question à voix haute : « si notre éditeur triplait ses tarifs demain, que se passerait-il pour nos données ? ». Si la réponse est « on paierait, on n’a pas le choix », vous mesurez le coût réel du closed BIM, celui qui n’apparaît sur aucun devis. Ce coût n’est pas forcément rédhibitoire, mais il doit être un choix, pas un défaut.
Opposer les deux comme des mondes étanches est la dernière erreur du débat. En pratique, l’immense majorité des projets sont hybrides, et c’est la bonne réponse.
La configuration la plus courante et la plus sensée mélange les deux à des endroits différents. Au sein d’une équipe qui partage les mêmes outils, on travaille en natif, parce que c’est plus fluide et que les fonctions avancées passent sans perte. Entre équipes qui n’ont pas les mêmes outils, on échange en ouvert, parce que c’est le seul terrain neutre.
Non pas « openBIM ou closed BIM ? », mais « où passe la frontière entre le natif et l’ouvert sur ce projet ? ». Cette frontière se décide, elle s’écrit dans la convention, et elle dépend de qui travaille avec qui. C’est une décision d’organisation, pas une profession de foi. Le raisonnement complet, outil par outil, est dans choisir sa chaîne d’outils.
Réduire l’openBIM au format d’échange de maquettes est l’erreur la plus commune. Ce format en est la pièce la plus connue, pas la seule : c’est un ensemble cohérent.
Dire « on fait de l’openBIM » et ne penser qu’au format d’échange de maquettes, c’est n’utiliser qu’un tiers de l’outil. L’échange fiable suppose les trois : des objets transportables, des remarques qui circulent, et des exigences vérifiables. Le format seul ne suffit jamais, et c’est pourquoi tant d’échanges « en openBIM » échouent quand même.
Un débat souvent idéologique, qui se règle par des décisions d’organisation et non par une prise de parti.
Trois idées à emporter. Le vrai enjeu n’est pas le format mais le pouvoir : le closed BIM lie la lisibilité de votre information à la pérennité d’un éditeur, l’openBIM vous en rend les clés, et ce coût de dépendance n’apparaît sur aucun devis. Ce n’est pas binaire : presque tous les projets sont hybrides, natif au sein d’une équipe, ouvert entre équipes, et la vraie question est où placer la frontière. Enfin, l’openBIM est plus large que l’IFC : il faut aussi l’échange de remarques et l’expression vérifiable des exigences, sans quoi l’échange échoue malgré le bon format.
Le composant central de l’openBIM est le format IFC, complété par le BCF pour les remarques. La décision concrète, outil par outil, se prend dans choisir sa chaîne d’outils. Et pour situer ce choix dans une échelle de maturité, souvent invoquée à tort dans ce débat, voyez les niveaux de maturité BIM.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Non, l'IFC n'est pas « le PDF de la maquette ». C'est une base de données structurée qui transporte vos objets et leurs propriétés d'un logiciel à l'autre. Comprendre ce qu'il contient vraiment, c'est arrêter de subir les exports ratés.
Assembler le meilleur outil de chaque catégorie produit rarement la meilleure chaîne. Ce qui coûte cher n'est pas le nombre de logiciels, c'est le nombre d'endroits où l'information doit changer de main. Voici comment concevoir une chaîne au lieu de la subir.
Dire « il y a un problème ici » suppose de désigner un ici. Envoyer la maquette est absurde, envoyer une capture perd la position. Le BCF résout exactement ce point, et c'est pour cela qu'il tient dans quelques kilo-octets.