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.
Une offre gratuite est conçue pour l'une de deux raisons très différentes, et quelques minutes d'utilisation suffisent généralement pour savoir laquelle un fournisseur a choisie. La première version existe pour permettre à un développeur d'évaluer réellement un produit : assez de volume pour construire une vraie intégration, la faire tourner sur des données réelles et décider si elle vaut la peine de payer. La seconde existe pour offrir un avant-goût juste assez grand pour susciter l'intérêt et juste assez petit pour imposer presque immédiatement une décision de passage à l'offre supérieure, fonctionnant moins comme un outil d'évaluation que comme la première page d'un argumentaire commercial.
La nôtre se veut de la première sorte. 2 500 requêtes par jour depuis n'importe quelle adresse, sans clé, et 2 500 de plus par jour une fois que vous ajoutez une clé, comptées par réseau et partagées entre l'usage sans clé et avec clé depuis ce réseau. C'est suffisant pour construire et tester une vraie intégration, et non une quantité symbolique qui s'épuise dès le premier après-midi d'essai de l'API et vous oblige à prendre une décision d'achat avant d'avoir appris quoi que ce soit.
La distinction compte, car une offre gratuite dimensionnée comme un appât produit un type de décision précis, et mauvais. Un développeur qui épuise ses requêtes gratuites dès la première heure ne décide pas de passer à l'offre supérieure parce que le produit a prouvé sa valeur. Il décide s'il continue à consacrer du temps à une évaluation écourtée, souvent avant même d'avoir atteint les parties de l'intégration qui révéleraient si la qualité des données et la forme des réponses conviennent réellement à son cas d'usage. Ce n'est pas une vraie évaluation. C'est une évaluation tronquée, déguisée en essai gratuit.
Une offre gratuite dimensionnée pour une véritable évaluation coûte davantage au fournisseur, au sens direct où une part significative de cet usage ne se convertira jamais en revenu. Nous pensons que ce coût achète quelque chose qui en vaut la peine : un client qui passe à l'offre payante parce qu'il a réellement testé le produit et que celui-ci a fonctionné, et non parce qu'un compte à rebours ou un plafond de requêtes a imposé la décision avant la fin des tests. La conversion qui découle d'une véritable évaluation tend à être plus durable, car elle repose sur le produit plutôt que sur l'épuisement de la marge disponible pour continuer à l'évaluer.
Une offre gratuite généreuse remplit un second rôle, plus discret : elle couvre des cas d'usage modestes, permanents et à faible volume sans jamais exiger de compte payant. Un projet personnel, un petit outil associatif, un devoir d'étudiant : aucun n'a besoin de devenir client simplement pour continuer à fonctionner dans les limites d'un quota quotidien raisonnable. Une offre gratuite qui n'existe que pour expirer n'est pas conçue pour ce cas d'usage. La nôtre l'est, volontairement, car tout usage légitime d'une API n'a pas vocation à devenir une ligne dans le budget mensuel de quelqu'un.