Auteur : Léa Sattler avec la participation de Thomas Maigne_

Précédemment nous avons brossé le contexte dans lequel le BIM est apparu à la fin des années 2010 : une démocratisation de l’usage de la 3D, et un zeitgeist diffus de morphologies non euclidiennes – vulgarisation architecturale des percées des années 90 [article I/III]. Toutefois, le BIM, d’un point de vue computationnel, n’est pas une nouveauté et est très archaïque vis-à-vis de son équivalent dans d’autres industries. De plus, le terme baigne dans un grand flou conceptuel, assez bénéfique pour les éditeurs de logiciel – tant et si bien que le BIM est systématiquement associé à quelques-uns d’entre eux seulement.  Ainsi, au-delà du software, quelles pratiques organisationnelles et technologiques sont induites par la mise en place d’une méthode dite « BIM » ?

II/III Système d’information et modèle autonome

« J’ai là pour vous […] une bibliographie des bibliographies, c’est-à-dire la liste alphabétique des listes alphabétiques des titres de tous les livres et travaux qui ont été consacrés ces cinq dernières années aux progrès des sciences éthiques […] Le secret de tout bon bibliothécaire est de ne jamais lire, de toute la littérature qui lui est confiée, que les titres et les tables des matières. Celui qui met le nez dans le contenu est perdu pour la bibliothèque ! […] Jamais il ne pourra avoir une vue d’ensemble ».

Robert Musil, L’homme sans qualité [1]

La visée du BIM, c’est l’économie, dans son sens le plus classique : de matière, de moyens, de processus. Faire plus avec moins. Pour atteindre ce but, une méthode BIM n’est rien d’autre que la conception et le déploiement d’un système d’information stable au sein d’un projet. Cela passe par une méthode de description, de décomposition ontologique de l’objet « construction d’un bâtiment » : éléments physiques, opérations, dénominations. Quand bien même on n’adhérerait pas à l’idéologie d’optimisation sous-jacente du BIM, cette décomposition est la base des opérations intellectuelles du projet d’architecture, de l’esquisse à la construction. Notre postulat est donc qu’on ne peut y échapper – que cette méthode est inhérente à l’exercice du projet architectural, comprise dans son ADN. Par ailleurs, notons que la problématique du système d’information en soi n’est ni nouvelle, ni liée à l’ère numérique [2] – elle est liée à la question fondamentale de la construction de la connaissance

A. Structuration

La première question est donc celle de la création d’une structure de fichiers. Comment décompose-t-on un bâtiment en différents morceaux numériques?  Un format numérique, l’IFC (Industry Foundation Classes) existant depuis 1997, procède à cette décomposition ontologique, de manière à permettre l’interopérabilité des fichiers de l’industrie AEC. Ce format est souvent critiqué, car difficile à satisfaire – en effet, il est exhaustif, et ne résout pas, en soi, les problèmes de structuration de données, mais propose simplement un châssis à cette structuration. Ce format est assez pur, de par cette exhaustivité, et aussi de par ses présupposés (la notion de classe renvoie directement à une logique numérique de construction de l’information). Il nécessite, donc, en amont, d’organiser correctement les données : la problématique de la structuration des datas subsiste. Celle-ci se posait traditionnellement dans l’industrie du BTP en termes plus simple. L’on avait globalement deux facteurs de division : économique (lots) et spatial (zones), croisés avec des plans de coupe de référence, sur lequel chacun venait empiler l’information. La maquette BIM soulève aussi ces questions de zones et de lots, mais en pose une nouvelle : celle de l’espace de travail collaboratif digital. La maquette permet à différents intervenants de travailler autour des mêmes objets, d’où la nécessité de créer un environnement partagé. L’ensemble maquette + plateforme d’échange est un système articulant deux axes : l’organisation spatiale et physique du bâtiment d’une part, et l’organisation du travail humain, de l’autre. À l’espace physique du bâtiment vient se rajouter un espace numérique de collaboration.

Division du travail

Ainsi, la maquette numérique est la rencontre de ces deux organisations – ou sa tentative de rencontre. Le premier exercice est donc de faire correspondre les deux types de division – spatiale / physique, travail / humain. Ce qui revient à se demander : comment divise-t-on un bâtiment en zones de travail ?

Cette interrogation générale soulève très vite trois sous-questions épistémologiques. Tout d’abord : quel facteur de division choisit-on ? Par zones, lieu ? Par discipline, métier ? Par phases ? Par intervenants ? En somme – quel est le diviseur, quelles classes établit-on. La seconde question est la suivante : dans quel ordre divise-t-on ? C’est le dilemme de l’ordonnancement des nœuds : divise-t-on par métier puis par niveaux ou par niveau puis par métier ? Le thème ici soulevé n’est autre que celui de l’accès par défaut à l’information. En effet, l’utilisation d’identifiants stables permet de recomposer à souhait des assemblages, par combinatoire – c’est ainsi que fonctionnent les bases de données, c’est l’indexation. Ainsi, cette seconde interrogation n’a plus lieu d’être, à condition de définir au préalable des éléments stables au sein du système. Ce qui amène naturellement à la troisième question, qui elle, est essentielle : comment identifier un composant, au sens abstrait du terme, capable de perdurer tout au long du projet ? Car in fine se pose la question du suivi : il est facile de suivre la modification d’un objet, mais que se passe-t-il lorsque celui-ci, disparaît, ou fusionne avec un autre ? Il y a une grande similitude avec la question de la topologie, que l’on retrouve en géométrie : que se passe-t-il si un élément devient plusieurs, ou si plusieurs deviennent un ? [3]

Ontologie

On est ici en fait confronté à une très vieille question, celle de la définition d’un composant, à laquelle on rajoute, de manière explicite, une question tout aussi ancestrale, celle de l’organisation du travail. On notera que vu sous cet angle, le BIM n’a absolument rien de nouveau. La nouveauté, dans l’industrie du bâtiment, est dans l’établissement d’un système d’information numérique évolutif, qui traitera ces deux volets simultanément. Ainsi, par quelle pièce procède-t-on à la décomposition ? Quel est l’atome d’un tel système? Quelle unité d’information, pour permettre un suivi efficace ? C’est la question de la décomposition ontologique, inhérente à la méthodologie BIM

L’unité d’information sera le produit des deux sous-systèmes afférants : la combinatoire entre une logique de travail collaboratif et un ensemble de fragments physiques du bâtiment, entre l’unité « travail » (le groupe qui modélise ou consulte la maquette) et l’unité « physique » (un morceau de bâtiment). Cette unité sera modifiée au cours du projet, depuis la phase esquisse, jusqu’à la phase de construction, et idéalement, la phase de maintenance. Elle doit être en soi suffisamment consistante pour perdurer au long du projet, à travers tous les circuits d’information et les modifications de projet, de contrats, de réorganisations d’équipes. Cette répartition des données en unités dynamiques d’information est à la base du processus de partage d’information du projet. Le système est performatif : les données sont organisées de manière à entraîner leur partage, rapide et efficace. On notera que le terme « BIM » est rarement apposé à la notion d’organisation scientifique du travail, auquel il est pourtant intrinsèquement lié…

Unité d’information persistante

À titre d’illustration, sur le projet de la Fondation Luma de Frank Gehry, l’unité d’information est donc cette cellule hybride, rencontre entre deux inputs : matériels et organisationnels. Le bâtiment est divisé de manière arborescente en zones et composants physiques (la structure, la façade, les fluides, les finis), qui viennent rencontrer le système de partage et de traitement de l’information (processus de validation et des avis/visas) qui exige de regrouper ces éléments en petits lots de soumission/validation, dont le traitement progressif entraine l’avancement des études et du chantier.

Un châssis d’information solide et dense a résulté de la combinaison de ces unités d’information, sur lequel quantité de processus et méthodes numériques ont pu être appliqués, comme celles des validations de la maquette de l’entreprises par la maitrise d’œuvre (l’équivalent du visa en 3D), mais surtout, d’une grande variété de types d’extraction et de recombinaisons de données : 2D, méta-data, désassemblage, réassemblage. L’indexation des objets a permis grande consistance et fluidité dans l’analyse des données ou le datamining.

Ainsi, ce déploiement ne peut faire l’économie d’une phase de définition de cette unité d’information, ou objet persistant doté d’une dynamique interne, déclinable en une multitude d’éléments formant in fine un système d’information. La difficulté de trouver un nom pour ces objets en dit long sur leur complexité. Le nom n’est pas simplement un moyen de communiquer, d’expliciter l’objet, c’est un moyen de le faire exister dans le système d’information, le fameux UID (Unique Identifier). Nommer cet objet, c’est le propulser de manière effective dans un écosystème de travail. Mal le nommer, c’est assurer l’impossibilité d’identifier des éléments, et donc des processus liés – c’est sous-informer, et empêcher toute automation.[5]

B. Distribution

La question de la définition des objets mène naturellement à celle de l’établissement de leurs limites. Un système numérique étant en soi incommensurable, au sens propre, système d’objets eux-même ramifiables à l’infini, il faut pourtant établir des seuils – qui justement vont permettre ces ramifications. La définition d’un système passe par l’établissement de ces contours : ce qu’il traite, ce qu’il ne traite pas. Dans le cas d’objets numériques, c’est la question de l’input/output.

Interface utilisateur : conscience de l’outil

La première limite peut sembler évidente, mais on en perd souvent conscience : c’est l’objet logiciel. L’utilisation d’un software comme Catia, qui implique la création et assemblages de différents types de composants génériques, force constamment à se demander quelle est la donnée entrante, et quelle est la donnée sortante. On est dans une logique de production puis traitement de l’information, et non d’utilisation ou de simple manipulation. Ainsi, aucune donnée n’est d’emblée… donnée, justement, aucun automatisme déjà présent, et toute modélisation force à sans cesse à recontextualiser l’information créée, à la reconnecter à son cadre réel – c’est-à-dire, dans notre cas, la réalité physique du bâtiment, ou la réalité concrète de l’organisation du travail. Il y a une conscience de la création d’information, à chaque étape.

Catia, en soi, est une limite, dans le sens où l’on a toujours une haute conscience de la manière dont l’information procède. L’infrastructure logicielle ne se cache pas, et ne fait pas miroiter autre chose que ce qu’elle traite ; le contour est clair. Cette notion importante est peu prise en compte, et bien souvent, les utilisateurs ne connaissent pas les étendues et limites des fonctionnalité de tel ou tel logiciel, et ne savent ainsi pas tester rationnellement un bug. De la même manière, il faut savoir définir un cahier des charges, pour un outil numérique, ce qui ne s’improvise pas.

Screenshots de Catia V2, 1983
Source : http://cadsolutionscatiav5.blogspot.fr/

Interfaces physiques : competitive modelling

La question de la délimitation du système est donc fondamentale – c’est la question de l’interface utilisateur, au sens large. De la même manière, la question de limites entre objets, soit l’interface entre objets physiques, est essentielle, et au cœur des problématiques BIM. A cet égard, sur le projet de la Fondation Luma, nous avons rencontré un cas intéressant. Les équipes de maîtrise d’œuvre, en France notamment, déjà habituées à utiliser le logiciel Digital Project et aux méthodes BIM des projets de Gehry, ont modélisé, pour certaines, trop vite. En effet, elles connaissaient le niveau de détail final, et ont assez spontanément modélisé à un LOD[6] assez élevé. Quand on compare la maquette de la Fondation Louis Vuitton avec celle de la Fondation Luma, à des phases équivalentes, la première est assez homogène en termes de LOD, tandis que la seconde est hétérogène, comportant des éléments très détaillés, et d’autres plus simples – une maquette à niveaux de détails compétitifs. C’était à la fois enthousiasmant – d’arriver, plus vite, en amont, à un niveau de définition élevé. Mais c’était aussi plus complexe à gérer pour la phase de synthèse : cette phase comprenait la tâche de détecter des clashs généraux, entre surfaces de référence, et les détails arrivaient trop tôt… On pourrait arguer du fait que cela donnait en réalité une maquette plus chaotique, puisque hétérogène. Certes, mais un chaos structuré, porté par cette volonté de s’approcher du réel. Une maquette comportant des clashs certes, mais pêchant par connaissance, plus que par ignorance.

Cette évolution spontanée de la maquette numérique, en ce sens qu’elle n’a pas été planifiée par une instance supérieure, mais qu’elle est le fruit du travail de diverses entités indépendantes, révèle son caractère autogéré et autonome, mais aussi sa performativité. Ici, quelques équipes, dotées de bons modeleurs, ont simplement poussé un certain niveau de détail, malgré la phase peu avancée, ce qui a déclenché des réactions en chaine et posé des questions de limites de prestation et d’organisation du travail de synthèse. Ainsi donc, un objet situé en bas peut, grâce aux méthodes BIM, faire remonter plus vite dans les sphères décisionnelles des questions cruciales. Dans ce cas précis, c’était une question d’interface entre composants physiques qui a déclenché ces remises en question. Il est révélateur que ce soit l’interaction entre différents composants d’une maquette commune, en soit, qui ait déclenché des décisions, plus qu’une volonté émanant d’en haut de régler les choses.

De l’interface au clash

Cette question de l’interface est fondatrice, dans le sens où un traitement de la notion de limite qui peut servir à lui seul de point de départ d’un projet architectural. Elle trouve son pendant vulgarisé dans la notion de clash. À cet égard, il est assez ironique de voir que le BIM aujourd’hui se focalise sur le clash détection, qui constitue un argument numérico-commercial de premier ordre… En effet, on peut poser l’hypothèse selon laquelle détecter un clash, c’est arriver trop tard, en aval. De plus, cela implique la définition en amont de composants et de règles d’interaction – définition qui fait trop souvent défaut. C’est prendre le problème à l’envers : si l’on s’est tenu à créer au préalable un ensemble d’objets numériques évoluant selon certaines règles établies, la question du clash ne se pose plus – elle est remplacée par des questions plus fines, d’interactions entre surfaces maîtresses et des surfaces esclaves, de conciliation géométrique, de granularité d’interfaces, de limites de prestations. En effet, quoi de plus flou et imprécis qu’un clash si l’on ne définit pas le régime de priorité entre deux éléments, ainsi que leur niveau de détail, et un seuil de tolérance ? Quel est l’intérêt d’une opération qui détecte 95% d’erreurs comme un boulon en conflit avec une dalle béton ?

Le BIM est donc cet établissement d’objets et de processus – une datastructure et ses logiques de distribution. Cette pratique implique la redéfinition de tout un champ de limites (entre objets, entre travailleurs) et leur prise de conscience, afin d’en abolir d’autres, plus lourdes, bureaucratiques. Si ces limites, inhérentes à l’organisation du travail et au contexte multi-entrepreneurial de l’industrie du BTP, persistent, elles sont par contre rendues plus souples, plus performatives – actives, et non passives. En un sens, le but du BIM est justement de rendre ces limites inter-équipes et inter-éléments plus fructueuses, de les transformer en terrain d’échange et de créativité, et non plus en simples limites de pouvoir. C’est en cela qu’une maquette numérique vient bouleverser l’organisation du travail….

C. Autogestion

Le BIM réveille ce rêve d’une certaine démocratisation de l’information, auquel tous les intervenants du projet ont accès de manière équivalente. On a en tête la figure démocratique du cercle, avec tous les acteurs du projet situés à égale distance du centre, quel que soit leur statut et corps de métier, convergeant vers le même objet maquette numérique. Dans les faits : tous les acteurs ont accès à la dernière version numérique du bâtiment, plus besoin de quêter pour accéder à l’information. Sur le projet de la Fondation Louis Vuitton, tout le monde avait accès aux modélisations détaillées des verrières, aux modélisations structurelles, à l’ensemble des composants intelligents – savoir accessible, au centre, au cœur… qui pour autant ne vient pas bouleverser si facilement les hiérarchies en place.

Contremaître numérique

Dans les débuts du BIM, il y a d’abord cette attitude un peu condescendante vis-à-vis de l’objet maquette numérique, qui reste associée au technicien, à l’exécutant. Dans l’esprit des gens, le BIM vient occuper la place qu’avaient les plans, carnets de détails, et est associé au projeteur 2D. Ainsi, dans un premier temps, les décideurs délaissent la chose – s’ils savent souvent à peine naviguer dans la maquette 3D, ils sont encore moins à même d’en extraire les données. C’est un objet technique, que l’on regarde de haut. Un renversement intéressant s’est produit quand le BIM est devenu plus mainstream, depuis les années 2010-2011. Le développement de multiples logiciels BIM viewer s’accélère, et le BIM sort du champ purement géométrique pour se rapprocher du champ plus vaste du contrôle de la data. Les logiciels BIM ont alors changé de destinataires ; des entreprises de construction ou architectes, ils se sont mis à cibler les commanditaires et maitres d’ouvrage – ceux qui consultent, la maquette numérique, et non plus ceux qui la créent.

A cet égard, le changement de nom de la version de consultation de « Digital Project Viewer » en « Digital Project Manager », en opposition à la version de modélisation, « Digital Projet Designer », est éloquent. Le viewer, en apparence passif, aurait pu rester ce voyeur en coulisse du projet, exploiter la maquette, en connaître secrètement quelques rouages – en despote éclairé discret, en homme de l’ombre qui tire les ficelles. Mais avec ce nouveau label de manager, il se glisse à nouveau dans la symbolique traditionnelle de celui qui contrôle, flique – celle du contremaître. Ce changement de nom marque une volonté de réaligner les statuts du software sur la hiérarchie officielle, classique, top-down. Une volonté d’affirmer la suprématie du décideur, qui via les processus BIM, donnerait des directives aux exécutants – et de confirmer l’hypothèse selon laquelle les exécutants piloteraient la maquette. C’est aussi une manière d’insister sur la gestion des données, et non plus leur création. Pourtant, comme on l’a écrit plus haut, cette première phase de création de données, en tant que production et structuration d’un ensemble d’objets, est essentielle si l’on veut analyser les données a posteriori. Quelle est la validité de l’opération intellectuelle qui consiste à vouloir traiter en masse des éléments invalides, ou internements mal structurés ?

S’il est vrai que le terme viewer était incomplet, on aurait pu imaginer un changement de nom moins caricatural, évoquant une organisation du travail et des agencements hiérarchiques plus subtiles. Sans même parler de l’immense vide lexical autour du mot manager… Le mot gestion, générique, serait à bannir du monde du travail, au profit de ses variantes spécifiques, comme : analyser, traiter, examiner, peser, balancer, résoudre…

Logique bottom-up

La maquette numérique a donc changé de statut : d’un objet technique, elle devient un objet de management. Ce renversement montre qu’a enfin été compris son potentiel d’aide à la décision. D’où ce besoin, évident, de le contrôler. Ce basculement se sent aussi dans les jeux politiques au sein d’un chantier, ou la prise de contrôle de la maquette devient un enjeu important.

Là encore, on rêverait que le BIM bouscule les pratiques classiques – par exemple, qu’il crée d’autres dynamiques entre la maîtrise d’œuvre et l’entreprise de construction, qui finalement, travaillent tous deux dans l’intérêt du projet[7]. Sur le projet de la Fondation Luma, c’était d’ailleurs le schéma proposé par la maîtrise d’œuvre même : une sorte d’équité, ou toutefois, de symétrie, entre les concepteurs et les constructeurs, qui effectuent, in fine, le même processus de produire, renseigner l’un après l’autre, et parfois simultanément, la maquette numérique. Cette symétrie, finalement, est le reflet d’un workflow[8] existant. Ainsi, nous avions proposé le diagramme de gauche ci-dessous, en collaboration avec les architectes d’exécution en France, pour illustrer cette sorte de miroir processuel entre les deux camps.

Source : Gehry Technologies Europe (consultante : Léa Sattler, 2014)

Mais ce diagramme, passé chez les designers du projet, à Los Angeles[9], a subi une petite rotation de 90 degrés – l’architecte remis à sa place… en haut. Notons que cette tentative de reprise de contrôle, du moins par un jeu de statut, sur un objet autogéré est comme une démonstration par l’absurde ce l’effectivité, et de la performativité de l’objet maquette numérique. Il n’en reste pas moins que, d’un objet auto-organisé, qui questionne les hiérarchies classiques, on revient sans cesse à un objet dirigé par une instance supérieure. Comme si cette figure top-down de l’organisation du travail n’était absolument pas remise en cause par l’ère numérique, qui rend pourtant possible, de manière effective, de nouvelles logiques bottom-up.

Caricatures de logiques top-down : en haut, prise de vue Zabriskie Point, de Michelangelo Antonioni (1970) : des spéculateurs immobilier.. En bas : des soldats américains en plein « tent briefing », en mai 1944, dans le sud de l’Angleterre – source : http://ww2today.com.

Bureaucratic Information Modelling

Ces prises de pouvoir ont un aspect dérisoire – elles s’en tiennent à la redescription, via de nouveaux labels et de stratégies de communication triviales, d’un objet pré-existant sur lequel elles n’ont pas d’action. Quel est l’impact d’un diagramme bureaucratique sur une réalité effective, un processus en marche ? Quelle est la validité intellectuelle d’un tel schéma désuet contre une technologie ? Si définir et créer un objet constitue un acte fondateur, il nous semble que relabeliser un objet doté d’une existence propre est un acte creux, mais hautement politique – comme lorsqu’une ville ou une place est renommée lors d’un coup d’état…

De ces tentatives politiques d’encadrer un objet performatif, on peut déduire que celui-ci a quelque chose de menaçant pour les formes de pouvoir en place. Bien évidemment, l’établissement d’un workflow BIM, si autogéré soit-il, n’empêche pas les décideurs de décider – l’argent et le politique s’en chargent[10]. Par contre, l’objet maquette numérique, de par sa centralité, son accessibilité et sa transparence, constitue tout de même, si n’est un contre-pouvoir, au moins un garde-fou, ou un moyen de contrôle plus précis du pouvoir à l’œuvre.

Ainsi, cet objet autonome gêne. Pour l’encadrer, on segmente et on retient : l’on entasse les processus, on multiplie les maquettes numériques, on rajoute des sas, des étapes, l’on rigidifie l’information, on freine… Par exemple, sur le projet de la Fondation Luma, avant même le début de la phase EXE, on comptait déjà quatre maquettes différentes, quasiment similaires, copies plus ou moins exactes ou à jour les unes des autres – frilosité de diffusion de l’information. Situation parfaitement surréaliste, quand on pense qu’un des leitmotivs du BIM est de centraliser et fluidifier l’information.

À cette époque, dans le même ordre d’idées, une de nos discussions avec Gehry Partners au sujet des systèmes BIM pour la Fondation Luma fut édifiante. Une de leur demande était d’avoir un accès à l’intégralité des maquettes des entreprises. Mais quand nous leur avons annoncé que nous avions réussi à mettre en place une maquette partagée sans filtre de validation – c’est-à-dire qu’ils avaient accès, en temps réel, aux dernières modélisations des entreprises, à leur modèle de travail live, gigantesque work in progress collaboratif, les choses se sont gâtées… Et les architectes se sont rétractés :  ils voulaient tout de même pouvoir ouvrir un modèle propre, pas un brouillon. En d’autres termes, ils voulaient rétablir une certaine forme de féodalité ; que l’information leur soit livrée, et non pas accéder eux même à l’information. Ils ont eux-mêmes, d’office, rajouté un sas bureaucratique, et donc entamé la fluidité de l’information dont ils ont pourtant besoin, dans ce désir contradictoire de tout contrôler sans pour autant mettre les mains dans le cambouis.

Lire la suite : III/III La désorganisation scientifique du travail

——————————————————————————————————

[1] Hambourg, Rowolht Verlag, 1932 (Paris, Editions du Seuil, 1956 pour la traduction française) p. 581.

[2] Comme l’illustre la citation ci-dessus, Musil, dans son roman culte L’homme sans qualité, ironisait déjà à propos du paradoxe du bibliothécaire, figure humaine, s’il en est, du système d’information, qui créée du sens par référencement.

[3] Prenons l’exemple trivial d’une façade classée en types de matériaux ; si ces matériaux changent et que certains éléments migrent d’une catégorie à une autre, comment suivre et garder une vue d’ensemble des différents sous-éléments ?  À ce sujet, Bernard Cache répondait déjà à Peter Macapia, dans une interview de 2008 filmée par Pierre Cutellic :  “ […] you get four objects, you get four spaces. So now where is the inside, where is the outside? If those spaces are objects in the database of a software, how do you number them? This is a huge problem. And I can tell you that we are only at the beginning of attacking this problem. […] You know it is a way to go around the problems, but to really confront it and make it possible that a certain entity becomes a multiple, and then comes back to one similar entity, that is very hard to do with the software”. (Interview non publiée / mise gracieusement à disposition par Peter Macapia).

[4] Cette question de l’ontologie et du BIM est vaste, et nous ne faisons ici que l’effleurer. Voir cet article, pour aborder la question : Ana Cristina, Bicharra Garcia, John Kunz, Martin Ekstrom, Arto Kiviniemi : “Building a project ontology with extreme collaboration and virtual design and construction”, Avril 2004.

[5] Nous avons ici un peu de scrupules à reprendre la phrase de Camus, qui est ré-utilisée à tort et à travers … Mais cette phrase, quand on en vient à la logique ontologique du BIM, ne peut que grandement résonner, de manière extrêmement factuelle : « Mal nommer un objet, c’est ajouter au malheur de ce monde ». Albert Camus, Sur une philosophie de l’expression, 1944.

[6] “Level of development” : niveau de développement.

[7] Même si les plans économiques divergent – les cabinets d’architecture et entreprises de construction ne gagnent pas d’argent selon les mêmes modalités. Les premiers par exemple n’ont pas intérêt à des modifications de dernière minute, tandis que les seconds facturent des travaux supplémentaires… etc.

[8] L’anglicisme workflow est devenu très à la mode en France, et fais souvent office de mot valise. Ainsi nous précisons que par workflow, nous entendons ici un ensemble de processus collaboratifs non linéaire liés à un même projet.

[9] Sur ce projet, les architectes sont bien évidemment Gehry Partners ; les architectes locaux français étant Studios Architecture.

[10] Nous avons ici conscience d’une certaine dichotomie, entre un pouvoir politique et technocratique… Mais nous assumons ce parti, étant donné l’aspect souvent primaire, violent, douteux des marchés du BTP souvent corrompus. Ainsi, nous nous reconnaissons dans cette réflexion de Rifkin : « La conversion de masse aux nouvelles valeurs technocratiques fut si efficace que même le choc de la crise de 1929 ne dissuada pas les Américains de continuer à défendre leur utopie technocratique. Ils choisirent plutôt de retourner leur colère et leur peur contre les hommes d’affaires avides qui, dans leur esprit, avaient sapé et contrecarré les objectifs élevés des nouveaux héros du pays : les ingénieurs. » Jeremy Rifkin, La fin du travail, Paris, Éditions La Découverte, Paris, 1995, p.85.