Design system, i18n et la recette visuelle

Les tokens : une seule source de vérité visuelle

Le principe appliqué sur cette plateforme (et sa refonte lumineuse en une heure le prouve) : aucune couleur, espacement ou rayon en dur dans les composants — tout vit en CSS custom properties (--c-primary, --sp-4, --radius-md). Un composant consomme des tokens ; un thème est un jeu de valeurs. Changer d'identité visuelle = changer un fichier ; le mode sombre = un data-theme qui rebinde les mêmes noms.

Au-dessus des tokens, la hiérarchie atomic design déjà croisée : atoms → molecules → organisms, avec la règle d'accès (stores/API réservés aux étages hauts). Le projet copilot utilise NuxtUI + Tailwind 4 — mêmes principes, bibliothèque industrialisée : on configure le thème, on compose les composants fournis, on ne réinvente pas un datepicker.

i18n : la discipline du jour 1

La leçon apprise sur les deux projets : l'internationalisation ne se rattrape pas, elle se commence. Les règles :

• zéro chaîne UI en dur : tout passe par t('quiz.check') — et cette plateforme a un test qui échoue si les locales fr/en divergent (la symétrie des clés, vérifiée en CI) ;
• la locale du contenu est indépendante de la locale de l'UI (un cours de khmer dans une UI française) — deux axes, pas un ;
• les pluriels, dates et nombres passent par les API i18n ({n} résultat(s) géré par la lib, pas par des if).

La recette visuelle : l'œil outillé

Le maillon final observé dans l'équipe copilot : le design se recette comme le code. Des tickets de retours visuels précis (« palette fuchsia non conforme », « gap + position toggle »), des specs avec maquettes opposables, et des suites E2E qui verrouillent les parcours — pendant que la revue visuelle humaine se concentre sur ce que les tests ne voient pas : la cohérence, le rythme, le ressenti. Le design system réduit drastiquement la surface de cette recette : un composant corrigé est corrigé partout.