DISCUSSIONS ET PERSPECTIVES pement des outils logiques en espaces d’interaction, souvent sur un même dispositif, peut permettre

une meilleure mémorisation de ces fonctionnalités. Il serait même envisageable d’introduire un méca-nisme d’aides contextuelles, basées sur des macros ou des vidéos, qui signifierait les actions possibles à l’utilisateur lors de la première apparition d’une feuille d’interaction (dans l’esprit de l’image que nous avons réalisée pour la figure 4.12 page 97, présentant en vignette la manipulation du Shuttle pour plier les calques).

Ce ne sont que des propositions, et il est évidemment indispensable de les évaluer afin de les confirmer, mais il nous semble que le temps d’apprentissage (et d’éventuelles erreurs) induit par une approche non standard telle que la nôtre sera minime par rapport aux gains qu’elle peut apporter, particulièrement en termes d’intégration dans une démarche créative.

5.3.2 Une démarche libre

En plus de son environnement matériel et logiciel, SVALABARD se veut aussi un support à la création de par le fait qu’il n’impose pas une démarche précise et figée. Il n’y a ni ordre, ni primitive de construction.

La notion de retouche

Les systèmes actuels, commerciaux ou prototypes, permettent la retouche du modèle au cours de sa création, mais rarement dans le sens où le concepteur l’utilise. En effet, manipuler des données précises (primitives géométriques) au tout début de la conception limite de fait les possibilités créa-tives, mais rend la modification et la révision du modèle plus ardue. Dans un premier temps, parce que des « chemins » de conception ont étés fermés. Dans un second temps, parce-que les techniques d’in-teraction et de modification de ces données ne sont pas aussi naturelles que le dessin, représentation figurative qui offre à la fois l’incertitude nécessaire à la spéculation mais aussi les techniques simples d’itération.

Or, dans les approches actuelles, révision et amélioration sont plus assimilables à de la gestion de versions, car trop liées à l’emploi de structures de données précises et globales (primitives de haut niveau). Certes, cette approche offre un avantage certain en terme de gestion de projet, mais n’est pas vraiment en accord avec les structures manipulées par l’utilisateur. Notre démarche se démarque sur ce point, car axée autour du trait comme donnée commune à l’utilisateur et au système, dans un contexte de dessin libre. Il est vrai que l’utilisation et l’interprétation du dessin comme médium entre le concepteur et le système informatique n’est en rien une nouveauté. Toutefois, notre approche se distingue par la notion de dessin libre, sans contrainte ni de vue (grâce aux possibilités du noyau de reconstruction utilisé) ni de qualité du dessin (vectoriel, limitation à la saisie de l’objet d’intérêt, etc.). Ainsi, même si dans les traitements le système d’interprétation va transformer ces données pour les exploiter, leur transformation et leur évolution vers des solutions plus précises aura toujours pour support le croquis et ses traits, associé à l’utilisation de calques.

Filtres et traitements du dessin

Les filtres de traitement du dessin prennent une place importante dans la façon dont le système va s’intégrer dans la démarche de conception : ils déterminent les possibilités de transformation des traits saisis vers une structure de données exploitable par le système. Ils sont aussi intimement liés à la tâche et au domaine d’utilisation et doivent être développés dans un contexte particulier. C’est ce

5.3. APPORTS ET DISCUSSIONS que nous avons tenté de réaliser par nos proposition, notamment par les filtres de détection des phases de dessin et de fusion des segments dans le cadre du croquis d’architecture en perspective.

Tout en conservant la démarche libre du concepteur en architecture, et notamment la révision grâce à la fusion des segments, nous pouvons produire en temps réel une structure vectorielle du dessin, un graphe 2D, utilisable pour des interprétations de haut niveau et la reconstruction 3D. Il convient toutefois de mesurer ce discours, de par le fait que ces traitements n’ont pas encore été évalués dans des conditions réelles d’utilisation, et ne s’appliquent pas non plus pour la production d’autres structures de données telles que des courbes. Toutefois, ils sont adaptés à la fois à la notion de démarche libre et itérative et à la finalité de notre système, son noyau mathématique.

Calques de dessin

Enfin, le principe des calques de dessin que nous avons proposé est aussi un atout pour le support de la conception et de sa démarche. En effet, outre leur apport à la métaphore des outils habituels de conception, les calques offrent dans notre système la même capacité de « mémoire » et de révision que leurs équivalents réels. C’est un autre point sur lequel notre système reproduit et emprunte ses outils aux méthodes de conception pour favoriser la démarche libre et créative. Il reste toutefois, comme nous l’avons souligné dans le chapitre précédent, à clarifier le mode de connexion des interpréteurs aux calques de dessin afin d’en améliorer la pertinence.

Limites

Certains points de SVALABARD peuvent encore contraindre la démarche de l’utilisateur. Tout d’abord, la fiabilité des filtres de dessin sous leur forme actuelle peut engendrer des erreurs d’interpré-tation, de reconstruction 3D, et, plus grave, de comportement du système (détection d’une mauvaise phase de dessin pour le filtrage des traits, par exemple). Dans un même ordre d’idée, les solutions que nous avons proposées pour la détection des propriétés de haut niveau du dessin peuvent conduire à des échecs ou des ambiguïtés (solutions multiples). Il nous semble donc que dans le cadre où nous avons inscrit nos travaux (le dessin libre pour la modélisation 3D), il est nécessaire de s’orienter vers une coopération entre le système et la machine pour régler ces problèmes plutôt que de viser une automatisation complète du processus d’interprétation du dessin.

Après avoir identifié les problèmes techniques actuels de nos filtres et proposé tout de même des pistes pour les améliorer, nous proposerons un compromis quant à l’intervention de l’utilisateur dans le traitement du dessin et la place du système dans la démarche de l’utilisateur.

Amélioration des filtres bas niveau

Nos algorithmes originaux de fusion de segments et de détection des phases de dessin d’architec-ture sont essentiellement basés sur des heuristiques et des analyses issues de notre étude. Bien que fiables dans le cas général, il n’en demeure pas moins quelques singularités entraînant des erreurs parfois pénalisantes pour le traitement du dessin, telles que la fusion erronée de segments (cas des « écrasements » dus à la vue perspective) ou un mauvais filtrage de traits.

Pour ce qui est de la détection des phases du dessin, il nous semble impératif de rendre ce trai-tement adaptatif à l’utilisateur de manière à prendre en compte les spécificités de ses méthodes et ses habitudes. L’étude de cette notion de profil utilisateur est une voie qui suffirait probablement à identifier et trouver les limites de notre approche.

CHAPITRE 5. DISCUSSIONS ET PERSPECTIVES problème. Il serait intéressant d’envisager une méthode plus globale, associant les heuristiques que nous avons proposées à une analyse de la topologie du graphe 2D formé par les points et segments détectés (recherche de pendants(1), de cycles, etc.). Nous reviendrons plus en détail sur cette approche dans l’annexe A page 3.

Finalement, même si il est indispensable d’approfondir les travaux que nous avons engagés sur les filtres et traitements du dessin, notre approche offre surtout une architecture logicielle permet-tant cette amélioration et cette évolution. La décomposition du traitement en plusieurs modules, qui peuvent être connectés dynamiquement, induit la flexibilité nécessaire à l’amélioration, l’insertion ou le remplacement de traitements sans pour autant remettre les autres en question.

Saisie des contraintes

Actuellement, la saisie des propriétés de haut niveau nécessaires à la reconstruction 3D est réalisée par l’utilisateur. Il est évident que cette saisie est fastidieuse, en particulier dans le cas d’un dessin important et complexe. Mais elle n’est toutefois pas si intrusive du point de vue de la démarche de conception, pouvant être réalisée à n’importe quel moment (au cours du dessin, ou à la fin). Bien en-tendu, cela pose tout de même le problème d’une longue tâche supplémentaire à réaliser, et ne permet pas de tirer tous les avantages de l’outil informatique. En particulier, si la saisie de ces propriétés est effectuée en fin de conception, le concepteur ne bénéficie pas de la construction d’un modèle 3D en parallèle à sa démarche.

Si l’on revient aux hypothèses originales du projet GINA, l’idée de départ était une saisie si-multanée du dessin et des contraintes en utilisant plusieurs modalités : le stylet pour le dessin et la parole pour les contraintes. Ainsi, l’utilisateur décrirait son dessin au fur et à mesure du tracé. Nous n’aborderons que de loin les problèmes techniques de ce principe (mise au point d’un vocabulaire de description et fusion multimodale), nous nous concentrerons essentiellement sur la démarche qu’il engendre.

Dans le cadre de la modélisation 3D dans les premières phases de la conception architecturale, un tel principe n’est à notre avis pas adapté. En effet, il est tout d’abord important de définir un vocabu-laire de description adapté au domaine. Or dans le cadre de l’architecture, le vocabuvocabu-laire est tout de même d’un niveau assez élevé, posant à notre avis un problème de fusion multimodale trop délicat (beaucoup de traits du dessin, qui de plus ne seront pas forcément tracés consécutivement, vont repré-senter une caractéristique architecturale déclarée). Il serait alors nécessaire de contraindre fortement la démarche du concepteur. En l’obligeant, dans un premier temps, à ne dessiner en séquence que ce qu’il vient d’énoncer (ou l’inverse, expliquer ce qu’il vient de dessiner). Mais aussi en le contraignant à préciser peut être trop tôt ses choix de conception. Toutefois, si l’on fait abstraction de la contrainte qui consiste à obliger le concepteur à « penser tout haut », cette approche multimodale serait un atout pour délimiter les phases de conception associées à des objets d’intérêt [Leclercq et al., 2004], plutôt que pour leur description précise (et géométrique).

Ce principe de description précise nous semble bien plus adapté à la modélisation 3D dans un cadre géométrique ou pour la saisie de modèles 3D déjà conçus ; en bref, lorsque la géométrie est bien défi-nie. Le vocabulaire peut alors être de plus bas niveau, basé sur les points, droites, parallélismes, etc., facilitant alors la fusion avec le dessin (mais à notre avis incompatible avec les concepts que manipule l’architecte).

Il est selon nous important de s’orienter vers une collaboration entre l’utilisateur et le système pour l’interprétation du dessin et son élévation en 3D, notamment au niveau de la détection des

5.3. APPORTS ET DISCUSSIONS priétés. Bien que ce principe puisse paraître en contradiction avec notre proposition de dessin et de démarche libre, il nous semble un compromis nécessaire pour éviter d’ajouter des tâches « annexes » à la conception trop lourdes pour le concepteur, ainsi que pour éviter des interprétations erronées par le système.

Retours, corrections et collaboration à l’interprétation

Du fait de l’imprécision des données traitées dans les premières phases de la conception, il est in-évitable que des traitements automatisés aboutissent à plusieurs solutions possibles au terme de leurs analyses. Ils doivent donc être vus comme des outils d’aide à la génération de solutions, comme nous l’avions évoqué dans le premier chapitre de ce mémoire, sans pour autant que ce soit le système qui fasse le choix d’une solution. Le problème majeur est alors la présentation de ces interprétations et solutions à l’utilisateur, de manière ni contraignante, ni intrusive.

Nous sommes d’avis qu’un principe d’interface suggestive, dans l’esprit de celle proposée par Ta-keo IGARASHIdans [Igarashi et Hughes, 2001], est une solution efficace. Cette technique, proche du principe des « What-if Tools » de Ben SHNEIDERMAN[Shneiderman, 2000] présente différents avan-tages, le plus important étant de ne pas interrompre la tâche de l’utilisateur tout en lui permettant de suivre et guider le système. Mais l’impact n’est à notre avis pas négligeable non plus sur sa démarche, lui offrant la possibilité de concrétiser plus rapidement des solutions ou de poursuivre à son propre gré.

Un tel mécanisme de suggestions serait un atout certain dans notre système pour la présentation des retours du système d’interprétation, permettant de conserver la notion de démarche libre. Dans notre paradigme des feuilles d’interactions, ces suggestions pourraient être présentées sur la feuille augmentée sous forme de vignettes interactives contenant une représentation graphique des propo-sitions, renforçant ainsi l’aspect non-intrusif de cette technique (la feuille augmentée n’apparaît que lorsque l’utilisateur ne dessine plus). Cette approche est un bon compromis pour une collaboration entre le système et l’utilisateur, à plusieurs niveaux : interprétation bas niveau du dessin, détection des propriétés et proposition de solutions.

5.3.3 Un système configurable et adaptable

Le dernier point sur lequel SVALABARD se démarque des travaux antérieurs est sa configurabi-lité et son adaptabiconfigurabi-lité en terme de dispositifs d’entrée, d’interactions et de comportements. En effet, l’utilisateur peut configurer simplement le système selon ses besoins et sa configuration matérielle. Mais cette conception modulaire simplifie aussi l’ajout de nouvelles fonctionnalités pour les déve-loppeurs ou d’interactions pour les concepteurs d’interfaces, faisant tendre notre proposition vers une architecture pour un système de support informatique à la créativité.

Nous ne développerons pas plus avant ces notions dans ce chapitre, celles-ci étant largement ex-posées dans la deuxième partie de ce mémoire où nous proposons un nouveau modèle d’architec-ture logicielle pour la conception des interfaces, implémenté dans la boîte à outil MAGGLITE(voir chapitre 8). Nous reviendrons précisément dans la section 8.4.3 page 203 sur le développement de SVALABARDavec ces outils.

CHAPITRE 5. DISCUSSIONS ET PERSPECTIVES