Themiser un design system

Imaginez : vous êtes ingénieur UX chez Proton.
Vous avez en charge la communication entre l'équipe design et l'équipe de développeurs JS, et vous maintenez et faites évoluer un design system lié à un components system, utilisé sur quatres applications web riches en constante évolution, utilisés par des millions de gens chaque jour à travers le monde.
Vous proposez d'ajouter la fonctionnalité de thèmes visuels au nombre indéfini, parce que ça vous plairait bien en tant qu'utilisateur, que vous voudriez proposer un thème sombre, un thème contrasté plus accessible, et des thèmes farfelus, le Saint Graal étant de permettre à l'utilisateur final d'en créer avec un maximum de dix couleurs.

En tant que développeur, vous vous dites que ça va être chaud, mais qu'importe : vous aimez les challenges.
Bien sûr, c'est une très bonne idée rapidement validée ! Ok, mais comment ? C'est à cette question que je vais répondre : comment nous avons défini un langage commun entre designers et développeurs, une taxonomie éprouvée maintenant utilisée sur toutes les applications web de Proton, et une flexibilité poussée pour parer aux évolutions graphiques et aux demandes spécifiques.