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.
Les données ouvertes de fuseau horaire ne devraient pas être une fonctionnalité premium
La base de données des fuseaux horaires IANA est publique. Elle est maintenue ouvertement depuis des décennies et suit chaque changement de décalage, chaque règle d'heure d'été et chaque redécoupage de frontière décidé par les gouvernements. Presque toutes les recherches de fuseau horaire sérieuses sur internet, y compris la nôtre, reposent sur ce même jeu de données public. Alors, quand une API facture un prix premium distinct spécifiquement pour la recherche de fuseau horaire, en plus de ce qu'elle facture déjà pour le géocodage, il est légitime de se demander ce que ce supplément paie exactement.
Parfois, la réponse est légitime : le temps d'ingénierie consacré à maintenir exacte la correspondance entre coordonnées et frontières de fuseaux horaires à mesure que ces frontières évoluent, et l'infrastructure nécessaire pour servir les recherches à grande échelle. C'est un vrai travail, et il a un coût. Ce qui l'est moins, c'est de traiter les données de fuseau horaire comme une gamme de produits distincte avec son propre niveau de tarif, bien au-dessus du coût marginal d'une recherche, parce qu'elles peuvent être intégrées à un flux de travail dont le client a déjà besoin et qu'il est moins susceptible de comparer séparément.
Nous ne faisons pas du fuseau horaire une option premium à part. C'est un endpoint parmi d'autres, facturé au même prix que tous les autres : couvert par le quota quotidien gratuit, puis facturé au même tarif de 0,0001 € par requête que tout le reste, ou inclus dans la même clé Unlimited à 50 €. Il n'existe ni niveau distinct pour le fuseau horaire ni majoration pour demander l'heure qu'il est à des coordonnées données.
La recherche de fuseau horaire compte davantage que son nom peu séduisant ne le laisse penser. Les systèmes de planification, les chaînes de journalisation, les plateformes de réservation et tout ce qui doit afficher l'heure locale correcte à un utilisateur en dépendent. En cas d'erreur, une invitation à une réunion tombe avec une heure de décalage, un horodatage de journal induit une enquête en erreur ou un créneau de livraison promet la mauvaise heure locale. C'est exactement le type de recherche qui devrait être bon marché et ennuyeux, et non une ligne qui apparaît comme une hausse surprenante sur une facture.
Si la recherche de fuseau horaire est traitée ailleurs comme une fonctionnalité premium, c'est en partie parce que les changements d'heure d'été et les modifications de frontières font paraître les données sous-jacentes plus complexes que de simples codes de pays statiques. Ce sont réellement des données délicates à maintenir. Mais délicat à maintenir ne veut pas dire coûteux à servir par requête, et la tarification devrait suivre ce second critère, pas la complexité du premier.
Facturer un supplément pour les données de fuseau horaire crée aussi une mauvaise incitation au niveau de la conception des API : les fournisseurs cessent de vouloir les exposer directement et cherchent plutôt à les intégrer dans des offres groupées plus importantes et plus chères, partant du principe qu'une fonctionnalité dont personne ne peut vérifier le prix séparément est plus facile à majorer. Nous pensons que l'approche inverse inspire davantage confiance. Rendre l'endpoint simple, le facturer au même prix que tout le reste et laisser les développeurs l'utiliser aussi souvent que leur application en a besoin, sans calcul mental pour savoir si cette recherche-là fait partie des plus chères.