Quelles propriétés exiger sur une porte ? sur un mur ? à quelle phase ? Chaque projet réécrit la réponse de zéro, mal, et chaque modeleur la devine. BIMids est une bibliothèque partagée qui répond une fois pour toutes, par élément, par usage et par phase, et qui exporte cette réponse en EIR, en fichiers de configuration et en fichiers de vérification.
Le site explique comment exprimer un besoin d’information, dans un EIR, et comment le graduer, avec le LOIN. Reste une question très concrète que chacun affronte seul : sur cette porte précise, quelles propriétés faut-il, et à quelle phase ?
En pratique, chaque maître d’ouvrage et chaque BIM manager répond à cette question à sa manière, en repartant d’une page blanche ou en recopiant un EIR d’un projet précédent. Le résultat est prévisible : des exigences incomplètes, incohérentes d’un projet à l’autre, et souvent invérifiables. En face, le modeleur découvre des demandes floues et renseigne ce qu’il croit attendu. Personne n’a tort, mais l’énergie dépensée à réinventer la même liste est colossale, et la qualité en pâtit.
BIMids répond à ce gaspillage. C’est une bibliothèque de référence, portée par le secteur en Belgique et au Luxembourg, qui dit pour chaque type d’élément quelles informations lui associer, selon le cas d’usage et la phase. Au lieu d’inventer, on part d’un socle commun, éprouvé et maintenu, qu’on adapte à son projet.
L’EIR dit ce qu’on veut, le LOIN dit à quel niveau. Ces deux notions sont justes mais abstraites : elles ne remplissent pas la case « quelles propriétés sur une porte coupe-feu en phase projet ». BIMids remplit cette case, à la place de chacun, à partir d’un référentiel partagé. C’est le chaînon concret entre la théorie des exigences et leur écriture réelle.
Le cœur de BIMids est un dictionnaire d’éléments : murs, dalles, portes, tableaux électriques, et ainsi de suite. Pour chacun, il ne se contente pas de nommer, il précise quatre choses.
Comment classer l’élément dans le logiciel de modélisation, pour qu’il parte du bon endroit. Le premier maillon d’un export propre.
Vers quelle classe d’échange l’élément doit être mappé, pour être compris de tous. C’est ce qui décide de son identité une fois exporté.
Comment le ranger dans les systèmes de classification employés dans la région, NLBE-SfB, Uniformat II, DIN 276, selon les besoins du projet.
Quelles propriétés lui attribuer, distinguées selon le cas d’usage et la phase : la géométrie attendue, les données alphanumériques, la documentation associée.
« Quelle information, sur quel objet, pour quel usage, à quelle phase ? ». C’est la question que tout EIR devrait trancher et que la plupart survolent. BIMids y répond élément par élément, ce qui transforme une intention générale (« nous voulons un modèle exploitable ») en une liste précise et opposable. Le niveau d’information cesse d’être un palier vague pour devenir une exigence par objet, exactement ce que le LOIN appelle de ses vœux.
La force de BIMids n’est pas seulement de contenir des exigences, c’est de couvrir toute la chaîne, du demandeur au vérificateur, à partir du même référentiel.
Côté demandeur, on choisit ses cas d’usage et BIMids recommande les informations à exiger, puis génère un EIR prêt à intégrer au contrat. Côté producteur, des fichiers de configuration aident à structurer ces informations directement dans les logiciels de modélisation, pour sortir un IFC conforme. Enfin, côté contrôle, des fichiers au format IDS permettent de vérifier automatiquement qu’un modèle contient bien ce qui était exigé, en auto-contrôle avant l’envoi ou dès la réception.
L’exigence, l’implémentation et la vérification sortent de la même source. Le demandeur spécifie depuis BIMids, le producteur implémente depuis BIMids, le contrôle vérifie depuis BIMids. Il n’y a donc pas d’écart entre ce qui est demandé et ce qui est contrôlé : le producteur peut se contrôler lui-même, avant de livrer, avec le fichier même qui servira à le juger. C’est l’aboutissement de la logique de l’IDS, appliquée à une bibliothèque entière plutôt qu’à une règle isolée.
L’apport se mesure en comparant deux façons de produire ses exigences d’information : la page blanche recommencée à chaque projet, et le référentiel partagé qu’on adapte.
BIMids ne supprime pas le travail de réflexion, il le déplace. Vous ne passez plus votre temps à reconstituer quelles propriétés porte une porte, vous le passez à décider quels cas d’usage servent vraiment votre projet, ce qui est la question qui mérite votre jugement. Le référentiel absorbe le répétitif, vous gardez le décisif.
Un référentiel puissant devient un piège si on le prend pour ce qu’il n’est pas. Trois précisions évitent de mal l’employer.
Ce n’est pas une obligation : c’est une recommandation, un socle à adapter, pas une norme qui s’imposerait. L’utiliser tel quel sans le confronter à ses propres cas d’usage revient à exiger des informations dont on n’a pas l’emploi, ce qui gonfle les modèles pour rien. Ce n’est pas non plus universel : il est ancré dans un contexte régional, ses classifications et ses conventions reflètent les pratiques belges et luxembourgeoises, et un usage ailleurs suppose de vérifier ce qui se transpose. Enfin, ce n’est pas un substitut au jugement : il accélère l’écriture des exigences, il ne décide pas à votre place de ce dont votre projet a besoin.
Prenez BIMids comme un point de départ éprouvé, pas comme un cahier des charges à copier. Sélectionnez les cas d’usage qui comptent pour votre projet, retenez les exigences correspondantes, écartez le reste, et vérifiez que son cadre de classification correspond au vôtre. Un référentiel bien adapté fait gagner des semaines ; un référentiel appliqué aveuglément produit des exigences décoratives que personne n’exploitera.
La pièce concrète qui manquait entre la théorie des exigences d’information et leur écriture réelle.
Trois idées à emporter. BIMids répond à la question que l’EIR pose sans la remplir : quelle information, sur quel objet, pour quel usage, à quelle phase, élément par élément, à partir d’un référentiel partagé plutôt que d’une page blanche. Il couvre toute la chaîne depuis une seule source : spécifier l’EIR, implémenter dans les logiciels, vérifier par fichiers IDS, sans écart entre ce qui est demandé et ce qui est contrôlé. Enfin, c’est un socle à adapter, pas une obligation : régional, non universel, et jamais un substitut au jugement sur les usages réels de votre projet.
BIMids donne corps à l’EIR et au LOIN, s’appuie sur le mapping vers le format IFC et sur les systèmes de classification, et boucle sur la vérification par l’IDS. Le contrôle manuel qui reste utile en complément est décrit dans contrôler un IFC pas à pas. BIMids est une référence sectorielle belgo-luxembourgeoise, à consulter pour son état à jour.
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.
Un même acronyme pour deux notions, des paliers américains détournés de leur sens, et une norme récente qui démonte toute l'approche. Le niveau d'information ne se décrète pas globalement : il se définit par objet, par usage et par jalon.
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.