La validation et la normalisation des adresses sont traitées comme une seule activité dans la plupart des projets, et cette confusion coûte réellement du temps aux équipes. L’une reformate une valeur pour que deux orthographes de la même adresse concordent ; l’autre tente de répondre à la question de savoir si l’adresse existe et peut être livrée. Elles utilisent des données différentes, échouent de manières différentes et — dans une suite de tests — méritent des assertions entièrement distinctes.
Cet article sépare les deux, explique pourquoi aucune autorité ne détient une liste mondiale complète d’adresses, et décrit ce qu’un système peut honnêtement affirmer après avoir exécuté l’une ou l’autre.
Ce que fait réellement la normalisation
La normalisation est une réécriture. Elle prend ce qu’un utilisateur a saisi et en produit une version canonique : une casse cohérente, des types de voie développés ou abrégés selon une convention unique, des mots directionnels normalisés, un séparateur cohérent, des espaces supprimés et un code postal écrit sous une forme convenue. Rien n’est vérifié. Une chaîne qui n’a jamais correspondu à un lieu réel se normalise aussi proprement qu’une chaîne correcte.
Sa valeur est la comparaison. Deux enregistrements qui décrivent le même lieu mais ont été saisis différemment deviennent identiques octet par octet après normalisation, de sorte que la déduplication, l’appariement et la recherche commencent à fonctionner. Elle stabilise aussi le stockage : une seule forme dans la base signifie que les consommateurs en aval cessent de réimplémenter les règles.
La normalisation est peu coûteuse, déterministe et sans danger à exécuter partout. Cette combinaison explique pourquoi elle a sa place à la première frontière que les données franchissent — le gestionnaire de formulaire, le script d’import, le point d’entrée d’API — et une seule fois. Normaliser de façon répétée dans différentes couches, c’est ainsi qu’une valeur finit par osciller entre deux orthographes.
Que cherche réellement à prouver la validation ?
La validation demande si une valeur est acceptable, et la réponse honnête dépend entièrement de la quantité de preuves dont vous disposez. Trois questions différentes se cachent derrière ce seul mot.
La première est structurelle : les champs obligatoires existent-ils, les caractères appartiennent-ils à l’ensemble autorisé, la longueur est-elle plausible. Cela ne nécessite aucune donnée de référence et peut se faire n’importe où.
La deuxième est relationnelle : le code postal tombe-t-il dans une plage utilisée par la région indiquée, le code d’État est-il cohérent avec lui, le pays s’accorde-t-il avec son code de subdivision. Cela nécessite des données de référence mais pas une base d’adresses, et cela intercepte une grande part des vraies fautes de frappe.
La troisième est existentielle : y a-t-il réellement un bâtiment à ce numéro dans cette rue. Cela nécessite un jeu de données local faisant autorité, et seuls certains pays en publient un assez complet pour y répondre.
La plupart des systèmes revendiquent la troisième et implémentent la deuxième. Ce n’est pas nécessairement faux, mais cela devrait être une décision consciente plutôt qu’un accident, car cela détermine ce que le message d’erreur peut honnêtement dire.
| Question | Ce qu’elle demande | Ce qu’il lui faut |
|---|---|---|
| Structurelle | Si les champs obligatoires existent, si les caractères appartiennent à l’ensemble autorisé et si la longueur est plausible | Aucune donnée de référence |
| Relationnelle | Si le code postal tombe dans une plage utilisée par la région indiquée, si le code d’État est cohérent avec lui et si le pays s’accorde avec son code de subdivision | Des données de référence, mais pas une base d’adresses |
| Existentielle | S’il y a réellement un bâtiment à ce numéro dans cette rue | Un jeu de données local faisant autorité, que seuls certains pays publient |
Existe-t-il une base mondiale d’adresses ?
Aucune qui soit complète, faisant autorité et à jour. Les opérateurs postaux entretiennent leurs propres données de distribution pour leurs propres territoires, selon leurs propres conditions, et beaucoup ne publient aucune liste au niveau de l’adresse. Là où des jeux de données nationaux existent, ils couvrent ce pays, dans la langue et la structure de ce pays. Il n’existe aucun registre unique qu’un fournisseur pourrait consulter pour décider si une adresse arbitraire, n’importe où sur Terre, existe.
Ce que font réellement les fournisseurs, en diverses combinaisons : ils utilisent leurs propres données de référence agrégées, apparient sur le code postal et les géographies administratives, appliquent des règles de plausibilité et — pour certains pays — utilisent un jeu de données local sous licence. Chacun de ces moyens est partiel. Un service qui déclare une adresse valide indique en général qu’elle paraît cohérente avec ce que le service sait, et un service qui la déclare invalide peut simplement manquer de couverture.
La conclusion pratique est que « adresse vérifiée » n’est pas une affirmation que votre système peut soutenir à l’échelle mondiale. « Structurellement valide et cohérente avec les données de référence dont nous disposons » est une affirmation qu’il peut soutenir, et c’est celle qui mérite de figurer dans la documentation.
Pourquoi l’ordre compte : normaliser, puis vérifier
Exécutez la normalisation en premier. Les vérifications de référence sont écrites contre une forme canonique, de sorte qu’une valeur non normalisée y échouera pour des raisons sans rapport avec son exactitude : un code postal dont le séparateur est ailleurs, un type de voie abrégé différemment, une différence de casse dans un nom de région.
L’ordre inverse est pire qu’inutile. Si la vérification de référence s’exécute d’abord et rejette la valeur, vous perdez la possibilité de corriger une chaîne simplement négligée, et l’utilisateur voit une erreur sur laquelle il ne peut pas agir. Si elle s’exécute d’abord et accepte, vous avez toujours besoin de la normalisation ensuite, de sorte que rien n’est gagné.
Une seconde règle d’ordre s’applique à la gestion des erreurs. Distinguez « impossible à analyser » de « en conflit avec les données de référence » et de « hors de notre couverture ». Les trois nécessitent des messages différents et des actions de suivi différentes, et les fondre en un seul échec est ce qui fait paraître la validation d’adresse arbitraire aux yeux des utilisateurs.
Pour les développeurs : règles, dérogations et jeux de tests
N’essayez pas de valider une adresse avec une seule expression régulière. La variation réside dans les parties où une expression régulière est la plus mauvaise — noms de rue, détails d’unité, écritures non latines — et la certitude réside dans les parties que vous pouvez vérifier contre une liste. Réservez les motifs aux contrôles de longueur et de caractères, et gardez les vérifications de référence dans des données.
Autorisez toujours une dérogation manuelle. Les données de référence sont incomplètes et parfois erronées, et une adresse réellement correcte que votre contrôleur ne reconnaît pas doit rester vivable. Journalisez la dérogation avec la valeur qui a été rejetée, afin de pouvoir dire si le contrôleur s’améliore ou s’il se contente d’agacer les gens.
Gardez la normalisation et la validation comme des étapes distinctes dans votre propre code, avec des noms distincts. Une fonction appelée address-check qui tantôt réécrit son entrée et tantôt la refuse est le genre de chose qui rend les bugs intraçables. Cette même séparation est ce qui permet d’exécuter la normalisation sur des enregistrements historiques tout en laissant la validation comme porte d’entrée, une distinction familière à quiconque construit des données d’adresse de test.
Pour une suite de tests, affirmez les deux comportements indépendamment : qu’une entrée donnée en désordre se normalise vers une chaîne canonique attendue, et qu’une paire de champs incohérente donnée est rejetée. Lorsque la liste de référence change, seul le second ensemble de tests devrait bouger.
Étapes suivantes
Écrivez, en une phrase, laquelle des trois questions votre système traite réellement aujourd’hui, et vérifiez si vos messages d’erreur en revendiquent davantage. Ajoutez ensuite un jeu de test pour une adresse correcte que votre contrôleur rejette, et décidez ce qui devrait lui arriver. Le générateur d’adresses produit des valeurs structurellement valides par construction, ce qui en fait une référence positive commode à côté des échantillons volontairement erronés que vous conservez. Structurellement valides est tout ce qu’elles sont : ces valeurs ne peuvent être livrées à aucune destination et ne prouvent rien sur la résidence. Pour un exemple détaillé d’une incohérence facile à détecter, voir les cas de test du formulaire d’adresse au paiement.