Une information saisie une fois doit servir jusqu'à l'exploitation, sans jamais être retapée. Ce principe explique à lui seul pourquoi les normes, les processus et les logiciels BIM sont faits comme ils le sont. Le comprendre, c'est arrêter de subir le BIM.
Prenez la référence commerciale d’un tableau électrique. Suivez-la sur un projet ordinaire, et comptez les fois où un humain la retape.
Le bureau d’études la choisit et l’inscrit dans sa note de calcul. Le rédacteur du CCTP la reprend dans la pièce écrite. Le projeteur la ressaisit comme propriété de l’objet dans la maquette. Le conducteur de travaux la recopie dans son tableau de suivi Excel. L’entreprise la mentionne dans sa fiche technique. Le rédacteur du DOE la retape une dernière fois. Puis l’exploitant la saisit dans sa GMAO.
Sept saisies pour une seule information. Six occasions de diverger.
Le problème n’est pas le temps de frappe : retaper une référence prend quinze secondes. Le problème, c’est qu’au bout de la chaîne, plus personne ne sait laquelle des sept versions fait foi. Quand le technicien de maintenance commande une pièce détachée trois ans plus tard et qu’elle ne correspond pas, le coût n’est plus de quinze secondes.
Ce n’est pas le temps perdu, c’est la perte de confiance. Dès qu’une information existe en plusieurs exemplaires divergents, chaque utilisateur suivant doit l’arbitrer : chercher la source, appeler quelqu’un, vérifier sur site. Cet arbitrage, répété sur des milliers de données, est le vrai budget invisible d’un projet.
Tout le BIM tient dans cette phrase. Une information est produite une seule fois, par celui qui la connaît le mieux, au moment où il la connaît, dans un endroit où les autres iront la chercher.
Cela suppose un renversement. Dans la pratique traditionnelle, chaque acteur produit ses documents : le BE produit ses notes, l’architecte ses plans, l’entreprise ses fiches. L’information est enfermée dans ces documents, et la transmettre veut dire transmettre le document, à charge pour le suivant d’en réextraire ce qui l’intéresse. À la main.
Dans une logique BIM, l’information est portée par des objets et par ce que la norme appelle des conteneurs d’information : des unités identifiées, versionnées, dont on sait toujours qui les produit, dans quel état elles sont et qui a le droit de les lire. Les documents ne disparaissent pas, mais ils changent de statut : ils deviennent des vues générées à partir de la source, et non plus la source elle-même.
Le BIM ne cherche pas à produire de plus belles maquettes. Il cherche à ce que l’information saisie en amont survive jusqu’à l’aval, sans ressaisie et sans perte de sens. Tout le reste (normes, processus, logiciels) n’existe que pour rendre cette survie possible.
Les phases d’un projet ne posent pas de problème en elles-mêmes. Ce qui casse, ce sont les passages de relais entre elles : le moment où l’information change de main, de métier et souvent de logiciel.
Un projet BIM mature ne se juge pas à la qualité de ses maquettes, mais à ce qui survit à ses quatre relais. C’est pour cela que l’ISO 19650 s’intéresse si peu à la modélisation et tellement aux moments d’échange.
La plupart des difficultés d’un projet BIM viennent d’un mélange des deux logiques. Les reconnaître permet de comprendre pourquoi un même geste est efficace chez l’un et catastrophique chez l’autre.
Le réflexe donnée ne rend pas le document inutile. Le plan visé reste la pièce contractuelle, et c’est très bien ainsi. Ce qui change, c’est qu’il cesse d’être l’endroit où l’on saisit l’information : il devient l’endroit où on la publie. Confondre les deux, c’est se retrouver à maintenir la même donnée à deux endroits, ce qui est pire que de n’en avoir qu’un.
Reprenons le tableau électrique du début, mais cette fois en faisant les choses dans l’ordre : une seule information, sa référence produit et sa date de mise en service, traverse tout le projet sans jamais être retapée.
Dès le programme, l’exploitant exige que tout équipement livré porte une référence produit et une date de mise en service exploitables dans sa GMAO. L’exigence est écrite une fois, dans l’EIR, et devient contractuelle.
Le bureau d’études modélise le tableau avec les paramètres attendus, renseignés de ce qu’il sait (puissance, type) et laissés vides pour le reste. La case existe : c’est ce qui garantit qu’on la remplira.
Le CCTP est rédigé à partir des mêmes données, pas en parallèle. Une exigence modifiée en conception se répercute dans la pièce écrite, sans double saisie.
À la commande, la fiche technique approuvée donne la référence réelle du matériel retenu. Elle est saisie dans le conteneur d’information du projet, pas annoncée dans un mail.
À la pose, l’autocontrôle enregistre la date de mise en service et le numéro de série. Personne d’autre ne peut fournir cette information, et personne n’aura à la redemander.
Le dossier n’est pas écrit en fin de chantier : il est extrait de ce qui a été renseigné au fil de l’eau. Ce qui manque se voit immédiatement, tant que les équipes sont encore là.
Trois ans plus tard, le technicien scanne le tableau, retrouve la référence exacte et commande la bonne pièce. La donnée saisie au relais 4 est celle du relais 1.
Un cycle de la donnée ne casse jamais par accident. Il casse toujours par une de ces quatre causes, et chacune a son remède dans une autre section du site.
L’information existe mais dans un format que le suivant ne peut pas lire. Le PDF est le tueur numéro un du cycle de la donnée.
Le champ est rempli, mais chacun y met autre chose. Sans nommage ni classification partagés, la donnée circule sans être comprise.
Personne n’a été désigné pour renseigner l’information au bon moment, alors tout le monde suppose que quelqu’un d’autre le fera.
L’information est demandée trop tard, quand celui qui la détenait a quitté le projet. Le récolement de dernière minute en est le symptôme.
Ces quatre ruptures sont exactement ce que l’ISO 19650 cherche à empêcher : un format commun (l’IFC), un vocabulaire commun (les conventions de nommage), une responsabilité explicite (les matrices de rôles) et un calendrier de livraison de l’information. La norme n’est pas une contrainte administrative : c’est la liste des remèdes.
Vous n’avez pas besoin d’être BIM manager pour utiliser ce fil rouge. Ces trois questions suffisent à révéler où votre projet perdra de l’information.
Devant n’importe quelle information (une référence produit, une surface, une date, une performance thermique), posez ces trois questions dans l’ordre :
Ce fil rouge est le plan du site. Les normes organisent le flux, les processus le mettent en œuvre, les logiciels l’outillent, et l’interopérabilité traite précisément des relais où l’information change d’outil. Si vous ne deviez lire qu’un guide après celui-ci, prenez l’ISO 19650 : vous y reconnaîtrez, sous un vocabulaire normatif, exactement les mécanismes décrits ici. Et pour la même démonstration menée sur une exigence contractuelle plutôt que sur une donnée, de bout en bout à travers les cinq pièces d’une opération, voyez l’étude de cas.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Trois personnes disent « on fait du BIM » et parlent de trois choses différentes, sans s'en apercevoir. Ce guide démêle d'abord ce malentendu, puis montre ce qui distingue réellement un objet de maquette d'une forme en 3D, et ce que la méthode ne résoudra pas.
La norme dont tout le monde parle, expliquée sans jargon : qui demande quoi, qui livre quoi, et comment l'information est validée avant d'être partagée. Après ce guide, l'ISO 19650 ne vous impressionnera plus.
Arrêtez de subir les 13 onglets : ce guide vous montre à quoi sert chaque module, comment ils s'alimentent entre eux, et la différence décisive entre l'échéancier (Schedule) et les plans de travail (Plan).