Marketplace à deux faces · pré-lancement
2026 · 6 min de lecture
Concevoir une marketplace avant qu'elle n'existe
Mission freelance pour une start-up en pré-lancement : démarche UX complète, de la proposition de valeur aux prototypes testés, avec l'IA comme accélérateur de production. Mission reconduite.
- Product Discovery
- Benchmark
- Tests d'utilisabilité
- Design system
- IA
- Client
- Start-up du closing freelance (confidentiel, pré-lancement)
- Rôle
- Product Designer freelance, en charge de toute la conception
- Durée
- Deux phases de trois mois en 2026, reconduite après la première
- Ce qui a changé
- Une interface validée par des tests avant le lancement, plutôt que corrigée après
Le problème
Pas d'interface existante, pas d'« avant » à corriger : tout était à construire, pendant que l'équipe technique développait en parallèle. La start-up met en relation des closers freelance, commerciaux spécialisés dans la conclusion de ventes, avec des entreprises qui cherchent à renforcer leurs équipes.
Trois contraintes structuraient la mission. Une marketplace à deux faces, où chaque décision doit convenir à la fois aux freelances et aux entreprises. Un développement mené en parallèle de la conception. Et surtout un code généré par une plateforme d'IA alimentée directement par mes livrables : la moindre imprécision dans une maquette devenait une imprécision dans le produit.
La solution
J'ai volontairement repoussé les maquettes. Sur un produit sans utilisateurs publics, la tentation est de dessiner tout de suite ; le risque est de soigner une interface qui répond à la mauvaise question. J'ai commencé par la stratégie (besoins couverts, modèle économique, proposition de valeur), puis le benchmark, puis les entretiens.
Les maquettes sont venues ensuite, accélérées par l'IA, et sont repassées en boucle par les tests : une quinzaine de journées de tests d'utilisabilité, d'A/B testing et d'audit heuristique réparties sur les six mois.
Démarche
Commencer par la stratégie et le marché, finir par les pixels : l'inverse du réflexe habituel sur un produit qui n'existe pas encore.
- Proposition de valeur
- Benchmark concurrentiel
- Entretiens closers et entreprises
- ≈ 15 journées de tests
- A/B testing
- Audit heuristique
Planches reconstituées en 2026 à partir des livrables originaux, qui appartiennent aux clients. Les contenus sensibles sont anonymisés.
Tester un matchmaking par swipe plutôt que d’en débattre
Le matchmaking était le cœur du produit. L'idée d'un geste de swipe, emprunté aux applications de rencontre, était séduisante mais risquée dans un contexte professionnel. Plutôt que d'en débattre en réunion, j'en ai produit rapidement des prototypes visuellement aboutis grâce à l'IA, pour que la direction puisse juger sur pièce.
Le swipe a ensuite été comparé en test à un matchmaking classique en liste, tout comme deux façons de trouver une mission : une barre de recherche avec filtres, ou des critères à sélectionner. Le swipe a été retenu sur mobile ; sur ordinateur, la liste reste plus adaptée à la comparaison. La recherche est restée importante, mais sur mobile les critères à sélectionner l'ont emporté, parce qu'ils sont plus accessibles qu'une saisie libre.
Matchmaking mobileVoir en grand ↗
Le parcours de matchmaking retenu sur mobile après comparaison en test avec une présentation en liste. Faire du suivi des données la raison de rester
Une plateforme de mise en relation se fait souvent quitter une fois le contrat signé. Le suivi intégré des ventes, des retours et des performances donnait aux closers une raison de revenir chaque jour.
J'ai conçu ces écrans comme un outil de travail, pas comme une vitrine : le taux de closing en tête, l'indicateur que les closers citaient en premier en entretien, puis le nombre de closings, les commissions et le détail par mission.
Tableau de bord du closerVoir en grand ↗
La hiérarchie de l'écran suit l'ordre dans lequel les closers citaient leurs indicateurs en entretien, pas l'ordre dans lequel la base de données les stocke. Faire du design system le contrat avec le code généré
L'équipe transformait mes livrables en code via une plateforme d'IA accessible à des profils peu techniques. Dans ce modèle, une maquette approximative produit un écran approximatif.
J'ai donc construit un design system strict et accompagné chaque maquette de spécifications d'implémentation précises, pour que l'outil n'ait rien à deviner. J'ai aussi codé moi-même quelques composants très spécifiques du système.
Ce que l'IA a accéléré, et ce qu'elle n'a pas remplacé
- Accéléré : des maquettes et prototypes testables en quelques heures au lieu de plusieurs jours
- Accéléré : montrer des directions visuellement fortes et comparables, au lieu de demander d'imaginer
- Pas remplacé : rien de ce que l'IA générait n'allait tel quel dans le produit
- Pas remplacé : les décisions sont restées celles de la recherche et des tests
Méthode designer et IAVoir en grand ↗
Où l'IA intervient dans mon processus, et où elle n'intervient pas : la frontière entre production accélérée et décision de conception.
Ce que j'en retiens
“L'IA impressionne, la spécification décide. Un prototype généré convainc une direction en une réunion. Mais quand le produit lui-même est généré par une IA, c'est la rigueur du design system et des spécifications qui fait la qualité finale. Mon travail s'est déplacé de la production vers la définition.”
Résultats
- Reconduite (2 × 3 mois)
- Mission
- Majorité, avant l'ouverture
- Recommandations implémentées
- ≈ 15
- Journées de tests
- Web + mobile, deux faces
- Périmètre
Il n'y avait pas d'« avant » à comparer : le résultat se mesure à ce qui a été adopté. La mission a été reconduite après la première phase, la majorité des recommandations doit être livrée avant l'ouverture publique, et la direction a fait des retours très positifs sur la démarche comme sur les livrables.