IFCX/5 : on a testé le prototype, voilà ce qu’il change vraiment

buildingSMART vient d’ouvrir le financement du projet IFCX – Core & Modularisation. Derrière l’annonce, les mêmes mots reviennent : nouvelle génération d’IFC, modularité, cloud, API, échanges incrémentaux.

Nous avons donc téléchargé les fichiers d’exemple du dépôt officiel, ouvert le schéma actuel et chargé hello-wall.ifcx dans le visualiseur de référence.

Un mur, deux calques contradictoires et quelques dizaines de kilo-octets plus tard, la direction devient beaucoup plus concrète.

Avec une réserve essentielle : ce que l’on teste aujourd’hui est encore un prototype alpha. Le Final Project Plan de buildingSMART indique lui-même que plusieurs choix fondamentaux doivent encore être confirmés.

IFCX n’est pas simplement « IFC 5 en JSON »

Dans les documents officiels, buildingSMART distingue désormais IFCX de l’ancien terme générique « IFC 5 ».

IFCX désigne principalement la nouvelle technologie d’échange : sérialisation, schémas, API et mécanismes de composition des données. Les classes, propriétés et autres contenus métier doivent être organisés dans des modules séparés.

L’objectif est donc de sortir progressivement du grand schéma monolithique actuel pour disposer d’un Core minimal, complété par différents modules selon les domaines et les usages.

C’est probablement un changement plus important que le passage de STEP à JSON.

Un mur qui n’est plus un bloc unique

L’exemple hello-wall.ifcx est volontairement simple : un mur, deux fenêtres, un bâtiment, un étage et quelques objets.

Mais sa structure est révélatrice.

Le même mur apparaît plusieurs fois avec le même identifiant, chaque entrée apportant une information différente : géométrie, classe IFC, propriétés, classification, matériau…

Le mur devient donc la somme de plusieurs contributions portant sur le même objet.

Et ces contributions peuvent, en principe, provenir de fichiers et d’acteurs différents.

C’est là que la logique IFCX commence vraiment à s’éloigner des échanges IFC auxquels nous sommes habitués.

631 octets pour ajouter une résistance au feu

Le dépôt fournit plusieurs petits calques destinés à enrichir le modèle.

L’un d’eux ajoute simplement une résistance au feu :

{
  "path": "93791d5d-...",
  "attributes": {
    "bsi::ifc::prop::FireRating": "R30"
  }
}

Le fichier complet utilisé dans notre test pèse 631 octets.

Dans ce scénario, un intervenant n’a donc pas besoin de renvoyer toute la maquette pour ajouter une information. Il peut transmettre uniquement sa contribution.

C’est précisément l’une des ambitions affichées par buildingSMART : échanges partiels, mises à jour incrémentales et modèles fédérés.

R30 contre R60 : la composition fonctionne

Le dépôt propose également deux calques volontairement contradictoires : l’un indique R30, l’autre R60.

Nous les avons chargés dans le visualiseur avec le modèle principal.

Selon l’ordre des calques, la valeur résolue du mur devient R30 ou R60. En réorganisant la pile, la valeur change sans modifier les fichiers sources.

C’est une petite démonstration, mais elle rend immédiatement visible l’intérêt du mécanisme : plusieurs acteurs peuvent enrichir un même objet sans fusionner à chaque fois une nouvelle maquette complète.

Le prototype reste toutefois… un prototype. Pendant notre test, il fallait par exemple resélectionner l’objet pour que le panneau d’attributs reflète le nouvel ordre des calques.

Et le JSON n’est pas forcément plus lourd

Autre résultat intéressant.

Le même exemple fourni par buildingSMART pèse :

• 79 592 octets en IFC STEP
• 42 935 octets en IFCX JSON

Soit environ 46 % de moins pour l’IFCX sur cet exemple.

Un mur et deux fenêtres ne permettent évidemment pas de conclure sur des modèles de plusieurs centaines de mégaoctets.

Mais cela suffit à montrer que l’équation « JSON = fichiers forcément plus lourds » est un peu rapide.

STEP sort-il vraiment ?

Pas encore.

Le prototype actuel utilise JSON et TypeSpec et s’appuie beaucoup plus sur des concepts web : API, URI, références externes, données distribuées.

buildingSMART présente d’ailleurs les limites de STEP/EXPRESS comme l’une des raisons de faire évoluer IFC.

Mais le Final Project Plan précise aussi que la technologie IFCX n’est pas encore finalisée. La sérialisation, les API et certains choix d’architecture doivent encore être évalués.

Autrement dit : JSON montre aujourd’hui une direction, pas encore une spécification définitive.

Plusieurs questions restent ouvertes

Le dépôt GitHub le montre assez bien.

Certains tickets portent encore sur le fonctionnement de la composition et la suppression d’attributs. D’autres interrogent directement la structure des fichiers.

La géométrie elle-même reste un sujet de décision : le projet doit encore déterminer ce qui doit appartenir au Core et ce qui pourrait être placé dans un module distinct.

Autre sujet à suivre : les dépendances externes. Le prototype utilise des URI pour référencer classifications, propriétés ou autres ressources.

Pour un usage à long terme, notamment côté patrimoine, cela pose une question simple : comment garantir qu’un jeu de données restera interprétable dans vingt ou trente ans ?

Le mécanisme devra être robuste pour que l’ouverture vers des ressources externes ne crée pas de nouvelles dépendances fragiles.

IFCX ne remplacera pas IFC 4.x demain matin

Un point est en revanche déjà clair : le futur IFCX Core ne sera pas rétrocompatible avec IFC 4.x.

buildingSMART prévoit de publier les nouveaux modules comme de nouvelles parties de la série ISO 16739, en parallèle des standards IFC 4.x existants.

IFC 4.3 restera donc disponible et maintenu.

Il faut plutôt voir IFCX comme une nouvelle architecture destinée à cohabiter progressivement avec l’IFC actuel, et non comme une prochaine version que tous les projets devront adopter à court terme.

Un horizon qui se compte en années

L’appel à sponsoring concerne un projet buildingSMART d’une durée maximale de 12 mois.

Mais ces douze mois ne correspondent pas à la livraison d’IFCX.

Ils doivent permettre de développer suffisamment le Core pour engager le processus formel ISO/CEN. Dans son scénario de référence, le Final Project Plan envisage une publication ISO autour de 2029, sous réserve du financement, des votes et des éventuels retards.

Nous sommes donc loin d’un nouveau format à demander dans les conventions BIM de 2027.

330 440 € à financer

buildingSMART chiffre à 330 440 € le financement nécessaire pour cette phase du projet, en complément des contributions en nature.

Le budget doit notamment couvrir le développement du Core, les tests logiciels, la documentation et le travail de normalisation.

Plusieurs acteurs du logiciel participent déjà au projet, aux côtés de buildingSMART, d’experts indépendants et d’un panel élargi.

Comme plusieurs décisions techniques sont encore ouvertes, la manière dont seront gouvernés les futurs modules et extensions mérite clairement d’être suivie.

Concrètement, qu’est-ce qu’on fait aujourd’hui ?

• BIM managers : rien à changer sur les projets en cours. En revanche, tester hello-wall.ifcx et les deux calques R30/R60 permet de comprendre rapidement le principe.
• Maîtres d’ouvrage : inutile de demander une « compatibilité IFC 5 » ou IFCX dans un cahier des charges aujourd’hui. Mieux vaut continuer à travailler la qualité et la structuration des données avec des versions IFC réellement supportées.
• Éditeurs et développeurs : c’est probablement maintenant que le sujet est le plus intéressant, puisque plusieurs choix structurants sont encore ouverts.

Ce qu’on en retient

Le plus intéressant dans IFCX n’est finalement pas le JSON. C’est le passage d’un fichier monolithique vers des données plus granulaires, composables et potentiellement échangeables de manière incrémentale.

Sur le petit exemple fourni par buildingSMART, le principe fonctionne déjà suffisamment pour devenir tangible.

Mais le chantier reste largement ouvert. La technologie d’échange, certaines règles de composition, la géométrie et l’organisation des futurs modules doivent encore être stabilisées.

La vraie question n’est donc pas encore :

« Quand allons-nous passer à IFCX ? »

Mais plutôt :

Qu’est-ce qui sera figé dans le Core, qu’est-ce qui restera extensible, et comment cette extensibilité préservera-t-elle réellement l’interopérabilité ?

Sources

• Appel à sponsoring IFCX – buildingSMART International
• Dépôt public IFC5-development
• Visualiseur officiel des exemples IFCX
• Le Final Project Plan IFCX – Core & Modularisation v1.0, daté de juin 2026, constitue également une source centrale de cette version de l'article.