Ce qu'une période d'essai peut prouver — et ce qu'elle ne prouve pas

Une période d'essai mesure de façon fiable une seule chose : ce que donne le début. L'inscription, la première impression, les premiers gestes. Ce n'est pas rien, car un début pénible s'améliore rarement. Mais ce n'est pas non plus ce dont dépend votre décision.

Ce qui porte la décision, c'est le comportement en activité : sous pression, avec des données accumulées, dans les cas particuliers. Une période d'essai standard ne peut structurellement pas saisir cela — non par malhonnêteté de l'éditeur, mais parce que deux semaines avec une base vide sont un autre système que deux ans avec une base pleine. Qui le sait peut monter un essai qui prouve tout de même quelque chose.

Commençons par ce qui fonctionne, car c'est plus que ce qu'on croit. Un essai répond solidement à quatre questions, et les quatre méritent une réponse.

Combien de temps dure le début ? De l'inscription à la première opération réelle. Si au bout de quatre-vingt-dix minutes vous n'avez toujours pas créé un rendez-vous, c'est un constat et non une difficulté de démarrage.

Vous en sortez-vous sans mode d'emploi ? Cliquez volontairement sans ouvrir l'aide. Là où vous bloquez à l'essai, vous bloquerez aussi en activité — mais avec du public.

En combien de temps le support répond-il ? Posez pendant l'essai une vraie question, pas une question de test. Le délai de réponse pendant l'essai est habituellement le meilleur que vous verrez jamais : c'est votre plafond, pas votre moyenne.

Quel effet fait le geste le plus fréquent ? Pas la fonction rare, mais celui que vous répétez vingt fois par jour. Deux secondes d'écart par opération font quarante secondes sur vingt opérations : invisible sur une journée, mais près de trois heures sur une année d'environ 250 jours travaillés.

Presque toute entreprise de service a des semaines qui n'ont rien à voir entre elles. Un salon en janvier et le même salon la semaine avant Noël sont deux entreprises. Un garage en juin et le même garage à la veille des grands départs également. Une école la deuxième semaine de novembre et la même école aux conseils de classe, à plus forte raison.

Si vous testez un logiciel dans la semaine calme, vous le testez dans des conditions où presque tout système fonctionne. L'essai vous confirme alors une chose qui n'a jamais fait débat et reste muet sur ce qui vous coûtera plus tard.

Le remède demande moins d'efforts qu'on ne le suppose :

• Placez l'essai dans une semaine chargée, pas pendant les vacances. Mieux vaut échouer en conditions réelles que réussir en conditions idéales.
• Ou demandez une prolongation. La plupart des éditeurs prolongent un essai sur demande motivée. Ce courriel coûte deux minutes.
• Ou reconstituez la pointe. Reprenez un vrai samedi de l'an dernier et saisissez-le en une heure dans le système d'essai. Vous saurez ensuite à quoi ressemble une journée pleine sans avoir à l'attendre.

Le dernier point a un effet secondaire à ne pas négliger : vous mesurez au passage combien de temps prend la saisie elle-même. Ce n'est pas un mauvais exercice, car c'est exactement le travail que vous referez lors de la reprise.

Un système vide est rapide, lisible et rangé. Il n'a pas de doublons, pas de clients anciens sans numéro de téléphone, pas de prestation supprimée depuis deux ans qui traîne encore dans la liste. Or c'est précisément de cela que le quotidien est fait.

La mesure la plus efficace dans tout essai est donc d'y faire entrer de vraies données — au moins un échantillon. Deux cents fiches clients et trois mois d'historique suffisent à répondre aux questions que cinq enregistrements de démonstration laissent invisibles : à quoi ressemble la recherche quand quatre personnes portent un nom voisin ? Que devient une fiche sans adresse électronique quand le système veut envoyer une confirmation ? Peut-on fusionner deux doublons sans perdre l'historique ?

Deux points comptent ici. Premièrement : un système d'essai reste un système où se trouvent de vraies données personnelles. Le traitement a besoin de la même base qu'en production, et si l'éditeur traite pour vous, il faut un contrat de sous-traitance — dans le cadre européen du RGPD, c'est l'article 28, et il vaut dès la première fiche d'essai, pas à partir de la première facture.

Deuxièmement : exigez dès l'essai que les données de test soient supprimables. Si vous renoncez à cet éditeur, vous voulez ces deux cents fiches hors du monde. Un système qui ne sait pas le faire seul vient de répondre à une question bien plus large.

La raison la plus fréquente pour laquelle un essai s'écoule sans résultat n'est pas le manque de temps. C'est que personne n'a fixé d'avance ce qui devait être testé. On clique çà et là, on trouve l'ensemble convenable, et au quatorzième jour la question est intacte.

Un plan utilisable tient sur une demi-page et comporte trois opérations réelles que vous menez du début à la fin — pas effleurées, terminées. Pour la plupart des entreprises, ce sont :

1. L'opération standard complète. De la demande au justificatif payé en passant par le rendez-vous, telle qu'elle se déroule vraiment chez vous.
2. Le cas particulier. Annulation de dernière minute, report, avoir, paiement partiel, correction d'une facture après coup. Les cas particuliers font une petite part des opérations et la plus grande part des ennuis.
3. Le regard en arrière. Que s'est-il passé le mois dernier ? Qui n'est plus venu depuis un an ? Une statistique que vous ne trouvez pas en deux minutes, vous ne la regarderez jamais.

S'y ajoute un exercice obligatoire qui ne prend pas dix minutes et que presque personne ne fait : déclenchez une fois un export complet et ouvrez le fichier. Non pour vous en servir, mais pour voir ce qu'il contient. C'est le seul moment où cette vérification ne coûte rien, et le seul constat de l'essai qui décidera plus tard de votre chemin de retour.

Des critères d'arrêt paraissent excessifs tant qu'on n'en a pas besoin. Ils protègent pourtant de l'effet le plus puissant de tout essai : après dix heures investies, plus personne ne veut entendre que le logiciel ne convient pas. On n'a plus testé un logiciel, on a défendu une décision.

Écrivez donc, avant la première connexion, deux ou trois phrases qui vous feront arrêter. Assez concrètes pour qu'une personne extérieure puisse les vérifier. Par exemple : « si je ne peux pas créer un rendez-vous standard en moins de trente secondes ». Ou : « si l'export ne contient pas l'historique des rendez-vous ». Ou : « si ma question au support reste sans réponse après deux jours ouvrés ».

De telles phrases rendent l'arrêt bon marché, et c'est là tout leur objet. Elles vous épargnent en outre la variante la plus désagréable : le contrat conclu parce que l'essai est arrivé à son terme et que personne n'a rien dit. Vérifiez donc dès le premier jour si votre accès d'essai bascule automatiquement en abonnement payant, et où exactement cela se désactive. Cette information a sa place au début de l'essai, pas à sa fin.

Et si vous arrêtez : dites brièvement à l'éditeur ce qui n'allait pas. Ce n'est pas une faveur que vous rendez — c'est le seul retour dont un produit apprenne réellement quelque chose.