Synchroniser l’espacement entre Figma et le code

L’espacement reste synchronisé entre Figma et le code quand aucun côté ne maintient sa propre liste : une seule échelle générée est exportée vers les deux — en Figma Variables pour le fichier de design, en propriétés personnalisées CSS ou en thème Tailwind pour la base de code — pour que designers et développeurs lisent les mêmes valeurs depuis la même source. Les plugins, les revues de redline et les règles de lint traitent le symptôme ; une source unique en supprime la cause.

Sans cette source, la dérive suit un scénario prévisible. Les designers gardent une liste d’espacement dans Figma ; les développeurs en gardent une autre dans le CSS. Personne ne décide de diverger — un écart est poussé à 20 pour sauver une carte trop chargée, un 22 est arrondi à 24 « pour rester sur la grille » — et un an plus tard, une redline devient une négociation : est-ce 20 ou 24 ? La réponse honnête est souvent « 22 dans le fichier, 20 en production ».

Cet article explique d’où vient la dérive, ce que sont les Figma Variables, le flux d’export qui permet à une seule échelle d’alimenter les deux côtés, et un audit pour les produits existants — la moitié design-vers-code d’un système d’espacement complet.

Pourquoi les valeurs d’espacement de Figma et du code dérivent-elles ?

Parce que deux listes sont maintenues à la main sous des pressions indépendantes. Le fichier de design est modifié pour corriger des problèmes visuels frame par frame ; la feuille de style est modifiée pour corriger des bugs de mise en page et pour accueillir du contenu. Chaque modification est locale, raisonnable et invisible pour l’autre côté. Aucun changement pris isolément n’est une erreur — la divergence est la somme de nombreuses décisions correctes prises face à deux sources de vérité différentes.

On entend la dérive dans les conversations de handoff. Une équipe synchronisée débat de quel palier un écart devrait être (« c’est une rupture de section, utilise le grand palier ») ; une équipe dérivée débat de ce qu’est la valeur (« le fichier dit 22, le build dit 20 »). Quand la mesure remplace le sens, les listes se sont déjà séparées.

Que sont les Figma Variables ?

Les Figma Variables sont des valeurs nommées — un nombre comme space/3 = 16 — qui peuvent être liées aux écarts et au padding de l’auto-layout à la place de nombres bruts ; l’introduction aux variables de Figma en couvre les mécanismes. Liez l’écart d’un frame à space/3 et le frame suit la variable : changez la variable une fois et chaque frame lié se met à jour. C’est l’équivalent, côté fichier de design, d’une propriété personnalisée CSS — une référence là où il y avait un nombre.

Une note de cadrage honnête : les Variables rendent le côté design capable de lire des tokens d’espacement, mais une collection de variables saisie à la main reste une liste maintenue à la main. La synchronisation vient du fait de générer cette collection à partir de la même échelle d’espacement que celle lue par le code — pas de la fonctionnalité elle-même.

Comment une seule échelle alimente-t-elle à la fois le design et le code ?

Trois mouvements :

1. Générer. Une seule échelle à partir de trois nombres — base 16, ratio 2, deux paliers par doublement — produit les paliers 8, 11, 16, 23, 32, 45, 64.
2. Exporter dans les deux sens. Les mêmes paliers partent en Figma Variables pour le fichier de design et en propriétés personnalisées CSS ou en bloc @theme Tailwind v4 pour la base de code, avec les tokens DTCG comme format d’échange neutre.
3. Lier et référencer. Le designer lie les écarts et le padding de l’auto-layout aux variables ; le développeur référence les propriétés personnalisées. Aucun côté ne tape plus jamais de valeur en pixels.

Ouvrez cette échelle avec l’export Figma Variables en vue — les sept paliers et les noms qu’ils portent dans les deux environnements.

À partir de là, un changement d’espacement est un événement en amont : ajustez la base ou le ratio une fois, ré-exportez les deux côtés, et le changement arrive dans le fichier de design et dans le build sous forme des mêmes nombres. La négociation de redline disparaît parce qu’il ne reste plus rien de local à négocier.

Comment mesurer la dérive d’espacement dans un produit existant ?

Inventoriez les valeurs d’espacement distinctes de chaque côté et comparez. Dans le code, faites un grep des feuilles de style pour les valeurs de margin, padding et gap et comptez les résultats distincts ; dans Figma, échantillonnez les écarts et le padding sur vos écrans principaux. Un audit non synchronisé typique ressemble à peu près à ceci : 41 valeurs distinctes en CSS, 13 dans Figma, 9 partagées entre les deux. Le nombre de non-concordances est la dérive, en un seul chiffre — et l’audit fait aussi office de plan de migration : associez chaque valeur existante au palier d’échelle le plus proche (22 → 23 ; un 20 esseulé devient un choix de jugement entre 16 et 23), puis convergez côté par côté plutôt qu’en une seule réécriture.

La synchronisation des valeurs garantit-elle un espacement cohérent ?

Non — et il vaut la peine d’être précis sur ce que la synchronisation apporte. Les exports partagés résolvent les valeurs : les deux côtés s’accordent désormais sur ce qui existe. Quel palier va où — padding de carte contre écart de section contre espacement d’icône — relève de la discipline d’usage, et cela reste du jugement humain des deux côtés du handoff. Un designer peut lier la mauvaise variable à un écart, et ce sera fidèlement, systématiquement faux dans le code aussi.

Ce que la source partagée change, c’est que le mauvais choix devient visible et nommable : « ça devrait être space-4, pas space-5 » est une conversation que deux personnes peuvent régler dans un fil de commentaires, là où « est-ce 20 ou 24 ? » relevait de l’archéologie. Les valeurs par la machine, les rôles par le jugement — voilà la répartition réaliste.

Configurer l’export de parité

Partez de l’échelle plutôt que de l’une ou l’autre liste : générez les paliers, puis placez les deux exports côte à côte — les mêmes sept valeurs rendues une fois en Figma Variables et une fois en bloc @theme Tailwind — et changez le ratio pour les voir se mettre à jour ensemble. Ce mouvement simultané est tout l’argument pour une source unique, visible sur un seul écran : ouvrez l’export de parité dans Scale Composer.