• Aucun résultat trouvé

CRÉATIVITÉ, MODÉLISATION 3D ET IHM dieux de saisie des objets géométriques sous leur forme la plus simple (points, lignes, NURBS) ou

Créativité, modélisation 3D et IHM

CHAPITRE 2. CRÉATIVITÉ, MODÉLISATION 3D ET IHM dieux 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éforma-tions et manipuladéforma-tions 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.

CAO : spécialisation et adaptation au domaine

L’évolution notable en terme de modélisation pour la CAO est l’adaptation au domaine de concep-tion en utilisant des objets paramétrés. L’approche reste toujours dans une démarche constructive, mais l’utilisateur a à sa disposition des objets de haut-niveau propres à son domaine, dont l’assemblage est rendu plus aisé par des scenarii d’utilisation délimitant alors les constructions possibles. Un objet fenêtre ne peut pas être ajouté si il n’est pas placé sur un objet mur. La construction du modèle est alors un processus très mécanique, dans le sens répétitif du terme, ou l’opérateur doit, par exemple, commencer par placer un mur. Il précise alors ses paramètres : dimensions, position, couches qui le compose (matériaux de construction, isolants, etc.). Ensuite, il placera sur ce mur une porte. Il choisit alors le type de porte, la place sur le mur et règle ses paramètres, qui sont contrôlés et vérifiés par le système pour être cohérents avec le reste du projet (taille, placement, etc.).

Plus que sur l’amélioration de la démarche de construction et de création de la maquette, du mo-dè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 do-maine : SOLIDEDGEde la société UGS (design industriel et mécanique), CATIA de DASSAULTSYS

-TÈMES[Dassault Systemes, 2002 2004] avec tous ses greffons dans beaucoup de domaines, MAYAde ALIAS[Alias, 2005b] (modeleur 3D intégré dans des suites adaptées : StudioTools pour le design, Au-toStudio 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 ARCHICAD™, développé comme extension à AUTOCAD par une société indépendante [Abvent, 2005]. La société NEMETSCHEK propose aussi ALLPLANFT [Nemet-schek, 2005], 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,

2.2. CAO ET SAISIE DU MODÈLE au niveau des données qu’ils traitent, des systèmes d’ingénierie et non de création.

2.2.2 L’inadéquation avec la démarche du concepteur

Le problème majeur dans la réalisation de ces systèmes a tout de suite été identifié comme « tech-nique », plutôt qu’humain. Ainsi, les travaux se sont avant tout axées sur la façon de représenter les données géométriques, les algorithmes permettant de les manipuler, de les afficher, ainsi que leur op-timisation. Puis, dans les environnements complexes de suivi d’un projet, ce sont posées les questions de la transformation des données pour le passage d’une étape à l’autre, de leur persistance (archi-vage, indexation), de leur conversion (formats de diffusion, passage d’une géométrie à un plan de construction, transmission des données à une machine outil).

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équa-tions :

1. uneinadéquation cognitive, due à une démarche de conception imposée trop éloignée de celle de l’utilisateur dans les premières phases du projet.

2. uneinadéquation contextuelle, due à un support figuratif et des paradigmes d’interaction très différents de ceux des concepteurs.

Inadéquation cognitive

Ainsi, l’opérateur est contraint à manipuler des entités géométriques précises et les transforma-tions qui leurs sont applicables, dans une approche orientée système. Cette représentation des données n’est pas un problème lorsque l’objet conçu est suffisamment avancé pour devenir quasiment « tan-gible », mais il est évident qu’elle ne correspond pas à la vision plus conceptuelle des premières phases de la résolution d’un problème. Ces systèmes ne savent pas manipuler de telles données floues, im-précises, caractéristiques de la résolution de problèmes comme nous l’avons vu dans le chapitre 1. Le concepteur doit alors rentrer dans la démarche qu’ont fixé les créateurs du logiciel.

Dans le domaine de la conception en mécanique, où l’aspect « précision et géométrie » est une contrainte présente relativement tôt dans le processus de conception, le problème est moindre. Par contre, si l’on se place dans le contexte de l’architecture, cette démarche se révèle inadaptée aux premières phases du projet.

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, rap-ports 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.

CHAPITRE 2. CRÉATIVITÉ, MODÉLISATION 3D ET IHM 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 ESTEVEZsouligne 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 [Estevez, 2001].

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 [Cross, 2002] : « 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éca-nique 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.

Inadéquation contextuelle

Nous avons souligné dans le chapitre précédent l’importance que tiens le dessin dans les premières phases de la conception en sa qualité d’outil figuratif, mais aussi pour la liberté qu’il induit dans la génération des solutions à un problème, essentiellement grâce à un rapport intuitif avec le concepteur. Il en va pourtant dans un tout autre sens pour les logiciels de CAO.

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 WIMP(1)de ces applications, cela se tra-duit par une augmentation proportionnelle de sa complexité. Cette notion a été montrée par Michel BEAUDOUIN-LAFONdans [Beaudouin-Lafon, 1997], 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’uti-lisation 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 page ci-contre).

(1)WIMP, pour « Windows, Icons, Mouse, Pull-down menus/Pointer » (fenêtres, icônes, souris, menus déroulants/pointeur) est le terme employé, parfois péjorativement, pour définir les interfaces actuelles.

2.2. CAO ET SAISIE DU MODÈLE

FIGURE 2.2 – ArchiCAD. L’interface d’ArchiCAD présente une partie de ses nombreuses fonctionnalités. Certes, l’espace de travail peut être maximisé en masquant barres d’outils ou fenêtres, mais au détriment de l’accessibilité aux outils.

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 page suivante, 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 environ-nement 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 des-sin dans un environnement traditionnel qui, comme le note justement Gabriela GOLDSMITH, per-mettent des évasions, gribouillages et autres manipulations physiques du support (pliage, coupures) [Goldsmith, 2002]. Rien ne peut prouver que ce rapport à l’environnement de dessin est un facteur

Outline

Documents relatifs