DEV Community: Rémi Alvado

Les erreurs à éviter quand on lance un MVP

Rémi Alvado — Wed, 02 Sep 2026 05:23:45 +0000

La plupart des MVP ne meurent pas d'un défaut technique. Ils meurent d'une série d'erreurs de jugement prises tôt, presque toujours les mêmes, presque toujours invisibles sur le moment. J'en vois passer plusieurs par trimestre, et les causes sont d'une régularité déprimante. La bonne nouvelle : ce sont des erreurs connues, donc évitables quand on les nomme avant de commencer.

Les erreurs les plus fréquentes au lancement d'un MVP sont : un périmètre qui dérive, construire avant d'avoir validé le besoin, le perfectionnisme qui repousse la sortie, l'absence de plan de distribution, confondre MVP et version 1, et ne jamais décider de la métrique qui dira si ça marche. Aucune n'est technique. Toutes se corrigent avant la première ligne de code.

Pour le cadre complet du premier produit, voyez le guide du MVP au PMF. Ici, on passe en revue les pièges concrets, dans l'ordre où ils font le plus de dégâts.

Les six erreurs qui reviennent le plus

Elles n'ont pas toutes le même poids. La première, la dérive de périmètre, est de loin la plus coûteuse parce qu'elle alimente toutes les autres. Les suivantes sont des variations sur un même thème : on construit trop, trop tôt, sur une hypothèse qu'on n'a pas pris la peine de vérifier.

Le fil rouge : on confond livrer et apprendre

Si on creuse, ces six erreurs partagent une racine unique. Le fondateur veut livrer un produit, alors que le but d'un MVP est d'apprendre quelque chose. Tout glisse de là. On ajoute des features pour que le produit soit « complet », on perfectionne pour qu'il soit « présentable », on repousse pour qu'il soit « prêt ». Or un MVP n'a pas à être complet ni présentable ni prêt. Il a à répondre vite à une question coûteuse.

Le réflexe qui désamorce les six

Avant chaque décision de scope ou de calendrier, posez une seule question : « est-ce que ça nous fait apprendre plus
vite, ou est-ce que ça repousse le moment d'apprendre ? » Ajouter une feature, polir un écran, attendre « que ce soit
propre » : presque toujours, ça repousse l'apprentissage. Le bon MVP est celui qui vous met le plus tôt possible
devant la vérité, agréable ou non.

Éviter les six d'un coup : cadrer avant de coder

La bonne nouvelle, c'est que ces erreurs se neutralisent toutes au même endroit, en amont, dans la phase de cadrage. Un périmètre tranché, une hypothèse formulée, une métrique de succès posée et un plan de distribution esquissé : quatre décisions prises avant le build, et la moitié des MVP que je vois échouer auraient tenu. Le coût d'un bon cadrage est dérisoire face à celui de trois mois de code sur la mauvaise hypothèse, un calcul que je détaille dans combien coûte un MVP.

C'est précisément le rôle d'un cadrage externe : nommer les pièges avant qu'ils ne coûtent, et tenir la ligne quand la pression de « rajouter juste ça » revient. On ne supprime pas le risque d'un MVP, on s'assure qu'il porte sur la bonne question.

On sécurise votre lancement ensemble ?

J'interviens comme CTO fractional armé d'IA pour cadrer votre MVP, trancher le périmètre et poser la métrique qui
comptera. Découvrez le Sprint Fondateur, ou réservons 30
minutes pour auditer votre plan de lancement.

Comment réduire le périmètre de son MVP

Rémi Alvado — Tue, 01 Sep 2026 05:23:18 +0000

Tout le monde sait qu'un MVP doit être petit. Personne n'arrive à le rendre petit. Chaque fonctionnalité a son avocat, sa bonne raison, son « mais si un client demande ça ». Réduire le périmètre, ce n'est pas un exercice de bon sens, c'est un exercice de courage : il faut dire non à des idées qui ne sont pas mauvaises, juste pas prioritaires.

Réduire le périmètre de son MVP, c'est garder le seul parcours qui teste votre hypothèse la plus risquée, et reporter tout le reste. La bonne méthode n'est pas de lister ce qui serait utile, mais de classer chaque feature en must, should ou cut, puis de défendre chaque must à voix haute. Ce qu'on ne sait pas défendre, on le coupe.

Si vous cadrez votre tout premier produit, le cadre d'ensemble est dans le guide du MVP au PMF. Ici, on regarde l'opération précise et inconfortable : couper.

La feature qu'on garde « au cas où » est un aveu

Quand une fonctionnalité reste dans le scope avec pour seule justification « au cas où », ce n'est pas une décision, c'est une absence de décision. Personne n'a osé la défendre vraiment, personne n'a osé la couper. Elle survit par inertie, et elle coûte : du temps de build, de la surface de bug, de la complexité dans l'interface, du retard sur la mise en marché.

Le test est simple. Pour chaque feature, demandez à voix haute : « Quelle hypothèse précise cette fonctionnalité teste-t-elle, et que se passe-t-il si on la retire du premier lancement ? » Si la réponse tient en une phrase claire, c'est probablement un must. Si la réponse est floue, hésitante, défensive, vous tenez votre prochaine coupe.

La méthode : must, should, cut

Oubliez les matrices à quatre quadrants et les scores pondérés. Sous pression, une équipe a besoin de trois cases, pas de douze. Chaque fonctionnalité candidate tombe dans l'une d'elles, et la règle de répartition est volontairement brutale.

Le « non » est un acte de design, pas un échec

Dans la tête de beaucoup de fondateurs, couper une fonctionnalité revient à appauvrir le produit. C'est l'inverse. Un produit n'est pas la somme de ce qu'il fait, c'est la clarté de ce pour quoi il existe. Chaque « non » resserre cette clarté. Le designer qui compte n'est pas celui qui ajoute, c'est celui qui retire jusqu'à ce qu'il ne reste que l'essentiel et que l'essentiel devienne évident.

Cette logique rejoint directement la question du volume : un MVP ne se mesure pas en nombre de features, mais en complétude d'un seul parcours, comme je le détaille dans combien de fonctionnalités dans un MVP. Réduire le périmètre et compter les features sont les deux faces de la même discipline.

Pourquoi un regard externe coupe mieux

Le plus dur, quand on coupe son propre produit, c'est qu'on a un attachement à chaque idée. Vous avez vendu cette feature à un associé, promise à un early adopter, imaginée à 2 h du matin. Un externe n'a pas cet historique affectif. Il pose la seule question qui compte, « ça teste quoi ? », sans ménager personne, et il assume le « non » à votre place quand vous n'y arrivez pas.

C'est exactement le rôle que je joue en cadrage de MVP : forcer la défense de chaque must, écrire les cut noir sur blanc, et protéger la V1 de la dérive. Un périmètre trop large, c'est aussi la première cause d'un budget qui dérape, comme je l'explique dans MVP qui coûte trop cher. Couper tôt, c'est dépenser juste.

On taille votre périmètre ensemble ?

J'interviens comme CTO fractional armé d'IA pour ramener votre MVP au seul parcours qui prouve votre hypothèse.
Découvrez le Sprint Fondateur, ou réservons 30
minutes pour trier votre scope avant de lancer le build.

Startup : construire ou acheter une solution ?

Rémi Alvado — Mon, 31 Aug 2026 05:23:49 +0000

« On va tout développer en interne, comme ça on maîtrise. » C'est l'un des réflexes les plus coûteux du démarrage. Vouloir tout construire soi-même, c'est dépenser ses semaines les plus précieuses à réinventer des briques que des milliers d'entreprises ont déjà résolues mieux que vous ne le ferez au début. La vraie question n'est pas « construire ou acheter », mais « construire quoi, et acheter quoi ».

L'arbitrage build vs buy se décide composant par composant, pas en bloc. La règle : on construit ce qui fait la valeur unique de votre produit (votre coeur métier), et on achète tout le reste, surtout les briques sensibles et standardisées comme l'authentification, le paiement ou la recherche. Coder soi-même ces briques au démarrage est presque toujours une erreur de priorité.

Si vous cherchez d'abord à cadrer le périmètre de votre premier produit, c'est dans le guide du MVP au PMF. Ici, on regarde un arbitrage précis : quoi coder, quoi assembler.

Le cadre : construire le coeur, acheter le reste

L'erreur classique consiste à traiter le produit comme un bloc à construire ou non. En réalité, un produit est fait de dizaines de composants, et chacun mérite sa propre décision. Le bon critère est simple : ce composant fait-il partie de ce qui vous différencie, ou est-ce une commodité que tout le monde a ?

Votre coeur métier, c'est la raison pour laquelle un client vous choisit vous plutôt qu'un autre : votre algorithme, votre expérience particulière, votre logique propre. Ça, vous devez le construire, parce que personne ne le vendra à votre place et que c'est là que se loge votre avantage. Tout le reste (se connecter, payer, chercher, envoyer un email) est une commodité résolue depuis longtemps par des acteurs spécialisés. La recoder, c'est dépenser votre budget le plus rare à fabriquer ce que vous pourriez brancher en quelques jours.

Ce qu'on ne doit jamais coder soi-même au début

Certaines briques cumulent deux propriétés qui les rendent toxiques à construire en interne : elles sont standardisées (donc sans valeur différenciante) et sensibles (donc dangereuses à rater). Les coder soi-même au démarrage, c'est prendre un risque maximal pour un gain nul.

Composant	Pourquoi ne pas le coder au début	À acheter / brancher
Authentification	Sécurité critique, faille = fuite de données, zéro valeur	Solution d'auth managée (OAuth, magic link)
Paiement	Conformité, fraude, réglementation : un métier en soi	Prestataire de paiement établi
Recherche (search)	Pertinence et scalabilité difficiles, très chronophage	Moteur de recherche spécialisé
Emails transactionnels	Délivrabilité, anti-spam, infrastructure lourde	Service d'envoi dédié
Stockage de fichiers	Durabilité, CDN, coûts cachés	Stockage objet d'un fournisseur cloud

Le point commun de ces briques : les rater coûte très cher (faille de sécurité, paiement défaillant, emails qui finissent en spam) et les réussir ne vous différencie en rien. Aucun client ne vous choisira parce que vous avez codé votre propre système d'authentification. Beaucoup vous quitteront si vous le ratez. Pour la recherche en particulier, le choix de la brique rejoint celui de la stack, que je détaille dans choisir sa stack technique.

Les vraies limites du « buy »

Soyons honnêtes : acheter n'est pas magique. Les briques tierces ont des coûts qu'il faut anticiper. Une dépendance externe, c'est un fournisseur qui peut augmenter ses prix, changer ses conditions, ou disparaître. C'est aussi une facture qui grandit avec votre volume, parfois plus vite que prévu. Le « buy » n'est pas gratuit, il est juste presque toujours moins cher que le « build » au démarrage.

La parade tient en un mot : la réversibilité. Quand vous branchez une brique externe, isolez-la derrière votre propre couche, de façon à pouvoir en changer sans réécrire la moitié du produit. C'est exactement le réflexe qui évite le lock-in propriétaire, le même que je décris pour l'hébergement dans cloud public ou VPS. Vous achetez la vitesse aujourd'hui, sans vous enfermer pour demain.

Et la frontière entre build et buy n'est pas figée. Une brique qu'on achète au démarrage peut devenir un candidat au build une fois que le volume le justifie économiquement, ou qu'elle devient un point de différenciation. Mais c'est une décision qu'on prend plus tard, avec des données réelles, pas par principe au jour un.

La question à se poser composant par composant

Pour chaque brique de votre produit, posez-vous une seule question : « est-ce que coder ça moi-même me différencie, ou est-ce que ça me ralentit sur ce qui compte vraiment ? ». Si la réponse est « ça me différencie », construisez. Sinon, achetez, et investissez le temps gagné dans votre coeur métier.

Le pire scénario n'est pas de payer quelques abonnements à des outils tiers. C'est de brûler vos premiers mois et votre budget le plus rare à reconstruire ce qui existe déjà, pendant que la seule chose qui vous distingue, votre vraie valeur, reste à l'état d'idée. Au démarrage, la rapidité de mise en marché bat l'autonomie technique presque à chaque fois.

On cadre vos arbitrages build vs buy ensemble ?

J'interviens comme CTO fractional armé d'IA pour décider, composant par composant, ce qu'on construit et ce qu'on
assemble, et concentrer votre budget sur votre coeur métier. Découvrez le Sprint
Fondateur, ou réservons 30 minutes pour
trancher avant de coder.

Garder le contrôle de son produit délégué

Rémi Alvado — Fri, 28 Aug 2026 05:23:22 +0000

Déléguer le développement de son produit est souvent le bon choix. Le piège n'est pas la délégation elle-même : c'est de la faire sans filet, et de découvrir un an plus tard qu'on ne possède plus rien de ce qui compte. La bonne nouvelle, c'est que tout se joue au départ. Quelques garde-fous posés dès le premier jour suffisent à garder la main, pour un coût quasi nul.

Pour garder le contrôle de son produit quand on délègue le développement, il faut poser cinq garde-fous dès le départ : un dépôt de code sur un compte qu'on possède, tous les accès à son nom, une documentation-mémoire tenue à jour, des jalons de livraison concrets, et un tiers de confiance pour relire. Mis en place tôt, ils coûtent presque rien ; rattrapés trop tard, ils coûtent des mois.

Cet article est préventif : comment ne jamais perdre le contrôle. Si vous êtes déjà dans la situation inverse, sans aucune main sur votre prestataire, le playbook curatif pour reprendre la main est dans les 5 signaux qu'il est temps de structurer votre équipe.

Pourquoi tout se joue au départ

La perte de contrôle ne survient jamais d'un coup. Elle se construit en silence, décision par décision, parce qu'au début tout va bien et qu'on ne pense pas à se protéger. Le dépôt de code est créé sur le compte de l'agence « parce que c'est plus simple ». Les accès aux serveurs restent chez le prestataire « parce qu'il s'en occupe ». La documentation n'existe pas « parce qu'ils connaissent le projet par cœur ». Chacune de ces facilités est un verrou qui se referme.

La logique est imparable : un prestataire n'a aucun intérêt spontané à vous rendre autonome, parce que son chiffre d'affaires repose sur le fait de rester indispensable. Ce n'est pas de la malveillance, c'est de la mécanique. À vous, donc, de poser les conditions de votre autonomie dès le départ, quand vous êtes encore en position de force, avant de signer.

Les cinq garde-fous à poser dès le premier jour

Voici les cinq protections à mettre en place avant même que la première ligne de code ne soit écrite. Aucune n'est technique au point que vous ne puissiez l'exiger vous-même. Toutes sont gratuites tant qu'on les pose au départ.

Ces cinq garde-fous se renforcent l'un l'autre. Le dépôt que vous possédez ne vaut que si la documentation permet à un autre de le reprendre. Les jalons ne valent que si quelqu'un de votre côté peut vérifier qu'ils sont réellement atteints. Pris ensemble, ils font que vous restez le propriétaire effectif de votre produit, pas seulement son payeur.

Garde-fou par garde-fou : ce qu'on évite

Chacune de ces protections désamorce un risque précis, le même qui transforme une délégation saine en dépendance subie. Mis en regard, le contraste est net.

Garde-fou posé au départ	Le risque qu'il désamorce
Dépôt sur votre compte	Le code reste otage du prestataire, impossible à confier ailleurs
Accès à votre nom	Vous ne pouvez plus rien faire sans passer par l'agence
Documentation-mémoire	Le savoir part avec le prestataire le jour où il s'en va
Jalons vérifiables	L'avancement est déclaratif, vous payez sans preuve de progrès
Tiers de confiance	Personne pour repérer la dette qui s'accumule en silence

La logique de fond rejoint celle de la propriété intellectuelle : posséder le code ne suffit pas si vous n'en avez ni les accès, ni la mémoire, ni les moyens de le faire reprendre. La cession de droits et ces garde-fous opérationnels sont les deux faces d'une même protection. Je traite le versant juridique dans à qui appartient le code de mon application.

La posture qui change tout

Au fond, garder le contrôle n'est pas une question d'outils mais de posture. Déléguer le développement, ce n'est pas se décharger du produit : c'est confier sa construction tout en restant le gardien de l'actif. Les cinq garde-fous ne sont que la traduction concrète de cette posture. Le fondateur qui les pose dès le départ ne dépend de personne ; celui qui les néglige se réveille un an plus tard à la merci d'un prestataire.

Le bon réflexe tient en une phrase : déléguez l'exécution, jamais la propriété. Vous pouvez ne pas savoir coder et garder un contrôle total sur votre produit, à condition de poser ces conditions quand vous êtes encore en position de les exiger.

On met en place vos garde-fous ensemble ?

J'interviens comme CTO fractional pour structurer votre délégation dès le départ : dépôt, accès, documentation,
jalons, et le regard externe qui vérifie ce qu'on vous livre. Découvrez l'accompagnement
CTO, ou réservons 30 minutes pour
sécuriser votre projet avant de déléguer.

Quand refaire son MVP de zéro (ou pas)

Rémi Alvado — Wed, 26 Aug 2026 05:23:26 +0000

« On repart de zéro, ce sera plus propre. » C'est tentant, surtout quand le produit actuel agace au quotidien. Mais la refonte totale est l'une des décisions les plus coûteuses qu'un fondateur puisse prendre, et l'une des plus souvent regrettées. Avant de jeter le code existant, il faut être sûr que le problème est bien le code, et pas autre chose.

Dans la grande majorité des cas, non, il ne faut pas refaire son MVP de zéro. Une refonte totale recrée la même dette avec un an de retard, pendant que vous arrêtez d'avancer. La bonne réponse est presque toujours un refactor module par module sur la base existante. Le rebuild ne se justifie que face à des signaux structurels précis, pas à une simple gêne.

Si vous cherchez d'abord à cadrer ce que doit contenir votre produit avant d'en parler de refonte, c'est dans le guide du MVP au PMF. Ici, on tranche une seule question : faut-il reconstruire, ou réparer ?

Pourquoi la refonte totale est un piège

L'erreur de raisonnement est toujours la même. On regarde le code actuel, on le trouve sale, et on en conclut qu'un code neuf serait sain. Mais ce qui a produit la dette du premier MVP n'a pas disparu : c'est la pression du temps, le périmètre flou, les décisions prises vite faute de recul. Reconstruisez dans les mêmes conditions, et vous obtiendrez la même dette, juste plus tard.

Le coût caché d'un rebuild, ce n'est pas le temps de développement. C'est l'arrêt de la livraison. Pendant que vous reconstruisez à l'identique ce qui existe déjà, vos concurrents ajoutent des fonctionnalités, vos clients attendent, et votre produit n'avance pas. Vous payez deux fois : le coût de la réécriture, et le coût d'opportunité de tout ce que vous n'avez pas construit pendant ce temps.

Il y a aussi un piège psychologique. Le code qu'on n'a pas écrit soi-même paraît toujours pire qu'il ne l'est. Une bonne partie de ce qu'on prend pour de la dette technique n'est en fait que du code qu'on ne comprend pas encore, ou qu'on aborde sans la documentation qui en explique les choix.

Refactor module par module : la voie par défaut

La vraie alternative à la refonte totale, ce n'est pas « ne rien faire ». C'est améliorer le produit là où ça fait mal, un morceau à la fois, sans jamais arrêter de livrer. On isole le module qui pose problème, on le réécrit proprement derrière une interface stable, on le remplace, et on passe au suivant. Le produit reste vivant et utilisable à chaque étape.

Cette approche a un autre mérite : elle force à comprendre ce qui ne va vraiment pas. Souvent, en isolant le premier module, on découvre que le problème était concentré sur 20 % du code, et que les 80 % restants étaient parfaitement sains. On vient d'éviter une réécriture intégrale en réparant un cinquième du produit.

Les vrais signaux qui justifient un rebuild

Soyons justes : il existe des situations où repartir de zéro est la bonne décision. Mais ce sont des signaux structurels, pas une question de confort. La gêne quotidienne n'en fait pas partie. Voici ce qui justifie réellement un rebuild.

Signal	Pourquoi il justifie un rebuild	Ce qui ne le justifie PAS
Stack obsolète ou abandonnée	Plus de mises à jour de sécurité, recrutement impossible	« Ce n'est pas la techno que j'aurais choisie »
Modèle de données fondamentalement faux	Le produit a pivoté, l'architecture ne porte plus le métier	Quelques tables mal nommées
Aucun module isolable	Tout est si couplé qu'on ne peut rien réparer séparément	Du code peu commenté mais structuré
Coût de maintenance > coût de rebuild	Chaque correction en casse trois autres, durablement	Un bug récurrent identifié

La règle de décision tient en une phrase : on reconstruit quand la base existante empêche structurellement d'avancer, pas quand elle ralentit. Un produit qu'on peut encore faire évoluer, même péniblement, mérite presque toujours un refactor plutôt qu'un rebuild. Si votre budget a déjà dérivé sur ce produit, les leviers pour le reprendre sans tout jeter sont dans MVP qui coûte trop cher.

La question à se poser avant de décider

Avant de trancher, posez-vous la vraie question : « qu'est-ce qui m'empêche d'avancer, exactement ? ». Si la réponse est « le code est moche », ce n'est pas un motif de rebuild. Si la réponse est « je ne peux ajouter aucune fonctionnalité sans tout casser, et ça dure depuis des mois malgré les corrections », alors on est peut-être dans un vrai cas de reconstruction.

Le rebuild se décide sur des faits, pas sur une impression

Avant de valider une refonte totale, exigez une cartographie honnête : quels modules sont sains, lesquels sont
réellement bloquants, et combien de temps un refactor ciblé prendrait par rapport à un rebuild complet. Si personne ne
peut produire cette carte, le problème n'est pas le code : c'est qu'il manque quelqu'un capable de le lire.

Dans la plupart des cas, le diagnostic révèle qu'on n'avait pas besoin de tout refaire. On avait besoin de comprendre le produit existant, d'isoler ce qui posait vraiment problème, et de le réparer méthodiquement. C'est moins spectaculaire qu'un grand rebuild, mais c'est ce qui garde l'entreprise en mouvement.

On regarde votre produit ensemble avant de tout jeter ?

J'interviens comme CTO fractional armé d'IA pour poser le bon diagnostic : ce qui est sain, ce qui est bloquant, et le
chemin le moins coûteux pour reprendre la main. Découvrez l'accompagnement CTO, ou
réservons 30 minutes pour trancher refactor ou rebuild.

Mon produit plaît mais personne ne paie

Rémi Alvado — Tue, 25 Aug 2026 05:23:30 +0000

« Tout le monde adore, les retours sont excellents, mais les ventes ne décollent pas. » C'est l'un des moments les plus déroutants pour un fondateur : un produit qui plaît visiblement, et pourtant personne qui sort sa carte. Le réflexe est de conclure qu'il manque une fonctionnalité. C'est presque toujours la mauvaise piste.

Quand un produit plaît mais ne se vend pas, le problème est rarement le produit lui-même : c'est la valeur perçue et la disposition à payer. Les gens apprécient sans acheter parce que vous ne résolvez pas un problème assez douloureux, ou que votre prix et votre offre ne traduisent pas la valeur. On tranche entre les deux avant de coder quoi que ce soit.

Si vous en êtes encore à décrocher vos tout premiers acheteurs, lisez d'abord trouver ses premiers clients sans budget. Ici, on traite le cas particulier où l'intérêt existe mais ne se convertit pas en revenu.

« Ça plaît » n'est pas « j'achète »

Le piège commence avec un faux signal. Des compliments, des inscriptions, des « super idée, je vais tester » : tout ça flatte, et rien de tout ça ne valide que votre produit a un marché payant. Apprécier un produit et payer pour l'avoir sont deux décisions différentes, séparées par un fossé que beaucoup de fondateurs ne voient qu'au moment de facturer.

La raison est simple : dire qu'on aime ne coûte rien, payer engage. Un utilisateur sincèrement enthousiaste peut ne jamais acheter parce que le problème que vous résolvez, tout réel qu'il soit, ne lui fait pas assez mal pour ouvrir son portefeuille. C'est inconfortable à entendre, mais c'est l'information la plus utile que le silence des ventes vous donne.

Problème de valeur perçue ou problème de produit ?

Avant de toucher au produit, il faut savoir lequel des deux maux vous frappe, parce qu'ils n'appellent pas du tout les mêmes corrections. Confondre les deux, c'est risquer de passer des mois à construire des fonctionnalités alors que le vrai sujet est votre offre, ou l'inverse.

L'ordre compte : on suspecte d'abord la valeur perçue, parce que c'est le cas le plus fréquent et le moins coûteux à corriger. On ne se rabat sur l'hypothèse « problème de produit » qu'une fois que le ciblage, le discours et le prix ont été testés et qu'on bute toujours sur le même manque cité par les prospects eux-mêmes.

Comment trancher, concrètement

On ne tranche pas par intuition, on tranche en allant chercher l'information là où elle est : auprès de ceux qui n'ont pas acheté. Ce sont eux qui détiennent la réponse, pas vos utilisateurs satisfaits. Voici les trois sondes qui révèlent la cause en quelques conversations.

Ces trois sondes mènent presque toujours au même verdict : dans la grande majorité des cas, ce n'est pas le produit qu'il faut refaire, c'est l'offre et le prix qu'il faut retravailler. Et c'est une bonne nouvelle, parce que c'est bien plus rapide à corriger que de relancer un chantier de développement.

Quand le problème est l'offre, pas le produit

Si le diagnostic pointe la valeur perçue, le levier le plus puissant est rarement de baisser le prix, c'est de mieux dire et mieux structurer ce que vous vendez. Un prix mal calé, trop bas par peur ou mal aligné sur la valeur, fait fuir autant qu'un prix trop haut. C'est tout le sujet de comment fixer le prix de son SaaS au lancement : le prix n'est pas une conséquence de vos coûts, c'est une traduction de la valeur perçue, et il se teste comme une hypothèse.

La façon dont vous laissez les gens découvrir le produit pèse tout autant. Un produit qu'on adore en démo mais qu'on n'achète pas souffre parfois simplement d'un mauvais modèle d'accès : un freemium qui retient les gens dans le gratuit ou un essai mal cadré peut tuer la conversion d'un produit pourtant aimé. Avant de conclure que votre produit est en cause, vérifiez que votre offre, votre prix et votre modèle d'accès donnent vraiment une raison de payer maintenant.

Le piège : construire pour répondre à un problème de prix

L'erreur classique quand les ventes ne décollent pas, c'est d'ajouter des fonctionnalités en espérant débloquer
l'achat. Si le vrai frein est la valeur perçue ou le prix, chaque fonctionnalité de plus aggrave le problème : elle
retarde le lancement, alourdit le produit et ne change rien à la décision d'achat. Diagnostiquez avant de construire,
toujours dans cet ordre.

Le réflexe de dirigeant à garder

Si je devais résumer : un produit qui plaît mais ne se vend pas est d'abord un signal sur votre offre, pas sur votre code. Allez interroger les non-acheteurs, testez la vraie disposition à payer, vérifiez votre ciblage et votre prix avant de toucher au produit. Neuf fois sur dix, vous trouverez que le problème était la valeur perçue et qu'il se corrige sans rouvrir le chantier de développement. La vente est une information, pas une finalité : écoutez ce que son absence vous dit.

Diagnostiquer pourquoi votre produit ne se vend pas ?

J'interviens comme CTO et CPO fractional pour trancher entre problème d'offre et problème de produit, et recadrer
valeur, prix et ciblage avant de relancer le moindre développement. Découvrez le Sprint
Fondateur, ou réservons 30
minutes pour comprendre pourquoi personne ne paie encore.

Combien d'utilisateurs avant de lever des fonds ?

Rémi Alvado — Mon, 24 Aug 2026 05:23:31 +0000

« Il me faut combien d'utilisateurs pour lever ? » La question revient à chaque préparation de tour, et la réponse attendue est un chiffre rond rassurant. Sauf qu'un investisseur ne compte pas des inscrits : il lit des signaux de traction, et ces signaux ne sont pas les mêmes selon votre modèle économique. Le nombre brut d'utilisateurs est souvent la métrique la moins parlante.

Il n'existe pas de seuil universel d'utilisateurs avant de lever : le bon repère, c'est la traction qui compte pour votre modèle. Un SaaS B2B se juge sur quelques clients payants et leur rétention, un produit grand public sur l'usage et la croissance organique. On prépare donc les bons signaux, pas un nombre d'inscrits.

Attention à ne pas confondre cette question avec « combien d'utilisateurs pour valider un MVP », qui relève de la validation produit et que je traite dans le guide du MVP au Product-Market Fit. Ici, l'angle est la levée : quels signaux de traction rendent un tour crédible.

Un investisseur ne compte pas des inscrits

La première erreur est de croire qu'un gros nombre d'utilisateurs impressionne en soi. Un fonds expérimenté sait qu'on peut acheter des inscriptions, gonfler une base avec de la gratuité, ou afficher des comptes morts. Ce qu'il cherche, c'est la preuve qu'il se passe quelque chose de réel et de répétable : des gens qui reviennent, qui paient, qui en amènent d'autres.

Autrement dit, la traction n'est pas un volume, c'est une dynamique. Cent clients qui paient et restent valent mieux que cent mille inscrits gratuits qui ne reviennent pas. C'est cette nuance qui sépare un fondateur qui « a des chiffres » d'un fondateur qui « a de la traction ». Le premier impressionne une seconde, le second convainc.

Les signaux de traction par modèle

Le « bon nombre » dépend entièrement de ce que vous vendez et à qui. Un même chiffre d'utilisateurs peut être excellent pour un modèle et dérisoire pour un autre. Voici les signaux qui pèsent vraiment selon le type de business, en ordre de grandeur indicatif pour un tour d'amorçage.

Type de modèle	Le signal qui compte vraiment	Le volume brut compte…
SaaS B2B	Quelques clients payants, rétention, revenus récurrents	Peu : la qualité prime
SaaS B2C / grand public	Usage régulier, croissance organique, rétention par cohorte	Beaucoup, mais lié à l'engagement
Marketplace	Liquidité des deux côtés, transactions répétées	Modérément : l'équilibre prime
Produit transactionnel	Volume de transactions et revenu généré	Le revenu, pas les comptes

La lecture du tableau est simple : en B2B, dix clients qui paient et renouvellent valent une levée ; en grand public, il faut un usage massif et qui croît tout seul pour que le même tour soit crédible. Chercher « le nombre d'utilisateurs » sans préciser le modèle, c'est se tromper de question.

Le revenu récurrent, le signal qui parle à tous

S'il fallait retenir un seul indicateur transversal, ce serait le revenu récurrent. Il condense en un chiffre ce que les investisseurs veulent savoir : des gens trouvent assez de valeur pour payer, et ils continuent. C'est pour ça qu'un montant de revenus mensuels récurrents, même modeste, déclenche souvent plus d'intérêt qu'une grosse base gratuite.

value="Payants > inscrits"
label="le ratio que regarde un fonds : la traction se mesure en clients qui paient et restent, pas en comptes créés"
/>

Cela ne veut pas dire qu'il faut du revenu pour tout lever. Certains produits grand public lèvent sur l'usage et la croissance avant la monétisation. Mais dans ce cas, le signal d'usage doit être spectaculaire et organique : une rétention forte, un bouche-à-oreille qui amène des utilisateurs sans dépense d'acquisition. Sans revenu et sans usage exceptionnel, il n'y a pas de traction qui tienne devant un fonds, juste un produit qui existe.

Ce nombre n'est qu'une partie du dossier

Le piège serait de réduire votre préparation à un seul chiffre de traction. Le nombre d'utilisateurs ou de clients payants n'est qu'un des éléments qu'un investisseur croise. Il le met en regard du montant que vous demandez et du palier que cet argent doit débloquer, ce que je détaille dans combien lever en seed pour une startup : on lève pour atteindre la prochaine preuve, et la traction actuelle doit rendre ce palier crédible.

La traction se lit aussi à côté du reste : votre récit, votre équipe, votre marché, et la solidité de votre base technique. C'est l'ensemble que je décris dans ce que regardent les investisseurs en tech. Un beau chiffre d'utilisateurs ne sauve pas un dossier bancal ailleurs, et une traction modeste mais nette se défend très bien quand le reste est solide.

Le réflexe avant d'aller lever sur sa traction

Avant de vous demander « ai-je assez d'utilisateurs ? », posez la vraie question : « quelle est la dynamique que je
peux démontrer en trois chiffres ? » Choisissez les deux ou trois signaux qui comptent pour votre modèle (revenu
récurrent, rétention de cohorte, croissance organique), suivez-les proprement, et sachez les raconter. Un fondateur
qui présente une dynamique claire et honnête bat toujours celui qui brandit un gros nombre creux.

Le réflexe de dirigeant à garder

Si je devais résumer : arrêtez de chercher le nombre magique d'utilisateurs et identifiez les signaux de traction qui comptent pour votre modèle. En B2B, des clients payants qui restent ; en grand public, un usage massif et organique ; partout, du revenu récurrent quand c'est possible. Préparez ces signaux comme vous préparez votre deck, replacez-les dans la trajectoire de levée, et vous arriverez devant un fonds avec une dynamique à montrer plutôt qu'un compteur à justifier. C'est la différence entre lever sur des chiffres et lever sur une preuve.

Préparer les signaux de traction de votre levée ?

J'interviens comme CTO et CPO fractional pour identifier et instrumenter les bons signaux de traction, et rendre votre
base technique crédible face à un fonds. Voyez la préparation d'une opération
capitalistique, ou réservons 30
minutes pour cadrer ce que votre traction doit prouver.

Go-to-market d'une startup early stage

Rémi Alvado — Fri, 21 Aug 2026 05:23:27 +0000

« On verra le go-to-market quand le produit sera prêt. » Cette phrase coûte des mois à beaucoup de startups. Le go-to-market n'est pas une couche qu'on ajoute à la fin : c'est le pont entre ce que vous construisez et le marché qui doit l'acheter. Pensé trop tard, il transforme un bon produit en produit que personne ne sait comment vendre.

Le go-to-market d'une startup early stage, c'est la manière dont votre produit rencontre ses clients : quelle offre, pour quelle cible précise, par quel canal. On le séquence dans cet ordre, on ne le devine pas. Et on le câble dès le périmètre du MVP, pas après le lancement, parce qu'il décide de ce qu'il faut construire en premier.

Si vous cherchez déjà comment décrocher vos tout premiers acheteurs sans budget, c'est dans trouver ses premiers clients sans budget. Ici, on prend de la hauteur : la mécanique d'ensemble qui relie le produit au marché.

Le go-to-market, c'est le pont entre build et marché

Beaucoup de fondateurs vivent le produit et la vente comme deux phases successives : on construit, puis on vend. C'est une erreur de séquencement. Un produit se construit toujours pour quelqu'un de précis, qu'on atteint par un canal précis, avec une promesse précise. Si ces trois éléments ne sont pas posés, vous construisez à l'aveugle et vous le découvrez au pire moment, quand il faut vendre.

Le go-to-market n'est donc pas du marketing au sens « campagnes et budget ». C'est la réponse à une question structurante : comment ce produit arrive-t-il entre les mains de quelqu'un qui paie ? Y répondre tôt évite le scénario le plus coûteux en early stage, celui d'un produit fini et techniquement propre, mais sans chemin clair vers son premier euro.

Séquencer offre, cible, canal

Le réflexe classique est de partir du canal : « on va faire du LinkedIn », « on va faire du SEO ». C'est l'ordre inverse du bon. Le canal se déduit de la cible, et la cible se déduit de l'offre. On séquence donc en quatre temps, et chaque étape conditionne la suivante.

Cette séquence a une vertu : elle vous empêche de répondre « comment » avant d'avoir répondu « pour qui ». La plupart des go-to-market early stage échouent là, en choisissant un canal avant d'avoir resserré la cible.

Pourquoi je le câble dès le périmètre du MVP

C'est le point que je défends le plus auprès des fondateurs que j'accompagne. Le go-to-market ne se décide pas après le MVP, il oriente ce que le MVP doit contenir. Si votre canal d'acquisition est la recommandation entre dirigeants, votre produit a besoin d'un effet « waouh » démontrable en réunion. Si c'est le self-service en ligne, il lui faut un onboarding qui se passe de vous. Ce ne sont pas les mêmes priorités de build.

Câbler le go-to-market dès le périmètre, c'est donc s'assurer qu'on construit d'abord ce qui sert la vente, et qu'on remet à plus tard ce qui ne la sert pas encore. C'est exactement la logique de cadrage que je détaille dans le guide du MVP au Product-Market Fit : le périmètre minimum n'est pas « le moins de fonctionnalités », c'est « le moins de fonctionnalités qui permettent de vendre et d'apprendre ».

Si votre canal principal est…	Alors le MVP doit d'abord soigner…	Et peut remettre à plus tard…
La vente directe et le réseau	La démonstration de valeur en rendez-vous	Le self-service et l'inscription autonome
Le self-service en ligne	L'onboarding sans contact humain	Les fonctionnalités d'administration fine
La recommandation entre pairs	Le moment « waouh » facile à raconter	La profondeur fonctionnelle large
Le contenu et l'inbound	Une preuve publique et un parcours d'essai clair	Les intégrations sur mesure

Le tableau dit une chose simple : il n'y a pas de MVP universel, il y a le MVP que votre go-to-market exige. Décider le canal après coup, c'est risquer d'avoir construit la mauvaise moitié du produit.

Le test de cohérence offre-cible-canal

Posez les trois à voix haute : « Je vends [offre] à [cible précise] que j'atteins par [canal]. » Si la phrase sonne
faux, c'est qu'un maillon ne tient pas. Un canal de masse pour une cible de niche, ou une offre floue pour un segment
précis : ces incohérences se voient à l'oral bien avant de coûter cher en acquisition. Faites ce test avant d'écrire
une seule ligne de code de plus.

Le réflexe de dirigeant à garder

Si je devais résumer : traitez le go-to-market comme une décision de produit, pas comme une étape d'après. Séquencez offre, cible, canal dans cet ordre, refusez de disperser vos forces avant qu'un canal fonctionne, et laissez ce go-to-market décider de ce que vous construisez en premier. Un produit pensé avec son marché part avec une longueur d'avance sur un produit pensé seul. Et ces premières ventes structurées sont ce qui rendra crédible la suite, qu'il s'agisse de combien d'utilisateurs réunir avant de lever ou simplement de tenir votre trajectoire.

Câbler votre go-to-market dans le périmètre du MVP ?

J'interviens comme CTO et CPO fractional pour cadrer votre MVP et son chemin vers le marché ensemble, jamais l'un sans
l'autre. Découvrez le Sprint Fondateur, ou réservons 30
minutes pour aligner produit, cible et canal avant de
construire.

Trouver ses premiers clients sans budget marketing

Rémi Alvado — Thu, 20 Aug 2026 05:23:27 +0000

« Je finis le produit, ensuite je m'occupe des clients. » C'est l'ordre que choisit la plupart des fondateurs, et c'est presque toujours le mauvais. Sans budget marketing, vos premiers clients ne viendront pas d'une campagne : ils viendront de gens que vous allez chercher un par un, souvent avant même que le produit soit fini.

Pour trouver ses premiers clients sans budget, on inverse la logique habituelle : la distribution prime sur le produit. On part de son réseau direct, on vise quelques early adopters qui ont vraiment le problème, et on vend avant d'avoir tout construit. Le piège à éviter : distribuer gratuitement pour « faire du volume », ce qui ne valide rien.

Si vous cherchez d'abord à cadrer ce que doit contenir ce premier produit, c'est dans le guide du MVP au Product-Market Fit. Ici, on traite la question d'après : comment lui trouver ses tout premiers acheteurs sans dépenser un euro de publicité.

La distribution prime sur le produit

L'idée fausse la plus tenace en early stage, c'est que le meilleur produit finit toujours par gagner. Sur le terrain, c'est presque toujours celui qui se fait connaître et adopter qui gagne, même quand il est moins abouti. Un produit excellent que personne ne trouve ne vaut rien commercialement.

Concrètement, ça change l'ordre des priorités. Avant de polir une fonctionnalité de plus, demandez-vous comment vous allez mettre votre produit entre les mains de quelqu'un qui paiera. Si vous n'avez pas de réponse, le problème n'est pas votre produit, c'est votre distribution. Et c'est un problème qu'on travaille tôt, pas une fois le produit « prêt ».

Vos canaux gratuits, du plus chaud au plus froid

Sans budget, vos canaux ne sont pas des plateformes payantes, ce sont des relations. Tous ne se valent pas : certains amènent des clients en quelques jours, d'autres demandent des semaines de présence. On commence toujours par les plus chauds, ceux où une intention d'achat existe déjà.

L'ordre compte autant que la liste. On épuise le réseau direct et les communautés avant de se lancer dans du contenu de long terme : le premier amène des clients en jours, le second en mois. Quand le cash est court, on commence par ce qui paie vite.

Vendre avant d'avoir fini

C'est le réflexe le plus contre-intuitif, et le plus puissant. Vous n'avez pas besoin d'un produit terminé pour décrocher un premier client : vous avez besoin d'un problème réel et de quelqu'un prêt à payer pour sa solution. Présentez ce que vous construisez à de vrais prospects maintenant, et regardez s'ils sortent leur carte ou trouvent une excuse.

Un client qui s'engage avant que le produit soit fini vous donne deux choses qu'aucune étude de marché ne remplace : la preuve que le problème vaut qu'on paie, et une boucle de feedback sur le seul produit qui compte, celui qu'on achète. À l'inverse, finir le produit dans son coin puis chercher des acheteurs, c'est découvrir trop tard que personne n'en voulait au prix où vous le proposez. Vendre tôt n'est pas malhonnête tant que vous êtes transparent sur l'état d'avancement : c'est la façon la plus rapide de valider que vous construisez la bonne chose.

Le piège du « gratuit » qui ne valide rien

Quand on n'a pas de clients, la tentation est forte de distribuer le produit gratuitement pour « faire du volume » et « prouver l'intérêt ». C'est un piège, parce que la gratuité ne valide presque rien de ce qui compte. Des gens qui prennent un produit gratuit ne vous disent pas s'ils paieraient, ils vous disent seulement qu'ils ne refusent pas ce qui ne coûte rien.

Le seul signal qui valide vraiment votre marché, c'est que quelqu'un sorte de l'argent. Un « oui, je prends, voici mon paiement » vaut cent inscriptions gratuites enthousiastes. C'est exactement la différence que je détaille dans mon produit plaît mais personne ne paie : l'usage gratuit mesure l'intérêt, jamais la valeur. Distribuer gratuitement pour gonfler des chiffres vous donne l'illusion de la traction sans sa substance.

Le test simple : est-ce que quelqu'un sort sa carte ?

Avant de conclure que votre produit « marche » parce que des gens l'utilisent, posez-vous la vraie question : combien
ont payé ? Si la réponse est zéro, vous n'avez pas encore de traction, vous avez de la curiosité. Demandez un
engagement réel (un paiement, un acompte, un bon de commande) le plus tôt possible. C'est inconfortable, et c'est
précisément pour ça que c'est un bon test.

Le réflexe de dirigeant à garder

Si je devais résumer : traitez la distribution comme un chantier aussi sérieux que le produit, et démarrez-le aussi tôt. Activez votre réseau direct avant tout, allez chercher quelques early adopters qui ont vraiment le problème, vendez avant d'avoir tout fini, et méfiez-vous du gratuit qui flatte les chiffres sans valider le marché. Ces premiers clients payants ne sont pas qu'un revenu : ils sont la première preuve qui rendra crédible tout ce qui suit, du go-to-market à une éventuelle levée. La traction se construit une vente à la fois.

Cadrer produit et distribution ensemble ?

J'interviens comme CTO et CPO fractional pour cadrer votre MVP et la façon dont il rencontre ses premiers clients, pas
l'un sans l'autre. Découvrez le Sprint Fondateur, ou réservons 30
minutes pour trouver vos premiers acheteurs sans budget.

Business model SaaS B2B vs B2C : que choisir ?

Rémi Alvado — Wed, 19 Aug 2026 05:23:39 +0000

« On vise les entreprises, mais on ouvrira aussi au grand public. » Cette phrase, je l'entends souvent au tout début d'un projet SaaS, et elle cache un piège. B2B et B2C ne sont pas deux marchés qu'on adresse avec le même produit en changeant la page de prix. Ce sont deux trajectoires qui engagent, dès les premières semaines, votre architecture, votre produit et votre manière de vendre.

En early-stage, choisir entre un SaaS B2B et un SaaS B2C n'est pas un détail marketing : c'est une décision structurante qui oriente vos choix techniques, votre roadmap et votre go-to-market. Viser les deux à la fois disperse une équipe qui n'a pas les moyens de la dispersion. On tranche tôt, quitte à élargir plus tard une fois un premier marché tenu.

Cet article ne refait pas le tour des modèles économiques du web (ads, e-commerce, SaaS, affiliation, leurs métriques) : ici, on se concentre sur un seul arbitrage et ses conséquences concrètes quand on démarre.

B2B et B2C ne se construisent pas pareil

La tentation de viser large est naturelle : plus de cibles, plus de marché potentiel. Mais en early-stage, vos moyens sont comptés, et chaque heure passée à contenter deux logiques opposées est une heure de moins pour en réussir une. Or B2B et B2C divergent sur presque tout ce qui compte au départ. Voici les axes où le choix se paie cash.

Ce qui change	SaaS B2B	SaaS B2C
Le client	Quelques comptes à forte valeur	Une masse d'utilisateurs à faible valeur unitaire
L'archi clé	Multi-tenant, rôles, droits, SSO, audit	Tenir la charge, vitesse, simplicité d'accès
La vente	Sales, démos, cycles longs, contrats	Acquisition self-service, viralité, paiement immédiat
Le produit	Profondeur, intégrations, conformité	Onboarding limpide, rétention, plaisir d'usage
Le nerf de la guerre	Peu de clients, gros paniers, churn à surveiller	Volume énorme, coût d'acquisition à maîtriser

Lire ce tableau colonne par colonne fait apparaître l'évidence : ce ne sont pas deux variantes d'un produit, ce sont deux produits. Le B2B vous demande de construire en profondeur pour un petit nombre de clients exigeants. Le B2C vous demande de construire pour l'échelle et la simplicité, et de financer une acquisition de masse. Mélanger les deux dès le départ, c'est faire les deux à moitié.

Ce que le choix engage concrètement

Le plus important à comprendre, c'est que cet arbitrage se matérialise très vite dans le code et dans l'organisation. Il ne s'agit pas d'un positionnement qu'on ajustera plus tard sans douleur : certaines décisions des premières semaines sont coûteuses à défaire. Voici les quatre chantiers où le choix B2B ou B2C change tout, dans l'ordre où ils se posent.

Pourquoi viser les deux à la fois est un piège

L'erreur la plus coûteuse, en early-stage, c'est de refuser de choisir. « On fera du B2B et du B2C » sonne ambitieux, mais sur le terrain ça veut dire une archi tiraillée entre l'isolation par client et la charge grand public, un produit qui hésite entre profondeur et simplicité, et une équipe commerciale qui ne sait pas si elle prospecte des comptes ou optimise un tunnel d'inscription. À ce jeu, on ne tient bien aucun des deux marchés, et le concurrent qui en a choisi un vous dépasse sur ce terrain-là.

Choisir, c'est concentrer ses moyens limités là où ils font la différence. Ce n'est pas renoncer pour toujours : beaucoup de SaaS qui réussissent commencent par un marché, le tiennent solidement, puis ouvrent le second une fois la machine rodée et l'équipe étoffée. L'inverse (élargir avant d'avoir gagné un premier marché) revient à se disperser au moment où la concentration compte le plus. C'est exactement la logique de cadrage d'un MVP qu'on veut valider sans sur-construire, que je détaille dans le guide du MVP au Product-Market Fit.

Comment trancher quand on démarre

Pour décider, je pars de trois questions simples. La première : qui ressent le problème assez fort pour payer maintenant, une poignée d'entreprises ou une foule de particuliers ? La valeur la plus aiguë désigne souvent le marché de départ. La deuxième : avez-vous les moyens d'une acquisition de masse ? Le B2C pur consomme énormément de cash en acquisition, et beaucoup d'acteurs ont fini par pivoter vers le B2B faute de pouvoir financer cette course. La troisième : votre produit délivre-t-il sa valeur seul, ou faut-il l'installer dans le contexte d'un client ? Cette réponse rejoint directement le choix entre freemium et essai gratuit et celui de votre prix de lancement, qui ne se posent pas du tout de la même façon en B2B et en B2C.

Le but n'est pas de prédire l'avenir, c'est d'engager vos premières semaines sur une seule trajectoire claire. Un SaaS qui gagne un marché peut presque toujours en conquérir un autre ensuite. Un SaaS qui veut les deux dès le premier jour finit souvent par n'en tenir aucun. Choisir tôt, c'est se donner les moyens d'élargir plus tard.

Arbitrer votre trajectoire SaaS ?

J'interviens comme CTO et CPO fractional pour cadrer votre MVP et l'aligner sur une trajectoire de marché tenable,
archi et go-to-market compris. Découvrez le Sprint Fondateur, ou réservons 30
minutes pour poser le bon arbitrage dès le départ.

Freemium ou essai gratuit pour son produit ?

Rémi Alvado — Tue, 18 Aug 2026 05:23:30 +0000

« Tout le monde fait du freemium, on fait pareil ? » La question revient à chaque lancement de SaaS, et la réponse par défaut (copier le modèle à la mode) est souvent la plus chère. Freemium et essai gratuit ne sont pas deux saveurs de la même chose : ce sont deux stratégies d'acquisition qui supposent des produits, des coûts et des cibles différents.

Pour choisir, une règle simple suffit dans la plupart des cas : si votre produit délivre une valeur évidente en moins de cinq minutes d'utilisation, le freemium peut marcher ; sinon, un essai gratuit de quatorze jours convertit mieux. Et avant de dire oui au freemium, il faut chiffrer son coût caché : l'infrastructure et le support de tous ces utilisateurs qui ne paieront jamais.

Si vous n'avez pas encore arrêté votre prix payant lui-même, lisez d'abord comment fixer le prix de son SaaS au lancement. Ici, on traite la marche d'avant : comment vous laissez les gens découvrir ce produit.

Deux modèles, deux promesses

Le freemium offre un palier gratuit pour toujours, volontairement limité, dont on espère qu'une fraction des utilisateurs basculera un jour vers le payant. L'essai gratuit donne un accès complet pendant une période courte, après quoi il faut payer pour continuer. La différence n'est pas cosmétique : l'un mise sur le volume et le temps long, l'autre sur l'intensité et l'urgence.

Aucun des deux n'est supérieur dans l'absolu. Le freemium a fait la fortune de produits qui se prennent en main en un coup d'œil et se diffusent d'eux-mêmes. L'essai gratuit reste le choix le plus sûr pour un produit B2B qui demande qu'on l'installe dans un contexte avant d'en sentir la valeur. Le bon réflexe n'est pas de suivre la mode, c'est de partir de votre produit.

La règle des cinq minutes

Voici le critère que j'utilise pour trancher vite. Posez-vous une seule question : un utilisateur seul, sans démo ni accompagnement, comprend-il la valeur de votre produit en moins de cinq minutes ? Si oui, le freemium est jouable, parce qu'un compte gratuit peut atteindre ce moment de déclic tout seul et donner envie de plus. Si non, le freemium se sabote lui-même : les gens s'inscrivent, ne voient rien, et le palier gratuit devient un cimetière de comptes morts.

Quand la valeur met du temps à se révéler (il faut importer ses données, connecter un outil, inviter son équipe, voir le produit tourner sur un vrai cas), l'essai gratuit fait mieux. La date de fin crée une raison de s'y mettre maintenant, et l'accès complet permet d'atteindre la valeur avant l'échéance. C'est le même esprit que pour valider un produit sans sur-investir, détaillé dans le guide du MVP au Product-Market Fit : on cherche le chemin le plus court vers la preuve, ici la preuve que le produit vaut qu'on paie.

Une nuance utile : les deux ne s'excluent pas toujours. On peut lancer en essai gratuit pour apprendre à convertir, puis ouvrir un freemium plus tard, une fois qu'on sait quelle limite déclenche le passage au payant. L'inverse est plus risqué : partir en freemium sans savoir convertir, c'est financer une foule gratuite en espérant qu'elle paie un jour.

Le coût caché du freemium

C'est l'angle mort le plus fréquent. Le freemium n'est pas gratuit pour vous : chaque utilisateur du palier gratuit consomme des ressources réelles, et la grande majorité ne paiera jamais. Avant de l'adopter, mieux vaut regarder en face ce que cette gratuité vous coûte, mois après mois.

Aucun de ces coûts n'est rédhibitoire si le modèle est pensé pour. Mais ils expliquent pourquoi tant de freemium échouent : on a regardé le volume d'inscrits en se réjouissant, sans voir que chaque inscrit gratuit creusait un peu plus la marge. Un freemium qui marche est un freemium dont on a borné le coût (limites strictes du palier gratuit, support prioritaire réservé aux payants, fonctionnalités coûteuses gardées pour le payant) et dont on sait précisément ce qui déclenche le passage à la caisse.

Comment décider, en pratique

Le raisonnement tient en peu de mots. Si votre produit se comprend seul en quelques minutes, qu'un compte gratuit coûte peu à servir, et que vous visez un très large public, le freemium peut être un moteur d'acquisition puissant. Si votre produit demande qu'on l'installe dans un contexte avant d'en sentir la valeur, ou que servir un utilisateur coûte cher, l'essai gratuit de quatorze jours est le choix sûr : il convertit mieux et ne vous fait pas porter une foule gratuite.

Dans le doute, commencez par l'essai gratuit. Il vous apprend à convertir et vous coûte moins cher à opérer pendant que vous cherchez votre marché. Le freemium, lui, se décide plus tard, quand vous savez exactement quelle limite pousse vos utilisateurs à payer. C'est aussi à ce moment que se pose la question du modèle de revenus complet, que je traite dans le panorama des business models du numérique.

Choisir le bon modèle d'acquisition ?

J'interviens comme CTO et CPO fractional pour cadrer votre MVP, son modèle de revenus et sa stratégie de conversion.
Découvrez le Sprint Fondateur, ou réservons 30
minutes pour décider freemium ou essai selon votre produit.

Comment fixer le prix de son SaaS au lancement

Rémi Alvado — Mon, 17 Aug 2026 05:23:26 +0000

« On met combien ? » La question tombe souvent à la dernière minute, juste avant d'ouvrir les inscriptions, et la réponse improvisée est presque toujours la même : un prix rond, modeste, calé sur la peur de faire fuir les premiers clients. C'est une erreur qui coûte cher, et elle se paie longtemps.

Le prix d'un SaaS au lancement ne se déduit pas de vos coûts mais de la valeur que vous créez pour le client. On choisit d'abord une value metric (l'unité qui suit cette valeur), on fixe un premier prix volontairement haut, et on le traite comme une hypothèse à tester, exactement comme on teste le produit. Le piège numéro un, c'est le prix trop bas posé par peur.

Si vous hésitez encore sur le modèle de revenus lui-même (abonnement, usage, transaction), commencez par le panorama des business models du numérique. Ici, on suppose le modèle SaaS choisi, et on s'attaque au seul prix de départ.

Le coût ne dit rien du prix

Le réflexe naturel d'un fondateur, surtout s'il vient de la technique, c'est de raisonner en coût : combien me revient un utilisateur en infrastructure et en support, j'ajoute une marge, et j'obtiens mon prix. C'est rassurant parce que c'est calculable. C'est aussi une fausse piste, parce que le client ne paie pas vos coûts, il paie ce que votre produit lui rapporte ou lui évite.

Un logiciel qui fait gagner deux jours par mois à une équipe, ou qui évite une erreur à dix mille euros, vaut pour le client une fraction de ce qu'il lui fait gagner. Que cette valeur vous coûte trois euros ou trente à servir ne change rien à ce qu'elle vaut pour lui. Le pricing au coût laisse donc presque toujours de l'argent sur la table, et il envoie au passage un signal de faible valeur.

Cela ne veut pas dire qu'on ignore les coûts. Ils fixent un plancher (en dessous, vous perdez de l'argent à chaque client) et ils comptent énormément sur les modèles à forte composante d'infrastructure. Mais ils ne fixent jamais le prix lui-même. Le prix, c'est une conversation avec la valeur perçue, pas avec votre comptabilité.

La value metric : sur quoi vous facturez

La décision la plus structurante n'est pas le montant, c'est l'unité sur laquelle vous le faites varier. C'est ce qu'on appelle la value metric : le compteur qui fait monter la facture quand le client tire plus de valeur de votre produit. Bien choisie, elle aligne votre revenu sur le succès du client, et le prix paraît juste des deux côtés.

Trois grandes familles existent, et le choix dépend de ce que votre produit fait gagner. Le prix par siège convient quand la valeur vient du nombre de personnes qui l'utilisent. La facturation à l'usage (volume, transactions, consommation) convient quand la valeur suit l'intensité d'utilisation. Les paliers par fonctionnalités conviennent quand des segments très différents coexistent, des indépendants aux grands comptes. Beaucoup de SaaS combinent les trois : un palier d'entrée par fonctionnalités, puis un siège ou un volume qui fait grimper.

Value metric	La valeur vient de…	Quand c'est le bon choix
Par siège (par user)	Le nombre de personnes qui s'en servent	Outils collaboratifs, adoption en équipe
À l'usage / volume	L'intensité d'utilisation	Stockage, transactions, API, traitement de données
Paliers fonctionnels	Des segments aux besoins distincts	Du freelance au grand compte sur un même produit

Le premier prix est une hypothèse, pas une gravure

Voilà le point que je martèle le plus auprès des fondateurs : votre prix de lancement n'est pas une décision définitive, c'est votre première hypothèse de prix. Vous ne validez pas votre produit en le décrétant bon, vous le confrontez au marché. Le prix obéit exactement à la même logique. Vous posez un chiffre, vous regardez comment le marché réagit, et vous ajustez.

Cela a une conséquence pratique forte : commencez plutôt trop haut que trop bas. Baisser un prix est facile et bien perçu (une promotion, un geste commercial). Le monter après coup est douloureux, vous froissez vos premiers clients et vous donnez l'impression de vous être trompé. Un prix de départ ambitieux vous laisse de la marge dans les deux sens. Un prix de départ timide vous enferme. C'est le même principe que pour un produit qu'on veut valider sans sur-investir, que je détaille dans le guide du MVP au Product-Market Fit : on pose une hypothèse claire, et on la teste pour de vrai.

L'erreur du « trop bas par peur »

Le réflexe le plus répandu, et le plus coûteux, c'est de fixer un prix bas parce qu'on craint de ne convaincre personne. C'est compréhensible, et c'est presque toujours une mauvaise idée. Un prix trop bas attire les mauvais clients, ceux qui partent au premier accroc et saturent votre support pour quelques euros. Il prive votre produit de la marge nécessaire pour s'améliorer. Et il envoie un signal de faible valeur, qui dévalue ce que vous vendez avant même qu'on l'essaie.

Le test de prix n'est d'ailleurs pas un test de génie commercial, c'est un test de lucidité. Si personne ne trouve votre prix un peu élevé, c'est probablement qu'il est trop bas. Un bon prix de lancement provoque quelques résistances, qui vous renseignent : sur qui est vraiment votre cible, sur ce qu'elle valorise, sur les segments à séparer. Un prix qui ne fait jamais sourciller ne vous apprend rien et vous appauvrit.

La bonne posture est donc à l'opposé de l'improvisation de dernière minute. On choisit une value metric alignée sur la réussite du client, on pose un premier prix ambitieux assumé comme une hypothèse, et on se donne les moyens de l'ajuster vite à la lumière des premières ventes. Le prix n'est pas une ligne dans un fichier, c'est un levier de produit à part entière, et un des plus rentables à manier tôt.

Ce prix ne se décide pas en vase clos. Il se règle différemment selon que vous laissez les gens découvrir le produit en freemium ou en essai gratuit, et selon que vous visez un marché B2B ou B2C, deux trajectoires qui ne valorisent pas du tout les mêmes choses. C'est aussi cette traction prix-revenus naissante qui rendra crédible un premier tour : un pricing tenu fait partie de ce qu'on montre pour lever en seed.

Caler votre pricing de lancement ?

J'interviens comme CTO et CPO fractional pour cadrer votre MVP et son modèle de revenus, value metric comprise.
Découvrez le Sprint Fondateur, ou réservons 30
minutes pour poser un prix de départ qui ne vous enferme pas.