Un générateur d’adresses américaines vous fournit à la demande des adresses américaines complètes, assemblées à partir d’un numéro de rue, d’un nom de voie, d’une unité facultative, d’une ville, d’une abréviation d’État à deux lettres et d’un code ZIP à cinq chiffres pouvant porter une extension à quatre chiffres. Ce qui distingue un générateur utile d’un assembleur de chaînes aléatoires, c’est que chaque champ s’accorde avec les autres : la ville appartient à l’État, et le code ZIP appartient aux deux.
Ce guide détaille ce qui compose réellement une adresse américaine, comment les États, les territoires et les divisions se rapportent les uns aux autres, pourquoi la cohérence entre le code ZIP et la ville compte plus que ne l’imaginent la plupart des équipes, et où se situe la limite honnête des enregistrements générés. À la fin, vous saurez quels défauts d’adresse vos formulaires devraient intercepter, et lesquels un générateur élimine discrètement pour vous.
De quoi se compose réellement une adresse américaine ?
Une adresse américaine s’écrit du plus petit au plus grand, soit l’inverse de l’ordre utilisé au Japon et dans plusieurs autres systèmes postaux. La ligne du destinataire vient en premier, puis le numéro et le nom de voie, puis l’unité ou l’appartement, puis la ville, puis l’abréviation d’État, puis le code ZIP. Lorsque l’adresse est écrite sur une seule ligne, la forme standard réunit la ville et l’État, une virgule, puis le code ZIP à la fin. Un générateur d’adresses américaines qui respecte cette séquence produit une étiquette lisible correctement par un transporteur, tandis qu’un générateur qui réordonne les éléments produit une ligne qui paraît étrangère même lorsque chaque valeur est juste.
L’élément d’État est toujours un code à deux lettres plutôt qu’un nom épelé, et le service postal maintient cette liste comme un ensemble figé. Le code ZIP comporte cinq chiffres, et depuis la fin des années 1980 un suffixe facultatif de quatre chiffres peut le suivre après un trait d’union pour identifier un segment de distribution plus fin. Les formulaires qui acceptent la forme étendue doivent accepter les deux longueurs, car un jeu de données qui ne porte jamais que la version à cinq chiffres n’exercera jamais le chemin plus long.
Le désignateur d’unité est le champ le plus susceptible d’être facultatif dans un système et obligatoire dans un autre. Un numéro d’appartement, de suite, d’étage, d’unité ou de bâtiment peut s’écrire sous forme d’un mot suivi d’un nombre, d’un croisillon suivi d’un nombre, ou d’un nombre seul sur une seconde ligne. Chacune de ces formes se rencontre dans des données réelles, si bien qu’un analyseur qui ne gère que la forme avec mot rejettera des saisies valides.
En quoi les États, le district de Columbia et les territoires diffèrent
Cinquante États, le district de Columbia et les territoires habités possèdent chacun leur code à deux lettres, et ils ne sont pas interchangeables dans une liste déroulante. Le district de Columbia porte le code DC et se comporte comme un État du point de vue de l’adresse, mais il n’en est pas un, et les systèmes qui modélisent le premier niveau de la hiérarchie comme « État » le mal étiquetteront dans les rapports et les filtres.
Les territoires sont le problème plus discret. Porto Rico porte PR, Guam porte GU, les îles Vierges des États-Unis portent VI, les Samoa américaines portent AS et les îles Mariannes du Nord portent MP. Certains systèmes d’expédition et de taxation les traitent comme des destinations intérieures et d’autres comme des destinations internationales, ce qui signifie qu’un formulaire qui code en dur « US » comme seul pays acceptable à côté d’un code de territoire produira une combinaison que le reste de la pile rejette.
Il existe aussi un groupe d’États librement associés et de zones insulaires mineures qui apparaissent dans les jeux de données de référence avec leurs propres codes mais figurent rarement sur une étiquette d’expédition. Un générateur qui revendique une couverture américaine doit préciser s’il inclut seulement les cinquante États, ou les États plus DC, ou l’ensemble complet incluant les territoires. La différence compte lorsque vous testez une liste déroulante de juridictions plutôt qu’un champ d’adresse postale.
Pourquoi le code ZIP, la ville et l’État doivent aller ensemble
Le défaut le plus courant dans les données d’adresses américaines construites à la main est l’incohérence entre le code ZIP et le lieu auquel il est censé appartenir. Quelqu’un choisit un nom de ville plausible, tape un nombre à cinq chiffres plausible, et les deux n’ont aucun rapport entre eux. Rien, dans l’une ou l’autre valeur, ne paraît faux isolément, ce qui explique précisément pourquoi le défaut survit à la relecture et parvient jusqu’à une fixture.
Une sélection aléatoire indépendante aggrave la situation au lieu de l’améliorer. Si vous tirez une ville dans une liste de mille noms et un code ZIP parmi quarante mille possibilités, la probabilité que la paire soit authentique est négligeable. C’est la même défaillance que l’on retrouve dans tous les autres pays, qu’il s’agisse d’un district turc associé à la mauvaise province ou d’un code postal brésilien rattaché à la mauvaise municipalité.
Le correctif est structurel plutôt qu’éditorial. Décidez d’abord l’État, puis choisissez une ville et un code postal qui lui appartiennent tous les deux, et déduisez l’indicatif téléphonique de la même région. Un générateur qui procède dans cet ordre ne peut pas produire de paire inter-régions, ce qui explique pourquoi le générateur d’adresses de ce site construit chaque enregistrement à partir d’une seule région, de haut en bas. La relation plus large entre les champs est traitée dans l’article sur la cohérence des champs, et elle s’applique tout aussi directement aux colonnes d’adresse qu’aux colonnes d’identité.
Que signifie réellement la couverture derrière un générateur d’adresses américaines ?
Les chiffres de couverture sont faciles à gonfler et difficiles à interpréter, il est donc utile de savoir à quoi se rapportent les comptages. Sur ce site, le jeu de données américain couvre l’ensemble complet des divisions de premier niveau, environ deux cents localités peuplées, un peu moins de deux mille divisions administratives en dessous, et plus de treize mille codes postaux issus de la répartition réelle.
Ces nombres importent moins que les relations entre eux. Deux cents villes pour treize mille codes ZIP signifient que la localité moyenne possède de nombreux codes postaux, et un générateur qui échantillonne indépendamment la liste des villes et celle des codes ZIP produira encore des incohérences la plupart du temps. L’affirmation qui compte n’est pas le nombre de valeurs disponibles, mais le fait qu’une ville choisie arrive toujours avec un code postal qui lui appartient. Un outil capable de produire une paire correcte à partir de deux listes quelconques vaut plus qu’un autre qui détient une liste plus longue de valeurs non reliées, car seul le premier peut servir dans une assertion qui tiendra encore l’année prochaine.
Il est également utile de savoir à quoi servent les divisions situées sous le niveau de la ville. Dans de nombreux pays, le niveau intermédiaire est l’unité à laquelle les codes postaux s’attachent, ce qui explique pourquoi les jeux de données sont organisés hiérarchiquement plutôt qu’en listes plates. Un formulaire d’adresse qui ne demande jamais que ville, État et code ZIP écarte une couche que d’autres pays exigeront, et une suite de tests qui n’exerce jamais cette couche ne révélera pas la différence.
Quels défauts d’adresse vos formulaires devraient-ils intercepter ?
Les données générées sont utiles pour confirmer qu’un formulaire accepte une saisie correcte, et plus utiles encore pour confirmer qu’il rejette une saisie incorrecte. Les défauts qui méritent des cas de test sont ceux qu’un formulaire peut réellement détecter : un code ZIP trop court ou trop long, un code d’État absent de la liste, une ville qui ne correspond pas à l’État sélectionné, un désignateur d’unité plus long que ne l’autorise le champ, et une ligne de voie qui dépasse la largeur de colonne stockée.
Viennent ensuite les cas qu’un formulaire ne peut pas détecter et qu’il ne devrait donc pas prétendre détecter. Un code ZIP correctement formaté mais appartenant à une autre ville que celle saisie n’est pas quelque chose qu’une validation côté client peut résoudre, pas plus qu’un nom de ville orthographié différemment du nom officiel. Traiter ces cas comme des échecs de validation produit de faux rejets, ce qui est un résultat pire que d’accepter un enregistrement légèrement bizarre.
Un fichier de test productif pour les tunnels d’achat contient généralement une série d’enregistrements d’adresses américaines générées pour le chemin nominal, un petit ensemble de valeurs délibérément malformées pour le chemin de rejet, et un ou deux enregistrements aux formes inhabituelles mais légales, comme un code de territoire, un code ZIP étendu, et un nom de voie comportant un point ou une apostrophe. L’article sur les cas de test du formulaire d’adresse au paiement en énumère d’autres, et celui sur le format d’adresse international explique pourquoi un même champ peut être obligatoire dans un pays et absent dans un autre. Lorsqu’un champ rejette une valeur, assurez l’assertion sur le message autant que sur le rejet, car un message clair et un message générique échouent très différemment auprès des utilisateurs.
Les adresses américaines générées sont-elles livrables ?
Elles ne le sont pas, et aucun outil honnête ne devrait suggérer le contraire. Une adresse générée possède la structure correcte et les relations internes correctes, ce dont un analyseur de formulaire, un jeu de règles de validation ou un tunnel d’achat a besoin pour être exercé. Elle ne correspond à aucun bâtiment réel, elle n’est enregistrée au nom de personne, et elle ne sera acceptée comme destination par aucun transporteur.
Cette distinction est facile à brouiller lorsque les données paraissent ordinaires. Le numéro de rue est plausible, le nom de voie est un nom de voie réel utilisé quelque part dans le pays, et la ville existe vraiment. C’est la combinaison qui la rend synthétique, car cette maison précise dans cette rue précise ne correspond pas à l’enregistrement qui se trouve devant vous.
La conséquence pratique est une règle qui appartient aux notes du jeu de données plutôt qu’à un commentaire que personne ne lit : ces enregistrements existent pour tester des logiciels, ils ne doivent pas servir à de véritables expéditions, et ils ne doivent pas être présentés comme le lieu de résidence de quiconque. Si une capture d’écran de données de préproduction s’échappe d’un environnement, l’enregistrement devrait annoncer ce qu’il est.
Comment stocker le résultat pour le réutiliser plus tard
Stockez les adresses générées sous forme de fixtures dès qu’elles ont une utilité, et conservez les paramètres de génération à côté d’elles. Une fixture qui enregistre la clé d’identité, le pays et la graine utilisée pour la produire peut être régénérée des années plus tard, ce qui rend un vieux test de non-régression significatif plutôt que mystérieux. L’article sur les données d’adresse dans les fixtures de test couvre la mécanique.
Gardez les colonnes d’adresse séparées de tout le reste. Les noms de destinataires, les notes internes, les détails du prestataire et les instructions de livraison n’ont pas leur place dans la ligne de voie, car les mélanger gonfle sa longueur, casse les contrôles de caractères et produit des échecs qui ressemblent à des problèmes d’adresse alors que la vraie faute est un schéma qui a laissé passer du texte sans rapport.
Enfin, affirmez les relations au lieu de leur faire confiance. Un test qui vérifie que la ville appartient à l’État, et que le code ZIP appartient au même État, intercepte la plupart des données d’adresses américaines fabriquées à la main avant qu’elles n’atteignent une fixture partagée. Cette seule assertion fait plus pour la qualité des données que tout le soin pris en saisissant les enregistrements à la main.
Gardez une habitude supplémentaire à côté de celle-ci. Lorsqu’un enregistrement échoue à un contrôle de relation, corrigez le générateur plutôt que l’enregistrement, car une ligne corrigée à la main est une ligne qui sera écrasée lors du prochain rafraîchissement de la fixture. Un contrôle que personne ne peut satisfaire en modifiant un seul champ est un contrôle qui continue de fonctionner.
Chaque adresse produite de cette manière est une donnée de test synthétique à la structure correcte et aux relations internes correctes, et rien de plus. Ce n’est pas un lieu livrable, elle n’appartient à aucune personne ni organisation, et elle ne doit pas servir à usurper l’identité de quiconque, à prouver une résidence, à recevoir du courrier réel ou à franchir une étape de vérification.