Dans un célèbre article essai « La Cathédrale et le Bazar »1, le développeur informatique Éric Raymond présente avec enthousiasme les principes qui font, selon lui, la supériorité des méthodes ouvertes et collaboratives du logiciel libre sur celles, cloisonnées, du logiciel propriétaire. Il insiste notamment sur le processus d’élaboration du logiciel, opposant d’un côté la méthode de la « cathédrale » à celle, de l’autre, du « bazar » : je pensais que les logiciels importants (comme les systèmes d’exploitation et les très gros outils comme Emacs) devaient être conçus comme des cathédrales, soigneusement élaborés […] à l’écart du monde, sans qu’aucune version bêta ne voie le jour avant que son heure ne soit venue. Le style de développement de Linus Torvalds — distribuez vite et souvent, déléguez tout ce que vous pouvez déléguer, soyez ouverts jusqu’à la promiscuité — est venu comme une surprise. À l’opposé de la construction de cathédrales, silencieuses et pleines de vénération, la communauté Linux paraissait plutôt ressembler à un bazar grouillant de rituels et d’approches différentes »2. Nous proposons d’interroger dans cet article ce que peut produire le transfert de ces méthodes collaboratives en architecture, assumant que, classiquement, ce sont les méthodes de la cathédrale qui dominent. Le monde des concours d’architecture et de la mise en concurrence incitent en effet à développer les bâtiments « en chambre » avant de les dévoiler au grand jour. Dans quelle mesure les méthodes collaboratives des tenants du logiciel libre peuvent-elles être mises en œuvre dans un projet d’architecture ? Autrement dit, si l’on accepte que le numérique collaboratif est un état d’esprit, une culture, davantage encore qu’une série d’outils plus ou moins ouverts, comment le numérique peut-il renouveler les méthodes et les pratiques du monde de l’architecture et de l’urbanisme ?
Pour aborder ces questions, nous prenons pour brève étude de cas le « Wikibuilding » promu par les agences HOST, UFO, membres de l’ONG 7 Milliards d’Urbanistes (7MU).
Architectes-entrepreneurs-traducteurs de l’urbanisme collaboratif, les membres de ces diverses organisations développent des approches de la production urbaine fortement inspirées des méthodes collaboratives numériques mobilisant à divers niveaux des outils logiciels. C’est bien la façon de faire, le processus, plus que le produit, « l’œuvre » architecturale, qui nous intéresse ici, même s’il y a fort à croire que le produit puisse être largement infléchi par la méthode, puisqu’aussi bien son pilotage, sa programmation que son exploitation s'éloignent des pratiques conventionnelles.
Les membres du réseau 7MU articulent donc concepts et outils issus du monde du numérique. Au cœur de leur activité réside un important principe d'indétermination du projet. Ce principe ne signifie pas pour autant que le collaboratif consiste à travailler à partir d'une page blanche. Au contraire, un ensemble de pré-projets fictifs, que l'on peut nommer des « promesses plausibles » suivant Éric Raymond, engagent les différents acteurs à soumettre leurs avis et à s'impliquer plus avant dans le projet. Ces projets reposent et utilisent alors un panel d'ateliers et de logiciels.
Leurs méthodes ré-emploient aussi certains classiques de l'architecture, tel que le « collage » (ci-dessus) ou la « perspective ultra réaliste » (ci-dessous), pour les insérer dans une forme de travail en réseau grâce aux technologies numériques.
Ainsi, les collages réalisés par l'intermédiaire de logiciels pour tablettes tactiles sont accessibles en ligne pour créer une forte intertextualité entre les propositions et avis des utilisateurs et favoriser leur mise en communication. Ces méthodologies n'oublient pas l'importance des rencontres physiques : des formats d'innovation très courts, nommés « hackathons » (de la contraction entre hack — détournement — et marathon) favorisent la rencontre de nombreux acteurs autour de la conception du projet, associant étudiants, entreprises et collectivités autour de la résolution de problèmes urbains concrets. Innovation et mise en réseau apparaissent ainsi comme les maîtres-mots des méthodes de l'association 7MU. Or, au regard des pratiques et outils développés par les membres du réseau 7MU, il ne faudrait pas confondre cette démarche avec les utopies d’un militantisme « participatif » dans lequel les rapports d’expertise et de décision entre élus, professionnels de l’urbain et citoyens seraient abolis au profit d’une collégialité horizontale. De fait, les rapports liés à des connaissances asymétriques et des postures de pouvoir ne sont pas niés dans l’urbanisme collaboratif mais visent à trouver de nouvelles articulations reposant sur un échange et une ouverture accrus entre les différentes parties. Par exemple, le tropisme architectural d’HOST et UFO tend à mettre l’architecte au cœur du processus de coordination, celui-ci développant par sa profession une certaine habitude de traduction. Ce recentrement autour de la figure de l’architecte est rééquilibré par la volonté d'activer les projets dans toutes leurs dimensions et de distribuer à d'autres disciplines et métiers la capacité d'organiser de nouveaux cœurs de coordinations.
Il nous semble que le grand emprunt des tenants de l’urbanisme collaboratif à la culture du logiciel libre réside dans la volonté de produire des « communautés » susceptibles d’œuvrer à l’élaboration et l’enrichissement continu du projet architectural.
En intéressant citoyens, élus et professionnels au projet par la présentation de « promesses plausibles », les outils d’HOST et UFO cristallisent progressivement le devenir du projet ainsi que les intérêts que peuvent avoir leurs interlocuteurs à y prendre part. La stabilisation du projet repose alors sur une compétence critique qu'il s'agit de savoir faire émerger, déjà soulignée par Éric Raymond et probablement cruciale dans toute démarche collaborative, « savoir reconnaître les bonnes idées de conception des autres »3.
-
RAYMOND Éric, 1997, La Cathédrale et le Bazar, http://www.linux-france.org/article/these/cathedrale-bazar/cathedrale-bazar.html ↩
-
Ibid. ↩
-
Ibid. ↩