CHAPITRE II. CONCEPTION ARCHITECTURALE 2.1. Le client ordinaire Il commande en
CHAPITRE II. CONCEPTION ARCHITECTURALE 2.1. Le client ordinaire Il commande en général un petit bâtiment, ignore les contraintes de la construction, le rôle qui lui incombe dans la définition de la commande et ce qu’il peut attendre de l’architecte. Celui-ci doit donc l’informer et en même temps se substituer largement au client pour définir la commande. 2.2. Le client habitué Il passe le plus souvent une succession des commandes pas nécessairement de même nature, mais toutes liées à un même domaine d’activité (succursales, bâtiments d’extension, réhabilitations successives,…). Il acquiert au cours du temps une certaine connaissance des modalités de travail et des compétences d’un architecte avec qui il noue une relation de travail qui leur permet à l’un et à l’autre de se communiquer rapidement l’essentiel pour une nouvelle commande. 2.3. Le client expert Il a non seulement l’assurance qu’il sait précisément ce dont il a besoin, mais il se sent compétent pour l’organisation du processus de construction. Il s’agit le plus souvent d’un maître d’ouvrage public chargé d’un vaste programme de construction (ensembles de logements, rénovation urbaine, hôpital,…). Il s’appuie souvent sur les compétences d’architectes qu’il emplie dans son organisme pour définir des programmations élaborées avant de passer la commande à l’architecte. Ce type de client contribue à l’explication claire 2.4. Le client extra-ordinaire Il cherche à construire un bâtiment qui se distingue manifestement d’une manière ou d’une autre : par sa taille, sa complexité, le prestige qui s’y attache ou par la valeur symbolique de sa fonction dans la cité. Il est alors, en général, nécessaire que l’architecte et le client consacrent des efforts de recherche particuliers pour la définition de la commande. 2.5. La programmation architecturale Elle définit la méthode scientifique dans les termes suivants : elle consiste en principes et procédures utilisés dans la poursuite systématique du savoir accessible à la communication intersubjective imposant les conditions nécessaires suivantes : - La reconnaissance et la formulation d’une problématique ; - Le rassemblement d’informations par l’observation et éventuellement l’expérience ; - La formulation d’hypothèses ; - La mise à l’épreuve en vue de la confirmation de l’hypothèse formulée. La démarche traditionnelle de résolution des problèmes d’architecture telle qu’elle se conçoit suit un cheminement parallèle : - Définition ; - Établissement des objectifs ; - Rassemblement des informations ; - Analyse du problème ; - Examen des solutions ; - Résolution du problème : établissement du projet. Les premières étapes de ce processus ont pour objectif d’aboutir à un problème correctement formulé et les dernières à la résolution du problème. En matière d’architecture, il est apparu souhaitable de bien distinguer entre ces deux phases et de les analyser chacune plus finement. a) La programmation Appelons programmation, la phase de clarification de l’énoncé du problème et élaboration du projet la recherche aboutissant à une solution du problème. Il est bien clair que l’une et l’autre font font partie de la conception architecturale et tout aussi clair qu’elles sont distinctes et que la programmation du projet précède son élaboration. La programmation peut être conduite selon un schéma adapté de celui qui a été évoqué plus haut afin de tenir compte de l’importance d’une clarification des besoins à satisfaire. Elle consistera très schématiquement en cinq phases : - Définir les objectifs ; - Rassembler et analyser les données ; - Mettre au jour te tester des concepts ; - Déterminer les besoins ; - Énoncer le problème. La programmation constitue donc une phase d’analyse. L’ordre des étapes dans cette analyse n’est pas nécessairement rigide comme ce serait le cas pour un algorithme mais l’énoncé du problème constitue nécessairement la dernière étape. Cette analyse, quand il s’agit d’un problème d’architecture, doit prendre à chaque phase les quatre domaines distincts suivants en considération : les fonctions, les formes, l’économie et la durée. Les objectifs sont destinés à permettre à l’architecte de savoir ce que veut réaliser le client et pourquoi il le veut. Les objectifs doivent être cohérents avec les concepts ; en effet, les objectifs sont des finalités et les concepts des moyens pour les atteindre. Les concepts ne sont bien entendu que des idées mais au niveau de la programmation, ce sont des idées relatives à des solutions en termes fonctionnels ou en termes d’organisation répondant aux préoccupations du client. L’analyse des données relatives au contexte économique, physique et à l’environnement du projet est une nécessité élémentaire, mais il faut prendre garde à ne pas se laisser envahir par des données inutiles et s’attacher à n’utiliser que l’information directement utile pour la confrontation des objectifs et des concepts et en vérifier la justesse ou vraisemblance. Les concepts de programmation ne doivent pas être confondus avec les concepts du projet qui sont des types de réponse en termes de construction à des problèmes de programmation. Douze concepts de programmation semblent susceptibles de se présenter dans un grand nombre de projets : - Le groupement des services ou leur éclatement ; - le groupement des personnes ou leur dispersion ; - L’interaction spatiale ou la ségrégation des activités ; - La priorité ; - Le réseau de relations entre les espaces ; - Les contrôles de sécurité ; - La flexibilité du bâti sous les trois espèces de : la capacité d’agrandissement, la possibilité de transformation interne, et la pluri-fonctionnalité ; - Les chemins suivis par des flux différents ; - La capacité d’orientation ; - Les économies d’énergie. Cette phase de programmation est une phase de clarification de la demande estimée à permettre à l’architecte d’aider le client à expliciter sa demande en lui faisant approfondir ses raisons (les besoins et les objectifs) et ses implications en termes de concepts de programmation. Il est donc nécessaire que le client soit le plus possible impliqué dans les choix successifs qui se présentent sur l’arbre de décision. Cette dernière expression qui tire son origine de la théorie des graphes indique un processus de décision sans feedback : on ne revient pas en arrière sur une décision. Par ailleurs, plus le client est amené à effectuer de choix, plus l’espace des solutions à envisager est réduit et plus le risque de se perdre dans les données de l’analyse se réduit. Il est donc de l’intérêt économique de l’architecte de susciter le plus possible la prise de position du client au cours de la programmation. Restent à déterminer les besoins, c’est-à-dire à confronter les concepts de programmation retenus et les moyens financiers disponibles. Cela repose sur une série d’estimations grossières fondées sur l’application des ratios normalisés de surface ou de volume de construction par des fonctions et sur des estimations des barèmes de coûts liés au site, à la qualité du bâtiment et à la densité d’occupation du sol prévus. b) La conduite de l’opération On peut décomposer la conduite d’une opération en un certain nombre de phases successives : la Programmation (P), l’Élaboration Schématique du Projet (ESP), l’Élaboration Finale du Projet (EFP), les Détails d’exécution (DE) et la Construction (C) : soit : La phase de conception à proprement parler est : Celle-ci se divise en deux phases distinctes : la programmation et l’élaboration du projet. Toutefois, W. Pena envisage que des phases de programmation alternent avec des phases d’élaboration du projet sur le modèle suivant par exemple : P ESP EFP DP C Conduite de l’opération P EST EFP Conception Programmation Elaboration sommaire du projet Programmation fine Elaboration finale du projet Décrite en ces termes, cette méthodologie semble laisser dans l’ombre une partie essentielle du processus de conception, à savoir l’élaboration du projet lui-même. En fait, ce n’est pas tout à fait vrai car la mise la mise ne place d’un système d’énoncés très précis portant sur des fonctions, les formes, les coûts et la durée tend à réduire considérablement le domaine d’incertitude au moment de l’élaboration du projet de construction. La traduction des concepts de programmation en concepts de projet de construction tend à transformer la phase de synthèse et l’exploitation d’un nombre limité de puzzles techniques et géométriques. D’autre part, l’énoncé des objectifs, s’il a été correctement conduit, doit être empiriquement opératoire et fournir les critères d’évaluation des solutions proposées. L’architecte dispose donc au terme de l’élaboration du programme non seulement d’un instrument de traduction des attentes de son client dans des termes directement utilisables par lui mais aussi d’une batterie de tests empiriques lui permettant de s’assurer dans des termes irrécusables par le client de la pertinence de toutes les propositions que comporte son projet. Réduit à son squelette logique le plus élémentaire, ce processus ramène à trois phases de résolution du problème architectural : c) La critique de Kent Spreckelmeyer Un effort important a été fait par de très nombreux auteurs pour préciser les méthodes d’explication des objectifs, de recueil des données, de construction des normes de besoin sur des bases empiriques. La psychologie du comportement y a trouvé matière à de nombreux travaux de recherche et un corpus efficace de connaissance s‘ en est dégagé. Des agences d’architecture utilisant ces méthodes ont pu effectivement réaliser des bâtiments très nombreux et uploads/Ingenierie_Lourd/ chap-2.pdf
Documents similaires
-
22
-
0
-
0
Licence et utilisation
Gratuit pour un usage personnel Attribution requise- Détails
- Publié le Nov 03, 2022
- Catégorie Heavy Engineering/...
- Langue French
- Taille du fichier 0.0924MB