Lorsque les développeurs recherchent « inspecteur Figma », ils veulent généralement l'une de deux choses : un moyen de voir les valeurs des propriétés sur les nœuds sans avoir de licence Dev Mode, ou un moyen d'alimenter un agent IA avec le contenu Figma. La première catégorie est bien servie par les plugins. La seconde l'est par presque rien — jusqu'à figmascope.
Cet article compare les deux catégories, explique pourquoi elles résolvent des problèmes différents, et montre à quoi ressemble concrètement un export natif pour agents. Rendez-vous sur figmascope.dev pour tester l'export vous-même, ou continuez la lecture pour la comparaison complète. Pour le flux de travail pratique, consultez Figma vers Cursor ou Figma vers Claude Code.
Ce que font réellement les outils « inspecteur Figma »
L'inspecteur Figma classique est le panneau de droite dans l'interface de Figma. Sélectionnez un nœud : voyez son remplissage, son contour, ses effets, ses dimensions, ses contraintes, sa typographie. En Dev Mode (ajouté en 2023), ce panneau propose des extraits de code — propriétés CSS inférées depuis le nœud, mise en page automatique exprimée en flexbox, couleurs avec leurs noms de variables si les Variables sont configurées.
Des plugins comme Inspect, Figma to Code, Anima et des dizaines d'autres étendent encore cette fonctionnalité. Certains génèrent des extraits React ou SwiftUI depuis les nœuds sélectionnés. Certains exportent des fichiers CSS. Certains annotent le canvas pour les revues de passation.
Tous ces outils sont conçus pour un développeur humain qui regarde l'écran. Ils exposent l'information à la demande, nœud par nœud, sélectionné par une personne qui sait quel nœud l'intéresse.
Pourquoi ce modèle ne fonctionne pas pour les agents IA
Un modèle de langage n'est pas assis dans Figma à cliquer sur des nœuds. Il a besoin de la totalité du contexte pertinent dans sa fenêtre de contexte avant de commencer à générer du code. L'inspection nœud par nœud produit des fragments. Ce dont l'agent a besoin, c'est d'un document structuré couvrant l'écran complet : la hiérarchie, les valeurs de tokens, les chaînes, les références de composants — le tout en une seule fois.
Il y a aussi un problème de format. Dev Mode produit des extraits CSS qui sont presque corrects mais pas tout à fait — les noms de propriétés diffèrent selon les frameworks, les propriétés raccourcies nécessitent une expansion, les valeurs en pixels absolus doivent être mappées vers votre système de tokens. Un agent consommant du Dev Mode brut réinventera des noms de tokens, inventera des valeurs d'espacement, et produira du code qui semble avoir été conçu par quelqu'un qui n'a vu votre design qu'une seule fois.
Les outils d'inspection répondent à « qu'est-ce que ce nœud ? ». Les outils pour agents répondent à « qu'est-ce que cet écran entier, dans un format que le modèle peut raisonner ? »
figmascope comme alternative à l'inspecteur Figma
figmascope n'est pas un panneau dans Figma. Il s'exécute dans votre navigateur, communique directement avec l'API REST de Figma, et exporte un bundle de contexte — un zip structuré contenant tout ce dont un agent IA a besoin pour implémenter le design. Le format des tokens est documenté en détail dans Export de tokens de design pour agents IA, et la philosophie générale de passation est traitée dans Passation de design IA.
L'export comprend :
- Un IR de mise en page pour chaque frame, typé et référencé aux tokens, pas un ensemble de CSS brut
- Des tokens de design dans un format JSON stable, pas une liste de valeurs hexadécimales sans noms sémantiques
- Des chaînes d'interface consolidées avec des clés de ressource, pas des valeurs de texte éparpillées
- Des rendus de référence à 2×, afin que l'agent dispose d'une vérité visuelle en parallèle des données
- Un document de spécification
CONTEXT.mdque l'agent lit en premier, qui explique les conventions de nommage des tokens, le périmètre, et toute anomalie
Comparaison directe
| Fonctionnalité | Figma Dev Mode | Plugins d'inspection | figmascope |
|---|---|---|---|
| Valeurs de propriétés d'un seul nœud | Oui | Oui | Non (hors périmètre) |
| Export d'arbre de mise en page complet | Non | Partiel | Oui — screens/*.json |
| Tokens de design typés en JSON | Non | Certains plugins | Oui — tokens.json |
| Document de spécification pour agent IA | Non | Non | Oui — CONTEXT.md |
| Chaînes consolidées avec clés | Non | Non | Oui — strings.json |
| Inventaire des composants | Partiel | Partiel | Oui — components/inventory.json |
| Rendus de référence | Export manuel | Non | Oui — screens/*.png (2×) |
| Inférence de tokens par fréquence | Non | Non | Oui — secours pour fichiers sans Variables |
| Nécessite une licence Figma | Licence Dev Mode requise | Variable | Non — PAT uniquement |
| Confidentialité / sans téléversement | Données traitées par Figma | Variable selon le plugin | Côté client, token vers api.figma.com uniquement |
Figma Dev Mode — ce qu'il fait bien et moins bien
Le panneau de code de Dev Mode est genuinement utile pour les développeurs humains qui ont besoin de lire rapidement une valeur d'espacement ou de vérifier une pile de polices. Son lien avec les Variables est un pas dans la bonne direction — lorsque le fichier Figma utilise correctement les Variables, Dev Mode affiche le nom de la variable à côté de la valeur résolue.
Où il est insuffisant pour les flux IA :
- Pas d'export au niveau du fichier. Vous pouvez lire un nœud ; vous ne pouvez pas exporter une représentation lisible par machine de la hiérarchie complète d'un frame.
- Les extraits CSS sont spécifiques à un framework et souvent incorrects pour les cibles non-web (iOS, Android, React Native).
- Pas de consolidation des chaînes. Les valeurs textuelles sont visibles par nœud mais non agrégées.
- Pas de document de spécification lisible par agent. Les annotations de Dev Mode sont destinées à être lues par des humains dans l'application, pas à être raisonnées par des modèles de langage.
- Nécessite une licence Dev Mode (45 $/éditeur/mois en 2025). figmascope n'a besoin que d'un jeton d'accès personnel, qui est gratuit.
Les plugins d'inspection Figma — panorama
Il existe environ trois catégories de plugins d'inspection Figma :
- Visionneuses de propriétés — reproduisent ce que montre le panneau de droite de Dev Mode, souvent pour les utilisateurs du niveau gratuit n'ayant pas accès à Dev Mode. Exemples : Figma Inspect, Handoff.
- Générateurs de code — produisent du code spécifique à un framework depuis les nœuds sélectionnés. Exemples : Figma to Code, Anima, Locofy. Ils génèrent du code depuis une sélection individuelle, pas un export structuré de fichier complet.
- Exporteurs de tokens — exportent des tokens de design depuis les Variables Figma. Exemples : Tokens Studio (anciennement Figma Tokens), Variables2JSON. Ils résolvent le problème d'export des tokens, mais pas celui de l'IR de mise en page ou de la spécification pour agents.
figmascope n'appartient à aucune de ces catégories. Il est plus proche de la catégorie « exporteur de tokens » dans l'esprit, mais il résout un problème plus large : produire le contexte structuré complet dont un agent IA a besoin pour implémenter correctement un écran entier.
Consultez figmascope vs plugins Figma pour une analyse plus détaillée du paysage des plugins.
Quand utiliser quoi
Ces outils ne sont pas mutuellement exclusifs. Un flux de travail réaliste :
- Utilisez Dev Mode ou un plugin d'inspection lorsque vous êtes un développeur qui vérifie ponctuellement les valeurs d'un nœud spécifique, confirme une décision d'espacement avec le designer, ou vérifie vers quelle variable une couleur se résout.
- Utilisez figmascope lorsque vous passez un écran entier (ou un fichier) à un agent IA pour la génération de code. Lancez-le une fois par jalon de design, validez le bundle dans le dépôt.
La distinction est entre l'inspection synchrone (un humain lit un nœud à la fois) et l'export par lot (l'agent obtient le tableau complet en un seul document structuré).
Le PAT — ce à quoi il accède, ce à quoi il n'accède pas
figmascope utilise un jeton d'accès personnel Figma pour lire le fichier via l'API REST. Le jeton est saisi dans votre navigateur, réside en mémoire navigateur pour la session, et n'est envoyé qu'en tant qu'en-tête à api.figma.com. Aucun serveur ne le reçoit. Lorsque vous fermez l'onglet, il disparaît.
La portée minimale requise est Contenu des fichiers : lecture seule. figmascope n'écrit pas dans Figma, ne crée pas de commentaires, n'accède pas aux fichiers d'équipe au-delà de ce que le jeton est autorisé à lire. Consultez Sécurité du PAT et figmascope pour le modèle de menace complet.
À quoi ressemble la sortie dans un vrai projet
Après l'export, le bundle de contexte réside aux côtés de votre code source :
myapp/
├── src/
│ ├── screens/
│ └── components/
├── design/
│ ├── CONTEXT.md ← l'agent lit ceci en premier
│ ├── tokens.json ← tokens de design typés
│ ├── _meta.json ← manifeste d'export, avertissements
│ ├── components/
│ │ └── inventory.json ← noms + ids canoniques des composants
│ ├── screens/
│ │ ├── Home.json ← IR de mise en page
│ │ ├── Home.png ← rendu 2×
│ │ ├── Profile.json
│ │ └── Profile.png
│ └── strings.json ← tout le texte d'interface, clés en notation pointée
└── package.json
C'est l'artefact que vous validez, référencez dans CLAUDE.md ou .cursorrules, et vers lequel vous pointez votre agent. Un seul export, tout le contexte nécessaire.
Comparez cela avec un flux d'inspection classique : le développeur ouvre Figma, clique sur des nœuds un par un, copie les valeurs dans le code, manque un nom de variable, se trompe d'espacement sur le padding mobile, passe vingt minutes à réconcilier le design et l'implémentation. L'export structuré supprime entièrement cette boucle lorsqu'un agent effectue l'implémentation.
Référencer le bundle dans la configuration IA de votre projet
Claude Code lit CLAUDE.md au démarrage de la session. Cursor lit .cursorrules. Les deux supportent un fichier d'instructions au niveau du projet qui oriente l'IA avant qu'elle ne fasse quoi que ce soit. Ajoutez une courte section design pointant vers votre répertoire design/ :
# For CLAUDE.md (Claude Code)
## Design context
All design data is in `design/`. Before implementing any UI:
1. Read `design/CONTEXT.md` for scope and token conventions
2. Use `design/tokens.json` for all color, spacing, radius, and typography values
3. Use `design/components/inventory.json` for canonical component names
4. Use `design/strings.json` for all UI copy — reference by dot-notation key
5. Validate against `design/screens/*.png` renders
# For .cursorrules (Cursor)
Always read design/CONTEXT.md before implementing UI.
Token values are in design/tokens.json — never hardcode colors or spacing.
Component names come from design/components/inventory.json.
UI strings come from design/strings.json with dot-notation keys.
Avec ces fichiers en place, chaque session d'agent dans le projet sait automatiquement que le répertoire design existe et comment l'utiliser — aucune répétition dans les prompts n'est nécessaire.
L'alternative MCP — et pourquoi ce n'est pas la même chose
Le serveur Model Context Protocol (MCP) propre à Figma permet à une IA de se connecter directement à l'API Figma et d'interroger des nœuds à la demande. C'est utile pour le travail exploratoire — demander « quelle est la couleur de ce bouton ? » dans une conversation en direct. Cela ne produit pas d'artefact reproductible et versionné. À chaque exécution de l'agent, il relit le fichier Figma en direct, qui peut avoir changé. Il n'y a pas de CONTEXT.md qui explique le périmètre. Il n'y a pas de dictionnaire de tokens pré-généré avec des noms stables. Il n'y a pas de système d'avertissement pour les mises en page anormales.
figmascope et Figma MCP résolvent des problèmes différents. MCP est en ligne, en direct, et bon pour l'exploration interactive. figmascope produit un artefact hors ligne, versionné, structuré, adapté à la génération de code déterministe au moment de l'implémentation. Consultez figmascope vs Figma MCP pour la comparaison détaillée, et explorez le blog figmascope pour des analyses approfondies des flux de travail de design IA.