Du maquettage statique au dialogue vivant
Figma a d'abord été pensé pour des écrans fixes. On y dispose des blocs, on aligne des marges, on fixe une hiérarchie visuelle. Une IA conversationnelle échappe largement à ce cadre, car son objet n'est pas une page mais un enchaînement. Ce qui compte, c'est l'ordre des tours de parole, la façon dont le système demande une précision, la manière dont il se reprend après une incompréhension. Dessiner cela suppose d'inventer une notation : des bulles qui se répondent, des branches conditionnelles, des états vides. Le designer quitte le confort de la grille pour représenter du temps et de l'incertitude, deux matières qui ne se dessinent pas comme un bouton.
Cette bascule demande une autre discipline mentale. Sur un écran classique, chaque élément a une place stable ; dans un dialogue, tout dépend de ce qui vient d'être dit. La même intention peut se manifester par une question, une reformulation ou une proposition, et le choix entre ces formes change l'expérience vécue. Figma reste utile à condition d'accepter qu'on n'y dessine pas un objet fini mais un arbre de possibilités. Le fichier de conception devient alors une grammaire : on y lit les intentions possibles, leurs réponses attendues et les sorties de secours. Sans ce travail de représentation, le dialogue se construit à l'aveugle, directement au fil du code.
Ce que l'IA déplace dans l'atelier de conception
L'intelligence artificielle n'intervient pas seulement comme sujet de la maquette ; elle modifie aussi la façon de la produire. Des fonctions d'assistance génèrent des variantes d'un composant, proposent des libellés, déclinent un état en plusieurs tonalités. Ce gain de vitesse a un revers : il produit beaucoup de propositions plausibles mais creuses si le designer n'a pas d'abord fixé les règles du dialogue. La conception d'une IA conversationnelle exige de décider ce que l'assistant a le droit de dire, de demander et de promettre. Ces décisions précèdent l'esthétique et ne se délèguent pas à un outil de génération automatique, aussi rapide soit-il.
Concevoir un dialogue, c'est aussi écrire. Les mots du système pèsent autant que la position d'un bouton. Un message d'erreur qui accuse l'utilisateur fait plus de dégâts qu'un décalage de pixels. Figma accueille donc des planches où texte et structure se lisent ensemble : arborescence des intentions, exemples de formulations, cas limites. L'IA aide à tester des tournures et à repérer les ambiguïtés, mais c'est la personne qui tranche sur le ton et sur le niveau de détail attendu. Le fichier de conception devient un document de référence partagé avec les développeurs et les équipes métier, ce qui évite des interprétations divergentes.
Éprouver le parcours avant d'écrire le code
Une maquette conversationnelle se teste tôt, bien avant d'être développée. On peut simuler le dialogue à la main : une personne joue le rôle du système et répond aux utilisateurs, en suivant les règles dessinées. Cette méthode rudimentaire révèle les impasses, les questions mal posées et les moments où la personne ne sait plus quoi répondre. Elle coûte peu et corrige des erreurs qui, laissées en production, exigeraient des semaines de développement. Mieux vaut un prototype imparfait testé sur quelques cas réels qu'un enchaînement élégant jamais confronté au moindre usager. Le test précoce est rarement spectaculaire, mais il économise beaucoup de temps perdu.
Ce qui s'observe pendant ces essais n'est pas seulement le succès de la tâche. On regarde les hésitations, les reformulations spontanées, les abandons. Une personne qui reformule sa demande signale souvent que le système n'a pas compris son intention première. Une autre qui répète la même phrase indique qu'elle n'a pas vu la réponse. Ces signaux guident la refonte du parcours et nourrissent les critères d'évaluation du futur système. Tester un dialogue relève autant de l'observation que de la mesure, et la maquette n'a d'intérêt que si elle sert à provoquer ces observations concrètes, plutôt qu'à décorer une présentation.
Les angles morts du prototype
Un prototype reste silencieux sur ce qui fait la difficulté réelle d'un assistant. La latence, par exemple, ne se dessine pas : une réponse juste mais lente se vit comme une panne. L'ambiguïté non plus, car dans une maquette le texte est préparé à l'avance, sans les fautes de frappe ni les tournures inattendues. La mémoire du contexte, enfin, échappe au fichier de conception alors qu'elle décide de la qualité d'un échange suivi. Ces dimensions relèvent des tests d'intégration et de l'ingénierie, pas du dessin. Le designer doit les anticiper pour que la conception ne promette pas ce que la technique ne peut pas tenir.
Le passage de la maquette au produit vivant se joue dans la documentation. Les intentions, leurs réponses attendues, les cas de refus et les conditions de reprise humaine constituent un cahier des charges que le code doit respecter. Sans ce livrable, chacun réinterprète le dialogue à sa façon et le comportement réel s'éloigne peu à peu du dessin. Il faut donc prévoir dès la conception les points de contrôle, les journaux à conserver et les garde-fous pour les actions sensibles. Une interface conversationnelle sérieuse se juge à la cohérence entre ce qui a été pensé, ce qui a été construit et ce que la personne a réellement vécu.
Aller plus loin
Concevoir un dialogue dans Figma n'a de sens que si le prototype annonce ce que le système saura tenir en production. Pour apprendre à relier design, usages et technique, explorez le catalogue des 31 formations.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations