admin – Virus Santé Communication

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.

⬡ Ce que ce guide n'est pas

Ce n'est pas un guide de design. Vos choix graphiques — composition, typographie, couleurs, hiérarchie, identité — restent entièrement les vôtres. On parle ici de plomberie : la manière dont le fichier est rangé, pas ce qu'il contient.

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.

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.

◆ Concrètement dans Figma

Rien de neuf à apprendre côté design. Les bonnes habitudes décrites ici — Variables, auto-layout, composants — sont déjà les vôtres si vous travaillez proprement. On les rend simplement systématiques, parce que la machine, elle, ne devine pas vos intentions implicites.

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.

⬡ À retenir

Tout ce qui est implicite à l'œil (« évidemment c'est un bouton », « évidemment ces trois blocs sont identiques ») doit être explicite dans la structure (un composant, un nom clair, un auto-layout). L'œil humain comble les trous ; la structure, non.

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.

✕ Calque brut, non structuré

/* 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 */

✓ Composant + variables + auto-layout

/* 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.

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).

◆ Concrètement dans Figma

Si un élément n'apparaît dans aucune de ces catégories, pour la machine il n'existe pas vraiment — il devient une image figée. Le réflexe : pour chaque zone d'un écran, se demander « par quoi de cette liste est-elle décrite ? ».

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.

◆ Concrètement dans Figma

Panneau de droite → onglet local variables (collections) pour créer vos jetons. Sélectionnez un texte → cliquez sur l'icône de style à droite du champ pour le lier à un style plutôt qu'à des valeurs libres.

✚ Contenu médical

Pour les libellés de soins ou les messages de réassurance, n'inventez pas de promesse clinique. Mettez un texte neutre marqué « à valider » — la formulation finale revient à la clinique et à sa conformité.

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.

⬡ Règle simple

Tout ce qui s'empile ou s'aligne (cartes, listes, barres de navigation, formulaires) devrait être en auto-layout. Réservez le positionnement libre aux éléments vraiment décoratifs et isolés.

◆ Concrètement dans Figma

Sélectionnez les éléments à regrouper → Shift + A pour créer un auto-layout. Réglez ensuite direction, espacement et padding dans le panneau de droite. Préférez les redimensionnements « Hug » (épouse le contenu) et « Fill » (remplit le parent) aux largeurs fixes.

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.

◆ Concrètement dans Figma

Sélection → Ctrl/⌘ + Alt + K pour créer un composant. Regroupez ses états dans un set de variantes et nommez les propriétés clairement (état, type, taille).

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.

⬡ À retenir

Vous n'avez pas à tout renommer. Concentrez-vous sur les conteneurs structurants (sections, cartes, blocs répétés, boutons) — c'est là que le nom paie. Les petits calques internes comptent moins.

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.

◆ Concrètement dans Figma

Utilisez l'auto-layout avec « Fill » pour les blocs qui doivent s'étirer, et précisez les contraintes dans le panneau de droite. Si un comportement responsive n'est pas évident, montrez-le plutôt que de le décrire : une frame mobile vaut mille mots.

⬡ À retenir

En l'absence de version mobile, le MCP doit supposer. Supposer, c'est risquer un rendu qui ne correspond pas à votre intention. Une frame mobile, même rapide, supprime ce risque.

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é.

▲ Piège fréquent

Un logo aplati en image matricielle (PNG flou) au lieu d'un SVG oblige à le redemander. Gardez les vectoriels vectoriels.

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.

◆ Concrètement dans Figma

Basculez en Dev Mode (interrupteur en haut à droite) et ajoutez des annotations sur les éléments concernés. Une note courte et précise vaut mieux qu'un long paragraphe : « bouton → ancre #rendez-vous » suffit.

Ce qui casse le MCP

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

▲ À éviter

Tout aplatir en image (texte inclus) : plus rien n'est lisible ni éditable.
Composants détachés : on perd la réutilisation et les états.
Positionnement absolu partout au lieu d'auto-layout : aucune logique responsive.
Calques « Frame 427 », « Rectangle 12 » : zéro indice de structure.
Couleurs et tailles en dur au lieu de variables/styles : rien de thématisable.
Texte transformé en contour/image : il devient une forme, plus du contenu.
Calques masqués qui traînent, doublons, « copie de copie » : du bruit qui induit en erreur.

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.

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 ».

FAQ & objections

« La machine va-t-elle remplacer mon travail de design ? »

Non. Le MCP ne conçoit rien : il recopie ce que vous avez décidé. Il n'a aucune idée de ce qui fait une bonne composition — c'est précisément pour ça qu'il a besoin que vous ayez tranché. Il remplace la partie ingrate (retranscrire des espacements en code), pas la partie créative.

« Ça va m'imposer une façon de dessiner. »

Non plus. Variables, auto-layout et composants sont des outils Figma natifs que les studios sérieux utilisent déjà. On ne change pas ce que vous dessinez, seulement la propreté du rangement — un peu comme nommer ses calques avant de livrer un fichier d'impression.

« C'est plus de travail pour moi. »

À court terme, quelques minutes de structuration. À moyen terme, beaucoup moins d'allers-retours : pas de « c'était quelle couleur, déjà ? », pas de reprise parce que le développeur a mal interprété. Et un fichier propre se réutilise d'un projet de clinique à l'autre.

« Et si je ne fais rien de tout ça ? »

Ça reste possible — mais le MCP devra deviner, et chaque supposition est un risque d'écart avec votre intention. Vous récupérez alors un thème « à peu près », qu'il faut corriger à la main. La préparation déplace l'effort avant plutôt qu'après, là où il coûte le moins cher.

« Le rendu sera-t-il vraiment fidèle à ma maquette ? »

Avec un fichier structuré comme décrit ici : oui, au pixel près sur les éléments normés (couleurs, espacements, typo). Les écarts restants concernent les zones laissées ambiguës — d'où l'intérêt des frames mobiles et des annotations. Plus vous précisez, plus c'est fidèle.