Management de l’information BIM : de la maquette à une donnée exploitable

Dans beaucoup de projets, on parle encore de BIM en comptant les maquettes, les objets ou les paramètres. Ce sont des indicateurs de production, pas des indicateurs de valeur. Une base remplie de milliers de propriétés incohérentes peut être moins utile qu’un jeu réduit d’informations fiables et directement exploitables. Le vrai sujet du management de l’information est donc de construire une chaîne dans laquelle le besoin, la production, le contrôle, l’échange et l’usage restent cohérents.

L’ISO 19650-1 positionne précisément le BIM comme une démarche de gestion de l’information sur l’ensemble du cycle de vie de l’actif. Elle traite notamment de l’échange, de l’enregistrement, du contrôle de version et de l’organisation des informations. Cette logique dépasse largement la production de modèles 3D.

Donnée, information et connaissance projet

Un paramètre brut n’est pas forcément une information exploitable. Une valeur « EI60 » dans un champ libre peut être parfaitement compréhensible pour un humain mais difficile à agréger si d’autres équipes utilisent « 60 min », « REI60 » ou simplement « 60 ». Le problème ne vient pas de l’absence de donnée : il vient de l’absence de structure commune.

Pour qu’une donnée devienne exploitable, son contexte doit être connu : objet concerné, propriété, type de valeur, unité, référentiel, source, date, statut et parfois niveau de validation. Plus l’usage est automatisé, plus cette formalisation devient importante.

C’est la raison pour laquelle le management de l’information s’intéresse moins au nombre de champs qu’à leur cohérence. Dans une base de données, un identifiant stable, une classification correcte et une valeur normalisée valent souvent davantage que vingt propriétés textuelles impossibles à contrôler.

La valeur de l’information vient de son usage

Une information coûte à produire, maintenir et contrôler. Il faut donc pouvoir relier chaque exigence importante à un usage. Dans une maquette de conception, une donnée peut servir à une vérification réglementaire, à un quantitatif ou à une coordination. Plus tard, une autre information sera nécessaire à la réception, à la maintenance ou au renouvellement d’un équipement.

Le principe est proche de la logique d’asset management décrite par la série ISO 55000 : les actifs doivent être gérés pour contribuer aux objectifs de l’organisation et produire de la valeur. L’information associée à ces actifs n’est pas la valeur elle-même, mais elle devient un moyen essentiel pour prendre les bonnes décisions au bon moment.

Sur un projet BIM, la question utile est donc rarement « quelles données pouvons-nous produire ? ». Elle est plutôt : quelles décisions seront prises avec ces données ?

Les dimensions de la qualité des données BIM

Une information peut être présente tout en étant mauvaise. Pour structurer les contrôles, je distingue plusieurs dimensions de qualité.

Toutes ces dimensions ne peuvent pas être automatisées de la même manière. La présence, les formats, les listes de valeurs, les doublons ou certains contrôles de cohérence se prêtent bien aux règles automatiques. L’exactitude par rapport au chantier réel demande souvent une validation humaine ou une source externe.

Sans identifiants stables, la donnée se fragmente

Pour relier une maquette à un planning, un outil de maintenance, une base documentaire ou un tableau Power BI, il faut une clé commune. L’identifiant devient alors une pièce centrale de l’architecture de données.

Le GUID IFC joue un rôle important dans les échanges openBIM, mais il ne remplace pas forcément les identifiants métier du projet. Un équipement peut avoir un GUID technique, un code de repérage projet, un identifiant de GMAO et éventuellement une référence fabricant. La bonne architecture doit définir lequel sert à quel usage et comment ces identifiants sont reliés.

Une erreur classique consiste à utiliser le nom d’un objet comme identifiant. Or les noms changent, sont parfois dupliqués et peuvent dépendre d’une langue ou d’une convention de saisie. Un identifiant durable doit être conçu pour rester stable même lorsque certaines caractéristiques de l’objet évoluent.

Le modèle BIM n’est pas toujours la source maîtresse

Il est tentant de présenter la maquette comme une « source unique de vérité ». En pratique, cette formule est souvent trop simplificatrice. Certaines informations sont maîtrisées dans le modèle BIM, d’autres dans un ERP, un logiciel de planning, une base de maintenance, un outil de calcul ou une GED.

Le bon objectif n’est donc pas nécessairement de tout stocker dans Revit ou dans l’IFC. Il faut plutôt définir la source de référence de chaque information et les mécanismes permettant de la relier aux autres systèmes.

Par exemple, les caractéristiques géométriques d’un équipement peuvent être maintenues dans la maquette, alors que son statut de commande est géré dans un ERP et ses opérations de maintenance dans une GMAO. Copier toutes ces informations dans chaque système augmente les risques de divergence.

Du PIM à l’AIM : préparer la continuité d’information

La logique ISO 19650 distingue notamment le Project Information Model — PIM, utilisé pendant la phase projet, et l’Asset Information Model — AIM, orienté vers la gestion de l’actif en exploitation. Cette distinction est essentielle car les besoins ne sont pas identiques.

Le PIM peut contenir de nombreuses informations temporaires nécessaires à la conception, à la coordination ou à la construction. Elles ne doivent pas toutes être transférées dans l’environnement d’exploitation. À l’inverse, certaines données essentielles à la maintenance n’apparaissent que tardivement : numéro de série, fabricant effectivement posé, date de mise en service, garantie ou référence de pièce.

La transformation du PIM vers l’AIM doit donc être pensée comme une sélection et une validation, pas comme une simple copie des fichiers de fin de chantier. Un DOE numérique utile est un jeu d’informations répondant aux besoins de l’exploitant, pas une archive brute de la production du projet.

La gouvernance compte autant que la technologie

Un outil de contrôle, un CDE ou une base de données ne résout pas les responsabilités. Pour chaque information critique, il faut savoir qui la produit, qui la contrôle, qui peut la modifier, à quel moment elle devient officielle et quel système fait référence.

Cette gouvernance doit également traiter les changements. Une donnée correcte à un instant peut devenir fausse après une modification de conception. Le processus doit donc définir quand les contrôles sont rejoués et comment les versions précédentes sont conservées.

C’est particulièrement important pour les échanges IFC. Une règle de contrôle appliquée sur le livrable final mais jamais sur les échanges intermédiaires produit des corrections tardives. Les projets les plus efficaces intègrent la qualité des données dans le cycle de production, au même titre que la coordination géométrique.

Le CDE comme système de confiance, pas simple stockage

L’environnement commun de données sert à organiser les conteneurs d’information, les statuts, les versions et les droits. Sa valeur vient de la capacité à distinguer clairement ce qui est en travail, ce qui est partagé pour coordination, ce qui est publié et ce qui est archivé.

Un CDE mal gouverné devient rapidement un espace où plusieurs fichiers portent presque le même nom, où l’on ignore quelle version fait foi et où les validations restent dans les emails. À l’inverse, un processus simple mais discipliné peut rendre les échanges beaucoup plus fiables.

La technologie est secondaire par rapport au workflow. SharePoint, Autodesk Construction Cloud ou une autre plateforme peuvent tous être efficaces si les règles de statut, de version et de responsabilité sont adaptées au projet.

Automatiser le contrôle plutôt que la saisie aveugle

L’automatisation BIM est souvent utilisée pour remplir plus rapidement des paramètres. C’est utile, mais ce n’est qu’une partie du sujet. Le gain le plus intéressant apparaît lorsque l’automatisation vérifie la qualité de l’information.

Une règle peut par exemple contrôler qu’un code existe, qu’il respecte une syntaxe, qu’il appartient à une liste autorisée, qu’il n’est pas dupliqué et qu’il correspond à la classe de l’objet. Dans un IFC, le contrôle peut également vérifier la présence d’un Property Set, le type de valeur ou un seuil numérique.

Cette logique permet de passer d’un contrôle ponctuel de fin de phase à un processus continu. Plus les règles sont intégrées tôt, moins les corrections coûtent cher en fin de production.

De la maquette vers les outils d’analyse

Lorsque les données sont structurées et identifiées correctement, elles deviennent exploitables en dehors des logiciels BIM. Elles peuvent être extraites vers Excel, une base SQL, Power BI ou des services web pour suivre la qualité, les quantités, les statuts ou les indicateurs projet.

La visualisation ne doit toutefois pas masquer la qualité de la source. Un dashboard très propre peut afficher des chiffres faux si la donnée amont est mal contrôlée. Je préfère donc séparer trois couches : extraction brute, transformation et contrôle, puis visualisation. Cette architecture rend les erreurs plus faciles à diagnostiquer et permet de rejouer le processus sur une nouvelle version de maquette.

Sur un audit BIM, par exemple, il est souvent plus intéressant d’extraire les données de Revit ou de l’IFC, de les normaliser dans une couche intermédiaire puis de construire les indicateurs. Le tableau de bord n’est que la dernière étape.

Le coût réel d’une mauvaise information

Je préfère éviter les grands chiffres génériques sur le « coût des mauvaises données », car ils dépendent fortement des secteurs et des méthodes de calcul. Sur un projet, les conséquences sont néanmoins très concrètes : ressaisie, recherche de la bonne version, contrôles manuels répétitifs, erreurs de commande, coordination supplémentaire, reprises de livrables et perte de continuité vers l’exploitation.

Une donnée mal structurée génère surtout du travail invisible. Chaque personne qui doit ouvrir la maquette, comprendre une convention locale, corriger un nom ou recopier une valeur réalise une transformation manuelle qui aurait pu être industrialisée.

Le management de l’information cherche précisément à réduire ces transformations non maîtrisées en définissant des structures communes et des responsabilités explicites.

Une stratégie simple pour améliorer la donnée BIM

Pour un projet ou une entreprise qui veut progresser, je recommande une approche progressive. Identifier d’abord les usages importants, puis les données nécessaires. Définir ensuite les sources de référence, les identifiants, les formats et les responsables. Enfin, automatiser les contrôles les plus répétitifs et mesurer les écarts.

Il vaut mieux réussir un jeu de vingt propriétés critiques que déployer trois cents paramètres mal gouvernés. La maturité ne se mesure pas au volume de données mais à leur capacité à circuler sans ambiguïté entre les personnes et les outils.

Ce que cela implique pour les outils PMB

Cette logique est directement liée aux deux univers de Pimp My BIM. Dans Revit, les outils de data management et de contrôle peuvent aider à fiabiliser les informations au moment de la production. Dans la plateforme IFC, les règles peuvent ensuite vérifier ce qui a réellement été transmis dans le fichier d’échange.

Le point important est la continuité : contrôler uniquement la maquette native ne garantit pas que l’IFC final contient les mêmes données. Les deux contrôles sont complémentaires et répondent à des étapes différentes de la chaîne d’information.