/design-system

Si tu vois des espaces réservés inconnus ou si tu dois vérifier quels outils sont connectés, consulte CONNECTORS.md.

Gère ton système de design — audite la cohérence, documente les composants ou conçois de nouveaux modèles.

Utilisation

/design-system audit                    # Audit complet du système
/design-system document [component]     # Documenter un composant
/design-system extend [pattern]         # Concevoir un nouveau composant ou modèle

Composants d'un système de design

Design Tokens

Valeurs atomiques qui définissent le langage visuel :

• Couleurs (marque, sémantique, neutre)
• Typographie (échelle, poids, hauteur de ligne)
• Espacement (échelle, padding des composants)
• Bordures (rayon, épaisseur)
• Ombres (niveaux d'élévation)
• Animation (durées, accélérations)

Composants

Éléments d'interface réutilisables avec :

• Variantes (primaire, secondaire, fantôme)
• États (par défaut, survol, actif, désactivé, chargement, erreur)
• Tailles (sm, md, lg)
• Comportement (interactions, animations)
• Accessibilité (ARIA, clavier)

Modèles

Solutions d'interface courantes combinant des composants :

• Formulaires (groupes d'entrée, validation, soumission)
• Navigation (barre latérale, onglets, fil d'Ariane)
• Affichage de données (tableaux, cartes, listes)
• Retours (toasts, modales, messages en ligne)

Principes

1. La cohérence plutôt que la créativité — Le système existe pour que les équipes ne réinventent pas la roue
2. La flexibilité dans les contraintes — Les composants doivent être composables, pas rigides
3. Documenter tout — Si ce n'est pas documenté, ça n'existe pas
4. Versionnage et migration — Les changements cassants nécessitent des chemins de migration

Résultat — Audit

## Audit du système de design

### Résumé
**Composants examinés :** [X] | **Problèmes trouvés :** [X] | **Score :** [X/100]

### Cohérence de la nomenclature
| Problème | Composants | Recommandation |
|----------|-----------|----------------|
| [Nomenclature incohérente] | [Liste] | [Norme à adopter] |

### Couverture des tokens
| Catégorie | Définis | Valeurs codées en dur trouvées |
|-----------|---------|------------------------------|
| Couleurs | [X] | [X] instances de hex codés en dur |
| Espacement | [X] | [X] instances de valeurs arbitraires |
| Typographie | [X] | [X] instances de polices/tailles personnalisées |

### Complétude du composant
| Composant | États | Variantes | Docs | Score |
|-----------|-------|-----------|------|-------|
| Button | ✅ | ✅ | ⚠️ | 8/10 |
| Input | ✅ | ⚠️ | ❌ | 5/10 |

### Actions prioritaires
1. [Amélioration la plus impactante]
2. [Deuxième priorité]
3. [Troisième priorité]

Résultat — Document

## Composant : [Nom]

### Description
[À quoi sert ce composant et quand l'utiliser]

### Variantes
| Variante | Utiliser quand |
|----------|----------------|
| [Primaire] | [Actions principales] |
| [Secondaire] | [Actions de support] |

### Props / Propriétés
| Propriété | Type | Par défaut | Description |
|-----------|------|-----------|-------------|
| [prop] | [type] | [défaut] | [description] |

### États
| État | Visuel | Comportement |
|------|--------|-------------|
| Par défaut | [description] | — |
| Survol | [description] | [interaction] |
| Actif | [description] | [interaction] |
| Désactivé | [description] | Non interactif |
| Chargement | [description] | [animation] |

### Accessibilité
- **Rôle** : [rôle ARIA]
- **Clavier** : [Comportement de Tab, Entrée, Échap]
- **Lecteur d'écran** : [Annoncé comme...]

### À faire et à ne pas faire
| ✅ À faire | ❌ À ne pas faire |
|-----------|-----------------|
| [Meilleure pratique] | [Anti-modèle] |

### Exemple de code
[Extrait de code adapté au framework]

Résultat — Extend

## Nouveau composant : [Nom]

### Problème
[Quel besoin utilisateur ou lacune ce composant résout]

### Modèles existants
| Composant associé | Similitude | Pourquoi ce n'est pas suffisant |
|-------------------|-----------|--------------------------------|
| [Composant] | [Ce qui est partagé] | [Ce qui manque] |

### Design proposé

#### API / Props
| Propriété | Type | Par défaut | Description |
|-----------|------|-----------|-------------|
| [prop] | [type] | [défaut] | [description] |

#### Variantes
| Variante | Utiliser quand | Visuel |
|----------|----------------|--------|
| [Variante] | [Scénario] | [Description] |

#### États
| État | Comportement | Notes |
|------|-------------|-------|
| Par défaut | [Description] | — |
| Survol | [Description] | [Interaction] |
| Désactivé | [Description] | Non interactif |
| Chargement | [Description] | [Animation] |

#### Tokens utilisés
- Couleurs : [Quels tokens]
- Espacement : [Quels tokens]
- Typographie : [Quels tokens]

### Accessibilité
- **Rôle** : [rôle ARIA]
- **Clavier** : [Interactions attendues]
- **Lecteur d'écran** : [Annoncé comme...]

### Questions ouvertes
- [Décision nécessitant un examen de design]
- [Cas limite à résoudre]

Si des connecteurs sont disponibles

Si ~~outil de design est connecté :

• Audite les composants directement dans Figma — vérifie la nomenclature, les variantes et l'utilisation des tokens
• Extrait les propriétés des composants et la structure des calques pour la documentation

Si ~~base de connaissances est connectée :

• Recherche la documentation des composants existants et les directives d'utilisation
• Publie la documentation mise à jour sur ton wiki

Conseils

1. Commence par un audit — Sache où tu en es avant de décider où aller.
2. Documente au fur et à mesure — Il est plus facile de documenter un composant pendant sa conception.
3. Priorise la couverture plutôt que la perfection — 80 % des composants documentés vaut mieux que 100 % de 10 composants.