Figma + agents IA : trois workflows concrets pour concevoir et coder sans friction

Ce que change l'IA dans le processus de design

La promesse des agents IA dans le développement produit n'est pas uniquement une question de vitesse. L'accélération est réelle, mais construire vite un mauvais produit ne sert à rien. Ce qui change réellement, c'est la capacité à itérer plus tôt, plus souvent et sur des artefacts plus concrets.

Figma s'inscrit dans cette logique en s'ouvrant aux workflows agentiques via son serveur MCP. L'idée : permettre à des agents comme Cursor, Claude Code ou Codex d'interagir directement avec le canvas de Figma (c’est-à-dire l’espace de travail), d'y lire des composants, d'y écrire des frames, de manipuler des variables. Le tout sans que le designer ait à effectuer le travail de copier-coller entre deux environnements.

MCP, agents et skills : de quoi parle-t-on exactement ?

Avant d'entrer dans les workflows, trois concepts méritent d'être compris clairement.

• Un agent, c'est un système logiciel qui utilise l'IA pour atteindre des objectifs et accomplir des tâches. Dans le développement produit, un agent peut planifier un projet, écrire du code, interpréter des visuels ou orchestrer d'autres agents. Cursor, Codex et Claude Code en sont des exemples courants.
• MCP signifie Model Context Protocol. C'est un standard ouvert qui définit comment les agents communiquent avec d'autres logiciels, comme Figma. Un serveur MCP permet à un agent de récupérer du contexte depuis des sources externes pour prendre de meilleures décisions. Le serveur MCP de Figma permet concrètement de :
• Traduire du code en designs Figma
• Créer et modifier des éléments sur le canvas
• Retransformer ces designs en code

Ce pont bidirectionnel entre design et code est ce qui rend le workflow agentique avec Figma utile.

• Un skill, enfin, c'est un fichier texte contenant un ensemble d'instructions qu'un agent peut apprendre et réutiliser pour accomplir une tâche spécifique. Toute tâche répétitive qu'on reprompt régulièrement à son agent est un bon candidat pour devenir un skill. Les skills liés à ces workflows sont disponibles sur la page Figma Community et peuvent être installés en copiant leur lien GitHub dans l'agent.

Il existe aussi un skill particulier, /figma-use, aussi appelé « write to canvas ». Il permet à un agent de créer et de modifier un fichier Figma réel en utilisant les composants, variables et styles existants du projet.

Workflow 1 : importer un prototype codé dans Figma

Quand l'utiliser : quand un prototype fonctionnel existe en code et qu'on veut le ramener dans Figma pour le réviser, itérer ou partager.

Beaucoup d'équipes commencent aujourd'hui à designer directement dans le code, souvent dans un « prototype playground » : un environnement bac à sable avec du vrai code et des écrans issus de l'application de production, mais sans risque d'affecter le code de production ni les designs finaux. Ce workflow s'applique à cette situation, mais aussi à n'importe quel prototypage en code.

Étape 1 : importer le prototype dans Figma

Le skill /prototype-to-figma prend en charge l'import. Il capture un prototype qui tourne en local et place chaque écran unique sur le canvas Figma sous forme de frames connectées au design system.

Pour l'utiliser, il suffit de taper /prototype-to-figma dans l'agent (par exemple Cursor) et de lui indiquer l'URL localhost du prototype. Chaque étape du flux du prototype apparaît sur le canvas comme une frame de design, avec les composants et styles du design system existant. Le skill génère aussi une page de résumé et une page de styles pour avoir le contexte de ce qui a été capturé et pourquoi.

Étape 2 : réviser et affiner sur le canvas

Une fois les écrans dans Figma, on peut voir l'ensemble du flux d'un seul regard et l'évaluer globalement. Un prototype généré par IA est un bon point de départ pour valider une idée, mais il nécessite souvent un travail de design avant d'être prêt pour un retour ou une passation.

Quelques points à examiner lors de la révision :

• Les éléments d'UI redondants : par exemple, si un écran a à la fois un indicateur d'étapes et une barre de progression, l'un des deux est probablement superflu.
• Les opportunités d'utiliser des composants du design system : remplacer des éléments ad hoc par de vrais composants (cartes, boutons, primitives de layout) rapproche le design des standards de production.
• La hiérarchie visuelle : illustrations, typographie et espacement peuvent créer une composition plus intentionnelle.
• La structure du layout : ajouter de l'auto layout aux frames donne un aperçu plus précis de l'espacement.

Itérer directement sur le canvas, surtout en co-design avec un collègue, est souvent plus rapide que de repromper l'agent pour faire les mêmes changements dans le code.

Étape 3 : partager ou mettre à jour le prototype

Une fois le design affiné, deux options s'offrent à vous : partager pour recueillir des retours (le design est prêt pour les parties prenantes), ou demander à l'agent de mettre à jour le prototype directement en utilisant le design Figma comme source de vérité.

Workflow 2 : synchroniser le design system entre code et Figma

Quand l'utiliser : quand on veut que les outils agentiques génèrent du code qui référence de vrais composants et tokens du design system.

Les design systems permettent aux équipes de créer des expériences cohérentes et qui passent à l'échelle. Mais quand le design se fait dans le code, lors d'un hack week, d'une expérimentation rapide ou d'un sprint IA, ces changements peuvent se retrouver isolés dans la codebase, déconnectés du design system dans Figma.

Ce workflow montre comment ramener un design codé (avec ses variables) sur le canvas, l'évaluer, l'affiner, et repousser les tokens mis à jour vers le code.

Les skills /figma-generate-design et /figma-generate-library utilisés ici sont pré-installés avec le serveur MCP de Figma.

Étape 1 : importer le design et les variables dans Figma

Si une nouvelle direction de design a été construite en code (par exemple, un dark mode utilisant les variables de couleur du design system existant), les skills pré-installés permettent de la capturer dans Figma. Un prompt appelant /figma-generate-design et /figma-generate-library va :

• Placer les écrans sur le canvas Figma (par exemple, les modes clair et sombre côte à côte)
• Créer une nouvelle collection de variables dans le panneau des variables qui reflète les tokens utilisés dans le code

On peut alors évaluer le design d'un seul coup d'oeil et vérifier comment il se tient sur plusieurs écrans, ce qui est difficile à faire quand le design n'existe que dans un environnement local qui tourne.

Étape 2 : évaluer et affiner les variables

Avec les écrans et les variables sur le canvas, on peut repérer les problèmes difficiles à détecter dans le code seul. Points courants à surveiller :

• L'intensité des couleurs : les couleurs d'accent qui fonctionnent bien en mode clair peuvent paraître saturées ou "néon" en mode sombre. Envisager de passer à une teinte différente de la palette.
• Le contraste du texte : les textes à faible contraste, notamment les labels secondaires comme les dates ou légendes, peuvent ne pas répondre aux standards d'accessibilité. Si l'équipe vise WCAG AAA, ces valeurs méritent une vérification attentive.

Pour effectuer des ajustements, on ouvre le panneau des variables et on met à jour les tokens directement. Les modifications se reflètent en temps réel sur tous les composants et références de styles du canvas, ce qui donne une vue globale de l'impact des décisions de tokens sur l'ensemble du design.

Voir les variables et leurs effets simultanément plutôt que de modifier une valeur dans le code et rafraîchir un navigateur accélère considérablement l'itération.

Étape 3 : repousser les tokens affinés vers le code

Une fois les variables stabilisées, on peut demander à l'agent de mettre à jour le design system dans la codebase avec les tokens affinés. Figma devient la source de vérité pour les décisions de design, et le code reste synchronisé.

Workflow 3 : explorer de nouvelles directions directement depuis le canvas

Quand l'utiliser : quand on veut rapidement explorer ou itérer sur des designs existants sans quitter Figma.

Pour beaucoup d'équipes, Figma est la source de vérité. Les designs existent déjà sur le canvas. Le défi n'est pas de partir de zéro, c'est de savoir comment avancer. Quand la recherche utilisateur fait remonter un problème sur un écran existant, la partie la plus difficile de l'itération est souvent de faire ce premier pas.

Ce workflow montre comment utiliser un agent pour générer une direction de départ avec les vrais composants de l'équipe, afin de pouvoir réagir à quelque chose de concret et l'affiner sur le canvas.

Étape 1 : définir le problème

On part d'un énoncé de problème clair, ancré dans la recherche ou les retours utilisateurs. Plus le prompt est précis, plus la sortie de l'agent sera utile.

Par exemple : un tableau de bord de revenus clients où l'état de renouvellement s'affiche comme un simple label texte en fin de chaque ligne. La recherche montre que les utilisateurs le ratent. Le problème à résoudre est de rendre l'état de renouvellement plus visible et plus facile à actionner.

Il existe souvent plusieurs approches valides : codage couleur, regroupement des lignes par statut, introduction d'une nouvelle hiérarchie visuelle. Voir des directions sur le canvas est ce qui fait avancer la conversation.

Étape 2 : générer une direction de départ avec l'agent

Dans l'agent, on lance le skill /figma-use. On inclut le contexte pertinent dans le prompt : insights de recherche utilisateur, problème précis, contraintes éventuelles, puis on demande à l'agent d'explorer une approche avec les composants existants.

L'agent produit une itération brute directement sur le canvas, construite avec les composants de production. L'objectif à ce stade n'est pas un design fini, c'est un point de départ concret sur lequel on peut réagir et affiner.

Étape 3 : affiner sur le canvas

On revoit ce que l'agent a produit et on s'en sert comme point de départ. Quelques éléments à évaluer :

• Est-ce que la solution change le principe organisateur du layout ? Grouper ou prioriser l'information différemment peut faire en sorte que les données critiques soient vues en premier, plutôt qu'après un balayage visuel.
• Est-ce que les bons composants sont utilisés ? L'agent doit piocher dans le design system. Si ce n'est pas le cas, on ajuste le prompt ou on remplace les composants manuellement.
• Qu'est-ce qui fonctionne, qu'est-ce qui ne fonctionne pas ? On réagit à ce qui est visible. L'agent dépasse le syndrome de la page blanche ; le designer et son équipe apportent le jugement de design.

Itérer directement sur le canvas plutôt que de prompter en boucle permet de passer rapidement de la discussion abstraite aux décisions concrètes et visibles.

Ce que ça change vraiment

Dans les trois workflows, le même schéma se répète : que le point de départ soit du code ou le canvas, l'agent prend en charge le travail d'assemblage mécanique. Le designer concentre son temps sur ce qui demande un oeil de designer.

Le serveur MCP de Figma peut être connecté de deux façons :

• via un serveur MCP distant (recommandé), qui se connecte directement à l'endpoint hébergé par Figma à https://mcp.figma.com/mcp,
• ou via un serveur MCP desktop qui tourne localement via l'application Figma, principalement pensé pour des cas d'usage spécifiques en entreprise.