Résumé exécutif

Pendant quinze ans, l'objectif du BIM a été de produire un modèle. Le basculement en cours fait que le modèle cesse d'être le livrable central pour devenir un nœud au sein d'une architecture d'information comprenant classifications, exigences, données fabricant, SIG, ERP, GMAO et capteurs. Ce changement repose sur une base technique : l'IFC peut être représenté sous forme de graphe RDF connectable à des données externes [5], le bSDD distribue classifications et propriétés via une API [7], et l'IFC5 est reconstruit selon une logique de composition par couches [4]. La conséquence : « quel logiciel utilisons-nous ? » compte moins que « comment nos données se relient-elles entre systèmes, et qui répond de chaque relation ? »

Le problème réel et ce qui change

Le symptôme habituel : une propriété d'un équipement mécanique existe simultanément dans le modèle Revit, dans le tableur des approvisionnements, dans le submittal du fabricant, dans le système de maintenance du propriétaire et dans un PDF de spécification. Cinq copies, aucune faisant autorité, aucune traçabilité sur laquelle est correcte. C'est ce problème que résout une architecture de données, pas une nouvelle plateforme.

La différence entre « modèle BIM » et « architecture de données connectée » tient à l'unité de gestion : dans la première approche, l'information voyage dans des fichiers et chaque échange produit une copie ; dans la seconde, elle est référencée — le modèle pointe vers une classification publiée, vers une propriété définie dans un dictionnaire et vers un identifiant d'actif que le propriétaire reconnaît. La copie est remplacée par le lien.

Trois développements soutiennent ce changement : la représentation des données IFC sous forme de graphes RDF via ifcOWL, qui permet de relier le bâtiment aux données de matériaux, SIG, fabricants, capteurs et classifications [5][8] ; des ontologies légères comme BOT (Building Topology Ontology), développée par le groupe Linked Building Data du W3C pour décrire la topologie d'un bâtiment — étages, espaces, éléments contenus — de façon adaptée au web [6] ; et le bSDD, qui héberge classifications, propriétés, valeurs admises et unités accessibles par API REST, mettant en œuvre les concepts des normes ISO 12006-3, 23386 et 23387 [7].

Pourquoi maintenant

Le principal moteur est économique. La plupart des entreprises AEC accumulent des fichiers historiques — plans, RFI, spécifications, rapports de clôture — inutilisables car incohérents, sur papier ou isolés dans des systèmes distincts [1]. Les données ne deviennent un avantage que lorsqu'elles sont capturées dès leur création, structurées pour être réutilisées, tracées quant à leur origine, et que l'entreprise conserve le droit d'en tirer des enseignements [1].

Le deuxième moteur est l'évolution du standard : l'IFC 4.3 a été ratifié comme ISO 16739-1:2024, étendant son périmètre aux infrastructures linéaires [2][3], tandis que l'IFC fait l'objet d'une refonte majeure sous le nom d'IFC5 [2], dont le dépôt publie des exemples alpha au format IFCX [4]. Précision importante : l'IFC5 reste un matériau alpha, pas une base pour planifier une production à court terme.

Le troisième moteur est contractuel : qui ne négocie pas la portabilité, la séparation des données entre clients et les conditions de sortie de plateforme risque de perdre le contrôle de son propre actif informationnel [1].

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

L'architecture s'organise en cinq couches : identité (identifiants stables, pour qu'un ventilateur reste le même objet en conception, en chantier et en exploitation), sémantique (ce que signifie chaque classe et propriété, en référençant des dictionnaires publiés plutôt que des conventions internes non documentées [7]), exigences (quelle information doit exister à chaque échange, dans un format vérifiable), échange (formats ouverts et API) et gouvernance (qui répond de chaque ensemble de données et comment il évolue).

Applications concrètes :

Métrés et approvisionnements connectés : les quantités ne sont pas exportées, elles sont interrogées ; un changement de conception se propage au paquet d'approvisionnement sans ressaisie manuelle.
Intégration BIM-SIG pour les infrastructures : l'IFC 4.3 apporte les définitions d'alignement et d'actifs linéaires qui relient le modèle à son contexte territorial [2][3].
Transfert vers la maintenance : au lieu d'un modèle et d'un dossier de PDF, un ensemble d'actifs identifiés avec des propriétés référencées à un dictionnaire commun, exploitable par la GMAO du propriétaire.
Requêtes transversales sur des graphes : des questions qu'un fichier ne répond pas bien, du type « quels équipements alimentent des espaces critiques et n'ont pas d'accès de maintenance vérifié » [5][6].

Impact sur l'entreprise et les équipes

L'impact direct porte sur le coût marginal de l'information. Avec des fichiers, chaque nouvel usage d'une donnée exige de la ressaisir ou de la réconcilier ; dans une architecture connectée, le coût de réutilisation tend vers zéro tandis que celui de la définition initiale augmente. C'est un basculement de la dépense variable vers l'investissement fixe, et ce calcul détermine si la démarche a du sens pour chaque organisation.

Une fonction apparaît dans les équipes, que beaucoup d'entreprises AEC n'ont pas : une personne responsable du modèle de données, pas du modèle 3D. Le BIM Manager assume des décisions d'architecture de l'information qu'assumait auparavant implicitement le logiciel choisi, et les spécialistes de discipline doivent expliciter des conventions qui restaient jusque-là dans leur tête.

Freins, risques et niveau de maturité

Le frein dominant est l'écart sémantique : l'IFC a été conçu comme un schéma d'échange, et la littérature sur les technologies sémantiques en AEC documente le besoin de transformations et de prétraitement intensif pour obtenir des structures adaptées à l'interrogation et au raisonnement [9] ; les auteurs de la conversion EXPRESS-vers-OWL en ont déjà signalé les limites [8]. S'y ajoutent la dépendance au fournisseur, plus forte lorsque la couche de connexion vit à l'intérieur d'une plateforme commerciale [1] ; le coût de maintenance, car une architecture sans propriétaire se dégrade plus vite qu'un fichier ; et la sécurité, domaine couvert par l'ISO 19650-5 [10].

Maturité : adoption précoce et très inégale. Les composantes normatives sont stables (IFC comme ISO 16739-1:2024, bSDD opérationnel avec une API publique, ontologies revues par des pairs) ; ce qui n'est pas consolidé, c'est la pratique, la plupart des projets fonctionnant encore par échange de fichiers, et l'IFC5 restant à l'état alpha [4].

Comment se préparer

Définir un modèle d'identité des actifs avant toute plateforme : ce qui est identifié, avec quel codage et qui l'administre.
Référencer des dictionnaires publiés plutôt que d'inventer des propriétés, en s'appuyant sur le bSDD et sur les normes ISO 12006-3, 23386 et 23387 [7].
Commencer par un cas d'usage métier avec un destinataire identifié — transfert vers la maintenance, approvisionnements, suivi d'avancement —, pas par une migration générale des données.
Séparer la donnée de l'outil : exiger un export complet, une API documentée et la portabilité dans chaque contrat de plateforme [1].
Assigner une propriété explicite à chaque ensemble de données, avec un responsable, un critère de qualité et un cycle de mise à jour ; sans cela, l'architecture se dégrade en un semestre.

Perspective d'avenir et conclusion

L'évolution probable à trois ou cinq ans est une longue coexistence : l'échange par fichiers IFC comme base contractuelle, complété par des requêtes API sur des sous-ensembles de données à valeur opérationnelle. L'IFC5 vise des cas d'usage plus avancés [2], mais son calendrier réel dépend de la mise en œuvre par les éditeurs de logiciels. Il est spéculatif de supposer que les graphes sémantiques remplaceront l'échange de fichiers dans cet horizon.

La conclusion stratégique : traiter le BIM comme une architecture de données n'est pas un projet informatique, c'est une décision sur les actifs que conserve l'entreprise. Un bureau d'études qui livre des modèles sans conserver une structure d'information réutilisable vend des heures ; celui qui accumule des données cohérentes et traçables entre projets construit un actif qui se valorise. La différence ne se voit pas sur le premier projet, elle se voit sur le vingtième.

Questions fréquentes

Cela signifie-t-il abandonner les fichiers IFC ? Non. L'IFC 4.3 est une norme ISO en vigueur [3] et reste la base contractuelle de l'échange. L'architecture connectée se construit dessus, pas contre lui.

Faut-il implémenter des ontologies et du RDF pour commencer ? Non. L'essentiel de la valeur initiale provient de décisions plus simples : identifiants stables, propriétés référencées à un dictionnaire commun [7] et exigences vérifiables. Les graphes sémantiques sont utiles pour des scénarios de requêtes complexes, pas un prérequis de départ.

Vaut-il mieux attendre l'IFC5 ? Pas pour les décisions opérationnelles. L'IFC5 est un matériau alpha en développement ouvert [4] ; les décisions d'architecture de données prises aujourd'hui — identité, sémantique, gouvernance — resteront valables quelle que soit la version du schéma.

Sources et références

[1] Ahmoye, D.; Sjödin, E.; Blanco, J. L. et autres. « How AI is reshaping the future of the AEC industry ». McKinsey & Company, 15 juillet 2026.

[2] buildingSMART International. « Industry Foundation Classes (IFC) » — version officielle IFC 4.3.2.0 et refonte vers l'IFC5.

[3] ISO. ISO 16739-1:2024, « Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema ».

[4] buildingSMART International. Dépôt IFC5-development (exemples alpha, format IFCX, schéma en développement).

[5] buildingSMART Technical. « ifcOWL » — représentation des données IFC en graphes RDF, reliées aux matériaux, SIG, fabricants et capteurs.

[6] Rasmussen, M. H.; Lefrançois, M.; Schneider, G. F.; Pauwels, P. « BOT: The Building Topology Ontology of the W3C Linked Building Data Group ». Semantic Web, vol. 12, n° 1, 2021.

[7] buildingSMART International. « buildingSMART Data Dictionary (bSDD) » — service de dictionnaires, API et alignement avec les normes ISO 12006-3, 23386 et 23387.

[8] Pauwels, P.; Terkaj, W. « EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology ». Automation in Construction, vol. 63, 2016, p. 100-133.

[9] « Knowledge-based semantic web technologies in the AEC sector ». Automation in Construction, 2024.

[10] ISO. ISO 19650-5:2020 — Security-minded approach to information management.