Une palette de marque se reduit trop souvent a six pastilles dans un Figma : primaire, secondaire, deux accents, deux neutres. Cela ne suffit pas. Un systeme couleur doit survivre au produit reel, aux contraintes d'accessibilite, et soutenir la conversion. Voici comment nous le construisons.
Le piege des six pastilles
Six couleurs n'ont jamais permis de coder une interface complete. Il manque : les variations claires et foncees de la primaire (pour les hovers, les fonds, les bordures), les variations grises (pour le texte muted, les separateurs, les disabled), les couleurs semantiques (succes, erreur, warning, info), les couleurs d'etat (selected, focus, pressed).
Resultat sur le terrain : les developpeurs improvisent, et la marque diverge en six mois. La palette consultee dans Figma ne ressemble plus a rien sur le produit.
Le probleme ne vient pas seulement du nombre de couleurs. Il vient du fait que la palette est pensee comme un objet de presentation, pas comme une infrastructure. Une page d'accueil, une landing page SaaS, un tunnel de paiement, un dashboard et un email transactionnel ne sollicitent pas les couleurs de la meme maniere. Les six pastilles peuvent sembler elegantes dans une planche de marque, puis devenir insuffisantes des que l'interface doit exprimer la hierarchie, l'etat, l'urgence ou la confiance.
Dans un projet reel, une couleur n'est jamais seule. Elle vit avec du texte, des icones, des bordures, des ombres, des surfaces, des photographies, des composants interactifs. C'est pourquoi une palette doit etre testee sur des usages, pas seulement admiree sur un fond blanc.
Partir des usages, pas de l'inspiration
La premiere question n'est pas : "Quelle couleur represente la marque ?" La bonne question est : "Quelles decisions l'utilisateur doit-il prendre, et quelles couleurs vont l'aider a les prendre sans confusion ?" Une palette efficace part des parcours : decouvrir, comparer, s'inscrire, acheter, reserver, contacter, confirmer.
Pour une PME francophone, cela signifie souvent que la palette doit couvrir des besoins tres concrets : un bouton de demande de devis, un badge "disponible", un bandeau d'information, un message d'erreur dans un formulaire, un tarif mis en avant, un temoignage client, un lien secondaire, une alerte de stock ou une confirmation de paiement.
Avant de produire les teintes, nous listons les situations couleur du produit :
- Actions primaires : demander une demo, reserver un appel, acheter, envoyer un formulaire.
- Actions secondaires : lire plus, comparer, telecharger, modifier une option.
- Etats systeme : succes, erreur, avertissement, information, chargement, desactivation.
- Surfaces : fond de page, cartes, sections alternees, encarts, tableaux, modales.
- Contenu editorial : liens, citations, surlignages, tags, categories, notes.
Cette approche rejoint le travail de fond d'une identite visuelle : la couleur doit traduire une intention, mais aussi rester utilisable. Si votre socle de marque n'est pas encore clair, commencez par consolider une charte de marque coherente avant de produire un systeme d'interface complet.
Le systeme par paliers numerotes
Plutot que "primaire, secondaire, accent", utiliser des paliers numerotes par couleur. Par exemple, pour la couleur brand : brand-50, brand-100, brand-200, jusqu'a brand-900. Idem pour gray, success, error, warning, info.
Ce systeme, popularise par Tailwind, Radix et Material, a un avantage decisif : il decuple la palette utilisable sans alourdir le brief. Le developpeur sait que brand-500 est la couleur "principale", brand-100 son fond clair, brand-900 son texte sur fond clair. Aucune ambiguite.
La force des paliers numerotes est leur regularite. Un designer peut choisir brand-50 pour un fond tres discret, brand-200 pour une bordure, brand-500 pour un bouton, brand-700 pour un hover et brand-900 pour un texte accentue. Le developpeur comprend la logique sans demander une nouvelle decision a chaque composant.
Un systeme simple peut commencer ainsi :
- 50 a 100 : fonds tres clairs, zones selectionnees, encarts doux.
- 200 a 300 : bordures, separations, fonds de badges, illustrations legeres.
- 400 a 600 : couleurs visibles, boutons, pictogrammes, elements actifs.
- 700 a 900 : textes sur fond clair, hovers, contrastes forts, zones denses.
Attention toutefois : les paliers ne doivent pas etre generes aveuglement par un outil. Une couleur jaune, par exemple, ne se comporte pas comme une couleur bleue. Ses paliers fonces peuvent vite devenir marron, et ses paliers clairs manquer de contraste. Chaque famille doit etre ajustee a l'oeil, puis verifiee en contexte.
Dans Figma, les styles doivent porter les memes noms que les tokens de code. Comme le rappelle Figma Learn, une bonne organisation des composants et styles facilite la collaboration entre design et production. Le nommage est donc un livrable, pas un detail.
Verifier les contrastes des le brief
Une palette qui ne passe pas WCAG AA n'est pas une palette, c'est un cauchemar a venir. Avant de valider la primaire, tester : contraste contre fond blanc (minimum 4.5:1 pour le texte normal), contraste contre fond noir (idem), contraste entre primaire et son texte associe (boutons), contraste des états hover et disabled.
Un outil rapide : webaim.org/resources/contrastchecker. Une fois la palette validee, generer un tableau de contrastes pour les developpeurs : c'est le meilleur livrable que l'on puisse fournir.
Les Web Content Accessibility Guidelines WCAG 2.2 donnent le cadre de reference pour les contrastes, la perception et l'accessibilite des interfaces. L'enjeu n'est pas seulement reglementaire ou technique : un contraste insuffisant ralentit la lecture, diminue la confiance et complique la decision.
Il faut tester au minimum les combinaisons suivantes :
- Texte principal sur fond clair : titres, paragraphes, labels de formulaire.
- Texte secondaire sur fond clair : metadonnees, aides, descriptions, placeholders.
- Texte blanc sur couleur brand : boutons, badges, bandeaux, cartes accentuees.
- Texte couleur brand sur fond clair : liens, chiffres cles, elements actifs.
- Etats interactifs : hover, focus, pressed, disabled, selected.
Le cas le plus souvent oublie est le focus. Un contour de focus presque invisible peut rendre la navigation clavier penible. Or une interface de qualite doit rester utilisable sans souris. Le focus n'est pas une decoration : c'est une information d'orientation.
Lors d'un audit UX avant refonte, nous regardons systematiquement si la couleur porte seule une information. Si une erreur de formulaire n'est signalee que par du rouge, sans message clair ni icone ni indication textuelle, l'interface devient fragile pour une partie des utilisateurs.
Reserver une couleur a la conversion
Si la marque est bleue, le bouton principal ne doit pas etre bleu. Sinon les CTAs se fondent dans la masse. Reserver une couleur d'accent contrastee, utilisee exclusivement sur les boutons de conversion, augmente leur visibilite et leur clic.
Exemple : Stripe utilise un bleu nuit comme couleur de marque, mais ses CTAs principaux sont en violet electrique. Linear utilise un degrade violet-rose pour la marque, mais ses CTAs sont en blanc sur fond noir. La couleur conversion n'est pas la couleur marque. C'est une regle.
Cette regle doit toutefois etre appliquee avec nuance. Une couleur de conversion ne sert a rien si elle est utilisee partout : boutons primaires, pictogrammes, liens, tags, illustrations, surlignages. Elle doit rester rare. Plus elle est rare, plus elle signale une action importante.
En pratique, nous definissons souvent trois niveaux d'action :
- Action primaire : couleur conversion, libelle direct, position visible.
- Action secondaire : bouton neutre, contour, texte ou fond discret.
- Action tertiaire : lien texte, option contextuelle, navigation secondaire.
La couleur ne remplace pas la clarte du message. Un bouton orange avec un libelle vague comme "Envoyer" convertira moins bien qu'un bouton plus sobre avec une promesse claire comme "Recevoir mon devis". La palette soutient la conversion, mais la hierarchie, la microcopie et la mise en page font le reste.
Pour les pages de vente, l'enjeu est encore plus net. Dans notre case study sur une page pricing SaaS, la couleur n'a pas ete traitee comme un embellissement, mais comme un outil de priorisation : mettre en evidence l'offre recommandee, clarifier les comparaisons et rendre l'action principale immediate.
Ne pas confondre emotion et lisibilite
Les couleurs portent une emotion, mais elles ne doivent jamais sacrifier la lecture. Une marque peut vouloir paraitre premium, chaleureuse, technologique ou audacieuse ; cela ne signifie pas que toute l'interface doit etre sombre, pastel, neon ou monochrome.
Un exemple frequent : une PME choisit une couleur tres elegante pour sa marque, comme un beige sable, un vert sauge ou un bleu gris. Ces teintes fonctionnent parfaitement en fond, en photographie ou en print. Mais utilisees comme texte de lien ou bouton principal, elles manquent souvent de presence. Il faut alors creer des paliers plus profonds, ou ajouter une couleur d'action distincte.
Autre point d'attention : la couleur interagit avec la typographie. Une fonte fine, un gris clair et une petite taille produisent vite une interface difficile a lire. A l'inverse, une typographie robuste permet parfois d'utiliser des couleurs plus subtiles. Si vos landing pages reposent fortement sur le contenu, alignez la palette avec une typographie de landing page SaaS lisible et persuasive.
Les recherches de Nielsen Norman Group rappellent regulierement que l'utilisabilite repose sur la clarte, la comprehension et la reduction de l'effort cognitif. Une palette reussie n'est donc pas celle qui impressionne le plus en atelier, mais celle qui aide l'utilisateur a comprendre plus vite.
Le mode sombre n'est pas une inversion
Beaucoup de palettes prevoient un mode sombre par inversion : ce qui etait fonce devient clair, et inversement. Resultat : un noir pur fatigant, des accents qui paraissent fluo, des contrastes desequilibres.
Le mode sombre est un theme alternatif, pas un negatif. Il necessite ses propres paliers (souvent moins satures et legerement plus chauds), ses propres semantiques (rouge moins agressif, vert plus desature), et ses propres tests de contraste.
Sur fond sombre, les couleurs semblent souvent plus lumineuses qu'elles ne le sont vraiment. Une primaire vive qui fonctionne bien sur blanc peut devenir agressive en dark mode. Les ombres disparaissent, les bordures deviennent plus importantes, et les surfaces doivent etre distinguees par des ecarts subtils de luminosite.
Un bon theme sombre evite generalement le noir absolu pour les grandes surfaces. Il utilise plutot des gris tres profonds, puis reserve les contrastes les plus forts aux textes, aux focus et aux actions essentielles. Les couleurs semantiques doivent aussi etre revues : un rouge d'erreur trop sature peut prendre toute la page, alors qu'un rouge plus calme associe a un texte explicite sera plus utile.
Le mode sombre doit etre teste dans les vrais composants : formulaires, cartes, menus, tableaux, modales, emails, graphiques. Il ne suffit pas de voir une page hero en dark mode pour valider un theme complet.
La validation par les emails transactionnels
Une palette validee uniquement sur le site est une palette qui va casser sur les emails. Les clients email (Outlook, Gmail, Apple Mail) interpretent les couleurs differemment, certaines ne supportent pas le mode sombre forcé, d'autres convertissent en JPG.
Tester la palette des le brief sur les trois templates emails les plus envoyes : welcome, transactional, marketing. Si les couleurs cassent ou paraissent ternes, ajuster avant de partir en design final.
Les emails imposent des contraintes que les interfaces web modernes masquent souvent. Les degradés peuvent etre mal rendus, les polices de marque ne chargent pas toujours, les fonds sombres peuvent etre transformes par certains clients, et les boutons doivent rester lisibles meme si une partie du style est ignoree.
Pour une palette robuste, creez une version email de vos tokens :
- Un fond principal tres fiable : blanc, gris tres clair ou sombre controle.
- Une couleur bouton compatible : lisible avec du texte blanc ou tres fonce.
- Des couleurs semantiques simples : succes, erreur, alerte, information.
- Des alternatives sans image : si les visuels ne chargent pas, le message reste clair.
Cette verification evite un ecart classique : une marque superbe sur le site, mais terne ou incoherente dans les confirmations de commande, les relances, les factures ou les emails de bienvenue. Or ces emails sont souvent des points de contact cruciaux pour la confiance.
Documenter en code, pas seulement en Figma
Le livrable final d'une palette en 2026 n'est plus un Figma. C'est un fichier de tokens (JSON ou CSS Custom Properties) que les developpeurs peuvent importer directement. Format usuel : un objet JSON par couleur, avec ses paliers et leurs contrastes calcules.
Ce livrable assure que la palette survit au passage entre design, developpement, CMS, email et futures evolutions. Il transforme une intention visuelle en langage partage. Sans tokens, chaque integration devient une interpretation ; avec tokens, chaque composant peut reutiliser la meme source.
Un token couleur peut decrire plusieurs niveaux :
- Valeur brute : brand-500 = une valeur hexadecimale ou HSL.
- Role fonctionnel : color-action-primary-background = brand-600.
- Etat : color-action-primary-hover = brand-700.
- Theme : light ou dark, avec valeurs adaptees.
Cette distinction est importante. Si un bouton appelle directement brand-600, changer la couleur de conversion devient complique. Si le bouton appelle color-action-primary-background, la marque peut evoluer sans casser tous les composants.
Sur le plan technique, les MDN Web Docs documentent largement les variables CSS, les couleurs et les bonnes pratiques front-end. C'est une base solide pour aligner designers et developpeurs autour d'un vocabulaire commun.
Tester les couleurs dans un prototype vivant
Une palette validee sur une planche statique reste theorique. Avant de figer la direction, il faut la tester dans un prototype vivant : une home, une page service, une page pricing ou une fiche produit, un formulaire, un email et au moins un etat d'erreur.
Ce prototype n'a pas besoin d'etre complet. Il doit surtout faire apparaitre les tensions : trop de couleurs concurrentes, CTA pas assez visible, texte secondaire trop faible, alerte trop agressive, fond de section trop proche des cartes, liens confondus avec du texte normal.
Nous recommandons de verifier la palette dans quatre conditions :
- Lecture rapide : l'utilisateur comprend-il immediatement ou agir ?
- Navigation mobile : les boutons et contrastes restent-ils clairs sur petit ecran ?
- Contenu reel : la palette fonctionne-t-elle avec de vrais textes, prix, photos et logos ?
- Performance : les effets visuels ne degradent-ils pas l'experience ?
Sur ce dernier point, Google web.dev rappelle l'importance de la performance et des Core Web Vitals dans la qualite de l'experience web. Une palette qui depend de videos lourdes, de grands degradés animes ou d'effets complexes peut nuire a la rapidite percue. La couleur doit renforcer l'interface, pas l'alourdir.
Ce test vivant s'integre tres bien dans un cycle court. Dans notre methode du brief au beta en six semaines, la palette est confrontee tot aux composants reels afin d'eviter les arbitrages tardifs et couteux.
Gouvernance : comment eviter la derive dans le temps
Une palette ne meurt pas le jour de sa livraison. Elle se degrade lentement : un gris ajoute pour une urgence, un rouge different dans une campagne, un bouton special pour une page, un email code a part, un prestataire qui reprend une ancienne version du logo.
La solution n'est pas de tout verrouiller. Une marque doit pouvoir evoluer. Mais il faut une gouvernance simple :
- Une source de verite : tokens, Figma et documentation alignes.
- Des regles d'usage : quand utiliser la couleur brand, conversion, neutre ou semantique.
- Un processus d'ajout : aucune nouvelle couleur sans role documente.
- Une revue periodique : verification des pages, emails, composants et campagnes.
La question a poser pour chaque nouvelle couleur est simple : "Quel probleme resout-elle que les couleurs existantes ne resolvent pas ?" Si la reponse est floue, il s'agit souvent d'une preference ponctuelle, pas d'un besoin systeme.
Une bonne documentation doit aussi montrer les interdits. Par exemple : ne pas utiliser la couleur conversion pour des icones decoratives, ne pas poser brand-500 sur un fond brand-600, ne pas utiliser success pour un message promotionnel, ne pas remplacer les messages d'erreur par une simple bordure rouge.
Conclusion : une palette est un outil de decision
Une palette qui convertit n'est pas une palette plus vive, plus tendance ou plus originale. C'est une palette qui rend les priorites visibles, qui soutient la lecture, qui respecte les contrastes, qui fonctionne en production et qui garde sa coherence dans le temps.
Au-dela de la charte, la couleur devient un systeme. Elle relie la marque, l'UX, le contenu, le developpement et la performance commerciale. C'est precisement la que se joue la difference entre une identite agreable a regarder et une interface capable d'aider les utilisateurs a agir.
Questions fréquentes
Combien de couleurs faut-il dans une palette web efficace ?
Il n'y a pas de nombre universel. Une palette efficace comprend surtout des familles de couleurs avec plusieurs paliers, des neutres, des couleurs semantiques et une couleur d'action clairement reservee aux conversions.
La couleur du bouton principal doit-elle etre la couleur de marque ?
Pas toujours. Si la couleur de marque est deja tres presente dans l'interface, une couleur d'action distincte peut rendre le bouton principal plus visible et plus facile a identifier.
Faut-il creer une palette separee pour le mode sombre ?
Oui. Le mode sombre ne doit pas etre une simple inversion de la palette claire. Il demande des valeurs adaptees, des contrastes verifies et des couleurs souvent moins saturees.
Quel est le livrable ideal pour transmettre une palette aux developpeurs ?
Le livrable ideal combine les styles Figma, une documentation d'usage et des tokens exploitables en code, par exemple en JSON ou en variables CSS.