Obtenir un itinéraire via l'ancienne API Directions

Développeurs de l'Espace économique européen (EEE)

Ce produit est en état obsolète. À partir d'octobre 2026, l'API Directions (ancienne) ne pourra plus être activée pour les nouveaux projets Google Cloud. Les projets existants restent entièrement compatibles. Pour bénéficier de nouvelles fonctionnalités et de performances améliorées, migrez vers l'API Routes.

Pour les calculs d'itinéraires qui répondent en temps réel aux entrées utilisateur (par exemple, dans un élément d'interface utilisateur), vous pouvez utiliser l'API Directions (ancienne) ou, si vous utilisez l'API Maps JavaScript, le service Directions. Pour une utilisation côté serveur, vous pouvez utiliser les clients Java, Python, Go et Node.js pour les services Google Maps.

L'API Directions (ancienne) vous permet d'effectuer les opérations suivantes :

  • Recherchez des itinéraires pour plusieurs modes de transport, y compris les transports en commun, la voiture, la marche ou le vélo.
  • Affichez des itinéraires multi-segments passant par une série de points de cheminement.
  • Spécifiez les points de départ, les destinations et les points de cheminement sous forme de chaînes de texte (par exemple, "Chicago, IL" ou "Darwin, NT, Australie"), d'ID de lieu ou de coordonnées de latitude/longitude.

L'API renvoie les itinéraires les plus efficaces lors du calcul d'itinéraires. Le temps de trajet est le principal facteur optimisé, mais l'API peut également prendre en compte d'autres facteurs (tels que la distance, le nombre de bifurcations et bien d'autres) lors du choix de l'itinéraire le plus efficace.

Avant de commencer

Avant de pouvoir utiliser l'API Directions (ancienne), vous devez disposer d'un projet avec un compte de facturation et l'API Directions (ancienne) doit être activée. Pour en savoir plus, consultez Configurer vos projets dans la console Cloud.

Créer vos requêtes Directions API (ancienne version)

Une requête de l'API Directions (ancienne version) se présente sous la forme suivante :

https://maps.googleapis.com/maps/api/directions/outputFormat?parameters

où outputFormat peut correspondre à l'une des valeurs suivantes :

  • json (recommandé) indique une sortie au format JSON (JavaScript Object Notation).
  • xml indique une sortie au format XML.

Remarque : Pour être valides, les URL doivent être correctement encodées. Elles sont limitées à 16 384 caractères pour tous les services Web. Tenez compte de cette limite lorsque vous créez vos URL.

Comme c'est la norme pour les URL, les différents paramètres sont séparés par une esperluette (&). Tous les caractères réservés (par exemple, le signe plus "+") doivent être encodés au format URL. Vous trouverez ci-dessous la liste des paramètres et leurs différentes valeurs possibles.

Paramètres obligatoires

  • destination

    ID de lieu, adresse ou valeur textuelle de latitude/longitude pour laquelle vous souhaitez calculer un itinéraire. Les options du paramètre de destination sont les mêmes que celles du paramètre d'origine.

  • origin

    ID de lieu, adresse ou valeur textuelle de latitude/longitude à partir de laquelle vous souhaitez calculer l'itinéraire.

    • Les ID de lieu doivent être précédés de place_id:. Vous pouvez obtenir les ID de lieu via l'API Geocoding et l'API Places (y compris Place Autocomplete). Pour obtenir un exemple d'utilisation des ID de lieu de Place Autocomplete, consultez Place Autocomplete et Directions. Pour en savoir plus sur les ID de lieu, consultez la présentation des ID de lieu. 

      origin=place_id:ChIJ3S-JXmauEmsRUcIaWtf4MzE

    • Si vous transmettez une adresse, le service Directions géocode la chaîne et la convertit en coordonnées de latitude/longitude pour calculer l'itinéraire. Cette coordonnée peut être différente de celle renvoyée par l'API Geocoding (par exemple, l'entrée d'un bâtiment plutôt que son centre). 

      origin=24+Sussex+Drive+Ottawa+ON

      Il est préférable d'utiliser des ID de lieu plutôt que des adresses ou des coordonnées de latitude/longitude. L'utilisation de coordonnées entraîne toujours l'alignement du point sur la route la plus proche de ces coordonnées, qui peut ne pas être un point d'accès à la propriété, ni même une route menant rapidement ou en toute sécurité à la destination.

    • Si vous transmettez des coordonnées, le point s'alignera sur la route la plus proche. Il est préférable de transmettre un ID de lieu. Si vous transmettez des coordonnées, assurez-vous qu'il n'y a pas d'espace entre les valeurs de latitude et de longitude. 

      origin=41.43206,-81.38992

    • Les Plus Codes doivent être mis en forme comme un code global ou un code composé. Mettez en forme les Plus Codes comme indiqué ici (les signes plus sont échappés au format URL en %2B et les espaces en %20).

      • Le code global est un indicatif de zone de 4 caractères et un code local à 6 caractères ou plus (849VCWC8+R9 correspond à 849VCWC8%2BR9).
      • Le code composé est un code local à six caractères ou plus associé à un emplacement explicite (CWC8+R9 Mountain View, CA, États-Unis correspond à CWC8%2BR9%20Mountain%20View%20CA%20USA).
    Remarque : Pour plus d'efficacité et de précision, utilisez des ID de lieu lorsque cela est possible. Ces ID sont explicitement uniques, comme une paire de valeurs de latitude/longitude, et offrent des avantages de géocodage pour l'itinéraire, tels que les points d'accès et les variables de trafic. Contrairement à une adresse, les ID ne nécessitent pas que le service effectue une recherche ou une requête intermédiaire pour obtenir des détails sur un lieu. Les performances sont donc meilleures.

Paramètres facultatifs

  • autres solutions

    Si ce paramètre est défini sur true, il indique que le service Directions peut fournir plusieurs itinéraires alternatifs dans la réponse. Notez que le calcul d'itinéraires alternatifs peut augmenter le temps de réponse du serveur. Cette option n'est disponible que pour les requêtes sans points de cheminement intermédiaires. Pour en savoir plus, consultez le guide sur les points de cheminement.

  • arrival_time

    Spécifie l'heure d'arrivée souhaitée pour les itinéraires en transports en commun, en secondes depuis minuit le 1er janvier 1970 UTC. Vous pouvez spécifier departure_time ou arrival_time, mais pas les deux. Notez que arrival_time doit être spécifié sous forme d'entier.

  • éviter

    Indique que le ou les itinéraires calculés doivent éviter les éléments indiqués. Il prend en charge les arguments suivants :

    • tolls indique que l'itinéraire calculé doit éviter les routes et les ponts à péage.
    • highways indique que l'itinéraire calculé doit éviter les autoroutes.
    • ferries indique que l'itinéraire calculé doit éviter les ferries.
    • indoor indique que l'itinéraire calculé doit éviter les escaliers intérieurs pour les itinéraires à pied et en transports en commun.

    Il est possible de demander un itinéraire qui évite toute combinaison de péages, d'autoroutes et de ferries en transmettant plusieurs restrictions au paramètre "avoid". Exemple : 

    avoid=tolls|highways|ferries.

  • departure_time

    Spécifie l'heure de départ souhaitée. Vous pouvez spécifier l'heure sous la forme d'un entier en secondes depuis minuit, le 1er janvier 1970 UTC. Si un departure_time postérieur au 31/12/9999 à 23:59:59.999999999Z est spécifié, l'API rétablit le departure_time au 31/12/9999 à 23:59:59.999999999Z. Vous pouvez également spécifier la valeur "now", qui définit l'heure de départ sur l'heure actuelle (à la seconde près). L'heure de départ peut être spécifiée dans deux cas :

    • Pour les requêtes où le mode de transport est "transit" : vous pouvez éventuellement spécifier departure_time ou arrival_time. Si aucune heure n'est spécifiée, departure_time est défini par défaut sur "now" (c'est-à-dire que l'heure de départ est définie par défaut sur l'heure actuelle).
    • Pour les requêtes où le mode de transport est la conduite : vous pouvez spécifier departure_time pour recevoir un itinéraire et une durée de trajet (champ de réponse : duration_in_traffic) qui tiennent compte des conditions de circulation. departure_time doit être défini sur l'heure actuelle ou sur une heure ultérieure, mais pas sur une heure passée.
    Remarque : Si l'heure de départ n'est pas spécifiée, l'itinéraire et la durée sont déterminés en fonction du réseau routier et des conditions de circulation moyennes toutes heures confondues. Les résultats d'une requête donnée peuvent varier au fil du temps en raison des modifications du réseau routier, de l'évolution des conditions de circulation moyennes et de la nature décentralisée du service. Les résultats peuvent également varier entre plusieurs itinéraires presque équivalents à tout moment et à n'importe quelle fréquence.
    Remarque : Les requêtes Matrice des distances spécifiant departure_time lorsque mode=driving sont limitées à un maximum de 100 éléments par requête. Le nombre d'éléments est défini par le nombre de points de départ multiplié par le nombre de destinations.

  • language

    Langue dans laquelle les résultats doivent être renvoyés. Notez que cela ne s'applique qu'aux adresses géocodées dans start_address et end_address, au texte localisé dans les champs distance et duration (dans les étapes et les segments) et à la description des manœuvres dans html_instructions, mais pas aux noms et adresses dans html_instructions, qui sont formatés dans leur langue et leur script locaux.

    • Consultez la liste des langues acceptées. Google met souvent à jour les langues acceptées. Cette liste n'est donc pas exhaustive.
    • Si language n'est pas fourni, l'API tente d'utiliser la langue préférée spécifiée dans l'en-tête Accept-Language.
    • L'API s'efforce de fournir une adresse postale lisible à la fois pour l'utilisateur et pour les habitants. Pour atteindre cet objectif, elle renvoie les adresses postales dans la langue locale, translittérées dans un script lisible par l'utilisateur si nécessaire, en respectant la langue préférée. Toutes les autres adresses sont renvoyées dans la langue préférée. Les composants d'adresse sont tous renvoyés dans la même langue, qui est choisie à partir du premier composant.
    • Si aucun nom n'est disponible dans la langue préférée, l'API utilise la correspondance la plus proche.
    • La langue préférée a une légère influence sur l'ensemble des résultats que l'API choisit de renvoyer et sur l'ordre dans lequel ils sont renvoyés. Le geocoder interprète les abréviations différemment selon la langue, par exemple les abréviations des types de rues ou les synonymes qui peuvent être valides dans une langue, mais pas dans une autre. Par exemple, utca et tér sont des synonymes de "rue" en hongrois.

  • mode

    Pour calculer les distances et les itinéraires, vous pouvez spécifier le mode de transport à utiliser. Par défaut, le mode driving est utilisé. Par défaut, les itinéraires sont calculés pour les trajets en voiture. Les modes de transport suivants sont acceptés :

    • driving (par défaut) indique un itinéraire en voiture standard ou une distance via le réseau routier.
    • walking demande un itinéraire à pied ou une distance via les voies piétonnes et les trottoirs (dans la mesure du possible).
    • bicycling demande un itinéraire à vélo ou une distance à vélo via les pistes cyclables et les rues à privilégier (dans la mesure du possible).
    • transit demande un itinéraire ou une distance via les réseaux de transports en commun (dans la mesure du possible). Si vous définissez le mode sur "transit", vous pouvez éventuellement spécifier un departure_time ou un arrival_time. Si aucune heure n'est spécifiée, departure_time est défini par défaut sur "now" (c'est-à-dire que l'heure de départ est définie par défaut sur l'heure actuelle). Vous pouvez également inclure un transit_mode et/ou un transit_routing_preference. Les trajets en transports en commun sont disponibles jusqu'à sept jours dans le passé ou jusqu'à 100 jours dans le futur, sous réserve de la disponibilité des informations sur les transports en commun fournies par les fournisseurs de données. Les horaires des transports en commun changent fréquemment. Les trajets disponibles peuvent changer au fil du temps, et il n'est pas garanti que les prédictions soient cohérentes longtemps à l'avance.
    Remarque : Les itinéraires à pied et les itinéraires à vélo peuvent parfois ne pas inclure de voies piétonnes ou de pistes cyclables claires. Dans ce cas, ces itinéraires renvoient des avertissements dans le résultat renvoyé que vous devez afficher pour l'utilisateur.

  • région

    Code régional, spécifié sous la forme d'une valeur ccTLD (domaine de premier niveau) à deux caractères. La plupart des codes ccTLD sont identiques aux codes ISO 3166-1, à quelques exceptions près. Par exemple, le ccTLD du Royaume-Uni est "uk" (.co.uk), tandis que son code ISO 3166-1 est "gb" (techniquement pour l'entité "Royaume-Uni de Grande-Bretagne et d'Irlande du Nord").

  • traffic_model

    Spécifie les hypothèses à utiliser pour calculer le temps de trajet. Ce paramètre influe sur la valeur renvoyée dans le champ "duration_in_traffic" de la réponse, qui contient le temps de trajet prévu en fonction des moyennes historiques. Le paramètre traffic_model ne peut être spécifié que pour les itinéraires en voiture lorsque la requête inclut un departure_time. Les valeurs disponibles pour ce paramètre sont les suivantes :

    • best_guess (par défaut) indique que la valeur duration_in_traffic renvoyée doit correspondre à la meilleure estimation du temps de trajet compte tenu des conditions de circulation historiques et en temps réel. Plus departure_time est proche de l'heure actuelle, plus la circulation en temps réel devient importante.
    • pessimistic indique que la valeur duration_in_traffic renvoyée doit être supérieure à la durée réelle du trajet la plupart du temps. Toutefois, les jours où la circulation est particulièrement difficile, le temps de trajet peut être plus long.
    • optimistic indique que la valeur duration_in_traffic renvoyée doit être inférieure à la durée réelle du trajet la plupart du temps. Toutefois, les jours où la circulation est particulièrement fluide, le temps de trajet peut être plus court.

    La valeur par défaut de best_guess fournit les prédictions les plus utiles pour la grande majorité des cas d'utilisation. Il est possible que la prédiction du temps de trajet best_guess soit plus courte que optimistic ou, à l'inverse, plus longue que pessimistic, en raison de la manière dont le modèle prédictif best_guess intègre les informations sur la circulation en temps réel.

  • transit_mode

    Spécifie un ou plusieurs modes de transport à privilégier. Ce paramètre ne peut être spécifié que pour les itinéraires en transports en commun. Le paramètre accepte les arguments suivants :

    • bus indique que l'itinéraire calculé doit privilégier les trajets en bus.
    • subway indique que l'itinéraire calculé doit privilégier les trajets en métro.
    • train indique que l'itinéraire calculé doit privilégier les trajets en train.
    • tram indique que l'itinéraire calculé doit privilégier les trajets en tramway et en métro léger.
    • rail indique que l'itinéraire calculé doit privilégier les trajets en train, en tramway, en métro léger et en métro. Cela équivaut à transit_mode=train|tram|subway.

  • transit_routing_preference

    Spécifie les préférences pour les itinéraires en transports en commun. Ce paramètre vous permet d'ajuster les options renvoyées plutôt que d'accepter le meilleur itinéraire choisi par défaut par l'API. Ce paramètre ne peut être spécifié que pour les itinéraires en transports en commun. Il prend en charge les arguments suivants :

    • less_walking indique que l'itinéraire calculé doit limiter le plus possible la marche.
    • fewer_transfers indique que l'itinéraire calculé doit utiliser un nombre limité de correspondances.

  • unités

    Spécifie le système d'unités à utiliser lors de l'affichage des résultats.

    Les résultats d'itinéraire contiennent du texte dans les champs de distance qui peut être affiché à l'utilisateur pour indiquer la distance d'une "étape" particulière de l'itinéraire. Par défaut, ce texte utilise le système d'unités du pays ou de la région de départ.

    Par exemple, un itinéraire de "Chicago, Illinois" à "Toronto, Ontario" affichera les résultats en miles, tandis que l'itinéraire inverse les affichera en kilomètres. Vous pouvez ignorer ce système d'unités en définissant explicitement celui que vous souhaitez utiliser dans le paramètre "units" de la requête, en transmettant l'une des valeurs suivantes :

    • metric spécifie l'utilisation du système métrique. Les distances textuelles sont renvoyées en kilomètres et en mètres.
    • imperial spécifie l'utilisation du système impérial (anglais). Les distances textuelles sont renvoyées en utilisant des miles et des pieds.
    Remarque : Ce paramètre de système d'unités n'influe que sur le texte affiché dans les champs de distance. Les champs de distance contiennent également des valeurs qui sont toujours exprimées en mètres.

  • waypoints

    Attention : Les requêtes utilisant plus de 10 points de cheminement (entre 11 et 25) ou utilisant l'optimisation des points de cheminement sont facturées à un tarif plus élevé. En savoir plus sur la facturation des produits Google Maps Platform

    Spécifie un tableau de lieux intermédiaires à inclure le long de l'itinéraire entre les points de départ et d'arrivée, en tant que lieux de passage ou d'arrêt. Les points de cheminement modifient un itinéraire en le faisant passer par le ou les lieux indiqués. L'API accepte les points de cheminement pour les modes de transport suivants : en voiture, à pied et à vélo, mais pas en transports en commun. Vous pouvez fournir un ou plusieurs lieux séparés par une barre verticale (| ou %7C), sous la forme d'un ID de lieu, d'une adresse ou de coordonnées de latitude/longitude. Par défaut, le service Directions calcule un itinéraire en utilisant les points de cheminement dans l'ordre fourni. L'ordre de priorité pour l'analyse de la valeur du point de cheminement est le suivant : ID de lieu, coordonnées de latitude/longitude, puis adresse.

    • Si vous transmettez un ID de lieu, vous devez le faire précéder de place_id:. Vous pouvez obtenir les ID de lieu via l'API Geocoding et l'API Places (y compris Place Autocomplete). Pour obtenir un exemple d'utilisation des ID de lieu de Place Autocomplete, consultez Place Autocomplete et Directions. Pour en savoir plus sur les ID de lieu, consultez la présentation des ID de lieu.
      Pour plus d'efficacité et de précision, utilisez des ID de lieu lorsque cela est possible. Ces ID sont explicitement uniques, comme une paire de valeurs de latitude/longitude, et offrent des avantages de géocodage pour le routage, tels que des points d'accès et des variables de trafic. Contrairement à une adresse, les ID ne nécessitent pas que le service effectue une recherche ou une requête intermédiaire pour obtenir des détails sur un lieu. Les performances sont donc meilleures.
    • Si vous transmettez des coordonnées de latitude/longitude, les valeurs sont envoyées directement au serveur d'interface pour calculer l'itinéraire sans géocodage. Les points sont alignés sur les routes et peuvent ne pas fournir la précision dont votre application a besoin. Utilisez des coordonnées lorsque vous êtes certain que les valeurs spécifient réellement les points dont votre application a besoin pour l'itinéraire, sans tenir compte des points d'accès possibles ni des détails de géocodage supplémentaires. Assurez-vous que les valeurs de latitude et de longitude sont séparées par une virgule (%2C) et non par un espace (%20).
    • Si vous transmettez une adresse, le service Directions géocode la chaîne et la convertit en coordonnées de latitude et de longitude pour calculer l'itinéraire. Si la valeur de l'adresse est ambiguë, elle peut déclencher une recherche pour lever l'ambiguïté par rapport à des adresses similaires. Par exemple, "1st Street" peut être une valeur complète ou une valeur partielle pour "1st street NE" ou "1st St SE". Ce résultat peut être différent de celui renvoyé par l'API Geocoding. Vous pouvez éviter les erreurs d'interprétation en utilisant des ID de lieu.
    • Vous pouvez également fournir un ensemble de points encodés à l'aide de l'algorithme de polyligne encodée. Un ensemble encodé est utile pour un grand nombre de points de cheminement, car l'URL est beaucoup plus courte. Tous les services Web ont une limite d'URL de 16 384 caractères.
      • Les polylignes encodées doivent être précédées de enc: et suivies d'un signe deux-points (:). Exemple : waypoints=enc:gfo}EtohhU:.
      • Vous pouvez également inclure plusieurs polylignes encodées, séparées par une barre verticale (|). Par exemple : waypoints=via:enc:wc~oAwquwMdlTxiKtqLyiK:|enc:c~vnAamswMvlTor@tjGi}L:| via:enc:udymA{~bxM:
    Influencer les itinéraires avec des points d'arrêt et de passage

    Pour chaque point de cheminement de la requête, la réponse d'itinéraire ajoute une entrée au tableau legs afin de fournir les détails des arrêts sur cette section du trajet.

    Si vous souhaitez influencer l'itinéraire à l'aide de points de cheminement sans ajouter d'arrêt, ajoutez le préfixe via: au point de cheminement. Les points de cheminement précédés du préfixe via: n'ajoutent pas d'entrée au tableau legs, mais l'itinéraire passe par le point de cheminement.

    L'URL suivante modifie la requête précédente de sorte que le trajet passe par Lexington sans s'arrêter : 

    https://maps.googleapis.com/maps/api/directions/json?
origin=Boston,MA&destination=Concord,MA
&waypoints=Charlestown,MA|via:Lexington,MA

    Le préfixe via: est plus efficace lorsque vous créez des itinéraires en réponse au déplacement des points de cheminement sur la carte par l'utilisateur. Cela permet à l'utilisateur de voir à quoi peut ressembler l'itinéraire final en temps réel et de s'assurer que les points de cheminement sont placés à des emplacements accessibles à l'API Directions.

    Attention : Si vous utilisez le préfixe via: pour éviter les arrêts, les résultats interprètent le point de cheminement de manière stricte dans l'itinéraire. Cela peut entraîner des détours importants ou un code d'état ZERO_RESULTS dans la réponse si l'API Directions ne peut pas créer d'itinéraire passant par ce point.
    Optimiser vos points de cheminement

    Par défaut, le service Directions calcule un itinéraire passant par les points de cheminement dans l'ordre fourni. Vous pouvez facultativement transmettre optimize:true comme premier argument dans le paramètre "waypoints" pour permettre au service Directions d'optimiser l'itinéraire fourni en réorganisant les points de cheminement dans un ordre plus efficace. (Cette optimisation est une application du problème du voyageur de commerce.) Le temps de trajet est le principal facteur optimisé, mais d'autres facteurs (tels que la distance, le nombre de bifurcations et bien d'autres) peuvent être pris en compte lors du choix de l'itinéraire le plus efficace. Tous les points de cheminement doivent être des arrêts pour que le service Directions optimise l'itinéraire.

    Si vous demandez au service Directions d'optimiser l'ordre des points de cheminement, cet ordre sera renvoyé dans le champ waypoint_order de l'objet "routes". Le champ waypoint_order renvoie des valeurs basées sur zéro.

    L'exemple suivant calcule un trajet routier entre Adélaïde, en Australie-Méridionale, et chacune des principales régions viticoles d'Australie-Méridionale à l'aide de l'optimisation d'itinéraire. 

    https://maps.googleapis.com/maps/api/directions/json?
origin=Adelaide,SA&destination=Adelaide,SA
&waypoints=optimize:true|Barossa+Valley,SA|Clare,SA|Connawarra,SA|McLaren+Vale,SA

    L'inspection de l'itinéraire calculé indique que le calcul utilise les points de cheminement dans l'ordre suivant : 

    "waypoint_order": [ 3, 2, 0, 1 ]
    Attention : Les requêtes utilisant l'optimisation des points de cheminement sont facturées à un tarif plus élevé. En savoir plus sur la facturation des produits Google Maps Platform

Étape suivante

Exemples d'instructions

Réponses d'itinéraires