Avant d’écrire la moindre ligne de CSS, chaque projet web sérieux passe par une étape que beaucoup bâclent : la maquette. Pas un beau visuel léché, pas un prototype cliquable — juste une représentation fidèle de l’architecture de la page, des blocs, des zones de contenu. C’est là que se jouent 80 % des décisions structurelles du site.
Une maquette de site (ou wireframe dans le jargon) sert à aligner l’équipe, valider la logique de navigation et éviter les aller-retours coûteux en phase de développement. Voici comment l’aborder avec méthode, que vous soyez freelance, chef de projet ou client qui veut comprendre ce que l’agence lui montre.
Ce qu’est vraiment une maquette de site
Wireframe, maquette, prototype : les trois niveaux
On confond souvent ces trois termes, alors qu’ils représentent des étapes bien distinctes du projet.
- Le wireframe (ou zoning) : un schéma en niveaux de gris, sans couleurs ni images. Il pose la structure — où va le menu, la zone hero, les blocs de contenu, le footer.
- La maquette graphique : le wireframe habillé. On y ajoute les couleurs, la typographie, les visuels. C’est ce que voit le client avant que l’intégrateur touche au code.
- Le prototype : une version cliquable qui simule la navigation réelle. Figma et Adobe XD permettent d’en créer sans développeur.
Dans l’usage courant, quand un client demande « la maquette du site », il veut généralement la version graphique. Mais le wireframe est la base — sans lui, la maquette graphique repose sur du sable.
La différence entre maquette et architecture de l’information
L’architecture de l’information, c’est le squelette conceptuel du site : les pages, leur hiérarchie, les liens entre elles. La maquette, elle, traduit cette architecture page par page. Les deux sont liées mais pas identiques. On définit d’abord l’arborescence (accueil → services → contact), puis on maquette chaque gabarit de page.
💡 Notre conseil
Avant de démarrer Figma ou Sketch, posez l’arborescence sur papier. Même un schéma manuscrit à la va-vite permet d’identifier les pages orphelines ou les menus surchargés — bien plus rapidement qu’en maquettant directement.
🎯 Choisir le bon outil selon votre contexte
Les outils pour wireframer
Figma domine le marché depuis 2021, et pour de bonnes raisons : collaboration en temps réel, composants réutilisables, export propre. Mais il n’est pas toujours le bon choix.
| 🖥️ Outil | 📌 Cas d’usage idéal |
|---|---|
| Figma | Projets d’équipe, itérations fréquentes, handoff développeur |
| Balsamiq | Wireframes rapides, style volontairement « brouillon » pour ne pas bloquer sur l’esthétique |
| Whimsical | Freelances solos, petits projets, diagrammes + wireframes combinés |
| Papier + stylo | Premiers ateliers clients, idéation rapide, pas de barrière technique |
Maquette mobile first ou desktop first ?
La question divise encore les équipes. Mobile first signifie maquetter d’abord la version smartphone, puis élargir vers le desktop. C’est la logique recommandée depuis que Google indexe prioritairement le mobile — mais c’est souvent inconfortable pour un client qui valide sur son écran 24 pouces. En pratique : maquettez mobile first, présentez desktop first au client. Ça marche.
✅ À retenir
Une maquette mobile first réduit les adaptations responsive de 30 à 40 % en phase de développement. Commencer par la contrainte — l’écran le plus petit — force à prioriser le contenu réellement utile.
Construire sa maquette de site pas à pas
Étape 1 : définir les gabarits à maquetter
Inutile de maquetter toutes les pages — seulement les gabarits uniques. Un site e-commerce de 500 produits ne nécessite pas 500 maquettes : juste la page accueil, la page liste produits, la fiche produit, le panier, la page de paiement et la page contenu statique. Six gabarits couvrent souvent 95 % du site.
Étape 2 : poser la grille et la hiérarchie visuelle
Chaque maquette commence par une grille. Sur desktop, une grille en 12 colonnes est standard. Définissez ensuite la hiérarchie visuelle : le titre principal (H1) doit attirer l’œil en premier, l’appel à l’action en second, le contenu ensuite. Cette hiérarchie doit être visible même en niveaux de gris — si elle dépend uniquement des couleurs pour fonctionner, c’est un problème.
Délimitez les grandes zones : header, hero, contenu principal, sidebar éventuelle, footer. Pas de détail à ce stade.
Menu de navigation, formulaires, boutons d’action, champs de recherche. Ce sont eux qui dictent l’expérience utilisateur.
Sur quoi clique-t-on ? Qu’est-ce qui s’ouvre en overlay ? Quels éléments changent selon l’état de connexion ? Les annotations évitent les malentendus en dev.
Étape 3 : valider avant de passer au graphisme
La maquette wireframe doit être validée par le client ou les parties prenantes avant d’y ajouter la moindre couleur. Pourquoi ? Parce qu’une fois le graphisme en place, les retours portent sur les couleurs et les images plutôt que sur la structure. Or c’est la structure qui coûte cher à retravailler en développement.
⚠️ À garder en tête
Un client qui valide une maquette graphique sans avoir vu le wireframe peut demander de déplacer un bloc majeur après intégration. Ce type de retard coûte en moyenne 3 à 6 heures de développement supplémentaires — et c’est toujours le prestataire qui absorbe la note.
Les erreurs qui sabotent une maquette
Trop de fidélité trop tôt
Certains designers livrent des wireframes avec des vrais textes, de vraies photos, des dégradés. Résultat : le client valide le contenu plutôt que la structure. Les fameux Lorem ipsum existent pour une raison — ils indiquent clairement « ce n’est pas le vrai texte, concentrez-vous sur la mise en page ».
Ignorer les états d’interface
Une maquette montre souvent un état « idéal » : formulaire vide, panier plein, utilisateur connecté. Mais qu’affiche la page quand le panier est vide ? Quand une recherche ne renvoie aucun résultat ? Ces états vides (empty states) sont rarement maquettés et toujours problématiques en développement.
| ✅ Bonnes pratiques | ❌ Pièges fréquents |
|---|---|
| • Valider le wireframe avant le graphisme • Maquetter les états vides et d’erreur • Annoter les interactions • Utiliser de vrais libellés de boutons |
• Sauter le wireframe pour gagner du temps • Travailler uniquement en desktop • Ne maquetter que l’état idéal • Livrer sans annotations |
Ne pas penser au référencement dès la maquette
Le SEO commence à la maquette, pas après. L’emplacement du H1, la présence d’une zone de contenu textuel au-dessus de la ligne de flottaison, la structure des URLs reflétée dans le menu — tout ça se décide en phase de maquettage. Relier la structure visuelle à la stratégie de contenu dès le départ, c’est exactement ce qu’explique notre article sur l’architecture de site web.
« La maquette est le seul moment du projet où tout le monde parle de la même chose au même endroit. Après, chacun travaille dans son coin. »
— Retour d’expérience courant en agences web
❓ Questions fréquentes sur la maquette de site
Combien de temps faut-il pour maquetter un site ?
Pour un site vitrine de 5 à 8 pages, comptez 1 à 3 jours pour le wireframe et 2 à 5 jours pour la maquette graphique complète. Un site e-commerce avec une dizaine de gabarits différents peut prendre 2 à 3 semaines de maquettage. Ces délais doublent si les validations clients sont lentes.
Peut-on maquetter soi-même sans être designer ?
Oui, pour un wireframe. Des outils comme Whimsical ou Balsamiq sont accessibles sans formation design. La maquette graphique, elle, demande une vraie culture visuelle — couleurs, typographie, cohérence — et se délègue généralement à un UI designer.
Faut-il une maquette pour un site construit sous WordPress ou Webflow ?
Absolument. Même avec un constructeur de page, sans maquette préalable, on finit par assembler des blocs au hasard et refaire trois fois la même section. Le temps gagné sur la maquette se perd toujours ailleurs. Avec Webflow notamment, définir les composants et la grille en amont évite de créer des styles en double à chaque nouvelle page.
Quelle est la différence entre une maquette et une charte graphique ?
La charte graphique définit les règles visuelles de la marque : palette couleurs, polices autorisées, logo et ses variantes, ton iconographique. La maquette applique ces règles à des pages concrètes. L’une sans l’autre est problématique : une charte sans maquette reste abstraite, une maquette sans charte donne des résultats incohérents d’une page à l’autre.