Figma Specs : pourquoi documenter votre design devient essentiel à l'ère de l'IA
Le 15 octobre 2026, lors de sa première conférence Config en Inde, Figma a présenté Specs, un éditeur Markdown collaboratif conçu pour rassembler les décisions, les règles et les références d'un projet au même endroit. L'objectif : permettre aux designers, aux développeurs et aux agents d'intelligence artificielle de travailler à partir d'un contexte commun.
Quelques jours plus tôt, Figma avait annoncé la disponibilité générale de son agent IA. Le 15 octobre, l'entreprise présentait également les code layers, désormais en bêta ouverte, qui permettent d'intégrer des éléments interactifs reposant sur du code directement dans les fichiers de conception.
Ces annonces illustrent une évolution des méthodes de production numérique : les outils d'IA ne se limitent plus à générer des propositions visuelles. Ils interviennent aussi dans la conception, le prototypage et le développement, ce qui rend la transmission des règles et des décisions de plus en plus importante.
Pour une PME ou un OBNL, la question n'est toutefois pas de savoir s'il faut adopter Specs. Elle se pose plus en amont : vos règles de design existent-elles ailleurs que dans la tête de la personne qui a conçu votre site?
Ce que Figma a annoncé
Specs est un éditeur collaboratif reposant sur le Markdown, un format de texte structuré qui permet notamment d'organiser des titres, des listes, des liens et des blocs de code.
Contrairement à un simple document texte, Specs peut être intégré directement au canevas Figma, à côté des maquettes, ou être créé comme document autonome. Plusieurs personnes peuvent y collaborer, commenter les décisions et faire évoluer les informations au fil du projet.
L'outil permet également d'intégrer des références visuelles et techniques : écrans de conception, diagrammes FigJam, composants et éléments de code. L'idée est de conserver les explications et les décisions à proximité du travail auquel elles se rapportent.
Specs ne sert donc pas uniquement à documenter une identité visuelle. Il peut aussi accueillir des exigences fonctionnelles, des décisions produit, des spécifications techniques ou des informations destinées au développement.
L'une de ses particularités est son intégration avec le serveur MCP de Figma. Le Model Context Protocol est un protocole permettant à des outils d'IA compatibles d'accéder à des informations provenant de systèmes externes.
Concrètement, un agent de programmation connecté au serveur MCP peut consulter une spec et les éléments qu'elle référence avant de générer du code. Selon la documentation de Figma, les agents compatibles peuvent également créer et modifier des specs.
Cela ne signifie pas que la documentation se maintient automatiquement ou qu'un agent applique toujours correctement les instructions reçues. Les modifications et leur cohérence avec le projet doivent continuer d'être vérifiées.
Au 2 novembre 2026, Specs est en cours de déploiement en bêta ouverte sur les forfaits Professional, Education, Organization et Enterprise. Le forfait gratuit Starter n'est pas inclus dans ce déploiement. Cette disponibilité est distincte de celle du serveur MCP de Figma, qui prend également en charge Starter.
Pourquoi un agent IA a besoin de règles écrites
Un agent IA peut reproduire les caractéristiques visuelles d'une marque sans nécessairement comprendre les règles qui les gouvernent.
Prenons l'exemple d'un bouton orange. Une maquette montre qu'il est orange, mais elle ne dit pas forcément qu'il est réservé à l'action principale d'une page, qu'il ne doit pas apparaître deux fois dans le même écran ou que le texte blanc posé dessus a été validé pour respecter les exigences de contraste.
Ces décisions existent, mais elles ne sont pas toujours consignées.
Une personne qui travaille sur le site depuis deux ans les connaît probablement. Un agent qui découvre le fichier ne dispose pas nécessairement de ce contexte. Il peut alors produire un écran plausible et cohérent en apparence, tout en contredisant des choix de conception importants.
Le même problème peut survenir lorsqu'une nouvelle personne rejoint une équipe ou qu'un fournisseur reprend un projet plusieurs années après sa livraison.
C'est ce manque de contexte que Specs cherche à combler. Mais il faut distinguer deux choses : documenter une règle et garantir son application.
Une documentation claire aide à transmettre les intentions. Elle ne remplace pas des composants correctement construits, des variables de design cohérentes, des contrôles de qualité ni la validation humaine.
Un agent peut recevoir les bonnes instructions et produire malgré tout un résultat qui nécessite des corrections.
Specs propose donc un moyen de mieux transmettre les décisions, pas une garantie que celles-ci seront systématiquement respectées.
Ce que disent les équipes qui possèdent déjà un design system
Les difficultés liées à la documentation ne sont pas nouvelles. Elles existent même dans les organisations qui disposent de ressources consacrées à leur design system.
zeroheight, une plateforme spécialisée dans la documentation des design systems, publie chaque année une enquête auprès des professionnels du secteur.
Son Design Systems Report 2026 repose sur les réponses de 147 praticiens.
Les résultats mettent notamment en évidence un manque de ressources :
- 61 % des répondants estiment que leur équipe ne dispose pas de suffisamment de personnel pour atteindre ses objectifs.
- 56 % identifient le manque de personnel comme le principal défi rencontré dans la maintenance et l'évolution de leur design system.
Ces résultats montrent que la difficulté ne réside pas seulement dans la création des règles. Il faut également disposer du temps et des ressources nécessaires pour les maintenir à jour, les transmettre et les appliquer dans les différents outils de production.
Une précision s'impose : zeroheight commercialise une solution de documentation, et son enquête repose sur un échantillon spécialisé de professionnels travaillant avec des design systems. Ces résultats ne sont donc pas représentatifs de l'ensemble des PME et des OBNL.
Ils illustrent néanmoins les difficultés que peuvent rencontrer des équipes déjà engagées dans une démarche de structuration et de documentation de leurs interfaces.
La nuance : ce n'est pas une question d'outil
Il serait tentant de conclure qu'il faut adopter Specs ou se procurer le plus récent outil d'IA en design. Pourtant, l'enjeu dépasse largement le choix d'un logiciel.
Specs vient tout juste d'être lancé, et il est encore trop tôt pour mesurer son efficacité à long terme dans les projets réels. Figma décrit les fonctionnalités et les usages qu'il souhaite faciliter, mais cela ne constitue pas une preuve que les agents respecteront systématiquement les règles documentées.
Ce qui retient davantage notre attention, c'est la place accordée à la documentation écrite.
Le Markdown est un format ouvert, utilisable dans de nombreux outils. Des règles rédigées clairement dans un fichier texte peuvent donc rester accessibles indépendamment du logiciel choisi.
Le contenu Markdown se distingue toutefois de ses intégrations. Les références à des composants, les éléments intégrés au canevas et certaines fonctionnalités collaboratives de Specs demeurent propres à l'environnement Figma.
Autrement dit, la documentation peut être réutilisable, sans que toutes ses fonctionnalités le soient.
Pour une organisation, des règles de marque clairement documentées peuvent servir à une nouvelle personne qui rejoint l'équipe, à un fournisseur chargé de faire évoluer le site ou à un outil d'IA utilisé dans le cadre d'un projet.
Pour bien des PME et des OBNL, le point de départ n'est d'ailleurs pas un design system complet. C'est souvent un guide de normes graphiques en PDF, livré avec le logo, et quelques maquettes dont les décisions n'ont jamais été consignées.
Ces documents sont utiles, mais ils ne répondent pas nécessairement à toutes les questions qui se posent lors de la création ou de la modification d'une interface web.
Ce que ça change dans la façon de livrer un design
Si une partie des écrans d'un site est appelée à être produite ou modifiée avec l'aide de l'IA, que ce soit par votre équipe, par un fournisseur ou par nous, la documentation du design devient un élément essentiel pour préserver la cohérence des résultats.
Mais elle ne doit pas être pensée uniquement pour les agents.
Une bonne documentation permet avant tout de transmettre les décisions prises pendant la conception et de faciliter les évolutions futures du site.
Voici ce que nous recommandons de documenter, en langage simple :
- Les couleurs et leur rôle : quelles couleurs utiliser pour les actions, les alertes ou les arrière-plans, et quelles combinaisons respectent les exigences de contraste.
- La typographie : quels styles utiliser pour les titres, le texte courant et les éléments d'interface, ainsi que les règles de hiérarchie et de lisibilité.
- Les composants : à quoi servent les boutons, les cartes et les formulaires, comment ils se comportent et dans quelles situations les utiliser.
- Le ton et le vocabulaire : comment l'organisation s'adresse à ses publics, les mots à privilégier et ceux à éviter.
- Les règles d'accessibilité : contrastes, navigation au clavier, états de focus, alternatives textuelles et comportements des éléments interactifs.
Cette documentation doit également correspondre au site réellement développé.
Un guide peut prévoir un bouton d'une certaine couleur ou un composant avec un comportement précis. Si ce composant a été modifié dans le code sans que la documentation soit mise à jour, les deux références finissent par se contredire.
La cohérence ne repose donc pas uniquement sur la rédaction initiale des règles, mais aussi sur leur maintien dans le temps.
Pour une PME ou un OBNL, cela ne signifie pas qu'il faut mettre en place une infrastructure complexe. Il s'agit surtout de déterminer quelles informations sont importantes, où elles doivent être conservées et qui sera responsable de les mettre à jour.
Les consigner au moment où les décisions sont prises évite souvent un travail de reconstitution beaucoup plus important plusieurs années plus tard.
Par où commencer
Si votre organisation n'a pas de design system, inutile d'en bâtir un simplement pour suivre la tendance.
Quelques questions suffisent pour mesurer l'écart entre les décisions prises lors de la conception de votre site et les informations réellement disponibles aujourd'hui.
Si une nouvelle personne devait créer une page de votre site demain, où trouverait-elle les règles à suivre?
Votre guide de normes graphiques couvre-t-il le web, ou seulement le logo et l'imprimé?
Les décisions prises lors de la conception de votre site sont-elles consignées quelque part?
Si vous utilisez déjà l'IA pour produire des visuels, des interfaces ou des textes, lui fournissez-vous ces règles?
Qui est responsable de mettre à jour cette documentation lorsque votre site ou votre identité visuelle évolue?
Répondre non à la plupart de ces questions ne signifie pas qu'il faut entreprendre un vaste chantier de documentation.
Cela indique simplement que certaines décisions reposent encore sur la mémoire de quelques personnes.
À mesure que les outils évoluent et que les intervenants se multiplient, cette dépendance peut compliquer la maintenance et les évolutions d'un site.
L'arrivée de Figma Specs ne change pas fondamentalement ce constat. Elle lui donne surtout une nouvelle importance dans un contexte où les agents IA participent de plus en plus aux processus de conception et de développement.
Vous voulez savoir si les règles de votre identité visuelle sont suffisamment claires pour être suivies, par une personne comme par une IA? Écrivez-nous. Chez ctrlweb, nous pouvons vous aider à les documenter à partir de votre site actuel.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sources
Article rédigé le 2 novembre 2026. Les fonctionnalités décrites reflètent les informations disponibles à cette date. Specs et les code layers étant des fonctionnalités récentes, leur disponibilité et leur fonctionnement sont susceptibles d'évoluer.
Annonces et documentation de Figma
- Figma : Introducing Specs, Markdown as a medium (15 octobre 2026). Présentation de Specs, de ses usages collaboratifs et de son intégration avec les agents IA.
- Figma : Build by design, New workflows for new ways of building (15 octobre 2026). Vue d'ensemble des annonces de Config Inde, notamment Specs et les code layers.
- Figma : Guide to Specs. Documentation sur les fonctionnalités et les conditions d'accès.
- Figma : Guide to the Figma MCP server. Documentation sur le serveur MCP, ses capacités et les forfaits compatibles.
- Creative AI News : Figma Specs. Couverture complémentaire du lancement et de la disponibilité de Specs.
Données sur les design systems
- zeroheight : Design Systems Report 2026. Enquête annuelle auprès de 147 praticiens.
- zeroheight : Design Systems Report 2026, We need more people. Présentation des difficultés de ressources, notamment les résultats de 61 % et 56 %.
Accessibilité web
- W3C : Web Content Accessibility Guidelines (WCAG) 2.2. Référentiel international couvrant notamment les contrastes, la navigation au clavier, les indicateurs de focus et les alternatives textuelles.
