Figma Specs : un document de règles lu par les agents
Figma Specs est un éditeur Markdown intégré à Figma. Une équipe y écrit ses décisions de design, pour que les personnes comme les agents IA les appliquent. Il a été annoncé le 14 octobre 2026 à Bengaluru, lors de la première Config India. Il se déploie en bêta ouverte sur les plans payants.
Une Spec peut vivre comme fichier à part ou directement sur le canevas. Elle peut citer des éléments du canevas et embarquer un diagramme FigJam, un design ou une code layer. D'après le billet de Figma, on peut aussi l'envoyer à un agent de code via le serveur MCP.
Pourquoi Figma en a besoin maintenant
Les agents produisent vite, mais pas forcément juste. Loredana Crisan dirige le design de Figma. Elle a chiffré l'écart pour TechCrunch : 17 fois plus de lignes de code produites qu'avant, pour seulement 1,3 fois plus de mises en production. Une IA non déterministe a besoin d'un cadre écrit pour produire des résultats prévisibles.
Specs, Guidelines, Guidelines.md : où écrire quelle règle
Figma propose désormais trois endroits pour écrire des règles destinées à l'IA, et ils ne servent pas à la même chose. Le tableau résume ce que la documentation officielle en dit au 16 octobre 2026.
| Où | Pour quoi | Qui le lit | Statut |
|---|---|---|---|
| Specs | Le contexte d'un projet : intentions, décisions, spécification produit | L'équipe, et les agents via MCP | Bêta ouverte, plans payants |
| Guidelines d'une bibliothèque | Les règles du design system : usages, anti-patterns | L'agent Figma, à chaque prompt avec la bibliothèque | Bêta ouverte, plans Professional et au-delà |
| Guidelines.md de Figma Make | Les règles d'un fichier Make | L'IA de Make, fichier par fichier | Disponible |
Piège à connaître : les Guidelines d'une bibliothèque publiée ne sont pas utilisées pour créer un kit Make. Une règle écrite d'un côté n'existe pas de l'autre, et il faut la maintenir aux deux endroits.
Répartir les règles entre la Spec et les Guidelines
La frontière tient en une question : la règle survit-elle au projet ? Si oui, elle appartient au design system et va dans les Guidelines de la bibliothèque. Si elle ne vaut que pour ce produit ou cette fonctionnalité, elle va dans la Spec. C'est notre lecture de la documentation, pas une règle énoncée par Figma.
- Guidelines → « un seul bouton primaire par écran », « jamais de texte sous 14 px ».
- Spec → « le paiement tient en trois étapes », « l'API ne renvoie pas encore l'historique ».
Mélanger les deux produit les erreurs les plus coûteuses. Une contrainte de projet copiée dans les Guidelines s'appliquera à tous les fichiers qui utilisent la bibliothèque. À l'inverse, une règle du design system oubliée dans une Spec laisse l'agent improviser, écran par écran.
Écrire une règle qu'un agent peut vraiment suivre
Une règle utile à un agent décrit une situation précise et une décision, pas un principe général. L'aide officielle des Guidelines est plus concrète que l'annonce de Specs, et ses conseils valent pour les deux.
Partir des erreurs, par scénario
Figma conseille de viser là où les gens se trompent : les erreurs courantes, les anti-patterns, les composants ou variantes faciles à confondre. Chaque règle prend la forme d'un scénario : la situation, un exemple à faire, un exemple à éviter, et la raison. La raison n'est pas décorative : c'est elle qui permet à l'agent de traiter un cas voisin.
Trancher au lieu de lister
Une liste d'options laisse l'agent choisir, donc deviner. La documentation demande une recommandation claire. Une règle sans exception s'écrit comme absolue. Si une exception existe, elle se décrit dans la règle, pour que deux consignes ne se contredisent pas.
Commencer par les fondations
Figma suggère de démarrer par trois sujets : les couleurs (variables, rôles sémantiques, valeurs brutes à éviter), les espacements et les rayons d'angle. Ce sont les décisions que l'agent rencontre sur chaque écran. Une équipe qui a déjà structuré ses design tokens a fait l'essentiel du travail.
Ne rien laisser inventer
L'agent peut rédiger un premier jet des fichiers. Le prompt modèle de Figma lui interdit pourtant d'inventer des noms de composants, de variantes ou de tokens. Ce qui manque doit être noté sous forme de questions. Pendant la bêta, c'est un humain qui relit et téléverse les fichiers.
Moins de règles, mieux tenues
Plus de contexte ne donne pas de meilleurs résultats. L'aide de Figma Make le dit sans détour : « More context isn't always better. It can confuse the LLM. » Les chiffres de la documentation fixent l'échelle :
- Formats → Markdown, texte brut ou JSON.
- Volume conseillé → de 3 à 8 fichiers ciblés, moins de 100 Ko au total.
- Plafond → 200 Ko pour l'ensemble des fichiers d'une bibliothèque.
- Découpage suggéré → overview.md, components.md, examples.md, anti-patterns.md, best-practices.md.
La répétition coûte aussi : une même consigne répétée dans plusieurs fichiers augmente le temps de traitement et la consommation de crédits IA. Avant d'ajouter un fichier, on vérifie qu'il ne contredit pas un autre, et on retire les consignes trop larges ou valables pour une seule tâche.
Exemple : une règle écrite pour l'agent
Voici à quoi peut ressembler une entrée d'un fichier anti-patterns.md, rédigée selon ces conseils. C'est notre exemple, pas un modèle fourni par Figma.
## Choix entre liste déroulante et boutons radio
Situation : un champ propose un choix unique.
À faire : 2 options ou moins → boutons radio visibles.
À éviter : une liste déroulante pour 2 options.
Pourquoi : la liste cache les options et ajoute un clic.
Exception : aucune.La règle tient en cinq lignes, nomme la situation, tranche et donne sa raison. Elle reprend l'exemple de l'aide de Make, qui proscrit la liste déroulante pour deux options ou moins. Une règle de cette forme se vérifie aussi : on relit les écrans produits et on compte les écarts.
Vérifier que l'agent applique la règle
Une règle écrite n'est respectée que si l'on contrôle les sorties. Figma recommande d'ailleurs de relire les productions passées de l'agent. On y repère les conventions non documentées : ordre de composition, composants aux noms proches, variables obligatoires. C'est la même logique que nous appliquons à un agent IA de production visuelle. Un agent applique une méthode, à condition qu'elle soit écrite et vérifiée.
Ce que la documentation ne dit pas encore
- La syntaxe d'une Spec → aucune structure imposée n'est documentée à ce jour.
- Les conflits → rien n'indique comment l'agent tranche entre deux fichiers contradictoires.
- Le coût → des Guidelines volumineuses consomment plus de crédits, sans barème publié.
Pour aller plus loin côté outillage, notre guide de l'agent Figma et du MCP détaille la connexion avec les outils de code.
Conclusion : le design system devient un texte
Avec Specs et les Guidelines, une partie du design system se lit désormais comme un texte, par une machine. Le travail du designer se déplace : il écrit moins de documentation exhaustive et davantage de décisions courtes, vérifiables, assorties de leur raison. Une bonne règle pour un agent est aussi une bonne règle pour un humain.
