Locofy fait la chose évidente : prendre un fichier Figma, produire du React. C'est le premier réflexe naturel. Designs en entrée, code en sortie. Pourquoi réfléchir davantage ?
Voici la réponse honnête : pour certains workflows, vous ne devriez pas réfléchir davantage. Locofy est rapide et concret. Mais le modèle a des limites qui s'accumulent au fur et à mesure que votre codebase grandit. figmascope prend un pari différent — livrer de la structure, laisser l'agent gérer la génération de code. Que ce pari soit payant dépend de ce que vous construisez et de qui le construit.
Ce que fait Locofy
Locofy est un plugin Figma (également disponible en application standalone) qui convertit les designs Figma en code React, Next.js, Vue, HTML/CSS ou Tailwind quasi-prêt pour la production. Vous installez le plugin, étiquetez vos calques avec des annotations Locofy (marquez ce qui est un input, un bouton, un conteneur), lancez l'export, et obtenez des fichiers de composants que vous pouvez coller dans un projet.
Il supporte les breakpoints responsifs, les états d'interaction de base, et une certaine gestion des assets. La sortie est censée être un point de départ, pas du code final — mais pour des pages marketing simples ou des sections de landing, il peut vous amener à 60-80% sans toucher un éditeur de texte.
Locofy a un tier gratuit avec des exports limités et des plans payants pour un volume plus élevé et des fonctionnalités d'équipe. Le plugin lui-même nécessite une installation via la Figma Community et s'exécute dans le runtime de plugin sandbox de Figma.
Là où Locofy l'emporte
Pas d'agent requis. Vous n'avez pas besoin de Claude, Cursor, ou d'assistant de code IA. La conversion est autonome dans le plugin Locofy. Pour un designer qui veut livrer une landing page sans impliquer un développeur du tout, Locofy peut combler cet écart.
Première sortie rapide. Pour des mises en page simples avec peu de composants, Locofy produit du code utilisable en quelques minutes. Si vous prototypez ou produisez des pages marketing jetables, la rapidité est réelle.
Structure opiniâtre. Locofy prend des décisions pour vous : voici votre arbre de composants, voici comment les props sont nommées. Cette opinionation est une fonctionnalité quand vous ne voulez pas prendre ces décisions vous-même.
Sortie framework-aware. Le code cible directement votre stack. Vous n'obtenez pas du JSON générique que vous devez ensuite interpréter — vous obtenez un fichier .tsx avec des instructions d'import, des hooks scaffoldés, et des classes CSS modules ou Tailwind déjà appliquées.
Là où Locofy perd
One-shot, pas itératif. Locofy produit un instantané. Quand le design change — et les designs changent toujours — vous relancez le plugin et réconciliez la nouvelle sortie avec votre codebase existant. Pas de modèle de diff. Vous fusionnez la sortie machine contre la sortie humaine à la main, ce qui devient vite coûteux.
Verrouillé aux opinions de Locofy. Le choix de framework, les conventions de nommage des composants, les signatures de props — tout cela vient du modèle de Locofy, pas des conventions de votre codebase. Si vous avez un système de design avec des APIs de composants spécifiques, Locofy n'en sait rien. Il génère les siennes. Vous passez du temps à réconcilier le monde Locofy avec votre-codebase-monde.
Dépendance au plugin. Chaque développeur qui veut lancer un export a besoin du plugin installé, d'un compte Locofy, et d'un accès au fichier Figma. Ça ne s'intègre pas dans un workflow CLI, un pipeline CI, ou l'environnement d'un non-utilisateur de Figma.
Surcharge d'annotation. Obtenir de bons résultats de Locofy nécessite que les designers ajoutent des tags spécifiques à Locofy aux calques. C'est de la dette d'outillage : les annotations doivent être maintenues, elles ajoutent du bruit au fichier Figma, et elles ne signifient rien en dehors de Locofy.
Boîte noire. La logique de génération de code est propriétaire. Quand la sortie est incorrecte — et parfois elle l'est — vous ne pouvez pas voir pourquoi. Vous ajustez les noms de calques, relancez, espérez. Il n'y a pas de représentation intermédiaire que vous pouvez inspecter ou auditer.
L'angle différent de figmascope
figmascope ne génère pas de code. Il génère du contexte.
Le bundle — CONTEXT.md, tokens.json, screens/*.json, components/inventory.json, strings.json — décrit le design précisément et laisse votre agent de choix faire la génération de code. Cet agent connaît votre codebase, vos APIs de composants, vos conventions de nommage, vos patterns de tests. Locofy ne connaît rien de tout ça. Votre agent si, parce qu'il a lu votre code.
La représentation intermédiaire dans screens/*.json capture la sémantique de mise en page : stack vs. absolute vs. overlay, identité des composants via componentId sur les nœuds INSTANCE, et chaînes textuelles via stringRef.key. Quand vous dites à Claude Code « implémente cet écran en utilisant nos composants Button et Input existants », il dispose de la structure spatiale, des références de composants et des noms de tokens pour faire ça correctement. Il n'infère pas depuis une capture d'écran — il lit une spec.
La source des tokens est en cascade : les variables Figma d'abord (si le système de design est câblé), inférées par fréquence ensuite (figmascope regarde quelles valeurs se répètent et les promeut), aucune si ni l'un ni l'autre ne s'applique. La sortie tokens.json est typée et lisible par machine. Un agent peut chercher color.surface.brand directement plutôt que de parser une capture d'écran pour une valeur hexadécimale.
Ce modèle est aussi itératif. Quand le design change, vous ré-exportez le bundle et committez la nouvelle version. Le diff dans tokens.json ou screens/login.json vous dit exactement ce qui a changé. Vous donnez le diff à l'agent : « tokens.json a changé — le border-radius est passé de 8px à 6px sur tous les éléments interactifs — mettez à jour les composants affectés. » C'est un workflow ciblé et diffable. Il ne nécessite pas de réconcilier deux ensembles de fichiers de composants générés.
Pourquoi « structure pour un agent » bat « code depuis un plugin » en 2026 pour de nombreuses équipes
La prémisse derrière Locofy — et les outils similaires — est que la génération de code depuis le design est un problème résolu ou presque. Générez le code, corrigez-le, livrez-le. Ça fonctionnait mieux quand l'étape de correction était peu coûteuse.
La réalité en 2026 : votre agent de code IA est très bon pour écrire du code idiomatique dans votre codebase s'il dispose d'un bon contexte. Il est mauvais pour réconcilier sa propre sortie avec celle de Locofy quand elles entrent en conflit. Donner à votre agent un contexte structuré et inspectable et le laisser faire la génération de code complète — dans vos conventions, contre vos composants — produit moins de travail de réconciliation, pas plus.
La sortie de Locofy est aussi framework-final. Une fois que vous avez un composant JSX de Locofy, vous éditez du JSX. La sortie de figmascope est framework-neutre. Le même bundle fonctionne avec Claude Code écrivant du React, Aider écrivant du Vue, ou Cursor écrivant des Web Components. L'agent choisit l'idiome. Le contexte reste constant.
Comparaison
| Dimension | Locofy | figmascope |
|---|---|---|
| Type de sortie | Fichiers de code React / Vue / HTML/CSS / Tailwind | Bundle de contexte : CONTEXT.md, tokens.json, screens/*.json, *.png |
| Nécessite un agent | Non | Oui — le bundle est l'entrée d'un agent IA |
| Opinionation framework | Élevée — la sortie cible un framework spécifique | Aucune — l'agent choisit le framework |
| Connaît votre codebase | Non | Votre agent le fait |
| Workflow itératif | Difficile — ré-export + réconciliation manuelle | Oui — les diffs de bundle sont structurés et inspectables |
| Surcharge d'annotation | Oui — tags de calques Locofy requis pour une bonne sortie | Non |
| Contrôle de version | Non (code généré uniquement) | Oui — bundle diffable et commitable |
| Open source / autonome | Non — SaaS propriétaire | MIT, s'exécute entièrement dans le navigateur |
| Installation de plugin requise | Oui | Non |
| Tarification | Tier gratuit + plans payants | Gratuit, pas de compte requis |
| Conscience des tokens / système de design | Partielle — mappe les styles Figma | Complète — tokens.json avec valeurs typées et sourcing de secours |
| Clés de chaînes i18n | Non | Oui — stringRef.key dans l'IR + strings.json |
Quand Locofy est le bon choix
Soyons honnêtes : Locofy mérite sa place pour les designers non-codeurs qui livrent des pages marketing, des sections de landing, ou des prototypes jetables. Si vous n'avez pas de configuration d'agent IA, n'en voulez pas, et avez juste besoin d'un fichier React à remettre à un prestataire — Locofy fait ce travail. Le code est médiocre mais il existe, et un code médiocre que vous pouvez livrer vaut mieux qu'un contexte parfait sur lequel votre équipe ne peut pas agir.
C'est aussi genuinement utile pour la validation rapide de maquettes : « est-ce que cette mise en page produit du markup sensé ? » Lancez Locofy, regardez la sortie, jetez-la. Retour rapide sans configurer un workflow d'agent complet.
figmascope est le meilleur choix quand vous construisez de l'UI de production avec un codebase existant, un système de design avec de vrais tokens, et un agent de code IA dans la boucle. Le bundle donne à l'agent la précision dont il a besoin pour écrire du code qui s'adapte à votre projet — pas du boilerplate générique qu'il doit réécrire.