Noé est arrivé chez Finary comme alternant. Personne ne lui avait demandé de lancer un design system. Il l'a fait parce que c'était une nécessité évidente. Aujourd'hui, la product manager de Finary builde des écrans Design System Compliance sans avoir jamais touché à Figma. Et Noé passe 80 à 90 % de son temps dans son terminal plutôt que dans Figma. Ce live est le récit de ce cheminement.
1. Repartir de zéro quand rien ne fit avec la prod
Quand Noé arrive chez Finary, il y a une trentaine de personnes, trois designers qui ont aussi des casquettes de product manager. Le produit fonctionne bien, mais la codebase Figma est problématique. Les composants sont empilés, beaucoup de valeurs sont hardcodées, rien ne fit avec la production.
Sa première mission, Finary One, le service pour les clients fortunés, lui confirme le problème. Il fait le job, puis propose de travailler sur un système.
L'audit comme point de départ
Première étape : un audit. Constat de l'existant, compartimenté sur les fondations (tokens, couleurs, fontes), puis sur les composants. La distinction clé à établir : ce qui est feature-specific ne doit pas vivre dans le DS core. Tout ce qui est standardisé et réutilisable sur les différents scopes des designers, si.
Une page blanche assumée
Décision radicale : repartir d'une page blanche. Nouveau fichier Figma, ancien mis en deprecated, itération progressive. Un nouveau repo côté code en parallèle, avec des développeurs qui implémentent les composants au fur et à mesure.
Pourquoi Token Studio n'a pas été retenu
L'outil perdait les tokens natifs de Figma, imposait des licences cumulées pour tous les designers en plus de Figma. La solution retenue : export JSON pour transférer les tokens au développeur chargé de l'intégration. Simple, fonctionnel pour des fondations qui n'ont pas vocation à changer toutes les semaines.
"On n'avait rien qui fittait avec la prod, on avait beaucoup de choses qui étaient hardcodées. Et derrière, les ambitions de la boîte, les ambitions de Mounir, de porter Finary jusqu'à une boîte valorisée à un milliard, c'est compliqué sur des fondations qui ne sont pas stables."
2. Montrer les résultats avant d'avoir le mandat
Personne n'avait demandé à Noé de lancer ce design system. Il prend du temps personnel pour avancer, montre des résultats concrets, obtient ensuite le soutien d'équipes qui défendent le sujet auprès de Mounir et de l'équipe produit.
Mesurer le ROI
Plusieurs niveaux. L'outil d'analytique de Figma permet de traquer l'utilisation des composants et des tokens. Quand ils ont switché d'une lib A à une lib B, ils ont regardé si les composants étaient détachés, s'ils étaient correctement utilisés et dans quels fichiers.
La vélocité développeur comme levier
Quand les composants ne sont pas détachés, tout est traçable. Les développeurs savent exactement de quel composant il s'agit. La vélocité et le end-off sont beaucoup plus fluides.
Le signal le plus concret
Justine, la product manager de Finary, a builté une grosse partie du scope Finary One sans designer. Le résultat était clean à 95 %. Un travail de review minimal. Elle n'avait jamais touché à Figma, ne maîtrisait pas la logique de composants, de variants, de props. Résultat : des composants feature-specific basés sur le DS, qualifiés d'incroyables.
"Si vous montrez le ROI, si vous montrez le retour sur investissement que ça représente, c'est ce qui fait convaincre finalement les équipes."
3. Un design system structuré, c'est aussi un contexte lisible pour un agent
Noé identifie un enjeu de fond. On est arrivé dans une ère où le contexte dans lequel on travaille est très important. Les choses doivent être organisées, structurées de manière à ce que des agents aussi puissent collaborer au quotidien.
La logique est simple : un agent va forcément devoir réutiliser, explorer les fichiers. S'ils sont correctement structurés, ça sera aussi simple pour un humain de comprendre ce que vous faites que pour un agent.
Conséquence pratique : si c'est le chaos à travers les différents outils, l'agent ne peut pas se caler. Un design system clean n'est plus seulement un outil pour les designers : c'est une infrastructure de contexte.
4. Possible, mais avec des garde-fous
Noé peut pusher du code chez Finary. Certains designers l'ont fait également. Mais il pose un point d'attention.
Qualité du Figma = qualité du code
La qualité du code généré est directement liée à la qualité du Figma. Figma, c'est juste une copie visuelle de ce qui se passe en code. La manière dont vous allez gérer vos variants, vos props, si vous le gérez correctement, ça sera simple pour un LLM de développer ça directement.
Les prérequis organisationnels
Un design system sain, une infrastructure solide, des développeurs qui backent la démarche. Quand vous travaillez dans une organisation, vous n'êtes pas tout seul.
La review systématique
Chez Finary, le code de Noé était sans arrêt reviewé par un développeur. Ça ne partait pas directement, ce n'était pas mergé comme ça. Il y avait encore des retours. Il n'a jamais eu un composant mergé en one shot.
La compréhension minimale requise
Claude peut faire 80 % du travail et runner les commandes. Mais il faut comprendre comment fonctionnent les branches, les PR, les commits, les conflits. Une fois qu'on les a appris, la barrière de la technicité tombe parce que c'est Claude Code qui s'en charge.
5. Spec, génération, review, apprentissage
Le workflow part d'un constat : au moment où il l'a construit, le MCP officiel de Figma ne permettait pas encore de crafter directement. Les composants étaient prêts dans Figma mais pas encore tous implémentés en code. Faire la génération côté code produisait beaucoup d'hallucinations. Solution : faire l'exercice dans Figma.
La spec comme source de vérité
La spec contient le template de ce que l'agent doit construire, avec les noms des composants du DS, les node IDs. Pas de guideline de prompt, mais un template de spec : ce qui doit y figurer précisément pour que Claude puisse setup correctement.
La génération
Une fois la knowledge base documentée et accessible à Claude, celui-ci vient chercher les composants le node ID du composant dans Figma pour composer l'écran. Dans sa spec, il spécifie précisément tous les composants dont il a besoin, et flag ceux qui manquent ou qui doivent être feature-specific. Résultat : il ne va pas halluciner, ou en tout cas très peu.
L'extension à l'échelle écran
Le workflow a commencé pour générer des composants. Une fois que ça marchait, Noé l'a testé à l'échelle d'un écran. L'enjeu supplémentaire : le layout. La solution : créer des composants de template dans Figma, comme référence pour l'agent. La knowledge base contient les principaux layouts de Finary, ce qui permet de scaler le modèle.
La review et l'apprentissage
Le flow n'est pas linéaire. Quand Claude génère quelque chose dans Figma, on itère sur le layout. Noé voulait que Claude apprenne de ses erreurs. Une fois qu'il a compris qu'il y a eu des changements et une diff par rapport à ce qu'il a fait, il apprend. La prochaine fois, il ne se trompera pas.
"Claude est très bon dans l'exécution. C'est-à-dire que si votre Claude est régi par des règles, par des conventions et backé avec un design system, il va vous faire des choses qui ressemblent plus ou moins à votre produit. Mais en termes de créativité, ça l'est moins."
6. L'exécution automatisée, pour libérer la création
Noé articule une distinction nette sur le rôle du designer. Aujourd'hui un designer fait deux choses dans son taf. Il fait de la création, il explore de nouvelles choses. Et à côté, il fait beaucoup d'exécutions, voire trop, pour faire en sorte que ça soit Design System Compliance, pour réduire la partie end-off.
L'idée du workflow : toute la partie exécution peut être automatisée par cet agent, et laisser plus de temps à la réflexion au designer, même au product manager.
La limite assumée
Il y a quand même une nécessité sur la création, la réflexion qu'aujourd'hui un agent n'a pas encore. Claude pose les fondations dans Figma. Le designer reprend ensuite dans un canevas ouvert pour itérer.
Son propre usage
Il passe désormais 80 à 90 % de son temps dans son terminal plutôt que dans Figma. Quand Opus 4 est sorti, la qualité produite a nettement progressé. Il est passé de Cursor à un terminal intelligent où il ne touche pratiquement plus au code.
7. Ce flow peut être répliqué pour tout et n'importe quoi
Noé est clair sur le profil requis. Ce workflow n'est pas pour tout le monde au même stade. Il faut que le système, l'infra derrière, soit très solide et la plus saine possible. Dans des contextes où beaucoup de choses sont détachées, où presque pas de variables existent, où la plupart des valeurs sont hardcodées : c'est compliqué de pusher du code en tant que designer.
La logique universelle
Mais la logique sous-jacente est universelle. La spec, c'est la source de vérité. C'est beaucoup plus précis et tangible qu'un prompt basique où l'agent va pouvoir diverger sur beaucoup de choses. Là, vous le faites converger sur quelque chose de très précis avec tous les node IDs des composants.
Les leçons du processus
Au départ, le workflow était très étendu, avec énormément d'étapes. Ce qui a vraiment aidé : le soustraire au maximum. Résultat final : quatre étapes.
"Je pensais que l'innovation était une question de taille. Et en fait, j'ai compris que l'innovation n'était pas une question de taille, c'était une question d'ambition et de vision."