Méthode de conception de produit intégrant ses services en phase conceptuelle appliquée aux projets de construction

La Programmation Architecturale

La programmation architecturale consiste à définir le cadre et les attentes d’un projet de construction sur base des exigences formulées par la Maitrise d’Ouvrage (MOA) (c.-à-d. le client) (Abdul-Kadir & Price 1995). Cette tâche incombe généralement à la MOA qui peut se faire accompagner d’un professionnel de l’Assistance à MOA (AMOA) appelé programmiste (Certu 2010). La programmation architecturale est un processus riche en informations à générer, à manipuler et à gérer (Voordt & Wegen 2005). Son but est d’informer la MOA lors de différentes phases décisionnelles du projet de construction (Kelly et al. 2002). La phase de programmation architecturale, comme toute phase conceptuelle, est basée sur une grande quantité d’informations vagues et incomplètes qu’il est nécessaire d’analyser et de clarifier (Wang et al. 2002). Macmillan propose une structuration de cette phase en deux étapes (Macmillan et al. 2001) : la première consiste à traduire les besoins métiers de haut niveau en une stratégie de conception tandis que la seconde concerne le développement de cette stratégie de conception en propositions de concepts architecturaux. La programmation architecturale se concentre sur la première étape de cette représentation de la phase conceptuelle. La programmation architecturale est reconnue comme étant l’une des phases les plus importantes dans le déroulement des projets de construction (Shen et al. 2004; Yu et al. 2005; Tzortzopoulos et al. 2006). Les études préliminaires, la programmation architecturale et les études de conception représentent près de 10% du coût total d’un projet de construction, le reste étant dédié à la construction du bâtiment (Certu 2010). Au cours de ces phases, près de 75% des coûts globaux du projet sont engagés (Faatz 2009; Certu 2010). Paulson, et plus tard MacLeamy, ont déjà démontrés que ces phases amont ont la plus grande influence sur le projet de construction tout en ayant les plus faibles coûts en termes de modifications (Paulson 1976). Il s’agit là de la meilleure opportunité d’amélioration pour un projet de construction .

Spécificités des Projets de Construction

La programmation architecturale se distingue de la phase conceptuelle des autres domaines d’ingénierie de par la nature même de son objet d’étude. Un bâtiment est défini par de nombreuses exigences et contraintes à satisfaire à un niveau social, urbain, fonctionnel, technique autant que économique, d’insertion dans le paysage et de protection de l’environnement, relatives à sa réalisation ainsi qu’à son utilisation (DGUHC & Certu 1999; JORF 2007). Tous ces éléments constituent un ensemble considérable d’informations hétérogènes, imprécises et incertaines, issues de sources multiples qu’il est nécessaire de rassembler et traiter tout au long du processus de programmation architectural (Shen et al. 2004).
La programmation architecturale se base sur une définition incertaine des besoins métiers de la MOA. Ces besoins métiers dépendent fortement du contexte local du projet de construction. La stratégie opérationnelle de la MOA qui en découle est étroitement liée aux exigences bâtiments qui sont à définir (Tzortzopoulos et al. 2006). La compréhension de cette stratégie est rarement complète, même pour la MOA qui éprouve des difficultés pour la décrire (Cooper & Press 1995; Barrett & Stanley 1999). Tout au long du projet, cette stratégie opérationnelle est également soumise à de nombreux changements et évolutions.
La programmation architecturale se confronte à de nombreux acteurs de nature complexe et manquant de coordination (Newcombe 2003; Tzortzopoulos et al. 2006) :
La MOA et ses parties prenantes représentent trois types de clients : le ‘‘client payeur’’ (dit MOA), le ‘‘client utilisateur’’ (dit utilisateur), et le ‘‘client usager’’ (dit usager). Dans le cas des bâtiments publics, ces trois entités sont représentées par des personnes bien distinctes ayant un rapport différent avec le bâtiment. Dans l’exemple d’un lycée, le MOA est le Ministère de l’Education Nationale qui finance le projet. L’utilisateur est représenté par le personnel de l’établissement (p. ex. les enseignants, le directeur, le concierge…). Ce personnel est nécessaire à la transmission de connaissance aux élèves, usagers de l’établissement.
La Maitrise d’œuvre (MOE) (c.-à-d. les concepteurs) est généralement représentée par une équipe de conception regroupant un ou plusieurs cabinets d’architectes, divers bureaux d’études et autres consultants allant de l’économiste de la construction aux experts légaux. Cette équipe de conception n’est souvent pas encore définie au moment de la programmation architecturale (p. ex. dans le cas des concours d’architecture).
Les entrepreneurs sont aussi représentés par une équipe de construction temporaire qui évolue tout au long du projet de construction. Chaque membre de cette équipe se voit assigner un certain nombre de taches interdépendantes au niveau du temps et du séquencement ce qui amène à des temps de construction longs et irréguliers (Kubicki et al. 2006).
Enfin, les bâtiments se distinguent également des autres types de produits (logiciel ou manufacturier) de par sa durée de vie relativement longue comparée à son usage intensif ainsi qu’aux coûts résultants de son cycle de vie (de sa conception à sa démolition). En général, un bâtiment a plusieurs secondes vies à travers la rénovation et la réhabilitation. De telles caractéristiques sont à prendre en compte au plus tôt dans le processus de développement de projet, ce qui impacte la phase de programmation architecturale.

Modéliser l’Objet d’Etude : Le Bâtiment en tant que Système

L’objet bâtiment est déjà considéré comme un système complexe multicouches (Bertelsen 2003). Son premier niveau de complexité s’observe sur les étapes de conception, industrialisation et construction notamment à cause des services techniques (p. ex. ventilation, air conditionné, chauffage) qui le composent (Kubicki et al. 2006). Ces travaux de recherche se focalisent sur un second niveau de complexité concernant la programmation architecturale. Cette complexité est liée à la nature bicéphale de l’objet bâtiment. En effet, un bâtiment n’est pas un objet autonome mais un système complexe séparable en deux parties : une partie statique (décrite par les concepts d’Espace et de Ressource) et une partie dynamique (décrite par le concept d’Activité).

Point de Vue Systémique

Le concept de Système est utilisé pour modéliser des objets complexes de façon abstraite afin de les rendre plus faciles à aborder. Ce concept apporte un point de départ neutre en termes de solution pour la définition et la résolution d’un problème de conception. Pour définir un système, trois concepts sont à prendre en compte : les besoins-exigences, les frontières et l’architecture (Faisandier 2011).
Les besoins-exigences font références à l’explicitation de ce qui est attendu en termes de services et de contraintes. Il s’agit du principal résultat de la définition des besoins. En programmation architecturale, ce résultat est compilé dans le programme, livrable sur lequel se base les architectes pour concevoir la partie bâtiment de ce système complexe. Cependant, ce bâtiment n’est pas suffisant pour adresser les besoins réels de la MOA. Pour comprendre les besoins réels de la MOA, le programmiste à besoin de comprendre le contexte et comment la MOA veut atteindre son but (et ses objectifs). Les besoins-exigences sont donc l’ensemble des informations concernant le domaine de définition des exigences bâtiment .

Paradigme Système Produit-Service

Dans la littérature, le Système Produit-Service est principalement associée à une notion de modèle économique (modèle d’affaire). Au lieu de vendre un produit aux consommateurs, un usage ou une fonctionnalité lui est proposé (Meier et al. 2010). L’idée est donc de développer des offres mélangeant des produits et des services pour (conjointement) satisfaire les besoins du client (Goedkoop et al. 1999). Les Systèmes Produit-Service sont classés en trois catégories : orienté produit, orienté usage, et orienté résultat (Manzini & Vezzoli 2003; Yang et al. 2009; Tukker & Tischner 2006).
Dans le cadre de ces travaux, le paradigme Système Produit-Service est utilisé comme une façon de percevoir notre objet d’étude, c.-à-d. le système bâtiment, de façon plus large qu’un simple objet physique limité au bâtiment. Ainsi, les entités physiques telles que le bâtiment, le mobilier, les équipements et les personnes (c.-à-d. les ressources qui composent ce système bâtiment) en représentent la partie Produit. Le concept de Service a deux sens dans le domaine de l’Architecture-Ingénierie-Construction qui diffèrent de celui du Système Produit-Service. Le premier concerne les services techniques du bâtiment (p. ex. ventilation, chauffage) qui donnent vie au bâtiment. Le second fait référence aux services (publics) fournit par les utilisateurs du bâtiment à ses usagers (p. ex. l’éducation fournie par les enseignants aux élèves). Ces deux sens se retrouvent dans une typologie associée au concept de Service dans le cas des Systèmes Produit-Service orientés résultat (Yang et al. 2010). Cette typologie distingue les Services Principaux des Services Supports .

Modèles Opérationnels pour une Formalisation Pratique Multi-Vue

Lors de la programmation architecturale, une quantité énorme d’informations est générée, des besoins métiers aux exigences bâtiment (Shen et al. 2004). Actuellement, ces informations sont transmises aux architectes et équipes de conception au travers du programme, un document textuel complété par quelques diagrammes dont la représentation graphique varie d’un programmiste à l’autre. La compréhension et la gestion de cette énorme quantité d’informations reste un challenge en termes de consistance, complétude et redondance.
Dans la première partie de ce Chapitre III, nous avons proposé un ensemble de modèles conceptuels pour structurer le domaine de définition au travers des paradigmes FBS et PSS. Cette seconde partie se concentre sur des modèles opérationnels (semi-formels) pour outiller de façon pratique le processus de programmation architecturale. Plutôt que de créer un nouveau modèle intégrant tous les concepts du domaine de définition, nous proposons d’utiliser les modèles existants dans les différents domaines d’ingénierie pour fournir des vues locales sur le même objet d’étude. Chaque modèle existant couvre un ensemble de concepts différents et propose un point de vue différent sur l’objet d’étude.
Cette section n’a pas pour vocation d’établir un état de l’art multidisciplinaire des modèles de représentation graphique ou de faire une analyse critique des langages de modélisation mais plutôt de démontrer l’intérêt de ces modèles et langages vis-à-vis de la représentation graphique des informations sur le système bâtiment. N’importe quel modèle de chaque domaine d’ingénierie pourrait être appliqué lors de la programmation architecturale pour autant qu’il intègre une partie des informations de son domaine de définition. D’ailleurs, il n’est pas strictement nécessaire que toutes les informations représentées par ces modèles soient présentes dans le domaine de définition. Une application partielle des formalismes de chaque modèle peut suffire à aider le programmiste ou la MOA.
Le concept de But (Objectif) est principalement modélisé dans les approches GORE (Goal-oriented Requirements Engineering) en Génie Logiciel (Giunchiglia et al. 2001; Kavakli & Loucopoulos 2003; Anwer & Ikram 2006; Lapouchnian 2005) (p. ex. Tropos, i* ou encore KAOS).Le concept de Fonction est modélisé via un certain nombre de modèles dit fonctionnels.
Chaque approche de conception systémique a sa propre définition du concept de Fonction mais aussi ses propres langages de modélisation plus ou moins opérationnels (Ross & Schoman 1977; Gero 1990; Pahl & Beitz 1995; Umeda & Tomiyama 1997; Suh 1998). Diverses recherches proposent déjà un état de l’art de ces modèles fonctionnels (Erden et al. 2008; Eisenbart et al. 2012; Eisenbart et al. 2013; Eisenbart 2014). Nous nous limitons ici à en introduire quelques-uns ayant un intérêt particulier pour ces travaux et de les positionner sur notre domaine de définition : le diagramme d’interaction (de la Bretesche 2000; Société APTE 2007), l’arborescence Fonction-Moyens (Tjalve 1978; Buur 1990; Bracewell & Sharpe 1996), le diagramme FAST (AFNOR 2000), ou encore le Bloc Diagramme Fonctionnel (Maussang 2008).
Le concept de Comportement possède également un grand nombre de langages de modélisation. Dans ces travaux, le focus est mis sur trois langages principaux : l’IDEF (National Institute of Standards and Technology 1993; Mayer, Crump, et al. 1995), le BPMN (White 2004; OMG 2011a) et l’UML (Booch et al. 1998; OMG 2011b). Chacun de ces langages intègre différents modèles plus locaux pour permettre de couvrir la modélisation de leur système respectif dans son ensemble. Le cas du BPMN est quelque peu particulier puisqu’il est déjà adopté dans le domaine de l’Architecture-Ingénierie-Construction pour représenter les processus métiers et les échanges d’informations au cours des projets de construction via l’IDM pour les usagers du BIM (Wix 2007; Weise et al. 2009; Berard & Karlshøj 2011).

Modèle Transitoire : Le Diagramme de Méta-Espace

Chaque type de méta-espaces représente un ensemble d’informations différent à différents moment du processus de programmation. Il en ressort un langage de modélisation a visée pratique appelé Diagramme de Méta-Espace. En s’appuyant sur l’abstraction apportée par le Méta-Espace, ce langage de modélisation permet d’outiller la transition d’un livrable à un autre. Ceci nous permet de formaliser ces transitions mais également d’assurer une certaine traçabilité des informations et de leurs dépendances d’un livrable à l’autre (continuité de l’information).
Un diagramme de Méta-Espace intègre les propriétés du graphe et du diagramme bulle mais utilisé dans un contexte différent et pour des objectifs différents (ceux de la programmation architecturale). L’agencement des méta-espaces composant le diagramme n’a pas d’importance. Le diagramme de méta-espace se contente de représenter de manière graphique les dépendances entre méta-espace, sachant que les méta-espaces contiennent les informations relatives aux activités qui y sont associées. Trois types de diagramme de méta-espaces sont proposées en adéquation avec les types de méta-espaces : le Diagramme de Méta-Espace Opérationnel, le Diagramme de Méta-Espace Fonctionnel et le Diagramme de Méta-Espace de Conception (ou Physique).
Le Diagramme de Méta-Espace Opérationnel est un outil d’abstraction des modèles d’ingénierie permettant de représenter les informations du programme (p. ex. IDEF0, Diagramme d’Activité, ou Diagramme d’Etat-Transition). Le diagramme de méta-espace opérationnel se débarrasse des formalismes propres à chaque modèle fonctionnel pour les résumer à un simple graphe . Les informations contenues dans ces modèles nécessites d’être conservées en arrière-plan pour une utilisation ultérieure (p. ex. lors du traitement des exigences permettant de réduire le nombre de méta-espaces avant obtention du diagramme fonctionnel). Une solution informatisée (p. ex. base de données) est à privilégier pour la conservation de ces informations. La restitution de ces informations peut se faire via différentes façons graphiques comme, par exemple, l’utilisation de couleurs ou de types de traits pour identifier des flux d’objets entre méta-espaces .
Le Diagramme de Méta-Espace Fonctionnel permet de faire le lien entre le diagramme de méta-espace opérationnel et le diagramme fonctionnel . L’obtention de ce diagramme se fait par le traitement des exigences contenues dans les méta-espaces opérationnels. Les méta-espaces opérationnels sont regroupés en méta-espaces fonctionnels sur base des règles logiques et métiers de regroupement des exigences compatibles. Le diagramme de méta-espace fonctionnel peut également se déduire du diagramme fonctionnel. Chaque espace fonctionnel s’abstrait en un méta-espace fonctionnel et leurs relations sont ensuite retranscrites dans le diagramme de méta-espace fonctionnel .
Le Diagramme de Méta-Espace de Conception (ou Physique) est utilisé pour modéliser la proposition (2D) de l’architecte. Chaque espace physique proposé par l’architecte est modélisé par un méta-espace physique et les accès entre espaces physiques sont retranscrits en lien entre les méta-espaces physiques. Le but est d’obtenir un formalisme identique entre le programme, le diagramme fonctionnel et les plans de l’architecte pour en faciliter la comparaison . La modélisation de trois propositions d’architectes sous ce formalisme facilite leur comparaison et l’identification des différences en termes d’agencement .
L’ensemble de ces trois diagrammes peut servir à outiller le processus de programmation architectural en traçant les informations issues des besoins de la MOA (c.-à-d. le programme) et retranscrites dans les projets architecturaux. Les méta-espaces sont utilisés pour modéliser des activités et des espaces tandis que les diagrammes de méta-espaces en modélisent les relations (p.ex. processus ou accessibilité entre espaces). L’ensemble de ces deux artefacts permet de formaliser la transition entre le concept d’Activité et celui d’Espace .

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Chapitre I – Contexte
1. Introduction 
1.1. La Programmation Architecturale
1.2. Spécificités des Projets de Construction
1.3. Etat de l’Art
1.4. Synthèse
2. Objectifs 
2.1. Objectifs Industriels
2.2. Objectif Scientifique
2.3. Synthèse
3. Méthodologie 
3.1. Sciences de la Conception et Recherche en Conception
3.2. Cas d’Etudes
3.3. Transdisciplinarité
4. Plan du Résumé Etendu 
Chapitre II – Décrire un Bâtiment 
1. Introduction
2. Développement de Systèmes : Vue d’Ensemble Multidisciplinaire 
3. Clarification des Concepts 
3.1. But – Pourquoi
3.2. Fonction – Quoi
3.3. Activité – Comment et Quand
3.4. Ressource – Qui/Avec Quoi
3.5. Espace – Où
3.6. Domaine de Définition
4. Synthèse 
Chapitre III – Modéliser un Bâtiment 
1. Introduction
2. Modéliser l’Objet d’Etude : Le Bâtiment en tant que Système 
2.1. Point de Vue Systémique
2.2. Paradigme Système Produit-Service
2.3. Principe d’Alignement
2.4. En Résumé
3. Un Modèle pour la Programmation Architecturale 
4. Modèles Opérationnels pour une Formalisation Pratique Multi-Vue 
5. Du Programme au Projet : Le Concept de Méta-Espace
6. Modèle Transitoire : Le Diagramme de Méta-Espace 
7. Synthèse
Chapitre IV – Définir un Bâtiment 
1. Introduction 
2. GFBS appliqué à la Définition des Besoins 
2.1. Identification de l’Environnement (étape 0)
2.2. Définition du But (étape 1)
2.3. Génération de Fonctions (étape 2)
2.4. Allocation des Fonctions (étape 3 et 4)
2.5. Décomposition des Comportements (étape 5)
2.6. Traitement des Exigences (étape 6)
2.7. Synthèse Fonctionnelle (étape 7)
2.8. Synthèse Physique (étape 8)
2.9. En Résumé
3. Instanciation sur des Vues Processus 
3.1. Vue Processus
3.2. Vue Information
3.3. Vue Collaboration
3.4. En Résumé
4. GFBS appliqué à l’Evaluation de Projets 
4.1. Analyse Fonctionnelle
4.2. Evaluation Fonctionnelle
4.3. Evaluation Quantitative
4.4. En Résumé
5. Synthèse
Chapitre V – Conclusion
1. Synthèse Scientifique 
2. Synthèse Industrielle 

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *