Article original : Figma MCP vs Kombai: Cloning the Front End from Figma with AI Tools
L'automatisation du front-end évolue rapidement. Des outils comme Figma MCP et Kombai peuvent lire le contexte du design et générer du code UI fonctionnel. J'ai voulu voir ce que l'on obtient réellement en pratique, j'ai donc décidé de les comparer.
Figma MCP expose les métadonnées de design aux clients IA, tandis que Kombai est un agent orienté front-end qui s'intègre aux éditeurs et aux stacks existantes.
Dans cet article, nous allons soumettre les deux mêmes fichiers Figma aux deux outils, examiner à quel point le résultat est fidèle aux designs et analyser la structure du code dans un véritable éditeur.
Table des matières
De quoi s'agit-il ?
Cloner des designs Figma complexes à la main n'est plus amusant, tout comme écrire votre CSS ligne par ligne avec une précision exacte.
Et bien sûr, vous pouvez joindre une capture d'écran ou autre à GPT, mais on finit souvent avec quelque chose qui ressemble à peine à votre design. C'est là qu'interviennent Kombai ou le Figma MCP.
Ils récupèrent réellement les métadonnées de votre design Figma et vous fournissent un code front-end extrêmement proche du modèle original.
Désormais, au lieu de passer des heures à reconstruire ce qui se trouve déjà dans votre fichier de design, vous pouvez vous concentrer davantage sur les petits ajustements et sur ce qui compte vraiment.
Présentation des outils
Kombai

Kombai est un agent IA conçu pour le travail front-end. Il prend des entrées de Figma (comme du texte, des images ou votre code existant), comprend votre stack et les convertit en une UI propre et prête pour la production.
💡 Il est conçu spécifiquement pour le front-end, vous pouvez donc vous attendre à ce qu'il soit très performant dans ce domaine (contrairement à des outils plus génériques comme ChatGPT ou Claude).
Kombai gère également les grands dépôts (repositories) facilement. Il ne se contente pas de convertir des designs Figma en code. Il comprend l'intégralité de votre base de code front-end, même si elle est immense.
Ainsi, que vous travailliez sur un petit projet personnel ou sur une application de production très volumineuse, il peut lire, modifier et écrire du code qui s'intègre parfaitement dans votre projet existant.
Note : Kombai n'est pas seulement doué pour cloner des designs Figma et écrire du code propre. Il comprend aussi tout votre repo. Vous pouvez discuter avec lui comme avec GPT, mais il connaît déjà votre front-end. Il peut aider à refactoriser le code, à nettoyer les choses ou à effectuer des changements sans jamais toucher à votre logique back-end.
Plutôt pratique, non ?
Aucun code back-end n'est jamais touché, ce qui garantit qu'aucune de vos logiques métier n'est modifiée par erreur.
Vous pouvez également ajouter Kombai directement dans votre éditeur. Il fonctionne avec VSCode, Cursor, Windsurf et Trae. Il suffit de le récupérer sur le marketplace des extensions, de le lancer, et vous êtes prêt.
Avec Kombai, vous pouvez :
Transformer des designs Figma en code (React, HTML, CSS, etc.) en utilisant la bibliothèque de composants que votre projet utilise déjà.
Travailler avec un moteur intelligent en front-end qui comprend plus de 30 bibliothèques, dont Next.js, MUI et Chakra UI.
Rester dans votre éditeur, suivre vos propres conventions et livrer plus rapidement avec une bonne précision.
Et surtout, prévisualiser les changements dans un bac à sable (sandbox) afin de pouvoir approuver ou rejeter la modification avant de la
commitdans les fichiers.
Vous pouvez être opérationnel en moins d'une minute. Voici les étapes pour commencer :
Installer l'extension pour votre éditeur
Se connecter et lier votre projet
Coller un lien Figma ou décrire ce que vous voulez construire
Examiner le résultat et
commitvotre code
Vous pouvez le trouver dans le marketplace des extensions de votre IDE.

L'utiliser est aussi simple que d'y accéder depuis la barre latérale gauche et de discuter de la même manière qu'avec ChatGPT. (Optionnellement, vous pouvez ajouter votre stack technique, mais Kombai la gère automatiquement.)

Rendez-vous sur la documentation pour commencer et trouver la configuration pour votre éditeur.
Note sur les tarifs : Kombai est un outil payant mais propose un plan gratuit avec 300 crédits par mois, ce qui est idéal pour les projets personnels. Pour des flux de travail plus avancés, vous pouvez passer au plan Pro ou au plan Enterprise.
Si vous passez la majeure partie de votre temps sur le front-end, Kombai peut être un bon choix.
Figma MCP
Figma MCP (Model Context Protocol) permet aux agents IA de se connecter directement à vos fichiers Figma. Il comble le fossé entre vos designs et vos outils IA en leur donnant un accès structuré aux données de design réelles au lieu de se fier à des captures d'écran ou à des estimations approximatives.
Il fonctionne en exposant l'arborescence des nœuds de votre design, les styles, les règles de mise en page et la structure des composants afin que le modèle puisse construire l'UI avec des données de design réelles.
Cela signifie que des outils comme Claude Code, Gemini CLI, Cursor et VSCode peuvent réellement lire vos designs, y compris les calques, les composants, les couleurs, l'espacement et le texte, et utiliser ce contexte pour générer un code précis et prêt pour la production ou des mises à jour de design.
Avec Figma MCP, vous pouvez :
Laisser les outils IA extraire des données en direct de vos fichiers Figma, afin que vos suggestions de code correspondent toujours à vos derniers designs.
Demander à votre assistant IA d'inspecter des composants, des mises en page ou des styles directement depuis Figma.
Générer du code UI qui reflète le design et la structure réels au lieu de deviner à partir d'une image.
Maintenir les designers et les développeurs synchronisés sans envoyer constamment des fichiers.
La configuration est simple :
Lancer le serveur Figma MCP localement
Autoriser votre espace de travail Figma
Connecter votre éditeur ou outil IA (Cursor, Claude Code, Gemini CLI, etc.)
Pour ce test, j'utiliserai Figma MCP dans Claude Code sous Linux, et la configuration est aussi simple que d'ajouter le JSON suivant dans votre fichier de configuration Claude ~/.claude.json :
{
"mcpServers": {
"Framelink MCP for Figma": {
"command": "npx",
"args": ["-y", "figma-developer-mcp", "--figma-api-key=YOUR-KEY", "--stdio"]
}
}
}
Pour les utilisateurs Windows :
{
"mcpServers": {
"Framelink MCP for Figma": {
"command": "cmd",
"args": ["/c", "npx", "-y", "figma-developer-mcp", "--figma-api-key=YOUR-KEY", "--stdio"]
}
}
}
Note sur les tarifs : Pour utiliser Figma MCP, vous devez disposer d'un plan Figma payant (Professional, Organization ou Enterprise). Mais il existe un serveur MCP open-source maintenu par la communauté, Figma-Context-MCP, que vous pouvez tester gratuitement – c'est celui que j'utiliserai pour ce test.
Une fois qu'il est en cours d'exécution, n'importe quel outil compatible MCP peut comprendre vos fichiers de design, rendant le développement de code front-end beaucoup plus précis.
Consultez le Guide Figma MCP pour commencer.
Comparaison Front-End avec Figma
Pour ce test, nous allons comparer Kombai avec Figma MCP en utilisant deux designs Figma : l'un est un design de portfolio simple, et l'autre est un tableau de bord d'apprentissage plus complexe.
NOTE : Pour ce test avec Figma MCP, j'utiliserai Sonnet 4 qui, d'après mon expérience, a été le meilleur modèle pour coder le front-end. J'ai également testé avec les récents GPT-5 et Opus 4, mais Sonnet 4 semble être le plus performant pour le travail front-end. Si vous souhaitez essayer d'autres modèles, n'hésitez pas à le faire pour voir si vous remarquez une grande différence dans les résultats.
💁 Prompt : Clone ce design Figma à partir du lien de la frame Figma joint. Écris un code propre, maintenable et responsive qui correspond étroitement au design. Garde les composants simples, réutilisables et prêts pour la production.
Note rapide concernant les vidéos de la section suivante : Les enregistrements de démonstration sont assez longs car je les ai laissés bruts. L'idée est de montrer comment les outils se comportent en temps réel. Si seul le résultat final vous intéresse, n'hésitez pas à passer à la fin de chaque vidéo.
Test 1 : Design d'un portfolio simple
Commençons par un design plus simple avec peu d'éléments dans l'UI.
Vous pouvez trouver le template de design Figma ici : Personal Portfolio Template
Figma MCP
Voici la réponse de Figma MCP :
C'est plutôt correct. L'UI globale est bonne, et les couleurs ainsi que les polices sont toutes précises. Les plus gros problèmes visuels concernent l'image hero et quelques placements d'icônes, qui sont un peu décalés par rapport au fichier Figma original.
L'implémentation globale n'a pris qu'environ 5 minutes de codage et a permis d'obtenir tout ce résultat en une seule fois, comme vous le voyez dans la démo vidéo. Le temps nécessaire ne dépend pas vraiment du MCP lui-même mais surtout du modèle, les durées varieront donc en fonction du modèle que vous choisissez. Le timing est un élément que vous pouvez simplement ignorer ici.
Toute la page est divisée en composants logiques (Header, Hero, Projects, ProjectCard, Footer) et composée dans un fichier page.tsx propre.
export default function Home() {
return (
<div className="min-h-screen bg-bg-gray">
<Header />
<main>
<Hero />
<Projects />
</main>
<Footer />
</div>
);
}
C'est un point de départ agréable et lisible pour une application Next.
Vous pouvez trouver le code généré ici.
Mais voici quelques problèmes que j'ai remarqués immédiatement :
- La décoration hero est positionnée avec des valeurs absolues assez fragiles :
<div className="hidden lg:block absolute right-0 top-0 w-[720px] h-[629px] pointer-events-none">
<div className="relative w-full h-full">
<div className="absolute left-0 top-0 w-[777px] h-[877px] -translate-y-[248px] bg-brand-yellow" />
<div className="absolute left-0 top-0 w-full h-full">
<img
src="/images/hero-decoration-58b6e4.png"
alt="Decorative"
className="w-full h-full object-cover"
/>
</div>
</div>
</div>
Cela permet d'obtenir l'aspect souhaité sur une taille d'écran donnée, mais cela peut facilement se désaligner lors du redimensionnement. En comparant côte à côte avec la frame Figma, l'image hero et la forme jaune ne s'alignent pas comme elles le devraient.
- En-tête fixe
Pour une simple page de portfolio avec une section hero courte, un en-tête fixe ne vaut pas toujours la complexité induite.
Le problème ici est que, puisque l'en-tête est fixé en haut, le reste du contenu commence également tout en haut. Sur des appareils plus petits, cela pourrait couvrir des parties du contenu lors du défilement.
return (
<header className="fixed top-0 left-0 right-0 bg-bg-gray z-50 h-14">
{/* ... */}
<button
onClick={() => scrollToSection("about")}
className="font-raleway ..."
>
About
</button>
{/* more buttons */}
</header>
);
Cela reste une excellente base, bien que ce ne soit pas tout à fait au niveau où je l'ajouterais à un repo de production sans nettoyer certains changements de mise en page.
Kombai
Voici la réponse de Kombai :
Visuellement, celui-ci est extrêmement proche du template Figma. À part l'image hero qui est légèrement décalée par rapport au design Figma, je ne vois aucune autre différence. On a vraiment l'impression que le design a été copié-collé exactement.
Remarquez que la police, les images et les icônes sont exactement les mêmes, ce qui est pour moi incroyable.
Vous pouvez trouver le code généré ici.
Voici les points spécifiques qu'il gère mieux dans cet exemple simple.
- Il reflète la typographie et les couleurs Figma comme de véritables tokens
Kombai configure globals.css avec des tokens de type Figma et définit même des classes utilitaires pour les styles de texte :
:root {
/* ... */
}
@theme inline {
/* ... */
}
@utility text-heading-large {
/* ... */
}
@utility text-subtitle {
/* ... */
}
C'est très similaire à la façon dont un designer configurerait les styles dans Figma, et cela signifie que vous pouvez réutiliser ces utilitaires dans de nouveaux écrans au lieu de retaper les tailles de police Tailwind partout.
- Les composants sont plus propres et plus réutilisables
Tous les autres composants, comme Hero ou certains petits composants de boutons, utilisent les mêmes styles configurés dans styles.css.
const baseClasses =
"text-button px-6 py-3 rounded-sm transition-all hover:opacity-90";
const variantClasses =
variant === "primary"
? "bg-(--primary-yellow) text-(--foreground)"
: "bg-transparent border-2 border-(--foreground) text-(--foreground) hover:bg-(--foreground) hover:text-white";
Le pied de page (footer) place chaque icône dans son propre composant :
import InstagramIcon from "./icons/InstagramIcon";
import LinkedInIcon from "./icons/LinkedInIcon";
import MailIcon from "./icons/MailIcon";
En pratique, cela signifie que si le designer remplace l'icône de mail ou ajuste sa taille, il n'y a qu'un seul endroit à mettre à jour.
Ainsi, pour ce test simple, le résultat de Kombai est à la fois plus proche du design visuel et un peu mieux structuré pour un projet réel. J'ajusterais encore le nommage et quelques détails mineurs, mais je garderais volontiers la majeure partie de ce code tel quel. C'est assez fou, non ?
Test 2 : Tableau de bord d'apprentissage complexe
Pour le second test, créons un design légèrement plus complexe avec beaucoup d'éléments dans l'UI.
Vous pouvez trouver le template de design Figma ici : Learning Dashboard
Figma MCP
Voici la réponse de Figma MCP :
C'est bien, compte tenu de la complexité du design. Il est capable de mettre toutes les images et les ressources en place. C'est bien mieux que ce à quoi je m'attendais. Mais il y a une légère incohérence dans le placement des images entre le design original et l'implémentation, comme vous pouvez le voir par vous-même.
Si je compare le temps, cela a été fait super rapidement, en seulement 8 minutes, alors que Kombai a mis plus de 15 minutes pour y arriver (mais avec un meilleur résultat).
Vous pouvez trouver le code généré ici.
Voici ce que j'aime et ce que je n'aime pas dans ce qui a été fait ici :
- Excellents petits composants, mais tout reste très centré sur la page
Il divise bien les choses en composants logiques comme Sidebar, Input, Button, StatCard, CourseCard et Icons. La page principale les assemble ensuite :
export default function Home() {
const mentors = [
{
id: 1,
name: "John Doe",
subject: "UI/UX Design",
color: "bg-purple-500",
},
// ...
];
return (
<div className="flex items-center gap-8 w-full max-w-[1440px] h-[933px] bg-white rounded-[20px] mx-auto overflow-hidden">
{/* Sidebar */}
<Sidebar />
{/* Main content */}
<main className="flex flex-col items-center gap-6 pt-5 pb-0 flex-1 h-full overflow-hidden">
{/* Search, hero, cards, mentor table */}
</main>
</div>
);
}
La séparation en composants est agréable, mais tout est encore câblé directement à l'intérieur d'un seul grand composant de page avec des données fictives (mock data) en ligne. Pour une application réelle, je voudrais que ces données soient dans leur propre module, idéalement typées, afin qu'elles ne soient pas mélangées à la logique de mise en page.
- Dimensions codées en dur liées à la frame originale
Le conteneur extérieur est fixé à une hauteur spécifique :
<div className="flex items-center gap-8 w-full max-w-[1440px] h-[933px] bg-white rounded-[20px] mx-auto overflow-hidden">
C'est correct si vous recréez littéralement une frame de 1440 par 933 pour une capture d'écran, mais dans une application réelle, cela signifie :
Vous obtenez des espaces vides bizarres sur les écrans plus hauts.
Tout ce qui s'étend verticalement (titres de cours plus longs, plus de mentors) va soit déborder, soit être coupé.
La bannière hero présente le même type de positionnement au pixel près :
<div className="relative w-full h-[181px] bg-primary rounded-[20px] overflow-hidden">
<Image
src="/images/star1.svg"
alt="Star"
width={80}
height={80}
className="absolute top-[45px] left/[683px] opacity-25"
/>
{/* four more star images with fixed top/left */}
</div>
C'est parfait pour correspondre au design Figma spécifique, mais dès que la largeur change, ces positions ne s'alignent plus parfaitement.
Globalement, je dirais que ce résultat est étonnamment bon pour un seul prompt, mais un peu rigide et typé "template" dès que l'on commence à penser aux données réelles et à l'utilisation en production.
Kombai
Voici la réponse de Kombai :
Vous verrez dans la vidéo que j'ai dû corriger une petite erreur avec un prompt supplémentaire, mais après cela, il a produit un tableau de bord entièrement fonctionnel. La correspondance visuelle est très forte, compte tenu de la complexité de la mise en page.
Vous pouvez trouver le code généré ici.
Voici ce qui se démarque par rapport au résultat du MCP.
- Il traite le fichier Figma comme un produit réel, pas seulement comme un écran statique.
Au lieu de tout câbler dans une seule page avec des tableaux en ligne, Kombai crée des types de domaine appropriés et un fichier mock-data.ts :
import { UserProfile, Friend, Course, ProgressCard, Mentor } from "./types";
export const courses: Course[] = [
{
id: "1",
title: "Beginner's Guide to becoming a professional frontend developer",
category: "Frontend",
thumbnail: "/images/course-coding.jpg",
instructor: {
name: "Prashant Kumar singh",
role: "software Developer",
avatar: "/images/avatar-prashant.jpg",
},
},
// ...
];
Cela ressemble beaucoup plus à ce que l'on attendrait dans une base de code de production : des types clairs, des données séparées de la mise en page, et un composant de page qui se contente de tout assembler.
- Meilleur mapping des petits éléments d'UI
La carte de cours est similaire à celle du MCP, mais elle est maintenant entièrement pilotée par un objet Course :
export function CourseCard({ course }: { course: Course }) {
return (
<div className="flex flex-col gap-2.5 rounded-[20px] bg-white shadow-[0px_14px_42px_rgba(8,15,52,0.06)] overflow-hidden min-w-[268px]">
<div className="relative">
<Image
src={course.thumbnail}
alt={course.title}
width={244}
height={113}
className="w-full h-28 object-cover rounded-t-xl"
/>
<button className="absolute top-3 right-3 w-2 h-2 bg-white rounded-full" />
</div>
<div className="px-3 pb-4 flex flex-col gap-2.5">
<span className="text-[8px] font-normal uppercase text-primary px-3 py-1 bg-purple-50 rounded w-fit">
{course.category}
</span>
<p className="text-[14px] font-medium text-text-primary leading-tight">
{course.title}
</p>
<div className="w-full h-1.5 bg-gray-100 rounded-full overflow-hidden">
<div
className="h-full bg-primary rounded-full"
style={{ width: "60%" }}
/>
</div>
{/* instructor avatar and name */}
</div>
</div>
);
}
La structure et les styles de texte sont très proches du design original, et parce que la carte est entièrement basée sur les données, vous pouvez brancher des données réelles sans toucher au JSX.
- À nouveau, tokens de design et utilitaires de typographie
Comme dans l'exemple du portfolio, Kombai configure une couche de tokens appropriée pour le tableau de bord :
:root {
/* ... */
}
@utility heading-section {
/* ... */
}
@utility text-caption {
/* ... */
}
Les composants réutilisent ensuite ces utilitaires, ce qui maintient le code proche du design system au lieu de disperser les tailles de police et les couleurs partout.
- Choses que j'ajusterais encore
Ce n'est pas parfait :
Le fichier
layout.tsxde Next utilise toujours les polices Geist par défaut et les métadonnées "Create Next App", il faudrait donc aligner cela avec la police Inter et un vrai titre d'application.Certaines données fictives ont une casse incohérente dans les noms et les rôles, ce qu'il faudrait nettoyer dans un projet réel.
Le bouton de lecture sur la carte de cours n'est pour l'instant qu'un bouton point blanc, il faudrait donc y insérer la véritable icône.
Mais même avec ces problèmes, c'est très proche de quelque chose que je garderais réellement dans un repo de production après une passe rapide.
Ici, ce n'est pas aussi parfait que l'implémentation précédente de Kombai, et il y a eu des erreurs. Mais compte tenu de la complexité de ce design, avec de multiples cartes différentes contenant des images et tout le reste, c'est quand même vraiment impressionnant pour moi.
Pour celui-ci, le codage a pris un peu plus de temps, mais à mon avis, ce temps supplémentaire en valait la peine.
Imaginez que vous construisiez quelque chose de similaire et que vous obteniez déjà une réponse aussi bonne. Il n'est alors pas si difficile d'itérer un peu, n'est-ce pas ? Vous n'avez pas à partir de zéro. Faites juste quelques changements si nécessaire, et c'est fini.
Ce que vous devez savoir avant d'utiliser ces outils
Aussi performants que soient ces outils, on ne peut pas leur faire confiance aveuglément. Ils vous permettront de prendre un bon départ, mais vous devrez toujours ajuster quelques éléments avant de considérer le résultat comme prêt pour la production.
Kombai fait un excellent travail pour cloner les designs Figma et écrire un code propre et modulaire. Il divise les composants en fichiers plus petits et suit généralement une bonne structure.
Le seul problème que j'ai remarqué est qu'il fait parfois des erreurs sur les conventions de nommage. Comme il scanne l'intégralité de votre base de code pour rester cohérent avec votre configuration, il peut être un peu plus lent à générer du code, mais c'est aussi ce qui le rend plus intelligent. Vous n'obtenez pas seulement un cloneur Figma, vous obtenez un assistant qui comprend réellement votre front-end.
Figma MCP est rapide et fait un travail décent pour correspondre à l'UI, bien que les résultats dépendent beaucoup du modèle que vous utilisez pour la génération. Si votre objectif principal est de cloner des designs Figma rapidement et que cela ne vous dérange pas d'affiner le résultat, c'est une bonne option.
En résumé, les deux outils peuvent vous faire gagner énormément de temps, mais ils ne remplacent pas un flux de travail front-end "clés en main". Traitez-les comme faisant partie de votre boîte à outils, et vous obtiendrez les meilleurs résultats.
Verdict final et quelles sont les prochaines étapes ?
Maintenant que vous avez une idée de ce que ces outils peuvent faire, n'hésitez pas à les essayer. Vous pouvez transformer vos designs Figma en front-ends fonctionnels en quelques minutes sans avoir à jouer sans fin avec le CSS.
Pour résumer, voici un aperçu rapide :
Si vous voulez un code prêt pour la production qui ressemble réellement à votre design Figma et que vous travaillez principalement dans VS Code, Cursor ou n'importe quel IDE avec interface graphique, choisissez Kombai. Il soigne les détails et comprend même votre base de code, ce qui manque complètement à Figma MCP.
Si vous voulez simplement cloner un design Figma rapidement et que cela ne vous dérange pas si les choses sont légèrement décalées, Figma MCP est tout à fait correct. Il fait plutôt bien le travail.
En gros, choisissez Kombai si vous vous souciez de la précision et de la qualité du code avec une compréhension de la base de code.
Choisissez Figma MCP si vous voulez quelque chose de rapide, qui fonctionne et qui a l'air assez décent. 🤷♂️
Conclusion
Alors, qu'en pensez-vous ? Plutôt cool, non ? C'était une petite expérience amusante pour voir à quel point des outils comme Figma MCP et Kombai peuvent se rapprocher du clonage de front-ends réels directement depuis Figma.
Si vous aimez construire des front-ends et que vous voulez vous épargner quelques heures de souffrance CSS, essayez-les sans hésiter. Ne vous attendez pas à ce qu'ils soient parfaits du premier coup – leur résultat nécessite toujours une révision et probablement un peu d'affinage.
C'est tout pour celui-ci. Merci de m'avoir lu ! ✌️