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 avons conçu ce service comme nous voudrions l'acheter
Nous construisons et exploitons une API de géocodage. C'est toute l'entreprise. Chaque décision décrite dans le reste de ces articles (une tarification à la requête plutôt qu'au nombre d'utilisateurs, une offre gratuite sans clé plutôt qu'un essai à durée limitée, des hôtes compatibles plutôt qu'un format propriétaire, des en-têtes de quota sur chaque réponse plutôt qu'un tableau de bord en retard) découle du même test simple que nous n'avons cessé d'appliquer pendant sa construction : est-ce que cela nous agacerait si nous étions le client de l'autre côté.
La plupart des mauvaises habitudes dont nous avons parlé dans cette série échouent immédiatement à ce test, dès que l'on s'imagine réellement être celui qui les paie. Personne ne veut découvrir une limite de débit par une requête échouée en production. Personne ne veut d'une offre « illimitée » qui s'avère assortie d'une politique d'usage raisonnable. Personne ne veut d'une migration qui prend un trimestre parce que le SDK du fournisseur précédent a disséminé ses formats dans une base de code pendant des années. Ce ne sont pas des plaintes obscures. Ce sont des situations que presque tous les développeurs ont vécues de l'autre côté d'une relation avec une API, et c'est justement pourquoi nous ne pensons pas qu'il faille une étude client pour les identifier comme des problèmes à éviter.
La tarification était l'endroit le plus évident pour appliquer ce principe. 2 500 requêtes gratuites par jour depuis n'importe quelle adresse, sans aucune clé. Quand vous avez besoin de plus, inscrivez-vous avec une adresse e-mail et rechargez du crédit prépayé à 0,0001 € la requête ou prenez une clé Unlimited à 50 € par mois. Chaque endpoint et chaque hôte compatible coûte le même prix. Nous n'y sommes pas arrivés par un exercice d'optimisation tarifaire conçu pour maximiser le revenu par client. Nous y sommes arrivés en nous demandant à quoi ressemblerait un prix juste et honnête pour ce produit aux yeux de quelqu'un qui a déjà été agacé par des paliers opaques, des frais de dépassement et des appels commerciaux d'entreprise, parce que nous avons tous été cette personne à un moment donné.
Le même test s'applique à de plus petites décisions qui n'apparaissent jamais sur une page de tarifs : accepter une clé via un en-tête, un jeton bearer, l'authentification Basic ou un paramètre de requête sans surcoût, car imposer un seul schéma est une friction inutile pour quiconque dont le code existant fait autrement. Publier clairement les codes d'erreur et les limites de débit, car deviner la cause d'un échec non documenté fait perdre du temps à tout le monde. Aucune de ces décisions n'est spectaculaire. C'est l'accumulation du fait de ne pas faire la chose agaçante, encore et encore, dans chaque partie du produit.
Nous ne prétendons pas que cela rend chaque partie du produit terminée ou parfaite. Nous précisons quels endpoints nous considérons comme pleinement fonctionnels et lesquels, comme le géocodage direct, le géocodage inverse et la saisie semi-automatique, nous décrivons avec prudence plutôt que de les survendre, car survendre est une autre version du même échec : dire au client ce qu'il veut entendre plutôt que ce qui est réellement vrai. Construire le produit que nous voudrions acheter, c'est le construire honnêtement, y compris sur ses limites actuelles, et pas seulement construire les parties dont il est facile d'être fier. C'est l'exigence que nous nous sommes fixée, et c'est celle à l'aune de laquelle nous entendons continuer à être jugés.