Document en cours d'écriture (MAJ le 12-12 2011) - Le réseau ...

DEEA IV / 2 – ORGANISATION
PÉDAGOGIQUE p3
Organisation thématique des enseignements :
(Philippe Morel : 16-11-2011)
1. Initiation à l’algorithmique
a. Enjeux (présentation générale)
Depuis 2003, date du premier workshop dédié aux logiciels de modélisation 3D à l’ENSAPM,
les cours dispensés ont évolué vers une plus grande prise en compte, dans la formation des
étudiants, de l’importance de l’algorithmique dans la modélisation architecturale. En effet, si
la maîtrise des logiciels est nécessaire, elle n’est pas suffisante. Ces derniers ont une vie
parfois chaotique (ils peuvent disparaître du marché), ils sont parfois soumis à des effets de
modes, présentent un caractère très (et souvent trop) « appliqué » et reposent sur des types
de géométrie trop précisément définis. Ceci induit une sorte de déterminisme faisant que
dans chaque opération de modélisation il est possible de déceler une « volonté du logiciel ».
Cette volonté s’explique simplement par quelques exemples. Pour les logiciels les plus
orientés « architecture », il est aisé de voir que tous les éléments constitutifs du langage
courant de l’architecture et de la construction sont déjà présents. Par exemple les portes,
fenêtres, blocs de construction, isolants, poteaux, poutres, etc. L’usage de ces logiciels
donne aux étudiants la sensation fausse qu’ils « font de l’architecture » dès lors qu’ils
assemblent ces éléments dans un ensemble à peu près cohérent, or il va de soi que les
choses ne sont pas si simples. Nous pourrions même signaler que cette approche acritique
dans l’utilisation des logiciels a eu des effets extrêmement négatifs depuis leur introduction
dans l’enseignement de l’architecture, les écoles d’architectures ayant trop souvent délaissé
la réflexion sur ses propres méthodologies de conception et de production au profit d’une
formation d’« agenceurs » ou d’aménageurs , urbains ou non. Pour les logiciels plus
génériques, souvent issus de domaines extérieurs à l’architecture, par exemple la
mécanique ou la conception navale et aéronautique, le problème ne provient pas de la
présence d’un langage architectural figé ou désuet, mais des principes géométriques sur
lesquels ces logiciels reposent. Concrètement, ceci signifie qu’on ne peut accéder à la
géométrie à l’œuvre lors des opérations de modélisation, car celle-ci est cachée à l’intérieur
du solveur du logiciel (le solveur est le « cœur géométrique » du logiciel) qui fait office de
« boite noire ». Le contrôle relatif de la géométrie est un contrôle des formes dessinées et
non un contrôle des règles géométriques et opérations mathématiques qui les engendrent.
Ainsi, bien que l’usage des logiciels issus d’autres domaines que l’architecture soit
bénéfique, il n’est pas encore idéal. L’enjeu est donc d’articuler ces logiciels à d’autres qui
sont plus spécifiquement orientés vers le calcul technique et scientifique (tels Mathematica
ou Matlab), et surtout, quel que soit l’environnement retenu, de faire en sorte que les
étudiants comprennent l’essentiel des opérations géométriques qu’un logiciel effectue
lorsqu’on clique sur une icône (par exemple l’icône « rotation », « répétition », « étirer »,
etc.). Les cours d’algorithmique, associés à quelques cours de logique élémentaire et
d’algèbre, sont donc essentiels à une meilleure compréhension de ce qui se passe à
l’intérieur d’un logiciel. Ils permettent pratiquement d’automatiser les tâches grâce aux
langages de script, de se placer dans un contexte de recherche et de développement et non
de simple utilisateur, d’acquérir les connaissances génériques et abstraites communes à
différents logiciels (qui permettent une meilleure adaptation à diverses plateformes) et enfin
de relier l’usage des logiciels à diverses traditions architecturales caractérisées par le
recours à des opérations géométriques simples mais riches et complexes. Le savoir lié à la
45