Le workflow IA pour design systems qui m’a enfin évité les résultats bâclés

J’ai passé une bonne partie de mon samedi à me disputer avec Claude à propos d’un bouton.

Pas la logique. Le bouton. Le principal call-to-action sur un écran de paywall pour une application financière que je prototypais. J’avais branché le MCP Figma, orienté Claude vers mon système de design, tapé « construis-moi un paywall en utilisant nos composants » — et ce qu’il a produit ressemblait à tous les autres écrans générés par IA que j’ai jamais vus. Des coins arrondis qui semblaient arbitraires. Un dégradé qui n’existait nulle part dans mon système. Un espacement presque correct, comme un groupe de reprises est presque l’original. Assez proche pour être reconnaissable. Assez loin pour faire mal.

J’ai fermé le fichier. Fait du café. Je me suis assis et j’ai vraiment lu ce que j’étais en train de faire.

Voilà ce que j’ai compris : je traitais Claude comme une baguette magique. L’agiter sur un fichier Figma, attendre un rendu pixel-perfect. Et il faisait tranquillement exactement ce que fait n’importe quel modèle quand on lui donne une pile de données non étiquetées — il faisait une moyenne. Il faisait la moyenne de mes tokens avec tous les autres systèmes de design qu’il avait jamais vus. Il faisait la moyenne de mes boutons avec tous les boutons d’internet. Le résultat, c’était un fantôme de mon système de design déguisé en costume convaincant.

La solution n’était pas un meilleur prompt. La solution, c’était des données d’entraînement structurées — des tokens avec descriptions, des composants regroupés avec des règles d’utilisation, des exemples d’écrans précis — puis itérer localement dans Claude Code avant d’envoyer un seul frame dans Figma. Une fois que j’ai fait ça, mon UI de premier jet est passée de « bon, je vais tout refaire » à « en fait, j’ai juste deux styles de texte à ajuster ».

C’est ce workflow que je veux vous présenter. Rien de révolutionnaire. Juste une structure patiente et ennuyeuse qui fait que Claude se comporte comme un junior designer qui a vraiment lu votre système — pas comme un touriste ivre qui a vaguement entendu parler de design.

Pourquoi l’IA Figma “vanilla” et les workflows “Just Prompt It” s’effondrent

Permettez-moi de décrire précisément le mode d’échec, car la plupart des articles passent cette étape sous silence.

Vous installez le serveur MCP de Figma. Vous connectez Claude à votre fichier Figma. Vous écrivez “génère un écran de paramètres en utilisant notre design system.” Claude se lance, lit quelques métadonnées, produit quelque chose. Vous l’ouvrez. C’est faux, mais d’une manière difficile à nommer — la hiérarchie semble bancale, le padding est le mauvais 16 (celui qui existe dans tous les systèmes, pas celui que vous utilisez), l’ombre de la carte est proche mais pas exactement la vôtre. Techniquement, vos composants sont utilisés. Mais il ne comprend tout simplement pas quand les utiliser.

Cela arrive pour une raison évidente une fois qu’on la nomme : un fichier de design system n’est pas une donnée d’entraînement. Un fichier de design system est un entrepôt. Les tokens sont dans une collection. Les composants dans une autre. Les règles d’usage vivent dans un doc Notion que personne ne lit. La colle — la vraie connaissance du “quand utiliser la surface élevée ou la surélevée” — n’existe que dans la tête de votre designer senior.

Quand Claude lit cet entrepôt, il voit des noms et des valeurs. Il ne voit pas l’intention. Et sans intention, chaque décision ambiguë est résolue par une moyenne statistique de tout ce qu’il a déjà vu sur Internet. C’est ainsi que vous vous retrouvez avec un paywall qui ressemble vaguement à Stripe, vaguement à Linear, et pas du tout à votre application.

La position de Figma sur ce point est en fait assez claire — ils ont publié un guide pour créer des skills personnalisées précisément pour cette raison. Le serveur MCP est livré avec des skills de base comme figma-use et figma-generate-library, mais ce ne sont que des échafaudages. Ils s’attendent à ce que vous superposiez votre propre connaissance métier par-dessus. La plupart des gens ne le font pas. Ensuite, ils blâment le modèle.

Moi aussi, j’ai blâmé le modèle. Puis j’ai arrêté.

Il y a un troisième problème que la plupart des tutoriels éludent, et nous y reviendrons plus loin dans la section implémentation — mais il concerne ce qui se passe lorsqu’un modèle voit trois variantes d’un composant “carte” et doit en choisir une. Je vous montrerai à quoi cela ressemble et comment le corriger. Mais d’abord, il nous faut des tokens qui parlent.

Des tokens qui parlent : le template qui a tout changé

Voici le plus grand déclic de tout ce workflow, et c’est d’une simplicité embarrassante.

Claude est un modèle de langage. Vos tokens sont principalement des chiffres et des codes hexadécimaux. Lorsque vous donnez à un modèle de langage une entrée non linguistique, il doit en déduire le sens. Lorsque vous lui donnez une entrée linguistique, il suit les instructions. La solution, c’est donc de faire en sorte que vos tokens parlent anglais.

J’utilise un template à quatre colonnes pour chaque token. Nom. Valeur en mode clair. Valeur en mode sombre. Une phrase qui décrit quand l’utiliser.

Voici un extrait de mes vrais tokens de surface :

| Token                  | Light    | Dark     | When to use                                      |
|------------------------|----------|----------|--------------------------------------------------|
| surface-base           | #FFFFFF  | #0B0B0F  | The page background. Nothing sits behind this.   |
| surface-raised         | #F7F7F9  | #15151B  | Cards, list rows, anything one layer above base. |
| surface-elevated       | #FFFFFF  | #1D1D25  | Modals, popovers, menus — floating UI only.      |
| surface-sunken         | #F0F0F3  | #08080C  | Input fields, inset wells, read-only regions.    |
| surface-brand-subtle   | #EEF2FF  | #1A1D3A  | Brand-tinted backgrounds for promoted content.   |

Lisez bien la colonne « When to use ». C’est la partie qui intéresse Claude. C’est ce qui transforme un token d’une simple valeur en une véritable instruction.

Faites-le pour chaque catégorie de tokens : surface, contenu (texte), bordure, action, statut, élévation, rayon, espacement, mouvement. Oui, même l’espacement. space-2: 8px — tight rhythm inside dense components like form field groups est mille fois plus utile que space-2: 8px.

C’est exactement la direction prise par la communauté design systems en 2026 : des tokens sémantiques avec l’intention intégrée dans le nom, associés à une documentation qui décrit le but, pas l’apparence. La nuance que j’apporte, c’est que la documentation doit vivre avec le token, dans le format que Claude ingère, et non dans un wiki séparé.

Enregistrez ce tableau comme fichier markdown. design-tokens.md. Gardez-le dans votre repo de projet, juste à côté de votre code. Ce fichier est désormais votre vrai design system — les variables Figma ne sont que le rendu final.

Petite parenthèse : j’ai résisté à cette idée pendant des semaines parce que je pensais que Claude pouvait simplement lire les descriptions des variables Figma. Techniquement, il le peut. Mais la plupart des descriptions écrites dans Figma sont soit vides, soit rédigées pour les designers (« couleur principale de la marque ») au lieu d’un modèle qui doit choisir entre cinq bleus à 2h du matin un samedi. Réécrivez-les pour le modèle. Vos designers pourront toujours les lire. Personne n’y perd.

Voilà la moitié du chemin. L’autre moitié concerne les composants — et c’est là que le workflow échoue généralement si vous ne les regroupez pas correctement.

Regrouper les composants pour éviter que Claude ne panique

Voici une leçon que j’ai apprise à mes dépens. Si vous donnez à Claude un design system avec 140 composants dans une liste plate et que vous lui demandez de construire un écran, il agit comme un entrepreneur à qui l’on remet un magasin de bricolage en lui disant de construire une cuisine. Techniquement, il a tout ce dont il a besoin. En pratique, il va utiliser le mauvais marteau.

La solution : regroupez vos composants en catégories sémantiques, avec une compétence dédiée pour chaque groupe (ou, si vous voulez simplifier, une seule compétence qui connaît tous les groupes). Les trois regroupements qui couvrent 90 % des interfaces produit :

1. Éléments de formulaire. Champs de saisie, zones de texte, menus déroulants, cases à cocher, boutons radio, interrupteurs, sélecteurs de date, zones de dépôt de fichiers, ligne de formulaire, message d’erreur, texte d’aide. Toutes les variantes. Tous les états — par défaut, focus, erreur, désactivé, chargement.

2. Navigation. Barres supérieures, navigation latérale, barres d’onglets, fil d’Ariane, pagination, liens de retour, contrôles segmentés, stepper. Les états sont aussi importants ici — actif, survol, désactivé, réduit.

3. Affichage des données. Tableaux, cartes, éléments de liste, tuiles de statistiques, badges, tags, avatars, états vides, skeletons de chargement, graphiques, pieds de page de pagination. C’est ici que la plupart des écrans générés par l’IA s’effondrent, car le modèle propose par défaut des tableaux là où une grille de cartes serait appropriée, ou des tuiles de stats là où une liste conviendrait mieux.

Pour chaque composant dans chaque groupe, documentez trois éléments pour Claude :

• Variantes — toutes, avec les noms de clés de variante exactement comme ils apparaissent dans le panneau de propriétés Figma
• Props — tous les booléens et enums exposés par le composant
• Règle d’utilisation — une phrase : « Utilisez la variante compacte pour les tableaux denses avec plus de 8 colonnes. Variante par défaut pour tout le reste. »

C’est cette troisième ligne qui empêche Claude de choisir une variante au hasard parce que le nom lui semblait sympa.

C’est le schéma que j’ai mis au point dans mon précédent article sur le workflow Figma MCP, et c’est ce schéma qui a permis au workflow actuel de produire enfin des premiers jets de design exploitables. Si vous avez déjà construit des design systems, vous savez que le plus difficile n’est pas de définir les composants — c’est de documenter quand utiliser lequel. Cette documentation a toujours été précieuse pour les humains. Il s’avère qu’elle l’est encore plus pour les modèles.

Astuce de pro : si vous avez plus d’un designer dans votre équipe, réunissez-les et débattez à voix haute des règles d’utilisation avant de les rédiger. Le débat est la spécification. Les désaccords qui émergent sont précisément les cas limites que Claude risquerait de mal gérer. Rédigez la réponse convenue comme règle.

On pourrait croire qu’on est prêt à générer maintenant. Ce n’est pas le cas. Il reste une étape, et c’est celle que la plupart des gens sautent complètement.

Arrêtez de dire « Construis-moi une modal » — Montrez à Claude exactement ce que vous voulez dire

La plus grande erreur que je vois en ingénierie de prompt dans le design avec l’IA, c’est la vague qui se fait passer pour de la concision. « Construis-moi une modal. » « Conçois un dashboard. » « Fais un écran de paramètres. » Ces requêtes semblent précises. Elles ne le sont pas. C’est l’équivalent, pour un entrepreneur, de dire « construis-moi une cuisine » sans aucun plan au sol.

Ce qui fonctionne vraiment : associez votre compétence sur les composants à des exemples d’écrans issus d’applications en production.

C’est là que Mobbin justifie son abonnement. La bibliothèque de Mobbin compte plus de 600 000 écrans provenant de plus de 1 200 applications en production en 2026 — ce qui signifie que, pour presque tous les patterns UI que vous essayez de créer, il existe quelque part une version expédiée, conçue par une équipe qui y a probablement réfléchi plus longtemps que vous n’en aurez jamais le temps.

Mon workflow réel, en prenant l’exemple du paywall de samedi :

1. Ouvrir Mobbin. Chercher « paywall » dans la catégorie Finance.
2. Ouvrir le paywall de Rocket Money. Celui de Copilot. Celui de YNAB.
3. Faire une capture d’écran de deux ou trois qui correspondent au ton recherché.
4. Déposer les captures dans Claude Code comme références visuelles, à côté de mes compétences sur les tokens et les composants.
5. Prompt : « Construis un écran de paywall pour une application de finance. Style et mise en page en référence ci-jointe. Utilise nos design tokens et composants. Sors le résultat en HTML. Hero : plan annuel à 79,99 $ avec pastille ‘Économisez 40 %’. Trois lignes de fonctionnalités. Bascule mensuel/annuel. Logos de confiance en bas. »

Ce prompt contient tout ce dont un designer aurait besoin. Des références pour le style et la composition. De la précision sur le contenu. Des contraintes sur les blocs de construction. Aucune ambiguïté à résoudre pour le modèle par moyennage.

Comparez avec « construis-moi un paywall ». La première version vous donne un vrai écran. La seconde vous donne une hallucination d’écran.

(Si vous ne voulez pas Mobbin, les alternatives de 2026 sont vraiment bonnes — InspoAI ajoute la recherche en langage naturel, Appshots montre des parcours plutôt que des écrans isolés, Webframe est orienté web. Je garde Mobbin car les catégories Finance et B2B SaaS y sont plus riches. Votre expérience pourra varier.)

Encore un point sur les références — utilisez-en deux ou trois, pas une seule. Avec une référence, Claude la copie. Avec trois, Claude interpole, ce qui se rapproche bien plus de ce que vous voulez vraiment. L’art du prompt réside dans la distance entre les exemples que vous choisissez.

Voilà. Vous avez les tokens. Vous avez les composants groupés avec leurs règles d’usage. Vous avez des exemples d’écrans. Maintenant, on passe à l’étape où vous installez vraiment la mécanique et générez.

Installer les compétences Figma dans Claude

Deux compétences assurent le travail réel dans ce pipeline, et chacune s’installe en cinq minutes.

1. figma-use — c’est la compétence fondamentale, issue du serveur MCP officiel de Figma. Elle permet à Claude d’écrire sur votre canvas Figma : créer des frames, instancier des composants, appliquer des variables, définir des styles. Tout ce qui entre dans Figma passe par cette compétence. La documentation officielle de Figma détaille l’installation ; en résumé : clonez le dépôt de la compétence, zippez-le, déposez-le dans le dossier des compétences de Claude, redémarrez la session. C’est tout.

2. Votre propre compétence "Apply Design System" — c’est la pièce personnalisée. Un simple fichier markdown que vous rédigez. Il contient :

• Un lien ou une référence vers votre fichier design-tokens.md
• Un lien ou une référence vers votre fichier components.md (groupés par catégorie, avec les règles d’utilisation)
• Un préambule qui indique à Claude comment appliquer ces éléments : "Toujours utiliser les tokens sémantiques. Ne jamais utiliser de valeurs hex brut. Toujours choisir la variante de composant dont la règle d’utilisation correspond au contexte. En cas de doute, demander avant de deviner."
• Une liste de comportements interdits : "Ne pas inventer de nouveaux tokens. Ne pas créer de nouveaux composants. Ne pas utiliser de dégradés qui n’existent pas dans la liste des tokens. Ne pas arrondir les coins avec des valeurs de rayon arbitraires."

Ce préambule est crucial. La liste des comportements interdits, en particulier, est ce qui empêche la dérive vers la "moyenne d’internet". Vous n’apprenez pas au modèle à être créatif. Vous lui apprenez à être discipliné. Et c’est exactement ce que vous voulez lors d’un premier passage.

Déployez les deux compétences. Redémarrez Claude Code. Vérifiez qu’elles sont bien chargées.

À ce stade, vous disposez d’une instance Claude qui comprend vos tokens en anglais, connaît vos composants dans leur contexte, possède des écrans de référence pour le pattern souhaité, et dispose des compétences nécessaires pour écrire dans Figma. C’est la configuration de base. Maintenant, on génère — et voici la partie non évidente que personne ne vous explique.

Si vous préférez que quelqu’un mette en place tout ce pipeline de bout en bout pour un design system en production — compétence tokens, compétences composants, câblage MCP, déploiement équipe — c’est une prestation spécifique que je propose. Vous pouvez voir ce que j’ai réalisé sur fiverr.com/s/EgxYmWD.

Générez localement dans Claude Code d’abord. Puis poussez vers Figma.

Voici l’étape que la plupart des tutoriels ratent. Ils sollicitent Claude une fois, laissent pousser directement dans Figma, regardent le résultat, puis commencent à itérer dans Figma. Ce flux de travail est lent, coûteux en tokens, et produit un résultat de moindre qualité car chaque itération fait un aller-retour via le serveur MCP.

Le bon schéma : itérer d’abord dans Claude Code en HTML. Ne pousser vers Figma que lorsque le HTML est satisfaisant.

Ma séquence réelle pour le paywall finance :

1. Prompt avec tout chargé — compétence tokens, compétence composants, trois références Mobbin, le brief de contenu spécifique. Demander une sortie HTML avec des classes Tailwind mappées à mes design tokens.

2. Claude génère le HTML en ligne dans Claude Code. Je le rends dans un aperçu navigateur. Cela prend environ 8 secondes. Aucun aller-retour Figma.

3. Je le critique. Pas “améliore-le”. Spécifique : “Le CTA principal utilise action-primary-subtle mais c’est une surface de conversion — utilise action-primary-bold. L’espacement de la ligne de fonctionnalités utilise space-3 ; ce pattern requiert space-4 car les icônes font 24px. La ligne des logos de confiance n’a pas de séparateur.”

4. Claude met à jour le HTML. Encore 6 secondes. Je re-render.

5. Je fais cette boucle deux ou trois fois. À ce stade, chaque itération est peu coûteuse — pas de Figma, pas de payload MCP, juste du texte.

6. Quand le HTML est à 90% prêt, je demande à Claude de le pousser dans Figma en utilisant la compétence figma-use. C’est l’opération coûteuse, et je ne la fais qu’une fois par design.

7. Claude écrit les frames dans Figma. De vrais composants. De vraies variables. De vraies variantes. Responsive. Couches nommées. Auto-layout appliqué. Quelques petits ratés sur les styles de texte, que je vais aborder dans un instant.

Ce schéma local-first réduit mon temps d’itération d’environ moitié et consomme nettement moins de tokens. Il produit aussi un meilleur résultat, car j’itère sur le design tant qu’il est encore peu coûteux à modifier. Au moment où je pousse dans Figma, le design est quasiment terminé — Figma est la destination, pas l’atelier.

Un point spécifique à souligner : lorsque vous demandez une sortie HTML, spécifiez les noms des tokens dans le prompt. “Utilise des classes comme bg-surface-raised, text-content-primary, rounded-radius-md.” Cela force Claude à traiter les tokens comme des éléments de première classe dans le markup généré. Vous pourrez les connecter à votre config Tailwind réelle plus tard, ou simplement les lire comme documentation de l’utilisation des tokens. Dans tous les cas, vous obtenez un résultat auditable.

La partie honnête : ce que ce workflow rate encore

J’ai livré des dizaines d’écrans via ce pipeline à ce stade. C’est une amélioration massive par rapport au prompting classique. Mais ce n’est pas magique. Voici précisément ce qui lui échappe encore, sans fard.

Les styles de texte sont les plus souvent oubliés. Claude gère parfaitement l’espacement, les couleurs, les composants, la mise en page — puis applique text-body-md à un titre qui devrait être en text-heading-sm. Je ne comprends pas totalement pourquoi la typographie est spécifiquement le point faible. Ma théorie est que les tokens de style de texte véhiculent une intention plus subtile (« utiliser ceci pour les titres de listes à densité moyenne ») que les tokens de couleur ou d’espacement, et que le modèle a moins de signaux pour s’y accrocher. Quoi qu’il en soit : vérifiez toujours la typographie manuellement côté Figma. Prévoyez trois à cinq minutes par écran pour ce nettoyage.

La direction de l’auto-layout s’inverse parfois. Une ligne devient une colonne, ou l’inverse, surtout dans les composants imbriqués. Généralement, c’est une correction en un clic dans Figma, mais c’est un irritant récurrent.

La personnalité de la marque ne transparaît pas. Le workflow produit des écrans corrects. Il ne produit pas des écrans inspirés. Ce supplément d’âme — la micro-interaction, le choix de composition inattendu, le traitement typographique qui donne à votre app son identité — doit encore venir d’un humain. Ce workflow vous amène à une première version soignée, conforme au design system. Il ne vous amène pas à l’œuvre d’art.

Les tokens sont parfois appliqués littéralement au lieu d’être interprétés sémantiquement. Si Claude voit surface-raised: #F7F7F9 dans mon fichier de tokens, il écrit parfois #F7F7F9 dans le HTML au lieu de bg-surface-raised. Le préambule qui l’interdit aide, mais ne règle pas tout. Passez en revue le code généré.

La parité clair/sombre nécessite une vérification manuelle. Même avec les deux valeurs définies dans vos tokens, il arrive que Claude choisisse une combinaison qui fonctionne en clair mais échoue au contraste WCAG en sombre. Je l’ai vérifié sur le paywall — la ligne des logos de confiance passait le contraste 4,5:1 en mode clair mais tombait à 3,2:1 en sombre. Faites un contrôle de contraste avant de livrer ; le seuil de référence 2026 reste 4,5:1 pour le texte principal.

Si je listais ces échecs sans le contexte de l’amélioration apportée par la structure, cela semblerait pire que ce n’est. Alors laissez-moi inverser la perspective.

Ce qui change réellement : qualité du premier jet et temps de nettoyage

Voici la véritable différence, observée sur mes propres projets au cours des huit dernières semaines. Je ne vais pas vous donner de pourcentages inventés, car je ne consigne pas ces données dans une base de données. Ce que je mesure, c’est le nombre d’écrans livrés sans retouches majeures, et le schéma est suffisamment régulier pour que je lui fasse confiance.

Avant ce workflow : la sortie du premier jet avec un prompt classique nécessitait la plupart du temps une reconstruction structurelle. Les composants étaient incorrects, la hiérarchie bancale, la moitié des tokens n’étaient même pas appliqués. Le chemin réaliste vers un écran prêt à être livré représentait 45 à 90 minutes de nettoyage par écran, et je reconstruisais généralement une bonne partie à la main.

Après ce workflow : la sortie du premier jet est structurellement correcte. Les tokens sont appliqués. Les composants sont justes. La hiérarchie de la mise en page est proche de la version finale. Le nettoyage concerne principalement les styles de texte, un ou deux ajustements d’espacement, et un audit du contraste. Le chemin réaliste vers un écran livrable est de 10 à 15 minutes de nettoyage par écran, et je fais de l’édition plutôt que de la reconstruction.

Le gain cumulatif, c’est la cohérence. Un membre de l’équipe qui suit cette même configuration produit des écrans qui semblent issus du même système, parce qu’ils le sont réellement. Avant les compétences structurées, les écrans générés par l’IA avaient une sorte d’entropie — chaque génération dérivait légèrement. Après l’introduction des compétences structurées, la dérive est limitée par la description même du système.

Pour les équipes qui travaillent avec des design systems, ce schéma reflète ce que Figma a documenté dans leur workflow IA-vers-Figma pour les design systems plus tôt cette année : structurez le système, puis laissez les agents opérer à l’intérieur de cette structure. L’amélioration ne vient pas de modèles plus intelligents. Elle vient de garde-fous plus stricts.

Un dernier point mérite d’être souligné. L’heure que vous passez à rédiger les descriptions de tokens et les règles d’utilisation des composants est une heure qui sera rentabilisée à chaque génération d’écran. Après le cinquième ou sixième écran, le workflow devient largement positif. Avant le cinquième, vous investissez. N’abandonnez pas après le deuxième écran. Arrêtez-vous au dixième si ça ne fonctionne toujours pas, et à ce moment-là vous saurez exactement quelle partie de la configuration doit être resserrée.

Le Paywall, Terminé

Le paywall qui m’a dévoré mon samedi, comme je l’ai raconté en début d’article, a été reconstruit le lendemain matin en environ 40 minutes, y compris le travail sur les tokens et les composants que j’aurais dû faire dès le départ. La version finale utilisait mon véritable action-primary-bold pour le CTA, le bon surface-elevated pour la carte d’abonnement, le rythme précis space-4 pour les lignes de fonctionnalités. Le séparateur avec le logo de confiance était bien là. Les modes clair et sombre passaient tous deux les tests de contraste. Les styles de texte n’ont nécessité qu’un seul passage de nettoyage côté Figma. Expédié.

La leçon, ce n’est pas que le design assisté par IA fonctionne aujourd’hui. La leçon, c’est que le design par IA fonctionne quand vous traitez votre design system comme des données d’entraînement et que vous itérez localement avant de valider sur la maquette. Ça fonctionne quand vous arrêtez d’espérer que le modèle va deviner vos intentions et que vous commencez à décrire ce que vous avez en tête de façon si précise que le modèle n’a plus à deviner.

Voici ce que je veux que vous fassiez aujourd’hui — pas la semaine prochaine, pas après avoir lu trois autres articles. Ouvrez votre design system. Choisissez une catégorie de tokens. Surface, contenu, ou espacement. Rédigez une phrase « quand l’utiliser » pour chaque token de cette catégorie. C’est votre première étape. C’est la clé de tout. Faites-le pour une catégorie aujourd’hui, et vous serez déjà plus avancé que la plupart des équipes. Faites-le pour chaque catégorie cette semaine, et vous aurez un design system qu’un modèle pourra réellement exploiter.

Le prochain paywall que vous construirez ne vous mangera pas votre samedi. Il vous prendra quarante minutes. Et ces quarante minutes seront surtout du nettoyage typographique, ce que — soyons honnêtes — vous auriez fait de toute façon.

Foire aux questions

Ai-je besoin du serveur Figma MCP payant pour utiliser ce workflow ?

Non. Le serveur Figma MCP de base ainsi que la compétence fondamentale figma-use sont gratuits à installer. Un abonnement payant à Figma est requis pour certaines opérations d’écriture dans les bibliothèques d’équipe partagées, mais le travail en solo sur des fichiers brouillon fonctionne avec la version gratuite. Consultez la section d’implémentation ci-dessus pour la configuration complète.

Est-ce que cela fonctionne avec Codex ou d’autres modèles non-Claude ?

Partiellement. Le serveur Figma MCP prend en charge plusieurs clients MCP, dont Codex, donc le côté Figma fonctionne. Le schéma de chargement des compétences est spécifique à Claude — Codex utilise son propre format d’extension. L’idée centrale (tokens structurés + compétences de composants + écrans de référence) est indépendante du modèle et s’adapte à tout agent de codage suffisamment performant.

Combien de temps faut-il pour configurer les tokens de design et les compétences de composants la première fois ?

Prévoyez entre trois et six heures de travail concentré pour un système de taille moyenne, en supposant que vos tokens et composants soient déjà documentés quelque part. Le temps est presque entièrement consacré à la rédaction des descriptions « quand utiliser » — la création mécanique des fichiers de compétences est rapide.

Claude peut-il créer de nouveaux composants si je lui demande ?

Oui, mais il est préférable de l’interdire dans le préambule de vos compétences pour un usage en production. Autoriser Claude à inventer des composants à la volée casse la cohérence du système, ce qui va à l’encontre de l’objectif de cette démarche. Si un nouveau composant est réellement nécessaire, concevez-le d’abord délibérément dans Figma, ajoutez-le ensuite à votre compétence de composant, puis générez avec celui-ci.

Quelle est l’erreur la plus fréquente au démarrage de ce workflow ?

Oublier les descriptions « quand utiliser » sur les tokens. Les équipes copient les noms et valeurs des tokens, pensent que cela suffit, puis s’étonnent que le résultat reste générique. Ce sont les descriptions qui transforment un token de simple donnée en véritable instruction. Sans elles, vous revenez à un prompt basique, avec juste quelques étapes supplémentaires.

Travaillons ensemble

Vous souhaitez créer des systèmes d’IA, automatiser vos workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous accompagner.

• Fiverr (développements & intégrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions d’entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io