Design System : et si votre Product Designer le mettait à jour lui-même ?

Dans la plupart des équipes produit, il se passe entre 2 et 4 semaines entre le moment où un Product Designer met à jour le design system dans Figma et le moment où ces changements arrivent en production. Et encore, quand ils arrivent. Car certaines modifications ne sont tout simplement jamais scopées, créant un décalage permanent entre ce que le designer conçoit et ce que l'utilisateur voit. Avec l'arrivée de Claude Code et du MCP Figma, ce délai peut maintenant se compter en minutes.

Le problème en un coup d'œil

Le fossé entre Figma et la production

Le problème est connu de tous les CPO et pourtant il persiste. Le Product Designer fait évoluer le design system dans Figma — nouveaux tokens, composants mis à jour, variantes ajoutées — puis crée un ticket pour que l'équipe frontend intègre ces changements. Ce ticket rejoint le backlog, attend sa priorisation, passe par un sprint planning, est développé, reviewé, puis déployé. Dans le meilleur des cas, ça prend 1 à 2 sprints. Dans la réalité, certaines modifications passent à la trappe parce qu'elles ne sont pas jugées prioritaires face aux fonctionnalités business. Le designer finit par être déconnecté de la réalité terrain : il conçoit ses prochaines maquettes avec des composants qui n'existent pas encore en production.

De l'autre côté, les développeurs frontend travaillent avec une version du design system qui a plusieurs semaines de retard sur Figma. Le résultat, c'est une incohérence permanente entre les maquettes et le produit réel, des allers-retours pour réconcilier les deux, et une frustration palpable des deux côtés. Plus le temps passe, plus l'écart se creuse, plus le coût de rattrapage augmente. C'est un cercle vicieux que j'observe dans quasiment toutes les organisations produit que j'accompagne, quelle que soit leur taille ou leur maturité. Et jusqu'ici, personne n'avait vraiment trouvé de solution satisfaisante parce que le coût de synchronisation continue était trop élevé.

Claude Code, le MCP Figma et un nouveau workflow

Depuis quelques mois, des outils comme Claude Code permettent de manipuler du code via des instructions en langage naturel. Ce qui change la donne pour notre sujet, c'est l'arrivée du MCP (Model Context Protocol) Figma : un connecteur qui permet à Claude Code d'accéder directement au contenu d'un fichier Figma — composants, tokens, variantes, styles. En combinant les deux, on obtient un workflow où le Product Designer peut mettre à jour le design system dans le code sans écrire une seule ligne lui-même. Concrètement, voici ce que ça donne :

1. Le Product Designer met à jour un composant ou un token dans Figma, comme il le fait déjà
2. Il ouvre Claude Code Desktop et lui demande, en langage naturel, de mettre à jour le composant correspondant dans le code
3. Claude Code lit les spécifications Figma via le MCP, identifie les différences avec le code existant, et propose les modifications
4. Le designer voit le résultat directement dans l'interface de Claude Code Desktop, qui affiche un aperçu visuel du composant modifié
5. Il valide, et les changements sont prêts à être mergés

L'arrivée de Claude Code en version Desktop est un élément clé de ce workflow. La CLI est un outil que les designers ne connaissent pas et qui peut légitimement faire peur — un terminal noir avec du texte blanc, c'est loin de leur quotidien. L'interface graphique de Claude Code Desktop change complètement la donne : on interagit en langage naturel, on voit les résultats visuellement, on n'a pas besoin de maîtriser git ou le terminal pour obtenir un résultat. Le designer reste dans un univers familier tout en ayant un impact direct sur le code. C'est un point fondamental, car l'adoption par le designer est le facteur clé de succès de ce workflow. Si l'outil lui semble hostile ou trop technique, le bénéfice théorique restera théorique.

Le designer, gardien élargi du design system

Ce nouveau workflow ne transforme pas le Product Designer en développeur frontend. Il étend son périmètre naturel. Si on y réfléchit, le designer est déjà le gardien du design system dans Figma : il en définit les règles, les fait évoluer, s'assure de la cohérence. Lui permettre de pousser ces évolutions directement dans le code, c'est simplement supprimer l'intermédiaire sur une tâche où il est le plus légitime. Le Product Owner n'a plus besoin de créer un ticket, le développeur n'a plus besoin de traduire une maquette en code pour des changements de tokens ou de composants standards. Tout le monde gagne du temps.

Il y a un enjeu plus stratégique derrière. Avec l'accélération des temps de développement permise par les outils IA — comme l'IA agentique qui permet aux développeurs d'aller 5 à 10 fois plus vite — les Product Designers risquent de devenir un goulot d'étranglement dans l'organisation produit s'ils ne trouvent pas eux aussi le moyen d'accélérer. La solution réside justement dans le design system : en le maintenant rigoureusement à jour et en le faisant grandir, ils fournissent la palette nécessaire aux développeurs et aux Product Owners pour concevoir toutes les interfaces simples de manière autonome. Dès que ça devient plus complexe et que le design system existant manque de profondeur, le designer reprend la main et montre alors sa vraie valeur — la conception d'expériences utilisateur que personne d'autre dans l'équipe ne peut imaginer.

Le prérequis non négociable : un design system solide

Aussi prometteur que soit ce workflow, il ne fonctionne qu'avec un design system clairement défini et bien structuré. Sans cette fondation, l'IA va accélérer le chaos au lieu de l'ordre. C'est une constante avec ces outils : l'IA est un accélérateur. Quand les bases sont solides, tout va mieux très vite. Quand elles sont fragiles, tout s'effondre très vite aussi. Un design system "prêt" pour ce type d'usage, c'est au minimum des tokens bien définis (couleurs, typographies, espacements), des composants atomiques clairement documentés dans Figma, et une implémentation frontend qui suit la même structure. Si votre Figma est un ensemble de maquettes sans composants réutilisables, ou si votre code frontend duplique des styles sans logique commune, Claude Code ne pourra pas faire de miracle. Il va générer du code incohérent qui va créer plus de problèmes qu'il n'en résout.

C'est d'ailleurs une raison supplémentaire d'investir sérieusement dans votre design system si ce n'est pas encore fait. Comme je le mentionnais dans l'article sur les métriques d'équipe CPO, la couverture du design system est un indicateur clé de la maturité d'une équipe produit. Avec ce nouveau workflow, ce n'est plus seulement un indicateur de qualité — c'est un prérequis pour débloquer un levier d'accélération majeur. Chaque composant correctement documenté dans votre design system est un composant que votre designer pourra mettre à jour en autonomie, sans mobiliser de développeur. L'investissement se rentabilise très vite.

En résumé

Le décalage entre le design system dans Figma et son implémentation en production est un problème ancien que personne n'avait vraiment résolu. Pas parce que c'est techniquement impossible, mais parce que le coût de synchronisation continue était trop élevé pour être fait en continu. Avec Claude Code et le MCP Figma, ce coût devient quasi nul pour les mises à jour du design system. C'est une opportunité concrète pour les CPO qui veulent à la fois accélérer leur équipe design et améliorer la cohérence de leurs produits. À condition, comme toujours, d'avoir les fondations en place.