Pour beaucoup d’utilisateurs, un fichier IFC (Industry Foundation Classes) reste une maquette 3D. Cette lecture est réductrice. Un IFC est avant tout une base de données structurée, conçue pour organiser l’information et la rendre exploitable dans des processus industriels. L’exemple officiel E.4.8 – Reinforcing Assembly de buildingSMART permet de dépasser cette vision. En analysant directement le script IFC, on comprend comment le ferraillage est modélisé non pas comme une géométrie, mais comme un système constructif structuré, optimisé et reproductible.
Une logique d’assemblage explicite
La première information clé ne se situe pas dans la géométrie, mais dans les relations entre objets. Le script met en place une hiérarchie claire entre la poutre, la cage d’armatures et les barres. La poutre est définie comme un IfcBeam. Elle contient un IfcElementAssembly, classé en REINFORCEMENT_UNIT, qui regroupe l’ensemble des armatures. Les barres individuelles (IfcReinforcingBar) sont ensuite agrégées à cet ensemble via des relations IfcRelAggregates.
Cette structuration n’est pas anecdotique. Elle traduit une logique métier, le ferraillage est traité comme une unité cohérente. Pour les usages en exécution ou en préfabrication, cela signifie que l’on manipule un objet unique, et non une liste dispersée d’éléments.
Le mapping une approche orientée performance
L’optimisation du modèle repose sur un principe central du script, la représentation mappée. La géométrie d’un étrier est définie une seule fois à l’aide d’un IfcRepresentationMap. Chaque occurrence dans le modèle est ensuite générée via un IfcMappedItem, qui ne contient qu’une transformation (position, orientation, éventuellement échelle). Ce mécanisme est répété pour toutes les barres. On ne redéfinit jamais la géométrie complète.
L’intérêt est immédiat. La taille du fichier est fortement réduite, la duplication d’information est évitée et les performances restent stables même lorsque le nombre d’éléments augmente. Cette logique est indispensable dès que l’on travaille sur des ouvrages comportant des centaines ou des milliers d’armatures.
Une géométrie fidèle aux contraintes de fabrication
Le script ne se contente pas de produire une forme visuelle correcte. Il reproduit le comportement réel de la barre d’acier. La trajectoire de l’étrier est définie par une IfcIndexedPolyCurve. Cette entité s’appuie sur une liste de points indexés et permet de combiner segments droits et arcs de cercle. On obtient ainsi une description précise du cintrage, comparable à celui réalisé en atelier. Le volume est ensuite généré par un IfcSweptDiskSolid. Un disque, correspondant au diamètre de la barre, est balayé le long de la directrice. Cette méthode garantit que la section reste constante et toujours perpendiculaire à la trajectoire.
Ce choix n’est pas neutre. Il conditionne la qualité des analyses en aval, notamment pour la détection de collisions ou les processus de fabrication automatisée.
Type et occurrence, une séparation structurante
Le modèle distingue clairement la définition des propriétés et leur instanciation. Les caractéristiques des barres sont portées par un IfcReinforcingBarType. On y trouve le diamètre, la section, ou encore les paramètres généraux de l’armature. Les barres présentes dans la maquette sont des occurrences (IfcReinforcingBar) qui héritent de ce type via une relation IfcRelDefinesByType.
Cette organisation permet d’éviter toute redondance. Une modification du type se propage instantanément à l’ensemble des occurrences. On garantit ainsi la cohérence des données à l’échelle du projet.
Un positionnement paramétrique des armatures
Le positionnement des étriers repose sur des transformations géométriques simples mais systématiques. Chaque occurrence est définie par une position (IfcCartesianPoint) et une transformation (IfcCartesianTransformationOperator3D). Les coordonnées présentes dans le script montrent un espacement régulier le long de la poutre, de l’ordre de 150 mm. Le modèle ne décrit pas un placement manuel, mais une logique répétitive et maîtrisée.
Cette approche permet de conserver une structure paramétrique implicite, même dans un format d’échange.
Une complexité maîtrisée
Un point souvent négligé apparaît clairement dans cet exemple. La poutre elle-même est modélisée de manière simple, à l’aide d’une extrusion (IfcExtrudedAreaSolid). À l’inverse, le ferraillage mobilise des concepts avancés comme le mapping, les polycourbes indexées et les solides balayés.
Ce contraste n’est pas un hasard. Il reflète une hiérarchie technique, la complexité est concentrée sur les éléments qui en ont réellement besoin.
Bref !
L’exemple E.4.8 montre que l’IFC 4.3 ne doit pas être abordé comme un simple format géométrique. Il s’agit d’un modèle de données structuré, conçu pour décrire des systèmes constructifs de manière cohérente et exploitable. Le ferraillage y est défini comme un assemblage, optimisé par le mapping, décrit avec une géométrie fidèle à la fabrication et piloté par une logique de typage. Cette combinaison permet de passer d’une représentation graphique à un modèle réellement utilisable dans des processus industriels.
La maîtrise de l’IFC ne repose donc pas sur la capacité à produire des formes, mais sur la compréhension de leur organisation.
Référence technique
Documentation buildingSMART International – IFC 4.3, Annexe E, exemple E.4.8 (Reinforcing Assembly)
