Comprendre IDS 1.0 — ce qu'est le standard et à quoi ressemble une première règle

Dans la plupart des projets BIM, le cahier des charges est un document Word. Trois à cinquante pages qui précisent quels éléments doivent être livrés, quelles propriétés doivent être renseignées, quelles classifications nous utilisons. Écrit pour des humains, vérifié à l'écran. Cela fonctionne tant que la personne qui contrôle reste concentrée. Mais quiconque a déjà contrôlé quatre livraisons IFC d'affilée par rapport à un tel document le sait : à partir du troisième fichier, le regard commence à dériver.

La question n'est pas de savoir si le cahier des charges est faux. La question est de savoir comment le rendre lisible par la machine. Pour cela il existe, depuis 2024, un standard ouvert : l'Information Delivery Specification, en abrégé IDS. Dans ce billet, j'explique ce que fait IDS, comment un fichier IDS est structuré et à quoi ressemble une première règle concrète.

Ce que fait IDS

IDS est un langage XML qui permet d'écrire des exigences BIM de telle sorte qu'un logiciel puisse les contrôler automatiquement. Il est standardisé par buildingSMART International. La version 1.0 a été approuvée comme standard final le 4 juin 2024. L'utiliser aujourd'hui n'est plus une démarche de pionnier.

Trois termes sont fréquemment confondus dans le quotidien BIM. Voici comment les distinguer :

• MVD (Model View Definition) — décrit ce qu'un logiciel doit exporter en IFC. Du point de vue de l'éditeur de logiciel.
• IDM (Information Delivery Manual) — décrit, en termes de processus, qui livre quelle information dans quelle phase. Du point de vue du flux de projet.
• IDS — est le pont lisible par la machine entre l'IDM et l'IFC. Ce qui a été convenu textuellement dans l'IDM, IDS le contrôle techniquement.

Concrètement : un maître d'ouvrage ou un planificateur général qui écrit « tous les murs porteurs doivent avoir une résistance au feu » peut formuler la même phrase en IDS de telle sorte que chaque livraison soit automatiquement contrôlée. Plus personne ne fait défiler le modèle à la main.

Comment un fichier IDS est structuré

Au cœur, un fichier IDS est du XML. Pas joli à lire, mais stable à traiter. Il se compose de plusieurs Specifications, et chaque Specification comporte deux parties :

• Applicability — à quels éléments de modèle la règle s'applique. Exemple : tous les IfcWall avec LoadBearing = True.
• Requirements — ce que ces éléments doivent satisfaire. Exemple : une property FireRating doit exister et porter une valeur tirée d'une liste définie.

En version très simplifiée, cela donne en IDS-XML :

<specification name="Murs porteurs — résistance au feu">
  <applicability>
    <entity name="IfcWall" />
    <property propertySet="Pset_WallCommon"
              baseName="LoadBearing" value="True" />
  </applicability>
  <requirements>
    <property propertySet="Pset_WallCommon"
              baseName="FireRating">
      <value>
        <enumeration values="REI30,REI60,REI90,REI120" />
      </value>
    </property>
  </requirements>
</specification>

Pset_WallCommon est un property set défini dans IFC. LoadBearing et FireRating sont des property standard. Si vous utilisez vos propres property ou des property spécifiques au projet, il suffit d'indiquer le property set adapté.

Deux points à retenir :

• IDS contrôle des structures et des valeurs, pas la géométrie. La question « ce mur a-t-il un FireRating ? » se traduit bien. « Ce mur traverse-t-il la fenêtre ? » non. Plus de détails plus bas.
• Les fichiers IDS sont versionnables et partageables. Une bibliothèque IDS bien tenue grandit avec chaque projet. C'est un actif que l'on emporte d'un projet à l'autre.

Une première règle — étape par étape

Exemple : « Les murs porteurs doivent avoir une résistance au feu. » Voici comment cela devient une règle IDS finalisée.

Étape 1 — formuler l'exigence avec précision. Le cahier des charges dit typiquement « Les murs porteurs doivent être marqués avec une résistance au feu ». Pour une règle lisible par la machine, ce n'est pas suffisant. Que signifie « porteur » en termes IFC ? Quelles valeurs sont admises ? Où se trouve la property ? La phrase devient :

Tous les éléments de type IfcWall avec Pset_WallCommon.LoadBearing = True doivent avoir une property Pset_WallCommon.FireRating dont la valeur est dans la liste REI30, REI60, REI90, REI120.

Étape 2 — exprimer la règle en IDS. Cela se fait soit à la main dans un éditeur XML (possible, mais risqué), soit via un éditeur de règles qui génère le XML en arrière-plan. À la fin, on dispose d'un fichier .ids que tout outil conforme peut lire.

Étape 3 — vérifier la règle sur un modèle IFC. Le fichier .ids est chargé en même temps que le fichier .ifc. Un validateur parcourt toutes les instances IfcWall, filtre les porteurs et vérifie que FireRating est présent et dans la plage autorisée. Le résultat : un rapport qui indique, élément par élément, ce qui passe et ce qui ne passe pas — avec justification.

Ce qui prenait des heures de contrôle ponctuel manuel par livraison IFC se règle ainsi en quelques secondes. Et surtout : de manière reproductible à chaque nouvelle livraison.

Ce qu'IDS ne résout pas encore

Aussi utile soit-il, le standard n'est pas universel. Trois choses ne font explicitement pas partie du périmètre d'IDS.

• Contrôles géométriques. Hauteur minimale, distance minimale, largeur de passage de porte — tout ce qui doit être mesuré métriquement n'est pas exprimable en IDS. Cela nécessite des outils dotés de leur propre moteur de géométrie, souvent en combinaison avec un workflow BCF.
• Détection de collisions. La détection de clashes est un sujet voisin mais distinct. IDS ne dit rien des relations spatiales.
• Logique métier croisée. « Un mur avec FireRating REI90 devrait avoir au moins 12 cm d'épaisseur » combine géométrie et propriétés — et sort donc du champ d'IDS 1.0.

Ces lacunes ne sont pas, à mon sens, des défauts du standard, mais une délimitation assumée. IDS est le langage des contrôles d'exigences structurés. Pour le reste, il existe d'autres outils — souvent ceux qui tournent déjà dans la chaîne BIM.

Conclusion

Depuis la sortie de la 1.0, IDS n'est plus un sujet de recherche. Le standard est là, les outils aussi. Le passage du cahier des charges Word à la bibliothèque IDS n'est pas une opération unique, mais un processus graduel. La plupart des projets que j'accompagne démarrent avec dix à quinze règles et grandissent au fur et à mesure de l'expérience.

Pour essayer une première règle, c'est possible directement dans le navigateur sur ifclint.com. Charger un modèle IFC existant, fournir un fichier IDS ou composer une règle dans l'éditeur — et lancer la vérification. Le résultat sort sous forme de rapport BCF, prêt à être transmis aux planificateurs et aux corps de métier.

Pour le contexte sur les questions de qualité sous-jacentes, voir « Pourquoi l'assurance qualité IFC décide du succès ou de l'échec des projets BIM » et « Les 10 erreurs les plus fréquentes dans les modèles IFC ».