Yexit · Design system · 2026

Un design system prêt pour l’IA chez Yexit

Le fichier venait d’un kit. Ses variables de couleur gardaient les noms du kit, une seconde collection de couleurs restait inutilisée, et un même nom, bg-brand-solid, remplissait le bouton principal de gris ardoise en mode clair et de bleu en mode sombre. Les composants n’avaient aucune description.

Un designer contourne le problème en regardant le fichier. Un agent IA choisit un token d’après son nom et sa description. Quand ni l’un ni l’autre n’indique à quoi sert une couleur, le choix se fait au jugé.

Un agent IA a lu les collections de variables via l’API des plugins Figma et a listé tous les tokens avec leur valeur dans chaque mode. Quatre constats ont façonné la suite.

1. F1 Le bleu roi de la marque n’existait que dans la collection inutilisée.
2. F2 Un même nom portait deux couleurs différentes selon le mode : bg-brand-solid.
3. F3 La bordure du kit sur les champs de saisie et les boutons secondaires mesurait 1,6:1 par rapport à la page en mode clair, en dessous du rapport de 3:1 nécessaire aux contrôles.
4. F4 Certaines paires de texte tombaient sous 4,5:1 en mode sombre tel que défini dans le fichier : text-tertiary à 4,3:1, text-placeholder à 2,4:1. Leurs notes l’indiquent.

Le système garde trois couches, chacune avec une seule fonction. Les écrans n’utilisent jamais directement la première couche. Quand un token d’intention existe, il remplace le rôle du kit : le bouton principal est en ink, pas en bg-brand-solid.

C’est avec le renommage que le système est devenu lisible. Chaque nouveau nom énonce une fonction et une limite.

Chacun des 473 tokens de couleur porte une note : à quoi il sert et, quand c’est pertinent, avec quoi l’associer et son rapport de contraste. La note est ce qu’un agent lit quand il choisit une couleur, et ce à quoi un relecteur compare l’écran.

Le brand book est écrit sous forme de règles vérifiables, pas en termes d’ambiance. Chaque règle nomme les tokens qu’elle utilise. La même liste sert à l’agent qui génère un écran et à la personne qui le relit.

1. C1 Un seul accent par écran, et au maximum un mot en accent dans un titre.
2. C2 Cibles tactiles d’au moins 44pt. Rien d’accessible uniquement au survol.
3. C3 Les champs sont des cartes sur surface avec shadow-soft-sm, jamais encadrés.
4. C4 Les teintes servent à marquer des personnes et des catégories, jamais à décorer.
5. C5 Majuscule en début de phrase uniquement. Pas d’emoji dans les textes d’interface.
6. C6 Priorité au téléphone : un écran de 390pt, une colonne, l’action principale dans la zone du pouce.

41 composants sont construits en code à partir de la structure du fichier Figma : 32 issus du kit et 9 patterns Yexit. Les composants Figma n’avaient aucune description, leurs consignes d’usage ont donc été rédigées à partir du fichier. Chaque page de composant liste les variantes Figma que le composant laisse de côté et les bizarreries qu’il garde de la source.

Le système liste ce qu’il ne couvre pas, pour qu’un agent ne comble pas le vide au jugé : boutons de connexion via les réseaux sociaux et badges de magasins d’applications qui exigent des logos tiers, certains types et tailles de champs, les 30 pages d’application et les 16 pages marketing du kit, ses pages d’icônes, quelques effets et la variante sombre du logo.

La référence est le design system par défaut des outils d’IA qui génèrent les écrans et les prototypes de Yexit.

Les noms du kit restent dans le fichier de tokens, marqués à titre de référence, jusqu’à ce que les variables Figma portent les noms d’intention.