Vendre avant de coder, time-to-value sous 5 min, pricing avant feature, observabilité produit, multi-tenant natif : ce qui sépare les SaaS qui décollent de ceux qui dorment.
Lancer un SaaS B2B en agence, c'est moins une question de tech que de discipline produit. Cinq produits livrés en huit mois — voici ce qui sépare ceux qui décollent de ceux qui dorment.
Chez Ubuntu Consulting, j'ai livré cinq SaaS B2B sur huit mois : Prospect-Pro AI, RunWeek, HomeEnergy, MailCraft et une plateforme d'enrichissement de données. Trois ont trouvé une traction commerciale rapide. Deux n'ont jamais décollé malgré une tech impeccable.
La différence n'est pas venue du code. Elle est venue de comment on a abordé le passage du MVP à la traction. Cet article condense les patterns que j'ai vu marcher.
Un MVP qui marche techniquement n'a aucune valeur si la promesse n'est pas claire. La promesse, c'est ce qu'on dit en une phrase au prospect.
Bonne promesse : "On automatise la prospection B2B avec scoring IA — 60 % de conversion en plus, 15 h économisées par semaine."
Mauvaise promesse : "On a une plateforme moderne de gestion de leads avec intelligence artificielle."
La première promet un résultat quantifié. La seconde décrit une catégorie. Sur les cinq produits, ceux qui n'ont pas trouvé de promesse claire sont restés des PoC techniques.
Le premier produit qui a marché (Prospect-Pro) a démarré par 12 entretiens utilisateurs avant qu'une seule ligne de code soit écrite. Format : 30 min, deux questions :
Aucune mention du produit envisagé. Juste écouter. Sur 12 entretiens, 8 ont décrit le même problème — fichiers Excel manuels, contacts vieux de 6 mois, messages génériques qui ne marchent pas.
C'est devenu le brief produit. La tech a suivi.
À l'inverse, les deux produits qui n'ont pas décollé ont démarré par "on a vu une opportunité techno" sans interviews préalables. Résultat : six mois de dev sur des fonctionnalités que personne n'avait demandées.
Avant le MVP fonctionnel, on a vendu trois licences sur démo "magicienne d'Oz" : interface réelle, backend trafiqué à la main. Les clients ne le savaient pas — pour eux, l'app marchait. Pour nous, ça validait que les gens étaient prêts à payer pour ce résultat précis, indépendamment de l'implémentation.
Ce pattern (Wizard of Oz MVP) demande du courage mais évite des mois de dev inutile. Si personne ne sort sa carte bleue sur la démo, le produit n'a pas de marché — quelle que soit la qualité de la tech qu'on aurait écrite.
Sur RunWeek, le premier essai sortait l'utilisateur après 14 minutes de setup (connexion Garmin, autorisation HealthKit, sélection de paramètres, import historique). On perdait 70 % des utilisateurs à l'étape 3.
Refonte du parcours :
Après refonte : time-to-value à 3 minutes 20. Taux d'activation x4.
La règle : chaque seconde de friction entre install et premier "wow" coûte de la rétention. Mesurer ce temps. Le baisser comme un sprint produit à part entière.
Erreur classique : empiler des fonctionnalités, puis chercher comment les vendre. Mieux : définir le pricing en premier, et n'ajouter que les features qui justifient le palier.
Sur HomeEnergy, trois paliers :
Chaque feature développée se demandait : "ça justifie un palier ou ça enrichit un palier existant ?" Si c'était ni l'un ni l'autre, on coupait.
Résultat : roadmap compacte, pricing lisible, taux de conversion gratuit → pro à 8 % (vs 1-3 % typique).
Sans données, on bricole à l'aveugle. Trois choses à instrumenter dès le MVP :
Chaque étape clé entre signup et premier "wow" est tracée. Sur Prospect-Pro :
| 1 | [Signup] → [Onboarding step 1] → [First search] → [First export] → [First contact sent] |
| 2 | 100% 78% 52% 38% 22% |
Le drop le plus fort (étape 2 → 3) signalait un onboarding confus. Refonte → drop divisé par deux.
Pour chaque cohorte (signups d'une semaine donnée), tracker la % qui revient les semaines suivantes. Sans ça, on confond croissance et churn.
| 1 | S+1 S+2 S+4 S+8 |
| 2 | Cohort W12 65% 48% 35% 28% |
| 3 | Cohort W14 72% 58% 45% 38% ← amélioration palpable |
Pas le NPS automatisé après 30 jours qui n'enseigne rien. Le NPS conversationnel : on appelle les 10 premiers clients payants, on demande "qu'est-ce qui te ferait nous quitter ?" et "qu'est-ce qui te ferait t'engager plus ?". Les réponses guident la roadmap mieux que n'importe quel formulaire.
Côté technique, trois principes pour ne pas se tirer une balle dans le pied :
Next.js + PostgreSQL + Tailwind couvre 90 % des SaaS B2B. Inutile d'aller chercher un framework expérimental pour faire la même chose en plus lent et plus risqué. Plus la stack est commune, plus on recrute et collabore facilement.
Un SaaS B2B sert plusieurs clients. Isoler la donnée par tenant_id partout, dès la première ligne. Coût : 5 % d'effort en plus. Bénéfice : pas de refonte douloureuse à la 50e société cliente.
| 1 | CREATE TABLE leads ( |
| 2 | id UUID PRIMARY KEY, |
| 3 | tenant_id UUID NOT NULL, |
| 4 | name TEXT NOT NULL, |
| 5 | -- ... |
| 6 | ); |
| 7 | CREATE INDEX ON leads (tenant_id, created_at); |
| 8 | CREATE POLICY tenant_isolation ON leads |
| 9 | USING (tenant_id = current_setting('app.tenant_id')::uuid); |
Toute nouvelle fonctionnalité non triviale arrive derrière un flag, activable par tenant. On peut tester sur 3 % des clients sans risquer les 97 % autres. Sur MailCraft, ce pattern a évité trois rollbacks en production.
Réalité commerciale du SaaS B2B en Afrique de l'Ouest francophone et en France :
D'où : pages produit avec un cas client raconté en histoire, plus efficace qu'un tableau de fonctionnalités. Logos visibles. Pricing affiché (pas "contactez-nous"). Démo cliquable en 2 clics.
Les sites SaaS B2B qui font "vendeur premium mystique" sans pricing affiché filtrent 80 % des prospects qualifiés qui partent voir un concurrent transparent.
Sur les paliers payants, proposer le mensuel + l'annuel avec ~20 % de réduction. Effets multiples :
Sur Prospect-Pro, le passage à un pricing annuel/mensuel proposé sur la même page a fait monter le CAC payback de 11 à 5 mois.
| Piège | Symptôme | Correction |
|---|---|---|
| Coder avant d'écouter | Features que personne ne veut | 10+ entretiens utilisateurs avant code |
| Time-to-value > 10 min | Drop massif à l'onboarding | Mesurer et réduire chaque étape |
| Pas de pricing visible | Drop avant contact | Pricing affiché transparent |
| Feature avant business model | Empilement sans cohérence | Pricing en premier |
| Pas d'observabilité produit | Décisions à l'aveugle | Funnel + cohort + NPS conversationnel |
| Multi-tenant ajouté tard | Refonte douloureuse | tenant_id dès le schéma initial |
| Vendre à l'engineering | Personne ne signe | Vendre au décideur business |
| Pas de pré-paiement annuel | Cash flow tendu | Annuel proposé visible |
Sur les cinq produits Ubuntu :
| Produit | Traction | Pattern manqué |
|---|---|---|
| Prospect-Pro AI | Forte | — |
| RunWeek | Moyenne | Onboarding initial trop long |
| HomeEnergy | Forte | — |
| MailCraft | Forte | — |
| Plateforme enrichissement | Faible | Pas d'interviews utilisateurs avant code |
Les trois qui ont décollé ont en commun : interviews préalables, time-to-value court, pricing visible, multi-tenant natif. Les deux qui ont stagné ont sauté l'une de ces étapes.
Le SaaS B2B n'est pas un problème technique. La tech est le moyen. Le problème est de trouver une promesse claire, la valider en pré-vente, livrer un time-to-value court et instrumenter la rétention.
Si vous démarrez aujourd'hui : six semaines de découverte avant le premier sprint code. Trois paliers de pricing visibles. Multi-tenant dès le jour 1. Funnel d'activation tracé.
Le reste suit. Sinon, votre SaaS rejoint le cimetière des MVP techniquement impeccables que personne n'a achetés.
Si ce sujet ressemble à un problème réel dans votre produit, je peux intervenir sur le diagnostic, l'architecture, le backend, l'interface et les automatisations qui rendent une plateforme exploitable.
Réactions des lecteurs
Aucun commentaire pour l'instant
Soyez le premier à réagir à cet article.