Un cahier des charges dit « les murs porteurs doivent indiquer leur résistance au feu ». Deux personnes le lisent et le vérifient différemment ; un ordinateur ne peut pas le vérifier du tout. L'IDS traduit cette même exigence dans une forme que la machine exécute, avec le même verdict partout. C'est le chaînon qui manquait entre écrire une exigence et la contrôler.
Vous savez exprimer ce que vous attendez d’une maquette, dans un cahier des charges. Vous savez, à la fin, contrôler ce que vous avez reçu. Entre les deux, il y a un trou : rien ne relie automatiquement l’un à l’autre.
Une exigence écrite en français est interprétable. « Les équipements techniques doivent porter leur puissance » : est-ce tous les équipements ? Dans quel champ ? Sous quelle unité ? Deux personnes de bonne foi répondront différemment, et le producteur livrera selon sa lecture, le contrôleur vérifiera selon la sienne. Le désaccord se découvre à la réception, quand il coûte le plus cher.
L’IDS supprime ce trou. C’est un document lisible par une machine qui exprime la même exigence de façon exécutable : à quels objets elle s’applique, ce qu’ils doivent porter, et sous quelle forme. Un logiciel lit ce document, ouvre la maquette, et rend un verdict, sans qu’aucun humain n’ait à interpréter quoi que ce soit.
L’IDS est la traduction de votre cahier des charges dans une langue que l’ordinateur exécute. Il ne remplace pas l’exigence écrite, il la rend vérifiable. Là où l’EIR dit ce qu’on veut à des humains, l’IDS dit la même chose à une machine, et permet de contrôler à chaque dépôt ce qui prenait des jours à la main.
Le mécanisme est d’une simplicité rassurante. Chaque règle d’un IDS tient en deux parties, et c’est leur articulation qui fait toute la puissance de l’outil.
À quels objets la règle s’applique. Par exemple : tous les murs extérieurs, ou tous les équipements de ventilation, ou tous les objets d’une classification donnée. C’est le filtre qui sélectionne la cible.
Ce que ces objets doivent porter. Telle propriété, dans tel jeu de propriétés, avec une valeur d’un certain type, dans une unité imposée, éventuellement dans une liste de valeurs autorisées. C’est ce qui sera vérifié.
La logique est celle d’un « si… alors ». Si un objet est un mur extérieur, alors il doit porter une résistance au feu exprimée en minutes. Un objet qui entre dans le « si » sans satisfaire le « alors » est signalé, nommément. Un objet qui n’entre pas dans le « si » est ignoré : la règle ne le concerne pas.
Le contrôle au jugé, celui qui vérifie « à peu près » et laisse passer ce qui ressemble. Avec un IDS, il n’y a pas de « à peu près » : soit la propriété est là, au bon endroit, dans le bon format, soit elle ne l’est pas. Cette rigueur est parfois désagréable, et c’est exactement ce qu’on attend d’un contrôle : qu’il ne se laisse pas attendrir.
C’est la propriété la plus précieuse de l’IDS, et la moins évidente pour qui n’a jamais vécu le problème inverse : deux outils de contrôle qui, sur la même maquette, rendent deux avis différents.
Avant l’IDS, chaque logiciel de contrôle qualité avait sa façon d’écrire les règles. Un contrôle « conforme » chez un émetteur pouvait ressortir « non conforme » chez le destinataire, non parce que la maquette avait changé, mais parce que les deux outils n’interprétaient pas la règle de la même manière. Le désaccord portait alors sur l’outil, pas sur l’ouvrage.
L’IDS étant strictement adossé au schéma d’échange IFC, une même règle produit le même résultat dans tout logiciel qui la lit. Le verdict cesse d’être une opinion d’outil pour devenir un fait vérifiable par tous. C’est ce qui permet d’écrire une exigence une fois, de la joindre à la consultation, et d’être certain que producteur et contrôleur parlent exactement de la même chose.
Quand l’exigence est un IDS, l’acceptation n’est plus négociable au cas par cas : elle est objective. Le producteur peut vérifier lui-même, avant de livrer, qu’il passera le contrôle, avec le fichier même qui servira à le juger. On sort du régime de l’avis, où le dernier qui parle a raison, pour entrer dans celui de la preuve. C’est l’aboutissement logique des critères d’acceptation d’un EIR bien écrit.
L’IDS n’est pas un système isolé : c’est la pièce qui rend exécutables des exigences exprimées ailleurs. Le situer évite de lui demander ce qu’il ne fait pas.
L’IDS vérifie que l’information est là et bien formée, pas qu’elle est vraie. Un objet peut porter tous les attributs exigés, dans le bon format, avec des valeurs fausses : il passera. C’est déjà énorme, car l’absence et le mauvais format sont les défauts les plus massifs et les plus fastidieux à traquer à la main. Mais la vérification du fond reste un travail humain, décrit dans auditer une maquette.
L’IDS est récent. C’est une force, parce qu’il a été conçu en connaissant les échecs des approches précédentes, et une limite, parce que son écosystème se met encore en place.
La version 1.0 a été publiée en 2024 et constitue désormais un standard officiel de l’organisation qui maintient les formats ouverts. Ce qui est stabilisé : le principe, la structure de la règle, l’adossement au format d’échange. Ce qui bouge encore : le support dans les logiciels, inégal selon les éditeurs, et des versions ultérieures en préparation d’après les retours des premiers utilisateurs.
N’attendez pas que tout l’écosystème soit mûr pour commencer, mais vérifiez le support dans les outils de votre chaîne avant d’en faire une exigence contractuelle. Un IDS que vos intervenants ne peuvent ni lire ni contrôler ne sert à rien, quelle que soit sa qualité. Commencez par quelques règles simples, celles qui couvrent vos exigences les plus fréquentes, plutôt que par un fichier exhaustif que personne n’outillera.
Un outil discret, qui comble le vide le plus coûteux du management de l’information : celui entre ce qu’on exige et ce qu’on peut vérifier.
Trois idées à emporter. L’IDS traduit une exigence en règle exécutable : là où une phrase en français s’interprète, un IDS s’exécute, et le contrôle qui prenait des jours à la main se fait à chaque dépôt. Son verdict est identique partout parce qu’il est adossé au schéma d’échange : l’acceptation cesse d’être une opinion d’outil pour devenir un fait, que le producteur peut vérifier lui-même avant de livrer. Enfin, il vérifie la présence et la forme, pas la vérité : une valeur fausse mais bien formée passe, et le jugement du fond reste humain.
L’IDS traduit ce qui s’exprime d’abord dans l’EIR et se précise avec LOD et LOIN. Il s’adosse au format IFC, dont il partage la logique d’objets et de propriétés, et c’est l’un des trois piliers décrits dans openBIM contre closed BIM. Ce qu’il ne couvre pas, le jugement du fond, relève d’auditer une maquette.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Le maître d'ouvrage doit exprimer ses besoins d'information avant même de savoir ce qu'il pourra en faire. D'où des cahiers des charges recopiés, qui exigent beaucoup et obtiennent peu. La méthode tient en une inversion : partir de la fin.
Non, l'IFC n'est pas « le PDF de la maquette ». C'est une base de données structurée qui transporte vos objets et leurs propriétés d'un logiciel à l'autre. Comprendre ce qu'il contient vraiment, c'est arrêter de subir les exports ratés.
Sans exigences écrites à l'avance, un audit n'est qu'un avis, et le producteur a le droit de ne pas être d'accord. Voici les quatre familles de contrôle, dans l'ordre où elles se mènent, et ce qui sépare un audit qui améliore d'un audit qui indispose.