Les agents produisent vite. Je conçois les conditions pour qu'on ait confiance en eux.
Accélérer avec l'IA est facile. Savoir si ce qu'elle a produit est correct, c'est une autre question.
Un agent peut créer un composant en 3 secondes. Il peut aussi créer un composant qui semble juste, compile, et contourne silencieusement le design system.
La confiance ne vient pas des capacités de l'agent. Elle vient du système construit autour de lui. Ce portfolio documente cette architecture: les flows, les règles, les premières pièces déployées.
Étude de casUne partie de ce système gouverne le case study Design OpsGain de temps
Gain de qualité
Confiance IA
Comprendre
Notes, retours qualitatifs, données quantitatives
Structurer
Cadrage, workflows, critères de décision
Explorer
Options, scénarios, alternatives, edge cases
Prototyper
Flows interactifs, états, premières pistes d'implémentation
Évaluer
Critique, scénarios de test, risques, angles morts
Décider
Arbitrages, risques produit, choix de solutions
Documenter
Specs, mémoire, guidelines, notes de design system
Communiquer
Narration, alignement, présentations, échanges d'équipe
Produire sans garde-fous
Composants, tokens, accessibilité : aucune vérification
Produire avec preuves
Composants vérifiés, tokens respectés, conformité déclarée
Trois flows montrent comment j'industrialise le design system avec l'IA : de la conception des mockups HiFi jusqu'à la synchronisation du code, en passant par l'évolution gouvernée du DS dans Figma.
Flux standard
DS complet
Flux étendu
Composant manquant
Hand-off produit
Le designer reçoit le hand-off produit : spec validée, ticket, wireframes: point de départ du mockup HiFi
Scaffolder les composants
Scanne la wireframe et la spec, crée une page Figma (nom du ticket) avec les composants DS candidats posés en vrac
Composer le mockup
Le designer compose les écrans depuis les composants candidats, ajuste états et espacement
Créer le composant LoFi
Le designer crée une frame low-fi (boîte + nom composant) à l'emplacement du composant manquant
Co-rédiger le brief
Scanne le contexte d'usage du composant manquant et produit un premier brief: le designer valide et enrichit
Valider le brief
Brief composant co-rédigé, validé par le designer: prêt à alimenter le flow DS scaling
→ Faire évoluer le DS
Bifurque vers le flow de création / évolution du design system pour résoudre le gap
Auditer la conformité
Vérifie tokens, valeurs hardcodées et composants hors bibliothèque: génère un rapport de conformité DS
Livrer le mockup
Mockup HiFi finalisé, annoté, prêt pour le handoff dev
Générer le rapport
Génère un rapport du flow : ticket, composants utilisés, lane empruntée, gaps détectés, adoption DS: met à jour memory.md
Flux standard
DS complet
Hand-off produit
Le designer reçoit le hand-off produit : spec validée, ticket, wireframes: point de départ du mockup HiFi
Scaffolder les composants
Scanne la wireframe et la spec, crée une page Figma (nom du ticket) avec les composants DS candidats posés en vrac
Composer le mockup
Le designer compose les écrans depuis les composants candidats, ajuste états et espacement
Auditer la conformité
Vérifie tokens, valeurs hardcodées et composants hors bibliothèque: génère un rapport de conformité DS
Livrer le mockup
Mockup HiFi finalisé, annoté, prêt pour le handoff dev
Générer le rapport
Génère un rapport du flow : ticket, composants utilisés, lane empruntée, gaps détectés, adoption DS: met à jour memory.md
Chaque fichier a un rôle précis. Les agents lisent, écrivent et mettent à jour ces fichiers à chaque étape du flow.
/design-system
# AGENTS.md ## Rôle Agent design system. Tu contribues à la maintenance et l'évolution du DS de manière gouvernée. ## Règles absolues - Lire /system/governance.md avant toute action - Consulter /components/component-catalog.md avant de créer - Ne jamais hardcoder de valeurs de tokens - Déclarer tout écart dans un rapport compliance ## Cycle de travail 1. Lire les fichiers de contexte (/system) 2. Analyser la demande et évaluer le risque 3. Exécuter le flow de la lane correspondante 4. Produire les livrables dans /reports 5. Mettre à jour /system/memory.md
# AGENTS.md ## Rôle Agent design system. Tu contribues à la maintenance et l'évolution du DS de manière gouvernée. ## Règles absolues - Lire /system/governance.md avant toute action - Consulter /components/component-catalog.md avant de créer - Ne jamais hardcoder de valeurs de tokens - Déclarer tout écart dans un rapport compliance ## Cycle de travail 1. Lire les fichiers de contexte (/system) 2. Analyser la demande et évaluer le risque 3. Exécuter le flow de la lane correspondante 4. Produire les livrables dans /reports 5. Mettre à jour /system/memory.md
Ce qui s'est passé
Un composant implémenté sans les tokens de min/max-width et min/max-height, pourtant présents dans le Figma.
Pourquoi
Le skill de scan ne ciblait pas les propriétés de contrainte de sizing, elles étaient ignorées silencieusement.
Comment j'ai corrigé
scan-figma.md mis à jour avec des règles explicites pour toutes les propriétés de sizing et contraintes.
Ce qui s'est passé
L'agent a créé un composant Button alors qu'il existait déjà en v2.4 dans le design system.
Pourquoi
Le catalog listait les noms mais pas les variantes ; l'agent ne reconnaissait pas la couverture existante.
Comment j'ai corrigé
component-catalog.md enrichi avec variantes, états et version de chaque composant.
Ce qui s'est passé
Sur une page composite, l'agent a recodé des composants existants au lieu d'utiliser ceux du DS.
Pourquoi
Les layers Figma avaient des noms incohérents ; l'agent ne faisait pas le lien avec les composants du code.
Comment j'ai corrigé
Convention de nommage des layers + règles de reconnaissance strictes ajoutées dans AGENTS.md. Ajout d'un agent de check de nommage.
Ce qui s'est passé
Un rapport compliance.md généré par l'agent déclarait 0 écart. Le composant utilisait un token déprécié (`--color-primary`) au lieu du token actif (`--token-color-primary`): code valide, aucune erreur de build, mais silencieusement en dehors de l'architecture token.
Pourquoi
Le skill de scan ciblait les valeurs hardcodées (hex, px arbitraires). Les alias CSS valides mais dépréciés n'étaient pas dans le périmètre de vérification: l'agent ne détectait aucune violation.
Comment j'ai corrigé
governance.md mis à jour : tout token non préfixé `--token-*` est traité comme une déviation déclarable. Liste des alias dépréciés ajoutée au périmètre du scan.
