Maquette cliquable : tester une application avant le code

Le moment le moins cher pour changer une application, c’est avant qu’elle existe. Une maquette cliquable permet justement de la faire essayer sans la construire : des écrans reliés entre eux, que l’on parcourt du doigt ou à la souris, comme la vraie. Avant tout développement, elle montre si les futurs utilisateurs trouvent leur chemin, et elle transforme une idée floue en périmètre qu’un devis peut chiffrer.

Ce qu’est une maquette cliquable, et ce qu’elle n’est pas

Elle se distingue de deux choses avec lesquelles on la confond :

• Une image d’écran se regarde ; une maquette cliquable se parcourt. C’est le parcours qu’on teste, pas la couleur des boutons.
• Un prototype codé fonctionne vraiment, avec des données. Il coûte plus cher, et on a souvent du mal à le jeter quand il le faudrait.

Les outils de conception d’interface (Figma, ou Penpot côté logiciel libre) produisent ce genre de maquette, et les générateurs d’interfaces par IA en dessinent une première version en quelques minutes. L’outil compte peu : ce qui compte, c’est de la mettre entre les mains des bonnes personnes.

Pourquoi tester avant de coder

Changer un écran dans une maquette prend quelques minutes. Changer un parcours dans une application développée oblige à reprendre les écrans, les règles, les tests, parfois la base de données. Le test sur maquette sert à faire les erreurs là où elles coûtent le moins.

Il n’a pas besoin d’être grand. L’argument le plus cité vient de Jakob Nielsen, du cabinet Nielsen Norman Group :

C’est un repère, pas une loi : l’article date de 2000, et son auteur précise lui-même qu’il faut tester davantage quand les utilisateurs forment des groupes très différents (un technicien sur le terrain et une assistante au bureau ne buteront pas sur les mêmes écrans). Mais l’idée tient : plusieurs petits tests, avec une correction entre chacun, apprennent plus qu’un seul grand.

Comment se déroule un test sur maquette

1. 01Choisir trois tâches réelles.

   « Déclarer une intervention terminée », « retrouver le dossier d’un client » : des gestes du quotidien, pas une visite guidée.

2. 02Recruter de vrais utilisateurs.

   Cinq personnes du profil visé, pas les membres du projet, qui connaissent déjà la réponse.

3. 03Les laisser faire, sans aider.

   On leur demande de penser à voix haute ; on note où elles hésitent, reviennent en arrière ou cherchent un bouton qui n’existe pas.

4. 04Corriger la maquette.

   Les blocages vus par plusieurs testeurs passent en premier.

5. 05Tester à nouveau.

   Avec d’autres personnes, sur la version corrigée.

Ce que la maquette fixe pour la suite

Une maquette validée n’est pas seulement un dessin : c’est la meilleure description possible de ce que l’application doit faire le premier jour. Chaque écran dit ce qu’il faut afficher, chaque bouton ce qu’il faut enregistrer, chaque parcours qui a le droit de faire quoi.

C’est elle qui permet un devis ligne par ligne plutôt qu’une fourchette. Les décisions qui font varier le prix (comptes et rôles, temps réel, hors ligne, notifications, intégrations) y apparaissent noir sur blanc, comme nous l’expliquons dans ce qui fait varier le prix d’une application. Et ce qui n’est pas dans la maquette attendra une version suivante : c’est la meilleure protection contre les fonctions ajoutées en route.

Quand peut-on s’en passer ?

La maquette n’est pas une étape obligatoire. On peut la sauter, ou la réduire à quelques écrans, quand :

• L’application reprend un parcours que l’équipe connaît déjà par cœur, par exemple un formulaire papier existant à mettre sur téléphone.
• Une première version peut être en ligne très vite. Pour Challenge Us, une application de défis de groupe que nous avons développée, l’idée, le cadrage et le premier code tiennent dans la journée du 1er septembre 2026, et la version 1.0 tournait dans le navigateur le lendemain. Dans ce cas, une vraie version installable, mise entre les mains d’utilisateurs, joue le rôle de la maquette : c’est l’approche décrite dans notre comparatif entre application web installable et application des stores.
• La décision ne porte pas sur le parcours mais sur le choix entre un logiciel existant et un développement : voir sur mesure ou outil du marché.

Une maquette générée en quelques minutes par une IA est tentante, mais elle a les limites de toute maquette : elle montre un parcours, pas un produit qui tient en production. Nous en parlons dans notre article sur le vibe coding.

Pour passer de la maquette validée à une application en service, notre développement d’applications commence par ce cadrage écrit, puis met une première version entre les mains de vos utilisateurs.

Questions fréquentes