Une maquette convaincante n’est pas encore une fonctionnalité prête à être livrée. Pour le vérifier, une agence peut réunir design, produit et développement autour d’un même cas, puis suivre le parcours de l’intention au dépôt GitHub. Voici un atelier d’une journée conçu pour tester ce flux sans confondre démonstration rapide et validation de production.
Le scénario s’appuie sur les nouveautés annoncées par Figma le 15 octobre 2026 : les code layers permettent de créer des prototypes interactifs adossés à du code, notamment à partir d’un écran de design ou d’un dépôt GitHub. Figma Specs vise à rapprocher décisions, exploration visuelle et détails techniques sur un même canevas. Ces fonctionnalités étant en bêta ouverte ou en cours de déploiement, vérifiez avant l’atelier qu’elles sont accessibles à votre équipe et à votre formule. Les sources officielles décrivent des capacités produit, pas une garantie de disponibilité uniforme ni de qualité de production. Consulter les notes de version de Figma et l’annonce de Figma Specs.
Le cas fictif : une demande de devis pour une PME de maintenance
Pour éviter un exercice trop abstrait, l’équipe travaille sur une fonctionnalité simple : permettre aux clients d’une PME belge de maintenance de demander un devis pour une intervention. La page de demande recueille le type de service, le code postal, une description et les coordonnées du client. À la fin, elle affiche une confirmation claire et un récapitulatif.
L’objectif de la journée n’est pas de créer un système complet de gestion des demandes. On cherche plutôt à tester un parcours représentatif : un client remplit le formulaire, reçoit un retour compréhensible et peut corriger ses informations avant l’envoi. Les données sont fictives. Aucun formulaire ne doit transmettre de vraies coordonnées ou déclencher de traitement réel.
Cette limite est importante : elle réduit les risques liés aux données personnelles et rend explicite la différence entre simuler une fonction et l’exploiter auprès de clients. Si le projet devait aller plus loin, il faudrait cadrer séparément les exigences métier, la sécurité, les responsabilités liées aux données et l’intégration au système existant.
Qui participe et que doit-on préparer ?
Les rôles pendant l’atelier
- Facilitateur ou cheffe de projet : garde le cap, fait respecter les créneaux, note les décisions et distingue les faits des hypothèses.
- Designer UX/UI : prépare le parcours, construit ou adapte la maquette, vérifie les états d’interface et conduit la revue d’usage.
- Développeur ou développeuse : examine la structure du dépôt, les composants réutilisables, les contraintes techniques et la qualité du code généré ou modifié.
- Responsable produit ou représentant métier : précise le besoin de la PME, les règles de validation et les conditions qui rendent le parcours utile.
- QA, accessibilité ou personne de test : essaie des scénarios normaux et d’erreur, repère les obstacles d’usage et consigne les défauts.
Une même personne peut cumuler plusieurs rôles dans une petite agence, mais la validation produit ne devrait pas être confondue avec l’approbation technique. Le développeur garde le dernier mot sur l’intégration au dépôt ; la personne métier tranche sur la pertinence du parcours ; le facilitateur documente les désaccords plutôt que de les masquer.
Préparation, idéalement avant le jour J
- Créer un fichier Figma de test et vérifier les accès aux fonctionnalités visées, dont les code layers et Specs.
- Préparer un dépôt GitHub dédié, sans secrets ni données clients, avec une branche de travail et un README bref.
- Fournir une maquette de départ ou des composants d’interface existants, en signalant ce qui est fictif.
- Préparer trois scénarios de test et un document de décisions : hypothèses, questions ouvertes, risques et responsables.
- Décider à l’avance qu’aucune fusion dans la branche principale ni publication publique n’aura lieu pendant l’exercice.
Si l’équipe veut tester l’import d’un dépôt, elle choisit un dépôt non sensible et clarifie les autorisations accordées. Les notes de Figma distinguent les code layers en bêta ouverte des sources de code GitHub ou npm, signalées en bêta fermée dans l’annonce du 15 octobre 2026. Ne faites donc pas dépendre tout l’atelier d’une capacité qui pourrait ne pas être activée sur votre compte. Pour renforcer vos pratiques d’interface, vous pouvez aussi consulter le service création de site web et les formations Enovatic.
Le déroulé de la journée, de 9 h à 17 h
9 h–9 h 30 : cadrer le test
Le facilitateur rappelle l’objectif : évaluer le flux entre maquette, prototype codé et dépôt, pas prouver que l’IA peut produire une interface spectaculaire. L’équipe formule une question de test, par exemple : « Pouvons-nous transformer une maquette en prototype interactif, l’ajuster au regard du besoin et transmettre un changement traçable dans GitHub ? » Elle définit aussi les éléments hors périmètre : authentification, paiement, envoi réel du formulaire et connexion à un CRM.
9 h 30–10 h 15 : écrire l’intention dans Specs
Le responsable produit décrit le problème, les utilisateurs visés, les informations nécessaires et les règles métier connues. Le designer ajoute le lien vers la maquette et le développeur note les contraintes qu’il connaît déjà. L’équipe consigne aussi les inconnues : formats de code postal acceptés, champs obligatoires, messages d’erreur et comportement après soumission.
Cette étape produit un brief court, pas une spécification exhaustive. Figma présente Specs comme un espace collaboratif réunissant contexte écrit, explorations et éléments du canevas ; le document doit donc rendre visibles les hypothèses, décisions et références utiles. L’équipe garde une trace de ce qui reste à arbitrer au lieu de laisser l’outil combler les trous par des suppositions.
10 h 15–11 h 15 : construire le parcours de référence
Le designer prépare ou ajuste trois états dans Figma Design : formulaire vide, formulaire avec erreurs de validation et confirmation après envoi simulé. Le représentant métier vérifie que les libellés correspondent au vocabulaire de la PME. La personne QA relève ce qui manque pour comprendre l’action attendue, notamment les champs requis et les retours d’erreur.
Le groupe sélectionne un parcours de base avant de passer au code. Il définit un critère observable : une personne qui découvre l’écran doit pouvoir comprendre quoi renseigner, corriger un champ invalide et identifier la confirmation. C’est ce parcours de référence qui servira à comparer le résultat codé, pas une impression générale du rendu.
11 h 15–12 h 30 : produire le premier code layer
Selon les accès et la configuration disponibles, l’équipe convertit une maquette en code layer, importe le dépôt prévu si la fonction est accessible, ou utilise le parcours de prototype codé disponible sur son compte. Le développeur vérifie immédiatement ce qui a été créé : structure des fichiers, dépendances, conventions, composants et comportement des interactions.
Le prompt ou les instructions doivent être précis : « Construire le formulaire de demande de devis selon les écrans liés, conserver les libellés, gérer les champs obligatoires et montrer une confirmation simulée sans transmettre les données. » Le designer compare le résultat au parcours de référence. Toute différence est notée : choix intentionnel, défaut visuel ou interprétation incorrecte.
12 h 30–13 h 15 : pause et revue intermédiaire
Avant la pause, l’équipe sauvegarde une version identifiable du prototype et consigne ce qui fonctionne, ce qui a été improvisé et ce qui reste bloquant. Elle évite d’empiler des demandes de correction à l’agent sans suivi : chaque modification doit répondre à un écart précis observé dans le test.
13 h 15–14 h 15 : tester les scénarios et corriger
La personne QA joue trois situations : demande complète, champ obligatoire manquant et code postal au format inattendu. Le représentant métier vérifie la cohérence des règles ; le designer observe la compréhension et la lisibilité ; le développeur évalue si les corrections se traduisent proprement dans le code. Le groupe choisit une ou deux corrections prioritaires, les applique et vérifie qu’elles ne cassent pas le parcours nominal.
On peut ensuite comparer le prototype au design, notamment sur les tailles d’écran, les retours d’erreur et les états de chargement si l’exercice les inclut. Il ne s’agit pas de polir chaque détail : l’enjeu est de comprendre si le flux raccourcit utilement la boucle entre intention et expérimentation, sans transférer toute la charge de vérification à l’équipe humaine.
14 h 15–15 h 15 : examiner le passage vers GitHub
Le développeur vérifie comment le résultat peut être relié au dépôt dans le cadre réellement disponible : import, travail sur une branche, export ou autre mécanisme supporté par le compte et le projet. Il s’assure que le dépôt reste propre, que les fichiers inattendus sont repérés et que les changements sont isolés. Si le lien direct entre le canevas et GitHub n’est pas accessible, l’équipe consigne cette limite et teste un passage manuel contrôlé plutôt que de prétendre avoir validé une intégration automatique.
Le code est examiné comme une contribution à relire, jamais comme une livraison acceptée par défaut. Le développeur inspecte au minimum les dépendances, la gestion des erreurs, la séparation des responsabilités, l’absence de secrets et la possibilité de lancer le projet. L’équipe inscrit dans le README ce qui est simulé et les étapes nécessaires pour reproduire le test.
15 h 15–16 h : revue croisée design, métier et technique
Chaque rôle donne son avis à partir de critères explicites. Le designer indique où le code ne respecte pas l’intention ; le représentant métier confirme ou refuse les règles de parcours ; le QA expose les scénarios non couverts ; le développeur signale les risques d’architecture et de maintenance. Les désaccords deviennent des éléments de décision, avec un responsable et une action suivante.
Une question utile est : « Si nous devions reprendre ce travail demain sans les personnes présentes, saurions-nous comprendre les décisions et reproduire le résultat ? » Specs peut aider à rapprocher le document des designs et des éléments codés ; l’équipe doit toutefois vérifier que ses références, annotations et liens sont effectivement à jour.
16 h–17 h : bilan et décision
Le facilitateur distingue trois résultats : ce que le flux a accéléré, ce qu’il a rendu plus difficile et ce qu’il n’a pas permis de tester. L’équipe choisit une décision parmi quatre options : poursuivre l’exploration, refaire un test ciblé, lancer un chantier d’ingénierie ou arrêter l’expérimentation. Elle attribue les prochaines tâches et archive le lien Figma, la branche GitHub, les scénarios et les décisions.
Prototype convaincant ou solution prête pour la production ?
Un prototype peut être convaincant s’il rend le parcours compréhensible et interactif, permet de discuter une hypothèse avec une PME et aide l’équipe à repérer des problèmes avant le développement complet. Cela ne prouve pas que la fonctionnalité est exploitable en conditions réelles. Pour décider, utilisez deux listes distinctes.
Le prototype est convaincant si…
- le parcours principal est testable sans explication permanente de son auteur ;
- les principaux états prévus, y compris les erreurs simulées, sont visibles ;
- les écarts entre maquette et résultat sont identifiés et discutables ;
- les participants comprennent ce qui est simulé, notamment l’envoi des données ;
- les retours recueillis répondent à une hypothèse métier ou UX clairement formulée.
La production exige davantage
- Code : un développeur responsable a revu, structuré et testé le code dans le dépôt et selon les conventions du projet.
- Fonctionnel : les règles métier, cas limites, messages d’erreur et intégrations réelles sont validés par les personnes concernées.
- Sécurité et données : les données collectées, leur transmission, leur stockage, les accès et les secrets ont fait l’objet des vérifications adaptées au projet.
- Qualité : les tests pertinents, l’accessibilité, l’affichage sur les appareils visés, les performances et la gestion des échecs ont été évalués.
- Exploitation : le déploiement, la surveillance, la maintenance, la responsabilité de support et le retour arrière sont prévus.
- Traçabilité : les décisions, versions, changements et validations peuvent être retrouvés par l’équipe.
Si un point essentiel reste inconnu, la conclusion n’est pas « prêt pour la production », mais « prototype prometteur, validation à poursuivre ». Cette distinction protège la relation avec le client : la démonstration ouvre une discussion, tandis que la mise en ligne engage la qualité et la responsabilité de l’agence. Pour cadrer la suite, découvrez les services Enovatic ou contactez l’agence.
Conclusion : tester le flux, pas seulement l’effet “waouh”
Une journée suffit pour observer comment maquette, code, documentation et dépôt peuvent se répondre, à condition de choisir un cas limité et de séparer prototype et produit. Le résultat attendu n’est pas nécessairement une fonctionnalité livrable : c’est une décision argumentée sur la valeur du flux, ses limites d’accès et les vérifications nécessaires avant toute production.
Appel à l’action : adaptez ce déroulé à votre équipe, choisissez une fonctionnalité fictive proche des besoins de vos clients PME et fixez dès le départ les critères qui feront dire « on poursuit » — ou « on s’arrête là ».
Sources
- www.figma.com — https://www.figma.com/release-notes/
- www.figma.com — https://www.figma.com/blog/introducing-figma-specs/
Photo d'illustration : Product School sur Unsplash.
