Autodiagnostic · 20 questions · 15 minutes

Design system et IA : votre DS est-il prêt pour Claude ?

Un design system bavard fait un Claude distrait. Répondez aux 20 questions et obtenez votre score, rubrique par rubrique, avec vos trois chantiers prioritaires.

Aucune donnée n'est envoyée : vos réponses restent dans votre navigateur.

Commencer le diagnostic

Avec un DS implicite

  • Un bleu proche, mais hors charte
  • Un libellé vague
  • Aucun état de focus prévu

Avec un DS lisible par Claude

  • Le token de la charte
  • Un libellé explicite
  • Un focus visible et contrasté
Le même bouton, demandé à Claude avec deux design systems différents. Illustration.

Comment répondre

Soyez sévère : une règle connue de l'équipe mais jamais écrite vaut « Partiellement » au mieux. Claude, lui, ne la connaîtra pas. Si vous ne savez pas, répondez « Non ».

  • Norme exigence WCAG 2.1 (niveaux A et AA), reprise par le RGAA
  • Bonne pratique recommandation de la profession ou d'Anthropic

Inventaire

Savez-vous ce que vous avez ?

01Disposez-vous d'une liste complète et à jour de vos fondations et composants ?

Bonne pratique Sans inventaire, impossible de dire à Claude ce qui existe, ni de repérer ce qui manque.

02Vos maquettes et votre code correspondent-ils : mêmes noms, mêmes variantes ?

Bonne pratique Si Figma dit « Bouton primaire » et le code « BtnMain », Claude doit deviner que c'est la même chose.

03Votre DS est-il exempt de doublons : couleurs quasi identiques, composants qui font la même chose ?

Bonne pratique Deux options presque semblables, c'est une chance sur deux que Claude choisisse la mauvaise.

Fondations et tokens

Vos valeurs ont-elles un nom et un rôle ?

04Vos couleurs, typographies et espacements sont-ils définis sous forme de tokens, plutôt que codés en dur ?

Bonne pratique Une valeur hexadécimale isolée ne dit pas à quoi elle sert.

05Vos tokens sont-ils nommés selon leur usage (color.action.primary) plutôt que leur apparence (blue-500) ?

Bonne pratique Le nom porte l'intention : c'est lui qui guide le choix de Claude.

06Vos tailles de texte et vos espacements suivent-ils une échelle cohérente ?

Bonne pratique Des valeurs hors échelle signalent des exceptions jamais documentées.

07Vos tokens sont-ils exportables dans un format structuré, comme le JSON au format DTCG ?

Bonne pratique Le format du Design Tokens Community Group est un standard communautaire, pas une norme W3C. Il facilite l'échange entre outils.

Composants

Chaque pièce a-t-elle son mode d'emploi ?

08Chaque composant documente-t-il tous ses états : défaut, survol, focus, actif, désactivé, erreur, chargement ?

Bonne pratique Un état absent sera inventé.

09Chaque composant a-t-il une règle écrite qui dit quand l'utiliser, quand ne pas l'utiliser, et quoi prendre à la place ?

Bonne pratique C'est la question la plus importante : sans interdit ni alternative, Claude n'a aucun moyen de trancher.

10Chaque composant dispose-t-il d'un exemple d'usage de référence ?

Bonne pratique Anthropic recommande quelques exemples canoniques plutôt qu'une longue liste de cas particuliers.

Accessibilité

Claude produira-t-il conforme par défaut ?

11Les contrastes texte/fond respectent-ils 4,5:1 pour le texte courant et 3:1 pour le grand texte ?

Norme · critère 1.4.3 Si vos couleurs ne sont pas conformes, Claude reproduira la non-conformité sur chaque écran.

12Les bordures de champs, icônes et indicateurs d'état atteignent-ils 3:1 contre leur fond ?

Norme · critère 1.4.11 On l'oublie souvent pour les champs de formulaire.

13Un état de focus visible est-il conçu pour chaque élément interactif ?

Norme · critère 2.4.7 S'il n'est pas dans le DS, il n'existera pas dans les écrans générés.

14Le comportement au clavier et le nom accessible de chaque composant sont-ils documentés ?

Norme · critères 2.1.1 et 4.1.2 Claude sait coder un composant accessible, à condition qu'on lui dise ce qui est attendu.

Lisibilité par Claude

Votre DS parle-t-il le langage d'une IA ?

15Votre documentation existe-t-elle en texte lisible (fichiers Markdown, par exemple), et pas seulement en visuels ou en pages générées dynamiquement ?

Bonne pratique Une règle visible sur une maquette mais jamais écrite est invisible pour Claude.

16Utilisez-vous un seul terme par concept, partout ?

Bonne pratique « CTA », « bouton principal » et « action primaire » pour la même chose : Anthropic recommande une terminologie constante.

17Avez-vous un point d'entrée court, avec les règles critiques en tête et le détail dans des fichiers séparés ?

Bonne pratique C'est la divulgation progressive décrite par Anthropic : Claude ne charge le détail que lorsque la tâche l'exige.

18Les règles implicites, celles que l'équipe applique sans les avoir écrites, sont-elles documentées ?

Bonne pratique Demandez-vous ce qu'un nouvel arrivant mettrait trois semaines à comprendre. Claude ne le comprendra jamais seul.

Gouvernance et test

Votre DS vit-il ?

19Votre DS a-t-il un responsable, un système de versions et un processus de contribution ?

Bonne pratique Un DS sans propriétaire se dégrade, et Claude appliquera fidèlement ses versions périmées.

20Avez-vous déjà soumis à Claude des tâches réelles, avec une grille pour noter la conformité du résultat ?

Bonne pratique Anthropic recommande de mesurer une base de référence avant d'écrire la documentation. Sans test, vous ne savez pas ce qui manque.

Sources

Les paliers de score sont une grille de lecture indicative, issue de notre pratique, et non une mesure scientifique. Seul un test sur vos propres tâches donne un résultat fiable.