Claude Code + Figma : 3 MCPs pour piloter Figma depuis le terminal

Pourquoi connecter Claude Code à Figma ?

Le workflow classique designer/développeur, c'est : ouvrir Figma, inspecter les maquettes, copier les couleurs et les espacements, traduire ça en CSS. Manuellement. À chaque itération.

En branchant Claude Code directement sur Figma via le protocole MCP, on change la donne. L'agent IA peut lire ce qu'il y a dans Figma (composants, tokens, styles) et aussi écrire dedans (créer des frames, du texte, des formes). Le terminal devient une télécommande pour Figma.

Mais il n'existe pas un seul outil pour tout faire. J'en utilise trois, chacun avec son approche et ses forces. Voici le comparatif.

Vue d'ensemble : 3 MCPs, 3 rôles

	Talk to Figma	figma-console-mcp	Figma MCP (officiel)
Éditeur	Communauté (arinspunk)	Communauté (southleft)	Anthropic
Connexion	WebSocket + Plugin	API REST + CDP	HTTP distant
Force principale	Création en temps réel	Extraction + debug	Lecture de fichiers
Authentification	Aucune (plugin local)	API Key Figma	API Key Figma
Nécessite Figma Desktop	Oui	Non	Non
Nombre d'outils	43	40+	Variable

En résumé : Talk to Figma est le bras qui crée, figma-console-mcp est l'œil qui inspecte, et le MCP officiel est le pont standardisé.

Talk to Figma : créer en temps réel dans Figma

C'est l'outil le plus spectaculaire. Talk to Figma permet à Claude Code de créer et modifier des éléments directement dans un fichier Figma ouvert, en temps réel. Vous voyez les rectangles, les textes et les frames apparaître dans Figma pendant que Claude écrit le code.

Comment ça marche

L'architecture repose sur trois couches :

Un plugin Figma — tourne dans Figma Desktop et écoute les commandes
Un serveur WebSocket — fait le relais sur le port 3055
Un serveur MCP — expose les outils à Claude Code via le protocole standard

La communication passe par un système de channels. Le plugin Figma génère un identifiant de channel (par exemple et8xi9cl), et Claude Code s'y connecte avec la commande join_channel. À partir de là, tout ce que Claude demande est exécuté instantanément dans Figma.

Ce qu'on peut faire

Créer des éléments — frames, rectangles, ellipses, polygones, étoiles, texte
Modifier les styles — couleurs de fond, bordures, effets, coins arrondis
Gérer la typographie — police, taille, poids, interligne, espacement des lettres
Organiser — auto-layout, grouper/dégrouper, imbriquer des éléments, cloner
Travailler avec les composants — instancier des composants locaux ou distants
Exporter — exporter un nœud en image (PNG, SVG, etc.)

Setup

# 1. Cloner le repo
git clone https://github.com/arinspunk/claude-talk-to-figma-mcp.git
cd claude-talk-to-figma-mcp

# 2. Installer et builder
bun install && bun run build

# 3. Lancer le serveur WebSocket
bun run dist/socket.js

Ensuite, dans Figma Desktop : Plugins → Development → Import plugin from manifest en pointant vers src/claude_mcp_plugin/manifest.json. Lancez le plugin, notez le channel ID.

La configuration MCP dans ~/.claude.json :

{
  "mcpServers": {
    "claude-talk-to-figma": {
      "command": "bun",
      "args": ["run", "/chemin/vers/claude-talk-to-figma-mcp/dist/talk_to_figma_mcp/server.js"]
    }
  }
}

Quand l'utiliser

Talk to Figma excelle quand vous voulez générer du design depuis une description. Par exemple : "Crée un composant card avec une image en haut, un titre, une description et un bouton CTA, en utilisant les couleurs de mon design system." Claude Code crée tout directement dans votre fichier Figma.

C'est aussi utile pour prototyper rapidement des variantes d'un composant ou pour générer des mises en page répétitives (grilles de cards, listes, formulaires).

Talk to Figma sur GitHub

Le repo open source avec les instructions d'installation complètes et la documentation des 43 outils disponibles.

Voir sur GitHub

figma-console-mcp : extraire, debugger, gérer les tokens

Si Talk to Figma est le bras, figma-console-mcp est l'œil. Cet outil se connecte à Figma via l'API REST et le Chrome DevTools Protocol (CDP) pour lire les informations du design — variables, styles, composants — et debugger les plugins en cours d'exécution.

Ce qu'on peut faire

Extraire les design tokens — récupérer toutes les variables (couleurs, espacements, typographie) d'un fichier Figma
Gérer les variables — créer, modifier, supprimer des variables individuellement ou par lot (batch)
Inspecter les composants — rechercher, lire les détails, générer la documentation d'un composant
Debugger — lire les logs console, prendre des screenshots, recharger un plugin
Vérifier la parité design/code — comparer les tokens Figma avec les valeurs CSS réelles
Configurer un design system complet — créer une collection de variables avec modes (light/dark) en un seul appel

Les opérations batch : un gain énorme

Un point fort de figma-console-mcp : les opérations batch. Au lieu de créer 50 variables une par une (50 appels MCP), on peut les créer toutes en un seul appel avec figma_batch_create_variables. C'est 10 à 50 fois plus rapide parce que tout s'exécute en un seul roundtrip CDP.

L'outil figma_setup_design_tokens va encore plus loin : il crée une collection complète (collection + modes + variables) de manière atomique. Idéal pour initialiser un design system depuis zéro.

Setup

La configuration est plus simple que Talk to Figma — pas besoin de plugin ni de WebSocket :

{
  "mcpServers": {
    "figma-console-mcp": {
      "command": "npx",
      "args": ["figma-console-mcp"],
      "env": {
        "FIGMA_API_KEY": "figd_votre_token_ici"
      }
    }
  }
}

Le token API se génère sur figma.com/developers/api. Une fois configuré, tous les outils sont disponibles immédiatement dans Claude Code.

Quand l'utiliser

figma-console-mcp est indispensable quand vous travaillez sur un design system. Extraire les tokens pour les convertir en CSS custom properties, vérifier que les couleurs du code correspondent aux valeurs Figma, documenter les composants automatiquement.

C'est aussi l'outil de choix pour le debugging de plugins Figma — lire les console.log, capturer des screenshots de l'état courant, et même ré-exécuter du code dans le contexte du plugin.

figma-console-mcp sur GitHub

Le serveur MCP pour l'extraction de tokens, le debugging et la gestion de design systems dans Figma.

Voir sur GitHub

Figma MCP officiel : l'intégration Anthropic

Anthropic propose son propre serveur MCP pour Figma, accessible via un endpoint HTTP distant. Contrairement aux deux autres qui tournent en local, celui-ci se connecte directement aux serveurs de Figma.

Ce qu'on peut faire

Lire les fichiers Figma — accéder au contenu d'un fichier sans avoir Figma ouvert
Inspecter les designs — récupérer la structure, les styles et les propriétés des nœuds
Obtenir des screenshots — capturer des rendus de composants ou de pages
Lire les variables et les design tokens — accéder aux définitions de variables

Setup

{
  "mcpServers": {
    "figma-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@anthropic/figma-mcp", "--figma-api-key=figd_votre_token_ici"]
    }
  }
}

Quand l'utiliser

Le MCP officiel est le meilleur choix quand vous voulez lire un fichier Figma sans avoir Figma Desktop ouvert. C'est utile en mode CI/CD, sur un serveur, ou simplement quand vous travaillez sur une machine qui n'a pas Figma installé.

C'est aussi la solution la plus simple à configurer — un seul package NPX, pas de plugin, pas de WebSocket. Idéal pour un setup rapide ou pour des collaborateurs qui veulent juste inspecter des designs.

Mon workflow au quotidien

En pratique, je n'utilise pas les trois en même temps. Le choix dépend de ce que je fais :

Je veux...	J'utilise...
Créer un composant UI dans Figma	Talk to Figma
Générer une mise en page complète	Talk to Figma
Extraire les couleurs et spacings pour mon CSS	figma-console-mcp
Créer ou modifier des variables en masse	figma-console-mcp
Debugger un plugin Figma	figma-console-mcp
Vérifier la parité entre mon code et la maquette	figma-console-mcp
Lire un fichier Figma depuis un serveur	Figma MCP officiel
Inspecter rapidement sans setup	Figma MCP officiel

Le plus souvent, c'est le duo Talk to Figma + figma-console-mcp qui tourne. Talk to Figma pour créer, figma-console-mcp pour vérifier et extraire. Le MCP officiel intervient surtout quand je travaille sur un projet où Figma Desktop n'est pas disponible.

Un exemple concret

En général, je reçois une maquette Figma d'un designer ou d'un client. Avant de lancer la génération de code, il y a un travail de préparation indispensable. C'est là que les MCPs entrent en jeu :

Audit de la maquette — j'utilise figma-console-mcp pour inspecter le fichier : est-ce que les layers ont des noms sémantiques ? Est-ce que les couleurs sont des variables ou du hex en dur ? Est-ce qu'il y a des composants réutilisables ?
Restructuration si nécessaire — via Talk to Figma, je renomme les layers en convention BEM, je transforme les groupes en Auto Layout, je remplace les positions absolues par du Hug/Fill. C'est le ménage avant de coder.
Extraction des tokens — une fois le fichier propre, figma-console-mcp extrait les variables (couleurs, espacements, rayons) et je les convertis en CSS Custom Properties
Génération du code — Claude Code lit la structure Figma via MCP et génère du HTML sémantique + CSS responsive. Comme le fichier est bien structuré, le code généré est directement exploitable.
Vérification de parité — pendant le développement, figma_check_design_parity compare les valeurs CSS avec les tokens Figma. Si le designer modifie une couleur, je le vois immédiatement.

Le point clé : au plus le Figma est bien configuré, au plus le code généré par Claude Code sera propre et maintenable. L'investissement dans la préparation du fichier Figma se récupère dix fois dans la qualité du code.

Configuration complète

Voici la configuration globale dans ~/.claude.json pour avoir les trois MCPs disponibles dans tous vos projets :

{
  "mcpServers": {
    "claude-talk-to-figma": {
      "command": "bun",
      "args": ["run", "/chemin/vers/claude-talk-to-figma-mcp/dist/talk_to_figma_mcp/server.js"]
    },
    "figma-console-mcp": {
      "command": "npx",
      "args": ["figma-console-mcp"],
      "env": {
        "FIGMA_API_KEY": "figd_votre_token_ici"
      }
    },
    "figma-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@anthropic/figma-mcp", "--figma-api-key=figd_votre_token_ici"]
    }
  }
}

Prérequis pour Talk to Figma :

Installer Bun (runtime JavaScript rapide)
Cloner et builder le repo Talk to Figma
Lancer le serveur WebSocket : bun run dist/socket.js
Importer le plugin dans Figma Desktop et le connecter

Prérequis pour les deux autres :

Générer un Personal Access Token Figma
L'ajouter dans la configuration MCP

C'est tout. Claude Code détecte automatiquement les serveurs MCP au démarrage et rend leurs outils disponibles.

Bien configurer Figma pour que l'IA puisse le lire

J'enseigne la mise en page web à des étudiants, et un module entier de mon cours est consacré à ça : préparer Figma pour que Claude Code puisse le lire et le traduire en HTML/CSS propre. Parce que la qualité du code généré dépend directement de la qualité du fichier Figma.

Un Figma mal structuré — avec des layers nommés "Frame 47", "Rectangle 2", pas d'Auto Layout, pas de composants — va produire du CSS rigide, des noms de classes absurdes et du code impossible à maintenir. Un Figma bien configuré, c'est l'inverse : du HTML sémantique, des variables CSS cohérentes, du responsive qui marche.

Le nommage des layers : la base de tout

C'est la première chose que j'explique à mes étudiants. Quand Claude Code lit un fichier Figma via MCP, il utilise les noms des layers pour générer les noms de classes CSS et la structure HTML. Un layer nommé section-products va devenir <section class="section-products">. Un layer nommé Frame 1 va devenir... .frame-1.

La convention que j'enseigne s'inspire du BEM (Block Element Modifier) :

section-products           → <section class="section-products">
├── section-header         → <div class="section-header">
│   ├── section__title     → <h2 class="section__title">
│   └── section__subtitle  → <p class="section__subtitle">
├── filters                → <div class="filters">
│   ├── filter-tag         → <button class="filter-tag">
│   └── filter-tag         → <button class="filter-tag">
├── products-grid          → <div class="products-grid">
│   ├── Card/Product       → <article class="card-product">
│   └── Card/Product       → <article class="card-product">
└── Button/Primary         → <a class="btn btn-primary">

La règle : chaque layer doit avoir un nom qui a du sens en HTML/CSS. Si le nom n'a pas de sens pour un développeur, il n'en aura pas non plus pour l'IA.

Auto Layout = Flexbox

C'est le concept le plus important pour le passage Figma → CSS. L'Auto Layout de Figma est l'équivalent exact de Flexbox en CSS. Quand mes étudiants comprennent ça, tout s'éclaire :

Figma (Auto Layout)	CSS (Flexbox)
Direction horizontale/verticale	`flex-direction: row / column`
Gap entre les éléments	`gap`
Padding interne	`padding`
Alignement	`align-items + justify-content`
Space between	`justify-content: space-between`
Wrap	`flex-wrap: wrap`

Quand un fichier Figma utilise l'Auto Layout partout (au lieu de positionner les éléments manuellement), Claude Code génère du Flexbox responsive au lieu de position: absolute avec des pixels en dur. C'est la différence entre un site qui s'adapte et un site qui casse.

Les 3 modes de redimensionnement

C'est le point où les débutants font le plus d'erreurs. Figma propose trois modes de redimensionnement pour chaque élément dans un Auto Layout :

Mode Figma	CSS équivalent	Utilisation
Hug Contents	`width: fit-content`	Boutons, badges, tags — l'élément s'adapte à son contenu
Fill Container	`width: 100%` ou `flex: 1`	Éléments pleine largeur — l'élément prend tout l'espace
Fixed	`width: 200px`	Icônes, avatars — taille fixe en pixels

L'erreur classique : tout laisser en Fixed. Le résultat ? Claude Code génère du CSS avec des largeurs en pixels partout — rien n'est responsive. La règle que j'enseigne : utiliser Fill pour les conteneurs principaux, Hug pour les éléments de contenu, et Fixed uniquement pour les icônes et avatars.

Les composants et variants

Dans Figma, un composant est l'équivalent d'une classe réutilisable en code. Le composant principal (losange violet) est la définition, et chaque instance (losange vide) est une utilisation. Quand Claude Code détecte des instances de composants, il génère du code DRY — une seule classe CSS réutilisée, pas du code dupliqué.

La convention de nommage avec des slashes organise les composants en catégories :

Button/Primary, Button/Secondary, Button/Ghost
Card/Product, Card/Article, Card/Testimonial
Input/Text, Input/Email, Input/Password

Les variants ajoutent des propriétés multiples à un composant : state (Default, Hover, Active, Disabled), size (Small, Medium, Large), style (Primary, Secondary, Ghost). Un bouton avec 3 styles × 2 tailles × 2 états = 12 variants, toutes générées depuis un seul composant. Claude Code traduit ça en classes CSS modulaires (.btn--primary, .btn--sm, .btn--disabled).

Les design tokens : Figma Variables → CSS Custom Properties

C'est le lien le plus direct entre Figma et le code. Les variables Figma (couleurs, espacements, rayons) deviennent des CSS Custom Properties :

/* Variables Figma extraites par figma-console-mcp */
:root {
  --color-dark: #1B234B;
  --color-white: #FFFFFF;
  --color-light-gray: #F1F2F4;
  --color-bg: #EDF0F2;
  --color-text-dark: #262626;
  --color-text-muted: #737880;
  --color-accent: #969F7D;

  --gap-xs: 8px;
  --gap-sm: 12px;
  --gap-md: 24px;
  --gap-lg: 40px;

  --radius-sm: 8px;
  --radius-md: 12px;
  --radius-lg: 20px;
}

Quand un fichier Figma utilise des variables au lieu de couleurs en dur, Claude Code génère du CSS avec var(--color-accent) au lieu de #969F7D. Changer une couleur dans Figma se répercute automatiquement dans tout le CSS — c'est la promesse du design system.

Checklist : votre Figma est-il prêt pour l'IA ?

Voici la checklist que j'utilise avec mes étudiants avant de lancer la génération de code :

Tout est en Auto Layout — aucun élément positionné manuellement
Les layers ont des noms sémantiques — pas de "Frame 47" ou "Rectangle 2"
Les composants sont utilisés — les éléments répétitifs sont des instances, pas des copies
Les modes de redimensionnement sont corrects — Fill pour la largeur des conteneurs, Hug pour les contenus
Les couleurs sont des variables — pas de hex en dur dans les éléments
Les espacements sont cohérents — un système de gaps (8, 12, 16, 24, 32, 40)
Les composants suivent la convention de nommage — Category/Name
Le layout est responsive — les cards wrappent quand la largeur diminue

Si ces huit points sont respectés, Claude Code va générer du HTML sémantique et du CSS maintenable. Si un seul manque, la qualité du code en souffre proportionnellement.

Enseigner le workflow Figma → IA → Code

Dans mon cours, le module se déroule en deux temps :

Séance 3 : Figma Auto Layout & Composants — les étudiants apprennent à structurer un fichier Figma correctement, avec des exercices progressifs (carte simple → composants → variants → page complète)
Séance 4 : L'IA comme assistant CSS — ils connectent leur Figma à Claude Code via MCP et génèrent du code à partir de leurs maquettes

L'exercice final de la séance 3 est révélateur : créer une section "Nos Produits" complète avec un header centré, des filtres sous forme de tags, une grille de 6 product cards en wrap (3 par ligne), et un bouton CTA. Tout en Auto Layout, tout avec des composants.

À la séance suivante, les étudiants lancent l'extraction MCP sur ce même fichier. Ceux qui ont bien structuré leur Figma obtiennent du code propre. Les autres obtiennent un tas de .frame-1 et de position: absolute. La leçon est immédiate et concrète : la qualité du Figma détermine la qualité du code.

L'exercice "IA vs Réalité"

Un autre exercice que je fais en début de module : les étudiants reçoivent un brief identique (une landing page pour un service de scooters électriques) et doivent la coder en 1h15 avec l'aide de l'IA. Ensuite, on analyse collectivement les erreurs typiques de l'IA :

Code verbeux — l'IA génère plus de code que nécessaire
Mobile-first oublié — le responsive est rarement bon du premier coup
Noms de classes génériques — .card, .btn sans contexte
Pas de variables CSS — des couleurs hex en dur partout
HTML non sémantique — des <div> partout au lieu de <header>, <section>, <footer>

Le but n'est pas de montrer que l'IA est mauvaise — c'est de montrer que l'IA est aussi bonne que les instructions qu'on lui donne. Un Figma bien structuré + un bon prompt = du code de qualité. Un Figma chaotique + un prompt vague = du code à jeter.

Ce que ça change

Avant ces MCPs, le workflow entre design et code était linéaire et manuel : designer dans Figma, inspecter, copier, coder. Maintenant c'est un dialogue bidirectionnel. Claude Code lit le design, génère du code qui correspond, et peut même modifier le design si nécessaire.

Les trois MCPs couvrent des besoins différents mais complémentaires :

Talk to Figma — pour les créatifs qui veulent générer du design depuis le terminal
figma-console-mcp — pour les développeurs qui veulent extraire et synchroniser les tokens
Figma MCP officiel — pour ceux qui veulent un setup simple et lisible partout

Le protocole MCP rend tout ça possible parce qu'il fournit un standard de communication entre l'agent IA et les outils externes. Chaque MCP est un module spécialisé qu'on branche selon ses besoins. C'est l'avantage d'un écosystème ouvert : on combine les outils au lieu d'attendre qu'un seul fasse tout.

Retour aux articles