Les étapes clés d’un projet BIM réussi

Sur les projets où le BIM fonctionne bien, les maquettes ne sont pas le point de départ. Le point de départ est le besoin : quelles décisions faut-il prendre, quelles informations seront nécessaires pour les prendre, qui doit les produire et comment vérifier qu’elles sont exploitables ? À l’inverse, beaucoup de projets se compliquent parce que l’on commence par modéliser, puis que l’on essaie ensuite de définir les règles autour de modèles déjà engagés.

La série ISO 19650 structure précisément le BIM comme un processus de management de l’information. L’ISO 19650-2:2018 traite la phase de réalisation des actifs et décrit un processus applicable à différents types et tailles de projets. Elle ne donne pas une recette universelle à recopier : elle fournit un cadre qu’il faut adapter à la complexité réelle du projet.

Les 8 étapes à structurer

Dans la pratique, je regroupe le démarrage et le pilotage d’un projet BIM en huit étapes. Elles ne sont pas totalement séquentielles : certaines sont révisées pendant le projet, mais l’ordre reste important. On ne devrait par exemple pas définir un niveau d’information détaillé avant d’avoir compris l’usage auquel il répond.

1. Commencer par les objectifs, pas par la maquette

La première erreur est de démarrer un projet BIM avec une liste d’outils : Revit pour la production, Navisworks pour la coordination, une plateforme cloud pour les échanges. Ces choix ont leur importance, mais ils viennent après la définition des objectifs.

Un usage BIM doit être relié à une décision ou à un besoin concret. « Faire de la coordination 3D » est encore trop vague. Veut-on réduire les collisions entre structure et lots techniques avant exécution ? vérifier les réservations ? préparer des zones de préfabrication ? sécuriser l’encombrement des locaux techniques ? Le niveau de modélisation, la fréquence des échanges et les tolérances de contrôle ne seront pas les mêmes.

La même logique vaut pour les données. Si un maître d’ouvrage demande une propriété « fabricant » dès l’APS alors que le fabricant n’est pas encore choisi, l’exigence est mal positionnée dans le temps. À l’inverse, demander cette information pour le DOE peut être parfaitement pertinent.

Avant d’écrire une convention BIM, je cherche donc à établir une matrice simple : usage → décision → information nécessaire → producteur → échéance → contrôle. Cette chaîne évite une grande partie des paramètres inutiles et des exigences impossibles à tenir.

2. Transformer les besoins en exigences d’information

Une fois les objectifs établis, il faut les traduire en exigences vérifiables. Dans la logique ISO 19650, les besoins d’information s’organisent à plusieurs niveaux. Pour la phase projet, les notions de PIR (Project Information Requirements) et d’EIR (Exchange Information Requirements) sont centrales : les premières cadrent les besoins d’information du projet, les secondes précisent ce qui doit être fourni lors d’un échange.

Dans un projet français, les termes employés ne sont pas toujours ceux de la version anglaise de l’ISO. On trouve des cahiers des charges BIM, chartes BIM, annexes de données, tableaux d’attributs ou matrices de livrables. Ce qui compte n’est pas le nom du document mais son caractère opérationnel.

Une exigence exploitable doit pouvoir être contrôlée. « Les objets doivent être correctement renseignés » n’est pas une exigence. « Chaque IfcDoor livrée au jalon X doit posséder l’identifiant projet, le code de type et la propriété de résistance au feu selon la table Y » est déjà beaucoup plus vérifiable.

3. Définir les responsabilités de production et de management de l’information

Le BIM crée facilement des zones grises : qui corrige une classification incohérente ? qui valide les coordonnées ? qui décide si un clash est acceptable ? qui contrôle le fichier avant publication ? qui autorise le passage d’un livrable vers un état publié ?

Ces responsabilités doivent être établies avant que les problèmes apparaissent. L’ISO 19650 raisonne en fonctions et responsabilités de management de l’information plutôt qu’en imposant un intitulé de poste unique. C’est important : un projet n’a pas besoin d’inventer un nouveau « BIM quelque chose » pour chaque action. Il doit surtout savoir qui est responsable de quoi.

Sur un projet de taille moyenne, une matrice de responsabilités bien tenue est souvent plus utile qu’un organigramme BIM très graphique. Pour chaque activité sensible, il faut identifier le producteur, le responsable du contrôle, l’autorité de validation et le destinataire de l’information.

Je recommande également de séparer autant que possible production et contrôle. La personne qui modélise peut réaliser des contrôles de premier niveau, mais certains jalons doivent être vérifiés par une fonction différente, en particulier lorsqu’un livrable est destiné à contractualiser une décision ou à être utilisé par une autre équipe.

4. Mettre en place la convention BIM et le CDE

La convention BIM est utile lorsqu’elle transforme les exigences en règles de travail. Elle doit notamment traiter les sujets qui provoquent réellement des incompatibilités : découpage des modèles, coordonnées et géoréférencement, conventions de nommage, unités, classifications, niveaux d’information, formats d’échange, règles IFC, fréquence de publication, contrôles et procédures de coordination.

Le document doit rester proportionné. Une convention de 150 pages n’est pas plus mature qu’une convention de 30 pages si personne n’arrive à retrouver la règle applicable. Les tableaux, exemples, schémas de flux et annexes de données sont souvent plus efficaces que les longs paragraphes génériques.

Le CDE, ou environnement commun de données, doit être conçu comme un workflow et non comme un simple espace de stockage. La logique ISO 19650 distingue des états d’information permettant notamment de séparer le travail en cours, l’information partagée, l’information publiée et l’archive. Le principe est essentiel : un fichier présent sur une plateforme ne doit pas automatiquement être considéré comme validé pour utilisation.

En pratique, il faut définir les droits, les statuts, les versions, les conventions de nommage, le processus de revue et les règles de publication. Sans cela, le CDE devient rapidement un disque partagé avec une interface web.

5. Mobiliser les outils et tester les workflows avant la production massive

La mobilisation est souvent sous-estimée. Pourtant, quelques tests réalisés au démarrage évitent des semaines de correction plus tard. Avant d’industrialiser la production, les équipes doivent valider les gabarits, paramètres, coordonnées, arborescences, méthodes de liaison, exports, nomenclatures et procédures de contrôle.

Sur un projet Revit, je considère comme indispensable de tester très tôt le géoréférencement et les liaisons entre disciplines. Une erreur de coordonnées détectée après plusieurs mois ne se corrige jamais aussi facilement qu’au démarrage. Même chose pour les unités, niveaux, zones, phases et conventions de nommage.

Pour un workflow openBIM, il faut également faire un premier échange IFC très tôt. Attendre le premier jalon contractuel pour vérifier l’export est une mauvaise stratégie. Le test doit contrôler au minimum les classes IFC, la géométrie, les identifiants, les Property Sets attendus, la position du modèle et la lecture dans l’outil destinataire.

Cette phase est aussi le bon moment pour vérifier les capacités réelles des équipes et des logiciels. Une règle parfaite sur le papier mais impossible à produire ou contrôler avec les outils disponibles devra être adaptée avant généralisation.

6. Planifier la production et les échanges d’information

Une fois les règles validées, il faut planifier les livrables. La logique ISO 19650 utilise notamment les TIDP (Task Information Delivery Plans) pour détailler les productions attendues des équipes de tâche et le MIDP (Master Information Delivery Plan) pour consolider les plans de livraison au niveau de l’équipe de production.

Il n’est pas nécessaire de transformer cela en usine documentaire. L’objectif est simple : savoir quels conteneurs d’information seront produits, par qui, à quel moment et pour quelle échéance. Selon le projet, cela peut être géré dans un tableau, un outil de planification ou une base de données.

Le planning de production doit surtout être cohérent avec le planning réel du projet. Une maquette structure nécessaire à la coordination CVC doit être partagée avant la réunion de synthèse, pas trois jours après. Les dates de production BIM n’ont de sens que si elles soutiennent les décisions du projet.

Il faut aussi distinguer les échanges intermédiaires de coordination et les livrables officiels. Les premiers peuvent être fréquents et pragmatiques ; les seconds nécessitent généralement des contrôles plus stricts, une validation formelle et une traçabilité renforcée.

7. Organiser coordination BIM et contrôle qualité

La coordination BIM ne se résume pas au clash detection. Le contrôle géométrique est important, mais un modèle peut être parfaitement coordonné en 3D et rester inutilisable parce que ses données sont incohérentes.

Je sépare généralement les contrôles en plusieurs familles : géométrie et interférences, structure du modèle, règles de nommage, coordonnées, classification, propriétés obligatoires, valeurs autorisées, cohérence entre paramètres, export IFC et conformité aux exigences du jalon.

Ces contrôles doivent être reproductibles. Si le résultat dépend uniquement de la personne qui ouvre la maquette et regarde « si tout semble bon », la qualité est fragile. Il faut privilégier des règles documentées, des vues ou nomenclatures de contrôle, des scripts, des règles IFC ou des outils capables de rejouer les mêmes vérifications à chaque version.

La gestion des anomalies est tout aussi importante que leur détection. Un clash ou une propriété manquante doit pouvoir être attribué, commenté, priorisé, corrigé puis fermé. Les workflows BCF sont particulièrement adaptés à ce type de suivi lorsqu’ils sont bien intégrés aux outils de coordination.

8. Contrôler le jalon avant de livrer

La livraison ne devrait jamais être une simple copie du dossier de travail vers un dossier « final ». Un échange d’information doit comporter une vérification adaptée à son usage. L’ISO 19650-4:2022 développe précisément le processus d’échange d’informations et les critères de décision destinés à assurer la qualité du modèle d’information résultant.

Avant chaque jalon, il faut donc exécuter un contrôle de conformité : présence des fichiers attendus, version, nommage, statut, coordonnées, géométrie, données, format, liens ou références nécessaires, rapport de contrôle et éventuelles dérogations acceptées.

La notion de critère d’acceptation est fondamentale. Un fichier n’est pas conforme simplement parce qu’il a été livré. Le projet doit savoir ce qui entraîne une acceptation, une acceptation avec réserve ou un rejet. Sans seuil clair, les contrôles deviennent des débats à chaque échéance.

Pour un DOE numérique ou un modèle destiné à l’exploitation, le contrôle doit se concentrer sur l’information réellement utile à l’exploitant : identifiants, localisation, caractéristiques maintenables, références documentaires, statut des équipements et correspondance avec le réalisé. Le modèle de conception ne devient pas automatiquement un bon modèle d’exploitation.

Le projet BIM est une boucle, pas une procédure figée

Après un jalon, les écarts observés doivent servir à ajuster le processus. Une règle incomprise par trois équipes n’est peut-être pas assez claire. Un paramètre constamment vide peut être demandé trop tôt. Un contrôle générant 80 % de faux positifs doit être recalibré. Une exportation IFC instable mérite un réglage ou un protocole de test spécifique.

Le management BIM consiste aussi à réduire progressivement ces frictions. Une convention doit pouvoir évoluer, les plans de livraison doivent être actualisés et les contrôles doivent suivre les changements du projet. Il faut toutefois conserver la traçabilité des décisions : modifier une règle sans documenter la date et les impacts crée rapidement des incohérences entre versions.

Les erreurs que je rencontre le plus souvent

La première est de définir le BIM trop tard, lorsque la production est déjà engagée. La deuxième est de rédiger des exigences beaucoup plus détaillées que les usages réels. La troisième est de vouloir contrôler à la fin ce qui aurait pu être contrôlé automatiquement chaque semaine.

Je vois aussi régulièrement des projets où le CDE sert uniquement au dépôt de fichiers, où la coordination ne produit aucune issue traçable, où les exports IFC ne sont testés qu’au moment du rendu et où le DOE est préparé dans les dernières semaines. Dans tous ces cas, le problème principal n’est pas l’outil : c’est l’ordre dans lequel le processus a été construit.

Une autre erreur fréquente consiste à vouloir imposer la même maturité BIM à tous les lots sans tenir compte de leur périmètre et de leurs capacités. L’ISO 19650 prévoit une application proportionnée à la taille et à la complexité de l’actif ou du projet. Cette proportionnalité est essentielle : trop de procédure tue autant la qualité qu’un manque total de règles.

Le socle minimal que je chercherais à sécuriser

Si je devais reprendre un projet BIM en cours avec peu de temps, je ne commencerais pas par refaire tous les documents. Je sécuriserais d’abord six points : les usages prioritaires, les responsabilités, les coordonnées, les livrables attendus, le workflow CDE et les contrôles de qualité critiques.

Ensuite seulement, j’industrialiserais les détails : matrices de données, règles IFC, automatisations, dashboards, scripts de contrôle et reporting. Cette hiérarchie est importante. Automatiser un processus mal défini permet uniquement de produire plus vite des résultats incohérents.