Guide · Conception web
Design system web : rendre les composants cohérents, accessibles et maintenables
Guide pour définir des styles, composants et règles de contenu réutilisables sans figer les parcours ni sacrifier l’accessibilité et la performance.
Réponse rapide
Un système de composants utile réduit les incohérences et facilite les évolutions. Il documente les décisions prises dans de vrais parcours.
- Inventorier les motifs récurrents avant de créer des composants.
- Définir les états interactifs autant que l’apparence au repos.
- Documenter le contenu attendu et les usages déconseillés.
- Tester les composants dans des pages complètes et sur plusieurs écrans.
1. Partir des pages existantes et des tâches
Un bouton, une carte ou un formulaire ne devient réutilisable que si sa fonction est stable. Analysez plusieurs pages et situations : découverte d’une offre, lecture d’un guide, prise de contact et navigation mobile. Regroupez les éléments qui accomplissent le même travail plutôt que ceux qui se ressemblent simplement.
L’inventaire révèle aussi les écarts utiles. Une carte éditoriale et une carte de service peuvent partager des styles, tout en exigeant des informations et des actions différentes.
- Lister les motifs répétés et leur rôle.
- Repérer les variantes nécessaires par contexte.
- Supprimer les variantes qui n’expriment aucune différence utile.
2. Définir des fondations faciles à faire évoluer
Couleurs, typographies, espacements et largeurs de contenu sont des décisions communes. Les nommer selon leur usage facilite leur évolution. Une valeur de couleur isolée dans chaque page rend la maintenance lente ; un jeton partagé permet de corriger les contrastes de manière cohérente.
Les fondations doivent rester assez souples pour les titres longs, les langues à mots plus étendus et les écritures de droite à gauche. Une interface multilingue se teste avec de vrais textes, pas seulement avec des chaînes courtes de démonstration.
- Nommer les couleurs par rôle plutôt que par teinte seule.
- Prévoir la croissance du texte et le retour à la ligne.
- Contrôler les contrastes sur les états réels.
3. Décrire le comportement complet du composant
Un composant interactif comporte des états de focus, de survol, de désactivation, de chargement et d’erreur. Son nom accessible, son ordre de lecture et sa réaction au clavier font partie de sa définition. Un simple dessin de bouton ne suffit pas.
Documentez également les contraintes de contenu : longueur conseillée du titre, image facultative ou obligatoire, rôle du lien et formulation de l’action. Ces règles empêchent le composant de devenir une coquille flexible mais incohérente.
- Définir tous les états visibles et accessibles.
- Fournir un exemple de contenu réaliste.
- Préciser quand utiliser un lien, un bouton ou un contrôle de formulaire.
4. Faire évoluer le système avec le site
Un design system trop théorique devient une collection inutilisée. Introduisez les composants au rythme des pages concrètes, puis révisez-les quand un nouveau besoin montre une limite. Gardez une source de vérité et un circuit simple pour proposer, tester et retirer une variante.
La qualité se vérifie dans la page finale : lisibilité, navigation au clavier, affichage mobile, chargement et cohérence des appels à l’action. Les mêmes contrôles doivent accompagner chaque changement du système.
- Tester dans au moins deux contextes de page.
- Noter les décisions et les exceptions acceptées.
- Retirer les styles et variantes obsolètes.
Quand créer un composant partagé ?
| Situation | Décision | Contrôle |
|---|---|---|
| Même fonction sur plusieurs pages | Composant commun | Comportement identique |
| Même apparence, rôles différents | Variantes ou composants distincts | Nom et action explicites |
| Cas unique | Motif local d’abord | Éviter l’abstraction prématurée |
| Nouvelle langue | Tester le composant existant | Débordement et sens de lecture |
Avant d’avancer
La check-list opérationnelle
- Les composants répondent à un besoin observé.
- Les états focus, erreur et désactivation sont définis.
- Les textes longs et les langues du site sont testés.
- Les règles de contenu sont documentées.
- Une page complète valide la performance et l’accessibilité.
Questions fréquentes
Les précisions à connaître
Un petit site a-t-il besoin d’un design system ?
Il a au minimum besoin de règles communes pour les couleurs, la typographie, les espacements et les composants répétés. La documentation peut rester légère et grandir avec le site.
Faut-il tout standardiser ?
Non. Partagez ce qui remplit la même fonction et gardez une marge de création pour les besoins réellement distincts.
Documentation
Sources de référence
Ces ressources officielles complètent les arbitrages et permettent de vérifier les recommandations dans leur contexte.
