Introduction

Dans le contexte de la transition environnementale, il est courant que les équipes de maîtrise d’œuvre adoptent un processus de conception itératif. Ce processus implique une collaboration entre les équipes d’architectes et d’ingénieur·es, avec une alternance de phases de conception/modélisation et d’analyses/simulations. Cependant, certains scientifiques considèrent que l’intervention des ingénieur·es est trop tardive, servant alors davantage d’outil de validation que d’outil d’aide à la décision (Attia et al., 2013).

Aujourd’hui, la programmation visuelle, qui permet au non-professionnel de la programmation informatique de coder facilement dans les logiciels de dessin d’architecture, facilite l’interopérabilité entre les outils de modélisation 3D des architectes et les outils d’analyses environnementales des ingénieur·es (études thermiques, de lumière, de vent), permettant ainsi d’automatiser en partie ce processus itératif, puisqu’il devient possible de diriger les outils de simulation depuis les logiciels de modélisation. L’arrivée, notamment, de l’outil de programmation visuelle Grasshopper du modeleur 3D Rhinocéros au milieu des années 2000 a permis l’essor d’une nouvelle philosophie de conception et une démultiplication du nombre de publications scientifiques sur le sujet, faisant de la conception générative et performative un champ de recherche à part entière (Touloupaki et Theodosiou, 2017).

Cette approche cherche à reproduire automatiquement et rapidement, et en grand nombre, le processus itératif entre architectes/ingénieur·es à l’aide d’un algorithme génératif. La modélisation paramétrique permet de faire varier facilement un modèle 3D. Si le modèle paramétrique est connecté aux outils d’analyse, alors, à chaque variation d’un paramètre, un nouveau modèle 3D est créé et analysé de façon automatique. En déléguant à l’ordinateur la tâche qui consiste à faire varier les paramètres, il peut générer de nombreuses variantes pour un même projet. Et en lui donnant la capacité d’apprendre au fur et à mesure des générations, il peut générer des solutions de plus en plus performantes.

Pour modéliser informatiquement cet algorithme, trois modèles sont nécessaires (voir Figure 1) :

1. Il est d’abord nécessaire d’élaborer un modèle permettant de créer différents scénarios de projet, qu’on nomme le « modèle génératif ». L’ensemble de ces scénarios s’appelle un « ensemble de solutions ». Dans la grande majorité des cas décrits dans la littérature, le modèle génératif est un simple modèle paramétrique.

2. Ensuite, l’utilisateur·rice relie le modèle paramétrique à des logiciels existants ou à des méthodes simplifiées d’évaluation. C’est le « modèle d’évaluation ».

3. Enfin, si l’ensemble de solutions ne peut être entièrement exploré dans un délai raisonnable, un algorithme d’optimisation peut être utilisé à l’aide d’un outil comme Galapagos (Rutten, 2011) pour déterminer la combinaison de paramètres permettant d’approcher un optimum global. C’est le « modèle d’exploration ».

Figure 1 : Fonctionnement général d’une méthode générative et exemple d’application

Source : auteur.rices

Il existe aujourd’hui une très grande quantité de publications de recherche sur le design génératif et performanciel appliqué à l’architecture illustrées par des cas d’études, mais ces applications se font bien souvent en dehors de la pratique professionnelle (Li et al., 2020), même s’il existe quelques exceptions notables (Haymaker et al., 2018 ; Shen et al., 2018). Certain·es auteur·rices ont tenté d’expliquer cet écart entre la théorie et la pratique en s’appuyant sur des revues de littérature d’applications réalisées en dehors d’un contexte professionnel, faute de pouvoir rassembler suffisamment de cas d’études issus de la pratique. Leurs arguments restent aujourd’hui des suppositions qui n’ont pu être démontrées ou observées en agence d’architecture.

L’objectif de cet article est de comprendre les limitations actuelles des méthodes génératives qui freinent leur démocratisation dans les agences d’architecture. À travers un retour d’expérience basé sur des applications réalisées sur des cas réels en cours de conception à l’agence Architecture Studio, principalement pour la conception d’enveloppes, nous cherchons à identifier les obstacles et les opportunités qu’offrent ces approches. Cette recherche, menée sur plusieurs années, s’inscrit dans le champ de la conception computationnelle et environnementale. Toutefois, nous nous adressons ici à l’ensemble des architectes intéressé·es par les pratiques numériques pour la conception architecturale, afin de faire connaître ces méthodes, de montrer les opportunités qu’elles représentent pour les architectes et les agences d’architecture, mais aussi les connaissances techniques que leur utilisation implique.

Après avoir exposé les différentes limites à la mise en pratique de telles méthodes identifiées dans la littérature scientifique, nous expliquerons comment les expérimentations ont été mises en place et présenterons l’ensemble des applications réalisées. Enfin, nous ferons notre retour d’expérience en décrivant les limites rencontrées dans la pratique, que nous illustrerons en revenant sur le détail de certaines expérimentations.

Les freins à la mise en pratique identifiés dans la littérature scientifique

Différents types de limites

Régulièrement, des auteur·rices publient des revues complètes (Attia, 2011 ; BuHamdan et al., 2021 ; Ekici et al., 2019 ; Li et al., 2020 ; Nguyen et al., 2014 ; Shi et al., 2016 ; Stevanović, 2013 ; Touloupaki et Theodosiou, 2017 ; Zhao et de Angelis, 2018) des publications scientifiques portant sur le design génératif et performanciel (voir Figure 2).

Figure 2 : Nombre de publications par année sur le design génératif et performanciel

Source : Zhao et de Angelis, 2019

Tableau 1 : Liste des limites qui, d’après la littérature, freinent la mise en pratique professionnelle du design génératif et performanciel

Références	Verrous à la mise en pratique	Types de verrou
(Attia, 2011 ; Shi et al., 2016 ; Touloupaki et Theodosiou, 2017)	Demande un haut niveau d’expertise, des connaissances en termes de logiciels et de programmation, besoin de formation	Pédagogie
(Attia, 2011 ; Nguyen et al., 2014 ; Touloupaki et Theodosiou, 2017)	Temps de calculs incompatibles avec les phases amont	Technique
(Attia, 2011 ; Nguyen et al., 2014 ; Stevanović, 2013)	Manque d’outils d’interopérabilité entre outils d’analyses et d’optimisation	Interface
(Attia, 2011 ; Zhao et de Angelis, 2018)	La formulation d’un problème est complexe	Pédagogie et technique
(Shi et al., 2016 ; Touloupaki et Theodosiou, 2017)	Les problèmes d’architecture sont plus complexes que ceux purement thermiques	Technique
(Attia, 2011 ; Nguyen et al., 2014)	Incertitude des paramètres de simulation et d’optimisation	Robustesse
(Attia, 2011)	Absence de méthode systématique	Pédagogie
(Shi et al., 2016)	Manque d’outils de post-traitement pour l’analyse des résultats	Interface
(Attia, 2011)	Faible confiance dans les résultats. Manque de retour venant de la pratique	Robustesse
(Shi et al., 2016)	Les résultats d’une optimisation multicritères ne sont pas toujours faciles à interpréter	Pédagogie
(Nguyen et al., 2014)	Conflits entre paramètres d’évaluation et d’optimisation	Robustesse
(Nguyen et al., 2014)	Les plateformes d’optimisation (type Matlab) ne sont pas adaptées aux architectes	Interface
(Ekici et al., 2019)	Très peu de méthodes, dans la littérature, intègrent des contraintes d’égalité, pourtant omniprésente en architecture	Technique
(Ekici et al., 2019)	Les temps de calcul limitent les applications à grande échelle	Technique
(BuHamdan et al., 2021)	Les méthodes sont spécifiques à un problème, difficilement généralisables	Robustesse
(BuHamdan et al., 2021)	Interface pas suffisamment « user friendly »	Interface
(BuHamdan et al., 2021)	Il faut intégrer du machine learning pour pouvoir créer facilement des ensembles de solutions qui respectent des règles de conception	Technique
(BuHamdan et al., 2021)	La quantité de critères d’évaluation qui peuvent être pris en compte est trop restreinte	Interface et technique
(Li et al., 2020)	Manque de formation des architectes aux outils d’analyse	Pédagogie

Source : auteur.rices

Les conclusions de ces revues portent souvent sur les raisons de la sous-utilisation de ces méthodes par les architectes, et sur des recommandations des auteur·rices pour remédier à cela. Dans le Tableau 1, nous avons recensé les différents arguments évoqués dans cette littérature. Nous les avons classés en quatre catégories :

1. les limites liées au manque de pédagogie, c’est-à-dire liées à un manque de compétences et de connaissances dans les agences d’architecture ;

2. les limites liées au manque d’interface, qui concernent à la fois la capacité des interfaces homme-machine (IHM) des outils numériques à répondre aux besoins des profils créatifs comme les architectes, mais aussi le manque d’interface entre les outils eux-mêmes (génération, évaluation, optimisation et visualisation) qui permet de faciliter les flux de données et ainsi de rendre l’approche plus fluide ;

3. les limites liées à la robustesse de la méthode, qui remettent en question la stabilité de la performance de l’approche ;

4. les limites techniques, qui justifient la nécessité de poursuivre les recherches en conception computationnelle.

Un besoin de pédagogie

Ces revues n’étant pas toutes récentes, ces arguments ne sont plus tous valables aujourd’hui, notamment concernant la pédagogie. De plus en plus de chercheur·ses s’intéressent avec un œil d’architecte à ces approches autrefois étudiées exclusivement par les ingénieur·es (Shi et al., 2016), et de plus en plus d’applications théoriques intègrent des préoccupations architecturales (Chatzikonstantinou et al., 2019 ; Ercan et Elias-Ozkan, 2015 ; Fathy et Fareed, 2017 ; Negendahl et Nielsen, 2015 ; Showkatbakhsh et Kaviani, 2020 ; Yi, 2019).

En outre, il existe aujourd’hui de nombreux outils d’analyse environnementale open source à la disposition des architectes, notamment via Grasshopper. Ces outils nécessitent peu de connaissances en physique fondamentale et intègrent des fonctions de visualisation conçues pour les architectes. Dans le Tableau 2, nous listons les plugins pour Grasshopper permettant de connecter le modeleur 3D Rhinocéros à différents logiciels de simulation. Nous avons testé plusieurs outils en agence et présentons ce que nous considérons aujourd’hui comme les mieux adaptés au contexte professionnel. Ce sont les outils que nous avons utilisés pour nos expérimentations.

Tableau 2 : Liste des outils Grasshopper pour l’analyse du confort et des critères environnementaux

Critère	Indicateur	Plugin	Logiciel de simulation
Lumière naturelle	Éclairement lumineux	Honeybee	Radiance®
	Facteur de lumière du jour	Honeybee	Radiance®
	Autonomie en lumière du jour	Honeybee	Radiance®
	Éclairement utile	Honeybee	Radiance®
Éblouissement	Daylight Glare Index	Honeybee	Radiance®
	Daylight Glare probability	Honeybee	Radiance®
Qualité de vue	Visibilité	Ladybug
Ensoleillement	Radiation solaire (directe et indirecte)	Ladybug
	Radiation solaire	Honeybee	Radiance®
	Heures d’ensoleillement	Ladybug
Confort au vent	Écoulement des vents	Eddy 3D	OpenFOAM®
Énergie	Prédiction des besoins énergétiques	Honeybee	Energy Plus®
	Prédiction des consommations énergétiques	Honeybee	Energy Plus®
Confort thermique	Predicted Mean Vote	Honeybee	Energy Plus®
	Predicted Percentage of Dissatisfied	Honeybee	Energy Plus®
	Universal Thermal Index	Honeybee	Energy Plus®
ACV	Impact carbone des matériaux de construction	One click LCA
	Impact carbone des consommations énergétiques	Bombyx LCA

Source : auteur.rices

Tableau 3 : liste des masters en conception digitale pour l’architecture

École	Pays	Type	Nom de la formation	Durée (mois)
Architectural Association School of Architecture (AA school)	RU	March MSc	Emergent Technologies and Design	12‑16
Universitat Politecnica de catalunya	Espagne	PM	Parametric Design in Architecture	12
Welsh School of Architecture	RU	MSc	Computational Methods in Architecture	12
The Bartlett School of Architecture	RU	MSc Mres	Architectural Computation	12
Carnegie Mellon University	USA	PM	Advanced Architectural Design	24
Weitzman School of Design	USA	MSc	Advanced Architectural Design	18
Dr. Bhanuben Nanavati College of Architecture for Women	Inde	MArch	Digital Architecture	24
Nottingham Trent University	RU	MSc	Digital Architecture and Construction	12
NMIMS Balwant Sheth School of Architecture	Inde	March	Advance Architecture Design	24
University of Kent	RU	MSc	Bio-Digital Architecture	12
École des ponts et chaussées	France	PM	Digital Building Design	12

Source : auteur.rices

Enfin, ces approches sont enseignées depuis quelques années dans certaines écoles d’architecture. Quelques-unes d’entre elles, notamment anglo-saxonnes, proposent même des masters consacrés à ces nouvelles méthodes de conception. Le Tableau 3 donne une liste non exhaustive des masters en conception digitale ouverts aux étudiant·es en architecture. Il s’agit parfois de masters en architecture (March), de masters en science (MSc), de masters de recherche (Mres) ou de post-masters (PM). Même si nombre de formations existent, une grande majorité des étudiant·es en architecture ne sont encore pas formé·es à ces technologies.

Le manque d’interface

Les arguments relatifs au manque d’interface ne sont plus, eux non plus, tout à fait d’actualité. Concernant l’environnement Rhinocéros/Grasshopper, beaucoup de progrès ont été réalisés pour permettre l’interopérabilité entre les outils de simulation environnementale des ingénieur·es et ceux de modélisation 3D des architectes. Pour faciliter l’interprétation des résultats, des outils d’analyse des données, aussi appelés outils de « data visualisation », comme Design Explorer2 (dont l’interface est présentée en Figure 3), ont été développés (Thornton Tomasetti, 2019).

Figure 3 : Interface graphique de l’application web de data visualisation Design Explorer2

Source : https://tt-acm.github.io/DesignExplorer

De plus, les architectes ont désormais à leur disposition de nombreux outils d’optimisation, dont la plupart sont dotés d’une interface homme-machine qui facilite la saisie des données d’entrée et le suivi de l’exploration. Dans un environnement comme celui de Grasshopper, il existe actuellement huit plugins d’optimisation (sans compter les plugins d’optimisation spécifique, comme l’optimisation topologique) et onze outils d’optimisation au total, permettant d’accéder à plus d’une vingtaine d’algorithmes mathématiques d’optimisation.

La robustesse de la méthode

Concernant la robustesse de la méthode, et notamment la question du manque de retour d’expérience issue de la pratique, il existe désormais quelques exemples de mise en pratique dans un contexte professionnel notable (Haymaker et al., 2018 ; Shen et al., 2018). En 2020, Marcelo Bernal et ses coauteurs comparent ce qu’ils appellent les « approches intuitives » (méthodes traditionnelles des architectes) et les « approches systématiques » (exploration numérique de solutions) dans un contexte professionnel (l’agence Perkins & Will à Chicago), et montrent une amélioration significative et constante des performances des projets après l’utilisation des approches systématiques (Bernal et al., 2020). Cette analyse est conduite sur trois cas d’étude où l’objectif était de maximiser l’éclairage naturel et de minimiser les besoins énergétiques. Il s’agissait d’une enveloppe pour un lycée, d’une empreinte d’un bâtiment pour des laboratoires et de la façade d’un bâtiment résidentiel. Les solutions proposées par les équipes de conception et les solutions optimisées ont ensuite été comparées sur des critères de performance environnementale. Pour chaque cas d’étude, les chercheurs ont récupéré les solutions proposées par les équipes de maîtrise d’œuvre, ils les ont analysées et ont défini un modèle paramétrique permettant de déformer l’esquisse. Leurs résultats ont montré que les solutions ont toutes été améliorées.

Les limites techniques

Au terme de cet état de l’art des revues sur le design génératif et performanciel, il semblerait que trois des quatre limites (qui pourraient expliquer le manque de popularité des méthodes génératives et performatives en agence) les plus couramment citées dans la littérature scientifique ne s’imposent plus avec la même force qu’autrefois. Reste en suspens la question des limites techniques, notamment celle des temps de calcul qui ne seraient pas adaptés aux phases amont de conception. Par exemple, une analyse de la lumière peut aller de quelques secondes à plusieurs heures (par simulation), selon la taille du modèle et le niveau de précision souhaité. Lorsque l’on génère des centaines voire des milliers de solutions, ce temps peut atteindre plusieurs journées, voire semaines.

De nombreux travaux ont déjà été réalisés pour tenter de trouver des solutions à ce problème : l’utilisation de modèles de substitution (où des algorithmes d’intelligence artificielle sont entraînés pour imiter les logiciels de simulation) semble être une réponse prometteuse, même si elle est encore peu appliquée (Westermann et Evins, 2019).

Les applications sur des projets en cours

Mise en œuvre des applications

Pour établir leurs arguments permettant d’expliquer le gap qui persiste entre la théorie et la pratique pour le design génératif, les chercheur·ses précédemment cité·es se sont jusqu’alors appuyé·es sur des revues de littérature avec des cas d’études majoritairement réalisés en dehors d’un contexte professionnel. Nous avons, quant à nous, expérimenté ces méthodes innovantes dans un contexte professionnel et dans une quantité encore jamais décrite à notre connaissance dans la littérature scientifique (quarante-quatre expérimentations au total). Entre janvier 2019 et février 2023, nous avons testé, ces méthodes sur des projets en cours de conception dans l’agence Architecture Studio, dans le cadre d’une « recherche-action » (Avison et al., 1999). Cette recherche a été rendue possible par le contexte d’une thèse CIFRE, pour laquelle l’une de nous a été embauchée en tant que doctorante experte en conception paramétrique.

À l’origine issue des sciences sociales, la recherche-action vise à transformer la réalité pour produire de la connaissance concernant ces transformations. Dans notre cas, nous avons cherché à modifier le processus de conception d’un projet d’architecture en phase amont en utilisant de nouveaux outils numériques, afin de mieux comprendre leurs atouts et leurs limites, mais surtout pour interroger leur compatibilité avec la méthode de conception des architectes. Il est important de préciser que ces expérimentations ont porté sur des problèmes très divers, avec des équipes et des attentes variées, et que les limites présentées ci-après ne sont pas systématiques pour l’ensemble des projets. L’objectif de notre article, dans une visée d’analyse qualitative, est davantage de rendre compte de la diversité de ces limites et freins.

La doctorante donc été mise à la disposition des équipes pour intervenir lors des phases de conception, et quelques fois même de chantier, afin de mettre en œuvre ces méthodes. Les interventions ont toujours été réalisées en parallèle des projets pour ne pas gêner leur avancement, et pour pouvoir nous confronter à une grande quantité de problèmes de conception. Les objectifs de cette recherche ont été présentés et rappelés régulièrement aux équipes de projet, afin qu’elles puissent identifier les problèmes sur lesquels nous solliciter. La réalisation de ces missions a ainsi nécessité de mobiliser des compétences de développeuse Grasshopper confirmée, d’avoir été initiée à l’optimisation multicritères et d’avoir des notions de conception bioclimatique.

Il a aussi été convenu que nous serions principalement sollicitée sur des problèmes de conception d’enveloppe, car : (1) il préexiste à l’agence Architecture Studio une culture de la modélisation paramétrique pour les façades, (2) les enveloppes ont un fort impact sur la performance environnementale des bâtiments (Verbeke et Audenaert, 2018), (3) les problèmes d’enveloppes sont plus simples à modéliser que d’autres (formes urbaines, génération de plans).

L’ensemble des documents produits sur chaque projet a été conservé pour pouvoir être analysé au laboratoire. Un cahier de recherche a été tenu et alimenté mensuellement avec des descriptions des problèmes rencontrés, des méthodes testées, les résultats d’exploration et des notes sur les difficultés rencontrées, qu’elles soient techniques ou autres. Lorsque la période consacrée aux expérimentations a pris fin, nous avons utilisé les archives de l’agence pour chaque projet ayant donné lieu à une expérimentation poussée, afin de pouvoir constater les éventuelles évolutions.

Les différents types de méthodes numériques

Nous avons remarqué, dans la littérature scientifique et dans la pratique, qu’il existe plusieurs méthodes. Elles n’impliquent pas toutes l’usage de l’optimisation, ce pour quoi nous préférons parler de « méthodes numériques d’exploration ». Elles peuvent être classées de la plus traditionnelle (0) à la plus computationnelle (la plus automatisée) (7) (voir Figure 5).

0. La méthode de conception traditionnelle : Le niveau 0 correspond au mode de conception traditionnel auquel sont habitués les collaborateur·rices de l’agence, c’est-à-dire où l’architecte produit la maquette 3D et une autre personne utilise des outils de simulation pour évaluer l’objet modélisé (traditionnellement un·ingénieur·e).

1. L’exploration « manuelle » : Le niveau 1 est une méthode d’exploration qualifiée de « semi-automatique », où les itérations se font encore « manuellement ». La modélisation et la simulation sont gérées sur la même machine et par le ou la même utilisateur·rice sur une interface unique. Les variantes du projet sont facilement générées à l’aide d’un modèle paramétrique couplé à un moteur d’évaluation. Le nombre d’itérations entre la modélisation et l’évaluation peut alors être beaucoup plus élevé que dans la méthode traditionnelle. Cette technique, très accessible, permet au concepteur ou à la conceptrice d’évoluer dans l’espace de solution de manière empirique.

2. La méthode de la « géométrie informée » : Dans cette variante de l’exploration manuelle, une analyse précède la modélisation paramétrique. Cette technique se modélise en six étapes illustrées par la Figure 4. Cette méthode est rapide à mettre en œuvre et donc efficace lors des concours. Elle peut se suffire à elle-même ou être intégrée à un processus d’optimisation.

3. L’étude paramétrique : Le niveau 3 n'implique toujours pas l’utilisation d’un algorithme d’optimisation, mais l’exploration est automatisée à l’aide d’une boucle de calcul. Si l’espace de solutions est suffisamment petit, on peut analyser toutes les solutions, ou alors on peut utiliser une fonction aléatoire pour ne sélectionner qu’une partie des solutions. Cette méthode est efficace sur des problèmes simples, elle peut aussi servir à faire une analyse de sensibilité pour aider à la formulation du problème, ou à générer des bases de données afin d’entraîner des algorithmes d’intelligence artificielle pour la création de modèles de substitution.

Figure 4 : Les six étapes de la méthode de la « géométrie informée »

Source : auteur.rices

4. L’optimisation monocritère : Le niveau 4 est utilisé lorsque l’espace de solutions est très grand ou lorsque les simulations sont chronophages. Dans ce cas, il n’est pas possible d’analyser toutes les solutions dans le temps imparti. Ainsi, les algorithmes d’optimisation permettent de trouver les meilleures solutions sans avoir à toutes les analyser. Les problèmes à critère unique sont rares dans la pratique, et les problèmes formulés par les architectes sont souvent faussement monocritères.

5. L’optimisation multicritères : Le niveau 5 est nécessaire lorsque plusieurs critères doivent être évalués simultanément, ce qui est récurrent dans la pratique, où les problèmes comportent souvent deux ou trois critères. Il faut alors utiliser un algorithme d’optimisation multicritères et des outils de visualisation spécifiques pour comparer les meilleures solutions trouvées. Il n’y a pas de limite sur le nombre de critères mais, plus il y a de critères, plus la lisibilité des résultats devient complexe.

6. L’optimisation multicritères sous contraintes : Le niveau 6 est nécessaire lorsque le problème est complexe. Dans ce cas, il est nécessaire d’intégrer des contraintes au processus d’exploration à l’aide d’une méthode adaptée. Pour cela, il faut être un·e développeur·se confirmé·e, car l’intégration des contraintes nécessite fréquemment des connaissances en programmation informatique.

Figure 5 : Les différentes méthodes d’exploration

Source : auteur.rices

7. L’optimisation multicritères avec modèles de substitution : Pour le niveau 7, il faut ajouter l’usage d’algorithmes d’intelligence artificielle pour réduire les temps de calcul en créant des modèles de substitution. Ce cas n’a pas été testé à l’agence Architecture Studio.

Plus on est proche des premiers niveaux, moins on utilise de techniques génératives ; on ne peut alors parler que de « design paramétrique ». Plus on se rapproche du niveau 7, plus on utilise de techniques génératives ; on peut alors parler de « design génératif ». Aussi, il n’y a pas une mais des méthodes informatiques pour faire de l’exploration numérique, plus ou moins difficiles à mettre en œuvre et plus ou moins adaptées selon les types de problèmes rencontrés dans la pratique.

Description de l’ensemble des applications

Dans cette partie, nous faisons une description de l’ensemble des explorations réalisées, car il est important de souligner que les conclusions à venir de ce retour d’expérience dépendent beaucoup de la nature de ces applications. Même si nous sommes convaincu·es que cette tentative d’expérimenter le design génératif dans un contexte professionnel peut nous éclairer sur la difficulté de le rendre accessible, une autre expérience dans un autre contexte, une autre agence, sur un sujet autre que les enveloppes ou pour des critères d’évaluation différents pourrait aboutir à des conclusions différentes.

Bien que nous ayons pu réaliser un grand nombre d’explorations, quarante-quatre au total sur des projets différents (voir Tableau 4 et Figure 6), environ un tiers d’entre elles relevaient de la conception traditionnelle et seulement 18 % ont impliqué l’usage de l’optimisation, mais 50 % ont nécessité d’utiliser une modélisation paramétrique.

Figure 6 : Les différentes méthodes d’évaluation à gauche, les différentes méthodes d’exploration à droite

Source : auteur.rices

Tableau 4 : Liste des expérimentations

Source : auteur.rices

Les graphiques présentés dans la Figure 7 mettent en évidence la grande diversité des projets sur lesquels nous sommes intervenue. Le premier des quatre graphiques illustre la répartition des méthodes appliquées lors des expérimentations. Il montre qu’environ un tiers des sollicitations n’impliquaient que des analyses simples à partir de modélisations créées manuellement. Il a donc été difficile, notamment au début, de faire sortir nos collaborateur·rices des schémas connus. Le deuxième graphique présente la répartition des objectifs des commanditaires (chefs d’agence, chefs de projets, architectes). Dans la majorité des cas, une aide à la conception était attendue ; dans d’autres, nos interventions ont plutôt servi à produire des analyses à des fins de communication (avec les client·es) ou pour vérifier le respect de certaines contraintes.

Le troisième graphique expose la répartition des critères pris en compte. Les critères analysés étaient principalement des critères de confort (ensoleillement, qualité de vue, confort au vent, lumière naturelle, protection contre les précipitations), nécessitant des simulations relativement simples à modéliser et des temps de calcul rapides (comparés à la simulation thermique). Cependant, tous ne sont pas environnementaux (comme le coût). Le dernier graphique présente la répartition des différentes phases de projet sur lesquelles nous sommes intervenue. Il s’agissait principalement d’une assistance lors de la phase esquisse. Cependant, étant donné que la conception de l’enveloppe peut être ajustée jusqu’au moment du chantier, nous sommes également intervenue lors de ces phases.

In fine, nous avons réalisé des explorations pour la conception d’enveloppes pour tous les types de programmes (bureaux, logements, équipements), tous les types d’affaires (secteur privé, concours internationaux, partenariats publics-privés), pour des projets localisés sous tous les types de climat et à différentes phases du projet.

Figure 7 : Description quantitative de la nature des applications

Source : auteur.rices

Les limites identifiées dans la pratique

Dans cette dernière partie, nous faisons un retour d’expérience des problèmes fréquemment rencontrés lors de la mise en pratique des méthodes de conception générative et performancielle. Ces éléments peuvent, selon nous, constituer des limites à la mise en pratique du design génératif. Certaines font écho aux limites identifiées dans les revues citées dans la première partie de cette étude et d’autres, à notre connaissance, n’ont pas encore été clairement explicitées dans la littérature.

Une philosophie de conception réservée aux initiés

La pensée des architectes s’accompagne souvent de philosophies de conception que Lawson appelle « design philosophies » : « Les concepteurs ont leurs propres motivations, les raisons pour lesquelles ils veulent concevoir, un ensemble de croyances, de valeurs et d’attitudes1 » (Lawson, 2005). Celles-ci peuvent se retranscrire jusque dans leurs méthodes de travail, comme à l’agence Architecture Studio, où la philosophie, pour une conception collaborative, est incarnée dans les méthodes du « tracé rouge » et du « tracé bleu ». Le design génératif et performanciel est plus qu’une méthode, il peut être considéré comme une philosophie de conception (Touloupaki et Theodosiou, 2017), qui convient à certains architectes et pas à d’autres. Durant notre expérience, nous avons pu observer que certains architectes adhèrent à cette philosophie au point d’insister pour utiliser des algorithmes d’optimisation sur des problèmes qui ne s’y prêtent pas toujours. À l’inverse, nous avons optimisé certaines solutions proposées par des équipes dont les résultats sont restés inexploités.

Même pour les plus convaincu·es, changer brusquement de méthode de travail pour un concours est une situation inconfortable. Lors de cette phase, le projet avait bien souvent changé de direction ou une solution avait fini par être figée avant même que l’on ait pu exploiter les résultats d’une exploration numérique. Finalement, c’est lorsque les architectes y étaient contraint·es par une demande de la maîtrise d’ouvrage que nous avons été le plus sollicitée par les équipes de conception.

Cependant, avoir envie d’utiliser des méthodes de design génératif ne suffit pas. S’il a déjà été dit que ces méthodes demandent des connaissances multidisciplinaires, et qu’il est nécessaire d’avoir un·e architecte-développeur·se formé·e à ces approches pour mettre en œuvre des explorations numériques, nous recommandons en outre que les architectes et chefs de projet qui travaillent avec l’expert·e soient initiés à la démarche. Il n’est pas nécessaire que l’ensemble des collaborateur·rices (dessinateur·rices, architectes, chef de projet et chef d’agence) maîtrisent toute la chaîne d’outils indispensables à la mise en place de ces méthodes, mais nous avons observé que, lorsque le ou la commanditaire savait utiliser un script Grasshopper, voire produire un script, alors la formulation et la modélisation du problème étaient beaucoup plus fluides.

Le cas du centre d’exploitation de Rosny-sous-Bois est un bon exemple pour illustrer notre propos. Pour ce concours réalisé avec une équipe de projet plutôt adepte du design génératif, nous avons tenté d’utiliser une méthode d’optimisation multicritères pour la réhabilitation de la couverture du centre d’exploitation et de ses ateliers qui assurent la maintenance des trains et de l’infrastructure. Comme le montre la perspective visible en Figure 8, le concept de départ était de disposer de façon optimale des boîtes aux dimensions hétérogènes pouvant servir de puits de lumière, de tours à vent ou de cheminées solaires selon les besoins.

Figure 8 : Description en images de l’étude pour le centre d’exploitation de Rosny‑sous‑Bois

Sources : auteur.rices et Architecture Studio

Au fil des échanges avec le bureau d’études (BE), il est apparu que les tours à vent n’étaient pas adaptées au climat local et que le positionnement des cheminées solaires devait résulter de contraintes intérieures et non environnementales. Aussi, l’analyse du confort thermique étant trop chronophage, seul le critère de l’éclairement naturel a finalement été intégré au processus d’exploration. Enfin, définir un espace de solutions a été complexe pour ce cas. Les boîtes, en nombre variable, devaient être positionnées sur la trame structurelle sans entrer en collision. Cette contrainte difficile à intégrer demande des connaissances poussées en programmation informatique.

Cet exemple montre bien que la formulation du problème est un travail d’équipe et qu’être un·e adepte du design génératif ne suffit pas à assurer sa mise en œuvre.

Les limites organisationnelles

Nous avons identifié trois limites d’un autre ordre, que nous qualifions d’« organisationnelles ». Il s’agit des limites liées aux méthodes de travail des architectes et à l’organisation d’une agence :

(1) Des méthodes de management inadaptées au design génératif. Pour mettre en place ces méthodes, il faut des compétences qui relèvent de la spécialisation (De Boissieu, 2012), elles sont donc rares chez les chefs de projet et les directeur·rices d’agence. Ainsi, lorsqu’un·e architecte-développeur·se met en place ce type d’approche, il ou elle le fait sous leur direction.

Le chef de projet est souvent le seul à avoir une vision globale du projet, de l’ensemble de ses contraintes, du planning, des différent·es intervenant·es et des tâches à réaliser. Ainsi, il transmet à chaque collaborateur·rice exclusivement les informations qu’il juge nécessaires à la bonne exécution de la tâche qui lui est confiée. Il est accoutumé, lorsqu’il s’agit d’analyse environnementale, à transmettre uniquement une maquette BIM ou une 3D avec une liste de matériaux. Pour faire du design génératif, l’architecte-développeur·se a besoin de beaucoup plus d’informations sur le projet : quels sont les critères de performance à prendre en compte ? Certains critères sont-ils plus contraignants que d’autres ? Quels sont les paramètres géométriques et les matériaux qu’il est possible de faire varier ? Sur quel ensemble de valeurs ? Y a-t-il des contraintes rendant certaines solutions inexploitables (structurelle, économique, normative) ? Il faut souvent plusieurs allers-retours pour obtenir ces informations et formuler correctement un problème avant de lancer des calculs. Durant notre expérience, l’accès à ces informations a parfois été difficile.

Les méthodes de management des directeur·rices d’agence d’architecture sont moins conventionnelles que celles des chefs de projet. Elles s’inscrivent dans une continuité des pratiques des écoles d’architecture, où les étudiant·es produisent et les professeur·es corrigent. La métaphore utilisée par Bryan Lawson en parlant du management de l’architecte Michael Wilford semble particulièrement adaptée pour décrire la façon dont le processus de conception est souvent contrôlé en agence (Lawson, 2005). Les architectes collaborateur·rices peuvent être apparenté·es à des journalistes et le chef d’agence à un rédacteur en chef à qui ils et elles présenteraient leurs articles pour qu’il puisse suggérer des modifications. L’usage de l’optimisation multicritères est déstabilisant avec ce type de fonctionnement, car il ne s’agit pas de corriger une solution, ou bien même quelques variantes, ou encore l’ensemble des solutions optimisées. Il s’agirait soit d’exploiter les résultats de l’exploration via des outils de data visualisation pour choisir une solution, soit de remettre en question la formulation du problème, notamment la qualité de l’espace de solutions de départ. Dans les deux cas, cela nécessite des compétences spécifiques à l’exploration numérique sans lesquelles le management se trouve déstabilisé.

(2) Le rôle du dessin sous-estimé par les chercheur·ses en optimisation. Un autre sujet qui peut expliquer le gap qui existe entre théorie et pratique pour l’exploration numérique est la méconnaissance que peuvent avoir les chercheur·ses en optimisation du rôle du dessin chez les architectes. L’idée qu’utiliser l’ordinateur pour dessiner à la place de l’architecte lui permettrait de gagner du temps est partiellement faussée. Le dessin n’est pas uniquement un outil de représentation pour les architectes, mais aussi un outil de conception que Bryan Lawson appelle le « design drawing » (Lawson, 2005). C’est le dessin qui permet de faire émerger les problèmes de conception. Ainsi, les problèmes d’architecture ne peuvent être énoncés de manière exhaustive, car, toujours selon Bryan Lawson, il est impossible d’être sûr·e d’avoir fait émerger tous les problèmes que soulève un projet. Cela peut expliquer pourquoi il est aussi difficile de formuler une bonne fois pour toutes un problème de conception. Les solutions choisies au terme d’un processus d’exploration numérique sont donc fatalement appelées à être modifiées. Si l’architecte ne sait pas pourquoi cette solution est plus pertinente qu’une autre, les caractéristiques qui ont fait que l’algorithme l’a mise en avant risquent de disparaître au fil des modifications successives, comme nous avons pu l’observer sur certaines expérimentations.

Ainsi, pour être véritablement utiles aux architectes, nous recommandons que ces explorations puissent faciliter la définition du problème, que l’on puisse en déduire un apprentissage. Au cours de notre expérience, nous avons observé que les conclusions sous la forme de principes de conception étaient souvent plus appréciées que le résultat géométrique lui-même. Inversement, pour certaines applications, nous avons expérimenté ce que Philippe Boudon appelle « une intention a posteriori » (Boudon et al., 1994). Il est courant que le résultat géométrique d’une exploration plaise aux architectes et soit conservé dans un rendu, même si toute la logique générative et performancielle sous-jacente est rendue caduque à la suite de modifications d’autres éléments.

(3) La modélisation paramétrique inadaptée à la phase esquisse. Au terme de ces expérimentations, il reste complexe de dire clairement comment et quand intégrer les méthodes d’exploration numérique dans les projets d’architecture. Il n’y a pas une méthode de conception, mais des méthodes qui diffèrent selon les concepteur·rices et les projets, rendant le processus de conception difficile à définir. Cependant, il paraît possible de distinguer deux usages de l’optimisation :

1. Lors de nos expérimentations, nous avons exclusivement utilisé l’optimisation pour modifier une solution en lui appliquant des transformations à la marge plutôt que pour faire une réelle exploration du champ des possibles. Ainsi, les expérimentations qui ont eu le plus de succès ont été réalisées lors des phases d’avant‑projet.

2. Un autre usage de l’optimisation serait une utilisation en phase esquisse, avant qu’une solution ne soit choisie pour être développée. Cela implique d’être en mesure de proposer des espaces de solutions avec des formes beaucoup plus diverses, avec des variations topologiques assurément impossibles à produire avec un modèle paramétrique, sans compter que la taille de l’espace de solutions serait aussi beaucoup plus importante, imposant une explosion des temps de calcul.

En effet, les méthodes génératives à base d’algorithmes d’optimisation, avec un ensemble de solutions défini à l’aide d’un modèle paramétrique, n’ont pas, contrairement à d’autres techniques génératives (Caetano et al., 2020), la faculté d’émergence, c’est-à-dire la capacité à générer des solutions inattendues (Harding et Shepherd, 2017). Les techniques génératives qui ont cette faculté nécessitent des connaissances en programmation informatique pour être implémentés. Elles sont difficiles à contrôler, donnant des solutions parfois tellement inattendues qu’elles ne permettent pas de facilement proposer un ensemble de solutions qui respecterait un même « geste architectural », comme peut le faire un modèle paramétrique.

L’exemple du concours pour la réhabilitation d’une caserne de pompier en immeuble de bureaux à Nancy permet d’illustrer notre propos sur les limites organisationnelles. L’enjeu de ce projet est la conservation en l’état d’une façade classée qui laisse peu entrer la lumière naturelle, rendant le respect des exigences en matière d’éclairement naturel dans des espaces de travail très difficile. Nous sommes donc intervenue au début du projet lorsqu’aucune solution n’avait encore été figée. Au départ, l’équipe d’architectes souhaitait comparer la qualité de l’éclairement de différentes variantes en effectuant des évaluations du facteur de lumière du jour (FLJ) (voir Figure 7) selon les exigences du programme basé sur la norme HQE (haute qualité environnementale), ce qui, compte tenu de la taille du bâtiment, demande plus de 24 heures de calcul par variante, rendant l’usage de l’optimisation complètement impraticable.

Figure 9 : Analyse du FLJ pour deux variantes

Source : auteur.rices

Au cours de l’étude, voyant que les objectifs seraient difficiles à atteindre, les architectes ont démultiplié le nombre de paramètres et dispositifs à interroger pour trouver une solution adéquate. Deux échelles étaient donc étudiées pour chercher à optimiser l’accès à la lumière naturelle : l’échelle globale du bâtiment, où les architectes cherchaient quel dispositif (patios, toiture vitrée…) permettrait d’éclairer un maximum de locaux, et l’échelle du détail, où l’on étudiait comment augmenter la surface du local avec un FLJ suffisant.

Abstraction faite des temps de calcul, pour lesquels même l’entraînement d’algorithmes d’intelligence artificielle pour créer des modèles de substitution ne semblait pas réaliste, l’usage de l’optimisation restait complexe pour ce problème à cette phase de conception. Pour les deux échelles, la définition d’un modèle paramétrique s’est révélée très difficile. D’abord parce que le management à la tâche, où les paramètres à interroger changent tous les jours, ne s’y prête pas, ensuite parce que les solutions que nous devions comparer étaient souvent très éloignées typologiquement les unes des autres. Avec un modèle paramétrique, nous pouvons interroger la dimension et l’emplacement des patios, ou interroger la quantité de fenêtres en façade, ou la surface vitrée en toiture, mais c’est un exercice différent de comparer les trois. Il en va de même pour le détail des fenêtres. Dans la solution retenue par les architectes, finalement obtenue avec une méthode de conception traditionnelle, des parois sont disposées sur l’axe des fenêtres ; ainsi, certaines éclairent deux bureaux à la fois. Pour favoriser la diffusion des rayons lumineux, une partie de la paroi (celle proche de la fenêtre) est vitrée. Une telle solution ne peut être inventée par un algorithme d’optimisation, où les solutions sont prédéfinies par le modèle paramétrique. Ce dernier permettent de comparer des dispositifs architecturaux, d’optimiser un dispositif architectural, mais pas d’en imaginer un.

Des limites techniques

Pour finir, cette expérience nous aura permis de soulever deux limites techniques qui freinent la mise en pratique de ces méthodes de conception innovantes. Souvent évoqués dans la littérature scientifique, il y a d’abord les temps de calcul, qui réduisent la fluidité de la méthode, mais aussi un autre sujet rarement mentionné : la difficulté d’intégrer des contraintes au processus d’optimisation.

Au début, les applications ne nécessitaient pas l’usage de simulations complexes, les temps de calcul n’ont jamais été rédhibitoires, mais bien souvent nous avons restreint la taille de l’espace de solutions pour pouvoir respecter les plannings. Les temps de calcul selon les projets varient d’une nuit à trois jours. Effectués les week-ends, ils ne freinaient pas l’avancement des projets. Avec le temps, nous avons été sollicitée sur des sujets plus complexes (échelle urbaine, confort au vent), pour lesquels l’exploration d’une quantité importante de solutions est difficilement concevable sans l’usage d’algorithmes d’intelligence artificielle. Avec ces algorithmes, les temps de calcul sont considérablement réduits, même s’il restera toujours un temps de calcul incompressible pour générer des bases de données pour leur entraînement. Cela oblige à une certaine organisation, mais implique surtout des connaissances en apprentissage artificiel (ou machine learning en anglais, soit la capacité des systèmes informatiques à apprendre et à améliorer leurs performances sur des tâches spécifiques à partir de grandes quantités de données) à acquérir pour l’architecte-développeur·se, qui s’ajoutent à une liste déjà longue.

Finalement, la limite technique la plus rédhibitoire est, selon nous, la gestion des contraintes. Ces dernières sont omniprésentes et peuvent être de natures très diverses (structurelles, réglementaires, environnementales, fonctionnelles, esthétiques ou pour éviter des aberrations géométriques). Si seulement quelques solutions de l’espace préalablement défini ne respectent pas les contraintes, cela reste facile à gérer, mais si la plupart des solutions sont caduques, alors l’algorithme ne peut être démarré en l’état. Au cours de ces expérimentations, nous avons régulièrement été confrontée à ce problème. Ainsi, nous avons dû soit reformuler les problèmes en réduisant drastiquement leur complexité, et au passage la taille de l’espace de solutions, soit abandonner le projet faute d’avoir trouvé une alternative acceptable.

Pour illustrer notre propos sur les limites techniques, nous nous appuierons sur l’exemple du concours en partenariat public/privé pour la cité internationale de Marseille. Nous avons été sollicités sur ce concours pour optimiser le système de protection solaire des façades, à la suite d’une demande de la maîtrise d’ouvrage. Nous avons donc cherché à créer un modèle pour ce projet qui a entraîné de nombreux questionnements.

Il s’agissait d’optimiser la disposition de lames horizontales pour trouver un compromis entre trois critères pour les salles de classe : la réduction des apports solaires en été, l’accessibilité à la lumière naturelle et la visibilité vers l’extérieur. L’ensemble des lames devait être réparti de façon homogène et créer un effet aléatoire, comme sur la perspective illustrée en Figure 10. L’objectif était donc de faire une optimisation à la marge du système d’enveloppe sans remettre en question l’architecture générale de la façade, en essayant si possible d’optimiser son coût.

Figure 10 : Description du problème pour la cité scolaire internationale de Marseille

Source : auteur.rices et Architecture Studio

L’esquisse dessinée par l’équipe d’architectes étant recouverte de plusieurs centaines de lames, la combinatoire apparaît comme énorme. Deux approches sont alors possibles :

1. La première consiste à faire une optimisation par orientation et par bâtiment, soit huit explorations. Seulement, la combinatoire reste grande et des contraintes doivent être intégrées au modèle (collisions, lévitation et répartition homogène des lames).

2. La seconde consiste à faire un modèle à l’échelle de la salle de classe et à réaliser autant d’explorations qu’il y a de configurations de salles de classe dans l’école. Cela permettrait de restreindre le modèle à quelques paramètres sur un nombre raisonnable de lames. Les architectes pourraient ensuite reconstituer le puzzle de chaque façade à partir des résultats des différentes configurations. Pour que deux salles de classe soient considérées comme similaires, elles doivent avoir la même dimension, orientation et quantité d’apports solaires. Cela reviendrait à relancer plusieurs dizaines d’explorations.

Finalement, il apparaît que traiter le problème façade par façade est moins chronophage mais, après plusieurs tentatives, nous n’avons pas réussi à trouver un modèle paramétrique qui permette d’intégrer toutes les contraintes précédemment citées. Cette tentative d’expérimentation a finalement dû être abandonnée, avant d’être réexploitée pour une recherche sur les méthodes d’intégration des contraintes en optimisation (Duclos-Prévet, 2024).

Conclusion

Au terme de cette étude comprenant quarante-quatre applications pratiques de méthodes de design génératif et performanciel sur des projets réels, nous pouvons affirmer qu’il n’existe pas une mais des méthodes de design génératif, nécessitant de nombreuses compétences techniques pour être mises en œuvre. Mais il apparaît surtout que les limites qui peuvent expliquer la sous-utilisation de ces méthodes dans la pratique professionnelle décrites dans la littérature scientifique diffèrent quelque peu de celles identifiées dans la pratique, et/ou mériteraient d’être plus expliquées.

Nous avons relevé que les limites organisationnelles sont trop rarement soulignées par les chercheur·ses en optimisation. À l’avenir, il faudrait mieux prendre en compte le fait que les problèmes de conception architecturale sont sans cesse à reformuler, que les solutions optimisées par les processus d’exploration numérique sont fatalement destinées à être modifiées, que les architectes doivent pouvoir apprendre des méthodes d’exploration et comprendre quelles caractéristiques rendent une solution plus performante qu’une autre.

Ensuite, il est nécessaire de former des architectes pour démocratiser l’usage de ce type d’outils innovants. Bien entendu, la formation de jeunes architectes-développeur·ses maîtrisant la programmation visuelle est essentielle, mais aussi la formation des architectes plus expérimenté·es, notamment à la formulation de problème d’optimisation et aux outils de data visualisation.

Enfin, si les temps de calcul peuvent être longs, ils ne se sont pas rédhibitoires pour la mise en œuvre de ces approches, notamment pour les critères de confort, y compris pendant les phases esquisse, même si dans certains cas nous recommandons plutôt l’usage de la méthode dite de la « géométrie informée ». La limite technique la plus bloquante, selon notre expérience, est l’intégration des contraintes dans le processus d’optimisation. Les problèmes rencontrés dans la pratique sont souvent multicritères et doivent intégrer de multiples contraintes. Évaluer des solutions sans intérêt pour les architectes représente une perte de temps, sans compter que, dans certains cas, l’algorithme n’est pas en mesure de générer une seule solution faisable.

À l’avenir, il serait intéressant de tester ces méthodes sur des cas pratiques en utilisant des algorithmes d’intelligence artificielle et des méthodes d’intégration des contraintes adaptées aux problèmes de conception des architectes (Duclos-Prévet et al., 2022).