IDS : spécifications de livraison d'information pour un projet BIM

L'IDS (Information Delivery Specification) est un format de fichier et un standard openBIM développé par buildingSMART. Les fichiers IDS permettent de définir les exigences d’information d’un projet BIM et d’établir des processus de validation automatique des données dans les modèles IFC.

Interface de BIMcollab Nexus pour créer facilement un IDS (fichier XML avec l’extension .ids)

L'émergence d'un standard nécessaire aux échanges d'informations

L’Information Delivery Specification (IDS) représente une révolution dans la formalisation des exigences d’échange d’informations. Officialisé le 4 juin 2024 en version 1.0, ce standard introduit une approche structurée et automatisée afin de définir puis valider les données requises dans les modèles. En effet, contrairement aux spécifications traditionnelles souvent ambiguës, l’IDS établit un langage commun, compréhensible par l’être humain tout en étant interprétable par les systèmes informatiques, ce qui garantit une uniformité d’application et une vérification objective des conformités.

L’IDS s’inscrit dans la continuité des normes et standards openBIM existants, notamment : l’IFC (Industry Foundation Classes) et le BCF (BIM Collaboration Format).

En s’appuyant sur une architecture XML rigoureuse et une intégration native dans l’écosystème OpenBIM, IDS transforme les spécifications descriptives en contraintes techniques exécutables, ouvrant ainsi la voie à une automatisation intelligente des processus de validation.

Comprendre le XML et son rôle

Le XML (eXtensible Markup Language) constitue un langage de balisage standardisé par le W3C (World Wide Web Consortium) depuis 1998. Ce langage est conçu pour structurer, stocker et transporter des informations de manière lisible à la fois par un être humain et par un ordinateur. Contrairement au HTML qui se concentre sur la présentation des données, le XML se focalise sur leur description sémantique et leur structure hiérarchique. Dans le contexte du BIM et particulièrement de l’IDS, le XML offre plusieurs avantages déterminants :

Le principe de fonctionnement du XML repose sur une structure arborescente d’éléments imbriqués, où chaque élément peut contenir des attributs, du texte ou d’autres éléments. Cette hiérarchisation naturelle s’aligne parfaitement avec la structure des modèles BIM : où les bâtiments contiennent des étages, qui contiennent des espaces, qui contiennent des équipements.

Les balises XML, définies par l’utilisateur, permettent de créer un vocabulaire métier précis : <specification>, <applicability>, <requirements> deviennent ainsi des concepts directement compréhensibles dans le contexte IDS BIM. De plus, l’utilisation d’espaces de noms (namespaces) évite les conflits de dénomination et permet l’intégration de multiples standards dans un même document, facilitant ainsi l’intégration à l’écosystème openBIM. Nous préciserons ces concepts plus loin dans l’article.

Architecture technique et schéma XSD de l'IDS

L’architecture de l’IDS repose sur un schéma XSD (XML Schema Definition) disponible à l’adresse : https://standards.buildingsmart.org/IDS/1.0/ids.xsd. Ce schéma définit une structure hiérarchique rigoureuse utilisant le namespace http://standards.buildingsmart.org/IDS

Qu'est-ce qu'un schéma XSD (XML Schema Definition) ?

Un schéma XSD est comme un « cahier des charges technique » pour les documents XML. Il définit la structure, le contenu et les types de données qu’un fichier XML doit respecter pour être considéré comme valide. Si nous faisons une analogie rapide avec un projet de construction :

Qu'est-ce qu'un namespace XML ?

Les namespaces XML résolvent un problème fondamental : garantir l’unicité des noms d’éléments lorsqu’on combine différents schémas XML. Par exemple, prenons deux schémas distincts définissant chacun un élément <description>. Le premier schéma S1 l’utilise pour décrire un produit commercial, tandis que le schéma S2 l’emploie pour une description médicale. Sans mécanisme de différenciation, fusionner ces schémas créerait un conflit. Le namespace associe donc une URI (Uniform Resource Identifier) unique à chaque schéma, transformant <description> en deux éléments distincts : http://commerce.com/S1:description et http://medical.org/S2:description.

Utilisation des préfixes

Cette notation complète étant fastidieuse, XML permet d’associer des préfixes courts aux namespaces. La correspondance préfixe-namespace se déclare dans le document XML lui-même. Ainsi, on peut écrire com:description et med:description après avoir établi les associations correspondantes.

Syntaxe et namespace par défaut

Dans l’exemple ci-dessus, le namespace par défaut (déclaré avec xmlns sans préfixe) s’applique automatiquement aux éléments non préfixés, simplifiant ainsi l’écriture lorsqu’un vocabulaire prédomine.

La déclaration du namespace dans les fichiers IDS suit une syntaxe XML classique :

Cette déclaration établit des éléments cruciaux : le namespace par défaut pour tous les éléments IDS, les références aux schémas XML standards du W3C, et le lien vers le schéma XSD de validation spécifique à l’IDS.

Ainsi, le mécanisme de namespace permet à l’IDS de coexister avec d’autres schémas XML de l’écosystème buildingSMART et au-delà :

Modularité fonctionnelle des spécifications IDS

En plus de sa configuration basée sur XML, l’IDS démontre son efficacité à travers l’agencement soigné de ses différents éléments fonctionnels. Chaque fichier au sein du système IDS a la capacité d’incorporer plusieurs spécifications, chacune dotée d’une identification unique et accompagnée de documents qui retracent leur provenance et leur finalité. Cette approche modulaire facilite le regroupement d’exigences relatives tout en préservant leur autonomie logique.

Un fichier IDS suit une architecture XML en couches successives :

Ainsi, un seul fichier XML (extension .ids) peut inclure plusieurs spécifications indépendantes

Imaginez un classeur Excel avec plusieurs onglets. Chaque onglet (spécification) traite d’un aspect différent du projet, mais ils sont regroupés dans le même fichier pour faciliter la gestion. Par exemple, un fichier IDS « Exigences_Thermiques_Projet.ids » pourrait contenir :

Chaque spécification possède plusieurs attributs d'identification :

name : Nom technique de la spécification
ifcVersion: Définit la version du schéma IFC pour laquelle la spécification est valide.
identifier : Code unique pour la traçabilité (souvent lié à un système de gestion des exigences)
description : Explication détaillée de l’objectif
instructions : Contexte d’application ou notes pour l’utilisateur

Avantages de l'approche modulaire pour la gestion de projets BIM

Activation/désactivation sélective de certaines spécifications selon les phases projet
Possibilité d'exécuter uniquement les contrôles pertinents pour un corps d'état
Mise à jour d'une spécification sans impacter les autres
Les spécifications peuvent être copiées entre projets
Constitution de bibliothèques de spécifications standards dans les organisations (exemple : une entreprise)

Les principes d'applicabilité et d'exigences

Chaque spécification IDS suit une logique binaire rigoureuse articulée autour de deux composants complémentaires. L’applicabilité (<applicability>) définit le périmètre d’intervention en identifiant précisément les objets concernés par la vérification. Les exigences (<requirements>) spécifient ensuite les informations que doivent porter ces objets pour satisfaire aux critères de conformité.

Contrôle quantitatif avec minOccurs et maxOccurs

Les paramètres minOccurs et maxOccurs définissent le nombre d’objets BIM qui doivent satisfaire à une spécification. Par exemple, exactement deux issues de secours doivent être présentes :

Contrôle qualitatif avec l'attribut cardinality

L’attribut cardinality offre trois modalités qualitatives pour les requirements (exigences) :

1 - Required (obligatoire) - L'information DOIT exister :

2. Optional (facultatif) - L'information PEUT exister :

3. Prohibited (interdit) - L'information NE DOIT PAS exister :

Cette granularité permet de modéliser des exigences complexes avec une précision chirurgicale, depuis les validations simples jusqu’aux règles métier sophistiquées combinant plusieurs niveaux de contrôle dans un même flux de travail.

Les six types de facettes dans IDS 1.0

Le standard définit six types de facettes afin de spécifier les exigences d’information, EIR (Exchange Information Requirements, selon la norme ISO 19650) :

Entity Facet : constitue le socle en identifiant les types d'entités IFC (comme IFCWALL, IFCDOOR) et leurs types prédéfinis selon le schéma IFC. Cette facette est généralement utilisée dans la partie applicabilité pour cibler les objets concernés.
Property Facet : exploite les PropertySets et QuantitySets avec des paramètres obligatoires (propertySet, baseName) et optionnels (value, dataType). Elle permet de valider aussi bien l'existence d'une propriété que sa valeur, offrant une flexibilité remarquable pour les contrôles de conformité.
Attribute Facet : cible les attributs directs des entités IFC tels que Name, Description, ou GlobalId (attributs par héritage de IfcRoot). Cette facette s'avère particulièrement utile pour valider les conventions de nommage ou vérifier la présence d'informations descriptives essentielles.
Classification Facet : gère l'intégration avec les systèmes de classification externes (Uniclass, OmniClass, etc.) en utilisant des références URI vers le buildingSMART Data Dictionary (bSDD). Cette approche standardisée garantit l'interopérabilité entre différents systèmes de classification.
Material Facet : contrôle les matériaux associés aux éléments, permettant de vérifier leur présence et leurs caractéristiques.
PartOf Facet : gère les relations spatiales et de compositions

Comprendre les types de données supportés dans les IDS

Les IDS doivent gérer une dualité importante :

La bonne gestion de cette dualité offre le meilleur des deux mondes : rigueur technique pour l’interopérabilité IFC et flexibilité pour l’adoption par différents outils et contextes d’usage.

Les types IFC Natifs :

Ces types proviennent directement du schéma IFC et correspondent aux types de données définis dans la norme ISO 16739. Voici des exemples de types de données issues du schéma IFC :

IfcLabel

Nature : Chaîne de caractères (texte)
Longueur max : 255 caractères selon le schéma IFC
Usage typique : Noms, descriptions, identifiants textuels

IfcBoolean

Nature : Valeur logique vraie/fausse
Représentation : « true » ou « false » (ou parfois « .T. » et « .F. » en notation STEP)
Usage typique : Propriétés binaires comme IsExternal, LoadBearing

IfcReal

Nature : Nombre décimal (virgule flottante)
Précision : Double précision selon IEEE
Usage typique : Dimensions, coefficients thermiques, surfaces

Les types génériques :

Ces types sont plus universels et permettent une approche plus flexible, surtout pour les outils qui ne sont pas strictement IFC.

String

Équivalent IFC : IfcLabel, IfcText
Différence avec IfcLabel : Peut dépasser 255 caractères
Validation possible : Patterns regex

Boolean

Équivalent IFC : IfcBoolean
Représentation XML : « true » ou « false » uniquement
Plus strict : Pas de notation STEP acceptée

Integer

Équivalent IFC : IfcInteger
Nature : Nombre entier sans décimales
Usage : Comptage, indices, numéros d’étage

Real

Équivalent IFC : IfcReal
Flexibilité : Accepte différents formats de notation

URI (Uniform Resource Identifier)

Spécificité : Type spécial pour les références externes
Usage principal : Liens vers le buildingSMART Data Dictionary (bSDD)

Règle de décision simple pour choisir le bon type :

Vous validez une propriété IFC standard ou un attribut ? → Utilisez le type IFC natif correspondant
Vous créez une validation personnalisée ? → Utilisez les types génériques pour plus de flexibilité
Vous référencez une classification externe ? → Utilisez URI

Exemple complet combinant plusieurs types de données :

Les 4 mécanismes de restriction dans les IDS

Ces mécanismes de restriction sont la colonne vertébrale de la validation IDS, permettant un contrôle automatisé et précis de la qualité des données.

1 - ids:simpleValue - Pour les valeurs exactes

C’est le mécanisme le plus direct : vous spécifiez exactement LA valeur attendue, voici le fonctionnement :

Principe : Comparaison stricte d’égalité
Sensible à la casse : « Béton » ≠ « béton »
Espaces comptent : « Béton » ≠ « Béton »

Exemples de cas d’usages :

Valeurs booléennes (true/false)
Codes standardisés de l’entreprise
Types d’objets IFC spécifiques
Valeurs de référence uniques

2 - xs:restriction avec xs:enumeration - Pour les listes de choix

Ce mécanisme définit une liste fermée de valeurs acceptables (comme une liste déroulante).

Principe de fonctionnement :

L’élément DOIT avoir une des valeurs listées
Aucune autre valeur n’est acceptée
Chaque valeur possible est un xs:enumeration séparé

Syntaxe complète :

Avantages de xs:restriction avec xs:enumeration

Contrôle total : Liste exhaustive des valeurs permises
Documentation implicite : La liste elle-même documente les options
Validation stricte : Impossible d’avoir des valeurs inattendues

3 - ids:bounds - Pour les plages de valeurs numériques

Ce mécanisme définit des intervalles acceptables pour les valeurs numériques.

Liste des attributs disponibles :

Exemple pratique : coefficient thermique (U) des murs

4 - Patterns regex - Pour les formats de texte complexes

Les patterns utilisent les expressions régulières (regex) du standard XML Schema afin de valider des formats complexes de texte.

Arbre de décision, quel mécanisme utiliser ?

C’est une valeur unique fixe ? → ids:simpleValue
C’est un choix parmi plusieurs options définies ? → xs:enumeration
C’est une plage numérique ? → ids:bounds
C’est un format de texte à respecter ? → xs:pattern (regex)

Les bénéfices de l'IDS dans les projets BIM

L’adoption de l’IDS entraîne une modification radicale de la gestion des exigences BIM. En convertissant les spécifications ambiguës en contraintes techniques exécutables via XML, ce standard permet une plus grande automatisation dans le flux de travail dédié à la validation des modèles IFC. Les bénéfices sont immédiats : réduction des non-conformités tardives, contrôles qualité automatisés, et constitution de bibliothèques de spécifications réutilisables.

L’architecture modulaire de l’IDS, avec ses mécanismes de restriction précis et ses six types de facettes, offre une flexibilité remarquable pour adapter les validations aux besoins métiers spécifiques. Les maîtres d’ouvrage disposent d’un outil objectif de vérification des livrables numériques, tandis que les équipes projet bénéficient d’un cadre clair dès la conception.

Ainsi, cette standardisation renforce la confiance dans les informations échangées et réduit considérablement les risques contractuels.