Le plugin qu'on ne télécharge plus, on le décrit
Jusqu'ici, créer un plugin Figma sur mesure supposait de savoir coder. Il fallait connaître l'API du plugin, ou payer quelqu'un qui la connaît. Avec les Generative Plugins, annoncés à la Config 2026, cette barrière technique disparaît. On décrit l'outil dont on a besoin, et l'agent Figma génère un plugin qui s'exécute directement sur le canevas.
C'est une nouvelle brique du vibe coding appliqué au design. Une différence de taille la distingue d'un prompt classique : le résultat n'est pas une réponse jetable. C'est un outil qui reste dans votre fichier, et qu'on réutilise à volonté.
Comment ça marche, concrètement
La documentation officielle décrit un flux minimal. On ouvre l'onglet Agents dans la barre de navigation, puis on démarre une conversation. On tape « Build me a plugin », et on décrit le comportement attendu. L'agent écrit le code, l'exécute, et le plugin apparaît comme n'importe quel autre outil du fichier.
La formulation du prompt change tout
Le point de vigilance principal touche à l'intention. Selon les conseils de prompting officiels, il faut signaler explicitement qu'on veut un outil réutilisable. « Build me a plugin that generates button variants », par exemple, pas simplement « génère des variantes de bouton ». Sans cette précision, l'agent peut interpréter la demande comme une tâche ponctuelle, plutôt que comme la création d'un outil permanent.
Des cas d'usage très concrets
Les exemples publiés par Figma donnent une idée du niveau de granularité visé :
- un linter d'hygiène de calques qui détecte les calques sans nom, les groupes orphelins vides, l'imbrication redondante et les quasi-doublons de composants
- un plugin qui répète un motif botanique personnalisé sur un cadre entier
- un plugin dédié à un workflow déterministe de style d'icônes, exécuté à chaque nouvelle icône
Le fil conducteur : des tâches répétitives, bien définies, qu'on préfère automatiser une fois plutôt que refaire à la main à chaque fichier.
Plugin ou skill : ce n'est pas le même outil
Figma distingue explicitement deux registres. Un plugin convient quand le workflow est déterministe : la même entrée doit produire le même résultat à chaque exécution. Un renommage systématique, une génération de grille, un contrôle de contraste en sont de bons exemples. Une skill, à l'inverse, est le bon choix quand on veut que l'agent interprète le contexte. Elle fait des choix de jugement, et adapte son approche d'un prompt à l'autre.
Cette distinction évite une confusion fréquente depuis l'arrivée du Figma Agent et des connecteurs MCP. Tout ce qui ressemble à de l'IA générative sur le canevas n'a pas vocation à improviser. Un plugin généré reste du code fixe et prévisible. On peut l'auditer et le réutiliser sans craindre une réponse différente à la dixième exécution.
Ce que ça change pour un designer solo ou une petite équipe
L'avantage économique est net. Une fois construit, un plugin généré ne consomme plus de jetons à l'usage, et il voyage avec le fichier partagé au client. Pour une petite structure sans développeur dédié à l'outillage interne, c'est une opportunité concrète.
Elle permet de combler des trous d'automatisation qui, jusqu'ici, ne justifiaient jamais le coût d'un vrai développement. Trop spécifiques, trop mineurs, trop propres à un seul workflow : ce sont exactement les besoins que les Generative Plugins rendent enfin rentables à traiter. C'est un chantier qui s'inscrit dans une tendance plus large de compétences IA attendues du designer en 2026. Savoir décrire précisément un besoin d'outillage devient presque aussi utile que savoir manier Figma lui-même.
Un exemple de gain de temps réel
Prenons le linter d'hygiène de calques cité par Figma. Avant les Generative Plugins, cette vérification se faisait à la main, fichier par fichier, avant chaque livraison. Un designer solo n'a tout simplement pas le temps de le faire systématiquement. Un plugin généré une fois, réutilisé ensuite sur chaque projet, change la donne sans nécessiter le moindre budget de développement.
Où ça s'arrête
Un plugin généré reste un plugin. Il hérite des limites de l'API Figma, pas de capacités magiques supplémentaires. Pour un besoin complexe, multi-fichiers, ou qui doit s'intégrer à des systèmes externes au-delà du canevas, un développement classique reste plus indiqué. Une skill capable de raisonner au cas par cas peut aussi être la meilleure option, selon la nature du besoin.
La documentation « Behind the Build » de l'équipe Figma est explicite sur ce point. Les plugins générés visent des tâches bien cadrées, pas une refonte d'outillage entière. C'est un gain de vitesse sur le dernier kilomètre, pas un remplacement du développement sur mesure.
Un budget qui reste à surveiller malgré tout
« Gratuit à l'usage » ne veut pas dire gratuit à produire. Générer le plugin lui-même consomme des jetons, comme n'importe quelle requête à l'agent. Sur un plugin complexe, plusieurs itérations de prompt peuvent être nécessaires avant d'obtenir le comportement voulu. Le calcul reste favorable dès qu'un outil est réutilisé plus de quelques fois. Il ne faut pas confondre coût de création et coût d'usage. Ce sont deux lignes budgétaires distinctes, même si Figma communique surtout sur la seconde.
Conclusion
Les Generative Plugins déplacent le seuil d'entrée de l'automatisation Figma. Ce qui demandait hier un développeur ou un abonnement à un plugin tiers devient une conversation avec l'agent. Le vrai gain n'est pas la génération elle-même. C'est le fait qu'un outil ainsi créé reste gratuit à l'usage et embarqué dans le fichier. Reste à bien poser la question — déterministe ou contextuel, plugin ou skill — avant de lancer le prompt.
