Dire « il y a un problème ici » suppose de désigner un ici. Envoyer la maquette est absurde, envoyer une capture perd la position. Le BCF résout exactement ce point, et c'est pour cela qu'il tient dans quelques kilo-octets.
Prenons comme exemple une gaine de ventilation qui traverse une poutre au niveau 2. Vous devez le signaler au bureau d’études structure. Comment lui montrez-vous de quoi vous parlez ?
Trois réflexes existent, et aucun ne fonctionne bien. Lui envoyer la maquette est disproportionné : plusieurs centaines de mégaoctets pour signaler une intersection, et il devra la charger, la naviguer et retrouver l’endroit lui-même. Lui envoyer une capture d’écran perd la position : il voit le problème mais doit le retrouver à la main dans son propre modèle. Lui décrire l’endroit par écrit transforme la remarque en devinette, surtout sur un plateau où tout se ressemble.
Le BCF résout précisément ce point, et rien d’autre. Il transporte la désignation d’un endroit et d’objets précis, plus la conversation qui s’y rattache, sans transporter le modèle. D’où sa légèreté : quelques kilo-octets pour une remarque que personne ne peut mal situer.
Le BCF ne transporte pas un modèle, il transporte un pointeur et une conversation. C’est un format de communication greffé sur l’IFC, pas un format de description d’ouvrage. Les deux se complètent et ne se remplacent jamais.
Un fichier BCF est une archive légère. Voici les quatre choses qu’elle transporte, et ce que chacune permet.
Les deux montrent la même chose à l’écran. Ce qui les sépare, c’est tout ce qui se passe après l’envoi.
Ce n’est pas le confort de la navigation, c’est la suppression du tableur de suivi. Dans la plupart des projets, quelqu’un tient à la main une liste des points ouverts, qui diverge des échanges réels en quelques semaines. Le BCF fait disparaître ce travail et cette divergence.
C’est le point qui n’est presque jamais expliqué, et qui explique pourtant la plupart des BCF qui « ne marchent plus ».
Une remarque BCF ne contient pas les objets, elle les désigne par leur identifiant unique dans le fichier IFC. Tant que cet identifiant reste le même d’une livraison à l’autre, la remarque continue de pointer sur le bon objet, y compris après correction et réexport.
Si l’identifiant change, le lien se casse. La remarque existe toujours, avec son texte et son point de vue, mais elle ne sélectionne plus rien : le destinataire retrouve la vue et doit désigner l’objet à la main. Sur un projet qui compte des centaines de remarques, cette rupture rend le suivi inexploitable en un cycle.
Les identifiants doivent être stables entre deux exports du même modèle. Testez-le tôt : exportez, créez une remarque, réexportez après une modification mineure, et vérifiez que la remarque désigne toujours le bon objet. Un projet qui découvre ce problème au troisième cycle a déjà perdu son historique de coordination.
Le format n’a d’intérêt que par le cycle qu’il permet. Voici les cinq états par lesquels passe une remarque utile.
La remarque naît dans l’outil d’analyse ou de visualisation, avec sa vue et les objets concernés. Une remarque sans objet désigné perd la moitié de son intérêt.
Un nom et une échéance. Une remarque adressée à « la structure » n’appartient à personne et attendra la prochaine réunion pour exister.
Le destinataire accepte, conteste ou demande une précision, dans la remarque elle-même. C’est ce qui évite que la décision se perde dans les courriels.
La correction se fait chez le producteur, jamais dans le fichier fédéré ni dans le BCF, qui ne modifie aucun modèle.
Le cycle suivant confirme que le problème a disparu. Fermer sans vérifier est la façon la plus courante de faire réapparaître un sujet trois mois plus tard.
Le format existe sous deux formes, qui ne s’adressent pas aux mêmes situations.
Le fichier, une archive que l’on exporte et que l’on envoie, fonctionne partout et avec n’importe qui. C’est la voie universelle, celle qui ne suppose aucune plateforme commune ni aucun compte à créer. Son défaut est celui de tout échange asynchrone : deux personnes peuvent travailler en parallèle sur la même remarque et produire deux versions divergentes du fil de discussion.
Le serveur, où les remarques vivent dans un service partagé auquel chaque outil se connecte, supprime ce risque : tout le monde voit le même état en temps réel. En contrepartie, il suppose que tous les intervenants accèdent à la même plateforme, ce qui n’est pas toujours acquis avec des partenaires occasionnels.
Serveur pour le noyau d’équipes qui coordonnent chaque semaine, fichier pour les intervenants ponctuels. Ce qui compte est de décider lequel fait foi : deux canaux en parallèle sans hiérarchie déclarée produisent exactement le désordre que le format devait supprimer.
Il rend les remarques transportables et suivables. Il ne décide rien, ne hiérarchise rien, et n’organise personne.
Un projet qui adopte le BCF sans changer sa façon de travailler produit simplement des remarques mieux formatées, et toujours autant. Le format ne fait pas le tri entre l’anodin et le bloquant, ne groupe pas deux cents occurrences d’un même sujet, et ne désigne pas d’arbitre en cas de désaccord. Ces questions relèvent du processus, traité dans le guide sur la clash detection et dans celui sur la coordination.
Voici les erreurs qui reviennent le plus souvent.
Le sujet localisé, assigné et refermé n’existe pas qu’en coordination : c’est exactement la mécanique d’une réserve de chantier, décrite dans le suivi de chantier numérique.
Le format que le BCF accompagne est traité dans IFC, le format qui fait tenir tout l’openBIM. L’usage qui en produit le plus est décrit dans clash detection, et le rythme dans lequel ces remarques circulent dans la coordination BIM.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Quarante mille conflits détectés, et pas une décision prise. La détection automatique est la partie facile : toute la valeur est dans ce qu'on filtre, ce qu'on arbitre et ce qui revient dans la maquette. Voici la boucle complète.
Beaucoup d'équipes appellent « coordination » le rendez-vous du jeudi. C'est la partie visible, et la moins déterminante. Ce qui fait tenir une coordination, c'est un cycle, une autorité et une clôture. Voici le processus complet, du gel des maquettes au procès-verbal.
Non, l'IFC n'est pas « le PDF de la maquette ». C'est une base de données structurée qui transporte vos objets et leurs propriétés d'un logiciel à l'autre. Comprendre ce qu'il contient vraiment, c'est arrêter de subir les exports ratés.