Design handoff : que vérifier avant l'intégration web ?

Design handoff: que vérifier avant l'intégration web?

Le curseur survole « Inspecter », et dans les dix premiers clics, l'impression est formée: soit le fichier est un document de travail clair et navigable, soit c'est un labyrinthe de calques « Rectangle 47 », de codes hexadécimaux tapés à la main et de trois versions du même composant empilées dans un coin. Nous connaissons toutes et tous le scénario qui mène à une intégration fluide, et celui qui génère ces longs fils d'e-mails où quelqu'un finit par demander: « Du coup, c'est quoi le padding exact de ce bouton? »

La bonne nouvelle, c'est que la préparation d'un fichier Figma pour le handoff n'est pas un art obscur réservé aux agences aux budgets infinis. C'est une série de choix vérifiables, dont la plupart vivent directement dans le fichier avant même qu'une seule ligne de code ne soit écrite. Nous avons condensé ces choix dans une checklist que nous utilisons nous-mêmes avant chaque livraison, parce que nous avons appris à nos dépens qu'un fichier mal préparé coûte plus que du temps: il crée une friction silencieuse dans toute l'équipe.

Un calque bien nommé, c'est la moitié du travail d'intégration déjà faite.

Architecture et nommage: poser les fondations avant l'inspection

La première chose que fait un développeur en ouvrant votre fichier Figma? Il regarde la liste des pages à gauche. S'il y lit « Page 1 », « Page 2 », « Copie de Homepage », « Version finale V2 », c'est déjà mauvais signe. Un fichier bien organisé commence par des pages au nom explicite, chacune dédiée à une section majeure du site: Accueil, Blog, Page produit, Compte, etc. Nous recommandons l'ajout d'une page supplémentaire intitulée « Design System » où vivent tous vos composants, variables et styles partagés — ainsi le développeur peut comprendre la logique d'un coup d'œil sans avoir à chasser.

Vient ensuite la question du nommage des calques. Pourquoi « Frame 12 » pose-t-il problème? Parce que lorsque le développeur inspecte l'élément, ce nom voyage directement dans la classe CSS ou le composant React. Si la base est confuse, la base de le devient aussi. C'est pourquoi nous utilisons systématiquement un nommage sémantique: « Button/Primary/Default » plutôt que « Rectangle 23 », « Hero/Headline » plutôt que « Text Layer Copy ». Cette discipline simple évite au développeur de deviner la fonction de chaque élément, et les valeurs inspectées correspondent à ce qu'il utilisera réellement.

Mais ce n'est pas tout: chaque composant majeur gagne à être documenté directement dans Figma, par une petite annotation collée à côté. À quoi sert ce composant, dans quel contexte l'utiliser, quelles sont ses variantes acceptables? Ces notes valent de l'or au moment du handoff, parce qu'elles répondent à des questions que le développeur n'osera pas toujours poser.

Maîtrise du responsive: grilles et comportements Auto Layout

Combien de fois avons-nous reçu une maquette desktop-only pour découvrir ensuite que la version mobile « arriverait plus tard »? Le problème, c'est que le responsive n'est pas une étape finale ajoutée par-dessus le design — c'est une contrainte qui doit façonner le design dès le départ. La première chose à définir, ce sont les breakpoints sur lesquels nous allons travailler: nous nous accordons généralement sur trois standards qui couvrent l'immense majorité des cas — 375 px pour le mobile, 768 px pour la tablette et 1440 px pour le desktop.

Pour chaque breakpoint, il faut spécifier le système de grille: combien de colonnes, quelle gouttière, quelle largeur maximale de contenu. Sans cette information, le développeur doit inventer une grille, et vous devinez le résultat. Sur Figma, cela signifie créer un frame dédié pour chaque breakpoint, avec sa propre configuration de grille, et s'assurer que les éléments à l'intérieur sont correctement contraints.

Voici comment nous structurons généralement ces trois grilles dans un projet type:

Là où beaucoup de fichiers pèchent, c'est dans l'usage de l'Auto Layout. L'Auto Layout, c'est ce qui permet à un conteneur de s'adapter automatiquement à son contenu — et bien configuré, c'est ce qui élimine des catégories entières de bugs. Nous vérifions systématiquement que les conteneurs de texte sont réglés sur « hug » verticalement, pour qu'un contenu dynamique (un nom de produit plus long, un commentaire plus bavard) ne casse pas la mise en page. À l'inverse, les éléments qui doivent conserver une taille fixe, comme un avatar ou une icône, doivent être contraints, pas étirés.

Auto Layout, c'est l'assurance que votre maquette survit au contenu réel — et pas seulement à vos données de démo.

Systèmes de design et variables: bannir les valeurs codées en dur

C'est probablement le point le plus important, et pourtant c'est celui que nous voyons le plus souvent être sauté: les valeurs codées en dur. Concrètement, cela signifie taper « #3A86FF » directement dans un remplissage de couleur, au lieu d'utiliser une variable Figma liée à un token « Primary/500 ». Cela signifie écrire « 16 px » dans un style de texte, au lieu d'utiliser un style partagé nommé « Body/Regular ».

Pourquoi est-ce si problématique? Parce que le jour où la couleur de marque change — et elle changera, tôt ou tard — le développeur doit remplacer manuellement chaque code hexadécimal dans le codebase. Avec un design system proprement configuré, un changement de variable met à jour l'ensemble du fichier. La même logique s'applique aux tailles de texte, aux espacements et aux effets (ombres, flous).

Alors avant chaque handoff, nous ouvrons le fichier et cherchons ces fameuses valeurs codées en dur. Quand nous en trouvons, nous les convertissons en styles et variables partagés. L'étape peut sembler fastidieuse, mais c'est la différence entre un design qui vit et évolue, et un design qui devient une pièce de musée après le premier redesign.

Un autre point souvent négligé: le contraste des couleurs. WCAG AA est le standard minimum d'accessibilité — cela signifie s'assurer que le texte courant a un ratio de contraste d'au moins 4,5:1 par rapport à son arrière-plan. Nous vérifions cela pour chaque paire texte/fond, et pas seulement pour les combinaisons principales. Un design inaccessible, ce n'est pas seulement un problème éthique — c'est un risque légal que le développeur finira tôt ou tard par gérer.

États des composants: ne rien laisser dans l'ombre

Il existe une catégorie de problèmes qui génère toujours le même échange: « Que se passe-t-il quand ce bouton est désactivé? » « Et quand il n'y a pas de données dans le tableau? » « Et quand la soumission du formulaire échoue? » Si ces questions n'ont pas de réponse dans le fichier Figma, le développeur devra choisir pour vous — et vous n'aimerez probablement pas son choix.

La règle est simple: chaque composant interactif doit voir tous ses états modélisés. Pour un bouton, ce sont les états par défaut, survol, actif, focus, désactivé et chargement. Pour un champ de formulaire, ce sont les états vide, rempli, focalisé, en erreur, validé. Pour un bloc de contenu (une carte, un élément de liste), ce sont l'état avec données, l'état vide et l'état de chargement. Nous ne laissons jamais un état « implicite » — si l'état vide n'est pas dessiné, c'est qu'il n'a pas été pensé.

Sur Figma, nous avons deux façons de gérer cela: les variants ou les propriétés booléennes. Dans la plupart des cas, les variants restent l'option la plus claire et la plus lisible — le développeur les voit comme un composant unique avec plusieurs apparences. Pour les cas plus complexes (une carte avec un CTA optionnel, un message avec ou sans icône), les propriétés booléennes permettent d'afficher ou de masquer des calques spécifiques sans dupliquer entièrement la variante. Le choix dépend de la complexité, mais la règle reste: rien ne doit être laissé à l'imagination du développeur.

Un composant sans tous ses états, c'est une conversation garantie pendant l'intégration — et pas la plus agréable.

Optimisation des assets et accessibilité: ne rien sacrifier

Le dernier point de contrôle, et pas le moindre: les assets. Les icônes et illustrations doivent être exportées en SVG, le format qui préserve la qualité à toutes les tailles et reste facilement modifiable. Les photos et images complexes passent en PNG ou JPG, mais toujours avec attention au poids du fichier — une image hero à 4 Mo détruira les performances du site, aussi belle soit-elle.

Pour les exports, nous fournissons généralement deux versions: une en 1x pour les écrans standards, une en 2x pour les écrans retina. Certains assets bénéficient aussi d'une version 3x pour les écrans à très haute densité, mais cela dépend des besoins du projet. Le panneau d'export Figma permet de générer tous ces formats en quelques clics, à condition que les calques soient correctement nommés et organisés. Ce que nous oublions trop souvent, c'est de compresser les images avant export: un PNG 24 bits pour une icône monochrome, c'est du gaspillage pur. Le format PNG-8 ou WebP fait souvent le même travail pour un poids divisé par quatre.

Vient ensuite l'accessibilité, que nous gardons en tête du début à la fin. Au-delà du contraste des couleurs déjà mentionné, cela signifie aussi s'assurer que les indicateurs de focus sont visibles sur tous les éléments interactifs, que le texte reste lisible lorsqu'on zoome à 200 %, et que les icônes utilisées comme boutons ont une alternative textuelle définie. Ces détails sont souvent invisibles dans la maquette, mais ils ont un impact direct sur la manière dont le développeur structurera le HTML.

La checklist finale avant de cliquer sur « remettre au développeur »

Avant d'envoyer le fichier, nous repassons systématiquement par cette checklist à deux. Elle n'est pas exhaustive, mais elle couvre l'essentiel de ce que nous voyons se dégrader le plus souvent:

• Pages et calques renommés de manière sémantique, avec une page « Design System » dédiée et des annotations collées sur les composants majeurs.
• Trois breakpoints configurés (375 px, 768 px, 1440 px) avec grilles définies pour chacun, et des frames dédiés par taille d'écran.
• Auto Layout utilisé systématiquement, avec les conteneurs de texte en « hug » vertical et les éléments fixes correctement contraints.
• Aucune valeur codée en dur: toutes les couleurs, tailles de texte et effets sont liés à des variables et styles partagés, vérifiables depuis la page Design System.
• Tous les états des composants modélisés: par défaut, survol, actif, focus, désactivé, erreur, vide, chargement — pour chaque élément interactif.
• Contraste des couleurs conforme à WCAG AA (ratio minimum de 4,5:1 pour le texte courant), vérifié pour chaque combinaison texte/fond utilisée.
• Assets exportés dans le bon format: SVG pour les vecteurs, PNG/JPG compressés pour les images, avec versions 1x et 2x fournies.
• Indicateurs de focus et alternatives textuelles visibles dans la maquette pour les éléments interactifs non textuels.

Avant de refermer le fichier

Préparer un fichier Figma pour le handoff, ce n'est pas une question de perfection — c'est une question de clarté. Chaque choix que nous faisons dans le fichier est un choix que nous faisons pour le développeur, et par extension, pour l'utilisateur final. Plus cette transition est fluide, plus nous avons tous du temps pour nous concentrer sur ce qui compte vraiment: créer des interfaces que les gens prennent plaisir à utiliser.

Alors avant d'envoyer votre fichier, accordez-vous une heure de plus. Ouvrez chaque page, cliquez chaque composant, inspectez chaque calque. C'est ce petit investissement à la fin qui épargne des jours d'allers-retours, et au final, un résultat bien plus cohérent. Parce qu'au fond, un bon handoff, ce n'est pas une transmission — c'est une conversation apaisée entre deux métiers qui partagent le même objectif: une interface juste, fluide, et pensée pour celles et ceux qui la parcourront.