Système Jemaï · v2.0
Le système qui construit ce site
Ce site est construit avec son propre Design System, documenté ici en entier. Il sert de démonstration de méthode : comment passer de valeurs brutes à des décisions partagées, puis à des composants que les équipes adoptent.
Cinq principes
Les principes servent à trancher quand deux bonnes idées s'opposent. J'ai formulé chacun pour qu'il puisse dire non à quelque chose.
La cohérence avant la créativité locale
Un écran original qui casse le système coûte plus cher qu'il ne rapporte. On innove dans le système, par contribution, pas à côté.
Accessible par défaut
Le composant livré est déjà conforme : contraste, focus, clavier, lecteur d'écran. L'équipe produit n'a rien à ajouter pour être en règle.
Les tokens d'abord
Aucune valeur en dur. Une couleur, un espacement ou une durée passent par un token nommé selon son rôle, jamais selon son apparence.
Documenté ou inexistant
Un composant sans documentation, sans exemple et sans règles d'usage n'est pas publié. Il reste en incubation.
L'adoption est le produit
Le succès se mesure à l'usage réel dans les produits. Le nombre de composants n'en dit rien.
Moins, mais mieux
Chaque composant ajouté est un coût de maintenance à vie. On préfère étendre un composant existant plutôt qu'en créer un proche.
Architecture
Le système s'organise en couches. Chaque couche ne connaît que celle du dessous : un composant consomme des tokens sémantiques, jamais des primitives. C'est ce qui permet de changer de thème, de marque ou de densité sans toucher aux composants.
--char-950--fg--accent--btn-radius--space-4Explorer la documentation
Fondations
Couleur, typographie, espacement, grille, rayons, élévation, mouvement et iconographie.
Tokens
Les trois couches, la convention de nommage, les exports et un atelier pour les manipuler en direct.
Composants
25 composants avec démonstration interactive, états, variantes et notes d'accessibilité.
Patterns
12 réponses éprouvées : formulaires, erreurs, états vides, chargement, recherche, tableaux.
Accessibilité
WCAG 2.2 AA, RGAA, vérificateur de contraste et checklists par métier.
Gouvernance
Contribution, versions, rôles, rituels, indicateurs d'adoption et modèle de maturité.
Par où commencer
- Lisez les fondations : elles expliquent pourquoi chaque valeur existe.
- Partez toujours des composants existants. Si un besoin n'est pas couvert, regardez les patterns avant de dessiner.
- Un besoin réellement nouveau ? Ouvrez une demande de contribution (voir Contribuer).
- Consommez les tokens sémantiques, jamais les primitives ni des valeurs en dur.
- Utilisez les composants tels quels ; leurs états et leur accessibilité sont déjà gérés.
- Respectez la politique de versions : l'équipe cœur annonce les changements cassants une version à l'avance.
- Le Design System réduit le coût de chaque écran. Prévoyez du temps pour l'utiliser correctement, pas pour le contourner.
- Suivez les indicateurs d'adoption de votre produit.
- Faites remonter les besoins communs à plusieurs équipes : ce sont les meilleurs candidats à l'intégration dans le système.
- Appliquez les règles de voix et ton : verbes d'action, phrases courtes, vouvoiement.
- Les messages d'erreur disent ce qui s'est passé et comment corriger. Voir le pattern Erreurs.
- Les libellés de boutons décrivent l'action : « Enregistrer », pas « OK ».
Journal des versions
Le journal ci-dessous concerne le système de ce site. Il illustre le format recommandé : une ligne par changement, classée par type.
| Version | Type | Changement |
|---|---|---|
2.0.0 | Cassant | Thème sombre par défaut ; renommage --text-primary → --fg. Alias conservés une version. |
2.0.0 | Ajout | Couche de tokens composants (--btn-*, --card-*, --input-*). |
1.4.0 | Ajout | Composants Segmented control, Skeleton et Toast. |
1.3.2 | Correctif | Focus visible sur les onglets en navigation clavier. |
1.3.0 | Dépréciation | Variante de bouton « outline » remplacée par « secondary ». |