Étude de cas
Design System ANS × DSFR
Design system IA
On ne m’a pas demandé de trancher entre deux design systems. C’était pourtant la vraie question.
- Rôle
- UI / Product designer, conseil et système
- Période
- 2025 → 2026
- Contexte
- Agence du Numérique en Santé, via Atos / Eviden
- Outils & stack
- DSFR 1.14.x · Design tokens JSON · Génération assistée par IA · Dépôts open source ansforge
L’ANS entretenait historiquement son propre design system. En parallèle, l’État impose le DSFR à tous les services publics numériques. Deux systèmes, une seule agence. La commande disait « installez le DSFR » ; la vraie question était : que fait-on de l’identité de l’Agence quand l’État impose la sienne ? Il fallait un pont, pas un choix binaire.
Les décisions
L’additif plutôt que le remplacement
Réécrire un design system complet par-dessus le DSFR aurait doublé la maintenance et cassé l’accessibilité native à chaque montée de version. La position tenue : on ne touche pas au cœur DSFR ; on surcharge par des tokens et une feuille dédiée. La conformité reste « gratuite », les mises à jour restent indolores, et on ne thématise un composant que si l’identité de l’ANS l’exige vraiment.
Générer les tokens par IA, valider par jugement
L’IA accélère la partie combinatoire : produire et faire correspondre des dizaines de variantes de tokens JSON compatibles DSFR. Elle ne remplace pas le jugement : chaque lot est vérifié à la main : contraste (seuils RGAA), fidélité à la marque, cohérence entre composants, et l’accessibilité qui ne doit jamais reculer. Un token généré peut être joli et non conforme.
Savoir quand ne pas thématiser
Quand le téléservice de certification est arrivé, l’outil de thématisation existait, et la réponse a été de ne pas s’en servir : DSFR pur, parce qu’un service régalien doit être reconnu comme un site de l’État, pas comme une marque d’agence. Un outil dont on ne sait pas quand se servir n’est qu’un gadget ; la mission a livré le critère.