Créer un SaaS : par où commencer

Pour créer un SaaS, on commence par un problème précis vécu par un groupe de clients identifiable, et par la preuve que ces clients sont prêts à payer pour le résoudre. Vient ensuite une première version réduite à l’essentiel, mise entre leurs mains le plus tôt possible. La technique compte, mais elle passe après : la plupart des projets de SaaS qui échouent ont été bien construits pour un besoin qui n’existait pas assez.

Qu’est-ce qu’un SaaS, concrètement ?

Un SaaS (de l’anglais « Software as a Service », logiciel en tant que service) est un logiciel que vos clients utilisent dans leur navigateur ou dans une application, sans rien installer, et qu’ils paient en général par abonnement. Vous l’hébergez, vous le mettez à jour, et chaque client retrouve ses propres données dans son propre espace.

Trois traits le distinguent d’un outil développé pour une seule entreprise :

• Plusieurs clients partagent le même logiciel. Un cabinet de kinésithérapie à Lille et un autre à Nantes utilisent la même application, mais chacun ne voit que ses patients et ses rendez-vous.
• Le revenu est récurrent. Le client paie tant qu’il utilise le service, ce qui vous oblige à rester utile mois après mois.
• Une mise à jour profite à tous. Vous corrigez ou améliorez une fois, et tous vos clients en bénéficient le jour même.

Ce dernier point est une force, et une responsabilité : une erreur touche aussi tout le monde en même temps.

Partir d’un problème, pas d’une idée de logiciel

L’erreur la plus courante consiste à partir d’une liste de fonctions (« un planning, un chat, des statistiques, une application mobile ») plutôt que d’une douleur précise. Un bon point de départ ressemble plutôt à ceci : « les entreprises de nettoyage de bureaux perdent un temps fou à prouver à leurs clients que les passages ont bien eu lieu ».

Cette phrase contient déjà l’essentiel :

• un public que vous pouvez nommer et joindre ;
• un problème qui coûte du temps ou de l’argent ;
• une situation actuelle (un carnet papier, un tableur, des photos envoyées par SMS) que votre logiciel viendra remplacer.

Si vous connaissez ce métier de l’intérieur, c’est un atout considérable : vous savez quels mots utilisent vos futurs clients, ce qui les agace et ce qu’ils ont déjà essayé.

Comment valider une idée de SaaS avant de développer ?

Valider, c’est chercher des preuves que des gens paieront, pas des encouragements. Plusieurs méthodes se complètent :

1. Les entretiens. Parlez à des personnes du public visé, en leur demandant comment elles font aujourd’hui, combien de temps cela leur prend, ce qu’elles ont déjà tenté. Évitez de présenter votre idée trop tôt : vous recueilleriez de la politesse.
2. Le prototype cliquable. Quelques écrans maquettés, sans vrai code, suffisent pour observer si quelqu’un comprend l’outil et s’il s’y projette.
3. La page de présentation. Une page qui décrit le service et propose de s’inscrire pour être prévenu du lancement mesure un intérêt réel, à condition d’y amener le bon public.
4. L’engagement. Une lettre d’intention, une précommande ou l’accord d’un client pilote pour tester sur ses vraies données vaut plus que cent « bonne idée ».

Signal	Ce qu’il vaut
« C’est une super idée »	Presque rien
« Ce serait utile »	Un peu, sans engagement
Inscription sur une liste d’attente	Un intérêt réel, à confirmer
Temps consacré à tester un prototype	Un bon signe
Paiement, précommande, client pilote engagé	Une preuve

Un client qui accepte de vous donner du temps ou de l’argent avant que le produit soit fini vous en apprend plus que toutes les études de marché.

Que mettre dans la première version de votre SaaS ?

La première version doit permettre à un client de résoudre son problème du début à la fin, même de façon simple. Un parcours complet et modeste vaut mieux que dix fonctions à moitié terminées. Nous détaillons cette logique dans notre article sur le MVP d’une application, et elle s’applique à un SaaS de la même manière.

Pour l’exemple de l’entreprise de nettoyage, la première version pourrait se limiter à : l’agent valide son passage sur son téléphone avec une photo, le client final reçoit un récapitulatif, le responsable voit les passages manquants. Les statistiques avancées, les exports comptables et la gestion des congés peuvent attendre.

Les briques invisibles à prévoir dès le départ

Certaines fondations ne se voient pas mais coûtent cher à rattraper plus tard :

• La séparation des clients. Chaque requête doit être vérifiée sur le serveur pour qu’un client ne puisse jamais lire les données d’un autre. C’est le point le plus sensible d’un SaaS.
• Les comptes et les rôles. Qui est administrateur, qui consulte, qui saisit.
• Un back-office pour vous. Créer un client, l’aider, voir ce qui se passe, suspendre un compte impayé.
• Les sauvegardes automatiques et la possibilité de restaurer.
• L’export des données d’un client, qu’il vous demandera tôt ou tard.

Les choix techniques qui engagent pour longtemps

Quelques décisions prises au début vous suivront pendant des années.

Web, mobile ou les deux. La plupart des SaaS commencent dans le navigateur, qui fonctionne partout sans passer par les stores. Une application mobile se justifie quand l’usage se fait sur le terrain, comme notre agent de nettoyage. Avec Flutter, une même base de code peut servir pour iPhone et Android, ce qui limite l’effort.

L’hébergement. Pour des clients européens, un hébergement dans l’Union européenne simplifie beaucoup les échanges avec leurs services juridiques.

Le paiement. Les abonnements, les relances de carte expirée et les factures se confient à un prestataire de paiement spécialisé. Développer cela soi-même n’a pas de sens au démarrage.

La propriété du code. Si vous faites développer votre SaaS, assurez-vous de recevoir le code source, la documentation et tous les accès (hébergement, base de données, nom de domaine, paiement). C’est ce que nous remettons à la fin de chaque projet : votre logiciel est votre actif, il ne doit pas rester bloqué chez un prestataire.

RGPD : ce qui change quand vous hébergez les données de vos clients

Un SaaS destiné aux entreprises traite presque toujours des données personnelles : les comptes des utilisateurs, et souvent les clients de vos clients. Dans ce cas, votre client est en général responsable du traitement de ces données, et vous êtes son sous-traitant au sens du RGPD.

Ce rôle entraîne des obligations concrètes :

• signer avec chaque client un contrat ou une annexe qui encadre ce que vous faites de ses données (article 28 du RGPD) ;
• n’utiliser ces données que pour rendre le service, pas pour vos propres besoins ;
• assurer leur sécurité et prévenir votre client sans tarder en cas de fuite ;
• savoir où sont hébergées les données et quels prestataires y ont accès.

La CNIL publie un guide RGPD du développeur et des fiches pour garantir la sécurité des données : deux bonnes lectures avant d’écrire la première ligne de code. Les entreprises qui achètent un logiciel posent de plus en plus ces questions avant de signer, et avoir les réponses prêtes fait partie du produit.

Fixer le modèle d’abonnement

Le modèle de prix se pense tôt, parce qu’il influence le produit lui-même. Plusieurs structures existent :

• par utilisateur : simple à comprendre, mais il peut freiner l’adoption dans l’équipe du client ;
• par volume (nombre de dossiers, de sites, de rendez-vous) : il suit la valeur apportée ;
• par palier : quelques formules avec des fonctions ou des limites différentes.

L’essai gratuit limité dans le temps convient bien aux logiciels professionnels, où le client a besoin de tester sur son cas. La version gratuite permanente demande beaucoup d’utilisateurs pour qu’une petite part paie, ce qui correspond rarement à un SaaS de niche. Nous avons détaillé ces mécanismes dans un article sur la monétisation par abonnement.

Lancer, écouter, améliorer

Les premiers clients d’un SaaS ne sont pas des utilisateurs comme les autres : ce sont des partenaires. Accompagnez-les personnellement, regardez-les utiliser l’outil, notez où ils bloquent. Chaque question qu’ils posent signale un écran à simplifier.

Quelques indicateurs suffisent au début :

• combien de clients utilisent vraiment l’outil chaque semaine ;
• combien arrêtent leur abonnement, et pourquoi (demandez-le, systématiquement) ;
• le temps entre l’inscription et le premier usage utile.

Ensuite, améliorez par petites étapes. Un SaaS n’est jamais fini, et c’est justement ce qui justifie l’abonnement aux yeux de vos clients.

Questions fréquentes

Faut-il savoir coder pour créer un SaaS ?

Non. Beaucoup de SaaS sont lancés par des personnes qui connaissent un métier et s’associent à un développeur ou font appel à un studio. Votre rôle est de connaître le problème, les clients et le marché. Il reste utile de comprendre les grandes décisions techniques pour pouvoir les discuter.

Peut-on commencer avec un outil sans code ?

Pour valider une idée, oui : un outil sans code permet de tester un parcours auprès de quelques clients. Ses limites apparaissent avec la séparation fine des données entre clients, la performance et la dépendance à la plateforme. Beaucoup de projets passent ensuite à un développement classique, en reprenant ce qui a été appris.

Combien de temps faut-il pour une première version ?

Cela dépend entièrement du périmètre : un parcours unique bien défini se construit bien plus vite qu’un outil aux nombreux rôles et connexions. C’est pourquoi le travail de cadrage, qui réduit la première version à l’essentiel, est l’étape qui a le plus d’effet sur le délai.

Web ou application mobile pour commencer ?

Le web dans la grande majorité des cas, parce qu’il fonctionne partout et se met à jour instantanément. Une application mobile s’ajoute quand vos utilisateurs travaillent loin d’un ordinateur : chantier, tournée, intervention chez le client.

Si vous avez identifié votre problème et vos premiers clients, la suite se construit étape par étape. Notre page applications et SaaS décrit notre façon de travailler, et vous pouvez nous parler de votre projet : nous répondons en moins de 24 heures.