Introduction
Dans de nombreuses équipes, le passage du design à la production reste un défi : les maquettes Figma sont souvent parfaites sur le plan visuel, mais leur traduction en code peut entraîner des incohérences, des pertes de temps et des erreurs.
Chez nous, nous avons mis en place un workflow Design-to-Code qui relie étroitement designers et développeurs grâce à trois piliers :
• Les design tokens
• Les component libraries
• Une boucle de collaboration continue
1. Figma comme point de départ
Figma est notre espace de création et de prototypage. Chaque élément y est pensé pour être sémantiquement cohérent avec le code.
Nous structurons nos fichiers selon un design system :
• Styles globaux (couleurs, typographies, espacements)
• Composants réutilisables (boutons, formulaires, cartes)
• Pages et prototypes pour tester les interactions
Astuce : Utiliser le mode “Dev” de Figma permet aux développeurs d’inspecter directement les valeurs CSS, les marges et les tailles sans dépendre d’un export manuel.
2. Les Design Tokens : la clé de la synchronisation
Les design tokens sont des variables universelles qui traduisent les décisions de design en code.
Ils garantissent que la couleur, la typographie ou le rayon d’un bouton restent identiques entre Figma et le code.
Exemple concret :
Élément
Valeur Figma
Variable CSS
Couleur primaire
#0077ff
--color-primary
Taille de police titre
24px
--font-title: 1.5rem
Espacement standard
8px
--spacing-sm: 0.5rem
Outils utilisés :
• Tokens Studio pour Figma → export JSON des tokens
• Style Dictionary → conversion automatique en variables CSS, SCSS ou Tailwind
• CI/CD GitHub Actions → mise à jour automatique des tokens dans le repo front-end
3. Les Component Libraries : cohérence et réutilisabilité
Une bibliothèque de composants est le cœur du design system.
Chaque composant Figma correspond à un composant codé (React, Vue, Angular, etc.), avec le même nom et les mêmes propriétés.
Bonnes pratiques :
• Nommer les composants de manière identique dans Figma et le code : Button / Primary → <Button variant="primary" />, Input / Error → <Input state="error" />
• Utiliser Auto Layout pour simuler le comportement CSS (Flexbox, Grid)
• Connecter Figma à Storybook pour visualiser les composants réels et tester leur rendu
4. Collaboration Designers ↔ Développeurs
La communication est continue et structurée :
• Les designers marquent les éléments “Ready for Dev”
• Les développeurs inspectent les valeurs via le mode Dev
• Les tokens et composants sont synchronisés via Git
• Les retours sont faits directement dans Figma ou via des PR (pull requests)
Objectif : réduire les allers-retours et garantir une cohérence visuelle et fonctionnelle à chaque mise à jour.
5. Automatisation et outils IA
Les outils modernes comme Figma Dev Mode, Locofy.ai, Anima, ou Builder.io Visual Copilot permettent de générer du code de production à partir des designs.
Ces solutions utilisent l’IA pour convertir automatiquement les layouts Figma en code React, Vue ou HTML/CSS propre et responsive.
Avantages :
• Gain de temps (jusqu’à 80 % sur la conversion manuelle)
• Réduction des erreurs humaines
• Alignement parfait entre design et développement
6. Exemple de workflow complet
1. Création du design dans Figma
2. Export des tokens via Tokens Studio
3. Synchronisation automatique avec le repo front-end
4. Intégration des composants dans Storybook
5. Validation visuelle et fonctionnelle
6. Déploiement via CI/CD (GitHub Actions, Vercel, Netlify…)
7. Cas pratique : du composant Figma au composant React
Prenons l’exemple d’une carte produit (ProductCard) conçue dans Figma, et voyons comment elle se traduit en code.
Étape 1 — Le composant dans Figma
Dans Figma, le composant Card / Product est structuré ainsi :
• Un conteneur avec Auto Layout (direction verticale, padding 16px, gap 8px, coins arrondis 8px)
• Une image (ratio 16:9)
• Un titre (--font-title, 24px)
• Un prix (--color-primary, --font-weight-bold)
• Un bouton Button / Primary
Les designers exportent les tokens correspondants via Tokens Studio :
{
"color": {
"primary": { "value": "#0077ff" },
"text-default": { "value": "#1a1a1a" },
"background-card": { "value": "#ffffff" }
},
"spacing": {
"sm": { "value": "8px" },
"md": { "value": "16px" }
},
"borderRadius": {
"card": { "value": "8px" }
},
"fontSize": {
"title": { "value": "1.5rem" }
}
}
Étape 2 — Conversion en variables CSS via Style Dictionary
:root {
--color-primary: #0077ff;
--color-text-default: #1a1a1a;
--color-background-card: #ffffff;
--spacing-sm: 0.5rem;
--spacing-md: 1rem;
--border-radius-card: 8px;
--font-title: 1.5rem;
}
Étape 3 — Le composant React
// ProductCard.jsx
import "./ProductCard.css";
/**
* Composant ProductCard
* Reproduit fidèlement le composant Figma "Card / Product"
* en respectant les design tokens définis dans variables.css
*/
export default function ProductCard({ image, title, price, onAddToCart }) {
return (
<div className="product-card">
{/* Image avec ratio 16:9, comme défini dans Figma */}
<img src={image} alt={title} className="product-card__image" />
{/* Titre — utilise le token --font-title */}
<h3 className="product-card__title">{title}</h3>
{/* Prix — couleur primaire issue du token --color-primary */}
<span className="product-card__price">{price} €</span>
{/* Bouton réutilisable, correspond au composant Figma "Button / Primary" */}
<button className="button button--primary" onClick={onAddToCart}>
Ajouter au panier
</button>
</div>
);
}
/* ProductCard.css */
.product-card {
display: flex;
flex-direction: column;
gap: var(--spacing-sm);
padding: var(--spacing-md);
background-color: var(--color-background-card);
border-radius: var(--border-radius-card);
box-shadow: 0 2px 8px rgba(0, 0, 0, 0.05);
}
.product-card__image {
width: 100%;
aspect-ratio: 16 / 9;
object-fit: cover;
border-radius: var(--border-radius-card);
}
.product-card__title {
font-size: var(--font-title);
color: var(--color-text-default);
margin: 0;
}
.product-card__price {
font-weight: bold;
color: var(--color-primary);
}
.button--primary {
background-color: var(--color-primary);
color: white;
border: none;
border-radius: 4px;
padding: var(--spacing-sm) var(--spacing-md);
cursor: pointer;
}
.button--primary:hover {
opacity: 0.9;
}
Étape 4 — Validation dans Storybook
// ProductCard.stories.jsx
import ProductCard from "./ProductCard";
export default {
title: "Components/ProductCard",
component: ProductCard,
};
export const Default = {
args: {
image: "/images/sample-product.jpg",
title: "Casque Audio Sans Fil",
price: "89.99",
},
};
Le designer peut alors comparer côte à côte le rendu Storybook et la maquette Figma pour valider la fidélité visuelle — et signaler d’éventuels écarts directement en commentaire sur la story ou la PR.
8. Pièges courants et limites à connaître:
Même avec un workflow bien rodé, certains écueils reviennent souvent. Les anticiper évite bien des frustrations.
Auto Layout ≠ Flexbox parfait
Figma simplifie beaucoup le modèle CSS réel. Un Auto Layout avec un comportement “hug” ou “fill” ne se traduit pas toujours 1:1 en flex-grow, flex-shrink ou min-width. Il faut souvent ajuster manuellement le CSS généré, surtout sur des layouts complexes ou imbriqués.
Le responsive n’existe pas vraiment dans Figma
Figma travaille sur des frames à taille fixe. Les breakpoints, les media queries, le comportement mobile-first : tout cela doit être pensé séparément par les développeurs, idéalement avec des maquettes dédiées par taille d’écran (mobile, tablette, desktop) plutôt qu’en espérant qu’un seul design s’adapte automatiquement.
Dérive entre tokens et code (token drift):
Si la synchronisation CI/CD échoue silencieusement, ou si un développeur modifie une valeur “en dur” dans le code sans repasser par les tokens, design et code divergent progressivement. Solution : des tests automatisés (ex. visual regression testing avec Chromatic ou Percy) qui comparent le rendu réel aux maquettes Figma.
Versioning des design tokens
Quand un token change de valeur (ex. --color-primary passe de #0077ff à #0066dd), l’impact peut être large. Bonnes pratiques : versionner les fichiers de tokens (semver), documenter les breaking changes, et prévoir une période de transition avec les deux valeurs disponibles si nécessaire.
L’accessibilité n’est pas garantie par défaut:
Un composant visuellement fidèle à Figma n’est pas forcément accessible. Les designers pensent rarement aux contrastes WCAG, aux états :focus, aux attributs ARIA ou à la navigation clavier. Ces éléments doivent être ajoutés côté code et idéalement testés (ex. avec axe-core ou Lighthouse), même s’ils n’apparaissent pas dans la maquette.
Les outils IA (Locofy, Anima, etc.) génèrent du code “brut”
Le code généré automatiquement est rarement prêt pour la production tel quel : noms de classes peu sémantiques, structure HTML pas toujours optimale, dépendances inutiles. Il doit être considéré comme un point de départ à nettoyer et intégrer dans le design system existant, pas comme un livrable final.
9. Conclusion
Le passage “From Figma to Production” n’est plus une étape douloureuse : c’est un processus fluide et collaboratif.
Grâce aux design tokens, aux component libraries et à une communication constante, les équipes peuvent livrer des produits cohérents, rapides et évolutifs.rticle content coming soon.