Ne lancez pas un essai. Décidez d’abord ce que vous testez.

• Ce qui colle

  Est-ce que cela règle le problème que vous avez vraiment, pour le travail que vous faites vraiment ?

• Ce qui frotte

  Qu’est-ce qui sera pénible à configurer, à apprendre, à migrer ou à entretenir une fois la nouveauté passée ?

• Ce que vous cédez

  Qu’est-ce que vous échangez : de l’argent, de la souplesse, du contrôle, ou la facilité de partir ?

La plupart des mauvaises décisions logicielles ne viennent pas d’une fonction manquante. Elles viennent d’une adéquation jugée sans regarder les frottements, ou d’un renoncement que personne n’a écrit. Un produit peut faire tout ce que vous avez demandé et rester un mauvais achat si sa configuration réclame trois semaines que vous n’avez pas, ou si en partir suppose de reconstruire un travail qui ne s’exporte pas.

L’intérêt pratique des trois lectures est d’obliger à écrire une phrase pour chacune. Quel problème cela règle, dans des mots qu’un collègue reconnaîtrait. Ce qui sera pénible, nommé précisément plutôt que balayé d’un haussement d’épaules. Ce que vous cédez : de l’argent, de la souplesse, du contrôle, ou la possibilité de changer d’avis à bas prix.

L’habitude la plus utile est d’écrire le problème avant que l’essai commence. Un essai lancé sans question devient une visite ; un essai lancé avec une question devient un test dont on a la réponse à la fin.

Travaillez avec des données réelles. Un espace rempli de fiches d’exemple se comporte parfaitement et ne prouve rien sur le client dont le nom contient une apostrophe, ni sur la demande arrivée sans numéro de téléphone. Un frottement trouvé pendant l’essai ne coûte rien ; le même frottement trouvé au troisième mois, si.

Posez ces questions tant que vous avez encore un moyen de pression. Une fois l’engagement annuel signé, « que se passe-t-il si nous voulons partir en mars » devient une question théorique. La plupart des fournisseurs répondent simplement ; ceux qui renvoient vers un rendez-vous commercial vous disent aussi quelque chose.

Un essai vous montre le produit à son meilleur : vide, rapide, avec des invites d’accueil et une assistance qui répond. Il ne vous montre pas le produit à trois mille fiches, avec deux ans d’historique, un collègue parti et une intégration cassée parce que l’autre éditeur a changé son API. Ce sont pourtant ces conditions qui décident si vous continuez à payer, et aucun essai ne les reproduit.

Ce qu’un essai montre vraiment, si on s’en sert exprès : si la forme du produit correspond à la forme de votre travail, combien de temps prend une tâche réelle, comment le logiciel se comporte avec des données imparfaites, et si les gens qui ne sont pas vous le supporteront. Ces quatre réponses valent plus qu’une liste de fonctions deux fois plus longue.

Imaginez une agence de quatre personnes qui évalue une plateforme censée remplacer trois abonnements. Ce qui colle : la panne qu’elle sait nommer, c’est que les devis restent sans réponse pendant quinze jours ; le test consiste donc à vérifier qu’un devis peut porter un responsable, une date et une relance automatique. Ce qui frotte : elle n’a pas d’administrateur, donc tout ce qui exige un spécialiste est un coût qu’elle ne paiera pas. Ce qu’elle cède : réunir trois outils en un revient à confier tout l’historique client à un seul fournisseur, ce qui rend le test d’export non négociable. Voilà une évaluation. Le reste est du lèche-vitrine.

Trois pages appliquent la méthode à un produit, GoHighLevel, qui est aussi celui sur lequel ce site perçoit une commission. C’est écrit au pied de chaque page, et c’est pourquoi ces pages citent l’éditeur avec des dates au lieu de demander qu’on les croie : les conditions d’essai telles qu’elles sont publiées, les prix tels qu’ils sont publiés, et une évaluation qui énumère les frottements et les renoncements aussi précisément que les points forts.