Auteur : Léa Sattler avec la participation de Thomas Maigne_
DOI : https://doi.org/10.48568/h4tq-vn98
[« L’ère post-BIM, pour une obsolescence déprogrammée » est un texte écrit par Léa Sattler comme un palimpseste d’observations réflexives, tissé au fil de 5 ans de travail au sein de Gehry Technology (entre 2011 et 2016) en particulier sur les projets de la Fondation Louis Vuitton et de la Fondation Luma. Lea Sattler propose ici une mise en perspective de son quotidien de la pratique du BIM, où elle interroge ses enjeux techniques autant que ses enjeux humains et politiques.
Il ne s’agit pas d’un article scientifique à proprement parler, son ton général en témoignera. Il s’agit en effet d’un texte de praticien réflexif, riche de son expérience et de sa volonté d’interroger et de comprendre les pratiques actuelles du numérique en architecture. Il apporte des éléments à discuter et contredire. En cela il trouve sa place dans le corpus que DNArchi vise à constituer et éditer.
Cet article est divisé en trois parties:
- I/III Du CAD au code
- II/III Système d’information et modèle autonome
- III/III La désorganisation scientifique du travail
De 2014 à 2016, j’ai travaillé sur le projet de la Fondation Luma, par Frank Gehry. Je prenais le train chaque semaine pour aller de Paris à Arles, sur le chantier, et j’ai commencé à prendre des notes informelles sur mon travail autour du BIM et des systèmes d’information, tout simplement pour prendre un peu de recul sur mon métier. C’est parti d’un petit notepad, qui est devenu un fichier word de plus en plus ramifié, une table des matières a fini par émerger, avec des sous-parties granulaires, des notes dans tous les sens. Et puis un jour je me suis aperçu que c’était un article. Comme il n’était pas scientifique, au sens strict du terme, et que je n’appartenais pas au monde académique à part entière, je n’en ai rien fait, à part le faire lire à quelques proches et théoriciens concernés par le sujet, qui eux-mêmes l’ont diffusé autour d’eux – jusqu’au jour où mon amie Aurélie de Boissieu m’a proposé de le publier quand même.
I/III : du CAD au Code
In many instances our societies cannot yet do without the iron inflexibility of the typographical page – a mechanical attribute par excellence. […] Even in the electronic era the internal revenue services of most countries are forced to use the most sophisticated technologies to reduce the ectoplasmic variation of digital images to the mechanical fixity of printed images. […] Marshall McLuhan would have been delighted in the digital emulation of Gutenberg’s machine recently perfected by the modern states bureaucracies : the typographical man is so integral to the modern state that the modern state, even after adopting eletronic technologies, is forced to perpeturate a mimesis of the typographical world. » [1]
« BIM », cet acronyme que l’on voit déferler dans l’industrie AEC depuis les années 2000, est aussi flou que celui auquel il est généralement apposé – le très vague titre de manager. Acronyme de Building Information Modeling, il désigne une méthode de centralisation et fluidification de l’information au sein d’un projet de construction afin de minimiser erreurs et perte de temps. Intrinsèquement liée à la notion d’économie – d’énergie, de matériaux, de processus, de temps, d’argent, le BIM invite aussi à un réel souci de l’après : la maintenance, le coût du bâtiment.
Cette pratique séduit et agace, déclenchant des réactions enflammées ou sceptiques. D’aucuns ont peur de voir leur rôle réduit à remplir des cases dans des databases préconfigurées, à saisir machinalement de la donnée. D’autres craignent d’y perdre leur propriété intellectuelle, leur droit d’auteur architectural, en mettant à disposition trop d’information, dévoilant les secrets du métier… En effet, le terme « BIM » est rarement, si ce n’est jamais défini, et reste balloté à travers un amalgame d’injonctions commerciales ou politiques.
Si ce n’est une ébauche de définition, c’est donc au moins un étayage des préceptes liés à cette pratique, qui nous occupera ici. A travers l’exemple de développements BIM des deux projets français récents de Frank Gehry, que sont la Fondation Louis Vuitton, livrée en 2014, et la Fondation Luma, dont la livraison est prévue pour 2018, nous tenterons, d’apporter des éléments de réponse aux questions suivantes : quelles sont les modalités de mise en place de tels systèmes, en termes de technologie, de méthodologie et d’idéologie ? Quelles sont ses conséquences, sur l’organisation du travail et la production ? Et, en préambule : dans quel contexte – d’un point de vue à la fois logiciel et métier – le BIM a-t-il émergé ?
L’emploi du trigramme « BIM » se démocratise dans les années 2000, et le postulat est simple : l’industrie du bâtiment gâche, beaucoup, 25% du budget en moyenne [2]. Les technologies digitales permettent de centraliser, en une maquette numérique, la modélisation 3D d’un bâtiment ainsi que les métadonnées [3]. Cette centralisation de l’information et sa mise à disposition pour toutes les équipes et intervenants va permettre de fluidifier les processus d’échange lors de la conception puis réalisation d’un bâtiment [4]. En résulte une réduction des erreurs liées à la difficulté de trouver et échanger LA bonne information, la dernière, la plus à jour. La coordination est facilitée, puisque tout le monde se réfère à une maquette commune d’une grande précision – quel niveau de précision, jusqu’à quel point, c’est une question cruciale, intrinsèquement liée à la question de l’accès à l’information, et qui sera détaillée plus bas. La technologie poussant vers un affinement perpétuel des niveaux d’information, on peut miser sur le fait que la question du seuil de tolérance reste entière [5].
A. D’une industrie à l’autre
L’information dans la chaîne de montage
Le BIM naît donc de la rencontre entre une technologie et un besoin – plus exactement, de la rencontre entre le déplacement d’une technologie d’une part, et des acteurs de plus en plus éduqués d’autre part. En effet, le PLM, product lifecyle management, pourrait être considéré comme l’ancêtre du BIM [6]. Le monde de l’industrie lourde, de par son échelle, n’a pas attendu les années 2000 pour se pencher sur la question du coût lié aux erreurs découlant d’une mauvaise gestion de l’information et considère la donnée comme partie intégrante des entrées de la chaîne de production, au même titre que les données matérielles. La data, au même titre que le boulon ou l’écrou. L’automatisation est le cœur du métier – si l’on peut mécaniser une chaîne de montage, on ira naturellement appliquer un processus similaire sur la chaîne d’information afférente. C’est dans la culture industrielle, et il n’y a pas de différence ontologique entre l’automation d’un calcul dans un fichier numérique, d’un protocole d’échange d’information, et l’automatisation d’un robot d’assemblage ou d’une machine à commande numérique.
En atteste la robustesse du logiciel Catia, de Dassault Système, dont les premières versions naissent dans les années 1970, où tout est pensé pour les routines d’extraction de données automatisées. Utilisé en combinaison avec la base de données Enovia, du même éditeur, on a une gestion performante de la donnée, et bien plus que n’importe quelle solution BIM existant sur le marché à l’heure où j’écris cet article (et ce, même avec une version d’Enovia ou de Catia qui daterait d’une vingtaine d’années). La technologie existait déjà, donc – mais elle n’était pas démocratisée ni utilisée dans le BTP. Elle était cantonnée aux industries lourdes, qui développaient elles-mêmes leurs systèmes d’information autour de leurs outils logiciels PLM. En d’autres termes, elle était réservée aux industries où elle était perçue comme nécessaire.
La question étant : pourquoi, donc, arrivés en 2016, le BIM est-il perçu comme nécessaire, à tel point qu’en France, un projet de loi prévoyait de rendre obligatoire [7] la livraison d’une maquette BIM pour toute réponse à un appel d’offre dans le cadre d’un marché public ? Pourquoi un tel engouement politique, un tel revirement idéologique ?
L’injonction méthodologique du non-standard
L’arrivée de la computation en architecture, dans les années 1990-2000 [8], a considérablement changé la donne de la gestion de la donnée à travers un projet d’architecture. Certains architectes ont pu concevoir et modéliser numériquement, de manière précise, des bâtiments à géométrie complexe et ils se sont naturellement demandés comment assurer la stabilité de la donnée qu’ils avaient produite, depuis la conception jusqu’à la fabrication. Cette question n’était tout simplement plus contournable, pour une raison purement pragmatique : impossible de construire sans. Il était logique d’utiliser les mêmes supports (numériques), depuis la conception jusqu’à la fabrication, afin de prévenir toute rupture dans le flux de données, qui aurait conduit à une perte d’information et à une altération de la matérialité du projet. La technologie tirait la réalité vers le haut, et empêchait tout retour en arrière : pour construire ce que l’on avait modélisé, il fallait suivre la logique numérique insufflée au moment de la conception, l’objet n’étant tout simplement plus appréhendable avec les outils de représentation classiques. La modélisation, voire la simulation, devenait nécessaire. Il a fallu attendre de se retrouver devant des surfaces dont la discrétisation donnait nécessairement un ensemble de pièces uniques échappant au standard pour se reposer la question du standard, sous la forme suivante : quel ensemble de règles partagent ces pièces uniques ? Ainsi, la démocratisation du non-standard [9] a fait réémerger, sous un nouvel éclairage, la question de la rationalisation de la production de bâtiments. Il aurait été souhaitable que cette question s’impose de manière effective beaucoup plus tôt chez les architectes, notamment dans les années 1950-1960, qui ont connu un fort accroissement de l’industrialisation de la production d’architecture – l’automation était alors en pleine expansion dans les autres industries. À cet égard, l’éditorial ci-dessous, de mai 1956, d’un journal grand public de vulgarisation scientifique, en dit long sur le retard technologique dans le BTP… On notera la métaphore des « cerveaux électroniques » [10] pour désigner l’intelligence artificielle, domaine de recherche dont l’acte de naissance se situe tout juste deux ou trois mois plus tard, à l’été 1956, lors d’une conférence sur le campus de Dartmouth College.
Editorial de Science et Vie, numéro de mai 1956
Héritage des technologies aéronautiques et automobiles
L’arrivée des logiques computationnelles en architecture a donc permis de concevoir, fabriquer et construire des bâtiments aux morphologies complexes. Naturellement, le BIM s’est tout d’abord déployé dans les projets qui nécessitaient absolument, de par leur taille et leur complexité géométrique, l’utilisation d’une plateforme centrale de données associée à des modeleurs 3D puissants.
L’histoire, telle qu’elle se raconte chez Gehry Technologies [11], est que Frank Gehry a utilisé Catia au début des années 90 pour modéliser puis suivre la construction de sa Fish Sculpture à Barcelone, puis du musée Bilbao. L’avantage de cet outil résidait tout d’abord dans son volet paramétrique et associatif, permettant la mise en place de composants adaptatifs et d’une modélisation mathématique de surfaces complexes. Le second avantage était lié au mode d’assemblage de fichiers, qui permettait de diviser un modèle 3D en différent fichiers numériques, assemblées au sein d’une maquette [12] partagée, autour de laquelle collaborent les différents intervenants. Gehry a par la suite développé en partenariat avec Dassault Systèmes le logiciel Digital Project, une version de Catia spécialisée dans l’industrie AEC. Une synergie similaire a eu lieu entre Foster + Parters et Bentley Systems, avec entre autres le logiciel MicroStation.
Démocratisation du big-data
Alors que les prix de ces logiciels les cantonnent à certains types de projets et budgets, les méthodologies numériques se répandent. Autour de 2005, Rhino, de McNeel, automatisable en langage VB, prend rapidement une place assez importante chez les architectes. En 2007 arrive Grasshopper, cette interface intuitive de programmation visuelle, très vite massivement investie par les étudiants en architecture. Alors que commence à Paris le chantier de la Fondation Louis Vuitton, Grasshopper commence à être utilisé en France. Il devient ainsi possible, en quelques composants, de gérer les instances d’éléments 3D complexes, sans avoir besoin de taper une ligne de code. Au même moment, une multitude de logiciels spécifiques se démocratisent (de simulation acoustique, thermique, etc.), et l’utilisation du cloud se généralise – chacun a désormais une Dropbox. Stocker et échanger ses données en ligne est devenu une opération quotidienne. C’est dans ce contexte de plus en plus techo-friendly qu’Autodesk amorce une politique commerciale de plus en plus agressive pour Revit. Et il nous a semblé que c’est aussi à ce moment que la pratique du BIM, originellement liée à une certaine liberté, au dépassement de certaines limites via la programmation et le code, se mute en une pratique plus passive de remplissage de champs et de formulaires.
B. Lobbying
Le logiciel et la pensée
Petit retour en arrière. En France, dans les années 2000, Autocad était le logiciel de CAO dominant chez les architectes. Ce n’était pas un logiciel d’architecture, mais un logiciel de dessin industriel. Archicad, édité par Graphisoft, qui ressemblait déjà fort à l’actuel Revit, avec sa collection d’objets pré-définis comme les murs, dalles ou toits… était l’ennemi à abattre, justement à cause de ce pré-formatage qui amènerait par capillarité à un pré-mâchage du projet architectural. Si le logiciel ne vous propose que des murs verticaux, il y a fort à parier que vous vous retrouviez à faire des murs verticaux… si entre-temps vous avez cessé de réfléchir par vous-même. Car, notons-le au passage : le risque majeur n’est pas qu’un logiciel pense à votre place – ce n’est pas un risque, c’est un fait, c’est la fonction primaire, son unique fonctionnalité : effectuer les opérations mentales qu’il vous économise. On peut par contre supposer que le risque est qu’il vous amène à penser comme lui sans que vous vous en rendiez compte. En d’autres termes, que la paresse prenne le dessus. Et ce risque est la responsabilité de l’utilisateur, pas du logiciel. Loin de nous l’idée de défendre ce type d’approche CAO/BIM où l’on évolue parmi des standards bien ficelés. Si nous la critiquons, ce n’est toutefois pas pour les raisons habituellement invoquées. Il est indéniable que ces logiciels, s’ils sont utilisés avec un esprit critique, sont très efficaces, du moins pour la partie standard d’un projet. Mais leur pratique reste peu intéressante, non pas parce qu’elle ferait « perdre une certaine liberté » à l’architecte (qui devrait utiliser ces logiciels en toute connaissance de cause : ce n’est pas parce que l’on ouvre un catalogue de standards que l’on doit arrêter de penser) mais tout simplement parce que sa logique inhérente est peu excitante intellectuellement, mais parce qu’elle ne propose pas de construire ses propres objets, et dans une certaine mesure, restreint et empêche même ce processus. Et tout le travail de l’architecte est justement dans la redéfinition perpétuelle des objets conceptuels, numériques et physiques qu’il met en œuvre et manipule. Ne pas utiliser l’objet mur, mais bien le redéfinir, le réinventer, le construire.
L’architecte et la production
Autodesk a très bien su tirer parti de cette peur émanant de la communauté d’architectes, de cet effroi de voir l’industrie du logiciel écraser ou réduire la pensée du projet, énième argument de victimisation sur une scène architecturale rejouant sans cesse le mythe de David contre Goliath (l’architecte contre tous les autres : les politiques, les entreprises de construction, les industriels…). Ainsi, Autodesk a habilement propulsé Autocad, grand concurrent d’Archicad, au-devant de la scène, en utilisant cet argument tant entendu dans les années 2000 – avec Autocad, l’on restait libre. C’était flatter un aspect très conservateur de la profession : maintenir l’architecte en dessinateur, dans tous les sens du terme, c’était le maintenir dans une posture d’artiste, d’artisan, et non dans la position d’un responsable d’une production, celle d’un bâtiment.
On l’aura compris, nous ne rejouons pas ici le débat des années 90/2000, Autocad versus Archicad, qui fut vite rendu caduque par l’apparition des logiciels 3D puis du BIM. Il nous semble simplement que la défense du premier au profit du second était toujours étayée avec un raisonnement émanant en grande partie du discours commercial de l’éditeur du logiciel adverse, et ceci au nom d’une liberté « numérique ». En effet, il est paradoxal de se plaindre du déferlement numérique en invoquant des arguments créés de toute pièce par des vendeurs de logiciels…
Opium technologique
Autodesk distillait donc le rêve de continuer à dessiner, librement. Avec Autocad, originairement robuste devenu au passage une usine à gaz grouillant de fonctions inutiles et distrayantes, en bon opium du peuple, l’architecte restait libre de dessiner, et surtout, de ne pas structurer digitalement l’information du projet, comme une incitation à la paresse. Sans tomber dans la théorie du complot, une hypothèse pourrait toutefois être émise : maintenir la communauté d’architectes dans une grande incompétence numérique en ce qui concerne la gestion des flux de données était fort intéressant pour Autodesk, et permettrait à la firme de mieux imposer, en déferlante, quelque années plus tard, son Archicad à elle : Revit. Quand gérer des objets et non des dessins serait devenu à la mode ; quand l’overdose de trim, split, extend [13] serait devenue trop pénible ; quand tous les logiciels environnants, truffés de 3D et de logique de code, seraient devenus assez effrayants en terme de compétences requises, alors, le timing serait parfait pour imposer Revit, logiciel BIM à tout faire, intuitif, facile, à utiliser les yeux fermés…
En effet, la société Autodesk, qui rappelons-le, se développe en rachetant des logiciels et en les déployant à grande échelle sans forcément les améliorer, comme en attestent les nouvelles versions de Maya ou Ecotect, a racheté Revit et rapidement imposé ces familles d’objets qu’elle avait contribué à mettre de côté une décennie plus tôt dans sa lutte contre Archicad… Si après tout Autodesk, entreprise privée, poursuit à raison sa tâche d’expansion économique (chacun son travail, dirait-on), un fait, toutefois, est préoccupant : Revit est considéré comme le logiciel BIM en France, c’est le plus utilisé… C’est celui qui est évoqué, dans les projets de loi, de manière insidieuse, et lors de toute évocation d’une maquette numérique [14]. La question du monopole se pose. Si nous avons au sujet de Revit les mêmes réserves que pour Archicad, force est de constater que ce logiciel est redoutablement efficace, et surtout, intuitif – c’est d’ailleurs là son principal danger. En effet, Revit établit au sein d’un projet un système d’information opaque [15], en ce sens que ses règles ne sont pas entièrement explicitées. Au-delà de la critique d’une méthode commerciale tentaculaire, qui au lieu de déployer et ramifier des méthodes numériques, se contente de vendre des solutions logicielles black-box et non-réversibles d’année en année, demandons-nous : quelles sont les présupposés conceptuels de l’établissement d’un système d’information au sein d’un projet, et quelles alternatives existent ?
Lire la suite : II/III Système d’information et modèle autonome
——————————————————————————————————
[1] Mario Carpo. The alphabet and the algorithm, The MIT press, 2011, p10
[2] Cheng, Jack CP, Jongsung Won, and Moumita Das. « Construction and demolition waste management using BIM technology. » International Group for Lean Construction Conference (IGLC), Perth, Australia.
[3] C’est la définition que nous utiliserons dans cet article: la maquette numérique ou maquette BIM, est un ensemble de modélisations 3D lié à des métadonnées (nous utiliserons parfois, afin d’éviter les lourdeurs, le simple terme maquette. Nous éviterons le terme modèle BIM, souvent utilisé, et découlant du faux-ami anglais BIM model. (Le modèle BIM, en version française, nous semble plus ambigu, car il englobe à la fois les modélisations, les métadonnées et les processus). Nous utilisons par contre le terme modèle 3D, qui désigne couramment le fichier contenant les modélisations 3D.
[4] Chuck Eastman, BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors, 2nd Edition, Willey, 2011
[5] “Perhaps the question to ask is not how difference between design and production can be eliminated, but how it can be valued?” , Bob Sheil “ Negociating Zero Tolerance”, in Architectural Design, n°277 January February 2014, High Definition, Zero tolerance in design and production, p19.
[6] On notera que le terme « PLM » n’est plus utilisé par Dassault, qui l’a remplacé par son leitmovit de 3D-experience… L’ « expérience », donc, qui ne fait plus la différence entre la modélisation 3D et la construction sous-jacente d’une database – la première étant impensable sans la seconde. Par ailleurs, si les termes PLM et BIM sont apparus respectivement en 1985 et 1986, le second s’est véritablement répandu deux décennies plus tard.
[7] Ce projet de loi a été temporairement gelé, mais la volonté d’encourager le BIM est bien présente politiquement, via le PTNB, le Plan de Transition Numérique dans le Batiment, qui « vise à accélérer le déploiement des outils numériques à l’échelle de l’ensemble du secteur du bâtiment. À ce plan est affecté un fonds de 20 Millions d’Euros ». Source : http://www.batiment-numerique.fr/PTNB/presentation.htm
[8] À ce sujet, voir Mario Carpo, The digital turn in architecture 1992-2012, AD Reader, Edited by Mario Carpo. Chichester : John Wiley & Sons, 2013.
[9] Le terme apparait en 2003, avec l’exposition « Architectures non standard », au centre George Pompidou à Paris (commissaire : Mnam/Cci, Frédéric Migayrou – Z. Mennan).
[10] Notons ici la mention de “maitres-cerveaux” et de “sous-cerveaux » – ou la volonté de calquer une structure hiérarchique top-down classique sur une structure computationnelle… Cette hiérarchie étant pourtant justement potentiellement bouleversée par l’arrivée de cette proto intelligence artificielle.
[11] Originellement cellule R&D BIM et modélisation 3D avancée de Gehry Partners, Gehry Technologies s’est détachée en 2003 pour créer une société indépendante.
[12] cf. note 3, sur les termes maquettes/modèles/modélisations.
[13] Fonctions basiques du logiciel Autocad.
[14] Notons ici la grande faiblesse de la théorisation autour du BIM en France. L’ouvrage qui fait référence en France, truffé de discours vagues et politiques, dénué de toute problématique, est ainsi intitulé : « le BIM et la maquette numérique » (2014, Eyrolles, CSTB. Auteurs : Olivier Celnik, Eric Lebègue, Collectif Eyrolles).
[15] Dans Revit, les objets et outils ont des pré-réquis bien précis – ce que nous ne critiquons en aucun cas : c’est ce qui le rend si efficace. Nous avons par contre des réserves quant à l’explicitation, dans l’interface utilisateur, de certains de ces pré-requis, dont découlent les règles de modélisation, rendue opaques. Si la notion d’hôte est claire (une fenêtre a pour hôte un mur, c’est-à-dire qu’une de ses données d’entrée est un mur), certains outils n’explicitent pas cette notion d’inputs/outputs. Par exemple, dans Revit 2017, il y a 3 manières de créer un mur. Par chemin géométrique simple (poly-ligne ou poly-courbes composées uniquement de ligne ou arc de cercles – à l’exclusion de tout autre type de courbe comme les ellipses, splines, coniques…), par face (ici, tout type de surface, dont le mur devient un offset) et via des composants génériques (où l’on construit un volume libre auquel on assigne l’attribut mur). Le processus de construction géométrique du mur diffère dans les 3 cas : extrusion d’une poly-ligne ou poly-arc puis offset, offset d’une surface, et construction libre d’un volume. Pourquoi ces 3 types d’opération ne sont pas explicitées dès le premier clic ? Pourquoi, en cliquant sur l’outil mur, ne voit-on pas d’emblée, ces 3 options proposées ? En résulte le fait suivant : alors que dans un logiciel comme Grasshopper ou Digital Project, on vient parfois buter sur des problèmes géométriques, ou de logique pure, dans Revit, lorsqu’on bute, c’est pour se demander comment Autodesk a construit son logiciel. On se heurte à la logique de l’éditeur, au lieu de buter sur une logique géométrique ou mathématique. Le problème étant que ces dernières produisent du savoir et de la connaissance, ce qui n’est pas le cas de la première.
