Prévente de SaaS : définir une offre pilote et un engagement réaliste

Décrire le résultat, l’état du produit, la participation demandée et les décisions en cas de retard. Une fiche pour discuter d’un pilote sans confondre intérêt, essai et achat.

Une offre pilote permet de convenir d’un essai limité avec une organisation, autour d’un résultat précis. Avant de parler de prévente, écrivez ce qui existe, ce qui reste à construire et ce que chaque partie accepte de faire. La discussion devient alors un engagement compréhensible, plutôt qu’un accord enthousiaste sur un futur produit indéfini.

Ce guide traite la préparation de cette offre. Il ne fournit pas un contrat prêt à signer et n’exécute aucun paiement. Vous trouverez une fiche de discussion, un exemple fictif et des questions à résoudre avant une proposition commerciale engageante. Les conditions applicables dépendent de votre offre et de votre situation.

Le cas suivi est Dossier Clair, un service fictif pour rassembler les pièces de projets d’agence. Salomé envisage un pilote avec l’agence fictive Rivage. Leur objectif serait de distinguer les éléments reçus, ceux à corriger et ceux encore attendus. Aucun de ces échanges ni aucun achat n’a eu lieu.

Nommer le type d’accord recherché

Le mot prévente peut recouvrir des situations différentes : payer pour un produit futur, acheter une prestation de préparation ou réserver un accès sous certaines conditions. Ne les rassemblez pas dans une même phrase. L’acheteur doit comprendre ce qu’il reçoit en échange de son engagement et à quel moment.

Un partenaire pilote participe à un essai organisé. Cela peut inclure un paiement, du temps de préparation ou des retours convenus, mais ces éléments doivent être formulés séparément. Accepter de donner un avis ne signifie pas accepter de devenir client ; payer ne signifie pas accepter toutes les demandes de participation.

Écrivez votre demande immédiate : examiner une proposition, préparer des exemples autorisés, nommer un référent ou décider d’une commande. Une prochaine action claire vaut mieux qu’un formulaire où « intéressé » pourrait signifier cinq choses. Le guide des premiers clients traite la prise de contact qui précède cette discussion.

Gardez une trace distincte de l’état de chaque échange. Une personne peut avoir accepté une présentation sans avoir discuté du budget. Une autre peut envisager l’achat sous réserve d’une fonction. Le suivi commercial doit conserver cette condition au lieu de transformer l’intention en vente certaine.

Décrire un résultat assez petit pour être examiné

Le pilote doit répondre à une question de travail. Dans notre exemple : une cheffe de projet peut-elle retrouver les pièces encore attendues et préparer une demande claire au client ? Cette question est plus précise que « améliorer la collaboration » et ne demande pas de remplacer toute la gestion de l’agence.

Définissez le point de départ et la sortie : un dossier avec une liste de pièces, des réponses reçues et un état à vérifier. Dites qui utilise la sortie et dans quelle décision. Un résultat utile n’est pas seulement un écran rempli ; il permet à quelqu’un d’avancer dans son travail.

Ajoutez les cas exclus : signature contractuelle, archivage réglementaire, gestion des factures ou classement de données sensibles non prévu. Les exclusions doivent correspondre aux limites du produit. Elles ne servent pas à cacher une fonction indispensable à la tâche que vous avez promis de rendre possible.

Repérez une solution de repli. Si l’essai s’interrompt, Rivage doit pouvoir continuer son travail habituel et retrouver les informations nécessaires. Le pilote ne devrait pas devenir le seul moyen de terminer une activité importante avant que sa fiabilité ait été examinée dans le contexte prévu.

Pour comprendre · illustration du guide

Montrer l’état réel du produit

Préparez quatre rubriques : disponible et vérifié, disponible mais à vérifier, à construire, hors périmètre. Renseignez-les avec des observations datées. Une maquette de formulaire ne doit pas figurer dans la même case qu’un parcours où une donnée a été enregistrée puis retrouvée après connexion.

Dans le scénario fictif, Salomé pourrait montrer la liste des pièces sur un dossier inventé, tout en précisant que les invitations et l’envoi des rappels restent à construire. Elle doit alors décider si le pilote peut commencer avec un accompagnement manuel annoncé, ou s’il dépend de ces fonctions.

N’appelez pas une intervention manuelle une automatisation. Si vous préparez vous-même le dossier ou envoyez le message après une vérification, dites-le. Cela peut être acceptable dans un pilote limité. La transparence permet surtout d’apprendre ce qui devra devenir autonome avant une offre plus large.

Le Service Manual britannique sur la phase beta décrit une ouverture progressive et l’apprentissage auprès d’utilisateurs réels. C’est une référence de conception de services publics, pas un modèle de contrat SaaS. Nous en retenons l’intérêt de limiter l’ouverture et de suivre le service pendant l’essai.

Définir la participation des deux côtés

Nommer un référent aide à savoir qui organise les essais et qui rassemble les retours. Identifiez aussi les utilisateurs et la personne qui peut décider de la suite. Ces rôles peuvent être tenus par des personnes différentes. Ne confiez pas au seul utilisateur la responsabilité d’un achat qu’il ne peut pas autoriser.

Pour chaque partie, listez les actions demandées : préparer un dossier autorisé, participer à une séance, tester un parcours, répondre à une question ou examiner le bilan. Précisez les disponibilités à confirmer. « Faire des retours réguliers » reste trop vague pour organiser le travail.

L’éditeur doit également dire ce qu’il fournit : accès, explication initiale, canal d’assistance et corrections dans le périmètre convenu. Un pilote ne doit pas devenir un échange où le client fournit du temps pendant que l’éditeur change librement les objectifs sans prévenir.

Prévoyez ce qui se passe si le référent est absent ou si les données ne sont pas prêtes. Il peut être nécessaire de déplacer une étape, réduire l’essai ou l’arrêter. Écrire cette possibilité dès le départ évite de considérer tout retard comme un manque d’intérêt pour le produit.

Fixer un calendrier avec des décisions

Un calendrier utile contient des étapes observables : préparation du dossier, accès disponible, premier essai, retour sur un blocage et bilan. Associez chaque étape à une personne et à une condition d’entrée. Une date seule ne dit pas si l’étape peut réellement commencer.

Séparez date souhaitée, date confirmée et dépendance extérieure. Si l’accès dépend d’une intégration non terminée, cette incertitude doit apparaître. Ne présentez pas une intention de développement comme un engagement ferme sans avoir examiné votre capacité de réalisation.

Dans le cas fictif, le premier essai pourrait dépendre de deux vérifications : retrouver un dossier enregistré et s’assurer que l’utilisateur ne voit que l’espace autorisé. Tant qu’elles manquent, Salomé peut montrer une maquette, mais elle ne doit pas présenter l’essai comme prêt à recevoir les vrais dossiers de Rivage.

À chaque point, prévoyez une décision courte : continuer, corriger avant de poursuivre, modifier le périmètre avec accord ou arrêter. Le calendrier sert à apprendre et à respecter l’engagement, pas à faire croire qu’un prototype se transforme en produit complet par le seul passage du temps.

Expliquer la contrepartie et les suites commerciales

Si vous envisagez un paiement, décrivez ce qu’il rémunère : participation au pilote, accès pendant une période définie, préparation accompagnée ou future livraison. Les mots utilisés sur la proposition, la page de paiement et les échanges doivent désigner la même chose. Un libellé flou prépare des attentes différentes.

Clarifiez ce qui arrivera après le pilote : fin de l’accès, proposition distincte, poursuite à confirmer ou autre scénario annoncé. Ne laissez pas un tarif futur inconnu se cacher derrière un « accès à vie » ou une remise impossible à comparer. Les conditions de départ doivent rester retrouvables.

Préparez les questions à faire examiner avant une offre engageante : retard, abandon, remboursement éventuel, facturation, données et responsabilités. La fiche jointe laisse ces décisions à compléter selon votre situation. Elle ne crée aucun droit particulier par elle-même et ne remplace pas la rédaction des documents nécessaires.

Si vous utilisez Stripe, sa documentation de test permet de simuler un paiement sans mouvement réel de fonds. Cela peut aider à vérifier le parcours affiché et les messages d’erreur. Un essai de paiement réussi ne valide ni votre offre commerciale ni l’accord de la personne sollicitée.

Lire correctement les signes d’engagement

Un intérêt verbal indique que la proposition mérite peut-être une discussion. Un accord pour essayer ajoute une action envisagée. Une intention d’achat peut rester conditionnelle. Un paiement atteste une transaction selon ses conditions. Ces signes ne sont pas interchangeables et aucun ne prouve à lui seul l’usage durable du produit.

Consignez les mots exacts et les réserves utiles. « Nous examinerons l’offre après la clôture du dossier actuel » est différent de « Envoyez la proposition au service achats ». Ne classez pas les deux en client acquis. Notez la prochaine action attendue et la date convenue, si elle existe.

Un refus peut aussi apporter une information précise : responsabilité impossible à transférer, disponibilité insuffisante ou résultat trop éloigné du besoin. Respectez la décision et demandez une explication seulement si la personne souhaite la donner. L’absence de paiement ne révèle pas automatiquement la cause du refus.

Même un pilote payé peut reposer sur votre accompagnement personnel, une relation de confiance ou une demande très particulière. Pour envisager un SaaS partagé, il faudra examiner ce qui reste vrai avec d’autres clients et sans toutes les interventions manuelles. Le pilote ouvre cette enquête ; il ne la termine pas.

Éviter que chaque demande devienne une promesse

Gardez un registre des demandes pendant l’essai. Pour chacune, notez le problème, l’effet sur le résultat visé et la décision prise. Une correction d’un comportement promis, une aide temporaire et une nouvelle fonction correspondent à trois travaux différents.

Si Rivage demande un module de facturation, Salomé peut reconnaître l’intérêt sans l’intégrer au pilote de collecte. Elle peut proposer de discuter ce besoin séparément après le bilan. Ce choix protège la compréhension de l’essai et la capacité à juger le résultat initial.

Lorsqu’un changement devient indispensable, réécrivez le périmètre, les dépendances et le calendrier avant de poursuivre. Demandez aux parties concernées de confirmer cette nouvelle version. Une liste de messages dispersés ne suffit pas à savoir sur quel engagement vous travaillez actuellement.

Préparer un bilan qui autorise aussi l’arrêt

Le bilan rapproche le résultat prévu des faits : tâche réalisée, aides nécessaires, erreurs rencontrées, éléments non vérifiés et avis des utilisateurs. Ajoutez la décision commerciale distincte. Une personne peut juger l’essai intéressant sans vouloir acheter ; une organisation peut acheter tout en demandant une adaptation.

Préparez une suite pour les données et les accès, que le pilote continue ou s’arrête. Vérifiez ce qui sera récupéré, conservé ou supprimé selon les conditions retenues. Ne laissez pas un espace ouvert indéfiniment parce qu’aucune des parties n’a explicitement pensé à la fin.

La fiche d’offre pilote à compléter contient le scénario de Rivage, les champs à discuter et une grille des engagements. Utilisez-la pour faire apparaître les désaccords et les inconnues avant la proposition finale. L’objectif est un petit accord précis dont les deux parties comprennent la portée.