Wireframe vs mockup vs prototype : ce que vous validez

Une fondatrice avec qui nous avons travaillé l’an dernier a passé trois semaines de revues de design à approuver poliment des boîtes grises. Elle pensait que le studio lui montrait un produit inachevé et qu’il traînait. Ce qu’elle regardait en réalité, c’était un wireframe, et son travail dans ces réunions était de repérer un problème de structure qu’il aurait coûté cinq chiffres de corriger deux mois plus tard. Elle n’en a repéré aucun, parce que personne ne lui avait dit que c’était la mission. Le parcours de checkout plaçait l’étape de paiement au mauvais endroit. C’est parti en production comme ça, et le correctif est tombé en semaine neuf au lieu de la semaine une.

Cet écart est le sujet de cet article. La question wireframe vs mockup ressemble à un problème de designer, mais si vous payez un studio pour construire un logiciel sur mesure et que vous n’écrivez pas de code, elle est la vôtre : une fois que la phase de discovery a défini ce que vous construisez, on vous remettra des wireframes, puis des mockups, puis un prototype, en général dans cet ordre, et on vous demandera de valider chacun. Savoir à quoi sert chacun fait la différence entre un retour qui vous fait gagner un mois et un retour qui gâche l’après-midi de tout le monde.

Voici la version courte de wireframe vs mockup vs prototype, les trois mots que vous entendrez le plus. Un wireframe est le plan : des boîtes grises et des étiquettes montrant ce qui va où et comment les écrans s’enchaînent, sans couleur ni marque. Un mockup, ce sont ces mêmes écrans avec le vrai design visuel appliqué : vos couleurs, vos typographies, l’espacement, votre logo, l’apparence pour de vrai. Un prototype, c’est le mockup relié pour que vous puissiez cliquer et naviguer comme dans une vraie app, même si rien derrière les boutons ne fonctionne encore. Le wireframe répond “la structure est-elle bonne ?”. Le mockup répond “est-ce que ça nous ressemble ?”. Le prototype répond “est-ce que le parcours marche vraiment ?”. Trois artefacts, trois questions, trois rôles différents pour vous.

Wireframe vs mockup vs prototype : pourquoi le studio les montre dans cet ordre

L’ordre n’est pas arbitraire, et ce n’est pas le studio qui traîne. C’est le studio qui dépense votre argent dans la séquence la moins chère possible.

Changer un wireframe prend quelques minutes. Quelqu’un déplace une boîte, renomme une étiquette, fait passer un bouton du haut de l’écran vers le bas. Changer un mockup prend plus de temps, parce qu’il y a maintenant du vrai design visuel à refaire : l’espacement, le traitement de la couleur, l’apparence du composant dans trois états. Changer un prototype prend encore plus de temps. Et changer le logiciel réellement construit, ce qui tourne sur du vrai code, est le changement le plus cher de tous, parfois d’un ordre de grandeur.

Alors un studio compétent met en avant les décisions faciles à défaire et repousse le travail coûteux et difficile à défaire vers la fin. Il règle la structure d’abord, quand la structure est libre de bouger. Il règle le design visuel ensuite. Il confirme le parcours en dernier, avant qu’une seule ligne de code de production ne soit écrite. Toute la séquence existe pour trouver vos objections tant qu’elles sont encore bon marché. C’est aussi là que le périmètre abstrait que vous avez écrit dans un document d’exigences que le studio peut chiffrer devient enfin quelque chose que vous pouvez voir et auquel vous pouvez réagir.

C’est aussi pour ça que “sautez les wireframes et montrez-moi tout de suite le rendu” est une demande tentante qui se retourne souvent contre vous. Quand vous sautez directement à un mockup soigné, vous et le studio commencez à débattre de la nuance de bleu et des coins arrondis, et personne ne remarque que tout le modèle de navigation est faux. Le soin masque les problèmes de structure. Les boîtes grises existent justement parce qu’elles n’ont rien de joli pour vous distraire.

Ce que vous validez vraiment à chaque étape

Les artefacts sont faciles à définir. La partie difficile, celle que les blogs d’outils de design ne couvrent jamais, c’est ce que vous êtes censé faire quand l’un d’eux arrive dans votre boîte mail. Voici le travail à chaque étape.

Wireframe : vérifiez la plomberie. Chaque écran dont l’utilisateur a besoin existe-t-il vraiment ? Peut-on aller de l’inscription jusqu’à ce pour quoi la personne est venue sans impasse ? L’action la plus importante de chaque écran est-elle la plus évidente ? Demandez-vous l’information au bon moment, ou réclamez-vous une carte bancaire avant que l’utilisateur ait compris ce qu’il achète ? Ce sont des questions de structure, et le wireframe est la seule étape où y répondre coûte peu. Si quelque chose dans le parcours sonne faux ici, dites-le fort. C’est la réunion qui compte le plus et celle que les fondateurs prennent le moins au sérieux, parce qu’elle a l’air inachevée.

Mockup : vérifiez l’identité et la hiérarchie. Il y a maintenant du vrai design, donc votre jugement visuel sert enfin. Est-ce que cela ressemble à un produit auquel votre client confierait son argent ou ses données ? Ce que vous voulez le plus voir cliqué est-il visuellement plus fort que ce que vous ne voulez pas ? L’écran dense, celui avec le tableau ou le dashboard, reste-t-il lisible ? Ici, “rendez le bouton principal plus visible” est une remarque utile. Elle aurait été inutile sur le wireframe, où tout est gris exprès.

Prototype : parcourez-le comme un utilisateur perdu. Cliquez au mauvais endroit exprès. Essayez de faire la tâche principale comme si vous n’aviez jamais vu l’app. Donnez-le à quelqu’un qui ressemble à votre vrai client et regardez-le se bloquer sans l’aider. Le prototype est la dernière chance bon marché de découvrir qu’un parcours qui tenait debout sur une image fixe s’effondre dès qu’une vraie personne tente de le traverser. Le Nielsen Norman Group, le nom le plus cité en recherche sur l’utilisabilité, montre depuis des décennies que même des prototypes grossiers attrapent la majorité des problèmes de parcours qu’un vrai build expédierait sinon en production. Vous n’avez pas besoin d’un prototype parfait pour apprendre l’essentiel. Vous avez besoin d’un prototype cliquable et d’un testeur honnête.

L’erreur de retour qui coûte un mois

L’erreur la plus fréquente et la plus chère que commettent les fondateurs non techniques en revue de design, c’est de donner le mauvais type de retour à la mauvaise étape. Précisément : un retour cosmétique sur un wireframe, et un retour de structure sur un mockup.

Quand vous dites au designer que la typo du wireframe est moche, vous n’avez rien dit, parce que le wireframe n’a pas de vraie typo. Vous avez aussi signalé que vous pensez que votre rôle est de réagir à l’apparence, ce qui vous entraîne à continuer de réagir à l’apparence justement aux étapes où la structure est la seule chose qui compte. Pendant ce temps, le problème de navigation reste là, sans que personne le mentionne.

L’inverse coûte tout aussi cher. Quand vous attendez le mockup soigné pour dire “en fait, les utilisateurs devraient pouvoir tout faire en un écran au lieu de trois”, vous venez de demander un changement de structure après que la structure était censée être figée. Le studio refait alors un design que vous aviez déjà validé, et le délai qu’on vous a promis glisse en silence. Tous les studios ont vécu ça. C’est la première cause d’un build en retard alors que, techniquement, chacun a fait son travail.

Le remède est simple à énoncer et exige de la discipline à tenir. Faites correspondre votre retour à l’artefact. La plomberie sur le wireframe. L’identité et la hiérarchie sur le mockup. Le parcours sur le prototype. Quand vous vous surprenez à vouloir parler de couleur sur un écran gris, notez la remarque et gardez-la pour le mockup. Quand vous vous surprenez à vouloir réorganiser les écrans sur un mockup terminé, arrêtez-vous et demandez pourquoi cela n’est pas sorti à l’étape du wireframe, parce que l’attraper maintenant coûte de l’argent pour de vrai.

Figma est-il un wireframe ?

Non, et la confusion mérite d’être levée parce que vous allez entendre le mot “Figma” en permanence. Figma est l’outil que la plupart des studios utilisent pour dessiner les trois : wireframes, mockups et prototypes cliquables vivent tous dans le même fichier Figma. Donc “on est sur Figma” ne vous dit rien sur l’étape que vous regardez. Demandez directement : est-ce un wireframe, un mockup ou un prototype ? La réponse vous dit quel retour le studio attend vraiment de vous maintenant.

Idem pour les autres outils dont vous entendrez peut-être le nom. Balsamiq est fait pour des wireframes en basse fidélité, exprès, avec un rendu croquis fait main pour que personne ne le confonde avec du travail fini. Sketch et Figma couvrent toute la gamme. L’outil n’est pas le sujet. La fidélité est le sujet, et la fidélité n’est qu’un mot savant pour dire à quel point une chose a l’air finie. Basse fidélité veut dire boîtes grises. Haute fidélité veut dire que ça pourrait passer pour la vraie app. Si les designers vont vers la basse fidélité tôt, c’est pour la même raison que le studio vous montre des wireframes d’abord : ça vous garde concentré sur la décision réellement en jeu.

Avez-vous besoin des trois ?

Pas toujours, et un bon studio vous dira quand ce n’est pas le cas. Le bon nombre dépend de ce que vous construisez.

Si vous validez une idée encore brute et que les écrans sont simples, des wireframes plus un prototype léger peuvent suffire, et le mockup visuel peut accompagner le build. Si vous construisez quelque chose où la confiance et la finition sont le produit, le portail patient d’une clinique haut de gamme, un dashboard de fintech qui manie de l’argent réel, vous voulez les trois et vous voulez consacrer une vraie attention au mockup, parce que la couche visuelle fait un travail porteur. Si vous étendez un produit qui existe déjà et possède un design system, vous pouvez aller droit aux mockups, parce que les décisions de structure et de visuel ont été réglées il y a longtemps et que les réutiliser est tout l’intérêt.

Ce dont vous devez vous méfier, c’est d’un studio qui veut sauter complètement le wireframe sur un build parti de zéro et aller droit à des écrans soignés. Parfois c’est très bien, pour un périmètre minuscule. Souvent, cela veut dire qu’on saute la réflexion de structure, et vous paierez ce saut plus tard, dans le build, là où les changements coûtent le plus cher. L’ordre existe pour protéger votre budget. Le compresser est une décision, pas un accident, et vous avez le droit de demander pourquoi.

Rien de tout cela n’exige que vous appreniez le design. Cela exige que vous sachiez quelle question on vous pose, et que vous répondiez à cette question plutôt qu’à celle qui attire votre œil par hasard. Réussissez ça et la phase de design devient ce qu’elle doit être : l’endroit le moins cher pour avoir tort avant le build, là où avoir tort devient cher. Voilà toute la raison d’être de ces trois artefacts, et la raison pour laquelle un studio vous y fait passer dans l’ordre. Le plan, puis l’apparence, puis la preuve que ça marche, chacun une occasion de changer d’avis tant que changer d’avis ne coûte presque rien.

FAQ

Quelle est la différence entre un mockup et un wireframe ?
Un wireframe est le plan de structure : des boîtes grises et des étiquettes montrant ce qui va où et comment les écrans s’enchaînent, sans couleur ni marque. Un mockup, ce sont les mêmes écrans avec le vrai design visuel appliqué, y compris les couleurs, les typographies, l’espacement et votre logo. Le wireframe règle la structure ; le mockup règle l’apparence. Les studios font le wireframe d’abord parce que les changements de structure y sont bon marché et coûteux à toutes les étapes suivantes.

Quelle est la différence entre un wireframe et un prototype ?
Un wireframe est une maquette statique que vous lisez. Un prototype est interactif : des écrans reliés pour que vous puissiez cliquer dans le produit et ressentir le parcours, même si les boutons ne font encore rien de réel. Le wireframe vous montre la structure d’un écran à la fois. Le prototype vous montre si passer d’un écran à l’autre a du sens pour une vraie personne qui essaie d’accomplir une tâche.

Figma est-il un wireframe ?
Non. Figma est un outil de design qui produit des wireframes, des mockups et des prototypes cliquables, tous dans le même fichier. Entendre “c’est sur Figma” ne vous dit donc pas quelle étape vous passez en revue. Demandez directement au studio si vous regardez un wireframe, un mockup ou un prototype, parce que chacun a besoin d’un type de retour différent.

Quels sont les types de prototype ?
Les prototypes se décrivent en général par fidélité, c’est-à-dire à quel point ils ont l’air finis. Un prototype basse fidélité fait cliquer à travers des écrans gris de wireframe pour tester le parcours ; un prototype haute fidélité fait cliquer à travers les mockups soignés et peut passer pour la vraie app dans une démo. Pour la plupart des fondateurs, la distinction utile est simplement basse contre haute fidélité : servez-vous d’un prototype basse fidélité pour tester si le parcours marche, et d’un haute fidélité quand il vous faut une démo qui a l’air réelle pour un investisseur ou un client.