Utilisation de l'open data en Prod dans un applicatif SI interne

#1

Bonjour à tous et toutes,

Est-ce que certaines ou certains d’entre vous utilisent des données en open data dans le fonctionnement en production d’un applicatif ou d’un SI interne dans leur administration, hors données du Service Public de la Donnée ?

Autant c’est une bonne nouvelle pour l’open data de voir son usage se généraliser et d’être considéré comme une source de données fiable, mais cela pose aussi la question (pas nouvelle) de la mise à jour et de la maintenance des schémas.

De mon côté, certains projets data, produits et développés en interne envisagent l’utilisation de plusieurs datasets en open data. Les prototypes concluants nous orientent désormais vers une pérennisation et une mise en production de ces projets. Mais voilà, les process internes n’autorisent ni les mises à jour manuelles, ni les connexions des SI internes directement vers internet pour une application en production.

Comment, avec ces contraintes, envisager l’utilisation de l’open data pour alimenter de nouvelles applications métier ?
Si la solution est de faire sauter les contraintes, quelle architecture garantissant la mise à disposition de données fraîches et suivant le même schéma serait à envisager ?

Je suis curieuse de vos retours d’expérience si vous l’avez fait chez vous !

1 Like
#2

Bonjour,

Merci pour cette question intéressante.

Voici notre expérience au centre de crise sanitaire de la DGS si cela peut être utile. Nous avons mis en place en avril un portail de données interne, dont certaines provenait de l’open data, en particulier de Santé publique France.

En pratique nous avons créé un dépôt GitLab par source de données. Ce dépôt comprend un fichier datapackage.json utilisé pour valider le schéma des tables (important pour limiter les problèmes en aval ! :slight_smile:), et indiquer où trouver les données et métadonnées (README.md, documents complémentaires, etc). Nous avons utilisé GitLab-CI pour programmer la récupération des données, éventuel prétraitement, et validation du schéma, avec l’intérêt de gérer ainsi les environnements d’executions (des agents gitlab-ci sur des VM azure) et les logs d’erreurs.

Les données elles-mêmes sont stockées dans le dépôt GitLab, sauf dans certains rares cas où elles étaient volumineuses et stockés dans des blobs azure. Les différentes sources sont ensuite centralisées par un autre projet, et mise à disposition sur un site avec d’autres fonctions qui permet notamment d’accéder aux données par API. Un fonctionnement avec pas mal d’étapes, pas très économe en ressources (copies de fichiers, environnement de calcul, etc), mais qui a permis de bien séparer les tâches et d’être très agile pour mettre cela en place en quelques semaines.

Cf cette présentation haut niveau et cette présentation plus technique (ça commence à 1h02, il faut entrer une adresse mail :confused:)

Je suis aussi intéressé par d’autres retours, car nous avons d’autres projets à la HAS où je suis maintenant, qui exploitent de l’open data pour des outils, avec des questions similaires qui se poseront.

6 Likes
#3

Bonjour,

J’aime bien l’approche décrite par @pajachiet. On imagine de notre coté un mode ou les plateforme de données permettraient d’enregistrer des webhooks : des que les données seraient mises à jour, cela pourrait déclencher des taches d’intégration continue qui prépareraient une nouvelle version des données adaptées à l’utilisation souhaitée.

1 Like
#4

Super intéressant, merci beaucoup pour le partage @pajachiet !
Je recommande d’ailleurs la vidéo à toutes les personnes intéressées par le Retex.

J’aime aussi beaucoup l’utilisation de Gitlab pour récupérer des données et les valider avec le package Python goodtables et Table Schema. (méthode utilisée aussi chez vous @johan si je ne m’abuse)

En réalité, côté gouvernance, les questions que cela pose sont multiples :

  • Quel engagement de service pour l’open data ?
  • Quelle ingénierie mettre en place côté producteurs de données pour garantir une sorte de maintenance opérationelle pour les données publiées ET réutilisées (si tel est le but du jeu) ?
  • Quel impact sur les modes de diffusion et donc les plateformes ? ( la proposition de webhooks est également intéressante @nicolas-bonnel )
  • Nécessité de diversifier les points d’accès ( un fichier téléchargeable bien sûr, cela fait partie des principes. Une API c’est bien aussi, et les deux, pour certains jeux de données, c’est le combo magique.)

Quoi qu’il en soit, il y a l’aspect coûts à prendre en compte. Assurer une qualité et une pérennité des données a un coût pour les producteurs, mais aussi pour les réutilisateurs.

Chez nous, on pourrait s’orienter vers un portail API interne un peu sur le modèle de la DGS pour mettre à dispo les données open data pour une utilisation en production métier dans le SI fermé. Ce qui veut dire que nous prenons en charge la mise en qualité éventuelle nécessaire, chaque changement éventuel de schéma qui pourrait affecter nos projets, etc…

Encore des arguments venant renforcer la nécessité de publier des données de qualité et suivant des standards et principes longuement discutés sur ce forum, et de continuer à sensibiliser les producteurs de données sur la posture à adopter : publier c’est bien, publier en pensant réutilisateurs et réutilisation, c’est mieux :slight_smile:

2 Likes
#5

Par ailleurs @pajachiet, côté gouvernance comment ça se passait sur ce projet ?

  • Qui validait la pipeline s’il y avait des modifs et que le dataset ne passait pas le script de goodtables ?
  • Qui reçoit les alertes de fail ?
  • Qui adapte les métadonnées si besoin ?
#6

Super si cela peut donner des idées.

Sur ce projet

  • l’API est une API de téléchargement de fichiers csv complets, avec juste une clé pour gérer les droits.
    • Pour des usages d’analyse de données, il y a (ici) peu d’intérêt à accéder par API à un sous-ensemble des données par API. Nous avions initialement besoin de filtrer certaines lignes selon des droits, et avions donc un backend Postgresql, avec des tables créés automatiquement depuis les schémas. Puis nous avons réussi à faire sauter cette contrainte et sommes passés à un pur stockage fichier dans des blobs azure, plus simple et plus stable.
  • En cas d’erreurs, des corrections sont apportés soit par les personnes à la source de l’erreur (cf ci-dessous), soit des personnes responsable de sources spécifiques, soit par des ingénieurs dédié au développement et maintient des sources de données.
  • En cas d’erreur de pipeline, la notification remonte aux mainteneurs du projet (avec un projet par source toujours), et au compte utilisateur ayant déclenché la pipeline.
    • Pour les pipelines sur de l’open data, les pipelines sont programmés via la fonction pipeline schedules de GitLab. On utilise pour cela un compte dédié avec une adresse mail qui est une boite fonctionnelle (ou liste de diffusion).
    • Pour des pipelines déclenchés par un commit - modification des métadonnées, du code de transformation, ajout par l’interface web d’un fichier de données -, le compte déclencheur est le compte ayant réalisé le commit.

Au final GitLab est vraiment puissant pour tout cela à bas coût (on a utilisé la version gratuite). Il manque une gestion séparés des données volumineuses, et l’interface est déroutante pour qui n’est pas habitué (+ cela nécessite d’embarquer pas mal de compréhension technique sur git, etc). Ceci dit on a réussi à faire contribuer des personnes pas techniques du tout sur l’ajout de fichiers manuels, ou la mise à jour régulière de métadonnées.

Je suis d’accord sur l’intérêt de webhooks sur les portails open data. Cela permettrait d’agir au moment des mises à jour, et pas de façon programmée parfois inutilement.

2 Likes