Avant d'adopter cette méthode, ce type de projet pouvait monopoliser une équipe pendant longtemps, avec de nombreux allers-retours. Extraire manuellement les couleurs, transcrire les espacements, maintenir la synchronisation avec les mises à jour design... Le scénario est connu : au moindre changement, si personne n'est prévenu, on découvre les écarts deux sprints plus tard.

Aujourd'hui, l'approche d'ACSEO permet de produire une bibliothèque de composants React avec des tests, un système de tokens complet, une synchronisation Figma automatisée, et un suivi des changements. Cette approche conjugue gain de temps ET amélioration de la qualité de nos projets.

Un design system Figma complet

Le design system du client incluait des composants Button et Card, des variables locales structurées pour les couleurs et les espacements. Rien de fantaisiste, mais un travail de design rigoureux avec une nomenclature cohérente et des tokens bien organisés, ce qui constitue un facteur clé de succès pour la suite des opérations.

On a connecté Claude Code (ou Cursor) directement au fichier Figma via le serveur MCP (Model Context Protocol) fourni par Figma.

Extraction automatisée des design tokens

Notre workflow commence par l'extraction des design tokens, en fournissant l'URL du composant Figma à Claude Code.

# Commande réelle utilisée sur le projet client
mcp__figma__get_design_context node-id=XXX fileKey=YYY

L'outil se connecte au fichier Figma, analyse la structure du composant, et extrait l'ensemble des propriétés : couleurs, espacements, tailles de police, et propriétés de thème. La particularité de cette approche, c'est que les données sont immédiatement transformées en tokens TypeScript structurés, avec typage strict et hiérarchie sémantique :

// src/tokens/colors.ts - Généré automatiquement
export const colors = {
  cta: {
    default: {
      background: '#f2c94c',
      border: '#14b8a6',
      text: '#ffffff',
      icon: '#ffffff',
    },
    hover: {
      background: '#2dd4bf',
      border: '#2dd4bf',
      text: '#ffffff',
      icon: '#ffffff',
    },
  },
} as const;

Nos prompts ont été affinés pour que les guidelines de qualité des projets ACSEO soient appliquées dès cette première étape.

Génération de composants React production-ready

L'étape suivante consiste à générer les composants React. On voit souvent des outils de génération produire du code jetable, avec des valeurs en dur et une architecture approximative. Notre approche est différente. Chaque composant généré respecte nos standards de production : React 19, TypeScript strict avec interfaces complètes exportées, architecture token-based sans aucune valeur en dur, accessibilité native avec props ARIA et gestion du focus et intégration du ThemeProvider via hooks pour la gestion des thèmes.

Aucune valeur en dur dans ce code. Tout vient du système de tokens. Quand le design change dans Figma, seuls les tokens sont mis à jour. Le code des composants ne bouge pas.

Workflow de synchronisation, le cas réel d'une mise à jour design

Voici où l'approche devient vraiment intéressante. Sur ce projet client, le designer a modifié la couleur du bouton CTA pendant le sprint. Changement visuel important : passage du teal (#14b8a6) au jaune (#f2c94c) pour améliorer la hiérarchie visuelle. Dans un workflow classique, voici ce qui se passe :

1. Le designer modifie Figma et prévient l'équipe dev
2. Un développeur compare visuellement les deux versions
3. Il cherche dans le code où cette couleur est utilisée (grep, recherche manuelle)
4. Il met à jour manuellement les valeurs dans les fichiers de tokens, les composants, les tests
5. Il teste visuellement chaque composant affecté
6. Il documente le changement dans le CHANGELOG

Temps total : Entre une et plusieurs heures, surtout si la couleur est utilisée dans différents composants ou si on découvre des incohérences.

Notre workflow avec MCP Figma ressemble à ça :

# Étape 1 : On demande à Claude de synchroniser
# "Analyse le node-id=XXX dans Figma et compare avec notre implémentation"

# Étape 2 : Détection automatique des changements
# - Button background: #14b8a6 → #f2c94c (BREAKING VISUAL CHANGE)
# - Border unchanged: #14b8a6
# - Autres propriétés inchangées

# Étape 3 : Mise à jour des tokens
# Modifie src/tokens/colors.ts et src/tokens/theme.ts

# Étape 4 : Ajustement des tests
# Met à jour les assertions RGB dans Button.test.tsx

# Étape 5 : Validation
# Lance npm test → 45/45 passing

# Étape 6 : Documentation
# Génère le CHANGELOG.md pour la v1.1.0 avec migration guide

Temps total : 5 minutes. Zéro oubli, zéro erreur de transcription, documentation automatique. Sur ce projet, on a itéré 3 fois sur les couleurs du CTA avant validation finale. Sans cette automatisation, on aurait perdu une journée complète juste sur ce composant.

Une suite complète de 45 tests générés et maintenus

Un aspect souvent négligé dans les projets de design system : la couverture de tests. Sur ce projet client, chaque composant généré inclut sa suite de tests complète. Pas 2 ou 3 essais symboliques pour faire joli dans le rapport, mais une validation réelle des tokens, variants, états et thèmes :

// src/components/Button.test.tsx - Extrait
describe('Button Component', () => {
  it('should apply default CTA variant tokens', () => {
    renderWithTheme(<Button>Test</Button>);
    const button = screen.getByRole('button');

    // Vérifie que les tokens sont appliqués (pas de valeurs en dur)
    expect(button.style.backgroundColor).toBe('rgb(242, 201, 76)'); // #f2c94c
    expect(button.style.borderColor).toBe('rgb(20, 184, 166)'); // #14b8a6
  });

  it('should support three sizes with correct spacing tokens', () => {
    // Test des 3 tailles avec vérification des espacements
  });

  it('should switch theme correctly', () => {
    // Test du passage light/dark mode
  });

  // ... 15 autres tests par composant
});

Résultat sur ce projet client : 45 tests couvrant Button (18 tests) et Card (27 tests), avec gestion des thèmes, des variants, et des cas limites. Tous générés automatiquement et tous passent. Générer cette suite de tests manuellement aurait pris deux jours minimum, sans compter le temps passé à débugger les cas limites qu'on découvre toujours trop tard. Ici, les tests sont générés en même temps que les composants, avec la même rigueur.

Métriques du projet client

Les chiffres concrets de ce projet :

Métrique	Valeur	Équivalent manuel
Composants générés	2 (Button, Card)	3-4 jours
Fichiers de tokens	6 (colors, spacing, typography, borders, sizing, semantic)	1-2 jours
Tests écrits	45 (tous passing)	2 jours
Temps de sync Figma	< 5 minutes par mise à jour	4-6 heures
Build output	CJS: 14.83 KB, ESM: 12.55 KB, Types: 14.18 KB	Identique
Versions livrées	v1.0.0, v1.1.0 (breaking color change)	-
Itérations design	3 cycles complets	1 cycle (limitation temps)

Le ratio temps investi sur résultat obtenu change complètement la donne. On parle de livrer en 3-4 jours ce qui aurait pris 2-3 semaines en approche manuelle. Mais surtout, on peut se permettre d'itérer. Sur ce projet, le client a validé le CTA au bout de 3 essais. En manuel, on aurait figé le design dès la première version par manque de temps.

Livraison en production : bibliothèque npm privée

Ce qu'on vient de décrire n'est pas un proof of concept. C'est une bibliothèque production-ready, publiée sur le GitLab Package Registry du client, avec versioning sémantique et CHANGELOG documenté à chaque release. La bibliothèque est consommée par 3 applications du client (site vitrine, back-office, application mobile web).

Le workflow de mise à jour devient :

1. Le designer met à jour le design system Figma
2. On lance la synchronisation Claude/MCP (5 minutes)
3. Les tokens sont mis à jour dans les fichiers sources
4. La suite de tests valide que rien n'est cassé (npm test → 45/45)
5. Le build est regénéré (CJS + ESM + Types)
6. On publie une nouvelle version sur le registry (MAJOR/MINOR/PATCH selon l'impact)
7. Les 3 applications clientes font npm update @client/design-system
8. Les équipes valident en staging avant de pousser en production

Figma devient la source de vérité. Le code reste synchronisé. Les applications consommatrices reçoivent les mises à jour de manière contrôlée. Sur ce projet, on a livré 2 versions majeures en production (v1.0.0 et v1.1.0) avec zéro régression, grâce à la couverture de tests automatique.

Les trois piliers techniques de l'approche

Trois ingrédients expliquent l'efficacité de cette méthode, et pourquoi on l'applique maintenant sur tous nos projets de design system.

MCP Figma : accès programmatique aux designs. Le Model Context Protocol permet à Claude Code de se connecter directement aux fichiers Figma et d'en extraire la structure complète. Variables locales, propriétés des composants, annotations design, tout est accessible. Fini d'ouvrir Figma pour mesurer des pixels ou copier des codes couleur. L'outil lit directement la source de vérité et transforme les données en tokens structurés. La précision est absolue parce qu'il n'y a pas d'interprétation humaine.

Claude Code : génération architecturale, pas template basique. Claude Code ne se contente pas de générer du code à partir de templates. Il comprend l'architecture du projet, identifie les patterns existants, respecte les conventions de l'équipe (React 19, TypeScript, conventions de nommage), et maintient la cohérence à travers tous les fichiers générés. Sur ce projet client, on avait des conventions spécifiques pour les noms d'interfaces TypeScript et l'organisation des fichiers. Claude Code les a respectées sans configuration particulière, juste en analysant le contexte du projet.

Architecture token-based : séparation design/logique. L'approche token-based garantit qu'une mise à jour design ne nécessite jamais de toucher au code des composants. Les tokens sont la couche d'abstraction entre le design et l'implémentation. Quand une couleur change dans Figma, seuls les fichiers de tokens sont modifiés. Le code des composants reste intact. Cette séparation est la clé pour maintenir un design system à long terme sans accumuler de dette technique.

Impact sur les projets clients

Ce que cette approche change concrètement sur nos projets :

Pour les équipes design/dev. Les équipes design et développement restent synchronisées en continu. Le designer modifie Figma, la synchronisation met à jour les tokens, les tests valident, les applications récupèrent la nouvelle version. Pas de documentation à maintenir manuellement, pas de réunions pour aligner les équipes, pas d'écarts qui s'accumulent entre le design et le code. Sur ce projet client, on a livré 3 itérations design en 2 semaines. En approche manuelle, on aurait figé le design dès le début par contrainte de temps.

Pour les délais et budgets. Les délais passent de plusieurs semaines à quelques jours. Le budget initialement prévu pour "transformer le design system en code" a été réduit de 60%, et réalloué sur des fonctionnalités métier à plus forte valeur. Le client a pu investir ce temps gagné dans des tests utilisateurs et des itérations design, plutôt que dans de la transcription manuelle.

Pour la maintenabilité. Le code généré reste maintenable sur le long terme. Architecture token-based, TypeScript strict, tests complets, documentation automatique. Quand un nouveau développeur rejoint le projet, il comprend immédiatement la structure. Pas de dette technique cachée, pas de "quick fixes" accumulés au fil du temps. On a repris un projet client après 6 mois d'inactivité : la reprise a pris 2 heures au lieu des 2 jours habituels.

Pour les projets multi-marques. Si vous pilotez plusieurs marques ou applications partageant un socle commun, un seul design system Figma alimente tous les projets. Les mises à jour se propagent de manière contrôlée via le versioning npm. La cohérence visuelle est garantie par construction, pas par des revues de code manuelles qui ratent toujours des détails.

Où on en est-on aujourd'hui ?

ACSEO applique depuis plusieurs mois cette méthode, qui a été déployée sur plusieurs projets clients avec des design systems de complexité variable. Le projet présenté ici (Button + Card + thèmes) était un cas d'usage volontairement simple pour valider l'approche.

Ce qui fonctionne bien : l'extraction des tokens, la génération des composants atomiques (Button, Input, Card), la gestion des thèmes, et la synchronisation Figma. Les gains de temps sont constants, projet après projet. La qualité du code généré est supérieure à ce qu'on produisait manuellement, notamment sur la couverture de tests qu'on négligeait souvent par manque de temps.

Ce qui reste à améliorer : les composants avec beaucoup de logique métier (formulaires avec validation complexe, tables avec filtres dynamiques) nécessitent encore du travail manuel après génération. On est à 70-80% d'automatisation sur ces cas, contre 95% sur les composants simples. L'objectif est d'atteindre 90% partout d'ici 6 mois.

ACSEO investit dans ces outils pour libérer nos développeurs des tâches répétitives et leur permettre de se concentrer sur l'architecture, l'expérience utilisateur, et les fonctionnalités métier. Les problèmes qui demandent de la réflexion. Si vous passez encore vos journées à copier des codes couleur depuis Figma et à maintenir manuellement la synchronisation entre design et code, vous perdez du temps et de l'argent. Ce temps pourrait être investi sur des fonctionnalités qui apportent de la valeur à vos utilisateurs.

Si vous êtes intéressé par un projet d'automatisation, l'équipe d'ACSEO vous accompagne pour intégrer l'IA dans vos workflows Figma vers React et transformer vos processus de production.