Les équipes produit utilisent désormais Claude pour générer des maquettes, des prototypes et du code front. Le design system devient alors la principale source de vérité de l'IA. S'il est conçu uniquement pour des yeux humains, il est mal interprété. Voici les 10 règles que nous appliquons chez Wolfox pour le rendre lisible par une machine, sans le rendre moins utile pour vos équipes.
Pourquoi votre design system doit-il être lisible par une IA ?
Parce que Claude ne regarde plus seulement vos écrans : il lit vos fichiers. Trois usages le montrent.
- Claude Design (Anthropic Labs, lancé en avril 2026) construit le design system d'une équipe en lisant sa base de code et ses fichiers de design, puis l'applique à chaque projet. Anthropic recommande de configurer ce design system avant tout déploiement.
- Claude Code génère du code front à partir de vos maquettes, via le serveur MCP de Figma qui transmet la structure réelle du fichier (calques, variables, auto-layout) plutôt qu'une capture d'écran.
- Les agents (dans Claude ou ailleurs) consultent la documentation de votre design system comme n'importe quelle source : si elle est ambiguë, ils comblent les trous au hasard.
Un design system « IA-ready » n'est donc pas un nouveau design system. C'est le même, rendu explicite : ce qu'un designer senior sait implicitement doit être écrit.
Les 10 règles pour un design system exploitable par Claude
Chaque règle indique s'il s'agit d'un standard (spécification publiée, opposable) ou d'une bonne pratique (retour d'expérience, recommandation d'éditeur).
1. Exprimer vos tokens au format DTCG
Statut : standard. Les design tokens doivent être stockés au format JSON défini par le Design Tokens Community Group du W3C, dont la première version stable (2025.10) est parue le 28 octobre 2025.
Pourquoi : un format standard est lu de la même façon par Figma, vos outils de build et Claude. Un format maison oblige l'IA à interpréter. Point d'attention : $description est le champ le plus utile pour une IA, car il porte l'intention.
{ "color": { "text": { "danger": { "$type": "color", "$value": "{color.red.700}", "$description": "Texte d'erreur sur fond clair. Contraste ≥ 4,5:1 (WCAG 1.4.3)." } } } }
2. Nommer les tokens par intention, en couches
Statut : bonne pratique. Organisez trois niveaux : primitives (red.700), sémantiques (color.text.danger), composants (button.primary.background).
Pourquoi : red-500 dit à Claude à quoi ressemble une valeur, color.text.danger lui dit quand l'utiliser. Une IA ne choisit bien que si le nom contient la décision. Interdisez l'usage direct des primitives dans les composants.
3. Garder une seule source de vérité, synchronisée
Statut : bonne pratique. Les variables Figma, les tokens JSON et les variables CSS doivent porter les mêmes noms et les mêmes valeurs, générés depuis une source unique.
Pourquoi : si Figma et le code divergent, Claude reçoit deux vérités et en choisit une au hasard. Automatisez la synchronisation (pipeline de build, Tokens Studio ou équivalent) plutôt que de la confier à la discipline humaine.
4. Nommer et structurer les composants pour être devinés
Statut : bonne pratique. Un composant = un nom métier stable (Button, pas CTA-v2-final), des propriétés explicites et un nombre fini de variantes.
Pourquoi : Claude compose des interfaces à partir de ce qu'il peut identifier. Des calques nommés « Frame 482 », des variantes détachées ou des propriétés booléennes empilées produisent des maquettes incohérentes. Utilisez l'auto-layout et les variables partout : c'est ce que le serveur MCP de Figma transmet.
5. Relier chaque composant Figma à son code
Statut : MCP = standard ouvert ; Code Connect = fonctionnalité Figma. Code Connect associe un composant Figma au composant de production ; le serveur MCP de Figma transmet ensuite ce lien à Claude Code.
Pourquoi : sans ce lien, Claude recrée un bouton au lieu d'importer le vôtre. Avec lui, le code généré réutilise votre bibliothèque réelle. Priorisez les 20 composants les plus utilisés.
6. Écrire les règles d'usage en texte, pas en images
Statut : bonne pratique. Pour chaque composant, rédigez : à quoi il sert, quand l'utiliser, quand ne pas l'utiliser, et quelle alternative choisir.
Pourquoi : une capture « Don't » barrée d'une croix rouge est parlante pour un humain, ambiguë pour un modèle. Une phrase comme « N'utilisez qu'un seul bouton primaire par écran ; pour une action secondaire, utilisez Button variant=secondary » est directement applicable.
7. Intégrer l'accessibilité dans chaque composant
Statut : standard. Les exigences viennent de normes publiées : WCAG 2.2 (recommandation W3C), RGAA 4 en France, et l'European Accessibility Act, applicable depuis le 28 juin 2025.
Pourquoi : Claude n'applique que les exigences qu'il trouve. Documentez pour chaque composant le rôle ARIA, le comportement clavier, l'ordre de focus, les textes alternatifs attendus et les critères RGAA/WCAG concernés. Encodez les contrastes validés dans les tokens (règle 1) : l'IA ne peut plus associer une couleur de texte à un fond non conforme.
8. Publier une documentation en Markdown, versionnée
Statut : bonne pratique. Rédigez la documentation du design system en Markdown, dans le même dépôt que le code, avec un exemple de code minimal par composant.
Pourquoi : le Markdown est le format que les modèles lisent le mieux et que l'on versionne facilement. Option émergente : un fichier llms.txt à la racine de votre site de documentation, qui sert d'index pour les agents. C'est une proposition communautaire, pas un standard ; aucun gain de visibilité n'est démontré à ce jour.
9. Donner des instructions explicites à Claude
Statut : Agent Skills = standard ouvert ; CLAUDE.md = convention Claude Code. Rédigez un fichier de règles pour l'agent : composants à importer, tokens obligatoires, interdits, conventions de nommage.
Pourquoi : Claude Code lit le fichier CLAUDE.md du projet à chaque session. Pour réutiliser ces règles au-delà d'un dépôt, packagez-les en Agent Skill (un dossier avec un fichier SKILL.md), format publié en standard ouvert par Anthropic en décembre 2025. Dans Claude, le design system de l'organisation se configure aussi directement à partir de vos fichiers de code et de design.
10. Tester avec des prompts de référence et mesurer
Statut : bonne pratique (recommandée par Anthropic). Constituez 5 à 10 demandes types (un formulaire, une page de liste, un écran d'erreur…) et comparez la sortie de Claude à ce qu'un designer aurait produit.
Pourquoi : c'est le seul moyen de savoir si votre design system est réellement compris. Anthropic recommande de valider la cohérence des rendus avant d'ouvrir l'outil à toute l'équipe, puis de maintenir un canal de retours. Chez Wolfox, nous mesurons avant/après : conformité aux tokens, réutilisation des composants, erreurs d'accessibilité détectées.
Checklist : votre design system est-il prêt pour Claude ?
- Tokens exportés au format DTCG 2025.10, avec $description
- Trois niveaux de tokens : primitives, sémantiques, composants
- Mêmes noms et valeurs dans Figma, le JSON et le CSS
- Composants nommés en langage métier, variantes finies, auto-layout partout
- Code Connect configuré sur les composants les plus utilisés
- Règles « quand utiliser / quand ne pas utiliser » rédigées en texte
- Exigences WCAG 2.2 / RGAA documentées par composant, contrastes encodés dans les tokens
- Documentation Markdown versionnée avec le code
- Fichier de règles pour l'agent (CLAUDE.md ou Agent Skill)
- Jeu de prompts de référence et mesure avant/après
FAQ
Qu'est-ce qu'un design system exploitable par une IA ?
C'est un design system dont les décisions sont écrites dans des formats lisibles par une machine : tokens standardisés, composants reliés au code, règles d'usage en texte. L'IA peut alors l'appliquer sans interpréter.
Claude peut-il utiliser un design system Figma ?
Oui. Via le serveur MCP de Figma, Claude Code lit la structure du fichier, les variables et les liens Code Connect. Dans Claude, le design system d'une organisation se construit à partir des fichiers de design et du code.
Le format DTCG est-il obligatoire ?
Non, mais c'est le seul format de tokens standardisé et stable à ce jour (version 2025.10). Il réduit les erreurs d'interprétation entre outils, IA comprise.
Faut-il refaire son design system pour l'IA ?
Rarement. Dans la plupart des cas, il s'agit de renommer, documenter et relier l'existant. Un audit permet d'identifier les écarts prioritaires.
L'IA garantit-elle des interfaces accessibles ?
Non. Elle reproduit les exigences qu'on lui donne. Un composant documenté réduit les erreurs, mais un audit RGAA reste nécessaire pour attester la conformité.
En résumé
Un design system exploitable par Claude est un design system explicite : chaque décision implicite devient un token nommé, une règle écrite ou un lien vers le code. Les mêmes efforts profitent à vos équipes humaines, à votre accessibilité et à la sobriété de vos interfaces.
Vous voulez savoir où en est votre design system ? Wolfox réalise des audits de design systems orientés IA, accessibilité (RGAA, WCAG) et éco-conception, puis accompagne leur mise à niveau. Contactez-nous.
Sources
