En utilisant les métadonnées de data.gouv.fr et un script fait maison (en), j’ai pu vérifier à la volée la disponibilité* de toutes les ressources (fichiers) publiées ou simplement référencées sur le portail data.gouv.fr. Ce script récupère également le temps de réponse du serveur.
Les données de disponibilité sont mises à jour de temps en temps. Vous pouvez télécharger les données brutes sur data.gouv.fr.
- Au 6 août 2015 (+ 29 jours), 5106 ressources (+ 518) sur 53635 (+ 1177) sont indisponibles, soit 9.5 % (+ 0,8 %) (cette hausse n’est pas significative car le procédé de vérification a légèrement évolué, voir les notes de version)
- Au 8 juillet 2015, 4 588 ressources sur 52 458 sont indisponibles, soit 8.7 %
Accéder à l’interface de visualisation des données.
Les causes d’indisponibilité
J’ai identifié les causes suivantes :
- Certaines collectivités ont vu, un jour, leur portail open data indexé (ou « moissonné ») par l’équipe de data.gouv.fr. Malheureusement, cette indexation n’a pas été mise à jour faute d’automatisation du processus. Du coup, les liens vers les ressources ont changé petit à petit. Ce problème est difficile à quantifier, car je ne crois pas que la liste des collectivités dans ce cas de figure soit publique. Seule solution : les collectivités doivent soit migrer vers une solution logicielle compatible avec les moissonneurs de data.gouv.fr, soit développer le leur.
- Certaines URL sont mal formées (la liste, 41 ressources au 7 août 2015)
Temps de réponse des serveurs
Au 6 août, vous serez heureux de savoir que le temps de réponse moyen des serveurs était de 333 millisecondes. C’est pas mal !
Bon, on a quand même 649 ressources (1.2 %) à plus de 3 secondes et 170 (0.32 %) à plus de 10 secondes de temps de réponse.
Au prochain épisode, on verra quelles organisations ont les serveurs les plus rapides et les plus lents. Je peux déjà vous dire que celles qui ont choisi d’être hébergées sur data.gouv.fr (et pas juste référencées) ne seront pas loin du haut du tableau 😉
*Les erreurs suivantes sont considérées comme une indisponibilité :
- 401 AUTHORIZATION REQUIRED
- 403 FORBIDDEN
- 400 BAD REQUEST
- 404 NOT FOUND
- 405 METHOD NOT ALLOWED
- 410 GONE
- 500 INTERNAL SERVER ERROR
- 502 BAD GATEWAY
- 502 PROXY ERROR
- 503 SERVICE TEMPORARILY UNAVAILABLE
- 504 GATEWAY TIMEOUT
Excellente initiative !
Merci, ce n’est que le début 😉
Ton script est trop agressif pour la passerelle Inspire car tu déclenches simultanément des dizaines de transcodage à la volée, d’où les milliers d’erreurs 500.
J’ai modifié son API pour éviter de déclencher les transcodages en cas de requête HEAD, donc la prochaine passe de ton script devrait améliorer le comptage 😉
En tout cas bonne initiative !
J’étais passé à du GET pour éviter les erreurs 405 METHOD NOT SUPPORTED…
Je vais donc revenir à HEAD et ‘attraper’ les erreurs 405, qui auront un GET.
Tu diras pardon de ma part à la passerelle 😛
Super !
Je publie ces URL de transcodage pour réconcilier géomatique et Open Data, donc hélas je suis à la merci de temps de réponse du serveur source et du processus de transcodage 😉
Ah d’accord, je ne savais pas. next.inspire.sgmap.fr est de loin le domaine sur le lequel mon script a le temps d’aller se faire un café quand il y check une ressource 🙂 Je vois parfois des timeout après 1 minute.
Après modification du script, ça marche effectivement beaucoup mieux :
les URL répondent beaucoup plus vite, et avec moins d’erreurs. On fera
les comptes dans quelques heures.