Les design tokens dans les constructeurs UI sans code aident les équipes à définir couleurs, typographie, espacements et variantes une fois pour toutes, puis à livrer une interface cohérente sans deviner.
L'incohérence UI ne naît rarement d'un « problème de design ». Elle naît d'un problème de temps. Quelqu'un a besoin d'un bouton maintenant, il en copie un d'une autre page et le retouche jusqu'à ce qu'il paraisse assez proche.
C'est ainsi que de petites différences s'installent : deux bleus presque identiques, un rayon de bord qui passe de 6 à 8, un titre « un peu gras », et des paddings qui dépendent de qui a construit l'écran. Dans les builders sans code, il est encore plus facile d'apporter des modifications ponctuelles parce que les contrôles sont accessibles et les changements semblent anodins.
À mesure que le produit grandit, la dérive s'accélère. Plus de pages signifie plus de motifs répétés. Plus de builders signifie plus de goûts personnels. Plus de coéquipiers signifie plus de « corrections rapides » faites en isolation. Si une personne construit le portail client et qu'une autre construit le panneau admin, vous vous retrouvez avec deux interprétations différentes de la même marque.
L'« eyeballing » apparaît dans le travail quotidien : choisir une couleur jusqu'à ce qu'elle « ait l'air juste », ajuster l'espacement de quelques pixels parce que l'écran semble « trop serré », créer un nouveau style de bouton plutôt que d'en réutiliser un existant, mélanger des tailles de police parce que la valeur par défaut paraît « un peu petite », ou corriger un écran sans vérifier les autres.
Le coût apparaît plus tard. Les revues ralentissent parce que les retours deviennent subjectifs (« fais-le ressembler plus à l'autre page »). Le travail de reprise s'accumule parce qu'il est difficile d'appliquer un changement partout. Le web et le mobile divergent parce que différentes personnes font des choix similaires mais non identiques.
Les design tokens résolvent cela en remplaçant les décisions « assez proches » par des valeurs partagées. L'UI reste cohérente même lorsque l'équipe et l'application grandissent.
Les design tokens sont des décisions nommées concernant votre UI. Plutôt que de dire « utilisez ce bleu » ou « faites des boutons aérés », vous donnez à ces choix des noms clairs que n'importe qui peut réutiliser.
Un token n'est pas la valeur brute. La valeur brute peut être 16px, #2563EB ou 600 (épaisseur de police). Le token est l'étiquette qui explique ce que cette valeur signifie dans votre produit, comme space-4, color-primary ou font-weight-semibold.
Ce changement empêche le problème d'eyeballing. Quand les gens choisissent des valeurs au feeling, on finit par collectionner cinq bleus différents, trois titres légèrement différents, et des espacements qui varient d'un écran à l'autre.
Les tokens fonctionnent mieux comme source unique de vérité. Si chaque écran et composant référence le même ensemble de noms, vous pouvez changer l'apparence de toute l'application en mettant à jour quelques valeurs de tokens, plutôt qu'en chassant des dizaines d'écrans.
Les tokens font aussi le pont entre design et construction. Les designers utilisent les noms de tokens dans les specs, et les builders utilisent les mêmes noms dans un constructeur UI sans code, de sorte que le design survit à la passation.
La plupart des jeux de tokens se répartissent en quelques catégories : rôles de couleur (primary, background, text, danger), typographie (famille, tailles, poids, interlignes), pas d'espacement (padding, margin, gaps), forme et profondeur (rayons, largeurs de bordure, ombres), et parfois motion (durées et easing).
La plupart des équipes n'ont pas besoin d'une énorme bibliothèque de tokens. Elles ont besoin d'un ensemble petit et clair qui couvre la plupart des écrans afin que les gens arrêtent de deviner les valeurs. Cela compte encore plus dans les outils sans code, où les retouches « juste cette fois » se propagent rapidement.
Un ensemble de démarrage pratique couvre cinq groupes :
Une règle garde la librairie rationnelle : si une valeur apparaît à trois endroits ou plus, faites-en un token. Si elle n'apparaît qu'une fois, considérez-la avec suspicion avant qu'elle ne devienne « la nouvelle norme ».
De bons noms de tokens empêchent les disputes avant qu'elles n'apparaissent. Si les gens peuvent deviner un token sans chercher, ils le réutiliseront. S'ils ne le peuvent pas, ils en créeront un nouveau, et votre thème se fragmentera.
Privilégiez des noms qui décrivent le rôle d'une valeur dans l'UI, pas son apparence. text-primary dit à tout le monde quand l'utiliser. blue-600 n'est qu'un pot de peinture.
Un pattern utile comporte deux couches :
color-blue-600, space-16, font-14text-primary, bg-surface, border-mutedDans un constructeur UI sans code, ce sont les tokens sémantiques qui aident les non-designers à choisir la bonne valeur rapidement sans eyeballing.
La plupart des bibliothèques de tokens deviennent désordonnées parce que « nouveau » est la valeur par défaut. Faites de la « réutilisation » la valeur par défaut.
Gardez des règles simples :
Standardisez ensuite le nommage. Choisissez une casse (kebab-case fonctionne bien), utilisez des préfixes stables (text-, bg-, border-, icon-, space-) et gardez des échelles numériques cohérentes (space-4, space-8, space-12, space-16).
Considérez votre UI actuelle comme des preuves. Avant de créer quoi que ce soit de neuf, faites un inventaire rapide : rassemblez des captures d'écran, inspectez les styles et notez chaque couleur, taille de police et espace que vous voyez réellement en production (y compris les valeurs « one-off » qui n'apparaissent que sur un écran).
Ensuite, réduisez les doublons volontairement. Vous trouverez généralement le même gris utilisé en cinq hex légèrement différents, ou des espacements qui sautent entre 14, 15 et 16. Choisissez une valeur à garder, puis mappez les anciennes valeurs dessus. C'est là que les tokens deviennent pratiques : vous arrêtez de débattre du goût et commencez à vous mettre d'accord sur un petit ensemble de choix partagés.
Une première version solide peut être construite en un seul passage :
Pour chaque token, ajoutez une phrase de guidage : où l'utiliser et où ne pas l'utiliser. Exemple : « text-muted est pour le texte d'aide, pas pour les boutons primaires. »
Enfin, décidez de la propriété. Il est utile de nommer une personne (ou un petit groupe) pour approuver les changements, avec une règle simple : « Ajoutez un nouveau token seulement si un existant ne convient pas. » Cela maintient le système stable pendant la croissance du produit.
Commencez par des valeurs par défaut héritées par chaque écran : un style de texte de base (police, taille, interligne, couleur), des styles de titres (H1-H3) et un petit ensemble de règles d'espacement de layout pour que les pages ne semblent pas aléatoires.
Ensuite, mappez les tokens à ce que votre outil appelle paramètres de thème : variables de thème, styles globaux, presets de style ou réglages du design system. L'objectif est que choisir « Primary » ou « Space/16 » sélectionne un token, pas une valeur ponctuelle.
Conservez les styles réutilisables sur des motifs que vous utilisez tous les jours. Un jeu de départ peut inclure un style de carte (fond, bordure, rayon, padding, ombre), un style de champ de formulaire (label, input, texte d'aide), des styles de boutons et des règles de densité/hover pour les lignes de tableau.
Les états sont là où l'incohérence s'insinue, donc définissez-les tôt. Chaque composant interactif doit avoir des valeurs pilotées par des tokens pour hover, focus, disabled et error. Le focus doit utiliser la même couleur et épaisseur d'anneau partout. L'erreur doit utiliser le même duo bordure/texte.
Enfin, prévoyez le partage. Si votre workspace supporte des templates ou des modules réutilisables, mettez les tokens et styles de base dans une « starter app » que les nouveaux projets copient. Ainsi, les nouveaux écrans partent cohérents par défaut.
Les variantes sont l'endroit où un système UI devient soit calme et prévisible, soit un tas de retouches ponctuelles. Les variantes fonctionnent mieux quand elles sont une couche légère qui mappe vers des tokens pour la couleur, la typographie et l'espacement.
Commencez avec un petit ensemble de composants clés que vous utilisez partout : boutons, inputs, badges, alertes et cartes. Donnez à chacun d'eux les mêmes deux dimensions de choix : taille et intention. La taille doit être mécanique (typographie et espacement). L'intention doit être sémantique (couleurs).
Les variantes de taille restent cohérentes quand elles ne changent que quelques propriétés pilotées par des tokens : taille de police, padding et rayon. Les variantes d'intention doivent principalement changer les rôles de couleur (fond, texte, bordure) et ne jamais modifier l'espacement en douce.
Un ensemble couvrant la plupart des produits :
Définissez des règles d'état qui s'appliquent à chaque composant, pas seulement aux boutons. Par exemple : le focus affiche toujours un anneau visible, le hover augmente le contraste de manière cohérente, et disabled utilise la même opacité et bloque les clics.
Ajoutez une nouvelle variante seulement si elle représente un sens récurrent (comme « danger »). Si c'est un besoin d'agencement ponctuel, il s'agit généralement d'un nouveau composant ou d'un wrapper, pas d'une variante que tout le monde utilisera mal plus tard.
Quand un produit est publié sur web et mobile, « même marque » ne signifie pas toujours « mêmes pixels ». L'objectif est que les écrans se sentent comme une même famille, même si les plateformes ont des comportements différents.
Commencez par des tokens partagés qui se traduisent bien : rôles de couleur (background, surface, text, primary, danger), échelle typographique (tailles et poids) et tokens d'espacement (4, 8, 12, 16, 24). Ceux-ci éliminent les approximations et rendent les mises à jour prévisibles.
Puis acceptez les différences réelles. Le mobile nécessite des cibles tactiles plus larges et souvent un peu plus d'espacement. Le web nécessite des tableaux plus denses, des sidebars et des layouts multi-colonnes. Les polices peuvent aussi différer : vous pouvez utiliser une police de marque sur le web mais préférer les polices natives sur iOS/Android pour la lisibilité et la performance.
Une approche pratique est en deux couches : des tokens globaux qui définissent le sens, et des tokens plateforme qui définissent comment ce sens est rendu.
color.text, color.primary, space.md, radius.sm, type.bodytype.family.web, control.height.web, space.tableRowtype.family.mobile, control.height.mobile, space.touchConservez des noms de composants cohérents (Button/Primary) même si les tailles diffèrent. Exigez des vérifications de contraste pour les deux thèmes avant la mise en production.
Les tokens ne fonctionnent que s'ils restent stables et compréhensibles. Sans une gouvernance légère, les équipes ajoutent silencieusement « encore un bleu » ou « encore un padding », et vous revenez à l'eyeballing.
Gardez le processus petit, mais réel :
Maintenez un changelog simple avec dépréciations. Si un ancien token est remplacé, indiquez quoi utiliser à la place, maintenez-le fonctionnel un temps, et marquez-le clairement pour que les nouveaux écrans ne l'adoptent pas.
Le nettoyage fait partie du travail. Une fois par mois, supprimez les tokens et variantes de composants inutilisés (ou au moins signalez-les).
Les non-designers ont besoin d'exemples, pas de théorie.
À faire : utilisez l'échelle d'espacement pour les gaps, et utilisez la variante Primary Button pour l'action principale.
À ne pas faire : définir un padding à « 13px parce que ça a l'air bien », ou créer un nouveau style de bouton pour correspondre à un écran précis.
Lie le travail des tokens aux priorités produit : nouvelles fonctionnalités, refontes de marque et corrections d'accessibilité doivent piloter les mises à jour des tokens, pas les préférences personnelles.
La manière la plus rapide de perdre les bénéfices des tokens est de les traiter comme un dépôt de bordel. Vous commencez avec de bonnes intentions, puis quelques corrections rapides s'accumulent, et l'équipe revient à l'eyeballing.
Un piège courant est de créer trop de tokens trop tôt. Si chaque écran obtient son propre token de couleur ou d'espacement, vous ne construisez pas un système — vous cataloguez des exceptions. N'ajoutez un token que si vous pouvez montrer au moins deux endroits où il sera utilisé.
Un autre problème discret est de laisser des valeurs brutes s'infiltrer dans les composants. Quelqu'un règle le padding d'un bouton à 14px « juste cette fois », ou utilise un hex directement dans une carte. Des semaines plus tard, personne ne se souvient pourquoi c'est différent. Habituez-vous : si c'est visible et réutilisable, ça doit être un token.
Surveillez aussi le mélange des types de tokens. Les tokens de base (comme gray-900 ou space-4) décrivent des valeurs brutes. Les tokens sémantiques (comme text-primary ou surface-muted) décrivent le sens. Les problèmes commencent quand un composant utilise des tokens de base et qu'un autre utilise des tokens sémantiques pour le même rôle.
Les états sont une autre douleur en fin de processus. Les équipes définissent souvent les styles normaux, puis patchent focus, hover, disabled et error juste avant la sortie. C'est comme ça qu'on finit avec des anneaux de focus incohérents et trois rouges « erreur » différents.
Avant de monter en échelle, faites un rapide contrôle anti-piège :
Avant de déployer votre UI sur plus d'écrans, d'équipes ou de produits, vérifiez si votre fondation est suffisamment claire pour être copiée sans deviner.
Une petite équipe construit deux apps en parallèle : un portail client et un panneau admin interne. Différentes personnes touchent différentes pages, et elles construisent rapidement dans un builder sans code. Après quelques semaines, l'UI commence à paraître « décalée », même si personne ne sait nommer le problème.
Avant les tokens, les commentaires de revue s'accumulent : les boutons se ressemblent mais ne sont pas identiques, l'espacement varie d'un écran à l'autre, les champs de formulaire ne correspondent pas, et le portail paraît « convivial » tandis que l'admin paraît « strict » par accident.
Ils règlent ça en introduisant un petit jeu de tokens pratique. Ils définissent des couleurs sémantiques (Primary, Success, Danger, TextMuted), une échelle d'espacement (4, 8, 12, 16, 24) et des variantes de boutons (Primary, Secondary, Ghost) avec un rayon unique et des états cohérents.
Désormais, les contributeurs arrêtent de choisir des hex ou des tailles de police au hasard sur chaque écran. Ils sélectionnent des tokens et des variantes, donc chaque nouvelle page hérite des mêmes décisions.
Le développement s'accélère parce que les choix sont déjà faits. Les revues passent de détails visuels mineurs à de vrais problèmes UX. « Faites ce bouton en variante primaire » remplace « Peux-tu le rendre un peu plus bleu et légèrement plus haut ? »
Puis survient une petite refonte : la couleur primaire change et l'échelle typographique se resserre. Avec des tokens, l'équipe met à jour quelques valeurs et le portail comme le panneau admin se rafraîchissent ensemble.
Choisissez un flux que les gens utilisent souvent et qui présente une dérive évidente, comme l'onboarding, une page de paramètres ou un formulaire simple. Convertir un seul flux est le moyen le plus rapide de prouver l'idée et d'arrêter l'eyeballing.
Commencez par un petit ensemble de tokens sûrs : primary/background/text/border/danger, une courte échelle typographique, une échelle d'espacement, et 2-3 niveaux de radius et d'ombre. Ensuite, créez un mini-ensemble de composants qui n'utilisent que des tokens : un bouton, un input, une carte, une alerte. Ajoutez des variantes seulement quand elles répondent à un vrai besoin.
Faites une courte revue avec l'équipe en utilisant deux captures : un écran « avant » avec des paddings et polices incohérents, et un écran « après » construit à partir de tokens et de variantes. Mettez-vous d'accord sur quelques règles (par exemple « pas de couleurs codées en dur » et « l'espacement doit être un token ») et corrigez d'abord les incohérences majeures.
Pour le déploiement, convertissez d'abord les nouveaux écrans, puis rétroportez les anciens au fur et à mesure que vous les modifiez. Quand le support demande un nouveau filtre admin, reconstruisez ce panneau avec des composants basés sur des tokens et remplacez seulement ce que vous éditez.
Si vous construisez des produits complets (backend, web et mobile) dans AppMaster, il est utile de définir les tokens et styles réutilisables tôt afin que les nouveaux écrans héritent des mêmes décisions. Ainsi, cohérence visuelle et logique applicative progressent ensemble sans nettoyages répétés plus tard.
Pourquoi l'incohérence UI se produit-elle même quand nous avons un designer ?La dérive UI commence souvent par des petites modifications « juste pour cette fois » : copier un composant, ajuster un padding, ou choisir une couleur à l'œil. Avec le temps, ces différences s'accumulent entre les écrans et les membres de l'équipe, et les revues deviennent des débats subjectifs au lieu de vérifications rapides contre des règles partagées.
Qu'est-ce qu'un design token exactement (sans la théorie) ?Les design tokens sont des décisions UI nommées que l'équipe réutilise au lieu de deviner des valeurs brutes. La valeur peut être 16px ou #2563EB, mais le nom du token explique son usage, par exemple space-16 ou color-primary, pour que tout le monde fasse le même choix à chaque fois.
Quelles catégories de tokens devrions-nous définir en priorité pour un produit réel ?Commencez par les rôles de couleur, la typographie, l'espacement et un petit ensemble de rayons (radius) et d'ombres. Cela couvre la plupart des écrans et évite les problèmes d'« eyeballing », tout en gardant l'ensemble de tokens assez petit pour que les gens l'utilisent réellement.
Quand devons-nous ajouter un nouveau token plutôt que conserver un style ponctuel ?Règle pratique : créez un token quand une valeur apparaît dans deux endroits ou plus, ou quand elle prend en charge un état réel comme hover, focus, disabled ou error. Si la valeur est vraiment unique, gardez-la locale au composant pour qu'elle ne devienne pas par accident une norme globale.
Nos noms de tokens doivent-ils être sémantiques (comme text-primary) ou bruts (comme blue-600) ?Les noms sémantiques décrivent l'usage du token, par exemple text-primary ou bg-surface, pour que l'on puisse choisir correctement sans mémoriser une palette. Les noms bruts comme blue-600 conviennent comme tokens de base, mais les utiliser directement dans les composants facilite les mauvaises utilisations des couleurs.
Comment créer des tokens à partir d'une UI existante et incohérente sans tout casser ?Faites un audit de ce que vous publiez : collectez les couleurs, tailles de police et espacements réellement utilisés en production, puis fusionnez volontairement les quasi-dupliqués. Une fois que vous avez un petit ensemble propre, mappez les anciennes valeurs sur le token le plus proche pour que les futurs écrans réutilisent les tokens au lieu de réintroduire des valeurs « presque identiques ».
Comment appliquer les tokens dans un constructeur UI sans code en pratique ?Définissez d'abord des valeurs globales par défaut, puis mappez les tokens aux variables de thème ou styles globaux du builder afin que les composants réfèrent des noms, pas des codes hex ou des pixels. Ensuite, créez un petit jeu de styles réutilisables pour vos composants quotidiens et assurez-vous que leurs états (hover, focus, disabled, error) utilisent aussi des tokens.
Comment créer des variantes de composants (boutons, champs) sans créer le chaos ?Limitez les variantes à la taille et à l'intention. La taille doit modifier uniquement quelques propriétés pilotées par des tokens (taille de police, padding), et l'intention doit surtout échanger des rôles de couleur sémantiques. Ainsi, un bouton « danger » ne change pas subrepticement l'espacement ou la typographie.
Comment aligner les thèmes web et mobile sans imposer des pixels identiques ?Partagez des tokens sémantiques globaux entre plateformes pour garder le même sens, puis autorisez des tokens spécifiques à chaque plateforme pour gérer les différences (tailles cibles tactiles, densité). L'objectif est « même famille, pas mêmes pixels » : web et mobile doivent se sentir cohérents tout en respectant leurs contraintes.
Comment gouverner les tokens pour que le système reste propre dans le temps ?Attribuez une responsabilité claire et utilisez un petit flux de revue pour les changements afin d'éviter que de nouveaux tokens ne soient ajoutés comme des rustines. Publiez les mises à jour selon un rythme régulier et dépréciez les anciens tokens plutôt que de les remplacer silencieusement. Cela permet de garder le système stable à mesure que plus de personnes créent des écrans, notamment dans des projets AppMaster.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
