Sous-sections

2.2 CAO et saisie du modèle

Si les ordinateurs ont d'abord été des calculateurs, leur capacités de calcul associées à l'apparition des tables traçantes et des écrans ont très rapidement été pressenties comme des moyens de productions d'images pour l'étude, la simulation et même l'art. La figure 2.1 est la première image produite par un ordinateur (1960), réalisée par William FETTER, à qui l'on crédite aussi le terme de Computer Graphics. Mais bien au delà de son aspect historique, cette image est intéressante car elle a été produite dans le cadre d'un problème de conception, William FETTER étant alors concepteur de la firme BOEING, et travaillant sur l'optimisation de l'espace dans les cockpits d'avion.
Très peu de temps après, la thèse de Ivan SUTHERLAND [Sutherland1963] introduisait Sketchpad, système considéré comme la première interface graphique, qui permettait de créer des images très précises sur l'écran à l'aide d'outils de dessin (lignes, points, coins) et un crayon optique, le «light pen». Ces deux faits subliment à notre avis deux points fondamentaux de l'histoire de la CAO: la première image numérique est l'œuvre d'un concepteur, le premier système informatique permettant de produire des images de manière interactive est basé sur un paradigme de dessin.

Figure 2.1: The Boeing Man. Cette image générée par ordinateur est considérée comme le premier résultat de Computer Graphics (1960). Elle fut produite par le concepteur William FETTER alors qu'il travaillait sur la conception de cockpits d'avions.
\includegraphics[width=.8\textwidth]{fetter}

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.

2.2.1 Tour d'horizon

2.2.1.1 Logiciels généralistes de modélisation 3D

Il existe un nombre important de logiciels de modélisation 3D dits généralistes. Nous avons employé ce qualificatif pour signifier que ces logiciels ne s'inscrivent pas dans un domaine précis, ils sont fondés sur une modélisation de la géométrie de la scène 3D à représenter. Nous ne pouvons les citer tous, tant leur nombre est élevé depuis les logiciels libres jusqu'aux standards commerciaux: 3D Studio Max, Strata 3D, Rhino, Blender, etc.

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.

2.2.1.2 CAO: spécialisation et adaptation au domaine

L'évolution notable en terme de modélisation pour la CAO est l'adaptation au domaine de conception 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 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.

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 « technique», 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 optimisation. 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 (archivage, 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équations:

  1. une inadé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. une inadéquation contextuelle, due à un support figuratif et des paradigmes d'interaction très différents de ceux des concepteurs.

2.2.2.1 Inadéquation cognitive

Ainsi, l'opérateur est contraint à manipuler des entités géométriques précises et les transformations 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 «tangible», 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, impré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, 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.

2.2.2.2 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 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).

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.
\includegraphics[width=\textwidth]{archicadfull}

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).

Figure 2.3: ArchiCAD. Interaction avec AutoCAD® 2006. La fenêtre principale du programme, actuellement dans la vue dite de dessin. Les détails montrent les étapes d'une technique de dessin.
\includegraphics[width=\textwidth]{autocadihm}

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 ?

2.2.3 Des débuts de réponse ?

Cette inadéquation relègue actuellement la modélisation d'objets numériques, et donc l'intervention de l'ordinateur, aux étapes avancées du projet de conception. L'architecte, par exemple, va effectuer ses recherches et concevoir une ou plusieurs solutions en employant ses outils traditionnels de figuration: le dessin sous toutes ses formes. L'étape de modélisation est alors souvent réalisée par un spécialiste de l'infographie, devant reprendre, interpréter et modéliser ce que le concepteur a produit.

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».

2.2.3.1 Association de logiciels et usage transgressif

Bien que n'étant pas une réelle utilisation des systèmes de CAO dans les premières phases d'un projet, il est à noter l'importance que prennent de nos jours l'utilisation combinée de logiciels, ou leur utilisation transgressive dans un but créatif. Ainsi, il est fréquent que des utilisateurs se servent de plusieurs systèmes pour arriver à leurs fins, ou même en détournent certains de leur vocation originale, qu'ils en ignorent des fonctions inutiles pour le but qu'il veulent atteindre [Estevez2001].

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\textregistered) 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)?

2.2.3.2 Sketchup

Le logiciel SketchUp [@Last Software2000 2004] marque un pas important vers une modélisation 3D interactive, plus adaptée aux concepteurs et à leurs habitudes figuratives. Ainsi, il propose une large palette d'outils d'interaction essentiellement basés sur la manipulation directe et masquant donc l'aspect «géométrique» de la modélisation 3D traditionnelle (ce qui en a rapidement fait un logiciel très apprécié des architectes). Il est ainsi possible de modeler interactivement les formes à l'aide d'un seul outil interactif permettant de les pousser, les tirer, etc. selon un principe combinant extrusion et opérations booléennes (cet outil n'est d'ailleurs pas sans rappeler les principes de modélisation 3D proposés dans le système SCULPTOR, un outil de CAO expérimental basé sur la manipulation des espaces [Kurmann1995,Kurmann et al.1997]). Un autre outil permet de tracer des chemins, selon un principe d'étirement de lignes en 3D proche du dessin vectoriel, avec des aides contextuelles appropriées (comme par exemple l'indication interactive d'appartenance à un plan dans la figure 2.4(b)). Bien entendu, ce logiciel propose aussi des bases d'objets prédéfinis adaptées à divers domaines (architecture et construction, mécanique dans une moindre mesure), ainsi que divers modes de visualisation (coupes et rendus graphiques avancés).

Figure 2.4: SketchUpTM [@Last Software2000 2004]. Ce logiciel introduit des fonctionnalités plus «intuitives», inspirées du dessin, pour la création de modèles 3D
\begin{figure}\setcounter{subfigure}{0}
\subfigure[\small Interface globale.]{
...
... \og 3D\fg.]{
\includegraphics[width=.27\textwidth]{sketchupb}}
\end{figure}

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.

2.2.4 Synthèse

Le bilan que nous venons de dresser peut se résumer simplement: le principal obstacle à ce que les systèmes actuels de CAO deviennent des outils de support à la créativité dans les premières phases de conception se situe principalement dans leurs interactions avec l'utilisateur, et donc dans la manipulation des données et du dialogue. Nous avons situé cette inadéquation à deux niveaux:

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
2005-09-06