La coopération au sein d’un projet architectural

Dans un projet architectural, les relations entre les acteurs peuvent être décomposées en deux familles correspondant aux deux grandes phases d’un projet : la première au cours de la conception et la seconde au cours de la construction.

II.3.1 Le cadre de la coopération

Les connaissances rassemblées autour des processus de conception [Conan 1990; Prost 1995] et de construction [Armand and Raffestin 1997] nous permettent de dresser un bilan des exigences des deux étapes d’un projet architectural (cf. figure 62) :

– Organisation : cet axe décrit l’organisation sociale du groupe de projet. Dans une organisation purement hiérarchique, un acteur dirige tout le groupe. Dans un groupe basé sur la coopération, les acteurs échangent et se coordonnent spontanément. Les phases de construction se rapprochent d’un processus de production industriel. Elles se révèlent donc plus hiérarchisées que les phases de conception.

Figure 62 : Protocoles sociaux et interactifs au cours d’un projet architectural.

– Stabilité des documents : au cours des phases de conception, les choix et les documents produits sont fréquemment remis en cause afin d’intégrer à la fois les aspects techniques, économiques et les besoins du maître d’ouvrage. Lors de la construction, les changements portent essentiellement sur une précision de détails et de procédés constructifs. L’évolution des documents se trouve donc plus linéaire.

– Type de réunions : les concepteurs doivent évaluer les besoins de leur maître d’ouvrage, exposer le point de vue conceptuel sur le projet, étayer leur parti technique. Les réunions au cours des phases de conception sont donc fréquentes, non planifiées à l'avance et proches de séances de brainstorming. Au contraire, les réunions de chantier portent sur la validation de l’avancement et l’assignation de nouvelles tâches aux constructeurs ; elles sont régulières et planifiées.

– Coordination : lors de la construction, l’ordre d’intervention des corps d’état est connu, les réunions de chantier sont planifiées et périodiques, les acteurs connaissent les délais qui leur sont alloués. Nous sommes en présence d’une coordination explicite (Godart et al., 2001). Au cours de la conception, l’interaction des acteurs est peu planifiée et par conséquent plus proche d’une coordination implicite.

– Précision du processus : au cours d’une phase de conception, contrairement à la production, nous connaissons les documents que nous devons produire mais nous ignorons le nombre et le type des documents intermédiaires à réaliser.

La phase de conception d’un projet architectural se caractérise par ce que Maher appelle une collaboration exclusive (Maher et al., 1998) dans laquelle les acteurs travaillent sur des parties du problème, négociant et demandant conseil aux autres acteurs impliqués. Ce type de travail collectif nécessite de la part des acteurs une grande implication pour être créatif (Kvan, 2000). Un des moyens mis en avant pour renforcer la capacité opérationnelle (Shea et al., 1987) de ce type de structure est la création d’une conscience de groupe (awareness) par une diffusion équitable des informations relatives à l’évolution du projet (Dourish et al., 1992). La coopération au sein d’un projet de conception

architecturale constitue alors un bon cadre d’expérimentation pour la proposition d’un modèle d’assistance à la conception coopérative.

II.3.2 Exemple de coopération, la place Painlevé

La plupart des outils coopératifs proposés sur le marché, dédiés ou non au bâtiment, repose sur une représentation hiérarchique de l’information (BSCW, Teamwave, Buzzsaw, Batibox..). Afin d’évaluer les problèmes liés à ce type d’organisation de l’information, nous avons mené une expérimentation d’utilisation d’un de ces outils dans le cadre d’un projet de restructuration d’un espace urbain : la place Paul Painlevé à Nancy. Ce projet a impliqué plusieurs niveaux d’acteurs : une agence d’architecture, les services techniques de la mairie et une commission de quartier.

a. Contexte

Le projet s’est déroulé sur une durée de 6 mois. Un plan qualité a été fourni aux intervenants. Ce dernier comportait la nomenclature des fichiers, des indications sur les règles d’échange et spécifiait les formats d’échange de fichiers. La mise en place d’un tel document est indispensable pour permettre une cohérence des données et rendre possible le partage d’informations par le biais d’un logiciel.

Architecte 1

Conçoit et dessine Architecte 2

Conçoit et dessine

Architecte Expert Architecte Responsable

Synchronisent leurs plans Informe Valide Conseille Ingénieur Expert technique Responsable Supervise le Projet Association de Quartier Exprime les attentes des

riverains Valide Maître d’ouvrage Informe Valide Informe Attentes Agence d’architecture Equipe de Projet

Figure 63 : Organisation d’une équipe de projet de conception

Pour les besoins de l’expérimentation, nous avons utilisé un collecticiel généraliste (BSCW développé par GMD-FIT) [Bentley, Horstmann et al. 1995]. Par rapport aux besoins que nous avons pu identifier, les possibilités offertes par cet outil reflètent les fonctionnalités [Salvador, Scholtz et al. 1995]proposées par la majeure partie des collecticiels que nous avons analysés. Pour cette étude, nous nous affranchirons des considérations ergonomiques, les acteurs étant sensibilisés et formés à l’utilisation de cet outil.

b. Déroulement

Le déroulement de ce projet a permis de mettre en évidence des relations et des rôles tenus par les acteurs au cours de la conception du projet (cf. Figure 63). Au cours de cette activité, les acteurs manipulent des documents. Les rôles sont les suivants : architecte, architecte expert, responsable, MO délégué voirie/réseaux, MO délégué responsable, usagers (commission de quartier).

Nous prendrons comme exemple la réalisation d’un plan d’aménagement de la place. Au début de la coopération, les acteurs doivent structurer l’information dans l’outil de manière à respecter les différents niveaux de validation, d’abord en interne, à l’agence d’architecture puis auprès de la maîtrise d’œuvre. L’attribution des droits s’appuie sur une organisation hiérarchique de répertoires qui autorise et fige les différents niveaux de validations (cf. Figure 64b). Cette organisation ne correspond pas à une représentation satisfaisante de la progression du projet. Elle reflète au mieux la hiérarchie existante au sein du groupe plutôt que l’esprit relationnel de celui-ci.

ARCHITECTE 1 Conception de la place ARCHITECTE 2 Crée V 0.1 Modifie V 0.11 annotée ARCHITECTE 3 V 0.2 Annote V 1.0 ARCHITECTE 4 Valide et premier (1) Services Techniques Valident si 1 est OK (2) V 2.0 RIVERAINS Peuvent lire si 2 est OK Architectes (1+2) Concepteurs (1+2+3) Agence d’architecture (1+2+3+4) Equipe de projet (1+2+3+4+MO)

Valide

Valide

Lit

V 1.0 (copie pour validation)

V 2.0 (validée)

V 2.0 (copie pour information)

Remarques des riverains V 0.2 (copie pour validation)

V 1.0 (validée) Agence d’Architecture

Agence d’Architecture + MO

Agence d’Architecture + MO + Riverains

V 0.1 (copie pour annotation)

V 0.11 (annotée) Groupe de Conception V 0.1 (original) V 0.2 (modifiée) Architectes (1+2) Copie Projet de la Place Copie Copie Copie

Figure 64a : Séquence de validation d’un document

Figure 64b : Structuration en répertoire correspondant à l’organisation du projet et

copies de fichiers découlant de cette organisation

c. Analyse de l’expérimentation

Le déroulement de ce projet illustre la nécessité de mettre en place des règles d’échange très rigides pour préserver la cohérence du système. Ces règles portent principalement sur la nomenclature des noms de fichiers et sur l’organisation des calques. L’expérience montre que s’il est aisé de s’accorder sur une organisation cohérente des calques à l’intérieur des pièces graphiques, il n’en va pas de même pour les règles portant sur les noms des fichiers. En effet, chaque acteur attribue aux fichiers un nom qu’il juge explicite mais ce nom ne suffit pas pour identifier le document dans un contexte multi-utilisateurs.

Le principe de structuration de l’information utilisée dans la plupart des collecticiels existants oblige les utilisateurs à créer des copies des fichiers lors des phases de validation (cf. Figure 64b). Lorsqu’un acteur désire échanger un document, il est obligé de copier ou de déplacer ce document dans un autre répertoire. La multiplication des copies rend difficile la recherche d’informations et augmente considérablement le risque de voir apparaître des incohérences et des conflits entre des versions concurrentes.

La vision que donne l’outil du projet est la même pour tous les acteurs quelque soit leur rôle au sein du projet. Les événements liés à l’activité sont systématiquement visibles. Ils contribuent certainement à l’amélioration de la conscience de groupe et donc de la coordination implicite [Godart, Halin et al.],

mais lorsqu’ils sont trop nombreux et parfois inopérants c’est vers une surcharge cognitive que le système oriente l’utilisateur. Ainsi les collecticiels actuellement disponibles proposent une vue encore trop proche de l’organisation physique des données qui ne peut en aucun cas refléter l’organisation sociale du projet. La prise en compte de cette dimension associée à un mode alternatif de structuration de l’information [Dourish, Edwards et al.] nous semble une piste à suivre pour la définition d’un nouveau modèle de coopération proposant une vision contextuelle et adaptative du projet.

III. Un Meta-Modèle de coopération orienté «relation»

Le domaine de la conception et plus particulièrement de la conception architecturale constitue un contexte particulier de coopération basé sur des relations à la fois hiérarchiques et coopératives entre acteurs (Bernoux, 1990). Chaque composant du projet possède un environnement spécifique avec lequel il entretient des relations. Par exemple, un acteur entretient des relations avec ses documents, les activités auxquelles il participe et les acteurs également impliqués dans le projet. Le modèle de coopération que nous proposons est la représentation des relations existant dans un projet de conception. La définition de ce modèle s'inscrit dans les approches par meta-modélisation [Lemesle 2000] utilisées dans le standard MOF (Meta Object Facility) proposé par l’OMG (Object Management Group).