Wireframe, maquette, prototype : dans un brief, lors d’un devis ou en réunion client, ces trois mots sont souvent utilisés de façon interchangeable. Ils ne le sont pas. Chacun désigne un livrable précis, avec un niveau de fidélité différent, un objectif différent et une place déterminée dans le processus de conception.
Confondre les trois ne fait pas seulement perdre du vocabulaire. Ça crée des attentes mal alignées entre designers, développeurs et clients, et parfois des retours tardifs qui auraient pu être évités plus tôt dans le projet.
Le wireframe : la structure avant tout
Le wireframe est le premier livrable tangible d’un projet d’interface. C’est un schéma en niveaux de gris, sans couleur ni typographie travaillée, qui montre où se placent les éléments : navigation, blocs de contenu, zones d’image, boutons, formulaires.
Son rôle est de répondre à une seule question : est-ce que la structure de la page à du sens ? Pas si c’est beau. Pas si ça fonctionnera techniquement. Juste si l’organisation de l’information est logique pour l’utilisateur.
Un wireframe délibérément rudimentaire est un avantage, pas un défaut. Il force les discussions à rester sur la structure et évite que le client ne commente la couleur d’un bouton alors qu’on valide encore l’arborescence.
Les wireframes se font sur papier, sur tableau blanc, ou avec des outils comme Figma, Balsamiq ou Whimsical. La rapidité d’exécution prime sur la finition.
La maquette : le design tel qu’il sera
La maquette (ou mockup) est la version haute fidélité de l’interface. Couleurs, typographie, icônes, espacements, images : tout est représenté tel que ça apparaîtra dans le produit final. C’est un fichier statique, non interactif, qui permet de valider les choix visuels.
C’est à ce stade que le design system entre vraiment en jeu. Les composants, les couleurs et les styles définis en amont s’assemblent pour former des écrans cohérents et conformes à l’identité visuelle du produit.
La maquette sert à :
- Valider les choix visuels avec le client avant de développer
- Préparer les assets pour le handoff développeur
- Documenter l’état cible du produit
- Présenter l’interface à des parties prenantes non techniques
Le prototype : tester avant de développer
Le prototype est cliquable et navigable. Il simule l’expérience réelle : l’utilisateur peut cliquer sur des boutons, naviguer entre les écrans, remplir des champs. Il ne développe rien en dur : c’est une simulation qui permet de tester les flux avant d’écrire une ligne de code.
Les prototypes existent à deux niveaux de fidélité :
- Basse fidélité : wireframes cliquables, utiles pour tester la logique de navigation en phase exploratoire
- Haute fidélité : maquettes finalisées avec interactions, utilisés pour les tests utilisateurs formels et la validation avant développement
Figma permet de créer des prototypes directement depuis les maquettes, ce qui a simplifié le processus. Avant, wireframe, maquette et prototype étaient souvent dans des outils différents.
Les trois livrables en un coup d’oeil
| Wireframe | Maquette | Prototype | |
|---|---|---|---|
| Fidélité | Basse | Haute | Basse à haute |
| Interactif | Non | Non | Oui |
| Objectif | Valider la structure | Valider le visuel | Tester les flux |
| Audience | Équipe produit | Client, équipe | Utilisateurs, équipe |
| Outils courants | Figma, Balsamiq, papier | Figma, Sketch | Figma, Marvel, ProtoPie |
Dans quel ordre et pourquoi
L’ordre classique est wireframe, maquette, prototype. Mais en pratique, il dépend du projet et du niveau de risque à valider.
Sur un projet simple avec un client expérimenté, on peut sauter les wireframes et aller directement en maquette. Sur un projet complexe avec des flux utilisateurs nouveaux ou un public peu testé, un prototype basse fidélité tôt dans le processus évite des retours coûteux après développement.
La règle de fond : plus une décision est risquée ou coûteuse à corriger tard, plus elle mérite d’être validée tôt avec le livrable le plus léger possible. Valider une structure en wireframe prend une heure. Corriger la même structure après développement peut prendre plusieurs jours.
Ce que ça change dans la relation client
Clarifier ces trois termes en début de projet n’est pas un exercice pédagogique. C’est une façon de cadrer les livrables et les moments de validation dans le planning.
Un client qui reçoit un wireframe et le commente comme si c’était la maquette finale va demander des changements de couleur sur un fichier en niveaux de gris. Un client qui comprend qu’il valide la structure, pas le visuel, donne des retours utiles au bon moment.
C’est aussi un outil de gestion de projet : chaque livrable correspond à une validation formelle, ce qui réduit les allers-retours non facturés en fin de mission. Un point que connaissent bien les designers qui travaillent en freelance et qui doivent cadrer précisément les phases de leur process.
