Les fonctionnalités d’agent de Figma placent les règles de conception entre l’IA et le canevas

Figma a présenté de nouvelles fonctionnalités d’agent Figma qui donnent aux équipes davantage de contrôle sur les résultats produits par l’IA, malgré le comportement imprévisible de cette technologie. La mise à jour relie les agents à des spécifications écrites, des bibliothèques de conception, des sources de code et des prototypes fonctionnels au sein d’une même plateforme.

Il ne s’agit pas simplement d’un assistant disposant de davantage de commandes. Figma cherche à définir l’environnement opérationnel qui entoure les agents avant que les interfaces générées ne se propagent dans les équipes produit. Son pari est que le contexte partagé, le travail visible et des règles de conception applicables comptent davantage qu’une génération sans contraintes.

Cette position place Figma entre les designers et des agents de codage externes tels que Claude Code, Codex, GitHub Copilot et Cursor. Plutôt que de concurrencer uniquement les performances des modèles, Figma veut faire de son canevas le plan de contrôle où les équipes décident de ce que les agents doivent construire.

Les nouvelles fonctionnalités d’agent de Figma définissent les règles avant la génération

Figma déplace le contrôle des agents des prompts individuels vers une infrastructure produit partagée.

L’entreprise a annoncé ce flux de travail élargi lors de son premier événement Config en Inde. L’ajout central est Figma Specs, un espace de travail basé sur Markdown permettant de consigner les exigences produit, les décisions, les références et le contexte technique.

Une spécification peut exister comme son propre fichier Figma ou accompagner le travail sur le canevas. Les équipes peuvent référencer des conceptions, des diagrammes FigJam, des couches de code et d’autres éléments sans tout réduire à du texte détaché.

Cette structure est importante, car un agent échoue rarement uniquement à cause d’une faible génération de langage. Il lui manque souvent les liens entre une exigence, un composant visuel, une implémentation en code et une décision antérieure de l’équipe.

Un fichier Markdown classique peut décrire ces relations, mais ne les préserve pas automatiquement. Les liens deviennent obsolètes, les images perdent leur contexte et différents fichiers peuvent présenter des instructions contradictoires.

Figma Specs est conçu pour rendre ces connexions natives. Selon la présentation du lancement de l’entreprise, les équipes peuvent transformer des idées approximatives en spécifications détaillées et les transmettre à des agents de codage via le serveur MCP de Figma.

Le Model Context Protocol, ou MCP, est une norme qui permet aux systèmes d’IA de se connecter à des outils externes et à un contexte structuré. Dans l’implémentation de Figma, il peut faire circuler les informations produit entre le canevas et les agents de développement pris en charge.

Le flux de travail commence avant qu’un agent n’écrive du code. Une équipe peut réunir des exigences, des diagrammes, des références de conception et du contexte de code dans une spécification, puis utiliser ce matériau pendant la génération.

Le même contexte peut prendre en charge une couche de code, c’est-à-dire un prototype interactif reposant sur du code exécuté sur le canevas Figma. Le prototype peut ainsi être inspecté aux côtés des conceptions et des décisions qui l’ont produit.

Figma a également étendu les informations disponibles via les systèmes de conception. Les équipes peuvent ajouter des directives écrites aux bibliothèques publiées et connecter des sources de code provenant de dépôts GitHub ou de packages npm.

Les directives peuvent documenter des règles, des modèles privilégiés, des traitements interdits et des détails d’implémentation. Les agents peuvent consulter ce matériau lorsqu’une bibliothèque pertinente est activée.

Les sources de code ajoutent une autre couche d’ancrage. Elles donnent à un agent accès à des composants implémentés, au lieu de le forcer à déduire chaque élément d’interface à partir de captures d’écran ou de maquettes visuelles.

Cette combinaison crée une hiérarchie de contexte. Les spécifications décrivent ce qu’une équipe entend construire, les bibliothèques de conception définissent son langage visuel et les sources de code montrent comment les éléments fonctionnent dans le logiciel.

L’annonce concernant les agents a également mis en avant une gestion centralisée des bibliothèques de conception, des bibliothèques de code et des directives. Figma indique que les agents peuvent consulter ce système lors de la création ou de la modification de travaux.

Ces contrôles répondent à un problème récurrent des interfaces génératives. Un modèle peut produire un écran convaincant tout en ignorant les règles de composants, les modèles d’interaction ou les pratiques d’accessibilité de l’organisation.

Un résultat soigné n’est pas nécessairement un résultat produit valide. Il peut sembler correct tout en créant des composants dupliqués, des états non pris en charge ou un travail d’implémentation que les développeurs devront ensuite remplacer.

La réponse de Figma n’est pas d’éliminer les prompts. Elle consiste à les entourer d’un contexte durable appartenant à l’équipe, plutôt qu’à la personne qui ouvre une conversation.

Cela change le rôle du prompt lui-même. Il devient une demande au sein d’un espace de travail gouverné, et non la seule instruction séparant un agent du produit.

Les couches de code Figma apportent le logiciel en fonctionnement sur le canevas

Les couches de code Figma transforment le canevas en un espace où l’on teste les comportements, et non seulement où l’on examine des représentations visuelles.

Les couches de code sont passées d’une bêta fermée à une bêta ouverte dans le cadre de cette mise à jour. Figma indique que la fonctionnalité est progressivement déployée dans ses différentes offres, bien que chaque compte puisse y accéder à des moments différents.

Une couche de code contient une interface fonctionnelle soutenue par du code exécuté. Les équipes peuvent la placer à côté de maquettes conventionnelles, la dupliquer, tester différentes orientations et inspecter les états interactifs.

La distinction est importante. Les prototypes traditionnels peuvent simuler un parcours entre des maquettes liées, mais ils ne représentent pas nécessairement le comportement d’un véritable composant.

Une implémentation en fonctionnement peut révéler les comportements de chargement, les états vides, les erreurs, les mises en page responsives et des interactions complexes. Ces détails font souvent émerger des questions produit que les écrans statiques laissent sans réponse.

Le guide des couches de code décrit plusieurs points de départ. Les utilisateurs peuvent générer une couche via l’agent Figma, convertir une conception, importer du code ou partir d’une base de code existante de l’équipe.

Un designer pourrait sélectionner un parcours de paiement établi et demander à l’agent d’ajouter une autre option de livraison. La couche de code obtenue pourrait montrer les comportements de validation, de chargement, de réussite et d’échec.

L’équipe pourrait ensuite dupliquer cette version et tester une autre interaction à côté. Les chefs de produit, designers et ingénieurs compareraient des options fonctionnelles dans un même fichier partagé.

Figma indique que les modifications peuvent revenir dans la couche de code et, dans les flux de travail pris en charge, dans la base de code connectée. Cette promesse reste plus importante qu’un simple export de conception vers le code.

Un export est généralement un artefact de transmission. Une couche de code connectée est conçue pour rester intégrée à une boucle itérative entre l’exploration de la conception et l’implémentation.

Figma a présenté pour la première fois les couches de code en bêta fermée en juin 2026. Son précédent aperçu du canevas prenait en charge les imports GitHub, les dossiers locaux, les modèles, les résultats de Figma Make et les points de départ générés par des agents.

La bêta ouverte étend ce modèle à un public plus large. Elle constitue aussi un test plus vaste pour déterminer si la collaboration soutenue par le code fonctionne au-delà d’équipes soigneusement sélectionnées.

Le cas d’usage immédiat n’est pas l’expédition automatique de code généré. Il s’agit de rendre le code suffisamment peu coûteux pour être utilisé pendant la découverte produit.

La directrice du design de Figma, Loredana Crisan, a décrit un écart croissant entre la création de code et les mises en production réelles. Elle a déclaré à TechCrunch que les organisations produisent 17 fois plus de code, tandis que les mises en production n’ont augmenté que de 1,3 fois.

Ces chiffres sont fournis par l’entreprise et ne doivent pas être considérés comme une référence indépendante pour le secteur. Ils expliquent néanmoins la stratégie qui sous-tend les couches de code Figma.

Le code généré est de plus en plus utilisé pour explorer des possibilités qui n’atteignent jamais la production. Figma veut que ce travail exploratoire se déroule là où les équipes peuvent le voir, en discuter et le perfectionner ensemble.

Cela recadre le code, qui passe d’un médium d’implémentation final à un matériau de conception. Les équipes produit peuvent utiliser un logiciel fonctionnel pour préciser ce qu’elles doivent construire avant de s’engager dans une architecture de production.

Cette approche reconnaît également que les sessions d’agents en terminal sont souvent difficiles à partager. Un développeur peut générer rapidement plusieurs interfaces, mais les collaborateurs ne reçoivent parfois qu’un lien ou un enregistrement par la suite.

Ce processus masque les alternatives, les prompts et les compromis derrière le résultat. Amener une version fonctionnelle sur le canevas rend l’exploration visible et plus facile à remettre en question.

Toutefois, la visibilité ne rend pas le code de prototype prêt pour la production. Les équipes ont toujours besoin de revues d’ingénierie, de tests, de contrôles de sécurité, de validation de l’accessibilité et d’une architecture maintenable.

La valeur des couches de code dépend donc de la manière dont les équipes classent leurs résultats. Utilisées comme artefact exploratoire, elles peuvent raccourcir les boucles de retour sans prétendre que les prototypes générés sont des logiciels terminés.

Le véritable affrontement oppose le contexte partagé aux conversations isolées avec les agents

Figma parie qu’un contexte gouverné comptera davantage que l’agent qui génère le plus rapidement la première ébauche.

Le principal adversaire dans cette histoire n’est pas un autre fournisseur de conception. C’est le flux de travail isolé avec les agents, qui place le travail produit dans des conversations privées, des terminaux ou des sessions de navigateur déconnectées.

Les agents de codage génèrent déjà des interfaces à partir de texte et d’images. Leur rapidité crée un nouveau problème de coordination lorsque chaque participant travaille à partir d’instructions et d’un contexte local différents.

Un designer peut joindre la dernière bibliothèque de composants. Un développeur peut utiliser une ancienne branche du dépôt, tandis qu’un chef de produit fournit des exigences copiées depuis un document distinct.

Chaque agent peut renvoyer une réponse plausible. Les résultats peuvent néanmoins entrer en conflit parce que les systèmes n’ont jamais reçu la même source de vérité.

Figma Specs tente de réduire cette fragmentation en donnant au contexte un emplacement visible. Il conserve les exigences près des diagrammes, des conceptions, des couches de code et des décisions auxquels elles font référence.

L’extension du système de conception s’attaque à un problème connexe. Figma veut que les agents comprennent non seulement les composants disponibles, mais aussi les règles qui gouvernent leur utilisation.

Une bibliothèque peut contenir plusieurs variantes de boutons sans préciser laquelle convient à une action destructive. Les directives peuvent fournir cette logique de décision manquante.

De même, l’accès aux sources de code peut montrer à un agent si un composant existe déjà. Cela peut réduire la tentation de générer un remplacement visuellement similaire au comportement incompatible.

L’agent existant de Figma prend désormais en charge la recherche dans les fichiers, l’ajout de contenu de plateforme, le référencement d’éléments de bibliothèque et l’exécution simultanée de plusieurs prompts. Sa documentation sur les agents distingue également l’agent intégré des clients MCP externes.

L’agent intégré fonctionne directement dans les fichiers de conception. Les agents externes peuvent utiliser les capacités d’écriture sur le canevas de Figma pour importer dans la plateforme du contenu provenant de bases de code ou d’autres projets d’IA.

Cette distinction permet à Figma de prendre en charge plusieurs agents sans exiger qu’un seul assistant traite chaque tâche. L’entreprise peut rester la couche partagée sous un ensemble évolutif de modèles et d’outils de développement.

Selon l’entreprise, sa prise en charge de MCP comprend désormais plus de 20 nouveaux partenaires. La liste annoncée inclut OpenCode, Dia, Meta Muse et la startup indienne d’IA Sarvam.

Figma avait déjà cité Claude Code, Codex, GitHub Copilot et Cursor comme exemples d’agents externes capables d’écrire dans des fichiers. L’élargissement de la prise en charge des partenaires fait de la neutralité vis-à-vis des modèles un élément de la stratégie de la plateforme.

Cette position est défendable, car les classements des modèles évoluent rapidement. Une équipe peut préférer un agent pour le code d’interface et un autre pour la recherche, la documentation ou la génération d’images.

Figma n’a pas besoin de remporter chaque comparaison de modèles si l’entreprise contrôle le contexte partagé du produit. Elle doit amener les agents à traiter les fichiers, bibliothèques et règles de Figma comme des sources d’autorité.

La mise à jour MCP du canevas de l’entreprise rend cette ambition explicite. Les compétences peuvent indiquer à des agents externes comment exécuter des workflows, enchaîner les étapes et respecter les conventions de l’équipe.

Ici, une compétence est un ensemble d’instructions réutilisable qui façonne le comportement d’un agent. Elle peut encoder des connaissances opérationnelles qui resteraient autrement dans l’historique des prompts d’un seul employé.

Une équipe de systèmes de design pourrait créer une compétence pour construire des formulaires. Les instructions pourraient exiger des composants de champ approuvés, des libellés accessibles, des états de validation documentés et des jetons d’espacement spécifiques.

Un agent de programmation externe pourrait alors appliquer ces règles lors de la création ou de la mise à jour d’éléments. Le canevas de Figma afficherait le travail résultant là où l’ensemble de l’équipe collabore déjà.

Cela ressemble à une base de connaissances d’ingénierie structurée, mais le contexte est directement attaché aux artefacts du produit. La différence réside dans l’endroit où les décisions deviennent exploitables.

La concurrence émergente porte donc sur l’orchestration. Les outils de design, éditeurs de code, dépôts et systèmes de documentation cherchent tous à devenir l’endroit où les agents reçoivent un contexte fiable.

Figma dispose d’un avantage, car de nombreuses décisions d’interface vivent déjà sur son canevas. Mais cet avantage ne tient que si la plateforme maintient la synchronisation de ces décisions avec le code de production.

Des agents prévisibles dépendent toujours d’entrées imparfaites

Figma peut encadrer le comportement des agents, mais ne peut pas garantir que chaque règle soit complète, à jour ou correctement interprétée.

L’entreprise introduit ces contrôles car l’IA générative reste non déterministe. La même demande peut produire des structures, détails et choix d’implémentation différents selon les exécutions.

Les directives peuvent réduire cette variabilité. Elles ne peuvent pas l’éliminer, en particulier lorsque les instructions se contredisent ou ne couvrent pas une situation nouvelle.

Une équipe peut demander à un agent d’utiliser un composant privilégié alors que son dépôt connecté contient deux implémentations. La bibliothèque de design peut identifier une version, tandis que le code de production dépend d’une autre.

Les spécifications introduisent une autre obligation de maintenance. Une spécification bien structurée n’aide que lorsque ses exigences reflètent les décisions actuelles.

Un contexte obsolète peut rendre un agent systématiquement erroné. Cet échec est plus dangereux qu’une hallucination évidente, car le résultat peut sembler encadré et fiable.

Les équipes de systèmes de design devront définir des règles de responsabilité pour les instructions destinées aux agents. Elles devront décider qui peut publier des directives, connecter des sources de code, résoudre les conflits et approuver les changements.

Figma présente en avant-première une gestion centralisée des systèmes de design avec des cartes et des contrôles système. Ces outils visent à révéler les dépendances et les lacunes, y compris les descriptions ou états d’interaction manquants.

Cette couche administrative est nécessaire car l’accès des agents augmente les conséquences d’une documentation système insuffisante. Un composant non documenté était autrefois plus difficile à utiliser correctement pour les humains.

Désormais, un agent peut reproduire le malentendu sur de nombreux écrans en quelques minutes. Une génération plus rapide amplifie autant les bons standards que ceux qui ont été négligés.

Le contrôle d’accès soulève une autre préoccupation. Connecter les agents aux designs, spécifications, dépôts et services externes élargit la surface qui contient des informations propriétaires sur le produit.

Figma indique que la capacité MCP bénéficie de ses contrôles de sécurité et de fiabilité. Les équipes d’entreprise devront toutefois examiner les autorisations, la rétention des données, les clients connectés et l’accès aux dépôts.

La plateforme permet aux administrateurs de désactiver les fonctionnalités d’IA, mais les contrôles disponibles peuvent être trop larges pour certaines organisations. Selon la documentation d’assistance de Figma, désactiver les couches de code peut également désactiver d’autres fonctionnalités d’IA.

Les équipes pourraient souhaiter des politiques plus fines selon la sensibilité du projet, le dépôt, le fournisseur de modèles ou le rôle de l’utilisateur. L’efficacité de la gouvernance dépendra de l’évolution de ces contrôles.

L’adoption reste également incertaine. Les designers peuvent apprécier l’exploration soutenue par le code sans vouloir maintenir des instructions pour agents ni résoudre les problèmes de dépôts importés.

Les développeurs peuvent résister à des structures générées qui paraissent convaincantes mais entrent en conflit avec l’architecture établie. Les chefs de produit peuvent créer des spécifications détaillées qui deviennent un document de plus à synchroniser.

Les premières discussions d’utilisateurs ont déjà soulevé des questions sur les importations de dépôts, les erreurs d’infrastructure et le fait de savoir si les fonctionnalités d’IA détournent l’attention de demandes de produit anciennes. Ces anecdotes ne permettent pas d’établir la qualité globale du produit.

Elles montrent néanmoins ce que la bêta ouverte doit tester. Figma doit prouver que les couches de code fonctionnent de manière fiable avec de vrais dépôts et les contraintes quotidiennes des équipes.

La plateforme fait aussi face à un risque conceptuel. Combiner exigences, design, code, contenu et contrôles des agents peut réduire la fragmentation, mais peut également rendre Figma lui-même plus complexe.

Un canevas partagé réussit lorsque chaque participant peut comprendre l’état pertinent sans maîtriser tous les systèmes sous-jacents. Trop de surfaces qui se chevauchent recréeraient le problème de coordination au sein d’un même produit.

Les affirmations de Figma concernant une génération de meilleure qualité et mieux alignée sur la marque exigent également des preuves indépendantes. L’entreprise a montré comment le contexte entre dans le workflow, et non avec quelle régularité les agents le respectent.

Les équipes devraient mesurer les résultats plutôt que de les présumer. Parmi les indicateurs utiles figurent la réutilisation des composants, les défauts d’accessibilité, le travail de reprise, le temps de revue et les écarts entre les prototypes et le code de production.

La question centrale n’est pas de savoir si un agent peut générer un écran attrayant. Elle est de savoir si cet écran résiste au contact d’un véritable système de design et d’une véritable base de code.

Figma Specs étend la plateforme au-delà des fichiers de design

Specs transforme la stratégie d’agents de Figma en une ambition plus large : maîtriser les décisions produit avant et après le canevas.

Une spécification produit a traditionnellement vécu dans un outil documentaire, un système de tickets ou un dépôt. Le travail visuel passait ensuite dans Figma, tandis que l’implémentation technique se déroulait ailleurs.

Chaque transition créait une étape de traduction. Les exigences pouvaient perdre des nuances, les designs pouvaient s’écarter du comportement approuvé et les développeurs pouvaient interpréter différemment des notes de transmission incomplètes.

Figma Specs remet en cause cette séparation. Il traite Markdown comme un support flexible tout en l’intégrant au réseau d’artefacts visuels et techniques de Figma.

Un chef de produit peut rédiger une exigence et référencer un diagramme FigJam. Un designer peut connecter les écrans pertinents, tandis qu’un ingénieur peut ajouter du contexte de code depuis GitHub.

Un agent peut ensuite utiliser le matériau combiné pour créer une couche de code ou transmettre la spécification via MCP. La spécification devient une entrée active, plutôt qu’un document examiné uniquement par des personnes.

Cela élargit le workflow adressable de Figma. La plateforme ne se limite plus à créer des designs d’interface et à les transmettre aux équipes de développement.

Elle veut participer à la définition du produit, au prototypage, au contexte d’implémentation et aux opérations de contenu. Chaque surface supplémentaire rend le contexte partagé plus précieux pour les agents.

L’intégration de Payload par Figma renforce cette orientation. Payload est un système de gestion de contenu headless open source qui a rejoint Figma en 2025.

La nouvelle intégration relie Payload à Figma Make, le créateur d’applications et de sites web de la plateforme basé sur des prompts. Les équipes peuvent créer des expériences alimentées par les données et gérer le contenu sans dissocier le prototype visuel de son modèle de contenu.

Figma indique que les téléchargements de Payload ont été multipliés par six au cours des 12 mois précédents. Il s’agit d’une mesure communiquée par l’entreprise, qui ne révèle pas combien de projets utilisent la nouvelle intégration.

Pourtant, cette combinaison répond à une limite pratique des sites web générés. Une page soignée devient moins utile lorsque le contenu reste codé en dur ou déconnecté des workflows de publication.

Payload fournit le stockage de contenu, des API, des workflows et une interface administrative. Figma affirme que les équipes marketing peuvent gérer le contenu tandis que les développeurs conservent l’accès au framework open source.

Cela précise également la distinction entre construire pour explorer et construire pour livrer. Un prototype jetable n’a besoin que d’un comportement suffisant pour tester une idée.

Un site de production exige du contenu persistant, des autorisations, des structures de données et des workflows opérationnels. L’intégration d’un CMS rapproche Figma Make de cette seconde catégorie.

L’entreprise veille à préserver une voie de sortie. Elle indique que les équipes peuvent sortir de Figma leur travail basé sur Payload, ce qui compte pour les développeurs préoccupés par le verrouillage de plateforme.

Toutefois, la portabilité doit être évaluée à travers des projets réels. Un code exportable n’est pas automatiquement facile à maintenir sans l’environnement qui l’a généré.

La stratégie plus large exerce une pression sur plusieurs catégories à la fois. Les outils documentaires hébergent les spécifications, les agents de programmation génèrent des implémentations et les créateurs de sites web associent édition visuelle et déploiement.

Figma ne les remplace pas tous par un seul modèle. L’entreprise tente de devenir le socle partagé où leurs résultats se connectent.

Cette approche correspond au modèle de collaboration existant de l’entreprise. Figma est devenu central pour les équipes produit parce que ses fichiers prenaient en charge l’édition multijoueur, les commentaires, les composants et les bibliothèques partagées.

Les agents ajoutent un nouveau type de participant. Contrairement aux collaborateurs humains, ils peuvent modifier rapidement de vastes zones et agir à travers les outils grâce à des interfaces lisibles par machine.

La plateforme doit donc prendre en charge à la fois la collaboration et la contrainte. Elle doit rendre le travail des agents visible tout en limitant l’ampleur de la propagation d’une instruction erronée.

Figma Specs, les sources de code et les directives sont des fonctionnalités distinctes, mais leur valeur se cumule lorsqu’elles sont utilisées ensemble. Chacune répond à une partie différente du problème de contexte.

Les spécifications expliquent l’intention. Les bibliothèques expriment des décisions de design réutilisables, tandis que les sources de code ancrent ces décisions dans l’implémentation.

Les couches de code offrent un espace exécutable pour tester le résultat. MCP relie ensuite ce processus à des agents opérant ailleurs.

C’est ainsi que les agents Figma fonctionnent dans le modèle émergent de l’entreprise. Ils ne reçoivent pas simplement un prompt pour produire un écran.

Ils opèrent au sein d’une chaîne de contexte produit, de règles partagées, d’artefacts de travail et de revue humaine. Cette chaîne constitue la stratégie produit.

Trois signaux montreront si la stratégie d’agents de Figma fonctionne

Le prochain test consiste à déterminer si les workflows d’agents gouvernés améliorent les résultats réels des équipes sans ajouter une nouvelle couche de maintenance.

Le premier signal sera l’adoption des couches de code après le déploiement de la bêta ouverte. L’accès seul ne démontrera pas la valeur.

Les équipes devront créer, dupliquer, revoir et affiner à plusieurs reprises des prototypes fonctionnels sur le canevas. Une utilisation continue indiquerait que l’exploration soutenue par le code résout un véritable problème de collaboration.

Les preuves les plus utiles compareraient les workflows avant et après l’adoption. Des cycles de revue plus courts, moins de révisions lors de la transmission ou une meilleure représentation des états interactifs soutiendraient la thèse de Figma.

Des importations abandonnées, une exécution peu fiable ou des recréations fréquentes dans des outils externes l’affaibliraient. La bêta ouverte donne à Figma une population plus vaste pour repérer ces problèmes.

Le deuxième signal sera de savoir si les directives de design et les sources de code réduisent les erreurs des agents. Les équipes devraient constater une plus grande réutilisation des composants approuvés et moins d’écarts de marque ou d’implémentation.

Les notes de version d’octobre de Figma confirment que l’agent peut lire les directives des bibliothèques, rechercher dans les fichiers, attacher un contexte de plateforme et prendre en charge des compétences personnalisées. Ces capacités établissent le mécanisme, non le résultat.

Les preuves décisives viendront d’une utilisation répétée en production. Un système réussi devrait aider les agents à respecter les conventions sans obliger les utilisateurs à les reformuler dans chaque prompt.

Cela devrait également rendre les conflits visibles. Si la bibliothèque de conception et le dépôt de code divergent, le système doit aider les équipes à identifier quelle source fait autorité.

Sinon, un contexte supplémentaire peut accroître l’ambiguïté. Un agent peut recevoir davantage d’informations tout en étant moins certain de l’instruction à suivre.

Le troisième signal concerne l’évolution de la prise en charge des agents externes. L’argument de Figma en faveur de sa plateforme se renforce lorsque les équipes peuvent changer de modèles sans reconstruire leur contexte de conception.

La prise en charge d’un plus grand nombre de clients MCP favorise la distribution, mais la compatibilité doit aller au-delà du simple accès en écriture. Les agents externes ont besoin d’un accès fiable aux composants, variables, directives, images et relations avec le code.

Figma a indiqué travailler vers une parité plus large avec son Plugin API. Les progrès sur ce point détermineront si les agents externes deviennent des collaborateurs à part entière ou de simples outils d’importation limités.

La réponse concurrentielle comptera également. Les éditeurs de code et les plateformes de développement peuvent approfondir leurs propres intégrations de conception, tandis que les systèmes documentaires peuvent rendre les spécifications plus lisibles par les agents.

Si ces outils préservent le contexte sans faire transiter le travail par Figma, les équipes pourraient préférer un flux de travail distribué. Figma doit démontrer que la consolidation produit des décisions plus claires, et pas seulement une dépendance accrue à la plateforme.

Pour les designers, la question pratique est de savoir si le canevas demeure un lieu de jugement. Les agents devraient accélérer les variantes et les modifications de routine sans transformer la revue de conception en nettoyage de résultats.

Pour les développeurs, la question est de savoir si les couches de code conservent un contexte d’implémentation utile. Les prototypes générés doivent révéler les compromis sans être confondus avec du code de production révisé.

Pour les responsables produit, la valeur réside dans la traçabilité. Une exigence doit pouvoir être reliée à la conception, au prototype, à la source de code et à la décision qui l’ont façonnée.

Les fonctionnalités d’agent de Figma fournissent désormais les éléments de ce flux de travail. Les prochains mois montreront si les équipes peuvent maintenir ces éléments synchronisés sous la pression du quotidien.

Considérez la bêta ouverte comme une expérience opérationnelle. Choisissez un flux de travail circonscrit, connectez les sources actuelles, définissez les responsabilités et mesurez les retouches avant d’étendre le dispositif.

La question importante n’est plus de savoir si un agent IA peut dessiner une interface. Elle est de savoir si votre équipe peut expliquer pourquoi cette interface respecte ses standards, et la corriger lorsqu’elle ne les respecte pas.