Du design au code

De la maquette au composant : changer d’état d’esprit

Jusqu'ici, tu produisais des pages : des rendus à montrer, à discuter, à valider. Le développeur du client, lui, n'intègre pas des pages — il intègre des composants : des briques autonomes et réutilisables (un bouton, une carte, un champ de formulaire) qu'il assemble dans son application. Le passage du design au code est d'abord ce changement d'unité de pensée : tu ne livres plus un écran, tu livres un vocabulaire de briques.

Pourquoi ça compte autant ? Parce qu'un bouton codé en composant existe en un seul exemplaire dans le code, décliné par des paramètres (sa variante, sa taille, son état). Corriger un défaut le corrige partout. À l'inverse, une page monolithique où le même bouton est copié-collé douze fois devient ingérable dès la première évolution. C'est la même logique que les design tokens, un niveau au-dessus : le système avant la page.

flowchart LR
  D["Design validé dans l'artifact"] --> T["Tokens : variables CSS"]
  T --> C["Composants : props + états + accessibilité"]
  C --> I["Intégration par le développeur"]
  I --> V["Vérification : états, clavier, contrastes"]

Anatomie d’un bon composant

Un composant bien conçu se décrit par ses props (ses paramètres d'entrée) : pour un bouton, typiquement variant (primary, secondary, ghost), size (sm, md, lg) et disabled. Cette interface n'est pas un détail technique : c'est la traduction en code des décisions de ton design system. Trois variantes de bouton dans la maquette = une prop variant à trois valeurs dans le code. Si tu te retrouves à demander une quatrième variante « juste pour cette page », c'est le signal qu'une décision de design est en train de fuir le système.

Demande toujours à l'IA le composant plus un exemple d'usage : voir <Button variant="primary" size="lg">Essayer gratuitement</Button> permet de juger immédiatement si l'interface est intuitive. Et précise le format de sortie dès le départ — HTML/CSS pur, React, avec ou sans Tailwind — car convertir après coup fait perdre du temps et introduit des écarts.

Les états interactifs : hover, focus, disabled

Voici la différence la plus visible entre un rendu de démo et un composant professionnel : les états. Un vrai bouton vit quatre vies au minimum : repos, hover (survol — feedback que l'élément est cliquable), focus (sélection au clavier — indispensable, on y revient), active (l'instant du clic) et disabled (action indisponible). Un composant sans états n'est pas fini : c'est une image qui ressemble à un bouton.

Chaque état doit être perceptible mais cohérent : au survol, on fonce légèrement la couleur (d'où le token --color-primary-hover) et on peut élever subtilement l'ombre ; à l'état disabled, on réduit l'opacité et on change le curseur. Les transitions doivent être douces — 150 à 200 ms — pour l'ambiance apaisante de Sereno. Et pense aux composants au-delà du bouton : un champ de formulaire a aussi ses états (focus, erreur, rempli), une carte cliquable a son survol.

Transforme le bouton de la landing Sereno en composant React réutilisable :
- props : variant (primary | secondary | ghost), size (sm | md | lg), disabled
- états visuels : hover (fonce vers --color-primary-hover, transition 180ms), focus-visible (anneau de 2px en --color-accent, décalé de 2px), active (légère réduction d'échelle), disabled (opacité 0.5, cursor not-allowed)
- utilise exclusivement les variables CSS du design system fourni — aucune valeur en dur
- accessibilité : élément <button> natif, focus visible au clavier, taille minimale 44px de haut en md
Donne le code complet + 3 exemples d'usage (un par variant) + la liste des tokens utilisés.

L’accessibilité dans le code : au-delà des contrastes

Au chapitre 2, l'accessibilité concernait les contrastes. Dans le code, elle prend deux dimensions supplémentaires. D'abord la navigation au clavier : une partie de tes utilisateurs n'utilise pas de souris (handicap moteur, lecteurs d'écran, ou simple préférence). Chaque élément interactif doit être atteignable au Tab et montrer clairement qu'il est sélectionné — c'est le rôle de l'état focus-visible, cet anneau autour du bouton que certains designers suppriment « parce que c'est moche ». Ne le supprime jamais : style-le pour qu'il soit beau.

Ensuite la sémantique HTML : un bouton doit être un <button>, pas un <div> stylé avec un gestionnaire de clic. L'élément natif apporte gratuitement le focus clavier, l'activation par Entrée et Espace, et l'annonce correcte aux lecteurs d'écran. Même logique pour les titres (<h1>…<h2> dans l'ordre, sans sauter de niveau), les listes et les liens. L'IA produit du HTML sémantique correct… si tu le demandes. Ajoute systématiquement « HTML sémantique et accessible » dans tes prompts de code, et demande un audit : « vérifie ce composant du point de vue accessibilité et liste les problèmes ».

Image → interface : partir d’une capture ou d’un croquis

Capacité spectaculaire et réellement utile : donner une image à l'IA — capture d'écran, maquette exportée, ou photo d'un croquis au feutre sur un coin de table — et lui demander d'en reproduire la structure en code. Les modèles actuels analysent la mise en page, identifient les composants (navigation, hero, cartes, formulaires) et produisent une interface fonctionnelle proche de l'original.

Les usages concrets en studio : digitaliser un atelier (le client a dessiné sa vision au tableau blanc — photographie et code en cinq minutes, l'effet est garanti), repartir d'une référence (« reprends la structure de cette capture, mais applique entièrement mon design system » — structure empruntée, peau personnalisée), ou reconstruire l'existant (capture de l'ancien site du client comme point de départ de la refonte).

Voici la photo du croquis fait par le client en atelier [image jointe].
Reproduis la structure de cette mise en page en HTML/CSS :
- identifie chaque zone (navigation, hero, colonnes, footer) et nomme-les en commentaires
- applique mon design system fourni ci-dessous — la structure vient du croquis, le style vient des tokens
- là où le croquis est ambigu, choisis l'interprétation la plus simple et signale-la en commentaire
[colle ici ton bloc :root]

Garder le code propre et branché aux tokens

Dernier maillon : la qualité du code livré. Trois exigences à formuler explicitement. Un : le code réutilise les tokens — toute valeur en dur est un bug de cohérence (tu peux demander un audit : « liste toutes les valeurs en dur restantes dans ce code et remplace-les par les tokens appropriés »). Deux : les commentaires expliquent les choix non évidents, pas chaque ligne — « pourquoi ce z-index » mérite un commentaire, « ceci est un bouton » non. Trois : les noms (classes, props, fichiers) suivent une convention cohérente que le développeur du client pourra prolonger.

Prends aussi l'habitude de la relecture critique : le code généré est généralement correct, mais pas toujours optimal. Des règles CSS dupliquées, un sélecteur trop spécifique, un état oublié — demande à l'IA de relire son propre code (« relis ce composant comme un développeur senior exigeant : qualité, accessibilité, cohérence avec les tokens ») avant de livrer. Un composant propre se maintient ; un composant bricolé devient vite ingérable, et c'est la réputation du studio qui est en jeu à chaque livraison.