|
Depuis cette révolution jusqu'à nos jours, un grand nombre de systèmes informatiques basés sur la création graphique ont été développés et sont largement utilisés. Proposant toujours plus de fonctionnalités, ils intègrent et permettent diverses activités, de l'art numérique au cinéma en passant par la conception (design, architecture, mécanique, automobile, ...). Le point commun à tous ces logiciels, qu'ils soient dits de synthèse d'image, de CAO, de DAO ou autre, est la nécessité de saisir une représentation numérique des objets à représenter (une description géométrique dans l'espace). Dans le cadre de la synthèse d'image et de la CAO, ces maquettes numériques sont le plus souvent représentées dans trois dimensions et l'on parle alors de modélisation 3D. Bien que les objectifs de ces logiciels ne soient pas les mêmes, ils n'en restent pas moins tous des modeleurs 3D, proposant ensuite des fonctionnalités étendues à leur contexte d'utilisation.
C'est donc à cette notion de modélisation 3D que nous allons nous intéresser, dans les logiciels que nous qualifierons de généralistes et dans les système de CAO.
La méthode de modélisation employée est dite constructive, nécessitant souvent un travail fastidieux de saisie des objets géométriques sous leur forme la plus simple (points, lignes, NURBS) ou par des primitives prédéfinies (cubes, sphères, surfaces, etc.). Une foule de transformations, déformations et manipulations est disponible, le but essentiel de ces logiciels restant la production d'images ou d'animations.
Il existe toutefois pour ces systèmes des bases d'objets pré-construits mais leur assemblage et leur mise en relation dans une même scène nécessite toujours la maîtrise de leur géométrie et des transformations qui leurs sont applicables.
Plus que sur l'amélioration de la démarche de construction et de création de la maquette, du modèle, les logiciels de CAO ont rapidement évolué vers un concept de gestion du projet de conception, utilisant alors les capacités de calcul et de précision de l'ordinateur pour faciliter, et améliorer le passage à la fabrication . Ainsi, ont été proposées des fonctionnalités de génération des plans et métrés, d'analyses de coûts de fabrication, et même de pilotage de machines outil dans les domaines de la construction mécanique. Ces logiciels s'intègrent maintenant dans le PLM, «Product Lifecycle Management» (Gestion du cycle de vie du produit).
Apparaissent alors des suites logicielles, toutes basées sur un modeleur 2D ou 3D, et déclinées en divers produits selon les spécificités du domaine. On peut citer les exemples de «ténors» dans ce domaine: SOLID EDGE de la société UGS (design industriel et mécanique), CATIA de DASSAULT SYSTÈMES [Dassault Systemes2002 2004] avec tous ses greffons dans beaucoup de domaines, MAYA de ALIAS [Alias2005b] (modeleur 3D intégré dans des suites adaptées: StudioTools pour le design, AutoStudio pour l'automobile, ...). La société AUTODESK, a construit autour de son produit AUTOCAD toute une série d'applications à des domaines de conception: pour l'architecture, il y a AUTODESK AUTOCAD REVIT7, mais aussi ARCHICADTM, développé comme extension à AUTOCAD par une société indépendante [Abvent2005]. La société NEMETSCHEK propose aussi ALLPLAN FT [Nemetschek2005], pour la conception architecturale, etc.
Globalement, ces logiciels tendent à s'intégrer sur la durée complète du projet. Les arguments que l'on retrouve dans leurs brochures tournent autour de l'idée «de l'esquisse à la fabrication». Mais il est important de modérer cette notion d'intégration par le fait que ces logiciels suivent les phases du processus de conception industriel. Il est indéniable qu'ils offrent un support de choix pour les phases avancées d'un projet. Mais dans ses premières phases, et bien qu'employant largement les termes de dessin, croquis et esquisse, ils ne prennent pas en compte les aspects créatifs du processus de conception, ne deviennent pas des outils de figuration comme l'est le dessin traditionnel. Ils restent, au niveau des données qu'ils traitent, des systèmes d'ingénierie et non de création.
Il en ressort alors une explosion des fonctionnalités, voire même une argumentation basée sur leur
nombre et une course à leur optimisation, que ce soit pour la création du modèle (la saisie des
données et de leurs paramètres) ou pour les étapes ultérieures.
Seulement, l'interfaçage de ces fonctionnalités (le noyau fonctionnel du système) avec l'utilisateur
a simplement été réduit à de simples points d'entrée, basant la communication sur la représentation
des structures de données du système. Cela soulève à notre avis deux problèmes majeurs, deux
inadéquations:
Tout d'abord, ce mode de construction du modèle rend primordiale l'enveloppe, la forme, par
rapport à tous les autres aspects que va prendre en compte l'architecte (fonctionnel, intégration,
rapports d'espace). Ensuite, l'aspect itératif et évolutif des solutions, mais surtout leur
combinaison pour en produire de nouvelles est incompatible avec la rigueur imposée par la
construction géométrique. Ainsi, lorsque l'architecte repasse des traits, les combines, les
prolonges, ce n'est pas dans un but esthétique, mais bien dans une démarche de modification et de
génération de nouvelles solutions. De telles actions et interactions sont impossibles avec un
système de CAO: il est nécessaire d'avoir tout de suite la bonne solution, sous peine de devoir
remettre en question toute la construction de l'objet. Bien qu'il existe des fonctionnalités
d'annulation d'action, ou de retour arrière, ce n'est que de la gestion de version.
Dans un même ordre d'idée, nous avons évoqué l'importance que tiennent des supports comme le calque
pour l'architecte. Les systèmes de CAO proposent aussi des calques, mais ceux-ci n'ont pas la même
sémantique. Ce sont des couches permettant une séparation modulaire, organisationnelle du travail
(niveaux d'un bâtiment, séparation sols/murs, etc.), alors que dans le dessin d'architecte, ils
servent à l'élaboration graphique et la construction d'un espace de solutions.
Enfin, Daniel ESTEVEZ souligne aussi l'importance du changement d'espace de travail, obligeant le concepteur à prendre en compte des aspects qui n'existent pas avec une feuille de papier et un crayon. Il soulève ainsi les difficultés nouvelles que peuvent engendrer la gestion de propriétés qui ne sont pas visibles dans le modèle, tels que la gestion de la mémoire, la compréhension des notions d'espace image et d'espace objet, ainsi que les possibilités de pannes de la machine [Estevez2001].
Ces constatations montrent l'écart entre les principes de modélisation d'un objet numérique et sa création dans un processus de conception. Si l'on reprend les termes de Nigel CROSS lorsqu'il parle du dessin dans la conception [Cross2002]: «Le concepteur doit maîtriser un genre de médium - le croquis - permettant aux idées partiellement formées d'être exprimées et réfléchies: d'être prises en considération, développées, et reconsidérées». Il est clair que la démarche constructive et mécanique de la modélisation 2D/3D, ainsi que le caractère précis des données qu'elle nécessite, ne sont pas adaptés aux premières phases de la conception. De tels systèmes ne peuvent évidemment pas remplacer le dessin, ni même l'utiliser comme support à la communication Homme-Machine.
Mais, en parallèle à cette question de la démarche, demeure un autre point important dans l'inadéquation des logiciels actuels pour les premières phases de la conception: un rapport, un dialogue inadapté entre le concepteur et le système informatique pour l'utiliser comme outil de figuration de la conception créative.
Nous avons déjà soulevé le fait que les principales préoccupations et améliorations des systèmes de CAO ont souvent été de fournir des fonctionnalités de plus en plus avancées, mais aussi de plus en plus nombreuses. Or il est clair que, dans le paradigme WIMP2.1 de ces applications, cela se traduit par une augmentation proportionnelle de sa complexité. Cette notion a été montrée par Michel BEAUDOUIN-LAFON dans [Beaudouin-Lafon1997], où il calcule qu'une application «standard offre 150 commandes dans ses menus, 60 boîtes de dialogue, et 80 outils». Si l'on ne considère alors que le temps nécessaire à la prise en main, l'adaptation et la découverte des fonctionnalités, ce fait rend tout de suite un système de CAO excessivement complexe dans un contexte créatif par rapport à l'utilisation d'un simple papier et d'un crayon. À cela, on peut ajouter une réduction de l'espace de travail au profit des widgets permettant l'accès aux outils (voir figure 2.2).
|
Ainsi, les interactions sont composées d'un grand nombre de manipulations indirectes des objets d'intérêt (primitives de l'objet) par l'intermédiaire de boutons, menus et boîtes de dialogue et de quelques manipulations directes sur les objets. De plus, la multiplication des possibilités entraîne à la restriction de ces techniques de manipulation directe. La figure 2.3, par exemple, présente la saisie d'un trait par une technique de dessin avancée. Le principe est de fournir un affichage permanent des caractéristiques du trait manipulé ou tracé, ainsi que de permettre la saisie au clavier de ces caractéristiques directement sous le curseur. Il est clair que cette technique évite des allers-retours entre une zone de saisie et le dessin tout en offrant à chaque instant une vision des propriétés d'intérêt. Elle est sans nulle doute adaptée au dessin d'ingénierie. Elle n'a par contre aucun intérêt ni avantage dans les premières phases de la conception, voire l'inverse (distraction et focalisation du concepteur sur des détails encore à négliger sous peine de fermer des chemins).
|
C'est cet aspect que nous appelons l'inadéquation contextuelle, le fait que, hormis le biais qui existera toujours dans le cadre de l'utilisation d'une machine, ces systèmes proposent un environnement de conception loin des habitudes de travail des utilisateurs, de leur contexte privilégié. Dès lors, quel dialogue, quelle communication peut s'instaurer entre le système et le concepteur ? Il nous semble que l'aspect rigide, fermé et purement fonctionnel de ces interfaces est un autre des aspects bloquant leur utilisation dans un contexte créatif.
Nous en voulons pour preuve l'intimité et la proximité qu'entretiennent le concepteur et son dessin dans un environnement traditionnel qui, comme le note justement Gabriela GOLDSMITH, permettent des évasions, gribouillages et autres manipulations physiques du support (pliage, coupures) [Goldsmith2002]. Rien ne peut prouver que ce rapport à l'environnement de dessin est un facteur nécessaire à la créativité, mais le fait est qu'il existe et qu'il n'est pas retranscrit par les systèmes informatique actuels. Nous avons d'ailleurs toujours été surpris d'entendre des étudiants, architectes ou éditeurs de logiciels qualifier les systèmes de CAO d'outils de dessin, tant l'appréhension d'un système informatique est à l'heure actuelle différente et éloignée de leurs habitudes et de leurs outils.
Cela nous mène alors à nous poser la question de savoir si les logiciels de CAO, et plus particulièrement dans la saisie du modèle, peuvent être considérés comme des outils ? Daniel ESTEVEZ aborde cette notion de manière intéressante et balancée dans la fin de son ouvrage [Estevez2001]. Sa vision peut être résumée par le fait que ce ne sont pas des outils au sens où les définissent les ergonomes, et ceci en partie à cause du fait que ce sont des machines (Il cite d'ailleurs à ce propos Hanna ARENDT: «L'outil le plus raffiné reste au service de la main qu'il ne peut ni guider ni remplacer. La machine la plus primitive guide le travail corporel et éventuellement le remplace tout à fait.» , citation que nous reprendront en partie pour illustrer nos travaux dans le chapitre 4). Par contre, il montre que les logiciels de dessin sur ordinateur «induisent un mode d'ustensilité nouveau au sein du travail humain (y compris lorsqu'il est d'ordre spéculatif et cognitif), ustensilité qui aboutirait à une forme de partenariat entre l'homme et l'appareil». Ce partenariat se traduit par la répartition des tâches entre le concepteur et la machine. Et de conclure: «C'est qu'un outil de figuration doit augmenter la faculté du concepteur et non la restreindre en le délestant précisément... de ses tâches figuratives». Nous partageons cette vision, du moins pour les premières phases de la conception. Même si l'on peut créditer ces systèmes d'outils pour les phases avancées de la conception (qu'il n'ont pas réellement bouleversées, mais améliorées et facilitées), il est clair qu'il ne sont pas des outils de figuration dans le sens où l'est le dessin pour l'architecte. Nous pourrions même arriver plus facilement à cette conclusion en constatant simplement qu'ils ne peuvent pas être qualifiés d'outils lors des premières phases de conception du fait qu'il ne sont pas utilisés à ce moment là.
Nous avons pourtant vu dans la section 1.3.3 les apports envisageables de l'informatique dans les premières phases de la conception, ainsi que la nécessité d'intégration que cela implique. Quelles sont alors les pistes pour qu'un tel système devienne un outil figuratif des premières phases du processus de conception créative ?
Pourtant, il est important de noter que les systèmes actuels peuvent, dans une certaine mesure, induire une démarche créative de la part de leurs utilisateurs. C'est ce que nous constaterons dans la section suivante. Mais nous verrons aussi, avec l'exemple du logiciel SketchUp, que ces systèmes peuvent être améliorés tout en restant inscrits dans une démarche et un paradigme d'interaction « standard».
Association de logiciels
Il est fréquent dans les étapes descriptives d'un projet de conception architecturale, que les
architectes aient recours à des outils de retouche d'images (type Photoshop) pour
améliorer, compléter ou modifier le rendu d'une scène 3D produite avec un système de CAO. C'est une
tendance aussi visible dans le design industriel, où les designers utilisent ces mêmes logiciels de
«peinture numérique» pour concevoir l'aspect de leurs objets, avant de simplement projeter ces
images comme textures sur un modèle 3D représentant la forme générale de l'objet. Ainsi, il n'est
pas nécessaire de modéliser précisément les détails, ces textures peuvent être modifiées plus
facilement par la suite mais aussi combinées plus facilement (il est plus simple de modifier ou
retoucher un dessin type «image» qu'une maquette virtuelle en 3D).
Soulignons d'ailleurs, que la société éditrice de logiciels de CAO Alias (ex Alias Wavefront) [Alias2005b], souvent précurseur dans le domaine de l'IHM, a introduit de tels outils dans ses modeleurs. Il est ainsi simple de combiner le dessin 2D et la modélisation 3D dans un même environnement. Outre le côté pratique d'un environnement unifié, cette combinaison de modèle 3D pour l'enveloppe et de textures dessinées pour les détails permet plus de souplesse dans la conception avec un ordinateur, l'intégrant alors plus tôt dans le processus.
Usage transgressif
Cette notion d'usage transgressif est mise en valeur dans l'épilogue de l'ouvrage de Daniel
ESTEVEZ [Estevez2001] d'où nous tirons d'ailleurs ce terme. Il est en effet prudent,
comme le suggère l'auteur, de ne pas faire tendre ces inadéquations vers un rejet total des systèmes
d'infographie actuels. Il considère pour cela les capacités d'adaptation et d'anticipation de
l'Homme lorsqu'il poursuit un but précis, ce qui est le cas dans une tâche de conception. Ainsi,
l'usage transgressif est la capacité de ne pas s'enfermer dans la démarche guidée des systèmes
actuels, mais de l'utiliser à bon escient selon ses buts et ses moyens: n'utiliser que les fonctions
utiles à un moment donné, utiliser des fonctionnalités a priori prévues pour un autre but, alterner
les supports (passer du dessin à l'infographie, et repasser au dessin, etc...).
Nous partageons cette vision, mais nous y répondons toutefois que quel que soit l'outil informatique et son domaine d'application, il en sera toujours fait un usage détourné ou transgressif, constatant que c'est surtout la démarche imposée par le logiciel qui induit la transgression, ou sa flexibilité qui en favorise le détournement. Est-ce une raison pour ne pas assimiler ces modes d'utilisation, ou les intégrer dans une démarche plus proche de l'utilisateur, moins guidée et donc plus libre (bien que poursuivant un but précis)?
L'utilisation de ce logiciel rend la modélisation 3D plus intuitive et son apprentissage plus rapide. SketchUp représente une étape importante, dans un domaine ou l'industrie tarde encore à relâcher un peu les aspects fonctionnels et l'efficacité de calcul au profit de plus d'interactivité. Car bien évidemment, il ne possède pas toutes les fonctionnalités d'une suite logicielle de CAO complète. Toutefois, sans être vraiment du dessin à proprement parler, il peut déjà permettre un premier rapprochement entre les fonctions descriptives et spéculatives du dessin. Il convient toutefois de rester modéré quant à une utilisation spéculative dans le sens de la conception architecturale, les outils interactifs de ce logiciel n'offrant tout de même pas la souplesse des opérations figuratives des traits du dessin à main levée (révision des solutions et itération, émergence d'idées). C'est ce que nous avons pu remarquer dans les témoignages publicitaires des utilisateurs professionnels de ce logiciel qui ne parlent que des avantages descriptifs de celui-ci, en particulier des possibilités de rapidement modifier le modèle en temps réel devant le client. C'est certes un atout, sûrement une introduction plus précoce de l'outil informatique dans la conception, mais nous sommes d'avis que ces architectes ont d'abord conçu les bases de leur projet avec du dessin traditionnel.
Malgré de constantes améliorations les logiciels actuels ne permettent toujours pas la conception de modèles numériques. Ces améliorations passent par des primitives de construction plus malléables et spécifiques, par l'adoption de dispositifs d'entrée plus adaptés (tablettes, dispositifs 3D, etc.), mais ne changent ni la démarche, ni le paradigme d'interaction global. Surtout, elles n'améliorent pas les capacités du système à supporter la spéculation.
stuf