Comment créer un SaaS : du problème au lancement

Commencer par une situation observable

« Un outil pour les PME » ne décrit pas encore un marché exploitable. Choisissez une personne, une tâche et un moment : par exemple, un responsable de club qui relance les inscriptions chaque début de saison. Décrivez ce qu’il utilise aujourd’hui, les erreurs fréquentes et ce qui rend le changement difficile. Un tableur peut être une solution concurrente plus importante qu’un autre SaaS.

Interrogez les personnes sur leur dernière expérience réelle. Demandez comment la tâche s’est déroulée, qui est intervenu et ce qu’elles ont dû refaire. Évitez de demander uniquement si elles aimeraient votre idée : une opinion positive n’est pas une preuve d’usage ni une intention d’achat. Consignez les objections et les contradictions autant que les encouragements.

Identifier l’utilisateur et l’acheteur

Dans un SaaS B2B, l’utilisateur quotidien n’est pas toujours celui qui signe. Cartographiez les rôles : utilisateur, responsable du budget, validateur technique et éventuel administrateur. Chacun peut bloquer l’adoption pour une raison différente. Une interface simple aide l’utilisateur ; un export de données ou une règle claire de facturation peut rassurer le décideur.

En France, certaines organisations attendront également des précisions sur l’hébergement, les contrats et le traitement des données. Listez ces exigences pendant les échanges sans promettre une conformité non vérifiée. Leur coût et leur impact peuvent modifier la clientèle initiale à privilégier.

Formuler une promesse vérifiable

Écrivez une phrase reliant la tâche au résultat : « aider les clubs à suivre les inscriptions sans recouper plusieurs fichiers ». Cette promesse reste plus utile qu’une liste d’outils. Elle permet de définir une première démonstration et de vérifier si les personnes reconnaissent leur problème.

Choisissez ensuite un signal de validation. Cela peut être l’acceptation d’un entretien approfondi, un test sur des données représentatives ou une proposition de pilote. Les signaux ne sont pas équivalents : visiter une page demande peu d’effort, migrer un processus en demande beaucoup. Précisez ce que chaque expérience doit vous apprendre avant de la lancer.

Définir le parcours minimum

Un MVP doit permettre d’accomplir une tâche complète. Pour notre club fictif, le parcours pourrait être : créer une campagne, inviter les membres, suivre les réponses et exporter la liste. Un tableau de bord avancé peut attendre ; une gestion compréhensible des erreurs d’import peut être indispensable.

Concevoir le produit et son exploitation

Le logiciel ne se limite pas aux écrans visibles. Définissez les comptes, les organisations, les permissions, la facturation, les notifications et les opérations de support. Pour un SaaS multi-entreprises, l’isolation des données doit être testée explicitement : un changement d’identifiant dans une requête ne doit jamais exposer le compte voisin.

Choisissez ensuite les technologies selon les compétences disponibles, les intégrations et les contraintes d’exploitation. Une architecture simple, testable et documentée est souvent préférable à des services distribués prématurés. Gardez une procédure de sauvegarde et de restauration, des journaux utiles et un moyen de revenir à la version précédente.

Préparer le lancement pendant la construction

Un lancement ne doit pas être la première conversation avec le marché. Identifiez les personnes qui testeront le produit, le message qui les intéresse et le canal par lequel elles pourront être contactées. Préparez une démonstration courte, un onboarding guidé et une manière de recueillir les blocages.

Au début, les échanges directs apportent une compréhension que les tableaux de bord ne donnent pas. Observez si les utilisateurs atteignent la première valeur, s’ils reviennent pour une tâche réelle et ce qui les oblige à utiliser encore leur ancien outil. Évitez de confondre inscription, activation et fidélisation.

Piloter les décisions après le lancement

Organisez les retours par problème, et non par nombre de fonctionnalités demandées. Plusieurs personnes peuvent demander des solutions différentes au même besoin. Reliez chaque évolution à un comportement attendu, une contrainte ou un risque identifié. Conservez un journal de décisions pour expliquer pourquoi une fonctionnalité a été ajoutée ou reportée.

Le budget doit intégrer cette phase : support, correction, infrastructure, contenu, acquisition et apprentissage. Consommer toute la capacité avant le premier usage réel laisse peu de place aux ajustements. Définissez des points de revue où vous pourrez poursuivre, réduire ou réorienter le produit.

Un exemple de cadrage de bout en bout

Prenons un outil fictif de validation de devis pour petites agences. La demande initiale est « centraliser tous les projets ». Cette formulation conduit rapidement à construire un CRM, un planning et une facturation. L’entretien révèle pourtant une difficulté plus précise : personne ne sait quelle version du devis le client a acceptée. Le premier produit peut donc se concentrer sur une version datée, un destinataire, une décision et un historique consultable.

Le pilote commence avec une seule agence, sur des devis représentatifs sans données confidentielles inutiles. L’équipe observe la création du document, son ouverture par le destinataire, une demande de modification et la recherche de la version acceptée. Un refus et un lien expiré font aussi partie du test. La réussite ne se limite pas à « le bouton fonctionne » : le responsable doit retrouver la bonne version sans demander au fondateur de l’aider.

La suite dépend du résultat. Si les clients ne veulent pas ouvrir un nouvel outil, la prochaine expérience peut porter sur l’accès invité. Si les agences continuent à recopier les décisions dans un tableur, il faut comprendre quel besoin n’est pas couvert avant d’ajouter un tableau de bord. Une intégration comptable ne devient prioritaire que si elle débloque un usage confirmé.

Organiser les responsabilités avant le pilote

Le fondateur porte les décisions de marché et de périmètre. Le responsable produit transforme les observations en parcours et critères d’acceptation. Le responsable technique vérifie les règles, les accès et l’exploitation. Une personne peut cumuler ces rôles, mais chaque responsabilité doit avoir un propriétaire explicite. Sans cela, une décision attendue peut immobiliser une équipe entière.

Préparez également une sortie du pilote : export des documents, révocation des accès, traitement des demandes reçues et communication sur ce qui se passe ensuite. Un pilote qui ne se poursuit pas peut néanmoins fournir une preuve utile. Conservez les hypothèses invalidées et la raison de l’arrêt ; elles évitent de relancer la même idée sous un autre nom.

Le dossier à remettre à une équipe

• Un exemple concret de tâche actuelle, avec ses exceptions.
• Une description du public initial et du décideur.
• Le parcours attendu, les exclusions et les critères d’acceptation.
• Les données nécessaires, leur origine et les droits d’accès.
• Le mode de recrutement des pilotes et la date de revue.
• Les responsabilités de support, d’exploitation et de décision.

Ce dossier ne remplace pas une conversation. Il permet de consacrer cette conversation aux risques et aux arbitrages plutôt qu’à reconstituer le contexte.

Atelier : préparer une décision de mise en service

Voici un exercice de préparation, sans résultat client implicite. Imaginez un logiciel qui aide un atelier de réparation à suivre les demandes déposées par ses clients. L’objectif du premier pilote est précis : permettre au responsable de savoir quelle demande exige une action aujourd’hui. Le lancement ne consiste pas à annoncer que le tableau de bord est terminé. Il consiste à vérifier qu’une demande réelle peut entrer, être traitée et sortir du système sans perdre d’information.

Préparez une répétition avec trois rôles : une personne joue le client, une autre le responsable de l’atelier et une troisième observe. Le client dépose une demande incomplète. Le responsable doit demander la précision manquante, retrouver la réponse, attribuer la réparation et informer le client de sa disponibilité. L’observateur note les passages qui nécessitent une explication orale extérieure au produit. Ces explications deviennent des éléments à clarifier dans l’interface, le support ou la procédure d’exploitation.

N’ajoutez pas automatiquement une fonctionnalité pour chaque incident observé. Une procédure manuelle documentée peut suffire au pilote si elle reste réalisable, proportionnée au volume et connue des participants. En revanche, un incident qui compromet la confidentialité, perd une demande ou annonce un faux succès doit être traité avant l’ouverture concernée.

Terminez l’atelier avec une décision datée. Indiquez les utilisateurs admis, le volume que l’équipe accepte de traiter, les situations exclues, le responsable de support et la façon de suspendre le pilote. Fixez le prochain point de revue en fonction de l’activité réelle attendue. Un produit utilisé chaque mois ne fournit pas les mêmes observations en une semaine qu’un outil utilisé chaque jour.

Le livrable est une fiche de mise en service d’une page, accompagnée des preuves de la répétition. Elle permet de distinguer une interface convaincante d’un service effectivement exploitable. Conservez aussi les raisons de vos exclusions : elles éviteront de transformer une concession provisoire du pilote en règle permanente du produit.

Questions fréquentes

Faut-il savoir coder ?

Non, mais il faut pouvoir arbitrer le problème, le public et les priorités. Une équipe technique peut traduire ces décisions en architecture et expliquer les compromis. Le rôle du fondateur ne disparaît pas lorsque le développement est délégué.

Combien de temps faut-il ?

Il n’existe pas de durée sérieuse sans périmètre. Les dépendances externes, la migration de données et les règles métier pèsent parfois davantage que le nombre d’écrans. Demandez une estimation par jalons, avec hypothèses et risques, plutôt qu’une date isolée.

Quelle première action entreprendre ?

Rédigez une page décrivant une personne, une tâche récurrente, la solution actuelle et le changement attendu. Utilisez-la pour préparer vos entretiens. Elle constitue un meilleur point de départ qu’un long inventaire de fonctionnalités.

Les exemples sont pédagogiques et ne décrivent pas des résultats clients. Contenu préparé avec assistance IA ; voir notre politique éditoriale. Notre méthode ↗