INSEE et SIRENE... changements à venir


(Christian Quest) #1

Suite du sujet Ouvrir, ce n’est pas juste partager des données : simple, basique :


Ouvrir, ce n’est pas juste partager des données : simple, basique
(Christian Quest) #2

J’ouvre un autre sujet pour ne pas polluer l’initial :wink:

La tendance à obliger de passer par des API est un réel problème. Le prochain recul dans le genre c’est l’INSEE qui propose désormais une API pour interroger SIRENE et va du coup suspendre la diffusion de certains fichiers téléchargeables (comme les mises à jour quotidiennes).

Donc depuis cet été l’INSEE propose une API pour interroger la base SIRENE.

Ce qu’on gagne:

  • une API (mais la dépendance qui va avec)
  • l’accès aux historiques, c’est à dire les états passés d’une entreprise ou d’un établissement
  • l’accès aux entreprises et établissement aujourd’hui fermés

Ce qu’on perd:

  • pas mal de variables ne sont plus disponibles, certaines se retrouvent par croisement avec le COG ou NAF, mais pas toutes
  • la mise à jour d’une base répliquée, locale n’est pas aussi simple que ça l’était avec les CSV
  • le nombre d’appels à l’API est limité (30 par minute)
  • il faut maintenant gérer des login/pass et des tokens

Les fichiers CSV de mise à jour quotidienne vont disparaitre.
Les fichiers CSV “stock” mensuels devraient évoluer dans leur contenu (c’est pas bien clair et surtout pas documenté à ce jour à ma connaissance).

L’impact pour les réutilisateurs (certains “historiques”) risque malheureusement d’être important.

J’essaye de mon côté de voir si je peux sortir depuis l’API un CSV à peu près équivalent aux anciens, afin de proposer une version géocodée qui ne change pas trop, mais c’est pas aussi simple. Toutes les variables/champs ont changé de nom et il n’est pas évident de s’y retrouver.

Bref, je pense que vous aurez compris que je ne suis franchement pas heureux que l’INSEE profite de l’ajout d’un nouvel outil (l’API) pour débrancher quelque chose qui depuis des années était stabilisé. C’est de plus assez peu conforme à l’esprit du Service Public de la Donnée et aussi à la lettre (le décret de 2017).


(Nicolas Bonnel) #3

Merci Christian pour ces précisions et je partage ton constat.

Je suis navré de voir ce genre de chose arriver : nous avons de notre coté construit une API entreprise enrichies avec le Bodacc et Infogreffe. Le pivot pour agréger toutes ces données est le code SIRET et la base Sirene occupe donc une place centrale. La base est mise à jour quotidiennement à partir des fichiers CSV. Et nous ne pourrons bientôt plus la maintenir…

On s’était préparé à devoir faire évoluer nos outils par rapport à Infogreffe ou le Bodacc car nous n’avions aucune garantie sur le format de sortie et même la pérennité à leur accès. On pensait par contre qu’il n’y avait pas de problème avec Sirene car elle faisait partie du SPD. J’associe dans ma tête ces jeux de données à une infrastructure de la donnée sur laquelle on peut se reposer. La j’ai l’impression que l’on va rapprocher les rails d’un mètre l’un de l’autre et que mes trains ne pourrons plus circuler dessus …

Y aurait t-il un moyen de demander à ce que le mode de distribution soit conservé ou le changement est inéluctable et nous pourrons mettre a la poubelle des dizaines de jours de boulot ?


(Samuel Goëta) #4

C’est très étonnant par par rapport à l’évolution de la jurisprudence CADA qui prévoit désormais que « la consultation sur Internet de documents librement communicables ne saurait être subordonnée à une procédure de demande d’accès impliquant une autorisation préalable de l’administration »


(Samuel Goëta) #5

Je suis tombé via le Github d’Etalab sur https://entreprise.data.gouv.fr/

La beta laisse entendre que les données pourront toujours être téléchargées depuis data.gouv.fr


(Joël Gombin) #6

techniquement l’API de l’INSEE ne suppose pas d’ “autorisation préalable de l’administration”. Mais je suis d’accord avec @nicolas-bonnel : c’est gênant au regard de l’esprit et de la lettre du SPD. Curieux de savoir ce qu’en pense Etalab (poke @RomainTales @schignard et les autres).


(Joël Gombin) #7

oui mais ce que dit @cquest c’est que le fichier de mise à jour quotidien ne serait lui plus disponible ?
ce qui est bizarre avec ce projet entreprise.data.gouv.fr c’est que l’Etat développe son API sirene en parallèle à l’INSEE. Je serais curieux de connaître le degré de concertation et collaboration entre les deux.


(Christian Quest) #8

entreprise.data.gouv.fr c’est autre chose, une autre façon de diffuser les données SIRENE, voire provenant d’autres sources et cela s’appuie aussi sur les données INSEE diffusées dans le cadre du SPD.

L’ouverture de compte ne va pas du tout dans le sens de l’accès libre.
L’usage d’un token (à renouveler) alourdit l’accès, mais peut se comprendre dès lors qu’on passe sur une API et donc des ressources en CPU et pas uniquement en bande passante.

Ce type de changement important dans le mode de diffusion des données du SPD pose un sérieux problème car ce ne sont plus “des données sur lesquelles vous pouvez compter”, slogan affiché du SPD à son ouverture.
La stabilité est nécessaire pour que les réutilisateurs, qu’ils soient privés ou publics, n’aient pas à revoir trop régulièrement le fonctionnement de leur système d’information.

Là, clairement et malheureusement, ce n’est pas le souci de l’INSEE qui va semble-t-il aussi changer le contenu des fichiers mensuels, mais qui n’a publié aucune documentation ou fichier d’exemple pour que l’on puisse anticiper ces changements sans clairement communiquer sur les dates des changements.

Même quand il est respecté, le delais de 3 mois prévus par le décret est déjà très court pour s’adapter vu la lourdeur de beaucoup de systèmes d’information rarement agiles !


(Tales Romain) #9

Je ne peux que souscrire aux propos de Christian…le changement de périmètre d’une base issue du SPD remet en question la pérennité de l’ensemble des données issues du SPD…


(Christian Quest) #10

En attendant… la version géocodée du dernier stock (à fin août) est dispo sur http://data.cquest.org/geo_sirene/last/

On verra demain ce qu’il en est pour les mises à jour.


(Samuel Goëta) #11

Voilà une réponse qui devrait suffire à convaincre quiconque de ne plus parler de “l’Etat” ou de “l’administration” comme un monolithe :slight_smile:

J’espère que ces divergences de stratégie ne sont pas une conséquence directe des rumeurs qui circulent


(Colin Maudry) #12

Je viens de recevoir le mail suivant de l’INSEE (le gras est de mon fait) :

Bonjour,

Vous avez souscrit à l’API Sirene sur le catalogue des API de l’Insee.

Nous vous informons qu’une nouvelle version (version 3.4) sera mise en ligne d’ici mi-septembre.

Cette nouvelle version ne comporte pas d’évolution sur les fonctionnalités d’API Sirene. Elle prépare uniquement la mise en ligne sur data.gouv.fr des fichiers contenant les données diffusées par API Sirene.

Nous restons à votre disposition pour toutes précisions, vous pouvez nous contacter via le formulaire de contact du catalogue, onglet contact (https://api.insee.fr/catalogue/site/themes/wso2/subthemes/insee/pages/help.jag).

L’équipe de diffusion Sirene

À voir de quels fichiers ils parlent, ce serait bien que le delta quotidien soit publié sur datagouvfr.


(Christian Quest) #13

L’INSEE a publié le stock de la base SIRENE à fin septembre selon le nouveau format de diffusion téléchargeable (CSV). Par contre, plus de CSV de mise à jour quotidiens :frowning:
Les fichiers au format actuel (stock et mise à jour) seront publié jusque fin janvier 2019.

Voir ici: https://www.data.gouv.fr/fr/datasets/5b7ffc618b4c4169d30727e0/

J’ai mis à jour mes scripts de géocodage pour en faire une version géocodée, qui est disponible sur http://data.cquest.org/geo_sirene/v2019/AAAA-MM/

Quoi de neuf ?

Seul le fichier StockEtablissement est traité, vu que c’est le seul fichier parmis les 4 diffusés par l’INSEE qui contient des adresses.

Les changements:

  • les fichiers départementaux sont désormais compressés en gzip (plus de 7z)
  • le stock national est disponible pour les établissements Actifs et pour l’ensemble des établissements (Actifs ou Fermés)
  • un traitement supplémentaire prends en compte les anciennes communes qui n’existent plus (fusions) et leur fait correspondre le code INSEE actuel afin de permettre le géocodage. Certaines “adresses” ne sont plus géocodables (ex: “GALERIE MARCHANDE MAMMOUTH” vu que le dernier Mammouth a fermé en 2009)

Fichiers générés:

  • StockEtablissement_geo.csv.gz : fichier national complet (29 millions)
  • StockEtablissementActif_geo.csv.gz : fichier national des établissements Actifs (11 millions)
  • geo_siret_DDD.csv.gz : stock complet pour un département (et découpé par arrondissements de Paris)
  • communes/{codeINSEEcommune}.csv : stock complet pour une commune
  • logs.tgz : logs complet de géocodage (un fichier par département)
  • stats.json : statistiques finales du géocodage par département

N’hésitez pas à me signaler toute anomalie, ça sent encore un peu la peinture fraîche même si la partie géocodage est très proche de ce qui a été fait jusqu’à maintenant.


(Benjamin Ooghe-Tabanou) #14

Je me permets d’en profiter pour reposer la question :wink:
Ce nouveau stock contient-il toutes les lignes ? Ou les entreprises ayant coché la case “ne pas partager les informations personnelles” sont toujours entièrement retirées du fichier plutôt qu’avec les colonnes correspondantes vides?


(Christian Quest) #15

Il manque toujours des lignes… plutôt que des colonnes :frowning:


(Christian Quest) #16

Vu qu’il y a pas mal de réutilisateurs de la version géocodée de la base SIRENE, j’ai tenté de regénérer les fichiers de stock CSV format 2017 à partir des nouveaux stocks (2019).

C’est “retrosirene” et c’est sur https://github.com/cquest/retrosirene

Le premiers fichiers “beta” issus de cette moulinette sont disponibles sur http://data.cquest.org/geo_sirene/beta/

N’hésitez pas à me remonter des anomalies, il y en a forcément !


(Christian Quest) #17

Comme l’INSEE va stopper fin janvier la diffusion de fichiers téléchargeables permettant de maintenir à jour une copie de la base SIRENE, je teste la génération de ces fichiers quotidiens à partir de données extraites depuis leur API.
Ces fichiers ne sont pas géocodés, c’est l’étape suivante à laquelle je vais m’attaquer.

http://data.cquest.org/geo_sirene/v2019/quotidien/

Pour chaque jour, 3 fichiers sont pour l’instant générés:

  • un json qui contient l’ensemble des unités légales et établissements avec tout leur historique
  • un CSV des unités légales (mêmes colonnes que les CSV de stock mensuels publiés par l’INSEE sur data.gouv)
  • un CSV des établissements (mêmes colonnes que les CSV de stock mensuels là aussi)

Exemple:

  • 2018-10-22-sirene.json.gz (unités légales et établissements en json)
  • 2018-10-22-siren.csv.gz (unités légales en CSV)
  • 2018-10-22-siret.csv.gz (établissements en CSV)

Pour conserver un stock mensuel à jour, il suffit d’intégrer par date croissante ces fichiers.

Merci d’avance pour vos retours, l’idée étant de pérenniser tout ça.

J’attends le prochain stock début novembre pour valider que la mise à jour via cette voie est bien complète…

Les scripts utilisés sont là : https://github.com/cquest/geocodage-spd/tree/master/insee-sirene/apiv3


(Christian Quest) #18

Bon, petit bilan sur les fichiers de mise à jour pour SIRENE v2019… c’est pas vraiment ça :frowning:

J’ai comparé les stocks d’octobre et novembre et les mises à jour quotidiennes récupérées via l’API par mes scripts quotidiens laissent des “trous”. Le problème n’est pas très clair, peut être lié à des effets de bord sur les dates de dernier traitement, potentiellement antidatées.

Je tente donc de ratisser plus large en récupérant les entreprises et établissements sur une fenêtre glissante d’un mois… et il faut attendre le stock de décembre pour savoir si c’est ok. :frowning: