Ce qu'une frame contient réellement
Une frame Figma est un arbre de formes avec des positions, des fonds, des contours, des séquences 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 simultanément 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 échec — 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, qui apparaissent tous 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 génèrent
#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 deuxième point est le plus conséquent et le moins visible lors de la revue. Une fois que les écrans générés contiennent 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 absent du fichier de tokens permet de bloquer cela dès l'entrée.
Le mapping l'emporte sur la génération
L'approche productive consiste à arrêter de demander à l'outil d'écrire du code et à commencer à 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 passe plus par la génération, mais par la 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 générées | 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 la division du travail correcte : 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 2 de Salesforce en 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 exemples de l'équipe sont radius-border-4 et font-scale-4 — ainsi, les designs correspondent un pour un au code réel. Leur objectif affiché est un vocabulaire partagé faisant le pont entre le design et le développement.
Le résultat 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, donc aucune perte de sens possible. Comparez cela à un style Figma nommé "Heading / Large" correspondant à une variable CSS nommée --text-2xl : chaque handoff devient une recherche, et chaque recherche est source d'erreur.
| Incohérent | Cohérent | |
|---|---|---|
| Handoff | Une étape de traduction par propriété | Copier le nom |
| Révision | "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 lisant les deux | Deux vocabulaires, aucune relation définie, devinettes silencieuses | Un seul vocabulaire |
Si vous ne devez retenir qu'une chose de cet article, renommez vos variables Figma pour qu'elles correspondent exactement à vos propriétés CSS personnalisées. Cela prend une après-midi, ne nécessite aucun plugin et supprime une taxe permanente sur chaque handoff. Les noms plats, en minuscules et avec des traits d'union fonctionnent dans les deux outils — plus d'informations sur le nommage pour la portabilité.
Quand le design system vit dans Figma
De nombreuses équipes disposent d'une bibliothèque Figma complète et d'une base de code qui ne la reflète que partiellement. L'instinct est de chercher un outil qui comble cet é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, l'ensemble des composants, le rythme des espacements. Ces décisions se transfèrent parfaitement sous forme de texte, et le texte est le format sur lequel un développeur et un agent de code peuvent agir. Les extraire dans un fichier de tokens accompagné d'un brief écrit représente 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 analysé 299 fichiers DESIGN.md conçus pour transmettre précisément ces informations aux agents IA, et la plupart échouent : 86 % spécifient les couleurs en hexadécimal brut sans rôle sémantique, 76 % n'énoncent aucune interdiction, 69 % ne définissent aucun mode sombre et 44 % n'indiquent aucune valeur de taille concrète. Un brief extrait correctement d'une véritable bibliothèque Figma surpasse presque tous ces fichiers — vous possédez déjà les chiffres.
- 1
Exporter les variables en tokens, avec des rôles
Pas la palette brute. Les rôles : quelle couleur est pour le texte atténué, laquelle est pour une bordure, laquelle est pour 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 ; le côté code n'en possède généralement qu'un sous-ensemble complété par de l'improvisation.
- 3
Noter ce que la bibliothèque refuse de faire
Les interdictions sont implicites dans la bibliothèque — pas d'ombres, pas de graisse au-dessus de 600 — et ce sont les éléments les plus précieux à expliciter, car ils sont invisibles pour toute extraction automatisée.
- 4
Mapper les composants qui existent déjà dans le code
C'est seulement à ce stade que l'outillage devient pertinent, et uniquement pour les composants présents des deux côtés. Tout ce qui n'est pas mappé est une création, et savoir faire la distinction est en soi utile.
Les kits Identity Forge sont cet artefact sous forme pré-construite : 28 rôles de couleurs sémantiques pour le mode clair et sombre, des échelles de typographie et d'espacement, des motifs et des consignes explicites (do's and don'ts), exportables en variables CSS, @theme Tailwind, élément de registre shadcn ou JSON DTCG/W3C. Parcourir les kits ou lire comment rédiger le brief.
À quoi s'attendre avec les outils actuels
Attentes calibrées, par tâche :
| Résultat réaliste | |
|---|---|
| Un prototype jetable à partir d'une maquette | Bien. La dette structurelle n'a aucune importance dans un code destiné à être supprimé |
| Extraction de mesures et de valeurs | Bien, et sous-estimé. L'inspection via le Dev Mode est une victoire simple et fiable |
| Un nouvel écran utilisant des composants existants | Bien si le mapping est configuré. Médiocre sans lui |
| Markup de production à partir d'une frame complexe | Médiocre. Visuellement proche, structurellement faux, et le nettoyage prend généralement plus de temps que de l'écrire |
| 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 déplace 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 parle de 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é.