Wireframe : douze exemples de gabarits de pages et le modèle à réutiliser

Ce que contient le document de wireframes

Le document proposé ici tient en treize pages : une page de méthode, puis douze gabarits, un par page. Chaque gabarit montre le plan de la page en blocs gris, avec trois repères numérotés posés directement sur le dessin, et, dans la colonne de droite, trois décisions à trancher avant de passer au graphisme. Ce sont ces trois questions qui font la valeur du document : le dessin seul se recopie, les questions se répondent.

Le même contenu est fourni en vectoriel, dans un fichier unique importable dans votre outil de maquettage. Chaque gabarit y est un groupe séparé, chaque bloc reste sélectionnable et modifiable. Le format natif de Figma étant propriétaire et non générable hors de l’application, c’est un fichier vectoriel standard qui est livré : il s’importe directement, reste éditable bloc par bloc, et s’ouvre aussi dans les outils concurrents. Un acheteur y gagne, un format captif ne lui apporterait rien.

Comment travailler ses wireframes, étape par étape

Commencez par compter les gabarits, pas les pages. Un site de deux mille pages produites automatiquement n’a souvent que neuf gabarits différents, et c’est ce nombre qui décide de la charge de conception, donc du prix. Listez-les à partir de votre arborescence : à chaque type de page correspond un gabarit, et deux types qui se ressemblent à 90 % n’en font qu’un.

Dessinez ensuite du gros vers le fin. La première passe pose les zones : en-tête, contenu principal, colonne latérale, pied. La deuxième place les blocs dans chaque zone et décide de leur ordre. La troisième seulement écrit les libellés réels. Descendre au libellé dès la première passe est l’erreur classique : on passe une heure sur le texte d’un bouton qui va disparaître.

Travaillez la version étroite en premier quand la moitié de votre audience est sur téléphone. Un gabarit conçu large puis comprimé produit une page mobile faite de compromis ; un gabarit conçu étroit puis élargi produit une hiérarchie qui tient dans les deux cas, parce qu’on a été obligé d’ordonner.

Écrivez les libellés réels, pas du faux texte. Un bouton nommé « Envoyer » et un bouton nommé « Recevoir le devis sous 48 h » n’occupent pas la même place et ne produisent pas le même taux de clic. Le faux texte masque exactement les problèmes que le wireframe doit révéler : un titre trop long, une colonne trop étroite, une hiérarchie qui ne tient pas.

Dessinez les états, pas seulement la page pleine. Une page a au moins quatre visages : chargée normalement, vide à la première visite, en erreur, et en attente. Les trois derniers sont ceux qu’on rencontre le plus souvent en usage réel et ceux qu’on dessine le moins. Le douzième gabarit du document leur est entièrement consacré.

Annotez au lieu d’expliquer en réunion. Un repère numéroté à côté d’un bloc, avec une phrase, survit à la réunion ; une explication orale ne survit pas à la semaine. Ces annotations deviennent d’ailleurs directement les critères d’acceptation du backlog, sans réécriture.

Arrêtez-vous au bon moment. Un wireframe qui commence à recevoir des couleurs de marque, des photos et une vraie typographie n’est plus un wireframe : c’est une maquette faite dans le mauvais outil, et les retours porteront sur le vert du bouton au lieu de porter sur l’ordre des blocs. Dès que la structure est validée, changez d’outil et de conversation.

Un exemple commenté, sur un cas fictif

L’extrait ci-dessous reprend les trois repères du gabarit 03, la page prestation, tel qu’il figure dans le document. Les gabarits ne décrivent aucune entreprise réelle.

Ce que le wireframe décide en matière d’accessibilité

Une bonne partie de l’accessibilité d’un site se joue à l’étape du wireframe, bien avant le choix des couleurs, et c’est une bonne nouvelle : ce qui se décide ici ne coûte rien, alors que les mêmes corrections après l’intégration se comptent en jours.

Le premier point est l’ordre des blocs. L’ordre dans lequel vous les empilez est celui que suivront la navigation au clavier et la lecture par une technologie d’assistance. Un menu placé après le contenu principal dans le wireframe, mais affiché au-dessus par une astuce de mise en page, produit une navigation incohérente. Décidez l’ordre logique une fois, et tenez-le.

Le deuxième est la hiérarchie des titres. Un wireframe qui montre trois niveaux de titres de tailles différentes décrit déjà une structure de document. Si deux blocs portent visuellement le même poids alors qu’ils sont à des niveaux différents, le problème est de structure, pas de graphisme, et il se corrige au crayon.

Le troisième est la taille des zones actionnables. Un bouton principal se dessine à au moins quarante-quatre pixels de hauteur sur une version étroite : c’est une contrainte de dimension, donc de wireframe. Un bouton dessiné trop petit à cette étape le restera, parce que l’agrandir plus tard casse la mise en page validée.

Le quatrième est l’emplacement des messages d’erreur. Un message affiché au champ fautif, en texte, se réserve dans le gabarit du formulaire. Un message affiché en fenêtre ou porté par la seule couleur du champ est une décision qu’on ne remet jamais en cause après coup. Le sixième gabarit du document réserve cet emplacement explicitement.

Les erreurs qui coûtent le plus cher

Un wireframe raté ne se voit pas au moment de la validation : il se voit à l’intégration, quand on découvre que la moitié des écrans réels n’a jamais été dessinée.

• Dessiner une page par URL. Vous produisez deux cents dessins dont cent quatre-vingt-dix sont identiques, et vous n’avez toujours pas décidé combien de gabarits l’agence doit fabriquer. C’est le nombre de gabarits qui se chiffre.
• Mettre du faux texte. Il masque précisément ce que le wireframe doit révéler : titres trop longs, colonnes trop étroites, hiérarchies qui ne tiennent pas. Écrivez les vrais libellés, même approximatifs.
• Y mettre des couleurs et des images. Les retours portent alors sur le graphisme et jamais sur la structure, c’est-à-dire sur la seule chose que ce document doit valider.
• Oublier les états. Écran vide à la première visite, aucun résultat, erreur technique, attente : ce sont les écrans les plus fréquents en usage réel, et ils apparaissent en cours de développement, hors périmètre, en avenant.
• Ne pas annoter. Un dessin sans note se réinterprète à chaque relecture. Trois repères écrits valent une heure de réunion, et ils deviennent ensuite des critères d’acceptation sans réécriture.

Wireframes et devis : ce que le prestataire en fait

Le nombre de gabarits est la première variable de chiffrage d’un projet web, avant le nombre de fonctionnalités. Une agence qui reçoit douze gabarits annotés chiffre une conception et une intégration précises ; une agence qui reçoit « un site d’une quinzaine de pages » chiffre une hypothèse, et l’écart entre deux hypothèses peut atteindre un rapport de deux.

Les annotations changent aussi la nature de la réponse. Un repère qui dit « le prix reste visible au-dessus de la ligne de flottaison » est une exigence testable, qui se retrouve telle quelle dans les critères d’acceptation. Un wireframe non annoté laisse chaque décision ouverte, et chaque décision ouverte se tranche plus tard, en réunion, à votre charge.

Attention à ne pas confondre ce document avec une commande de design. Les gabarits fournis ici servent à cadrer et à faire chiffrer : la conception d’interface reste le travail que vous achetez, et une bonne agence s’écartera de vos dessins en expliquant pourquoi. C’est exactement ce que vous voulez qu’elle fasse.

La suite du circuit : l’arborescence donne la liste des gabarits, le cahier des charges les intègre en section 5, et les réponses se lisent sur la grille de lecture des devis.

Les autres modèles du guide

• Arborescence de site web : le modèle à remplir et trois exemples commentés
• Backlog produit : le modèle Excel, la priorisation et un exemple rempli
• Expression de besoin : le document à rédiger avant le cahier des charges

Tous les modèles sont réunis sur le hub des ressources. Le document qui les rassemble reste le cahier des charges de site internet : c’est lui qui part aux prestataires. Les fourchettes de prix publiées et la grille de lecture des devis servent ensuite à comparer les réponses ligne à ligne.