Fichier IFC : que contient vraiment une maquette numérique (et pourquoi vos outils n'en exploitent qu'une partie)

À retenir

Un fichier IFC n'est pas un plan, c'est une base de données. Elle contient la hiérarchie spatiale, les objets, leurs propriétés et leurs relations. Aujourd'hui, vos outils n'en exploitent que la surface visible : la géométrie. La vraie valeur, technique et contractuelle, est dans tout le reste. Et elle est déjà là, dans vos fichiers, en attente d'être rendue accessible.

Derrière chaque maquette livrée à un bureau d'études, il y a un fichier IFC (Industry Foundation Classes) qui a coûté des centaines d'heures à produire. On l'ouvre, on regarde la 3D, on valide, puis on l'archive. Et on passe à côté de l'essentiel : sous la géométrie qu'affichent les visionneuses vit une couche d'information bien plus riche (propriétés des ouvrages, matériaux, relations entre éléments, hiérarchie spatiale) qui, elle, reste presque toujours enfermée dans le fichier. La plupart des outils du marché n'en lisent qu'une fraction : la forme.

Cet article démystifie ce qu'un .ifc contient réellement et pourquoi cette donnée vous est aujourd'hui presque inaccessible.

Un fichier IFC, c'est quoi exactement ?

L'IFC est un format de données ouvert et normalisé (ISO 16739), développé par buildingSMART pour permettre l'échange de maquettes numériques entre logiciels : c'est le pilier de l'openBIM. Là où un fichier natif (Revit, ArchiCAD, Tekla…) est propriétaire et lié à son éditeur, l'IFC est un format pivot : neutre, lisible par n'importe quel outil compatible, conçu pour survivre aux logiciels qui l'ont produit.

Concrètement, on rencontre l'IFC sous trois formes :

• .ifc : le format texte (basé sur la norme STEP). C'est un fichier lisible, où chaque ligne décrit un objet et ses liens.
• .ifcXML : la même information au format XML.
• .ifcZIP : une version compressée des deux précédents.

Le point clé : un IFC ne décrit pas de pixels ni de traits, mais des objets métier (un mur, une poutre, une porte, un espace, ...), chacun porteur de ses propres caractéristiques. C'est là toute la différence avec un export 3D classique.

Que contient réellement un fichier IFC ?

On peut voir un IFC comme quatre couches d'information superposées.

La hierarchie spatiale

Tout IFC s'organise en arborescence : un projet contient un ou plusieurs sites, qui contiennent des bâtiments, eux-mêmes découpés en niveaux, eux-mêmes en espaces. Cette structure permet de répondre à des questions comme « quels sont tous les ouvrages du deuxième étage ? », à condition de pouvoir l'interroger.

Les objets

Chaque élément du bâtiment est une entité typée : un mur est un IfcWall, une poutre un IfcBeam, un poteau un IfcColumn, ... Le fichier ne dit pas seulement « il y a une forme ici », il dit « ceci est un mur ». C'est une information sémantique, pas géométrique.

Les propriétés

C'est le cœur souvent ignoré. Chaque objet porte des jeux de propriétés (Psets) : un mur connaît son épaisseur, son matériau, sa résistance au feu, sa fonction (porteur / cloison). On y trouve aussi des quantités (surfaces, volumes, longueurs) et des classifications (Uniclass, références CCTP, codes internes). Toute cette donnée descriptive vit dans le fichier.

Les relations

L'IFC encode aussi des relations entre objets : agrégation (un mur composé de plusieurs couches), connexion (une poutre qui s'appuie sur un poteau), appartenance (un équipement rattaché à un local). Cette topologie (qui est lié à quoi) est précisément ce qui distingue une maquette d'un simple dessin.

Géométrie n'est pas information : le malentendu des visionneuses

Ouvrez un IFC dans une visionneuse classique : vous voyez un bâtiment en 3D, vous tournez autour, vous cliquez sur un mur. Impeccable. Mais cette expérience entretient un malentendu : vous regardez la géométrie, pas la donnée.

La forme 3D n'est qu'une des couches du fichier : la plus visible, la plus simple à afficher. Les propriétés, les quantités, les relations, la classification : tout cela existe, mais reste tapi sous la surface. Une visionneuse vous montre à quoi ressemble le bâtiment ; il ne vous dit pas, sans clics laborieux, toutes les portes coupe-feu 30mn du second étage.

L'information est là. Elle n'est simplement pas exploitable.

Pourquoi vos outils n'en exploitent qu'une fraction

Trois familles d'outils cohabitent dans un bureau d'études, et aucune ne tire pleinement parti de l'IFC :

1. Les modeleurs (Revit, ArchiCAD, Tekla) produisent la donnée, mais chacun dans son monde. Dès l'export en IFC, une partie de la richesse des données natives est simplifiée ou perdue en fonction de la qualité de la conversion des données.
2. Les visionneuses affichent la géométrie et permettent quelques clics sur les propriétés, mais une par une, élément par élément. Impossible d'interroger l'ensemble.
3. Les outils documentaires (GED, moteurs de recherche internes) ignorent purement et simplement le contenu d'un IFC. Pour eux, un .ifc est un fichier binaire opaque, indexé tout au plus par son nom. La donnée technique reste totalement hors de portée de la recherche.

Résultat : une maquette qui a coûté des centaines d'heures à produire devient, une fois livrée, un objet qu'on regarde mais qu'on n'interroge pas. L'information de l'entreprise, celle qui prouve un fait dans un litige, qui accélère une vérification, qui capitalise un savoir, dort dans des fichiers que personne ne sait fouiller.

Le même angle mort se retrouve du côté des outils de recherche documentaire. Nous détaillons pourquoi ils ne sont pas adaptés aux bureaux d'études dans cet article.

Interopérabilité : pourquoi l'IFC ne suffit pas

L'IFC devait résoudre l'interopérabilité. En théorie, c'est le cas : n'importe quel logiciel conforme peut lire n'importe quel IFC. En pratique, « lire » ne veut pas dire « exploiter ».

Deux limites reviennent sans cesse :

• La qualité d'export varie énormément. Selon le logiciel d'origine et le paramétrage, un même bâtiment génère des IFC plus ou moins complets : des propriétés manquantes, des classifications absentes, des relations approximatives.
• L'ouverture du format ne donne pas l'accès à la donnée. Avoir un fichier ouvert et savoir en extraire l'information utile sont deux problèmes distincts. Le second demande de parcourir la structure du fichier (la hiérarchie, les entités, les Psets, les relations) et de la transformer en quelque chose d'interrogeable.

Autrement dit : l'IFC a résolu le problème de l'échange. Il n'a pas résolu celui de l'exploitation.

Vers l'exploitation réelle de la donnée technique

C'est précisément là que se joue la prochaine étape. Un fichier IFC contient déjà la réponse à la plupart des questions qu'un ingénieur se pose au quotidien : où sont les portes coupe-feu **? quelle est l'épaisseur de ce mur porteur ? quels équipements dépendent de ce local ? Le défi n'est pas de produire plus de données (elles existent), mais de les rendre accessibles, croisées avec le reste des documents du projet (CCTP, plans, mails de chantier) et interrogeables en langage naturel.

Imaginez interroger une maquette comme on interroge un collègue : « donne-moi tous les murs porteurs modifiés d'une version du plan à la suivante ». La topologie, la géométrie et les propriétés sont déjà dans le fichier pour y répondre. Il manque la couche qui transforme cette base de données figée en mémoire vivante et consultable.

Rendre cette base de données interrogeable en langage naturel, c'est précisément ce que permet l'IA générative appliquée aux bureaux d'études. Nous détaillons son impact sur la lecture des plans IFC et l'analyse des CCTP dans cet article.

C'est la conviction qui guide BatiSearch : la donnée technique du bâtiment ne doit plus rester prisonnière d'un viewer. Exploiter l'IFC pour ce qu'il est réellement, une base de connaissances, change la façon dont un bureau d'études recherche, vérifie et prouve.