Liste des points à vérifier avant le lancement

S'assurer que votre équipe a accès aux ressources nécessaires

Conserver votre lettre de bienvenue Google Maps APIs Premium Plan en lieu sûr

Pourquoi c'est important : Votre lettre de bienvenue est votre kit de démarrage de Google Maps APIs Premium Plan et peut-être aussi votre kit de premiers secours. Elle contient des informations importantes comme votre ID du projet Google API Console, votre ID client et votre clé cryptographique, qui sont nécessaires pour commencer à utiliser le Premium Plan. Elle contient également toutes les informations utiles pour contacter l'équipe de support Premium Plan si jamais vous rencontrez des problèmes techniques avec certaines Google Maps API.

Utiliser le Google Cloud Support Portal

Pourquoi c'est important : Le portail de support vous donne accès à des informations comme les rapports d'utilisation, les flux d'actualité et des ressources utiles pour les développeurs. Plus important encore, le portail de support vous permet de soumettre des demandes d'assistance auprès de l'équipe de support Premium Plan en cas de problèmes techniques au cours du développement ou du lancement. Vous pouvez accéder au portail de support à l'adresse URL suivante :

https://google.secure.force.com/

Avant le lancement, veuillez prendre le temps d'activer l'accès au portail de support pour tous les développeurs responsables de la maintenance de votre application. Si vous rencontrez des problèmes techniques, l'accès au portail de support aura le double avantage de permettre aux membres de votre équipe de contacter le support et à l'équipe de support de contacter les personnes concernées de votre organisation. Par exemple, l'équipe de support peut avoir besoin de contacter votre organisation si elle détecte un trafic ou un comportement anormal qui pourrait risquer d'interrompre votre application. L'assurance de pouvoir contacter les développeurs concernés peut permettre de prévenir les pannes au lieu de les subir. Si vous n'avez pas accès au portail de support, faites une demande d'accès ici :

Demander un compte Google Cloud Support Portal

S'abonner à des flux de notification pertinents

Pourquoi c'est important : Pour vous tenir au courant des développements et des changements au sein des Maps API, nous vous recommandons de vous abonner aux flux de notification qui vous concernent, comme décrit dans la FAQ.

Vous pouvez également vous abonner au flux RSS suivant pour Google Maps Premier API Announcements: Outages, Updates, Service Notifications :

http://google.force.com/services/xml/MapsRSS

Garder le numéro de l'assistance téléphonique à portée de main

1-877-355-5787 pour les clients aux États-Unis, +1 404-978-9282 en dehors des États-Unis

Pourquoi c'est important : L'assistance téléphonique vous permet d'appeler Google Cloud Support Portal. Ajoutez cette page aux favoris pour disposer du numéro de téléphone du support le plus à jour. Veuillez noter que même si vous pouvez utiliser l'assistance téléphonique pour signaler des problèmes techniques à notre équipe, cette ligne est uniquement réservée aux cas de panne de production ou de service inutilisable. Nos niveaux de priorité sont définis dans ce document :

https://support.google.com/work/answer/184028

Optimiser votre application

Configurer un pare-feu pour autoriser l'accès aux services Google Maps APIs

Pourquoi c'est important : les services Google Maps APIs utilisent une grande variété de domaines, dont certains qui n'appartiennent pas au domaine *google.com. Si vous vous trouvez derrière un pare-feu restrictif, il est important d'autoriser l'accès aux domaines utilisés par chaque service Maps API. En effet, si votre pare-feu n'autorise pas l'accès à ces domaines, les requêtes d'API échoueront, ce qui peut interrompre vos applications. La liste complète des domaines utilisés par les Maps API est disponible sur le portail de support :

  1. Connectez-vous au Google Cloud Support Portal.
    Le portail de support est disponible uniquement aux clients disposant de Google Maps APIs Premium Plan ou d'une licence antérieure de Google Maps APIs for Work ou Google Maps for Business.
  2. Naviguez jusqu'à l'onglet Resources.
  3. Sélectionnez la liste des domaines utilisés par la famille Google Maps APIs. (Voici le lien direct.)
  4. Autorisez vos applications à accéder aux domaines répertoriés.

Nous vous déconseillons de gérer les restrictions du pare-feu par adresse IP, car les adresses IP associées à ces domaines ne sont pas statiques.

Remarque : les services Google Maps APIs utilisent les ports 80 (http) et 443 (https) pour le trafic entrant et sortant. Ces services nécessitent également des requêtes GET, POST, PUT, DELETE et HEAD. Configurez votre pare-feu de façon à autoriser le trafic sur ces ports et à autoriser les requêtes, en fonction de l'API et du cas d'utilisation.

Charger les API sur le nom d'hôte SSL approprié

Pourquoi c'est important : Les applications qui chargent les Maps API via SSL doivent le faire depuis https://maps.googleapis.com et non depuis l'ancien nom d'hôte, https://maps-api-ssl.google.com.

Autoriser les domaines SSL à utiliser avec Google Maps JavaScript API

Pourquoi c'est important : Lorsque vous utilisez Google Maps JavaScript API avec un domaine SSL, il est essentiel d'avoir explicitement autorisé vos domaines HTTPS pour vous assurer que vos requêtes ne seront pas rejetées. Veuillez noter qu'autoriser http://yourdomain.com n'active pas automatiquement son équivalent SSL, https://yourdomain.com. Vous pouvez vérifier votre liste de domaines autorisés sur le Google Cloud Support Portal en cliquant sur le lien Maps: Manage Client ID dans le menu de navigation situé à gauche. Pour résoudre des problèmes liés à l'utilisation d'API côté client avec un domaine SSL, nous vous incitons à vérifier au préalable si certains éléments de votre page sont chargés via HTTP. Voir aussi le guide sur la résolution des erreurs d'autorisation.

Sélectionner la version d'API appropriée

Pourquoi c'est important : Avant de développer votre application, il est important de connaître les versions des API qui sont obsolètes. En choisissant d'utiliser les versions non obsolètes des API pour le développement, vous économiserez du temps et de l'argent à terme lorsque les versions obsolètes ne seront plus disponibles.

Plus particulièrement, il est important de comprendre le schéma de version utilisé par Google Maps JavaScript API pour éviter d'utiliser accidentellement une version inadaptée de l'API dans votre environnement.

Par exemple, il peut être possible d'utiliser la version expérimentale de l'API dans votre environnement de développement ou de test, mais nous vous déconseillons fortement d'utiliser cette version dans un environnement de production. Notre contrat de niveau de service ne s'applique qu'aux versions stables de l'API, vous ne devez donc utiliser que des versions stables dans votre environnement de production.

Voir le guide sur les versions de Google Maps JavaScript API.

Choisir une conception côté client ou côté serveur

Pourquoi c'est important : Le choix d'une approche côté client ou côté serveur est une décision d'architecture qui est absolument essentielle pour la stabilité et l'évolutivité de votre application. De manière générale, une approche côté serveur doit être utilisée pour le prétraitement et le post-traitement des enregistrements hors connexion (en dehors de votre application). À l'inverse, une approche côté client doit être utilisée pour les parties de vos applications qui interagissent avec vos utilisateurs (par exemple, traitement en temps réel des requêtes soumises par l'utilisateur).

Le déploiement d'une approche côté serveur là où une approche côté client devrait être utilisée est la cause principale de dépassement des quotas et, par conséquent, de l'interruption des applications. Nous vous recommandons vivement de consulter le document Stratégies de géocodage avant de concevoir ou de lancer des applications reposant sur des appels côté serveur.

Optimiser l'utilisation de votre quota

Pourquoi c'est important : Comprendre comment votre application consomme le quota, appelé crédits Maps API, vous aidera à réduire le montant de votre facture. Par exemple, si vous utilisez Google Maps JavaScript API, votre application consomme des crédits Maps API pour chaque chargement de carte. Voir le guide sur les taux et limites d'utilisation du Premium Plan.

Gérer l'utilisation du quota des services Web

Pourquoi c'est important : Par défaut, le quota des services Web partagés est fixé à 100 000 requêtes gratuites par jour. Pour une décomposition plus détaillée des quotas par API, voir le guide sur les limites d'utilisation. Pour connaître le quota associé à votre projet, complétez une demande d'assistance.

Avant de lancer votre service, il est important de comprendre les différentes erreurs liées aux quotas (par exemple OVER_QUERY_LIMIT, User Rate Limit Exceeded), et de paramétrer la logique appropriée dans votre application pour pouvoir répondre à de telles erreurs en cas de dépassement de votre quota. Commencez par lire la FAQ sur les limites d'utilisation. Pour plus d'informations sur les codes d'état renvoyés par chaque API, consultez le guide du développeur de cette API. Par exemple, voir le guide sur les codes d'état Google Maps Directions API. La compréhension et la mise en œuvre de ces concepts vous permettra de réduire considérablement les risques de dépassement des quotas autorisés, de blocage par Google et/ou d'interruption.

Effectuer des tests de charge de votre application

Pourquoi c'est important : Utilisez les tests de charge de votre application pour vous assurer qu'elle peut traiter de gros volumes de requêtes sans dépasser les quotas définis pour les Maps API.

Effectuer des tests de charge par rapport aux services Google actifs pourra entraîner le dépassement du quota autorisé de votre application et son blocage par Google. Google Maps APIs peut traiter de très gros volumes. En 2012, Sur la piste du Père Noël a traité 1 600 000 requêtes par seconde. Il est donc inutile d'effecteur des tests de charge par rapport aux services Google. En revanche, les tests de charge de votre application doivent garantir que celle-ci est capable de gérer de grands volumes de requêtes sans dépasser les quotas définis pour les Maps API. Par exemple, si votre quota pour Google Maps Geocoding API est de 20 QPS (requêtes par seconde), le test de charge de votre application doit garantir que l'application peut traiter 600 QPS sans envoyer plus de 20 QPS à Google Maps Geocoding API.

Pour y parvenir, les tests de charge doivent être effectués par rapport à une API factice (mock) — un service capable d'absorber de grandes quantités de requêtes et d'y répondre de manière appropriée, sans faire intervenir les Google Maps APIs. Vous pouvez ainsi tester la charge de votre application sans risquer d'être bloqué par les Google Maps APIs.

Consultez cet exemple d'API factice, implémentée en tant que petite application Google App Engine. Vous pouvez transférer cet exemple dans votre application App Engine (après en avoir enregistré une à l'adresse appengine.google.com) et configurer votre application pour qu'elle envoie des requêtes à cette adresse plutôt qu'à maps.googleapis.com.

Les quotas App Engine (gratuits) par défaut sont généralement suffisants pour effectuer le test de charge de votre application, bien au-delà des quotas réservés aux services Web Maps API. Assurez-vous que votre application définit l'en-tête User-Agent approprié pour activer la compression des réponses. Étape essentielle, elle garantit une utilisation efficace de la bande passante, ce qui est particulièrement important pour une application App Engine traitant un gros volume de réponses en texte brut (JSON/XML). Dans les rares cas où cela s'avérerait nécessaire, vous pouvez augmenter le quota de votre application App Engine en activant la facturation.

Migrer votre application d'une licence standard à une licence premium

Inclure votre ID client ou votre clé d'API dans vos requêtes d'API

Pourquoi c'est important : L'une des choses les plus importantes à faire pour votre application est d'inclure votre ID client (gme-yourclientid) ou votre clé d'API (qui ressemble à ça : AIzaSyBdVl-cTICSwYKrZ95SuvNw7dbMuDt1KG0) dans vos requêtes d'API. L'ID client ou la clé d'API permet d'identifier vos requêtes comme étant des requêtes Google Maps APIs Premium Plan.

Vous devez inclure votre ID client ou votre clé d'API dans vos applications pour pouvoir profiter de toutes les fonctionnalités propres à Premium Plan. Il est également nécessaire d'inclure votre ID client ou votre clé d'API pour pouvoir recevoir une assistance technique et s'assurer que votre application est couverte par notre contrat de niveau de service

Pour la plupart des API, vous pouvez choisir entre utiliser un ID client ou une clé d'API. Votre ID client est inclus dans la lettre de bienvenue qui a été envoyée aux contacts principaux de votre organisation. Vous pouvez générer vos propres clés d'API dans la Google API Console.

Pour plus de détails, voir le guide sur l'authentification et l'autorisation.

Inclure la clé d'API ou l'ID client dans les requêtes d'API, mais pas les deux

Pourquoi c'est important : Afin de pouvoir charger correctement Google Maps JavaScript API, ou envoyer une requête à d'autres Google Maps API, vous devez inclure au choix votre ID client ou votre clé d'API, mais pas les deux. Si vous choisissez d'utiliser un ID client, vous devez supprimer tous les paramètres key. Si votre requête comporte à la fois un ID client et une clé, elle échouera.

Suivez le guide sur l'authentification et l'autorisation pour plus d'informations sur le formatage approprié des requêtes Premium Plan par API.

Lors de l'utilisation d'un ID client, autoriser les domaines à utiliser avec Google Maps JavaScript API

Pourquoi c'est important : Afin d'éviter que des sites non autorisés utilisent votre ID client, Google Maps JavaScript API exige que vous autorisiez tous les domaines auprès de notre équipe de support pour tous les sites qui utiliseront votre ID client. (L'enregistrement des URL n'est pas obligatoire si vous utilisez une clé d'API au lieu d'un ID client.) Si le site qui tente d'utiliser votre ID client ne correspond à aucune URL autorisée, votre site ne pourra pas utiliser l'API avec cet ID client. Vous pouvez autoriser des domaines à tout moment. Aussi, veillez à autoriser ceux de tous vos sites avant le lancement.

Vous pouvez vérifier votre liste de domaines autorisés sur le Google Cloud Support Portal en cliquant sur le lien Maps: Manage Client ID dans le menu de navigation situé à gauche.

Pour les problèmes d'autorisation, nous vous recommandons de consulter le guide sur la résolution des erreurs d'autorisation avant de renseigner une demande.

Lorsque vous utilisez un ID client, signez les requêtes de service Web à l'aide d'une signature générée avec votre clé cryptographique privée.

Pourquoi c'est important : Votre clé cryptographique privée est utilisée pour générer des signatures numériques qui signalent à Google que vos requêtes proviennent d'une source fiable. Nos API de services Web exigent que vous ajoutiez une signature numérique à vos requêtes, si vous utilisez un ID client pour l'authentification. Votre requête profite alors d'un niveau de sécurité supplémentaire qui protège davantage le quota associé à votre ID client. Votre clé cryptographique (par exemple, vNIXE0xscrmjlyV-12Nj_BvUPaw=) se trouve dans la lettre de bienvenue qui a été envoyée aux contacts principaux de votre organisation.

Remarque : La clé cryptographique sert à générer des signatures. Ne l'ajoutez pas à vos requêtes en tant que signature à proprement parler. Votre clé cryptographique ressemble au code secret de votre carte bancaire. Elle est utilisée comme moyen d'authentification afin d'accéder à votre compte et ne doit jamais être partagée ouvertement ni être visible par des sources non fiables. Les requêtes de service Web Premium Plan qui ne sont pas correctement signées seront rejetées par nos serveurs, il est donc essentiel que votre application signe correctement une requête avant le lancement. Voir le guide sur l'authentification et l'autorisation.

Suivre l'utilisation d'une application

Pourquoi c'est important : En tant que client Premium Plan, vous avez accès à des rapports détaillés sur l'utilisation de votre application, notamment les requêtes effectuées, les crédits consommés, les erreurs renvoyées, etc. Voir le guide sur les rapports.

Un paramètre channel est un paramètre facultatif qui vous permet de suivre l'utilisation via votre ID client en attribuant un canal distinct à chacune de vos applications. Les paramètres channel n'ont pas besoin d'être enregistrés sous votre ID client. Ajoutez-les à votre requête d'API pour afficher les résultats d'utilisation par canal dans les rapports d'utilisation du portail de support 1 ou 2 jours après l'implémentation. C'est à vous de décider où vos paramètres channel doivent être implémentés, et donc comment votre utilisation doit être cumulée. Décidez avant le lancement si votre application doit ou non intégrer des paramètres channel pour suivre l'utilisation de votre application.

Le paramètre channel doit utiliser le format suivant :

  • Il doit s'agir d'une chaîne alphanumérique ASCII.
  • Les caractères point (.), trait de soulignement (_) et tiret (-) sont autorisés.
  • Le paramètre channel n'est pas sensible à la casse ; les paramètres channel en majuscules, en minuscules ou mixtes sont transformés en minuscules. Par exemple, l'utilisation du paramètre channel CUSTOMER est combinée à celle du paramètre channel customer.

Vous pouvez implémenter jusqu'à 2 000 paramètres channel distincts par ID client.

Pour utiliser le paramètre channel, vous devez l'inclure dans l'URL de la requête avec le paramètre client utilisé pour transmettre l'ID client.

Notez que le paramètre channel doit correspondre à une valeur attribuée statiquement par application. Il ne doit pas être généré dynamiquement ni utilisé pour suivre des utilisateurs individuels.