Les limites des design tokens trop souvent ignorées

Les design tokens sont devenus la solution miracle pour homogénéiser les interfaces. On les présente comme la panacée : un système centralisé, versionné, multi-plateforme. Sauf que dans la réalité des projets, j'observe régulièrement des équipes qui nagent en eaux troubles après avoir mis en place leur système de tokens. Pourquoi ? Parce qu'on oublie les limites réelles du concept.

Après avoir implémenté des systèmes de design tokens chez plusieurs clients—du scale-up au groupe Fortune 500—j'ai compris que les tokens ne sont pas une solution universelle. Ils résolvent certains problèmes mais en créent d'autres. Il faut le dire clairement : un mauvais système de tokens coûte plus cher qu'aucun système du tout.

Le mythe de la maintenabilité centralisée

Première limite : on croit que centraliser les tokens facilite la maintenance. En théorie, c'est vrai. En pratique, j'ai vu des équipes bloquer pendant des mois sur des changements trivaux à cause d'une mauvaise architecture de tokens.

Imaginez un système tokens pour une grande application web et mobile. Vous décidez que la couleur primaire est définie une seule fois, utilisée partout. Sauf qu'après un an, iOS a besoin d'une teinte légèrement différente pour des raisons d'accessibilité WCAG. Maintenant vous avez un choix : soit vous casser la cohérence supposée du système, soit vous maintenez deux variantes incompatibles. L'approche « single source of truth » devient fragile.

Ce que j'ai appris : les tokens doivent être hiérarchisés par contexte d'usage, pas par intention globale. Une couleur primaire n'existe pas seule. Il faut avoir des tokens pour « bouton primaire sur fond blanc », « bouton primaire sur fond sombre », « bouton primaire désactivé ». Sinon, vous n'économisez que 10% de code mais perdez 90% de flexibilité.

La scalabilité illusoire entre plateformes

Deuxième limite majeure : les design tokens ne scalent pas magiquement entre web, iOS et Android. C'est techniquement possible, mais humainement complexe.

Un token de spacing de 16px sur web ne signifie rien pour un designer iOS travaillant en points. Un radius de border 8px en web n'aura pas le même rendu tactile qu'un coin arrondi iOS. Et les typographies ? Les hiérarchies diffèrent radicalement selon les plateformes à cause des conventions UX respectives.

J'ai accompagné une équipe qui a voulu partager 100% de ses tokens entre web et mobile native. Résultat : aucun respect des conventions UIKit/Material. Les designers iOS rebellés, les utilisateurs de l'app déconcertés. Six mois et 40% de tokens surchargés plus tard, il a fallu accepter que 40-50% des tokens doivent être contextualisés par plateforme.

La vraie approche : utiliser un système de tokens modulaire où le cœur (certaines valeurs métier) est partagé, mais les **implémentations concrètes** restent spécifiques. Un token de couleur primaire peut être partagé. Un token de « spacing du bouton primaire » ne doit pas l'être.

Le coût caché de la gouvernance

Troisième limite : mettre en place un système de tokens efficace demande une gouvernance que 90% des équipes sous-estiment.

Qui valide un nouveau token ? Comment? Selon quels critères? Qui applique les tokens dans le codebase? Comment on versionne? Qu'arrive-t-il quand un designer veut utiliser une couleur non-approuvée? Les design systems sans gouvernance claire deviennent des vortex de discussions infinies ou, pire, des systèmes morts dont personne ne respecte les règles.

J'ai vu une équipe attendre 3 semaines l'approbation d'un simple token de margin pour un cas d'usage spécifique. Trois semaines pour 4px. À ce moment-là, les développeurs commencent à utiliser des valeurs en dur et votre système de tokens n'a plus aucun sens.

Règle empirique : avant de lancer des design tokens, investissez dans la gouvernance. Un processus défini, des rôles clairs, des approbations asynchrones si possible. Et acceptez que 20-30% des cas réels sortent du système—c'est normal, il faut des exceptions documentées.

La fragmentation de la documentation

Quatrième limite enfin trop oubliée : vos tokens ne valent rien sans une documentation vivante.

J'ai hérité d'un projet avec 200+ tokens totalement documentés... en fichier Figma de 2021. Personne ne savait pourquoi le token spacing-md-lg existait. Les devs inventaient leurs propres tokens. Le système explosait.

La documentation doit : préciser l'usage réel de chaque token (où l'utiliser, où ne pas l'utiliser), montrer des exemples visuels concrets, être mis à jour avec les tokens eux-mêmes, rester accessible dans les outils où les gens travaillent (Storybook, Figma, repo, etc.).

Sans cela, vous n'avez que des variables magiques que personne ne comprend vraiment.

Conclusion : les tokens ne résolvent pas tout

Les design tokens sont un outil puissant, mais ce n'est pas une solution qui résout seule les problèmes de cohérence design. Leur vraie valeur émerge quand on accepte leurs limites : hiérarchiser par contexte, contextualiser par plateforme, investir dans la gouvernance, et documenter comme si votre vie en dépendait.

Avant de lancer votre système de tokens, posez-vous la bonne question : quel problème résout-il réellement chez nous? Si c'est juste « centraliser les couleurs », gardez vos tokens simples. Si c'est « assurer la cohérence multi-plateforme avec maintenance rapide », préparez-vous à la complexité. Et surtout, ne croyez pas aux promesses marketing des outils de design tokens. C'est 30% d'outils, 70% de discipline.