Dans les coulisses du développement : plugins génératifs et shaders chez Figma

Nous avons intégré des plugins génératifs et des shaders au canvas car nous voulions vous offrir un moyen de concevoir les outils dont vous avez besoin, quand vous en avez besoin, qu'il s'agisse de générer des mises en page ou d'ajouter une distorsion de lentille. Depuis Config 2026, nous avons travaillé sans relâche pour étendre ces fonctionnalités, et nous sommes ravis de vous présenter ces nouveautés aujourd'hui :

• Publication communautaire et interne : publiez les plugins et les shaders que vous avez créés avec l'agent de conception Figma dans la communauté Figma ou en privé dans votre organisation si vous disposez d'un forfait Organisation ou Entreprise.
• Shaders animés et interactifs : l'agent peut désormais intégrer du mouvement et de l'interactivité à n'importe quel effet que vous décrivez.
• Accès au code : affichez et téléchargez le code sous-jacent à tout shader ou plugin que vous avez créé, afin de pouvoir éditer le code directement dans un agent tiers.
• Mises à jour MCP : utilisez le serveur MCP de Figma pour afficher et modifier les plugins génératifs et les shaders avec votre agent ou exportez les shaders vers un agent qui les implémente précisément dans du code React.

Ces mises à jour reflètent en miniature la manière dont on construit aujourd'hui : en collaboration avec l'IA, en passant avec fluidité de la conception au code et en travaillant ensemble sur le canvas. Je souhaite raconter comment nous avons lancé des plugins génératifs et des shaders, car la concrétisation de cette vision peut nous éclairer sur l'état actuel du design. Voici comment nous avons lancé l'idée, réuni la bonne équipe et créé quelque chose qui dépasse ce que chacun de nous aurait pu accomplir seul.

Vibe coding avec une vision

Je suis obsédé par l'idée d'apporter la puissance des shaders à Figma depuis des années maintenant. Mais ce n'est que récemment que les LLM ont facilité la démonstration (et pas seulement l'évocation) de ma vision. Pour commencer, j'ai développé par vibe coding un environnement WebGPU fonctionnant à la manière de Figma, permettant d'ajouter des effets de shader à n'importe quel calque du canvas – y compris des vecteurs, des calques 3D ou même des systèmes de particules. Je me suis concentré sur la conception de trois éléments clés :

• Composabilité, de sorte que la sortie d'un shader alimente le suivant.
• Ergonomie de l'éditeur, afin que vous puissiez appréhender concrètement le design grâce à des commandes générées dynamiquement d'une manière impossible avec de simples prompts.
• Création agentique, afin que les LLM puissent suggérer des paramètres que vous pouvez ajuster à votre guise.

Bien qu'il ait fallu des mois pour concevoir le flou progressif dans Figma Draw, je pouvais maintenant créer le même effet de shader avec un simple prompt – ou peut-être deux pour obtenir un résultat parfait. J'avais besoin de donner de l'élan à ce projet, mais je ne pouvais pas me contenter d'enregistrer une vidéo Loom, de la lancer sur Slack et de croiser les doigts. Il nous fallait encore un récit convaincant, un argumentaire et une équipe pour le concrétiser.

Assembler la bonne équipe

Je me suis tourné vers Yassir Solomah, ingénieur en rendu et animation, pour lui poser mes questions : cela allait-il vraiment fonctionner ? M'y prenais-je de la bonne manière ? Cela risquait-il de faire chuter les performances de Figma ? Après tout, l'approximation d'application de canvas WebGPU par vibe coding est bien loin de la véritable solution d'envergure industrielle reposant sur un rendu par tuiles. (Essayez de créer un canvas infini performant. C'est plus difficile qu'il n'y paraît.)

Heureusement, Yassir était partant. Nous avons supprimé mon système de shaders de fragment WebGL 2 pour le remplacer par un système de pipeline WebGPU, permettant ainsi aux shaders de devenir des programmes miniatures qui assurent le rendu d'objets 3D et appliquent une logique basée sur la position de la souris et le temps pour contrôler les éléments visuels au sein des calques. Avec cette architecture, nous pouvions isoler les scripts de génération graphique dans leurs propres sandbox, tout en exploitant toute la puissance de WebGPU. Cela se traduisait par une sécurité accrue pour les scripts exécutés par les utilisateurs, ainsi que par la prise en charge de la logique, des systèmes de particules, des shaders de calcul, de la 3D, et bien plus encore.

Yassir a validé mon prototype en en produisant des versions fonctionnelles dans Figma Design. C'est alors que Georgia Rust, product manager, a eu vent de notre idée. Ayant une vue d'ensemble de ce qui se passe chez Figma, elle a su articuler nos efforts avec les projets des autres équipes et nous obtenir les ressources nécessaires pour concrétiser le tout. Par exemple, à peu près au même moment, le designer produit Jason Calleiro partageait des prototypes de plugins adaptatifs et génératifs dans Figma Design. Georgia nous a encouragés à unir nos forces autour des outils génératifs : une suite de méthodes permettant d'utiliser des agents sur le canevas pour créer, à la volée, des plugins et des shaders personnalisés.

Au fil de quelques séances de planification, Georgia, Yassir et moi avons fait évoluer notre idée, passant de quelques démonstrations à une présentation solide capable de convaincre la direction. J'ai réalisé une démonstration en direct de la possibilité de produire des effets de shader à l'aide d'agents, incluant des poignées sur le canvas et des commandes dynamiques. Yassir a complété cette présentation en détaillant l'implémentation du cœur du système, le modèle de sécurité et la manière dont nous allions garantir de bonnes performances. Georgia a exposé les priorités de développement, les partenaires associés et les perspectives d'évolution futures. Notre présentation a convaincu, et nous avons obtenu le feu vert. La date de lancement ? Config Nous avions deux mois pour concrétiser notre projet.

J'ai conçu un logo d'équipe inspiré des années 80 qui combinait outils et effets génératifs, symbolisé par la clé anglaise et l'éclair. L'arc-en-ciel illustre le caractère quasi magique de la génération de prompt, tandis que l'inclinaison vers l'avant évoque la dynamique et l'accélération.

Découvrir de nouvelles façons de concevoir

Disposant de très peu de temps pour le développement, nous sommes revenus à l'essentiel : pas de fiches techniques ni de revues critiques formelles et privilégier le prototypage et les démonstrations aux processus de validation classiques. Nos ingénieurs et nos designers ont rejoint un immense canal Slack et nous faisions chaque semaine une présentation aux principaux sponsors. À mesure que nous avons commencé à faire des démonstrations lors des réunions d'entreprise, nous avons pris de l'élan et notre équipe initiale de 15 personnes a commencé à s'agrandir.

Les plugins génératifs et les shaders partageaient une infrastructure commune : des éléments dynamiques et itératifs, pilotés par du code et basés sur des prompts, destinés à figurer dans notre nouvelle barre latérale d'outils. Bien que les plugins allaient utiliser l'API existante, nous voulions qu'ils s'intègrent naturellement à l'univers de Figma et reprennent les modèles auxquels les designers étaient habitués. Les shaders nécessiteraient une toute nouvelle API. J'ai donc conçu PropsKit, un kit UI Figma basé sur des composants web que les agents pouvaient utiliser.

Fort de mes succès avec le vibe coding, je voulais que chaque conception commence par un prototype fonctionnel. Je pensais que cela nous permettrait d'avancer plus vite, de nous faire une idée de l'expérience et de fournir aux développeurs une base concrète sur laquelle concevoir. Il s'est avéré que, si les prototypes créés par vibe coding constituaient d'excellents outils pour les designers – nous permettant de valider et de remettre en question nos propres hypothèses, ils ne constituaient pas des références utiles pour les développeurs, les PM et les parties prenantes.

Nous avons donc changé d'approche. Nous avons élaboré des maquettes statiques dans Figma pour présenter une vue éclatée de tous les états possibles et parvenir à un consensus sur les fonctionnalités clés en amont. Nous sommes ensuite passés à des prototypes de code fonctionnels pour tester et affiner les meilleures solutions, en évitant les allers-retours habituels entre l'attente de l'implémentation, le retour à la phase de conception, la réimplémentation et les tests. Ces prototypes nous ont permis de parvenir plus rapidement à de meilleures solutions, sans gaspiller le temps précieux de nos ingénieurs. J'ai même écrit du code de production dans la base de code de Figma et soumis quelques demandes d'extraction. Notre canal Slack était en pleine effervescence, rythmé par les démonstrations, les revues de demandes d'extraction et les décisions prises sur le vif. L'énergie était palpable.

Franchir la ligne d'arrivée

Deux semaines avant Config, nous avions parcouru 90 % du chemin, mais les 10 % restants constituaient l'étape la plus difficile. Nous avancions si vite que nos dirigeants et nos sponsors examinaient des versions déjà obsolètes. Il y a eu des moments où l'on aurait pu croire que ce projet allait finir au rebut.

Nous avons communiqué rapidement et fréquemment, pris des décisions instinctives et élaboré des solutions sur le vif. Les mises en page des plugins ne sont pas tout à fait au point ? Nous avons créé trois nouveaux composants UI qui ont facilité la prise de décision de l'agent. Les contrôles de propriétés personnalisés pour les palettes de couleurs ont nécessité trois jours de développement supplémentaires ? Nous avons opéré une sélection drastique et opté pour une liste restreinte dans l'intervalle. Le design avait besoin d'être peaufiné ? Nous avons ouvert une demande d'extraction. En tant que designer et fondateur de ce projet, j'ai trouvé particulièrement difficile de faire des coupes, mais j'ai dû apprendre à mettre certains éléments de côté et à en privilégier d'autres pour franchir la ligne d'arrivée.

Lorsque Georgia et moi sommes montés sur scène pour le discours préliminaire de Config afin de présenter les plugins génératifs et les shaders, nous représentions le travail acharné d'une équipe incroyable ainsi qu'une toute nouvelle façon de travailler.

Ce projet nous a également appris à utiliser Figma de nouvelles manières, réduisant ainsi les frictions entre le design et la production. Notre microsite Config pour les shaders, par exemple, a largement utilisé notre serveur MCP de Figma. À notre époque, un ingénieur exécutant un agent local s'attend à pouvoir lire le design via notre MCP avec get_design_context. Le code sur le canvas, en d'autres termes, n'est pas si différent du design sur le canvas. Nous avons conçu des shaders exportables en HTML et pour React, et nous sommes fiers de les inclure dans les mises à jour que nous lançons aujourd'hui.

Je suis impatient que vous essayiez nos fonctionnalités. Nous travaillons sans relâche pour mettre davantage de possibilités d'expression et d'outils pratiques à portée de votre main, et nous avons hâte de voir ce que vous partagerez avec le monde.

Lancez-vous avec notre fichier d'expérimentation pour les plugins génératifs et les shaders. Quiconque ayant accès à l'agent de conception Figma peut créer des plugins génératifs et des shaders. L'agent est disponible en version bêta ouverte dans tous les forfaits pour les utilisateurs disposant d'une licence Full. Les utilisateurs disposant d'une licence Collab, Dev et View peuvent utiliser l'agent dans leurs brouillons. L'agent est gratuit pendant la période bêta, mais commencera à consommer des crédits d'IA dans quelques semaines.