Une adresse qui se lit tout naturellement dans un pays peut sembler complètement à l'envers, ou simplement fausse, lorsqu'elle est structurée selon la convention d'un autre pays. L'ordre dans lequel apparaissent le numéro, le nom de la rue, la localité, la région et le code postal relève d'une convention nationale, et parfois régionale, et non d'un modèle universel figé ; supposer que l'ordre de votre propre pays est l'ordre naturel ou par défaut est l'une des erreurs les plus courantes, et les plus évitables, lorsqu'on construit un outil qui gère des adresses internationales.
Certaines conventions placent le numéro avant le nom de la rue, d'autres après. Certaines mettent le code postal avant le nom de la ville sur la même ligne, d'autres après, et d'autres encore sur une ligne entièrement séparée. L'ordre relatif de la ville, de la région et du pays varie aussi, et quelques pays structurent les adresses du haut vers le bas selon la hiérarchie administrative, d'une manière qui paraît presque inversée par rapport aux conventions construites du bas vers le haut à partir du bâtiment précis.
Cela compte pour deux parties très différentes d'un système. La gestion des saisies, en particulier des champs d'adresse en texte libre, doit réellement tolérer les variations de format plutôt que d'attendre un modèle rigide, puisque les vrais utilisateurs qui saisissent une adresse de leur propre pays l'écriront naturellement dans l'ordre conventionnel de ce pays, et non dans l'ordre autour duquel votre formulaire a été conçu. La mise en forme en sortie, lorsqu'une adresse renvoyée est affichée à un utilisateur, devrait idéalement respecter la convention propre au pays de destination plutôt que de présenter toujours chaque adresse selon une disposition fixe, numéro d'abord ou code postal d'abord, quel que soit l'endroit où elle se trouve réellement, car une adresse mise en forme localement se lit naturellement tandis qu'une adresse mise en forme à l'étrangère semble nettement bizarre, même lorsque chaque composant sous-jacent est correct.
Le géocodage lui-même résiste généralement mieux à l'ordre des composants qu'un analyseur naïf, en particulier lorsqu'il traite l'entrée comme une chaîne entière à rapprocher de données de référence connues plutôt que d'attendre les composants dans une séquence stricte et prédéfinie. Cela dit, tester votre gestion des adresses spécifiquement avec des exemples correctement mis en forme provenant de plusieurs pays, et pas seulement avec des versions réordonnées du format de votre propre pays, révélera les lacunes de votre logique de validation et d'affichage bien avant que des utilisateurs internationaux ne les rencontrent directement.
Si vous construisez la saisie ou l'affichage d'adresses pour un public international, il vaut la peine de tester délibérément quelques pays dont les conventions diffèrent sensiblement des vôtres, plutôt que de supposer qu'un modèle unique se généralise. Notre endpoint de géocodage direct est conçu pour tolérer ces variations dans l'entrée elle-même, mais la validation de formulaire et la logique d'affichage d'adresses qui l'entourent méritent d'être vérifiées séparément face à la même diversité.