Design System
Compétence feuille en Design ; accessible via son domaine ou par son nom.
Un design system économise les décisions seulement tant que les équipes lui font confiance. La dérive érode cette confiance silencieusement : trois noms pour un composant, des valeurs hexadécimales brutes à côté des tokens qu'elles dupliquent, des états que personne n'a documentés. Une fois que les équipes cessent de faire confiance au système, elles construisent autour. Cette méthode fonctionne en trois modes — auditer le système tel qu'il est, documenter un composant pour qu'il soit utilisé correctement, l'étendre avec un motif qui s'intègre — et ancre chacun dans la source réelle : fichiers de tokens, code des composants et fichier de design, pas une idée générique d'un design system.
Un exemple d'audit travaillé
Situation (fictive) : une bibliothèque React avec un fichier de tokens ; la demande est "auditez nos boutons et nos cartes".
Nommage Button, IconBtn et .btn-link nomment un concept de trois façons.
→ Adopter Button avec une variante `icon` et `link` ; aliaser les anciens
noms pendant une version.
Tokens 23 couleurs en dur dans Card et Modal. 18 égalent un token existant
(remplacer mécaniquement) ; 5 ne correspondent à aucun.
→ Les 5 nécessitent une décision : un token manquant, ou une erreur de design à corriger.
États Card n'a pas d'état focus bien qu'elle soit cliquable.
Le choix réutilisable est la distinction entre une valeur qui duplique un token, ce qui est une correction mécanique, et une valeur qui ne correspond à aucun token, ce qui est une question de design à soumettre à une personne plutôt que de deviner.
Rassembler le système
Lisez ce qui existe avant de le juger : la source des tokens, le code ou la bibliothèque des composants, et la documentation. Une recherche comme
rg -n '#[0-9a-fA-F]{3,8}\b|[0-9]+px' src/components trouve les valeurs en dur dans le code ; adaptez le motif à la pile.
Les sections marquées
~~nomment une catégorie d'outil, pas un produit :~~outil de design(par exemple Figma) ou~~base de connaissances(par exemple Notion). Utilisez l'outil connecté de cette catégorie que l'hôte fournit ; ignorez l'étape quand il n'y en a pas.
Avec un ~~outil de design, inspectez les noms des composants, les variantes, la structure des calques et l'utilisation des tokens dans le fichier de design et comparez-les avec le code. Avec une ~~base de connaissances, trouvez les pages de composants existantes et les directives d'utilisation, et publiez la documentation mise à jour uniquement si la personne l'a demandé.
Un système a trois couches ; l'audit et la documentation couvrent chacune :
| Couche | Contenu |
|---|---|
| Tokens | Couleur (marque, sémantique, neutre), typographie, espacement, rayon et bordure, élévation, durées et easings de mouvement |
| Composants | Variantes, états (par défaut, survol, focus, actif, désactivé, chargement, erreur), tailles, comportement, accessibilité |
| Motifs | Formulaires, navigation, affichage de données, feedback — composants combinés pour résoudre un problème récurrent |
Lorsque les tokens se déplacent entre les outils, le format du Design Tokens Community Group (première version stable 2025.10, octobre 2025) est le format d'échange commun ; suivez le format que le projet utilise déjà.
Principes
- Cohérence avant nouveauté. Le système existe pour que les équipes cessent de re-décider les mêmes choses ; une variante ponctuelle a besoin d'une raison que le système ne couvre pas.
- Composable dans les contraintes. Préférer une variante ou une composition de composants existants à un nouveau composant.
- Non documenté signifie inutilisable. Un état ou une variante que personne ne peut trouver est reconstruit.
- Versionner et migrer. Un renommage ou une suppression cassante nécessite un chemin de migration, comme un alias pendant une version et un codemod ou une recherche pour trouver les utilisations.
Auditer
Rapportez des comptes et des preuves, pas un score : un nombre sans critères masque le problème qui compte.
## Audit du design system : [périmètre]
**Révisé :** [composants, fichiers de tokens] | **Résultats :** [nombre par catégorie]
### Nommage
| Problème | Où | Recommandation |
|---|---|---|
### Couverture des tokens
| Catégorie | Tokens définis | Valeurs en dur | Correspondant à un token existant |
|---|---|---|---|
### Complétude des composants
| Composant | États | Variantes | Documentation | Accessibilité |
|---|---|---|---|---|
| Bouton | complet | partiel : pas de taille icône seule | manquant | anneau de focus présent |
### Actions prioritaires
1. [Impact utilisateur ou équipe le plus élevé en premier, avec l'effort nécessaire]
Documenter
Documentez un composant réutilisable pour tous ceux qui le consomment. Prenez les props et l'exemple de code du composant réel, pas d'une API inventée.
## Composant : [Nom]
[Ce que c'est et quand l'utiliser — et quand utiliser autre chose]
### Variantes
| Variante | Quand l'utiliser |
|---|---|
### Props
| Prop | Type | Défaut | Description |
|---|---|---|---|
### États
| État | Visuel | Comportement |
|---|---|---|
### Accessibilité
- **Rôle :** [rôle ou élément natif]
- **Clavier :** [Tab, Entrée, Espace, Échap, flèches]
- **Lecteur d'écran :** [annoncé comme …]
### À faire et à ne pas faire
| À faire | À ne pas faire |
|---|---|
### Exemple
[Un court extrait dans le framework du projet]
Étendre
Avant de proposer quelque chose de nouveau, listez les composants existants qui s'en approchent et dites pourquoi chacun ne suffit pas ; la plupart des demandes aboutissent à une nouvelle variante. Un nouveau composant réutilise les tokens existants et ne propose un nouveau token qu'avec sa justification.
## Composant proposé : [Nom]
### Problème
[Le besoin utilisateur ou le manque]
### Options existantes
| Composant | Ce qu'il partage | Pourquoi il ne suffit pas |
|---|---|---|
### Conception
Props, variantes et états comme dans le modèle de documentation ; tokens utilisés.
### Accessibilité
Rôle, comportement clavier et lecteur d'écran.
### Questions ouvertes
[Décisions nécessitant une revue de design]
Les composants et les tokens du système sont le sujet de cette méthode. Une fiche technique pour une fonctionnalité ou un écran, et la direction visuelle d'un nouveau produit, sont un travail de design séparé ; un audit système ne remplace pas non plus un audit WCAG.