L'API Google Places (Legacy) est gelée : ce que les développeurs EU doivent faire avant le début du compte à rebours

Google a gelé l'API Places legacy en mars 2025. Elle fonctionne encore, mais ne recevra plus de nouvelles fonctionnalités, et la dépréciation approche. Pour les développeurs EU, la décision de migration est plus compliquée que ce que la documentation de Google suggère.

En mars 2025, Google a discrètement restructuré sa plateforme cartographique d'une manière qui a créé une vraie urgence pour les développeurs, même si le message était formulé avec douceur. L'API Places legacy, l'API Directions et l'API Distance Matrix ont toutes été reclassées comme « services Legacy ». Elles fonctionnent encore. Elles continueront à fonctionner jusqu'à ce que Google annonce une date de dépréciation. Mais elles ont été gelées.

Plus de nouvelles fonctionnalités. Pas d'améliorations architecturales. Les remises de volume plafonnées au niveau 100 000+, en dessous de ce dont les applications plus importantes ont besoin. Et quelque part dans l'avenir, une annonce de dépréciation avec 12 mois de préavis.

Pour la plupart des développeurs, la question n'est pas de savoir s'il faut migrer. C'est quand, et vers quoi.

Pour les développeurs EU en particulier, le calcul est différent. La décision de migration implique non seulement la compatibilité des API et la tarification, mais aussi la conformité RGPD, la résidence des données et le risque juridique lié à l'infrastructure américaine que la documentation même de Google n'aborde pas entièrement.

Ce guide couvre ce qui a changé, ce qu'implique la migration et les questions que les équipes EU devraient se poser avant de s'engager dans une direction.

Ce que Google a changé en mars 2025

La restructuration de mars 2025 comportait deux composantes distinctes que de nombreux développeurs ont confondues.

Restructuration des prix : Google a remplacé le crédit mensuel forfaitaire de 200 $/mois par des niveaux gratuits par SKU. Au lieu d'un crédit unique applicable à n'importe quelle combinaison d'API, chaque type d'API dispose désormais de son propre niveau gratuit :

• API Geocoding : 10 000 événements gratuits/mois, puis 2 à 7 $ pour 1 000 événements
• API Maps JavaScript : 10 000 événements gratuits/mois
• API Places (New) : niveau gratuit par type de requête
• API Routes : niveau gratuit par type d'itinéraire

Pour les développeurs qui utilisaient intensivement une seule API sous l'ancien crédit de 200 $, le nouveau modèle peut signifier payer davantage. Pour les développeurs répartis sur plusieurs types d'API, les niveaux gratuits par SKU peuvent effectivement réduire les coûts. La seule façon de le savoir est d'auditer votre utilisation actuelle en fonction de la nouvelle structure SKU.

Parallèlement au changement de tarification, Google a lancé des plans d'abonnement : Starter à 100 $/mois (50 000 appels combinés), Essentials à 275 $/mois (100 000 appels combinés) et Pro à 1 200 $/mois (250 000 appels combinés). Ces plans sont censés apporter de la prévisibilité à grande échelle, mais ajoutent une couche de complexité supplémentaire à la projection des coûts.

Désignations de dépréciation d'API : Séparément, Google a désigné trois API comme services Legacy :

• API Places (Legacy) : remplacée par l'API Places (New)
• API Directions : remplacée par l'API Routes
• API Distance Matrix : remplacée par l'API Routes avec computeRouteMatrix

La désignation Legacy signifie que ces API ne reçoivent pas de nouvelles fonctionnalités et ne sont pas éligibles aux nouveaux niveaux de remise de volume élargis. Elles sont en mode maintenance.

Ce que l'API Places (New) change réellement

L'API Places (New) n'est pas un remplacement plug-and-play. Elle a un format de requête différent, une structure de réponse différente et un modèle de sélection de champs différent.

Le changement le plus significatif est le masquage de champs. L'API legacy retourne une structure de réponse fixe. La nouvelle API vous oblige à spécifier les champs dont vous avez besoin via un en-tête de masque de champ. Cela réduit le transfert de données inutile et signifie que vous ne payez que pour les champs que vous demandez, mais cela signifie également que chaque appel API dans votre base de code doit être mis à jour avec des masques de champs explicites.

Principales différences rencontrées par les développeurs lors de la migration :

Format de requête : La nouvelle API utilise des requêtes POST avec un corps JSON plutôt que des requêtes GET avec des paramètres de requête. Si votre intégration construit des appels basés sur des URL, chaque appel doit être restructuré.

Structure de réponse : Les noms de champs ont changé. formatted_address devient formattedAddress (camelCase). place_id devient id. L'objet geometry est restructuré. Le code d'analyse des réponses doit être audité dans l'ensemble du projet.

Nouvelles fonctionnalités uniquement dans l'API Places (New) : Résumés IA générativa, nouveaux champs de données pour les stations de recharge électrique, les prix du carburant, les détails d'accessibilité et des suggestions d'autocomplétion améliorées. Si vous avez besoin de l'une de ces fonctionnalités, vous devez migrer.

Gestion des photos : Le format de référence des photos a changé. Les URL de photos générées par l'API legacy cesseront éventuellement de fonctionner, donc toutes les références de photos en cache doivent être régénérées.

Google fournit des guides de migration, mais l'expérience pratique montre que la migration est une tâche d'ingénierie significative, pas un simple changement de configuration. Les équipes prévoient généralement une à quatre semaines selon la complexité de l'intégration.

La migration vers l'API Routes (distincte mais liée)

L'API Directions et l'API Distance Matrix suivent un modèle similaire. Le remplacement est l'API Routes, qui utilise un format de requête/réponse différent et offre des fonctionnalités que les API legacy n'ont pas : routage tenant compte du trafic, modificateurs d'itinéraire, prise en charge des deux-roues et optimisation de l'efficacité du carburant.

L'API Routes a également une tarification différente. L'API Directions legacy facturait par élément (paire origine-destination). L'API Routes facture par requête d'itinéraire et par élément dans les requêtes matricielles. Pour les applications effectuant de gros volumes de requêtes matricielles, les coûts peuvent changer significativement.

Si vous migrez l'API Places, il vaut la peine de planifier la migration de l'API Routes en même temps plutôt que de réaliser deux migrations séparées. L'effort parallèle est plus efficace que des migrations séquentielles nécessitant chacune leurs propres cycles de test et de déploiement.

Les considérations spécifiques à l'UE

C'est là que la décision de migration devient plus nuancée pour les développeurs européens que ce que la documentation de Google suggère.

RGPD et transferts de données transfrontaliers

Google Maps Platform est une infrastructure américaine. Lorsque le navigateur d'un utilisateur fait une requête à l'API Places ou charge une carte, cette requête transite par les serveurs américains de Google. Dans le cadre du RGPD, il s'agit d'un transfert de données transfrontalier.

La base juridique actuelle pour ces transferts est le Cadre de Protection des Données UE-États-Unis, qui a remplacé l'accord Privacy Shield invalidé par l'arrêt Schrems II en 2020. Ce cadre a été contesté juridiquement et sa stabilité à long terme n'est pas garantie. Pour les entreprises dans des secteurs réglementés (santé, fintech, services juridiques, applications proches du gouvernement), la dépendance continue à l'infrastructure américaine est une conversation de conformité continue qui nécessite une surveillance.

L'utilisation des API Google Maps nécessite également un consentement aux cookies pour l'API JavaScript dans certaines implémentations, car les adresses IP des utilisateurs et les identifiants d'appareils sont envoyés à Google. Pour les applications qui souhaitent charger des cartes sans déclencher une bannière de consentement, l'infrastructure hébergée aux États-Unis crée un problème structurel.

Google a mis à jour ses conditions de service Google Maps Platform EEE en 2025 pour s'appliquer spécifiquement aux adresses de facturation EU. Les développeurs devraient examiner les conditions mises à jour par rapport à leurs exigences de DPA.

Simplification de la conformité comme déclencheur de migration

Pour de nombreuses équipes EU, les changements de mars 2025 ont fourni un déclencheur pratique pour réévaluer s'il fallait rester dans l'écosystème Google ou passer à une alternative hébergée dans l'UE.

L'argument pour la réévaluation est simple : si vous allez de toute façon investir du temps d'ingénierie dans une migration (API Places legacy vers API Places New), l'effort marginal supplémentaire pour migrer vers un autre fournisseur est souvent plus faible qu'il n'y paraît. Les changements de points de terminaison d'API, le travail de mappage de champs et les cycles de test sont largement les mêmes que vous migriez vers la nouvelle API Google ou vers une alternative tierce. La différence réside dans ce que vous obtenez à la fin.

Une API de cartographie hébergée dans l'UE élimine entièrement le problème de transfert transfrontalier RGPD. Toutes les requêtes restent dans l'UE. Pas de CCT à négocier, pas de dépendance au cadre DPF, pas de consentement aux cookies requis pour charger une carte. Pour les entreprises qui ont récemment terminé des audits RGPD ou qui en anticipent un, cette simplification a une réelle valeur organisationnelle.

Évaluer si migrer au sein de Google ou changer de fournisseur

Le cadre honnête pour cette décision comporte quatre parties.

1. Auditez votre utilisation actuelle des API

Avant de prendre toute décision, cartographiez chaque appel à l'API Places, à l'API Directions et à l'API Distance Matrix dans votre base de code. Comptez le volume par type de point de terminaison. Mappez cela à la fois au modèle de tarification de l'API Places (New) et aux points de terminaison équivalents chez les fournisseurs alternatifs candidats.

La comparaison des coûts n'a de sens qu'avec de vraies données d'utilisation. Les estimations approximatives basées sur le volume total de requêtes ne sont pas suffisantes, car les différentes API d'un même fournisseur ont des tarifications différentes.

2. Évaluez votre exposition RGPD

Demandez à votre équipe juridique ou de conformité dans quelle mesure la dépendance à l'infrastructure américaine représente un risque continu pour votre contexte spécifique. Pour un produit SaaS avec des clients enterprise EU qui ont des DPA en place, le niveau de risque est différent que pour une application grand public traitant des données personnelles sensibles.

Si la simplification de la conformité a de la valeur, attribuez-lui un coût. La charge juridique interne liée au maintien des CCT, à la surveillance de la stabilité du DPF et au traitement des questionnaires de conformité des clients représente un vrai travail avec un vrai coût.

3. Évaluez l'effort de migration pour chaque chemin

Migrer vers l'API Places (New) au sein de Google : estimez en fonction de la complexité de votre intégration. Changements de masquage de champs, restructuration des requêtes, mises à jour de l'analyse des réponses. Généralement une à quatre semaines d'effort d'ingénierie.

Migrer vers une alternative tierce : portée d'ingénierie similaire. Changements d'URL de points de terminaison, différences de paramètres, différences de format de réponse. Pour les équipes utilisant déjà MapLibre GL JS comme couche de rendu (le fork open-source de Mapbox GL JS), la couche de rendu reste la même. Seuls les appels de géocodage, de recherche et de routage changent.

4. Considérez ce que vous obtenez de l'autre côté

L'API Places (New) vous donne accès aux dernières fonctionnalités de Google : meilleure autocomplétion, résumés IA génératifs, données de lieux enrichies. La couverture de données de Google est inégalée au niveau mondial.

Les alternatives hébergées dans l'UE comme MapAtlas offrent la conformité RGPD par conception, la résidence des données dans l'UE et, dans certains cas, des outils de visibilité dans la recherche IA que les API de Google ne fournissent pas. Pour les applications dans l'immobilier, l'hôtellerie ou la logistique où la découvrabilité IA des pages de localisation est importante, la couche de visibilité IA est un différenciateur significatif.

Aucun chemin n'est universellement correct. La bonne réponse dépend de vos exigences de conformité, de votre sensibilité aux prix et des fonctionnalités les plus importantes pour votre application.

Que faire dès maintenant

Quel que soit le chemin de migration que vous choisissez, plusieurs actions ont du sens immédiatement :

Auditez et documentez votre surface API actuelle : Sachez exactement quels points de terminaison legacy vous utilisez, à quelle fréquence et quels champs de données vous utilisez. Ces informations sont nécessaires pour toute décision de migration.

Effectuez la comparaison des prix avec de vraies données : Utilisez vos données d'utilisation réelles pour comparer la tarification legacy, la tarification de l'API Places (New) et les fournisseurs alternatifs. Faites-le à votre volume actuel et à 2 fois votre volume actuel.

Vérifiez votre documentation RGPD : Examinez votre DPA actuel avec Google, vos CCT ou votre dépendance au DPF, et votre implémentation du consentement aux cookies. Comprenez votre position juridique actuelle avant de la modifier.

Ne migrez pas sous pression temporelle : L'API legacy fonctionne encore. Elle est gelée, pas cassée. Prenez la décision de migration avec des données claires et une marge d'ingénierie suffisante plutôt que de vous précipiter en raison d'une urgence perçue. L'annonce de dépréciation vous donnera 12 mois de préavis.

Fixez une date limite de décision : « Quand Google annoncera la dépréciation » n'est pas un plan. Fixez un point de décision interne sur le chemin de migration à prendre, idéalement dans le trimestre suivant.

Si vous souhaitez comparer à quoi ressemblent concrètement les API de cartographie hébergées dans l'UE en termes de surface API, de tarification et d'effort de migration, MapAtlas couvre le géocodage, l'autocomplétion d'adresses, le routage et les tuiles cartographiques sous un modèle de tarification unique avec résidence des données dans l'UE. La page de tarification affiche la structure des niveaux actuels, et le niveau gratuit (10 000 requêtes par mois pour la plupart des API, 25 000 pour le géocodage) vous permet de tester l'intégration avant de vous engager.

Questions fréquentes

Quand Google dépréciera-t-il l'API Places legacy ?

Google n'a pas fixé de date de dépréciation définitive au début 2026. L'API legacy a été gelée en mars 2025 et ne reçoit plus de nouvelles fonctionnalités. La politique de Google est de fournir au moins 12 mois de préavis avant la dépréciation. Traitez la migration comme urgente, mais pas comme une urgence immédiate.

L'API Places (New) est-elle plus chère que l'API Places legacy ?

Cela dépend de votre profil d'utilisation. Les nouveaux niveaux gratuits par SKU bénéficient à certains profils d'utilisation et en pénalisent d'autres. Mappez vos appels API actuels vers la nouvelle structure SKU avec vos données d'utilisation réelles avant de tirer des conclusions.

Dois-je également migrer depuis l'API Directions ?

Oui, si vous souhaitez de nouvelles fonctionnalités et de meilleures remises de volume. L'API Directions et l'API Distance Matrix ont toutes deux été désignées comme services Legacy en mars 2025. Le remplacement est l'API Routes, qui nécessite sa propre évaluation de migration distincte.

Quel est le risque RGPD de continuer à utiliser les API Google Maps en tant que développeur EU ?

Google Maps Platform utilise une infrastructure américaine, ce qui nécessite des mécanismes de transfert de données transfrontaliers dans le cadre du RGPD. La base actuelle est le Cadre de Protection des Données UE-États-Unis, qui a été contesté juridiquement. Pour les secteurs réglementés, c'est un risque de conformité continu qui nécessite une surveillance.

Combien de temps prend la migration vers un fournisseur alternatif ?

L'effort d'ingénierie est similaire à la migration au sein de Google : une à quatre semaines selon la complexité de l'intégration, principalement consacrées aux mises à jour des points de terminaison, aux différences de paramètres et aux tests de format de réponse. Les équipes utilisant MapLibre GL JS pour le rendu ont le chemin de migration le plus léger, la couche de rendu restant la même.

Conclusion

Les changements de mars 2025 ont mis un compte à rebours sur l'utilisation de l'API Places legacy sans en démarrer officiellement le décompte. L'API fonctionne encore. La date de dépréciation n'a pas été annoncée. Mais la direction est claire, et la migration sera moins douloureuse avec une planification adéquate que sous l'urgence.

Pour les développeurs EU, ce moment de migration est aussi un moment d'évaluation. L'effort d'ingénierie pour changer les points de terminaison d'API est largement le même que vous restiez chez Google ou que vous passiez à une alternative hébergée dans l'UE. La différence significative réside dans ce que vous portez en avant : l'ensemble de données mondial complet et les dernières fonctionnalités de Google, ou la conformité RGPD par conception, une tarification plus simple et la résidence des données dans l'UE.

C'est une décision qui mérite d'être prise délibérément, avec de vraies données d'utilisation et une vue claire de vos exigences de conformité, plutôt que de vous en tenir par défaut au chemin de moindre résistance immédiate.

Lectures complémentaires :

• Alternatives à l'API Google Maps pour les développeurs EU
• Guide du développeur EU sur les API de cartes conformes au RGPD
• Tarification de l'API Google Maps en 2026 : ce que vous payez réellement
• Passer de l'API Google Maps : ce que choisissent les développeurs EU
• API d'autocomplétion d'adresses : comment elle améliore la conversion au checkout