Les petits territoires et les codes spéciaux sont l’endroit où un modèle de données pays découvre quelle part de sa conception était une hypothèse. Le jeu de données fonctionne à merveille pour les lieux grands, non ambigus et bien documentés, puis une dépendance, un département d’outre-mer ou un code réservé arrive et quelque chose doit céder.
La valeur de ces cas est qu’ils sont peu coûteux à ajouter et exceptionnellement efficaces pour révéler des problèmes structurels. Un modèle qui les gère a généralement rendu explicites plusieurs décisions importantes.
Pourquoi l’hypothèse du code à deux lettres s’effondre-t-elle ?
Parce que les systèmes de codes ont été conçus dans des buts qui n’exigent pas tous un code à deux lettres pour chaque lieu. Le système à deux lettres est le plus familier, mais il existe aussi un système à trois lettres et un système numérique, et chacun existe pour résoudre un problème différent. Le système numérique en particulier est apparu pour éviter l’ambiguïté des lettres entre les langues.
Le codage des subdivisions ajoute une couche supplémentaire. Certains lieux n’apparaissent que comme subdivisions au sein d’une entité plus grande plutôt que comme entités à part entière, et certains apparaissent dans un système mais pas dans un autre. Un modèle qui traite le code à deux lettres comme la clé primaire du monde n’aura tout simplement pas de case pour ces lieux.
La conséquence pratique est que la clé primaire devrait être quelque chose que votre système contrôle, et non une valeur empruntée à une norme qui a ses propres décisions de portée. Le code normalisé devient alors un attribut — important, interrogeable, mais remplaçable lorsque la situation l’exige.
Que devrait-il arriver aux codes réservés et retirés ?
Les codes sont ajoutés, réservés pour un usage futur et retirés. Les codes retirés ne disparaissent pas du monde ; ils restent dans les enregistrements historiques, les documents archivés et les anciennes bases de données, et ils continueront d’arriver dans les imports longtemps après que le code a été retiré.
Un système doit décider quoi en faire. Les rejeter d’emblée casse la capacité de lire l’histoire. Les accepter silencieusement comme actuels invente un fait sur le présent. Le juste milieu praticable est de les accepter avec un marqueur indiquant qu’ils ne sont pas actuels, et de garder cette distinction visible partout où la valeur est affichée.
La même logique s’applique aux codes qui ont été réservés avant même d’avoir été utilisés. Un code réservé n’est pas une erreur ; c’est une lacune dans la numérotation que quelqu’un a choisie délibérément, et une règle de validation qui le rejette comme mal formé se trompe sur la norme plutôt que sur l’entrée.
Anciens noms et noms qu’un lieu se donne à lui-même
Les noms changent, et le changement est rarement simultané partout. Pendant une période, un nouveau nom est officiel tandis que l’ancien nom est encore ce que contiennent la plupart des documents, et pour les noms de lieux la forme locale et la forme internationale diffèrent fréquemment.
Trois sortes de noms doivent donc être distinguées. Le nom officiel actuel, le nom qui apparaît dans les anciens enregistrements, et le nom utilisé localement par les personnes qui y vivent. Un système qui n’en conserve qu’un des trois sera faux dans une direction ou une autre, et la direction dépend de qui lit.
C’est un endroit où le nettoyage des données peut les détruire. Une passe de normalisation bien intentionnée qui réécrit chaque enregistrement historique avec le nom actuel fait concorder l’archive avec le présent et cesse de la faire concorder avec elle-même.
Non applicable n’est pas la même chose qu’inconnu
Les petits territoires rendent cette distinction impossible à ignorer, car ce sont les cas où un champ ne s’applique véritablement pas.
Un champ qui ne s’applique pas signifie que le concept n’existe pas pour ce lieu, donc il n’y a rien à chercher et aucune valeur correcte. Un champ inconnu signifie que la valeur existe et n’a pas encore été établie. Ces deux cas produisent la même cellule vide et exigent des réponses opposées, et une liste de contrôle qui les consigne comme un seul état continuera de produire du travail impossible à terminer.
Lorsque le champ est un système de code postal, la différence est flagrante. Le guide des formats de codes postaux par pays couvre combien ce champ varie selon les lieux. La situation de chaque pays doit être classée avant qu’une validation ne la touche, car un système qui suppose qu’un champ existe marquera comme incomplète chaque entrée dépourvue de ce champ, et un système qui suppose qu’il peut ne pas exister acceptera des saisies réellement mauvaises.
Non pris en charge n’est pas la même chose que mal formé
C’est la distinction qui se perd le plus souvent, et c’est celle dont le coût visible pour l’utilisateur est le plus clair.
Une valeur qu’un système ne prend pas en charge n’est pas une valeur qui est fausse. Elle peut être parfaitement bien formée pour son propre lieu, dans un format que le système n’a simplement jamais appris à gérer. La signaler à l’utilisateur comme invalide lui dit qu’il a fait une erreur alors qu’en réalité la limitation est du côté de la réception.
| Ce que le système a trouvé | Ce qu’il sait | Ce qu’il devrait dire |
|---|---|---|
| Une valeur qui suit les règles qu’il implémente | La valeur est valide | L’accepter |
| Une valeur qui suit des règles qu’il n’implémente pas | La valeur peut très bien être valide | Ne peut être vérifiée ici |
| Une valeur qui enfreint des règles qu’il implémente | La valeur est invalide | Signaler le problème précis |
| Un champ qui n’existe pas pour ce lieu | Il n’y a rien à vérifier | Non applicable, pas manquant |
Fusionner les deux lignes du milieu est la défaillance courante. Cela produit un produit qui est avec assurance faux exactement là où ses connaissances sont les plus ténues, et les clients de ces lieux sont les premiers à le remarquer.
Pour les développeurs : rendez le troisième état exprimable
Un résultat binaire valide ou invalide ne peut pas représenter « non vérifié ici », donc le résultat de validation a besoin d’une troisième valeur qui se propage honnêtement jusqu’à l’interface. C’est un changement de type plutôt qu’un changement de règle, ce qui explique pourquoi on tend à le sauter sous pression et à le regretter plus tard.
Testez ensuite les cas limites à dessein. Incluez un lieu dont le code n’apparaît que dans un seul système, un code qui a été retiré, un lieu sans système de code postal, et un nom qui a changé. Ces quatre cas sont petits, rapides et exceptionnellement productifs, et ils méritent de rester en permanence dans la suite plutôt que d’être ajoutés à l’arrivée d’un ticket.
Le répertoire des pays et régions est un endroit raisonnable pour voir comment un pays et ses subdivisions sont affichés lorsqu’ils sont traités comme une entrée de premier ordre plutôt que comme une exception, et l’entrée des États-Unis montre à quoi ressemble une entrée pleinement spécifiée à côté d’une plus mince.
Les territoires, codes, noms et états de champs utilisés dans cet article sont des cas limites construits pour illustrer un problème de conception. Ce ne sont pas un jeu de données, ils ne représentent la classification réelle d’aucun territoire, et rien ici ne doit être cité comme un fait sur un lieu précis.
Prochaines étapes
Ajoutez les quatre cas limites ci-dessus à votre suite et voyez lesquels produisent une mauvaise réponse plutôt qu’une réponse non gérée. Le guide du choix des pays pour les données de test explique comment placer de tels cas délibérément dans un ensemble par défaut, et le guide des scénarios d’adresses transfrontalières couvre ce qui se passe lorsqu’un lieu comme ceux-ci apparaît comme l’un de plusieurs pays dans une même transaction.