Figma MCP : 3 workflows agents pour designer avec l’IA en 2026

Temps de lecture : 6 min

Pourquoi j’ai testé le MCP de Figma

Depuis que je bosse dans le développement web, j’ai vu défiler pas mal de promesses autour de l’IA. Mais avec ma casquette de fondateur WebNyxt et de créateur de l’app GymLog, je reste pragmatique. Une techno, pour moi, doit répondre à un vrai problème : construire vite, certes, mais surtout construire la bonne chose. Et si on enchaîne les mauvaises itérations, on perd du temps.

Concrètement, dans mes projets, quand on itère entre code (Next.js) et design (Figma), le gouffre est immense. On fait un écran en React, on capture une image, on la colle dans Figma pour la commenter, on revient au code pour intégrer les retours… C’est un aller-retour poussif. Le serveur MCP de Figma change la donne : c’est une API en temps réel que les agents IA peuvent utiliser pour manipuler le canvas directement, sans copier-coller. Je l’ai expérimenté avec Cursor, et ça m’a bluffé par la réduction de friction.

MCP, agents, skills : posons les définitions

Avant de plonger, clarifions trois termes que j’utilise fréquemment :

• Agent IA : un système (Cursor, Claude Code, Codex) qui utilise l’IA pour planifier, coder, interpréter des visuels ou orchestrer d’autres agents. Il exécute des tâches complexes avec un but précis.
• MCP (Model Context Protocol) : un standard ouvert qui permet à un agent de dialoguer avec des logiciels comme Figma. Le serveur MCP de Figma expose un point d’accès (https://mcp.figma.com/mcp) où l’agent peut envoyer des commandes : lire un composant, créer une frame, modifier une variable. C’est du bidirectionnel pur.
• Skill : un fichier texte d’instructions téléchargeable sur la Figma Community. Une sorte de “recette” que l’agent intègre pour savoir exactement comment accomplir une tâche (importer un prototype, générer un design). Pas besoin de le reprompter à chaque fois.

Plus précisément, il y a un skill appelé /figma-use (aussi appelé “write to canvas”) qui est la cheville ouvrière : il permet à l’agent de manipuler en direct les composants, variables et styles du projet Figma.

Workflow 1 : Importer un prototype codé dans Figma

Quand tu bosses sur un prototype playground (un bac à sable avec du vrai code de prod, sans risques), tu veux parfois remonter le résultat dans Figma pour le montrer à une équipe, le réviser visuellement, ou le partager.

Étape 1 : Import via le skill /prototype-to-figma

Dans Cursor, je tape /prototype-to-figma et je file l’URL localhost (par exemple, http://localhost:3000/prototype). Le skill capture chaque écran unique et les place sur le canvas Figma sous forme de frames reliées au design system existant : composants, styles, tokens, tout est respecté. Il génère aussi une page de résumé et une page de styles pour le contexte.

Concrètement, en deux minutes, j’ai un prototype clicable dans Figma, sans retaper quoi que ce soit. Pour le design de GymLog, ça me permet de partager des maquettes avec mon équipe avant même de finaliser le code.

Étape 2 : Révision sur le canvas

Une fois les écrans dans Figma, je peux voir le flux complet d’un coup d’œil. Le prototype généré par IA est rarement parfait. Je vérifie :

• Éléments redondants (indicateur de progression + barre de progression = superflu)
• Composants du design system : remplacer des éléments ad hoc par des cartes ou boutons du DS pour coller à la prod
• Hiérarchie visuelle : espacements, typo, illustrations
• Auto layout : tout frame doit être responsif

Itérer directement sur le canvas (souvent en co-design) est plus rapide que de reprompter l’agent pour chaque changement code.

Étape 3 : Partager ou repousser vers le code

Deux options : soit je partage pour des retours utilisateurs, soit je demande à l’agent de mettre à jour le prototype en utilisant le design Figma comme source de vérité. Le serveur MCP gère le va-et-vient.

Workflow 2 : Synchroniser un design system entre code et Figma

Quand ton équipe fait du design dans le code (pendant un sprint IA ou une hack week), les nouvelles variables et tokens risquent de se perdre, déconnectés du DS Figma. Ce workflow résout ça.

Étape 1 : Importer le design et les variables

Les skills /figma-generate-design et /figma-generate-library capturent les écrans codés (par exemple, dark mode) et créent une nouvelle collection de variables dans le panneau Figma, qui reflète les tokens utilisés dans le code. En un seul prompt, je vois le dark mode et le light mode côte à côte, avec leurs variables.

Étape 2 : Évaluer et affiner les variables

Sur le canvas, je détecte des problèmes difficiles à voir dans le code :

• Intensité des couleurs : une couleur d’accent qui marche en light mode peut donner un effet “néon” en dark mode
• Contraste du texte : les labels secondaires risquent de ne pas passer les tests WCAG AAA

J’ouvre le panneau des variables, je modifie les tokens, et toutes les frames se mettent à jour en temps réel. C’est beaucoup plus rapide que de modifier une valeur dans un fichier CSS et recharger le navigateur.

Étape 3 : Repousser les tokens vers le code

Une fois les variables stabilisées dans Figma, je demande à l’agent de mettre à jour le design system dans la codebase. Figma devient la source de vérité pour les décisions de design et le code reste synchronisé. Dans mes projets Next.js, ça évite les divergences entre fichiers de tokens SCSS et le DS Figma.

Workflow 3 : Explorer de nouvelles directions depuis le canvas

Quand je dois itérer sur un écran existant avec un vrai problème utilisateur, la page blanche (ou l’écran vide) est le plus grand ennemi. Ce workflow casse ça.

Étape 1 : Définir le problème

Je pars d’un énoncé clair. Exemple : sur un tableau de bord de revenus clients, les utilisateurs ne voient pas l’état de renouvellement (simple label texte en fin de ligne). Le problème : rendre cette info visible et actionnable.

Étape 2 : Générer une direction avec l’agent

J’active le skill /figma-use et je lui fournis le contexte : insights utilisateur, contraintes (taille d’écran, palette existante). L’agent explore une approche et place une itération brute sur le canvas, utilisant les vrais composants du design system. Ce n’est pas un design final, c’est un point de départ concret.

Étape 3 : Affiner sur le canvas

Je regarde ce que l’agent a produit :

• Changé-t-il le principe organisateur du layout ? (regrouper par statut, prioriser les lignes)
• Utilise les bons composants ? Je remplace ou corrige si nécessaire
• Qu’est-ce qui fonctionne ? Je garde l’essai

Itérer sur le canvas plutôt que de prompter en boucle évite les allers-retours et permet de prendre des décisions visuelles rapidement. Je peux même co-designer avec un collègue en temps réel.

Ce que ça change concrètement pour mon workflow

Dans les trois workflows, le même pattern se répète : l’IA fait l’assemblage mécanique (générer des frames, importer des écrans, manipuler des variables), et moi, designer/développeur, je me concentre sur les décisions de fond. Le résultat, pour un projet comme GymLog, c’est des itérations deux à trois fois plus rapides.

Pour connecter le serveur MCP, deux options :

• Serveur MCP distant (recommandé) : l’agent se connecte à https://mcp.figma.com/mcp
• Serveur MCP desktop : tourne localement via l’application Figma, pour des cas spécifiques en entreprise

Perso, j’utilise le distant avec Cursor, et c’est transparent. Pas de maintenance, juste un endpoint à configurer une fois.

N’hésite pas à explorer ces workflows sur la page Figma Community pour les skills, et à les intégrer dans tes projets. Si tu veux échanger sur ton retour d’expérience, les commentaires sont là.

Nicolas D.

Développeur full-stack depuis 25 ans, je suis passé du PHP des années 2000 aux stacks modernes (Next.js, React Native, IA). J’accompagne entrepreneurs et créateurs dans leurs projets digitaux avec une approche pragmatique : du code aux résultats concrets.