Assembler le meilleur outil de chaque catégorie produit rarement la meilleure chaîne. Ce qui coûte cher n'est pas le nombre de logiciels, c'est le nombre d'endroits où l'information doit changer de main. Voici comment concevoir une chaîne au lieu de la subir.
La méthode habituelle consiste à choisir le meilleur logiciel de chaque catégorie : le meilleur modeleur, le meilleur outil de coordination, la meilleure plateforme, le meilleur outil de métré. Chaque décision est défendable, et le résultat ne fonctionne pas.
La raison est simple à énoncer et difficile à admettre : on n’utilise jamais un outil isolément. Entre chacun d’eux, l’information doit changer de main, et chaque passage est un endroit où elle perd du sens, des propriétés, ou sa fraîcheur. Sept outils excellents, cela fait au minimum six jonctions, et c’est là que se joue la qualité réelle de votre production.
Une chaîne d’outils ne vaut donc pas la moyenne de ses composants. Elle vaut sa pire jonction. Un modeleur remarquable dont les données meurent au premier export ne vous apporte rien de plus qu’un modeleur médiocre, et vous avez payé la différence.
Cessez de comparer des logiciels, commencez à cartographier des flux. La question n’est pas « quel est le meilleur outil de coordination », mais « qu’est-ce qui entre dans cet outil, qu’est-ce qui en sort, et qu’est-ce qui survit au trajet ».
Devant un projet de chaîne, dessinez le trajet de l’information plutôt que la liste des logiciels. Le dessin révèle immédiatement ce que la liste cache.
Chaque jonction se paie de trois façons : un temps de manipulation à chaque cycle, une perte d’information plus ou moins maîtrisée, et un risque d’erreur humaine, puisque quelqu’un doit lancer l’opération et vérifier le résultat. Multipliez par le nombre de cycles d’un projet, et la facture réelle apparaît.
À bénéfice équivalent, la chaîne la plus courte gagne. Ajouter un outil parce qu’il fait mieux une chose ne se justifie que si le gain dépasse le coût permanent de la jonction supplémentaire. Cette comparaison-là n’est presque jamais faite.
Deux logiciels peuvent communiquer de quatre manières très différentes. Savoir laquelle vous employez détermine ce que vous pouvez en attendre.
Un aller-retour dans une chaîne signale presque toujours un problème d’organisation avant d’être un problème technique. Demandez-vous qui devrait être propriétaire de cette donnée. Si la réponse est claire, l’aller-retour disparaît de lui-même : l’information part, et ce qui revient n’est plus la donnée mais une remarque.
Les deux méthodes produisent des listes d’outils qui se ressemblent. Elles ne produisent pas du tout les mêmes projets.
Devant une proposition d’outil, posez trois questions : qu’est-ce qui entre, qu’est-ce qui sort, et qui vérifie que le passage s’est bien fait. Si votre interlocuteur ne répond qu’à la première, il vous vend une fonctionnalité, pas une place dans votre chaîne.
Elle se mène une fois pour l’organisation, puis s’ajuste par projet. Chaque étape produit un document réutilisable.
Listez ce que vous devez remettre et ce que le client doit pouvoir en faire. On conçoit une chaîne à l’envers, depuis la sortie, jamais depuis le logiciel de modélisation.
Dessinez le parcours de l’information, de sa création à son usage final. Le dessin fait apparaître les boucles et les impasses qu’une liste d’outils masque complètement.
Pour chacune, notez son type parmi les quatre, sa fréquence dans un cycle, et qui la déclenche. Une jonction sans responsable désigné finira par être oubliée.
Faites passer un fragment de projet réel dans chaque jonction, pas un fichier de démonstration. Vérifiez ce qui arrive de l’autre côté, propriétés comprises.
Le résultat du test devient une fiche par jonction. C’est le document le plus utile de tout l’exercice, et celui que personne ne rédige.
Formats, versions, réglages d’export et responsables entrent dans la convention BIM. Sans cela, la chaîne testée n’est qu’un souvenir de la personne qui l’a testée.
Elles se ressemblent : toutes reviennent à décider d’un outil sans avoir regardé ce qui le relie au reste.
Le choix du modeleur lui-même est traité dans Revit ou Archicad, la jonction entre les deux dans passer de Revit à Archicad, et la jonction la plus fréquente de toutes dans exporter un IFC propre depuis Revit. Pour comprendre ce que transporte réellement le format sur lequel repose la voie ouverte, voyez le format IFC, et pour le débat de fond qui sous-tend tout choix d’outils, openBIM contre closed BIM.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Sur les quatre-vingts pour cent d'usages courants, les deux font le travail. Demander lequel est le meilleur n'a donc pas de réponse. La bonne question est ailleurs : quelle contrainte de votre contexte n'est pas négociable ? Voici une méthode de décision, pas un verdict.
Un export IFC n'est pas un enregistrement, c'est une traduction. Tant que vous ne décidez pas comment Revit traduit, il décide à votre place. Voici les trois réglages qui font 90 % du résultat, et la logique derrière, valable quelle que soit votre version.
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.