Figma ne sert plus seulement à dessiner votre application : il commence à produire le code et les écrans fonctionnels

Figma ne veut plus s’arrêter au moment où la maquette est validée. Avec Figma Make, l’entreprise permet déjà de transformer une description ou un écran Figma en prototype interactif, puis d’y ajouter une authentification, des données et un déploiement Web. Une bêta plus récente va encore plus loin : elle peut travailler dans une base de code locale, modifier visuellement l’interface et préparer les changements pour une revue par les développeurs.

La frontière entre outil de design et constructeur d’applications devient donc beaucoup moins nette. Cela ne signifie pas pour autant que Figma remplace automatiquement Lovable, Bolt, Replit Agent ou une équipe de développement. La vraie comparaison commence après la jolie première génération, lorsque le projet doit supporter vingt demandes de modification, des utilisateurs réels et six mois de maintenance.

Ce que Figma Make produit réellement

Figma Make est un outil de génération d’interface et d’application Web piloté par des instructions. On peut partir d’une idée écrite, d’une maquette existante ou de composants issus d’un système de design. L’outil produit du code, affiche un aperçu fonctionnel et permet de demander des corrections dans la conversation.

Il ne se limite plus à simuler des clics entre des écrans. Figma documente une intégration à Supabase pour conserver des données, gérer des secrets et construire des parcours d’authentification. Il faut toutefois lire la limite : Make configure actuellement des magasins clés-valeurs simples dans PostgreSQL, pas nécessairement toute la structure SQL complexe qu’exigerait un SaaS mature.

Le projet peut être publié sur une adresse Web. Le domaine personnalisé dépend du forfait, et l’indexation par les moteurs n’est pas activée par défaut sur les applications publiées. Créer un site visible ne suffit donc pas à obtenir une page correctement indexable : titres, métadonnées, HTML sémantique, performances, pages publiques et règles d’exploration restent à contrôler.

L’évolution importante : modifier le vrai code depuis le design

Le changement le plus intéressant n’est pas seulement la génération d’un écran supplémentaire. Dans sa bêta de bureau annoncée en mai, Figma Make peut se connecter à une base de code de production locale. Le designer sélectionne un élément dans l’aperçu, change une couleur, une police, une dimension ou une disposition, puis l’agent retrouve le code concerné et applique la modification.

Pour un comportement plus complexe, il est possible d’annoter plusieurs éléments et de décrire l’interaction attendue. Figma prend également en charge des opérations Git : branche, historique de commits, retour à une version précédente et préparation d’une pull request. Le changement reste donc soumis au circuit de revue de l’équipe au lieu d’être injecté silencieusement en production.

Cette fonction n’est pas encore un bouton universel disponible à tous. Figma l’a présentée comme une bêta limitée, d’abord dans son application de bureau bêta sur Mac, avec accès sur sélection. Elle vise surtout les designers qui disposent déjà du code de leur entreprise. Il serait trompeur de la confondre avec le Figma Make standard accessible depuis un forfait payant.

Le même petit SaaS pour comparer cinq méthodes

Pour comparer correctement Figma Make, Lovable, Bolt, Replit Agent et un développement classique, il faut leur imposer exactement le même cahier des charges. Un gestionnaire de rendez-vous constitue un bon cas d’école : page d’accueil publique, création de compte, tableau de bord, base de données, formulaire de réservation, annulation, courriel de confirmation et espace administrateur.

Le protocole devrait aussi prévoir trois tailles d’écran, une page indexable, un domaine personnalisé et un export ou dépôt Git. Les vingt modifications doivent être définies avant le test : changer la couleur principale, ajouter un champ, modifier un rôle, renommer une table, déplacer une carte, gérer un état vide, corriger le menu mobile, ajouter une page tarifaire, puis revenir sur plusieurs décisions.

Cette méthode évite de favoriser l’outil qui produit la première page la plus spectaculaire. Elle mesure la capacité à comprendre l’existant, à limiter les régressions et à laisser derrière lui un projet qu’une autre personne peut reprendre.

Figma Make, Lovable, Bolt, Replit ou code classique : les différences

Ce tableau compare les capacités documentées, pas les résultats d’un test physique mené par Okibata. Les produits évoluent rapidement et leur qualité dépend du prompt, du modèle, du forfait et de la complexité du projet. Un futur comparatif devra publier le cahier des charges, les vingt demandes exactes, les erreurs observées et le coût final de chaque parcours.

Authentification et base de données : le premier filtre sérieux

Une page d’accueil réussie ne démontre presque rien sur la capacité à construire un SaaS. Le premier test consiste à créer deux comptes différents, vérifier que chacun ne voit que ses données, réinitialiser un mot de passe, supprimer un utilisateur et contrôler les droits de l’administrateur.

Figma Make s’appuie sur Supabase pour l’authentification, le stockage de secrets et la persistance. Lovable peut utiliser son environnement cloud ou Supabase. Bolt propose également des briques intégrées ou des services externes selon le projet. Replit Agent dispose d’une base PostgreSQL gérée et de solutions d’authentification intégrées, dont une option liée aux comptes Replit et une option personnalisable reposant sur Clerk.

Le développement classique demande davantage de configuration, mais permet de choisir précisément le fournisseur, le schéma de données, les migrations et la politique de sauvegarde. Dans tous les cas, il faut tester les autorisations côté serveur. Masquer un bouton dans l’interface ne protège pas une donnée.

Responsive : ne pas se contenter de réduire la fenêtre

Les générateurs savent produire une interface qui change de largeur. Cela ne garantit pas qu’elle reste utilisable. Le test doit couvrir le clavier d’un téléphone, les longs intitulés français, le zoom à 200 %, les tableaux trop larges, les menus, les formulaires et les messages d’erreur.

Figma Make possède un avantage naturel lorsque le système de design contient déjà des composants et des règles d’espacement bien définis. Mais un agent peut tout de même ajouter une valeur isolée, dupliquer un composant ou corriger un écran au détriment d’un autre. Après chaque changement, les trois tailles d’écran doivent être vérifiées de nouveau.

Export du code : la question n’est pas seulement « peut-on télécharger ? »

Posséder un dossier de fichiers ne garantit pas que le projet soit réellement portable. Il faut pouvoir l’installer sur une machine neuve, retrouver les variables d’environnement, recréer la base, exécuter les tests et déployer sans dépendre d’un bouton disparu.

Lovable documente une synchronisation bidirectionnelle avec GitHub et la possibilité de déployer ailleurs. Replit peut importer des dépôts et fournit un véritable environnement de développement. La bêta locale de Figma Make utilise branches et commits pour travailler dans une base existante. Pour Bolt, il faut vérifier au moment du test le dépôt, l’historique et la récupération complète des fichiers et secrets.

Le meilleur contrôle consiste à confier l’export à un développeur qui n’a pas participé à la génération. S’il lui faut une journée pour comprendre comment démarrer le projet, l’export existe juridiquement mais reste coûteux opérationnellement.

SEO : un domaine publié n’est pas une stratégie

Les constructeurs d’applications privilégient souvent les interfaces exécutées dans le navigateur. Pour un tableau de bord privé, ce choix est logique. Pour des pages qui doivent attirer des visiteurs depuis Google, il faut examiner le HTML envoyé, les titres, les descriptions, les balises canoniques, les données structurées, le sitemap, le fichier robots.txt et les performances.

Figma précise que ses applications publiées ne sont pas indexées par défaut. Cette protection est utile pour un prototype, mais devient un problème si l’on croit avoir lancé un site public optimisé. Une application monopage peut également rendre la création de nombreuses pages éditoriales moins naturelle qu’avec un CMS ou un framework conçu pour le rendu côté serveur.

Le même raisonnement vaut pour les autres outils. Une fonction « SEO » qui remplit automatiquement une description ne remplace ni l’architecture des contenus ni le contrôle technique. Pour un projet destiné à générer du trafic, le test doit inclure une exploration avec les outils des moteurs et une mesure des Core Web Vitals.

Combien coûtent réellement vingt modifications ?

Comparer uniquement les abonnements mensuels serait trompeur. Le coût réel additionne les crédits consommés par l’agent, l’hébergement, la base de données, le stockage, le domaine, les services de courriel et le temps humain passé à relire ou réparer le code.

Chaque modification devrait être chronométrée et classée : acceptée du premier coup, corrigée par une deuxième instruction, réparée manuellement ou annulée. Il faut également noter les régressions. Une demande facturée quelques centimes peut coûter cher si elle casse l’authentification et mobilise un développeur pendant deux heures.

Le test le plus révélateur consiste à reprendre le projet après une semaine sans conversation active. L’agent comprend-il encore l’architecture ? Respecte-t-il les composants existants ? Ajoute-t-il une nouvelle bibliothèque pour résoudre un problème déjà traité ailleurs ? Le coût de la vingtième modification est souvent plus instructif que celui de la première.

Quel outil choisir pour construire un petit SaaS ?

Figma Make est particulièrement intéressant lorsqu’une équipe possède déjà ses écrans, ses variables et son système de design dans Figma. Il rapproche la maquette du code et peut réduire les allers-retours sur l’interface. Sa bêta locale devient encore plus pertinente si les changements doivent passer par Git et une revue technique.

Lovable ou Bolt peuvent être plus directs pour un entrepreneur qui part d’une idée et veut rapidement obtenir un produit Web complet. Replit Agent prend l’avantage lorsque l’on souhaite travailler dans un environnement de développement intégré avec frontend, backend et déploiement. Le développement classique reste le choix le plus contrôlable lorsque la sécurité, les performances, l’architecture ou la durée de vie du produit priment sur la vitesse de la première démonstration.

Pour trouver un sujet suffisamment étroit avant de choisir l’outil, notre sélection de 15 idées de micro-SaaS inspirées de problèmes réels fournit des scénarios concrets. Le fonctionnement de Figma Make rappelle aussi une évolution déjà visible dans la 3D : Pascal Editor permet à une IA de manipuler une scène architecturale structurée, et non plus seulement de générer une image.

Figma devient-il vraiment un constructeur d’applications ?

Oui, progressivement. Figma Make produit déjà des interfaces fonctionnelles, peut connecter un backend, publier une application et, dans sa bêta la plus ambitieuse, modifier du code local avec un workflow Git. Ce n’est plus seulement un outil de dessin.

Mais l’expression « constructeur d’applications » ne doit pas masquer le reste du travail. Une application durable exige une architecture, des droits d’accès, des sauvegardes, des tests, un suivi des erreurs, un SEO adapté et une personne capable d’intervenir lorsque l’agent ne comprend plus le projet.

Le gagnant ne sera donc pas nécessairement celui qui génère le plus beau tableau de bord en cinq minutes. Ce sera celui qui permet encore à une équipe de corriger proprement ce tableau de bord six mois, vingt changements et plusieurs utilisateurs plus tard.