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 données d'altitude sont traitées comme secondaires
Dans ce secteur, les données d'altitude souffrent d'un problème d'image plus que d'un problème technique. On les présente comme un plus agréable, une fioriture ajoutée à une vue cartographique ou à un outil de planification de vol, plutôt que comme des données dont dépendent réellement des applications concrètes : évaluation des risques d'inondation, planification du drainage, travaux agricoles, calculs de marge de franchissement en aviation, évaluation de chantiers de construction. Aucun de ces usages n'est marginal. Tous exigent que l'altitude du sol soit traitée avec le même sérieux qu'une coordonnée ou une adresse, et non comme un extra décoratif greffé sur un produit cartographique.
Nous avons construit l'altitude comme un véritable endpoint, avec sa propre place dans le produit, et non comme un obscur champ facultatif enfoui dans une réponse de géocodage dont la plupart des intégrations ne remarquent jamais l'existence. Elle est facturée comme tout le reste : couverte par la franchise gratuite quotidienne et facturée au même tarif de 0,0001 € par requête au-delà, ou incluse dans la même clé Unlimited à 50 €, exactement comme les recherches de géocodage, d'IP et de fuseau horaire. Aucun prix distinct et plus élevé n'y est attaché, qui indiquerait qu'elle est considérée comme une fonctionnalité spécialisée plutôt que standard.
Si l'altitude est sous-estimée, c'est en partie parce qu'elle est réellement moins visible dans un produit grand public typique qu'une adresse ou un repère sur une carte. Personne ne remarque directement les données d'altitude comme on remarque une adresse erronée sur un formulaire de livraison. Cette invisibilité pour l'utilisateur final ne rend pas les données sous-jacentes moins importantes pour les systèmes qui en dépendent. Un calcul de drainage faussé parce que la valeur d'altitude qui l'alimentait était erronée ne se signale pas comme le fait une mauvaise adresse. Il se manifeste plus tard, sous forme de conséquence bien réelle, dans une décision qui supposait que la hauteur du sol était correcte.
Nous considérons l'altitude comme l'une des parties de notre produit qui fonctionnent pleinement et que l'on peut décrire concrètement en toute sécurité, aux côtés des données d'IP et de fuseau horaire, précisément parce que nous pensons qu'elle mérite la même confiance et le même investissement que n'importe quel autre endpoint central, et non une réserve ou une note de bas de page. Elle est aussi disponible en option, ajoutée à une réponse standard pour les appelants qui veulent l'altitude du sol en plus d'une recherche de localisation qu'ils effectuent déjà, sans exiger un produit spécialisé distinct ou un contrat distinct simplement pour y accéder.
Plus largement, l'altitude est exactement le type de données qui souffre lorsqu'un produit prend la visibilité pour l'utilisateur final comme indicateur de l'importance réelle. Certains des usages les plus lourds de conséquences des données de localisation, en agriculture, en ingénierie et en évaluation des risques, reposent entièrement sur des données que l'utilisateur final du produit obtenu ne verra jamais directement. Bien construire ces données, et les facturer comme une fonctionnalité standard plutôt que comme une option spécialisée, c'est parier que les parties invisibles d'un système méritent le même soin que les parties visibles, car les décisions qui reposent sur elles sont tout aussi réelles.