La fraîcheur des données pays est normalement rapportée comme un seul chiffre : la dernière fois que le jeu de données a été mis à jour. Ce chiffre est presque toujours trompeur, car un jeu de données ne se rafraîchit pas d’un seul geste.
Une table de pays typique est assemblée à partir de plusieurs sources, récupérées à des moments différents, couvrant des portées différentes. Une entrée peut avoir été corrigée le mois dernier tandis qu’une entrée voisine est restée intacte pendant des années, et une seule date en tête de fichier ne peut pas exprimer cette différence.
Qu’est-ce qui fait vieillir les données pays ?
Trois forces, et elles fonctionnent sur des horloges différentes.
La première est le changement du monde. Les noms changent, les devises changent, les divisions administratives sont réorganisées, et les codes sont ajoutés, dépréciés ou réservés. Aucun de ces événements ne s’annonce à un système qui ne les surveille pas.
La deuxième est le changement de la source sous vos pieds. Même une source qui reste exacte peut réviser sa propre présentation, retirer un champ ou commencer à inclure des entités qu’elle omettait auparavant, si bien qu’un rafraîchissement peut importer un changement que personne n’a demandé.
La troisième est la dérive de portée. Une règle écrite pour les entités qu’un jeu de données contenait à l’époque devient discrètement fausse lorsque cet ensemble grandit, et l’erreur apparaît comme une exception plutôt que comme une défaillance.
Seule la deuxième des trois est visible dans un journal de rafraîchissement. Les deux autres sont la raison pour laquelle un jeu de données peut être rafraîchi ponctuellement et pourtant rester faux.
Consignez la source, la date de récupération et la portée séparément
Trois attributs expliquent la provenance d’une valeur, et les réduire à un seul horodatage détruit la capacité de raisonner à son sujet.
| Attribut | La question à laquelle il répond | Pourquoi il ne peut pas être déduit |
|---|---|---|
| Source | D’où vient cette valeur | Deux sources peuvent diverger, et la divergence est une information |
| Date de récupération | Quand cette valeur a été obtenue | La récupération n’est pas la même chose que la date à laquelle la source elle-même a changé |
| Portée | Quelles entités et quels champs cette valeur couvre | Une source peut faire autorité pour les noms mais rester muette sur les divisions |
L’attribut de portée est celui qui manque le plus souvent et le plus coûteux à reconstituer. Sans lui, un champ vide est ambigu : la source a dit qu’il n’y avait rien, ou la source n’a jamais été interrogée sur ce champ.
Stocker les trois ensemble rend aussi les conflits lisibles. Lorsque deux sources ne sont pas d’accord sur un nom, un lecteur peut voir quelle valeur vient d’où et quand, et la résolution devient une décision fondée sur des preuves plutôt qu’un tirage au sort.
Trois stratégies de mise à jour et ce que chacune coûte
Il existe globalement trois façons de maintenir les données pays à jour, et elles échangent l’effort contre la surprise de manière prévisible.
Tirer selon un calendrier est le plus simple : rafraîchir tout périodiquement, que quelque chose ait changé ou non. C’est facile à raisonner et facile à oublier, car une tâche planifiée qui échoue en silence ne produit aucun symptôme visible avant que les données soient fausses.
Tirer sur signal est plus efficace : surveiller les avis de changement émis par les organismes qui publient les codes et les noms, et rafraîchir quand quelque chose est réellement annoncé. Cela réagit vite et dépend de quelqu’un qui lit les avis, ce qui signifie qu’il échoue précisément pendant les périodes où personne ne regarde.
Rafraîchir à la demande est le moins spectaculaire et souvent le plus fiable pour un petit jeu de données : mettre à jour une entrée spécifique lorsqu’une question à son sujet se pose, et consigner qui l’a demandé et pourquoi. Cela garde les données honnêtes sur leurs propres lacunes, au prix de ne pas couvrir les entrées que personne n’a encore remises en question.
La plupart des systèmes réels finissent par combiner les trois, avec un calendrier lent comme plancher, des signaux pour les parties qui évoluent vite, et des correctifs ciblés pour les plaintes individuelles. Ce qui compte est que la combinaison soit délibérée et que le résultat soit consigné par entrée plutôt que par version.
Que doit préserver un instantané historique ?
Un instantané n’est utile que s’il peut répondre à une question sur un moment passé, il doit donc préserver plus que les valeurs.
Préservez les valeurs telles qu’elles étaient, la date qu’elles décrivaient, et l’état de la source qui les a produites. Un instantané qui ne conserve que les valeurs ne peut pas expliquer pourquoi le nom d’un pays a changé entre deux versions, et un instantané qui ne conserve que la date ne peut rien reproduire.
Il y a une limite à fixer délibérément. Garder chaque champ pour toujours est coûteux et rarement consulté ; garder les valeurs modifiées, avec attribution, suffit généralement à répondre aux questions qui sont réellement posées — quel nom était en vigueur pendant une période donnée, et quand un code a cessé d’être utilisé.
Le test le plus précieux pour un instantané est celui qui reconstruit un enregistrement à une date passée et le compare à ce que le système a produit à l’époque. Si les deux divergent, l’instantané est un journal intime plutôt qu’un enregistrement.
Pour les développeurs : gardez la provenance sur la valeur, pas sur la version
Stockez la source, la date de récupération et la portée à côté de chaque valeur, ou à côté de chaque groupe de valeurs qui les partagent. Toute question sur la fiabilité devient alors une requête plutôt qu’un exercice de mémoire.
Lorsqu’une valeur n’a aucune source consignée, traitez cela comme un état à faire remonter plutôt qu’une valeur par défaut à supposer. Le guide de la liste de contrôle de couverture des données pays détaille les trois états qu’un champ peut occuper et pourquoi une inconnue doit rester visible ; la fraîcheur n’est que la quatrième dimension appliquée à la même table.
Pour les codes eux-mêmes, les avis de changement publiés sont les déclencheurs qui font autorité, et le guide des codes ISO de pays et de subdivisions couvre la manière dont les systèmes de codes s’articulent les uns avec les autres. Gardez le répertoire des pays et régions comme l’endroit neutre vers lequel orienter les lecteurs qui veulent voir comment les noms et les codes sont présentés ensemble plutôt que lire sur la maintenance.
Les noms de sources, les dates de récupération et les étiquettes de version utilisés comme exemples ci-dessus ne sont qu’une notation illustrative. Ce ne sont pas des références au contenu, au calendrier ou à la couverture d’un jeu de données particulier, et ils ne décrivent aucun processus de mise à jour réel appartenant à une organisation.
Prochaines étapes
Choisissez une entrée de pays et essayez d’écrire de mémoire sa source, sa date de récupération et sa portée. Là où vous n’y parvenez pas, l’information n’est pas stockée, et le prochain désaccord sur cette entrée sera tranché par une opinion. Le guide de la mise à l’échelle des données de test entre pays montre comment un ensemble d’entrées à la provenance inégale peut quand même servir à générer une population de test cohérente.