figmascope vs Plugins Figma
Runtime de plugin ou export navigateur ?

L'écosystème de plugins Figma est vaste. Il existe des plugins pour l'export de tokens, l'annotation de code, les guides de style, les vérifications d'accessibilité et la génération de code. Quand quelqu'un dit « outil Figma-vers-code », il pense presque toujours à un plugin. figmascope n'est pas un plugin. Voici pourquoi cela importe et quand ça ne l'est pas.

Le modèle plugin

Les plugins Figma s'exécutent dans un iframe sandbox à l'intérieur de l'application Figma desktop ou web. Ils accèdent à l'API plugin Figma — une interface JavaScript qui expose l'arbre de nœuds du fichier courant, les styles, les composants et les variables. Le plugin peut lire ces données, les transformer, et écrire les résultats dans le fichier ou exporter des fichiers vers le système local de l'utilisateur via la boîte de dialogue de sauvegarde de Figma.

L'API plugin est riche. Vous pouvez traverser chaque nœud, lire les styles calculés, accéder aux définitions de composants, interroger les variables, et même faire des requêtes réseau depuis la couche UI du plugin. Pour la plupart des tâches de type « lire les données de design et en faire quelque chose », l'API plugin est suffisante.

Les plugins sont distribués via le store Figma Community ou comme plugins d'équipe privés. Les utilisateurs les installent via l'interface Figma. Les mises à jour arrivent par l'hébergement de plugins de Figma. Le compte développeur qui a publié le plugin peut pousser des mises à jour ; les utilisateurs les reçoivent la prochaine fois qu'ils exécutent le plugin.

Plugins Figma-vers-code populaires : Locofy (couvert dans la comparaison Locofy), Tokens Studio (sync de tokens de design), Figma to Code (open source Flutter/SwiftUI/Jetpack Compose), et des dizaines d'outils plus spécialisés.

Limites des plugins

Fonctionne uniquement dans Figma. Pour exécuter un plugin, vous ouvrez Figma, ouvrez le fichier, ouvrez le plugin, déclenchez l'export. Le plugin ne peut pas être appelé depuis un terminal, un job CI, un script, ou tout contexte en dehors de l'application Figma. Pas de CLI. Pas d'API à appeler. Tout le contexte d'exécution est l'UI Figma.

Exécution uniquement au runtime. Les plugins ne s'exécutent pas en arrière-plan. Ils s'exécutent quand un humain les ouvre et clique sur le bouton. Les exports planifiés, les pipelines automatisés et l'intégration programmatique ne sont pas possibles via le modèle plugin.

Gardiens du store de plugins. Publier un plugin Figma public nécessite la révision et l'approbation de Figma. Les mises à jour nécessitent une nouvelle révision. Si Figma change sa politique de révision ou décide qu'un plugin entre en conflit avec ses intérêts, le plugin peut être retiré ou restreint. Les plugins d'équipe privés contournent le store mais s'exécutent toujours dans le sandbox de Figma et dépendent de l'infrastructure de plugins de Figma.

Contraintes de ressources. Le sandbox de plugin est limité en mémoire et en temps d'exécution. Les grands fichiers Figma avec des hiérarchies complexes peuvent atteindre des timeouts ou faire planter le plugin. L'UI du plugin s'exécute dans un iframe avec un accès restreint — pas d'accès au système de fichiers local sauf via la boîte de dialogue d'export de Figma, pas d'accès réseau arbitraire depuis le thread principal.

Incohérences cross-platform. L'application Figma desktop et l'application web ont un comportement API plugin légèrement différent dans certains cas limites. Des plugins qui fonctionnent parfaitement dans l'une peuvent avoir des comportements étranges dans l'autre.

Friction d'installation pour la distribution d'équipe. Chaque développeur qui a besoin d'exécuter le plugin l'installe séparément. La cohérence des versions au sein d'une équipe dépend du mécanisme de mise à jour automatique de Figma. Si vous avez besoin d'une version spécifique épinglée, ce n'est pas simple.

L'approche externe de figmascope

figmascope ne touche pas du tout au système de plugins. Il s'exécute dans un onglet de navigateur standard — n'importe quel navigateur, pas besoin de l'app Figma — et appelle l'API REST Figma directement en utilisant un Personal Access Token fourni par l'utilisateur. Le PAT est conservé en mémoire uniquement, jamais envoyé à un serveur.

L'API REST Figma est la même source de données que celle exploitée par l'API plugin, mais accédée en externe. figmascope récupère le JSON du fichier, traite l'arbre de nœuds côté client (tout le calcul se passe dans votre navigateur), et produit le bundle de contexte. Les appels API vont directement de votre navigateur vers les serveurs de Figma. La propre infrastructure de figmascope n'est pas dans le chemin des données. Votre PAT est en mémoire et est effacé quand vous fermez l'onglet.

Cela a plusieurs implications :

Pas d'installation. Ouvrez un onglet, collez votre URL Figma et votre PAT, cliquez sur exporter. Rien à installer, pas de compte à créer, pas de plugin à trouver dans le store Community. N'importe qui avec un navigateur peut l'utiliser — y compris des développeurs qui ne sont pas utilisateurs de Figma et n'ont pas l'app installée.

Scriptable en principe. Parce que figmascope est construit sur l'API REST, les mêmes appels qu'il effectue peuvent être reproduits programmatiquement. Le code source MIT est ouvert à l'inspection. Si vous voulez construire un script qui exporte un bundle depuis la ligne de commande sans ouvrir un navigateur, le code source de figmascope vous montre exactement comment appeler l'API et traiter la réponse.

Compatible CI/CD en principe. Un pipeline d'export headless est réalisable : appels API REST Figma, même logique de traitement IR, même format de bundle. L'application navigateur de figmascope ne s'exécute pas directement en CI (c'est un outil navigateur), mais l'approche architecturale — API REST, traitement déterministe, sortie de fichiers simples — est conçue pour être CI-friendly. Rien dans le modèle ne nécessite une interface graphique.

Pas de dépendance au store de plugins. figmascope est hébergé sur un domaine, open source sur GitHub. Il ne dépend pas de l'infrastructure de plugins de Figma ni de son processus de révision. Figma ne peut pas le retirer d'un store. Si le domaine tombe, vous pouvez l'exécuter localement depuis le dépôt — c'est entièrement du HTML/JS statique.

Pas besoin de l'app Figma. Un développeur peut exporter le contexte pour un fichier Figma qu'il n'a jamais ouvert dans l'app Figma, en utilisant uniquement une URL Figma partagée et un PAT. Cela importe pour les workflows où les ingénieurs n'utilisent pas Figma directement mais ont besoin de la spec de design.

Ce que les plugins font mieux

Soyons honnêtes. Les plugins ont de vrais avantages que l'approche API externe ne réplique pas.

Annotation in-canvas. Les plugins peuvent écrire dans le fichier Figma — ajouter des annotations, définir des propriétés de composants, marquer des frames comme prêtes, poster des commentaires. figmascope est en lecture seule. Si vous avez besoin d'un outil qui fait du travail côté design dans Figma, vous avez besoin d'un plugin.

Contexte de canevas en direct. Un plugin sait ce qui est sélectionné. Il peut répondre aux changements de sélection, surveiller les mises à jour de nœuds, et réagir au travail de design en cours. figmascope prend un instantané. Il n'a pas accès au canevas en direct.

Distribution d'équipe via l'org Figma. Si toute votre équipe est sur un plan Figma org, pousser un plugin privé vers l'équipe est simple. Tout le monde l'a dans son instance Figma. Pour la distribution cross-équipe au sein d'une org, le modèle plugin est bien supporté.

Interaction plus riche dans l'UI Figma. Un plugin peut rendre une UI personnalisée dans un panneau, répondre aux interactions utilisateur, et fournir un retour immédiat dans le workflow existant du designer. L'interface de figmascope est un onglet navigateur séparé — un changement de contexte.

Comparaison

L'angle confidentialité des données

Quand un plugin Figma fait des requêtes réseau, vos données de design peuvent quitter votre navigateur et aller vers les serveurs du vendeur du plugin. Vous faites confiance à la politique de confidentialité et à l'infrastructure du plugin. Pour de nombreuses équipes, c'est acceptable. Pour certaines — équipes enterprise avec des designs couverts par des NDA, agences travaillant avec des fichiers clients sensibles — c'est une préoccupation significative.

L'approche externe de figmascope est différente. Tout le traitement se passe dans votre onglet navigateur. Les appels API REST vont de votre navigateur vers les serveurs de Figma (les mêmes appels que fait votre navigateur quand vous utilisez Figma normalement). Les propres serveurs de figmascope ne sont pas dans le chemin. Vos données de design ne vont nulle part sauf vers l'API de Figma.

C'est un avantage structurel de l'approche navigateur externe par rapport aux plugins qui dépendent d'un vendeur backend.

Quand choisir lequel

Utilisez un plugin Figma quand : vous avez besoin d'annoter ou d'écrire dans le fichier, vous voulez une interaction in-canvas dans le cadre d'un workflow designer, votre équipe est entièrement sur Figma et la distribution via le mécanisme de plugin est pratique, ou le plugin dont vous avez besoin a une UI in-Figma spécifique que l'approche API REST ne peut pas répliquer.

Utilisez figmascope quand : vous avez besoin d'un bundle de contexte portable et versionné pour la génération de code par agents IA, vous voulez pas d'installation et pas de dépendance au store, vous vous souciez de la confidentialité des données et ne voulez pas que les données de design soient envoyées à un vendeur de plugin tiers, vous voulez que la sortie vive dans votre dépôt git aux côtés de votre code, ou vous voulez que le processus d'export soit explicable et reproductible.

Pour la plupart des workflows de génération de code UI en production avec des agents IA, le modèle plugin ajoute une friction qu'il ne peut pas compenser. Le plugin s'exécute dans Figma. L'agent s'exécute dans votre éditeur. Faire passer la spec de design de l'un à l'autre via un plugin nécessite soit un copier-coller manuel, soit un plugin qui écrit sur disque — et alors vous avez un fichier opaque issu d'un pipeline opaque. La sortie de figmascope est inspectable, structurée, et explicitement conçue pour cette passation à l'agent.