Build in Public #3 : Ce que j'ai Appris de mes 20 Premiers Utilisateurs
Les 3 leçons tirées des premiers retours utilisateurs de ResumeRank, et comment j'ai automatisé la collecte de feedback en 30 minutes grâce au Model Context Protocol (MCP).

TL;DR : Mes 20 premiers utilisateurs m'ont appris 3 leçons cruciales : rendre le "Aha Moment" gratuit, renforcer le moteur d'analyse (passage à GPT-5), et automatiser la collecte de feedback. Spoiler : j'ai construit tout un système d'envoi automatique en 30 minutes grâce au MCP.
Dans le précédent chapitre, je t'ai montré ma stack technique et mon workflow de Vibe Coder pour construire ResumeRank. Aujourd'hui, on entre dans une nouvelle phase : le moment où les utilisateurs réels commencent à utiliser le produit.
Ça y est, ResumeRank est dans la nature depuis quelques semaines. Une vingtaine d'entre vous se sont inscrits, ont commencé à tester, et surtout... à me faire des retours. Et ça, ça change tout.
Tu vas découvrir :
- Les 3 leçons cruciales que j'ai tirées de ces premiers retours
- Les changements concrets que j'ai déjà mis en place
- Comment j'ai automatisé la collecte de feedback en 30 minutes (avec le détail technique complet)
- Ma prochaine étape : l'attaque du marché américain
Lancer un produit, c'est un peu comme parler tout seul dans une pièce pendant des mois. Le premier feedback, c'est la première fois que quelqu'un te répond.
Le Premier Retour : Un Moment de Soulagement
Quand Iwan, un des premiers testeurs (merci à toi !), m'a envoyé une liste détaillée de ses impressions, ma première réaction a été simple : le soulagement.
Enfin, quelqu'un d'autre que moi utilisait l'outil pour de vrai et me donnait des pistes concrètes pour l'améliorer. Ce n'était plus juste moi qui testais mes propres scénarios. C'était un vrai utilisateur, avec un vrai besoin, qui me disait ce qui fonctionnait... et ce qui ne fonctionnait pas.
Ces premiers retours étaient de l'or. Mais ils sont arrivés principalement parce que je les ai demandés manuellement. Et ça, ce n'est pas scalable.
Leçon n°1 : Le "Aha Moment" Doit Être Gratuit. Point.
Je vais être honnête avec toi. Au début, j'avais une stratégie claire : garder la meilleure fonctionnalité pour les plans payants.
Dans le cas de ResumeRank, c'est l'analyse par poste. La possibilité de créer un poste et d'y déposer des dizaines de CVs pour obtenir une shortlist automatique.
Pour moi, c'est là que se trouve le fameux "Aha Moment", cet instant où tu te dis "Wow, ça va vraiment me faire gagner un temps fou". Mon plan était de le réserver pour inciter les gens à s'abonner.
Le Feedback Était Unanime
Iwan et d'autres m'ont dit : "Les analyses de CV classiques sont bien, mais c'est la fonctionnalité d'analyse de CV par poste qui apporte le plus de valeur. Si on ne peut pas la tester, on n'a pas accès à la fonctionnalité phare de l'outil."
Ils avaient raison.
❌ Mon Erreur Initiale
Cacher la meilleure fonctionnalité derrière un paywall, c'était demander aux utilisateurs de payer pour quelque chose qu'ils n'avaient jamais expérimenté.
Le Changement Que J'ai Mis en Place
J'ai donc décidé d'ouvrir l'analyse par poste à tout le monde, y compris dans le plan gratuit. La limite se fait maintenant sur le nombre d'analyses (5 par mois), mais tout le monde peut tester l'expérience complète.
✅ Ce Que J'en Retiens
Ne cache jamais ta meilleure fonctionnalité. C'est elle qui doit convaincre. Le "sacrifice" de la mettre en gratuit n'en est pas un, car il faut déjà que les utilisateurs utilisent le produit gratuitement avant d'envisager de souscrire à un abonnement.
Le freemium n'est pas un frein, c'est un accélérateur. Les limites doivent porter sur la quantité, pas sur la qualité de l'expérience.
Leçon n°2 : Le Fond ET la Forme, l'Éternel Débat du Curseur
J'ai passé beaucoup de temps à construire une interface propre, un parcours utilisateur fluide. Je voulais que l'outil soit agréable à utiliser.
Mais plusieurs retours, notamment de quelques amis RH, pointaient une chose : la pertinence de l'analyse.
Le Problème : Des Scores Trop "Gentils"
L'écart de score entre un bon et un mauvais candidat n'était pas assez marqué. C'était trop "gentil". Tous les candidats se retrouvaient avec des scores entre 65 et 80, ce qui rendait le tri difficile.
Pourquoi ? Parce que vu que je partais de zéro sur ResumeRank, j'ai fait le "minimum" sur les prompts d'analyse de CV. J'avais passé de nombreuses heures à travailler sur tout ce qu'il y a autour (interface, UX, parcours d'analyse, fonctionnalités, etc.) mais moins sur le cœur du moteur.
💡 La Réalisation
Une belle carrosserie ne sert à rien si le moteur n'est pas assez puissant. J'avais fait le "minimum viable" sur l'analyse pour construire une belle expérience autour.
Les Changements Techniques Mis en Place
1. Changement de Cerveau : GPT-5
J'ai remplacé le modèle d'IA principal pour l'analyse par GPT-5. Il est plus récent, plus puissant, et apporte plus de nuances dans ses évaluations.
La différence est notable : GPT-5 comprend mieux les subtilités d'un parcours professionnel, détecte les incohérences, et évalue plus finement l'adéquation entre un profil et un poste.
2. Un Prompt Plus Sévère et Discriminant
J'ai complètement retravaillé mon prompt d'analyse pour qu'il soit plus "discriminant". L'objectif est de créer des écarts de score plus nets entre les profils :
- Mauvais candidat : 30-50/100
- Candidat moyen : 50-65/100
- Bon candidat : 65-80/100
- Excellent candidat : 80-95/100
Le prompt inclut maintenant des instructions explicites pour :
- Pénaliser les parcours incohérents
- Valoriser l'expérience pertinente
- Détecter les points faibles cachés
- Identifier les sur-qualifications
Ce Que J'en Retiens
C'est un équilibre constant entre l'interface et le moteur. Maintenant, il est temps d'itérer et de renforcer le cœur du produit pour apporter encore plus de valeur.
La leçon : il faut construire rapidement pour tester le marché, mais ne jamais négliger la qualité du cœur de produit une fois les premiers utilisateurs arrivés.
Leçon n°3 : Automatiser le Feedback pour Ne Plus Naviguer à Vue
Ces premiers retours étaient de l'or, mais ils sont arrivés principalement parce que je les ai demandés manuellement.
Pour que ResumeRank continue d'évoluer, je ne peux pas dépendre de ma capacité à contacter chaque utilisateur individuellement. Je dois industrialiser la collecte de feedback.
La Règle Simple
Si un utilisateur a créé son compte depuis plus de 5 jours ET a fait au moins une analyse, il recevra automatiquement un email avec un formulaire très court.
Objectifs :
- Mesurer le NPS (Net Promoter Score)
- Identifier les points de friction
- Collecter des suggestions d'amélioration
- Segmenter les retours par langue (FR/EN)
🎯 Les Questions Clés du Formulaire
1. NPS : "Sur une échelle de 0 à 10, recommanderiez-vous ResumeRank ?"
2. Satisfaction : "Quelle fonctionnalité appréciez-vous le plus ?"
3. Friction : "Qu'est-ce qui vous a frustré ou bloqué ?"
4. Suggestions : "Quelle fonctionnalité aimeriez-vous voir ajoutée ?"
5. Contexte : Champs cachés pour tracker la langue, le plan tarifaire, et le nombre d'analyses effectuées
Les Coulisses Techniques : Comment j'ai Automatisé la Collecte de Feedback en 30 Minutes
Pour les plus curieux, voici comment j'ai construit ce système en une seule session de développement.
C'est exactement le genre de tâche où le Model Context Protocol (MCP) brille : connecter plusieurs services, orchestrer des API, et déployer une automatisation complète sans écrire manuellement des centaines de lignes de code.
La Stack Technique
- Tally : Pour les formulaires (simple, beau, et avec un MCP)
- Supabase : Pour la base de données et les fonctions serverless
- Resend : Pour l'envoi des emails
- MCP (Model Context Protocol) : Mon "chef d'orchestre" IA pour tout piloter depuis Cursor
🤖 Le Pouvoir du MCP
Le Model Context Protocol permet à Cursor de se connecter directement aux APIs de mes outils (Tally, Supabase). Je peux lui demander "Crée-moi deux formulaires FR/EN dans Tally avec ces questions" et il le fait instantanément via l'API.
Le Processus en 5 Phases
Phase 1 : Formulaires Multilingues avec MCP Tally
J'ai choisi Tally parce qu'ils ont un MCP. Cela me permet de le connecter à Cursor et de lui demander directement :
"Crée-moi deux formulaires identiques (FR/EN) avec les questions suivantes : [liste des questions]. Ajoute des champs cachés pour user_id, plan, et langue."
En quelques secondes, Cursor a utilisé le MCP Tally pour :
- Créer deux formulaires via l'API Tally
- Configurer les questions en français et en anglais
- Ajouter les champs cachés pour le tracking
- Récupérer les URLs et IDs des formulaires
Temps passé : 5 minutes (au lieu de 30 minutes manuellement)
Phase 2 : Architecture de la Base de Données
Le MCP Supabase a créé deux nouvelles tables dans ma base de données :
-
Une table pour stocker les réponses : elle collecte les retours utilisateurs (NPS, fonctionnalité préférée, frustrations, suggestions) avec la langue et le plan tarifaire pour segmenter les analyses.
-
Une table pour suivre les invitations : elle évite de spammer un utilisateur qui a déjà reçu l'invitation en gardant une trace de qui a été contacté et quand.
Cette séparation permet de gérer proprement le cycle de vie des feedbacks : qui doit être contacté, qui l'a déjà été, et quelles réponses ont été données.
Temps passé : 3 minutes
Phase 3 : Les Edge Functions Serverless
L'IA a créé deux fonctions Supabase qui gèrent toute la logique :
Fonction 1 : Recevoir les Réponses de Tally
Cette fonction reçoit un webhook de Tally à chaque soumission de formulaire. Elle récupère les données (NPS, réponses, contexte utilisateur) et les stocke de manière structurée dans la base de données. Le mapping des champs est géré intelligemment pour s'adapter à la structure dynamique des formulaires Tally.
Fonction 2 : Envoyer les Invitations Automatiques
Cette fonction s'exécute quotidiennement et fait trois choses :
- Identifier les utilisateurs éligibles : compte créé depuis plus de 5 jours + au moins une analyse effectuée
- Générer l'URL du formulaire : avec les paramètres pré-remplis (user_id, plan, langue) pour tracker les réponses
- Envoyer l'email via Resend : dans la bonne langue (FR/EN) avec un lien personnalisé
Une fois l'email envoyé, elle enregistre l'invitation pour éviter les doublons.
Temps passé : 15 minutes (avec tests et corrections)
Phase 4 : Les Tests et Corrections (Les Galères)
Rien ne marche du premier coup. Voici les problèmes que j'ai rencontrés :
Problème 1 : Les Clés de Champs Tally Dynamiques
Les webhooks de Tally utilisent des IDs de champs générés dynamiquement, pas les labels que je vois dans l'interface. J'ai dû créer un formulaire test, le soumettre, et inspecter le payload pour comprendre la structure.
Solution : J'ai créé un mapping intelligent basé sur les types de champs et les mots-clés dans les labels.
Problème 2 : Authentification du Webhook
Tally peut envoyer des webhooks à n'importe qui. Il faut sécuriser l'endpoint.
Solution : Ajout d'un secret partagé dans l'URL du webhook et vérification côté serveur.
Problème 3 : La Détection de la Langue Préférée
Comment savoir si un utilisateur préfère recevoir l'email en français ou en anglais ?
Solution : J'ai ajouté un champ preferred_language dans la table users qui se remplit automatiquement en fonction de la langue de l'interface lors de l'inscription.
Temps passé : 10 minutes de debugging
Phase 5 : L'Automatisation CRON
Pour que tout fonctionne de manière autonome, j'ai configuré une tâche planifiée dans Supabase qui déclenche automatiquement la fonction d'envoi d'invitations tous les jours à 10h UTC.
Plus besoin de penser à envoyer les emails : le système tourne en pilote automatique.
Temps passé : 2 minutes
Les Résultats du Premier Lancement
Au premier lancement manuel (pour tester), le système a :
- Identifié 6 utilisateurs éligibles
- Envoyé 6 emails (5 FR, 1 EN)
- Reçu ma première réponse en moins de 30 minutes
💰 Le ROI de Cette Automatisation
Temps investi : 30 minutes de développement
Temps économisé par utilisateur : 30 minutes (rédaction email + suivi manuel)
Scalabilité : Infinie. Que j'aie 10 ou 10 000 utilisateurs, le système fonctionne pareil
Qualité des données : Structurées, segmentées, et prêtes à analyser
Résultat : Je passe de 30 minutes par utilisateur à zéro temps de gestion.
Pourquoi le MCP Change Tout
Avant le MCP, ce type de projet aurait pris plusieurs heures :
- Lire la documentation de Tally API
- Écrire manuellement les appels API
- Créer les tables SQL à la main
- Écrire les fonctions serverless ligne par ligne
- Débugger pendant des heures
Avec le MCP, Cursor a accès direct aux APIs et connaît déjà leur structure. Je lui donne l'intention, il génère l'implémentation.
L'IA qui a créé les formulaires est aussi celle qui a accès au back office de ResumeRank. Elle a donc directement créé les questions pertinentes en citant les bonnes fonctionnalités du produit.
C'est ça, le vrai pouvoir du MCP : l'orchestration intelligente entre plusieurs services.
La Suite : Direction l'Ouest !
Ces trois leçons et ces améliorations ne sont pas juste des pansements. Elles renforcent le produit pour la prochaine grande étape : l'attaque du marché américain.
Pourquoi les États-Unis ?
Le nom même de l'outil, ResumeRank, a été pensé "US-first". J'ai fait ce choix stratégique dès le début pour plusieurs raisons :
- Marché plus mature : Les RH américains sont plus habitués aux outils SaaS payants
- Pouvoir d'achat supérieur : Un abonnement à 29$/mois est plus accessible qu'en France
- Volume de recrutement : Les entreprises américaines recrutent en continu et à plus grande échelle
- Adoption rapide : La culture du "try and buy" est plus ancrée
Le Produit Est Prêt
Avoir un produit solide avant de prospecter, c'est essentiel. Maintenant, je peux affirmer que :
- ✅ Le "Aha Moment" est accessible gratuitement
- ✅ Le moteur d'analyse est puissant (GPT-5)
- ✅ L'interface est propre et professionnelle
- ✅ Le feedback est collecté automatiquement
- ✅ Le produit est 100% multilingue (FR/EN)
Avoir validé ces points avec mes premiers utilisateurs français me donne la confiance nécessaire pour aller chercher mes premiers utilisateurs payants aux États-Unis.
La Stratégie : Cold Email à l'Américaine
Mon plan d'attaque pour les prochaines semaines :
- Identifier les cibles : PME américaines en croissance (50-200 employés) avec des besoins récurrents en recrutement
- Pattern Interrupt : Créer un email qui sort du lot et capte l'attention
- Valeur immédiate : Offrir un test gratuit avec un cas d'usage concret
- Follow-up structuré : Séquence de 3-4 emails espacés de quelques jours
Ce sera l'objet du prochain chapitre de ce "Build in Public" : ma stratégie de cold email pour le marché US. On parlera scripts, "Pattern Interrupt", taux d'ouverture, et bien sûr, des résultats.
Conclusion : Écouter, Ajuster, Scaler
Ces trois leçons résument bien l'état d'esprit du Solo Builder :
- Ne cache jamais ta meilleure fonctionnalité → Les utilisateurs doivent vivre le "Aha Moment" avant de payer
- Le fond ET la forme → Une belle interface sans un moteur puissant, c'est une voiture de sport avec un moteur de 2CV
- Automatise tout ce qui est répétitif → Ton temps est précieux, utilise-le pour créer de la valeur, pas pour des tâches manuelles
Le feedback utilisateur, c'est l'or noir du produit. Mais il faut aller le chercher, le structurer, et l'intégrer rapidement dans le produit.
Maintenant, direction les États-Unis. 🇺🇸
Rejoins l'Aventure Build in Public
Si tu veux suivre la suite de cette aventure et recevoir mes prochains apprentissages, abonne-toi à la newsletter Make Time. Chaque semaine, je partage les coulisses de la construction de ResumeRank, mes erreurs, mes succès, et surtout, des astuces concrètes pour devenir un meilleur Solo Builder.
Tu peux aussi tester ResumeRank gratuitement et me donner tes retours. Chaque commentaire compte pour améliorer le produit.
Dans le Prochain Chapitre...
On va parler stratégie d'acquisition. Comment j'attaque le marché américain avec une stratégie de cold email, mes scripts, mes tests, et surtout : les résultats concrets. Taux d'ouverture, taux de réponse, conversions... tout sera transparent.
À très vite ! 👋