Ce qu'une frame contient réellement
Une frame Figma est un arbre de formes avec des positions, des fonds, des contours, des segments de texte et des contraintes de mise en page. C'est une description complète de l'apparence d'un élément à une taille donnée. Ce n'est pas une description de ce qu'est cet élément.
| Dans le fichier | Doit être déduit | |
|---|---|---|
| Structure | Un groupe de rectangles et de texte à ces coordonnées | Que ce groupe est une Card, et qu'il s'agit de la même Card utilisée sur neuf autres écrans |
| Couleur | Le fond est #6b7280 | S'il s'agit d'un texte atténué, d'une bordure, d'un état désactivé ou d'un placeholder |
| Espacement | 32px entre ces deux éléments | Si 32 est une étape d'échelle, une valeur unique ou le résultat d'un ajustement manuel |
| Responsiveness | Les contraintes et les éventuelles frames de breakpoints | Ce qui se passe pour chaque largeur entre elles |
| Sémantique | Texte avec une taille plus grande et une graisse plus épaisse | S'il s'agit d'un h1, d'un h2 ou d'un texte stylisé qui n'est pas du tout un titre |
Chaque ligne de la colonne de droite représente une décision que le convertisseur doit prendre sans information. Il prendra chaque décision de manière plausible et indépendante, c'est pourquoi le résultat est à la fois convaincant au premier coup d'œil et impossible à maintenir.
Une frame encode l'apparence. Le code a besoin d'identité et d'intention. Le convertisseur n'est pas en cause. L'information n'a jamais été dans le fichier.
Le coût du code généré
Accepter le résultat tel quel entraîne quatre problèmes spécifiques, lesquels n'apparaissent qu'après la fusion du code plutôt que lors de sa revue.
- 1
Aucune réutilisation de composants
Une même carte convertie sur cinq écrans devient cinq implémentations indépendantes. Rien ne les lie ; ainsi, une modification de la carte implique cinq changements, et quelqu'un n'en trouvera que quatre.
- 2
Des valeurs littérales partout
Les convertisseurs émettent
#6b7280car c'est ce qu'indique le remplissage. Votre couche de tokens est totalement contournée, ce qui signifie que le design system que vous avez construit devient purement décoratif sur ces écrans. - 3
Mise en page absolue ou fragile
Les données de position sont converties en positionnement. Le résultat correspond au frame exactement à sa largeur d'origine, mais se dégrade pour toutes les autres, et cette dégradation est maximale sur les appareils que vous avez le moins testés.
- 4
Absence de sémantique
Un texte large et gras devient une
divstylisée. Les lecteurs d'écran se retrouvent avec une page sans structure de titres, les utilisateurs du clavier n'ont aucun point de repère, et personne ne s'en aperçoit avant un audit.
Le second point est le plus conséquent et le moins visible lors de la revue. Une fois que les écrans générés portent des valeurs de couleur littérales, votre base de code possède deux systèmes de couleurs : les tokens, et ce que le fichier de design indiquait ce jour-là. Un contrôle CI qui échoue lorsqu'un hexadécimal est hors du fichier de tokens permet de bloquer cela dès l'entrée.
Le mapping l'emporte sur la génération
Le recadrage productif consiste à ne plus demander à l'outil d'écrire du code, mais à lui indiquer quel code existe déjà. Code Connect de Figma fait exactement cela : il lie un composant de design à votre véritable composant de code, afin que le Dev Mode affiche le composant réel et ses props plutôt que du CSS généré.
Cela transforme le problème : on ne parle plus de génération, mais de recherche (lookup), et la recherche est un problème qui peut être résolu sans erreur.
| Générer | Mapper | |
|---|---|---|
| Produit | Un nouveau balisage approximant le frame | Une référence au composant que vous maintenez déjà |
| Réutilisation | Aucune. Chaque conversion repart de zéro | Totale, par construction |
| Tokens | Contournés ; valeurs littérales émises | Préservés ; le composant les utilise déjà |
| Accessibilité | Ce que le convertisseur a déduit | Ce que votre composant fait déjà |
| Coût de configuration | Aucun | Un mapping par composant, maintenu lors de l'évolution des composants |
| Échoue quand | Toujours, et lentement | Un design utilise un élément qui n'existe pas encore dans le code |
Cette dernière ligne représente le coût réel, et il est concret : le mapping ne fonctionne que pour les composants existants. Un design véritablement nouveau doit toujours être construit. Mais c'est là la bonne répartition du travail : un humain ou un agent construit le nouveau composant une seule fois, et chaque utilisation ultérieure est une référence plutôt qu'une régénération.
Il est important d'être concret sur la cible du mapping. Un handoff est terminé lorsque le côté code ressemble à ceci — des rôles nommés avec des valeurs réelles — plutôt qu'à une liste d'hexadécimaux récupérés d'un frame :
La stratégie de parité de nommage
Sous le mapping de composants se trouve un changement moins coûteux qui comble une part surprenante du fossé, et il ne nécessite aucun outil : utilisez les mêmes noms aux deux endroits.
Le SLDS de Salesforce est l'exemple publié le plus clair. Sa bibliothèque Figma utilise les mêmes noms de hooks de style sémantiques que le CSS (les propres exemples de l'équipe sont radius-border-4 et font-scale-4), de sorte que les designs correspondent parfaitement au code en production. Leur objectif affiché est de créer un vocabulaire partagé faisant le pont entre le design et le développement.
L'effet est qu'une catégorie entière de bugs de handoff disparaît. Lorsqu'un designer dit font-scale-4 et qu'un développeur tape font-scale-4, il n'y a pas d'étape de traduction, et donc aucun risque de perte de sens. Comparez cela à un style Figma nommé "Heading / Large" associé à une variable CSS nommée --text-2xl : chaque handoff est une recherche manuelle, et chaque recherche peut échouer.
| Incohérent | Conforme | |
|---|---|---|
| Handoff | Une étape de traduction par propriété | Copier le nom |
| Réviser | « Est-ce le bon gris? » nécessite l'ouverture des deux outils | Le nom est soit correct, soit il ne l'est pas |
| Un agent qui lit les deux | Deux vocabulaires, aucune relation établie, supposition silencieuse | Un seul vocabulaire |
Si vous ne devez faire qu'une chose de cet article, renommez vos variables Figma pour qu'elles correspondent exactement à vos propriétés CSS personnalisées. Cela prend un après-midi, ne nécessite aucun plugin et supprime une taxe permanente sur chaque handoff. Des noms plats, en minuscules et séparés par des tirets survivent dans les deux outils : en savoir plus sur le nommage pour la portabilité.
Quand le design system réside dans Figma
De nombreuses équipes disposent d'une bibliothèque Figma exhaustive et d'une base de code qui ne la reflète que partiellement. L'instinct est de chercher un outil capable de combler l'écart automatiquement. Il existe une solution moins coûteuse et plus efficace.
Une bibliothèque Figma contient les décisions : l'échelle, les rôles, le jeu de composants, le rythme d'espacement. Ces décisions se transfèrent parfaitement sous forme de texte, et le texte est le format sur lequel un développeur comme un agent de code peuvent agir. Les extraire dans un fichier de tokens accompagné d'un brief écrit demande une journée de travail et rend toute conversion ultérieure inutile, car le code dispose désormais des mêmes informations que le design.
Nous avons échantillonné 299 fichiers DESIGN.md rédigés pour transmettre précisément ces informations à des agents IA, et la plupart ne le font pas : 86 % spécifient les couleurs sous forme de hex bruts sans rôle sémantique, 76 % ne mentionnent aucune interdiction, 69 % ne définissent pas de mode sombre, et 44 % ne mentionnent aucune valeur de taille concrète. Un brief extrait d'une véritable bibliothèque Figma, réalisé correctement, surpasse presque tous ces fichiers. Vous avez déjà les chiffres.
- 1
Exporter les variables en tant que tokens, avec des rôles
Pas la palette brute. Les rôles : quelle couleur est un texte estompé, laquelle est une bordure, laquelle est un état désactivé. Si vos variables Figma sont nommées par teinte, c'est le moment de les renommer par rôle aux deux endroits simultanément.
- 2
Noter les échelles sous forme de nombres
Tailles de police, étapes d'espacement, rayons. La bibliothèque contient déjà ces éléments ; la partie code n'a généralement qu'un sous-ensemble complété par l'improvisation.
- 3
Noter ce que la bibliothèque refuse de faire
Les interdictions sont implicites dans la bibliothèque (pas d'ombres nulle part, pas de graisse supérieure à 600), et ce sont les éléments de plus haute valeur à rendre explicites, car ils sont invisibles pour toute extraction automatisée.
- 4
Mapper les composants déjà présents dans le code
C'est seulement à ce stade que l'introduction d'outils est pertinente, et uniquement pour les composants présents des deux côtés. Tout ce qui n'est pas mappé nécessite un développement, et savoir ce qui est quoi est en soi utile.
Les kits Identity Forge sont cet artefact sous forme préconstruite : 28 rôles de couleurs sémantiques pour les modes clair et sombre, des échelles de typographie et d'espacement, des motifs et des instructions explicites (do's and don'ts), exportables en tant que variables CSS, @theme Tailwind, élément de registre shadcn/ui ou JSON DTCG/W3C. Parcourir les kits, ou lire comment rédiger le brief.
Ce qu'il faut attendre des outils actuels
Attentes calibrées, par tâche :
| Résultat réaliste | |
|---|---|
| Un prototype jetable à partir d'une maquette | Bien. La dette structurelle n'importe pas pour du code que vous allez supprimer |
| Extraction des mesures et des valeurs | Bien, et sous-estimé. L'inspection via Dev Mode est une victoire simple et fiable |
| Un nouvel écran utilisant des composants existants | Bien avec un mapping configuré. Médiocre sans lui |
| Markup de production à partir d'un frame complexe | Médiocre. Visuellement proche, structurellement erroné, et le nettoyage est généralement plus long que l'écriture initiale |
| Convertir un design system complet | Ce n'est pas un problème de conversion. Extrayez plutôt les décisions sous forme de texte |
La deuxième ligne mérite plus de reconnaissance qu'elle n'en reçoit. Une inspection fiable (valeurs exactes, noms de tokens réels, props de composants effectives) élimine une friction quotidienne bien réelle sans jamais prétendre faire plus que ce qu'elle fait.
L'IA peut-elle convertir des designs Figma en code de production ?
Elle peut produire un code qui ressemble à la frame. Quant à savoir s'il s'agit de code de production, cela dépend de la structure, et la structure est précisément ce qu'une frame ne contient pas : l'identité du composant, les rôles sémantiques, le comportement responsive entre les breakpoints. Attendez-vous à un résultat visuellement proche mais structurellement erroné, et prévoyez du temps pour le nettoyage.
Qu'est-ce que Figma Code Connect ?
Une fonctionnalité qui lie les composants de design à vos composants de code réels, afin que le Dev Mode affiche le composant effectif et ses props au lieu d'un CSS généré. Cela transforme le problème : on ne génère plus de nouveau markup, on référence du code que vous maintenez déjà, ce qui préserve la réutilisation, les tokens et le travail d'accessibilité.
Pourquoi le résultat du design-to-code utilise-t-il des couleurs codées en dur ?
Parce que le remplissage dans la frame est une valeur, et le convertisseur n'a aucun moyen de savoir quel rôle sémantique cette valeur joue. C'est l'alignement des noms de variables Figma avec vos noms de tokens CSS qui permet à l'outil d'avoir une référence plutôt qu'un code hexadécimal.
Comment intégrer mon design system Figma dans le code ?
Pas en convertissant des écrans. Exportez les variables en tant que tokens sémantiques avec des rôles associés, consignez les échelles sous forme de nombres, notez ce que la bibliothèque refuse de faire, et seulement ensuite, mappez les composants qui existent des deux côtés. Cela représente une journée de travail et rend toute conversion ultérieure inutile.
Les designers et les développeurs doivent-ils utiliser les mêmes noms de tokens ?
Oui, et c'est le changement offrant le meilleur retour sur investissement pour l'effort fourni. Lorsqu'un designer dit font-scale-4 et qu'un développeur tape font-scale-4, il n'y a plus d'étape de traduction et donc aucun risque de perte de sens. Salesforce a bâti la bibliothèque Figma de SLDS 2 précisément sur cette parité.