Test mené le 31 juillet 2026 sur une maquette publique de la communauté Figma, que chacun peut reprendre
On me demande souvent si on peut générer un site à partir d’une maquette Figma. La réponse qui circule est “70 % automatique, 30 % à la main”. C’est l’argument commercial d’Anima, repris depuis dans des articles qui ne disent jamais ce qu’ils ont mesuré
Locofy affiche dans son propre plugin une phrase plus utile : “A well structured design file can save you 70-80 % of your time compared to poorly structured design”. Autrement dit, la qualité de la maquette pèse autant que l’outil. J’ai donc pris une maquette très propre, un seul bloc, et j’ai comparé trois façons d’en tirer du code avec les mêmes critères
Résultat : l’écart entre le meilleur et le pire rendu vient surtout des consignes que j’ai données à l’agent, pas du modèle
Le protocole
La maquette : Launch UI, une template gratuite de la communauté Figma. Composants, auto layout, variables, styles nommés
Le bloc : le hero. Un badge, un titre, un sous-titre, deux boutons, une illustration
Les trois méthodes :
- Locofy, un plugin Figma qui convertit la maquette en HTML/CSS. Propriétaire, payant, avec un essai gratuit
- Le serveur MCP officiel de Figma branché sur Claude Code. Il ne convertit rien lui-même, il fournit du contexte à l’agent qui écrit le code
- Silex, l’éditeur visuel que je développe, qui s’appuie sur le même agent
Les critères, fixés avant de commencer : fidélité au rendu mesurée au pixel, responsive aux largeurs des variantes dessinées dans le fichier, nombre d’erreurs au validateur du W3C, qualité du CSS lue comme en revue de code
Je n’ai pas mesuré le temps passé. Je juge uniquement ce qui sort
Les résultats
| Locofy | MCP officiel, sortie brute | Claude Code piloté | |
|---|---|---|---|
| Fidélité | fidèle sur le texte, l’illustration n’est pas dans l’export | non évaluable | moins de 4 px d’écart, mobile compris |
| Responsive | aucune media query dans 180 lignes de CSS | aucune classe de palier | les trois variantes appliquées |
| HTML (W3C) | 6 erreurs | non validable en l’état | 0 erreur |
| CSS | classes nommées d’après le texte du titre | non livrable | correct, avec réserves |
Silex n’apparaît pas dans le tableau : il utilise le même agent, donc il produit le même code. Sa différence porte sur ce qui se passe après, j’y reviens plus bas
Locofy, en largeur desktop, est fidèle sur la partie texte : badge, titre coupé au même endroit que dans la maquette, sous-titre, boutons. Balises sémantiques, flexbox, variables du design system conservées
Le reste pose problème. En mobile, le titre déborde des deux côtés : sa largeur est fixée en dur et les 180 lignes de CSS ne contiennent aucune media query. L’illustration manque à l’export. Le validateur du W3C renvoie 6 erreurs : pas de balise title, deux div dans des button, trois liens imbriqués dans des boutons. Conséquence concrète : au clavier, la tabulation s’arrête deux fois sur le même élément, et un lecteur d’écran annonce “bouton” puis “lien” pour la même action
Deux points que le validateur ne voit pas : un appel à Google Fonts, qui transmet l’IP de chaque visiteur à Google (une pratique condamnée par un tribunal allemand en 2022), et un window.open vers le site de l’auteur de la template, reliquat d’un lien de prototypage. La police était déjà déclarée en variable dans le même fichier
La sortie brute du MCP n’est pas faite pour être livrée, et Figma le précise dans chaque réponse de l’outil : “The generated React+Tailwind code MUST be converted to match the target project’s technology stack and styling system”. C’est une matière première pour l’agent, pas un résultat à comparer à Locofy
Limite de ce test : je n’ai pas essayé l’Agent Mode de Locofy, qui propose justement de corriger le responsive après coup en langage naturel
Ce qui a fait la différence : trois consignes à l’agent
Claude Code piloté l’emporte sur les quatre critères avec le même modèle que la sortie brute. Ce qui change, ce sont trois consignes que je lui ai données
1. Lire les données dans l’API REST de Figma
Le responsive est déjà dessiné dans la maquette, en trois variantes :
| Desktop | Tablet | Mobile | |
|---|---|---|---|
| Largeur | 1312 | 1024 | 393 |
| Taille du titre | 96 px | 72 px | 36 px |
| Padding horizontal | 32 | 32 | 16 |
Ni le plugin ni le MCP officiel ne transmettent ces trois paliers. J’ai demandé à l’agent d’aller les lire dans l’API REST de Figma, et il les a appliqués au pixel près. L’information était dans le fichier, il suffisait d’aller la chercher
L’API REST donne l’arbre complet du fichier, les identifiants réels des calques et les variantes, là où le MCP en omet une partie. Elle est gratuite et sans quota mensuel. Le MCP officiel est limité à 6 appels par mois sur un plan Starter, et aussi pour un siège View ou Collab sur un plan payant. Avec un siège Dev, c’est 200 par jour sur Professional ou Organization, 600 sur Enterprise (vérifié le 7 septembre 2026)
Trois de mes appels sont partis à chercher un identifiant de calque. Le node-id affiché dans la barre d’adresse de Figma ne désigne pas le calque sélectionné mais le frame parent, et le MCP renvoie alors plus de 100 Ko tronqués sans avertissement
2. Faire vérifier le rendu par l’agent
C’est cette consigne qui fait passer de 6 erreurs à 0
Je demande à l’agent d’ouvrir un navigateur après chaque modification, de faire une capture de son rendu, de la comparer à la capture de référence, de mesurer l’écart et de corriger le CSS, puis de recommencer
Il juge ainsi son travail sur le rendu et non sur son code. C’est comme ça qu’il a repéré seul deux défauts : le titre qui disparaît là où le dégradé de texte ne s’applique pas, et le halo de l’illustration qui déborde du bloc. Locofy et la sortie brute du MCP ne regardent jamais ce qu’ils produisent
3. Donner un critère d’arrêt chiffré
Sans critère, l’agent s’arrête quand il estime que c’est bon. Je lui ai donné des conditions mesurables : zéro erreur au validateur, un écart maximum contre la référence, et le rendu vérifié aux trois largeurs
Ce que ça coûte
L’agent a eu besoin de 7 tours de boucle (modifier, servir, capturer, mesurer, corriger) pour converger. Deux ont été perdus :
- un problème de police qui n’existait pas : la bonne police était appliquée depuis le début, un cache de feuille de style faussait la capture
- une fausse mesure de 10 % d’écart partout, qui a failli faire corriger un CSS juste. La capture de référence avait une marge autour du bloc, et comparer deux images sur leur largeur totale n’avait pas de sens. Il faut caler la mesure sur un repère commun aux deux images
7 tours pour un seul bloc, c’est le chiffre à retenir si vous pensez passer un site entier à la même méthode. Chaque tour mobilise un gros modèle généraliste pour une tâche étroite : comparer deux images, réécrire du CSS. L’impact environnemental n’est pas acceptable, et le coût deviendrait vite prohibitif à l’échelle d’un site
D’où une question, que je creuse avec des mesures : un modèle plus petit, spécialisé, éventuellement local, suffirait-il pour ce type de tâche ?
Après la génération, la correction
Même avec un code généré parfait, le travail continue : changer un texte et voir comment le titre passe sur trois lignes, déplacer un bouton, vérifier un contraste, brancher les contenus sur un CMS, reprendre quand le client change d’avis
Avec un agent, chaque retouche passe par une description en mots, puis une modification du fichier, puis une vérification. Mes deux tours perdus viennent de ce détour
Dans un éditeur visuel comme Silex, on voit le défaut sur la page et on le corrige à la souris. Le code de départ est le même puisque l’agent est le même. Ce qui change, c’est qu’on peut ajuster un padding sans écrire de prompt ni ouvrir de fichier, et sans être développeur
Les deux se complètent : l’agent pour lire le fichier Figma, comprendre les trois variantes et écrire un CSS structuré, l’éditeur visuel pour les ajustements qui suivent
Limites du test
Un seul bloc, une maquette très bien construite, un site statique. Sur un fichier sans composants ni variables, les trois méthodes feraient moins bien, et l’écart entre elles serait sans doute plus grand. Je n’ai testé ni l’Agent Mode de Locofy, ni une page entière, ni une application
Pour refaire le test, la template Launch UI est publique dans la communauté Figma. Il faut un token Figma (Settings, Security, Personal access tokens, scope File content: Read-only) que vous donnez à l’agent, et les trois consignes ci-dessus
Si le quota du MCP officiel vous bloque, Figma-Context-MCP est un serveur MCP libre (licence MIT) qui passe par la même API REST, sans quota. Au 7 septembre 2026, sa dernière version date du 18 juin et 73 des 96 commits de l’année viennent d’une seule personne : à vérifier avant un usage en production
Vous avez des maquettes à transformer en sites, ou une équipe à outiller sur ce type de chaîne : parlons-en