Une maquette de site web est l’image fidèle d’une page avant son développement : sa mise en page, ses couleurs, ses typographies, ses images et ses vrais textes, sur ordinateur comme sur mobile. Elle n’est qu’une étape du webdesign d’un site internet, qui en compte cinq : le zoning et les wireframes fixent la structure ; les maquettes donnent l’apparence ; le prototype cliquable fait vivre le parcours ; le design system rassemble les règles ; la passation transmet le tout aux développeurs. Des tests utilisateurs s’intercalent entre ces étapes.

Chacune répond à une question précise et se valide séparément. C’est ce découpage qui permet de changer d’avis au moment où cela coûte encore peu. Voici à quoi sert chaque étape, ce que vous validez, et ce que vous évitez en ne la sautant pas. Ce guide s’inscrit dans notre rubrique sur l’expérience utilisateur et l’accessibilité.

Les étapes en un coup d’œil

ÉtapeLa question poséeCe que vous validez
Zoning et wireframesQuoi, où, dans quel ordre ?L’arborescence, les gabarits de pages, la hiérarchie des contenus
MaquettesÀ quoi cela ressemble-t-il ?La direction visuelle, puis chaque gabarit sur ordinateur et sur mobile
Prototype cliquableLe parcours fonctionne-t-il ?Les enchaînements d’écrans, les formulaires, les comportements
Design systemComment rester cohérent ?Les composants et leurs règles d’usage
PassationComment construire sans rien perdre ?Le périmètre définitif avant le développement

Wireframe, maquette, prototype : à quoi sert chacun ?

Ces trois mots désignent trois états d’une même page, du plus schématique au plus réaliste. Chacun sert à trancher un type de question : les garder distincts évite de discuter des couleurs quand le contenu n’est pas encore décidé.

LivrableCe qu’il montreÀ quoi il sert
Wireframe, ou maquette fonctionnelleLa structure de la page, en noir et blanc : zones, titres, textes, boutonsDécider ce qui apparaît, et dans quel ordre
Maquette, ou maquette graphiqueLa page telle qu’elle sera en ligne : couleurs, typographies, imagesValider l’apparence, sur ordinateur et sur mobile
PrototypeLes maquettes reliées entre elles, que l’on peut cliquerTester les parcours avant de les développer

Zoning et wireframes : la structure avant le style

Le zoning découpe chaque page en grandes zones : en-tête, promesse, services, preuves, appel à l’action, pied de page. Le wireframe précise ensuite chaque zone : vrais titres, longueur des textes, boutons, champs de formulaire. Les deux mots sont souvent employés l’un pour l’autre, comme le rappelle l’entrée wireframe de notre glossaire.

Le tout se dessine en noir et blanc, sans couleur ni image : on discute de ce qui doit apparaître et dans quel ordre, pas encore de goûts.

C’est aussi le bon moment pour écrire les contenus clés. Un wireframe rempli de faux texte, le fameux « lorem ipsum », promet une page qui n’existera jamais ; avec les vrais titres, on voit tout de suite ce qui déborde ou ce qui manque. Notre méthode pour rédiger des textes de site compris en cinq secondes commence justement là.

Ce que vous validez : l’arborescence du site, la liste des gabarits (accueil, service, article, contact…) et la hiérarchie des informations sur chacun. Dans l’itinéraire en cinq escales que suivent nos projets, ce travail correspond à l’escale « Contenus et parcours », qui dure en général une à trois semaines. L’arborescence elle-même s’esquisse dès le cadrage, à partir des questions de vos clients : notre méthode pour construire l’arborescence d’un site web en détaille les étapes, exemples à l’appui.

Les maquettes : l’apparence, gabarit par gabarit

Les maquettes graphiques, ou maquettes UI (pour « interface utilisateur »), appliquent l’identité visuelle à la structure validée : typographies, couleurs, images, icônes, espacements. Nous les dessinons dans Figma, en version ordinateur et en version mobile. Le mobile n’est pas une réduction du grand écran : pour beaucoup de sites, c’est l’écran le plus utilisé, et il impose ses propres choix.

Le plus efficace est de procéder en deux temps. D’abord une direction visuelle sur un ou deux gabarits clés, par exemple l’accueil et une page de service. Ensuite, une fois cette direction validée, la déclinaison des autres pages. Cela évite de redessiner dix écrans pour une couleur qui ne convient pas.

L’accessibilité se joue déjà ici, et c’est pourquoi nous appliquons le RGAA dès la maquette :

  • des contrastes suffisants, soit 4,5:1 au minimum pour un texte courant selon les WCAG ;
  • une information jamais portée par la seule couleur ;
  • des zones cliquables assez grandes, au moins 24 × 24 pixels CSS selon les WCAG 2.2, sauf exceptions ;
  • un focus clavier visible et des libellés de formulaire toujours affichés.

Le W3C en propose une synthèse dans ses conseils pour concevoir des sites accessibles. Corriger un contraste sur une maquette prend une minute ; sur un site en ligne, il faut parfois revoir toute la charte. Pour de nombreux sites marchands, ce n’est d’ailleurs plus une simple bonne pratique, comme l’explique notre article sur les obligations de l’European Accessibility Act.

Ce que vous validez : la direction visuelle, puis chaque gabarit, sur ordinateur et sur mobile. Chez nous, la validation des maquettes est un jalon du projet : elle déclenche la deuxième échéance de paiement.

Le prototype cliquable : tester le parcours avant de le coder

Le prototype relie les maquettes entre elles. On clique sur un bouton et l’on arrive sur l’écran suivant ; un menu s’ouvre, un formulaire affiche une erreur, une confirmation apparaît. Il ne contient aucun code de production : il simule le site pour qu’on puisse le parcourir comme s’il existait.

Son intérêt est de rendre les problèmes visibles avant qu’ils ne coûtent cher. Sur une maquette statique, tout paraît logique ; en cliquant, on découvre qu’il faut quatre écrans pour demander un devis, ou qu’un message d’erreur ne dit pas quoi corriger.

Pour un site vitrine, un prototype léger suffit souvent : navigation principale, une page de service, le formulaire de contact. Pour une application métier sur mesure, il devient l’outil central, celui sur lequel les futurs utilisateurs vérifient qu’ils retrouvent leurs gestes du quotidien. C’est typiquement le cas d’une application métier comme celle d’Escadre Logistique, notre étude de cas d’exemple : des écrans utilisés au quotidien, où chaque clic superflu finit par compter.

Ce que vous validez : les parcours, de la page d’entrée jusqu’à la prise de contact ou à l’achat, et le comportement des éléments interactifs.

Le design system : des règles plutôt que des pages

Un design system rassemble tout ce qui permet de construire une nouvelle page sans la redessiner :

  • des jetons (design tokens) : couleurs, typographies, espacements, arrondis ;
  • des composants : boutons, cartes, champs, menus, avec leurs états — survol, focus, erreur, désactivé ;
  • des règles d’usage : quel bouton pour quelle action, combien d’appels à l’action par écran, comment écrire un message d’erreur.

Son intérêt est économique autant qu’esthétique. Un composant conçu une fois est développé une fois et testé une fois, accessibilité comprise, puis réutilisé partout. Le jour où vous ajoutez une page ou une offre, elle se monte avec des briques existantes.

Il se dimensionne selon le projet. Pour un site vitrine, une bibliothèque de composants légère suffit. Pour une boutique en ligne ou une application, le système devient plus complet et se documente, parce que plusieurs personnes le feront vivre.

Ce que vous validez : la cohérence de l’ensemble et les règles que vos équipes suivront après la mise en ligne.

Les tests utilisateurs : regarder plutôt que demander

Un test utilisateur consiste à observer une personne réaliser une tâche — « trouvez le délai de livraison », « demandez un devis » — sur une maquette ou un prototype, sans l’aider. On ne lui demande pas si elle aime les couleurs : on regarde où elle hésite, où elle se trompe, ce qu’elle cherche sans le trouver.

Plusieurs formats existent, selon l’étape :

  • le tri de cartes, avant le zoning, pour organiser le menu selon la logique de vos clients plutôt que selon votre organigramme ;
  • le test des cinq secondes, sur une maquette, pour vérifier que la promesse de la page est comprise ;
  • le test de tâches, sur le prototype, pour valider les parcours ;
  • le test d’arborescence, pour vérifier qu’on trouve une page à partir du seul menu.

Inutile de viser une grande étude. Quelques sessions avec des personnes proches de vos clients font déjà apparaître les blocages les plus importants. Mieux vaut un test modeste à chaque étape qu’une enquête ambitieuse jamais réalisée.

La passation aux développeurs

La passation, ou handoff, transmet aux développeurs tout ce qu’une maquette ne montre pas : comportements au survol et au clic, adaptation entre mobile et grand écran, cas des contenus très longs ou absents, messages d’erreur, ordre de tabulation, textes alternatifs, rares animations prévues. Ces animations sont rares à dessein : nous ne gardons que celles qui aident le visiteur, selon la grille de décision de notre article sur les animations utiles ou nuisibles. Les jetons du design system sont repris tels quels dans le code : les couleurs et les espacements restent identiques d’un écran à l’autre.

Chez FOGG, design et développement sont assurés par la même équipe, sans sous-traitance offshore : la passation se fait de vive voix, pas par un dossier envoyé à l’autre bout du monde. Le design reste suivi pendant toute la construction, et chaque semaine, « la démo du vendredi » permet de vérifier avec vous que le site construit correspond bien aux maquettes validées. Cette organisation est détaillée sur la page consacrée au studio FOGG.

Pourquoi chaque étape fait faire des économies

Le principe est simple : plus un changement arrive tard, plus il coûte. Déplacer un bloc sur un wireframe prend quelques minutes. Le même déplacement après validation des maquettes oblige à reprendre plusieurs écrans. Après le développement, il touche aussi les gabarits, les styles, parfois le CMS et les contenus déjà saisis.

Chaque validation fige donc une décision au moment où elle est la moins chère à prendre :

  • le zoning fige la structure avant tout travail graphique ;
  • les maquettes figent l’apparence avant la première ligne de code ;
  • le prototype vérifie les parcours avant qu’ils soient développés ;
  • le design system évite de payer deux fois le même composant.

Bien valider chaque étape

Une validation n’est utile que si elle est franche. Quelques habitudes facilitent les choses :

  • désignez une seule personne qui tranche de votre côté, même si plusieurs donnent leur avis ;
  • regroupez vos retours par écrit plutôt que de les envoyer au fil de l’eau ;
  • regardez toujours la version mobile, sur votre propre téléphone si possible ;
  • jugez avec vos vrais contenus : un titre définitif change parfois toute une page ;
  • posez la question du but avant celle du goût : « cette page aide-t-elle le visiteur à agir ? ».

Zoning, maquettes, prototype et design system font partie de chacun de nos projets de site : c’est le cœur de notre offre de webdesign et de design UX/UI à Nantes. Sur un petit site, ces étapes sont simplement plus courtes. Durées et budget sont détaillés dans les tarifs d’une mission de webdesign.

Questions fréquentes

Quelle est la différence entre une maquette et un prototype ?

La maquette montre à quoi ressemble une page, de façon statique. Le prototype relie les maquettes entre elles pour simuler la navigation : on clique, un menu s’ouvre, un formulaire réagit. La maquette sert à valider l’apparence, le prototype à valider le parcours.

Combien de temps dure la phase de webdesign d’un site internet ?

Dans notre méthode, l’étape contenus et parcours, avec le zoning, prend en général une à trois semaines, puis le design, avec les maquettes, le prototype et le design system, deux à trois semaines. Une mission de webdesign seule compte en général trois à six semaines, selon le nombre de gabarits et d’allers-retours.

Un design system est-il utile pour un petit site vitrine ?

Oui, à sa mesure. Pour un site vitrine, il se limite à une palette, quelques styles de texte et une bibliothèque de composants réutilisables. Ce socle rend le site cohérent et permet d’ajouter des pages plus tard sans tout redessiner.