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 les environnements de test devraient être gratuits
Certaines API proposent un environnement sandbox fonctionnellement séparé de la production : des clés différentes, parfois des endpoints différents, occasionnellement sa propre structure tarifaire ou ses propres limites plus restrictives. L'intention est raisonnable : offrir aux développeurs un espace sûr pour tester sans toucher à l'utilisation ni à la facturation réelles. En pratique, un sandbox qui exige sa propre inscription, sa propre clé ou sa propre mise à niveau payante ajoute de la friction exactement au moment où un développeur essaie de décider si votre API vaut la peine de cette friction.
Nous n'exploitons pas de sandbox séparé. Les tests et la production utilisent la même franchise gratuite quotidienne : 2 500 requêtes par jour depuis n'importe quelle adresse sans clé, et 2 500 de plus par jour dès que vous ajoutez une clé, comptées par réseau. Il n'y a pas de mode de test distinct avec ses propres limites à apprendre, ni d'offre payante qui conditionne des tests sérieux à un achat. Tout ce sur quoi vous construisez pendant l'évaluation est exactement le même système que celui sur lequel vous déployez, avec exactement la même franchise gratuite, avant même d'avoir dépensé un euro.
C'est important, car un sandbox qui se comporte même légèrement différemment de la production teste le sandbox, pas votre intégration. Si un sandbox séparé utilise des données de réponse simplifiées ou fictives au lieu du vrai jeu de données, vous ne découvrez les particularités des données réelles qu'après la mise en production, ce qui annule une grande partie de ce que les tests sont censés détecter. Tester sur le vrai système, avec de vraies données, en utilisant la vraie franchise gratuite, signifie que ce que vous apprenez pendant l'évaluation est réellement vrai de ce que vous exécuterez en production.
Ne pas conditionner l'accès au sandbox à une étape payante distincte a un coût pour nous : une partie de ce trafic de test gratuit ne se convertira jamais en compte payant, le même compromis que pour toute offre gratuite généreuse. Nous pensons que ce coût en vaut la peine, car l'alternative impose exactement la mauvaise incitation à un développeur qui se demande s'il doit construire sur votre API. Un mode de test payant ou fortement restreint demande à quelqu'un de s'engager financièrement avant de savoir si le produit convient à son cas d'usage. Un parcours de test gratuit et pleinement fonctionnel permet de prendre cette décision sur le fond, après avoir réellement essayé.
Cela ne signifie pas que les tests n'ont aucune limite. Les mêmes 2 500 requêtes par jour qui couvrent une utilisation légère en production couvrent aussi les tests, et un test de charge à grande échelle sur cette franchise atteindra le même plafond qu'une petite intégration en production. C'est voulu. L'offre gratuite est assez généreuse pour une véritable évaluation, pas infinie, et en faire votre environnement de test permanent pour un produit à fort volume est autre chose que de l'utiliser pour confirmer qu'une intégration fonctionne avant de passer à l'utilisation payante.
Un sandbox devrait répondre honnêtement à une seule question : est-ce que cela fonctionne comme je l'attends, avec le vrai système. Faire payer cette réponse, ou y répondre avec autre chose que le vrai système, va à l'encontre du but dans les deux cas.