Une liste de quarante adresses d'agences triées par nom de ville n'est d'aucune utilité pour un client qui veut savoir laquelle est la plus proche de son bureau. Une banque régionale a affiché exactement ce type de liste sur son site pendant des années, et l'équipe d'assistance recevait un flux régulier d'appels qui revenaient, en pratique, à lui demander de faire ce tri à la main au téléphone.
Pour y remédier, il fallait deux données de localisation dont la banque ne disposait pas encore sous une forme exploitable : des coordonnées pour chaque agence et un moyen de déterminer le point de départ du client. Les adresses des agences ont été géocodées une seule fois, en un seul lot envoyé à /v1/forward, puisqu'une requête groupée compte chaque adresse comme un élément facturé. Chaque agence a ainsi obtenu une latitude et une longitude fixes sur lesquelles s'appuyer, ce que l'ancienne liste, construite uniquement à partir d'adresses textuelles, ne pouvait jamais permettre.
Pour la partie client du calcul, la banque proposait deux possibilités. Un client qui autorisait la page à détecter sa position approximative l'obtenait grâce à /v1/ip, qui traduit l'adresse IP du visiteur en coordonnées ainsi qu'en ville et en région, fournissant un point de départ raisonnable sans rien demander. Un client qui préférait saisir une adresse, ce qui est courant quand on prévoit de se rendre dans une agence près de son lieu de travail plutôt que de sa position actuelle, voyait cette adresse géocodée par le même appel /v1/forward que celui utilisé pour la liste des agences, puis classée par rapport à celle-ci de la même façon.
Une fois que les deux côtés disposaient de coordonnées, le classement relevait d'un simple calcul de distance que le site de la banque effectuait lui-même, sans aucun service supplémentaire. Le résultat visible était un localisateur d'agences qui affichait d'abord les cinq agences les plus proches, chacune avec une distance claire, au lieu d'une liste de quarante adresses à faire défiler, regroupées par ville.
S'agissant d'une banque, l'équipe a veillé au degré d'assurance avec lequel l'outil s'exprimait. La localisation basée sur l'IP est une approximation, utile comme point de départ mais pas exacte, en particulier pour un client sur un réseau mobile ou un VPN d'entreprise, et le localisateur de la banque présentait toujours la position détectée comme une première estimation, facile à ajuster, plutôt que comme une certitude. Cela comptait davantage ici que pour un simple localisateur de magasins, car un client orienté vers la mauvaise agence pour un rendez-vous de certification de documents subit un désagrément plus important qu'un client orienté vers le mauvais café.
Le trafic de l'outil était modeste et prévisible, une ou deux recherches par session de visiteur, largement dans le quota quotidien gratuit inclus avec la clé de la banque, même lors d'une campagne marketing qui a généré un trafic supplémentaire sur le localisateur d'agences. Le projet a aussi fourni à la banque des coordonnées d'agences propres et réutilisables, qu'elle a ensuite utilisées pour d'autres besoins, comme tracer de simples cartes de rayon pour l'annonce de l'ouverture d'une nouvelle agence, sans aucun travail de géocodage supplémentaire.
Un localisateur d'agences ou de magasins est l'un des usages les plus courants du géocodage, précisément parce que le bénéfice est très visible : un localisateur classé par distance qui fonctionne se remarque en quelques secondes d'utilisation, à côté d'un outil qui manifestement ne fonctionne pas. La documentation des endpoints concernés se trouve sur /docs/forward-geocoding/ et /docs/ipv4-lookup/.