Le pilote a été validé avec un réel enthousiasme. Huit utilisateurs nommés, quatre semaines, un canal partagé et une restitution déjà dans l'agenda. La première semaine se passe bien : tout le monde se connecte, les questions arrivent, quelqu'un importe un vrai jeu de données et trouve cela prometteur.
La deuxième semaine est calme. La troisième est silencieuse. Le jeudi précédant la restitution, quelqu'un côté client demande si le pilote pourrait être prolongé, parce que les équipes ont été très prises et qu'elles veulent lui laisser une vraie chance. Parfois, la prolongation aboutit à une décision. Le plus souvent, elle aboutit à un deuxième mois calme et à un message poli, à l'automne, expliquant que les priorités ont changé.
Le produit n'a rien fait de travers. Le problème, c'est qu'un pilote est un problème d'onboarding déguisé en démarche commerciale, et qu'il a été mené uniquement comme une démarche commerciale. Ce guide explique ce qui distingue un pilote d'un essai et d'une bêta, les trois points à valider avant le premier jour, comment en définir le périmètre, la chute d'usage de la deuxième semaine qui décide de la plupart des pilotes, le point d'étape à mi-pilote, comment mener une restitution qui débouche sur une réponse, et ce qu'il faut mesurer pendant le pilote.
À retenir
- Un pilote se définit par sa fin. Des critères convenus, une date et un décideur nommé. Sans ces trois éléments, ce n'est qu'un essai prolongé.
- Les pilotes meurent d'inactivité, pas de déception. L'échec vient le plus souvent du fait que trop peu de participants nommés ont utilisé le produit assez pour en juger.
- Un périmètre assez étroit pour boucler un vrai cycle. Un pilote plus large ne produit pas davantage de preuves, seulement davantage de calendrier.
- Le point d'étape à mi-pilote est la seule véritable intervention. Au moment de la restitution, tout est déjà joué.
- Mesurez la participation, pas le ressenti. Le nombre d'utilisateurs nommés ayant atteint un résultat réel est le chiffre qui prédit la décision.
Ce qu'est réellement un pilote
Le programme pilote, en un paragraphe
Un programme pilote, aussi appelé preuve de concept (POC), est une évaluation limitée dans le temps au cours de laquelle un client potentiel utilise votre produit pour un vrai travail, avec de vraies données et un groupe de personnes nommées, afin de décider s'il l'achète. Ce qui en fait un pilote plutôt qu'un long essai, c'est la décision attachée à sa fin : des critères de succès convenus, une date fixe et une personne qui répondra oui ou non. Retirez l'un de ces éléments et l'évaluation expirera au lieu de se conclure.
Le terme est employé de façon approximative, ce qui fait de réels dégâts, car les trois notions avec lesquelles on le confond appellent des traitements opposés.
| Essai gratuit | Pilote / POC | Bêta | |
|---|---|---|---|
| Qui participe | Une personne, de sa propre initiative | Un groupe nommé au sein d'un comité d'achat | Des clients existants volontaires |
| Ce qu'il faut prouver | Si le produit convient à cette personne | S'il produit un résultat métier convenu | Si une fonctionnalité inachevée est prête |
| Qui décide | L'utilisateur, de manière informelle | Un sponsor nommé, de manière formelle | Votre équipe produit |
| Comment cela se termine | Il expire | Une restitution et une décision | Une mise en production |
| Échec typique | Un utilisateur n'atteint jamais la valeur | Trop peu de participants l'ont utilisé pour juger | Des retours trop maigres pour agir |
Deux conséquences en découlent. D'abord, la méthode qui fonctionne pour la conversion des essais gratuits (optimiser pour qu'une personne atteigne rapidement la valeur) est nécessaire mais pas suffisante dans un pilote, car un pilote est jugé sur le groupe. Ensuite, un programme bêta vise à apprendre et peut tolérer une expérience inachevée ; un pilote vise à prouver, et ne le peut pas.
Trois points à valider avant le premier jour
Presque tous les pilotes sauvés l'ont été au début plutôt qu'en cours de route. Ces trois accords prennent une heure et déterminent si l'évaluation pourra seulement se conclure.
1. Des critères de succès dans les chiffres du client
Deux ou trois résultats, écrits noir sur blanc, exprimés dans les unités que le client utilise déjà et observables pendant la durée du pilote. Des validations bouclées en moins d'une journée au lieu de trois. Deux cents enregistrements traités sans correction manuelle. Le rapport du lundi produit sans aucun export. Des critères comme l'équipe trouve l'outil simple à utiliser ne peuvent pas être réfutés, ce qui signifie qu'ils ne peuvent pas non plus être prouvés, et un pilote qu'on ne peut pas rater est un pilote qu'on ne peut pas réussir.
Lorsque les critères ne sont pas visibles dans votre produit, décidez à l'avance comment ils seront observés. Sinon, vous aurez une restitution où chaque partie se souvient différemment des quatre dernières semaines.
2. Le périmètre : un vrai cycle, un vrai jeu de données, une vraie équipe
Choisissez la tranche de travail la plus étroite qui, si elle fonctionne, se transpose à tout le reste. Des deux côtés, le réflexe est de prouver le plus possible, ce qui donne un pilote dispersé sur cinq équipes et concluant sur rien. Un pilote qui prouve un seul workflow de bout en bout avec de vraies données est plus convaincant qu'un pilote qui a effleuré six workflows avec des données de test, et il est bien plus facile à mener à terme.
3. Une date et un décideur nommé
La restitution est inscrite au calendrier avant le début du pilote, avec la personne qui décidera présente à cette réunion. Si personne ne peut nommer le décideur à l'avance, c'est l'information la plus utile que vous apprendrez de tout le trimestre, et mieux vaut l'apprendre en semaine zéro. Convenez aussi de ce qui se passe pour chaque issue, y compris ce que signifie un « non », car un pilote sans issue négative définie a tendance à finir en prolongation plutôt qu'en réponse.
Un pilote sans fin définie n'échoue pas. Il s'évapore. Les prolongations semblent généreuses et marquent généralement le moment où un pilote cesse d'être une évaluation active pour devenir un compte laissé à l'abandon.
Choisir la cohorte
La liste des participants est souvent constituée de ceux qui sont disponibles, ce qui décide discrètement de l'issue. Trois règles rendent le groupe assez représentatif pour prouver quelque chose et assez petit pour être accompagné.
Petit et nominatif. Six à dix personnes, identifiées individuellement plutôt qu'en tant qu'équipe. « L'équipe des opérations » donne un pilote où chacun suppose que quelqu'un d'autre s'en occupe. Une liste de noms crée de la responsabilité et, tout aussi important, vous donne un dénominateur pour mesurer la participation.
Incluez un sceptique. Un pilote composé uniquement d'enthousiastes prouve que les enthousiastes aiment votre produit. L'objection qui sera soulevée au moment de la décision d'achat a tout intérêt à l'être en deuxième semaine, quand vous pouvez encore y répondre.
Incluez la personne qui fait le travail au quotidien. Les pilotes évalués uniquement par des managers mesurent l'impression laissée par le produit plutôt que le produit lui-même. L'utilisateur quotidien est aussi celui dont le comportement vous dit si la valeur est réelle, car c'est le seul participant pour qui utiliser l'outil n'est pas une faveur.
La chute de la deuxième semaine
L'usage pendant un pilote suit une courbe si régulière qu'on peut l'anticiper. La première semaine est chargée, parce que le pilote est nouveau et qu'il y a eu un lancement. La deuxième s'effondre, parce que le travail habituel reprend et que rien dans la journée du participant ne dépend du pilote. Les semaines trois et quatre sont calmes. Puis survient un petit pic juste avant la restitution, quand les gens se souviennent de la réunion.
L'usage se concentre aux deux extrémités. Le milieu est justement la période où les preuves devaient être réunies.
Cette chute n'est pas un signe de désintérêt. C'est ce qui arrive à toute activité volontaire une fois la nouveauté passée : le participant avait l'intention d'utiliser le produit, puis une vraie échéance est arrivée. Quand il revient, il a oublié la configuration faite en première semaine et doit réapprendre un peu, et c'est précisément le moment où l'on remet à plus tard.
Le remède est peu spectaculaire mais efficace : rendre le retour peu coûteux. Un participant qui revient en troisième semaine doit retrouver immédiatement où il en était, avec l'étape suivante bien visible, sans avoir à demander à qui que ce soit. Cela suppose un guidage dans le produit qui résiste à l'interruption : une checklist montrant ce qu'il a fait et ce qui reste, une aide contextuelle sur les écrans qu'il n'a vus qu'une fois, et une courte invite sur le chemin menant aux critères de succès du pilote. Tout ce qui dépend de la disponibilité d'un humain échouera ici, car le réapprentissage a lieu un mardi à 7 h 40.
C'est aussi pour cette raison que les participants d'un pilote doivent être onboardés avec autant de soin que des clients payants, et non plus légèrement. La cohorte d'un pilote a moins de patience qu'un nouveau client, pas plus : elle ne s'est pas encore engagée, et abandonner discrètement ne lui coûte rien. Les principes d'activation de notre guide pour augmenter l'activation des utilisateurs s'appliquent ici, en plus intense.
Le point d'étape à mi-pilote
Placez un point d'étape à la fin de la deuxième semaine, inscrit au calendrier dès le premier jour, et traitez-le comme la réunion la plus importante du pilote. La restitution est un moment de compte rendu ; le point d'étape est le seul moment où l'issue peut encore être modifiée.
Apportez des données de participation plutôt que des impressions : combien d'utilisateurs nommés se sont connectés, combien ont atteint chaque critère de succès, où les gens se sont arrêtés. Ce dernier point est celui qui produit une conversation utile, car il transforme une inquiétude vague en quelque chose de réparable. Trois participants bloqués sur le même écran de configuration, c'est un problème soluble. « Ça n'a pas beaucoup servi », non.
La complétion par étape transforme le point d'étape à mi-pilote en conversation factuelle : qui a atteint quel critère, et où les gens se sont arrêtés.
Le point d'étape vous protège aussi de la demande de prolongation. Quand une revue à mi-pilote a déjà établi que quatre personnes sur huit sont actives, une prolongation peut se négocier comme un plan de réengagement avec une nouvelle date, plutôt que s'accorder comme une vague continuation. Les prolongations accordées sans changement de plan produisent généralement une seconde période d'usage identique.
Une discipline utile. Si la participation est inférieure à la moitié de la cohorte au point d'étape, traitez la participation avant toute autre chose. Aucune objection produit ne mérite de réponse quand l'objection est que personne n'a encore regardé.
Mener la restitution
La restitution fonctionne mieux sous la forme d'une réunion courte et structurée que d'une démonstration. Passez en revue les critères convenus un par un et dites clairement si chacun a été atteint, y compris ceux qui ne l'ont pas été. Reconnaître un échec d'emblée est ce qui rend le reste crédible, et un pilote qui a atteint deux critères sur trois, avec une explication claire du troisième, convertit plus souvent qu'un pilote présenté comme un succès sans faute.
Deux ajouts font porter la réunion. Montrez le tableau de participation (qui l'a utilisé, combien, pour quels résultats), car un sponsor qui n'a rien entendu depuis un mois a besoin de savoir que les preuves sont réelles. Et apportez l'esquisse de déploiement : à quoi ressembleraient les quatre-vingt-dix premiers jours après un oui, qui serait onboardé dans quel ordre, et ce que cela exigerait de leur part. Un décideur qui dit oui n'achète pas le pilote, il achète le déploiement, et l'esquisse répond à la question qu'il est réellement en train de peser. Les principes de passation de notre guide sur la passation entre ventes et onboarding s'appliquent dès que ce oui arrive, et les pilotes convertissent plus vite quand la transition semble déjà conçue.
Lorsque le pilote s'oriente vers un déploiement multi-équipes, la structure par comptes et par licences du guide sur l'onboarding en entreprise est le bon cadre pour cette esquisse à quatre-vingt-dix jours.
Ce qu'il faut mesurer pendant un pilote
1. La participation des utilisateurs nommés
La part de la cohorte convenue qui a utilisé le produit, ne serait-ce qu'une fois, cette semaine. C'est le signal le plus précoce disponible et celui qui est le plus fortement lié à la décision finale. Suivez-le en proportion de la liste nominative, jamais en nombre total de sessions, car deux utilisateurs enthousiastes peuvent faire paraître sain un pilote inactif.
2. Les critères atteints
Pour chaque critère de succès convenu, combien de participants l'ont réellement atteint dans le produit. C'est la restitution, construite en continu plutôt que la veille au soir, et elle fait de la réunion finale une confirmation plutôt qu'une révélation.
3. Le délai avant le premier résultat réel
Le nombre de jours entre l'accès et le moment où un premier participant accomplit un vrai travail, pas un exemple. C'est la version pilote du time to value, et quand il dépasse la première semaine, la chute fera le reste. Quand il est lent, la cause est presque toujours la mise en place : les données, les droits d'accès ou une intégration dont personne n'était responsable.
4. Le point d'abandon
L'étape à laquelle les participants s'arrêtent le plus souvent. Dans un pilote, elle vaut davantage que n'importe quel agrégat, car le groupe est assez petit pour qu'un seul écran bloquant explique toute la courbe. C'est le même raisonnement que celui d'un funnel d'onboarding, appliqué à une cohorte de huit personnes.
Sept façons dont les pilotes échouent
1. Aucun décideur dans la salle
Le pilote est mené par un champion enthousiaste qui s'avère ne pas détenir le budget. Tout se passe bien et rien ne se produit. Nommez le décideur avant le premier jour, ou acceptez qu'il s'agit d'une exploration et non d'une évaluation.
2. Des critères rédigés après coup
Quand le succès est défini lors de la restitution, chaque partie le définit comme ce qui s'est passé, et la réunion devient une négociation sur l'interprétation plutôt qu'une décision.
3. Un périmètre impossible à boucler
Cinq équipes, trois workflows, deux intégrations et quatre semaines. L'ampleur rassure et garantit que rien ne sera prouvé de façon concluante.
4. Des données d'exemple au lieu de vraies données
Un pilote mené sur des données de démo prouve que le produit fonctionne sur des données de démo. C'est dans les vraies données que se trouvent les cas limites, et ce sont eux qui intéresseront le sceptique.
5. Un onboarding confié au seul appel de lancement
Une session en direct, aucun guidage ensuite, et un participant qui revient en troisième semaine sans se souvenir où se trouve quoi que ce soit. C'est la plus fréquente et la plus facile à corriger des sept.
6. Aucune visibilité sur l'usage
Un pilote suivi uniquement comme une étape du pipeline commercial signifie que le premier signe de difficulté arrive à la restitution, quand plus rien ne peut être fait. Quelqu'un de votre côté doit pouvoir consulter la participation chaque semaine.
7. La prolongation automatique
Accorder plus de temps sans changer le plan revient à répéter le même mois. Si une prolongation se justifie, elle doit s'accompagner d'une nouvelle cohorte, d'un périmètre plus restreint ou d'une nouvelle date : bref, de quelque chose de différent.
Mener un pilote avec Kompassify
La partie d'un pilote qui reste le plus souvent sans pilotage est l'expérience des participants entre le lancement et la restitution, parce qu'elle se déroule dans le produit, là où la démarche commerciale ne voit rien.
Avec Kompassify, vous pouvez offrir à la cohorte pilote sa propre couche de guidage, sans travail d'ingénierie : un court parcours guidé à la première connexion qui mène directement aux critères de succès convenus plutôt qu'à une visite de tout le produit, une checklist d'onboarding de pilote dont les étapes sont les critères eux-mêmes, pour que la progression soit visible par le participant comme par vous, une aide contextuelle sur les écrans que les gens n'ont vus qu'une fois pendant le lancement, et une invite qui ramène un participant de retour en troisième semaine à l'étape suivante plutôt qu'à l'écran d'accueil. Comme les parcours sont ciblés par segment, tout cela ne s'applique qu'au groupe pilote et disparaît lorsque le compte passe à un déploiement normal.
Les données de complétion par étape transforment aussi le point d'étape à mi-pilote en conversation factuelle : vous pouvez dire quels critères ont été atteints et par qui, et où dans le parcours les gens se sont arrêtés, quatre semaines avant que quiconque ait à se forger une opinion.
Ne perdez plus vos pilotes en deuxième semaine
Offrez à chaque cohorte pilote un parcours guidé vers ses propres critères de succès, voyez quels participants y sont parvenus et corrigez l'étape bloquante pendant que l'évaluation est encore en cours. Sans code. Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres à partir de 129 $/mois, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →La version en un paragraphe
Un pilote est une évaluation assortie d'une décision, ce qui suppose des critères convenus dans les chiffres du client, une date fixe et un décideur nommé, le tout réglé avant le premier jour. Limitez-le à un vrai cycle de travail réel avec une petite cohorte nominative qui inclut un sceptique et une personne qui fait le travail au quotidien. Puis anticipez la forme que prend réellement l'usage d'un pilote : une première semaine chargée, un effondrement en deuxième, et un pic de panique avant la restitution. Rendez le retour peu coûteux grâce à un guidage dans le produit qui ramène le participant à l'étape suivante sans intervention humaine, organisez un point d'étape à mi-pilote à la fin de la deuxième semaine avec des données de participation plutôt que des impressions, et traitez une faible participation comme le problème à résoudre avant toute objection produit. Menez la restitution critère par critère, reconnaissez ce qui n'a pas été atteint et apportez une esquisse de déploiement à quatre-vingt-dix jours, car le sponsor décide du déploiement plutôt que du pilote. Mesurez la participation des utilisateurs nommés, les critères atteints, le délai avant le premier résultat réel et le point d'abandon, et considérez toute prolongation accordée sans changement de plan comme le début d'un deuxième mois silencieux.
Questions fréquentes
Qu'est-ce qu'un programme pilote en SaaS ?
Un programme pilote, souvent appelé preuve de concept, est une évaluation limitée dans le temps au cours de laquelle un client potentiel utilise votre produit pour un vrai travail, avec de vraies données et un groupe de personnes défini, afin de décider s'il l'achète. Ce qui le caractérise n'est ni sa durée ni son prix, mais la décision attachée à sa fin : un pilote a des critères de succès convenus, une date et une personne nommée qui dira oui ou non. Une évaluation sans ces trois éléments n'est pas un pilote, c'est un essai prolongé qui expirera discrètement.
Quelle est la différence entre un pilote et un essai gratuit ?
Un essai gratuit est en libre-service, individuel et ouvert dans son intention : une personne explore le produit pour voir s'il lui convient, et l'essai se termine en expirant. Un pilote est collectif, cadré et tourné vers une décision : un groupe utilise le produit au regard de critères convenus, et il se termine par une réunion où quelqu'un tranche. Ils échouent aussi différemment. Un essai échoue quand un seul utilisateur n'atteint pas la valeur, tandis qu'un pilote échoue généralement parce que trop peu de participants nommés l'ont utilisé suffisamment pour que quiconque puisse juger.
Combien de temps doit durer un pilote SaaS ?
Assez longtemps pour boucler un vrai cycle du travail que votre produit prend en charge, et pas plus. Pour la plupart des produits, cela représente quatre à six semaines ; pour les produits liés à un processus mensuel ou trimestriel, un cycle complet plus une semaine. Les pilotes plus longs produisent rarement davantage de preuves, car l'usage se concentre sur les deux premières semaines et la dernière. Si un pilote a besoin de trois mois pour prouver quoi que ce soit, la preuve recherchée est généralement trop large, et resserrer le périmètre est une meilleure réponse que rallonger le calendrier.
Un pilote doit-il être payant ou gratuit ?
Un pilote payant achète de l'engagement : quand une ligne budgétaire existe, les participants sont nommés, du temps est alloué et quelqu'un en interne doit rendre compte d'un résultat. Un pilote gratuit abaisse la barrière d'entrée et augmente le risque de dérive, car personne dans l'organisation du client n'a à justifier le temps passé. Lorsque la mise en place exige un réel effort de la part du client, facturer quelque chose, même des frais d'implémentation symboliques, améliore généralement davantage le taux de complétion que n'importe quelle quantité de relances.
Pourquoi les pilotes échouent-ils alors que le produit fonctionne ?
Parce qu'ils n'ont pas été assez utilisés. L'échec le plus courant n'est pas un produit décevant mais une cohorte qui ne s'est jamais impliquée : les comptes ont été créés, deux des huit utilisateurs nommés se sont connectés, et lors de la restitution personne ne pouvait se prononcer sur le résultat. L'enthousiasme est maximal les premiers jours et chute fortement dès que le travail habituel reprend, si bien que le vrai travail pendant un pilote consiste à garder un petit groupe actif pendant quelques semaines, ce qui relève de l'onboarding plutôt que de la vente.
Quels doivent être les critères de succès d'un pilote ?
Deux ou trois résultats exprimés dans les chiffres du client, convenus par écrit avant le démarrage et mesurables pendant la durée du pilote. De bons critères ressemblent à un processus précis qui s'accélère, à un volume précis qui est traité ou à une erreur précise qui disparaît. De mauvais critères sont la satisfaction, la facilité d'utilisation ou le fait que l'équipe apprécie l'outil, car ils ne peuvent pas être réfutés et ne peuvent donc pas non plus être prouvés. Si les critères ne peuvent pas être observés dans le produit, décidez avant le pilote comment vous les observerez.
Qui doit porter le pilote en interne ?
Une personne nommée de chaque côté, le fournisseur étant responsable de la dynamique et le client de la décision. L'échec fréquent est un pilote porté par un commercial qui le suit comme une étape de son pipeline et ne voit rien de ce qui se passe dans le produit, si bien que le premier signe de difficulté est la restitution elle-même. Associer le responsable commercial à la personne qui peut voir l'usage, et convenir à l'avance d'un point d'étape à mi-pilote, règle l'essentiel du problème.