Maquette webdesign : les étapes de la conception

Maquette webdesign: les étapes de la conception

La première fois qu'un client m'a tendu un dossier épais de captures d'écran Pinterest en me disant « je veux exactement cette ambiance-là, mais pour mon studio de yoga », j'ai fait ce que beaucoup de designers font au début de leur pratique: j'ai ouvert Figma, j'ai posé une palette de verts tendres, j'ai cherché la bonne typographie manuscrite et j'ai commencé à composer une page d'accueil magnifique. Trois jours plus tard, en relisant mes propres écrans, je me suis rendu compte que la rubrique « cours du week-end » était coincée entre deux blocs décoratifs, que le bouton de réservation se perdait dans un coin et qu'aucun de mes choix n'avait été pensé pour quelqu'un qui chercherait, simplement, à s'inscrire à un cours. La maquette était belle. Elle ne fonctionnait pas.

C'est cette expérience — et toutes celles qui ont suivi — qui m'a appris qu'une maquette web ne commence jamais par la couleur. Elle commence par une architecture invisible, posée avec méthode, et qui décidera ensuite de tout le reste: la lisibilité, l'ergonomie, l'accessibilité et même, paradoxe, la place laissée à la beauté. Les étapes de création d'une maquette webdesign ne sont donc pas une succession de livrables décoratifs. Elles forment un processus de décision, du premier schéma jusqu'au prototype interactif.

Je vais vous guider à travers les grandes étapes que je pratique systématiquement en studio — du zoning au prototype — en vous expliquant le rôle de chacune. Une maquette n'est jamais un exercice de style: c'est un outil au service de vos visiteurs.

Zoning et wireframe: structurer l'architecture fonctionnelle sans artifice

Avant qu'un seul pixel ne prenne sa couleur définitive, je travaille toujours sur deux artefacts en apparence très austères: le zoning, puis le wireframe. Ces deux documents n'ont qu'un seul objectif: organiser l'information pour que l'œil sache où aller, sans avoir à réfléchir. C'est un acte d'accueil, en réalité. Vous accueillez un visiteur pressé, fatigué, souvent sur un téléphone dans le métro, et vous lui devez de lui rendre la lecture facile.

À ce stade, rien n'est encore « design » au sens où on l'entend communément, et c'est précisément ce qui fait la force de la démarche. En retirant les couleurs, les images séduisantes et les effets de profondeur, on empêche les détails visuels de masquer les problèmes de fond.

Le zoning, première lecture de la page

Le zoning est le plus primitif des deux: c'est un découpage en grands rectangles sur une page blanche, où chaque bloc indique un type de contenu — logo, menu, titre, image principale, appel à l'action, pied de page — sans aucun style. On y voit l'emplacement, la taille relative et la hiérarchie. C'est un plan d'architecte avant les fondations.

Sa vertu principale est de forcer une conversation de fond avec le client sur la structure du message, pas sur les couleurs. Quand un client me dit « je veux une vidéo plein écran dès l'arrivée sur le site », je peux lui demander, en regardant simplement le zoning: où voulez-vous que vos visiteurs trouvent l'information sur vos tarifs? Et le bouton de réservation? Et les horaires?

Le zoning sert aussi à repérer les déséquilibres très tôt. Une page d'accueil peut sembler riche dans un document de cadrage et devenir étouffante dès que l'on représente ses blocs. À l'inverse, un site qui paraît manquer de contenu peut révéler une structure claire, avec quelques sections bien hiérarchisées. On ne cherche pas encore la bonne composition: on vérifie que la page a une raison d'être et que chaque bloc contribue à cette raison.

Le wireframe, du volume vers l'usage

Le wireframe descend d'un niveau. Il transforme chaque bloc du zoning en une représentation plus précise, avec des emplacements pour les titres, les paragraphes, les boutons, les images et les icônes. On reste en noir, blanc et gris: la mise en forme visuelle n'est pas encore notre sujet.

C'est sur ce schéma que l'on commence à valider l'ergonomie. La navigation est-elle intuitive? Les actions principales sont-elles visibles sans devoir parcourir toute la page? Le pied de page contient-il les informations que les gens cherchent vraiment? Une page de service explique-t-elle clairement ce qui est proposé avant de demander un contact? Le wireframe ne répond pas seulement à la question « où placer ce bloc? », mais aussi à « dans quel ordre le visiteur doit-il comprendre les choses? ».

Cette étape permet également de travailler le rythme de la page: sa respiration, son équilibre entre zones denses et zones de pause, la progression entre une promesse, une explication et une action. Une page n'est pas une collection de rectangles empilés. C'est un parcours de lecture. Même très simplifié, le wireframe doit déjà rendre ce parcours perceptible.

Le wireframe est moins sexy qu'une jolie maquette, mais c'est lui qui décide si votre site sera trouvé, compris et utilisé.

Cette phase a un bénéfice très concret: elle rassure le client. Voir un zoning propre et un wireframe structuré lui donne immédiatement le sentiment que le projet est entre des mains sérieuses, bien avant qu'il ne voie quoi que ce soit de joli. Et pour le designer, c'est une garantie: on ne risque pas de découvrir, après trois jours de composition graphique, que le client voulait six rubriques principales quand on n'en avait prévu que quatre.

Pour distinguer clairement les deux artefacts dans votre pratique, voici les décisions qu'ils doivent permettre de trancher:

Ce tableau n'est pas une liste à imprimer. C'est une grille de lecture pour vérifier, à chaque étape, si vous avez bien pris les décisions qu'il fallait prendre à ce moment-là. Si vous vous retrouvez à discuter de la couleur d'un bouton dans le zoning, vous avez sauté une marche. Il faudra revenir en arrière, même si cela donne temporairement l'impression de ralentir le projet.

Le mockup: donner vie à l'identité visuelle sur une base validée

Une fois le wireframe validé — et seulement une fois validé —, l'identité visuelle entre en scène. C'est l'étape du mockup, que l'on appelle aussi maquette graphique: on applique la charte graphique — couleurs, typographies, iconographie, style photographique, traitement des espaces — sur la structure fonctionnelle déjà approuvée. On ne change plus l'architecture, on l'habite.

Cette distinction est essentielle. Si le mockup sert encore à déplacer les sections, à inventer de nouvelles fonctionnalités ou à corriger la navigation, il devient difficile de savoir ce que l'on est réellement en train de valider. Le travail graphique doit pouvoir s'appuyer sur une base stable. Cela ne signifie pas qu'aucune modification ne sera jamais nécessaire, mais que chaque changement doit répondre à un problème identifié, et non à une envie apparue au détour d'une composition.

C'est à ce stade que ma pratique devient presque physique. Je pense à la maquette comme à un intérieur que l'on aménage: la structure est la maison, et maintenant, on choisit les matériaux, la lumière et les textiles. La texture d'une typographie avec empattements peut donner une impression de profondeur et de tradition; une sans-serif géométrique, au contraire, appuiera la sensation de modernité et de respiration. Une palette de couleurs saturées crée une tension visuelle excitante, tandis qu'une palette désaturée invite à ralentir.

Ces choix ne sont pas purement esthétiques. Ils traduisent le positionnement de la marque. Une clinique, un cabinet d'avocat, une maison d'édition ou une marque de vêtements ne peuvent pas raconter la même histoire avec les mêmes contrastes, les mêmes images et la même densité visuelle. Le rôle du designer est de transformer des intentions parfois abstraites — sérieux, proximité, précision, audace, simplicité — en décisions visibles et cohérentes.

Construire une hiérarchie plutôt qu'une collection d'effets

Je travaille souvent en deux ou trois itérations sur cette phase. La première pose les grandes masses: couleur dominante, choix typographiques principaux, ton photographique et traitement des éléments de marque. La deuxième équilibre les contrastes, vérifie que la hiérarchie typographique reste lisible sur tous les écrans et harmonise les espaces de respiration entre les blocs. Une troisième itération sert parfois simplement à chasser les incohérences: un bouton trop appuyé, un titre mangé par une image, un pied de page qui n'a pas le même ton visuel que l'en-tête.

Trois points méritent une attention particulière, parce qu'ils reviennent dans presque tous mes projets et qu'ils font, à eux seuls, la différence entre une maquette qui plaît et une maquette qui fonctionne.

D'abord, le choix typographique ne se fait pas en solo. Une typographie principale pour les titres et une seconde, complémentaire, pour le corps de texte constituent souvent un équilibre suffisant. Trop de fontes sur un même écran créent un bruit visuel qui fatigue la lecture et disperse l'attention, comme une pièce où l'on aurait mélangé sept ambiances musicales différentes. Il faut également observer les caractères accentués, les chiffres, les graisses disponibles et la lisibilité des petits corps. Une fonte qui paraît superbe dans un titre de présentation peut devenir pénible dans un formulaire ou une longue page de contenu.

Ensuite, la palette de couleurs doit servir la hiérarchie. Une couleur d'accent unique, utilisée pour les boutons et les liens importants, vaut mieux qu'un arc-en-ciel où plus rien ne se distingue. Le visiteur doit savoir, en un instant, où il peut agir. Cela suppose que tout le reste s'efface discrètement derrière l'action principale.

Enfin, le rythme vertical — l'espace entre les sections, entre les paragraphes et entre les lignes — est aussi important que les contenus eux-mêmes. C'est lui qui donne à la page sa respiration et qui décide si le visiteur s'arrête ou s'il fait défiler l'écran sans même s'en rendre compte. Un espace vide n'est pas nécessairement un espace perdu. Il peut isoler une information, donner du poids à une promesse ou éviter qu'un appel à l'action ne soit noyé dans la page.

La maquette doit aussi être pensée dans plusieurs dimensions. Une version desktop très réussie ne garantit pas une expérience mobile correcte. Il faut observer ce qui arrive aux titres trop longs, aux images horizontales, aux tableaux, aux menus et aux boutons lorsque la largeur diminue. Le responsive ne consiste pas à réduire mécaniquement tout ce qui existe sur grand écran. Il oblige parfois à modifier l'ordre des informations, à simplifier une navigation ou à transformer une rangée de cartes en liste verticale.

Prototypage interactif: simuler l'expérience utilisateur avant le code

Le mockup est une belle image. Le prototype, lui, est une promesse d'expérience. Dans Figma, je relie les écrans entre eux par des zones cliquables, j'ajoute des transitions, j'anticipe les états — bouton survolé, formulaire en erreur, menu ouvert sur mobile — et je simule des parcours utilisateurs entiers. Le prototype transforme une série d'images en quelque chose qui se vit, et c'est précisément ce changement de statut qui le rend si précieux.

Une maquette statique peut donner l'impression qu'un parcours est évident parce que l'on connaît déjà la logique du projet. Le prototype oblige à effectuer les actions dans leur ordre réel. Où clique-t-on pour prendre rendez-vous? Que se passe-t-il après l'envoi du formulaire? Comment revient-on à la page précédente? Le menu se referme-t-il correctement? Une animation attire-t-elle l'attention vers le bon endroit ou ralentit-elle simplement la navigation?

Cette étape a profondément transformé ma relation avec mes clients. Au lieu de décrire ce que fera le site, je peux leur mettre un prototype entre les mains — sur leur téléphone, le plus souvent — et leur dire: « Essayez de réserver un cours, comme si vous étiez un nouveau visiteur. » Ce qui se passe dans les cinq minutes suivantes est presque toujours éclairant. Soit le parcours fonctionne et tout le monde se détend; soit un blocage apparaît, et on le découvre pendant la conception, plutôt qu'après plusieurs semaines de développement.

Les états qui manquent toujours dans une première maquette

Un prototype convaincant ne se limite pas au parcours idéal. Il doit aussi prévoir les moments où l'utilisateur hésite, se trompe ou attend. Un formulaire ne comporte pas uniquement un état vide et un état envoyé. Il peut être incomplet, contenir une adresse électronique invalide, afficher un message de confirmation ou rencontrer un problème technique. Un menu ne se résume pas à son apparence fermée. Sur mobile, il faut montrer son ouverture, sa fermeture, son niveau de navigation et la manière dont il laisse l'utilisateur revenir en arrière.

Concrètement, un prototype interactif permet de tester plusieurs points essentiels avant l'écriture de la première ligne de code:

1. La clarté des parcours principaux: un visiteur trouve-t-il ce qu'il cherche sans revenir plusieurs fois en arrière?

2. La lisibilité des états d'erreur: un message d'alerte est-il perçu sans ambiguïté et placé au bon endroit?

3. L'ergonomie mobile: la navigation au pouce est-elle fluide, les cibles tactiles sont-elles suffisamment larges et espacées?

4. La cohérence des transitions: les changements d'écran conservent-ils le ton visuel de la marque sans produire d'effets gratuits?

5. L'anticipation des micro-interactions: que fait un menu qui s'ouvre, un bouton qui se remplit ou une image qui se charge progressivement?

6. La compréhension des retours système: l'utilisateur sait-il qu'une action a bien été prise en compte, qu'une page charge ou qu'un champ doit être corrigé?

Le prototype n'est pas une option réservée aux grands projets. Pour un site de cinq pages, il est déjà utile, parce qu'il économise des allers-retours avec le développeur et force l'équipe à se mettre d'accord sur le comportement attendu. Pour un site marchand, un outil en ligne ou toute interface où le parcours de conversion compte, il devient particulièrement important: on ne peut pas tester un achat, une inscription ou une demande de devis sur une image figée.

Il faut néanmoins garder une juste mesure. Tout n'a pas besoin d'être animé. Une transition complexe qui n'apporte aucune information peut détourner l'attention et alourdir la phase de conception. Je prototype en priorité les parcours qui portent une décision, une compréhension ou un risque: navigation, formulaire, recherche, paiement, prise de rendez-vous, création de compte. Le reste peut être précisé dans les échanges avec l'équipe de développement.

L'accessibilité numérique comme pilier dès la conception graphique

J'ai longtemps traité l'accessibilité comme un sujet technique que je confiais au développeur en fin de projet. J'avais tort, et cette erreur m'a coûté plusieurs refontes. Aujourd'hui, j'intègre les normes WCAG 2.2 et leur équivalent français RGAA 4.1 dès la phase de wireframe, parce que les décisions qui déterminent l'accessibilité d'un site — taille des textes, contrastes, largeur des cibles tactiles, hiérarchie des titres — se prennent dans les premières grilles, pas dans les dernières lignes de code.

Le raisonnement qui me guide est simple: si je conçois ma maquette pour une personne qui a une vision réduite, qui navigue au pouce dans le métro ou qui consulte le site sur un vieux téléphone en plein soleil, je conçois une maquette qui sera meilleure pour tout le monde. Les contraintes d'accessibilité peuvent améliorer la lisibilité et l'utilisabilité générales. Un contraste plus net aide une personne malvoyante, mais aussi quelqu'un qui consulte son écran dehors. Un texte mieux structuré facilite la navigation avec une technologie d'assistance, mais aussi la lecture rapide d'un visiteur pressé. Des cibles tactiles suffisamment grandes réduisent les erreurs de toute personne qui utilise son téléphone en mouvement.

Il n'est pas nécessaire d'attendre la fin du projet pour prendre ces décisions. Dès le wireframe, on peut prévoir une hiérarchie de titres cohérente, réserver une place aux messages d'erreur, éviter de transmettre une information uniquement par la couleur et vérifier que les actions principales restent identifiables. Au moment du mockup, on affine les contrastes, les tailles, les espacements et la visibilité des états de focus. Le développeur aura encore un rôle essentiel, notamment pour la structure du code et la navigation au clavier, mais il ne devrait pas avoir à réparer une architecture visuelle pensée sans ces contraintes.

Ce tableau ne couvre pas tous les critères des WCAG, mais il rassemble des décisions que l'on peut prendre directement dans une maquette. Il faut aussi penser aux utilisateurs qui désactivent les animations, à la lisibilité des liens dans les paragraphes, à la présence d'un focus visible et à la manière dont les informations sont regroupées. Une interface accessible n'est pas seulement une interface avec de bons contrastes. C'est une interface qui reste compréhensible lorsque l'utilisateur ne voit pas, ne touche pas ou ne lit pas la page de la manière imaginée au départ.

Concevoir accessible, ce n'est pas cocher une norme. C'est décider que votre site parle aussi à la personne qui ne vous ressemble pas.

Un détail que je glisse systématiquement à mes clients pour qu'ils comprennent l'enjeu: les situations de handicap ne sont pas les seules à prendre en compte. Un bras dans le plâtre, un environnement bruyant qui empêche d'écouter un tutoriel vidéo, une connexion mobile limitée qui rend les images inutiles ou une lumière de plein soleil qui efface les contrastes faibles modifient aussi la façon dont on utilise un site.

Une maquette accessible est donc rarement une maquette appauvrie. Elle est souvent plus claire, plus stable et plus directe. Elle laisse moins de place aux ambiguïtés et davantage aux choix qui aident réellement le visiteur à comprendre quoi faire.

Optimiser les coûts: pourquoi corriger dans Figma plutôt qu'en développement

Le dernier point que je veux partager avec vous est peut-être le plus concret — et le plus mal compris par les clients qui voient la phase de maquettage comme un coût plutôt que comme un investissement. Corriger un défaut d'ergonomie, un problème de contraste ou un parcours cassé directement dans Figma pendant la conception coûte en moyenne bien moins cher que de le corriger après le développement et la mise en production du site. Le principe est simple: plus une décision est modifiée tard, plus elle dépend d'autres décisions déjà prises.

Une retouche dans une maquette Figma, c'est parfois quelques minutes: déplacer un bouton, ajuster une couleur, réorganiser deux blocs, agrandir une cible tactile. La même correction, une fois le site développé, suppose de rouvrir le code, de tester la modification sur plusieurs navigateurs et supports, de vérifier qu'elle ne casse pas la mise en page ailleurs et de redéployer le site. Plusieurs heures, parfois plusieurs jours, si la correction touche à l'architecture du modèle ou à un composant réutilisé sur des dizaines de pages.

Le coût ne vient pas uniquement du temps du développeur. Une modification tardive peut demander une nouvelle validation du client, un ajustement des contenus, une reprise des tests, une mise à jour de la documentation ou une intervention sur des éléments qui n'étaient pas prévus dans le périmètre initial. C'est ainsi qu'un petit bouton déplacé peut devenir une discussion de projet entière.

Pour transformer ce constat en gestes concrets, voici les moments où une correction dans la maquette épargne un coût réel:

1. Lors de la revue du wireframe: déplacer un bloc, renommer une rubrique ou ajouter une section reste relativement simple, car aucune direction artistique n'est encore figée.

2. Lors de la revue du mockup: ajuster une couleur, changer une typographie ou rééquilibrer un espacement demande une itération ciblée, sans toucher au fonctionnement général.

3. Lors du test du prototype: vérifier qu'un parcours est compréhensible permet de corriger l'enchaînement des écrans avant que celui-ci ne soit traduit en composants et en code.

4. Lors de la vérification de l'accessibilité: corriger un contraste, agrandir une cible tactile ou renforcer la hiérarchie des titres évite de devoir reprendre plusieurs modèles une fois le développement lancé.

5. Lors de la préparation de la transmission: préciser les états, les comportements et les variantes réduit les interprétations différentes entre le designer et le développeur.

Le moment où la correction devient réellement coûteuse, c'est après la validation du développement, quand le site est déjà construit autour de choix qui n'ont pas été suffisamment testés. C'est souvent à ce moment que le client découvre les vrais problèmes, parce qu'il n'avait pas pu expérimenter une image figée. Le prototype interactif déplace ce moment de vérité vers la phase de conception, là où les changements sont encore réversibles.

Une bonne maquette prépare aussi le travail de développement

La maquette ne s'arrête pas au dernier écran présenté au client. Elle doit pouvoir être comprise par la personne qui va la transformer en interface réelle. Cela implique de nommer correctement les composants, de regrouper les variantes, de préciser les comportements importants et de distinguer ce qui relève d'une intention visuelle de ce qui constitue une règle fonctionnelle.

Je veille notamment à ce que les éléments récurrents soient cohérents: boutons, champs, cartes, titres, messages d'erreur, liens, menus et pieds de page. Si un même composant change d'apparence à chaque écran, la conception devient difficile à maintenir et le risque d'incohérence augmente au fil du développement. Le travail de design ne consiste pas à produire le plus grand nombre d'écrans possible, mais à établir un système capable de les faire tenir ensemble.

Cette préparation est également utile lorsque le contenu réel n'est pas encore finalisé. Un titre beaucoup plus long que le texte de présentation peut modifier la hauteur d'un bloc, repousser un bouton ou casser l'équilibre d'une image. Je préfère tester ces variations dans la maquette plutôt que de remplir chaque écran avec du texte idéal, parfaitement calibré pour la composition. Le contenu n'est pas un décor que l'on remplace à la dernière minute: il participe à la forme.

Du wireframe au prototype: une conception qui avance par preuves

Les étapes de création d'une maquette webdesign suivent une logique assez simple: d'abord décider ce qui doit être présent et dans quel ordre, ensuite donner une forme à cette structure, puis vérifier comment elle se comporte lorsqu'on la parcourt. Le zoning clarifie l'architecture. Le wireframe vérifie la hiérarchie et les parcours. Le mockup traduit l'identité visuelle. Le prototype confronte les choix à l'usage. L'accessibilité accompagne toutes ces phases, au lieu d'être ajoutée après coup.

Ce processus design UX/UI n'a rien de spectaculaire dans ses premières heures. Il produit parfois des écrans gris, des blocs provisoires et des questions qui semblent moins séduisantes qu'un choix de couleur. Mais ces questions évitent les décisions prises à l'aveugle. Elles permettent aussi au client de participer au bon moment: parler du contenu et de la navigation avant de discuter des détails visuels, puis tester une expérience plutôt que donner son avis sur une image.

Une maquette web interactive n'est pas seulement une présentation plus impressionnante. C'est un moyen de rendre les hypothèses visibles. Tant qu'un parcours reste décrit dans une réunion, chacun peut lui donner un sens différent. Dès qu'il faut cliquer, revenir en arrière, remplir un champ ou trouver une information, les désaccords deviennent concrets et donc corrigeables.

C'est là, pour moi, que se situe la vraie valeur d'une maquette. Elle ne promet pas que le site sera parfait avant même sa mise en ligne. Elle donne à l'équipe un espace où les erreurs coûtent encore peu, où les choix peuvent être comparés et où l'on peut défendre l'esthétique sans sacrifier l'usage. Une belle interface attire l'œil. Une interface bien conçue sait ensuite quoi lui faire faire.