figmascope vs Figma MCP
Connexion serveur ou fichiers simples ?

MCP — Model Context Protocol — permet aux agents IA de faire des appels d'outils au runtime vers des services externes. Figma fournit un serveur MCP officiel, et la communauté en a construit plusieurs autres. L'argument : votre agent peut demander des données de design à Figma directement, à la demande, en pleine conversation. Pas d'étape d'export. Toujours en direct.

figmascope prend le pari architectural opposé : exporter une fois, livrer un bundle, ne plus jamais se connecter. Ce sont des choix genuinement différents avec des implications différentes. Voici ce que chacun coûte et gagne réellement.

Ce qu'est le serveur MCP de Figma

Model Context Protocol est le standard ouvert d'Anthropic pour connecter des agents IA à des outils externes via une interface serveur. Un serveur MCP expose des outils typés que l'agent peut appeler : « get_file », « get_node », « get_styles », et ainsi de suite. Quand l'agent a besoin de contexte design, il appelle l'outil, le serveur MCP appelle l'API Figma, et le résultat revient comme contexte pour la requête courante.

Le serveur MCP officiel de Figma couvre la lecture de fichiers, l'inspection de nœuds, la récupération de composants et l'accès aux commentaires. Les serveurs MCP communautaires (il en existe plusieurs sur GitHub) étendent cela avec des schémas personnalisés, des transformations supplémentaires, ou des périmètres plus étroits optimisés pour des workflows d'agents spécifiques.

Pour utiliser n'importe quel serveur MCP Figma, vous le configurez dans votre client agent (Claude Desktop, Cursor, Continue, etc.), fournissez un PAT Figma, et le serveur s'exécute comme un processus local. Quand votre agent a besoin du contexte Figma, il appelle l'outil. Vous n'exportez rien explicitement — l'agent récupère ce dont il a besoin quand il en a besoin.

Le modèle MCP en pratique

Un workflow Figma typique alimenté par MCP ressemble à ceci : vous ouvrez Cursor, démarrez une conversation, dites « implémente l'écran de paiement depuis ce fichier Figma », et l'agent appelle get_file, tire l'arbre de nœuds, et dispose des données de design en contexte. Si vous dites ensuite « le designer a mis à jour les tokens du bouton », l'agent peut rappeler et obtenir des données fraîches.

Ce modèle de connexion en direct est réel et convaincant pour certains workflows. L'agent travaille avec des données courantes. Vous ne gérez pas d'artefacts d'export. Il n'y a pas d'étape manuelle entre « le designer a poussé un changement » et « l'agent l'a ».

Là où MCP l'emporte

Données en direct, pas d'étape d'export. L'agent récupère l'état courant à la demande. Si le design a changé il y a dix minutes, l'agent peut le voir. figmascope nécessite un ré-export manuel pour capturer les changements.

Exploration de design conversationnelle. « Quelle est la couleur du bouton CTA ? » « Combien d'écrans référencent ce composant ? » Avec MCP, un agent peut répondre en appelant Figma. Avec un bundle, la réponse n'est fraîche qu'au moment du dernier export.

Édition directe de Figma. Certains serveurs MCP exposent des opérations d'écriture — créer des nœuds, mettre à jour des propriétés, poster des commentaires. C'est uniquement possible avec une connexion en direct. Un bundle statique n'a pas de chemin d'écriture.

Pas de workflow manuel. Pour les développeurs qui utilisent déjà des configurations d'agents connectés par MCP, pas d'étape d'export signifie une chose de moins à oublier. La gestion du contexte est déléguée à l'agent.

Là où MCP perd

Le modèle de connexion en direct a des coûts architecturaux qui sont faciles à sous-estimer.

État lié à la session. Les appels MCP se produisent dans le contexte d'une session de conversation. Les données que l'agent a récupérées dans la session A ne sont pas disponibles dans la session B sans re-fetch. Si vous démarrez un nouveau chat, l'agent repart de zéro. Un bundle figmascope persiste entre les sessions, entre les développeurs, et entre les outils — ce sont juste des fichiers.

Opaque pour git. Il n'y a pas d'artefact. Rien à committer. Le contexte de design qui a informé votre code ne vit pas dans le dépôt. Dans six mois, si vous voulez comprendre à quoi ressemblait le design quand un composant a été construit, il n'y a aucun enregistrement. Avec un bundle dans le dépôt, vous avez un historique de commits de l'intention de design.

Nécessite une connexion. MCP a besoin d'un serveur en cours d'exécution, d'une connexion API Figma en direct, et d'un PAT avec accès. Réseau coupé, API Figma en panne, PAT expiré — l'agent n'a pas de contexte. Un bundle fonctionne dans un avion.

Récupération dépendante du modèle. Ce que l'agent demande via MCP dépend de ce qu'il décide de demander. Il peut ne pas récupérer les valeurs de tokens. Il peut ne pas tirer l'inventaire des composants. Il peut ne demander que le sous-arbre de nœuds qu'il pense avoir besoin, manquant le contexte spatial des nœuds adjacents. La récupération est probabiliste, pas déterministe. figmascope récupère tout, à chaque fois, avec un schéma fixe.

Plus difficile à tester et reproduire. « Mon agent a construit ce composant depuis ces données Figma à ce moment précis » n'est pas vérifiable avec MCP. Le fetch est éphémère. Avec un bundle, vous pouvez rejouer exactement : même bundle, même agent, même prompt — sortie déterministe. Cela importe pour le débogage, la revue de code, et la responsabilité de release.

Pression sur la fenêtre de contexte. Un appel naïf get_file sur un fichier Figma complexe renvoie un arbre JSON énorme. Les agents doivent faire des appels d'outils sélectifs pour rester dans les budgets de contexte. Cela introduit des heuristiques et des jugements qui peuvent mal tourner. figmascope pré-traite l'arbre en un IR structuré avec uniquement ce qui est nécessaire, à une taille connue et bornée.

Le modèle bundle de figmascope : capturez une fois, livrez pour toujours

figmascope exporte un .zip de fichiers simples depuis l'API REST Figma — pas de plugin, pas de serveur, fonctionne dans votre navigateur. Le bundle contient :

• CONTEXT.md — spec lisible par les humains, spec lisible par les agents
• tokens.json — tokens de design typés, sources en cascade : variables Figma → inférés par fréquence → aucun
• screens/*.json — IR par écran avec sémantique de mise en page : stack, overlay, absolute, leaf ; componentId sur les nœuds INSTANCE ; stringRef.key sur le texte
• screens/*.png — captures de référence à 2×
• components/inventory.json — index complet des composants
• strings.json — tout le contenu textuel, clé
• _meta.json — métadonnées d'export

Une fois exporté, le bundle est autonome et immuable. Il va dans votre dépôt aux côtés du code qu'il décrit. N'importe quel agent, n'importe quelle session, n'importe quel développeur, n'importe quel job CI peut le lire. Pas de connexion à quoi que ce soit requise.

Diffs versionnables : comparer les bundles comme du code

C'est l'argument le plus fort du modèle bundle. Parce que la sortie est du JSON structuré et du Markdown, vous pouvez la differ.

Exportez un bundle avant un sprint de design. Exportez-en un autre après. Lancez diff sur tokens.json :

- "spacing.4": "16px"
+ "spacing.4": "14px"

C'est un changement cassant dans votre échelle d'espacement. Il est visible, révisable, et traçable jusqu'à un commit. Avec MCP, le même changement se produit silencieusement — la prochaine fois que l'agent récupère, il obtient la nouvelle valeur, et il n'y a aucun enregistrement que quoi que ce soit a changé.

Vous pouvez utiliser cela comme un garde de PR : exportez le bundle dans le cadre de la passation de design, committez-le, exigez l'approbation du designer et du dev sur le diff avant que l'implémentation commence. C'est la spec-de-design-comme-code. MCP n'a pas d'équivalent.

L'argument du déterminisme

Même version de fichier Figma + même export figmascope = même bundle. À chaque fois. Le schéma IR est fixe. La logique de sourcing des tokens est déterministe. L'extraction des clés de chaînes est basée sur des règles.

La récupération MCP n'est pas déterministe. L'agent décide ce qu'il faut récupérer. Agents différents, formulation de prompt différente, budgets de contexte différents — comportement de fetch différent. La sortie est dépendante du modèle.

Pour la génération de code UI en production, le déterminisme importe. Vous voulez que la spec qui a généré un composant soit reproductible. Vous voulez pouvoir régénérer le composant depuis les mêmes entrées et obtenir des résultats cohérents. Les bundles supportent cela. Les sessions MCP ne le font pas.

Comparaison

MCP brille pour « éditer Figma en direct » — les bundles brillent pour « construire de l'UI de production »

C'est le résumé honnête. Si votre workflow est l'exploration de design conversationnelle — « change ce composant », « annote cet écran », « quels sont les tokens de couleur sur ce frame » — la connexion en direct de MCP est le bon modèle. L'agent est un collaborateur dans le processus de design, et il a besoin de données courantes pour faire ça.

Si votre workflow est de construire de l'UI de production depuis un design finalisé (ou quasi-finalisé) — implémenter des composants, câbler l'état, écrire des tests — le modèle bundle est meilleur. Vous voulez la spec ancrée dans votre dépôt, diffable à travers les itérations de design, lisible par n'importe quel agent sans configuration, et suffisamment déterministe pour construire dessus.

Les deux modèles sont complémentaires. Utilisez MCP quand le design est en flux et que vous itérez de manière collaborative. Exportez un bundle figmascope quand le design est stable et que vous le remettez aux ingénieurs pour l'implémentation. Le bundle devient la source de vérité contre laquelle l'implémentation est construite — traçable, révisable, reproductible.