Préparer un fichier Figma
pour qu'il devienne du code.

00

Objectif & périmètre

Ce guide explique une seule chose : comment préparer techniquement un fichier Figma pour qu'un outil automatisé — le MCP — puisse le transformer en thème WordPress propre.

Le MCP (Model Context Protocol) est le pont qui permet à Claude Code de lire votre fichier Figma et d'en générer le code (HTML, SCSS/CSS, PHP, blocs Gutenberg). Plus le fichier est structuré, plus le code produit est fidèle à votre intention — et moins il y a d'allers-retours.

Autrement dit : vous continuez à concevoir exactement comme aujourd'hui. On vous demande seulement quelques habitudes de rangement qui font qu'un écran « se code tout seul » au lieu d'être redessiné à la main.

01

Ce que ça change pour vous

Concrètement, un fichier bien préparé change votre quotidien sur trois plans :

• Moins d'allers-retours. Quand le code sort juste, on ne revient pas vous voir dix fois pour « c'était quel espacement, déjà ? ».
• Votre fichier devient la source de vérité. Les couleurs, les marges, les tailles de texte que vous posez sont reprises telles quelles. Personne ne « réinterprète » votre maquette.
• Votre fidélité est préservée. Le but n'est pas que la machine invente — c'est qu'elle recopie ce que vous avez décidé, au pixel près.

02

Comment Claude lit un Figma

Point clé, et il change tout : le MCP ne « regarde » pas une image. Il ne voit pas votre maquette comme une capture d'écran. Il lit la structure de données de votre fichier : la liste des calques, leurs noms, leurs propriétés d'auto-layout, les variables liées, les styles, les contraintes.

Pensez-y comme à un imprimeur qui ne reçoit pas une photo de l'affiche, mais le fichier vectoriel avec tous les calques nommés. Si vos calques s'appellent Frame 427 et Rectangle 12, il devine. S'ils s'appellent carte-service et bouton-rdv, il sait.

03

Preuve : Figma → code

Un même bouton « Prendre rendez-vous », selon qu'il est préparé ou non. Le rendu visuel peut sembler identique dans Figma — mais ce que la machine en tire diffère radicalement.

/* ce que le MCP doit deviner */
<div style="
  position:absolute;
  left:412px; top:880px;
  width:198px; height:52px;
  background:#6d7f60">
  <span>Prendre rendez-vous</span>
</div>
/* couleur en dur, position figée,
   rien de réutilisable */

/* ce que le MCP recopie */
<a class="btn btn--primary"
   href="#rendez-vous">
  Prendre rendez-vous
</a>

.btn--primary {
  background: var(--color-accent);
  padding: var(--space-3) var(--space-5);
  border-radius: var(--radius-md);
}

À gauche : des valeurs en dur, une position absolue, rien de réutilisable — le code devra être réécrit à la main. À droite : un composant nommé, des variables liées, un auto-layout. Le second se branche directement sur le thème WordPress. C'est le même bouton à l'écran ; ce n'est pas le même fichier.

04

Ce que le MCP consomme

Voici, par ordre d'importance, les éléments que le MCP exploite directement. Chacun fait l'objet d'une section dédiée plus loin.

• Variables (couleurs, espacements, rayons, typo) → variables CSS / tokens.
• Styles de texte → familles, tailles, graisses, interlignes.
• Auto-layout (direction, gap, padding, alignement) → flexbox / grid.
• Composants & variantes → blocs réutilisables et leurs états.
• Noms de calques → indices de structure (sections, classes).
• Contraintes → comportement responsive.
• Calques exportables → images, icônes, logos.
• Annotations Dev Mode → comportements invisibles (liens, états, champs CMS).

05

Variables & Styles

Les Variables Figma sont la pierre angulaire. Une couleur posée via une variable (color/accent) devient une variable CSS (--color-accent) dans le thème. Une couleur posée « à la main » devient un code hexadécimal figé, impossible à thématiser.

Couleurs

Définissez vos couleurs comme variables, et nommez-les par rôle, pas par teinte : color/accent plutôt que vert-sauge, color/text plutôt que gris-fonce. Le rôle survit à un changement de teinte ; la teinte, non.

Espacements & rayons

Posez une échelle d'espacement en variables numériques (space/1 = 4, space/2 = 8, space/3 = 12…) et utilisez-la pour les paddings et les gaps. Idem pour les rayons (radius/sm, radius/md). Le code reprend l'échelle telle quelle.

Styles de texte

Chaque niveau (H1, H2, corps, légende…) doit être un style de texte nommé, pas un réglage ponctuel. Le MCP en tire la hiérarchie typographique du thème.

06

Auto-layout

L'auto-layout est ce qui se traduit le plus directement en code. Un cadre en auto-layout devient un conteneur flex : la direction devient flex-direction, l'espace entre éléments devient gap, les marges internes deviennent padding, l'alignement devient justify-content / align-items.

À l'inverse, un élément positionné en absolu (posé « à l'œil » sur la toile) ne porte aucune logique de mise en page. Le MCP doit alors figer des coordonnées — ce qui casse au premier changement de contenu ou de taille d'écran.

07

Composants & variantes

Un composant Figma devient un bloc réutilisable dans le thème (bloc Gutenberg, partial PHP, ou classe de composant). Si trois cartes de service sont trois copies indépendantes, le MCP code trois fois la même chose. Si ce sont trois instances d'un composant carte-service, il code un bloc, décliné trois fois.

Variantes = états et déclinaisons

Les variantes (et propriétés de variante) décrivent les états : un bouton type=primaire / secondaire, état=normal / survol / désactivé. Elles se traduisent en modificateurs CSS (.btn--primary, .btn:hover) ou en attributs de bloc.

Propriétés de composant

Les propriétés de texte et les swaps d'instance signalent ce qui est variable (donc, souvent, un champ éditable côté WordPress) versus ce qui est fixe.

08

Nommage

Les noms de calques sont des indices gratuits que vous donnez à la machine. Frame 427 ne dit rien ; section-services dit tout.

• Nommez par rôle / contenu, pas par apparence : en-tete, carte-service, pied-de-page.
• Restez cohérent : un même type d'élément porte toujours le même nom.
• Préférez les minuscules et les tirets : bouton-rdv plutôt que Bouton RDV (copie 2).
• Nettoyez les Group 12, Rectangle 8, copie de… avant la remise.

09

Contraintes & responsive

Un site de clinique est consulté en grande majorité sur téléphone. Le MCP a besoin de savoir comment chaque bloc se comporte quand la largeur change. Deux leviers :

• Les contraintes (gauche/droite/centré, étiré…) indiquent comment un élément réagit au redimensionnement de son parent.
• Les maquettes par point de rupture. Fournir au moins une version mobile en plus du bureau lève toute ambiguïté : ordre des blocs, ce qui passe en pleine largeur, ce qui se masque.

10

Export des assets

Tout ce qui est graphique et non reproductible en CSS (logos, illustrations, icônes sur mesure, photos) doit être exportable proprement.

• Icônes & logos : en SVG (vectoriel, net à toute taille).
• Photos : WebP ou JPG, et prévoir le @2x pour les écrans Retina.
• Nommage des exports : logo-clinique.svg, icone-rdv.svg — lisibles, sans espaces ni accents.
• Marquez les calques exportables (réglages d'export dans le panneau de droite) pour qu'ils soient repérés sans ambiguïté.

11

Dev Mode & annotations

Certaines informations ne se voient pas sur une maquette statique : où mène un lien, quel est l'état au survol, quel bloc est répétable, quel texte sera géré dans WordPress. Le Dev Mode de Figma et ses annotations servent exactement à ça.

• Annotez les liens et destinations (« mène vers la page Services »).
• Signalez les états interactifs non dessinés (survol, focus, actif).
• Indiquez les champs éditables côté CMS (« titre géré en ACF », « liste de services dynamique »).
• Précisez les blocs répétables et leur source de données.

12

Ce qui casse le MCP

La liste noire — les pratiques qui forcent la machine à deviner, donc à se tromper :

Aucune de ces pratiques n'est « une faute de design ». Ce sont des habitudes de toile libre qui n'ont juste pas de traduction en code. Les éviter, c'est parler la langue de la machine.

13

Check-list de remise

Avant d'envoyer le fichier, un dernier passage. Si tout est coché, le MCP produit un thème fidèle dès le premier jet.

• Variables — couleurs, espacements et rayons sont posés en variables nommées par rôle.
• Styles de texte — chaque niveau typographique est un style, pas un réglage libre.
• Auto-layout — tout ce qui s'empile ou s'aligne est en auto-layout, pas en absolu.
• Composants — les éléments répétés sont des instances d'un composant unique.
• Variantes — les états (survol, désactivé, types) sont décrits en variantes.
• Nommage — conteneurs structurants nommés par rôle ; plus aucun « Frame 427 ».
• Responsive — au moins une frame mobile en plus du bureau ; contraintes réglées.
• Assets — logos/icônes en SVG, photos en WebP/JPG @2x, exports marqués et nommés.
• Annotations — liens, états et champs CMS signalés en Dev Mode.
• Nettoyage — calques masqués, doublons et « copie de… » supprimés.
• Contenu médical — aucun claim clinique inventé ; placeholders « à valider ».

14

FAQ & objections

Annexe A

Un fichier exemple, expliqué pas à pas

Pour rendre tout ça concret, ouvrons un fichier bien préparé comme une boîte transparente. On prend une page d'accueil de clinique dentaire. Aucune connaissance de Figma n'est nécessaire pour suivre.

Le mini-lexique — 6 mots à connaître

L'exemple : la page d'accueil d'une clinique dentaire

Le visiteur, lui, voit une page normale : un menu, une grande zone d'accueil avec un bouton « Prendre rendez-vous », trois cartes de services, un formulaire, un bas de page. Voici comment cette même page est rangée à l'intérieur du fichier :

📄 Accueil — version ordinateur          ← le grand cadre de la page
├─ en-tete                               ← le menu du haut (composant réutilisé)
├─ section-hero                          ← la zone d'accueil
│  ├─ titre        (style display/h1)
│  ├─ accroche     (style body/lead)
│  └─ bouton « Prendre rendez-vous »     ← composant bouton
├─ section-services                      ← une rangée de cartes
│  └─ carte-service ×3                   ← 3 copies du MÊME modèle
├─ section-rendez-vous                   ← le formulaire
└─ pied-de-page                          ← bas de page (composant réutilisé)

📱 Accueil — version téléphone           ← la même page, réorganisée pour mobile

Tout est nommé clairement, rangé en sections, et les éléments répétés sont des copies d'un même modèle. C'est exactement ce qui permet à la machine de recopier la page fidèlement. Décortiquons chaque ingrédient :

1. Les variables — « les contacts de votre téléphone »

   La couleur de marque est enregistrée une fois sous le nom color/accent. Comme un contact « Maman » : changez le numéro à un seul endroit, et tous les appels aboutissent au bon numéro. Ici, on change la couleur une fois → tout le site se met à jour.

2. Les styles de texte — « le style Titre de Word »

   Comme le style « Titre 1 » d'un traitement de texte : la forme du gros titre est définie une seule fois (display/h1) puis réutilisée partout. Pas besoin de re-régler la police à chaque page.

3. Les composants — « l'emporte-pièce à biscuits »

   Le bouton et la carte de service sont des modèles. Comme un emporte-pièce : un seul moule, autant de biscuits identiques qu'on veut. Les trois cartes de services sont trois copies d'un même modèle — corriger le modèle les corrige toutes les trois.

4. L'auto-layout — « l'étagère qui se range seule »

   Les éléments ne sont pas posés « à l'œil ». Ils sont dans un rangement automatique qui les aligne et garde des espaces réguliers — comme une étagère qui ré-espace les livres quand on en ajoute un. Si un texte s'allonge, tout se replace proprement.

5. Le nommage — « étiqueter les boîtes de déménagement »

   Une boîte marquée « cuisine » se range toute seule ; une boîte « divers » oblige à tout rouvrir. section-services dit ce que c'est ; Frame 427 ne dit rien. Des noms clairs = une machine qui comprend la structure.

6. La version téléphone — « montrer plutôt que décrire »

   On fournit une deuxième version de la page, pour téléphone, qui montre comment les blocs se réorganisent (le menu se replie, les cartes passent les unes sous les autres). Plus besoin de deviner : on voit.

7. Les annotations — « les post-it sur la maquette »

   Des notes collées sur les éléments expliquent ce qui ne se voit pas sur une image : où mène un bouton, quel texte sera modifiable dans WordPress, quelle liste est alimentée automatiquement. Comme des post-it laissés au développeur.