Retour d’expérience: Gare Saint Denis Pleyel, quand un façadier s’associe avec un éditeur de logiciel

Auteur : Nicolas Senemaud
Senior Solution Architect chez CATIA Hub 3DDT

DOI : https://doi.org/10.48568/919c-y064

[Résumé :La gare Saint Denis Pleyel est une des plus importante du Grand Paris dont l’ouverture est prévue pour les jeux Olympiques de Paris 2024. L’entreprise Aldowa est en charge de concevoir, fabriquer et installer les 77000 m2 de façade intérieure avec plus de 1000 types de panneaux sur 7 niveaux. Pour cela, l’entreprise devait modéliser l’ensemble des panneaux avec leur structure a un niveau de détails élevé permettant d’assurer la coordination avec les autres corps d’état mais également d’organiser la fabrication dans l’atelier et l’installation sur le chantier. Pour relever ce défi, l’entreprise s’est associée avec l’éditeur de logiciel Dassault Systèmes, en charge de mettre en place un Outil automatisé permettant de créer le jumeau numérique de la façade intérieure. Reposant sur une solution architecture complexe, cet Outil devait pouvoir générer l’ensemble des configurations de panneaux tout en assurant les différentes étapes de validation. Cet article décrit l’Outil mis en place d’un point de vue technique, analysant sa complexité et décrivant l’architecture solution sur laquelle il repose. Il s’agira également d’observer comment les méthodologies de collaboration ont été essentielle à sa mise en place.]

[Abstract : Saint Denis Peyel station is one of the largest new Grand Paris station planned to be open for the 2024 Paris Olympics. Aldowa, a Dutch façade company, is in charge of fabricating and installing all the interior panels of the Station. Composed of 7 levels, the Station has more than 7700m2 of interior facade with more of 1000 unique panel types. Aldowa had to model all the interior walls, creating for each component fabrication and installation documentation. All this information had to be centralized in a Bill of Material to keep track of the quantity takeoffs to organize the fabrication in the workshop and the installation on site. To answer this challenge they decided to work with the software provider Dassault Systemes to help them implement automated workflows to create digital twin of the interior façade. Dassault Systemes therefore developed a digital Tool that could generate the detailed structure for all the interior curtain walls, covering all possible configurations. This article illustrates how the Tool was developed from a technical standpoint, analyzing its complexity and the architecture solution it relies on. It also describes how critical collaboration methods were to its development.]

Contexte projet 

La gare de Saint Denis Pleyel est une des plus importantes du Grand Paris. Elle accueillera 4 lignes de métro à une profondeur de plus de 50 mètres sous terre. Composée de plus de 7 étages dont 4 sous terrains, cet ouvrage est un des plus complexes par sa proximité avec les centres urbains (paris, Saint Ouen, Saint Denis) et son aspect multi modal. Sa livraison est prévue pour les Jeux Olympiques de Paris en 2024. 

Le Projet

L’entreprise Aldowa (basée en Hollande) étant en charge du lot de façade intérieure, doit fabriquer, livrer et assembler plus de 7700m2 de panneaux d’ici 2024. Si les panneaux ne présentent que peu de complexité en eux même, le système de fixation l’est bien plus. Beaucoup de configurations différentes sont à prendre en compte en fonction des différentes profondeurs de plenum, charges (mobilier), ouvertures (trappes, portes) et angles. Dassault Systèmes via sa cellule service CATIA Hub a aidé l’entreprise à automatiser la modélisation de la maquette numérique en prenant en compte l’ensemble de ces scenarios de variabilité. Avec plus de 5000 panneaux dont 1000 uniques, nous avons dû mettre en place une méthodologie qui permette de sécuriser la génération de la maquette mais aussi des dessins d’assemblage et de fabrication quel que soit leur configuration. Toutes ces données (3D, 2D, Excel, metadata) doivent être répertoriées selon une nomenclature spécifique permettant une meilleure traçabilité dans la base de donnée (évitant les doublons) et une meilleure collaboration avec l’entreprise générale et l’architecte. La maquette numérique une fois générée va donc servir comme support de collaboration mais également la fabrication anticipant les achat/commandes, ressources et planning d’atelier. ¹

Avec la forte digitalisation des pratiques en AEC², il est de plus en plus classique pour une PME de faire appel à un Virtual Maker³ pour automatiser les méthodes et processus. Cependant collaborer directement avec un éditeur logiciel dans le cadre d’un projet est plus rare. Cet article expliquera comment ce partenariat avec le CATIA Hub a influencé les méthodes et outils de travail dans le contexte du projet de la Gare Saint Denis. Il exposera dans une premier temps l’architecture solution générale de l’Outil⁴ mis en place ainsi que les challenges techniques associés. Puis nous essayerons d’analyser comment son développement a aussi été un défi en termes de collaboration. Nous terminerons sur les leçons tirées par Dassault Systèmes en tant qu’entité de service mais aussi en tant qu’éditeur logiciel.

Figure 1: Vue de la Maquette Numérique des panneaux intérieurs. Le volume des panneaux étaient modélisés sur Solidworks. L’Outil les prenait en données d’entrée pour générer l’ensemble de la structure.

Figure 2 : Décomposition du système de fixation des panneaux

Figure 3: Détail d’un des configuration de la structure des panneaux

Le processus

La mission du CATIA Hub était de délivrer un Outil permettant à Aldowa de générer les panneaux et leur structure à partir de données IFC venant de Revit et SolidWorks. Il devait permettre à l’utilisateur de cliquer sur le(s) mur(s) à générer, choisir le type de mur et instancier⁵ les différents éléments de structure.  Ce processus apparemment simple repose sur une architecture solution complexe car elle doit être flexible, séquentielle (passant par les différents LOD⁶ ) tout en restant robuste (gestion de toutes les configurations de mur). Aldowa récent utilisateur de la 3DEXPERIENCE⁷ , devait pouvoir utiliser cet Outil se basant sur le logiciel CATIA⁸

Cette architecture solution se base sur deux mécanismes principaux : La factory (l’interface utilisateur permettant de sélectionner les murs à générer et faisant le lien entre tous les sous-mécanismes d’automatisation) et Le template⁹ de mur (famille adaptative paramétrique supportant toutes les configurations présentes dans le projet). 

Via la factory, l’utilisateur choisit le(s) mur(s) à générer et calcule automatiquement la distance du plénum entre les panneaux et la structure béton via une action EKL¹⁰ et VB¹¹ (étape 2 de la figure 6). Cette distance définit la bonne configuration de structure à instancier (voir GIF). Elle est interprétée par le template qui une fois instancié va générer d’abord un squelette paramétrique filaire (étape 3 de la figure 6) puis une version LOD200¹² de la structure ainsi que les dessins d’assemblage avec annotations, dimensions, niveaux et axes (étape 4 de la figure 6). Ces géométries sont dans une seule part¹³  et non un assemblage ce qui permet de compacter l’information dans une seule représentation et évite de surcharger la base de données. Une fois vérifiées et validées, l’utilisateur active une seconde fonctionnalité du template qui crée la représentation LOD400¹⁴ du mur où chaque objet (rail, fixation, panneau) est exposé comme une part dans la base de donnée (étape 5 de la figure 6). Les interfaces (réservations, perforations) sont générées ainsi que les dessins de fabrications. Cette représentation très détaillée est destinée pour la fabrication (nomenclature, dessin d’atelier), trop lourde pour de la collaboration. Un processus de Reuse (identification de doublons) est aussi mis en place permettant de détecter si un rail par exemple est déjà présent avec les mêmes propriétés (percements, type, longueur) dans la base de données. Cela permet de réutiliser les objets déjà présents en base au lieu de recréer une référence unique (plus coûteux en performance). Ces différentes représentations (squelette paramétrique, LOD200 et LOD400) sont agrégées dans un seul assemblage (Figure 5), ce qui permet de facilement passer de l’une à l’autre et de mieux gérer les liens entre elles. Ce système en « poupée russe » a été clé pour valider le résultat de l’outil étape par étape. 

Figure 4: Démonstration d’ instanciation des différentes configurations de structure portantes des panneaux en fonction de la profondeur de plenum. Plus la distance était grande, plus la structure était importante.

Figure 5: Structure en « poupée russe » du template. Pour chaque instance, un contenant est créé qui contiendra les trois types de représentations :  le squelette paramétrique, la représentation LOD200, et la représentation LOD400. Ce modèle d’assemblage est le même quel que soit les configurations, le nombre de panneaux et leur type ce qui permet.

Figure 6: Etapes d’utilisation de l’Outil

Figure 7: Vidéo de démonstration de l’Outil.

Le Défi de l’automatisation 

Lorsqu’un Outil d’automatisation comme celui-ci est développé en cours de projet, son temps de développement devient un enjeu critique. Il dépend de 4 paramètres principaux : Taille du projet (bâtiment de 3/10/50 étages ?)  Granularité des objet générés (LOD200, LOD400 ?), Variabilité des configurations (5,10,15 configurations différentes ?), niveau d’automatisation (interface utilisateur OutOfTheBox ou custom ?)  et peut être résumée ainsi : TpsDev = Granularité x taille de projet x # de configurations x  % automatisation. Chacun de ses paramètres ont un impact très important sur le temps de développement et doit être soigneusement sous pesé afin de respecter le calendrier de projet. 

Dans le cas du projet, nous avons dû être attentifs à certaines configurations qui étaient trop spécifiques dans le projet et avons préféré ne pas en couvrir certaines. Les cas non couverts par l’Outil doivent néanmoins être modélisés manuellement par les équipes de projeteurs d’Aldowa. La balance modélisation automatisée / modélisation manuelle rentrait elle aussi en ligne de compte, l’Outil devant permettre d’automatiser au moins 70% des murs présents dans le projet. Il s’agit alors de faire la différence entre comportement standard et spécifique des murs afin de les intégrer ou non dans le template. 

Cependant beaucoup d’exceptions (ex : rajout ou modification de structure de manière locale à un mur) étaient à prendre en compte. Des mécanismes ont dû être rajoutés afin de donner la flexibilité à l’utilisateur de pouvoir rajouter/modifier certains éléments comme des rails ou des attaches. L’utilisateur peut par exemple rajouter manuellement des éléments de structure en créant de simples points ou lignes directement sur le mur. Ces informations sont prises en compte par le template qui retirera ou rajoutera des rails en fonction. Bien qu’ils rajoutent à la complexité de l’Outil, ces mécanismes hybrides automatiques/manuels sont une manière de répondre à la très grande variabilité de configurations dans ce projet. Templatiser 100% des configurations possibles aurait été chronophage (voire impossible) mais surtout inefficace compte tenu que les solutions techniques et leurs spécifications ne cessent d’évoluer au cours des projets. 

Figure 8 : Vue du Squelette paramétrique du template sur l’application de programmation visuelle CATIA xGenerative Design. Un filaire est généré positionnant tous les éléments (rails, pattes de fixation, panneaux) avec leurs propriétés (type, longueur, réservation, matériau…)

Figure 9: Logigramme représentant  le« pseudo code » xGenerative Design générant le squelette paramétrique. Les opérations en gris processent les données d’entrée, les opérations en bleu génèrent les panneaux, en rouge les rails et en vert les pattes de fixation. Au total le configurateur peut supporter 96 configurations de panneaux différentes

Une desilotation nécessaire 

A mesure que l’architecture de l’Outil s’affinait, le projet pourtant en phase EXE continuait d’évoluer. Cela poussait Aldowa à revoir les solutions techniques préconisées (renfort de structure par endroit) et à en développer de nouvelles dans certains cas (nouvelles configurations). Ces évolutions constantes en cours de projet impactent naturellement le développement de l’Outil qui repose sur une architecture complexe avec de nombreux mécanismes interdépendants. Certaines configurations devaient donc être reprises en profondeur, ce qui a des étapes avancées du projet pouvait avoir une incidence sur la stabilité de l’Outil, impliquant plus de tests nécessaires.

A cela s’ajoute les discontinuités propres aux projets de construction ou les étapes de validation peuvent être asynchrones (ex : solution technique en cours de validation par le bureau de contrôle, attente des Maquettes Numériques sous-traitants). Ces discontinuités provoquent des temps morts également au niveau du développement de l’Outil ce qui contenu de sa complexité pouvaient être difficile à gérer. Les équipes du CATIA Hub devaient donc moduler le temps passe sur le projet tout en assurant la continuité et la cohérence du développement de l’Outil malgré les temps morts. 

Dans l’industrie automobile par exemple, les cahiers des charges sont définis en amont et représentent la feuille de route du développement d’une solution customisée. Chaque modification des spécifications/exigences, donne lieu à une modification de contrat impactant le coût de la prestation, temps de livraison etc. Ce modèle parait rigide pour l’AEC où les projets continuent d’évoluer en phase EXE mais garantie la qualité des livrables. Lorsque de nouvelles spécifications arrivaient en cours de développement, il était difficile de savoir rapidement si elles rentraient en conflit avec d’autres spécifications existantes. Afin d’éviter les erreurs, nous avons dû tester l’Outil après chaque modification. Cela impliqua un investissement humain plus important mais nécessaire afin d’être certain de couvrir toutes les configurations demandées de murs.  L’intensification des échanges ne put se faire que parce que les deux équipes modélisaient, testaient, validaient et échangeaient sur la même plateforme cloud. Les modifications de l’Outil étaient instantanément appliquées sans perturber son utilisation. La plateforme accueillait non seulement les données mais aussi les échanges quotients via un réseau social interne (communauté 3DSwym, figure 10) permettant de tracer les échanges, les rapports de clashs, listes de requis etc. jusqu’à se passer des emails. Le support R&D de Dassault Systèmes avait également accès à cette communauté et orientait les équipes en cas de difficultés techniques. Cela leur permettait d’être plus réactifs sur d’éventuels correctifs ou améliorations à apporter sur les applications OOTB¹⁵. Cette triangulation CATIA Hub, Aldowa et R&D Dassault Systèmes nous a permis de développer une solution complexe tout en évitant les point de blocages techniques. C’est cette intensification des échanges qui a poussé chacun des acteurs à sortir de son silo : Aldowa participait activement à la création de ce qui allait être un Outil digital de capitalisation de son savoir-faire, et Dassault Systèmes se devait d’être plus réactif face aux modifications de cahier des charges de l’Outil et de comprendre les problématiques de construction qui lui étaient inhérentes.  

Figure 10: Réseau social de la 3DEXPERIENCE, la communauté SWYM centralisait tous les échanges avec Aldowa, le CATIA Hub et la R&D de Dassault Systèmes

Conclusion 

Après 14 mois de collaboration, les premiers profiles ont été livre sur le chantier. L’Outil a permis de d’automatiser 70% à 80% de la structure des 7700m2 de panneau de la gare. Le processus séquentiel (LOD200-400) et le modèle d’assemblage (en « poupée russe ») a permis de valider la modélisation étape par étape la tout en garantissant la qualité des informations et des géométries générées.  C’est également un Outil sur mesure, taillé pour que n’importe quel employé d’Aldowa puisse l’utiliser tout en contrôlant certaines options (ex : génération des dessins) et paramètres (ex : distance min/max entre deux profiles). La création de cet Outil a d’abord été un défi technique pour le CATIA Hub. Composé de 51 scripts EKL, 9 scripts VB et 2 scripts en programmation visuelle de plus de 2500 opérations, l’architecture de l’Outil a dû être pensée et affinée afin qu’il soit efficace (supporter toutes les configurations avec le bon niveau d’information) et utilisable (économie de performance de calculs). Ne pas connaitre toutes les configurations possibles dès le début du projet a poussé le CATIA Hub a trouvé une architecture solution qui puisse être évolutive mais qui impliquait plus de test. Ça a également été un défi en matière de collaboration. Le CATIA Hub jusqu’à la plutôt habitué à des projets dans l’aéronautique ou l’automobile s’est adapté à la culture projet AEC, avec une temporalité beaucoup plus courte et des aléas fréquents même en phase EXE. Le CATIA Hub a dû être plus réactif, prenant part avec le client a la définition des structures. Cela a aussi poussé Dassault Systèmes à trouver d’autres modes contractuels basées notamment sur le résultat du service¹⁶ plutôt qu’au temps passé, permettant de mieux gérer les temps morts tout en garantissant la qualité des livrables. 

 La création de cet Outil ad hoc fut donc empirique mais n’aurait pas été possible sans une collaboration (et confiance mutuelle) forte. Le fait de travailler dans une plateforme avec une seule base de donnée partagée (Common Data Environnement) a permis de tracer l’ensemble des échanges (demandes de correction/modification, question, documentation) tout en accélérant les tests et le développement de l’Outil. Il a également fallu que les deux partis comprennent les enjeux et challenges de d’un et de l’autre afin d’avancer sur un calendrier réaliste.  

Nous pensons que cette collaboration aurait été encore plus efficace si elle avait été étendue à l’ensemble du groupement, plus en amont du projet. La double casquette des éditeurs logiciels (développement logiciel + entité de service) leur permettrait alors d’agir comme un intégrateur qui développerait des Outils métiers spécifiques pour certains co-traitants, tout en centralisant les données pour l’ensemble du groupement, administrant les licences, monitorant les révisions de maquette, répertoriant les clashs, autant de chose que les prestataires VDC/BIM font mais sans l’infrastructure R&D et support client. Des plus les retours d’expérience du CATIA Hub a la R&D de Dassault Systèmes ont permis d’améliorer les applications utilisées pour ce projet (plus de 10 demandes d’évolutions ont été faites). Dans l’industrie aéronautiques, de nombreux OEMs¹⁷ jouent déjà ce rôle d’intégrateur parmi leurs sous-traitants mais ce schéma est-il applicable en construction ? Certaines entreprises comme Bouygues Construction¹⁸ en font le pari, mais cette approche de design intégré nécessite forcément un changement de paradigme quant à la manière de collaborer, clé pour pouvoir suivre la complexification de la digitalisation des projets en construction.

Contributeurs CATIA Hub : Renaud D’ANDRE, Pross CHENG, Nicolas SENEMAUD

Contributeurs Aldowa : Misja VAN HATTUM, Bas HAGE

1. Cellule de Dassault Systèmes spécialisée dans les services liés à l’automatisation des processus
2. Architecture Engineering Construction, industrie BTP
3. Sous-traitant spécialisé dans le service BIM/Design computationnel. 
4. L’Outil dans cet article représente la solution permettant de générer l’ensemble des configurations des structures et des panneaux
5.  Action d’appliquer un template à des données d’entrée spécifiques. Le template est le configurateur comportant toutes les configurations possibles d’un système. Une instance est le résultat une fois le template instancié avec des données d’entrée spécifiques. Plus d’information sur le processus d’instanciation sur la chaine Youtube CATIA AEC : https://www.youtube.com/watch?v=YlKcPutK3SY&t=748s
6. Level Of Development. Niveau de détails standard BIM : https://www.structuremag.org/?p=558
7. La 3DEXPERIENCE est la plateforme collaborative lancée par Dassault Systèmes en 2012. Des applications associées partageant la même base de données permettent des modéliser, simuler, partager, des modèles/données.
8. Premier modeleur solidien crée en 1981 par Dassault Aviation. Connu pour sa robustesse permettant la création d’assemblages complexes à des niveaux de détails élevés, CATIA deviendra le standard dans l’ingénierie mécanique avant d’être utilise en AEC dans les années 90. Dans cet article nous avons utilisé les applications CATIA disponibles sur la plateforme 3DEXPERIENCE Cloud : https://www.3ds.com/cloud/virtual-construction-twin-3dexperience
9. Composant génératifs pouvant s’adapter à différentes données d’entrées.  (Equivalent de Famille dans Revit)
10. Entreprise knowledge language langage de programmation propriétaire CATIA.
11. Visual Basic , langage de programmation
12.  Niveau de détails de modélisation intermédiaire permettant la validation ou détection de clash. Tous les objets sont modélisés dans un seul et même fichier (Part), considérés comme un seul et même objet.
13.  Une part est une représentation 3D. Elle peut contenir une ou plusieurs géométries, des dessins, des propriétés (elle peut être comparée à un fichier 3dm sur Rhinocéros).
14. Niveau de détails de modélisation avancé dédié à la fabrication. Chaque objet est une part avec des attributs propres (IFC, dessins de fabrication, localisation). La structure devient un assemblage de parts.
15. Out Of The Box , fonctionnalités de base d’un logiciel 
16. https://www.3ds.com/consulting-services-value-engagement/outcome-based-engagement 
17. Original Equipement Manufacturer, Fabricant d’équipements d’origine.
18. https://www.3ds.com/fr/insights/customer-stories/bouygues-construction