Collaboration BIM : comment organiser le travail entre architectes, ingénieurs et entreprises

Sur un projet complexe, l’architecte, le BET structure, les ingénieurs fluides, les entreprises et la maîtrise d’œuvre ne produisent pas la même information et n’ont pas les mêmes responsabilités. Le BIM ne supprime pas cette séparation : il doit au contraire la rendre explicite et organiser les interfaces entre les disciplines.

Le problème commence lorsque « collaborer » devient synonyme de partager des fichiers. Déposer des maquettes sur une plateforme ne suffit pas. Il faut savoir quelle version peut être utilisée, à quel jalon, pour quel usage, avec quel niveau de fiabilité et qui doit traiter les écarts détectés.

Des modèles métiers séparés plutôt qu’une maquette unique

La maquette unique, éditée librement par toutes les disciplines, est rarement une bonne architecture de projet. Les modèles métiers ont des logiques, des niveaux de détail et des responsabilités différentes. L’architecte contrôle ses éléments architecturaux, le BET structure ses éléments porteurs et les équipes MEP leurs systèmes.

Cette séparation permet de garder une autorité claire sur la donnée source. Une gaine incorrecte doit être corrigée dans la maquette CVC, pas « réparée » dans la maquette fédérée. Un voile structure doit rester sous la responsabilité de l’auteur du modèle structure. La fédération sert à comparer et décider ; elle ne devient pas automatiquement une nouvelle source de production.

Le découpage doit cependant être défini. Selon l’échelle du projet, un modèle peut être séparé par discipline, bâtiment, zone, ouvrage, niveau ou lot. Trop peu de fichiers rendent les modèles lourds et les responsabilités floues ; trop de fichiers multiplient les liaisons, publications et contrôles. Il faut trouver un découpage adapté aux usages et aux performances des outils.

Le CDE : un workflow d’information, pas un disque partagé

L’environnement commun de données ou CDE est l’une des briques de la collaboration BIM. La logique ISO 19650 vise à gérer l’information selon des états et des processus contrôlés. En septembre 2026, ISO 19650-2:2018 reste la norme internationale publiée applicable à la phase de réalisation, même si une nouvelle édition est en cours de développement.

Dans la pratique, l’essentiel est de distinguer ce qui est encore en travail, ce qui est partagé pour coordination, ce qui est publié pour un usage officiel et ce qui est archivé. Une équipe ne devrait pas devoir deviner si le fichier « STR_V15_final_2.rvt » est la bonne référence.

Un CDE utile doit donc gérer au minimum les versions, statuts, responsabilités, droits d’accès et dates de publication. Selon les plateformes, ces mécanismes peuvent être natifs ou nécessiter des conventions projet. Le logiciel n’est qu’une partie du sujet : si les équipes publient sans discipline, le CDE devient un stockage plus propre mais pas un vrai processus de management de l’information.

Avant toute coordination : verrouiller les coordonnées

On parle souvent du clash detection avant de vérifier que les modèles sont correctement positionnés. C’est une erreur. La coordination n’a aucun sens si les maquettes ne partagent pas une stratégie de coordonnées cohérente.

Les équipes doivent savoir quelle référence fait foi : point projet, système topographique, grille ouvrage, altitude de référence et orientation. Sur les projets d’infrastructure ou les opérations multi-bâtiments, ce sujet devient encore plus critique. Une différence d’origine locale ou un mauvais géoréférencement peut produire des modèles apparemment vides ou décalés de plusieurs kilomètres.

Je recommande de valider très tôt un test de fédération simple : un fichier par discipline, quelques éléments connus, des points de contrôle et une vérification indépendante dans l’outil de coordination. Cette mobilisation initiale est beaucoup moins coûteuse qu’une correction après plusieurs mois de production.

Le cycle réel de coordination BIM

Une coordination efficace fonctionne comme une boucle. Les équipes produisent leurs modèles, réalisent un contrôle interne, publient une version destinée à la coordination, puis le coordinateur BIM assemble les modèles et exécute les contrôles prévus. Les sujets pertinents sont ensuite qualifiés, attribués et suivis jusqu’à leur résolution.

Cette boucle semble évidente, mais beaucoup de projets sautent le contrôle interne. Résultat : la coordination centrale devient un service de nettoyage de problèmes qui auraient pu être détectés dans chaque équipe. Le coordinateur passe alors son temps à signaler des doublons, objets temporaires, réservations non mises à jour ou paramètres manquants au lieu de traiter les interfaces entre disciplines.

Clash detection : détecter moins, mais mieux

La détection de collisions est utile lorsqu’elle répond à des règles compréhensibles. Un test global « tout contre tout » génère rarement une information exploitable. Les contrôles doivent être organisés par familles de conflits : structure contre réseaux principaux, réservations contre porteurs, équipements contre zones de maintenance, réseaux entre disciplines, enveloppe contre éléments techniques, etc.

Les tolérances doivent également être adaptées. Une collision dure n’est pas la même chose qu’une distance de maintenance insuffisante. Une gaine passant à 5 mm d’un plafond n’a pas le même niveau de criticité qu’un collecteur traversant une poutre principale. Le moteur de clash détecte une relation géométrique ; c’est le projet qui détermine si elle devient un problème.

La maturité d’une coordination ne se mesure donc pas au nombre de clashs trouvés ou fermés. Elle se mesure plutôt à la capacité de transformer les écarts significatifs en décisions rapides, traçables et vérifiables.

BCF : communiquer un problème sans envoyer toute la maquette

Le BIM Collaboration Format est particulièrement utile dans cette boucle. buildingSMART définit BCF comme un standard openBIM destiné à communiquer des issues et autres sujets liés aux modèles. Il existe sous forme d’échange de fichiers ou via une API REST permettant de synchroniser les sujets entre plateformes.

Un sujet BCF peut contenir le contexte d’un problème, une vue, un snapshot, des coordonnées et des références vers des objets BIM via leurs GUID IFC. L’intérêt est important : au lieu d’envoyer une capture d’écran avec « voir collision en local technique », on transmet un sujet structuré pouvant replacer l’utilisateur au bon endroit et identifier les objets concernés.

BCF ne remplace pas IFC. L’IFC transporte le modèle et ses données ; le BCF transporte la discussion et le suivi autour de ce modèle. Les deux standards répondent à des besoins complémentaires.

Un bon issue management est plus important qu’une réunion de synthèse

La réunion de coordination reste utile, mais elle ne doit pas être l’endroit où l’on découvre pour la première fois tous les problèmes. Les sujets doivent être préparés, filtrés et attribués en amont. La réunion sert alors à arbitrer les cas qui nécessitent une décision entre plusieurs acteurs.

Chaque issue doit avoir suffisamment d’information pour être actionnable : description claire, localisation, discipline responsable, priorité, statut, échéance et éventuellement référence aux éléments concernés. À l’inverse, trop de champs obligatoires transforment la création d’un sujet en procédure administrative.

Les statuts doivent rester simples. Par exemple : ouvert, en cours, à vérifier, fermé, éventuellement rejeté ou doublon. Des statuts trop fins rendent les tableaux de bord impressionnants mais rarement plus efficaces.

Coordination ne veut pas dire transfert de responsabilité

Le BIM peut donner l’impression que le coordinateur devient responsable de tout ce qu’il voit dans la maquette fédérée. Ce n’est pas souhaitable. La coordination identifie et organise les interfaces, mais chaque discipline reste responsable de sa conception et de ses livrables selon son périmètre contractuel.

La convention BIM doit donc préciser qui produit, qui contrôle, qui peut créer ou fermer une issue, qui arbitre les conflits de conception et quels livrables sont utilisés pour les décisions. Ces règles doivent rester cohérentes avec les contrats et responsabilités métiers ; le BIM ne doit pas inventer une chaîne d’autorité parallèle.

La collaboration porte aussi sur les données

Une coordination 3D réussie peut masquer une mauvaise collaboration informationnelle. Deux maquettes peuvent être géométriquement compatibles mais utiliser des codifications différentes, des systèmes de classification incohérents ou des propriétés incompatibles.

Les contrôles doivent donc inclure la structure des données. Par exemple, une entreprise peut recevoir un modèle géométriquement correct mais impossible à filtrer parce que les systèmes MEP sont mal renseignés. Un exploitant peut recevoir des équipements parfaitement modélisés mais sans identifiant stable permettant de les rattacher à sa GMAO.

C’est ici que le management de l’information rejoint directement la coordination. Les équipes doivent partager non seulement une géométrie compatible, mais aussi un langage commun suffisamment structuré pour les usages attendus.

Collaboration propriétaire ou openBIM ?

Un projet homogène peut choisir une chaîne principalement propriétaire, par exemple plusieurs équipes Revit coordonnées dans des outils Autodesk. Cette architecture peut être efficace si tous les acteurs disposent des mêmes versions, compétences et droits d’accès.

Un projet multi-éditeurs s’appuie davantage sur les standards openBIM, notamment IFC pour les modèles et BCF pour les issues. Cela évite de rendre la collaboration entièrement dépendante d’un format natif, mais demande davantage de rigueur sur les exports, mappings et contrôles.

Il n’y a pas besoin d’opposer systématiquement les deux approches. Beaucoup de projets fonctionnent en hybride : fichiers natifs pour certaines productions internes, IFC pour les échanges contractuels ou multi-outils, BCF ou une plateforme d’issues pour la coordination. L’important est que le format choisi corresponde à l’usage et que les pertes d’information soient connues et contrôlées.

Les erreurs que je retrouve le plus souvent

La première est de lancer la coordination trop tard. Lorsque les modèles sont déjà très détaillés, modifier un réseau ou une trame structure coûte beaucoup plus cher. La deuxième est de publier des modèles sans contrôle interne. La troisième est de conserver des clashs pendant des semaines sans responsable clair.

Je retrouve aussi fréquemment des sujets non reproductibles : capture d’écran sans coordonnées, commentaire sans référence de modèle, issue liée à une version obsolète. Enfin, certaines équipes traitent la fédération comme une vérité absolue alors qu’elle peut contenir des fichiers de dates différentes ou des exports incomplets.

Le remède est rarement un nouvel outil. Il faut d’abord sécuriser les publications, les identifiants, les responsabilités et le cycle de vérification.

Quels indicateurs suivre ?

Les KPI de coordination doivent rester orientés vers l’action. Le nombre total d’issues n’est pas très intéressant seul. Il vaut mieux observer les sujets critiques ouverts, leur ancienneté, le taux de réouverture, les disciplines qui concentrent les interfaces non résolues et le respect des échéances de publication.

Un autre indicateur utile est la part des anomalies détectées par l’équipe métier avant la fédération. Si le coordinateur central continue à découvrir des erreurs élémentaires de modélisation, le processus de contrôle interne doit être renforcé.

Conclusion

Le BIM facilite réellement la collaboration lorsqu’il donne aux équipes un cadre commun pour produire, publier, contrôler et corriger leurs informations. La maquette fédérée n’est qu’une étape de cette chaîne.

Une collaboration robuste repose sur des modèles métiers avec des responsabilités claires, un CDE structuré, des coordonnées maîtrisées, des contrôles proportionnés et un système d’issues capable de suivre chaque décision jusqu’à sa résolution. IFC et BCF deviennent alors des outils d’interopérabilité au service du processus, pas des fins en soi.