Dix jours d'essai — les vôtres, pas ceux du calendrier

Lundi soir, vous installez RideComposer. Vous désignez votre dossier de musique, l'analyse démarre — plusieurs heures sur une grande bibliothèque, souvent la nuit entière. Mardi, vous jetez un œil au résultat entre deux choses.

Mercredi, vous donnez cours. Avec votre ride habituel, celui que vous connaissez par cœur : on ne teste pas un logiciel neuf devant quarante personnes le premier jour.

Jeudi, vendredi : rien. Samedi, cours — encore avec l'ancien. Dimanche, enfin un moment : vous commencez à construire. Lundi, vous partez trois jours.

Jeudi de la semaine suivante, vous rouvrez le logiciel pour reprendre là où vous en étiez.

Votre essai est terminé.

Dix jours se sont écoulés. Vous avez ouvert RideComposer quatre fois. Vous n'avez jamais donné un seul cours construit avec.

Le calendrier n'était pas la bonne unité

Un instructeur ne prépare pas ses cours tous les jours. Il donne cours deux ou trois fois par semaine, et il prépare quand il a une heure devant lui — le dimanche matin, tard le soir, dans le train. Entre deux, le logiciel reste fermé.

Notre essai, lui, comptait les jours où il était fermé. Un week-end en famille coûtait deux jours. Un déplacement professionnel en coûtait trois. Une semaine chargée pouvait en emporter la moitié.

Et personne ne s'en plaignait. On ne réclame pas les jours qu'on n'a pas vus passer : on se dit simplement qu'on n'a pas eu le temps, et on passe à autre chose. C'est précisément ce qui rend ce genre de défaut durable — il ne fait de bruit chez personne.

Ce qui change aujourd'hui

Une journée d'essai ne se consomme que si vous ouvrez RideComposer. Dix journées d'utilisation réelle, à prendre dans une fenêtre d'un mois.

Ce que vous faites	Avant	Maintenant
Vous partez en week-end	Deux jours perdus	Rien
Vous l'ouvrez trois fois le samedi	Un jour	Un jour
Vous ne l'ouvrez qu'un jour sur trois	Coupé au dixième jour	Vous tenez le mois
Vous travaillez dix jours d'affilée	Dix jours	Dix jours

Celui qui s'en sert tous les jours ne voit aucune différence. Celui qui s'en sert quand il prépare — c'est-à-dire à peu près tout le monde — gagne le droit de vivre sa semaine.

Pourquoi un mois, et pas davantage

Parce qu'un essai sans échéance n'est plus un essai.

Trente jours, c'est assez long pour analyser votre bibliothèque, construire deux ou trois cours, les donner, et savoir ce que vous en pensez. Et c'est assez court pour que la question se pose vraiment. Nous préférons vous le dire franchement plutôt que de laisser traîner une durée floue.

Si votre essai est déjà terminé, relancez le logiciel

La nouvelle règle ne concerne pas que les nouvelles installations. Elle a été appliquée à tous les essais existants.

Si vous avez installé RideComposer il y a moins de trente jours et que vos dix jours se sont écoulés sans que vous ayez eu le temps de vous en servir, il vous reste des journées. Ouvrez le logiciel, vous verrez.

Rien à télécharger, rien à réinstaller, rien à demander.

Un mot sur le « rien à mettre à jour »

Pour ceux que la mécanique intéresse : l'application ne décide pas de votre essai. Elle pose la question à notre serveur au démarrage, et affiche la réponse.

Changer la règle, c'était donc changer une seule chose, à un seul endroit — et elle vaut immédiatement pour tout le monde, y compris pour les versions installées le mois dernier. C'est aussi ce qui nous permet de vous rendre du temps sans rien vous demander.

Ce qu'un essai doit vraiment servir à mesurer

Un essai ne sert pas à vérifier qu'un logiciel démarre, ni que les boutons répondent. Ça, dix minutes suffisent.

Il sert à répondre à une seule question : est-ce que mes cours seront meilleurs avec ? Et cette réponse ne se trouve pas devant un écran. Elle se trouve en salle, le jour où le bloc tombe juste, où la transition passe inaperçue, et où la salle suit sans que vous ayez eu à crier.

Dix jours d'écran, c'était trop court pour y arriver. Dix jours de travail, ça laisse le temps.