Wireframe et maquettes

Un wireframe, c'est le plan d'une interface avant qu'elle existe : où vont les blocs, dans quel ordre, avec quelle importance. On le confond souvent avec « faire du design », alors qu'il s'agit surtout de penser avant de taper. Beaucoup de dev sautent cette étape, se jettent sur le code, et paient ensuite en allers-retours : une page qu'on reconstruit trois fois parce que le parcours n'avait pas été réfléchi, un client qui découvre le résultat trop tard, des états oubliés qu'on bricole en catastrophe. Le wireframe déplace la réflexion là où elle coûte le moins cher.

Concrètement, wireframer te fait gagner sur quatre plans. Tu clarifies l'intention produit avant la première ligne de code, en te forçant à décider ce qui est vraiment prioritaire à l'écran. Tu détectes les manques tôt : les états qu'on oublie toujours quand on code directement — écran vide, message d'erreur, chargement. Tu alignes tout le monde (toi, le client, le design) sur une base visuelle commune, bien plus parlante qu'une description écrite. Et tu peux tester plusieurs pistes en quelques minutes, sans t'attacher au pixel puisqu'il n'y en a pas encore.

La vraie raison derrière tout ça, c'est le coût du changement, qui grimpe à mesure qu'on avance. Déplacer un rectangle dans un wireframe prend trente secondes. Le même changement sur un composant déjà codé, branché à des données, testé et déployé, prend des heures — parfois une migration, des tests à réécrire, une revue de code. Plus tôt tu valides la structure, moins la modification coûte cher. Wireframer, ce n'est donc pas une étape « en plus » : c'est ce qui rend toutes les étapes suivantes moins douloureuses.

Faut-il wireframer pour tout ? Non, et savoir quand sauter l'étape fait partie du métier. Pour un mini-composant interne, un correctif mineur ou un changement trivial, va directement au code. Mais dès qu'il s'agit d'une nouvelle page, d'un parcours ou d'une fonctionnalité un peu ambitieuse, wireframe d'abord, toujours. Le réflexe à installer : avant d'ouvrir ton éditeur, demande-toi « est-ce que je sais déjà exactement à quoi ressemble cet écran et ce qu'on peut y faire ? ». Si la réponse est floue, prends un papier avant le clavier.

Ce que tu gagnes à wireframer

• Clarifier l'intention produit avant la première ligne de code
• Détecter les manques fonctionnels tôt (états vides, erreurs, chargement)
• Aligner dev, design et client sur une base visuelle commune
• Réduire drastiquement le coût du changement
• Tester rapidement plusieurs pistes sans s'attacher au pixel

Quand wireframer (et quand sauter)

Pour un mini composant interne ou un fix mineur : direct au code. Pour une nouvelle page, un parcours, une feature majeure : wireframe d'abord, toujours.

La « fidélité » d'un wireframe, c'est son degré de ressemblance avec le produit final. Vois-la comme un curseur que tu règles selon la question que tu te poses : plus tu montes en fidélité, plus tu ajoutes de détails, mais plus tu figes des choix et plus le feedback se déplace vers l'esthétique. Le piège classique du débutant est de vouloir tout de suite un rendu « joli ». On perd alors du temps à choisir des couleurs sur un écran dont le parcours n'a même pas été validé.

Le low-fidelity sert à valider la structure. Croquis papier ou Excalidraw, formes grises, aucune couleur, aucune image réelle : on répond seulement à « où vont les blocs, dans quel ordre, quelle hiérarchie ? ». Son côté volontairement moche est une force : personne n'ose s'attacher à un rectangle gris, donc les retours portent sur le fond, pas sur le vernis. En dix minutes tu produis trois variantes et tu les compares. C'est le niveau où l'on prend les décisions les plus importantes.

Le mid-fidelity précise le contenu. On passe au numérique (Figma, Penpot), avec des blocs propres, une hiérarchie nette, mais toujours sans couleurs ni typo finales. Détail qui compte : on y met de vrais textes réalistes plutôt que du Lorem ipsum, parce qu'un faux texte cache les vrais problèmes de longueur et de ton. Le high-fidelity (le mockup) précise enfin le visuel : couleurs, typographie, images, icônes, espacements définitifs. Il représente fidèlement le rendu final et sert de référence au développement.

La règle d'or tient en une phrase : valide la structure en low-fi, puis monte en fidélité. Passer en high-fi trop tôt, c'est se retrouver à débattre de la nuance d'un bouton alors que le parcours utilisateur est cassé — un débat qui masque le vrai problème et coûte cher à défaire. Chaque niveau a son moment ; les brûler dans le désordre est la source numéro un de temps perdu en conception.

Low-fidelity : valider la structure

• Croquis papier ou Excalidraw
• Formes grises, pas de couleurs, pas d'images réelles
• Focus : où vont les blocs, dans quel ordre, quelle hiérarchie
• Génère du feedback sur la structure, pas sur l'esthétique

Mid-fidelity : préciser le contenu

• Blocs numériques propres dans Figma ou Penpot
• Hiérarchie claire, mais sans couleurs ni typo finale
• Vrais textes (pas de Lorem ipsum), faux mais réalistes

High-fidelity (mockup) : préciser le visuel

• Couleurs, typo, images, icônes, espacements finaux
• Représente fidèlement le rendu final
• Sert de référence pour le développement

Wireframe, mockup, prototype : ces trois mots sont utilisés de façon interchangeable dans énormément d'équipes, et c'est une source de malentendus. Ils désignent pourtant trois livrables aux rôles bien distincts. Le wireframe répond à la question où vont les blocs — c'est un plan statique de la structure. Le mockup répond à à quoi ça ressemble — c'est le rendu visuel fidèle, avec couleurs et typo. Le prototype répond à comment ça marche — c'est une version cliquable qui simule les interactions. Savoir lequel tu es en train de produire t'évite de faire du travail de mockup quand un croquis suffisait.

Le prototype mérite qu'on s'y attarde, car c'est lui qui débloque le vrai test utilisateur. Dans Figma, tu branches les écrans entre eux : un clic sur un bouton mène à l'écran suivant, ouvre une modale, déclenche une animation. Tu obtiens un parcours navigable sans avoir écrit une ligne de code. Tu peux alors mettre ce prototype entre les mains de quelques personnes, les regarder se débrouiller, et repérer les points de friction pendant qu'ils ne coûtent encore rien à corriger. Découvrir un parcours bancal sur un prototype vaut infiniment mieux que de le découvrir en production.

Quand tu passes le relais au développement, un bon livrable ne se limite pas à « voici la maquette ». Il comprend le mockup haute fidélité, un prototype navigable pour comprendre les interactions, les specs (les tokens de couleurs, typo et espacements ; les états de chaque composant : par défaut, survol, focus, désactivé, erreur) et le comportement responsive — ce que devient chaque bloc en mobile. Ce sont précisément ces détails, souvent absents des maquettes bâclées, qui font la différence entre un développement fluide et une série d'allers-retours « au fait, il se passe quoi si… ».

• Wireframe : plan statique de la structure (où vont les blocs)
• Mockup : rendu visuel fidèle (à quoi ça ressemble)
• Prototype : version cliquable qui simule les interactions (comment ça marche)

Un prototype Figma branche les écrans entre eux pour tester un parcours réel : clic sur un bouton → écran suivant, ouverture d'une modale, animation. C'est l'outil pour tester un parcours auprès d'utilisateur·ices avant de coder.

Ce qu'on livre au dev

• Mockup haute fidélité
• Prototype navigable pour comprendre les interactions
• Specs : tokens (couleurs, typo, espacements), états (default, hover, focus, disabled, error)
• Comportements responsive (que devient chaque bloc en mobile)

La hiérarchie visuelle, c'est l'art de guider le regard : décider ce que l'utilisateur·ice voit en premier, en deuxième, en dernier. Une interface réussie se lit sans effort parce que son concepteur a fait ces choix à sa place. À l'inverse, quand tout est mis en avant, plus rien ne ressort : si tout crie, plus rien ne s'entend. Ton travail au wireframe n'est pas de tout montrer, mais de trier.

Tu disposes de quatre leviers pour créer cette hiérarchie : la taille (un titre est plus gros), le poids (un texte en gras attire l'œil), le contraste (une couleur forte ressort sur un fond neutre) et la position (le haut et la gauche se lisent en premier dans nos cultures). Le corollaire le plus important : une seule action primaire par écran. Le bouton qu'on doit cliquer en priorité est le seul à porter le style plein et coloré ; les autres deviennent secondaires (contour) ou tertiaires (lien texte). Trois boutons pleins de la même couleur, et l'utilisateur·ice ne sait plus où donner de la tête.

Sous la hiérarchie, il y a la structure invisible : la grille. En desktop, la norme est une grille de 12 colonnes, parce que 12 se divise facilement par 2, 3, 4 et 6 — tu peux donc faire des mises en page 50/50, 33/66 ou quatre colonnes égales sans jamais casser ton alignement. En mobile, on tombe le plus souvent à 4 colonnes. Ajoute des gouttières régulières entre les colonnes (16 à 24 px) et des marges latérales identiques sur toute la page : c'est ce qui donne cette impression de propreté qu'on remarque à peine mais qui change tout.

Dernier ingrédient : l'espacement, et il obéit à deux principes. Le premier, choisis une échelle et tiens-t'y (4, 8, 16, 24, 32, 48, 64) au lieu de bricoler des margin-top: 13px au hasard ; ton design respire et ton code devient cohérent, surtout avec des design tokens ou Tailwind. Le second, la loi de proximité : les éléments qui vont ensemble doivent être visuellement proches. Un label est collé à son champ, deux champs distincts sont plus espacés. L'œil comprend alors les groupes sans qu'on ait à tracer de cadres. Ça paraît évident — c'est pourtant exactement ce qui sépare une interface lisible d'une bouillie de blocs.

Hiérarchie visuelle

Quatre leviers pour guider la lecture : taille, poids, contraste, position. Un titre est gros et en haut, l'action principale est colorée et bien placée, le corps reste discret.

Une seule action primaire par écran

Le bouton qui doit être cliqué en priorité est seul à avoir le style primaire (plein, couleur forte). Les autres actions sont secondaires (outline) ou tertiaires (lien texte). Si tu as 3 boutons pleins de la même couleur, l'utilisateur·ice ne sait pas où cliquer.

Grille et gouttières

• Desktop : grille 12 colonnes, c'est la norme (divisible par 2, 3, 4, 6)
• Mobile : grille 4 colonnes
• Gouttières régulières (16 à 24 px desktop, 16 px mobile)
• Marges latérales identiques sur toute la page

Échelle d'espacement

Choisis une échelle et tiens-t'y : 4, 8, 16, 24, 32, 48, 64. Bannit les margin-top: 13px aléatoires. Ton design respire mieux, ton code est plus cohérent (Tailwind, design tokens).

La typographie porte l'essentiel du contenu d'une interface — donc l'essentiel de son expérience. Une typo cohérente se remarque à peine ; une typo anarchique, avec cinq tailles et trois polices par écran, donne une impression de brouillon même quand le reste est soigné. La bonne nouvelle : quelques règles simples suffisent à obtenir un résultat propre, sans être designer.

Limite-toi à deux familles au maximum : une pour les titres, une pour le texte courant (souvent, une seule suffit). Définis une échelle typographique claire plutôt que des tailles au hasard : par exemple 12, 14, 16, 20, 24, 32, 48 px. Règle une hauteur de ligne confortable (1.4 à 1.6 pour le corps de texte) pour ne pas tasser les lignes. Et tiens-toi à trois graisses : regular (400), medium (500 ou 600) et bold (700). Au-delà, tu ajoutes du bruit sans ajouter de sens.

Le second réflexe pro, c'est de penser en composants dès la maquette. Un bouton, un champ, une carte, une alerte, une modale : chacun est un élément nommé, réutilisable, et décliné en états (par défaut, survol, focus, désactivé, erreur). Concevoir ainsi t'évite la « dette de design » : ces interfaces où le même bouton existe en quatre variantes légèrement différentes parce que personne n'a centralisé sa définition. Un composant bien pensé se dessine une fois et se réutilise partout.

Cette façon de travailler crée un pont direct entre design et code. Une bibliothèque de composants Figma bien construite se transpose presque telle quelle en composants React, Vue ou autre : la variante et l'état côté design deviennent des props côté code. Le designer et le dev finissent par parler la même langue — « le composant Button, variante secondaire, état désactivé » désigne exactement la même chose des deux côtés. C'est ce vocabulaire commun qui fait qu'une équipe avance vite sans se répéter.

Typographie

• Maximum 2 familles : une pour les titres, une pour le texte courant
• Échelle typographique claire : 12, 14, 16, 20, 24, 32, 48 px par exemple
• Hauteur de ligne (line-height) : 1.4 à 1.6 pour le texte courant
• Poids : 400 (regular), 500 ou 600 (medium), 700 (bold). Pas plus.

Penser composants

Un bouton, un champ, une carte, une alerte, une modale : chacun est un composant nommé, déclinable en états (default, hover, focus, disabled, error).

L'erreur la plus répandue, c'est de traiter l'accessibilité comme une couche qu'on ajoutera « à la fin, si on a le temps ». En réalité, la majorité des problèmes d'accessibilité se décident au wireframe : le contraste, la taille des cibles, l'ordre de lecture, les états d'un composant. Corrigés en conception, ils ne coûtent presque rien ; découverts après coup, ils imposent de reprendre des maquettes et du code. Bonne nouvelle : trois ou quatre réflexes suffisent à éviter l'écrasante majorité des cas, et ils relèvent des référentiels WCAG et RGAA.

Premier réflexe, le contraste. Le texte courant doit atteindre un rapport d'au moins 4.5:1 avec son fond (niveau AA), le gros texte (24 px, ou 18 px en gras) se contente de 3:1, et l'objectif haut (AAA) est de 7:1. Ce n'est pas de la coquetterie : un contraste trop faible rend un texte illisible en plein soleil, sur un mauvais écran ou pour une personne malvoyante. Un plugin comme Stark dans Figma te le vérifie en temps réel, pendant que tu conçois.

Deuxième et troisième réflexes : les cibles tactiles et la navigation clavier. Toute zone cliquable sur mobile doit mesurer au moins 44 × 44 px — la surface moyenne d'un pouce ; en dessous, on rate sa cible et on s'agace. Quant au clavier, pense-le dès le wireframe : la touche Tab doit parcourir les éléments focusables dans un ordre logique (gauche-droite, haut-bas). Si ton agencement visuel ne suit pas cet ordre, il sera pénible à corriger en code — alors qu'au wireframe, il suffit de réorganiser des blocs.

Quatrième réflexe, le plus oublié : ne jamais transmettre une information par la seule couleur. Un message d'erreur en rouge, très bien — mais ajoute une icône et un texte explicite. Une personne daltonienne, ou qui consulte en niveaux de gris, ne percevra pas le rouge ; couleur + icône + libellé, et tu couvres tout le monde. Pense aussi aux états qu'on oublie : focus visible, écran vide (aucun résultat), erreur, chargement. Si tu ne les dessines pas, le dev les improvisera dans son coin — souvent mal. Les prévoir au wireframe, c'est s'assurer qu'ils existeront vraiment.

Contraste de couleur

• Texte courant : contraste minimum 4.5:1 avec le fond (WCAG AA)
• Gros texte (24 px+ ou 18 px+ bold) : 3:1 minimum
• Texte AAA : 7:1 (objectif haut)
• Plugin Figma Stark pour vérifier en temps réel

Cibles tactiles

Minimum 44x44 px pour toute zone cliquable sur mobile. C'est la taille moyenne d'un pouce. En dessous, l'utilisateur·ice rate sa cible.

Ordre de lecture et navigation clavier

Pense au parcours clavier dès le wireframe : Tab passe d'élément focusable en élément focusable, dans un ordre logique (gauche-droite, haut-bas). Si ton design ne suit pas cet ordre visuellement, ce sera difficile à réparer en code.

Ne pas transmettre par la couleur seule

Un message d'erreur en rouge ? OK, mais ajoute une icône et un texte. Les daltoniens et les personnes en mode dégradé visuel ne verront pas la couleur. Couleur + icône + texte : tu couvres tout le monde.

Bonne nouvelle pour qui débute : le marché des outils de design s'est stabilisé, et tu n'as pas besoin d'en maîtriser dix. Trois couvrent la quasi-totalité des besoins, chacun avec un terrain de prédilection. Figma est la référence du marché : gratuit en solo, collaboratif en temps réel, doté d'une profusion de plugins ; c'est le choix par défaut pour le mid et le high-fidelity. Penpot est son alternative open source, auto-hébergeable, aux fichiers ouverts — idéal si tu veux garder la maîtrise de tes données. Excalidraw, enfin, est parfait pour le low-fi : croquis rapides en réunion ou en solo, effet « papier », zéro friction.

Le choix se fait moins par goût que par usage. Tu brainstormes un parcours en quinze minutes avec un collègue ? Excalidraw. Tu construis une maquette destinée à être développée, avec des composants et un prototype cliquable ? Figma (ou Penpot). L'important est de ne pas sortir l'artillerie lourde pour un croquis, ni de croquer sur un coin de table ce qui deviendra la référence du développement. Adapte l'outil au niveau de fidélité, pas l'inverse.

Reste l'étape décisive et la plus négligée : le hand-off, c'est-à-dire le passage de relais au développement. C'est lui qui détermine si le produit fini ressemblera vraiment à la maquette. Un bon hand-off livre des composants nommés avec leurs variantes et leurs états, des interactions annotées (quel clic, quel survol, quelle transition et sa durée), la liste des points de rupture (mobile, tablette, desktop) avec le comportement responsive de chaque bloc, et les tokens (couleurs, espacements, typo) dans un format exploitable. Et surtout, le fichier de design reste la source de vérité : on le met à jour quand le code évolue, sinon il devient un mensonge que plus personne ne consulte.

Les outils

• Figma : référence du marché, gratuit en solo, collaboratif, plugins à foison
• Penpot : alternative open source, auto-hébergeable, fichiers ouverts (.penpot)
• Excalidraw : croquis rapides en réunion ou en solo, parfait pour le low-fi

Plugins Figma utiles

• Stark : contraste de couleur, simulation daltonisme
• Iconify : milliers d'icônes prêtes à l'emploi
• Content Reel : du faux contenu réaliste (noms, avatars, dates)
• Variables2CSS : exporter les variables en CSS/Tailwind

Hand-off au dev

• Composants nommés, avec leurs variantes et leurs états
• Annoter les interactions (clic, hover, transitions, durée)
• Lister les breakpoints (mobile, tablette, desktop) et le comportement responsive
• Fournir les tokens (couleurs, espacements, typo) dans un format exploitable
• Garder le fichier Figma comme source de vérité, le mettre à jour quand le code évolue