Du Figma au composant : ce qui ne doit pas se perdre en route
Entre la maquette validée et le composant en production, des intentions de design se perdent. Cinq habitudes pour qu’elles arrivent intactes.
Une maquette validée n’est pas un produit. Entre le dernier commentaire Figma (nouvel onglet) et le composant en ligne, il y a un passage où beaucoup d’intentions se perdent : un espacement arrondi, un état oublié, une animation jugée « pas prioritaire ». Personne ne l’a décidé, c’est juste arrivé en route.
Comme je dessine et que je code, je vois les deux côtés de ce passage. Voici ce que j’essaie de garder, à chaque projet.
Nommer comme le code
Le premier écart vient souvent des mots. Dans la maquette, un bouton s’appelle « CTA bleu » ; dans le code, Button variant="primary". Deux noms, deux objets, et une traduction à chaque échange.
Je nomme désormais les composants Figma comme ils s’appelleront dans le code, propriétés comprises :
| Figma | Code | Valeurs |
|---|---|---|
| Bouton / Principal | <Button variant> | primary, secondary, ghost |
| Bouton / Taille | size | sm, md, lg |
| Bouton / État | state | default, hover, disabled, loading |
Les tokens avant les écrans
Un écran se refait, une échelle d’espacement se respecte. Avant la première page, je pose les tokens : couleurs, rayons, espacements, durées d’animation. Ils vivent dans Figma (variables) et dans le code (custom properties), avec les mêmes noms. J’en parle plus en détail dans un design system de poche.
- colonnes de grille
- 12
- pas d’espacement
- 8 px
- thèmes, clair et sombre
- 2
:root {
--space-2: 8px;
--space-4: 16px;
--radius-md: 12px;
--ease-out: cubic-bezier(0.2, 0, 0, 1);
}
Quand un écart apparaît entre la maquette et le navigateur, on compare deux valeurs nommées, plus deux impressions.
Dessiner les états oubliés
Une maquette montre presque toujours le cas idéal : la liste remplie, le texte de la bonne longueur, la connexion rapide. Le produit, lui, vit surtout dans les autres cas.
Pour chaque composant, je coche au minimum :
- l’état vide
- le chargement
- l’erreur
- le texte trop long
- le focus clavier
Un état qui n’est pas dessiné sera quand même codé, mais par quelqu’un qui devra deviner.
Antoine PineyDirecteur artistique & développeur créatifPrototyper dans le navigateur
Certaines décisions ne se prennent pas dans Figma : la vitesse d’une transition, le comportement au redimensionnement, la sensation d’un scroll. Je les tranche dans un prototype de code le plus tôt possible, puis je reporte le résultat dans la maquette, pas l’inverse.
Le raccourci ⇧ G de ce site, qui affiche la grille, vient de là : vérifier dans le vrai rendu que tout tombe sur les colonnes.
Ma checklist avant de passer en développement
- Composants nommés comme dans le code
- Tokens partagés entre Figma (nouvel onglet) et le CSS (nouvel onglet)
- Tous les états dessinés
- Transitions validées dans un prototype
L’IA dans le process, la finition à la main
J’utilise l’IA pour aller plus vite sur ce qui est répétitif : variantes d’un composant, tests, premières versions d’un texte. L’idée n’est pas de tout générer, mais d’accélérer ce qui ne demande pas de jugement. Je garde la main sur ce qui fait la différence : les proportions, le rythme, la hiérarchie, les détails d’interaction.
En résumé
- Mêmes noms dans Figma (nouvel onglet) et dans le code.
- Les tokens d’abord, les écrans ensuite.
- Tous les états, pas seulement le cas idéal.
- Les décisions de mouvement se prennent dans le navigateur.
- L’IA accélère, le jugement de design reste humain.
Rien de tout ça n’est révolutionnaire. C’est justement l’idée : ce sont de petites habitudes, tenues à chaque projet, qui évitent la perte entre la maquette et la mise en ligne.
