Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Pourquoi nous préférons perdre une vente plutôt que cacher une limite en petits caractères
Toute entreprise qui rédige sa propre page de tarifs dispose d'un raccourci bien précis et tentant : mettre en avant les bons côtés et reléguer les limites dans une note de bas de page, un article d'assistance à trois clics de distance, ou une formulation assez vague pour que la plupart des lecteurs retiennent l'interprétation la plus généreuse. Cela fonctionne, au sens étroit où cela convertit davantage d'inscriptions qu'une page qui annonce clairement chaque limite dès le départ. Cela produit aussi un coût prévisible, plus tard : un client qui découvre une limite à ses dépens, en pleine intégration ou sur une facture, et qui se sent désormais trompé plutôt que simplement informé.
Nous préférons le nombre plus faible d'inscriptions qui découle d'une présentation claire des limites au nombre plus élevé obtenu en laissant les gens s'inscrire sans bien comprendre ce qu'ils obtiennent. Le quota gratuit est de 2 500 requêtes par jour, compté par réseau et partagé entre l'usage sans clé et l'usage avec clé depuis ce réseau. C'est un chiffre réellement utile pour l'évaluation et les petits volumes, et c'est aussi, clairement, une limite. Le dire directement, au lieu de mettre en avant le mot « gratuit » et de laisser quelqu'un découvrir le plafond à travers une requête en échec, c'est la forme d'honnêteté qui nous coûte quelque chose à court terme.
Ce choix ne paraît mauvais que si l'on mesure le succès au seul nombre d'inscriptions. Mesuré sur toute la durée d'une relation client, il paraît différent. Un client qui a compris les limites avant de s'engager et a choisi de continuer malgré tout est un client qui ne se sentira pas surpris ni trompé plus tard, car rien dans sa situation n'a changé entre l'inscription et le moment où il atteint réellement un seuil. Un client qui s'est inscrit sur une impression plus vague, puis découvre le vrai plafond au moment où celui-ci l'affecte, a un grief légitime, et les griefs légitimes se transforment en plaintes publiques, en demandes de remboursement et en un coût pour la réputation qui dure plus longtemps que la valeur de l'inscription qui les a causés.
La même logique explique pourquoi les en-têtes de quota figurent dans chaque réponse et pas seulement dans le tableau de bord du compte, pourquoi les limites de débit sont publiées sous forme de vrais chiffres dans la documentation au lieu d'être décrites vaguement, et pourquoi la clé Unlimited est vraiment illimitée, et non illimitée avec un plafond souple non divulgué. Dans chacun de ces cas, la version plus vague et plus généreuse en apparence convertirait probablement un peu mieux à première vue, et c'est pourtant la version honnête que nous avons choisie.
Nous ne pensons pas que cela fasse de nous des modèles de vertu. Il s'agit plutôt d'un pari sur le type d'entreprise qui survit à l'utilisation réelle de son produit par ses clients, à grande échelle, pendant des années, et pas seulement à une inscription ponctuelle. Une page de tarifs optimisée uniquement pour maximiser les inscriptions considère l'inscription comme la ligne d'arrivée. Nous pensons que l'inscription est plutôt la ligne de départ, et que les petites lignes que vous n'avez pas lues sont exactement la partie de la relation qui détermine si les années suivant l'inscription se passent bien.