On le prend pour un fichier, souvent pour « un tableur », et on passe à côté. COBie ne dit pas comment livrer, il dit quelles données l'exploitant doit recevoir. Et avant de l'écrire dans un cahier des charges, il y a une question de version à trancher.
C’est la réaction la plus fréquente quand quelqu’un ouvre un livrable COBie pour la première fois. Elle est compréhensible, et elle rate complètement le sujet.
Ce qu’on regarde alors, c’est une forme de livraison, pas le standard. COBie ne définit pas un fichier : il définit quelles informations doivent être transmises à l’exploitation, sur quels objets, et sous quelle structure. Que cette structure arrive dans un tableur, dans un fichier IFC ou en XML est une question secondaire.
L’analogie utile est celle d’une liste de courses. Elle ne dit ni dans quel magasin aller ni comment porter les sacs : elle dit ce qu’il faut rapporter. Reprocher à COBie d’être un tableur revient à reprocher à une liste de courses d’être écrite sur un bout de papier.
Le problème de la livraison de données d’exploitation. Sans structure convenue, chaque projet remet ce qu’il veut, dans le format qui l’arrange, et l’exploitant ressaisit. COBie fournit une structure partagée, indépendante des logiciels d’émission comme de réception, et donc vérifiable.
Le standard organise l’information autour de ce dont un gestionnaire de patrimoine a réellement besoin. Pas de géométrie, ou très peu : des objets, leurs caractéristiques et ce qui les relie.
Le découpage spatial de l’ouvrage : bâtiments, étages, locaux, zones. C’est l’ossature à laquelle tout le reste se rattache, exactement comme dans un fichier IFC.
Les types et les occurrences : un modèle de centrale de traitement d’air d’un côté, les trois unités réellement posées de l’autre, chacune située dans un local.
Ce qui relie les équipements entre eux : réseaux, circuits, ensembles fonctionnels. Sans cela, on a un inventaire, pas une compréhension du bâtiment.
Ce qui permet de maintenir : documents, garanties, pièces détachées, tâches de maintenance et attributs libres pour le reste.
COBie ne demande presque pas de géométrie. C’est déroutant pour qui associe le BIM à la maquette 3D, et parfaitement logique : un technicien de maintenance a besoin de savoir quel équipement se trouve où, de quelle référence, sous quelle garantie. La forme exacte du carter ne l’intéresse pas.
La même information peut être livrée sous trois habillages. Le choix a des conséquences pratiques, pas sémantiques.
Le tableur est la forme la plus répandue et la plus mal comprise. Son mérite est considérable : n’importe qui peut l’ouvrir, le lire, le trier et le vérifier, sans logiciel spécialisé ni compétence BIM. C’est précisément ce qui permet à un service de maintenance de contrôler ce qu’il reçoit. Son défaut est symétrique : il se modifie à la main, donc il diverge de la maquette dès la première correction.
La forme IFC garde le lien avec le modèle et convient quand la chaîne outillée existe des deux côtés. La forme XML sert surtout aux échanges entre systèmes.
Si le livrable COBie est produit à partir de la maquette à chaque jalon, le tableur reste cohérent et son ouverture universelle devient un atout. S’il est rempli à la main une fois pour toutes, il devient un document mort, et sa facilité d’édition se retourne contre le projet.
Écrire « livraison au format COBie » dans un cahier des charges sans préciser la version est une imprudence. Voici pourquoi.
La version de référence est ancrée dans une annexe nationale britannique. Rien ne garantit qu’un équivalent existe dans votre pays. Vous ne pouvez donc pas vous appuyer sur un renvoi implicite : précisez la version dans votre propre cahier des charges, ainsi que la forme de livraison et les objets concernés.
Le scénario se répète partout : la livraison arrive, quelqu’un remplit un tableur en trois semaines, l’exploitant le range, et personne ne l’ouvre jamais.
Demandez des livraisons intermédiaires, même incomplètes. Un COBie livré à la fin ne se contrôle plus : les équipes qui détenaient l’information ont quitté le projet, et il ne reste qu’à constater les trous. Un COBie livré trois fois pendant le chantier se corrige encore.
Ce mot seul n’engage à rien de précis. Ces cinq points le rendent opposable.
Le livrable dans lequel tout ceci atterrit est traité dans le DOE numérique : c’est là que se joue concrètement la réussite ou l’échec de la remise. D’où vient l’exigence : de vos besoins d’information de patrimoine, expliqués dans OIR, AIR, PIR, EIR. Comment la formuler : rédiger un EIR. Et le format qui peut porter ces données en gardant le lien avec la maquette : le format IFC, qu’un service de maintenance peut ouvrir sans licence grâce aux visionneuses IFC gratuites.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Quatre cents PDF sur un disque dur, contractuellement irréprochables et pratiquement morts. Le problème n'est pas le format : c'est qu'un dossier produit à la fin est une reconstitution, faite par quelqu'un qui n'était pas là quand l'information existait.
Quatre sigles qui ressemblent à de la bureaucratie normative, et qui répondent pourtant à une question très concrète : d'où vient cette exigence, et qui a le droit de la changer ? Comprendre la chaîne, c'est cesser de réinventer ses besoins à chaque projet.
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.