đŸ€Â RĂ©union de conception d'un projet de bĂątiment. Comment les rĂ©ussir ?

Cet article fait partie de la formation gratuite Agile pour l'architecture, n'hésite pas à t'y inscrire pour t'aider à mettre en place l'agile sur tes projets.

En tant qu'architecte, BIM manager ou ingénieur en bùtiment, tu as surement une grande habitude des réunions de conception. Parfois, elles sont trÚs denses. D'autre fois, disons... plus ennuyeuses.

NĂ©anmoins, les rĂ©unions de conception sont essentielles, pour concevoir un bĂątiment, un espace public ou bien đŸ˜ïž un nouveau quartier.  L'Ă©quipe de maĂźtrise d'Ɠuvre peut ainsi se coordonner et montrer le projet et son avancement au client. Ces rendez-vous rĂ©guliers sont autant d'Ă©chĂ©ances pour structurer la conception d'un bĂątiment. Donner un rythme, qui finalement n'est pas si loin des itĂ©rations Agile.

Donc finalement, qu'est-ce que l'agile apporte Ă  ce format de rĂ©union qui existe dĂ©jà  ?

Pour rĂ©pondre Ă  cette question, je vais t'expliquer pourquoi cette Ă©tape est indispensable en agile. C'est en effet elle qui referme la fameuse boucle des retours ou feedbacks loops 🔁 qui symbolise la conception agile. C'est notamment pendant cette rĂ©union, que tu vas recevoir les avis des parties prenantes : maĂźtre d'ouvrage, utilisateurs finaux et autres membres de l'Ă©quipe projet.

Mais quand tu parles de retours ou boucle de retours, qu’entends-tu par là ?

La boucle de retours en Agile

La boucle de retours ou feedback loop, c'est quoi l'idée ?

La “feedback loop” ou “boucle de retours”, c’est ce qui reprĂ©sente la progression d’un projet Agile. En effet, on avance itĂ©ration aprĂšs itĂ©ration. Et Ă  chaque Ă©tape, l’équipe montre le projet tel qu’il est aux parties prenantes afin de recueillir des avis

Avec la mĂ©thode traditionnelle (ou en cascade = waterfall), il peut se passer des semaines, voire des mois avant qu’une dĂ©cision soit finalement Ă©valuĂ©e par le maĂźtre d’ouvrage. Ça peut se faire par exemple Ă  la fin d’une phase. Mais les phases en architecture sont relativement longues : 1, 3, 5 mois. Cela dĂ©pend de la phase et de la taille du projet.

Maintenant imagine que tu as travaillĂ© pendant toute cette pĂ©riode. Que le projet est enfin complĂštement calĂ©. Et qu’aprĂšs avoir reçu tous les documents, le maĂźtre d’ouvrage se rend compte d’un aspect important, qui ne lui convient pas ! 😰

Il demande donc des changements avant de valider le dossier. Mais ces changements peuvent ĂȘtre couteux, pour l’équipe de maitrise d’Ɠuvre. Par exemple s’il faut changer de maniĂšre importante la maquette. Cela peut crĂ©er des tensions et en tout cas des heures supplĂ©mentaires qui vont dĂ©caler encore le planning et le dĂ©marrage du chantier !

À l’inverse, si chaque itĂ©ration est Ă©valuĂ©e rĂ©guliĂšrement, par exemple en faisant une dĂ©mo de la maquette BIM. Le client ou les autres membres de l’équipe de maitrise d’Ɠuvre peuvent donner leur avis. Et ainsi, si quelque chose ne va pas, on le sait tout de suite, Ă  la fin de chaque dĂ©mo. On peut alors corriger le tir rapidement. Ce qui est beaucoup moins coĂ»teux que de faire les modifications plus tard.

Quand on conçoit un bĂątiment, une voiture, un tĂ©lĂ©phone ou un logiciel, le coĂ»t des modifications s’accroit en effet de maniĂšre exponentielle avec le temps comme le montre l’illustration suivante.

De plus, le client prend une part beaucoup plus active Ă  la conception, car il peut rĂ©orienter l’équipe de maitrise d’Ɠuvre au fil de l’eau. Et ce de maniĂšre Ă  mieux correspondre aux besoins, qu’il a identifiĂ© chez les futurs utilisateurs de son bĂątiment, mais aussi de contraintes pratiques comme le budget disponible.

Donc, tu l’as compris, l’objectif en agile est de rĂ©duire la durĂ©e de cette boucle des retours. Pour que le projet soit rĂ©guliĂšrement revisitĂ© par l’équipe et le client. Et que l’on soit ainsi sĂ»r de travailler dans le bon sens avec les bonnes prioritĂ©s.

Plus on avance, plus il est difficile de faire des changements.

Partager la maquette BIM dĂšs que possible !

Les revues de projet ou dĂ©mos sont idĂ©ales pour recevoir des avis Ă  chaud. Les parties prenantes, architectes, ingĂ©nieurs, maĂźtre d’ouvrage sont rassemblĂ©es et peuvent ainsi rapidement confronter leur point de vue sur le projet.  En revanche, elles ne sont pas forcĂ©ment adaptĂ©es pour une discussion approfondie ou trop technique.

Et ceci pour plusieurs raisons :

  • Pour ne pas perdre le rythme et “endormir” l’assistance
  • Car il est nĂ©cessaire d’avoir du recul pour avoir un avis plus affirmĂ©
  • Enfin, certaines personnes ne peuvent pas se libĂ©rer pour les rĂ©unions

En complément des revues de projets ou démo, il est ainsi trÚs utile de partager la maquette BIM dans une plateforme collaborative.

Dans cette plateforme, il doit ĂȘtre possible  :

  • De visualiser le projet dans son Ă©tat actuel ou dans une version prĂ©cĂ©dente
  • De pouvoir adapter la visualisation : plan de coupe, points de vue

  • D'Ă©crire des commentaires ou demander des modifications
  • De pouvoir suivre l’avancement des sujets via un systĂšme de gestion de tĂąche

Ça tombe bien, j’ai contribuĂ©, Ă  une plateforme collaborative Bricks, qui te permet de faire cela : recueillir des avis sur la maquette et gĂ©rer les tĂąches de projet en agile avec ton Ă©quipe.

Si tu souhaites tester, n’oublie pas de me faire des retours, positif ou nĂ©gatif. Et oui, Bricks est conçu en agile, tu l’imagines bien !  

En résumé, je te conseille de mixer les deux approches  :

  • RĂ©unions de revues de projet synchrone, en prĂ©sentiel ou Ă  distance, pour soulever les points majeurs et confronter les points de vue
  • Partager  la maquette et discuter en asynchrone pour poursuivre une discussion dĂ©taillĂ©e au fil des semaines et suivre les avancĂ©es sur chaque sujet

En appliquant cette stratĂ©gie, on s’approche du but qui est de rĂ©duire le temps de retour sur les choix de projet. Et sĂ©curiser le rendu final du dossier, qui sera dĂ©jĂ  bien connu du maitre d’ouvrage au moment de rendre la phase

GrĂące Ă  une plateforme collaborative recueille des commentaires au fils de l'eau

Comment réintégrer les retours dans ta prochaine itération

Donc, tu as maintenant de nouvelles techniques pour rĂ©colter de prĂ©cieux avis sur le projet soit en rĂ©union, soit au fils de l’eau.

Mais comment intĂ©grer ces retours ? Ils ne sont en effet pas forcĂ©ment tous pertinents. Certains sont peut-ĂȘtre un avis trĂšs particulier d’une seule personne.

Par exemple, un ingĂ©nieur est forcĂ©ment par nature plus conservateur qu’un architecte, car il a une responsabilitĂ© sur le fait que le bĂątiment tienne encore plus grande. Il aura ainsi surement des avis plus mitigĂ©s sur le porte-Ă -faux monumental conçu par l’architecte.

Le maĂźtre d’ouvrage, s’il se charge de l’entretien des bĂątiments, aura en tĂȘte tous les problĂšmes qu’il a eu sur d’autres chantiers. Et il cherchera Ă  les Ă©viter, en Ă©tant peu ouvert aux approches plus risquĂ©es.

Enfin, l’utilisateur final aura certainement une idĂ©e sur sa maniĂšre d’habiter son appartement actuel. Mais peut ĂȘtre des difficultĂ©s pour se projeter dans une architecture trop innovante.

Tu l’as compris, chacun prĂȘche sa chapelle comme dit l’expression. Mais nĂ©anmoins, chaque personne de l’équipe apporte ainsi une expertise, qu'une seule personne ne peut pas avoir. Ce partage permet de rendre le projet meilleur et de dĂ©tecter des problĂšmes. Si tu es comme moi, tu as surement notĂ© plein de dĂ©fauts de conception dans les bĂątiments dans lequel tu Ă©volues. Par exemple dans mon appartement, des portes qui en s’ouvrant en mĂȘme temps se choquent l’une sur l’autre ! C’est bateau â›”, mais probablement ça embĂȘtera tout le monde pour les 30 prochaines annĂ©es !

Le deuxiĂšme point Ă  prendre en compte est la temporalitĂ©, est-ce que le point relevĂ© est prioritaire, mĂ©rite d’ĂȘtre traitĂ© dans la prochaine itĂ©ration. Et lĂ , on ferme la boucle avec la prĂ©paration de l’itĂ©ration suivante, appelĂ© aussi sprint planning dans le Scrum.

Non ce n'est pas une installation d'arstiste ! Petite erreur de niveau :)

🎹 Mets une touche d’agilitĂ© dans ta prochaine rĂ©union projet

Mettons cela en pratique, commençons par des choses simples que tu peux tester dĂ©jĂ  en interne. Pourquoi ne pas organiser une rĂ©union projet en implication bien sĂ»r avec l’équipe. Mais en ouvrant Ă©galement aux autres membres de l’agence et aux externes si possible : ingĂ©nieurs, client


VoilĂ  donc ce que je te propose :

✅  Organise une rĂ©union projet interne toutes les deux semaines

✅  Invite des personnes extĂ©rieures Ă  l'Ă©quipe d’architectes comme les ingĂ©nieurs et pourquoi pas le maĂźtre d’ouvrage

✅ Liste les nouveautĂ©s depuis la derniĂšre prĂ©sentation et demande Ă  chaque personne responsable de les prĂ©senter

✅  Utilise si tu le peux une plateforme collaborative avec un visualiseur IFC pour partager le modùle à l’avance

✅  Recueille les avis de chacun et encourage les participants à parler franchement

✅  Organise un tableau de suivi, pour que l’on sache si les points ont Ă©tĂ© traitĂ©

✅  Si tu utilises une plateforme collaborative, continue la discussion jusqu'Ă  la prochaine dĂ©mo

La rĂ©union projet est donc bien sĂ»r fondamentale pour la collaboration et l’agilitĂ©. Mais encore faut-il concevoir comme un moment d’échange et non comme la prĂ©sentation d’un travail terminĂ© 😉

Enfin si ce contenu t'intéresse, sache qu'il fait partie d'une série pour apprendre l'agile pour l'architecture et la construction. Abonne toi à ma formation par email. C'est gratuit !