Une maquette peut être convaincante à l’écran tout en laissant une question importante sans réponse : que se passe-t-il quand on clique, qu’on remplit un formulaire ou qu’on rencontre un message d’erreur ? Les prototypes interactifs adossés à du code permettent de tester ces situations plus concrètement qu’une succession d’écrans statiques.
Figma fait évoluer cette approche avec les « code layers », ou calques de code : des prototypes exécutables intégrés directement au canevas de conception. L’idée n’est pas de déclarer qu’une maquette est devenue un site prêt à publier. C’est plutôt de rapprocher l’exploration visuelle et l’essai fonctionnel, pour que l’équipe et le client puissent valider une idée avant d’engager tout le développement. Voici comment en tirer parti, et où placer les limites.
Un calque de code, c’est quoi au juste ?
Un prototype qui s’exécute dans l’espace de conception
Un prototype classique relie des écrans et simule des interactions prévues à l’avance. Un calque de code va plus loin : il s’agit d’une expérience interactive qui repose sur du code exécuté, mais qui se place et se partage dans un fichier Figma. Figma indique que ces calques peuvent être créés à partir d’une demande, d’un écran conçu dans Figma, d’un site existant, d’un dossier local ou d’un dépôt GitHub compatible. On peut ensuite essayer le parcours, commenter l’expérience et comparer plusieurs variantes au même endroit.
Le produit a d’abord fait son apparition dans Figma Sites sous la forme d’éléments interactifs reposant sur React. Figma a ensuite présenté les calques de code dans Figma Design, où le code et les éléments de conception peuvent cohabiter sur le canevas. Au 21 octobre 2026, Figma annonce leur passage en bêta ouverte. Les modalités d’accès et les limites peuvent évoluer : mieux vaut les vérifier dans la documentation officielle avant de bâtir un processus d’équipe autour de la fonctionnalité.
Pourquoi parler de « vrai code » ?
Parce que le prototype ne se contente pas de montrer une image de bouton : il peut exécuter un comportement. Cela rend testables des éléments comme l’ouverture d’un menu, une validation de formulaire, un état de chargement ou une variante de mise en page. Les calques peuvent aussi être importés depuis une base de code, sous réserve de compatibilité. Le terme « vrai code » décrit donc le principe technique, pas une garantie de qualité de production : un prototype exécutable reste une expérience de validation tant qu’il n’a pas été vérifié, sécurisé et intégré dans le contexte réel du projet.
Ce que cela change pour les retours client
On commente une expérience, pas seulement une image
Face à une maquette statique, les retours portent souvent sur ce qui est visible : couleurs, textes, alignements, hiérarchie. Un prototype fonctionnel amène des questions plus proches de l’usage : « Que se passe-t-il si je laisse ce champ vide ? », « Est-ce que je comprends que la demande est envoyée ? », « Le menu reste-t-il facile à utiliser sur mobile ? » Ce changement de perspective aide à repérer plus tôt les incompréhensions et les étapes inutiles.
Il facilite aussi la discussion entre profils différents. Une personne métier peut expliquer son besoin sans devoir interpréter une démonstration technique. Le designer peut montrer plusieurs pistes en situation. Le développeur peut mieux identifier les comportements attendus et les zones qui nécessitent une décision. Le canevas partagé donne un support commun aux commentaires, sans remplacer les échanges nécessaires pour clarifier les contraintes.
Des retours plus précis, à condition de poser la bonne question
Un prototype réaliste peut aussi orienter les retours vers des détails prématurés. Si l’on demande « Vous aimez ? », les commentaires risquent de se concentrer sur des préférences personnelles ou sur la finition visuelle. Avant chaque séance, formulez plutôt une question vérifiable : les visiteurs trouvent-ils le formulaire de devis ? Comprennent-ils la différence entre deux offres ? Peuvent-ils terminer le parcours sur smartphone ?
Pour une PME, le bénéfice est concret : mieux cerner ce qu’il faut construire avant de lancer un chantier complet. Le prototype ne garantit pas qu’une décision sera bonne, mais il rend les hypothèses visibles et discutables. Pour cadrer cette étape dans un projet de création de site web, l’essentiel reste de relier chaque écran à un objectif métier : prise de contact, demande de devis, réservation ou achat.
Un mini-processus de test agence-client
Avant la séance : choisir une hypothèse et un parcours
Il n’est pas nécessaire de prototyper tout un site. Sélectionnez un parcours important et une incertitude qui mérite d’être levée. Par exemple : « Un nouveau visiteur comprend-il comment demander une estimation ? » Définissez ensuite les profils concernés, le contexte de test et le critère d’observation. Ce critère peut être qualitatif : la personne trouve-t-elle l’action sans aide ? Peut-elle expliquer ce qui se passera après l’envoi ?
- Délimiter le périmètre. Choisissez une page ou un flux essentiel, comme la demande de contact ou la réservation.
- Préparer deux variantes au maximum. Comparez un choix structurant, par exemple deux libellés ou deux organisations de contenu, plutôt que de modifier tout simultanément.
- Préciser ce qui est simulé. Indiquez si l’envoi du formulaire, le paiement ou la connexion à un outil externe est fictif.
- Faire tester une tâche. Demandez au participant d’accomplir un objectif avec ses mots, sans lui expliquer immédiatement où cliquer.
- Noter les observations. Consignez les hésitations, les erreurs, les questions et les éléments compris sans aide.
- Décider et documenter. Tranchez ce qui change, ce qui reste à vérifier et ce qui sera transmis au développement.
Pendant la séance : observer avant d’expliquer
Le client ou l’agence peut animer le test, mais la personne qui observe doit éviter de guider l’utilisateur. Une consigne neutre suffit : « Vous cherchez à demander un devis pour ce service. Montrez-moi comment vous feriez. » Si la personne hésite, notez l’endroit et demandez ensuite ce qu’elle cherchait. Évitez de défendre le design pendant le test : l’objectif est de comprendre le comportement, pas de convaincre que l’interface est déjà claire.
Après quelques essais, faites un bilan court : quel obstacle revient ? Quel changement pourrait le réduire ? Faut-il tester une autre variante ? Les calques de code permettent de comparer visuellement et fonctionnellement plusieurs pistes sur le canevas, mais la décision doit rester fondée sur les objectifs définis, pas sur l’effet « impressionnant » d’une démo.
Encadré pratique : avant de partager un prototype, ajoutez une courte note précisant son objectif, les éléments simulés, les appareils visés et les décisions encore ouvertes. Cela évite de confondre une démonstration d’interaction avec une validation complète du futur site.
Les limites à garder en tête avant la production
Un prototype n’est pas une version publiable
Un prototype peut illustrer un parcours sans couvrir toutes les situations réelles. Il peut manquer des règles métier, des cas d’erreur, des contenus définitifs, des intégrations ou des exigences d’accessibilité. Un formulaire qui semble fonctionner ne prouve pas que les données sont correctement transmises, stockées ou protégées. Une animation convaincante ne garantit pas qu’elle sera fluide sur tous les appareils.
Il faut aussi vérifier le code, la structure, les performances, la compatibilité des navigateurs, la sécurité et la conformité aux besoins du projet. Si le prototype part d’un dépôt existant, Figma précise que tous les dépôts ne sont pas nécessairement compatibles avec les calques de code. L’équipe technique doit donc examiner le contexte avant de promettre une reprise directe en production.
Le risque de prendre la maquette pour le cahier des charges
Une interface peut sembler évidente pendant une démonstration parce que la personne qui la présente connaît déjà le parcours. Le client, lui, peut supposer que chaque élément visible est finalisé. Pour éviter ce malentendu, séparez clairement les décisions confirmées des hypothèses. Indiquez les états non testés, les contenus provisoires et les questions qui nécessitent une validation technique ou métier.
Le prototypage avec du code demande également un cadre de collaboration : qui peut modifier le prototype, comment les versions sont comparées, et où se trouve la source de vérité quand le code évolue ? Sans ces règles, on risque d’avoir une maquette, un prototype et une base de code qui racontent trois histoires différentes. Le passage au développement doit inclure une revue et une transmission explicites.
Comment l’intégrer à un projet de PME
Réserver le prototypage aux décisions à fort enjeu
Tout ne mérite pas un prototype codé. Pour une page simple dont la structure est déjà éprouvée, une maquette et un prototype classique peuvent suffire. Le code devient plus intéressant quand l’expérience dépend d’interactions spécifiques, d’états multiples, d’un comportement responsive ou d’une logique difficile à expliquer par des écrans statiques.
Commencez petit : une fonctionnalité, un parcours, une question. Évaluez ensuite si le test a réellement aidé à prendre une décision. Si oui, formalisez ce qui a été appris et transmettez-le à l’équipe de réalisation. Si vous souhaitez améliorer la coordination entre conception et développement, explorez aussi notre article sur Figma et Payload : rapprocher maquette et site en production, qui rappelle l’importance de distinguer design, contenu et CMS.
Préparer l’équipe plutôt que miser sur l’outil seul
Une nouvelle fonctionnalité ne remplace ni la méthode ni les compétences. Les personnes impliquées doivent savoir formuler une hypothèse, construire une tâche de test, recueillir un retour sans l’influencer et transformer les observations en décisions. Une formation adaptée aux outils et pratiques web peut aider une équipe à gagner en autonomie, notamment si elle veut structurer ses méthodes de conception et de collaboration.
En pratique, convenez d’un rituel léger : un objectif par prototype, un nombre limité de variantes, une courte séance de test, puis un compte rendu des décisions. L’agence et le client savent ainsi ce que l’on cherche à apprendre, ce qui a été observé et ce qui reste à construire. Pour parler de votre projet, vous pouvez contacter Enovatic.
Questions fréquentes
Faut-il savoir coder pour utiliser les calques de code ?
Pas nécessairement pour créer une première exploration ou tester un parcours. Toutefois, comprendre les limites du prototype et faire intervenir une personne technique pour les vérifications est important avant toute décision de production.
Un prototype avec du code peut-il être repris tel quel pour le site final ?
Parfois, une partie peut servir de point de départ, notamment si l’exploration repose sur une base de code existante. Mais il faut examiner la qualité du code, son architecture, sa sécurité, ses performances et son adéquation aux exigences du projet. Ne présumez pas que le prototype est prêt à publier.
Quelle différence avec un prototype Figma classique ?
Un prototype classique relie des écrans et simule des transitions selon les interactions configurées. Un calque de code exécute une expérience reposant sur du code, ce qui permet d’explorer des comportements plus proches d’une interface web réelle. Le bon choix dépend de la question à tester.
Quel parcours choisir pour un premier test en PME ?
Privilégiez un parcours important pour l’activité et dont le fonctionnement suscite une incertitude : demander un devis, réserver un rendez-vous ou trouver une offre. Gardez le test court et vérifiez un objectif précis plutôt que d’essayer de valider tout le site en une séance.
Conclusion : tester plus tôt, sans confondre prototype et produit
Les calques de code rapprochent l’idée, l’interaction et la discussion d’équipe. Pour une PME, leur intérêt est de rendre certaines hypothèses visibles avant d’engager l’ensemble du développement : les visiteurs comprennent-ils le parcours, trouvent-ils l’action attendue, et quelles variantes méritent d’être retenues ?
La bonne approche reste pragmatique : choisir une question, tester un parcours limité, recueillir des observations et faire valider techniquement ce qui doit être construit. Le prototype accélère la conversation ; il ne remplace ni les tests complets, ni les exigences de production, ni le travail de conception et de développement. Vous préparez une refonte ou une nouvelle fonctionnalité ? Découvrez les services d’Enovatic ou échangeons sur votre besoin.
Sources :Actualités Figma, Code on the Figma canvas et documentation officielle sur les calques de code.
Sources
- www.figma.com — https://www.figma.com/blog/news/
- www.figma.com — https://www.figma.com/blog/code-on-the-figma-canvas/
- help.figma.com — https://help.figma.com/hc/en-us/articles/44193259600535-Code-layers-in-Figma-Design
Besoin d’un accompagnement sur mesure ?
Nos experts en design, développement web et référencement accompagnent les entreprises belges au quotidien. Découvrez nos services de création de site web, nos formations professionnelles et nos réalisations.
Contactez-nous pour un devis gratuit.
Photo d'illustration : Hal Gatewood sur Unsplash.
