Imaginons un studio qui a abandonné son bleu électrique il y a huit mois pour un bleu plus sourd, et dont la spec, restée dans un coin du canvas, mentionne toujours l'ancien. Un agent de code la lit, comme on le lui demande, puis décline le bouton principal sur quarante écrans. Aucune hésitation, aucune relecture. C'est le scénario que Specs, ouvert en bêta publique par Figma le 14 octobre 2026 au premier Config India, rend possible. Les code layers, qui posent du code exécutable à côté des maquettes, arrivent avec lui. Les deux sont réservés aux offres payantes.
Figma revendique aussi plus de 20 nouveaux outils connectés à son serveur MCP (Model Context Protocol), le standard par lequel un agent lit le contexte d'un projet. L'éditeur ne veut plus seulement être l'endroit où l'on dessine, mais celui où l'on décide, avant que le code ne soit généré.
Du Markdown sur un canvas, rien de plus magique
Specs ne devine rien. Il stocke ce qu'on y met : un fichier Markdown, des frames, des diagrammes FigJam, des code layers, des références tirées d'un dépôt GitHub ou d'un outil d'analyse comme Hex, via des connecteurs. L'agent de Figma peut commenter le document comme un collègue, et le tout part vers un agent de code par le MCP. Ce qui n'est pas écrit, l'agent l'invente.
Reste la question que l'annonce évite : un fichier Markdown dans un dépôt Git, lu par un agent de code, fait déjà l'essentiel, gratuitement, avec un historique ligne par ligne. Specs n'apporte rien sur le texte. Son intérêt tient ailleurs : le document vit à côté des frames et des composants auxquels il renvoie, et un designer qui n'ouvre jamais un terminal peut l'éditer. Pour un studio où le design et le code sont tenus par les mêmes deux personnes, Git suffit. Pour une équipe où la charte appartient à une directrice artistique, l'argument de Figma se défend.
« Dix-sept fois plus de lignes de code qu'auparavant, mais seulement 1,3 fois plus de releases. Une grande partie de ce code ne sert pas à livrer, mais à découvrir ce qu'est le produit. » Loredana Crisan, directrice du design chez Figma (propos traduits de l'anglais).
Ce chiffre sert l'argument de Figma : si les agents produisent du code pour « découvrir » le produit, autant leur donner un cadre écrit en amont. Il dit aussi l'inverse : tout ce code supplémentaire ne livre presque rien de plus, donc une spec bancale multiplie surtout du travail à jeter.
Que devient le design system quand il se met à parler aux machines ?
Figma avance sur d'autres fronts. Les guidelines peuvent rejoindre les bibliothèques publiées (bêta ouverte), les sources de code s'importent depuis GitHub ou npm (bêta fermée), et une cartographie du système avec contrôle des manques est annoncée. Le design system n'est plus un fichier de composants, mais un mélange de règles, de code et de texte.
Une spec utile ne ressemble pas à une présentation de marque. Elle liste les tokens avec leurs usages autorisés, et surtout les états des composants : survol, focus, erreur, chargement, écran vide, que personne ne dessine jamais jusqu'au bout. Elle dit aussi ce qu'on ne fait pas, par exemple pas de bouton secondaire plein à côté d'un bouton principal, et fixe le ton : titres de 60 caractères maximum, messages d'erreur sans « Oups ».
Tout cela demande du temps, des arbitrages et quelqu'un pour en répondre. Les prix précis de Specs n'ont pas été détaillés au lancement, seulement sa présence dans les offres payantes : à vérifier avant de bâtir une méthode dessus.
Qui corrige la spec le jour où le produit change ?
Un designer qui oublie une consigne se trompe sur un écran. Un agent qui lit une spec obsolète se trompe sur tous, sans hésiter. Une bibliothèque de composants se périme déjà seule ; un document Markdown, plus vite encore, parce que personne ne le voit en travaillant. Il faut donc une date, un historique et un nom en tête de chaque spec.
Une spécification fausse n'est pas neutre : elle est exécutée.
Figma y gagne ; les studios, selon ce qu'ils vendent
Figma gagne un argument pour ses offres payantes et une place centrale entre la maquette et le code. Les studios qui savent documenter et trancher y gagnent aussi : leur valeur passe de l'exécution à la règle. Ceux qui vendent surtout des écrans produits à la chaîne voient leur avantage fondre, puisque la production devient plus rapide et moins chère.
Une démo n'est pas un outil quotidien. Specs et les code layers sont en bêta ouverte, les sources de code en bêta fermée. Une équipe de cinq personnes tiendra-t-elle un document de référence à jour en pleine livraison ? Et un client paiera-t-il pour cette discipline ? Rien dans l'annonce n'y répond.
Figma automatise la lecture d'un contexte. Décider de ce qui doit être cohérent, accessible ou désirable reste un travail humain, et la direction artistique n'a pas de raison d'y perdre sa place.
Par où commencer quand on n'a pas de charte écrite ?
Pas par un nouveau rituel documentaire. Une page suffit : les couleurs et typos réellement en production, les états des composants, trois règles d'usage, une règle de ton. Dans Figma ou dans Git, peu importe, pourvu qu'elle soit datée et qu'un nom y soit attaché.
Si les équipes entretiennent ces documents, la spec pèsera aussi lourd que la maquette. Sinon, Figma aura surtout fourni un moyen élégant de répandre des erreurs à grande vitesse. Entre les deux, la question à poser à son équipe est simple : qui, ici, relira cette page dans trois mois ?