Utiliser des sources officielles stables

[Pierlou]

Pour la mise à jour des données de référence (codes INSEE, postaux, noms des communes, etc.), plusieurs solutions sont possibles :

• mises à jour manuelles régulières (scripts inclus dans le package ?)
• mises à jour automatiques régulières (github action ?)
• fetch en temps réel (peut-être un peu plus lent selon l'architecture choisie ?)

Dans tous les cas, il serait bon de trouver des sources officielles et stables. Pour les communes/départements/EPCI/régions cela pourrait être : https://geo.api.gouv.fr/decoupage-administratif

Maintenant que le système est rôdé (avec csv-detective 0.7.2) cela pourrait être une piste d'amélioration 🚀

[pierrecamilleri]

Merci !

Effectivement, mais il y a une question sous-jacente : a priori, il me semble souhaitable de garder toutes les versions pour pouvoir en référencer une plutôt qu'une autre.

En effet, sinon, chaque nouvelle version des données introduit un breaking change (des fichiers qui étaient valides et qui peuvent ne plus l'être avec des nouvelles données).

Je propose donc d'avoir un moyen de versionner, par exemple de pouvoir indiquer Region.is_valid("Limousin", cog = "2005") (ou alternativement : version = "cog2005") pour préciser un code officiel géographique. Dans les schémas, ça pourrait se manifester comme ça :

{
 "frFormat": {
    "name": "region",
    "cog": "2005"
  }
}

Se pose la question de si on veut supporter une valeur par défaut, ou une fonctionnalité qui permet d'utiliser cog = "latest". Je suis plutôt d'avis contraire, car 1. ça nous engage et c'est difficile de revenir en arrière (alors qu'on peut toujours l'ajouter plus tard si le besoin est confirmé), 2. ça génère des schémas qui n'ont pas un comportement stable dans le temps et donc toute mise-à-jour de "frFormat" peut entraîner des régressions et 3. ça encourage des mauvaises pratiques de ne pas se poser la question de quel référentiel géo utiliser.

Pour la mise à jour des référentiels disponibles, je ne ferai pas de fetch en temps réel, qui pose des problématiques de performance et de mise en cache, de possibilité d'utilisation hors connexion, etc. qui me semblent pas indispensable pour le moment. J'opterais dans un premier temps pour une mise-à-jour manuelle avec scripts, et on pourra toujours automatiser sur cette base à l'avenir.

[Sarrabah]

La pull request #21, déjà mergée, se concentre exclusivement sur les Codes Officiels Géographiques des années 2023 et 2024. Ces codes sont mis à jour manuellement, ce qui inclut l’actualisation des fichiers contenant les valeurs valides et l’ajout des noms correspondants dans notre classe enum Millesime pour définir l’année de publication.