Combien d'heures votre équipe passe-t-elle à copier un PFT dans Revit?
J'ai passé une bonne partie de ma carrière à regarder des architectres retaper des programmes dans des tableaux de superficies, puis dans Revit. Pas par choix. Parce que c'est comme ça qu'on fait, depuis toujours, dans à peu près toutes les firmes que je connais.
Le scénario est toujours le même. Un nouveau projet démarre. Dans les intrants on a le programme fonctionnel et technique, un beau document de plus de 2000 pages monté selon la méthodologie du MSSS ou les exigences de la SQI. Dedans, tout est là : les besoins, les unités fonctionnelles, les fiches de locaux, les superficies nettes cibles, les exigences techniques par pièce. C'est structuré, c'est rigoureux, c'est complet.
Et c'est en PDF.
Alors quelqu'un dans l'équipe ouvre Excel, et le travail de moine commence.
Le PFT est une base de données déguisée en document
Prenons un projet de 800 locaux. Chaque local a un code, un nom, une superficie cible, une unité fonctionnelle, plus une dizaine d'exigences techniques : finis, ventilation, prises électriques, équipements, TIC. Ça fait beaucoup d'information. Toutes déjà rédigées, validées, approuvées par le client.
Revit a besoin de plusieurs de ces données pour faire son travail. Mais Revit ne lit pas les PDF. Il attend des paramètres partagés de pièces, bien nommés, bien typés.
Entre les deux, il y a un être humain avec deux écrans (ou 3 maintenant). À gauche le PFT, à droite Excel. Copier, coller, nettoyer les cellules fusionnées, refaire les sous-totaux, mapper les colonnes vers une autre feuille pour permettre l'export Excel vers Revit, importer dans le modèle, réexporter, vérifier les concaténations et les RECHERCHEX... Pour un projet de cette taille, comptez une à deux semaines. De la pure transcription. L'information existait déjà, on l'a juste déplacée.
Ça, c'est la partie facile. Parce qu'au moins, on ne la fait qu'une fois.
Puis arrive la révision 2 du Programme
Le MSSS le dit lui-même dans ses guides : l'élaboration d'un PFT est un processus itératif. Traduction concrète : le programme va changer. Peut-être plusieurs fois.
La version 2 arrive par courriel un jeudi après-midi. Soixante locaux modifiés, douze ajoutés, huit retirés. Lesquels exactement? Bonne question. Le document ne le dit pas toujours. Alors on vérifie le Excel, on met les deux versions du programme côte à côte (belle utilisation de l'IA si vous ne l'avez jamais essayé), on compare ligne par ligne, on surligne en jaune, on reporte les changements dans le modèle, on revérifie.
Sur un projet de centre culturel, j'ai déjà vu ce cycle 8 fois. Et chaque fois, le risque est le même : un changement qui passe entre les mailles. Le local 2.145 qui a été renuméroté dans le PFT mais pas dans Revit, et voilà toute une fiche de local qui pointe vers la mauvaise pièce. Personne ne s'en rend compte avant la remise en page du tableau de superficie avant la remise.
Le tableau de superficie, ce livrable qui ne meurt jamais
Le tableau des superficies n'est pas juste un outil de travail interne. C'est un livrable administratif de contrôle du projet demandé par les clients. À chaque jalon, concept, préliminaire, définitif, il faut démontrer au client que ce qu'on a dessiné respecte ce qui était programmé, unité par unité, avec les écarts et les justificatifs.
En pratique, ça veut dire : exporter les superficies réelles depuis Revit, les coller dans une autre feuille, reconstruire les formules d'écart et de RECHERCHEX, mettre en forme, envoyer. Le lendemain, un collègue déplace trois cloisons et le tableau est déjà faux.
J'ai vu des équipes refaire cet exercice chaque semaine pendant des mois. Deux à quatre heures à chaque fois. Faites le calcul sur 18 mois de conception.
Mettons des chiffres là-dessus
Sur un projet institutionnel typique, en étant prudent : 30 à 40 heures pour la saisie initiale, 12 à 16 heures par révision de programme, 16 à 20 heures par remise du tableau de superficie, plus tout le temps perdu à réconcilier des versions et à chasser des erreurs. On peut facilement dépasser les 100 heures par année pour un seul projet. Du temps à ne pas concevoir, à déplacer des données.
Excel n'est pas le coupable
Je veux être clair là-dessus, parce que j'aime Excel. Le problème n'est pas l'outil, c'est le rôle qu'on lui fait jouer. Excel est excellent pour analyser des données à un moment précis. Il est incapable de maintenir un lien vivant entre deux sources qui évoluent en parallèle. Chaque export crée une copie figée, et chaque copie figée est une divergence en devenir.
Lier le programme fonctionnel et technique à Revit
Ce qu'il faut, c'est traiter le programme comme ce qu'il est vraiment : une base de données centrale, connectée au modèle Revit. Les exigences saisies une seule fois. Chaque pièce du modèle liée à sa fiche programme par un identifiant stable. La comparaison programme/proposé calculée en temps réel plutôt que reconstruite à la main chaque vendredi. Un historique des révisions qui dit qui a changé quoi, et quand.
C'est le problème qu'on a décidé de régler avec RoomStack : une plateforme de programmation d'espaces avec synchronisation bidirectionnelle vers Revit, construite pour la réalité des projets d'ici. Pas parce que c'est un beau problème technologique, mais parce que ces 100 heures par année, par projet, je les ai vécues.
Si vous vous êtes reconnu quelque part dans ce texte, on cherche justement des équipes pilotes pour tester RoomStack sur des projets réels. Écrivez-nous.