Wireframe — ce que le croquis tranche, et ce que le code ne peut plus défaire

Le wireframe est l’étape la plus souvent sautée d’un projet de site et le moment le moins cher pour encore changer quelque chose. On le saute parce qu’il ne montre aucun progrès : il est en noir et blanc, laid, et ressemble à quelque chose dessiné en cinq minutes.

Cette impression vous coûte exactement l’écart entre déplacer un bloc sur un croquis et le déplacer sur un site en ligne. L’écart est d’environ trente fois, et nous allons montrer d’où il vient.

Wireframe, maquette, prototype — trois mots, trois choses différentes

Les clients les emploient indifféremment, alors que chacun tranche autre chose, apparaît à une autre étape et coûte différemment. Les confondre est la raison la plus fréquente pour laquelle une conversation sur un projet part de travers.

Le wireframe — le squelette. Basse fidélité, une disposition de blocs en noir et blanc. Aucune photo, aucune couleur, aucune typographie au-delà de celle par défaut. Il tranche ce qui figure sur la page, dans quel ordre et ce qui prime sur quoi. C’est la seule chose que vous jugez à ce stade — et volontairement, rien d’autre n’y est jugeable.

La maquette — la couche visuelle. Haute fidélité, le design complet : couleurs de la marque, typographie, photos, icônes, états des boutons. Elle tranche l’apparence. Elle se construit sur un wireframe validé, pas à sa place.

Le prototype — le comportement. Un modèle cliquable, généralement dans un outil de design, où les boutons mènent aux écrans suivants. Il tranche si le parcours a du sens, avant qu’une ligne de code soit écrite. Sur un site d’entreprise simple, il peut être superflu ; sur un formulaire à plusieurs étapes, un configurateur ou un espace client, c’est lui qui fait économiser le plus.

La conséquence pratique : si l’on vous remet un « wireframe » avec des couleurs et des photos, on vous a remis une maquette — et la conversation glissera vers la teinte d’un bouton avant que quiconque ait vérifié si le formulaire est au bon endroit.

Ce que le croquis tranche, et ce qu’il ne peut plus trancher

Quatre décisions se prennent sur un wireframe, et toutes les quatre sont coûteuses à défaire dans le code.

Ce qui est visible sans faire défiler. L’écran d’ouverture contient une seule chose la plus importante, pas quatre à égalité. Décider laquelle est une décision commerciale et non graphique — et sur un croquis, ce choix se voit immédiatement, parce qu’aucune couleur ne vient le masquer.

L’ordre des sections. Les avis clients passent-ils avant ou après la description de l’offre. Les tarifs se trouvent-ils au-dessus du formulaire. Ce sont des déplacements de blocs qui prennent quelques minutes sur un croquis.

Le chemin vers l’action. Combien d’étapes séparent l’arrivée sur le site de l’envoi d’une demande, et combien sont réellement nécessaires. Chaque étape superflue est plus facile à supprimer maintenant qu’une fois qu’elle possède son composant, son adresse et ses tests.

Ce qui ne tiendra pas du tout. La fonction la plus inconfortable et la plus précieuse d’un wireframe : il montre qu’on ne peut pas tout faire tenir, et il oblige à choisir avant que le hasard ne choisisse à votre place.

Ce que vous ne tranchez pas sur un wireframe : les couleurs, les photos, la typographie, les textes exacts. Si la conversation glisse vers ces sujets à ce stade, l’étape est gaspillée.

Ce que coûte la même modification à chaque étape

Remonter un formulaire, c’est un quart d’heure dans un outil de design au stade du wireframe. La même modification sur un site en ligne est une autre opération, et il vaut la peine de comprendre pourquoi — car l’écart ne vient ni de la mauvaise volonté de quiconque ni d’un devis gonflé.

Une modification de mise en page dans le code entraîne une chaîne :

• la refonte du composant qui affiche ce bloc, avec ses variantes téléphone et ordinateur,
• la modification de la structure de contenu dans le système de gestion, si le bloc possède ses propres champs à ajouter, déplacer ou supprimer,
• la correction des requêtes qui récupèrent les données, car le composant demande désormais autre chose,
• une refonte des styles, pour que la nouvelle disposition ne casse pas les sections voisines,
• des tests de régression, c’est-à-dire vérifier que rien de ce qui fonctionnait ne s’est cassé au passage.

Chacune de ces étapes est minime prise isolément. Ensemble, elles transforment un quart d’heure en quinze à trente heures de travail, tests compris.

Le rapport est donc d’environ 1 à 30, et c’est toute l’économie de cette étape. Un wireframe ne vaut pas ce que coûte son dessin — il vaut ce que coûterait la découverte du même problème trois mois plus tard.

Comment tester un wireframe avant de le valider

La façon habituelle de juger un croquis, c’est que la personne qui commande le site le regarde et dit « ça me plaît ». C’est le test le plus faible qui soit, parce que cette personne connaît l’offre par cœur et sait où chercher.

Il existe une méthode moins chère et bien plus efficace, et elle repose sur une base documentée. Jakob Nielsen l’a publiée le 18 mars 2000 et elle est depuis l’une des règles les mieux confirmées du domaine : un test avec cinq utilisateurs détecte environ 85 % des problèmes d’utilisabilité.

Le chiffre ne sort pas de nulle part : il découle d’une formule dans laquelle un utilisateur seul trouve en moyenne environ 31 % des problèmes, les suivants répétant largement les mêmes découvertes. Après la cinquième personne, la courbe s’aplatit : du sixième au quinzième utilisateur, le coût est celui des cinq premiers et l’apport une dizaine de points de pourcentage.

La même publication contient une seconde conclusion, moins citée et plus pratique : le même budget vaut mieux dépensé en trois tests de cinq personnes qu’en un seul test de quinze. Après le premier test, vous corrigez ce qui est ressorti, et le deuxième examine la version corrigée au lieu de confirmer une fois de plus des problèmes connus.

Comment le faire sur un wireframe, sans outils et sans budget :

Écrivez trois tâches, pas des questions. Pas « que pensez-vous de cette mise en page », mais « trouvez les tarifs et allez jusqu’à l’envoi d’une demande ». Une question d’opinion donne une opinion ; une tâche donne un comportement.

Installez cinq personnes extérieures au projet. Elles n’ont pas besoin d’être clientes — à ce stade, des gens qui ne connaissent pas ce site suffisent. Quelqu’un de la comptabilité, quelqu’un de votre famille, le voisin du bureau d’à côté.

Regardez, n’expliquez pas. Au moment où vous expliquez où cliquer, le test est terminé. Une hésitation de dix secondes est un résultat, même si la personne finit par trouver.

Notez des endroits, pas des impressions. « Trois personnes sur cinq ont cherché les tarifs dans un menu qui n’en contient pas » est un résultat exploitable. « Ça leur a plu » ne l’est pas.

C’est la ligne de défense avant de dépenser de l’argent en développement : une erreur trouvée ici coûte un bloc déplacé, pas un composant refait.

Comment lire un wireframe que vous n’avez pas dessiné

On vous remet un fichier de rectangles gris et on vous demande de le valider. Cinq questions font la différence à ce moment-là — toutes posables sans aucune connaissance technique.

« Que doit faire quelqu’un qui arrive ici ? » Si la réponse est « prendre connaissance de l’offre », revenez au brief. La réponse doit être une action : envoyer le formulaire, appeler, réserver un créneau. Vérifiez ensuite que cette action est l’élément le plus visible du croquis.

« Pourquoi ce bloc est-il ici ? » Chaque section doit avoir une raison autre que « c’est comme ça qu’on fait ». Un concepteur capable de justifier l’ordre y a réfléchi ; un concepteur qui répond « c’est une disposition standard » a reproduit un gabarit.

« Qu’est-ce qui manque ici et figurait dans le brief ? » Un wireframe perd toujours quelque chose, parce que tout ne tient pas — c’est sa fonction. L’important est que ce soit une décision et non un oubli. Reprenez le brief point par point et cochez.

« Que se passe-t-il si le texte est deux fois plus long ? » Sur un croquis, les textes sont fictifs et commodément courts. Les vôtres seront plus longs. Un bloc conçu pour un titre de trois mots se disloque à huit, et vous l’apprendrez après la mise en ligne.

« Quels éléments pourrai-je modifier moi-même ? » Sur un croquis, cette question paraît prématurée, et c’est le dernier moment où la réponse est bon marché. Un bloc censé être modifiable doit être conçu ainsi — l’ajouter plus tard, c’est la même refonte que celle décrite dans la section sur le coût.

Une chose à ne pas faire à ce stade : recueillir les avis de cinq collègues d’un coup. Un wireframe appelle des commentaires sur l’apparence, parce qu’il a l’air brut, et chaque personne supplémentaire ajoute ses préférences. Mieux vaut désigner un décideur et mener le test par tâches décrit plus haut — cela donne du comportement au lieu de la préférence.

Un téléphone n’est pas une version plus petite

L’erreur la plus fréquente dans les wireframes d’entreprise : la mise en page est dessinée pour un écran large et la version téléphone en est déduite par rétrécissement. Cela ne fonctionne pas, parce que sur un écran étroit les blocs s’empilent et l’ordre devient la hiérarchie — ce qui se trouvait sur le côté en version bureau atterrit à la fin sur un téléphone.

La conséquence est concrète. Si, sur un écran large, le formulaire de contact occupe la colonne de droite et la description du service la gauche, alors sur un téléphone il faut faire défiler toute la description avant de voir le formulaire. Sur un croquis, cela se voit en cinq secondes ; dans du code terminé, c’est une refonte de composant.

Trois choses à trancher sur le wireframe séparément pour l’écran étroit :

Ce qui reste en haut. Un écran de bureau accueille un titre, une image et un appel à l’action. Un téléphone en accueille un seul. Choisissez lequel, au lieu de laisser l’ordre du code choisir pour vous.

Ce qui disparaît et ce qui se replie. Un menu, un tableau comparatif, une longue liste de références — chacun doit avoir un comportement conçu pour l’écran étroit. « On verra bien » signifie que le résultat sera un hasard.

Où atterrit le contact. Dans les entreprises de services, le numéro de téléphone est l’élément le plus utilisé du site, et sur un téléphone il doit être cliquable et visible sans défilement. C’est une décision sur un croquis et l’une des plus chères à défaire ensuite, parce qu’elle touche un en-tête présent sur chaque page.

Comment cela s’est passé chez nous — et ce que le wireframe n’a pas sauvé

Nous avons une réalisation où nous l’avons vérifié sciemment, et nous la présentons avec une réserve qui fait partie du résultat : c’est un site de démonstration, pas une mission client, donc elle parle de méthode et non de vente.

Nous n’avons pas commencé par un croquis mais par une architecture de l’information rédigée comme un contrat : chaque nœud du site a reçu un objectif, une audience, une liste de sections, des champs dans le système de gestion de contenu et des règles de mise à jour. L’effet a été celui que nous espérions — les wireframes se sont dessinés à partir de ce document sans tour de réécriture du périmètre, c’est-à-dire sans cette boucle caractéristique où le croquis révèle que le périmètre a été mal posé et où l’on revient à une conversation vieille de deux semaines.

Et voici la partie que nous ne passerons pas sous silence, parce qu’elle est plus intéressante : trois décisions de conception n’ont pas survécu au contact du code. Des choses qui semblaient tranchées sur le croquis se sont révélées irréalisables ou absurdes à l’implémentation, et il a fallu les changer en route. Nous avons consigné cet écart comme matière première plutôt que de le balayer — parce que c’est la limite réelle de cette méthode.

La conclusion a deux volets et les deux comptent. Un wireframe raccourcit le chemin vers la décision et élimine les erreurs de mise en page les plus chères. Mais il ne remplace pas le contact avec l’implémentation : certaines choses ne s’apprennent qu’une fois le code écrit, et le budget d’un projet devrait le prévoir au lieu de faire comme si rien ne changeait après la validation d’un croquis.

L’affirmation méthodologique elle-même — qu’une bonne architecture de l’information se transforme en croquis sans tour de corrections — reste chez nous une hypothèse à confirmer sur la prochaine réalisation, pas une règle. Une réalisation reste une réalisation. La description complète de ce projet figure dans le portfolio, en anglais, avec la liste de ce qui s’est passé autrement que prévu.

Basse ou haute fidélité — et quand cela n’a pas d’importance

On distingue les wireframes de basse et de haute fidélité, et le choix est plus simple que ne le suggèrent les guides.

La basse fidélité, ce sont des rectangles gris et des légendes. Cela se fait en quelques heures et suffit à une conversation sur la mise en page et à un test avec cinq personnes. Dans la plupart des projets d’entreprise, c’est tout ce qu’il faut.

La haute fidélité, c’est un croquis aux proportions réelles, avec les vrais textes et les vrais espacements — toujours sans couleurs et sans photos. Elle a du sens là où c’est la densité d’information qui se joue : tableaux comparatifs, tableaux de bord, configurateurs.

Et l’erreur de client la plus fréquente, celle qui fait perdre tout son sens à l’étape : une conversation sur les couleurs et les typographies devant un croquis de basse fidélité. Tant que la mise en page et la priorité des contenus ne sont pas validées, poser une couche visuelle est un travail qu’il faudra refaire. Le croquis est laid volontairement — c’est sa fonction, pas son défaut.

Règle pratique : si une phrase sur une teinte est prononcée en réunion wireframe, revenez à la question de savoir si ce bloc est au bon endroit.

Quand un wireframe est superflu

Il faut le dire, parce que tout ce texte défend une étape et qu’il existe des situations où cette étape n’apporte rien.

Quand le site repose sur un gabarit acheté que vous ne comptez pas refondre. Le gabarit est le wireframe — la mise en page a déjà été tranchée par quelqu’un d’autre, et votre décision se réduit au choix du gabarit et à son remplissage. Dessiner un croquis pour ensuite chercher un gabarit qui lui ressemble, c’est travailler à l’envers.

Quand il y a trois pages et que chacune tient sur un écran. Un site vitrine avec une description, des coordonnées et des tarifs n’a pas d’architecture à concevoir. La conversation sur ce qui passe en premier tient dans un paragraphe d’e-mail.

Quand vous refondez une seule section d’un site existant. Le contexte est déjà fixé, et croquer un bloc isolé est souvent plus lent que le montrer directement dans son apparence finale.

Et le cas limite où la réponse est « oui quand même » : quand quelqu’un dans l’entreprise a un avis tranché sur l’apparence du site. Le croquis est alors un endroit moins cher pour cette conversation qu’une maquette finie — et c’est le seul moyen que nous connaissions de l’empêcher d’avoir lieu à l’étape où chaque changement coûte trente fois plus.

Ce que ce texte ne tranche pas

À quoi ressemble tout le processus de projet. Le wireframe est l’une des étapes et nous les montrons dans l’ordre où elles surviennent.

Ce qu’il faut fixer avant le croquis. Les objectifs, l’audience et le périmètre se décident dans le brief, le wireframe ne fait que les dessiner — texte à part.

Comment concevoir un site qui convertit. La mise en page est une couche ; l’autre est le contenu. La rubrique design, y descend plus profond.

Ce que coûte un projet. Les tarifs dont découle le calcul de 1 à 30 sont les nôtres et concernent une seule ligne. Un devis complet relève de la rubrique consacrée aux coûts.

D’où viennent ces chiffres

• 85 % des problèmes d’utilisabilité avec cinq utilisateurs, et la recommandation de trois tests de cinq — Jakob Nielsen, Why You Only Need to Test with 5 Users, Nielsen Norman Group, 18 mars 2000. La courbe de la figure est calculée à partir de la formule donnée dans cette publication, avec une valeur de 31 % de problèmes détectés par un utilisateur seul.
• Le rapport de 1 à 30 entre une modification sur un croquis et la même dans le code — nos propres tarifs et notre propre calcul de travail, détaillés pas à pas dans la section sur le coût. Ce n’est pas une référence de marché et nous ne le présentons pas comme telle.
• La réalisation sur laquelle nous avons vérifié la méthode — un site de démonstration décrit dans notre portfolio, pas une mission client, et c’est ainsi qu’il est présenté dans le texte. Les trois écarts entre conception et implémentation proviennent de son propre rapport.
• Ce qui ne figure pas ici : la version précédente de ce texte présentait sept études de cas avec des résultats en pourcentage et un retour sur investissement de 2100 %. Aucune n’avait de nom de client, de données avant et après, ni d’autorisation de publication : elles ont été supprimées en totalité plutôt que corrigées.