Figma Make : mes retours après des projets réels

Comment prototyper un site fonctionnel, comment implementer la méthode chez un client. Retour d’expérience.

Cas n°1 : un besoin de production rapide pour une opération marketing

Lors de notre campagne sur l’accessibilité et l’IA, nous avions besoin de créer rapidement un site fonctionnel pour dénoncer les fausses promesses des audits automatisés.

Le défi : produire un prototype réaliste, professionnel et accessible en moins de 24 heures.

La solution : Figma Make (outil équivalent à Lovable).

Voici comment nous avons procédé et surtout ce que j’ai appris sur cet outil en conditions réelles de production, sur ce projet mais aussi sur la fabrication d’un prototype en situation réelle, chez un client, avec un design system complet.

Le process technique : De l’idée au prototype en 24h

Le meta-prompting : la clé du succès

J’ai d’abord expliqué notre projet à ChatGPT en langage « naturel » et je lui ai demandé de me rédiger le prompt parfait pour Figma Make.

Voici le prompt complet que j’ai utilisé :

Design a single-page marketing website that sells a fake AI-powered accessibility audit service. The site must appear highly professional, visually engaging, and persuasive. The design should be fully compliant with WCAG 2.1 / RGAA 4.1, including strong color contrast, keyboard navigability, screen-reader friendliness, and semantic HTML structure.

The user lands on a hero section with:

• A bold, emotional headline that claims the service saves 1 month of work with AI.
• A short, high-impact value proposition (1 or 2 lines).
• A central URL input field with a « Launch audit » CTA.
• The page should convey expertise in accessibility with trust-building elements (badges, icons, quote, or stat).

When the user enters a URL and clicks « Launch audit », simulate a 15-second animated progress bar (very dynamic, full-width), replacing the input field.

During the animation, sequentially show realistic audit phases like:

• « Analyzing ARIA landmarks »
• « Checking contrast ratios »
• « Parsing heading structure »
• « Verifying image alternative texts »
• « Testing focus order »
• « Evaluating keyboard navigation »

At the end, show a flashy completion animation with a message like « Audit complete! » and then transition to a new result screen.

The result screen should display:

• A full-page message with a large ironic headline: « Vous y avez cru ? »
• A short explanatory paragraph: »Un vrai audit nécessite de l’expertise humaine. L’IA peut aider, mais pas tout faire. Méfiez-vous des promesses miracles. »
• Clear statements against:
  • AI-only audits
  • Overlay accessibility widgets
• A CTA to contact real experts (button: « Discuter avec un expert »)

Additional requirements:

• Use semantic HTML components (main, header, nav, footer, etc.).
• Ensure keyboard navigation is supported in all interactive elements.
• Use only accessible color palettes (AA minimum for text, AAA for critical components).
• Use visible focus indicators and ARIA roles where necessary.
• All animations should be WCAG-friendly (no flashing, allow reduced motion).
• Text content must remain readable when zoomed to 200%.

Style direction: Clean, modern, accessible-first. Avoid dark mode by default. Typography must be legible and scalable.

Itérations et perfectionnement

À partir de la base produite, on a itéré une dizaine de fois pour ajuster certains textes, certains aspects graphiques, certains points d’accessibilité et pour rendre le site consultable en Anglais.

On l’a ensuite lié à une URL Frontguys (https://ia11y.frontguys.fr/) afin de rendre le site plus crédible.

Bilan de production

Au final : une journée de travail au global pour concevoir et mettre le site en ligne.

Gain de productivité : ×8

Cas n°2 : Intégration d’un prototype Figma Make dans un contexte client

Depuis l’arrivée de Figma Make, une question revient souvent dans les équipes produit :
qu’est-ce que ça change vraiment, d’intégrer un prototype interactif et réaliste dans un projet client ?

La réponse : beaucoup de choses.
Parce qu’on ne parle plus d’une simple maquette, ou d’un prototype statique, mais d’un prototype fonctionnel capable de simuler de vraies interactions, de tester des parcours complets, et d’aligner rapidement tous les acteurs — métier, design, et technique — autour d’une même expérience tangible.

Dans un contexte client complexe, avec un Design System déjà en place, avec une charte établie, cette intégration change profondément la manière de concevoir, de valider et de collaborer.

---

1. Deux livrables, deux logiques

Nous distinguons toujours deux livrables dans notre approche :
les écrans de conception et le prototype d’expérience.

Les écrans de conception

Ils constituent la base de travail.
C’est ici que les designers construisent les interfaces à partir du Design System, valident les contenus et les états fonctionnels, et itèrent avec les métiers et les devs.
Ils représentent le périmètre fonctionnel validé à un instant T : ce qui va être produit, testé, livré.

Le prototype Figma Make

Le prototype, lui, dépasse le cadre figé des écrans statiques.
Grâce à Figma Make, il devient un produit simulé : navigation réelle, transitions fluides, comportements dynamiques.
Il permet de tester la cohérence de l’expérience complète, d’identifier les zones de friction et de recueillir du feedback beaucoup plus tôt.
Et surtout, il parle à tout le monde : développeurs, métiers, utilisateurs.

👉 Le prototype n’est plus une vitrine, c’est un outil de décision et de transmission.

---

2. Les bénéfices concrets dans les projets clients

Intégrer un prototype Figma Make dans le workflow change la dynamique d’équipe :

• Les product owners valident sur la base d’un rendu quasi réel, plus besoin d’interpréter une maquette.
• Les développeurs peuvent anticiper les comportements, les animations, et les micro-interactions avant même le sprint.
• Les utilisateurs finaux testent une version crédible, permettant de récolter des insights fiables sans attendre un MVP.
• Et les designers gagnent un temps précieux : les allers-retours se font sur la perception et non sur la compréhension.

Résultat : moins de réunions d’interprétation, plus de décisions fondées sur l’expérience vécue.
Et une meilleure anticipation de l’effort de développement.

---

3. Ce que ça change dans la culture design

Au-delà de l’outil, ce que Figma Make change réellement, c’est la culture design.
En rendant l’expérience visible et testable très tôt, on aligne les équipes sur une réalité commune.
Cela renforce la collaboration, encourage les échanges transverses, et réduit le décalage entre la vision métier et la mise en œuvre technique.

Dans un environnement outillé d’un Design System, cette boucle rapide entre idée, test et ajustement devient un vrai accélérateur d’apprentissage collectif.

---

4. Et la suite ?

L’intégration de Figma Make ouvre une voie passionnante : celle du prototypage réaliste et collaboratif, au service de la clarté et de la qualité.
On teste mieux, plus tôt, avec plus de sens.
Et surtout, on redonne au design son rôle premier : faire le lien entre vision et réalité.

Guide pratique : Bonnes pratiques Figma Make (REX complet)

Disclaimer important

Attention : pour l’instant, Figma Make remplace uniquement les prototypes classiques de Figma. C’est un outil de passation et d’alignement sur l’expérience, ce n’est pas un outil de passation dev.

On a toujours besoin :

• Des écrans
• Des passations
• Des composants
• De la doc

En revanche, il aide beaucoup :

• Les PO à la rédaction des US
• Les QA pour les tests
• Toute l’équipe produit, la direction, pour s’aligner et se projeter

Ils ont enfin une référence réaliste pour décrire et comparer ! C’est TRÈS puissant !

Quelle est la courbe d’apprentissage sur des outils comme Figma Make ?

Plutôt rapide. On voit très vite les limites quand on lui fournit des écrans complets.

Conseils d’utilisation : les essentiels

1. Toujours définir un langage commun

Définir une nomenclature et donner des noms clairs aux différents éléments, composants etc. Cela peut se faire dans le fichier Guidelines.md.
Dans ce fichier, on peut lui écrire en langage naturel. Il s’agit ici de lui donner des règles fontionnelles, des attendues de comportement (responsive, interaction, accéssibilité, utilisation des variables ou token, etc…)
Exemple : ne permet jamais qu’un élément de contenu dépasse de la zone affichable.

Comme en vrai, plus la documentation sera complète, plus il sera efficace.

2. Nommer les calques !

C’est indispensable pour que Figma Make comprenne la structure. Il faut être rigoureux (exit la fonctionnalité Rename Layer de Figma)
Exemple :
Le layer d’une liste à puce doit être bulleted list
Les layers de chaque item de cette liste peuvent s’appeller icon + text

3. Itérer par petits bouts

Il faut bien préparer le terrain en préparant :

• Le fichier des guidelines
• La doc de ses composants
• l’intégration des CSS de la librairie (export JSON depuis Figma et copié collé dans le fichier Global CSS)
• Commencer par developer les composants de base

Et même comme ça, il n’arrive pas à faire le job parfaitement. Il faut itérer et comprendre ses limites. Une fois qu’un composant est bien produit, là il ne se trompe plus quand on l’appelle.

Plus on découpe les tâches, mieux il fait du premier coup.

4. Bien identifier les problèmes à résoudre

Dès fois un manque d’espace est en fait un manque de zone de scroll. Il faut toujours essayer d’être factuel sur le comportement attendu, et pas lui donner une solution design ou technique, sauf si vous êtes sûr de la solution.

Exemple : passer un composant en version mobile à partir d’un certain breakpoint. (en lui fournissant la frame de ce composant en mobile)

5. Bien penser son projet en amont

Comme pour un Design System, bien identifier ce qui va être réutilisable et lui préciser en permanence.

6. Pour les demandes complexes : meta-prompting

Il faut les découper, et éventuellement s’aider d’une autre IA textuelle comme ChatGPT pour rédiger le prompt. Les résultats sont meilleurs.

7. Utiliser des fichiers markdown pour les grands contenus

Si vous avez des grands contenus à mettre dans vos écrans (beaucoup de texte par exemple), vous pouvez lui demander de créer un fichier markdown dans les fichiers de code. Mais également, aller copier-coller vous-même le texte dedans. Il pourra aller piocher dedans.

8. Utiliser la flèche d’inspection

N’hésitez pas à vous servir de la flèche d’inspection pour sélectionner des éléments directement dans le design, comme avec un inspecteur, pour aller voir le code et le modifier ou bien prompter spécifiquement sur cet élément.
Pour modifier un texte, ou des éléments simples, inspectez l’élément et modifiez le texte directement dans le code.

Les points de douleur à connaître

Variables et modes de variables

Gros pain point : si vous utilisez des modes de variables, il ne vas pas comprendre si vous lui demandez d’utiliser un certain mode. Il utilisera le mode de variable par défaut sauf si vous personnalisez les global CSS : supprimez les CSS des modes que vous ne voulez pas utilisé. Je n’ai pas trouvé de solution pour l’instant.

Pour les CSS, si on ne prompt pas de demande de changement visuel, il ne les change pas. Le but est de toujours utiliser les variables dans les prompts pour qu’il les respecte. Je n’ai pas encore testé mais je pense que dans Guidelines, si on lui dit de ne pas utiliser de valeurs en dure et de n’utiliser que les variables de global.css il le fait vraiment. Parce que le gros problème aujourd’hui c’est que quand je lui file une frame de Figma avec les variables appliquées il ne les reconnaît pas forcément.

Bugs sur les éléments visuels

Il bug souvent sur des éléments visuels fournis, mais en lui apprenant et lui répétant les choses, il finit par comprendre.

Cela n’est pas magique

Il faut itérer encore et encore pour avoir un résultat parfait (surtout pour coller à son DS).

Composants réutilisables

Il sait faire des composants réutilisables, mais ne le fait pas bien, donc il faut bien lui préciser et lui donner la documentation précise pour qu’il y arrive.

Impossible de passer un composant en entier

Impossible de lui donner un composant en entier donc il faut lui fournir et lui décrire les variants un par un.

Ma conclusion sur Figma Make

Est-ce qu’aujourd’hui tu as changé ta façon de prototyper ?

Oui, je ne ferais plus jamais de prototype avec Figma Design (ou alors des tout petits éléments, rapides à faire – interactions basiques de composants par exemple).

Figma Make produit plus vite. IL est plus facilement maintenable et surtout les prototypes sont réalistes, enfin…

Les utilisateurs en tests peuvent vraiment tester les fonctionnalités avancées !

Écrire dans un champs texte, faire une vraie recherche etc : c’est une révolution !

Le changement de paradigme

L’IA ne remplace pas la réflexion design mais elle transforme radicalement le prototypage :

• Avant : des heures à créer des interactions factices dans Figma
• Maintenant : des prototypes fonctionnels en quelques itérations
• Impact : plus de temps pour tester avec de vrais utilisateurs

Recommandations finales

• Commencez petit, avec des composants simples
• Documentez votre Design System pour Figma Make
• Acceptez l’itération comme partie intégrante du process
• Ne cherchez pas la perfection du premier coup
• Gardez un œil critique ! L’outil est puissant mais pas infaillible

Pour en savoir plus sur le projet qui nous a permis de tester Figma Make en conditions réelles, consultez l’article « Quand l’IA bouscule l’accessibilité : le faux audit qui dit la vérité ».

Ressources :

• Site de démonstration : https://ia11y.frontguys.fr/

Pour discuter d’un projet d’accessibilité ou d’intégration de l’IA dans vos process produit, contactez-nous !