Figma Make en production : mes retours après un projet réel

Comment prototyper un site fonctionnel en 24h et ce que j’ai appris sur cet outil.

Le contexte : Un besoin de prototypage rapide

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

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 (responsible, interaction, 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 developper 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.

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 variables et des modes de variables, il ne va pas le comprendre facilement. Il utilisera le mode de variable par défaut sauf si vous personnalisez les global CSS. Malgré ça il n’est pas toujours efficace.

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 !