Multi-modèles coopératifs pour une instrumentation informatique du projet architectural et urbain

HAL Id: hal-03102133

https://hal.archives-ouvertes.fr/hal-03102133

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Multi-modèles coopératifs pour une instrumentation

informatique du projet architectural et urbain

Régine Loisel

To cite this version:

Régine Loisel. Multi-modèles coopératifs pour une instrumentation informatique du projet archi-tectural et urbain. [Rapport de recherche] 0969/97, Ecole Nationale Supérieure d’Architecture de Normandie; Laboratoire informatique de Rouen (LIR); Institut National des Sciences Appliquées de Rouen-Normandie; Bureau de la recherche architecturale (BRA). 1996, pp. 48. �hal-03102133�

E C O L E D 'A RC H ITECTU RE DE N O RM AN D IE 27 rue Lucien Fromage, 76160 DARNETAL

LIR - IN SA R O U EN PI. E.BIondel, Mt St Aignan

u

6 S ( ' S . f

tSo (

MULTI - MODELES CO O PERATIFS POUR UNE

IN STRU M EN TATIO N

IN FO R M A T IQ U E

DU P R O JE T A R C H IT E C T U R A L ET URBAIN

RAPPORT FINAL

O cto b re 1996

Régine LOISEL,

A rc h ite c te DPLG,

D o cte u r 3 èm e c y c le en Inform atique,

Professeur 2 è m e classe-E.A .N o rm a n d ie

Multi - M odèles Coopératifs pour une instrumentation

informatique du projet architectural et urbain

Un modèle est c e qui unit la science et l'imaginaire parce qu'il est un produit de /'imagination passion­ née plus que de /intuition de vérités évidentes comme peut-être le croyait Descartes

Pau! Caro

ECOLE D’ARCHITECTURE de VERSAILLES

Centre de C 'urr ‘- ‘ion

5, av. de Sceaux - L.! .674 '

78006 VERSAILLES CEDEX

Tél. 01 39 07 40 02 Fax 01 39 07 40 04

In tro d u c tio n

3

P en ser un outil in fo rm atiq u e p o ur A rc h ite c te 4 Un c a d r e pour construire d e s m o d è le s 6 U ne d é m a r c h e a s s o c ia n t A cquisitio n d e C o n n a is s a n ­

c e s e t e x p é rim e n ta tio n in fo g ra p h iq u e 7

M o d é lise r les a s p e c t s c o g n itifs d e l'outil d a n s u n e a p p r o c h e 'A cq u is itio n d e C o n n a is s a n c e s '

A n a ly s e d e l'A ctivité d e l'expert: le tra va il d e l'Archi­

t e c t e 11

Le travail sur le co n ce p t Des moyens pour penser D ém arche, projet. Im age

Les m o d è le s co g n itifs d e l'expertise p artie lle 15 Les trois modèles fondam entaux

Im portance du ca s traité

Structurer e t recueillir la c o n n a is s a n c e ] 8

M o d é lise r les a s p e c t s in fo g ra p h iq u e s d e l'outil d a n s u n e a p p r o c h e e x p é rim e n ta le

Les m o d è le s existants: a v a n t a g e s e t in co n v é n ie n ts 21 La modélisation géom étrique traditionnelle

la modélisation descriptive La modélisation objet la modélisation acte u r

La modélisation d éclarative de scènes

Proposition d e m o d élisatio n in te rp ré ta tive p a r a g e n ts

protéiform es 24

Sim ulation d 'o p é ra tio n n a lisa tio n 26 Présentation du logiciel: Topofil

Adéquation à la modélisation proposée

M o d é lise r la c o o p é ra tio n

31

D e l'Outil à l'O util-Partenaire 32

Le M o d è le C o n c e p tu e l d e C o o p é ra tio n 33 Le m odèle d e partag e des savoirs

Le modèle d e partag e du travail Le modèle d e dialogue P e rs p e c tiv e s : le p ro je t M O P IA 37 P u b lic a tio n s 39 C o lla b o ra tio n s 40 B ib lio g ra p h ie 41 O u v ra g e s g é n é ra u x R é fé re n c e s b ib lio g rap h iq u e s 2

Pendant longtemps, les artistes ont c ré é et réalisé les outils nécessaires à l'expression d e leurs sensibilités au sein m êm e d e leurs ateliers, souvent de manière empirique, mais égalem ent en intégrant, en "s'appropriant" les con­ naissances scientifiques de l'époque,

A v e c l'apparition d e l'ère industrielle les savoir-faire technologiques échap p ent à la maîtrise des artistes, iis leurfaut apprendre à énoncer de faço n explicite leurs besoins pour obtenir un outil conform e à leurs attentes.

Lorsque l'informatique à la fois savoir scientifique et savoir-faire technologique se dévelo p p e, c e tte coupure entre créateur et co n cep teu r d'outils s'élargit du fait d e la sophistication des connaissances tant pratiques que théoriques à mettre en oeuvre pour être opérationnel,

Mais "l'artiste, e t l'artiste seulem ent sera susceptible d e donner une âm e à

c e s artifices, p ro cé d é s ou ingrédients (J-M Philippe).

PENSER UN OUTIL INFORMATIQUE POUR ARCHITECTE

L'Architecture est une discipline artistique. Pendant ie travail d'élaboration du projet l'Architecte associe réflexions théoriques et manipulations opératoires pour parvenir à donner forme, structure et mesure à des objets architecturaux qui n'existent pas. Il utilise des figures, des dessins, des schém as, des collages, toutes sortes de "traces dessinées”, des "images", des m aquettes.... réalisés à l'aid e à la fois d'outils conceptuels et d'outils concrets de représentation pour m ener à bien son travail de co ncep tio n. Par conception, il faut entendre: une activité créative, innovative, au sens d e Brown et C handrasekaran, qui distin­ guent l'activité de conception innovative (on ne connait pas à l'avan ce les stratégies et les connaissances) de l'activité d e conception routinière (à partir d'une solution "approchée" on ch e rch e une satisfaction des contraintes, des exigences spécifiques,etc,..),(B& Ch88).

C 'e st pendant les années 60 que les premières expériences d'utilisation d'outils "informatiques” en Architecture ont eu lieu. Elles ont souvent été le fait d'êtres "hybrides" mi-architectes, mi-informaticiens. C es premières tentatives se sont fondées sur des modélisations m athém atiques utilisant des m éthodes dévelop­ pées en logique, en recherche o p érationnelle.... Sur le plan graphique, le plaisir de l'exploit technique qui consistait à réussir à faire produire des "dessins" sur un é cran a enthousiasmé quelques-uns tout en d éco u rag eant les autres du fait d e la m édiocre qualité plastique des im ages obtenues.

L'évolution des matériels, l'explosion com m erciale et les impératifs économ i­ ques ont évincé ces expérimentateurs des "temps héroïques" et fait proliférer les logiciels réalisés par des spécialistes de l'informatique, souvent peu au fait de la pratique artistique de l'Architecte. Ils ont privilégié la réalisation de c e que nous appelions des "images contractuelles" (plans, co up es, fa ç a d e s , axonométries et mêm e images de synthèses photoréalistes), proposant ainsi des outils qui ne visent qu'à la reproduction des gestes artisanaux de la planche à dessin, des "metteurs au propre" en quelque sorte. Ces logiciels permettent des gains substanciels en efficacité et en précision dans la production des docum ents d 'ag ence. Mais, leur emploi dans la phase initiale d e conception

se révèle inadap té et m êm e dangereux c a r il conduit à mesurer avan t d'im aginer, à assembler avan t d e créer, à com m uniquer avan t d e concevoir, en introduisant la précision, le détail et la mesure p endant l'ap p ro ch e conceptuelle qui implique ia gestion du flou, d e l’ambiguité et de l’incertitude, Parallèlement, des recherches pour rendre les m achines plus "intelligentes" ont été entreprises à l’initiative de chercheurs-architectes ou de chercheurs en Intelligence Artificielle. Les systèmes experts d e première génération ont fait la preuve de leurs limites. Les systèmes de seco n d e génération ou Systèmes à Base d e Connaissances (S.B.C.) offrent d e meilleures perspectives. Mais là encore les principales réalisations se p réo ccup ent seulem ent d ’améliorer les conditions d e représentation du projet lorsque sa définition est d éjà assez précise.

La problématique d e cette re ch erche est d ’essayer de définir un système informatique qui permettent d’apporter une aid e à l’A rchitecte dès le début de son travail, dans la phase initiale de conception.

La pratique graphique de l’A rchitecte étant consubstancielle à sa m éthode de co ncep tio n, le système à construire doit associer la gestion des connaissances avecdesfonctionnalitésgraphiques. Il doitpouvoir coopérer a v e c le concepteur afin d e produire des images qui auront vocation à faciliter le chem inem ent de sa pensée et à lui faire appréhender l’e sp a c e , en totale co h éren ce a v e c sa d ém arch e créative et le ou les systèmes d e représentation qu’il aura choisis. Il ne s'agit pas de tenter d'automatiser les tâch es d e l'Architecte, mais d'exploiter la com plém entarité d e l'intelligence humaine et celle du système artificiel, en quelque sorte de cré e r un "outil-partenaire".

Le système doit être co nçu com m e un véritable " outil d e création quin 'ira plus

dans le sens d'une simple amélioration d u préexistant, mais dans le sens d'une véritable révélation." (Phi94)

Pour "penser" c e t outil, il est nécessaire d e construire des m odèles, le terme étant bien sûr utilisé ici au sens scientifique (une abstraction qui permet de réduire la complexité réelle d'un problèm e en se co ncentrant sur certains asp ects) et non au sens d ’archétype.

U N

CADRE POUR CONSTRUIRE DES MODELES

Les pratiques modéllsatricessont enracinées dans l'histoire profonde de l'huma­ nité. Les méthodes analytiques se sont affirmées com m e seules garantes de l'objectivité dans la com m unauté scientifique jusqu'à l'ém ergence des dém ar­ ches d e modélisation systémique g râ c e aux travaux de N.Wiener (théorie de la cybernétique 1948), L.Von Bertalanffy (théorie des systèmes ouverts et des systèmes généraux 1951), J.P iag et, HA.Simon et E.Morin. C ette nouvelle appro­ c h e cognitive s'impose du fait d e l'inadéquation des méthodes analytiques à modéliser les phénomènes com plexes (à ne pas confondre a v e c compliqués) pour construire leur intelligibilité, c'est à dire pour com prendre, donner du sens. Elle substitue le processus à l'objet, le systèm e à l'ensemble, la conception à l'analyse, l'organisation à la structure, la pertinence à l'évidence... .Si on se réfère au G rand Robert, "c'est avant tout une attitude, un éta t d'esprit voire un a rt.

C e tte manière de concevoir la modélisation est a d a p té e à la complexité du processus de conception architectural qui nécessite de prendre en com pte: - la subjectivité du modélisateur qui construit simultanément sa d ém arche et ses représentations

- les aspects multidimensionnels et pluridisciplinaires du processus - le flou, l'incertain et l'aléatoire

- la relation a v e c l'environnement, la relation entre les parties et le to u t....

Nous suivrons la voie constructiviste (il faut entendre "constructivisme" dans le sens "invention de la réalité" com m e le co nço it P.WatzIawick (W&al88)), c a r

o b jectif n'est p a s d e découvrir une vérité existante extérieurem ent aux acteurs impliqués dans ie processus mais d e construire un je u d e d é s qui leur ouvrira d e s p o rte s e t leu r p erm ettra d e chem iner, d e p ro g resser conform ém ent à leurs objectifs e t à leurs systèm es d e valeurs. (Roy90)

Les modèles que nous allons construire dans c e t esprit doivent nous permettre d'imaginer et de spécifier un "outil-partenaire" doté d e fonctionnalités graphi­ ques offrant à l'Architecte un outil réellem ent efficient en phase initiale de conception.

UNE D EM A RCH E A SSO C IA N T A CQ U ISITIO N DE C O N N A IS­

SA N C ES ET EXPERIMENTATION IN FO G RA PH IQ U E

L'outil-partenaire que nous souhaitons construire à term e doit posséder: - une intelligence qui pourra être acquise par l'adjonction d'un Système à Base d e Connaissances

- une aptitude à produire des images g râ c e à des techniques infographiques - une propension à coop érer a v e c l'utilisateur.

Mais peut-on vraim ent utiliser le terme "coopération" pour définir certains types de rapports Hom m e/M achine?

L'utilisation d e termes anthropomorphiques pour parler des ordinateurs est fréquent et provoque souvent un faux d é b a t , il suffit d e penser à "cerveau électronique", "intelligence Artificielle", mots m alheureux s'il en fut.

L'utilisation de "coopération", "partenaire" participent d e ce tte ambiguité. Nous utilisons "coopération" au sens défini par la com m unauté C O O P, groupe de recherche pluridisciplinaire fondé il y a environ cinq ans et qui se consacre essentiellement à la modélisation d e la coopération hom m e-m achine dans le ca d re des Systèmes à Base d e Connaissances.

La coopération se distingue de l'aide, c a r elle nécessite l'utilisation d e connais­ sances. Elle ne se confond pas a v e c l'interaction et ne se limite pas à la réalisation d'une interface plus ou moins conviviale. Elle contribue à l'efficacité et à l'approfondissement d e la réflexion d e l'utilisateur qui doit adopter une attitude active.

Pour réaliser effectivem ent ce tte coopération, il faudra dépasser le "paradoxe d e la conception centrée utilisateur" (Zac93) qui peut s'énoncer ainsi: " le

m odèle d e l'activité d'un utilisateur défini avant l'introduction du systèm e n e p e u t pas, p a r principe, co ïn cid er a v e c ïa ctivité effective une fois le systèm e mis en p la ce . ''

Le système ne pourra donc pas être spécifié en une seule fois. Il devra se développer par é tap es, par une série d e raffinements successifs, mêlant aspects cognitifs et logiciels, afin d'observer les modifications induites par

l'utilisation d'un nouvel outil, modifiant elles-mêmes l'outil en gestation.

La d ém arch e que nous proposons consiste à explorer deux directions de travail com plém entaires:

- l'une plus théorique utilise les co ncep ts et les ressources d e la discipline "Acquisition de Connaissances" afin d'essayer d e d ég ag er les caractéristiques fondam entales d'un Système à Base d e Connaissances" associé

- l'autre plus expérim entale s'appuye sur les ressources du génie logiciel en matière d'infographie.

C ette manière d e procéder doit nous permettre d e jeter les bases d'une mise en oeuvre progressive d'un environnement logiciel incom plet dont l'utilisation entraînera la reformulation des modèles initiaux c a r tout nouvel outil introduit des activités méta-fonctionnelles qui induisent d e nouveaux savoirs et savoir- faire. D'autre part, l'étude des interactions d e l'utilisateur a v e c cette préfiguration sommaire du système donnera les moyens d e préciser la modélisation de la coopération dont nous ne pouvons qu'esquisser les grandes lignes.

Après avoir montré com m ent dans une phase exploratoire:

- modéliser les aspects cognitifs de l'outil dans une app roche "Acqui­ sition d e Connaissances"

- modéliser les aspects infographiques de l'outil dans une app roche expérim entale

- modéliser la coopération,

nousconciueronssurla manière d e poursuivre la définition itérative et interactive de ce s différents modèles mis en é vid e n ce pour aboutir à la com plète Modélisation d'un Outil-Partenaire pour A rchitecte (Projet MOPIA).

MODELISER LES ASPECTS COGNITIFS DE L'OUTIL DANS

UNE APPROCHE "ACQUISITION DE CONNAISSANCES"

L'acquisition d e connaissances est désormais considérée com m e un processus de modélisation (Ste90), (AKS92), (WSB92), (Erc95) et non com m e une activité de transcription d'expertise; on n'imagine plus que la connaissance existe en tant que telle dans la tête de l'expert. On essaie de construire une abstraction structurée explicite des processus du m onde "réel".

De nombreuses recherches et tentatives d e conception de Systèmes à Base de Connaissances (SBC) ont mis en é vid e n ce quatre étapes nécessaires à la réalisation d'un système (AKS92):

- l'acquisition de connaissances dirigées par les données, phase initiale du processus d'acquisition de connaissance pour définir une Expertise Partielle - la construction d'un Schém a d e Modèle C o n cep tu el, c'est à dire d'un ca d re pour exprimer et représenter les connaissances, pour conceptualiser l'expertise à modéliser

- l'instanciation du schém a d e m odèle co ncep tuel aboutissant à la définition du M odèle C o n cep tu el, dont on exige une certaine pertinence "cognitive" - l'opérationnalisation du Modèle C oncep tuel.

Dans le but d e construire le Schém a de Modèle C oncep tuel correspondant à notre problém atique, pour com prendre l'objet du travail d e co ncep tio n, la d é m arch e d e création (toujours à forte com posante personnelle), les connais­ sances mises e n je u ... nous allons d'abord décrire l'activité d e l'Architecte. Puis nous expliciterons et justifierons le choix des modèles cognitifs retenus pendant l'expertise partielle, avan t de proposer une manière de décrire la connaissance par un réseau d e com posants dialogiques qui peuvent éventuellem ent être appris.

ANALYSE DE L'ACTIVITE DE L'EXPERT

:LE TRAVAIL DE L'ARCHITECTE

L'Architecture ayant une dimension artistique importante, il est normal que le vo cab u laire et les conceptions qui s'y référent soient nombreuses, variables et conduisent à des débats passionnés, polémiques et parfois m êm e violents. Les options retenues et explicitées ici sont bien sûr partiales c a r nous nous situons dans un courant artistique et dans un type de dém arche particulier correspon­ d an t à une certaine faço n de voir le monde. Bien qu'un grand nombre d'Architectes envisagent actuellem ent leurtravail de c e tte m anière, le système que nous envisageons de construire devra nécessairem ent permettre à c h a ­ que utilisateur une personnalisation et une prise en co m p te d e ses spécificités

LE TRAVAIL SUR LE CONCEPT

A vant d e pouvoir donner mesures et définitions formelles e xa cte s aux éléments à créer, il est indispensable d'avoir réalisé tout un travail en am ont que nous appelons "travail sur le concept" et qui consiste à faire ém erger du programm e une idée fondatrice qui va servir de ligne directrice à la re ch e rch e d e la mise en forme spatiale.

C e tte idée constitue par la suite le crible par lequel doivent passer tous les choix de l'A rchitecte dans une "dém arche raisonnée" pour faire ém an er la form e, les e sp a ce s et leur organisation.

Pendant ce tte première phase de création et d'exploration du c o n c e p t pour aller vers sa spatialisation, l'Architecte utilise toutes les ressources offertes par le texte, le dessin, la m aquette ... pour faire progresser son travail en explorant et exprim ant son imaginaire. Il ado p te différents points d e vue (esthétique, constructif, spatio-temporel fonctionnel...) pour construire l'e sp a ce architectural à travers sa représentation par une série de manipulations et d e simulations ne figeant pas trop rapidem ent le projet dans une réalité physique plausible dont le réalisme pourrait d éco u rag er la dém arche conceptuelle.

L'Architecte se trouve donc en perm anence confronté au problèm e de "représentation". Il a besoin de "moyens pour penser".

DES MOYENS POUR PENSER

Lorsqu'il utilise les m édia que sont les "images " et les m aquettes, l'Architecte choisit son système de représentation: un m ode d e construction d'une repré­ sentation qui correspond à une façon de voir le m onde, une "prise déposition

théorique p a r rapport à l'objet à représenter (For84)", pour exprimer la

sém antique associée à son co ncep t.

Nous appelions "images contractuelles" les représentations du projet utilisées pour com m uniquer les éléments physiques d e sa matérialisation en vue d e sa construction. Il s'agit des plans, coupes, fa ç a d e s, docum ents fortem ent form a­ lisés et répondant à un co d e tout à fait précis et universellement ad o p té . C e sont celles que le grand public connait, mais elles sont réalisées en général quand le projet est presque terminé.

D'une toute autre nature sont les "images conceptuelles". Elles prennent de multiples formes et ont pour rôle d'aider à la spatialisation du co n ce p t. L'Architecte peut inventer de nouvelles règles d e projection, il peut réorganiser les co d e s pour exprimer la sém antique associée à son co n c e p t, il n'est plus lié par la nécessité d'une adéquation entre son système d e représentation et la norme servant de référence à la société dans laquelle il vit, C es im ages visent à figurer la d é m arch e, la pensée architecturale a van t l'objet, elles doivent être " b a sé es sur des illusions cognitives-com m e ia vie - e t non plus sur d e s illusions

p ercep tiv es com m e c'est ie ca s en co re m a in te n a n t(Les94).

Il n'y a pratiquem ent pas de logiciel perm ettant la production d e telles images. Toutefois, nous utilisons depuis plusieurs années deux logiciels: IKOlight de Michel Bret (CLL91), (Por93) et Topofil d'Yves Bertrand (LBM96) qui nous perm et­ tent d'avoir une production graphique fructueuse dès le début du processus de travail sur le c o n ce p t m oyennant un certain "savoir-faire", qui tient pour partie d'aptitudes qu'on peut rapprocher de la "métis" des grecs (forme d ’intelligence et d e pensée qui implique un ensemble de com portem ents intellectuels qui com binent le flair, la sag acité , la prévision,la souplesse d ’esprit... des habile­ tés diverses, une expérience longuement acqu ise... (D&V78)).

De m êm e, les m aquettes de travail (ou m aquettes conceptuelles que nous opposons aux m aquettes de com m unication réalisées lorsque le projet est totalem ent co n çu ) construites par l'Architecte pendant c e tte phase initiale ont pour but d'indiquer " sans forfanterie ia conception dont elles sont représen­

tatives, plutôt que la vraisemblance d'une perception illusoire" (Bou89).

Elles apparaisent souvent construites "de bric et d e broc ", assem blages de bout d e ficelles, de carton, d e m atériaux de récupération, ... incompréhensibles parfois pour le profane, mais en fait très construites, c h a q u e m atériau choisi a v e c précision et bien a d a p té aux besoins de représentation ressenti par l'Architecte.

Il y a un rapport très charnel qui s'établit entre la matière et la main qui travaille. C'est sans doute la perte de c e t asp ect tactile qui constitue le principal inconvénient de l'utilisation d'une m aquette informatique, c'est à dire d'une simulation des " conditions d e production d'un visible en co re informulé' (Qué86) sur un é cra n à l'aide d'un système informatique.

La création d'une m aquette informatique suppose d e savoir construire un m odèle ad é q u a t du projet en gestation et de disposer d'un logiciel perm ettant sa concrétisation sur l'écran de l'ordinateur, c e qui n'est pas toujours évident (remarquons au passage que la production d'images informatiques est souvent issue d'une modélisation 3D et que ia distinction im age/m aquette s'estompe). M oyennant quoi, la m aquette informatique présente des avan tag es non négligeables en terme d e déformabilité, d'ubiquité (on peut "voir" d e l'extérieur ou de l’intérieur de faço n quasi-instantanée, c e qui n'est pas le ca s pour une m aquette "physique" qui nécessite l'utilisation d'un m aquettoscope pour a p ­ préhender les e sp aces intérieurs a v e c les difficultés d e compréhension de l'échelle qui en découlent), de gestion du détail par rapport à la globalité, de l'historique d'évolution (dans le temps et l'esp ace d e co ncep tio n), de la multiplicité des points de vu e (abstrait, géom étrique, fonctionnel, constructif...).

DEMARCHE, PROJET, IMAGE

L'Architecte, dispose d 'u ne culture, de connaissances antérieures diverses, de savoir-faire... et de l'aptitude à utiliser un m édia cognitif particulier: l'im age, pour résoudre le problème de conception posé dans le projet.

Le projet est une entité incrém entale qui correspond à l'état de la conception à un mom ent donné. Au départ il s'agit des éléments du program m e, puis petit à petit va se forger le c o n c e p t qui se construit à travers les manipulations, puis l'ém anation du co n ce p t dans une forme spatiale de plus en plus précise. Pour c e la , le co ncep teur utilise un certain nombre d e faits d e culture, de références personnelles fruits d'une re-conceptualisation et non d e

ques d e formes pré-établies. Parallèlement, il construit des outils, ou des utilisations particularisées d'outils existants afin de pouvoir réaliser les images conceptuelles sém antiquem ent typées qui vont lui permettre de faire a v a n c e r sa réflexion.

On peut schém atiser ainsi les inter-relations qui se développent (fig 1):

architecte

outils

images

füg J : Rôle des images dans le processus d e projet

LES MODELES COGNITIFS DE L’EXPERTISE PARTIELLE

Il ya quelques années, on aurait voulu mettre "la tête de l'Architecte dans la m achine" dans l'espoir d'automatiser la conception! Devant la faillite de ce tte ap p ro che on ch erch e plutôt aujourd'hui à construire un système qui puisse fournir une aide cognitive à la conception, par exem ple en aidant à construire des im ages pour faire a v a n c e r le processus de pensée. C e qui nous a m èn e à opérer les regroupements suivants (fig 2):

architecte

_outils

_images

fig 2 : Mise en valeur des différents m odèles cognitifs

LES TROIS MODELES FONDAMENTAUX

Nous appellerons m odèle créatio nnel (A) les connaissances d e culture, les questionnements et l'état de la création à un mom ent donné (c 'e st à dire l'état du projet et les images déjà créées), dans le contexte particulier du projet en cours.

L ensem ble des principes d 'action intelligente, des savoir-faire qui perm ettent d imaginer, de susciter et d 'évaluer des opérations cognitives et pratiques a d a p té e s au projet seront exprimés dans le m o d èle d écisionnel (B).

On introduit la notion de m odèle instrumental (C ) pour décrire l'ensem ble des procédés et moyens à mettre en oeuvre pour la réalisation des images conceptuelles qui serviront à alimenter le m odèle créationnel via la médiation du m odèle décisionnel.

Nous retiendrons d onc le schém a organisationnel suivant (fig 3):

B

fig 3 : Organisation des m odèles cognitifs

C es modèles ne sont pas des entités figées, mais au contraire des entités dynam iques qui évoluent au fur et à mesure d e la progression du travail de conception, et en fonction du projet étudié.

On peut donc considérer qu'ils se construisent d e faço n incrém entale à partir d 'u ne base initiale d e connaissances que nous appellerons noyau.

Dans le ca s du m odèle créationnel, il peut s'agir d'un certain nombre de faits culturels, artistiques, techniques, philosophiques...qui sont fondam entaux du point d e vue du créateur. Dans le cas du m odèle décisionnel, il peut s'agir de m éthodes de raisonnement, d'heuristiques, d'habiletés qu'il utilise fréquem ­ ment dans sa d ém arche. Le noyau du m odèle instrumental peut être constitué par le m odèle associé à un logiciel existant dont l'usage pourra être «détourné».

Le m odèle créationnel va s'augm enter des données relatives au program m e, et g râce à la mise en mouvement du modèle décisionnel, le m odèle instrumental v a s'enrichir et produire des images qui viendront alimenter le modèle créationnel, et le processus se répétera jusqu'à la définition com plète du projet,

IMPORTANCE DU CAS TRAITE

Nous avons vu que les processus mis en oeuvre sont com plètem ent déterminés par le «projet» à étudier et à réaliser, Nous nous situons d onc en a c co rd a v e c le point d e vue de (Ste90), (VdV93), (K&G95) qui reconnaît la p la c e importante tenue par la notion d e «cas traité» dans les approches d e la modélisation au niveau connaissance.

Nous nous inscrivons d o n c dans le schém a général (K&G95) (fig 4)

fig 4 : Architecture au niveau connaissance

Les connaissances du c a s traité se trouvent à la fois:

- dans (A) sous la forme des différents avatars du projet et des im ages - dans (B) sous la forme de la d ém arch e ad o p té e pour le projet

- dans (C ) sous la forme des modèles des images d e projet et du système de représentation choisi.

Les connaissances du dom aine se trouvent à la fois:

- dans (A) sous la forme du noyau de base augm enté des connaissances propres à l'expert

- dans (C ) sous la forme du noyau de base et des savoir-faire d e l'utilisation pratique des différents outils.

Les connaissances de stratégie sont dans (B) sous la forme du noyau de base augm enté des connaissances propres à l'expert.

STRUCTURER ET RECUEILLIR LA CONNAISSANCE

Le c a ra c tè re com plexe de la conception architecturale nous am è n e à penser

“sans jam ais d o re les co n ce p ts, briser les sphères d o se s: rétablir les articu­ la tio n s e n tre c e q u i e s t d isjo in t, e s s a y e r d e c o m p r e n d r e ia multidimensionna/ifé, d e p en ser a v e c ia singularité, a v e c ia localité, a v e c ia tem poralité, n e jam ais oublier les totalités intégratrices." {Mor91)

Dans notre problém atique, la connaissance est essentiellement un phéno­ m ène culturel qu'on ne peut réduire à quelques primitives, mais au contraire que l'on considère dans une perspective interprétative s'exprim ant en termes d e com posants (B&C93). Ces composants sont des élém ents provisoires per­ m ettant de décrire des connaissances en constante réélaboration en fonction du co ntexte. Ils se structurent en une organisation com plexe s'auto-définissant. C es élém ents ne prennent valeur de représentation q u 'à partir du m om ent où un interprétant leur attribue un sens.

Les notions et les relations mises en jeu sont tout à la fois com plém entaires, concurrentes, antagonistes et incertaines, c e qui implique d e préserver un principe dialogique qui “consiste à faire jo u e r ensem ble d e fa çon co m p lé­

m entaire d e s notions qui prises absolum ent seraient antagonistes e t se rejetteraient les unes les autres.'{Mor91)

LES ARCHI-GRANULES DIALOGIQUES

Nous appellerons archi-granule dialogique, un com posantdialogique, perm et­ tant d e prendre en com pte la com plexité d e la co nnaissance à représenter. C e com posant doit servir à décrire des propriétés topologiques, physiques, subjectives, poétiques, stratégiques... des possibilités d 'a ctio n , d'interaction et de dialogue. Il peut être utilisé pour exprimer à la fois des connaissances du dom aine, du c a s traité et du contrôle.

L'ensem ble des archi-granules constitue un réseau dynam ique com m uniquant dans lequel l'Architecte est représenté par un archi-granule particulier, le super- archi-granule qui a vocation à gérer la globalité.

Les archi-granules perm ettent de stocker des connaissances en naviguant dans leur réseau (fig 5) en fonction des besoins révélés p endant le processus d'élaboration du projet. Ces connaissances sont soit des connaissances du cas traité, ou des connaissances du dom aine, ou des connaissances stratégiques ap p artenan t aux modèles créationnel, décisionnel ou instrumental. Il n 'y a pas de chem in à priori pour recueillir les différents types de co nnaissance. Les archi- granules évoluent en fonction des besoins et peuvent être créés à tout moment si nécessaire. Le recueil d e ces connaissances peut se faire d e fa ç o n d éclarative ou en utilisant des techniques d'apprentissage (CLL90).

fig 5 : Exemple d'une partie du réseau organisé autour d e idrchi-granule BAIE

MODELISER LES ASPECTS INFOGRAPHIQUES DE

LOUTIL DANS UNE APPROCHE EXPERIMENTALE

LES M O D E L E S EXISTANTS:AVANTAGES ET INCONVENIENTS

Les modèles exploités dans les logiciels de CAO-DAO ont pour fonction essen­ tielle de décrire des scènes tridimensionnelles dont on pourra donner différentes visualisations. Nous allons rappeler rapidem ent leurs caractéristiques en m ettant en é vid e n ce leurs potentialités à servir ou non notre propos.

LA MODELISATION GEOMETRIQUE TRADITIONNELLE

Les élém ents géométriques sont représentés par des ensembles d e points de l'esp ace euclidien R3 . On considère généralem ent:

- les modèles surfaciques où les éléments sont définis par des ensembles de m orceaux de surfaces polyédriques ou de surfaces gauches telles que B-Spline, nurbs, courbes et carre au x de Bezier, B-surfaces. (bien qu'on considère en général que ces modèles sont de type B-rep, nous les distinguerons c a r en général leur structure topologique est mal définie)

- les modèles volumiques parmi lesquels le m odèle C SG (Constructive Solid G eom etry) dans lequel les éléments sont définis à partir d'élém ents volumiques simples (les primitives) et d'opérations booléennes (union, intersection, diffé­ rence).

La simple saisie d e la géom étrie des éléments architecturaux implique une co nnaissance déjà importante d e c e qui est à représenter. C ette nécessité de donner mesure et forme est une contrainte qui s'avère en général fâcheusem ent réductrice lorsqu'elle intervient au début du processus créatif c a r elle enferm e le co n ce p te u r dans un réalisme physico-optique qui peut bloquersa d é m arch e conceptuelle.

LA MODELISATION DESCRIPTIVE

Les modèles dits de représentation par les bords (boundary représentation ou B-Rep) permettent la séparation entre les aspects topologiques et les aspects purem ent géométriques (plongem ent dans Rn) d'un solide. La définition d'un

élém ent nécessite la construction d'un m odèle topologique auquel on associe un m odèle d e plongem ent (plusieurs plongements peuvent être associés à un m êm e m odèle topologique).

G râ c e au calcu l des caractéristiques topologiques, on peut s'assurer d e la validité du solide construit et réduire les risques d'erreur relatifs aux phénom ènes d'approxim ation (surfaces disjointes au lieu d 'être ad jace n te s par le fait d'approxim ations successives) (Ber92).

L'intérêt principal de cette modélisation est d e respecter les trois niveaux de perception et de représentation de l'esp ace définis par Piaget et Francastel, en co m m e n çan t par la description de l'esp ace topologique qui rend com pte des rapports élém entaires de voisinage, limite, continuité, connexité des figures indépendam m ent de leur forme et de leur grandeur. Dans la suite du processus de pensée aboutissant à un objet architectural, l'Architecte sera bien sûr, a m en é à donner forme et mesure à l'esp ace en m ettant en oeuvre sa "dém arche raisonnée".

Donc, petit à petit, il pourra substituer à l'esp ace initial topologique, l'esp ace projectif (qui s'intéresse au c a ra c tè re de la forme et aux qualités des élém ents), puis l'esp ace euclidien (fondé sur les rapports abstraits de mesure) com m e e sp a ce de représentation.

Com m e c e la peut se faire en définissant un m odèle de plongem ent de l'esp ace topologique dans l'espace euclidien habituel, il n'y a pas à pratiquer d e nouvelle saisie pour faire évoluer la m aquette informatique réalisant ainsi en quelque sorte une animation dans le temps de la conception.

LA MODELISATION OBJET

Un objet se définit à la fois par son état (les attibuts statiques: cham ps ou variables d'instance) et par les opérations qu'on lui applique (les attributs dynam iques: les m éthodes). Tout objet est instance d'une classe. Les classes sont organisées hiérarchiquem ent. La hiérarchie «partie de» (is-part) décrit une décom position autorisant la représentation d'objets compliqués. La hiérarchie «sorte de» (is-a) est une classification autorisant l'héritage des propriétés et des m éthodes. Les intérêts de ce tte modélisation co ncern ent les possibilités d'in­ clure les définitions d 'in terface dans ch a q u e objet, d e ré-utiliser des objets dans d'autres applications, d e simplifier la saisie des données et d e permettre différents niveaux d e définition g râ ce aux propriétés de l'héritage. C ette ap p ro ch e est assez largem ent utilisée dans le dom aine de l'Architecture, Elle

présente de notables avan tag es mais ne peut être totalem ent satisfaisante en phase de conception c a r l'architecture ne peut se réduire à la manipulation d'un légo géant (c e qui est favorisé par l'aspect de décomposition hiérarchique des éléments en sous-éléments).

LA MODELISATION ACTEUR

On peut considérer que le m odèle a cte u r est une extension du m odèle objet (bien qu’il n'y ait pas d'organisation hiérarchique) par ajout d e la notion d'activité. Au lieu de m éthodes, on peut plutôt parler de processus. Elle permet d'intégrer des notions d e com portem ent, de scénario et de scripts qui peuvent évoluer a v e c le temps (on a donc une modélisation temporelle et dynam ique), On construit un e sp a c e , une scène en organisant le rôle de c h a c u n des éléments constitutifs. Elle perm et bien d e prendre en com pte les différents points d e vue exprimés en phase d e conception et en particulier peut gérer des visualisations a d a p té e s à la sém antique proposée par l'observateur,

Le logiciel IKOlight d e M ichel Bret est un exe m p le d'im plém entation efficace(CLL91), qui nous a permis de tester l'intérêt d'une modélisation par formes-acteurs définies par leur support géom étrique et un certain nombre de com portem ents perm ettant en particulier de gérer les affichages en fonction du sens à exprimer.

LA MODELISATION DECLARATIVE DE SCENES

Les éléments de la scè n e sont décrits en én on çant en langage quasi-naturel leurs propriétés ainsi que leurs contraintes de positionnement,

C e tte m éthode perm et de se libérer d e certaines sujétions de saisie, mais il ne faut pas oublier que le passage du mot à l’im age est un problèm e non trivial, dont la com plexité varie en fonction du degré d e schématisation d e l'énoncé et d e la production graphique.

PROPOSITION D'UNE MODELISATION INTERPRETATIVE PAR

AG EN TS PROTEIFORM ES

Nous avons montré dans de précédents travaux (LBM96) qu'il n'existe pas de représentation «neutre» et que ie choix de la représentation d'un e sp a ce architectural est fonction du point de vue ad o p té par le modélisateur. C e qui implique que le co ncep teur devient lui-même un élém ent de l'e sp a ce à représenter. C 'est une conception appréhensive d e l'e sp a ce .

Nous avons plusieurs fois souligné le c a ra c tè re «complexe» d e la conception architecturale qui ne peut se réduire à une organisation hiérarchique et perm anente. Les objets architecturaux eux-mêmes ne peuvent être ap p réhen­ dés com m e une simple juxtaposition de sous-objets ou com m e quelque combinaison de primitives à l'aide d'opérations ensemblistes. Il faut prendre en com pte les aspects topologiques des élém ents et gérer leurs c a p a cité s à se transformer, à modifier leur état local, à cré e r d'autres élém ents, à s'afficher suivant les points de vue du co ncep teur...

Ces nécessités correspondent au co n ce p t générique d'agent tel qu'il est formulé dans (E&F93) ou (L&L93) : "un a g en t p e u t être défini com m e une entité

(physique ou abstraite) ca p a b le d'agir sur elle-m êm e e t son environnem ent disposant d'une représentation partielle d e c e t environnem ent, pou van t com m uniquer a v e c d'autres agents e t d o n t ie com portem ent est ia co n sé­ q u e n ce d e ses observations, d e sa connaissance e t d es interactions a v e c les autres agents

Toutefois il nous semble important de souligner que l'ensemble des agents n'est pas assimilable, pour nous, à un système multi-agents classique c a r nous ne cherchons pas à construire une résolution coop érative de problèm e, c e n'est pas l'interaction des com posants qui peut générer le projet architectural.

Intuitivement et d e fa ço n im agée, on peutd écrire c e type d'agent com m e une structure molle, évolutive, contenant en germ e des m étam orphoses potentiel­ les et tendant des sortes d e pseudopodes pour se liaisonner et inter-agir a v e c les autres agents, c'est pourquoi nous le qualifions de protéiforme.

Autrem ent dit, en utilisant de nouveau, un vo cab ulaire anthropom orphique, on peut considérer qu'il est constitué de quatre parties:

- un "corps" définissant les propriétés topologiques

- un "esprit" contenant des connaissances, des a p titu d e s,.... - une "mémoire" contenant l'historique de son évolution

- des "outils" perm ettant l'action, la connexion ... a v e c d'autres agents,

Le contenu d e ces différentes parties se modifie tout au long d e la d ém arch e: - par l'action de l'Architecte qui les fait évoluer d'un état peu précis vers un état dont la sém antique augm ente et s'affine.

- par les interactions dynam iques qui s'établissent entre agents.

Les agents protéiformes nécessaires à la description des éléments d 'arch itec­ ture à prendre en com pte ne sont pas définis à priori. Ils sont créés à tout mom ent, en fonction des besoins du co n cep teu r, qui peut leur assigner des buts partiels à réaliser (p ar exem ple "déforme toi pour t'ad ap te r à c e t autre composant").

On peut définir un certain nombre de types d'agents protéiformes, par exem ­ ple:

- les agents protéiformes concrets perm ettant d e décrire des élém ents physi­ ques d'architecture (murs, portes, linteaux,...),

- les agents protéiformes abstraits correspondant à des élém ents subjectifs (lisibilité, rythme, passage, transp arence...),

- les agents protéiformes expressifs correspondant à des types d'approches (poétique, m étaphorique, plastique, fonctionnelle....),

- les agents protéiformes stratégiques ayant vocation à contenir les heuristiques, les savoir-faire

- les agents protéiformes réglem entaires...

L'ensemble d e ces agents va évoluer par interactions successives afin de construire une m aquette et des im ages satisfaisantes du projet.

SIMULATION D'OPERATIONNALISATION DANS TOPOFIL

Nous avons vu l'importance de la modélisation à base topologique dans notre d ém arch e.

La plupart des modeleurs classiques n'offrent généralem ent pas a c c è s à la structuration topologique des éléments modélisés. Lorsqu'une telle structuration, existe, elle souffre le plus souvent de trois défauts majeurs: elle est d'une grande com pléxité (une dizaine d'entités topologiques distinctes, interdépendantes est chose courante), les contraintes d'intégrité ne sont pas explicitées, q ue c e soit dans le c o d e du logiciel ou dans sa docum entation, et elle est enfin organisée de manière ad hoc, sans m odèle m athém atique sous-jacent.

Pour pallier à ces graves lacunes, nous avons été am enés à nous intéresser à un m odeleur à base topologique Topofil (BDFL92), (BD94) s'appuyant sur un m odèle topologique app elé les cartes généralisées (Lie89), afin d e satisfaire à nos exigences en matière de topologie.

Après avoir présenté les caractéristiques et les fonctionnalités d e c e logiciel, nous allons montrer com m ent il est possible d'introduire des fonctionnalités supplémentaires perm ettant d'implémenter les agents protéiformes tels que nous venons de les définir.

PRESENTATION DU LOGICIEL TOPOFIL

Topofil est un logiciel qui a été développé au sein du LSIIT (URA CNRS 1871) à l'Université Louis Pasteur de Stasbourg par Yves Bertrand. Il a été mis à notre disposition en é ch an g e d'une collaboration autour de la définition de topologies et plongements adap tés à l'expression de la co ncep tio n architecturale. Topofil est un modeleur dit "à base topologique" p a rce que son raisonnement repose principalem ent sur le modèle topologique que sont les cartes g é n é ra ­ lisées (G -cartes), et que l'information topologique prime sur les autres informa­ tions (forme, couleur, e tc ...) pour des raisons d e sém antique, d 'efficacité et de technique détaillées dans (LBM96), (LE93).

Sa conceptions'app uie surdes spécifications formelles app elées spécifications algébriques, et plus particulièrement à l'aide c e qu'on ap p elle dans c e dom aine: sortes ordonnées(G&M83).

Toute G -carte c'est à dire tout m odèle de la topologie d'un objet peut être définie par un unique type d'élément app elé brin et par un unique type de relation entre ces éléments appelé couture.

L'opération fondam entale de couture (ou d e dé-couture) "fonctionne" d e la m êm e manière que la pratique manuelle qui nous fait assem bler (séparer), coller (décoller) des m orceaux lors d e la construction d'une m aquette physi­ que a v e c des moyens traditionnels. En cousant deux brins, on obtient une arête, plusieurs arêtes entre elles une fa c e , e tc ...

On peut associer à ch aq u e brin ou ensemble d e brins, une ou plusieurs informations de nature quelconque: les attributs.

Un type d'attribut particulier est l'attribut de "plongement géométrique", qui perm et de préciser d e quelle manière on entend plonger le brin, les ensembles quelconques de brins dans l'espace euclidien traditionnel.

Le travail qui se poursuit au sein du LS HT perm et d'étendre le formalisme des G- cartes par un plongement matériel portant aussi bien sur les brins que sur les co utures. Il s'agit d 'asso cier des propriétés (p hysiques, m é ca n iq u e s, "com portem entales"...) à la fois aux brins et aux coutures des G -cartes. (T&L93), (CLF93), (F&L94).

C e niveau matériel ajouté peut être d'ordre quantitatif ou qualitatif. Il permet en particulier de qualifier le type d e liaison entre éléments en sém antisant les opérations de couture qui peuvent être plus ou moins solides tel le bâti, le surfilage, le surjet des couturières pour rester dans la m êm e m étaphore de vocabulaire.

On peut co ncevo ir des fa ce s impénétrables et assez rigides, d'autres plus souples pour ajouter des qualifications de m atière. On peut co n cevo ir et représenter des objets ayan t une arm ature d'arêtes rigides et des fa ce s m écaniquem ent très molles....

L'homogénéité des G-cartes en toute dimension, permet l'adjonction du niveau matériel à toutes les dimensions.

A D E Q U A T IO N A L A M O D E LIS A T IO N P R O P O S E E

Examinons la manière dont on peut traiter les différentes parties d'un agent protéiforme sans perdre de vue qu'il est en perpétuelle évolution en fonction du co ntexte et de ses inter-actions.

A un mom ent donné, on peut définir: - le "corps" par une G -carte

- I"'esprit" par des attributs d e différents types (géom étriques, colorimétriques, m é ca n iq u e s...) potentiellement activables et modifiables (par prise en com pte d e contraintes, par passage d e param ètres entre agents protéiform es....).

- les "outils" à la fois par des attributs de plongem ent (qui perm et leur affichag e pour une visualisation suivant les points de vue retenus par le co n ce p te u r), par des opérations de couture (éventuellem ent sém antisées).

- la "mémoire" par l'utilisation d'un "journal d 'é ch a n g e d e messages", c'est à dire en mémorisant les opérations appliquées entre c h a q u e modification des agents protéiformes (par l'Architecte, ou par un autre com posant), pour perm ettre d e gérer les états intermédiaires des agents protéiformes, c e qui est indispensable pour maintenir la co h é re n ce d e la d é m a rch e , (c a r m êm e si une id ée a été ab an d o n n ée, elle ne doit pas pour c e la aller à la poubelle! elle peut être reprise plus tard, pour être re-visitée).

La construction d'une m aq uette inform atique peut se faire au niveau topologique sans préjuger d e la forme géom étrique (qu’on pourra préciser par la définition des attibuts de plongement géom étrique), et d e la qualité des m atériaux utilisés (qu'on pourra préciser par la définition des attibuts de plongem ent matériel). D'autre part dès qu'un plongem ent est précisé, on peut obtenir une visualisation sur l'écran, en particulier une visualisation axonométrique qu'on peut faire "tourner" très simplement g râ c e à la gestion d'une interface incluant non seulem ent une souris, mais aussi une boite à boutons.

Les opérations de couture permettent d e liaisonner entre eux les agents protéiformes.

C e tte opération de liaison pouvant être sém antisée (attributs d e plongem ent m atériel), c e la permet d e partir de quelques agents protéiformes pour arriver

au bout d e la conception, à un unique agent entièrem ent déterm iné consti­ tuant le projet architectural. Mais on peut égalem ent partir d'un ag e n t très général 0"'espace", le "cube g é n é ra tif, ou m êm e le "site"....), qu'on fragm en­ tera p ar les opérations d e modification de topologie, afin d e parvenir à la définition des éléments constitutifs du projet dans leur inter-relation. Entre ces deux conduites extrêm es on utilise le plus souvent le liaisonnement ou la fragm entation dans une série d'aller et retour.

Il ap p arait donc que la manipulation du logiciel Topofil perm et de juger du bien- fondé d e notre choix d e modélisation par agents protéiformes dans le c a d re d'une d é m arch e co ncep tuelle telle que nous la pratiquons.

Il peut servir d 'é b au ch e à la com posante infographique d e l'outil que nous souhaitons construire.

Il existe deux manières d e concevoir la coopération Hom m e/M achine: soit en "copiant", en reproduisant les modalités de la relation Homme/Homme, soit au co ntraire en faisan t jouer la co m p lém en tarité entre d e u x entités fondam entalem ent différentes (homm e et m achine) puisqu'il m anque, entre autre, à l'ordinateur la sociabilité (Suc87). A l’alternative d'Yves Kodratoff: "l'Intelligence Artificielle, est-ce simuler la tête d e l'Homme dans la M achine ou simuler la M achine dans la tête de l'Homme?", nous répondons résolument oui à la deuxièm e hypothèse. Pour faire faire à la m achine des tâch e s "intelligen­ tes", il faut utiliser au mieux ses atouts spécificiques. C e qui ne veut pas dire qu'il n'y a rien à attendre d e l'étude des comportem ents humains, mais bien qu'il faut savoir les re-visiter en fonction de c e que l'on sait du fonctionnem ent d e la m achine. Il faut penser en term e de com plém entarité.

Dans notre problém atique, c e n'est pas la m achine qui va co ncevo ir, bien évidem m ent. Il ne s'agit d onc pas de tenter d e reproduire la pratique de conception telle que nous l'avons évo q uée, mais de savoir utiliser les c a p a cité s spécifiques à la m achine, pour aider à l'ém ergence du projet.

Remarquons que c e qui peut faire la qualité, l'intérêt de la m achine peut aussi être un h an d icap pour l'utilisateur. Considérons par exem ple la rapidité d'exé­ cution. A priori c'est un a va n ta g e . Mais en fait, le risque est grand d e produire des images trop rapidem ent, sans réflexion, contrairem ent à c e qui arrive a v e c des outils plus traditionnels où l'esprit peut travailler au rythme d e la main. De m êm e si l'on considère la possibilité d'utiliser la puissance com binatoire de la m achine pour une exploration des solutions possibles, on peut penser qu'il s'agit d'un atout important. Mais proposer des solutions sans pouvoir les confron­ ter au c o n ce p t (qu'on ne peut pas expliciter à la m achine c a r il se construit plus ou moins rapidem ent a v e c la manipulation) présente le d an g er d e saturer l'esprit a v e c un trop plein d'information ou de d évoyer la pensée, c e qui est un com ble pour une m achine qui se veut partenaire.

Il s'agit donc d e d ég ag er les modèles élém entaires nécessaires à la construc­ tion de la coopération en évitant c e genre d'écueils et en respectant la d ém arch e du co ncep teur,

DE L'OUTIL A L'OUTIL- PARTENAIRE

Nous avons déjà souligné (cf. p.12) que la pratique des logiciels actuels de D.A.O peut se faire de manière plus ou moins habile de la part de l'utilisateur. Mais d e tels produits restent des outils "sans pouvoir décisionnel", conçus seulem ent pour être manipulés.

Introduire une com posante "intelligente" com m e nous le prévoyons à l'aide d'un Système à Base de Connaissance modifie le rapport à l’outil qui devient une sorte d'extension électronique des facultés intellectuelles et graphiques de l'utilisateur.

Il ne s'agit plus seulement:

- de manipuler des objets mais aussi du savoir

- de faire du transfert d'informations mais d e gérer des actions réciproques - de "cliquer" mais de dialoguer.

Ces transformations fondam entales dans la m anière d'envisager le travail a v e c c e nouveau type d'outil limitent la portée d'une analyse d e l'interaction actuelle entre l'Architecte et la m achine: interaction qui se limite d'ailleurs souvent à la pratique d'interfaces plus ou moins ergonomiques.

Il nous faut donc imaginer c e que pourrait être c e tte coopération non enco re exp é rim e n té e , a v a n t d'en construire, dans une p h ase ultérieure, une préfiguration qui nous permettra d'alimenter le cy c le :

afin d 'a va n ce r dans l'implémentation du systèm e-partenaire souhaité.

Les trois différences fondam entales que nous venons de recenser qui font la différence entre outil et outil-partenaire nous am èn e à définir trois modèles élém entaires pour constituer le Modèle C o n cep tu el de Coopération: le mo­ dèle d e partage des savoirs, le m odèle de partag e du travail et le m odèle de dialogue. Notre app roche s'apparente à celles proposées par (Zac93‘) et (Ros96) en prenant en com pte la spécificité d e la d é m arch e d e conception.

LE MODELE CON CEPTUEL DE COOPERATION

LE MODELE DE PARTAGE DES SAVOIRS

Il n'est heureusem ent plus question actuellem ent d e croire qu'on puisse "rentrer" dans la m achine de faço n exhaustive, toutes les connaissances d e l'utilisateur! Alors quelles connaissances est-il pertinent d e sélectionner, qu'est-ce que la m achine doit savoir de c e que sait l'Architecte? Mais à contrario, qu'est-ce que l'Architecte doit savoir des ca p a cité s de la m achine? Nous croyons que ce tte symétrie entre les deux rôles doit être retenue, m êm e si les deux m odèles qu'il faut mettre en p lace: m odèle d e l'utilisateur ("dans" la m achine) et m odèle de la m achine ("dans" la tête de l'homme) sont de natures différentes. Il n'est pas nécessaire que c h a q u e partie du couple Hom m e/M achine sa ch e tout c e que sait ou fait l’autre, mais il faut qu'il puisse s'en construire une représentation efficiente, c e qui implique un "savoir partagé".

Nous remarquerons d'abord que nous confondons l'expert et l'utilisateur qui sont deux rôles successifs que tient l'Architecte qui va utiliser le nouvel outil- partenaire, suivant en c e la notre point d e vue initial: l'artiste doit "fabriquer" son outil.

Nous voyons que pour construire le m odèle d e la m achine, il y aura à prendre en com pte une partie des expertises qui conduisent à la définition du m odèle instrumental (cf.p, 16), d e façon symétrique le m odèle d e l'utilisateur pourra être nourri par l'utilisation d'éléments du modèle créationnel et du m odèle décisionnel.

LE M O D E L E D E P A R T A G E DU T R A V A IL

Nous utilisons c e terme de préférence à résolution collective d e problème habituellem ent utilisé dans la com m unauté scientifique. En effet, le terme résolution de problème nous parait inapproprié c a r nous avons vu qu'au début du processus d e conception, il n’existe pas de problèm e à proprem ent parlé: on le construit simultanément a v e c la solution (cf. p.13) par une série d e re­ formulations successives,

De m êm e la notion de tâch e au sens habituel du term e est difficile à cerner. Nous utiliserons de préférence l'expression "étapes de travail". En effet, on ne peut prédéfinir des tâch es com m e c e la peut se faire dans des problèm es de diagnostics par exem ple, elles vont naître au fur et à mesure des besoins d e la d é m arch e.

C es étapes d e travail peuvent nécessiter différentes manières d e coopérer: ajustem ent mutuel, supervision directe, standardisation des procédures.... Nous pensons com m e (D&K92) que les allocations de rôle peuvent évoluer en fonction du contexte au cours du processus et que certaines étap es soient traitées uniquement par l'utilisateur.

C e m odèle est particulièrement difficile à co ncevo ir, c a r il met en jeu la maîtrise du processus par l'Architecte. Com m e tous les autres modèles q ue nous avons définis, il devra évoluer a v e c le temps et la pratique effective d e l'outil. Il sem ble raisonnable au début d e restreindre le rôle décisionnel d e la M achine afin de ne pas "effaroucher" l'Architecte qui pourrait craindre d e se voir dépossédé de son libre-arbitre.

LE MODELE DE DIALOGUE

Il englobe et dépasse le modèle d'interface physique. Il doit prévoir les modes de com m unication entre l'Homme et la M achine ainsi que la nature et la forme des informations à échanger. Il doit tenircom pte du fait que l'utilisateur a besoin de co h é re n ce , concision et fléxibilité (Cou90)pour se sentir à l'aise p endant son travail.

m onde abstrait. Nous avons une certaine réticen ce à utiliser les m étaphores habituelles, telles que le bureau popularisé par le M acintosch. Nous préférons avoir recours au langag e afin de garder une plus grande liberté et souplesse d'intervention. C e qui ne veut pas dire que nous refusons fenêtres, icônes et souris, mais il faut savoir quelles peuvent limiter la pensée co n cep tu elle et ne doivent être utilisées en co nséq uence que pour des actions triviales.

L'utilisation d e la multimodalité ouvre des perspectives nouvelles d'interaction. Si nous pensons que le geste, la parole, éventuellem ent la langue naturelle offre à l'utilisateur des facilités de com m unication a v e c une m achine, nous sommes plus réservés quant à l'usage de c e qu'on nomme généralem ent "réalité virtuelle", en sortie de m achines infographiques, en particulier dans la représen­ tation d 'esp aces architecturaux.

Les environnements proposés sont en général d'une très g rand e pauvreté plastique et il serait fâch e u x de croire que les problèmes de représentation (Goo90) sont tout à co up gommés, Nous préférons la notion d e "réalité augm entée" qui correspond mieux à notre m anière de voir l'apport d'un outil informatique en phase d e conception. Il n'est pas utile d'immerger l'Architecte dans une pseudo-réalité indigente, son imaginaire est plus puissant. Par contre, il est intéressant d'optimiser et d'élargir ses perceptions et ses facultés en "augm entant” g râ ce à la m achine, la réalité qu'il se construit.

Nous venons de mettre en évid e n ce un certain nombre de m odèles cognitifs et instrumentaux afin d'essayer d e progresser dans la définition d'un nouvel outil pour A rch itecte, utilisable dans la phase initiale d e conception.

Com m e nous l'avons souligné, c e t outil dès qu'il sera c ré é modifiera le com por­ tem ent d e l'utilisateur, c'est pourquoi, il n'est plus nécessaire d'affiner les modèles de base élaborés pendant cette étude, il faut passer à la phase suivante. Il est indispensable d e fabriquer un prototype à partir des sp é cifica ­ tions que nous venons d'ém ettre afin :

- de conforter ou d'infirmer notre expertise et le bien-fondé des m odèles que nous avons choisi,

- d e pouvoir étudier les répercussions de c e nouvel outils sur les pratiques et les manière d e penser l'Architecture.

Pour c e la , j'ai initié un projet au sein du LIR-INSA, le laboratoire conjoint d e la Faculté des Sciences et d e l'INSA qui m 'accueille depuis deux ans environ. C e projet s'appelle MOPIA (Modélisation d'un Outil-Partenaire Informatique pour A rchitecte). Catherine Barry-Gréboval, enseignant-chercheur au UR-INSA, Yves Bertrand du LSIIT, Françoise Darses du laboratoire d'Ergonomie du CNAM et J a c Fol, enseignant-chercheur à l'E. A.Normandie, y collaboreront a v e c moi.

Pour pouvoir progresser, nous nous appuyerons sur c e travail. Nous utiliserons le logiciel Topofil dont l'équipe d'Yves Bertrand continue de d évelo p p er les fonctionnalités com m e base infographique. Nous avons vu qu'il supporte la modélisation par agents protéiformes (cf.p.24).

Ces agents utilisent actuellem ent des connaissances qui sont données d irec­ tem ent par l'utilisateur au moment où il les fait naître ou les modifie. Nous étudions en c e mom ent la manière dont ils pourraient acquérir ses connaissan­ ces par l'intermédiaire du Système à Base de Connaissance dont nous avons co m m e n cé à construire le Schém a de Modèle C o ncep tuel (cf.p.10).

L'étude des nouveaux com portem ents induits par l'utilisation du prototype ainsi défini devrait nous permettre de franchir une nouvelle é ta p e en affinant les modèles d e coopération que nous avons esquissés (cf.p.31) et ainsi de c o n c e p t u a lis a tio n e n e x p é rim e n ta tio n , e t d 'e x p é rim e n ta tio n en conceptualisation, offrir aux Architectes une base pour construire leur outil com m e ils le désirent.

PUBLICATIONS

Certains aspects de ce tte recherche ont fait l'objet de publication:

R.Loisel, Y.Bertrand, D.Maillard, D ém arche projectuelle et instrumentation infographique à base topologique. A ctes du colloque IMARA'96, p.23-31

R.Loisel et C.Gréboval-Barry, Acquisitions de connaissances pour la

construction d'outils infographiques d'assistance à la conception architecturale, A ctes 7èm e Journées d'Acquisition des Connaissances, 1996, p .l 1-24

COLLABORATIONS DEVELOPPEES

LIR - INSA ROUEN

Le Laboratoire d'informatique de Rouen est conjoint à l'Université d e Rouen et à l'INSA d e Rouen. J'ai rejoint l'Equipe Heuristique et Informatique A v a n c é e du LIR-INSA dirigée par le Professeur P écu ch et en Juin 1994,

J'enseigne depuis octobre 1995 dans une option d e DEA: Représentation des Connaissances.

J'ai proposé en juin 1996 de poursuivre au sein du LIR-INSA le travail initié dans le ca d re d e c e projet habilité par la D.A.U. "Multi-modèles coopératifs pour une instrumentation informatique du projet architectural et urbain". C e tte proposi­ tion a été a c c e p té e sous le nom d e projet MOPIA (Modélisation d'un Outil Partenaire pour Architecte).

Catherine Barry-GrébovaL enseignant-chercheurau LIR-INSA, contribuera a v e c moi au développem ent de c e projet en collaboration a v e c Yves Bertrand du LS HT, Françoise Darses du laboratoire d'Ergonomie du CNAM et J a c Fol, ensei­ gnant-chercheur à l'E.A.Normandie.

LSIIT (URA CNRS 1871) UNIVERSITE LOUIS-PASTEUR - STRASBOURG

Au sein du Groupe d e Modélisation Géom étrique de Strasbourg Yves Bertrand a mis au point un m odeleur volumique interactif basé sur une ap p ro che topologique (Topofil). C e logiciel généraliste a été mis à notre disposition pour collaborer à la définition d'une version plus "orientée Architecture".

La collaboration doit continuer dans le c a d re du projet MOPIA afin d e faire évoluer le logiciel vers une é b a u ch e d e système partenaire afin de tester la pertinence des modèles déjà construits.

BIBLIOGRAPHIE

OUVRAGES GENERAUX

autour d e ta com plexité

Le Moigne J-L (1977) La théorie du système général (PUF)

Le Moigne J-L (1990) La modélisation des systèmes com plexes (DUNOD) Morin E (1977 à 1987) La M éthode - tomes I à IV (SEUIL)

Simon H-A ( 1991) Sciences des systèmes, sciences d e l'artificiel (DUNOD) Thom R. (1972) Stabilité structurelle et m orphogénèse, essai d'une théorie générale des modèles (EDISCIENCE)

Publications du groupe AFCET "Systémique et Cognition"

Sous la direction d e P.WatzIawick (1988) L'invention d e la réalité: contributions au constructivisme (SEUIL)

Colloque de Cerisy (1991)Les théories de la com plexité: autour d e l'oeuvre d'Henri Atlan (SEUIL)

Lewin R. (1994) La com plexité: une théorie d e la vie au bord du chaos (INTEREDITIONS)

philosophie, art e t scie n ce s

Bateson G . (1977) Vers une écologie de l'esprit (SEUIL)

Sous la direction de M aréchal l-A (1994) Sciences et Imaginaire (ALBIN MICHEL) Bergson (1939) Matière et Mémoire (PUF)

Valéry P, (1894) Introduction à la m éthode de Léonard d e Vinci (GALLIMARD) Groupe p (1992) Traité du signe visuel: pour une rhétorique d e l'im age (SEUIL) Nelson G oodm an (1990) Les langages de l'art (ED. J.CHAM BON)

U.Eco, La production des signes, Poche , essais, 1992(édition française) Serres M. (1993) Les origines de la géométrie (FLAMMARION)

Direction A.Soulez (1993) L'Architecte et le Philosophe, (M ARDAGA) Boudon P. (1992) Introduction à l'Architecturologie, dans S ciences d e la C oncep tion (DUNOD)

Lebahar J-C . (1985) Aide logique à la conception, in Etudes en C FA O , A rch itec­ ture et Batiment, (HERMES)

intelligence artificielle, interfaces

Rapportd Activité 1991-1993 du Pôle Interfaces hom m e-m achine multimodales du GDR-PRC Com m unication Homme-Machine

Rasmussen J. (1986) Information Processing and Human-Machine Interaction: an ap p ro ach to cognitive engineering (NORTH-HOLLAND)

Coordination N.Aussenac-Gilles, P.Laublet, C .R eyn au d (1996) Acquisition et Ingénierie des connaissances: tend ances actuelles (CEPADUES Editions) COOP'96 (1996) Deuxième co nféren ce internationale sur la co ncep tio n des systèmes coopératifs