Catégorie: Stratégie
Publié le 15 Juillet 2020 par Arthur Grenier et Steve Sénéchal

Le Nouveau Complexe Hospitalier (NCH) du site de l’Hôpital de l’Enfant-Jésus n’est pas seulement l’un des projets de construction les plus ambitieux à Québec; il est aussi un projet de classe mondiale élaboré dans le cadre d’un processus unique de conception. 

Afin de donner un ordre de grandeur au type de gestion qu’implique un projet de cette échelle, voici quelques statistiques:

L’équipe d’architecture à elle seule comporte plus de 80 membres travaillant en simultané sur les différentes composantes du projet. Cette équipe est composée de six (6) pratiques d’architecture de Québec et Montréal. Le bureau de projet principal se situe à Québec à proximité du site mais des bureaux satellites sont également en place chez différents membres du consortium. 

La conception et la réalisation des plans sont réparties concrètement sur plusieurs phases de travaux. Ce qui se reflète en 21 phases distinctes à l”intérieur de Revit comprenant les ouvrages existants, les nouvelles construction échelonnés dans le temps ainsi que les multiples réaménagements.

La quantité de maquettes utilisées par les différentes composantes du projet a augmenté en parallèle avec la complexité des bâtiments. En date du printemps 2020 le nombre de maquettes utilisées en Architecture s’élève à 37 dont 8 étant dédiées à un bâtiment unique. C’est tout de même bien peu comparé au 400 et plus maquettes pour toutes les disciplines confondues. Le coupable principal étant les différentes maquettes MEP qui se dénombrent à plus de 300.

La taille du projet (que nous qualifions amicalement de MÉGA-Projet, progression logique au-delà du Grand Projet) jumelée à la conception intégrée en liens vivants donne lieu à une multitude de défis. Ce blogue explorera ces différents défis et leurs solutions.

BIM One est fier de faire partie de l’équipe de ce projet, pour partager notre expertise dans la transformation numérique de la construction, la gestion de projets BIM et nos années d’expérience dans l’utilisation de nombreux outils technologiques. Nous sommes très heureux de partager dans les prochaines lignes nos bonnes pratiques BIM développées et appliquées sur ce Nouveau Complexe Hospitalier.

Introduction au projet

Description du projet et de l’équipe

Avant d’entrer dans notre premier sujet, il est pertinent de prendre un peu de recul et tenter de visualiser ce projet dans son entièreté. Le Nouveau Complexe Hospitalier (NCH) se situe sur le site de l’Enfant-Jésus dans la ville de Québec. Son budget estimé à tout près de 2 milliards de dollars en fait probablement un des plus gros projets hospitaliers de la région. Il est possible de consulter le site du CHU de Québec–Université Laval (CHU) pour explorer les diverses facettes du projet.

En voici d’ailleurs une projection finale incluant les différentes composantes et leur année prévue d’ouverture:

Outre l’ampleur considérable du projet, il est unique dans sa méthode de conception. Le projet entier est réalisé sur Revit en liaison de maquettes vivantes et ce toutes disciplines confondues. La coordination interdisciplinaire se fait donc en temps réel sur la plateforme collaborative BIM 360 DOCS. Chaque discipline intégrant directement les maquettes des autres à leur processus de conception et de documentation. 

Afin de donner un ordre de grandeur au type de gestion qu’implique un projet de cette échelle, voici quelques statistiques:

  • L’équipe d’architecture à elle seule comporte plus de 80 membres travaillant en simultané sur les différentes composantes du projet. Cette équipe est composée de six (6) pratiques d’architecture de Québec et Montréal. Le bureau de projet principal se situe à Québec à proximité du site mais des bureaux satellites sont également en place chez différents membres du consortium. 
  • La conception et la réalisation des plans sont réparties concrètement sur plusieurs phases de travaux. Ce qui se reflète en 21 phases distinctes à l”intérieur de Revit comprenant les ouvrages existants, les nouvelles construction échelonnés dans le temps ainsi que les multiples réaménagements.
  • La quantité de maquettes utilisées par les différentes composantes du projet a augmenté en parallèle avec la complexité des bâtiments. En date du printemps 2020 le nombre de maquettes utilisées en Architecture s’élève à 37 dont 8 étant dédiées à un bâtiment unique. C’est tout de même bien peu comparé au 400 et plus maquettes pour toutes les disciplines confondues. Le coupable principal étant les différentes maquettes MEP qui se dénombrent à plus de 300.

La taille du projet (que nous qualifions amicalement de MÉGA-Projet, progression logique au-delà du Grand Projet) jumelée à la conception intégrée en liens vivants donne lieu à une multitude de défis. Cette série explorera ces différents défis et leurs solutions.

Besoin initial en matière de documentation

Dichotomie Transversalité / indépendance 

Dans un projet de cette envergure, la documentation et l’annotation des plans représentent un travail de taille. Lors des phases initiales de démarrage des premières composants du projet, plusieurs méthodes de travail ont été envisagées. Les besoins de l’équipe de conception ont alors fait surface.

Devant à une équipe aussi étendue et une gamme de projets aussi large un compromis a dû être accepté entre la transversalité des outils inter-équipe et leur indépendance de conception..

La transversalité des données entre les différentes maquettes du projet devait être conservée afin de livrer un produit uniforme au client. tout autant de pouvoir récupérer le travail déjà effectué sur certaines phases du projet afin de l’appliquer ailleurs. 

Par contre, le travail d’une équipe de conception ne doit pas influencer les autres composantes directement de manière involontaire. Toute l’information comprise aux plans doit y être conservée de manière intégrale et sans altération une fois émise. Dans un système totalement transversal, les modifications apportées par un utilisateur sur certaines données risquent d’affecter d’autres occurrences. Tout comme un changement dans un type de famille va modifier toutes les occurrences placées. Il n’est pas possible de s’assurer qu’un changement n’ai pas de conséquences inattendues sur du travail déjà effectué ou en cours de production.

Le compromis à atteindre devrait donc garantir un certain degré d’indépendances entre les composantes du projet tout en permettant de conserver la transversalité des notes écrites aux plans.

Notes aux plans indépendantes pour chaque bâtiment

Les périodes de conception et de production des différentes composantes étant étalées et se chevauchant, les besoins d’annotation des plans sont uniques. 

Expansion du système

Capacité d’ajouter facilement et rapidement des jeux de notes indépendants pour les nouveaux projets.

Solutions envisagées et limitations

Un seul fichier de note par maquette

La limitation principale du système conventionnel de Notes d’identification réside dans le fait qu'un seul fichier source peut être utilisé. Ce fichier sous format texte (.txt) doit contenir l’ensemble des notes à être utilisées. Changer de fichier dans le but d’utiliser un jeu d’annotations différentes pose un risque d’erreur et d'inconsistances immense. 

La situation demandait d’avoir accès aux notes spécifiques à une composante dans les maquettes adjacentes. Certains fichiers devraient alors être combinés afin de pouvoir accéder à leurs informations de manière transversale.

Usagers multiples simultanés

Un des enjeux principaux qui a été considéré lors de l’implantation d’une nouvelle solution tourne autour des accès aux fichiers à distance. Lorsque revit tente d’accéder à son fichier de notes d’identifications, il se sert d’un chemin d’accès local, un emplacement fixe sur le poste de l’usager. Ce chemin d’accès est enregistré de manière absolue dans le fichier central et doit être uniforme pour chaque usager. Un des défis du système consiste donc à trouver une plateforme d’hébergement des fichiers qui retournera un chemin d’accès fixe et absolu pour tous les usagers, peu importe leur localisation.

Les gens qui utilisent les notes n’étant pas nécessairement les mêmes que ceux qui les écrivent, il n’est pas possible de simplement héberger les fichiers sur un seul poste de travail localement. L’ampleur de l’équipe de travail empĉhait également des transferts de fichiers manuels entre les différents bureaux satellites, de telles manipulations auraient été des sources potentielles de beaucoup d’erreurs et de pertes de travail. L’utilisation d’une plateforme centralisée pour tous les utilisateurs potentiels des fichiers de note est donc un besoin central.

L’infrastructure de gestion documentaire a déjà été implantée au début du projet sous la forme d’un serveur Sharepoint dédié et géré par le client. Les fichiers ont donc été hébergés sur cette plateforme dans un dossier dédié et accessible par l’intermédiaire d’un lecteur réseau déployé sur chaque poste. 

Cette solution s’est avérée fonctionnelle malgré l’instabilité du serveur qui demandait une gestion supplémentaire lors de pertes d’accès.

Solutions rejetées

Logiciels compléments 

Naturellement, une des premières questions à avoir lors de discussions de nouveaux outils devrait être “Qu’est-ce qui existe déjà et pouvons-nous s’en servir?”. Quelques logiciels compléments de gestion de notes existaient déjà lors du déploiement du projet, mais ils ont été rejetés pour quelques raisons simples.

  1. Le parc informatique à la disposition du bureau de projet étant géré par le client, tous les logiciels déployés doivent être approuvés et installés par le service TI en charge. Cette précaution, bien que nécessaire pour assurer la sécurité informatique du projet, complique énormément le déploiement et la mise à jour d’outils directement sur place. De plus, l’intégration des multiples bureaux satellites, chacun ayant son département de gestion informatique, rend complexe l’utilisation de logiciels externes aux outils de base.
  2. Lors de la phase de test de ces différents outils de gestion leurs limites ont également étés rapidement atteintes. L’ampleur du projet en venait à causer des ralentissements considérables et l’utilisation des logiciels compléments testés est devenue impossible. Voici quelques outils qui ont été considérés lors du déploiement des fichiers de notes d’identification. Il serait pertinent de revisiter ces outils lors d’un prochain projet et d’en évaluer les avantages en comparaison avec un système traditionnel.
    • Keynotes manager (Revolution Design)
    • Manage keynotes (pyRevit)
    • Macaw Plus +

Notes d’identification par éléments

En parallèle avec le déploiement du système d’annotation, la question du déploiement à l’intérieur des maquettes a été explorée. une des méthodes qui a été brièvement testée fut l’utilisation des notes d’identification par élément . 

À première vue la standardisation des informations attachées aux familles directement semblait pouvoir réduire le risque de disparité entre les différentes occurrences de texte. Cependant le blocage de l’information attachée au type de la famille aurait causé une prolifération du nombre de types de familles, en particulier dans le cas des éléments de détails. Chaque variation de texte demandant une note différente, un nouveau type de famille doit être créé. Lorsqu’on considère toutes la variance possible dans l’information pouvant être associée à un simple panneau de gypse, l’idée des notes par élément a vite été rejetée. 

D’autant plus que la gestion des versions de familles de manière transversale dans toutes les maquettes du projet comporte son lot de défis. Inutile d’y rajouter cette couche de complexité supplémentaire.

Notes Phase 1 - Fichiers indépendants

La première phase du projet comportait entre autres les composantes de la Centrale d’énergie et du Centre Intégré de Cancérologie. Étant des bâtiments largement indépendants les uns des autres autant au niveau géographique que conceptuel, le besoin de transversalité s’est peu fait sentir.

Il a donc été décidé de séparer les notes d’identifications par composantes afin d’éviter le chevauchement et diminuer le risque d’erreur lors de l’édition et la correction des notes.

Les fichiers de notes ont été séparés de manière à avoir une seul point d’entrée par maquette. Le travail ainsi divisé par équipe assurait que chaque groupe soit en contrôle de ses propres annotations. Un fichier Excel unique fut créé pour chaque maquette Revit représentant une composante de projet. Les cahiers de plans ont pu ainsi conserver leur individualité. Étant donné que le travail simultané sur un même fichier excel n'était pas envisageable à ce point, garder un nombre d’usagers restreint sur chaque fichier évitait les conflits de modification.

Mise en place de fichiers partagés

En présence d’une plateforme déjà implantée, les notes d’identification ont été placées sur le serveur Sharepoint du client. Cet emplacement assurait que les bureaux satellites pouvaient modifier les fichiers appartenant à leurs composantes respectives.

Initialement, les notes d’identification étaient entrées dans un classeur Excel et ensuite exportées en format texte supporté par Revit. Un simple script de sauvegarde assurait que le fichier soit toujours enregistré au même emplacement et dans le même format, minimisant le risque d’erreur. 

Notes Phase 2 - Fichier centralisé

La progression des phases du projet apporte inévitablement un niveau de complexité supérieur. Les bâtiments de la Phase 2 sont juxtaposés les uns aux autres et souvent interconnectés. Les interventions ne se font plus à l’intérieur d’une seule maquette isolée mais bien de manière transversale autant sur le spectre de la modélisation que de la documentation.

Certains bâtiments viennent se connecter à d’anciennes portions existantes autant que des nouvelles constructions de phase antérieure. Cet étalement a pour conséquence la multiplication des interventions dans plusieurs maquettes pour un même cahier de plans. 

Suite à cet étalement il est devenu nécessaire de pouvoir accéder aux notes d’identification d’un seul projet dans plusieurs maquettes mais aussi de pouvoir classifier les notes se rapportant à différents projets dans un fichier unique.

Un bon exemple de ce besoin de transversalité est illustré ci-bas. Les cahiers de plans numérotés 0501 et 1302 pour leurs projets respectifs impliquent des travaux dans 4 maquettes adjacentes. Les mêmes notes doivent donc se retrouver dans chaque maquette, rendant impratique l’approche du fichier unique. Le risque d’erreur et d’omission apporté par le besoin de copier les notes entre les fichiers est trop élevé.

Il fut déterminé qu’il fallait pouvoir accéder aux notes spécifiques d’autres cahiers de plans que celle de la maquette courante tout en s’assurant que l’information reste constante. Mais aussi que les cahiers de plan et les informations contenues dans ces derniers ne devaient pas être modifiables suite à leur émission. En gros qu’une note déjà émise ne devait pas être réutilisable à d’autres fins pour des cahiers de plans toujours en conception et sujets à changements.

Processus de travail 

  1. Chaque équipe responsable d’un projet a accès à son propre fichier Excel qui lui est exclusif. D’ordre général au plus 2 ou 3 personnes par équipe ont la tâche d’ajouter des notes au fichier, les risques de chevauchements sont donc grandement réduits. La coordination se fait également facilement au sein d’un petit groupe d’usagers typiquement dans le même bureau satellite.
  2. Une fois les modifications apportées le fichier individuel est sauvegardé et la personne responsable ouvre le fichier Excel “MASTER” dans lequel tous les cahiers sont colligés automatiquement à l’ouverture. Un script de sauvegarde vient ensuite consolider toutes les informations contenues dans les différents onglets avant d'exporter le tout dans un fichier texte unique.
  3. En rechargeant ce fichier de notes d'identification dans Revit toutes les notes deviennent accessibles selon le classement prédéterminé. Le préfixe de cahier de plans étant ajouté à chaque ligne de note, l’organisation par projet est possible.

Voici un schéma illustrant le processus d’utilisation des fichiers dans deux maquettes différentes comportant des cahiers de plans individuels et partagés.

Notes Phase 2.5 -
Plateforme Web et Desktop connector

Dans la foulée du confinement et du travail à distance, une opportunité d’amélioration s’est présentée. Depuis la dernière migration de plateforme le maquettes sont hébergées sur BIM360 DOCS, ce qui nous donne aussi la possibilité d'y déposer des fichiers d’autres formats que les maquettes. Le logiciel complément Autodesk Desktop Connector nous permet d’accéder à ces fichiers par un chemin Absolu, ce qui est requis pour les accès aux fichiers de notes par de multiples usagers décentralisés. 

Le transfert depuis Excel vers Google Sheets pour la rédaction des notes d’identification amène plusieurs avantages notables au déploiement à grande échelle. 

  • La possibilité de modification par multiples utilisateurs de manière simultanée.
  • La visualisation des changements effectués par chaque usager en temps réel.
  • Un accès simple sur de multiples plateformes.
  • Un contrôle des strict des accès en plusieurs niveaux de permissions.
  • Système d’historique des changements et de restauration robuste.

Le fichier Excel central est ensuite connecté à chaque section individuelle de notes par une série de requêtes. Les données consolidées sont ensuite exportées en format texte pouvant être utilisé par Revit. 

L’accès par le Desktop Connector se fait par la suite relativement sans difficulté même si l’occasionnel problème de connexion se présente. La situation se règle assez facilement au niveau de chaque usager par une simple déconnexion du fichier et un rechargement des notes dans Revit.

Pistes d’amélioration et conclusion

En gros l’analyse de la progression du schéma de travail des notes d’identification du projet NCH nous montre clairement au moins une chose. L’échelle des projets influence drastiquement les méthodes de réalisation jusque dans les plus petits détails. Les aspects de projets conventionnels que nous croyons maîtriser et prenons pour acquis peuvent soudainement devenir inadéquats lorsque confrontés à l’échelle d’un besoin démesuré.

L'interaction entre les multiples phases et composantes du projet jumelé aux différentes réalités des bureaux satellites a rapidement dépassé la capacité du système initial. C’est devant ces défis souvent inattendus que les équipes responsable du BIM sur un tel projet réussissent à innover tout en restant dans le cadre donné et avec les outils disponibles.

Naturellement, les solutions choisies sont adaptées aux besoins rencontrés et varient de projet en projet. Dans le cas qui nous concerne, elles changent même tout au long d’un même projet. 

En fin de compte, cette manière de gérer les annotations aux plans a permis à de multiples usagers de concerter leurs efforts de documentation et de minimiser les risques associés aux émissions rapides. En se référant à une procédure d’utilisation unique et simple, tous les utilisateurs ont pu contribuer à la documentation des plans, peu importe leur niveau d’aptitude avec la modélisation ou le dessin.

La flexibilité lors de l’analyse des besoins et des outils disponibles assure une réponse adéquate, peu importe l’ampleur du projet.


Arthur Grenier
Spécialiste BIM, BIM One


Steve Sénéchal
Gestionnaire BIM, BIM One

En cliquant sur S'ABONNER, je reconnais avoir lu et accepté la politique de confidentialité.