TalkToFigma : faire piloter Figma par un agent MCP

Le problème : un agent qui ne voit que du texte

Un agent de code comme Cursor ou Claude Code travaille sur des fichiers. Un fichier Figma n'en est pas un : c'est un document binaire manipulé par l'application, avec des nœuds, des styles, des instances de composants et des overrides. L'agent ne peut donc ni lire la structure réelle d'une maquette, ni la modifier, sauf à passer par une API. TalkToFigma comble cet écart en exposant Figma comme un ensemble d'outils MCP que l'agent appelle en langage naturel. Le public visé est précis : des designers ou des développeurs qui pilotent déjà un agent dans leur éditeur et qui veulent automatiser des tâches répétitives sur un fichier Figma ouvert. Le README cite deux cas concrets, tous deux contribués : le remplacement de texte en masse et la propagation d'overrides d'instances depuis une instance source vers plusieurs cibles. Ce sont des tâches où l'on clique normalement des dizaines de fois.

Trois processus et un canal nommé

L'architecture tient en trois morceaux, décrits dans la section Project Structure. Un serveur MCP en TypeScript vit dans src/talk_to_figma_mcp/. Un plugin Figma vit dans src/cursor_mcp_plugin/. Entre les deux, src/socket.ts fait office de serveur WebSocket. Le flux est le suivant : l'agent appelle un outil MCP, le serveur relaie la commande par le WebSocket, le plugin l'exécute dans Figma et renvoie le résultat par le même chemin. Le point important, et il est facile à manquer, c'est le canal. Le plugin ne se connecte pas tout seul : l'utilisateur doit le joindre à un canal via l'outil join_channel. Sans cette étape, le serveur MCP parle dans le vide. Cette contrainte a un mérite : plusieurs instances de Figma peuvent coexister sur la même machine, chacune sur son canal, et l'agent n'adresse que celle qui l'intéresse. Elle a un coût : rien dans le matériel fourni ne décrit ce qui se passe si deux plugins rejoignent le même canal.

Ce que l'agent peut réellement faire sur le document

La liste d'outils est longue et couvre plusieurs familles. Côté lecture : get_document_info, get_selection, read_my_design (qui agit sur la sélection courante sans paramètre), get_node_info et get_nodes_info pour interroger un ou plusieurs nœuds par identifiant. Côté écriture : create_rectangle, create_frame, create_text, set_fill_color, set_stroke_color, set_corner_radius, move_node, resize_node, clone_node, delete_node. Côté auto-layout, cinq outils distincts : set_layout_mode, set_padding, set_axis_align, set_layout_sizing et set_item_spacing. Il y a aussi de quoi manipuler les composants (get_local_components, create_component_instance, get_instance_overrides, set_instance_overrides) et les annotations, avec set_annotation qui accepte du markdown. Cette granularité est un choix : l'agent ne dispose pas d'un outil fourre-tout mais de primitives. Cela le rend plus prévisible, au prix d'un nombre d'appels plus élevé pour une même tâche.

Mise en route : Bun, un socket, un manifest

Le README donne une séquence courte. On installe Bun, puis on lance bun setup, qui installe aussi le serveur MCP dans le projet Cursor actif. On démarre ensuite le WebSocket avec bun socket. Le plugin s'installe soit depuis la page de la communauté Figma, soit localement via Plugins > Development > New Plugin, puis Link existing plugin en pointant sur src/cursor_mcp_plugin/manifest.json. Pour une configuration manuelle, on déclare le serveur dans ~/.cursor/mcp.json sous la clé mcpServers avec l'entrée TalkToFigma, command bunx et args ["cursor-talk-to-figma-mcp@latest"]. En développement local, on remplace par command bun et args ["/path-to-repo/src/talk_to_figma_mcp/server.ts"]. Une note Windows + WSL existe : elle demande de décommenter hostname: "0.0.0.0" dans src/socket.ts avant de relancer bun socket. Ce détail est un vrai point de friction, car il élargit l'écoute du socket au-delà de la boucle locale, et le README ne dit rien des conséquences.

Le cas où l'outil est le mauvais choix

TalkToFigma suppose une session interactive. Il faut Bun installé, un serveur WebSocket qui tourne, Figma ouvert et le plugin connecté à un canal. Aucun de ces éléments n'est décrit comme scriptable en CI, et le README ne mentionne ni exécution sans interface, ni authentification, ni gestion de plusieurs utilisateurs. Pour générer des maquettes dans un pipeline automatisé, ou pour travailler sur un fichier sans ouvrir Figma, ce montage n'est pas le bon. Il y a une seconde limite, plus discrète. Les outils modifient le document ouvert, et la liste inclut delete_node et delete_multiple_nodes. Le README ne documente ni annulation, ni journal des modifications, ni confirmation avant suppression. Un agent qui se trompe de nœud supprime donc pour de bon, et la seule protection reste l'historique de versions de Figma, que le projet n'évoque pas. Enfin, l'absence de release publiée dans les données du dépôt signifie que la commande bunx ...@latest pointe vers ce que le main contient au moment de l'installation.

Face à une intégration REST directe

L'alternative évidente est d'écrire soi-même un client contre l'API REST de Figma, ou de passer par un plugin maison. La différence d'approche est nette. Une intégration REST travaille sur des fichiers identifiés par clé, avec un jeton d'accès, sans Figma ouvert, et convient donc à des traitements par lots ou planifiés. TalkToFigma fait l'inverse : il agit sur le document en cours d'édition, dans la session de l'utilisateur, et c'est précisément ce qui permet à l'agent de raisonner sur ce que le designer a sous les yeux (sélection courante, nœud focalisé via set_focus). L'API REST ne connaît pas la notion de sélection. En contrepartie, elle n'exige ni plugin, ni canal, ni serveur local. Le choix se joue donc sur une question simple : la tâche dépend-elle de l'état courant de l'éditeur, ou d'un fichier que l'on peut adresser à distance ?

Coût de maintenance et cadre de licence

Le dépôt est publié sous MIT, ce qui autorise la réutilisation et la modification avec conservation de la mention de licence. Le README ne contient aucune clause additionnelle, et je ne peux pas en dire plus sur les conditions exactes : à vérifier dans le fichier LICENSE du dépôt, car ce texte n'est pas un avis juridique. Côté maintenance, plusieurs signaux comptent. Le code est en JavaScript et TypeScript, avec Bun comme runtime et gestionnaire de paquets, ce qui ajoute une dépendance à un outil encore jeune dans certaines équipes. La surface d'outils MCP est large, donc toute évolution de l'API de plugin Figma se répercute sur plusieurs fichiers. Les données du dépôt ne montrent aucune release, donc pas de version épinglée ni de notes de version à consulter avant une mise à jour. La fonctionnalité de remplacement de texte en masse et celle de propagation d'overrides viennent de contributeurs externes, ce qui indique un projet ouvert aux patches mais aussi des zones dont la maintenance dépend de leurs auteurs.

Conclusion éditoriale

À adopter si vous voulez qu'un agent lise et modifie un fichier Figma par lots (textes, auto-layout, overrides d'instances) et que vous acceptez de garder un serveur WebSocket et le plugin ouverts pendant la session. À éviter si vous cherchez une intégration sans canal local, ou si votre équipe travaille derrière un réseau qui bloque le port. Avant de vous engager, vérifiez trois choses dans le dépôt : la valeur de hostname dans src/socket.ts, la présence d'un manifest.json dans src/cursor_mcp_plugin/, et le fait qu'aucune release n'est publiée, ce qui vous place sur le tag latest de bunx.

Sources officielles

1. grab/cursor-talk-to-figma-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README