Connecter Google Maps : distance, durée et ETA des itinéraires pour les axes TMS
Créez un projet dans Google Cloud Console, activez la Routes API, créez une API key, saisissez cette unique api_key dans Integration, testez-la avec un appel Routes réel, choisissez le modèle de planification d’itinéraires et activez : le TMS obtient alors distance, durée et itinéraire pour le coût d’axe et l’ETA.
Le connecteur Google Maps est une source de données d’itinéraires pour le TMS. Il utilise la Google Maps Routes API pour calculer un itinéraire à la fois (distance, durée et l’itinéraire lui-même), afin que les expéditions et les appels d’offres dans le TMS utilisent ce résultat comme base du coût d’axe et de l’ETA. C’est son seul rôle : il n’importe ni n’envoie de commandes, ne synchronise ni clients ni stock, et ne suit pas les véhicules. Une connexion contient une seule Google Maps API Key.
Prérequis#
- Accès à Google Cloud Console avec le droit de créer un projet, d’activer une API et de créer une API key dans ce projet.
- La Routes API sera activée dans ce projet. Sans elle, une clé correcte ne peut toujours pas renvoyer d’itinéraire.
- Vous comprenez que tester cette connexion génère de l’usage : il n’existe pas d’endpoint de sonde gratuit pour la Routes API, donc chaque test est un appel d’itinéraire réel et utilise un quota. Ne cliquez pas sur tester à répétition sans raison.
- Droit dans ce système d’ouvrir Integration et de créer une nouvelle connexion.
Obtenir les identifiants#
- Connectez-vous à Google Cloud Console et créez un projet pour cette connexion.
- Dans ce projet, activez la Routes API.
- Créez une API key dans le même projet et copiez la clé complète. Les clés de ce connecteur commencent par AIza… : copiez la valeur entière, sans rien couper à aucun bout.
- Restreignez la clé comme le suggère le guide de la console : limitez-la à la Routes API et à votre IP. Notez exactement quelle API et quelle IP vous avez autorisées, car un échec ultérieur vient souvent d’un simple écart avec cette restriction.
Remplir dans Integration#
- Ouvrez Integration → Marketplace → Google Maps → Nouvelle connexion.
- api_key, obligatoire, Google Maps API Key : collez l’API key complète créée dans Google Cloud Console après l’activation de la Routes API. C’est un champ de type mot de passe, conservé comme secret. Ce connecteur n’a pas de second champ : aucun nom de compte, champ de projet ni nom d’utilisateur à saisir ici.
- Enregistrez la connexion avant de la tester, afin que le test utilise exactement la clé que vous venez de saisir.
Tester la connexion#
Cliquez sur Tester la connexion. Avec une clé saisie, le test effectue un appel Routes réel et minimal : il envoie une requête computeRoutes à https://routes.googleapis.com/directions/v2:computeRoutes avec votre clé dans l’en-tête X-Goog-Api-Key, de l’origine 34.0633,-117.6509 à la destination 34.0733,-117.6409 en mode driving. Un succès signifie que la clé est valide et que la Routes API est joignable, et le message de succès le dit en toutes lettres : API key valide, Routes API joignable (la sonde consomme un quota). Prenez cette dernière partie au pied de la lettre : cette sonde est un appel réel et utilise un quota à chaque exécution. Testez donc une fois, corrigez la cause en cas d’échec, et retestez seulement ensuite.
Mapping / choisir un modèle#
Choisissez le modèle de planification d’itinéraires — le seul que ce connecteur utilise. Il n’y a aucun champ de commande ni de client à mapper. Ce que le modèle définit, c’est la façon dont un mode de déplacement demandé dans le TMS est envoyé à Google : driving et driving-traffic sont envoyés comme DRIVE, cycling comme BICYCLE et walking comme WALK. Après un test réussi, demandez dans le TMS un itinéraire que vous connaissez déjà et comparez la distance et la durée renvoyées avec ce que vous attendez pour cet axe, avant d’activer. Si les chiffres semblent faux sur tous les axes, vérifiez d’abord le mode : les deux mêmes points donnent des résultats très différents en voiture, à vélo et à pied.
Activer#
Après activation, le TMS peut demander un itinéraire à cette connexion quand une expédition ou un appel d’offres a besoin d’une estimation d’axe : la connexion renvoie distance, durée et itinéraire, et le TMS les utilise comme base du coût d’axe et de l’ETA. Surveillez les premières demandes réelles dans Runs / Logs et comparez quelques distances et durées renvoyées avec des axes que vous connaissez, avant de laisser la connexion sans surveillance.
Ce que cette connexion ne fait pas : elle fournit uniquement la planification d’itinéraires. Elle n’importe pas de commandes, ne renvoie rien vers un autre système, ne synchronise ni clients ni stock, et ne suit pas un véhicule en mouvement. Si un écran du TMS n’affiche aucune nouvelle commande après l’activation, c’est attendu : les commandes viennent de vos canaux de commande, et cette connexion répond seulement quand le TMS demande quelle distance, quelle durée et quel itinéraire.
FAQ#
Le test échoue juste après la création de la clé, avec la Routes API non joignable
La cause la plus fréquente est que la Routes API n’a jamais été activée dans le projet qui détient la clé. La clé peut être parfaitement valide en tant que clé, mais Google n’a pas le service Routes activé pour ce projet, donc l’appel computeRoutes n’a nulle part où aller.
Ouvrez Google Cloud Console, sélectionnez le même projet que celui où vous avez créé la clé, activez-y la Routes API, attendez un court moment que le changement prenne effet, puis testez la connexion une fois de plus.
Le test échoue après la restriction de la clé à une API et une IP
La restriction mise sur la clé ne correspond pas à la façon dont ce système appelle Google. Si la liste des API autorisées n’inclut pas la Routes API, ou si l’IP autorisée n’est pas l’adresse depuis laquelle ce système appelle, Google refuse l’appel même si le texte de la clé collé est exactement correct.
Dans Google Cloud Console, ouvrez cette clé et vérifiez les deux parties de la restriction : la Routes API doit figurer dans la liste des API autorisées, et l’IP autorisée doit être l’adresse depuis laquelle ce système appelle Google. Corrigez la restriction, enregistrez et testez une fois de plus — ne créez pas une seconde clé pour contourner un écart de restriction.
L’usage augmente alors que la connexion n’est pas encore activée
Chaque test est un appel réel. La Routes API n’a pas d’endpoint de sonde gratuit, donc le test ne peut prouver que la clé fonctionne qu’en demandant un itinéraire réel — et cette demande utilise un quota, exactement comme le dit le message de succès : la sonde consomme un quota. Tester à répétition avant l’activation est un usage réel.
Testez une fois. En cas d’échec, lisez l’échec, corrigez cette seule cause dans la clé, le projet ou la restriction, et retestez seulement ensuite. Quand le test réussit, passez au modèle et à l’activation au lieu de retester pour revérifier.
La clé semble complète, mais Google la refuse toujours
La valeur collée n’est pas la clé que Google a émise pour ce projet : un caractère s’est perdu à la copie, un espace en trop s’est glissé, ou la clé appartient à un autre projet où la Routes API et la restriction sont réglées autrement. Le champ accepte n’importe quel texte, donc seul l’appel réel du test peut trancher.
Retournez dans Google Cloud Console, ouvrez la clé dans le projet où la Routes API est activée, recopiez la valeur complète en une seule fois, collez-la dans api_key sans taper aucune partie à la main, enregistrez et testez une fois.
Les distances et durées semblent fausses sur un axe que vous connaissez bien
L’itinéraire a été calculé pour un mode de déplacement différent de celui attendu. Le modèle envoie driving et driving-traffic comme DRIVE, cycling comme BICYCLE et walking comme WALK, et les deux mêmes points donnent une distance, une durée et un itinéraire très différents dans chaque mode : un résultat à pied lu comme un résultat en voiture semble faux alors que l’appel a fonctionné.
Vérifiez quel mode la demande du TMS a utilisé pour cet axe, comparez-le avec le mode que vous aviez en tête et recalculez avec le mode voulu. Jugez le résultat uniquement face au même mode — ne comparez pas une durée BICYCLE avec votre expérience en voiture.
Activée, mais aucune commande ni aucun suivi n’apparaît nulle part
Rien n’est cassé. Cette connexion n’a jamais transporté de commandes ni de suivi : sa seule capacité est la planification d’itinéraires, donc l’activation n’ajoute ni flux de commandes ni positions de véhicules — elle permet seulement au TMS de demander distance, durée et itinéraire quand une expédition ou un appel d’offres a besoin d’une estimation d’axe.
Utilisez vos canaux de commande pour les commandes et les outils du transporteur pour le suivi. N’utilisez cette connexion que là où un coût d’axe ou un ETA est nécessaire, et vérifiez son travail dans le résultat d’itinéraire d’une expédition ou d’un appel d’offres dans le TMS.