Une Palette UI, ce n’est pas “un joli nuancier” posé dans un fichier Figma. C’est un système de couleurs structuré, documenté et gouverné, conçu pour rester lisible, accessible et cohérent dans le temps, même quand l’équipe grandit. L’objectif est simple : permettre à tout le monde (design, produit, dev, marketing) d’utiliser les mêmes couleurs pour les mêmes raisons, sans débat permanent ni dérive visuelle. Dans cet article, vous allez voir comment poser les bases d’une palette durable, puis comment mettre en place des tokens, des règles et des rôles pour aligner l’équipe.
L’essentiel à retenir (pour construire une Palette UI utilisable par toute l’équipe)
- Ne partez pas d’une “liste de couleurs”, partez d’usages : fond, texte, bordure, état, feedback (succès, alerte, erreur).
- Séparez strictement les couleurs “brutes” (valeurs) des couleurs “sémantiques” (rôles) via des tokens.
- Prévoyez une stratégie de contraste dès le départ (WCAG) pour le texte, les icônes, les bordures et les composants interactifs.
- Limitez les degrés de liberté : quelques neutres solides + un primaire + des feedbacks + des états suffisent dans la majorité des produits.
- Documentez les règles (quand utiliser quoi) et pas seulement les hexadécimaux.
- Outillez la synchronisation : Figma + variables/tokens + export vers le code (JSON) si possible.
- Mettez en place une gouvernance : qui peut créer une couleur, qui valide, et comment on déprécie une couleur existante.
Les bases d’une Palette UI cohérente et durable
Penser “système” avant “couleurs”
Une palette UI cohérente commence par une intention : servir l’interface, pas la décoration. Concrètement, cela veut dire que chaque couleur doit avoir un rôle identifiable dans la hiérarchie visuelle (priorité, lisibilité, interaction) et dans la communication (statuts, messages, alertes).
Dans un produit numérique, les couleurs les plus utilisées ne sont souvent pas les couleurs “de marque”, mais les neutres : fonds, surfaces, séparateurs, textes. Une palette durable investit donc d’abord dans une échelle de gris robuste (ou “neutres”) et des règles d’usage claires, avant d’étendre les accents.
Enfin, une palette UI n’est “durable” que si elle anticipe les cas réels : modes clair/sombre, états (hover, focus, disabled), tableaux denses, interfaces admin, et contenus générés par les utilisateurs. Sans ces scénarios, vous aurez une palette qui marche en démo, puis casse en production.
Structurer la palette : neutres, accents et couleurs de feedback
Dans la plupart des systèmes, on retrouve trois familles stables : les neutres (surfaces et typographie), les accents (souvent le primaire et parfois un secondaire), et les couleurs de feedback (succès, information, avertissement, erreur). Cette structure limite l’explosion du nombre de couleurs et facilite la prise en main par toute l’équipe.
Les neutres doivent couvrir plusieurs niveaux de contraste, car ils servent à créer de la profondeur (background, surface, elevated) et à gérer la densité (bordures, separators, placeholders). Si vos neutres sont trop proches, vous compenserez avec des “couleurs au hasard”, et le système se fragmente.
Pour les feedbacks, privilégiez des échelles (light à dark) plutôt qu’une couleur unique. Une alerte “erreur” ne se résume pas à un rouge : il vous faut un fond léger, un texte lisible, une bordure, éventuellement une icône, et des variantes selon le thème (clair/sombre).
Accessibilité : le vrai test de solidité
Une palette UI fiable respecte la lisibilité, pas seulement l’esthétique. Le point le plus critique est le contraste texte/fond et icône/fond, mais il faut aussi penser au focus visible, aux états désactivés, et aux éléments fins comme les bordures.
En pratique, visez des couples de couleurs qui passent les exigences WCAG pour le texte courant et les éléments interactifs. Si vous n’êtes pas certain, restez prudent : un contraste “limite” finit souvent illisible sur certains écrans, en mobilité, ou pour des utilisateurs fatigués visuellement.
Autre point souvent négligé : ne pas dépendre uniquement de la couleur pour transmettre une information (ex. “rouge = erreur”). Ajoutez un libellé, une icône, une bordure ou un pattern d’état. Une palette UI bien conçue est aussi une palette “compréhensible” sans la couleur.
Rôles, tokens et règles pour aligner l’équipe
Du nuancier aux tokens : valeurs, sémantique et composants
Pour qu’une palette soit utilisable par toute l’équipe, elle doit être traduite en tokens (jetons de design), c’est-à-dire des noms stables qui représentent un usage, pas une teinte. On distingue généralement les tokens “primitifs” (valeurs brutes) et les tokens “sémantiques” (rôles), puis les tokens “composants” (cas d’usage précis).
Exemple : au lieu d’utiliser directement #1E40AF, vous définissez un token primitif type blue-700, puis un token sémantique action-primary qui pointe vers blue-700. Le composant “Button primary” utilisera action-primary, ce qui permet de changer la teinte plus tard sans casser l’interface.
Cette séparation évite deux dérives fréquentes : la multiplication de couleurs quasi identiques (“un bleu un peu différent pour ce bouton”) et la dépendance au branding. Votre marque peut évoluer, mais les rôles UI (texte, fond, action, feedback) restent.
| Niveau | Ce que c’est | Exemple de nommage | À quoi ça sert |
|---|---|---|---|
| Primitif | Valeur brute (palette) | neutral-0, neutral-900, blue-700 | Avoir un nuancier maîtrisé et réutilisable |
| Sémantique | Rôle dans l’UI | text-primary, surface-default, border-subtle, action-primary | Assurer la cohérence d’usage |
| Composant | Application à un composant | button-primary-bg, input-border-focus | Industrialiser le design system |
Règles d’usage : éviter les interprétations et les “exceptions”
Les tokens ne suffisent pas si l’équipe ne sait pas quand utiliser chaque couleur. Une bonne documentation répond à des questions simples : “Quel token pour un texte secondaire ?”, “Quel fond pour une carte élevée ?”, “Comment traiter une alerte dans un modal ?”. Sans règles, chacun improvise et le système se désaligne.
Définissez des règles minimales, directement actionnables, par exemple :
text-primarypour le contenu principal,text-secondarypour l’aide,text-disableduniquement quand l’élément est réellement inactif.action-primaryréservé à l’action principale d’un écran (ou 1 par zone), sinon utilisezaction-secondary.border-subtlepour les séparations standards, et une bordure plus contrastée uniquement pour les champs en erreur ou en focus.
Prévoyez aussi une politique d’exception. Par exemple : “Toute nouvelle couleur sémantique doit prouver qu’elle ne peut pas être couverte par un token existant, et être validée en design review.” Cela paraît rigide, mais c’est exactement ce qui rend une palette utilisable à long terme.
Gouvernance et outillage : Figma, code, et cycle de vie
Pour qu’une Palette UI soit “utilisable par toute l’équipe”, elle doit exister au même niveau en design et en code. Côté design, Figma propose aujourd’hui des variables (notamment utiles pour clair/sombre) et des bibliothèques. Côté dev, l’objectif est d’exposer les mêmes tokens via des variables CSS, un fichier JSON, ou un thème dans votre framework (selon votre stack).
La gouvernance est l’autre moitié du travail. Définissez clairement les rôles : qui maintient la palette (souvent un duo design system designer + lead front), qui valide les ajouts, et comment les demandes arrivent (ticket, doc, exemple). Sans ce circuit, la palette devient un “document mort” que l’équipe contourne.
Enfin, gérez le cycle de vie : ajout, modification, dépréciation. Une couleur ne devrait pas disparaître du jour au lendemain si elle est utilisée dans l’app. Marquez-la comme “dépréciée”, proposez un remplaçant, et planifiez la migration. C’est ce niveau de rigueur qui transforme une palette en système, et un système en standard d’équipe.
Construire une Palette UI utilisable par toute l’équipe revient à faire trois choses : limiter et structurer les couleurs (neutres, accents, feedback), garantir la lisibilité (contraste, états, non-dépendance à la couleur), et traduire le tout en tokens gouvernés et documentés. Si vous devez passer à l’action, commencez par auditer l’existant, définir une échelle de neutres solide, puis créer une petite couche de tokens sémantiques (texte, surface, bordure, action, feedback) avant de décliner au niveau des composants. Une palette bien conçue ne se remarque pas : elle rend l’interface plus claire, et l’équipe nettement plus rapide.
