Concevoir un design system dans Figma, puis l'implémenter avec Claude Code

Ce que le côté Figma du système représentait

Le système de design a été construit dans Figma avec des tokens structurés : espacement, couleur, typographie, border radius, ombre, tous définis comme des variables avec des conventions de nommage explicites. Les composants ont été construits avec des auto-layout frames nommés clairement, des variantes organisées par état (default, hover, focus, disabled, error) et des propriétés de composants exposées de façon cohérente. La documentation était intégrée directement dans la structure du composant plutôt que maintenue séparément.

Ce niveau de structure n'est pas exceptionnel pour un système de design mature, mais il importe ici pour une raison précise : il rend le fichier lisible par Claude Code via le Figma MCP. Le modèle peut lire les noms de composants, les labels de variantes, les valeurs de tokens et la hiérarchie structurelle. Un fichier Figma désorganisé avec un nommage incohérent aurait produit un output beaucoup plus bruité à l'étape d'implémentation.

Comment Claude Code lit le système de design

Le Figma MCP donne à Claude Code accès aux données du fichier : structure des composants, valeurs de tokens, noms de calques, combinaisons de variantes. Ce n'est pas du screenshot-to-code. Le modèle lit des données de design structurées, ce qui constitue un input fondamentalement différent. Il peut distinguer un état « Button/Primary/Large/Default » d'un état « Button/Primary/Large/Hover », non pas en interprétant un visuel, mais en lisant l'arbre de composants.

En pratique, cela a produit plusieurs résultats concrets. Les composants atomiques (boutons, champs de saisie, badges, tags, chips) ont été implémentés avec une haute fidélité dès le premier passage. L'espacement, le border radius, les tokens de couleur, l'échelle typographique : tout correspondait aux spécifications Figma sans correction manuelle. L'écart qui existe normalement entre ce qu'un designer spécifie et ce qui est construit était proche de zéro pour ces éléments.

Les composants composites (cartes, navigation, sections de formulaire) ont nécessité plus d'itérations. La logique structurelle de l'interaction entre sous-composants n'était pas toujours lisible depuis la structure du fichier seule. Cela a nécessité de retourner dans Figma, de rendre la hiérarchie plus explicite, puis de relancer le passage d'implémentation. C'est du travail, mais d'une nature différente : de la clarification de design plutôt que du débogage après coup.

La plateforme d'implémentation et pourquoi Astro avait du sens

Le site dédié au système de design a été construit avec Astro et Tailwind CSS. Astro a été choisi pour son modèle d'isolation de composants et sa capacité à produire un site statique léger et rapide sans surcharge d'un framework JavaScript lourd. Tailwind s'est mappé proprement au système de tokens : les valeurs de design tokens ont été traduites directement en extensions de configuration Tailwind, de sorte que la couche CSS et le fichier de design partagent les mêmes valeurs sous-jacentes.

Claude Code a piloté l'implémentation de chaque page de composant : générant le code du composant depuis les données Figma, construisant la mise en page de documentation, créant les exemples d'utilisation et rédigeant les tables de référence de tokens. Le rôle du designer dans cette phase était d'évaluer la fidélité, de signaler les écarts et de clarifier les ambiguïtés dans la structure de design, plutôt que d'écrire du markup ou du CSS.

Là où la source de vérité unique tient vraiment

Le résultat pratique de ce workflow est que le fichier Figma et l'implémentation restent synchronisés tant que le fichier de design reste structuré. Quand une valeur de token change dans Figma (une couleur, une unité d'espacement, un border radius), le changement peut être propagé vers le codebase via une session Claude Code ciblée plutôt que par un find-and-replace manuel dans des dizaines de fichiers. Quand une nouvelle variante de composant est ajoutée dans Figma, l'implémentation peut être générée depuis le nouvel état du fichier plutôt qu'à partir d'une spécification écrite.

Cela n'élimine pas le jugement humain. Cela change ce à quoi ce jugement est appliqué. Au lieu de passer du temps sur la traduction, vérifier que ce qui a été designé dans Figma est fidèlement reflété dans le code, l'attention du designer va vers les décisions structurelles : cette variante de composant est-elle nécessaire, ce nom de token communique-t-il la bonne intention, cette page de documentation aide-t-elle un ingénieur à prendre la bonne décision sans demander de clarification. Ce sont des questions d'ordre supérieur. Ce sont aussi celles qui déterminent en réalité si un système de design est utilisé ou ignoré.

Le plafond de l'approche

L'expérience avait des limites claires. L'animation, le mouvement et le comportement d'interaction n'étaient pas lisibles depuis le fichier Figma d'une façon produisant une implémentation précise. Les décisions de mise en page complexes impliquant un comportement responsive nécessitaient une description explicite plutôt qu'une inférence depuis les données de design. Et la qualité de l'output du Figma MCP se dégradait notablement pour les structures de composants profondément imbriquées.

La conclusion n'est pas que l'implémentation de système de design pilotée par IA remplace l'implication du designer. C'est qu'un fichier de design bien structuré entre les mains d'un designer qui sait diriger une couche d'implémentation IA peut comprimer la distance entre spécification et artefact à un degré qui n'était pas pratiquement atteignable auparavant. Le travail qui reste est du travail de design. Le travail qui disparaît est du travail de traduction, et c'est exactement ce qui devrait disparaître.