Merge sources/* to domains.csv

[JulienPalard]

TODO :

• [x] Prendre en compte les commentaires de sources/*.txt (lignes avec des #).
• [x] Mettre à jour check.py
• [x] Mettre à jour sort.py
• [x] Mettre à jour le README.
• [x] Mettre à jour les scripts d'insertion.

Alors, j'ai pris une liberté : j'ai mergé sources/* dans domains.csv plutôt que créer encore un nouveau fichier (et oui je suis toujours ouvert à la discussion). Les « colonnes » sont donc :

$ head -n 1 domains.csv 
name,http_status,https_status,SIREN,type,sources,script

J'ai versionné scripts/convert.py qui fait la convertion, je ne pense pas que ce soit nécessaire.

J'ai surtout besoin de relecture côté « choix des mots », dans convert.py j'ai :

    pretty_names = {
        "academies.txt": "Académie",
        "ambassades.txt": "Ambassade",
        "aphp.txt": "APHP",
        "centre-de-gestion.txt": "Centre de gestion",
        "collectivites.txt": "Collectivité",
        "communes.txt": "Commune",
        "conseils-departementaux.txt": "Conseil départemental",
        "conseils-regionaux.txt": "Conseil régional",
        "epci.txt": "EPCI",
        "etablissements-scolaires.txt": "Établissement scolaire",
        "gouvfr-divers.txt": "Gouvernement",
        "hopitaux.txt": "Hôpital",
        "mdph-mda.txt": "MDPH ou MDA",
        "nongouvfr-divers.txt": "",
        "prefectures.txt": "Préfécture",
        "sante-fr.txt": "Santé",
        "universites.txt": "Université",
    }

J'ai aussi :

    return "Ajout manuel de " + get_commit_author(commit)

Je pense que tout le monde ne veut pas voir son nom ici répété des milliers de fois, moi le premier, mais je manquais d'inspiration pour les ajouts manuels. On peut se contenter de « Ajout manuel », l'auteur est dans le git log de toutes façons ?

Pour expérimenter j'ai implémenté :

On peut imaginer une option --json si un jour quelqu'un veut un export json, qu'on est pas obligé de versionner.

[mfaure]

Grandiose !

Les noms des catégories me semblent OK. Il y en aura d'autre à venir (exemples : office de tourisme, musée)

Voici quelques retours complémentaires :

• j'ai découvert en surfant "manuellement" sur quelques sites de communes, que certaines ont avec leur EPCI le même site (même domaine, même URL). Ce sont plutôt de petites agglo (je n'ai pas noté les noms), mais j'en ai remarquées plusieurs. Conséquence : soit le contributeur fait un choix, soit on autorise un domaine à appartenir à plusieurs types différents. (Je n'ai pas encore d'avis sur la question)
• Le code couleur est pratique pour faire un retour d'information, mais ce principe (utiliser une couleur pour fournir une information) n'est pas accessible au sens RGAA. Suggestion : conservons les couleurs c'est pratique, mais ajoutons un symbôle textuel pour indiquer ladite info. Bonus, ça permet des filtrer à coup de sed, awk et consort.

Autre question : on passe à une structure en JSON (au lieu de CSV) ? Dans un deuxième temps ?

[JulienPalard]

@villesinternet propose :

Avez vous vu ma suggestion concernant le choix du numéro de Siren plutôt que le numéro de Siret ? (Plus facile à trouver, plus généraliste pour identifier une entité juridique que le Siret qui est associé à chaque établissement physique, et meilleur pivot car invariable et unique).

[JulienPalard]

@villesinternet Je ne comprends pas trop la proposition d'utiliser le SIREN plutôt que le SIRET (spoiler : je n'ai aucune connaissance de comment ces numéros sont utilisés par les organismes publics).

Ma compréhension est que le SIRET commence par le SIREN. Donc si on a l'un, on a l'autre ?

meilleur pivot car invariable et unique

Si le SIRET commence par le SIREN, et que le SIREN est unique, le SIRET l'est aussi ?

[mfaure]

Il y a une relation 1-N entre SIREN et SIRET. Un établissement (public ou non) possède un seul SIREN, qui correspond à l'entité juridique. À ce SIREN sont associés un ou plusieurs SIRET. Un SIRET est associé à une adresse.

Cas typique : l'entreprise X possède un SIREN 123 456 789. L'adresse "principale" (disons Bordeaux) possède un SIRET (5 chiffres ajoutés au SIREN) : 123 456 789 00001. Si l'entreprise X possède d'autres bureaux, disons à Annecy, ces derniers ont un autre SIRET 123 456 789 00002 (mais les 9 premiers chiffres du SIREN restent les mêmes puisqu'il s'agit de la même entreprise).

Il en va de même pour les établissements publics.

Est-ce que cela répond à ta question @JulienPalard ?

[villesinternet]

Il y a une relation 1-N entre SIREN et SIRET. Un établissement (public ou non) possède un seul SIREN, qui correspond à l'entité juridique. À ce SIREN sont associés un ou plusieurs SIRET. Un SIRET est associé à une adresse.

Effectivement "qui peut le plus peut le moins" : on peut déduire le SIREN depuis un SIRET. Le contraire est moins évident : lorsqu'on ne connaît que le SIREN de l'entité juridique derrière un domaine (site/MX...), mais que ce domaine ne correspond pas précisément à un lieu "avec adresse" de cet organisme, le choix d'un SIRET plutôt qu'un autre devient arbitraire et n'a pas forcément de sens. (Exemple : le site internet commercial ou le domaine MX d'une entreprise concerne l'ensemble de l'entité juridique / des salariés, pas seulement tel ou tel bureau de cette entreprise.)

Je vois donc trois possibilités :

1) On retient uniquement le SIREN à 9 chiffres comme objectif d'identification des entités juridiques associées aux domaines. Avantages : la métadonnée est plus simple à trouver et plus stable dans le temps. Par ailleurs, l'information est suffisante pour distinguer les types d'organismes (typologie par code NAF/APE par exemple) ce qui est l'objectif principal de ce champ. Inconvénient : on perd en précision lorsqu'il y a bien une logique de correspondance précise entre un lieu "physique" et un nom de domaine

2) On conserve un champ SIRET à 14 chiffres Avantage : information plus précise quand c'est pertinent Inconvénient : information parfois plus difficile à trouver ou moins pertinente que le seul SIREN (car "tous les établissements de l'entité juridique sont concernés"). Il faudrait déterminer une convention pour faire la sélection d'un SIRET correspondant au SIREN connu (a priori ce serait l'établissement siège qu'on chercherait), mais la "précision" de l'information serait alors parfois artificielle. Par ailleurs, l'actualisation du jeu de donnée promet plus de travail car chaque déménagement d'un établissement conduit à un changement de SIRET (alors que le SIREN est permanent et invariable tant que l'entité juridique continue d'exister, quelles que soient les adresses de ses établissements).

3) On conserve un champ "SIRET" qui peut être à 9 chiffres ou 14 chiffres (ou on crée deux champs, SIREN et SIRET...) : Avantage : On met l'information précise lorsque le SIRET est connu et que c'est pertinent, on se contente du SIREN dans les autres cas. Inconvénient : le schéma de données, ou le traitement des données, deviennent plus complexe.

Par sobriété je pencherai plutôt vers la solution 1. Mais pas de souci pour opter pour la 2 ou la 3 si quelqu'un voit un intérêt particulier à avoir le SIRET pour viser certaines réutilisations. (Pardon pour le pavé !)

Ressources :

• Correspondance COG / SIREN des communes sur Banatic : https://www.banatic.interieur.gouv.fr/V5/fichiers-en-telechargement/fichiers-telech.php / https://www.banatic.interieur.gouv.fr/V5/ressources/documents/document_reference/TableCorrespondanceSirenInsee.zip
• Recherche du SIRET de l'établissement siège depuis un code SIREN possible depuis les fichiers téléchargeables sur https://www.sirene.fr/sirene/public/accueil

[JulienPalard]

Merci pour vos explications !

[JulienPalard]

Rebasé, je suis preneur de vos retours.