Comment nous avons divisé par 10 la facture Google API pour notre client Austinbright

Le Challenge du filtre de distance : quand la précision coûte cher

Si vous gérez un site d'annonces d'emploi avec un filtre basé sur le temps de trajet ("Moins de 45 minutes en voiture"), vous offrez une fonctionnalité cruciale. Mais derrière cette expérience utilisateur se cache un gouffre financier : l'API Google Distance Matrix.

Chaque fois qu'un utilisateur lance une recherche pour un rayon de 45 minutes, votre serveur interroge l'API pour calculer le temps de trajet réel (incluant les bouchons et les routes) entre le domicile de l'utilisateur et chacune des offres d'emploi de votre catalogue.

Le constat est simple : pour 800 offres x 100 recherches/jour = 80 000 requêtes payantes par jour. La facture s'envole.

‍

‍

Les fausses bonnes idées et pourquoi nous les avons rejetées

Pour réduire les coûts, deux options ont été envisagées, mais nous les avons écartées au profit d'une approche plus fine :

1. Le filtrage préalable qui ruine l'UX

L'approche consistant à imposer des filtres supplémentaires (Région, Langue) avant l'accès à la recherche géographique part d'une intention d'optimisation technique, mais elle ignore les lois fondamentales de l'expérience utilisateur (UX).

• La frustration utilisateur : En e-commerce ou en recrutement, chaque clic supplémentaire entre l'intention de l'utilisateur et le résultat réduit le taux de conversion. Forcer un utilisateur à choisir une région ou une langue est clairement contre productif.
  
  
• La rupture du modèle mental : Le candidat raisonne en termes de mobilité personnelle ("Je suis prêt à faire 30 min de route"). Lui demander sa région alors qu'il veut simplement indiquer son point de départ inverse la logique de recherche.
  

Le verdict est sans appel : On ne règle pas un problème de coût API en transférant l'effort sur l'utilisateur.

2. OpenStreetMap (OSM) : Le mirage de la gratuité

L'idée de passer sur OSM est souvent séduisante car les données cartographiques sont gratuites. Cependant, passer de l'API Google à une infrastructure OSM auto-hébergée pour du calcul de temps de trajet est un piège économique pour un catalogue de taille intermédiaire (~800 offres).

• L'absence de données de trafic réel : C'est le point critique. OSM est excellent pour la distance kilométrique, mais n'inclut pas nativement les flux de trafic en temps réel comme Google. Pour un candidat, un trajet de 20 km peut durer 15 min ou 1h selon les bouchons. Perdre cette précision, c'est perdre la valeur ajoutée du filtre.

Verdict : Rejeté. L'installation et la maintenance d'un serveur OSM dédié  représentent un coût caché en temps de développement et en infrastructure. Pour un site de ce volume, c'est une complexité inutile.

La stratégie hybride de l’entonnoir

Nous avons choisi d'implémenter une architecture intelligente qui combine le meilleur des deux mondes : la vitesse d'un calcul interne gratuit et la précision de Google.

Étape 1 : Le pré-filtrage SQL à l’aide de la formule d’Haversine

C'est là que réside l'économie massive. Pour chaque recherche d'utilisateur, nous exécutons un algorithme en deux temps :

1. Conversion Temps -> Distance : Nous interceptons le choix de l'utilisateur (ex: "45 min en voiture") et le traduisons en un rayon kilométrique estimé (ex: 56 km). Nous utilisons une vitesse moyenne par mode de transport et appliquons un buffer de sécurité (+25%) pour ne rater aucune offre accessible rapidement (autoroute).
   
   
2. Calcul Haversine : Nous injectons cette distance dans une formule mathématique (formule de Haversine) directement dans la requête SQL.

Résultat : Au lieu d'interroger Google sur ~800 offres, le serveur filtre instantanément la base de données et ne conserve, par exemple, que 30 offres géographiquement plausibles. Coût : 0 €.

Étape 2 : Le filtrage définitif via Google Distance Matrix

C'est l'étape de la précision.

• Une fois que nous avons la liste courte des 30 "candidats" (filtrés par Haversine), nous envoyons uniquement ces 30 requêtes à l'API Google Distance Matrix.
  
  
• Google nous fournit alors le temps de trajet réel et précis (avec la prise en compte du trafic).

Résultat : Nous n'affichons que les offres validées par Google (par exemple, 10 offres qui sont réellement accessibles en 45 minutes). Nous payons pour 30 requêtes au lieu de 800.

Conclusion

L'implémentation de cette logique a été réalisée grâce à un module custom. Cela nous a permis d'injecter la formule Haversine directement dans la requête SQL garantissant :

1. Performance : Le tri est fait par la base de données (SQL), qui est ultra-rapide.
2. Baisse des coûts : La facture d'API Google Maps est fortement réduite.

En adoptant cette stratégie, nous avons préservé une excellente expérience utilisateur et assuré la pérennité économique de la fonctionnalité "Temps de trajet" sur le long terme.