Après plusieurs années d’adoption du principe de travail BIM (Building Information Modeling) que l’on peut qualifier comme un bouleversement logique de l’utilisation de l’outil informatique pour la conception du bâtiment (CAO/DAO), il est temps d’accélérer et de doper les technologies supports du BIM.
Un point du BIM 1.
Le porte parole du BIM est sans conteste la plateforme Autodesk Revit (Architecture, Structure, MEP). Cette plateforme offre aujourd’hui la possibilité de concevoir un ouvrage en échangeant des géométries et des informations dans un même format. Chacun des Revit réalisant sa propre maquette, l’enjeu essentiel est la mise à jour des données et de faire des synthèses sur des modèles dont l’état d’avancement est le même.
Chaque Revit propose des outils spécifiques liés aux métiers et aux nécessités des modes de conception. Des spécifications qui limitent les échanges et le travail collaboratif.
Chaque Revit possède son éco-système d’outils : un architecte ne peut pas utiliser des outils de calcul de structure avec Revit Architecture, par exemple. De plus, les méthodes de conception d’un même élément (transversal aux métiers) s’opposent en fonction des exigences métiers.
La maquette numérique d’architecture se confronte à la problématique d’objet unique. Le bâtiment n’est pas le monde industriel où un modèle numérique pilote un grand nombre de modèles physiques. Le temps de conception numérique doit être compensé par des simulations diverses sur le modèle et d’en tirer des informations substantielles d’aide à la prise de décisions.
La pratique du BIM
Le BIM est souvent mal perçu, et il n’est pas rare de voir des pratiques non appropriées au BIM. Les méthodes de dessins traditionnels sont souvent transposées dans la solution BIM, or le passage du dessin à acteur unique ne fonctionne pas dans un processus BIM multi-acteurs. Les flux de travail déficients doivent permettre de repenser les pratiques du BIM mises en place par chacun.
Revit n’est pas un simple modeleur orienté objet…
N’oublions pas que le BIM Revit fait appel à une base de données qui met en relation des informations (données) et des éléments (objets comportementaux) dans un contexte (architectural).
La structure d’un projet BIM
Une des préoccupations les plus importantes est la taille des fichiers et la quantité de données embarquées. Jamais dans l’histoire de conception de bâtiments nous manipulions des fichiers de si grandes tailles. Les fichiers liés et les sous-projets sont certainement une réponse partielle à cette problématique.
Une réflexion préalable sur le développement du projet est nécessaire avant toute saisie de données. Fichiers liés et sous-projets sont les principaux reflets aux contraintes du projet et de ses évolutions futures. Et régulièrement, ces préoccupations feront l’objet de révisions pour ne pas aboutir dans une voie sans issue.
L’éco-système est encore trop peu riche.
La conception d’un bâtiment par ordinateur passe par l’utilisation de plusieurs outils pour chaque intervenant ou spécialiste. La multiplication des échanges altèrent les données, est source de perte de productivité (temps passé aux exports et au formatage des données, re-saisie de données), et augmente les erreurs et oublies. Le manque de capacité de communication entre les outils à l’aide d’un format unique et natif (c’est à dire sans export) est un frein à l’utilisation multidisciplinaire d’une maquette numérique dite BIM.
Il est aujourd’hui difficile de garantir la possibilité de partager l’ensemble des informations saisies sur un projet ; des données forcément utiles devront être re-saisies dans des proportions variables.
Le format IFC est à mon sens pas assez développé pour être utilisé comme format d’interopérabilité.
Autre phénomène, la saisie de certaines données est fastidieuse par rapport aux bénéfices que l’on peut en tirer. Des opérations simples deviennent lourdes à l’aide des outils actuels.
La seule solution (réponse partielle) est l’agrégation des données à travers un outil indépendant des formats. Aujourd’hui, NavisWork joue le rôle de compilateur des données pour principalement les détections de clashs et la planification. Les modifications sont effectuées dans les logiciels d’origines.
Des demandes de plus en plus importantes.
Ceux qui utilisent le BIM deviennent beaucoup plus exigeants face aux outils proposés alors qu’un AutoCAD est pris tel quel sans remise en cause par la collectivité.
La confusion entre informations du projet et capacités des outils à les manipuler déroute les débutants. On se prête vite à rêver d’outils plus performants en terme de manipulation d’informations.
Le monde du bâtiment est vaste et la conception architecturale est multidisciplinaire. Les outils doivent l’être aussi. Or l’offre est aujourd’hui trop limitée dans sa diversité anabolisant la recherche et le développement orientés modèle numérique BIM.
Faut-il oublier l’ergonomie pour facilité une implémentation d’outils plus riches et plus performants ?
Depuis une vingtaine d’années, les éditeurs de logiciels sont sensibles à l’ergonomie et à la facilité d’utiliser les outils informatiques. On ne peut que se réjouir de cette approche. Or nos outils professionnels doivent répondre à des complexités liées aux coutumes de conception et de réalisations qui participent à la richesse de nos constructions. (La problématique est autre dans le monde industriel). Une équation dure à résoudre.
L’interface à rubans, le disque de navigation et le ViewCube facilitent une utilisation quotidienne mais n’enrichissent pas l’expérience BIM.
Visage d’un BIM 2.
Le BIM fait tous les jours des adeptes pour qui le retour vers des principes de dessins traditionnels est quasiment impossible. Le nombre grandissant d’utilisateurs du BIM incitera les éditeurs à en repousser les limites.
Première question que l’on peut se poser : Revit supportera t-il un BIM 2 ?
L’API est le pas vers un BIM 1.5 ; le passage vers le BIM 2 sera plus innovateur. En tant que jeune technologie (il faut une vingtaine d’année pour qu’une technologie s’impose) - Revit a une dizaine d’année - on peut imaginer que Revit supportera des modifications majeures dans les années à venir.
Structure de l’environnement BIM 2
La manipulation des fichiers de taille importante, de plusieurs formats de fichier, pourrait passer par un conteneur de données. A l’instar de NavisWork, un conteneur de données BIM mettrait en relation les différentes données issues de différents formats (et donc plusieurs sources). Ainsi, l’intégrité des données serait garantie par rapport à un export les altérant inévitablement. Le modèle BIM serait ainsi plus robuste.
L’utilisation d’un conteneur de données BIM peut être vu comme un paramètre supplémentaire au logiciel de conception BIM. Chaque composant serait capable d’intégrer des données supplémentaires spécifiques au composant lui-même.
La saisie des informations et leurs utilisations devraient-être au cœur du processus BIM 2.
Le type d’informations, le profil des intervenants et la hiérarchie des informations sont autant de paramètres à prendre en compte pour l’évolution des processus de renseignements d’un modèle numérique BIM. Il sera de plus en plus courant de rencontrer des projets où la phase d’information sera cruciale pour bien gérer le développement des projets. Le flux de saisie des informations doit être fluide et permanent durant la conception.
Les acteurs de conception et les acteurs contextuels (financiers, gestionnaires…) devront utiliser le modèle BIM en amont comme en aval du projet.
Dans un flux permanent de données, le travail de chacun peut se faire uniquement sur un modèle statique. Dès lors, le conteneur de données doit aussi jouer le rôle d’intégrateur de données pour la mise à jour du modèle unique (ce processus est actuellement assuré par le partage de projet).
Pour servir cette nouvelle structure du BIM 2, il sera indispensable de repenser la structure logicielle et notamment la gestion de la base de données. Seule une technologie client/serveur peut assurer la diffusion, l’agrégation et la gestion des données. Et si en plus cette base de données est ouverte (open source), son implémentation et ses outils spécifiques seront facilités. L’utilisation d’un serveur de base de données pour un modèle BIM faciliterait le travail collaboratif multi-sites, la sécurité des données (possibilité d’administrer la DB avec des droits) et la traçabilité des données (qui, quoi, quand).
Pour la partie graphique, une couche logicielle serait en charge de restituer un modèle de données géométriques - Là aussi, en fonction de l’application, seules les données graphiques adressées seraient exploitées à partir du modèle unique et toujours en relation avec leur contexte.
Le modèle unique doit être au cœur de toutes les attentions et en terminer avec l’éclatement des données : on passerait d’informations de modèle à un modèle de l’information.
Le conteneur sera capable de renvoyer uniquement les informations utiles à une requête sans devoir manipuler l’ensemble des données du projet.
Des processus de développement plus proche des réalités constructives.
Dans cette optique de manipulation de données précises, l’entrée des informations devrait être le plus proche possible de la réalité constructive ; les informations en “paquets” ne sont pas précis pour supporter un modèle BIM, seules des informations “cellulaires” seront capables de maintenir un modèle BIM robuste.
Une localisation systématique des éléments.
Le contexte des données du modèle doit pouvoir adresser la localisation de tous les éléments. Chaque cellule du modèle BIM contient sa localisation et ses relations avec le modèle. Localiser de façon précise et multi-facteurs un élément devrait accélérer les processus d’aide à la conception.
En conclusion, le BIM a une grande marge d’évolution tant sur le plan conceptuel qu’en terme de fonctionnalités pour les technologies qui s’appuieront dessus. L’enjeu est de pouvoir toujours plus intégrer d’informations ordonnées et de pouvoir répondre aux requêtes les plus simples comme les plus complexes.
