Timothée Jezek

Spécialité

Un design system n’est pas une bibliothèque. C’est une doctrine.

Ces quatre dernières années, j’ai traversé les trois situations possibles face à un design system : en faire grandir un depuis un UI Kit, thématiser celui de l’État, et décider de ne pas s’en servir. C’est la troisième qui m’a le plus appris.

01

De l’enfer du UI Kit au système

Chaque marque peut changer son fond et sa couleur, glassmorphisme compris : le parti pris fondateur du produit. En UI Kit, chaque combinaison était un cas particulier, des états multipliés et maintenus à la main, pendant que le produit passait d’un client à des dizaines. J’ai transformé ce UI Kit en design system où la personnalisation est une variable : contraste garanti par construction, variantes et états systématisés, composants documentés. L’ambition d’origine a survécu à l’échelle. Ce système a aussi été mon sujet de mémoire de master, soutenu avec les félicitations du jury.

Un bon système ne tue pas l’ambition d’origine : il la rend maintenable.

Lire l’étude de cas : EcoDesignCloud

02

Thématiser celui de l’État

Le DSFR est obligatoire pour les services publics ; l’identité de l’Agence existe aussi. La réponse : une couche de thématisation additive : le cœur DSFR n’est jamais modifié, l’identité se superpose par des tokens. Les tokens JSON sont générés par IA pour la partie combinatoire, puis vérifiés à la main : contraste RGAA, fidélité à la marque, non-régression d’accessibilité. Le tout est open source.

L’additif plutôt que le remplacement : on ne paie ni deux maintenances, ni la perte de l’accessibilité native.

Lire l’étude de cas : Design System ANS × DSFR

03

Savoir ne pas s’en servir

L’outil de thématisation existait, et la décision a été de ne pas s’en servir. Un téléservice régalien doit être reconnu comme un site de l’État, pas comme une marque d’agence : DSFR pur, assumé. C’est elle qui teste si le système a une doctrine ou n’est qu’une bibliothèque.

Un outil dont on ne sait pas quand se servir n’est qu’un gadget. Le critère d’usage fait partie du livrable.

Lire l’étude de cas : Ma Certif’ Pro Santé
Fondations EcoDesignCloud : des tokens sémantiques nommés par usage (intent-success-background → green-200), pas par couleur. La doctrine se lit dans le nommage.

Ce que je défends en réunion

  • Pas de design system par principe.

    Un système, c’est de la maintenance à vie. Sur Gatto, mon propre produit, je n’en ai pas fait : un UI Kit suffit, on est en mode build. Un DS aurait été une perte de temps.

  • L’additif plutôt que le remplacement.

    Sur l’ANS, le cœur du DSFR n’a jamais été modifié : l’identité vit dans une extension par-dessus. Les montées de version de l’État passent sans rien casser.

  • La sémantique avant le pattern.

    Un token se nomme par son usage : intent-success-background, pas green-200. Et un état vide n’est pas une erreur : sur Ma Certif’ Pro Santé, un référentiel pas encore publié s’affiche sans alerte rouge.

  • Un écart se défend sur l’accessibilité et le sens, jamais sur le goût.

    Les tokens générés par IA passaient les seuils de contraste RGAA avant d’entrer dans le système.

  • Livrer le critère d’usage avec l’artefact.

    La mission DSFR-ANS n’a pas livré qu’une capacité de thématisation : elle a livré la règle de quand ne pas s’en servir. Ma Certif’ Pro Santé l’a appliquée, DSFR pur.

L’accessibilité n’arrive pas en audit final, elle est dans les fondations : les seuils de contraste vivent dans les tokens. Je suis certifié Opquast et formé au RGAA, et l’IA a sa place dans ma pratique : générer le combinatoire, jamais remplacer le jugement.

Vous construisez ou adoptez un système ? Écrivez-moi.