Générer une interface cliquable prend désormais quelques heures. Le prototypage n'est plus le point dur d'un projet applicatif, et c'est précisément ce qui crée le piège : une maquette convaincante est confondue avec une preuve. La vraie question devient de savoir ce que ce prototype démontre, et devant qui. Voici comment transformer une maquette en décision, en une demi-journée de test utilisateur.

Config 2026 : le prototype se fabrique plus vite qu'il ne se valide

Le 24 juin 2026, à l'occasion de sa conférence annuelle Config à San Francisco, Figma a présenté un canvas qui réunit design, code et agents dans un même espace. Les équipes peuvent y cloner un dépôt de code, le faire vivre dans l'outil de design, puis resynchroniser les modifications vers le code. S'y ajoutent un module d'animations connecté aux systèmes de design, la génération d'effets visuels par instruction, plus de vingt outils de workflows IA et des agents capables de produire des extensions sur simple demande. Le déploiement est progressif et les disponibilités varient selon les modules. Dylan Field, cofondateur de Figma, y dénonce les « faux choix entre design et code » imposés par l'outillage.

Le mouvement dépasse un seul éditeur : Google pousse son propre outil de conception d'interfaces par IA, et les suites créatives enrichissent toutes leurs assistants. Pour une PME, la conséquence est simple. Le coût de fabrication d'un prototype s'effondre, celui de la validation ne bouge pas d'un centimètre. Une équipe peut aujourd'hui produire trois variantes d'un écran de saisie en une matinée et n'avoir toujours aucune idée de celle qui fera gagner du temps à ses opérateurs.

Ce qu'un prototype prouve, et ce qu'il ne prouve pas

Un prototype d'interface répond bien à quatre questions, et à elles seules : le vocabulaire affiché est-il celui du métier, l'ordre des étapes correspond-il au geste réel, une information indispensable manque-t-elle à l'écran au moment de décider, et entre deux options laquelle fait gagner des actions.

Il ne prouve rien sur le reste. Ni la tenue en charge, ni le comportement avec vingt mille lignes au lieu de douze, ni la gestion des droits, ni la solidité des intégrations, ni la durée réelle d'une saisie complète, ni l'adoption six mois plus tard. Un écran de liste magnifique sur un jeu de dix enregistrements soigneusement choisis dit très peu de choses de la vie d'un utilisateur qui en traite deux cents par jour. Confondre les deux niveaux est l'erreur la plus coûteuse de la phase amont : elle fait valider un budget de développement sur une démonstration plutôt que sur une observation.

Avant le test : trois décisions à prendre

Un test utilisateur improvisé produit des avis, pas des enseignements. Trois décisions, prises par écrit avant la première session, font toute la différence.

  • Une seule question à trancher. « Le nouveau parcours de saisie d'intervention est-il compris sans formation par un technicien ? » se teste. « Que pensez-vous de l'application ? » ne se teste pas.
  • Trois tâches réelles, formulées comme le métier les formule, pas comme le logiciel les nomme. « Vous rentrez de chez un client, enregistrez votre passage et les pièces utilisées » plutôt que « créez un rapport dans le module d'intervention ».
  • Un critère observable, fixé à l'avance : tâche terminée sans aide, nombre d'hésitations de plus de cinq secondes, endroit exact où la personne s'arrête. On mesure des faits, pas des déclarations.

Le protocole en une demi-journée

Cinq personnes, trente à quarante minutes chacune, un après-midi : c'est un format tenable pour une PME, et il suffit à sortir des convictions de couloir.

  1. Recrutez ceux qui font le geste. Pas le directeur, pas le chef de projet, pas l'informaticien : la personne qui saisira réellement, dans ses conditions réelles, y compris debout ou avec des gants si c'est le cas.
  2. Donnez une tâche, pas une visite guidée. Aucune présentation préalable de l'interface. La personne découvre, comme elle découvrira le jour du déploiement.
  3. Taisez-vous. Demandez de penser à voix haute, puis laissez le silence faire son travail. Toute réponse donnée à une question de l'observateur est une donnée perdue.
  4. Notez les faits. Un observateur distinct de l'animateur relève les actions, les blocages et les phrases exactes, jamais les interprétations.
  5. Corrigez entre deux séries. Si le même mur apparaît trois fois, arrêtez, corrigez le prototype, et testez la correction avec les suivants. L'objectif est d'améliorer la conception, pas de documenter ses défauts.

Cinq utilisateurs suffisent-ils ? Ce que dit la recherche

La règle vient d'un modèle mathématique publié par Jakob Nielsen et Thomas Landauer à la conférence ACM INTERCHI'93, à Amsterdam en avril 1993, popularisé par un article du Nielsen Norman Group du 18 mars 2000. En moyenne sur les projets étudiés, un seul participant révèle environ 31 % des problèmes d'utilisabilité d'une interface, et cinq participants en révèlent environ 85 %. Il faudrait une quinzaine de personnes pour tout trouver, mais le groupe recommande explicitement de dépenser ce budget en trois études de cinq plutôt qu'en une seule de quinze, puisque le second test vérifie que les corrections fonctionnent et creuse des sujets que les blocages de surface masquaient.

Deux nuances comptent en contexte métier. D'abord, la règle vaut pour un groupe d'utilisateurs homogène : si votre application sert à la fois des commerciaux et des préparateurs d'atelier, comptez trois à quatre personnes par catégorie. Ensuite, cinq participants servent à trouver des problèmes, pas à produire des chiffres : pour mesurer un temps de traitement ou un taux de réussite avec un minimum de fiabilité, le même organisme recommande une vingtaine de participants. Un test à cinq personnes ne permet jamais d'affirmer que « 40 % des utilisateurs se trompent ».

Cinq erreurs fréquentes

  • Tester avec l'équipe projet. Elle connaît déjà le modèle de données, elle ne peut plus se perdre.
  • Présenter au lieu d'observer. Dès que l'on explique, on teste sa propre pédagogie, pas l'interface.
  • Demander un avis. « Vous aimez ? » produit de la politesse. « Faites-le » produit de l'information.
  • Prototyper sur un jeu de données trop propre. Les cas limites, les libellés à rallonge et les enregistrements incomplets sont précisément ce qui casse un écran.
  • Ne rien décider. Un test qui ne se termine pas par une décision écrite entre corriger, poursuivre ou renoncer n'était qu'une réunion de plus.

Questions fréquentes

Faut-il un prototype cliquable ou un simple schéma papier suffit-il ?

Les deux se testent, et le papier reste redoutablement efficace pour valider l'ordre des étapes et le vocabulaire. Le prototype cliquable devient utile quand la question porte sur la navigation, les états d'un écran ou la densité d'information.

Combien d'utilisateurs faut-il pour un test utilisateur ?

Cinq personnes d'un même profil révèlent environ 85 % des problèmes d'utilisabilité selon les travaux de Nielsen et Landauer. Prévoyez trois à quatre personnes par catégorie si vos utilisateurs forment des groupes vraiment différents, et une vingtaine si vous voulez des mesures chiffrées.

Peut-on réutiliser le code d'un prototype généré par IA ?

Partiellement, et rarement tel quel. Ce qui se réutilise le plus sûrement, ce sont les enseignements du test, les règles de gestion mises au jour et les écrans validés comme référence de conception. Le code généré doit être traité comme une proposition à reprendre, pas comme une base de production.

Peut-on tester avec les données réelles de l'entreprise ?

Un prototype est un environnement peu protégé. Travaillez avec des données fictives ou anonymisées qui reproduisent les cas limites réels, et réservez les données de production à des environnements sécurisés au niveau de la production.

À quel moment ce test intervient-il dans un projet ?

Avant l'engagement du budget de développement, et de nouveau après chaque correction significative. Un test mené une fois le développement lancé ne sert plus à décider, seulement à négocier des retouches.

Passer de la maquette à la décision

Le prototypage rapide n'a de valeur que s'il raccourcit le délai entre une idée et une décision documentée. Chez Pulsar Forge, un prototype est livré avec les tâches à faire exécuter, le critère de réussite et la grille d'observation : sans cela, il reste une belle image.

Parlons de votre projet