Le terme BIM est souvent illustré par un bâtiment : niveaux superposés, pièces, murs, portes, réseaux techniques et maquette fédérée autour d’un point de projet. Cette représentation devient insuffisante dès que l’on travaille sur une route, une ligne ferroviaire, un tunnel ou un système d’ouvrages répartis sur plusieurs kilomètres.
Sur une infrastructure, la question centrale n’est plus uniquement « où est cet objet dans le bâtiment ? », mais souvent « où est-il par rapport à l’axe, au point kilométrique, au profil en long, au terrain, à une emprise et à un système de coordonnées réel ? ». Cette différence change profondément la manière de modéliser, de coordonner et d’échanger les informations.
1. Pourquoi une infrastructure n’est pas simplement un grand bâtiment
Un bâtiment est généralement organisé autour de niveaux, de zones et d’un repère local relativement compact. Une infrastructure linéaire peut traverser plusieurs communes, systèmes fonciers, ouvrages, zones géotechniques et phases de travaux. Les distances rendent immédiatement visibles les erreurs de coordonnées qui passeraient parfois inaperçues sur un petit projet.
La structure spatiale elle-même change. Pour une ligne ferroviaire ou une route, on raisonne en tronçons, axes, PK, gares, ouvrages d’art, zones techniques, emprises, plateformes, terrassements et réseaux longitudinaux. Les équipes ont besoin d’une lecture qui reste cohérente à la fois avec le SIG, les études de tracé, les maquettes 3D et les documents d’exécution.
La performance du workflow dépend donc beaucoup de la qualité du référentiel géographique et des identifiants. Un modèle très détaillé mais positionné avec un décalage de 30 centimètres ou rattaché au mauvais système de coordonnées devient inutilisable pour la fédération.
2. Le géoréférencement est une donnée de projet, pas un réglage logiciel
Sur une infrastructure, je traite le système de coordonnées comme une exigence d’information à part entière. Il faut définir le système de référence, les unités, le référentiel altimétrique, les transformations éventuelles, le point d’origine utilisé dans chaque logiciel et la procédure de contrôle.
Une erreur classique consiste à supposer que tous les logiciels comprennent automatiquement les mêmes coordonnées parce qu’ils affichent des nombres similaires. Or les applications peuvent combiner systèmes projetés, coordonnées locales, faux origines, rotations de projet et transformations internes. La validation doit donc passer par des points de contrôle connus.
Le test minimal est simple : plusieurs points géodésiques ou points de référence sont partagés entre les équipes. Chaque export est vérifié dans un outil indépendant. La fédération n’est acceptée que si la position planimétrique et altimétrique respecte la tolérance définie.
Dans IFC, le géoréférencement peut être porté par les mécanismes du schéma, tandis que les concepts d’alignement permettent ensuite de positionner les objets relativement à un axe. Ce n’est pas une raison pour abandonner le contrôle : l’information géographique n’a de valeur que si l’exporteur et l’importeur l’interprètent de manière cohérente.
3. L’alignement devient une colonne vertébrale du modèle
L’une des avancées majeures d’IFC 4.3 pour les infrastructures est la place donnée à IfcAlignment. buildingSMART définit l’alignement comme un système de référence destiné notamment au positionnement linéaire des routes, voies ferrées, ponts et autres ouvrages linéaires.
IFC 4.3 permet de décrire séparément le tracé horizontal, le profil vertical et, lorsqu’il est pertinent, le dévers ou cant. Cette structure correspond beaucoup mieux à la logique d’un projet d’infrastructure qu’une simple polyline 3D.
La différence est importante. Si l’axe reste seulement une géométrie dessinée, les objets sont positionnés dans un espace global mais sans relation sémantique claire avec le linéaire. Avec un alignement exploitable, un objet peut être décrit par rapport à une position le long de l’axe. On peut alors raisonner en stationnement, PK, distance latérale et relations avec le tracé.
Cette logique facilite aussi les échanges avec des outils de conception civil et des environnements SIG. Elle crée un langage plus cohérent entre la géométrie d’ingénierie et les objets BIM.
4. Ce qu’IFC 4.3 change réellement pour l’infrastructure
IFC 4.3.2.0 est aujourd’hui la dernière version officielle de l’IFC et correspond à ISO 16739-1:2024. Son périmètre officiel étend fortement l’IFC aux infrastructures : routes, railways, bridges, waterways et port facilities sont explicitement intégrés au champ couvert par le standard.
Cette évolution ne se limite pas à ajouter quelques classes d’objets. Elle apporte une meilleure définition des alignements, du positionnement linéaire, des structures spatiales communes aux ouvrages d’infrastructure, des terrassements et de différents éléments spécifiques aux domaines concernés.
Il faut cependant éviter un raccourci : la disponibilité du schéma ne signifie pas que tous les logiciels implémentent déjà l’ensemble d’IFC 4.3 avec le même niveau de maturité. buildingSMART prévoit plusieurs niveaux de mise en œuvre, notamment Reference View, Alignment Based View et Design Transfer View. Une équipe doit donc vérifier ce que son outil exporte réellement et ce que l’outil destinataire sait relire.
Autodesk illustre bien cette différence dans Civil 3D. Sa documentation 2026 distingue l’export IFC historique — qui ne supporte pas les objets d’infrastructure Civil 3D — et l’extension IFC 4x3, qui prend en charge des objets infrastructure, le point de base et les Property Sets. Ce type d’écart d’implémentation doit être identifié avant de contractualiser un échange.
5. Et les tunnels ? Une nuance importante
Les tunnels sont naturellement présents dans de nombreux projets d’infrastructure et dans les travaux de buildingSMART. Pourtant, le domaine Tunnel n’est pas encore un domaine dédié intégré au schéma officiel IFC 4.3.2. La documentation buildingSMART actuelle le signale explicitement : le domaine tunnel est visé par des développements futurs.
Cela ne signifie pas qu’un tunnel ne peut pas être échangé en IFC. Une grande partie de ses composants peut être décrite à l’aide des concepts communs du schéma : spatialisation, alignements, éléments de construction, systèmes techniques, propriétés, géométrie et relations. Mais il faut être prudent avant d’annoncer qu’un workflow « IFC Tunnel 4.3 » est totalement normalisé.
Sur un projet de tunnel, je recommande donc de documenter précisément le mapping retenu : classes IFC utilisées, Property Sets complémentaires, découpage par anneaux ou zones, règles de référencement longitudinal et traitement des équipements. Cette convention devient indispensable pour garantir une lecture identique chez les différents acteurs.
6. Découper le modèle selon les usages, pas selon les habitudes des logiciels
Une infrastructure ne doit généralement pas être livrée sous forme d’une seule maquette géante. Le découpage doit refléter la manière dont le projet est conçu, contrôlé, construit et exploité.
Selon le projet, on peut structurer les conteneurs par tronçon, zone géographique, ouvrage, lot technique, discipline, phase ou combinaison de ces critères. Une ligne de métro peut par exemple distinguer les gares, puits, ouvrages annexes, tunnels interstations, systèmes voie, énergie et ventilation.
Le piège consiste à multiplier les fichiers sans stratégie d’identification. Chaque découpage doit préserver la continuité des coordonnées, la référence à l’alignement et les identifiants des objets. Sinon, la fédération devient un assemblage manuel fragile.
Comme pour le management de l’information BIM, la question utile reste : qui produit cette information, qui la consomme, dans quel conteneur et avec quel identifiant ?
7. La fédération d’une infrastructure pose des problèmes particuliers
La coordination d’un bâtiment consiste souvent à superposer architecture, structure et MEP. Sur une infrastructure, la fédération ajoute le terrain, les nuages de points, les ouvrages existants, les réseaux enterrés, les emprises foncières, les données SIG, les terrassements, les ouvrages d’art et parfois plusieurs dizaines de kilomètres de tracé.
La performance devient un sujet à part entière. Une fédération exhaustive avec tous les objets au niveau de détail maximal est rarement pertinente pour chaque réunion de coordination. Il faut créer des vues et sous-ensembles adaptés aux usages : coordination d’une gare, contrôle d’un franchissement, analyse d’un réseau ou revue d’un tronçon donné.
Les règles de clash doivent également être adaptées. Un moteur de collision brut peut générer des milliers de résultats liés au terrain, aux objets temporaires ou à des tolérances de conception normales. Comme expliqué dans l’article sur la collaboration BIM, le nombre de clashes n’est pas un KPI de qualité. Le bon indicateur est la capacité à détecter et résoudre les conflits significatifs.
8. BIM et SIG : deux référentiels complémentaires
Les infrastructures se trouvent au croisement du BIM et du SIG. Le BIM décrit finement les objets construits, leurs propriétés et leurs relations. Le SIG est particulièrement performant pour replacer ces objets dans un territoire, croiser de grandes étendues géographiques et gérer des couches thématiques.
Vouloir tout faire entrer dans un seul environnement est rarement efficace. Un corridor routier, un ouvrage d’art, une parcelle foncière, une zone environnementale et une canalisation ne nécessitent pas le même niveau de détail ni le même outil.
Le vrai enjeu est donc l’interopérabilité des identifiants, des coordonnées et des classifications. Une donnée BIM doit pouvoir être rattachée à une position et, lorsqu’un usage le nécessite, à un objet ou une couche du système géospatial.
Cette articulation devient particulièrement importante en exploitation, lorsque les équipes patrimoniales ont besoin d’une vision territoriale du réseau plutôt que d’ouvrir les modèles de conception un par un.
9. Exemple de workflow sur un projet ferroviaire
Imaginons un tronçon comprenant plateforme, voies, drainage, signalisation, caténaire, ouvrages d’art et réseaux tiers. Le projet définit d’abord un système de coordonnées unique et plusieurs axes de référence. Chaque équipe dispose d’un périmètre clair et d’une convention de nommage commune.
Les modèles sont produits dans leurs outils métiers. Les objets portent au minimum un identifiant, un tronçon, une discipline, une zone, une classification et, lorsque pertinent, une référence linéaire. Les échanges IFC sont testés très tôt sur un échantillon avant d’être généralisés.
La fédération est organisée par tronçon. Les contrôles portent sur la position, les enveloppes de sécurité, les conflits physiques, la continuité des réseaux et les données obligatoires. Les issues sont suivies dans un workflow BCF ou équivalent plutôt que dans un tableau déconnecté des objets.
À chaque jalon, une recette IFC vérifie les classes, Property Sets, coordonnées et identifiants. Les informations utiles à l’exploitation sont progressivement consolidées afin d’éviter de recréer un patrimoine numérique en fin de chantier.
10. Les contrôles qualité que je considère indispensables
Sur une infrastructure, je sépare au minimum cinq familles de contrôles. D’abord le positionnement : système de coordonnées, altitude, rotation et points de contrôle. Ensuite la structure : tronçons, zones, ouvrages et conteneurs. Puis la sémantique : classes IFC, types, classifications et Property Sets. Viennent ensuite la coordination géométrique et, enfin, les exigences d’exploitation.
Les alignements doivent eux aussi être contrôlés. Un axe manquant, dupliqué ou interprété différemment dans deux outils peut contaminer de nombreux objets associés. La validation de l’axe doit donc précéder la validation massive des objets positionnés relativement à lui.
Cette logique est particulièrement adaptée à l’automatisation. Les vérifications de coordonnées, classes, attributs, valeurs autorisées, identifiants et appartenance à un tronçon peuvent être réalisées à grande échelle, à condition que les règles aient été définies correctement.
11. L’infrastructure amplifie l’intérêt du BIM patrimonial
Un réseau ferroviaire, une route ou un ensemble d’ouvrages d’art est exploité pendant plusieurs décennies. L’information utile ne se limite donc pas au DOE. Les gestionnaires doivent suivre les actifs, inspections, remplacements, interventions, restrictions et évolutions du réseau.
Le principe décrit dans l’article sur le BIM GEM s’applique ici avec encore plus de force : il faut identifier les actifs réellement maintenables et définir leurs données avant la réception.
Un équipement de signalisation, une section de voie, un appareil d’appui ou un dispositif de drainage doit pouvoir être retrouvé dans le système patrimonial sans dépendre du nom que lui avait donné un modeleur cinq ans plus tôt. La stabilité des identifiants devient donc un enjeu majeur.
12. Les limites actuelles de l’openBIM infrastructure
IFC 4.3 représente une avancée majeure, mais les implémentations sont encore hétérogènes. Certaines applications exportent correctement les alignements mais moins bien certains objets métiers ; d’autres lisent les géométries sans reprendre toute la sémantique. Les certifications et MVD progressent, mais un projet ne doit pas supposer une interopérabilité parfaite.
Il faut également garder en tête l’évolution du standard. buildingSMART travaille sur IFC 4.4 et sur la prochaine génération IFCX/IFC 5. Ce sont des travaux en cours ; ils ne doivent pas être cités comme remplaçants de la version officielle IFC 4.3.2.0 aujourd’hui.
La bonne pratique reste donc pragmatique : choisir une version contractuelle, définir le périmètre d’échange, tester les outils réellement utilisés et conserver des jeux de fichiers de référence permettant de contrôler les régressions.
13. Mes bonnes pratiques pour un projet infrastructure
Je commence par verrouiller le référentiel géographique et les alignements avant de multiplier les modèles. Je définis ensuite un découpage stable du projet et un système d’identifiants qui traverse les logiciels. Les exigences IFC sont testées sur un petit échantillon, puis automatisées lorsque le workflow est maîtrisé.
Je sépare également les modèles de production des modèles de coordination. Une maquette utile à un calcul de terrassement n’a pas nécessairement besoin d’être chargée intégralement dans chaque revue de coordination. Enfin, je traite la donnée d’exploitation comme un flux progressif, pas comme un livrable à produire à la fin.
Cette approche paraît moins spectaculaire qu’une fédération géante de plusieurs kilomètres. Mais elle produit des informations beaucoup plus robustes, et c’est précisément ce qui compte lorsqu’un projet doit être repris par des dizaines d’équipes pendant plusieurs années.
Conclusion : sur une infrastructure, la donnée de position est une donnée métier
Le BIM infrastructure devient réellement utile lorsqu’il sait relier les objets à leur territoire, leur alignement, leur tronçon et leurs usages. IFC 4.3 apporte aujourd’hui une base openBIM beaucoup plus crédible pour les routes, le rail, les ponts, les voies navigables et les ports. Mais le standard ne dispense pas de définir un protocole de géoréférencement, des règles de découpage, des identifiants et une recette d’échange.
Sur ces projets, la maîtrise de l’information n’est pas une couche administrative ajoutée à la conception. Elle constitue le mécanisme qui permet à plusieurs kilomètres de modèles, de données et d’actifs de rester cohérents entre eux.
Sources techniques
buildingSMART International — Industry Foundation Classes
buildingSMART — IFC 4.3.2 Scope
buildingSMART — IfcAlignment
buildingSMART — IFC 4.3 Model View Definitions
Autodesk — IFC 4x3 Extension for Civil 3D