# Plateformes de conception

## Design Platforms

Milovann Yanatchkov*,**

¹UMR MAP-MAACC 3495 CNRS/MC, ENSA Paris La Villette, Paris, France

**Résumé.** Le BIM s'est progressivement imposé comme un standard organisé autour d'une maquette numérique (BIM Niveau 2). Dans unenvironnement technologique à présent dominé par l'usage massif des réseaux numériques, les « plateformes de conception » représentent un nouveau paradigme de modélisation distribuée (BIM Niveau 3). Dans ce contexte, le principe « monolithique » des logiciels de bureau tend à évoluer vers des applications en ligne plus spécialisées. La possibilité qu'offre ce nouveau paradigme de composer des applications et des données provenant de sources variées rend possible la création de chaînes complexes de modélisation qui annoncent une évolution possible des principes fondamentaux du BIM.

**Mots clés.** Plateforme, Plateforme de conception, Conception générative, BIM.

**Abstract.** BIM has gained a central role in the digital modeling and exchange of information with the advent of international standards (BIM Level 2). In a context of an ubiquitous digital network at the core of our information age, new “design platforms” are emerging as distributed digital design tools (BIM Level 3). This trend shows a subtle shift from traditional desktop « software » towards online and more specific “applications”. The new approach allows the constitution of complex design workflows heralding a possible evolution of BIM's core principles.

**Keywords.** Platform, Design platform, Generative design, BIM.

## 1 Introduction

Nous discutons dans cet article de l'évolution des logiciels de conception du secteur AEC (Architecture, Ingénierie, Construction) vers le nouveau paradigme des « plateformes de conception ». Dans une précédente étude nous nous sommes intéressés à l'« émersion

<footnote>* Corresponding author: milovann.yanatchkov@nancy.archi.fr</footnote>
logicielle » entendue comme un mouvement menant « hors des logiciels ». Par l'entremise d'un serveur 3D, des applications hétérogènes peuvent se connecter pour former des objets composites prenant forme dans un espace plus global. Nous avons proposé de décrire ce phénomène comme une forme de « modélisation par le flux » [1]. À titre expérimental nous avons développé un prototype<fnref n="2" /> nous ayant permis de démontrer par preuve de concept la validité de ce « modèle collaborant » ou « modèle distribué ». Nous nous sommes référés à la « programmation par le flux » pour décrire ce contexte dans lequel une série de fonctionnalités externes et autonomes peuvent se combiner pour former des chaînes complexes de modélisation. Suite à cette étude, nous avons ouvert début 2020 le site continuum codes<fnref n="3" /> qui décrit l'espace de cette émersion avec le principe de « continuum numérique » comme référence théorique. Le site consacre une page aux plateformes de conception<fnref n="4" /> et inclut un prototype développé pour l'occasion. D'un point de vue technique, nous avons mobilisé l'idée de continuum pour mettre en avant la complémentarité et la continuité de certaines briques logicielles — applications ou bibliothèques de développement — que nous avons proposé de classer suivant une architecture « par couche » : noyau, modèle, interface, flux, computation, application. Suite à l'ouverture de continuum codes, nous avons ouvert le séminaire de recherche *Continuum* consacré à la notion de « continuum numérique »<fnref n="5" />. Lors de la session inaugurale, nous avons proposé un support théorique général à l'idée de « continuité » (idée/matière et discret/continu) [2]. Nous avons également présenté un prototype de plateforme de conception (figure 1) sous la forme d'une preuve de concept réalisée sur la base du prototype développé pour continuum codes et en conjonction avec la plateforme de programmation collaborative Jupyter<fnref n="6" />. Dans la continuité de ces recherches nous avons intégré dans le projet *Continuum* le thème des plateformes en début d'année 2021⁷, et nous avons constitué un groupe de travail réunissant sur cette thématique des enseignants-chercheurs en ENSA<fnref n="8" />.

<figure><img src="image_1.png" /><figcaption>**Figure 1.** Led : une plateforme de conception expérimentale basée sur Jupyter.</figcaption></figure>

<footnote n="2">² https://plateformes.codeatlas.cc/echo/</footnote>

<footnote n="3">³ https://continuum codes</footnote>

<footnote n="4">⁴ https://continuum codes/platforms/</footnote>

<footnote n="5">5 https://continuum.codeatlas.cc/</footnote>

<footnote n="6">6 https://jupyter.org/</footnote>

<footnote n="7">⁷ https://plateformes.codeatlas.cc/</footnote>

<footnote n="8">8 https://plateformes.org/</footnote>
## 2 Plateformes numériques

Dans le sens le plus général, nous parlons aujourd'hui de « plateforme » pour évoquer une technologie ou une entreprise proposant des services en ligne (recherche d'information, mise en réseau de personnes, vidéos à la demande, jeux vidéos en ligne, vente de biens de consommation, ...). Nous commençons par dresser un tableau de cette situation d'un point de vue socio-économique avant de préciser le sens plus technique du terme « plateforme numérique ».

Les GAFAM9 représentent aujourd'hui ces grandes plateformes numériques en position hégémonique dont les nombreuses « disruptions » sont autant de défis socio-économiques pour les états et les gouvernements. Citons en la matière le « Digital Market Act » (DMA)10 voté par le Parlement européen pour en limiter l'influence en favorisant l'émergence d'un écosystème numérique européen. Cette initiative s'inscrit dans la continuité d'un projet tel que Gaia-X11, un projet en réponse à ces défis qui se posent en termes de « souveraineté » pour les états européens. Dans ce domaine, l'« ubérisation » du travail et ses « externalités négatives », est un phénomène dont nous mesurons déjà les conséquences en matière de conditions de travail ou d'aménagement du territoire<fnref n="12" />. Il s'agit donc de bien saisir la valeur que représentent aujourd'hui les données (*data*) pour ces plateformes : une ressource « soumise à extraction et raffinage avant exploitation » [3]. Dans une étude réalisée par Claude Paraponaris du laboratoire LEST de l'université d'Aix-Marseille intitulée « Vers une monopolisation de la conception industrielle. L'exemple de la market place de Dassault Systèmes. » [4], la question des plateformes de conception est abordée en interrogeant la part disruptive que l'émergence des « places de marché numériques » vont représenter pour les conditions de travail des ingénieurs du secteur industriel notamment. Se référant à la volonté annoncée du groupe Dassault Systèmes de devenir l'« Amazon du monde de la production », l'auteur analyse les risques d'« ubérisation » qui vont se poser pour les ingénieurs en prise avec ces nouvelles places de marché numériques et l'impact qu'elles vont avoir sur les capacités d'innovation notamment.

D'un point de vue plus technique, il n'existe pas de définition « canonique » pour décrire les plateformes numériques, mais si l'on se réfère à Wikipedia une « plateforme informatique »<fnref n="13" /> peut être autant un système d'exploitation qu'un environnement de développement ou un serveur web. Dans un sens très général l'idée de plateforme informatique peut donc sembler bien floue, mais elle reflète malgré tout une réalité : on parle de plateforme pour évoquer une sorte d'« espace numérique » élargi, un support ou un contenant pour des collections d'« éléments applicatifs » fonctionnant en réseau et formant une « unité fonctionnelle ». En un sens, on peut rapprocher l'idée de plateforme numérique avec celle d'un « écosystème numérique ». Si le principe de plateforme numérique semble très général c'est qu'il est synonyme d'« environnement ». On comprend donc qu'il peut s'appliquer à tout environnement numérique dès lors qu'il est composé d'un certain nombre de services couvrant un spectre assez large de fonctionnalités. Nous voyons dans cette notion d'environnement numérique le signe d'un changement d'époque technologique vers un espace « post-logiciel ». Dans ce nouveau contexte, le logiciel ne représente plus qu'un élément, parmi d'autres, dans un écosystème plus large d'applications en interactions. Dans le contexte de notre étude, nous pouvons parfaitement saisir ce changement de paradigme avec la

<footnote n="9">⁹ Google Amazon Facebook Apple Microsoft</footnote>

<footnote n="10">¹⁰ https://ec.europa.eu/competition-policy/sectors/ict/dma_en</footnote>

<footnote n="11">¹¹ https://www.gaia-x.eu/</footnote>

<footnote n="12">¹² https://journals.openedition.org/rdctss/1532J</footnote>

<footnote n="13">¹³ https://fr.wikipedia.org/wiki/Plate-forme_(informatique)</footnote>
plateforme Forge<fnref n="14" /> d'Autodesk qui concentre aujourd'hui l'essentiel des efforts de développement au détriment des logiciels tels que Revit [5] ; un changement d'époque technologique à la source de tensions entre l'éditeur et les utilisateurs du logiciel<fnref n="15" />.

# 3 Plateformes et BIM de niveau 3

Les plateformes de conception que nous cherchons à décrire sont des instruments de nouvelle génération qui prolongent l'évolution des instruments BIM de première génération. Nous présentons dans cette partie le contexte à partir duquel ils évoluent.

## 3.1 Niveaux BIM

Dans le jargon BIM, le principe de « niveau de maturité » (BIM levels) fait référence à un diagramme publié par Mark Bew et Mervyn Richards en 2010 [6]. Il s'agit d'une représentation schématique qui présente l'évolution du BIM sous la forme d'une échelle ouverte orientée dans le temps. Cette échelle a pour origine un niveau 0 associé à un stade pré-numérique symbolisé par le support papier. Le domaine de « maturité BIM » commence à partir du niveau 1 symbolisé par le support de type fichier numérique. Ce niveau correspond à la première génération de logiciels de conception CAO (Conception Assistée par Ordinateur) et comprend les représentations numériques en 2D et les modèles 3D « pré-BIM » non standardisés. La modélisation BIM commence donc avec le niveau 2 de cette échelle qui est aujourd'hui associé au standard IFC (Industry Foundation Classes). Les plateformes de conception que nous proposons de décrire prennent leurs origines au niveau 3 de cette échelle. Notons que ce niveau est marqué, dans le diagramme de Bew & Richards, d'un trait rouge sur sa partie gauche le séparant du niveau 2, indiquant en cela une forme de rupture dans l'évolution de la technologie ; nous remarquons également que la partie droite est marquée par une ligne en zig-zag symbolisant le côté « ouvert aux innovations » de la technologie.

## 3.2 BIM de niveau 3

Nous relevons dans la description du niveau 3 du diagramme de Bew & Richards l'expression « Integrated Web Services BIM Hub » car elle correspond aux plateformes de conception que nous cherchons à décrire : un plateau (hub) de services web « intégrés » pour le BIM. Bien que le terme de plateforme ne soit pas encore explicitement mentionné, le schéma associé à cette définition représente déjà notre objet d'étude : un ensemble symbolisé par une « pile » comprenant des éléments de natures variées (BIM, GIS, ...) ainsi qu'une double flèche renvoyant à un espace « extérieur » identifié par divers formats de données (IFC, DWG, SQL, ...). Pour donner une assise un peu plus précise et actualisée à cette origine nous proposons de compléter cette description avec une version « enrichie » de ce diagramme réalisée par le groupe Dassault Systèmes dans un livre blanc (white paper) intitulé « End-to-end collaboration enabled by BIM level 3 » [7] page 2. Ce document nous intéresse car il précise un certain nombre de standards pour les niveaux 0, 1 et 2. Le diagramme nous donne également un cadre plus précis en matière chronologique en indiquant les années 2020 pour ce troisième niveau de maturité. Enfin, il fait mention du caractère transactionnel

<footnote n="14">¹⁴ https://forge.autodesk.com/</footnote>

<footnote n="15">¹⁵ https://letters-to-autodesk.com/</footnote>
(transactable) de ce niveau technologique, un point sur lequel nous reviendrons en
conclusion de notre étude.

3.3 Environnements de données

Nous voyons clairement émerger les premières plateformes BIM avec le principe d'« environnement de données en commun » (CDE pour Common Data Environment). Les CDE sont donc des plateformes numériques dont la fonction principale est le stockage, l'échange et l'annotation de données produites par des logiciels BIM. Nous pouvons identifier les CDE comme des « plateformes collaboratives » [8] dans le sens où elles servent de support et de plateau d'échange. Nous montrerons dans la quatrième partie comment les « plateformes de conception » jouent un rôle plus « actif », au même titre qu'un « logiciel de conception » (authoring software), contrairement au rôle plus « passif » et limité des plateformes collaboratives.

Nous pouvons distinguer les CDE de première génération avec des versions plus évoluées qui sont parfois identifiées comme des « plateformes d'intégration » [9]. Une terminologie qui permet de mettre en avant les processus d'agrégation, d'intégration et de consolidation de données provenant d'acteurs et de formats multiples. De ce point de vue, il est intéressant de bien distinguer deux types d'environnements dans un contexte où les limites entre les « silos informationnels » — l'intégration verticale et cloisonnée des applications métiers — sont des barrières qui appellent à être levées. Dans une étude récente menée par l'ETH de Zurich [10], la distinction entre « CDE ouverts » et « CDE fermés » est clairement identifiée comme une problématique équivalente à celle des anciens formats propriétaires. La « non-interopérabilité » de ces plateformes fermées se traduit donc comme un retour à des silos fermés et met en avant la nécessité de standards ouverts pour ces nouveaux types d'environnements.

3.4 Les limites de l'interopérabilité

Les plateformes collaboratives jouent un rôle important dans la gestion de l'interopérabilité des données en servant d'intermédiaire permettant de décloisonner les silos numériques grâce à des formats ouverts tels que les IFC. Mais paradoxalement, le caractère « universel » des IFC est problématique dans le fait même qu'ils couvrent un trop large spectre d'informations associées à des domaines parfois très éloignés. De cette massification de l'information résulte un « encombrement » (bloating) véritablement problématique générant des fichiers de plus en plus lourds. C'est ce que met en lumière le projet AEC Delta [11] : l'état actuel des chaînes d'interopérabilité impliquent l'échange de fichiers massifs dont l'encombrement et l'aspect « monolithique » est problématique. Le projet met en avant la nécessité d'élaborer des formats à un niveau de granularité plus fin, où la maquette n'est plus considérée « d'un bloc », mais comme constituée d'une série d'éléments plus indépendants [12]. Il s'agit ici d'évoluer vers un au-delà des « fichiers statiques » avec des protocoles d'échange tels que nous les avons identifiés à travers le concept de modélisation par le flux. Nous verrons que les plateformes de conception sont le lieu où peuvent se constituer de telles chaînes de modélisation.

4 Plateformes de conception

Nous proposons à présent de décrire les plateformes de dernière génération du secteur AEC
avant de donner un cadre de définition au principe de plateforme de conception.
## 4.1 L'écosystème des plateformes AEC

Comme nous l'avons vu dans la deuxième partie, en informatique le principe de plateforme reste un objet aux contours assez flous. Du point de vue de notre objet d'étude, il peut cependant exprimer deux idées bien précises : le recentrage technologique vers le web d'une part, et le passage d'un objet logiciel clos et monolithique vers une offre de services plus globale d'autre part. Dans la troisième partie nous avons vu que les seuls formats d'operopérabilité ne répondent plus aux besoins de processus de conception de plus en plus réactifs comme c'est le cas avec l'approche de la conception « pilotée par les données » ou avec la modélisation par le flux. Dans ce contexte, les données générées par un logiciel sont moins importantes que les opérateurs ou les fonctions génératrices à la source de ces données. Nous décrivons à présent les plateformes de conception comme un espace où sont assemblées et générées de telles fonctions, en distinguant deux types de plateformes : les « plateformes propriétaires » et les « plateformes open source ».

### 4.1.1 La « Forge » d'Autodesk

Du côté des plateformes propriétaires — c'est-à-dire « non libres » dans le sens de l'open source — le fait le plus marquant dans l'évolution vers les plateformes concerne la mise à disposition — sous certaines conditions et moyennant finances — de ressources technologiques permettant à des entreprises spécialisées ou à des bureaux d'étude de développer des instruments sur mesure ou de nouveaux types de services en ligne comme c'est le cas avec la Forge d'Autodesk. Techniquement, cela signifie donner un accès aux fonctionnalités des codes sources via une interface applicative de programmation (Application Programming Interface). En ayant accès à ces ressources, l'utilisateur peut composer de nouveaux logiciels, ou pour employer un vocabulaire plus adapté, de nouvelles « applications » offrant de nouvelles fonctionnalités. Dans le cas de la Forge d'Autodesk nous voyons clairement que ces nouvelles API web élargissent les possibilités de développement bien au-delà des extensions traditionnelles de logiciels (plugins) et offrent la possibilité de constituer de véritables produits qui sont ensuite commercialisés sur les places de marché numériques. Nous pouvons classer ce type d'environnement du côté des plateformes de développement fermés car la technologie est centrée sur un fournisseur unique impliquant un effet silos. De plus, le code source — propriétaire — n'est pas directement accessible par l'utilisateur final car il est uniquement hébergé sur les serveurs privés de la société.

### 4.1.2 Logiciels en tant que services

Avec l'essor des grandes plateformes (GAFAM) de nouveaux standards et de nouvelles technologies — principalement open source — ont permis de consolider les technologies embarquées dans les navigateurs web<fnref n="16" />. Ces avancées ont donné lieu à l'émergence d'un marché d'applications en ligne sur le modèle des « SaaS » (Software As A Service). Ces « logiciels en tant que services », contrairement aux logiciels traditionnels, ne sont pas installés chez les utilisateurs mais ils sont utilisables via le réseau et sur abonnement. Les services proposés peuvent aller de simples fonctionnalités de « gestion électronique de document » (GED) dans le cas de PlanGrid<fnref n="17" /> par exemple, jusqu'à des services d'intelligence artificielle dans le cas de SpaceMaker<fnref n="18" /> — deux entreprises rachetées par Autodesk. D'une

<footnote n="16">¹⁶ HTML5, WebGL, Wasm, ...</footnote>

<footnote n="17">¹⁷ https://www.plangrid.com/</footnote>

<footnote n="18">¹⁸ https://www.spacemakerai.com/</footnote>
façon générale, ces plateformes sont conçues sur la base d'une interface web 3D associée à une série de fonctionnalités bien spécifiques. Pour les plus « simples » d'entre elles, il s'agit de CDE « avancés » de type « plateforme d'intégration » (BIMdata<fnref n="19" />, 3Drepo<fnref n="20" />,...). D'autres plateformes proposent des services d'automatisation plus avancés (HighArc<fnref n="21" />, TestFit<fnref n="22" />,...) revendiquant parfois une véritable disruption du modèle CAD traditionnel (Computer Aided Design) [13].

## 4.2 Les plateformes de conception ouvertes

Nous nous intéressons à présent au cas des environnements ouverts car ils font partie des modèles de plateformes de nouvelle génération les mieux adaptés au développement et à la consolidation des « plateformes de conception » pour plusieurs raisons. En premier lieu, ces environnements étant basés sur des sources libres et ouvertes, incluant souvent dans les processus décisionnels la « communauté élargie » des développeurs et utilisateurs, ils sont mieux placés en matière de neutralité par rapport aux plateformes propriétaires pour aider à décloisonner les silos computationnels et informationnels. Cette neutralité se traduit naturellement dans une forme de neutralité de la technologie (formats de données et bibliothèques) formant ainsi au sens propre des « plateformes de développement » qui répondent aux critères de la modélisation par le flux. Nous présentons brièvement deux projets qui correspondent à ces types d'environnements.

### 4.2.1 Speckle

Speckle<fnref n="23" /> est un serveur 3D pour l'interopérabilité AEC associé à une plateforme web. Le projet est issu des recherches menées par Dimitri Stefanescu à la Bartlett School de Londres [14]. La plateforme Speckle est un environnement de développement pour des « clients » — c'est-à-dire des plugins — ciblant un large panel de logiciels AEC (Revit, Grasshopper, ...). La plateforme web permet de visualiser, depuis un navigateur, les éléments partagés via des « streams » — des « flux » — qui peuvent être des objets ponctuels (éléments géométriques ou objets BIM) ou des maquettes BIM complètes. Le projet se constitue aujourd'hui en place de marché numérique où un certain nombre d'acteurs externes proposent de nouveaux services basés sur les fonctionnalités qu'offre la plateforme.

### 4.2.2 BHoM

BHoM<fnref n="24" /> est un noyau logiciel (kernel) pour l'interopérabilité AEC. Contrairement à Speckle, BHoM n'est pas orienté web dans le sens où le projet est principalement développé en C# sous la forme de bibliothèques logiciels qui viennent se connecter directement sur les logiciels et les services ciblés (Revit, Grasshopper, ...). En revanche, il est intéressant de noter que BHoM s'inscrit parfaitement dans ce que l'on appelle une plateforme au sens de plateforme de développement : le projet contient un noyau de primitives et d'objets BIM qui sont associés à une grande collection de fonctionnalités souvent très spécialisées en matière

<footnote n="19">¹⁹ https://bimdata.io/</footnote>

<footnote n="20">²⁰ https://3drepo.com/</footnote>

<footnote n="21">²¹ https://higharc.com/</footnote>

<footnote n="22">²² https://testfit.io/</footnote>

<footnote n="23">²³ https://speckle.systems/</footnote>

<footnote n="24">²⁴ https://bhom.xyz/</footnote>
d'ingénierie, offrant ainsi une large « surface de développement » pour tout type de logiciels ou d'applications pour l'architecture et l'ingénierie.

## 4.3 Les plateformes de développement

### 4.3.1 Le statut des utilisateurs-développeurs

L'écosystème naissant des plateformes open source AEC est un phénomène relativement récent qui préfigure la consolidation du modèle des plateformes de conception, mais reflète également un phénomène qui mérite d'être souligné à sa juste mesure : l'avènement d'un profil hybride d'« utilisateur-développeur » dans le monde de la construction. Nous nous référons au terme d'« utilisateur-développeur » (end-user developer) identifié dans la littérature comme des pratiques de « développement-utilisateur » (end-user development) [15]. Cette appellation fait référence aux pratiques de développement logiciel — c'est-à-dire de programmation — par des « non-informaticiens ». Dans un monde ou la culture numérique est devenue une culture à part entière, des spécialistes venus de champs extérieurs à l'informatique ont incorporé les pratiques de programmation dans leurs domaines d'expertise. Dans le champ AEC nous pouvons clairement identifier les pratiques de programmation visuelle, qui sont des pratiques de « programmation-utilisateur », comme le stade initial menant vers le développement-utilisateur. La démocratisation des pratiques de « script » avec – le langage Python notamment – représente le chaînon qui mène directement vers des pratiques plus avancées de conception informatique. Au-delà des langages de scripts, la connaissance et la pratique de langages de plus bas niveau comme le C# par exemple, sont un pont vers de véritables pratiques de développement-utilisateur, comme c'est le cas avec BHoM, une technologie développée par des ingénieurs AEC non-informaticiens.

### 4.3.2 L'exemple Hypar

Nous voyons donc que dans la distinction que nous avons proposée entre « plateformes collaboratives » et « plateformes de conception », il est légitime d'ajouter les « plateformes de développement » comme une catégorie encore plus avancée dans laquelle des utilisateurs-développeurs ont intégré la pratique de la programmation dans des boucles de « rétroaction » de plus en plus fines entre recherche, développement et utilisation des technologies numériques. Si ces pratiques sont pour l'heure encore marginales, Hypar<fnref n="25" /> est l'exemple type d'une telle plateforme sur le versant commercial. La plateforme est une startup portée par des développeurs issus des rangs d'Autodesk dans lequel nous retrouvons notamment Ian Keough, le développeur du moteur de programmation visuelle Dynamo pour Revit. La plateforme, encore au stade de prototype, préfigure parfaitement ce que seront ces plateformes de développement. Présentant une interface assez similaire aux plateformes collaboratives précédemment analysées, Hypar se distingue nettement de ces plateformes sur deux points : la plateforme offre une « surface de développement » plus large en ouvrant une partie de ses codes sources<fnref n="26" />, et à l'instar de BHoM et Speckle, elle est conçue comme une plateforme de développement à destination des des utilisateurs-développeurs du secteur AEC.

<footnote n="25">²⁵ https://hypar.io/</footnote>

<footnote n="26">²⁶ https://github.com/hypar-io</footnote>
# 5 Conclusion

Ce panorama des plateformes montre dans quelle direction une nouvelle itération des principes constitutifs de la maquette numérique BIM peut évoluer. Nous avons mis en évidence dans ce contexte un écosystème « post-logiciel » qui offre une plus grande porosité entre utilisateurs et développeurs. Nous proposons pour conclure de récapituler sous la forme de « niveaux de maturité » l'état de cet écosystème et nous tirons des conclusions en forme de prospective concernant le « code » comme le médium d'un « design de transaction ».

## 5.1 Niveaux de maturité des plateformes

Notre étude a pu montrer qu'il existe une gradation dans la technicité et l'usage des « plateformes AEC ». Nous proposons de les classer suivant des « degrés de maturité » à l'instar des niveaux BIM précédemment évoqués en les classant par ordre croissant de maturité :

* « plateformes collaboratives » pour les CDE de première génération

* « plateformes d'intégration » pour les CDE de seconde génération

* « plateformes de conception » pour les plateformes de nouvelle génération

* « plateformes de développement » pour les plateformes de développement-utilisateur

Dans cette diversité nous trouvons donc des problématiques et des niveaux de maturité variés : approches collaboratives et design participatif, places de marché et écosystèmes applicatifs, automatisation de la conception et usages avancés de design génératif, pratiques de développement-utilisateur. Cette diversité offre autant d'axes de recherche différents : plutôt concernés par les aspects organisationnels et disruptifs [4], sur les problématiques d'interopérabilité [8, 12], ou dans la question de l'accessibilité et dans les usages « intermédiaires » du design génératif [16]. Malgré cette diversité des usages et des appellations, nous retenons le principe général de « plateforme de conception » (design platform) comme un environnement logiciel de nouvelle génération dans lequel le code informatique acquiert une place nouvelle dans les pratiques de conception architecturale. Dans ce contexte, les plateformes de développement basées sur des sources ouvertes (logiciels libres) offrent un environnement plus adapté aux pratiques émergentes de développement-utilisateur dans le secteur AEC.

## 5.2 Code de conception

En toute logique, plus les plateformes offrent un niveau de maturité élevé, plus les utilisateurs-développeurs, qu'ils soient ingénieurs ou architectes, ont un niveau de maturité informatique élevé. Dans ces conditions il serait intéressant de classer à leur tour les langages de programmation (visuels ou textuels) selon ces mêmes critères. Une telle étude dépasse largement le cadre de cet article mais nous soulignons la proximité qui relient ces problématiques : conception distribuée, modélisation par le flux, plateformes de conception, langages de programmation. Les plateformes arrivent, après les interfaces de programmation visuelle (Grasshopper, Dynamo, ...) comme un deuxième niveau de maturité en termes de conception générative dans lequel le « code » devient un élément central et « autonome » que nous proposons d'identifier comme un « code de conception » (design as code).
## 5.3 Design de transaction

Le « code de conception » représente un niveau élevé de maturité numérique dans le parcours de transition numérique du secteur AEC. Les dimensions scripturales et algébriques qui caractérisent ce nouveau médium diffèrent radicalement du dessin et de la géométrie propres au médium traditionnel de l'architecte. De ce point de vue, nous voyons dans le « mimétisme » de la maquette BIM de première génération avec la maquette physique traditionnelle un « obstacle épistémologique » qui se traduit dans les limitations actuelles du modèle. Avec les nouvelles plateformes de conception, une nouvelle vision de la maquette numérique est en train d'émerger autour d'« objets transactionnels » tels qu'évoqués par exemple dans le livre blanc publié par Dassault Systèmes ou dans les travaux de recherches à l'origine du projet Speckle [14]. Une évolution de la technologie préfigurant la possibilité de nouvelles pratiques de conception orientées vers un « design de transaction » mettant en avant l'information sous sa forme textuelle et procédurale.

## Références

1. M. Yanatchkov. Modélisation par le flux. In SCAN '18 : Séminaire de Conception Architecturale Numérique, **47**, page 01006, Nantes, France (2018)

2. M. Yanatchkov. Qu'est-ce qu'un continuum numérique ? https://continuum.codeatlas.cc/continuum/ (2020)

3. N. Srnicek. *Platform Capitalism* (John Wiley & Sons, 2016)

4. C. Paraponaris. Vers une monopolisation de la conception industrielle. L'exemple de la market place de Dassault Systèmes. In 36ème colloque INformatique des ORganisations et Systèmes d'Information et de Décision (2018)

5. M. Day. The future of Revit, AEC Magazine, https://aecmag.com/bim/the-future-of-revit/ (2020)

6. A. Alaghbandrad et D. Forgues. Development of a model to select BIM implementation strategy with respect to the BIM maturity level of an organization. Proceedings, Annual Conference - Canadian Society for Civil Engineering, 2:1149–1158 (2013)

7. Dassault Systems. End-to-end collaboration enabled by BIM level 3 (2016)

8. L. Sattler. Amélioration de l'interopérabilité BIM via un cadre de co-modélisation par requêtes et enrichissements itératifs de données. Thèse de doctorat, HESAM Université (2021)

9. B. Succar. *The Five Components of BIM Performance Measurement* (CIB World Congress, 2010)

10. D. Bucher et D. Hall. Common Data Environment within the AEC Ecosystem : moving collaborative platforms beyond the open versus closed dichotomy. EG-ICE 2020 Proceedings: Workshop on Intelligent Computing in Engineering, p. 491, Universitätsverlag der TU Berlin (2020)

11. UCL. AEC Delta Mobility (2019) https://www.ucl.ac.uk/bartlett/construction/research/management-projects/aec-delta-mobility

12. P. Poinet. Enhancing Collaborative Practices in Architecture, Engineering and Construction through Multi-Scalar Modelling Methodologies. Thèse de doctorat (2020)

13. HighArc — A Sea Change in Home Building (aka CAD is the walking dead) | by Javelin VP | Medium
https://medium.com/javelin-vp/higharc-a-sea-change-in-home-building-aka-cad-is-the-walking-dead-aec6cdcace81

14. D. Stefanescu. Alternate Means of Digital Design Communication. Thèse de doctorat (2020)

15. G Fischer et E. Giaccardi. Meta-design: A Framework for the Futureof End-User Development. 9, pages 427-457 (2006)

16. A. de Boissieu. Introduction to Computational Design: Subsets, Challenges in Practice and Emerging Roles. In: Bolpagni, M., Gavina, R., Ribeiro, D. (eds) Industry 4.0 for the Built Environment. Structural Integrity, 20. Springer (2022)