Figma vers React : de la maquette au composant en production, la Factory ACSEO expliquée

Un designer valide une maquette sur Figma. Quelques semaines plus tard, le composant qui arrive en production ne lui ressemble qu’à moitié : un espacement différent, une variante manquante, des tests absents, une documentation à reconstituer a posteriori pour que l’équipe suivante comprenne comment l’utiliser. Ce delta entre ce qui a été validé et ce qui est livré, presque toutes les équipes produit et design l’ont vécu et il coûte cher : des allers-retours de correction, des composants qui divergent d’un Front à l’autre, un design system qui se délite au fil des projets.

Sur le programme de refonte conduit avec un acteur majeur du tourisme, ACSEO a voulu éliminer ce delta à la source plutôt que de le corriger après coup. C’est le rôle de la Factory : un outillage interne qui gère la transition directe de Figma vers React pour produire un composant complet (code, tests, accessibilité et documentation), puis le fait voyager jusqu’en production à travers une chaîne de contrôle qualité automatisée.Cet article déroule une démonstration réelle de la Factory, étape par étape, telle qu’elle s’est produite sur ce programme.

Le problème récurrent : le delta entre la maquette validée et le composant livré

Dans un projet web classique, la distance entre une maquette Figma et un composant en production se traduit par du temps perdu à plusieurs endroits : la retranscription manuelle du design en code, qui introduit presque mécaniquement des écarts (espacements, couleurs, comportements responsives) par rapport à ce qui a été validé ; les tests et la documentation, souvent traités en dernier (quand ils le sont) alors qu’ils sont indispensables pour qu’un composant soit réutilisable en toute confiance par d’autres équipes ; et le contrôle qualité, qui intervient trop tard dans le cycle, une fois le composant déjà intégré, ce qui rend les corrections plus coûteuses qu’elles ne l’auraient été en amont.

Sur un programme qui doit alimenter plusieurs sites Front avec un même design system, ce delta ne se contente pas de ralentir un projet isolé : il se multiplie à chaque Front, à chaque nouvelle évolution. C’est ce constat qui a motivé la construction de la Factory, un outillage qui automatise le passage du design au code livrable, sans sacrifier ni la qualité ni la fidélité visuelle.

Les 4 grandes étapes de la Factory, en démonstration réelle

Pour rendre la mécanique concrète, voici comment s’est déroulée une génération réelle de composant sur le programme, du lien Figma jusqu’à la page en ligne.

1. Conception : la maquette comme unique point de départ

Tout commence, comme pour n’importe quel projet, par une maquette réalisée par l’agence UX/UI sur Figma. La seule information nécessaire pour déclencher la suite est le lien du composant à générer, en s’assurant que son identifiant de nœud (le repère du composant dans l’URL Figma) est bien présent. Rien d’autre n’est demandé au designer : pas de spécification technique supplémentaire, pas de format particulier. La maquette validée est, en elle-même, la source de vérité.

2. Génération : un composant, ses tests et sa documentation produits automatiquement

Ce lien Figma est ensuite transmis à un « skill » de génération de la Factory, une brique dédiée à cette tâche précise, puisée dans une bibliothèque de skills qui couvre les différents besoins de production (génération de composants, mais aussi d’autres automatisations du delivery). À partir de cette seule URL, la Factory génère automatiquement le composant, ses tests unitaires et sa documentation technique.

En quelques minutes, le travail est livré avec un rapport complet : une validation visuelle qui compare le rendu généré à la maquette Figma d’origine, et l’ensemble des fichiers produits, le composant lui-même, ses tests, les vérifications d’accessibilité, et la documentation destinée au registre de composants. Ce rapport est la preuve, consultable par l’équipe, que ce qui a été généré correspond bien à ce qui a été conçu.

3. Intégration Front : visible et testable avant même d’être en ligne

Le composant généré est immédiatement publié sur Storybook, avec sa documentation : props disponibles, variantes, exemples d’usage. Les équipes peuvent le consulter, le tester, l’évaluer visuellement, avant même qu’il soit intégré à une page réelle du site. C’est une étape souvent négligée dans les projets classiques, où un composant n’est visible qu’une fois assemblé dans son contexte final, trop tard pour un retour simple et rapide.

Une fois le composant ajouté sur une branche de travail et prêt à rejoindre le site, l’équipe Front l’intègre sur la page concernée, avec une vérification du rendu en direct (code et prévisualisation côte à côte) pour confirmer que l’intégration respecte le composant tel qu’il a été généré et validé.

4. Mise en ligne : un déploiement automatisé, sans ressaisie

Dès que le code est prêt, le passage en production ne demande plus d’intervention manuelle : les pipelines de contrôle qualité et de déploiement (détaillées ci-dessous) prennent le relais, jusqu’à la mise en ligne finale, par exemple via Vercel, après synchronisation avec le dépôt du site concerné.

Zoom qualité : la pipeline qui vérifie vraiment tout

C’est sans doute l’étape la plus décisive de la Factory, et celle qui distingue une automatisation sérieuse d’un simple gadget de productivité. Une fois le composant ajouté sur une branche de travail, le passage vers la branche de production déclenche une pipeline qui contrôle successivement :

• la qualité du code (conventions, lint, cohérence avec les standards du projet),
• l’audit des dépendances (vulnérabilités, versions obsolètes),
• la performance, via un audit Core Web Vitals réalisé avec Lighthouse.

Sur ce programme, cette dernière vérification n’a rien eu de théorique. Lors d’un déploiement, l’audit de performance a effectivement signalé un point bloquant : un indicateur Core Web Vitals en dessous du seuil attendu, ce qui a empêché la mise en production du composant concerné. Une fois le point corrigé, l’ensemble des contrôles est repassé en revue et a été validé, ce qui a permis au déploiement de se poursuivre normalement.

Cet épisode illustre exactement ce que doit apporter un contrôle qualité automatisé : non pas une case cochée pour la forme, mais un véritable filet de sécurité capable de stopper un déploiement avant qu’il ne dégrade l’expérience utilisateur et donc le référencement naturel et la conversion, deux indicateurs directement sensibles aux Core Web Vitals.

Une fois cette première pipeline validée, une seconde prend le relais : elle re-vérifie les tests, incrémente la version du composant selon les règles du semantic release, puis déploie une nouvelle image de l’application sur le serveur. Chaque composant livré est ainsi versionné de manière traçable, sans intervention manuelle sur le numéro de version.

Résultat : du lien Figma à la page en ligne, sans intervention manuelle

Mis bout à bout, le parcours est le suivant : un lien Figma en entrée, un composant généré avec ses tests et sa documentation, une validation visuelle automatique, une publication sur Storybook, un contrôle qualité en pipeline (code, dépendances, performance), un versionnement sémantique, et un déploiement automatisé, jusqu’à la page en ligne où le composant est visible par l’utilisateur final.

À aucune étape intermédiaire de ce parcours, une intervention manuelle n’est nécessaire pour faire avancer le composant d’une étape à la suivante. Ce qui ne signifie pas une absence de regard humain : les équipes consultent les rapports, valident les résultats sur Storybook, et interviennent précisément là où un signal de qualité l’exige, comme l’a montré l’exemple du déploiement bloqué.

Pourquoi c’est important pour un programme multi-Fronts

Sur un programme qui alimente plusieurs sites Front avec un design system commun, c’est le cas du modèle Plateforme + Fronts que l’on détaille dans cette série, la Factory change la nature du problème de cohérence visuelle. Un composant généré une fois, testé et documenté, devient un actif réutilisable par tous les Fronts du programme, sans ressaisie ni réinterprétation d’une équipe à l’autre.

Cela signifie concrètement qu’un même bouton, une même carte produit ou un même formulaire de recherche ne sont plus recodés à chaque nouveau site, avec le risque de divergence que cela implique. Ils sont générés une fois, à partir d’une maquette validée, puis consommés par chaque Front qui en a besoin — exactement comme la Plateforme mutualise la donnée et les règles métier côté backend. La Factory est, en quelque sorte, l’équivalent côté interface de ce que l’architecture MACH apporte côté architecture.

C’est aussi une garantie de qualité qui se propage automatiquement : chaque nouveau Front hérite des mêmes contrôles de performance et d’accessibilité, sans dépendre de la vigilance individuelle d’une équipe en particulier. Cette approche s’inscrit dans la méthodologie plus large de delivery augmenté à l’IA que l’on présente dans notre article sur l’IA au service du delivery, dont la Factory constitue l’une des applications les plus abouties.

La feuille de route : généraliser la Factory

Cette démonstration a porté sur un composant unique, mais la trajectoire ne s’arrête pas là. Trois chantiers sont d’ores et déjà engagés pour généraliser cette approche :

• Étendre la génération à l’ensemble des composants d’une maquette, et non plus composant par composant, pour accélérer encore la couverture d’un design system complet ;
• Déployer en continu sur l’ensemble des pages d’un site, en s’appuyant sur la même chaîne de contrôle qualité, pour que chaque évolution (composant ou page) suive le même chemin automatisé et vérifié.
• Construire un tableau de bord qualité qui regroupe en un seul endroit les résultats de tests, les indicateurs de performance et les audits de dépendances de l’ensemble des composants et des Fronts du programme, pour donner une vision d’ensemble continue plutôt que des contrôles dispersés.

Demandez une démo de la Factory sur votre propre maquette Figma

La meilleure façon de juger de l’intérêt de la Factory n’est pas de la lire décrite, mais de la voir fonctionner sur un cas concret, le vôtre. Si vous avez une maquette Figma en attente d’intégration, ou un design system que vous cherchez à industrialiser sur plusieurs Fronts, les équipes ACSEO peuvent vous montrer, en direct, le trajet complet du lien Figma jusqu’au composant en production.

Contactez-nous pour une démo de la Factory sur votre propre maquette Figma ! 17 ans d’expertise en delivery digital, une Factory éprouvée en conditions réelles, et un outillage conçu pour transférer la compétence plutôt que créer une nouvelle dépendance.