Note de méthode
Apprendre à une IA un design system qu'elle n'a jamais lu
Un design system, c'est l'ensemble des règles qui font que tous les écrans se ressemblent. Un humain les devine. Une IA, non.
Le problème
En prototypant directement en code avec l'IA, un problème est apparu très vite : elle écrivait du code hors design system. Une table importée de Material ici, un bleu absent de la palette là. Non parce qu'elle concevait mal, mais parce que les règles du système n'étaient écrites nulle part. Elles vivaient dans la tête des designers.
Demandez une table à un assistant : il produit une table générique, correcte en soi, mais pleine de conventions que le système interdit. Mon travail a consisté à écrire ces règles pour qu'il les respecte.
Design system × IA : le problème en une image
Rendre explicites les règles implicites
Démonstration sur « Nimbus », un design system fictif que j'ai créé pour illustrer le principe sans divulguer celui de Thales.
Nimbus · avant / après
Quand l'IA attrape le défaut générique
Demandez une table à un assistant : il produit une table « Material » générique, hors du système. Basculez pour comparer, et survolez (ou touchez) un repère numéroté pour savoir pourquoi.
Import IA · Material · hors système
- Des avatars ronds : le système les veut carrés. Et un bleu qui n'existe pas dans la palette.Ligne 04-AActifUn statut en pastille au lieu du badge maison.
- Ligne 12-CEn attente
- Ligne 07-BErreur
Voir la règle telle que la machine la lit
RULE action-hierarchy
max_primary_per_view: 1 # une seule action attendue
secondary: outline # jamais seule, accompagne un primary
tertiary: text-only # faible emphase, non bloquante
enforce: on_generate, on_review
RULE no-foreign-table
forbid:
- elevation > 0 # Nimbus est plat : bordures uniquement
- color: outside(tokens) # pas de bleu Material hors palette
- avatar.shape: circle # avatars carrés à coins arrondis
- pagination: default # utiliser le composant Nimbus
- status: chip # statut = badge point-coloré + libellé
on_violation: block, explainLe pipeline
Écrire les règles ne suffit pas : il faut d'abord décider lesquelles font autorité. La documentation existante suffisait à des designers humains, mais laissait trop de choses implicites pour un agent. Chaque zone de silence devait être tranchée avant d'être encodée.
Pipeline design system → skills IA
Cliquez une étape pour voir sa décision clé.
Pipeline en cinq étapes, dans l'ordre : Documentation existante, Gouvernance, Traduction en skills, Prototypes codés, Démonstrations clients. Un arc de retour réinjecte ensuite les apprentissages des démonstrations clients vers la gouvernance et la traduction en skills, dans une boucle d'amélioration continue.
Amélioration itérative : apprentissages réinjectés vers la Gouvernance et la Traduction en skills.
Système
Documentation existante
Le point de départ : une documentation qui suffisait aux designers humains, mais laissait trop de règles implicites pour un agent IA.
La structure du pipeline est réelle ; les règles et prompts précis des skills restent internes à Thales.
Ce que ça a produit
Les skills, des fichiers de règles que l'IA lit avant de générer du code, font gagner environ quatre heures par cycle d'idéation, mesurées sur quatre projets. Une première équipe les a adoptés, et l'extension à d'autres est prévue. Un développeur a rejoint la version destinée aux devs ; nous la maintenons à deux.
La limite
On ne peut encoder que les règles qui existent déjà. Partout où le design system était silencieux, l'IA continuait de produire des choix par défaut qu'il fallait arbitrer à la main.
Le chantier suivant n'est donc pas d'écrire plus de skills. C'est de combler les angles morts du système lui-même, et le passage par l'IA a eu ce mérite inattendu : il a rendu visible tout ce que le design system ne disait pas.