Paul Souvestre (Founding Front-end Engineer) et Hugo Mingoia (Product Designer) expliquent comment RockFi a équipé son équipe design pour intervenir directement sur la codebase. Claude Code, rules dans l'UI Kit, inventaires de composants, MCP Figma, sub-agents de review : le système, les règles, les résultats après cinq mois et les points de friction restants.
1. Le passage de relais design vers front-end
Le point de départ. Une petite modification visuelle passait par un ticket, une priorisation, un dev qui la prend, une implémentation, une review designer.
Hugo Mingoia juge ce circuit moins efficace que de laisser le designer faire la modification lui-même.
Deuxième cas : les sujets d'interaction et d'animation, difficiles à retranscrire en maquette.
"le code, c'est le meilleur médium pour s'exprimer, pour itérer"
2. Le constat d'opportunité
Mars 2026. Les LLM atteignent un niveau de maturité qui rend dommage de ne pas équiper d'autres profils que les ingénieurs.
Le talk d'Alan diffusé par TPC agit comme déclencheur.
Troisième facteur : l'équipe design de RockFi avait déjà une appétence technique et connaissait Git.
3. Le rituel Kaizen AI Design
Une session hebdomadaire, parfois trente minutes en fin de journée. Le principe : identifier le premier bloqueur, le faire sauter avant la semaine suivante.
Entre deux sessions, l'équipe design expérimente et remonte de nouveaux points de friction. Le Kaizen tourne toujours aujourd'hui.
"Le Kaizen, c'est une sorte de rituel qu'on met en place autour d'une problématique qu'on cherche à régler."
"Si on estime qu'on n'est pas capable de le traiter dans la semaine, on sait que le bloqueur est probablement trop gros et il faut le rediviser en sous-problèmes."
4. Les trois briques du système
Premier bloc : l'outil, le LLM. RockFi a choisi Claude, sans s'y enfermer.
Deuxième bloc : les règles, la façon de coder, les seuils de qualité, de lisibilité et de maintenabilité, et les directives portées par le design system.
Troisième bloc : la qualité livrée aux clients, non négociable. Pas de process spécifique aux designers avec des barrières qui sautent.
Les blocs règles et workflow sont en évolution constante.
5. Le setup des designers
Compte GitHub, clés SSH, variables d'environnement, tokens stockés en externe dans un AWS store.
Objectif : scripter l'onboarding pour qu'un designer entre dans l'écosystème sans s'arracher les cheveux, et puisse livrer du code en production comme un ingénieur.
6. L'UI Kit comme détenteur des règles
L'UI Kit est un repo et un package à part, consommé par les deux applications de RockFi. Il porte déjà un système de versioning et constitue le cœur du design system.
Décision : c'est lui qui détient les conventions Claude, les patterns d'implémentation, les directives d'usage des tokens (success, critical, warning et leurs combinaisons).
Sans document dédié, Claude s'embrouille dès que la collection de tokens s'élargit.
7. Le pattern découvert dans la documentation Next.js
RockFi utilise Next.js et s'appuie beaucoup sur les server components de React.
En cherchant comment garantir que Claude respecte les guidelines Next.js, Paul Souvestre découvre que le package Next embarque un fichier de documentation LLM, et qu'on peut le binder via la feature import files de Claude.
Les paths dynamiques dans les node_modules se résolvent depuis le CLAUDE.md. Un lien suffit pour charger ces fichiers en contexte.
8. Rules plutôt que skills
Un skill est invocable par le modèle ou par l'utilisateur, à discrétion. Une rule est identique, à une différence près : le frontmatter accepte une clé path.
Dès que Claude touche un fichier situé dans ce path, les rules sont chargées automatiquement. Pas de skill manqué.
Le mécanisme fonctionne surtout dans le contexte de l'UI Kit, les rules se comportant différemment à travers des packages consommés par plusieurs applications.
"Dès que Claude va toucher un fichier qui est dans ce path-là, il va forcément loader ses rules dans son contexte."
Deuxième usage : le data access layer, avec ses règles de services, adaptateurs et layers. Une rule ciblée évite d'alourdir le CLAUDE.md global.
"ça permet d'avoir une granularité et un contrôle un peu plus serein et maîtrisé de son contexte"
9. Les inventaires de composants et d'icônes
Problème constaté : quand on demandait une icône ou un composant, Claude les recréait parfois, ou lisait la source du package UI Kit. Beaucoup de read, beaucoup de search, du contexte pollué.
La réponse : des inventaires. Une liste des composants disponibles, une liste des icônes, chargées en contexte par défaut.
Des scripts de synchronisation en CI peuvent maintenir ces inventaires à jour.
10. Un même set de règles, deux comportements
Lancé dans l'UI Kit, l'agent comprend son contexte et se comporte d'une certaine façon. Lancé dans une application consommatrice, il se comporte différemment.
Dans les deux cas, il reste soumis au même set de règles du design system.
Conséquence directe : aucune stack designer friendly à maintenir en parallèle du workflow ingénieur.
11. Le workflow et l'évolution du rôle front-end
Branche, code, test, PR. Au début du Kaizen, chaque PR passait par une review front-end.
Au fil des itérations sur les fichiers markdown de l'UI Kit, le comportement des agents s'est amélioré. Des PR de designers passent aujourd'hui sans un commentaire, et selon le scope, sans review front-end.
Exemple cité : une PR de dix-sept composants, tous validés.
"notre métier d'ingénieur front-end, en tout cas, va évoluer. Notre rôle va être de mettre en place des systèmes et des environnements dans lesquels d'autres personnes comme des designers ou des PM vont pouvoir évoluer et jouer."
12. Les skills, dont deux écrits par l'équipe design
L'équipe design réutilise les skills déjà en place chez les ingénieurs : commit, ouverture de PR, review de code, release d'une version majeure de l'UI Kit, import d'icône.
Deux skills sont nés du Kaizen, côté design.
Local Kit : lance un serveur local et pointe l'application consommatrice vers le build local de l'UI Kit plutôt que vers la version publiée, via un link pnpm ou yarn, ou via un relative path dans le package. Pour tester une modification de composant sans passer par une publication.
Push Quick Fix : né d'une mauvaise gestion de Git. Reprend des modifications faites directement dans main et en fait une PR propre, sans jamais pousser sur main. Il invoque le style de commit maison, qui découpe les changements en commits les plus atomiques possibles.
13. Playwright et les limites du tooling de test
Playwright sert aux tests end to end, mais l'authentification Google de l'application Advisor rend le mock de session difficile.
Les server components ajoutent une contrainte : Playwright n'intercepte que les requêtes du browser, d'où un couplage avec MSW.
Comme Next.js et MSW sont deux process distincts, un reload du serveur Next fait perdre les route handlers, ce qui empêche de tester les error states.
Paul Souvestre qualifie ce point de friction d'ingénierie, hors périmètre Kaizen.
14. Une icône dans un tab
Hugo Mingoia travaille avec Claude Code in app, sans éditeur de code. L'inspecteur permet de pointer un endroit de l'interface et de le mettre en contexte.
Prompt en français, langage naturel, sans jargon technique. L'inventaire d'icônes étant déjà chargé, Claude n'a pas besoin de lire le code source pour trouver la bonne icône.
Hugo Mingoia lit le diff plutôt que le fichier complet.
"en tant que designer, on n'est pas obligé d'avoir un jargon technique"
"je n'ai à peu près jamais besoin d'ouvrir un éditeur de code"
"ça permet de démocratiser plein de choses"
15. Un état manquant via le MCP Figma
Un module de suivi de business plan pour les conseillers indépendants avait un état oublié en conception.
Plutôt qu'un aller-retour design vers dev, Hugo Mingoia designe l'état manquant dans Figma et passe à l'implémentation via le MCP Figma.
Le cas dépasse le changement cosmétique : il y a de la logique à intégrer. L'équipe reste prudente sur l'ampleur des modifications, pour éviter des reviews pénibles.
"on arrive petit à petit à repousser un peu les limites"
Un conflit apparaît en démo : l'implémentation Figma n'était pas conforme aux règles de consistency du design system. Claude signale l'écart et ne matche pas le design.
16. Le skill RockFi Review et les sub-agents
Tous les repos partagent un même skill de review. Il lit un fichier de directives dans le repo, qui liste les sub-agents disponibles selon la phase, review ou planification.
Chaque repo compte environ quinze sub-agents à scope défini : React, Next.js, sécurité, conformité des designs. L'agent sélectionne ceux qui correspondent à la nature du diff.
Limite constatée : la sélection est parfois imprécise, ou les quinze agents se lancent alors que les changements ne le justifient pas. Une piste de quick review avec un subset restreint est à l'étude.
Dans l'UI Kit, des sub-agents spécifiques vérifient qu'aucun token n'est laissé sans documentation.
17. La place de Figma dans le workflow
Sur les projets à process produit classique, Figma reste dans la boucle pour le mock-up fin. Sur les sujets d'animation ou de micro-interaction, le travail se fait directement en code.
Sur les tokens aussi : le retravail des palettes de couleurs pour améliorer les niveaux de contraste s'est révélé plus efficace en code, avec les impacts visibles immédiatement sur toute l'application.
Figma garde sa place pour créer un nouveau composant du design system, dont la portée dépasse une feature.
RockFi s'est réorganisé au sein de l'équipe Product & Tech : l'équipe design prototype parfois la fonctionnalité directement dans le code, en pair avec le front-end engineer qui garantit que la solution scale et reste maintenable.
18. Consommation de tokens et gestion du contexte
La règle de Paul Souvestre : à environ soixante pour cent du contexte consommé, si le travail n'est pas terminé, il demande un end of document pour repartir sur une session neuve mieux informée.
Il cite le plugin Grill Me, dont la version 1.1 remplace Grill with Docs par Wayfinder, et qui resplitte une session de grilling en plusieurs fichiers.
Le coût réel : les règles du design system étant injectées dans le CLAUDE.md, envoyé à chaque message, le contexte de base grossit avec le design system.
Le gain compense : plus de recherche dans les source files, plus de minutes passées à regarder le LLM lire des fichiers.
19. Quand le vrai sujet devient la spécification
Question du live : à partir de quand le problème n'est plus la qualité du code mais celle de la spécification.
Réponse de Paul Souvestre : c'est déjà le cas. Claude signale parfois lui-même les zones d'ombre fonctionnelles d'une demande. RockFi s'est réorganisé pour enrichir les spécifications produites en discovery.
"Donner un input à Claude n'était peut-être pas suffisamment riche à ce moment-là."
Note : RockFi n'a pas encore mis en place d'evals pour vérifier la stabilité des sorties après modification du design system ou des règles.
20. Bilan après cinq mois
Le scope d'intervention des designers s'étend progressivement. De la mise à jour d'un texte ou d'un ajustement visuel jusqu'à des travaux de micro-interaction, d'animation, et le refactoring de composants complets de l'UI Kit.
Des méthodes de co-développement front et design sont apparues : même journée, même fonctionnalité, le front pose l'architecture et le fonctionnel, le design affine l'interaction et le visuel.
"aujourd'hui, on a systématiquement par semaine plusieurs PR par designer qui sont faites"
21. Prochaines étapes
Faciliter davantage l'onboarding des profils non techniques. Étendre le Kaizen aux applications iOS et Android, aujourd'hui hors périmètre.
Explorer la distribution des agents et des skills en plugin, freinée par le fait que les sub-agents sont souvent contextualisés à une application.
Objectif final décrit par Paul Souvestre : une PR poussée sur GitHub, reviewée par un agent Claude, un agent Codex et un agent Kimi, envoyée directement en production si tout va bien, avec un ping vers un ingénieur front-end en cas de doute.
Les designers sont déjà autonomes sur le release des nouvelles versions de l'UI Kit.