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.
Le problème des données exactes le jour du lancement seulement
C'est le jour de son lancement qu'un jeu de données inspire le plus de fierté. Il a été vérifié, nettoyé et validé à partir des sources disponibles à ce moment-là, et l'annonce peut honnêtement revendiquer une bonne couverture et une bonne précision, car à cet instant précis, il mérite cette affirmation. Le problème, c'est que presque rien en géographie ne reste figé longtemps. Les limites administratives évoluent. Les services postaux redécoupent ou réattribuent des codes. Les gouvernements modifient les règles de l'heure d'été, parfois avec très peu de préavis. Un jeu de données exact le jour du lancement et qui n'a pas été activement maintenu depuis n'est plus le même jeu de données, même s'il est peut-être encore présenté avec la même assurance.
La base de données des fuseaux horaires IANA est un bon exemple de la manière dont cela peut être bien géré : elle existe précisément parce que les règles de fuseau horaire changent sans cesse, et elle est mise à jour au fil de ces changements par des personnes dont le métier est de suivre exactement ce type d'évolution. Une API de géocodage ou de localisation qui s'appuie sur une source de ce type et continue d'en récupérer les mises à jour fait quelque chose de sensiblement différent d'un fournisseur qui a constitué un instantané unique il y a des années et le sert depuis, à peine corrigé.
Nous pensons que cette distinction, maintenance continue contre construction ponctuelle, mérite plus d'attention qu'elle n'en reçoit habituellement dans la façon dont les produits de données de localisation sont commercialisés. Une annonce de lancement peut revendiquer une large couverture de pays, et ce sera vrai. Ce qu'elle ne peut pas promettre à elle seule, c'est que la couverture reste exacte deux ans plus tard, après des changements de frontières, des réorganisations postales et des modifications des règles de fuseau horaire survenus discrètement entre-temps, sans qu'un client ait la moindre raison de savoir qu'il faut vérifier.
C'est en partie pourquoi nous considérons les données de fuseau horaire, d'altitude et d'IP comme les parties de notre produit que nous décrivons le plus concrètement, car ce sont des domaines où les données de référence sous-jacentes, le type de source que représente la base IANA pour les fuseaux horaires, sont maintenues en continu par conception, et pas seulement selon le calendrier de mise à jour interne d'un fournisseur. C'est aussi pourquoi nous prenons soin de ne pas présenter le géocodage direct, le géocodage inverse et la saisie semi-automatique comme entièrement terminés avec une précision vérifiée : les données d'adresse en particulier varient énormément d'une région à l'autre dans la qualité de leur maintenance, et une affirmation qui paraît assurée à leur sujet mérite plus d'examen que l'affirmation elle-même n'en suscite habituellement.
L'âge d'un jeu de données n'est pas un défaut en soi. Un jeu de données bien entretenu datant de cinq ans et tenu à jour est plus fiable qu'un jeu tout neuf qui ne sera pas réexaminé avant la prochaine refonte. Ce qui compte, c'est de savoir si un fournisseur traite la maintenance des données comme une obligation continue ou comme un projet ponctuel achevé le jour où la page marketing a été mise en ligne. La façon honnête d'en juger n'est pas l'annonce de lancement. C'est ce que fait un fournisseur, discrètement, dans les années qui suivent.