Par Thomas Cohen, fondateur de Maestro
Transformer une prestation en micro-SaaS : repérer ce qui peut devenir un produit
Cartographier une prestation, distinguer les gestes répétables du jugement métier, puis choisir entre service assisté et outil autonome.
Transformer une prestation en logiciel commence par repérer ce que plusieurs clients vous demandent réellement de refaire. Décrivez les entrées, les étapes, les décisions et le résultat livré. Vous pourrez alors choisir une partie à rendre répétable, sans supposer que toute votre expertise peut devenir un bouton.
Un micro-SaaS désigne ici un service logiciel au périmètre limité, proposé à plusieurs clients. Passer à ce modèle modifie votre travail : vous devez expliquer le parcours, entretenir le produit et aider des personnes qui ne bénéficient plus forcément de votre présence. Ce changement mérite un essai avant une nouvelle offre complète.
Prenons un cas fictif : Élise prépare les dossiers de visite d’espaces événementiels. Elle rassemble les contraintes, trie les observations et remet une synthèse à un organisateur. Élise et les missions décrites sont inventées. Elles illustrent deux offres possibles, pas une reconversion observée ni un revenu annoncé.
Reconstituer une prestation de bout en bout
Choisissez une prestation identifiable, avec un début et un livrable. Rassemblez des éléments que vous êtes autorisé à utiliser, ou recréez-les avec des données fictives. Cherchez comment le travail commence, ce que vous demandez, les étapes que vous répétez et les vérifications avant remise.
Dans l’exemple, Élise reçoit le programme prévu, prépare une liste de questions, visite le lieu, classe ses notes et demande les informations manquantes. Elle rédige ensuite une synthèse qui distingue les points confirmés des questions ouvertes. Le document final dépend autant de ses relances que de sa mise en page.
Inscrivez chaque étape sur une ligne avec quatre champs : information reçue, action, décision et sortie. « Analyser le besoin » doit devenir plus concret : rapprocher le nombre de salles du programme, repérer une contradiction et demander confirmation. Cette description révèle les décisions cachées dans une formule générale.
Notez aussi les échanges informels. Le coup de téléphone qui semble accessoire peut empêcher une erreur importante. Si vous retirez cette intervention dans la future application, il faudra soit l’expliquer à l’utilisateur, soit prévoir un autre moyen de repérer le même problème.
Séparer les étapes communes des exceptions
Examinez plusieurs missions réelles si vous en disposez. Ne partez pas seulement de la dernière ou de la plus agréable. Recherchez ce qui revient avec le même sens : recueillir une date, associer une photo à une salle, demander une validation ou conserver la version remise.
Une étape identique en apparence peut cacher des règles différentes. Deux clients peuvent vouloir un compte rendu, mais l’un attend une trace descriptive et l’autre une recommandation qui engage votre jugement. Un même formulaire ne transforme pas ces attentes en un seul produit.
Classez les écarts : détail de présentation, règle de métier, qualité des informations ou intervention relationnelle. Les détails de présentation peuvent parfois devenir des réglages. Les désaccords sur le résultat attendu demandent d’abord un choix d’offre. Ajouter une option pour chaque cas rendrait le logiciel aussi difficile à piloter que la prestation.
Dans notre scénario, Élise retient la préparation descriptive d’une visite. Elle écarte les avis de conformité et la négociation avec les fournisseurs. Ce choix réduit la promesse, mais rend le résultat plus explicable : un dossier organisé, avec les informations connues et les points à confirmer.
Reconnaître ce qui repose sur votre jugement
Posez une question sur chaque étape : une autre personne pourrait-elle prendre la même décision avec les informations et les règles écrites ? Si la réponse est non, cherchez pourquoi. Il peut manquer une donnée, une règle ou un savoir construit par l’expérience.
La décision de regrouper deux notes est parfois simple. La décision qu’un accès convient à un événement peut dépendre de contraintes que vous n’avez pas encore décrites. Ne mélangez pas le rangement d’informations et l’avis professionnel sous une promesse générale d’intelligence artificielle.
Un agent peut aider à classer des observations ou à repérer une contradiction selon une consigne. Cela ne prouve pas qu’il peut assumer l’ensemble de votre prestation. Définissez les éléments à relire, les informations qu’il ne doit pas inventer et la personne qui accepte le résultat final.
La valeur de votre futur produit peut justement être de rendre le travail humain plus fiable à suivre : questions non résolues visibles, sources retrouvables et relecture explicite. Vous n’avez pas besoin de supprimer toute intervention pour proposer un outil utile et compréhensible.
Choisir le premier morceau à proposer
Le bon premier périmètre doit produire un résultat que le client peut reconnaître. Un assemblage de fonctions techniques, même impressionnant, ne suffit pas. Cherchez un morceau avec une entrée accessible et une sortie exploitable, qui ne nécessite pas de reconstruire tout le fonctionnement du client.
Pour Élise, ce morceau serait : importer des notes préparées, les relier à des lieux, signaler les informations manquantes et sortir un brouillon à relire. Le résultat ne serait pas une validation de l’événement. La personne comprendrait ce que l’outil lui apporte et où commence sa propre responsabilité.
Écrivez également ce qui se passe avec une entrée incomplète. Le logiciel doit pouvoir dire qu’il manque une information, conserver le travail commencé et permettre de revenir. Si chaque exception exige qu’Élise reprenne la mission entière, l’offre autonome est probablement prématurée.
Le périmètre choisi doit correspondre à une difficulté rencontrée par plusieurs personnes que vous pouvez joindre. Une personnalisation demandée par un seul client peut rester une prestation intéressante. Elle ne devient pas un produit partagé uniquement parce que vous l’avez automatisée.
Scénario A : vendre un service assisté
Dans le premier scénario fictif, le client continue de confier son dossier à Élise. Elle utilise un outil interne pour classer les notes et préparer un brouillon, puis elle le relit et le remet. L’offre vend toujours une prestation avec une responsabilité et une intervention humaines annoncées.
Cette voie permet d’observer le travail avant d’exiger du client qu’il le fasse seul. Élise peut voir quelles informations manquent, quelles erreurs se répètent et quelles décisions restent difficiles à formaliser. Elle doit néanmoins vérifier les droits d’utilisation des documents et les conditions de tout service auquel ils sont transmis.
Le client n’a pas à adopter immédiatement une nouvelle application. En contrepartie, la charge d’Élise reste liée au nombre et à la diversité des dossiers. Son outil peut faciliter le travail sans modifier la nature de l’offre ni justifier un abonnement logiciel.
Le critère de passage suivant serait observable : une personne autre qu’Élise peut préparer une entrée correcte avec les instructions fournies. Tant que cette étape dépend d’un long échange qu’elle seule sait mener, le service assisté peut être le bon modèle à conserver.
Scénario B : proposer un outil autonome
Dans le second scénario, le client ouvre son espace, crée une visite, ajoute ses notes et prépare lui-même la synthèse. Il doit comprendre les informations demandées, les états du dossier et le moment où la relecture est nécessaire. Le produit inclut désormais les explications auparavant données en conversation.
Il faut aussi gérer le travail inachevé. La personne peut revenir le lendemain, retrouver son brouillon et distinguer une version provisoire d’une version partagée. Ces détails ne sont pas accessoires : ils déterminent si le logiciel peut entrer dans une organisation réelle.
Élise devra prévoir une assistance et un moyen de traiter les erreurs. Si un utilisateur supprime une observation ou ne comprend pas un résultat, il ne peut pas compter sur une présence implicite. Une offre autonome demande de rendre visibles les aides, les limites et les possibilités de récupération.
L’essai utile consiste à donner une tâche avec un dossier fictif, puis à observer ce que la personne fait sans lui dicter les clics. Le résultat attendu est un brouillon correctement interprété. L’inscription au service ou la visite d’un écran ne suffit pas à montrer cette autonomie.
Comparer les deux offres sur le même travail
Pour chaque scénario, suivez le même dossier du début à la fin. Notez ce que fait le client, ce que vous faites, ce que fait le logiciel et les reprises nécessaires. Renseignez les durées réellement observées ; ne déduisez pas une économie d’un simple nombre d’étapes supprimées.
Le service assisté peut conserver davantage d’intervention tout en étant plus facile à acheter. L’outil autonome peut demander moins de traitement par dossier mais plus de préparation, d’assistance et de maintenance. Le prix et le temps économisé restent des sujets à examiner dans votre situation.
Séparez le travail de démarrage du travail récurrent : préparation initiale, accompagnement, traitement des exceptions, suivi des fournisseurs et évolution du produit. Une automatisation qui semble rapide pendant la démonstration peut demander une vérification manuelle après chaque dossier. Gardez cette activité dans le calcul.
Dans son essai Do Things that Don’t Scale, Paul Graham décrit l’intérêt possible d’un accompagnement manuel aux débuts d’un produit. Ce conseil entrepreneurial invite à apprendre du travail réel ; il ne garantit pas qu’une prestation doive devenir un logiciel ni qu’un accompagnement gratuit soit viable.
Vérifier ce que vous pouvez réutiliser
Votre expérience peut nourrir une méthode générale. Les fichiers, informations et livrables d’un client ne sont pas pour autant disponibles pour une démonstration ou un nouveau produit. Faites l’inventaire de ce que vous souhaitez reprendre et vérifiez les engagements qui l’encadrent avant toute utilisation.
Distinguez votre méthode, un modèle créé pour votre activité, un document fourni par le client et un élément provenant d’un tiers. Lorsque la situation reste incertaine, utilisez des exemples inventés et demandez une clarification adaptée. Masquer un nom ne règle pas toujours toutes les questions de réutilisation.
Le futur produit doit également expliquer où vont les informations. Si un assistant externe prépare une synthèse, ce fonctionnement mérite d’être décrit et configuré selon le contexte. Un fichier conservé sur votre ordinateur peut être transmis pendant un traitement ; le lieu de stockage ne suffit pas à décrire le parcours.
Préparer une transition qui laisse un choix
Ne basculez pas vos clients existants dans un logiciel parce que vous souhaitez changer de modèle. Présentez le résultat proposé, les tâches qui leur reviennent désormais et l’aide prévue. Certaines personnes préféreront continuer à acheter la prestation ; leur choix peut révéler où se trouve votre valeur actuelle.
Prévoyez un petit essai distinct du travail indispensable. Utilisez d’abord des exemples autorisés ou fictifs et conservez le moyen habituel de terminer le dossier. Convenez de ce qui sera examiné : compréhension, qualité de la sortie, interventions nécessaires et possibilité de reprendre en cas d’échec.
Décidez ensuite entre conserver le service, améliorer l’outil interne ou poursuivre vers un produit autonome. Ces trois issues peuvent être raisonnables. La cartographie prestation vers SaaS fournit le cas d’Élise, les deux scénarios et une grille vierge pour étudier votre propre activité sans annoncer trop tôt une transformation complète.