Étude de cas design engineering
Flex Academy : une seule source de vérité
Un concept issu d’un exercice de recrutement pour The Flex / Base360 : une landing page qui vend deux programmes à deux publics différents, construite comme un système connecté de variables Figma, de composants en code, de documentation Storybook et d’un prototype en ligne.
À propos du projet
Introduction
Flex Academy est un nouveau produit de The Flex, opérateur d’appartements meublés depuis 2019, et de Base360, la plateforme d’IA pour les entreprises de location courte durée (STR) qui en est issue. L’Academy apprend à lancer et à développer une activité STR avec le même playbook, les mêmes systèmes et le même logiciel. Le brief demandait une landing page pour deux programmes, Launch et Scale, uniquement comme exercice de design. J’ai aussi transformé la page en un petit design system en code pour montrer comment je travaille de bout en bout.
Mon rôle
Product designer, responsable du processus.
Stratégie, UX, UI, design system, règles pour les outils d’IA et revue de chaque modification.
Durée et type
3 jours de travail actif (5–7 oct. 2026). Un exercice de design pour un recrutement et un concept, pas un projet en production ni pour un client. Le développement ne faisait pas partie du brief ; le code et Storybook sont un ajout personnel.
Outils
Figma (Variables, Variants) · Storybook 10 · Next.js 16 · React 19 · TypeScript · Tailwind CSS v4 · Claude Code · Figma MCP · GitHub · Vercel
Le défi
Énoncé du problème
Une seule page devait vendre deux offres à deux personnes très différentes : quelqu’un qui veut « quitter son 9 h–17 h » et n’a pas encore commencé, et un opérateur débutant qui gère déjà quelques logements mais reste coincé dans le travail manuel et des marges faibles. Ce public est occupé et ouvertement sceptique envers les formations de « gourous ». Comment une page peut-elle gagner la confiance rapidement et permettre à chaque visiteur d’agir sur l’offre qui lui correspond ?
Décomposition du problème
Deux publics, une page
Un débutant et un opérateur n’ont pas les mêmes difficultés, le même niveau de confiance ni la même envie d’agir. Une page qui parle à tout le monde de la même façon ne convainc personne.
Un scepticisme de départ
Le marché de la formation est plein de cours de « gourous », la confiance doit donc apparaître avant toute proposition.
L’écart entre design et code
Un exercice de recrutement se termine généralement par des écrans statiques. Je voulais que les décisions de design vivent dans le code sans dérive : on modifie un token une fois, et Figma, Storybook et le site se mettent à jour ensemble.
Des critères de réussite clairs
En 5 secondes on sait de quoi il s’agit, en 30 secondes on fait confiance, et on peut agir depuis n’importe quel endroit de la page.
Écrans clés
Hero avec deux entrées : Launch en vert, Scale en bleu.
Bloc de crédibilité juste après le hero, avant toute offre.
Deux parcours CTA : inscription au webinaire et réservation d’un appel stratégique.
Les deux publics
Launch s’adresse à ceux qui veulent « quitter leur 9 h–17 h » avec zéro ou un logement : un cours à son rythme, des sessions de groupe en direct et des modèles, avec une entrée par un webinaire gratuit.
Scale s’adresse à l’opérateur débutant qui a quelques logements : 12 semaines de sessions de groupe hebdomadaires, un 1:1 mensuel avec un fondateur, une communauté, des SOP et l’accès à Base360, avec une entrée par un appel stratégique gratuit.
Launch · Webinaire
Engagement faible. Nom, e-mail, pays → confirmation et ajout au calendrier.
Scale · Appel stratégique
Intention forte. Logements actuels, objectif, ville, fourchette de budget → choix du créneau → confirmation.
Pas encore prêt · Checklist
Conversion secondaire : une checklist pour développer une activité STR en échange d’un e-mail.
Processus
1. Analyse du brief
Deux personas, une carte des irritants et des critères de réussite.
2. Wireframes dans Figma
Desktop 1440, Mobile 390, les deux parcours CTA et des notes de design.
3. Audit de marque
Styles calculés réels extraits de theflex.global et base360.ai et transférés dans des variables Figma : primitives → alias sémantiques. 157 calques liés à des variables.
4. Construction bloc par bloc
Code dans le prototype → vérification dans le navigateur → corrections → Storybook avec tous les états et la doc → miroir dans Figma sous forme de component set.
Décisions de design clés
Deux portes, un seul hero. Launch passe en premier parce que c’est le plus grand marché, mais Scale a le même poids visuel, pour que les opérateurs n’aient pas à faire défiler un contenu qui ne leur est pas destiné. La confiance avant le pitch : le bloc de crédibilité se trouve juste après le hero, avant toute offre, avec les fondateurs, les chiffres publics de l’entreprise (depuis 2019, 400+ logements, £10M+ de chiffre d’affaires, 7 villes) et des logos de presse.
Une couleur qui a du sens : Launch utilise le vert de The Flex, l’histoire des débuts des fondateurs ; Scale utilise le bleu de Base360, car Scale inclut l’accès à Base360. Des parcours séparés pour des intentions différentes : le webinaire est un court formulaire de trois champs, l’appel stratégique qualifie d’abord le lead puis permet de choisir un créneau.
Gagner la confiance
Répondre à l’objection de front
Une section « Not another guru course » compare le programme à YouTube, aux formations bon marché et aux masterminds au lieu de faire comme si le doute n’existait pas. Un bloc séparé sur les fondateurs a été supprimé parce qu’il répétait la section de crédibilité : une page plus courte plutôt qu’une répétition.
Aucun faux témoignage. Pour un public sceptique, des citations inventées détruisent la confiance, la preuve sociale reste donc sous forme d’emplacements clairement signalés.
Design responsive
Pipeline design engineering
Au lieu d’écrans statiques, j’ai construit la page comme un système avec une seule source de vérité : variables Figma → tokens.json → tokens.css → Tailwind v4 @theme → composants → Storybook → site en ligne.
Des tokens tirés des sites en ligne
Des styles calculés réels de theflex.global et base360.ai, pas à l’œil, transformés en variables Figma : primitives de marque et alias sémantiques comme offer/launch et offer/scale. Les mêmes 70 tokens vivent dans le code, sans couleurs, espacements ni rayons codés en dur dans les composants.
18 composants, 88 stories
Chaque composant est documenté dans Storybook avec tous ses états, ses props, des notes d’accessibilité et un Token Usage Report : propriété · token · valeur · source.
Des mentions « AI-defined » honnêtes
Tout ce qui n’était pas défini dans Figma est ouvertement marqué « AI-defined » dans la doc, pour que les relecteurs voient quelles décisions viennent du design et lesquelles non.
Figma reflète le code
Composants reconstruits dans Figma sous forme de jeux de variantes (Breakpoint, State, Tone, Step) liés aux mêmes variables. Les écrans sont assemblés à partir d’eux.
Modale + vraie URL
Les parcours CTA s’ouvrent dans une modale pendant que l’URL passe à /webinar ou /strategy-call. Si l’on ouvre ce lien directement, depuis une publicité ou un e-mail, le même formulaire se charge en page complète.
Accessibilité
01
Scale utilise un bleu plus profond (#3B4FE0, environ 5,6:1 avec le blanc) au lieu du bleu des boutons Base360 (#5070FE, environ 3,9:1), qui ne passe pas AA pour le texte courant.
02
Les parcours CTA utilisent un <dialog> natif : focus trap, fermeture avec Échap, retour du focus et blocage du défilement. Les champs font 48px de haut.
03
Les animations au défilement sont en CSS pur, sans bibliothèque d’animation, et respectent prefers-reduced-motion.
Comment j’ai travaillé avec l’IA
J’ai fixé la direction, les règles et le périmètre : quoi construire, comment structurer les tokens, le nommage, les décisions d’accessibilité et les critères de revue.
Règles, revue et vérifications
Claude Code a écrit l’essentiel de l’implémentation selon ces règles, définies dans les instructions du projet, un skill personnalisé et des documents de passation. Deux branches, prototype et design-system, partagent des fichiers de composants identiques. J’ai relu chaque modification, lancé le typecheck, le lint et le build Storybook, vérifié chaque bloc dans un vrai navigateur à 1440, 820 et 390 px, et validé chaque push.
Ce que je ferais ensuite
De vrais services
Brancher un vrai agenda, un CRM et l’e-mail à la place des bouchons actuels.
De vrais témoignages d’élèves
Remplacer les témoignages fictifs par de vraies histoires d’élèves.
Tester et vérifier
Tester en A/B un hero centré d’abord sur les opérateurs et ajouter des tests automatisés de régression visuelle à Storybook.
Résultat
Un fichier Figma avec le design system, les parcours CTA et les notes de design ; un Storybook avec 18 composants et 88 stories, chacun avec un Token Usage Report ; et un prototype en ligne sur Vercel construit exactement à partir de ces composants. Design, code et documentation qui ne peuvent pas diverger : on modifie un token une fois et il se met à jour partout.
En chiffres (périmètre du travail, pas impact business)
• 18 composants et 88 stories
• 70 tokens synchronisés entre Figma, Storybook et le site
• 2 branches et 2 projets Vercel
• 47 commits dans prototype, 36 dans design-system
• 3 jours de travail actif (5–7 oct. 2026)
Ce que j’ai appris
Traiter même une landing page comme un petit design system est vite rentable : les décisions prises une fois dans les tokens apparaissent de façon cohérente dans Figma, dans le code et dans la documentation, et les outils d’IA deviennent bien plus fiables quand ils travaillent dans des règles claires.
Limites assumées
C’est un concept, pas un site en production. Le backend, l’agenda et le CRM sont des bouchons, les témoignages sont fictifs et les prix ne sont pas affichés. Safari et une vraie intégration d’agenda n’ont pas été testés.