Figma Make veut rapprocher design et code pour accélérer le prototype produit

Une maquette réussie ne suffit pas toujours à expliquer comment une application réagira lorsqu’une personne clique, saisit une information ou change de parcours. Entre l’idée dessinée dans un outil de conception et le produit effectivement développé, les équipes doivent habituellement franchir plusieurs étapes, souvent réparties entre designers, product managers et développeurs. Figma Make, lancé en 2025, entend raccourcir cette distance en transformant plus directement des intentions de conception en prototypes interactifs.

L’ambition n’est pas seulement de produire une démo visuelle plus vite. Figma Make veut installer un espace commun où une interface, des instructions en langage naturel, des règles de produit et des composants de design system peuvent servir de point de départ à une expérience manipulable. Depuis sa sortie de bêta en juillet 2025, l’outil suscite un intérêt croissant, en particulier chez les designers et les responsables produit qui veulent tester une idée sans attendre la construction complète de l’application.

Figma Make, un outil pour passer de la maquette à l’expérience interactive

Figma Make est un outil de prototypage assisté par IA intégré à l’écosystème de Figma. Son principe est simple à énoncer : un utilisateur peut formuler une demande, apporter des éléments de design existants, puis obtenir une première version interactive de l’interface envisagée. Cette version peut ensuite être modifiée, partagée et utilisée pour discuter d’un parcours avec les autres membres d’une équipe.

L’interactivité fait ici la différence avec une maquette statique. Dans le travail produit, une suite d’écrans est utile pour présenter une direction graphique, mais elle ne restitue pas nécessairement les états d’une interface, les enchaînements entre les pages ni les réactions attendues après une action. Un prototype permet justement d’éprouver ces choix plus tôt : navigation, structure d’un formulaire, ordre des informations, compréhension d’un appel à l’action ou cohérence d’un parcours.

Figma Make ne se présente donc pas comme un simple générateur de code. L’enjeu est plutôt de faire émerger rapidement un objet de discussion concret, situé entre la maquette et une application plus fonctionnelle. Cela peut modifier la façon dont une équipe formule ses décisions : au lieu de débattre longuement d’un comportement hypothétique, elle peut examiner une version interactive et l’ajuster.

Comment une frame Figma devient-elle un prototype ?

L’un des usages mis en avant par Figma repose sur la continuité avec Figma Design, l’outil de conception déjà employé par de nombreuses équipes. Un utilisateur peut copier une frame, c’est-à-dire un écran ou un ensemble d’éléments de l’interface, et la coller dans Make. Cette opération fournit une base à partir de laquelle l’outil peut produire une première version interactive en quelques clics.

Ce passage est important parce qu’il évite de recommencer à zéro dans un environnement distinct. Le designer garde ses repères graphiques, tandis que le product manager peut préciser le comportement recherché et que le développeur peut mieux comprendre l’intention. Dans les organisations où les responsabilités sont séparées, la perte d’informations survient fréquemment au moment de transmettre une maquette à une autre équipe. Un même espace de travail peut réduire ces allers-retours, sans les faire disparaître complètement.

L’IA est particulièrement utile pour donner une forme initiale à une demande formulée en langage naturel. Elle peut accélérer l’exploration de variantes et rendre l’étape du prototype accessible à des personnes qui ne programment pas quotidiennement. Mais cette facilité d’entrée ne dispense pas de décrire clairement l’objectif. Un résultat pertinent dépend toujours du contexte fourni : ce que doit faire l’écran, pour qui, dans quel enchaînement et avec quelles contraintes.

Le prototype devient alors un support de collaboration. Il peut être montré lors d’une revue produit, servir de base à un test utilisateur ou aider à comparer plusieurs options avant qu’une équipe de développement ne consacre du temps à l’implémentation.

Les templates, une brique pour industrialiser les bonnes pratiques

Depuis le printemps 2025, les templates constituent l’une des fonctionnalités centrales de Figma Make. Leur intérêt dépasse le simple gain de temps. Un membre d’une équipe peut créer un prototype, le publier, puis le rendre disponible à l’ensemble de l’organisation. D’autres personnes peuvent ensuite partir de ce modèle pour bâtir leurs propres variantes.

Dans une grande équipe, cette logique répond à un problème connu : chaque nouveau projet ne devrait pas réinventer des mécanismes déjà éprouvés. Un modèle de tableau de bord, de formulaire, de parcours d’inscription ou de présentation de données peut être adapté à différents besoins tout en conservant des repères communs. Les templates facilitent ainsi la diffusion de pratiques cohérentes, notamment lorsque plusieurs équipes travaillent sur le même produit ou sur des produits apparentés.

Figma met également en avant des règles persistantes dans ces templates. Elles peuvent inclure des documents d’exigences produit et des guidelines, c’est-à-dire des consignes de conception ou d’usage. L’idée est que ces informations accompagnent le prototype au lieu de rester dans des documents séparés, parfois oubliés au fil des itérations.

Les composants sont, selon Figma, directement reliés au code, ce qui doit simplifier leur manipulation et leur mise à jour. Cette promesse s’inscrit dans l’évolution des design systems. Un design system ne se réduit pas à une bibliothèque de boutons et de couleurs : il rassemble des composants réutilisables, des règles de langage visuel et des conventions qui aident une organisation à produire des interfaces cohérentes. En rapprochant ces éléments du prototype et du code, Make ambitionne de rendre ce système plus vivant.

Une collaboration moins séquentielle entre design et développement

Holly Li, product manager de Figma Make, insiste sur l’objectif de collaboration entre designers et développeurs. L’outil a été conçu pour que les personnes concernées travaillent dans un environnement partagé plutôt que dans une succession de silos. Cette orientation correspond à une évolution plus large des équipes produit : les décisions de conception, de faisabilité technique et de priorités métier sont rarement indépendantes les unes des autres.

Dans un schéma séquentiel, le designer livre des écrans, le product manager détaille les besoins, puis le développeur interprète l’ensemble pour construire le produit. Chaque passage de relais peut introduire une ambiguïté. Une interaction imaginée dans une maquette peut sembler simple mais être difficile à mettre en œuvre. À l’inverse, une contrainte technique peut imposer une modification qui n’apparaît pas dans la version dessinée.

Figma Make cherche à faire intervenir ces discussions plus tôt. En manipulant un prototype, le développeur peut commenter la logique d’une interaction, tandis que le designer peut vérifier qu’une adaptation technique ne dégrade pas l’expérience. Le product manager peut, lui, confronter plus rapidement une fonctionnalité à son objectif initial.

L’exemple d’Affirm illustre cet usage. L’entreprise utilise Make pour générer des écrans interactifs côte à côte afin de comparer différents parcours utilisateur. Mettre deux variantes en regard peut aider une équipe à repérer ce qui change concrètement : le nombre d’étapes, la place d’une information ou la façon dont l’utilisateur passe d’un écran à l’autre. Certains clients intègrent aussi des éléments analytiques à leurs prototypes pour suivre les interactions en temps réel.

Claude Sonnet 4 au cœur de Make, avec des limites à connaître

Pour alimenter Make, Figma utilise actuellement Claude Sonnet 4, un modèle d’IA d’Anthropic. Figma explore en parallèle différents modèles afin d’améliorer l’expérience utilisateur. Ce choix rappelle que l’outil n’est pas figé : la qualité de la génération, la compréhension des demandes et la capacité à conserver le contexte d’un projet peuvent évoluer à mesure que les modèles sont intégrés ou remplacés.

Pour l’utilisateur, le principal changement est l’apparition d’une interface où l’on peut combiner langage naturel et éléments graphiques. Il ne s’agit plus de dépendre uniquement d’un prompt isolé. Une instruction peut être accompagnée d’une frame, de composants existants, d’un template et de règles propres à l’organisation. Cette combinaison est importante, car elle ancre davantage la demande dans le travail réel d’une équipe.

Il serait toutefois trompeur de considérer l’IA comme un substitut automatique à l’expertise de conception ou de développement. Une proposition générée peut nécessiter de nombreuses corrections. Elle peut aussi ne pas refléter entièrement les contraintes du produit, les exigences d’accessibilité ou les cas particuliers d’un parcours. La responsabilité de vérifier le résultat reste entre les mains des équipes.

Pour obtenir un prototype utile, il est donc préférable de donner des indications précises : objectif de l’écran, actions possibles, informations à afficher, comportements attendus et règles déjà établies dans le design system. Plus le contexte est explicite, plus le prototype a de chances de servir de base de travail crédible.

Pourquoi l’intégration au MCP est-elle attendue ?

Figma travaille sur une intégration avec le Model Context Protocol, ou MCP. Ce protocole vise à permettre à Make de se connecter aux environnements de développement. L’objectif annoncé est d’élargir le contexte disponible et de fluidifier le travail collectif entre les univers du design et du code.

Le mot « contexte » est déterminant. Pour qu’un prototype corresponde réellement à un produit, il ne suffit pas de connaître son apparence. Il faut aussi comprendre quels composants existent, quelles conventions de code sont utilisées, quelles données sont attendues et quelles contraintes s’appliquent au projet. Une connexion plus étroite aux environnements de développement pourrait limiter le décalage entre la démonstration conçue dans Make et la réalité du logiciel en construction.

À la date de publication de cet article, cette intégration est en développement. Elle relève donc d’une orientation annoncée, pas d’une fonctionnalité déjà disponible. Son utilité dépendra notamment de la qualité des informations réellement accessibles dans les environnements connectés et de la manière dont les équipes choisiront de les gouverner.

Ce qu’il faut surveiller dans l’évolution de Figma Make

Figma Make s’inscrit dans une tendance forte : les outils de création numérique cherchent à réduire les frontières entre l’idée, le design, le prototype et le code. Pour les équipes produit, le bénéfice potentiel est clair. Elles pourraient tester davantage d’hypothèses, rendre les discussions plus concrètes et partager plus facilement des méthodes de travail réutilisables.

Les prochains développements seront néanmoins décisifs. Il faudra observer la façon dont Figma rapproche effectivement Make du code, notamment via le MCP, mais aussi l’efficacité des templates dans les organisations complexes. Un modèle très flexible peut accélérer l’expérimentation, tandis qu’un cadre trop rigide peut limiter la créativité. L’équilibre entre cohérence du design system et liberté d’itération sera central.

Enfin, l’adoption dépendra de la confiance accordée aux prototypes générés. Les designers voudront préserver la précision de leurs intentions, les développeurs demanderont un lien fiable avec leurs contraintes techniques et les responsables produit chercheront des résultats facilement testables. Si Make parvient à donner à chacun un langage commun, il pourrait devenir bien davantage qu’un générateur de maquettes animées : un espace où le produit se construit collectivement, avant même d’être développé.