Développeur front-end design system : tokens, composants et publication

Un développeur design system travaille sur des composants partagés : bouton, champ de formulaire, modale, tableau, utilisés par plusieurs équipes. Il traduit les décisions des designers en design tokens (couleurs, espacements, typographie), les exporte vers le CSS et parfois vers iOS et Android, documente chaque composant dans Storybook et publie des versions sur un registre npm. Les offres le demandent surtout en React et TypeScript, parfois en Web Components pour servir plusieurs frameworks avec le même code. Les questions d'entretien d'un développeur design system portent donc sur l'API des composants autant que sur leur rendu.

Le poste a une particularité : ses utilisateurs sont des développeurs qu'il ne voit pas. Renommer une prop casse des applications ailleurs dans l'entreprise, et un focus mal géré dans une modale rend non conformes tous les écrans qui l'utilisent. Les bons profils parlent de versionnage sémantique, de dépréciations annoncées, de tests visuels et de navigation au clavier. En France, la référence d'accessibilité reste le RGAA 4.1.2, et sa version 5 est annoncée pour fin 2026.

Demandez à voir l'API d'un composant que la personne a publié, puis ce qu'elle a fait la dernière fois qu'il a fallu en changer le comportement. Le PDF propose 30 questions sur six axes et un cas de 20 minutes sur un combobox.

Les outils d'un design system côté code

Design tokens et format DTCG

Les tokens donnent un nom aux décisions visuelles : couleur de fond principale, rayon des boutons, espacement de base. On distingue en général les valeurs brutes (la palette), les tokens sémantiques (couleur d'erreur, fond de surface) et parfois des tokens propres à un composant. Le format du Design Tokens Community Group du W3C, publié en version stable 2025.10, normalise le fichier JSON avec $value, $type et des alias entre accolades.

Style Dictionary et Tokens Studio

Style Dictionary transforme les tokens en variables CSS, en constantes TypeScript ou en ressources iOS et Android. Côté design, Tokens Studio ou les variables Figma tiennent les mêmes valeurs, synchronisées avec le dépôt Git. Demandez qui fait foi quand Figma et le code ne disent plus la même chose.

Storybook

L'atelier et la documentation des composants. Chaque story montre un état (désactivé, en erreur, texte très long), des pages MDX expliquent l'usage. Storybook 10, sorti en octobre 2025, ne livre plus que des modules ES. L'addon Vitest exécute les stories comme des tests d'interaction, l'addon Accessibility contrôle chaque story.

API de composants

La partie que les autres équipes manipulent : props, événements, children ou slots, composants composés (Tabs, Tabs.List, Tabs.Panel), transmission des attributs et de la ref. Une API trop fermée pousse les équipes à recopier le composant ; trop ouverte, elle donne un usage différent dans chaque application.

Accessibilité : ARIA, APG et RGAA

Les composants portent une grande partie de l'accessibilité des produits : rôles et attributs ARIA, navigation au clavier, gestion du focus, contrastes. Le guide ARIA Authoring Practices (APG) du W3C décrit le comportement attendu de chaque motif, des onglets au combobox. axe-core trouve une partie des erreurs automatiquement, le reste se vérifie au clavier et au lecteur d'écran.

Web Components

Des composants natifs du navigateur (Custom Elements, Shadow DOM), écrits directement ou avec Lit ou Stencil, utilisables en React, Angular, Vue ou HTML simple. Ils servent quand plusieurs frameworks cohabitent dans l'entreprise. Les points délicats sont le style à travers le Shadow DOM, l'intégration aux formulaires (ElementInternals) et le rendu serveur.

Publication et versionnage

La bibliothèque se publie sur un registre npm, souvent privé, depuis un monorepo (pnpm workspaces, Turborepo ou Nx). Changesets ou semantic-release calculent la version selon le versionnage sémantique et rédigent le changelog. Le build produit des modules ES, les types TypeScript et un CSS importable, et le tree-shaking doit fonctionner chez les applications.

Tests visuels et tests de composants

Les tests de régression visuelle (Chromatic, captures Playwright) comparent chaque story à une image de référence. Les tests de composants vérifient le comportement : clavier, focus, événements. Sans eux, la modification d'un token peut décaler cinquante écrans sans que la revue de code le montre.

Le poste existe dès que plusieurs applications ou plusieurs équipes doivent partager la même interface. Le développeur écrit les composants et répond aux questions des équipes qui les utilisent, en lien étroit avec les designers du système. Selon l'entreprise, la bibliothèque est en React, en Angular, en Vue ou en Web Components, et parfois déclinée en tokens pour les applications mobiles. Les intitulés varient : développeur design system, design system engineer, développeur front-end React design system. Précisez dans l'offre le framework, l'outil de documentation et les engagements d'accessibilité, car ils changent beaucoup le profil recherché.

Ce que vous devez vérifier chez un développeur design system

• Architecture des design tokens et des thèmes
• Conception d'API de composants
• Accessibilité des composants (ARIA, clavier, focus)
• Documentation et tests dans Storybook
• Versionnage sémantique et publication npm
• CSS d'une bibliothèque partagée

Cinq questions sur les composants, les tokens et les versions

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · senior

   Le produit doit passer en mode sombre et accueillir une deuxième marque. Comment organisez-vous les tokens pour ne pas dupliquer les composants ?

   Une bonne réponseTrois niveaux : des valeurs brutes (la palette de chaque marque), des tokens sémantiques nommés d'après leur usage (fond de surface, texte secondaire, bordure d'erreur) et, si besoin, des tokens propres à un composant. Les composants ne lisent que les tokens sémantiques. Chaque thème, clair, sombre ou par marque, fait pointer ces tokens vers d'autres valeurs brutes, exportées en variables CSS sous un sélecteur comme [data-theme] ou une media query prefers-color-scheme. La personne vérifie les contrastes de chaque combinaison et ne nomme jamais un token sémantique d'après sa couleur.

   Signal d'alerteDes tokens nommés blue-500 utilisés directement dans les composants, ou un fichier CSS recopié à la main pour chaque thème.

2. Question 2 · confirmé à senior

   Vous concevez un composant Select utilisé par vingt équipes. Comment définissez-vous son API ?

   Une bonne réponseElle part des usages relevés dans les applications. Le composant fonctionne en mode contrôlé (value et onChange) et non contrôlé (defaultValue), suit les noms d'attributs du DOM, transmet les attributs restants et la ref à l'élément natif, et reçoit ses options par composition ou par children plutôt qu'avec une prop par cas particulier. Les états désactivé, en erreur et en chargement sont prévus, comme le lien avec un label et un message d'erreur. Tout ce qui est exposé devra être maintenu, donc l'API reste petite au départ.

   Signal d'alerteUne prop par demande d'équipe (showIcon, iconLeft, iconRightBlue…), ou un composant qui ne transmet ni la ref ni les attributs aria.

3. Question 3 · confirmé

   Comment rendez-vous une modale accessible ?

   Une bonne réponseL'élément dialog natif ouvert avec showModal(), ou role=dialog avec aria-modal et un titre relié par aria-labelledby. À l'ouverture, le focus entre dans la modale et Tab ne peut pas en sortir ; Échap la ferme ; à la fermeture, le focus revient sur le bouton qui l'a ouverte. Le reste de la page devient inerte, avec l'attribut inert ou le comportement natif de showModal(). La personne teste au clavier et avec un lecteur d'écran (NVDA, VoiceOver), en plus d'axe.

   Signal d'alerteUne div posée par-dessus la page et fermée seulement à la souris, ou « axe ne remonte aucune erreur, donc c'est accessible ».

4. Question 4 · confirmé

   Vous devez renommer une prop utilisée dans quarante applications. Comment publiez-vous ce changement ?

   Une bonne réponseRenommer une prop casse les appels existants, c'est donc une version majeure en versionnage sémantique. Avant, une version mineure accepte l'ancien et le nouveau nom, affiche un avertissement de dépréciation en développement et l'annonce dans le changelog. Un codemod (jscodeshift, ts-morph) peut faire la migration à la place des équipes. La majeure regroupe plusieurs ruptures, et l'ancienne majeure reçoit les correctifs pendant une durée annoncée. La personne sait aussi qu'un changement de valeur de token ou de structure HTML peut casser une application sans que l'API change.

   Signal d'alerteUne version corrective parce que « c'est juste un nom », ou un renommage sans période de dépréciation.

5. Question 5 · senior

   Une équipe n'arrive pas à surcharger les styles du bouton, une autre voit le bouton changer d'aspect dans son application. Comment construisez-vous le CSS de la bibliothèque ?

   Une bonne réponseUne spécificité basse et prévisible : des classes simples et préfixées, :where() pour la faire descendre encore, et des cascade layers (@layer) pour que les styles de l'application passent après ceux de la bibliothèque. La personnalisation passe par des variables CSS documentées, pas par des sélecteurs internes. Aucun style global sur les balises (button, h1) qui déborderait dans l'application. Selon la stack, CSS Modules, Vanilla Extract ou Tailwind, avec un CSS livré en un fichier ou importable par composant. En Web Components, le Shadow DOM isole les styles et les zones personnalisables s'exposent avec ::part et des variables CSS.

   Signal d'alerteDes !important partout, ou une remise à zéro globale des styles livrée avec la bibliothèque.

Questions fréquentes sur le poste de développeur design system

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.