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 codes postaux méritent plus de considération qu'ils n'en reçoivent
Demandez à une API de localisation la liste de ses fonctionnalités : le géocodage arrive généralement en tête, les recherches d'IP ensuite, et les codes postaux apparaissent quelque part vers le bas, décrits en une seule ligne, comme si résoudre un code postal en lieu, ou un lieu en code postal, était une recherche triviale avec une seule réponse évidente. Ce n'est pas le cas. Les systèmes postaux varient énormément d'un pays à l'autre : certains encodent directement la hiérarchie administrative dans les chiffres, certains sont alphanumériques, certains couvrent une zone de la taille d'un quartier et d'autres une zone de la taille d'un petit pays. Traiter cela comme un endpoint utilitaire mineur sous-estime toute la structure réelle qui se trouve derrière.
Nous avons conçu la recherche de codes postaux comme un endpoint à part entière aux côtés du géocodage, de l'IP, du fuseau horaire et de l'altitude, et non comme un ajout greffé à la réponse de géocodage. Elle bénéficie de la même tarification que tous les autres endpoints : couverte par le quota gratuit quotidien, puis au même prix de 0,0001 € par requête ou avec la même clé Unlimited à 50 € que tout le reste. Il n'existe pas de niveau distinct d'« endpoints utilitaires » qui traiterait la recherche postale comme une fonctionnalité secondaire méritant un prix moindre et, implicitement, une attention technique moindre.
Si les codes postaux sont sous-estimés, c'est en partie parce qu'ils paraissent simples vus d'un pays où le système se résume à un nombre fixe de chiffres correspondant proprement à une petite zone. Cette simplicité ne se généralise pas. Une recherche de code postal doit réellement gérer la diversité des formats et des significations administratives qui existent dans les différents pays, et pas seulement le modèle le plus familier à la personne qui a développé la fonctionnalité. Une API qui considère discrètement le format postal d'un pays comme la norme et traite tout le reste comme un cas limite n'offre pas vraiment une prise en charge mondiale des codes postaux. Elle offre le système d'un seul pays, avec une couverture limitée ajoutée par-dessus.
Cela a des conséquences pratiques faciles à négliger jusqu'à ce qu'elles posent problème. Les calculs de frais de livraison, la détermination des juridictions fiscales, les vérifications de zone de service et la tarification régionale dépendent tous d'une couche de codes postaux correcte, souvent plus directement que d'un géocodage complet au niveau de la rue. Un devis de livraison n'a généralement pas besoin d'une adresse précise au bâtiment près. Il a besoin d'une région postale correcte, résolue de façon cohérente. Traiter cela comme une fonctionnalité mineure par rapport au géocodage complet inverse la véritable dépendance pour de nombreuses applications réelles.
Nous ne prétendons pas que les données de codes postaux sont un problème résolu à l'échelle mondiale, car les systèmes postaux ne cessent d'évoluer et la qualité de la couverture varie réellement selon les pays et selon l'activité avec laquelle chaque autorité postale publie ses mises à jour. Ce que nous disons, c'est qu'elles méritent le même sérieux que n'importe quel autre endpoint : une vraie documentation, le même prix que tout le reste, et la même exigence de continuer à fonctionner correctement, au lieu d'être le recoin du produit que personne ne revisite une fois qu'il renvoie techniquement une réponse.