Si tu cherches « pourquoi Figma me propose le mauvais token couleur », tu es au bon endroit. Le bug (ou la “mise à jour”) est simple à vivre et pénible à expliquer : tu tapes un bout du nom d’un token dans la recherche… et Figma te met en avant un truc inattendu parce que la valeur hex du token semble compter plus que le naming. Résultat : tu cliques à côté, tu te méfies de tes conventions, tu ralentis… et à la fin quelqu’un recrée une couleur “vite fait” parce qu’il n’a pas trouvé la bonne.
Mon angle est volontairement terre-à-terre : tu peux attendre que l’UX de recherche redevienne parfaite. Ou tu peux rendre ton design system robuste même quand la recherche se comporte comme une loterie. Et ça, ça se joue sur ton naming, sur la séparation « palette brute vs tokens sémantiques », et sur une vraie source de vérité côté code.
Le symptôme : la recherche Figma match ton hex avant ton naming
Le retour qui revient (et que j’ai vu en équipe) ressemble à ça : tu tapes « prima » pour retrouver color/primary/500, et tu te retrouves avec un token complètement différent, juste parce que son hex contient un caractère qui “matche” mieux. Ça donne une sensation de régression, comme si la recherche n’était plus une recherche de tokens mais une recherche de valeurs déguisée.
Le plus frustrant, c’est que tu fais ce qu’on t’a toujours conseillé de faire sur un design system : un naming cohérent, des préfixes, des namespaces. Et pourtant l’outil te met des bâtons dans les roues au moment le plus fréquent du quotidien : choisir une couleur.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Pourquoi c’est dangereux : tu crois que c’est « juste un bug », mais ça casse ton système
Ce genre de friction ne coûte pas “10 secondes”. Il coûte des décisions. Quand la recherche est imprévisible, les gens changent de comportement : ils cliquent au jugé, ils prennent « presque pareil », ils se disent qu’ils corrigeront plus tard. Et surtout ils arrêtent d’apprendre le naming, parce que “ça ne sert à rien, Figma ne retrouve pas”.
Et là tu as le combo qui tue un design system : plus personne ne fait confiance aux tokens, donc on contourne. Puis on accumule des exceptions. Puis on se retrouve avec des composants qui n’utilisent pas les mêmes variables, et le jour où tu veux faire un rebrand ou introduire des modes (light/dark, high contrast), tu pleures.
Le vrai fix : arrêter de dépendre du search pour « trouver la bonne couleur »
Je vais être direct : si ton workflow repose sur « je tape 4 lettres et je choisis le premier résultat », tu as déjà un point de fragilité. Même si Figma corrige son algo demain, tu restes dépendant d’un comportement UI que tu ne maîtrises pas.
Le bon objectif, ce n’est pas “rendre la recherche agréable”. C’est rendre l’erreur difficile. Quand quelqu’un applique une couleur, il doit être plus simple de prendre le bon token que d’en inventer un autre.
Naming de tokens couleur : fais-le pour survivre à un search imparfait
Un naming « joli » ne suffit pas. Il faut un naming qui tient dans le réel, c’est-à-dire dans une UI de recherche qui peut pondérer n’importe quel champ. Ce qui marche bien, c’est de forcer un namespace ultra explicite au début, puis une structure stable : color/ (ou clr/), ensuite le niveau (palette ou semantic), puis le rôle, puis l’échelle.
Par exemple, color/semantic/text/primary et color/palette/blue/500. Le point important ici, c’est la séparation nette entre « ce que les designers tripotent » (palette) et « ce que les produits consomment » (semantic). Et oui, ça rend les noms plus longs. Tant mieux. Si tu dois choisir entre un token court et un token qui évite 50 erreurs, choisis le second.
Autre détail qui change tout en équipe : garde un séparateur cohérent (/ ou .), évite les synonymes (« primary » vs « main »), et bannis les noms contextuels flous (« accent », « highlight ») tant qu’ils n’ont pas une définition produit très claire. Les noms flous augmentent le “searching”, donc augmentent l’exposition au bug.
Palette brute vs tokens sémantiques : la séparation qui te sauve (même quand Figma déconne)
Si tout ton produit consomme directement la palette (blue-500, neutral-900…), tu es condamné à chercher dans une forêt. C’est un système “correct” sur le papier, mais en pratique ça pousse les gens à faire du pixel-picking mental : « j’avais utilisé quel gris déjà ? ». Et là, une recherche instable te finit.
Les tokens sémantiques, c’est l’antidote. Le produit ne devrait pas choisir « un bleu ». Il devrait choisir un rôle : text/primary, surface/default, border/subtle, action/primary/background. Ensuite, ces tokens sémantiques pointent vers la palette, et tu ajustes la palette sans casser le produit.
Très concrètement, ça réduit le besoin de “chercher une couleur”. Tu cherches un rôle. Et les rôles sont moins nombreux, plus mémorisables, plus faciles à documenter. C’est aussi ce qui rend les thèmes et les modes bien plus propres.
Le workflow qui marche : la couleur se choisit dans le composant, pas dans un menu de 300 tokens
Un des meilleurs moyens de contourner une recherche capricieuse, c’est de déplacer la décision. Au lieu d’appliquer un token à la main sur chaque calque, tu passes par des composants qui exposent des propriétés et des variantes, et derrière tu lies ça à des tokens sémantiques.
Le bénéfice est immédiat : moins de surface pour se tromper, moins de « je cherche la bonne couleur », et surtout plus de cohérence. Oui, ça demande un peu de design system upfront. Mais c’est exactement le genre d’investissement qui évite la dette “invisible”.
Ta source de vérité ne doit pas être Figma : exporte tes tokens vers le repo (souvent)
Je sais que c’est tentant de dire « Figma est la source de vérité ». Dans la vraie vie, la source de vérité, c’est ce que le produit compile et déploie. Donc : ton repo. Figma doit rester un éditeur et un point de validation, pas l’unique endroit où vit le système.
L’idée n’est pas de lancer un projet “design tokens platform” sur 6 mois. L’idée, c’est d’avoir un format simple, lisible, versionné, avec des PR. Quitte à exporter régulièrement depuis Figma (ou à maintenir côté code et synchroniser). Quand un dev hésite, il ne devrait pas scroller une liste de variables, il devrait pouvoir tomber sur un fichier clair, reviewé, historisé.
Un exemple minimaliste qui suffit déjà à éviter la dérive :
{
"color": {
"palette": {
"blue": { "500": "#2563EB" },
"neutral": { "900": "#0B1220" }
},
"semantic": {
"text": {
"primary": "{color.palette.neutral.900}"
},
"action": {
"primary": {
"background": "{color.palette.blue.500}"
}
}
}
}
}
Et derrière, tu génères des CSS variables ou des tokens TypeScript. Tu peux faire très simple, l’important est la discipline : les changements passent par PR, et on peut discuter « ce token doit exister ? », « ce rôle est bien nommé ? », « ça casse un thème ? ».
Le protocole d’équipe qui évite la loterie (et les couleurs inventées)
Le vrai problème, ce n’est pas qu’une personne perd 30 secondes sur une recherche. Le vrai problème, c’est que chacun invente sa méthode pour contourner. Et c’est comme ça que tu te retrouves avec trois “primary”, deux “brand”, et des gris qui diffèrent de 3 points de luminosité.
Ce qui marche bien, c’est un protocole simple et assumé : on n’ajoute pas une couleur “sur un écran” parce qu’on n’a pas trouvé. Si tu penses qu’il manque un token, tu crées une demande (ou une PR côté repo), et tu attends la validation design system. Ça met un peu de friction, oui. Mais tu mets la friction au bon endroit, pas au moment où quelqu’un est pressé et fait n’importe quoi.
Et je pousse un truc un peu impopulaire : documente 20 tokens sémantiques “vraiment utilisés” plutôt que 300 tokens “théoriquement disponibles”. Une mini doc, même dans le fichier Figma (une page « How we pick colors »), change la donne. Les gens arrêtent de chercher, ils appliquent la convention.
Les limites (et ce que je ferais si Figma ne change rien)
Il faut accepter une vérité pas glamour : tu ne contrôleras pas toujours l’UX de recherche dans Figma. Et même si tu trouves un contournement aujourd’hui, il peut casser demain. Donc je partirais sur une stratégie qui réduit l’impact de toute bizarrerie de search : moins de tokens exposés au quotidien, plus de sémantique, plus de composants, et une synchronisation régulière avec le code.
Ça ne rend pas le bug moins agaçant. Mais ça évite que ton design system repose sur une seule interaction UI fragile. Et ça, c’est ce qu’on veut : un système qui tient quand l’outil tousse.
Conclusion : ton design system doit survivre à l’outil, pas l’inverse
Quand la recherche de color tokens devient imprévisible, c’est très tentant de ne voir qu’un “petit glitch”. En réalité, c’est un test de solidité de ton design system. Si une UX de search te fait perdre confiance dans tes tokens, c’est que tes conventions et ton workflow ne protègent pas assez l’équipe.
La suite logique, si tu veux aller plus loin, c’est d’auditer ta liste actuelle de tokens couleur et de te demander un truc simple : « lesquels sont des rôles produit, lesquels sont juste de la matière première ». Tu fais ce tri une fois, et soudain le bug de recherche devient… beaucoup moins central.
