« C’est dans le Figma » n’est pas un handoff. Un fichier avec des calques non nommés, des composants détachés, des espacements incohérents et zéro annotation : le développeur va passer une heure à fouiller ce qu’il aurait pu lire en cinq minutes si le fichier avait été préparé.
Le handoff est l’étape qui transforme un design en code. Quand il est mal géré, il génère des questions constantes, des implémentations approximatives et des révisions en fin de sprint. Quand il est bien géré, le développeur travaille de façon autonome et le résultat ressemble à la maquette.
Le handoff n’est pas un moment
L’erreur classique : considérer le handoff comme un événement ponctuel. Le designer « livre » les maquettes, le développeur « prend le relais ». En pratique, les questions commencent dès que le développeur ouvre le fichier, et elles ne s’arrêtent pas jusqu’à la mise en production.
Les équipes qui fonctionnent bien traitent le handoff comme un processus continu : le designer et le développeur partagent le même espace de travail depuis le début, les décisions sont documentées au fil de la conception, et les statuts de préparation indiquent en temps réel ce qui est prêt à être développé.
Le meilleur handoff est celui où le développeur n’a pas besoin de poser de questions parce que toutes les réponses sont déjà dans le fichier.
Dev Mode : ce que les développeurs voient
Figma Dev Mode est une interface dédiée aux développeurs, séparée de l’espace de conception. Elle permet d’inspecter les composants, de voir les valeurs CSS générées, les tokens utilisés, les dimensions et les espacements, sans risquer de modifier les maquettes.
Fonctionnalités clés de Dev Mode :
- Inspection des composants : valeurs CSS, tokens de couleur et de typographie, dimensions exactes
- Annotations : les designers peuvent ajouter des notes directement sur les maquettes, visibles uniquement en Dev Mode, pour documenter les comportements, les cas limites ou les interactions
- Statuts Ready for dev : les composants et les frames peuvent être marqués « prêts pour le développement », ce qui évite que le développeur implémente une version encore en cours de révision
- Comparaison avant/après : quand une maquette est mise à jour, Dev Mode affiche les différences avec la version précédente
Préparer un fichier Figma pour le handoff
Un fichier Figma bien préparé répond à toutes les questions du développeur avant qu’elles soient posées. Checklist de préparation :
- Calques nommés logiquement : « Button/Primary/Large » plutôt que « Rectangle 47 ». Les développeurs qui inspectent le code généré voient ces noms.
- Composants utilisés, pas détachés : un composant détaché perd son lien avec la librairie. Le développeur ne peut pas identifier à quel composant du code il correspond.
- Tokens appliqués : les couleurs et typographies référencent des styles Figma ou des variables, pas des valeurs codées en dur.
- États documentés : hover, focus, disabled, erreur. Si l’état n’est pas dans la maquette, le développeur va soit l’inventer, soit revenir pour poser la question.
- Comportements annotés : animations, transitions, comportements au scroll, cas limite (texte trop long, liste vide, erreur réseau).
| Ce qui manque dans le handoff | Conséquence pour le développeur |
|---|---|
| Les états hover et focus | Implémentation inventée ou question au designer |
| Le comportement sur mobile | Adaptation approximative, revue en fin de sprint |
| Les cas d’erreur et les états vides | UX dégradée en production sur les cas limites |
| Les espacements en tokens, pas en pixels | Valeurs codées en dur, incohérences si la grille change |
| Les animations | Absentes ou approximatives, écart visible avec la maquette |
Ce qui change avec un bon workflow partagé
Quand le design system est partagé entre designers et développeurs, et que les conventions de nommage correspondent entre Figma et le code, le handoff devient mécanique. Un composant « Button/Primary » dans Figma correspond à un composant « ButtonPrimary » dans le code. Le développeur n’a pas besoin de deviner.
Cette correspondance demande une organisation initiale, mais elle réduit le volume de communication de façon durable. Chaque sprint bénéficie de la mise en place faite en amont.
Les rituels qui font fonctionner le handoff
Au-dela des outils, ce sont les rituels d’équipe qui déterminent la qualité du handoff :
- Design review avec un développeur avant le handoff : 30 minutes où un développeur parcourt les maquettes et signale ce qui pose problème techniquement ou ce qui manque de précision
- Critères d’acceptation définis ensemble : le designer et le développeur définissent ensemble ce que « c’est fait » signifie pour chaque composant
- Feedback visuel à l’implémentation : le designer compare le rendu en développement avec la maquette et documente les écarts, pas pour reprendre le travail mais pour corriger les points qui ont de l’impact réel
Un handoff qui fonctionne ne se remarque pas. Les développeurs avancent, les designers ne sont pas interrompus, et le produit ressemble à ce qui a été conçu. C’est l’état normal d’une équipe qui a investi dans ses processus.
