Figma Make en 2026 : comment passer du design à un prototype fonctionnel et au code

Figma Make a transformé le passage d’une interface conçue dans Figma à un produit que les utilisateurs peuvent réellement manipuler, tester et évaluer. En 2026, l’outil peut partir d’un brief rédigé, d’une frame Figma existante ou d’un mélange de références visuelles et de contexte de projet, puis générer un prototype fonctionnel ou une application web avec des interactions opérationnelles et du code modifiable. Cela ne supprime pas la nécessité d’un jugement de designer ni d’une vérification par les développeurs, mais réduit considérablement la distance entre un concept statique et une version fonctionnelle. La meilleure façon d’utiliser Make consiste donc non pas à le considérer comme un substitut automatique au travail produit, mais comme un environnement rapide permettant de transformer une intention de design claire en comportements concrets, de les vérifier plus tôt et de transmettre aux développeurs un résultat beaucoup plus précis. Le processus fonctionne particulièrement bien lorsque le design source est bien organisé, que le brief est précis et que chaque série de modifications répond à un objectif clairement défini.

Ce que Figma Make peut réellement faire en 2026

Figma Make repose sur une interface conversationnelle alimentée par l’IA qui génère du code pour créer des prototypes fonctionnels, des applications web et des interfaces interactives. Un projet peut commencer par une simple instruction en langage naturel, mais le meilleur point de départ consiste généralement à combiner du texte avec un contexte visuel. Il est possible de joindre des designs Figma, de coller directement des frames dans la conversation, d’utiliser les styles issus de bibliothèques publiées avec les abonnements payants compatibles et d’ajouter du contexte externe par l’intermédiaire de connecteurs MCP pris en charge. Figma propose également un mode de planification aux utilisateurs éligibles, qui prépare un plan de construction structuré avant la génération du code. Cette option est utile pour les produits comportant plusieurs écrans, car elle permet de corriger le parcours envisagé avant de lancer une génération importante. L’objectif est simple : fournir à Make suffisamment d’informations pour comprendre non seulement l’apparence d’un écran, mais également le rôle de chaque commande importante et la manière dont les différents états doivent s’enchaîner.

Le résultat généré dépasse le cadre d’une simple maquette cliquable. Make produit le code associé à l’expérience et affiche un aperçu interactif lorsque la génération est terminée. Il est ensuite possible de poursuivre la conversation, de modifier directement l’interface affichée, d’intervenir dans le code ou de revenir à une version précédente. Cette flexibilité est importante, car la première génération doit rarement être considérée comme définitive. Une fiche produit peut sembler correcte tout en se comportant mal sur une largeur d’écran réduite, un champ de recherche peut manquer d’état vide, ou une fenêtre modale peut s’ouvrir correctement sans restituer le focus au contrôle qui l’a déclenchée. Make apporte le plus de valeur lorsque ces problèmes sont traités comme une partie normale du processus d’itération plutôt que comme la preuve que le premier prompt a échoué. Dans un projet réel, la version générée doit être considérée comme une base testable que l’on affine avec le même niveau d’attention qu’un prototype classique.

Le choix du modèle est également devenu plus important en 2026. Figma a ajouté GPT-5.6 au sélecteur de modèles de Make en juillet, avec notamment l’objectif d’améliorer la qualité des premières propositions d’interface, des mises en page responsives et des interactions. Le modèle ne constitue toutefois qu’une partie de l’équation. La qualité des informations fournies continue d’avoir un impact direct sur le résultat. Une instruction courte comme « rendez cet écran interactif » laisse trop de décisions ouvertes. Il est préférable de préciser l’action de l’utilisateur, la réponse attendue, la modification visible de l’état et les éventuelles limites. Par exemple, un designer peut indiquer que la sélection d’un filtre produit doit mettre à jour le nombre de résultats, afficher clairement le filtre actif, conserver l’ordre de tri actuel et proposer une méthode évidente pour réinitialiser la sélection. Ce niveau de précision fournit au prototype généré un comportement concret à mettre en œuvre et, surtout, des critères précis à vérifier.

Partir d’un design existant plutôt que d’un prompt vide

L’un des usages les plus intéressants de Figma Make consiste à transformer une frame Figma Design existante en expérience fonctionnelle sans devoir reconstruire l’interface depuis zéro. Figma recommande d’utiliser des frames structurées plutôt que de se limiter à des captures d’écran, car les frames contiennent des informations qu’une image seule ne permet pas toujours d’interpréter correctement, notamment les relations entre les éléments et la structure de la mise en page. L’Auto Layout est particulièrement utile, puisqu’il aide Make à comprendre comment les composants doivent se redimensionner et se réorganiser. Pour une fonctionnalité limitée, il suffit généralement de joindre la frame concernée et de décrire le comportement attendu. Pour un produit plus complexe, il est préférable de travailler écran par écran ou avec un petit nombre de designs à la fois. Le contexte reste ainsi ciblé et il devient plus facile de repérer les situations où le résultat généré interprète mal un parcours, duplique un composant ou ajoute une logique qui ne figurait pas dans le design d’origine.

Les Make kits ajoutent une couche supplémentaire de cohérence pour les équipes qui disposent déjà d’un design system. Un kit peut inclure des packages npm servant de contexte pour le code, des variables et styles provenant de bibliothèques Figma Design publiées, ainsi que des consignes écrites expliquant comment utiliser les composants, les tokens et les différents modèles d’interface. L’avantage pratique est que le prototype généré peut se rapprocher immédiatement du produit réel au lieu d’inventer un nouveau langage visuel pour chaque expérimentation. Cette approche est particulièrement utile pour les éléments récurrents tels que les boutons, les champs de formulaire, les cartes, les espacements ou la typographie. Le designer doit toujours contrôler le résultat, mais le nombre de corrections peut être réduit lorsque Make reçoit le même vocabulaire visuel que celui déjà utilisé par l’équipe. Pour les organisations qui créent régulièrement des prototypes, un kit bien entretenu permet également d’éviter de répéter les mêmes règles graphiques dans chaque nouvelle conversation.

Les pièces jointes peuvent transmettre davantage que de simples références visuelles. En 2026, Figma a introduit les pièces jointes Make afin qu’un prototype puisse utiliser du contenu, des données et des contraintes propres au projet. Un prototype d’espace client peut ainsi être construit avec du contenu réaliste plutôt qu’avec du texte de remplissage, tandis qu’une interface riche en informations peut être organisée en fonction des types de données qu’elle devra réellement afficher. Le principe essentiel consiste à ne joindre que les éléments susceptibles d’influencer le résultat. Un fichier de consignes concis, une référence de composant réelle et un petit ensemble de données représentatives sont généralement plus utiles qu’un grand volume de documents vaguement liés au projet. Les informations sensibles ne doivent pas être insérées dans la conversation. Les recommandations de Figma précisent notamment qu’il faut éviter d’inclure des clés API, des données personnelles, des adresses ou d’autres secrets dans les prompts ; la gestion sécurisée de ces données doit rester dans le backend ou dans une autre partie contrôlée de l’implémentation.

Construire un prototype fonctionnel étape par étape

Le flux de travail Figma Make le plus fiable commence par la mise en page et le parcours utilisateur avant d’ajouter toutes les interactions avancées. Il faut d’abord joindre ou coller le design principal, puis expliquer l’objectif de l’écran, son utilisateur et le résultat attendu. Ensuite, il convient de définir les actions principales avec des termes simples. Pour un prototype de paiement, par exemple, il vaut mieux éviter de commencer par une longue instruction couvrant toutes les méthodes de paiement, toutes les animations et tous les scénarios de validation possibles. Il est plus efficace de construire d’abord le parcours principal : choisir une méthode de livraison, saisir les coordonnées, passer au paiement et confirmer la commande. Lorsque ce chemin fonctionne correctement, les états supplémentaires peuvent être ajoutés un par un. Cette méthode progressive correspond également aux recommandations de Figma, qui conseille de traiter d’abord la structure, puis les fonctionnalités, et de diviser les projets complexes en étapes plus petites. Les erreurs deviennent alors plus simples à identifier, car chaque modification possède une cause clairement identifiable.

Un bon prompt doit réunir la tâche, le contexte et les contraintes. La tâche indique à Make ce qui doit être construit, le contexte explique la situation du produit et de l’utilisateur, tandis que les contraintes empêchent certaines suppositions indésirables. Pour transformer un tableau de bord, par exemple, il est possible d’indiquer que la frame desktop existante constitue la référence visuelle, que le tableau doit rester lisible sur des écrans plus étroits, que les filtres doivent mettre à jour les lignes visibles et qu’aucun nouvel élément de navigation ne doit être ajouté. Cette méthode est beaucoup plus utile qu’une longue accumulation d’adjectifs décrivant l’esthétique souhaitée. Elle fournit également une liste de contrôle simple après la génération. Le tableau s’adapte-t-il comme prévu ? Les filtres fonctionnent-ils ? L’architecture de l’information a-t-elle été conservée ? Make a-t-il ajouté des éléments qui n’étaient pas demandés ? Plus le brief est précis, plus il devient facile d’évaluer le résultat sur des critères concrets.

Pour les projets plus importants, le mode de planification permet de réduire les générations inutiles. Avant d’écrire le code, Make peut produire un plan structuré que l’utilisateur examine et ajuste. Cette fonction est intéressante lorsqu’une fonctionnalité comporte plusieurs écrans, dépendances ou états de données, car l’erreur la plus coûteuse n’est souvent pas une mauvaise couleur ou un espacement incorrect, mais une mauvaise compréhension du parcours produit. Le plan peut révéler que le modèle prévoit d’ajouter une étape de compte supplémentaire, de traiter un filtre comme un élément de navigation ou de fusionner deux états qui doivent rester distincts. Corriger ce type d’erreur en amont est beaucoup plus simple que d’essayer de la réparer une fois qu’elle s’est propagée dans le code. Une fois le plan validé, la génération dispose d’un objectif plus précis. Le résultat peut encore nécessiter des ajustements, mais le travail commence sur une structure vérifiée plutôt que sur un long prompt jamais réellement testé comme spécification.

Affiner les interactions sans tout reconstruire

Les outils d’édition de Figma Make en 2026 sont conçus pour rendre les petites modifications plus précises. Dans les nouveaux fichiers Make, le panneau des propriétés permet de sélectionner un élément et d’ajuster des paramètres visuels familiers tels que l’espacement, la typographie, la mise en page, l’opacité, les bordures et d’autres propriétés associées. Les modifications sont préparées avant leur application, ce qui permet de vérifier les changements prévus sans valider immédiatement chaque ajustement. Cette méthode est souvent préférable à un prompt général comme « rendez cette carte plus compacte », qui pourrait conduire le modèle à modifier plusieurs parties sans rapport direct avec la demande. L’édition ciblée donne à Make un objectif beaucoup plus précis. Elle est particulièrement utile dans les dernières étapes, lorsque la structure générale est correcte et que les ajustements concernent surtout l’alignement, la hiérarchie visuelle, les dimensions des composants ou d’autres détails plus faciles à juger visuellement qu’à décrire dans un long texte.

Les annotations servent à gérer des modifications plus difficiles à exprimer uniquement avec des propriétés visuelles. Il est possible de sélectionner un ou plusieurs éléments directement dans l’aperçu et d’associer une instruction à ces emplacements précis. Un designer peut, par exemple, annoter une vignette afin de demander un léger zoom au survol, sélectionner le déclencheur d’un menu pour demander une superposition plein écran ou identifier plusieurs commandes qui doivent utiliser la même règle d’interaction. Puisque l’instruction est rattachée directement à l’élément concerné, Make dispose de moins de marge pour interpréter incorrectement la zone à modifier. Cette fonction devient particulièrement intéressante dans les écrans denses où plusieurs boutons ou composants répétés possèdent des libellés similaires. Plutôt que d’envoyer une nouvelle instruction concernant tout l’écran, il suffit de désigner précisément la cible, de décrire le comportement et d’examiner le résultat. Figma indique que les modifications appliquées depuis le panneau des propriétés et les annotations utilisent des crédits d’IA.

L’historique des versions et l’édition directe du code offrent deux autres moyens de mieux contrôler les itérations. Lorsqu’un prompt améliore une partie du prototype mais en détériore une autre, revenir à une version précédente peut être plus rapide que de tenter de corriger une succession de modifications non souhaitées. L’édition directe du code est utile lorsqu’un développeur ou un designer à l’aise avec le code peut identifier et corriger un petit problème plus rapidement dans la source qu’en rédigeant une nouvelle instruction à l’IA. L’essentiel consiste à choisir la méthode d’édition adaptée au problème rencontré. Le panneau des propriétés convient aux changements visuels précis, les annotations aux comportements liés à un emplacement spécifique, les prompts aux évolutions plus générales du produit et le code aux ajustements qu’il est plus simple d’exprimer directement. Cette approche évite d’utiliser la conversation pour chaque changement, même lorsqu’un outil plus précis est disponible. Elle permet aussi d’économiser des crédits en limitant les générations inutiles.

Du prototype au code modifiable et à la mise en ligne

Une fois le prototype fonctionnel, Figma Make propose plusieurs possibilités pour poursuivre le travail. Le code généré peut être consulté et modifié directement dans le fichier Make, et les projets peuvent également être envoyés vers GitHub. L’intégration GitHub actuelle de Figma permet de créer un dépôt pour un fichier Make et d’y envoyer ensuite les nouvelles versions du projet. Il est important de comprendre les limites de ce fonctionnement : dans le processus standard, l’envoi s’effectue dans un seul sens, de Make vers GitHub, et les modifications réalisées ensuite dans GitHub ne sont pas automatiquement réimportées dans Make. Figma indique également que Make envoie le projet vers le dépôt créé pour ce fichier plutôt que vers n’importe quel dépôt existant. Pour une équipe, GitHub peut donc servir de point de transmission, de sauvegarde et de continuation du développement, mais il ne faut pas considérer cette intégration comme un système complet de synchronisation bidirectionnelle. Une fois que les développeurs commencent à travailler en dehors de Make, la responsabilité du code et le processus de développement doivent rester clairement définis.

Figma teste également depuis 2026 un fonctionnement plus étroitement lié au code de production. La version bêta limitée annoncée en mai permet à certains utilisateurs éligibles de connecter une véritable base de code, de créer une branche, d’effectuer des modifications visuelles ou basées sur des prompts directement à partir de ce code, d’examiner les commits et de poursuivre le travail jusqu’à la création d’une pull request. Ce scénario est différent de l’envoi classique d’un projet Make autonome vers un nouveau dépôt GitHub. Il rapproche le designer du code réellement utilisé en production et peut révéler des dépendances qu’un design statique ne montre pas, par exemple lorsqu’un composant partagé est employé sur plusieurs écrans. L’accès à cette fonction reste cependant limité pendant la phase bêta, et Figma l’avait initialement réservée à certains utilisateurs de l’application desktop Beta sur Mac. Les équipes doivent donc vérifier les conditions d’accès actuelles avant d’organiser leur processus de travail autour de cette fonction plutôt que de supposer qu’elle est disponible pour tous les comptes.

Lorsqu’un prototype doit surtout être partagé publiquement plutôt que transmis immédiatement aux développeurs, Make peut publier un prototype fonctionnel ou une application web sur Internet avec sa propre URL. Le contenu publié peut être mis à jour ultérieurement, retiré lorsqu’il n’est plus nécessaire et associé à un domaine personnalisé lorsque l’abonnement le permet. Cette option est utile pour des sessions de test utilisateur, des présentations aux parties prenantes, des démonstrations commerciales ou des essais contrôlés dans lesquels les participants doivent disposer d’un lien fonctionnel sans accéder au fichier de design. La publication ne signifie toutefois pas que le code généré est automatiquement prêt pour la production. Avant toute mise en ligne publique, l’équipe doit encore vérifier les droits liés au contenu, le traitement des données, l’accessibilité, les performances, le comportement responsive et les éventuels services externes utilisés. Une démonstration convaincante peut masquer une mauvaise gestion des erreurs ou des hypothèses irréalistes concernant les données ; la vérification finale doit donc également examiner ce qui se passe en dehors du scénario idéal.

Les domaines où Figma Make nécessite toujours une vérification humaine

La principale limite de Figma Make ressemble à celle de nombreux outils de développement assistés par l’IA : un résultat crédible peut donner l’impression d’être terminé avant d’avoir été correctement contrôlé. Un bouton peut fonctionner dans le scénario principal mais échouer avec un libellé très long, la navigation au clavier peut rester incomplète, une mise en page mobile peut nécessiter davantage d’attention que sa version desktop, ou le contenu généré peut ne pas respecter certaines exigences juridiques ou éditoriales. Les recommandations actuelles de Figma indiquent que les résultats desktop et plein écran restent parfois plus solides que les rendus mobiles, ce qui rend indispensable une vérification volontaire du comportement responsive. Les designers doivent tester la mise en page sur des largeurs réalistes, l’expansion du texte, les états de focus, le chargement, les états vides, les erreurs et les contenus répétés. Les développeurs doivent examiner la structure du code, les dépendances et les implications en matière de sécurité. Le prototype devient réellement utile lorsqu’il permet de faire apparaître ces questions plus tôt, et non lorsqu’il est considéré comme une preuve qu’elles n’ont plus besoin d’être posées.

Il existe également une différence importante entre du code généré que l’on peut modifier et du code qu’une équipe souhaite maintenir pendant plusieurs années. Make peut constituer un excellent point de départ, notamment lorsqu’il dispose d’un contexte de design précis, d’un prompt clair et des bonnes règles de composants. Le code destiné à la production doit néanmoins s’intégrer à l’architecture du projet, aux normes de test, aux pratiques de sécurité, aux conventions de nommage et au processus de mise en production. Si une équipe possède déjà des composants partagés, une version générée séparément peut créer des doublons inutiles. Si l’application repose sur une authentification, des API privées ou des données réglementées, l’implémentation doit faire l’objet d’une vérification spécialisée avant d’être utilisée par de véritables utilisateurs. La transmission la plus raisonnable n’est donc pas « l’IA a écrit le code, nous pouvons le publier », mais plutôt « le comportement est désormais concret, le code existe et l’équipe peut examiner une proposition beaucoup plus précise ». Cette évolution réduit fortement l’ambiguïté sans faire disparaître la responsabilité des développeurs.

Le meilleur flux de travail avec Figma Make en 2026 prend donc la forme d’une boucle plutôt que d’un passage direct entre une frame et un produit terminé. Il faut commencer avec un design correctement structuré ou un brief clair, fournir suffisamment de contexte à Make pour préserver le système envisagé, générer la plus petite partie réellement utile, la tester, puis l’affiner avec la méthode d’édition la plus précise disponible. Les Make kits sont pertinents lorsque la cohérence est essentielle, les pièces jointes lorsque le contenu réel ou certaines contraintes modifient le comportement, tandis que GitHub ou la version bêta liée au code de production doivent intervenir lorsque le résultat est prêt à être examiné par les développeurs. Pour un prototype public, la publication doit intervenir uniquement après vérification des droits, de la confidentialité et des différents cas limites. Utilisé de cette manière, Figma Make permet de transformer l’intention de design en expérience testable beaucoup plus tôt dans le processus. Sa véritable valeur ne réside pas dans la disparition du travail entre le design et le code, mais dans la possibilité de rendre ce travail visible plus tôt, sous une forme que designers, responsables produit et développeurs peuvent tous examiner.