Navigation – Plan du site

AccueilPré-publicationArticlesRétroaction dans les processus nu...

Rétroaction dans les processus numériques de conception

Feedback in digital design processes
Sébastien Bourbonnais

Résumés

Les outils informatiques employés par les architectes ont connu des perfectionnements importants au cours des 60 dernières années et ont évolué selon un schéma complexe englobant de nombreuses préoccupations internes et externes aux milieux de l’architecture. En se concentrant sur la capacité de ces différents outils à retourner de l’information aux concepteurs, sous la forme de rétroaction, il sera ici question d’observer les différentes tendances historiques qui ont orienté ces perfectionnements ainsi que de repérer les implications qu’ont eu ces technologies sur les processus de conception architecturale.

Cette étude historique souligne que l’arrivée des technologies numériques a introduit de nombreux questionnements sur la constitution même des processus de conception, ainsi que de la place à accorder à ces outils. L’objectif est de montrer que les savoirs intégrés dans les différents programmes informatiques auront entraîné une véritable refonte des savoirs de conception, relevant en quelques sortes de la mise en place d’une épistémologie, engendré par les processus numériques de conception.

Haut de page

Texte intégral

Introduction

1Chercher à comprendre ce qu’ont entraîné les technologies numériques sur les manières de penser le projet d’architecture, et plus précisément la conception architecturale, impliquent de s’intéresser aux différents programmes informatiques qui ont été employés, voire inventés, ainsi que de chercher à comprendre les questionnements qui ont été soulevés lors de leurs apparitions. Il semble d’emblée possible d’établir une corrélation étroite entre les besoins ou vouloirs des architectes et les potentialités pressenties dans certains programmes, et même plus largement, d’y observer des correspondances entre les enjeux soulevés par le développement informatique et la façon de définir les processus de conception architecturale.

2En se concentrant sur la capacité des différents outils à retourner de l’information aux concepteurs, il sera ici question d’observer les différentes tendances historiques qui ont orienté les perfectionnements techniques ainsi que de repérer les implications qu’ont eu ces technologies sur ces processus. Les architectes s’aperçurent relativement tôt que l’ordinateur ne serait pas un simple outil qui permettrait d’informatiser, voire d’automatiser, la conception, mais soulèvera une série de questionnements sur la définition même de l’activité de conception : quelle place accorder à la machine ? Quel type d’information, de savoir-faire, l’ordinateur a-t-il la tâche d’intégrer et de retourner au concepteur ? Sous quelles formes ? Avec quels buts ?

3Après une présentation succincte du concept de rétroaction dans le projet Cybernétique de Norbert Wiener (Wiener, 2014 [1948]), dans son intention de penser la relation entre le vivant et la machine, nous nous intéresseront aux débuts de l’informatique en architecture, afin de démontrer comment la question de la conception numérique (CAO) deviendra l’un des enjeux majeurs des débats au début des années 1970. Il s’agira ensuite de montrer la bifurcation ainsi que la synthèse qui se sont opérées au milieu des année 1980, où l’ordinateur a semblé obtenir une place plus ou moins clairement délimitée. Par la suite, sans entrer dans les détails de l’épisode des années 90, avec les explorations formelles produites avec des logiciels d’animation et de simulation, il s’agira de montrer qu’il s’est à nouveau opéré un déplacement, où l’ordinateur s’est vu attribuer des tâches jusqu’alors réservé à l’architecte. L’ordinateur sera impliqué dans une recherche de la nouveauté, de l’inconnu, de telles manières que cette part créative, inexplicable, deviendra centrale dans les discussions autour de la conception. L’attention ne portera plus sur le besoin de formuler des idées parfois confuses ou imprécises, mais de chercher à faire varier certains paramètres de telle sorte à obtenir des résultats inattendus, mais tout de même suffisamment cohérents pour répondre aux intentions premières. Il s’est ensuite opéré un second déplacement au début des années 2000, où les réflexions autours des technologies numériques se sont imbriquées à des préoccupations contemporaines plus larges, comme celles de l’écologie, de la construction ou des nouvelles matérialités. Il va s’en dire que l’expérimentation des machines CNC (computer numerical control) de fabrication par certains architectes, ont participé au retour des questions autour de la matérialité, via le prisme des technologies numériques. L’emploi de ces machines, mais également le recours à d’autres technologies, comme celles par exemple du BIM (building information modeling) ont fortement contribué à la mise en place de processus de codification des connaissances impliquées dans les processus de conception-fabrication : à la fois connaissances quantitatives et qualitatives, procédant ainsi à une rétroaction négative (de correction) et une rétroaction positive (d’amplification).

4Cette étude historique cherche à montrer que l’évolution du rôle joué par les différents programmes informatiques, passant de l’assistant qui réalise une tâche que lui assigne l’architecte, jusqu’aux processus de morphogénèses auto-génératifs définis par différents algorithmes, laisse transparaître une intrication complexe dans la façon d’organiser et de penser les processus de conception architecturale. Il en résulterait un rapport tout à fait singulier avec les connaissances en jeu dans les processus de conception, s’instituant en quelque sorte une épistémologie spécifique, qui ne renie pas les méthodes traditionnelles, mais reconfigurent l’ensemble des méthodes selon de nouvelles dispositions.

Le place de la rétroaction dans les processus machiniques automatiques

5La place accordée au concept de rétroaction [feedback] occupe une partie constitutive du projet cybernétique développé par Wiener, comme le relève Ronan Le Roux dans la présentation de l’édition française de Cybernétique (2014). Ce concept possède une valeur méthodologique dans ce projet et occupe une place précise comme réponse à des comportements actifs et finalisés. Il faut, en effet, un objectif relativement clair pour qu’un processus de rétroaction, positif ou négatif, soit le moindrement pertinent. L’intérêt de Wiener pour ce processus apparaît semble-t-il lors de « la conception d’un prototype d’aide à la conduite de tir antiaérien, [ce qui] a suggéré à Wiener l’utilisation d’analogie fondamentale entre servomécanismes et processus de coordination psychologique » (Ibid.). Sans entrer dans les détails de cette machine, comme le AA Predicator utilisé à la fin de la deuxième Guerre, il est intéressant d’observer quelle information les filtres de cette machine devait retourner à l’utilisateur. Dans les faits, ces filtres parvenaient à bien suivre le mouvement de l’avion lorsque celui-ci était continu, ou même lorsqu’il était en zig zag, mais ils étaient inefficaces lorsqu’il passait de l’un à l’autre, rapidement. C’est sur ce principe d’incertitude que reposait la difficulté de « prédire » la trajectoire de l’avion, et où le recours à la machine à calculer devenait nécessaire.

6Dans le chapitre rétroaction et oscillation de Cybernétique, la rétroaction est introduite par l’exemple de patients atteints de ce qu’on appelle l’ataxie. L’un est incapable de porter un verre d’eau à ses lèvres, sans le renverser ; l’autre marche d’une allure bizarre « il commence chaque pas par un coup de pied » (Wiener, 2014 [1948]). Pour ces patients, le processus de rétroaction est trop fort et par conséquent entraîne des mouvements de plus en plus brusques de rééquilibrage. L’enjeu pour Wiener était de souligner l’importance de faire combiner énergie et information. Plus profondément encore, l’intérêt de Wiener pour ce processus de rétroaction était principalement lié à son rôle essentiel « à la constitution de la vie, [...] ce qu’on appelle l’homéostasie » (Ibid.). En d’autres termes, c’est grâce aux multiples processus de rétroaction que la vie se maintient ; qu’elle garde son équilibre interne et dynamique.

7Dans le deuxième Cybernétique, (Wiener, 2014 [1954]), le concept de rétroaction ne disparaîtra pas, mais évoluera vers la question plus large de la régulation de l’information dans les communications en général et demeurera malgré tout essentiel pour « l’avènement du nouvel âge de l’automatisme » (Ibid.). Wiener le rappelle, la rétroaction ce : « n’est pas autre chose que la possibilité de définir la conduite future par les actions passées » (Ibid.). Que ce soit par réflexe chez le vivant, conditionné, ou encore sous forme d’apprentissage, la rétroaction nécessite une information incorporée, récupérée, apprise, qui réagit par rapport à une action, dans un but précis. Comme mentionné plus haut, la rétroaction trouve sa pertinence lorsque la communication est compliquée, complexe, difficile : lorsqu’il y a beaucoup d’information à gérer, car « plus le message est probable, moins il fournit d’information » (Ibid.). C’est le message inattendu qui mérite l’attention. L’information évidente va de soi et ne mérite pas qu’on s’y arrête.

8Ce détour introductif à la rétroaction chez Wiener permet de mettre en avant deux points qui nous semblent importants afin de passer en revue l’évolution des préoccupations des architectes autour de l’informatique : d’une part, de chercher à répondre à des problèmes de plus en plus complexes ; et d’autre part d’assurer le maintien d’un équilibre entre les savoirs intégrés dans le programme et les savoirs intuitifs de l’architectes, en d’autres termes, de permettre une flexibilité pour laquelle le programme puisse apporter de l’information à la fois utile, pertinente et surtout, compréhensible pour l’utilisateur.

Manières de communiquer avec l’ordinateur

9La problématique de la communication homme-machine a mis un certain temps avant d’apparaître clairement. À l’époque où Wiener élabore ses concepts, il était difficile de parler de communication, même métaphoriquement. Le langage FORTRAN a certainement été l’une des premières étapes significatives comme « le premier langage de communication avec la machine qui ne soit pas un langage machine et qui se veut plus proche du langage naturel » (Cadoz, 1994). S’il est possible de communiquer avec la machine à partir de l’énonciation de règles écrites, ce qui entraînera comme nous le verrons de nouvelles manières de penser les processus de conception, certaines interfaces seront créées afin de permettre la communication graphique, comme le programme Sktechpad, développé en 1963 par Ivan Sutherland. « Le système Sketchpad permet à un homme et à un ordinateur de communiquer rapidement ensemble grâce aux traits du dessin » (Sutherland, 1963). Considéré comme la première GUI (Graphical User Interface), Sketchpad proposait ni plus ni moins un programme de dessin par ordinateur, capable de représenter et de manipuler des formes grâce à un système de communication graphique basé sur la reconnaissance de formes. À l’aide d’un stylo-lumineux [light pen], d’un écran cathodique, d’une boîte de commandes et d’imposants interrupteurs à bascules, il devenait possible de tracer, de modifier, de déplacer, d’agrandir, etc., les traits lumineux sur l’écran. Le programme définissait une entité « trait » qu’il manipulait selon une large palette d’actions, pour l’époque. Si le stylo-lumineux existait et était utilisé dans le secteur militaire, le programme Sketchpad a obtenu un succès auprès de l’avant-garde en raison de sa simplicité d’utilisation et de son indépendance par rapport à tout secteur.

Figure 1. Quelques exemples sur Sketchpad, Ivan Sutherland, MIT, 1963.

10Des personnalités autour de l’informatique comme J.C.R. Licklider, Alan Kay ou encore Ted Nelson seront rapidement impressionnées par ce programme, car « cela a permis d’envisager une nouvelle façon de travailler et de voir » (Nelson, 1977). En effet, Sketchpad permettait des opérations jusqu’alors impossibles sur support physique statique, comme un jeu d’agrandissements, de réductions, ou même la possibilité que l’objet dessiné puisse disparaître de l’écran, tout en restant présent dans la mémoire de l’ordinateur. Les possibilités demeuraient malgré tout limitées et Sketchpad était relativement difficile à manier. Quoiqu’il en soi, Sketchpad fut certainement l’un des premiers outils d’aide au dessin (DAO) a connaître un certain succès. Sketchpad pouvait corriger votre dessin de manière automatique, selon certaines règles programmées : traits parallèles, perpendiculaires, relier des coins, etc. Ce sera d’ailleurs le reproche que lui fera Nicholas Negroponte, figure importante qui a été entre autres le fondateur du The Architecture Machine Group en 1967 au MIT et du Media Lab en 1985.

11Le principal reproche qu’adresse Negroponte sera sur le terme Sketch de Sketchpad, car pour lui, le Sketch – l’esquisse ou le croquis – relève de l’intuition, de l’énergie créatrice, et de la pensée syncrétique. Sketchpad, selon Negroponte, est tout sauf intuitif. Il ne favorise pas l’élan créateur, mais le corrige. Pour lui, l’intérêt principal des machines de l’époque n’était pas que celles-ci reproduisent seulement une action - le dessin - mais qu’elles parviennent à penser comme un architecte-concepteur. Le problème : « c’est en partie parce que les machines sont communément pensées comme uniquement capable d’agir et non de comprendre » (Negroponte, Groisser, 1970). Pour Negroponte, l’une des manières de faire comprendre l’ordinateur était de placer la sémantique (le sens) devant la syntaxe (l’action), et non l’inverse. Cette différenciation aura inévitablement d’importantes répercussions quant à l’effort à produire sur certains points précis, mais également quant à la place à accorder à ces machines, nous y reviendrons.

12Negroponte développera cette idée, entre autres, dans deux projets : le programme URBAN 5 (1968) ainsi que l’expérience SEEK (1969). L’URBAN 5 était un programme conçu pour aider l’architecte à ne rien oublier dans la conception complexe d’un bout de ville. « Le principe de cette recherche est la création, grâce à l’ordinateur, d’un partenaire omniscient et omniprésent capable de refléter critiquement les décisions et les critères de l’utilisateur » (Courtieux, 1971). En formulant et formalisant des critères de design - par exemple, chaque pièce doit contenir au minimum une ouverture, une maison familiale doit être à moins de 500 m d’un parc, etc. - la machine agit comme un aide-mémoire infaillible et devient par le fait même capable d’orienter les décisions du concepteur. Grâce aux « connaissances » intégrées, il est possible pour le programme d’avertir et de signaler les conflits ou les incompatibilités de la modélisation réalisée par l’architecte avec les critères de conception préalablement formulés. Negroponte a soulevé néanmoins deux points sur lesquels URBAN 5 lui semblait insuffisant. D’une part, il ne pouvait prévenir le concepteur de critères qu’il n’avait pas lui-même décrits, et dans ce sens, il n’y avait pas réellement de compréhension ; d’autre part, le programme était plutôt destiné aux architectes et non aux résidents, non-spécialiste. Cette préoccupation est demeurée centrale dans le travail de Negroponte où, déjà en 1969, il souhaitait grâce à la machine supprimer le middleman, l’architecte, avec l’idée qu’un système réellement intelligent aurait la capacité de communiquer directement avec ses usagers, sans intermédiaire, apportant lui-même les connaissances nécessaires.

Figure 2. Urban 5, Architecture Machine Group (Nicholas Negroponte), MIT, 1968.

13SEEK a cherché en quelque sorte à pallier ces lacunes. SEEK était une maquette interactive qui, piloté par un système d’apprentissage, représentait une ville à échelle réduite. Composé de cubes de 5 x 5 cm, agencés selon une composition initiale, il a été question d’introduire une population de gerbilles qui, dans leurs mouvements, déplaçaient les cubes de manière plus ou moins aléatoire. Le rôle de la machine était d’abord de repérer le déplacement des cubes et ensuite de les replacer à leur position initiale. Si, en revanche, un cube était déplacé plusieurs fois, alors la machine considérait le nouvel emplacement comme plus pertinent, venant ainsi modifier la composition d’ensemble. Cette maquette agissait à titre de prototype afin de proposer, à courts termes, une architecture « réactive » aux réels besoins de ses usagés (Negroponte, 1973). Les gerbilles, dans le cas présent, généraient de la variation aléatoire et n’agissaient pas véritablement en tant qu’acteur appréciant et modifiant « consciemment » son environnement selon ses besoins, goûts et intérêts.

14En comparant ces deux projets avec le programme Sketchpad, on remarque d’emblée le peu d’intérêt que Negroponte porte au dessin, et par conséquent, pour la forme même que prendra l’édifice. Son objectif était plutôt de communiquer avec la machine afin d’obtenir des schémas de penser satisfaisants pour la conception de la ville, la forme n’étant plus une priorité. Dans ce sens, les cubes sont plutôt à considérer comme un schéma de formes possibles. Ce point n’est pas secondaire, au contraire, et marquera profondément les manières de penser la conception architecturale et surtout quant à la place à accorder aux dessins, à la figuration. Ce sera d’ailleurs la thèse défendue par Molly Wright Steenson dans Architectural Intelligence (2017) : Negroponte, comme Christopher Alexander et Cedric Price, sera principalement intéressé à trouver et/ou définir l’information pertinente pour rendre opératoire les machines, et non pas à manipuler une forme pour la modifier afin qu’elle s’accorde à ses intentions. Dans cette logique, que devient l’objet de la conception ? Est-ce le plan de l’édifice qui doit être représenté ou un schéma abstrait qui répond à certains critères, ouvert à différentes concrétisations ?

15Malgré les positions opposées défendues par ces deux auteurs, mais également par plusieurs autres, il est indéniable qu’ils ont participé, chacun à leur façon, à mettre en place les questionnements qui viendront englober la conception architecturale et l’informatique car, jusqu’alors, ces deux sujets étaient plutôt traités séparément. En effet, à partir des années 1960 ont été réalisés de nombreux travaux sur la conception, en général, et les ordinateurs étaient utilisés en architecture à d’autres fins, pour : « l’élaboration technique, l’évaluation des coûts ou l’organisation et de la planification des chantiers » (Lichnerowicz, 1971). C’est seulement au tournant des années 1970 que la réunion s’établit franchement entre ces deux thématiques et que les architectes s’intéresseront simultanément à la conception architecturale et à l’informatique.

L’introduction de l’ordinateur dans la conception architecturale

16Au début des années 1970, malgré la taille relativement imposante des ordinateurs, environ 2m2 au sol, l’ordinateur s’introduit, timidement, dans les milieux de la conception architecturale : professionnel, pédagogique et celui de la recherche. Différents événements et publications marqueront cet intérêt comme par exemple, en France, le dossier spécial « Informatique et architecture » de la revue Techniques et Architecture de 1971 ou encore les Journées Informatique et Conception en Architecture, organisées par l’IRIA, la même année. Comme évoqué plus haut, cet intérêt pour la conception était déjà présent, voire constituait un objet d’étude en soi, comme le montre les travaux d’Herbert A. Simon (Simon, 2004 [1969]) ou encore ceux de Christopher Alexander (Alexander, 1971[1964]). Il n’est pas anodin de rappeler qu’Alexander, avec Marvin Manheim, travaillait à la même époque à l’amélioration du HIDECS 2 : programme s’employant à rendre concrètes et opérationnelles ses théorisations sur la conception (voir infra.). Ces deux auteurs auront d’ailleurs une influence importante dans l’orientation des débats tenus sur l’informatique en architecture.

17S’il est vrai que les positions idéologiques de type – pour ou contre – l’informatique, étaient fortement ancrées dans les milieux de l’architecture, l’attitude des architectes expérimentant directement avec l’ordinateur restait tout de même très prudente par rapport aux attentes, ou du moins, par rapport aux efforts à fournir afin que l’informatique devienne réellement utile et performant. Des retours d’expériences, comme L’architecte face à l’informatique, montrait cette position ambiguë. « L’ordinateur est bête. [...] Alors en quoi peut-il nous être utile ? D’abord, et cela est à mes yeux le plus important, nous apprendre à penser en terme d’analyse » (Allée, 1971). Il est fort possible que cette approche analytique trouvait ses bases sur le « besoin de rationalité » défendu par Christopher Alexander dans De la synthèse de la forme, publié en 1964, et traduit justement en 1971. Il y aura d’ailleurs un court texte expliquant la « méthode » d’Alexander dans ce numéro spécial. Cette nouvelle manière d’aborder la conception sera d’ailleurs assez largement répandue et défendue par les architectes fortement impliqués dans la recherche et le développement des outils informatiques, comme Paul Quintrand, fondateur du GAMSAU. « La vérité est que l’utilisation de l’ordinateur peut nous aider à la résolution des problèmes, mais qu'elle ne peut être dissociée de certaines démarches intellectuelles qui définissent une nouvelle approche des problèmes de l’environnement » (Quintrand, 1971). On peut entrevoir dans ce commentaire qu’à cette époque les problèmes pour lesquels l’ordinateur pouvait donner une réponse n’étaient pas entièrement satisfaisants. En fait, la principale difficulté était qu’ils ne savaient pas tellement sur quels problèmes faire plancher l’ordinateur pour que son apport devienne significatif. Il apparaissait d’ailleurs que la conception architecturale ne pouvait être réduit à une simple résolution de problèmes, même complexes, comme le laissait entendre H. Simon. C’est également à ce moment que les architectes ont pris pleinement conscience « que le problème n’était pas simplement d’automatiser un processus existant mais la définition plus précise et plus objective de ce processus et par là même, parfois, sa mise en cause » (Maroy, 1971).

18C’est à cette époque, et entre autres lors de ces événements que différents questionnements, originaux, ont émergé sur la spécificité de la conception architecturale, comme celui de chercher à définir un « espace architectural » qui ne serait pas assimilable à celui du bâtiment.

19L’émergence de tels concepts servait notamment à contrecarrer, ou du moins à nuancer la proposition systémique d’Alexander qui a consisté à représenter les problèmes de conception selon une hiérarchisation arborescente qui décomposait, en ensembles et sous-ensembles, le « programme » de conception. La particularité de cette méthode reposait sur un système de notation 0-1, pour les différentes fonctions décomposées. Dans la lignée de Simon, il n’était pas question de trouver La solution optimale, mais une solution satisfaisante et adaptée. Il faut dire que pour Alexander : « une bonne adaptation [est] l’absence de certaines qualités négatives » (Alexander, 1971[1964]). Pour lui, il était plus simple de s’accorder, avec certitude, sur une situation désagréable que sur une situation agréable, réussie. D’ailleurs, quand ça va, on ne le remarque pas ! Cette méthode établie sur des arborescences a cependant été remise en cause par Alexander lui-même (De Paoli, 1998) dans Pattern Language où était réprimé cette idée de réduire le projet d’architecture à une formalisation mathématique, mais également, il proposait de retourner à son idée d’adaptation réciproque entre forme et contexte.

Figure 3. Simulation 0 du site de Luminy avec LOKAT, simulation réalisée par le GAMSAU, 1971.

20Pendant la période des années 1970 est apparue une série d’explorations : comme celles des allocations spatiales, des grammaires de formes, ou à partir de programmes d’aide à la conception comme DOMINO, ou LOKAT qui ont, chacun à leur manière, tenté de proposer une manière de faire adéquate afin d’intégrer les processus computationnels dans l’activité de conception. Cette production informatique, principalement centrée sur la conception de plans, ainsi que les réflexions émises autour sont restées néanmoins à l’état exploratoires, sans néanmoins trouver leur réelle opérabilité, à grande échelle. C’est seulement au milieu des années 80 que des résultats plus ou moins concluant sont apparus, proposant une sorte de stabilisation et de synthèse des considérations autour de ces questions. Il est en revanche compliqué de trouver une simple explication à ce basculement, comme le constatait Paul Quintrand.

Il ne faut pas voir dans les changements d’attitudes qui auront marqué les années 80 seulement l’apport des techniques informatiques, micro-informatique, techniques graphiques, intelligence artificielle, techniques de l’image. Certes, elles ont été nécessaire, mais elles se sont positivement conjuguées avec les transformations profondes que subit le milieu de la production architecturale depuis une décade – modification du marché en crise, exigences économiques, exigences de qualité, renouveau du contexte de la production architecturale mondiale moteur de nouveaux questionnements. (Quintrand, 1986a)

21L’ordinateur se retrouve ainsi sur le devant de la scène dans un contexte particulier qui demande une certaine efficacité. C’est entre autres pour cette raison qu'est apparue une scission franche entre ce qui était informatisable et où, par conséquent, il était possible de le déléguer à une machine ; et ce qu’il ne l’était pas et donc, restait réservé à l’architecte. À cette époque, il se produira également un retour à l’approche figurative, de la représentation, grâce aux avancées techniques soulevées par Quintrand, mais également par la nécessité de communication avec les différents intervenants du projet.

Conception et exécution

22Plusieurs débats éclateront dont celui qui existait déjà, mais qui n’avait pas été formulé aussi clairement quant à la place à accorder à l’ordinateur : quel serait son champ d’action ou d’application ? L’architecte Anton Harfmann posera cette question par rapport au degré d’implication que l’ordinateur pourrait ou devrait être avoir. « La créativité peut-elle ou doit-elle être externalisée ? Peut-elle ou devrait-elle être calculé [computed] » (Harfmann, 1987) ? Par cette question, Harfmann soulève la difficulté d’externaliser le processus créatif et de le rendre calculable, principalement parce qu’il est difficile d’externaliser les connaissances intuitives, changeantes, voire contradictoires, qui guident les concepteurs dans leur processus de création. Si Harfmann reste prudent quant à la possibilité de rendre calculable les processus de création, d’autres architectes, environ à la même période, proposaient une division plus franche où la conception serait divisée en deux : il existerait des tâches propices à être léguées à la machine, tandis que d’autres, demeuraient réservées à l’architecte. Cette scission a permis d’une part d’éviter de trop s’attarder sur la question qu’est-ce que la conception ? et d’autre part, à déplacer le problème sur une zone relativement précise du champ d’action à accorder à l’ordinateur.

23L’architecte-informaticien Christos I. Yessios, qui créera le logiciel Form*Z en 1991, ainsi que Paul Quintrand proposeront une distinction qui, malgré quelques similarités, repose sur des principes différents. Quintrand distinguera conception et instrumentalisation dans l’activité de projettation, cette dernière se trouvant insérée dans la séquence du projet entre l’intuition et la réalisation. L’intuition serait liée aux contextes où s’insère le bâtiment, aux programmes architecturaux, tandis que la réalisation « concerne l’architecte dans ses missions de coordination et de contrôle » (Quintrand et all., 1985). Même si ces deux phases du projet peuvent être informatisées, Quintrand et son équipe, s’intéressent plutôt à la projettation, qu’il divise en deux. La conception comprend la phase des premières esquisses, floues, et par conséquent difficile à rendre calculable en raison de « la nature de l’information à traiter [...] dont l’expression est rarement quantitative, faiblement textuelle, majoritairement graphique [et qui] pose des problèmes de représentation de l’objet architectural » (Ibid.). Si l’on comprend bien Quintrand, la partie « essentielle » ne pourrait être atteinte par l’informatique et resterait sous l’autorité de l’architecte. L’instrumentalisation quant à elle, est possible lorsque le bâtiment prend « une forme concrète » et que l’architecte peut contrôler, donner des dimensions et fournir l’information nécessaire à sa réalisation.

24Pour Yessios, la distinction qu’il propose entre conceptualisation et exécution comporte également cette idée où la conceptualisation aurait à faire avec des problèmes floues, encore mal posés et non reconnus. Par contre, pour Yessios, l’exécution participe à cette définition et reconnaissance des problèmes : la modélisation tiendrait ainsi un rôle similaire à celui joué par l’esquisse-croquis (voir infra). Cette division ne reposerait pas tellement sur une démarcation temporelle dans la séquence du projet, mais serait de nature ontologique, dans le sens où cette démarcation servirait à définir ce qui relève du subjectif (propre à chaque architecte) et de l’objectif, de l’objectivation, dans le sens littéral de faire objet. C’est pour cette raison d’ailleurs que Yessios ne s’intéresse pas à définir la conception, mais à quoi dans la conception est objectivable. « Même si nous ne pouvons pas tenter de définir la conception [design], nous abordons la question de savoir si elle est calculable ou non » (Yessios, 1987).

25Il est vrai que se sera à cette période que les tentatives de saisir les processus de conception dans leur intégralité perdront de leur intérêt : il y avait toujours quelque chose dans le processus qui leur échappait. Certains ont même parlé de puzzle (Archea, 1987) dans le sens où, peu importe la méthode employée, le projet et la cohérence de ses processus n’apparaissent seulement une fois toutes les pièces assemblées. D’autres ont démontré que les architectes fonctionnaient par concept-nomades, proposant « des agencements sans raison » (Girard, 1986) rendant ainsi difficile d’établir un système capable d’englober la totalité et la cohérence des processus singuliers de conception.

  • 1 Cette multitude de SE est également visible dans Intelligence artificielle et CAO en BTP. Applicati (...)

26Si plusieurs architectes ont délaissé cette question, la fragmentation opérée dans les processus leur a permis de se concentrer sur une partie relativement délimitée où il devenait possible de déployer de nombreux outils de calculs. C’est dans cette logique qu’est apparu dans les milieux de l’architecture de nombreux systèmes experts liés, plus ou moins, à la conception architecturale. Si les premiers systèmes experts apparaissent au milieu des années 1960, ces derniers feront une apparition en force dans le domaine de l’architecture au cours de cette même période du milieu des années 80. Comme l’explique Jean-Louis Laurière, dans son introduction générale aux systèmes experts, ou aides au raisonnement, en 1981, il fallait « que ces programmes travaillent dans des domaines bien définis, sachent apprendre les connaissances dans cette spécialité, sachent les gérer et les structurer » (Laurière, 1982). Certaines connaissances étaient évidemment plus propices à être gérées et structurées. Ce constat a été établi dans un important travail d’inventaire des systèmes experts dans l’architecture, le bâtiment et les travaux publics (Guéna, Zreik, 1988), où il a été répertorié une multitude de SE, aux vastes champs d’application, mais qui restaient malgré tout limités1. À la fin de l’enquête, le principal reproche était que ces systèmes étaient principalement utilisés, et utilisables, sur les phases finales de la conception, au moment où les choix décisifs de conception avaient été faits, et où il ne s’agissait ni plus ni moins d’évaluer le résultat. Une expertise relocalisée au sein des agences.

27Malgré ces SE très spécialisés, comme par exemple des SE dédiés au diagnostic thermique ou aux façons de gagner du temps sur le chantier, certains d’entre eux, comme TECTON, ont cherché à aborder la question large et complexe de la partie « sensible » de la conception. D’abord, il faut préciser que TECTON se définissait comme un système co-expert.

L’objectif de cette recherche est de doter un système de connaissance architecturales non pour faire de la conception automatique, mais pour enrichir et améliorer l’interaction homme/machine en offrant à l’architecture un outil de travail intelligent. En ce sens TECTON est un système co-expert en architecture, c’est-à-dire que ce n’est pas un système capable de résoudre des problèmes architecturaux, mais plutôt un outil intégrant d’une part du savoir-faire architectural relatif à la description et à la manipulation des objets architecturaux dans un processus de conception (Guéna, Zreik, 1988)

28Si l’équipe de TECTON s’appuyait sur le vocabulaire des architectes ainsi que sur les documents graphiques que ceux-ci produisaient (Hanot et all., 1986), la question même d’établir un savoir-faire spécifique à la conception recoupait les questions plus larges de la nature même de la conception en architecture.

Les questions autour du dessin

29Le retour en force du dessin a entraîné plusieurs questions autour de la représentation dont celle du type de représentations à privilégier, dont l’opposition entre 2D et 3D a constitué l’un des débats centraux. Parmi les pionniers comme Charles Eastman, certains privilégieront la représentation 2D, car selon le spécialiste, les difficultés des modeleurs de solides [Solid Modeling] de l’époque, n’étaient pas seulement lié à des problèmes techniques, de performances, de maniabilité, mais à d’autres raisons, plus profondes, celles liées aux capacités d’abstraction du dessin 2D. « Le dessin est l'abstraction de l'artefact conçu en fonction du contexte. [...] Le dessin permet un “flou” pendant la conception de l'artefact, ce que la modélisation de solides ne permet pas » (Eastman, 1987). Eastman ne sera ni contre la modélisation tridimensionnelle, ni contre l’ordinateur, mais ceux-ci devaient rester sous la tutelle du dessin. Les bénéfices de l’ordinateur, pour lui, étaient d’améliorer la productivité en s’occupant principalement des tâches automatisables. Il était possible de réaliser des modélisations à partir de projections orthogonales, mais non l’inverse.

30D’autres architectes en revanche tenteront justement de renverser cette dominance de la projection orthogonale, du dessin, comme Chris Yessios. Il faut dire que Yessios était pourtant d’accord avec le constat d’Eastman, les modeleurs de solides employés dans l’industrie n’étaient pas adaptés : ils étaient inefficaces pour la pratique architecturale. Cela ne voulait néanmoins pas dire qu’il rejetait tout type de modeleur, au contraire, ce constat lui a permis de développer un type de modeleur propre à la conception architecturale. Son idée était que les modeleurs ne devaient plus reposer sur une conception à partir de pleins (solides), mais des vides. Pour ce faire, Yessios a décrit des enveloppes spatiales [Space Enclosure] comme les peaux des vides [skins of voids] qui étaient générées à partir d’un squelette axial définissant ainsi une partie contenue et un contenant. Cette manière de modéliser, à partir des vides, permettait une plus grande efficacité pour répondre aux exigences de la conception architecturale, lorsqu’il était question de réaliser des formes relativement complexes, de concevoir des espaces irréguliers, ou de réaliser plusieurs manipulations sur une modélisation quelconque.

Figure 4. Processus de modélisation du vide, Chris Yessios, Ohio State University, 1987.

31Plus spécifiquement, le processus était réalisé à partir d’un croquis qui servait de base au squelette axial, qui lui, permettait de générer un modèle 2D, d’en évaluer la cohérence, et finalement devenait tridimensionnel. L’objectif de Yessios était de parvenir à travailler directement avec la modélisation, car celle-ci avait de nombreux avantages, dont celui de : « nous permettre d’extraire n’importe quelle information pertinente et utilisable » (Yessios, 1987). La modélisation volumétrique constituait une étape qui permettait de parvenir plus facilement à celles de l’édifice et de sa construction. Yessios développera cette idée, et la radicalisera avec la création de son logiciel. « Form*Z est un argumentaire contre le brouillon [drafting] » (Serraino, 2002).

32Quintrand partageait lui aussi des idées similaires, mais l’opposition n’était pas tout à fait la même. Pour lui, il y avait bien un retour du dessin, car le dessin avait jusqu’alors été « étranglé » d’une part par l’analyse mathématique écrite (type Alexander) et d’autre part par les réactions vives contre la virtuosité graphique (type Beaux-Arts). La réalisation d’un système CAO était pertinente pour lui car elle permettait de « créer les conditions d’une mise en situation informatique de l’espace graphique de résolution de problème dans des conditions telles qu’elles garantissent le bon fonctionnement de l’interaction entre le concepteur et son projet/problème tout au long du processus de conception » (Quintrand et all., 1985). Cette mise en situation était possible grâce à la maquette virtuelle et à « la mesure à quatre vues » qu’elle permettait. En effet, « représenter sur un écran, et simultanément, des vues multiples d’un objet, [permettait] d’évaluer, mesurer l’état du projet architectural dans toute sa complexité tridimensionnelle et en gérer la cohérence » (Quintrand, 1986b). La modélisation offrait la possibilité de travailler avec une image « objective et complète » qui se rapprochait de la perception que pourrait avoir l’usager du bâtiment une fois celui-ci construit. C’était grâce à ce type de visualisation, offrant plusieurs points de vue, qu’il devenait possible pour l’architecte de développer son projet relativement tôt dans le processus. Le fait de percevoir l’édifice à venir constituait en quelque sorte un support à l’imagination de l’architecte, où ce dernier serait en mesure d’évaluer et de développer ses intuitions de conception.

L’épisode des explorations formelles

33Cette recrudescence de l’image, en partie dû aux améliorations des simulations informatiques, type morphing et mapping (dans un premier temps) a entraîné un épisode fameux d’explorations formelles où, justement, ce qui avait jusqu’alors été réservé à l’architecte pouvait désormais être généré par les différents logiciels de simulation. L’ordinateur devenait un générateur de formes capable de proposer des solutions formelles alternatives qui, n’étant pas imaginées a priori, ni même imaginables, venaient déstabiliser les repères architecturaux les plus fortement ancrés. Dans cette optique, l’ordinateur servait à fournir de l’information inattendue et ne répondait plus à un but précis, clairement défini. Par conséquent, la rétroaction n’était plus négative, mais positive, elle servait à amplifier des patterns morphogénétiques de manière à leur faire découvrir d’autres façons de concevoir.

34Ces explorations à partir de processus morphologiques connurent un franc succès médiatique, relayées par de nombreuses revues, comme le démontre l’anthologie The Digital Turn in Architecture 1992-2012, dirigée par l’historien Mario Carpo (2013). Ces articles ont permis de montrer l’intérêt constant qui avait été manifesté par de nombreux architectes ainsi que les nombreux concepts qui ont été déployés pour suivre cette transition numérique. Plusieurs des principes défendus et des revendications exprimées pendant cette période se sont introduits dans les milieux de l’architecture, comme celle de prendre avec sérieux la réalité technique de ces processus numériques, ou encore de porter une attention toute particulière aux tout premiers moments de la création ; à ce qui relevait de l’inattendu ou de la nouveauté. La part d’inconnu et d’incertitude étaient essentielles et constitutives des processus de conception, obligeant les architectes à recourir à des connaissances qui étaient floues, évolutives et parfois manquantes. Ce basculement a entrainé des transformations radicales sur les façons de penser les processus numériques de conception, comme il est possible de le voir sous la forme de trois hypothèses, défendues par le chercheur Khaldoun Zreik : « 1) Admettre qu’il n’est plus concevable de prétendre pouvoir penser - a priori - l’ensemble des connaissances sollicité dans une activité de conception ; 2) Mettre en doute certaines des tendances qui pensent ou qui veulent faire croire que l’augmentation de la quantité d’informations (abstraite) améliore le rendement de leur usage ; et 3) Accepter l’absence d’une méthode exhaustive permettant de sélectionner, dans un ensemble d’information abstraite, la part de connaissance à intégrer ou à ignorer dans un processus » (Zreik, 1995). L’activité de conception procède par tâtonnements, opérant ainsi un revirement radical dans les manières d’intégrer, voire d’associer, l’informatique dans les pratiques.

35Comment penser les parts d’inconnu et de créativité de la conception architecturale, en sachant que celles-là sont formées directement et indirectement par le milieu technologique dans lequel les architectes conçoivent ? Certaines théories ont tenté de modéliser cette difficulté propre aux processus de conception en design, architecture et en urbanisme, comme la théorie C-K, élaborée et développée par Armand Hatchuel et Benoît Weil. Cette théorie permet en premier lieu de surpasser la « distinction classique entre jugement analytique et jugement synthétique. [...] Les deux jugements se confondent. L’analyse est nécessairement synthétique et la synthèse fait fonction d’analyse » (Hatchuel, Weil, 2008). L’assouplissement de cette distinction donne en effet une représentation plus juste des processus de conception à l’œuvre et laisse par conséquent ouvert la place accordée à l’ordinateur. L’un des objectifs majeurs de cette théorie consiste à définir la « rationalité de l’inconnu comme fondement de la raison conceptrice. » Plus précisément : « Elle modélise le raisonnement de la conception comme une double expansion, expansion dans l’espace des concepts et expansion dans celui des connaissances » (Ibid.). C’est grâce à cette double expansion – des concepts et des connaissances – qu’il devient possible d’approcher la logique de l’inconnu.

36Il faut préciser d’une part que concept ne prend par sa signification traditionnelle, mais répond à celle connue dans les milieux de l’architecture, du design, comme proposition innovatrice ou « ce qui initie un travail de conception » ; et d’autres part l’émotion ou la sensibilité font partie des formes particulières de connaissances. Nous pouvons ajouter encore que la notion d’expansion est relative, c’est-à-dire qu’elle repose sur la capacité du concepteur à reconnaître la connaissance, ce qui peut dépendre « de notre sensibilité, de notre entrainement ou des savoirs dont nous disposons » (Ibid.).

37Il s’opère alors un chassé-croisé entre plusieurs types de connaissances et d’apprentissages qui occupent à la fois les programmeurs, quels types de connaissances le programme doit-il intégrer et faire fructifier ; mais également chez l’utilisateur qui doit être sensible au type d’information proposé afin de le rende utilisable pour sa conception.

Connaissances et mode d’évaluation

38Cet intérêt pour des connaissances spécifiques (quantitatives ou qualitatives), leur possible expansion, aura pour conséquence de ne plus fermer la conception sur elle-même, mais de l’ouvrir de manière à intégrer de nombreuses préoccupations comme celles du développement durable, ou celles plus spécifiques à l’architecture, comme le retour en force des questions autour de la construction, de la matérialité et de la mise en œuvre. Il n’est plus tellement question de connaître la place à accorder à l’ordinateur que d’entrer en relation avec les différents éléments qui permettent aux concepteurs d’évaluer leur modèle, selon les problématiques qui les occupent. S’il est difficile de présenter un panorama exhaustif de l’ensemble de ces connaissances spécifiques proposées par les différents outils numériques, il est néanmoins possible de soulever différents types de relation offerts par certaines tendances logicielles. Il existe en effet un rapport à la connaissance différent selon que l’utilisateur conçoive sur une maquette numérique, avec un logiciel BIM comme par exemple Revit (Autodesk), ou dans un environnement de programmation graphique, type Grasshopper (Mc Neel & Associates). Les manières de manipuler l’information et celles de valider les choix de conception reposent sur des systèmes normatifs complètement différents. Malgré que les pratiques contemporaines ont montré « le passage » d’un logiciel à l’autre, selon le niveau d’approximation souhaité (Teyssot, Jacques, 2009), il n’en reste pas moins que deux pôles peuvent être définis quant à ces rapports à la normativité.

39D’un côté, il y aurait celui mis en avant par les technologies BIM, et plus encore par les Model Checkers, qui se placent en quelque sorte dans la lignée des SE, où certains architectes les appliquent à leur modèle de manière à le vérifier, selon différentes normes, entrainant ainsi un type de conception fortement lié aux forces en présences, place souvent occupée par les milieux de la construction. Dans cette logique, l’utilisateur reçoit de l’information calibrée selon des normes présélectionnées qui se retrouvent de plus en plus « inscrites » dans le logiciel ou l’application choisie. Certaines interfaces proposent d’ailleurs différents tableaux compilateurs ou tableaux de bord [Dashboard] intuitif, qui permettent de calibrer la modélisation selon différents critères.

40D’un autre côté, il y a un autre type de rapports qui s’engagerait avec des modeleurs qui proposent, dès les premiers moments de la conception, d’intégrer un mode d’évaluation de la morphologie en cours de développement. Que ce soit des plugins capables de gérer des géométries complexes ou des modeleurs dédiés à un critère spécifique (performances thermiques, ambiances lumineuses, etc.), la question n’est plus à proprement parlé d’établir des normes, ni d’augmenter le nombre de connaissances dans les logiciels, mais de chercher des moyens pour rendre cette connaissance effective et productrice de connaissance à son tour. C’est en quelque sorte ce que l’exposition non standard cherchait à penser : « une normativité ouverte, toujours ancrée au cœur de la détermination du singulier » (Migayrou, 2004). En d’autres termes, il ne s’agit pas de s’opposer à la norme, mais de chercher à l’ouvrir, à la faire fructifier par rapport à une connaissance expansive de telle sorte qu’elle puisse s’adapter au contexte dans lequel celle-ci est utilisée.

41Ces deux pôles offrent différents degrés de maniabilité-rigidité des modélisations, selon qu’elles se trouvent sous l’autorité, plus ou moins forte, du système de normes intégrée. Il ne s’agit évidemment pas de privilégier un type de rapport, mais de montrer que l’information pertinente se trouve régie par des modes de fonctionnement différents et parfois opposés. Si la « formation » de l’utilisateur, sa sensibilité, joue certainement un rôle central dans la « saisie » de cette information pertinente, il n’en reste pas moins, qu’une manière de faciliter cette maniabilité réside dans la possibilité d’évaluer ces connaissances sur au moins deux niveaux. Un premier niveau, d’abord, qui permet d’évaluer la proposition selon un critère, une norme, mais également un second, qui permet d’évaluer ce critère ou cette norme selon le contexte dans lequel il (ou elle) est effectif. Ce deuxième niveau d’évaluation est étroitement lié à la façon dont sont formulés, présentés et intégrés les processus normatifs dans les processus plus large de conception.

42Cette question de la visualisation de ces connaissances, loin d’être secondaire, a au contraire des répercussions sur la maniabilité et la flexibilité de l’information à intégrer dans les processus. Comme le principe d’homéostasie, présenté au tout début, ce signal d’information doit trouver sa place de régulation de manière presque naturelle, de manière à participer au maintien de l’équilibre dynamique des processus de conception.

Conclusion

43Cette étude historique, rapide et partielle, a cherché à regrouper certains des questionnements qui ont occupé les milieux de la conception architecturale, ainsi que de faire ressortir les débats qui ont eu lieu. Même si le rapprochement entre informatique et conception architecturale se fait relativement tôt, il ne va pas de soi quant au champ d’action à attribuer à l’ordinateur. L’idée d’automatiser la conception va rapidement être mise de côté devant la difficulté à définir les processus eux-mêmes, à chaque fois singulier, et parfois désordonnés.

44Les concepteurs auront ensuite une idée relativement précise de ce qu’il est « informatisable » et ce qu’il ne l’est pas. Cette frontière sera néanmoins grandement déplacée au milieu des années 1990, pour des raisons à la fois techniques mais également liées à l’introduction massive des technologies numériques dans le quotidien : grâce à leur domestication. Les processus numériques occuperont ainsi une place de plus en plus importante dans les premiers moments de la conception, où les intentions ne sont pas encore clairement formulées et par conséquent, ces technologies participeront de manière co-constitutive à la genèse du projet. Ces explorations ont entrainé un déplacement de l’attention et des questionnements. Les architectes engagés dans une pratique numérique ne s’intéressent plus autant intensément à l’activité même de conception, mais portent une attention particulière sur le choix des connaissances fécondes pour leur projet, ainsi qu’à leur organisation, leur calibrage. Il a donc été possible de remarquer un nouveau rapport qui s’est établit dans le choix des connaissances valables pour le projet. La façon même de mettre à disposition ces informations, de les faire fructifier, a impliqué de penser des dispositifs capables d’assurer la communication-compréhension de cette information, de manière analytique et intuitive.

45Ces déplacements successifs ont interrogé à chaque fois le choix des connaissances à mobiliser, à formuler et à intégrer dans les programmes informatiques, ainsi que la manière de les rendre manipulables pour l’utilisateur. Les développements récents de l’intelligence artificielle, avec entre autres les GAN (réseaux de neurones antagonistes génératifs [Generative Adversarial Networks]), ou encore les développements de plateformes dédiées à la conception architecturale semblent reconfigurer à nouveau frais le rapport entre les savoirs intuitifs et ceux rationnels, et surtout, ces développements relancent la question de la place à accorder à la machine, à la fois dans les processus de conception, ce qui était déjà connu, mais à un niveau plus large, dans la reconfiguration qui s’opère entre les différents acteurs – humains et non-humains – réunis autour d’un projet.

Haut de page

Bibliographie

ALEXANDER, C. (1971 [1964]), De la synthèse de la forme, essai, Paris, Dunod.

ALLÉE, G. (1971), L’architecte face à l’informatique, Techniques et Architecture, numéro spécial Informatique et architecture, 33e série, (4), 73.

ARCHEA, J. Puzzle-Making : What Architects Do When No One is Looking, in : KALAY, Y. E. (ed), Principles of Computer-Aided Design: Computability of Design, John Wiley & Sons, 11-36.

CADOZ, C. (1994) Le geste canal de communication homme/machine. La communication “instrumentale”, Technique et science informatiques, vol. 13, (1), 31-61.

CARPO, M. (2013) The Digital Turn in Architecture 1992-2012, Architectural Design Reader, Chichester, Wiley & Sons.

COURTIEUX, G. (1971), Récents développements dans les applications des ordinateurs à la construction civile, à l’architecture et à l’urbanisme, Techniques et Architecture, numéro spécial Informatique et architecture, 33e série, (4), 48-49.

De PAOLI, G. (1998), La CAO en architecture. Modélisation des actions et définition des opérations », in : TROUSSE, B. et K. ZREIK (eds), Les objets en conception, actes de 01Design 97, Paris, Europia Production, 197-207.

EASTMAN, C. M. (1987), Fundamental problems in the development of Computer-based Architectural Design Models, in : KALAY, Y. E. (ed), Principles of Computer-Aided Design: Computability of Design, John Wiley & Sons, 133-140.

GIRARD, C. (1986), Concept-nomades. Traité d’indicipline, Bruxelles, Mardaga.

GUÉNA, F. et K. ZREIK. (1988), Systèmes experts dans l’architecture, le bâtiment et les travaux publics. Étude de cas : la France, le Japon, les États-Unis et le Royaume-Unis, CIMA, Ministère de l’équipement et du logement.

HANOT, et all. (1986) Le projet TECTON : un système expert de CAO intégrant le savoir architectural, CAD and Robotics in architecture and construction, Hermès, 74.

HARFMANN, A. C., (1987) The Rationalizing of Design, in : KALAY, Y. E. (ed), Principles of Computer-Aided Design: Computability of Design, John Wiley & Sons, 1-8.

HATCHUEL, A. et B. WEIL. (2008), Introduction. L’activité de conception : figures anciennes et défis contemporains, in : HATCHUEL, A. et B. WEIL (eds), Les nouveaux régimes de la conception : Langages, théories, métier, Paris, Vuibert Cerisy, 1-14.

LAURIÈRE, J-L, Représentation et utilisation des connaissances. Première partie : Les systèmes experts, Technique et science informatiques, vol. 1, (1), 1982, 25-42.

LE ROUX, R. (2014), Présentation de l’édition française, in WIENER, N. La cybernétique. Information et régulation dans le vivant et la machine, Paris, Seuil.

LICHNEROWICZ, A. (1971), Préface, Journées Informatique et Conception en Architecture, l’IRIA (L’Institut de Recherche en Informatique et Automatique), Paris, 3.

MIGAYROU, F. (2003), Les ordres du non standard, in : MIGAYROU, F. et Z. MENNAN (eds), Architecture non standard, Paris, Centre Pompidou, 25-33.

MAROY, J-P. (1971), Introduction, Journées Informatique et Conception en Architecture, l’IRIA (L’Institut de Recherche en Informatique et Automatique), Paris, 5.

NEGROPONTE, N. et L. GROISSER. (1970), The Semantics of Architecture Machines, Architectural Design, (9), 1970.

NEGROPONTE, N. (1974), Concerning Responsive Architecture, in : ALLEN, E. (ed.) The responsive House, Cambridge, Mass., MIT, 302-305.

NELSON, T. (1977), The Home Computer Revolution, Indiana, South Bend.

QUINTRAND, P. (1971), Considérations générales sur informatique et architecture », Techniques et Architecture, numéro spécial Informatique et architecture, 33e série, (4), 66-68.

QUINTRAND, P. et all. (1985), La CAO en architecture, Paris, Hermès.

QUINTRAND, P. (1986a), La recherche dans le domaine de la conception architecturale assistée par ordinateur en France, CAO et Robotique en architecture et B.T.P, Paris, Hermès, 15.

QUINTRAND, P. (1986b), L’image en architecture, in : Alain Renaud (ed.), Imaginaire numérique, Paris, Hermès, 239-247.

SERRAINO, P. (2002), History of Form*Z, Basel, Birkhäuser.

SIMON, H. (2004 [1969]), Les sciences de la conception, Les sciences de l’artificiel, Paris, Gallimard.

SUTHERLAND, I. [1963), Sketchpad. A Man-Machine Graphical Communication System. PhD Thesis, Massachusetts Institute of Technology.

TEYSSOT, G. ET O. JACQUES. (2009), Faire parler les algorithmes. Les nuages virtuels du Metropol Parasol (Séville), Visiteur, (14), 101-123.

WIENER, N. (2014 [1948]), La cybernétique. Information et régulation dans le vivant et la machine, Paris, Seuil.

WIENER, N. (2014 [1954]), Cybernétique et société. L’usage humain des êtres humains, Paris, Seuil.

WRIGHT STEENSON, M. (2017), Architectural Intelligence. How Designers and Architects Created the Digital Landscape, Cambridge, Mass., MIT Press.

YESSIOS, C. (1987), The computability of void architectural modeling, in : KALAY, Y. E. (ed), Principles of Computer-Aided Design: Computability of Design, John Wiley & Sons, 141-172.

ZREIK, K. (1995), Communication et conception. Le dilemme du savoir-ignorance, in : CAELEN, J. et ZREIK, K. (eds), Le communicationnel pour concevoir, Paris, Europia productions, 73-86.

Haut de page

Notes

1 Cette multitude de SE est également visible dans Intelligence artificielle et CAO en BTP. Applications et recherche, CIMA, Paris, Hermès, 1988.

Haut de page

Table des illustrations

Légende Figure 1. Quelques exemples sur Sketchpad, Ivan Sutherland, MIT, 1963.
URL http://journals.openedition.org/netcom/docannexe/image/5426/img-1.jpg
Fichier image/jpeg, 80k
Légende Figure 2. Urban 5, Architecture Machine Group (Nicholas Negroponte), MIT, 1968.
URL http://journals.openedition.org/netcom/docannexe/image/5426/img-2.jpg
Fichier image/jpeg, 187k
Légende Figure 3. Simulation 0 du site de Luminy avec LOKAT, simulation réalisée par le GAMSAU, 1971.
URL http://journals.openedition.org/netcom/docannexe/image/5426/img-3.jpg
Fichier image/jpeg, 445k
Légende Figure 4. Processus de modélisation du vide, Chris Yessios, Ohio State University, 1987.
URL http://journals.openedition.org/netcom/docannexe/image/5426/img-4.jpg
Fichier image/jpeg, 225k
Haut de page

Pour citer cet article

Référence électronique

Sébastien Bourbonnais, « Rétroaction dans les processus numériques de conception »Netcom [En ligne], Articles, mis en ligne le 19 février 2021, consulté le 07 mars 2021. URL : http://journals.openedition.org/netcom/5426

Haut de page

Auteur

Sébastien Bourbonnais

Docteur en architecture (ENSA Paris-Malaquais et Université Laval, Québec). Chercheur associé à l’EVCAU (ENSA Paris Val-de-Seine) et consultant de recherche chez ASYNTH SAS, 93 rue de la Villette, Lyon.

Haut de page

Droits d’auteur

Licence Creative Commons
Netcom – Réseaux, communication et territoires est mis à disposition selon les termes de la licence Creative Commons Attribution - Pas d'Utilisation Commerciale - Pas de Modification 4.0 International.

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search