Retour au blog BIM & IFC
Validation · 2026-10-01 · 12 min
L'IDS expliqué : comment contrôler un modèle IFC avec une Information Delivery Specification
L'IDS transforme « le modèle doit contenir le degré coupe-feu » d'une phrase dans un PDF en un fichier qu'une machine peut vérifier. Ce que testent vraiment les six facettes, où la plupart des fichiers IDS se trompent, et comment en exécuter un sur votre IFC dans le navigateur.
L'IDS expliqué : comment contrôler un modèle IFC avec une Information Delivery Specification — IFC Viewer Online article cover
Toutes les EIR jamais rédigées contiennent une phrase du genre « toutes les portes devront indiquer leur degré coupe-feu ». Et sur chaque projet, cette phrase est vérifiée de la même manière : quelqu'un ouvre le modèle, clique sur quelques portes et décide que ça doit aller. L'exigence est précise. Le contrôle est une impression.
L'IDS — l'Information Delivery Specification — existe pour combler cet écart. C'est un petit format XML, normalisé par buildingSMART sous le nom d'IDS 1.0, qui exprime les exigences d'information sous une forme testable par une machine. Écrivez l'exigence une fois, remettez le fichier .ids à chaque prestataire, et « ça doit aller » devient « 412 portes sur 418 passent ; voici les six qui échouent ».
L’essentiel
- L'IDS contrôle l'information, pas la géométrie : classes, attributs, propriétés, classifications, matériaux et relations.
- Chaque spécification a deux moitiés : à quels éléments elle s'applique, et ce que ces éléments doivent avoir. La plupart des fichiers IDS défaillants se trompent sur la première.
- Un IDS est une pièce contractuelle. Il se range à côté de la convention BIM (BEP), versionné, et il est envoyé aux prestataires avant le début de la modélisation, pas après le premier refus.
Anatomie d'une spécification
Une spécification IDS se lit comme une phrase : pour chaque élément correspondant à l'applicabilité, exiger les exigences.
Un fichier IDS est une liste de spécifications. Chacune se lit comme une phrase avec un sujet et un prédicat : « pour chaque élément qui correspond à ceci, exiger cela ». Le sujet est l'applicabilité ; le prédicat, les exigences.
<specification name="Doors carry a fire rating" ifcVersion="IFC4">
<applicability minOccurs="1">
<entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
</applicability>
<requirements>
<property dataType="IFCLABEL">
<propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
<baseName><simpleValue>FireRating</simpleValue></baseName>
</property>
</requirements>
</specification>
Lisez-la à voix haute : c'est exactement la phrase de l'EIR. Chaque IfcDoor doit avoir un FireRating dans Pset_DoorCommon, stocké comme label. Le minOccurs="1" de l'applicabilité ajoute une seconde affirmation facile à manquer : le modèle doit contenir au moins une porte. Sans lui, un modèle sans aucune porte passe, ce qui est rarement l'intention de qui que ce soit.
Les six facettes et ce que chacune teste vraiment
| Facette | Teste | Exigence typique | Piège courant |
|---|
| Entity | Classe IFC et type prédéfini | Les murs sont des IfcWall, pas des IfcBuildingElementProxy | Oublier les sous-types : IfcWallStandardCase est un IfcWall en IFC2x3 |
| Attribute | Attributs IFC directs (Name, Description, Tag…) | Chaque espace a un Name et un LongName | Une chaîne vide est présente mais invalide, pas absente |
| Property | Une propriété d'un property set, avec type de donnée et valeur | Pset_WallCommon.IsExternal vaut TRUE ou FALSE | Bonne valeur, mauvais type de donnée (un label là où un booléen était demandé) |
| Classification | Une référence de classification et son code | Chaque élément a un code Uniclass Ss | Vérifier le code mais pas le système auquel il appartient |
| Material | Un nom ou une catégorie de matériau associé | Les poteaux structurels déclarent un matériau | Matériaux sur le type, pas sur l'occurrence |
| PartOf | Une relation avec un élément parent | Chaque élément est contenu dans un niveau | Confondre agrégation et contenance spatiale |
Chaque facette peut figurer dans l'applicabilité (pour sélectionner des éléments) ou dans les exigences (pour leur imposer quelque chose).Deux de ces pièges méritent qu'on s'y attarde, car ils expliquent la plupart des faux échecs signalés lors d'une première exécution d'IDS.
Type ou occurrence
Les propriétés peuvent être portées par le type plutôt que par l'occurrence. Un vérificateur IDS doit suivre le type, sinon il fait échouer des éléments corrects.
Revit, ArchiCAD et Tekla écrivent couramment propriétés et matériaux sur l'objet type (IfcWallType) plutôt que sur chaque mur. La sémantique de l'IDS est claire : l'information héritée du type vaut pour l'occurrence. Un vérificateur qui ne regarde que l'occurrence fera échouer tous les murs d'un modèle parfaitement correct. Si un IDS vous dit que 100 % de vos éléments n'ont pas une propriété que vous voyez dans le panneau des propriétés, c'est presque toujours la raison — et la faute revient au vérificateur, pas à vous.
Types prédéfinis USERDEFINED
Quand un type prédéfini vaut USERDEFINED, le vrai type se trouve dans ObjectType (sur les occurrences) ou ElementType (sur les types). Une facette entity qui demande IFCWALL avec le type prédéfini PARAPET doit correspondre à un mur dont le PredefinedType est USERDEFINED et l'ObjectType PARAPET. Les vérificateurs qui comparent l'énumération brute les ratent tous.
Cinq erreurs qui rendent un IDS inutile
- Une applicabilité trop large. « Tous les éléments doivent avoir un code Uniclass » embarque les ouvertures, les annotations et les éléments spatiaux que personne ne classe. Limitez chaque spécification aux classes réellement visées par l'exigence.
- Des valeurs sans type de donnée. Une exigence FireRating = « EI 60 » ne dit rien sur la manière de la stocker ; le même texte stocké comme description dans un autre pset échouera quand même. Dites ce que vous voulez dire, type de donnée compris.
- Des valeurs exactes là où un motif était voulu. Les données réelles contiennent « EI60 », « EI 60 » et « EI-60 ». Utilisez un xs:pattern ou une énumération, et convenez de la forme canonique dans le BEP.
- Une spécification géante. Quarante exigences dans une seule spécification donnent un seul réussi/échoué par élément et un rapport inexploitable. Une exigence par spécification, nommée en langage clair, c'est ce qui rend le résultat lisible.
- Écrire l'IDS après le modèle. Un IDS envoyé avec le premier refus est une nouvelle exigence. Un IDS envoyé avec la commande est une exigence. Seul le second est opposable.
Le volet contractuel de ce dernier point — quelles clauses rendent un IDS contraignant et ce qui se passe quand une livraison n'y satisfait pas — est traité dans les clauses du BEP qui évitent vraiment les mauvaises livraisons IFC et dans les critères d'acceptation IFC.
Exécuter un IDS sur votre modèle, étape par étape
- Ouvrez l'IFC Glissez le modèle dans la visionneuse. Il est analysé dans votre navigateur ; rien n'est envoyé.
- Chargez le fichier .ids Ouvrez le panneau IDS et choisissez votre fichier — ou partez d'une des spécifications d'exemple fournies si vous voulez d'abord voir le format.
- Lancez le contrôle Chaque spécification est évaluée avec les six facettes. Les gros modèles affichent la progression par phase et peuvent être annulés à tout moment.
- Lisez le résultat par spécification, élément ou classe Regroupez les échecs selon la façon dont vous comptez les corriger. Chaque échec donne sa raison en clair : propriété manquante, mauvaise valeur, mauvais type de donnée, mauvaise classe.
- Voyez-le en 3D Mettre en évidence colore les éléments en échec dans le modèle ; Isoler masque tout le reste. Les deux sont à un clic, et c'est ainsi qu'une liste de GlobalIds devient une conversation avec le modeleur.
L'IDS d'une révision à l'autre
Une exécution d'IDS est un instantané. Ce dont un coordinateur a réellement besoin, c'est la tendance : la révision 7 a-t-elle corrigé les échecs relevés sur la révision 6, et en a-t-elle introduit de nouveaux ? Comme le résultat est indexé par GlobalId, la même spécification peut être comparée entre deux versions d'un modèle — ce qui ne fonctionne que si vos GlobalIds sont stables d'un export à l'autre. S'ils ne le sont pas, corrigez cela d'abord : pourquoi les GUID IFC changent à chaque export. La comparaison elle-même est traitée dans comment comparer deux versions d'un modèle IFC.
Là où l'IDS s'arrête
L'IDS ne contrôle pas la géométrie. Il ne vous dira pas que deux gaines se heurtent, qu'une porte est trop étroite pour un fauteuil roulant, ni que le modèle se trouve à deux kilomètres de son point topographique. Il ne vérifie pas non plus qu'un IFC est structurellement sain : un fichier avec des GlobalIds en double ou des placements cassés peut passer un IDS sans le moindre échec.
Ce n'est pas une faiblesse, c'est un périmètre. Utilisez l'IDS pour les exigences d'information, un model checker pour la structure et la géométrie, et joignez les deux rapports à la livraison. Le processus complet est dans comment valider un fichier IFC.
L'IDS expliqué : comment contrôler un modèle IFC avec une Information Delivery Specification