Optimiser Google Maps API : comment j'ai divisé la facture par 5

Le problème : une facture qui explose à chaque pic de trafic

VoglioMap est une carte interactive qui localise les revendeurs Voglio Bene dans le monde. À chaque visite, le navigateur charge la carte, géolocalise l'utilisateur, géocode son adresse, calcule des trajets, affiche des markers. Multipliez ça par quelques centaines de visiteurs par mois, et la facture Google Maps grimpe vite.

Au début, je tournais autour de 250€/mois. Pas catastrophique, mais inutile : la majorité de ces appels étaient redondants. Avec quelques optimisations ciblées, je suis passé sous les 50€/mois - soit -80% - sans perdre de fonctionnalité.

Voici les 4 techniques qui ont fait la différence.

1. Cacher le géocodage en base de données

Le géocodage (transformer une adresse en coordonnées GPS) est l'appel le plus cher de l'API Maps. Et c'est aussi celui qui revient le plus souvent : à chaque fois qu'un nouveau revendeur est ajouté, à chaque visite si tu re-géocodes les adresses.

Mais une adresse ne change pas tous les jours.

J'ai ajouté une table geocode_cache dans MySQL :

CREATE TABLE geocode_cache (
    address_hash VARCHAR(64) PRIMARY KEY,
    address TEXT,
    lat DECIMAL(10, 7),
    lng DECIMAL(10, 7),
    geocoded_at DATETIME
);

Avant chaque appel à l'API Geocoding, je calcule le hash SHA-256 de l'adresse normalisée et je regarde si elle existe en cache. Si oui, je retourne les coordonnées stockées. Si non, j'appelle Google, je stocke le résultat, et je le réutilise pour toutes les requêtes futures.

Résultat : 95% des appels Geocoding éliminés. La facture sur cette ligne est passée de ~80€/mois à ~5€/mois.

2. Rate limiting sur les endpoints publics

Sans rate limiting, n'importe qui peut spammer ton frontend (un script qui recharge la page, un bot mal intentionné) et faire exploser la facture en quelques heures. C'est arrivé une fois à mon site - et la mauvaise surprise s'est vue le mois suivant.

J'ai ajouté un middleware côté PHP :

function checkRateLimit($ip) {
    $key = "rate:$ip";
    $count = apcu_fetch($key) ?: 0;
    if ($count >= 60) return false; // 60 requêtes / heure max
    apcu_store($key, $count + 1, 3600);
    return true;
}

60 requêtes par IP par heure, c'est largement assez pour un usage humain et ça bloque les abus. J'ai aussi ajouté un check côté API pour les endpoints sensibles (recherche, navigation), avec un seuil plus bas (10/h pour la navigation).

Résultat : zéro pic anormal depuis. La facture est devenue prévisible.

3. Lazy load des markers et clustering

Afficher tous les markers d'un coup quand tu en as quelques centaines, ça surcharge le navigateur et déclenche plus d'appels à l'API. La solution : ne charger que les markers visibles dans le viewport.

J'utilise l'événement bounds_changed de Google Maps pour récupérer les coordonnées visibles, puis je fais un fetch des markers dans cette zone. Côté serveur, c'est un simple WHERE lat BETWEEN x AND y AND lng BETWEEN x AND y - rapide avec des index spatiaux.

J'ai aussi activé le MarkerClusterer : au lieu d'afficher 200 markers individuels quand on zoome out, ils sont regroupés en clusters numérotés. Beaucoup plus lisible, et beaucoup moins de DOM à gérer.

Résultat : moins d'appels à places.nearbySearch() et un site qui reste fluide même avec beaucoup de revendeurs.

4. Static Maps pour les vues non-interactives

Toutes les pages n'ont pas besoin d'une carte interactive. Sur les fiches revendeur individuelles, par exemple, l'utilisateur veut juste voir l'emplacement - il ne va pas zoomer ni explorer.

Pour ces cas-là, j'ai remplacé l'embed JavaScript par l'API Static Maps qui retourne une image PNG. Le coût est ~10 fois moins cher par appel, et c'est aussi plus rapide à charger (une simple image vs un script JS qui initialise la carte).

<img src="https://maps.googleapis.com/maps/api/staticmap?
    center=43.6108,3.8767
    &zoom=14
    &size=400x300
    &markers=color:red%7C43.6108,3.8767
    &key=YOUR_API_KEY"
/>

Bonus : les images sont mises en cache par le navigateur, donc un retour sur la même fiche = zéro nouvel appel.

Résultat : ~30% des appels JavaScript convertis en Static Maps, à ~10x moins cher.

Le bilan chiffré

Et l'expérience utilisateur ? Aucune dégradation visible. Au contraire, le site charge plus vite (Static Maps + lazy load des markers) et est protégé contre les abus.

Ce que j'en retiens

L'API Google Maps n'est pas chère en absolu - elle est chère par défaut, parce qu'elle ne fait aucune optimisation pour toi. Tu paies chaque appel, qu'il soit utile ou redondant.

Cacher, rate-limiter, lazy-loader : c'est de la base, mais c'est rarement fait sur les implémentations standard. Si tu pars d'une carte non-optimisée, divise par 3 ou 5 ta facture est probablement à portée de quelques heures de dev.

Et si ton trafic explose un jour : tes optimisations te protègent du choc tarifaire. C'est aussi ça, le ROI.