Article body

Introduction

La programmation architecturale (PA) fait partie d’un ensemble plus vaste et complexe d’étapes nécessaires à la réalisation de l’édification du bâtiment. Elle est considérée par plusieurs auteurs et praticiens oeuvrant dans le domaine de la construction comme un élément essentiel de ce processus de réalisation. Se situant au tout début du processus, et dans bien des cas en tant que première étape, la PA a comme objectif premier de prévoir en amont de la conception du projet les éléments essentiels et constitutifs d’une bonne architecture : « The architectural program is the document in which the identified values, goals, facts, and needs are presented[1]. »

Par ailleurs, l’architecture virtuelle (AV) est un domaine d’application en émergence de l’architecture, qui possède plusieurs aspects similaires à l’architecture traditionnelle, mais qui révèle aussi ses propres caractéristiques et spécificités. Entre autres, la programmation d’une architecture virtuelle ne conduit pas nécessairement à son anticipation, mais au contraire à l’accroissement de sa complexité. Ainsi, l’AV doit être envisagée, comprise et développée comme un nouveau champ de recherche et de pratique en architecture ayant ses propres contingences.

L’essentiel de cet article vise à préciser et documenter cette démarcation, à dégager de cette nouvelle pratique les éléments essentiels qui différencient la programmation d’une architecture virtuelle de celle d’une architecture traditionnelle. L’exposé s’inspirera d’un exemple concret de la réalisation d’une architecture virtuelle, dans le cadre d’un atelier de conception architecturale par collaboration à distance qui s’est déroulé à l’automne 2008, portant sur un prototype de campus virtuel pour un programme d’enseignement à distance de deuxième cycle en arts visuels. Dans un premier temps, la programmation architecturale est introduite et définie, puis l’architecture virtuelle et enfin l’application de la programmation à l’architecture virtuelle.

La programmation architecturale

Il existe plusieurs démarches et méthodes pour établir le programme architectural d’une future construction. Ces méthodes, qu’elles soient ad hoc ou référées, visent toutes le même objectif, soit identifier le plus justement possible tout ce qui doit être pris en compte pour mener à bien la réalisation du futur bâtiment, pour ultimement être à même d’établir le coût, le plus juste possible, qui prendra en compte à la fois les intentions des intervenants, les besoins des futurs utilisateurs et le contexte de la réalisation de ce bâtiment. Nous résumerons l’esprit de cette définition en deux citations : la première est empruntée à Hilaire : « Le but de la programmation est de définir les conditions précises de l’intervention du maître d’oeuvre et d’anticiper les conditions de vie et de fonctionnement dans le futur équipement[2] », et la seconde à Duerk : « Programming is a systematic method of inquiry that delineates the context within which the designing must be done as well as defines the requirements that a successful project must meet[3]. »

Par ailleurs, la programmation consiste en un préprogramme contenant une synthèse des études pré-opérationnelles, soit les définitions et évaluations des objectifs du projet et ses contenus, et un programme contenant une description des études détaillées, soit une définition plus précise des exigences techniques et qualitatives du projet. L’ensemble constitue un document contractuel qui définit en termes d’objectifs et de performances le projet à réaliser.

Ainsi peut-on dire que programmer en architecture implique à la fois qualifier et quantifier l’architecture.

Les principaux acteurs de la programmation sont : les architectes, ingénieurs, géographes, sociologues, urbanistes, politiques… et très rarement les futurs utilisateurs.

Le rôle de la programmation en architecture peut se décliner par l’étude des fonctions (organisation fonctionnelle du projet), l’élaboration de normes prescriptives, l’étude des interactions et des activités humaines, l’étude de la relation du corps à l’espace. Fréquemment, pour définir les enjeux de la programmation en architecture (dans le cadre du bâti), on se doit de répondre à la série des qui, quoi, pour qui, pourquoi, comment, où et quand. À savoir : qui a décidé d’engager un projet ? Que veut-on programmer/concevoir/bâtir ? Pour quel public ? Quels seront les utilisateurs ? Faut-il aménager, construire ou réhabiliter ? Avec quel budget, quels partenaires, quelles contraintes techniques et d’implémentation du projet ? Quel site choisir ? Quelles sont les contraintes urbaines, politiques ? Quels sont les impératifs de dates, d’échéanciers ? Quels sont les délais de réalisation pour les différentes opérations ? Ces questions sont-elles aussi présentes dans le cadre d’une architecture virtuelle ? La réponse semble être oui. Cependant, programmer les rapports personnes-milieu dans des espaces réflexifs, par exemple, va au-delà du processus de « planification » et de « gestion » de ces espaces. En effet, les enjeux humains, techniques, esthétiques sont différents, de même que l’interaction entre l’espace conçu et l’utilisateur (avatar). Ainsi, la programmation architecturale en architecture virtuelle doit intégrer la possibilité de programmer (par le biais de langages de scripts) la réactivité de l’espace (dit alors réflexif) : les objets volumiques modélisés peuvent se modifier en répondant à des actions des avatars. Un des objectifs finaux de la programmation architecturale peut alors consister, une fois le programme du bâtiment établi, à préciser ce qui, dans ce programme, sera satisfait par une modélisation volumique, et ce qui le sera par la programmation (informatique, cette fois-ci) de scripts. Par exemple, en architecture virtuelle, une passerelle peut être modélisée comme relativement étroite (ne laissant passer qu’un avatar), et programmée pour prendre des dimensions plus conséquentes en fonction du nombre d’avatars qui l’empruntent. Cette « dilatation » pouvant avoir des conséquences sur les volumes avoisinants, ceux-ci peuvent alors être modélisés et/ou programmés en conséquence, et ainsi de suite. La fonction d’un élément d’architecture virtuelle peut donc être en partie définie dans son script, ce qui rajoute une étape à la phase de programmation architecturale : tel aspect doit-il être modélisé et/ou programmé ?

Incidence de la programmation en architecture

Plusieurs auteurs s’accordent pour reconnaître à la programmation un rôle plus important que celui d’une simple production de document, d’un cahier des charges visant à la réalisation d’un projet. Ainsi, deux objectifs apportent davantage à la programmation architecturale : d’une part, concevoir une bonne architecture, et d’autre part, assurer une bonne communication (transmission de l’information) entre les différents intervenants, clients, architectes, ingénieurs, entrepreneurs, utilisateurs. Et bien sûr, une bonne programmation conduit à réduire considérablement les coûts en amont du processus de construction du bâtiment : « La démarche programmatique, bien au-delà de la seule production d’un programme, consiste en la mise en place des conditions appropriées de dialogue et de réflexion entre les acteurs d’une opération, au service d’un projet[4]. »

Ainsi, la programmation devient un véritable processus d’élaboration du projet où des éléments de conception peuvent être développés. Et l’une de ces pistes est l’intégration et la participation des futurs utilisateurs à l’élaboration de la commande[5]. Trop souvent, le projet d’architecture est élaboré de manière fermée. Les intervenants traditionnels (architectes, ingénieurs, etc.) croient connaître ce qui sera bien adapté pour les futurs utilisateurs, alors que le recours à un groupe d’utilisateurs collaborant à la prescription lors d’un échange itératif avec les intervenants professionnels peut contribuer grandement à l’augmentation de cette adaptation des espaces conçus, si leur intervention s’effectue en amont de la conception, lors de la programmation du projet.

Une telle démarche, pour aboutir, doit nécessairement faire appel à la participation de tous les intervenants, ce qui fait ressortir du même coup l’importance de la dimension communicationnelle qui doit être gérée à cette étape du processus entre tous les acteurs du projet d’architecture[6]. Comme nous le verrons dans la prochaine section, la dimension communicationnelle est particulièrement présente en architecture virtuelle. Ainsi, ce type de programmation participative devrait donc être facilité.

L’architecture virtuelle

La notion d’architecture virtuelle est intimement liée à celle de métavers, ces mondes 3D interactifs considérés comme parallèles au nôtre. Dans des articles précédents, nous avons aussi défini l’AV comme étant un médium de conception, un outil pour « concevoir dedans » ces métavers. Ainsi définie, l’architecture virtuelle devient aussi un environnement à planifier et à programmer qui nécessite par extension un enseignement, un apprentissage et une pratique du projet d’architecture qui lui est propre. L’AV devient un médium intégral, ayant la capacité de supporter et de développer à la fois la représentation, l’interaction, la modélisation (création et transformation), la communication et la diffusion de ses propres artefacts et constituants[7].

Prenant Second Life comme exemple de métavers, nous y observons une représentation (une mise en scène) calquée sur le monde réel. En fait, tout le développement de Second Life emprunte cette vision. C’est une analogie très forte, la plus fidèle possible de ce que nous observons dans notre monde, et qui en utilise tous les attributs : la course du soleil au fil d’une journée (qui dure 4 heures dans cet univers) avec ses levers et ses couchers aux rendus flamboyants, son ciel variable, passant du nuageux au temps clair sous l’action du vent. De fait, la physique de notre monde tend à y être modélisée et simulée : la gravité, la propagation du son avec l’effet Doppler, etc. Cet univers, à première vue coutumier et rassurant, atteint par là même un degré de prégnance qui va conditionner son développement. En effet, si tout ce qui se construit dans Second Life est le fait des « résidents », ceux-ci sont confrontés à un contexte qu’il faut bien qualifier, dans une pratique de transformation, « d’actuel », et qui conditionne leurs réalisations par une approche mimétique du monde tangible. Mais précisément, c’est cette capacité de représentation qui donne lieu à son interprétation par ceux-là mêmes qui y sont confrontés et amenés à la transformer. Car, tout ceci étant simulé, il est possible d’activer (ou de désactiver) tel ou tel comportement ou phénomène, d’y faire voler les avatars, de suspendre dans le vide les artefacts, quelle que soit leur taille, de marcher sur et sous « l’eau », de se téléporter, etc. Bref, de redéfinir la représentation d’un métavers par cette AV.

Mais il y plus. Cette « réalité » d’un univers plus ou moins mimétique et coutumier, selon l’humeur du créateur (représenté par Linden Lab, puis par les résidents), a déterminé un contexte particulier qui sert maintenant de toile de fond à toute activité d’aménagement spatial dans Second Life, incluant toutes les activités de programmation. Tout exercice d’architecture hérite d’un déjà-là, d’un actuel qui reste, lui, totalement virtuel. Rapprocher ces deux termes, ou plutôt ces deux états, que le théâtre de la représentation numérique convoque dans une même fiction, n’est pas sans soulever une certaine ambiguïté chez le concepteur et le programmeur. Ce que celui-ci est tenté de considérer comme un contexte physique ambiant n’est que représentation, et, à l’opposé, la représentation de son artefact se voit dotée d’une qualité de présence physique identique à celle de l’environnement : les frontières entre représentation et réalisation sont abolies. À partir du moment où le modèle numérique n’est développé que pour s’inscrire dans, et se confronter à, un monde numérique, il n’est plus tout à fait modèle et tend à s’octroyer une parcelle de réalité. De plus, si l’on considère que les représentations du projet d’architecture sont à la fois représentation d’un objet (artefact) et d’un raisonnement, on mesure à quel point l’exercice de conception dans un tel univers (où, pour schématiser, contexte = représentation = artefact = raisonnement) est à même d’offrir un point de vue original et fertile sur l’architecture. Cette complexité d’enchevêtrements entre différents niveaux d’appréciation du projet d’architecture est très bien mise à l’oeuvre lors de la communication entre étudiants architectes dans le cadre des ateliers de conception collaborative à distance que nous organisons[8]. Dans ce cadre, communiquer à l’autre (ou façonner devant lui par l’intermédiaire de son propre avatar) un objet tridimensionnel, c’est illustrer son raisonnement, et rendre sensible, en l’installant dans l’univers, l’artefact en cours de conception. En ce sens, Second Life, comme lieu d’une architecture virtuelle, possède un mode de représentation certainement significatif qui offre un grand potentiel de réflexion sur l’architecture, dans sa dimension pédagogique ou pratique.

Par ailleurs, l’entrecroisement des différents niveaux d’interprétation du projet d’architecture fait aussi de Second Life un support « instable », ou plus exactement « nomade », fuyant toujours le regard d’indexation ou de définition, pour l’enseignement prospectif de la conception, activité cognitive qui relève aussi bien des images mentales que des représentations externes. Il s’agit pour nos étudiants de concevoir Second Life et ce, selon les différents sens du terme : se faire une idée de ce qu’il est ou pourrait être, et intervenir dans un geste d’invention. Il faut donc se mettre à distance de cet univers, le décrypter, l’analyser, et aussi s’y investir dans un acte créatif. L’instabilité ou le nomadisme d’un tel environnement peut constituer, selon la stratégie employée, un obstacle ou au contraire une passerelle entre ces deux activités.

La nature abstraite de l’architecture virtuelle devrait lui conférer une plus grande connivence avec l’activité mentale du concepteur : un schéma, un organigramme, peut être élevé au statut d’architecture virtuelle (et ne plus constituer qu’un simple outil accessoire). Toute trace, ou représentation, est éligible à un tel statut. En particulier les différents repentirs ou esquisses peuvent s’incorporer à l’édifice final qui devient alors une illustration plus complète et précise de l’histoire d’un processus, d’un raisonnement. On serait alors peut-être capable de mieux percevoir et comprendre la nature des pensées-idées émergeant de l’interaction sujet-objet, étudiant-artefact durant le processus de conception. C’est du moins le témoignage des étudiants participant à nos ateliers[9]. En effet, en permettant l’expression et la visualisation de leurs pensées de manière plus abstraite, c’est tout le processus d’idéation qui devient ainsi plus explicite, plus conscient.

L’interaction sujet-objet (artefact), déjà mentionnée, est également bien exploitée, assurée et facilitée par l’architecture virtuelle, y compris celle de Second Life. Elle dépasse la simple relation sujet-objet, soutenant la communication et l’interaction sujet-sujet par l’identification et la personnalisation d’un avatar (représentation 3D d’un utilisateur). De plus, cette dimension de l’interaction entre participants se déploie aussi en actions sur l’autre par l’intermédiaire de l’espace et des objets qui y sont conçus, manipulés et contenus.

Associées à l’action résultant d’une interaction, la modélisation et la transformation en temps réel sont des composantes identifiables du médium. À ce titre, comme technologie, Second Life est reconnu présentement comme l’environnement 3D offrant le plus de possibilités de modélisation, de transformation et de création des artefacts réalisés dans le métavers en temps réel et en présence. Ainsi que nous l’avons dit précédemment, une caractéristique du métavers de Second Life est d’être entièrement le fruit du travail de ses résidents. Une expression est même née de cette activité de création des formes dans Second Life, « rézer » (to rez) une primitive ou un objet en inventaire déjà construit, ce qui signifie faire apparaître, mettre en place, en scène un objet. Ces capacités de modélisation et de transformation en temps réel sont complétées par celle de pouvoir rendre dynamique, de programmer, tout ce qui compose Second Life par macro-programmation avec le langage de Second Life (LSL). Enfin, implicite à sa technologie, Second Life est également un médium de transformation interactif, en temps réel, tant de l’espace et des objets… que l’information qui y transite par texte (chat), image, audio et vidéo (streaming) rendant ainsi possible les conférences et performances « live » où l’expression artistique peut prendre place[10].

Nous avons déjà fait mention de la place importante qu’occupe la communication dans le déroulement de nos ateliers de conception collaborative[11]. Voyons cette importance en relation avec les possibilités de communication de Second Life. Bien adapté comme médium de communication, Second Life, tout en étant utilisé comme un lieu d’échanges synchrones d’informations entre participants que ce soit pour l’apprentissage de techniques de modélisation ou de macro-programmation avec LSL ou pour le déroulement d’une conférence, peut également servir à communiquer les idées et concepts architecturaux entre les intervenants, et ceci en temps réel. Cette dimension synchrone de la communication dans Second Life est de première importance pour accentuer l’impression de présence des participants et celle d’engagement dans l’activité en cours que ce soit par la présence de l’artefact lui-même, par le texte (chat) ou par l’audio aussi disponible. Ce réseau de communication, multidimensionnel, qui se met en place entre deux ateliers distants, concourt à une plus grande stimulation des participants qui doivent répondre et engager la communication avec leur homologue. Cette situation se répète aussi à différents niveaux de communication, développant autant de réseaux de communication, étudiant-étudiant, étudiant-enseignant, enseignant-enseignant et atelier-atelier[12]. Ces réseaux fonctionnant souvent en parallèle, la stimulation et l’information transmise deviennent beaucoup plus importantes qu’en situation traditionnelle, entraînant un besoin de s’occuper de la communication de manière explicite, ce qui aura des implications sur toute la programmation.

Dans sa théorie sur la diffusion des innovations, Everett Rogers conçoit la diffusion comme « […] the process in which an innovation is communicated through certain channels overtime among the members of a social system[13]. » Cette notion de diffusion peut être reprise dans le présent contexte d’une architecture virtuelle pour définir celle qui s’opère à l’intérieur de nos ateliers virtuels à partir de Second Life, en substituant le terme « innovation » à celui d’« état du projet » et, dans le contexte de Second Life, à celui de « réalisation du projet ». Or, cette diffusion s’opère à partir de multiples canaux : texte, voix, image, vidéo, 3D interactive (portes ouvertes). En fait, Second Life devient lui-même le médium de diffusion et peut étendre ses canaux de communication à l’extérieur sur Internet par tous les médias qui y sont disponibles.

En conclusion, cette analyse permet de définir l’architecture virtuelle, dont celle de Second Life en particulier, comme un médium intégral à cinq composantes, sous-systèmes, identifiables et caractérisant entièrement un médium unique et multidimensionnel de conception architecturale. À partir, donc, de la représentation, de l’interaction, la modélisation/transformation, la communication et la diffusion de et par l’architecture virtuelle, il devient possible d’articuler différemment la pédagogie, la pratique et la programmation du projet d’architecture, pour ainsi potentiellement transmuter son enseignement et ses pratiques.

La programmation architecturale et l’architecture virtuelle

D’une part, il ressort de ce qui précède que la programmation architecturale est un levier de mise en forme du projet d’architecture, puisqu’elle tente de prévoir, en amont, tous les composants susceptibles d’influencer les décisions éventuellement prises en aval du processus, lors, entre autres, de la conception du projet ; d’autre part, que l’architecture virtuelle possède ses propres impératifs et constituants qui font appel en particulier à une relation au temps (dimension dynamique du métavers) que l’on peut traduire par l’idée d’action et de présence en temps réel, lui conférant ses propres caractéristiques et, de ce fait, des considérations programmatiques spécifiques. Les implications spécifiques de l’AV quant à sa programmation acquièrent toutes leurs nuances dès lors que la question se pose de programmer l’artefact ou l’avatar. Mais, alors que nous pouvons établir des similitudes entre la programmation d’une architecture traditionnelle et celle d’une architecture virtuelle, par exemple prévoir pour un campus virtuel les équipements et espaces a priori utiles et nécessaires, certaines particularités de l’AV, par exemple ses capacités de communication et de modélisation, rendent le processus de programmation de l’architecture virtuelle progressif et dépendant, lié en quelque sorte au processus même de réalisation de l’AV et donc dynamique.

Dans une perspective encore plus radicale, on peut se poser la question suivante : s’agit-il de programmer l’artefact ou de programmer l’utilisateur (l’avatar) ? De programmer une machine ou un utilisateur (modèle utilisateur) ? La programmation dans le cas de l’architecture virtuelle peut-elle hésiter entre la programmation de l’espace ou des avatars ? Dans ce dernier cas, l’avatar (et, à travers lui, l’utilisateur) se voit donc conditionné à adopter une attitude spécifique vis-à-vis des espaces conçus.

De fait, « programmer » un artefact (du bâtiment au logiciel en passant par les objets d’utilisation courante) suppose d’avoir, peu ou prou, un modèle de l’utilisateur. Dans le cas des réalisations architecturales, ce modèle peut se permettre de reposer sur des typologies d’édifices ou des modèles de bâtiments dont les attributs caractéristiques ont été révélés par une sédimentation historique des usages. Toutefois, dans le cas de types de bâtiments « nouveaux » (aéroports, chaînes d’édifices de loisir, restaurants, hôtels, centres commerciaux, etc.), ce détachement par rapport au conditionnement de l’utilisateur ne s’est pas encore produit : suivre la file des personnes procédant à un enregistrement dans un aéroport, et faire comme tout le monde, est la meilleure manière de ne pas manquer son avion. L’utilisateur a donc là très peu de degrés de liberté (s’il ne veut pas rater son vol), et doit se conformer (par imitation de tiers s’il n’est pas expert) aux dispositions prévues pour lui. Il se retrouve en quelque sorte programmé dans son parcours et dans sa gestuelle pour franchir les différents lieux de ces espaces.

Dans le cas des logiciels, le détachement que pouvait procurer l’histoire de l’architecture ne s’est pas encore cristallisé dans un type d’artefact performant : il faut un modèle d’utilisateur. Modèle complexe à définir, généralisant des dispositions et des attentes, et revenant tout de même à transférer une partie de ce que sous-tend le terme « programmation » dans la part humaine du système de fonctionnement. Quoi qu’il en soit, un humain est, en principe, infiniment plus programmable, adaptable, façonnable, qu’un automate (du moins pour le moment). Des informaticiens (et plus précisément des entreprises de développement de logiciels) ont parfaitement compris et intégré cette considération pragmatique.

Dans le cas des « édifices » de l’architecture virtuelle (ou des aménagements spatiaux de l’univers numérique), qu’en est-il ? L’avatar (à la fois représentation de la part humaine du système humain-artefact et composante essentielle de l’interface du système humain-machine) est susceptible de programmation contextuelle, exogène, inaccessible aux moyens de contrôle de son denotatum humain : on prendra ici pour exemple les « dance floors » dans Second Life qui s’arrogent (certes, après demande) le contrôle presque total de l’avatar. Quoi qu’il en soit, que deviendrait ce signifiant numérique dans cet univers factice, s’il n’était pas programmé, puisqu’il n’a nul besoin, nulle contrainte, nulle obligation, nulle volonté ? Lui faire abandonner son contrôle (qu’il ne possédait de toute manière pas en propre), c’est le réifier en parfait exutoire d’une déviance programmatique du concepteur de l’artefact qui, par là même, masque la part peu avouable de sa tendance coupable à la programmation de l’humain. Libérer l’utilisateur en asservissant son avatar ! Un magnifique slogan, mais… Quand on peut tout programmer, de l’avatar, de l’architecture, de simples objets, de l’espace même, ou plus exactement de l’environnement, a-t-on fini de programmer l’utilisateur humain ? Ou est-ce au contraire une manière pernicieuse de resserrer les mailles du filet que l’on jette sur sa conscience d’être au monde (mais quel monde ?) et d’y agir librement (au sens que Bergson donnait à cette expression) ?

S’il est encore trop tôt pour se prononcer sur le cas de l’architecture virtuelle en général, l’exemple des univers numériques ludiques payants (où il s’agit parfois de provoquer une sorte de dépendance chez l’utilisateur) devrait ne pas nous faire oublier qu’il reste encore à définir une déontologie particulière pour l’architecte du virtuel.

Conclusion

Nous pouvons avancer sans trop de risques que la programmation de l’architecture virtuelle soulève autant de questions (pour ne pas dire de potentiels) que de réponses, ce qui la différencie spécifiquement et concrètement de sa soeur jumelle, la programmation architecturale.

Si elle présente certaines similarités avec une démarche traditionnelle, la programmation architecturale de l’architecture virtuelle s’en démarque aussi par la nature des problèmes soulevés et par l’originalité des réponses pouvant y être apportées. Pour ne citer que deux aspects, l’absence d’environnement physique (gravité, perturbations climatiques) et la possibilité de programmer informatiquement les espaces conçus nous placent dans des conditions tout à fait originales. Il semble alors totalement naturel, dans ce nouveau contexte, de définir de nouvelles fonctions pour les bâtiments. Si la nature d’abri physique n’est plus vraiment pertinente, que peut-on proposer comme caractéristiques d’un « abri numérique » ? Il s’agirait donc ainsi d’identifier les atteintes, gênes, malaises, agressions que peut induire un univers numérique, et d’imaginer des solutions architecturales pouvant les atténuer. Cet exercice sera sans doute nécessaire si l’utilisation de ces nouveaux univers se généralise et se banalise. Si, comme on peut le penser, la prochaine génération de systèmes d’exploitation d’ordinateurs fait une utilisation intensive de la 3D (en suivant une évolution qui part de la ligne de commande pour arriver actuellement au « bureau » et à ses icônes bidimensionnelles de dossiers et de fichiers), la question se posera sans doute avec insistance. Au problème de programmation informatique de ces fonctionnalités, se superposera aussi la question de la programmation architecturale de l’abri (« home ») de l’utilisateur, de son bureau, de ses périphériques, de ses serveurs connectés (« l’environnement »), etc. Et là, les aspects de robustesse, d’ergonomie et d’esthétique de ces interfaces tridimensionnelles revêtiront une pertinence qu’ils ne possèdent pas toujours dans les univers ludiques. La programmation architecturale de ces architectures virtuelles reste encore à inventer.