Illustration générée par IA — visuel conceptuel.
Quand un promoteur, une AMO BIM/Exploitation ou un gestionnaire immobilier « réceptionne » un projet, la difficulté n’est pas d’obtenir un fichier IFC : c’est d’obtenir des données fiables, complètes et vérifiables sur les espaces et surtout sur les équipements techniques (CVC, tableaux, éclairage, sûreté, GTB/GRMS, etc.).
Dans beaucoup d’opérations, ces exigences finissent en tableaux Excel ou en annexes PDF. C’est utile pour cadrer… mais difficile à contrôler de façon systématique et donc compliqué à transformer en critère clair de réception.
Le standard buildingSMART IDS (Information Delivery Specification) propose une approche différente : exprimer des exigences d’information dans un fichier .ids lisible par machine, puis vérifier automatiquement un modèle IFC contre ces exigences, côté production comme côté réception. ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
IDS, en une phrase : ce que vous achetez (vraiment)
Un IDS n’est pas « un DOE » et ce n’est pas « une maquette » : c’est une spécification de données orientée contrôle. Autrement dit, il sert à :
- formaliser ce que le modèle doit contenir (et pour quels objets),
- vérifier ensuite qu’un IFC respecte ces exigences,
- produire des résultats de conformité (et donc accélérer les itérations de corrections).
buildingSMART a annoncé qu’IDS v1.0 a atteint le statut de « final standard » en juin 2024. ([buildingsmart.org](https://www.buildingsmart.org/information-delivery-specification-ids-v1-0-is-approved-as-a-final-standard/?utm_source=openai))
Pourquoi l’Excel ne suffit pas (et comment IDS le complète)
Les tableaux Excel restent utiles : ils servent à arbitrer, documenter des décisions, tracer des responsabilités, lister des livrables qui ne sont pas dans l’IFC (PV, notices, procédures, sauvegardes…). En revanche, à la réception, ils atteignent vite leurs limites :
- Ambiguïté : « identifiant équipement »… lequel ? dans quel champ ? avec quelle règle ?
- Contrôle non reproductible : deux contrôleurs peuvent conclure différemment.
- Correction tardive : les incohérences de structure (espaces, relations, propriétés) explosent en fin de projet.
L’intérêt d’un IDS n’est donc pas de « remplacer la gouvernance » ; c’est de rendre une partie du contrat testable et répétable sur des IFC, au fil de l’eau. ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
Ce que contient un IDS : la logique à connaître (Applicability + Requirements)
Un IDS est un fichier .ids qui contient une liste de Specifications. ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
Chaque Specification est composée de deux parties : ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
- Applicability : à quoi la règle s’applique (quels objets sont concernés ?)
- Requirements : ce qui est exigé (quelles propriétés, attributs, classifications, relations… doivent être présents ou absents ?)
Ces deux parties s’expriment au travers de « facets » (familles de critères) telles que property, entity, classification, material ou partOf. ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
Exemple simple (illustratif, à adapter)
Le manuel donne un exemple volontairement basique : exiger que « tous les murs aient une propriété de résistance au feu ». ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
Dans une logique exploitation, la mécanique est la même, mais appliquée à vos objets critiques : équipements, espaces, zones, tableaux, centrales, etc.
De « DOE exploitable » à des exigences vérifiables : une méthode projet
Sur un projet tertiaire ou hôtellerie, le risque classique est de partir d’une liste « exhaustive » et d’aboutir à une surcharge de production… qui ne tient pas au planning. Une mise en place pragmatique se fait généralement en trois passes.
1) Partir de vos usages exploitation (pas du BIM)
Avant d’écrire un IDS, clarifiez ce que vous voulez faire, après réception. Exemples (à adapter) :
- construire ou alimenter un registre d’actifs (gestion patrimoniale, maintenance, contrats),
- préparer une reprise GTB/GRMS (synoptiques, arborescences, groupes),
- préparer une intégration GMAO (identifiants, localisation, familles d’équipements),
- fiabiliser les espaces/locaux (zones, affectations, relations aux équipements).
Ensuite seulement, vous décidez quelles informations sont « bloquantes » à la réception, et lesquelles relèvent d’améliorations progressives.
2) Convertir ces usages en contrôles « testables »
Pour rester opérable, classez vos exigences en catégories vérifiables :
| Besoin exploitation | Exigence exprimable (souvent) en IDS | Attention / limite |
|---|---|---|
| Inventaire d’actifs maintenable | Chaque équipement concerné possède un identifiant, une classification, une localisation (relation à l’espace) | Le sens de l’identifiant (référentiel) reste à gouverner côté MOA/MOE |
| Reprise GTB/GRMS | Relations équipement → local/zone + propriétés minimales cohérentes | L’IDS ne remplace pas l’ingénierie de mapping « points ↔ équipements » : il sécurise la base |
| Contrôle qualité à chaque jalon | Un IFC peut être contrôlé contre un IDS indépendamment du logiciel auteur | Le format est standard ; les rapports et workflows dépendent de l’outil choisi |
Le manuel IDS précise que tout modèle IFC, produit par n’importe quel logiciel, peut être contrôlé contre un fichier IDS (principe d’interopérabilité). ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
3) Découper l’IDS pour éviter un « monolithe » ingérable
Pour un maître d’ouvrage, une structuration simple consiste à séparer :
- un socle commun (règles transverses : espaces, identifiants, classification minimale, rattachements),
- des IDS par lot (CVC, CFO/CFA, SSI/sûreté, etc.),
- un IDS “réception exploitation” (strictement ce qui conditionne vos usages réels).
Ce découpage facilite les arbitrages contractuels et évite de bloquer toute la réception pour une exigence secondaire.
Exemples d’exigences utiles pour un DOE numérique exploitable (équipements & locaux)
Les exemples ci-dessous sont des patrons d’exigences : ils doivent être ajustés à vos référentiels (nomenclature, classification, conventions de localisation, responsabilités par lot).
A) Équipements techniques : rendre un “asset” exploitable
Un équipement « existe » pour l’exploitation s’il est :
- identifiable (identifiant stable dans le temps),
- classable (famille/typologie cohérente),
- localisable (lien clair à un local/zone/niveau),
- documentable (jeu minimal de propriétés de maintenance, selon votre stratégie).
Dans IDS, la logique typique consiste à :
- définir une Applicability (par entité IFC, classification, ou combinaison), ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
- poser des Requirements (présence de propriétés/attributs/relations).
B) Locaux et zones : fiabiliser le “référentiel espaces”
Beaucoup de dérives GTB/GRMS viennent d’un référentiel locaux instable (codes qui changent, zones mal définies, relations équipement→espace incohérentes). Un IDS peut aider à sécuriser :
- la présence d’un code de local (ou identifiant d’espace) et d’un nom cohérent,
- l’affectation (type d’espace),
- les relations structurantes (appartenance à une zone).
C) Préparer GTB/GRMS sans promettre une “magie automatique”
IDS ne « génère » pas une liste de points GTB/GRMS. En revanche, il peut sécuriser ce qui rendra ensuite le travail d’intégration moins artisanal :
- un identifiant équipement stable (que l’on peut réconcilier avec la nomenclature terrain),
- un rattachement exploitable à l’espace (pour filtrer et construire des vues métier),
- une classification cohérente (pour regrouper et appliquer des règles de gestion).
Sur la structuration « BIM → données exploitation » (et les pièges de l’export supposé automatique), vous pouvez aussi lire : Bâtiment intelligent : organiser les données entre la maquette numérique et KNX.
Vérifier : distinguer “audit du .ids” et contrôle “IFC vs IDS”
1) Auditer un fichier IDS (conformité au standard)
La release buildingSMART/IDS v1.0.0 mentionne un « IDS Audit tool » visant à aider à implémenter le standard de façon cohérente. ([github.com](https://github.com/buildingSMART/IDS/releases/tag/v1.0.0))
Ce type de contrôle répond à la question : « le fichier .ids est-il conforme au standard ? »
2) Contrôler un IFC contre un IDS (conformité du livrable)
C’est le contrôle « réception » : « le modèle IFC respecte-t-il les Specifications attendues ? » Le manuel précise que le destinataire peut utiliser l’IDS pour vérifier la conformité du modèle et générer des rapports de résultats. ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
Point d’attention : IDS est un standard ; les fonctions concrètes (ergonomie, rapports, gestion des réserves, visualisation, intégration à votre processus) dépendront des outils retenus.
Limites : ce qu’un IDS ne doit pas porter (ou pas seul)
Pour garder des attentes réalistes, retenez l’idée suivante : un IDS est particulièrement adapté aux exigences d’information alphanumériques et à la validation de présence/cohérence de données sur un IFC. ([itcon.org](https://www.itcon.org/papers/2025_30-ITcon-SI-Akbas.pdf))
Si votre réception exige des contrôles plus complexes (géométrie, règles de coordination, contraintes très spécifiques), IDS peut rester une brique utile, mais il devra généralement être complété par d’autres contrôles et méthodes.
Un exemple buildingSMART : un IDS « localisable » (logique transposable au DOE)
Le référentiel UCM (Use Case Management) de buildingSMART présente un cas d’usage « Regulatory Information Requirements » qui inclut un fichier .ids (IDS Version V1.0) et illustre une idée intéressante côté maîtrise d’ouvrage : un IDS peut être conçu comme une base localisable (par ajout ou suppression de clauses). ([ucm.buildingsmart.org](https://ucm.buildingsmart.org/en/use-cases/1834/en?utm_source=openai))
Même si l’exemple est orienté exigences réglementaires, la mécanique est transposable : partir d’un socle, puis le décliner selon la typologie d’actif, les lots concernés et vos usages exploitation.
Intégrer IDS dans vos pièces marché (sans rigidifier le projet)
Dans un cadre CCTP/EIR/BEP, une approche raisonnable consiste à :
- désigner les fichiers IDS comme annexes d’exigences (versionnés, datés),
- définir un processus de contrôle (jalons de vérification, modalités de levée de réserves),
- clarifier la responsabilité de production de chaque famille d’informations (par lot),
- prévoir un volet « DOE exploitation » plus large que l’IFC (sauvegardes, accès, procédures), car tout ne se met pas dans l’IDS.
Pour une vue « exploitation » de ce qu’il faut récupérer au DOE (au-delà de la maquette), voir aussi : DOE domotique : quels documents et sauvegardes le client doit-il recevoir ? et DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.
Sources et documentation (pour aller au primaire)
- buildingSMART/IDS — User Manual (GitHub)
- buildingSMART/IDS — Release v1.0.0 « Final buildingSMART Standard » (GitHub)
- buildingSMART/IDS — Schéma XSD (GitHub)
- buildingSMART UCM — Use case 1834 (IDS V1.0 + fichier .ids)
- buildingSMART — Annonce « IDS v1.0 approved as a final standard »
Conclusion
Si votre objectif est de réceptionner un DOE numérique réellement exploitable, buildingSMART IDS v1.0 apporte une réponse concrète : transformer une partie de vos exigences d’information en un artefact standard, testable et contrôlable sur IFC— plutôt que de dépendre uniquement de listes Excel difficiles à vérifier. ([github.com](https://github.com/buildingSMART/IDS/blob/development/Documentation/UserManual/README.md))
Si vous souhaitez cadrer un premier périmètre, une bonne entrée est souvent : espaces (référentiel locaux) + équipements critiques + identifiants + rattachements. Ensuite, on élargit lot par lot, avec des jalons de validation intégrés au projet.
Besoin d’aide pour démarrer ? Nous pouvons vous aider à structurer un socle d’exigences « exploitation » (GTB/GRMS/équipements), puis à le traduire en logique IDS (Applicability/Requirements) et en démarche de recette progressive.
