En 2007, j'ai lancé mon premier SaaS. J'avais codé quelque chose que je trouvais utile, je l'avais mis en ligne. Et j'attendais.
Les premiers paiements sont arrivés. Pas des centaines. Quelques dizaines. Mais ils arrivaient sans que je fasse rien. Des gens avaient un besoin, ils trouvaient mon outil, ils payaient. À 2h du matin parfois. Moi, je dormais.
C'est ce jour-là que j'ai vraiment compris ce qu'était un SaaS. Pas une technologie. Pas un type d'application. Une façon de construire quelque chose une fois, et de le faire travailler pour toi en continu.
Mais ce modèle n'a rien de magique. Et beaucoup de fondateurs se lancent dedans pour les mauvaises raisons. Dans cet article, je vous explique ce qu'est vraiment un SaaS, pourquoi ce modèle peut être très puissant, et surtout dans quels cas il a du sens, et dans quels cas il n'en a pas.
🎬 Vous préférez la version vidéo ?
Cet article existe aussi en vidéo sur la chaîne YouTube Joliweb Studio. Voir sur YouTube →
Ce qu'est vraiment un SaaS
SaaS est l'acronyme de "Software as a Service", soit logiciel en tant que service. C'est une façon de distribuer un logiciel.
Historiquement, si vous vouliez utiliser un logiciel, vous achetiez une boîte, vous installiez un CD, et le programme tournait sur votre ordinateur. Vous payiez une fois, c'était à vous. C'est ce qu'on appelle un logiciel "on-premise".
Le SaaS, c'est l'opposé. Le logiciel ne tourne pas chez vous. Il tourne sur les serveurs de l'éditeur, et vous y accédez depuis votre navigateur, depuis votre téléphone, depuis n'importe où. Et au lieu de payer une fois, vous payez un abonnement, généralement mensuel ou annuel.
Des exemples que vous connaissez certainement : Notion, Slack, Figma, HubSpot. Vous ne téléchargez rien, vous ouvrez un onglet, vous vous connectez, vous travaillez. C'est ça, un SaaS.
Mais ce qui rend ce modèle intéressant, ce n'est pas la technologie. C'est ce que ça fait au business.
Pourquoi le modèle SaaS est puissant, et quand il a vraiment du sens
💰 Le revenu récurrent
Quand vous vendez un produit physique, une prestation, ou même un logiciel en licence, vous vendez une fois. Pour gagner de l'argent le mois suivant, vous devez vendre à nouveau. Vous recommencez à zéro chaque mois.
Avec un SaaS, chaque client que vous signez reste. Il paie chaque mois, automatiquement, tant qu'il utilise votre produit. C'est ce qu'on appelle le MRR, le Monthly Recurring Revenue, soit le revenu mensuel récurrent. Ce chiffre, une fois que vous commencez à le construire, ne repart pas à zéro. Il s'accumule. Chaque nouveau client vient s'ajouter à ceux d'avant. C'est mathématiquement puissant.
📈 La scalabilité
Quand vous avez 10 clients et que vous passez à 100, votre logiciel sert 100 clients sans que vous ayez recruté 10 fois plus de personnes. Le coût marginal d'un client supplémentaire tend vers zéro. C'est fondamentalement différent d'une agence, où plus vous avez de clients, plus vous devez embaucher.
🏷️ La valorisation
Les SaaS se valorisent bien mieux que les autres types de business. Une agence va se valoriser à 1 ou 2 fois son chiffre d'affaires annuel. Un SaaS avec un bon MRR peut se valoriser à 5, 8, parfois 10 fois son ARR. J'ai lancé PrimoCV en 2007, un outil de création de CV en ligne. Ce n'était pas un abonnement mensuel au sens strict, les utilisateurs payaient à l'usage. Mais le produit tournait seul, générait des revenus sans que j'intervienne, et je l'ai revendu après 11 ans d'exploitation. Ce modèle avait une valeur à la revente qu'une prestation de service n'aurait jamais eue.
⚠️ Mais, et c'est là que ça devient important
Tout ça est vrai. Mais à une condition : que le SaaS ait du sens. Que le modèle soit justifié par ce que le produit fait vraiment.
Quand Adobe a basculé Photoshop et Premiere en abonnement mensuel, j'avais d'abord accepté la décision. Et puis les prix ont augmenté, une fois, deux fois, trois fois, sans que le produit évolue vraiment en proportion. À un moment je me suis demandé : qu'est-ce que je paie exactement chaque mois ? Ces logiciels tournent sur mon poste. Mes fichiers sont chez moi. Je ne collabore en temps réel avec personne. Rien dans l'architecture du produit ne justifie un abonnement qui augmente chaque année. C'est un modèle de pricing déguisé en SaaS pour générer du récurrent.
Et ça, les utilisateurs le sentent. Même sans pouvoir le formuler. Ils sentent qu'on leur fait payer chaque mois pour quelque chose qui ne le mérite pas.
Un vrai SaaS, c'est un produit qui a besoin intrinsèquement d'être centralisé. Parce que vos données doivent être synchronisées entre plusieurs appareils. Parce que vous collaborez en temps réel avec d'autres personnes. Parce que le service évolue en continu et que cette évolution vous apporte de la valeur réelle. Notion, Figma, Slack : ça a du sens en SaaS. Photoshop n'en avait pas.
Si vous construisez un SaaS juste pour faire du récurrent, sans que votre produit le justifie vraiment, vous construisez quelque chose que vos utilisateurs finiront par détester. Et ça, ça ne construit pas un business. Ça construit une réputation négative.
La question à se poser avant tout n'est pas "comment je vais monétiser", c'est "est-ce que mon produit, par nature, a besoin d'être un SaaS ?" Si la réponse est oui, le modèle a tout pour être très solide. Si la réponse est non, mieux vaut explorer d'autres options.
Ce que ça implique concrètement quand vous voulez en lancer un
🧠 Un SaaS, ça se pense avant de se coder
La majorité des projets SaaS qui échouent n'ont pas échoué à cause d'un bug ou d'une mauvaise technologie. Ils ont échoué parce que le problème qu'ils résolvaient n'était pas assez douloureux pour que les gens paient pour le résoudre.
Avant d'écrire une ligne de code, avant de choisir votre stack technique, avant de trouver un développeur, vous devez valider que le problème existe vraiment. Et que des gens sont prêts à payer pour qu'on le règle. C'est exactement ce qu'on explore dans l'article sur comment valider son idée SaaS sans écrire une ligne de code.
🔧 La technique, c'est un moyen, pas une fin
Beaucoup d'entrepreneurs non-techniques se perdent dans les questions tech dès le départ : quelle technologie choisir, no-code ou développeur, combien ça va coûter. Ces questions sont légitimes, mais elles viennent trop tôt.
La question numéro 1, c'est : est-ce que mon idée vaut vraiment le coup ? Est-ce que j'ai parlé à de vrais utilisateurs potentiels ? Est-ce que je comprends leur problème mieux qu'eux-mêmes ? Si la réponse est oui, alors on peut parler technique.
Ce qu'il faut retenir
Un SaaS n'est pas un type de logiciel. C'est un modèle business fondé sur l'abonnement et le revenu récurrent. Ce modèle est puissant à condition qu'il soit justifié par ce que votre produit fait vraiment : centralisation des données, collaboration en temps réel, service qui évolue en continu. Si votre produit n'a pas intrinsèquement besoin d'être centralisé, le SaaS n'est peut-être pas le bon modèle. Et si c'est le bon modèle, la première question n'est pas technique. C'est de valider que le problème que vous résolvez est suffisamment douloureux pour que quelqu'un paie pour la solution.
Questions fréquentes
Quelle est la différence entre un SaaS et un logiciel classique ?
Un logiciel classique s'installe sur votre ordinateur et se paie en une seule fois. Un SaaS tourne sur les serveurs de l'éditeur, est accessible depuis n'importe quel navigateur, et se facture sous forme d'abonnement mensuel ou annuel. La différence clé, c'est que vous n'avez rien à installer et que vos données sont synchronisées en permanence.
Est-ce qu'un SaaS est toujours plus rentable qu'un logiciel classique ?
Pas automatiquement. Le SaaS est plus rentable sur le long terme quand le produit justifie le modèle par nature : données synchronisées, collaboration en temps réel, service qui évolue en continu. Si votre produit peut tout aussi bien fonctionner en local, le modèle abonnement risque d'être perçu comme abusif par vos utilisateurs.
Peut-on lancer un SaaS sans compétences techniques ?
Oui, à condition d'être bien accompagné. La majorité des fondateurs de SaaS qui réussissent ne sont pas développeurs. L'essentiel est de comprendre suffisamment le produit pour le spécifier correctement, choisir les bons partenaires techniques, et piloter le développement. C'est exactement ce que couvrent les vidéos et articles de Joliweb Studio.