Suite du sujet Ouvrir, ce n’est pas juste partager des données : simple, basique :
J’ouvre un autre sujet pour ne pas polluer l’initial 
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).
6 « J'aime »
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 ?
1 « J'aime »
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 »
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
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).
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.
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 !
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…
1 « J'aime »
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.
Voilà une réponse qui devrait suffire à convaincre quiconque de ne plus parler de “l’Etat” ou de “l’administration” comme un monolithe 
J’espère que ces divergences de stratégie ne sont pas une conséquence directe des rumeurs qui circulent
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.
1 « J'aime »
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 
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.
Je me permets d’en profiter pour reposer la question 
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?
Il manque toujours des lignes… plutôt que des colonnes
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 !
1 « J'aime »
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
1 « J'aime »
Bon, petit bilan sur les fichiers de mise à jour pour SIRENE v2019… c’est pas vraiment ça
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.
1 « J'aime »
Bonjour,
quelles sont les delta ?
Plus de maj par l’API qu’entre les fichiers mensuels ou inversement ?
Coté établissement ? Unité légale ?
Pour ma part j’ai constaté dans les fichiers mensuels des fausses différences qui ne portent que sur la date de maj. Selon l’INSEE c’est du à des mises à jour d’informations non publiées mais qui impactent tout de même la date de MAJ.
Bonjour, je suis nouvel utilisateur de l’API Sirene.
Je suis embarrassé car j’ai deux endpoint API différents :
- Celui de l’INSEE: https://api.insee.fr/entreprises/sirene/V3
- Celui de entreprise.data.gouv.fr : https://entreprise.data.gouv.fr/api/sirene/v3/
Le 2ème utilise sans doute les données du premier.
Mais je constate des différences notables :
- INSEE exige un token et pas l’autre
- INSEE limite à 30 requêtes par minute et l’autre 7 requêtes par seconde…
Que me conseillez-vous ?
Merci