Un format d’adresse internationale n’est pas un format unique. C’est une famille de conventions qui ne s’accordent ni sur ce qui vient en premier, ni sur le nom d’une division, ni sur la position du nom du destinataire au-dessus ou au-dessous du bâtiment. Quiconque construit un formulaire, une étiquette ou une enveloppe imprimée se heurte vite à ces désaccords, et la solution la moins coûteuse — un seul modèle avec quelques lignes facultatives — cesse de fonctionner dès qu’un deuxième pays rejoint la liste.
Cet article traite de la manière dont les adresses sont réellement ordonnées dans le monde, des champs qui varient, de l’importance de l’écriture et de la façon de modéliser les données pour que les décisions d’affichage restent distinctes des décisions de stockage.
Deux sens de rédaction d’une adresse
Les adresses s’écrivent de la plus petite unité vers l’extérieur dans certains endroits et de la plus grande vers l’intérieur dans d’autres, et ces deux habitudes produisent des ordres de lignes en miroir.
Dans une grande partie de l’Asie de l’Est, une adresse va traditionnellement de la grande unité vers la petite : d’abord le pays ou la province, puis la ville ou l’arrondissement, puis le district, puis la rue, puis le numéro de bâtiment, puis l’unité. Les conventions occidentales vont dans l’autre sens : numéro et rue, puis ville, puis région, puis code postal, puis pays. Aucun ordre n’est plus logique ; chacun regroupe l’information comme le service postal local et le lecteur local l’attendent.
Le courrier international ajoute une convention supplémentaire par-dessus. Comme le pays de destination est ce dont les machines de tri ont besoin en premier, il est traditionnellement placé en dernière ligne, seul, en majuscules ou mis en évidence d’une autre manière. C’est une convention d’acheminement plutôt qu’une règle de données, et c’est pourquoi les enveloppes imprimées ressemblent souvent à tout sauf à l’ordre dans lequel un formulaire collecte les champs.
| Convention | Où c’est l’usage | Ordre des lignes |
|---|---|---|
| Grande unité vers l’extérieur | Une grande partie de l’Asie de l’Est | Pays ou province, puis ville ou arrondissement, puis district, puis rue, puis numéro de bâtiment, puis l’unité |
| Petite unité vers l’extérieur | Conventions occidentales | Numéro et rue, puis ville, puis région, puis code postal, puis pays |
| Convention d’acheminement | Courrier international | Le pays de destination en dernier, seul, en majuscules ou mis en évidence |
Un modèle unique peut-il gérer tous les pays ?
Seulement mal. Un modèle fige une hypothèse sur les champs qui existent, ceux qui partagent une ligne et leur ordre d’apparition, et ces hypothèses sont exactement ce qui change d’un pays à l’autre.
Un modèle unique et figé placera un numéro de maison devant un nom de rue dans un pays qui le place après, insérera une virgule là où la convention locale utilise un caractère marqueur, ou réservera une ligne à un État que l’adresse n’utilise jamais. Considérez ce qui se passe en pratique : certains pays omettent habituellement toute division, localisant une adresse par la ville et le code postal, de sorte qu’un champ région obligatoire force les utilisateurs à répéter la ville ou à choisir une approximation. D’autres utilisent un niveau de division qui n’a pas d’équivalent dans le modèle, et le nom est déversé dans le champ libre.
La solution est plus simple qu’il n’y paraît : gardez les données complètes et laissez la couche d’affichage décider de l’ordre des lignes. L’ordre relève de la présentation, et aucun champ ne devrait en dépendre.
Quelle est la différence entre un État, une province et une préfecture ?
Ce sont tous des divisions administratives de premier niveau, et leur nom varie selon le pays — État, province, préfecture, région, canton, gouvernorat, émirat, oblast. Le libellé importe au lecteur et pas du tout au modèle de données, et c’est pourquoi les appeler toutes « État » crée plus de problèmes qu’elle n’en résout.
Les problèmes sont concrets. Un utilisateur d’un pays qui nomme la division autrement doit deviner ce que le formulaire désigne. Un script de support qui filtre les enregistrements par État exclut les enregistrements dont la division porte un autre nom dans le système source. Une règle de validation vérifiée contre une liste d’États américains rejette presque toutes les adresses hors des États-Unis.
Gardez le champ générique dans le schéma et localisez le libellé au moment du rendu. Stockez la valeur avec son code pays, car un nom de division n’a de sens qu’à côté du pays auquel il appartient ; deux pays peuvent partager le nom d’une division et désigner des endroits différents. La parenté entre ces codes est décrite dans le guide sur les codes ISO de pays et de subdivisions.
Écriture, translittération et l’échec discret des champs purement latins
De nombreuses adresses sont rédigées dans une écriture autre que le latin. Certains pays de destination exigent l’écriture locale pour la distribution intérieure et acceptent une version romanisée pour l’acheminement international ; d’autres attendent la forme romanisée sur le courrier entrant. Aucun des deux arrangements n’est universel.
Deux choses tournent mal lorsqu’un système suppose des caractères latins. La première est le rejet pur et simple : un jeu de caractères qui exclut les lettres non latines transforme une adresse valide en erreur, et l’utilisateur ne peut rien corriger puisque l’adresse est correcte. La seconde est plus discrète — un champ qui accepte les caractères mais les normalise, les translittère ou les tronque, de sorte que la valeur stockée ne correspond plus à ce que l’utilisateur a saisi et qu’une comparaison ultérieure échoue.
Les caractères ne sont pas le seul danger. Certaines écritures s’écrivent sans espaces entre les composantes de l’adresse, de sorte qu’un analyseur syntaxique qui découpe sur les espaces trouve un seul jeton énorme au lieu de six champs. D’autres utilisent un marqueur entre le nom de rue et le numéro là où les conventions latines emploient une espace ou une virgule. La longueur n’est pas uniforme non plus : une adresse romanisée est généralement plus longue que son original, de sorte qu’un champ dimensionné pour l’écriture locale peut être trop petit pour sa propre translittération.
Gérer les noms de bâtiments, les numéros d’unité et les districts
Les adresses réelles comportent des unités que les modèles anticipent rarement : appartements, étages, blocs, tours, numéros d’entrée, noms de bâtiments, noms de sous-districts et indications sous forme de point de repère. La liste locale de ces identifiants diffère autant que les noms de divisions.
Deux règles les rendent gérables. Recueillez les détails d’unité dans leur propre champ plutôt que de les ajouter à la ligne de rue, afin que la rue subsiste pour l’analyse syntaxique et le géocodage. Et lorsqu’un pays inclut couramment un niveau que votre modèle n’a pas — un district sous la ville, un nom de bâtiment au-dessus de la rue — ajoutez un champ au lieu de concaténer. Un champ dont le sens est unique coûte peu ; un champ qui signifie « tout ce qu’il y avait d’autre » est l’endroit où la qualité des données va mourir.
Pour les développeurs : un champ, un sens
Le principe de conception qui résiste au contact du plus grand nombre de pays est le moins ingénieux : donnez à chaque élément d’information d’adresse son propre champ doté d’un seul sens, et ne laissez jamais le nom d’un champ sous-entendre un pays.
Concrètement, cela signifie un champ code pays, un champ division qui ne s’appelle pas État, des champs distincts pour le district, la ville, la rue, le numéro de maison et les détails d’unité, un champ code postal, et une ligne libre pour l’information qui ne rentre dans aucun d’eux. Gardez les champs facultatifs dans le schéma et imposez ce dont vous avez besoin par pays au moment de la validation, là où le pays est connu.
Ajoutez une définition d’affichage par pays, tenue à l’écart des données : l’ordre des lignes, les champs qui sont joints, la présence de la division dans le bloc d’adresse, et l’emplacement du code postal. Cette séparation vous permet d’ajouter un pays en modifiant une seule définition plutôt qu’en rouvrant la logique du formulaire. Elle signifie aussi qu’un bug de mise en page ne peut pas corrompre les données stockées.
Enfin, soyez prudent avec la concaténation. Si vous construisez une adresse sur une seule ligne pour un appel d’API, faites aussi du séparateur une partie de la définition d’affichage, car joindre avec une virgule partout produit une adresse qui ne se lit correctement que dans les pays qui utilisent la virgule.
Étapes suivantes
Choisissez trois pays que vous servez réellement et écrivez à la main la manière dont chacun ordonne la même information. Là où les trois divergent, vous avez trouvé les points de rupture de votre modèle. Ensuite, générez une adresse par pays dans le générateur d’adresses et collez chacune dans votre formulaire pour voir si la mise en page tient encore debout ; le guide sur les données d’adresse dans les jeux de tests explique comment garder ces échantillons reproductibles. Gardez à l’esprit ce que sont ces échantillons : des valeurs générées ayant la forme d’adresses réelles, destinées aux tests plutôt qu’à la livraison, et sans indication sur le lieu de résidence de quiconque.