Ce que j’ai appris en 4 ans à gérer une activité sur un marché SaaS extrêmement concurrentiel

xguru · 2025-04-14T11:01:01+09:00

OnlineOrNot, fondé par Max Rozen, a démarré sur un marché où il existait déjà plus de 200 produits concurrents Au départ, beaucoup de produits étaient pénibles à utiliser, puis d’innombrables concurrents sont apparus avant de disparaître rapidement Certains produits concurrents ont levé des fonds auprès de VC puis ont été rachetés par de grands groupes, avec une expérience utilisateur qui s’est progressivement dégradée OnlineOrNot vise une activité durable sur le long terme, financée sur fonds propres L’auteur conserve toujours un emploi à plein temps tout en développant son SaaS de manière régulière Il publie chaque année un billet de rétrospective, et certaines leçons tirées par le passé se sont révélées fausses avec le temps Principes qui n’ont pas changé J’ai appris énormément de choses en dirigeant une activité pendant plusieurs années, mais certains principes fondamentaux restent inchangés. Investir 2 heures chaque jour ouvré Avant même de lancer OnlineOrNot, je consacrais déjà 2 heures chaque matin à des projets personnels avant de partir au travail Ce temps m’a permis d’achever des centaines d’articles, un livre et plusieurs projets logiciels Plus que la quantité de temps investie dans une journée, c’est l’effort régulier au quotidien qui compte le plus Pour préserver ce créneau, je me lève 2 heures plus tôt et j’ai réorganisé ma routine Ne pas lancer d’autres side projects Comme le dit l’adage, on ne peut pas courir deux lièvres à la fois ; je me concentre donc sur une seule chose Certaines personnes exceptionnelles réussissent sur plusieurs projets, mais j’accepte que ce ne soit pas mon cas Le passage de $0 à $500 de MRR est la phase la plus difficile, et je ne vois pas l’intérêt de la répéter Je reste concentré sur un modèle qui fonctionne déjà, et je choisis aussi mon marketing avec cette logique La priorité, c’est résoudre la douleur du client Quand un utilisateur s’inscrit, un email automatique lui demande : « Pourquoi vous êtes-vous inscrit ? » Je lis tous les emails et j’y réponds moi-même ; c’est une source essentielle d’insights pour améliorer le produit Identifier ce qui frustre les utilisateurs, puis le résoudre réellement Itérer avec obstination et améliorer en continu Si je ne peux pas mettre quelque chose en production en moins de 2 heures, j’en réduis le périmètre pour le livrer d’abord Je n’arrive pas toujours à tomber exactement sur 2 heures, mais je préfère déployer vite une première version puis étendre la fonctionnalité Si on essaie de tout construire avant de livrer, on finit au contraire par perdre sa motivation et sa concentration Terminer progressivement une fonctionnalité derrière des feature flags est bien plus efficace Leçons apprises Lire quelques livres, puis se mettre immédiatement à construire Au démarrage, j’ai lu des dizaines de livres business pour éviter de faire des erreurs Mais j’ai fini par comprendre que rien n’est plus efficace que d’apprendre en se trompant soi-même Exemple : un passage en page d’accueil de Hacker News a attiré 6 000 visiteurs, mais seuls quelques-uns sont réellement arrivés jusqu’à l’application 75 % d’abandon sur le formulaire d’inscription → l’ajout d’une simple option de connexion OAuth a fait tomber ce taux à 50 % Si je devais recommencer, je ne lirais que ces trois livres avant de me lancer : The Mom Test (Rob Fitzpatrick) Deploy Empathy (Michele Hansen) Badass: Making Users Awesome (Kathy Sierra) Et si vous avez besoin de détails très concrets sur l’exploitation d’un SaaS, je recommanderais aussi The SaaS Playbook (Rob Walling) Avant de vendre un abonnement, il faut d’abord résoudre un problème Le but d’un SaaS n’est pas de vendre un abonnement, mais de résoudre la douleur du client Il faut passer de « si on continue à ajouter des fonctionnalités, les gens finiront bien par l’utiliser » à « résolvons un problème pénible dans le travail des utilisateurs » Le SaaS n’est qu’une manière parmi d’autres de résoudre un problème ; on peut aussi passer par un screencast, de la documentation, des articles, un livre, des ateliers, des exemples de code, etc. Construire petit et déployer souvent Les utilisateurs proposent des idées de fonctionnalités, mais dans la pratique ils s’en servent rarement Quand on lance son premier SaaS, le simple fait que quelqu’un nous parle peut suffire à nous enthousiasmer au point de construire la fonctionnalité sans réfléchir Il faut demander comment cette fonctionnalité serait utilisée, étudier aussi comment d’autres utilisateurs résolvent ce problème, puis l’implémenter d’abord sous sa forme minimale pour observer la réaction Mieux vaut une approche stratégique pour créer des fonctionnalités utilisées par beaucoup que de développer une « fonctionnalité flocon de neige » pour une seule personne Supprimer une fonctionnalité dans laquelle on a investi quelques heures fait mal, mais en supprimer une dans laquelle on a investi des mois est bien plus douloureux Déployez d’abord, réfléchissez à l’échelle ensuite La première version d’OnlineOrNot a été lancée rapidement, sans optimisation d’architecture En réalité, le système avait un bug qui limitait à environ 100 le nombre de checks qu’il pouvait traiter, et en cas de problème, l’interface se contentait d’afficher « Error! », signe d’un produit très inachevé Mais j’ai préféré me faire critiquer pour une UI incomplète plutôt que de construire des fonctionnalités inutiles Comme rien ne garantit qu’on aura des milliers d’utilisateurs dès le début, le plus important était de valider rapidement J’ai provisoirement augmenté la capacité en passant la base de données à un plan supérieur Puis, en quelques heures, j’ai refactoré l’ensemble pour pouvoir traiter des millions de checks, tout en améliorant aussi l’écran d’erreur Gérer un programme d’early access Au début du développement d’un produit, la majorité des utilisateurs est relativement tolérante vis-à-vis de fonctionnalités incomplètes Avec le temps, davantage d’utilisateurs attendent un produit plus mature Pour répondre à cela, j’ai ajouté dans chaque compte utilisateur une case « participer au programme d’early access » les participants testent en avant-première les fonctionnalités les plus récentes, encore inachevées, et fournissent leur feedback C’est une manière utile de trouver un équilibre entre tests et feedback Introduire l’essai gratuit le plus tôt possible Aujourd’hui, on entend souvent le conseil « un plan gratuit est trop difficile à calibrer, donc mieux vaut ne pas en faire » Pourtant, au début, le plan gratuit a bien fonctionné pour le bouche-à-oreille et l’acquisition d’utilisateurs Son inconvénient, c’est que si l’écart avec les fonctionnalités payantes est trop grand, il faut permettre aux utilisateurs de tester les bonnes fonctionnalités Ce n’est qu’au bout de 11 mois que j’ai ajouté à l’onboarding la question « Voulez-vous démarrer un essai gratuit ? » ce qui signifiait en pratique : « Voulez-vous essayer les bonnes fonctionnalités pendant 14 jours et décider ensuite, ou utiliser pendant des mois une version limitée avant de finir déçu ? » Ensuite, j’ai expérimenté un essai gratuit activé par défaut pour tous les utilisateurs et cette seule expérimentation a plus que doublé le taux de croissance mensuel Conclusion : « Ceci est un service payant. Si vous voulez continuer à utiliser les bonnes fonctionnalités, nous avons besoin de vos informations de paiement » est bien plus efficace commercialement que « ceci est un service gratuit ; peut-être payant si vous l’utilisez beaucoup » La documentation fait partie du produit Autrefois, on entendait souvent que « les développeurs ne lisent pas la documentation », mais c’est complètement faux Certains clients idéaux ont fait l’éloge de la documentation d’OnlineOrNot, ce qui m’a poussé à y investir sérieusement J’ai même construit moi-même la documentation de l’API afin de contrôler entièrement l’expérience utilisateur Observation faite avec les outils d’analyse produit : Quand un utilisateur bloque dans l’UI, consulte la documentation puis trouve la fonctionnalité, il continue à utiliser le produit S’il ne trouve pas l’information qu’il cherche, il ne crée pas de check et quitte La qualité de la documentation a un impact direct sur la rétention Concevoir le produit en pensant au mobile Contrairement à une idée répandue, les utilisateurs de SaaS B2B aussi commencent leur travail sur smartphone En réalité, environ 50 % des utilisateurs commencent à utiliser le produit sur mobile ils créent un compte, enregistrent quelques pages, puis reviennent vérifier plus tard sur PC Pendant les 6 premiers mois, je n’ai pas pensé à l’environnement mobile, et la plupart des inscrits sur mobile abandonnaient Après l’introduction d’une UI responsive, la rétention des utilisateurs mobiles a nettement progressé Demandez directement aux utilisateurs comment ils vous ont découvert L’un des changements de code les plus précieux introduits au milieu de la première année a été d’ajouter lors de l’inscription la question « Où avez-vous entendu parler d’OnlineOrNot ? » Comprendre les canaux d’acquisition est essentiel pour maximiser l’efficacité du marketing Il existe des dizaines de canaux marketing, mais les ressources sur lesquelles on peut se concentrer sont limitées Une fois qu’un canal se révèle efficace, il faut investir à fond dessus et continuer jusqu’à ce que les résultats diminuent Ne pas utiliser d’outils d’analyse intrusifs Au début, j’ai mis en place, comme beaucoup de SaaS, des outils de session tracking et d’analyse de funnel, mais leur utilité était faible Cela peut être utile pour de grandes équipes, mais pour un petit service, on risque surtout de surinterpréter des résultats aléatoires En tant que solo founder ne disposant que de 2 heures chaque matin, il était plus efficace d’obtenir directement l’avis d’un groupe d’utilisateurs de confiance (inner-circle) que d’analyser des masses de données Je recevais un feedback intuitif sur les fonctionnalités et les problèmes, puis j’améliorais le produit à partir de ce jugement sensible Parlez aux prospects même si vous n’avez pas encore la fonctionnalité Un jour, un CTO m’a demandé si je supportais une fonctionnalité précise Au départ, j’allais simplement répondre « désolé, ce n’est pas encore disponible », mais par curiosité, je lui ai demandé quel problème il rencontrait et quel objectif il cherchait à atteindre j’ai aussi demandé à mes utilisateurs inner-circle s’ils rencontraient le même problème et j’ai partagé des idées sur la manière de concevoir cette fonctionnalité Résultat : ce CTO est devenu client payant dès le lendemain et il l’est toujours aujourd’hui Cette fonctionnalité est désormais bien utilisée par d’autres utilisateurs aussi J’ai passé plus de temps à construire la plateforme qu’à résoudre le problème lui-même Sur les 4 dernières années, plus de la moitié du temps de développement a été consacrée à construire la plateforme SaaS alors que l’objectif initial, « vérifier qu’un site web est bien en ligne et envoyer des alertes », n’en représentait qu’une petite partie Les fonctionnalités réellement nécessaires incluaient : différentes méthodes d’authentification et la gestion des utilisateurs les essais, l’onboarding les tâches DB répétitives, la gestion des équipes, la facturation les emails de cycle de vie, etc. Une partie a été externalisée via des services comme Stripe, mais de nombreux éléments nécessitaient malgré tout un traitement direct ou une forte personnalisation, et j’ai donc fini par les implémenter moi-même La tarification est vraiment difficile Si les prix sont trop élevés, les attentes montent ou les gens hésitent carrément à s’inscrire Si les prix sont trop bas, un utilisateur à $9 peut exiger que toute l’application soit remodelée à son goût La solution : rembourser les clients pénibles et les laisser partir augmenter les prix, puis avancer surtout au début, à mesure qu’on étend le produit, il est indispensable d’expérimenter en continu sur la tarification Ne vous focalisez pas uniquement sur le MRR Le MRR (Monthly Recurring Revenue) peut être un mauvais indicateur pour mesurer la santé réelle d’une activité Comme ce que vous avez fait il y a plusieurs semaines ou plusieurs mois influence le MRR d’aujourd’hui, il est difficile de mesurer les effets en temps réel Sur certains produits SaaS, il peut s’écouler plus de 60 jours entre l’inscription et le paiement effectif Il faut donc s’appuyer sur d’autres indicateurs pour savoir si le produit est réellement utilisé et s’il délivre de la valeur par exemple : nombre d’images générées, nombre de formulaires soumis, ou d’autres indicateurs de succès fondés sur les usages Ne jamais proposer de « illimité » Il y aura toujours des utilisateurs qui pousseront au maximum ce que signifie “illimité” (whale customer) Exemple : un client qui paie seulement $250/mois tout en consommant énormément de ressources Si l’unité rendue illimitée génère un coût, c’est forcément une mauvaise affaire Ce conseil vaut aussi pour les lifetime deals si vous promettez un usage à vie pour $100, on peut ensuite vous demander pendant des années d’ajouter des fonctionnalités et si vous êtes passé par une marketplace tierce, vous ne toucherez peut-être en réalité que 30 % de cette somme Au final, cela revient à inviter non pas de vrais clients, mais des utilisateurs attirés par un gain court terme et qui vous lient pour longtemps Appliquez impérativement un rate limit sur les ressources payantes Si vous utilisez des API payantes comme l’IA, les SMS ou l’envoi d’emails, il faut impérativement limiter l’usage « Puisque c’est un client payant, il peut bien utiliser ça sans limite, non ? » → il peut exister des exceptions, mais dans la majorité des cas, cela expose à une explosion des coûts ou à une étiquette de spam chez le fournisseur Cas réel : un serveur hébergeant des centaines de sites WordPress a généré des erreurs faute de RAM ce qui a déclenché automatiquement des milliers d’alertes SMS, avec un coût important à la clé Si un client a vraiment besoin d’un très gros volume d’usage, il viendra vous contacter directement N’essayez pas de tout expliquer sur une seule page « Si vous essayez de tout dire à tout le monde, vous ne direz finalement rien à personne » Cette phrase s’applique particulièrement bien au copywriting d’une landing page À mesure que des fonctionnalités s’ajoutaient à OnlineOrNot, je continuais à enrichir la landing page principale avec de nouvelles explications, et le message est devenu confus, tout comme la compréhension des utilisateurs par exemple, l’intégration Slack a été la deuxième fonctionnalité développée, mais beaucoup de gens ignoraient même qu’elle existait Solution : créer une landing page dédiée pour chaque fonctionnalité principale : https://onlineornot.com/ surveillance d’uptime : https://onlineornot.com/website-monitoring monitoring d’API : https://onlineornot.com/api-monitoring status pages : https://onlineornot.com/status-pages monitoring de cron jobs : https://onlineornot.com/cron-job-monitoring Chaque page offre assez d’espace pour présenter clairement la fonctionnalité Il est difficile d’augmenter le trafic, mais on peut améliorer la conversion dès maintenant Attirer l’attention sur Internet est un travail de longue haleine et très lent même avec un content marketing régulier et de qualité, il faut parfois des mois ou des années pour passer de 1 ou 2 visiteurs à plusieurs centaines Augmenter le trafic en lui-même n’est pas facile En revanche, on peut changer immédiatement le comportement des visiteurs déjà présents par exemple, comme en ajoutant une option de connexion OAuth sur le formulaire d’inscription, des améliorations applicables dès aujourd’hui peuvent faire monter le taux de conversion Les concurrents ne sont pas si importants Si je parle si peu des concurrents dans tout cet article, c’est parce qu’ils ont en réalité peu d’impact Bien sûr, il faut posséder les fonctionnalités de base pour être pris en considération par les clients, mais le véritable concurrent, c’est le fait que l’utilisateur ne sache même pas que ce produit existe Plus que les fonctionnalités, la notoriété et l’accessibilité sont les vrais facteurs concurrentiels

(maxrozen.com)

74 points par xguru 2025-04-14 | 4 commentaires | Partager sur WhatsApp

OnlineOrNot, fondé par Max Rozen, a démarré sur un marché où il existait déjà plus de 200 produits concurrents
Au départ, beaucoup de produits étaient pénibles à utiliser, puis d’innombrables concurrents sont apparus avant de disparaître rapidement
Certains produits concurrents ont levé des fonds auprès de VC puis ont été rachetés par de grands groupes, avec une expérience utilisateur qui s’est progressivement dégradée
OnlineOrNot vise une activité durable sur le long terme, financée sur fonds propres
L’auteur conserve toujours un emploi à plein temps tout en développant son SaaS de manière régulière
Il publie chaque année un billet de rétrospective, et certaines leçons tirées par le passé se sont révélées fausses avec le temps

Principes qui n’ont pas changé

J’ai appris énormément de choses en dirigeant une activité pendant plusieurs années, mais certains principes fondamentaux restent inchangés.

Investir 2 heures chaque jour ouvré

Avant même de lancer OnlineOrNot, je consacrais déjà 2 heures chaque matin à des projets personnels avant de partir au travail
Ce temps m’a permis d’achever des centaines d’articles, un livre et plusieurs projets logiciels
Plus que la quantité de temps investie dans une journée, c’est l’effort régulier au quotidien qui compte le plus
Pour préserver ce créneau, je me lève 2 heures plus tôt et j’ai réorganisé ma routine

Ne pas lancer d’autres side projects

Comme le dit l’adage, on ne peut pas courir deux lièvres à la fois ; je me concentre donc sur une seule chose
Certaines personnes exceptionnelles réussissent sur plusieurs projets, mais j’accepte que ce ne soit pas mon cas
Le passage de $0 à $500 de MRR est la phase la plus difficile, et je ne vois pas l’intérêt de la répéter
Je reste concentré sur un modèle qui fonctionne déjà, et je choisis aussi mon marketing avec cette logique

La priorité, c’est résoudre la douleur du client

Quand un utilisateur s’inscrit, un email automatique lui demande : « Pourquoi vous êtes-vous inscrit ? »
Je lis tous les emails et j’y réponds moi-même ; c’est une source essentielle d’insights pour améliorer le produit
Identifier ce qui frustre les utilisateurs, puis le résoudre réellement

Itérer avec obstination et améliorer en continu

Si je ne peux pas mettre quelque chose en production en moins de 2 heures, j’en réduis le périmètre pour le livrer d’abord
Je n’arrive pas toujours à tomber exactement sur 2 heures, mais je préfère déployer vite une première version puis étendre la fonctionnalité
Si on essaie de tout construire avant de livrer, on finit au contraire par perdre sa motivation et sa concentration
Terminer progressivement une fonctionnalité derrière des feature flags est bien plus efficace

Leçons apprises

Lire quelques livres, puis se mettre immédiatement à construire

Au démarrage, j’ai lu des dizaines de livres business pour éviter de faire des erreurs
Mais j’ai fini par comprendre que rien n’est plus efficace que d’apprendre en se trompant soi-même
Exemple : un passage en page d’accueil de Hacker News a attiré 6 000 visiteurs, mais seuls quelques-uns sont réellement arrivés jusqu’à l’application
75 % d’abandon sur le formulaire d’inscription → l’ajout d’une simple option de connexion OAuth a fait tomber ce taux à 50 %
Si je devais recommencer, je ne lirais que ces trois livres avant de me lancer :
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- Et si vous avez besoin de détails très concrets sur l’exploitation d’un SaaS, je recommanderais aussi The SaaS Playbook (Rob Walling)

Avant de vendre un abonnement, il faut d’abord résoudre un problème

Le but d’un SaaS n’est pas de vendre un abonnement, mais de résoudre la douleur du client
Il faut passer de « si on continue à ajouter des fonctionnalités, les gens finiront bien par l’utiliser » à « résolvons un problème pénible dans le travail des utilisateurs »
Le SaaS n’est qu’une manière parmi d’autres de résoudre un problème ; on peut aussi passer par un screencast, de la documentation, des articles, un livre, des ateliers, des exemples de code, etc.

Construire petit et déployer souvent

Les utilisateurs proposent des idées de fonctionnalités, mais dans la pratique ils s’en servent rarement
Quand on lance son premier SaaS, le simple fait que quelqu’un nous parle peut suffire à nous enthousiasmer au point de construire la fonctionnalité sans réfléchir
Il faut demander comment cette fonctionnalité serait utilisée, étudier aussi comment d’autres utilisateurs résolvent ce problème, puis
- l’implémenter d’abord sous sa forme minimale pour observer la réaction
Mieux vaut une approche stratégique pour créer des fonctionnalités utilisées par beaucoup que de développer une « fonctionnalité flocon de neige » pour une seule personne
Supprimer une fonctionnalité dans laquelle on a investi quelques heures fait mal, mais en supprimer une dans laquelle on a investi des mois est bien plus douloureux

Déployez d’abord, réfléchissez à l’échelle ensuite

La première version d’OnlineOrNot a été lancée rapidement, sans optimisation d’architecture
En réalité, le système avait un bug qui limitait à environ 100 le nombre de checks qu’il pouvait traiter, et
- en cas de problème, l’interface se contentait d’afficher « Error! », signe d’un produit très inachevé
Mais j’ai préféré me faire critiquer pour une UI incomplète plutôt que de construire des fonctionnalités inutiles
Comme rien ne garantit qu’on aura des milliers d’utilisateurs dès le début, le plus important était de valider rapidement
J’ai provisoirement augmenté la capacité en passant la base de données à un plan supérieur
Puis, en quelques heures, j’ai refactoré l’ensemble pour pouvoir traiter des millions de checks, tout en améliorant aussi l’écran d’erreur

Gérer un programme d’early access

Au début du développement d’un produit, la majorité des utilisateurs est relativement tolérante vis-à-vis de fonctionnalités incomplètes
Avec le temps, davantage d’utilisateurs attendent un produit plus mature
Pour répondre à cela, j’ai ajouté dans chaque compte utilisateur une case « participer au programme d’early access »
- les participants testent en avant-première les fonctionnalités les plus récentes, encore inachevées, et fournissent leur feedback
C’est une manière utile de trouver un équilibre entre tests et feedback

Introduire l’essai gratuit le plus tôt possible

Aujourd’hui, on entend souvent le conseil « un plan gratuit est trop difficile à calibrer, donc mieux vaut ne pas en faire »
Pourtant, au début, le plan gratuit a bien fonctionné pour le bouche-à-oreille et l’acquisition d’utilisateurs
Son inconvénient, c’est que si l’écart avec les fonctionnalités payantes est trop grand, il faut permettre aux utilisateurs de tester les bonnes fonctionnalités
Ce n’est qu’au bout de 11 mois que j’ai ajouté à l’onboarding la question « Voulez-vous démarrer un essai gratuit ? »
- ce qui signifiait en pratique :
  
  « Voulez-vous essayer les bonnes fonctionnalités pendant 14 jours et décider ensuite, ou utiliser pendant des mois une version limitée avant de finir déçu ? »
Ensuite, j’ai expérimenté un essai gratuit activé par défaut pour tous les utilisateurs et
- cette seule expérimentation a plus que doublé le taux de croissance mensuel
Conclusion :
- « Ceci est un service payant. Si vous voulez continuer à utiliser les bonnes fonctionnalités, nous avons besoin de vos informations de paiement »
- est bien plus efficace commercialement que « ceci est un service gratuit ; peut-être payant si vous l’utilisez beaucoup »

La documentation fait partie du produit

Autrefois, on entendait souvent que « les développeurs ne lisent pas la documentation », mais c’est complètement faux
Certains clients idéaux ont fait l’éloge de la documentation d’OnlineOrNot, ce qui m’a poussé à y investir sérieusement
J’ai même construit moi-même la documentation de l’API afin de contrôler entièrement l’expérience utilisateur
Observation faite avec les outils d’analyse produit :
1. Quand un utilisateur bloque dans l’UI, consulte la documentation puis trouve la fonctionnalité, il continue à utiliser le produit
2. S’il ne trouve pas l’information qu’il cherche, il ne crée pas de check et quitte
La qualité de la documentation a un impact direct sur la rétention

Concevoir le produit en pensant au mobile

Contrairement à une idée répandue, les utilisateurs de SaaS B2B aussi commencent leur travail sur smartphone
En réalité, environ 50 % des utilisateurs commencent à utiliser le produit sur mobile
- ils créent un compte, enregistrent quelques pages, puis reviennent vérifier plus tard sur PC
Pendant les 6 premiers mois, je n’ai pas pensé à l’environnement mobile, et la plupart des inscrits sur mobile abandonnaient
Après l’introduction d’une UI responsive, la rétention des utilisateurs mobiles a nettement progressé

Demandez directement aux utilisateurs comment ils vous ont découvert

L’un des changements de code les plus précieux introduits au milieu de la première année a été
- d’ajouter lors de l’inscription la question « Où avez-vous entendu parler d’OnlineOrNot ? »
Comprendre les canaux d’acquisition est essentiel pour maximiser l’efficacité du marketing
Il existe des dizaines de canaux marketing, mais les ressources sur lesquelles on peut se concentrer sont limitées
Une fois qu’un canal se révèle efficace, il faut investir à fond dessus et continuer jusqu’à ce que les résultats diminuent

Ne pas utiliser d’outils d’analyse intrusifs

Au début, j’ai mis en place, comme beaucoup de SaaS, des outils de session tracking et d’analyse de funnel, mais leur utilité était faible
Cela peut être utile pour de grandes équipes, mais pour un petit service, on risque surtout de surinterpréter des résultats aléatoires
En tant que solo founder ne disposant que de 2 heures chaque matin,
- il était plus efficace d’obtenir directement l’avis d’un groupe d’utilisateurs de confiance (inner-circle) que d’analyser des masses de données
Je recevais un feedback intuitif sur les fonctionnalités et les problèmes, puis j’améliorais le produit à partir de ce jugement sensible

Parlez aux prospects même si vous n’avez pas encore la fonctionnalité

Un jour, un CTO m’a demandé si je supportais une fonctionnalité précise
Au départ, j’allais simplement répondre « désolé, ce n’est pas encore disponible », mais
- par curiosité, je lui ai demandé quel problème il rencontrait et quel objectif il cherchait à atteindre
- j’ai aussi demandé à mes utilisateurs inner-circle s’ils rencontraient le même problème
- et j’ai partagé des idées sur la manière de concevoir cette fonctionnalité
Résultat : ce CTO est devenu client payant dès le lendemain et il l’est toujours aujourd’hui
Cette fonctionnalité est désormais bien utilisée par d’autres utilisateurs aussi

J’ai passé plus de temps à construire la plateforme qu’à résoudre le problème lui-même

Sur les 4 dernières années, plus de la moitié du temps de développement a été consacrée à construire la plateforme SaaS
- alors que l’objectif initial, « vérifier qu’un site web est bien en ligne et envoyer des alertes », n’en représentait qu’une petite partie
Les fonctionnalités réellement nécessaires incluaient :
- différentes méthodes d’authentification et la gestion des utilisateurs
- les essais, l’onboarding
- les tâches DB répétitives, la gestion des équipes, la facturation
- les emails de cycle de vie, etc.
Une partie a été externalisée via des services comme Stripe, mais
- de nombreux éléments nécessitaient malgré tout un traitement direct ou une forte personnalisation, et j’ai donc fini par les implémenter moi-même

La tarification est vraiment difficile

Si les prix sont trop élevés, les attentes montent ou les gens hésitent carrément à s’inscrire
Si les prix sont trop bas, un utilisateur à $9 peut exiger que toute l’application soit remodelée à son goût
La solution :
- rembourser les clients pénibles et les laisser partir
- augmenter les prix, puis avancer
- surtout au début, à mesure qu’on étend le produit, il est indispensable d’expérimenter en continu sur la tarification

Ne vous focalisez pas uniquement sur le MRR

Le MRR (Monthly Recurring Revenue) peut être un mauvais indicateur pour mesurer la santé réelle d’une activité
Comme ce que vous avez fait il y a plusieurs semaines ou plusieurs mois influence le MRR d’aujourd’hui, il est difficile de mesurer les effets en temps réel
Sur certains produits SaaS, il peut s’écouler plus de 60 jours entre l’inscription et le paiement effectif
Il faut donc s’appuyer sur d’autres indicateurs pour savoir si le produit est réellement utilisé et s’il délivre de la valeur
- par exemple : nombre d’images générées, nombre de formulaires soumis, ou d’autres indicateurs de succès fondés sur les usages

Ne jamais proposer de « illimité »

Il y aura toujours des utilisateurs qui pousseront au maximum ce que signifie “illimité” (whale customer)
Exemple : un client qui paie seulement $250/mois tout en consommant énormément de ressources
Si l’unité rendue illimitée génère un coût, c’est forcément une mauvaise affaire
Ce conseil vaut aussi pour les lifetime deals
- si vous promettez un usage à vie pour $100, on peut ensuite vous demander pendant des années d’ajouter des fonctionnalités
- et si vous êtes passé par une marketplace tierce, vous ne toucherez peut-être en réalité que 30 % de cette somme
Au final, cela revient à inviter non pas de vrais clients, mais des utilisateurs attirés par un gain court terme et qui vous lient pour longtemps

Appliquez impérativement un rate limit sur les ressources payantes

Si vous utilisez des API payantes comme l’IA, les SMS ou l’envoi d’emails, il faut impérativement limiter l’usage
« Puisque c’est un client payant, il peut bien utiliser ça sans limite, non ? » → il peut exister des exceptions, mais
- dans la majorité des cas, cela expose à une explosion des coûts ou à une étiquette de spam chez le fournisseur
Cas réel :
- un serveur hébergeant des centaines de sites WordPress a généré des erreurs faute de RAM
- ce qui a déclenché automatiquement des milliers d’alertes SMS, avec un coût important à la clé
Si un client a vraiment besoin d’un très gros volume d’usage, il viendra vous contacter directement

N’essayez pas de tout expliquer sur une seule page

« Si vous essayez de tout dire à tout le monde, vous ne direz finalement rien à personne »

Cette phrase s’applique particulièrement bien au copywriting d’une landing page
À mesure que des fonctionnalités s’ajoutaient à OnlineOrNot, je continuais à enrichir la landing page principale avec de nouvelles explications, et
- le message est devenu confus, tout comme la compréhension des utilisateurs
- par exemple, l’intégration Slack a été la deuxième fonctionnalité développée, mais beaucoup de gens ignoraient même qu’elle existait
Solution : créer une landing page dédiée pour chaque fonctionnalité
- principale : https://onlineornot.com/
- surveillance d’uptime : https://onlineornot.com/website-monitoring
- monitoring d’API : https://onlineornot.com/api-monitoring
- status pages : https://onlineornot.com/status-pages
- monitoring de cron jobs : https://onlineornot.com/cron-job-monitoring
Chaque page offre assez d’espace pour présenter clairement la fonctionnalité

Il est difficile d’augmenter le trafic, mais on peut améliorer la conversion dès maintenant

Attirer l’attention sur Internet est un travail de longue haleine et très lent
- même avec un content marketing régulier et de qualité, il faut parfois des mois ou des années pour passer de 1 ou 2 visiteurs à plusieurs centaines
Augmenter le trafic en lui-même n’est pas facile
En revanche, on peut changer immédiatement le comportement des visiteurs déjà présents
- par exemple, comme en ajoutant une option de connexion OAuth sur le formulaire d’inscription, des améliorations applicables dès aujourd’hui peuvent faire monter le taux de conversion

Les concurrents ne sont pas si importants

Si je parle si peu des concurrents dans tout cet article, c’est parce qu’ils ont en réalité peu d’impact
Bien sûr, il faut posséder les fonctionnalités de base pour être pris en considération par les clients, mais
- le véritable concurrent, c’est le fait que l’utilisateur ne sache même pas que ce produit existe
Plus que les fonctionnalités, la notoriété et l’accessibilité sont les vrais facteurs concurrentiels

4 commentaires

thenewseason 2025-04-22

En tant qu’exploitant d’un service, je me reconnais beaucoup dans ce qui est dit.
Moi aussi, j’ai développé en rognant sur mon sommeil, et ma santé s’est dégradée..

Ce que j’aimerais demander à ceux qui ont vécu une expérience similaire, c’est si un tel investissement en temps est possible tout en élevant des enfants.
Comme le temps de trajet, les heures passées au travail et le temps à la maison avec les enfants occupent déjà presque toute la journée, pour créer et faire tourner ce genre de service, on finit par devoir renoncer à autre chose — et j’espère que ce ne sera ni la famille ni la santé..

tsboard 2025-04-15

C’est vraiment un texte dont on peut beaucoup apprendre. Utiliser 2 heures chaque matin pour écrire et mener à bien plusieurs projets, c’est impressionnant... !

ethanhur 2025-04-14

C’est un article très instructif. En fin de compte, il ne faut pas oublier que le SaaS aussi est un produit que les clients « embauchent » pour résoudre leurs problèmes.

xguru 2025-04-14

Ce que j’ai appris en gérant seul un SaaS pendant un an
Déjà 3 ans ont passé haha. Regardez en comparant ce qui a changé !