Un bénévole prêt à aider mais pas à conduire quarante minutes à l'aller et autant au retour est un bénévole qui cesse discrètement de répondre aux demandes. Une association locale qui coordonnait plusieurs centaines de bénévoles dans une agglomération a constaté que son ancien processus de mise en relation, où un coordinateur se rappelait de mémoire qui habitait à peu près près d'un besoin donné et contactait chacun individuellement, était à la fois lent et de moins en moins fiable à mesure que la liste des bénévoles dépassait ce qu'une seule personne pouvait garder en tête.
Les deux côtés du problème de mise en relation, les adresses personnelles des bénévoles et les adresses des besoins en cours, qu'il s'agisse d'une banque alimentaire ayant besoin d'une aide régulière, d'une personne âgée ayant besoin d'une assistance ponctuelle ou d'un événement local ayant besoin de bénévoles pour l'installation, existaient sous forme d'adresses textuelles recueillies via de simples formulaires d'inscription et de demande. Pour les transformer en éléments pouvant être rapprochés selon leur proximité réelle, l'association a commencé par géocoder les deux listes via /v1/forward, par lot pour la liste existante de bénévoles et de besoins, puis entrée par entrée à mesure qu'arrivaient de nouvelles inscriptions et demandes.
Avec des coordonnées des deux côtés, la mise en relation est devenue un calcul de distance que la simple base de données de l'association pouvait effectuer directement : pour tout nouveau besoin, classer les bénévoles inscrits selon la distance réelle depuis leur domicile, puis les contacter en commençant par les plus proches au lieu de compter sur ceux dont un coordinateur se souvenait qu'ils habitaient dans le bon quartier. Cela a fait apparaître des bénévoles restés inutilisés dans le système pour des raisons sans rapport avec leur motivation, simplement parce qu'aucun coordinateur ne savait personnellement qu'ils habitaient près d'un besoin récurrent donné.
L'association a gardé un coordinateur humain dans la boucle pour la prise de contact et la décision de mise en relation, car la distance était un facteur important mais pas le seul : les compétences particulières d'un bénévole, ses disponibilités ou sa relation existante avec un besoin donné comptaient parfois davantage que le fait d'être le plus proche. Le rôle de l'outil était de fournir une liste classée par distance qu'un coordinateur pouvait parcourir rapidement, et non d'automatiser entièrement une affectation qu'un coordinateur préférait examiner d'abord.
Les taux de réponse des bénévoles se sont nettement améliorés dès que les prises de contact ont systématiquement ciblé en priorité les personnes réellement proches, un résultat qui paraissait logique une fois que l'organisation l'a clairement vu dans ses propres données : une demande qu'il était réellement pratique pour un bénévole de satisfaire avait tout simplement plus de chances d'obtenir un oui qu'une demande plus éloignée vers laquelle un coordinateur s'était tourné par habitude plutôt que par proximité.
Comme il s'agissait d'une association soumise à de réelles contraintes budgétaires, le coût comptait tout particulièrement ici. L'usage du projet, un modeste traitement de géocodage par lot pour la liste initiale plus un faible flux continu pour les nouvelles inscriptions et demandes, tenait confortablement dans le quota quotidien gratuit sans jamais nécessiter de crédit prépayé ni de clé Unlimited. Toute la fonctionnalité de mise en relation géographique n'a donc rien coûté à une organisation pour laquelle chaque euro d'un budget limité comptait.
Si une organisation locale envisage quelque chose de similaire, le point de départ est plus modeste qu'il n'y paraît : géocodez les adresses dont vous disposez déjà et regardez à quoi ressemble concrètement une mise en relation fondée sur la distance avec vos vraies listes de bénévoles et de besoins, avant de construire quoi que ce soit de plus élaboré par-dessus. La documentation de l'endpoint se trouve sur /docs/forward-geocoding/.