Figma MCP : relier vos maquettes à votre base de données

Et si vos maquettes Figma pouvaient “expliquer” leur logique à un LLM, tout en se branchant à votre API ou à votre base de données. C’est exactement la promesse de Figma MCP, quand c’est bien cadré.

En clair : à quoi sert Figma MCP dans une équipe produit

Figma MCP (Model Context Protocol) permet de faire passer le context de vos designs Figma (components, variables, structure, styles) vers un MCP client comme Cursor, VS Code ou Claude Code. Ensuite, ce client peut combiner ce contexte avec votre codebase et vos données (API, serveur, base) pour produire un code plus fidèle et plus vite. 

Concrètement, vous l’utilisez pour :

• générer du code à partir d’un écran Figma sans perdre les détails (layout, variables, components)
• garder une cohérence entre design system et implémentation, même quand plusieurs développeurs travaillent en parallèle
• brancher une UI sur des données réelles via une API ou un serveur, avec les bons champs et les bons états
• accélérer les itérations, surtout quand le produit est data-driven (catalogue, back-office, dashboard)

Le workflow “figma → code → data” en 7 étapes

1. Structurer la conception dans Figma (components, variables, noms utiles)
2. Démarrer un MCP server Figma (desktop ou server remote)
3. Connecter votre MCP client (Cursor, VS Code, Claude Code)
4. Gérer l’access via OAuth ou un token / jeton selon le mode
5. Ajouter le context “data” (API endpoints, schéma DB, règles serveur)
6. Générer le code UI aligné design, puis brancher la donnée
7. Verrouiller la qualité (états, erreurs, perf, sécurité, règles)

L’idée n’est pas de “tout automatiser”. L’idée est d’obtenir un pipeline plus fiable, avec des garde-fous.

MCP, c’est quoi exactement et pourquoi tout le monde s’y met

Le Model Context Protocol (MCP) est un protocol ouvert pour connecter des apps LLM à des sources externes. Au lieu de créer une intégration sur mesure entre chaque outil et chaque model, on standardise : un serveur expose des tools, un client les appelle. 

Pourquoi c’est important pour Figma ?

• Un LLM qui reçoit le bon context (noms de components, variables, contraintes, hiérarchie) peut être précis.
• La frontière prototype / produit s’est réduite, surtout avec des approches prompt-to-app. Figma pousse cette logique plus loin avec Make et l’accès “design context everywhere”. 

Comment “relier une maquette à une base de données” fonctionne vraiment

On parle souvent de “connecter Figma à une DB” comme si Figma allait lire Postgres. En pratique, la connexion utile est ailleurs : vous connectez un agent (dans votre IDE) à Figma, puis cet agent connecte votre UI à la donnée via votre API ou votre serveur.

Les 4 briques à connaître

Figma documente deux façons de connecter son MCP server : desktop (local) et remote (hébergé).

Desktop ou remote : lequel choisir dans une PME

Le bon choix dépend de votre organisation, pas de la hype.

• Desktop MCP server : idéal pour démarrer vite. Il tourne en local via l’app Figma bureau. Figma indique une URL locale de serveur (127.0.0.1) pour la configuration côté client.
• Remote MCP server : utile quand vous voulez connecter sans dépendre d’un poste précis, ou quand l’équipe est distribuée. Il se connecte à un endpoint hébergé par Figma et passe par une authentification OAuth.

Un repère simple :

• équipe petite, itérations rapides, besoin d’un POC fiable : desktop
• équipe multi-dev, process outillé, besoin d’un accès homogène : remote

Ce que Figma MCP change pour le design et le code

Le gain principal n’est pas “générer du code”. Le gain principal est d’aligner trois mondes qui se parlent mal :

• le design (Figma)
• la réalité du code (codebase, conventions, components existants)
• la réalité de la donnée (API, règles serveur, formats)

Avec MCP, vous créez un “couloir” de context qui réduit les pertes d’information. Et c’est souvent là que se cachent les coûts : retours QA, incohérences, états oubliés, duplications de components.

Les cas d’usage les plus rentables (et les plus demandés)

Catalogue produits : e-commerce, B2B, marketplace

Un écran Figma “listing + fiche produit” a l’air simple, mais la donnée casse vite la conception :

• variantes, prix promo, stock, badges, règles de tri
• cartes qui changent selon le status ou le segment client

Avec un workflow MCP bien cadré, vous cherchez deux résultats :

1. des components de code qui reprennent la structure du design (grilles, spacing, typographies, variables)
2. un mapping clair entre champs data et UI, sans inventer des propriétés

Ici, le LLM est utile s’il sait lire votre design et votre API dans le même context.

Pages marketing et CMS : vitesse sans dette

Quand le contenu vit dans un CMS, la difficulté n’est pas la mise en page. C’est la robustesse :

• états “vide”, “chargement”, “erreur”
• composants réutilisables, pas un empilement de sections uniques
• règles simples côté serveur (cache, revalidation, sécurité)

Figma MCP aide à garder une cohérence visuelle, pendant que le développeur garde la maîtrise des règles serveur.

Dashboard et back-office : la vraie vie de la donnée

Pour un back-office, l’écran Figma est le début. Ensuite arrivent :

• tableaux, filtres, pagination, tri
• droits d’accès, rôles, audit
• performance et lisibilité

Le combo MCP + API contract est intéressant ici, car il force la conception à prendre en compte les états et les contraintes.

Design system vivant : variables, components, conventions

C’est souvent le cas d’usage le plus “sous-estimé”. Quand vos variables Figma sont propres et que vos components sont bien définis, le code généré devient plus stable. Et surtout, il devient réutilisable.

Figma met en avant l’extraction de variables et components via son MCP server pour améliorer la cohérence du code.

Mise en place : de Figma à Cursor, puis jusqu’à votre API

L’objectif ici n’est pas de vous donner une recette magique. L’objectif est de clarifier les étapes, pour que vous sachiez ce qu’il faut cadrer dans votre workflow.

Activer le MCP server côté Figma

Option desktop (bureau)
Dans Figma desktop, vous passez en Dev Mode, puis vous activez le desktop MCP server dans le panneau d’inspection. Figma indique ensuite l’adresse locale du server.

Option remote (hébergé)
Vous connectez votre client (VS Code, Cursor, Claude Code) au serveur remote Figma via l’endpoint MCP, puis vous autorisez l’accès (OAuth). La doc Figma montre un exemple de configuration mcp.json pour VS Code, et un flux guidé pour Cursor. 

Exemple de configuration côté VS Code (remote) :

{

  "inputs": [],

  "servers": {

    "figma": {

      "url": "https://mcp.figma.com/mcp",

      "type": "http"

    }

  }

}

Donner au LLM le bon context, sans le noyer

C’est un point qui distingue les projets “waouh en démo” des projets fiables.

Deux modes utiles existent côté Figma :

• selection-based (plutôt desktop) : vous sélectionnez un frame ou un layer dans Figma, puis le client travaille sur cette sélection
• link-based (remote et desktop) : vous donnez un lien vers un node, le client extrait le node-id et récupère le context 

Dans un produit réel, le lien fonctionne bien pour cadrer. La sélection fonctionne bien pour itérer vite.

Relier la base de données : le pattern qui évite les problèmes

Le pattern le plus sain pour une PME est souvent :

• UI générée ou assistée via MCP
• données via une API contrôlée (REST/GraphQL) côté serveur
• secrets et règles d’accès exclusivement côté serveur

Un accès direct DB depuis un tool MCP peut exister, mais il doit être verrouillé. Sinon, vous créez une surface de risque inutile, surtout avec des tokens mal gérés.

Obtenir un code fidèle au design (et pas “à peu près”)

Quand un LLM sort du code “propre” mais faux, ce n’est pas un problème de model. C’est un problème de context et de conventions.

Côté Figma : ce qui augmente la qualité

• Des components nommés comme des composants réels, pas “Frame 123”
• Des variables cohérentes (typo, spacing, colors) plutôt que des valeurs isolées
• Des variants limités mais intentionnels (size, state, intent)
• Des frames pas trop lourds : moins de bruit, plus de signal

Figma recommande d’éviter les frames trop lourds et de structurer le fichier pour de meilleurs résultats. 

Côté codebase : la clé est dans vos règles

Le LLM doit comprendre :

• vos conventions (naming, dossiers, lint)
• vos components existants
• votre façon de brancher l’API (fetch layer, services, hooks, cache)

C’est là que beaucoup d’équipes gagnent du temps : elles transforment le MCP en vrai workflow d’équipe, pas en outil perso.

Sécurité, access, token : ce qu’il faut verrouiller avant de connecter

Dès que vous “connect” un LLM à des tools, vous gérez des permissions. C’est une bonne nouvelle si c’est propre. C’est une mauvaise nouvelle si c’est implicite.

Les règles simples qui évitent 80% des soucis

• Un token ou jeton n’a jamais plus de droits que nécessaire
• Pas de secrets dans le client, tout passe par le serveur
• Des environnements séparés (dev, staging, prod)
• Des logs côté serveur pour savoir quel tool a été appelé, quand, et pourquoi
• Une liste courte de tools autorisés, avec une key de rotation si besoin

Remote MCP : OAuth et contrôle

Le remote MCP server Figma passe par un flux OAuth. C’est un bon point, car vous évitez de distribuer des clés statiques partout. 

À ce stade, ce qui compte, c’est votre gouvernance : qui peut accéder à quels fichiers Figma, et dans quel contexte.

Pour passer de la maquette à une app reliée à la donnée, sans dette

Figma MCP est un excellent levier quand il est traité comme un vrai sujet de produit : conventions, sécurité, access, mapping API, et intégration à la codebase. C’est exactement ce qui fait la différence entre une démo impressionnante et un workflow fiable au quotidien.

Chez Scroll, on aide les PME, TPE et entrepreneurs à mettre en place ce type de chaîne design → code → data, avec un cadre simple : design system, MCP server et client (Cursor, VS Code), règles de génération, et branchement propre à votre serveur et votre API. L’objectif est clair : livrer plus vite, sans perdre la maîtrise.

‍