Cahier des charges de la bibliothèque de documents Ma Dada

1

Salut tout le monde,
Dans notre 4ème milestone NGI, on doit mettre en place une bibliothèque/archive de documents reçus sur Ma Dada. Le but étant de faciliter la recherche, exploration de ces documents qui sont aujourd’hui seulement accessibles comme des PJ dans des emails.
Dans l’esprit, on voudrait une sorte de data.gouv avec ce que madada contient. Le but n’étant pas de réinventer la roue, mais plutôt réutiliser un outil existant et l’intégrer avec alaveteli, en espérant pouvoir le rendre utile aux autres plateformes par la suite.

Voilà ce que j’ai en tête pour ce système, mais je serais preneur de vos idées/commentaires. Et si vous avez des outils en tête qui pourraient correspondre à nos besoins, ajoutez les en commentaire aussi!

Cahier des charges pour ce système de « stockage » des documents

  1. Le but est de collecter les PJ reçues dans les réponses aux demandes (ou envoyées via wetransfer et compagnie). Cela doit être fait aussi automatiquement que possible afin de réduire la charge de travail manuel.
  2. Les documents ajoutés au système doivent pouvoir être filtrés:
    • automatiquement: par exemple ignorer les fichiers d’un certain type, ou d’une taille inférieur à X (typiquement pour ne pas enregistrer les logos des mairies)
    • à la main: on doit pouvoir facilement supprimer ou cacher un document dans l’archive pour quelque raison que ce soit (par exemple: RGPD, doc non communicable…)
  3. Les documents doivent pouvoir être automatiquement taggés au moment de leur archivage, par exemple:
    • entité qui a produit le document
    • sujet/thématique/…
    • les tags doivent ensuite pouvoir être modifiés à la main.
  4. Le système doit fournir une interface pour ajouter/modifier/supprimer du contenu depuis le code d’alaveteli (via une API en ligne, ou une API ruby)
  5. Idéalement, le code doit pouvoir être étendu via un système de hooks ou plugins pour pouvoir modifier le fonctionnement « de base »
  6. Le logiciel doit fournir un moteur de recherche par producteurs de données, tags, recherche dans le texte, dates, etc…
  7. Si possible, une extraction du texte façon OCR pour les documents scannés serait la bienvenue. Cela permettrait une indexation bien plus facile par les moteurs de recherche.
  8. On doit pouvoir obtenir facilement un lien direct vers un document (« partage »). Ce lien doit permettre une prévisualisation dans un navigateur pour les formats de documents courants.
  9. Bonus: Une mise en avant de certains documents à la main par les admins serait utile (exemple: Accueil - data.gouv.fr)
  10. Bonus: le système peut aussi offrir une option de transfert de fichier directement au moment de l’envoi (à la place d’un wetransfer ou équivalent) pour que l’administration envoie le document sans passer par une plateforme tierce où on devrait ensuite récupérer le document.
  11. Le système doit être un logiciel open-source, et idéalement libre.
  12. Il doit répondre aux besoins du RGPD (modification/suppression de documents pour retirer des données personnelles, par exemple)
  13. Le système doit pouvoir être répliqué sur d’autres instances d’alaveteli assez facilement.

(Tickets gitlab correspondants: Open data library to archive docs and datasets from requests (#177) · Issues · madada-team / dada-core · GitLab Setup a search engine through opendata library (#178) · Issues · madada-team / dada-core · GitLab et Improve SEO for web search (#179) · Issues · madada-team / dada-core · GitLab)

2 « J'aime »
2

Tout ça me semble très bien, merci beaucoup ! Peut-être juste une suggestion pour un autre point « bonus » sur la possibilité de commenter des documents/ajouter des exemples de réutilisation ?

3

Rien à rajouter, merci !

Est-ce que vous avez commencé à identifier des outils existants qu’on pourrait réutiliser ou pimper ? On avait repéré DocumentCloud en particulier.

4

Je n’ai pas cherché sérieusement, je voulais essayer de réfléchir aux besoins avant de regarder les solutions.
Mais oui, j’ai documentCloud et ckan en tête. Si tu en connais d’autres, n’hésites pas!

5

Très bonne idée. Je pense qu’il faut mettre un soin particulier sur les métadonnées qui doivent être bien structurées pour être bien exploitables. Perso, ce qui serait super, serait que le système génère ou travaille avec une une base de données BibTeX mais je suis peut-être le seul à utiliser LaTeX.

6

@LaurentS j’avais identifié aussi Aleph de l’OCCRP qui a l’air assez puissant et adapté pour la recherche d’entités nommés :

https://aleph.occrp.org/

On avait un peu travaillé dessus chez Datactivist, des collègues avaient eu un échange avec le développeur Friederich Lindenberg (alias @pudo : https://pudo.org/).

Je suis tombé sur cette liste d’outils où il y était, possible qu’il y ait d’autres choses : https://freedomlab.io/tools-for-hrds/category/tools/topic/data-collection-documentation/

7

Schéma de la base de données de Alaveteli :

image
image2398×1803 491 KB

Pierre

8

Hello tout le monde,

Ci-dessous mes recherches et réflexions sur le sujet.

Laurent, d’un point de vue technique, je distingue trois types de fonctions ou services dans ton message.

  1. Un service de catalogue de documents que l’on peut ensuite décomposer en deux sous-services : un catalogue de métadonnées et un serveur de documents.
  2. Un service d’indexation et de recherche du contenu de documents de différents formats (PDF, Word, HTML, XLS).
  3. Un service de transfert de fichiers.

Ensuite, la question posée est de savoir quelles briques logicielles utiliser pour répondre à ces différents services, en permettant à la fois une bonne intégration avec la brique de base d’Alaveteli mais aussi une bonne modularité (l’idée n’étant pas de réécrire ou de créer un nouveau fork d’Alaveteli).

Choix du logiciel de catalogue

Je pense que l’on a trois options :

  1. Déployer nous-mêmes un catalogue de données (CKAN, uData, etc.).
  2. Utiliser Alaveteli comme catalogue de données en lui ajoutant les services manquants (essentiellement un moteur de recherche de métadonnées).
  3. S’appuyer sur data.gouv.fr en référençant tous nos documents sur cette plateforme.

Mon choix serait de partir sur l’option 1 qui permettrait éventuellement à l’équipe de data.gouv.fr de nous moissonner et donc de réaliser également l’option 3. L’option 2 me semble à écarter car elle risque de nécessiter la réécriture d’une bonne partie d’Alaveteli.

Si on part sur l’option 1, vient ensuite le choix du logiciel. En voici quelques-uns :

CKAN:

Le standard des catalogues de données open source. Il est écrit en Python et bénéficie d’une communauté mature et de nombreux plugins. CKAN est à la fois un catalogue de métadonnées et un serveur de documents.

uData:

Le logiciel derrière data.gouv.fr, également écrit en Python. Utilisé par la France et quelques autres pays. Il offre des fonctionnalités similaires à CKAN avec une touche sociale peut-être un peu plus forte. Peut être un bon choix si l’on souhaite se faire moissonner facilement par data.gouv.fr.

jKan:

Une version statique de CKAN, écrit en Jekyll mais sans serveur de documents. Son principal avantage est sa simplicité de déploiement et de configuration. En revanche, je m’interroge sur sa capacité à gérer plusieurs milliers de métadonnées. L’autre défaut est l’absence de serveur de documents.

Aleph:

Il a aussi été mentionné ci-dessus. Aleph est un catalogue de documents dont l’un des principaux objectifs est de permettre de tracer les flux financiers. Il fait office de catalogue de métadonnées, de serveur de documents, il permet également l’upload et l’indexation de documents type PDF, donc il coche pas mal de cases. Cependant, son principal désavantage est son modèle de données (basé sur Follow the Money) et le nombre de services non nécessaires. J’ai peur qu’il y ait pas mal de travail de personnalisation pour l’intégrer avec Alaveteli, mais peut-être que je me trompe.

Tâches à réaliser

Une fois le logiciel de catalogue sélectionné, il faudra :

  1. Réaliser la table de conversion entre les métadonnées d’Alaveteli et le schéma de métadonnées du logiciel (on peut aussi passer par l’un des standards DCAT ou schema.org afin de rendre l’opération encore plus intéressante pour la communauté). Ce n’est pas si évident et il y aura des choix à faire. Par exemple, nous n’avons pas le titre du document automatiquement, seulement le titre de la demande et le nom du fichier. De même pour la description, la date de mise à jour, etc. Une autre option serait de considérer la demande comme la ressource principale, et les pièces jointes comme des jeux de données/documents de cette ressource. Je peux aider sur cette partie.

  2. Développer un téléverseur ou moissonneur automatique entre Alaveteli et le logiciel sélectionné. Dans le cas du téléverseur, on « verse » directement les métadonnées et documents une fois ceux-ci mis à disposition sur madada. Dans le cas du moissonneur, on va chercher les données sur madada de manière régulière.

  3. (ou 2bis) Dans le cas du moissonneur, une solution serait d’exposer (de publier) les métadonnées Alaveteli sous format DCAT ou Schema.org idéalement dans un fichier unique. Ainsi, le moissonneur peut se synchroniser plus facilement.

  4. Déployer et administrer le logiciel de catalogue sélectionné.

  5. Déployer un service d’indexation et de recherche du contenu de documents. Je n’ai pas pris le temps de beaucoup regarder. Je sais qu’Elasticsearch fait ça plutôt bien (Google Search Engine aussi). À voir s’il existe un plugin CKAN ou autre. Je n’ai également pas regardé la fonction d’indexation de documents derrière Aleph.

  6. Mettre en place un service de transfert de fichiers. On peut proposer le service Framadrop. Aleph a aussi une option d’upload.

Enfin je me demande si on ne pourrait pas dans un premier temps se focaliser sur l’aspect métadonnées et s’intéresser à l’indexation et recherche de documents dans un second temps, voire via un autre financement. Toutes ces tâches représentent un gros chantier. Et il faut aussi penser à la maintenance de tout ça.

L’autre question est de savoir qui peut faire quoi ? J’ai l’impression que tout le dev reposera sur toi Laurent :wink: ?

Pierre

9

Hello Pierre,

Merci d’avoir pris le temps de creuser le sujet! J’ai l’impression qu’on est en phase en ce qui concerne les besoins et l’approche.

Pour essayer de répondre point par point:

Choix du logiciel de catalogue

Tu proposes 3 options:

  1. me semble le plus logique, et le plus flexible, et permet de faire 3 aussi. Ça permet aussi de reproduire le système sur d’autres sites alaveteli hors France.
  2. Bricoler dans alaveteli en dehors des clous de ce que mySociety veut en faire me semble être compliqué (et un volume de travail trop élevé).
  3. Travailler en direct avec data.gouv.fr manquerait de flexibilité à mon avis.

Donc je te rejoins sur le 1.

Pour le choix du logiciel même, je suis en train de résumer ce que font les 4-5 options qu’on a évoquées dans ce tableau. J’essaie de le compléter d’ici mardi pour qu’on puisse en discuter rapidement tous ensemble.

Travaux à réaliser

Sur les 6 points que tu listes, les 5 premiers font partie du boulot qu’on a proposé pour NGI, et qui doit donc être achevé (très rapidement). Clairement, on va devoir faire pas mal de choses à moitié. Mon objectif est vraiment de faire le minimum vital pour pouvoir se faire payer par NGI, et on verra par la suite comment affiner/compléter ce qu’on aura.

Et pour ta dernière question, oui, c’est moi qui m’y colle. La deadline théorique est fin Janvier, on va pouvoir faire glisser un peu, mais même ainsi, ça ne va pas être facile. Les coups de main/retours sont évidemment les bienvenus.

10

Après un peu d’exploration et quelques discussions, notamment avec @samgoeta, je pense avoir changé d’avis.

Les outils que j’ai évalués (assez rapidement), sont ceux cités dans ce fil:

  • ckan
  • uData
  • jkan
  • DocumentCloud
  • Aleph

Les fonctions principales qu’ils apportent sont essentiellement une liste des documents sur la plateforme, avec une fonction de recherche dans leur contenu (CKAN et uData ne s’occupent même pas de cette partie recherche, il faut des extras).
Mis à part jkan (qui ne fonctionnera sans doute pas pour le nombre de documents qu’on y mettra à terme), tous ces outils nécessitent un gros boulot d’installation/déploiement (à vue de nez, du même ordre de grandeur qu’alaveteli) puis de maintenance. Ils nécessiteraient aussi un/des serveur(s) en plus de ce qu’on a déjà (gardons à l’esprit que le soutien de gandi n’est pas inconditionnel, et on pourrait avoir à payer pour tout ça un jour, et que les serveurs, c’est aussi du CO2 :wink:).

L’autre problème est lié à l’ajout d’une nouvelle base de données, avec administrations, documents, règles de censure, tags, etc… ce qui implique une duplication et une synchronisation de ces données entre les 2 systèmes, donc encore du boulot pas trivial et sur le long terme.

Fondamentalement, je crois que j’avais surestimé ce que ces outils proposent, et donc le travail que cela aurait représenté de reproduire ces fonctions dans alaveteli:

  • serveur de docs: alaveteli les sert déjà, il manque surtout une page qui permette de les présenter directement, sans passer par la « couche demandes ».
  • indexation/recherche: alaveteli le fait déjà avec xapian. Les résultats incluent les documents (en prenant en compte les règles de censure), il faut juste les mettre en avant différemment.
  • métadonnées/censure: alaveteli gère ces aspects, il faut juste modifier un peu le code pour pouvoir utiliser les tags sur les documents eux-mêmes (ou se servir des tags utilisés sur les demandes/administrations liées à ces documents).

Au vu de ces points, je pense donc que l’option qu’on avait écartée au début (modifier alaveteli) est probablement plus pertinente. Pour obtenir ce qu’on veut:

  • ajouter une page /documents ressemblant à ce que CKAN et autres présentent: un champ de recherche, des sélections par « facettes » (par type d’administration, type de document, géographie, etc…), et une liste des documents qui répondent à la recherche. Encore une fois, toute la mécanique d’indexation et de recherche est déjà en place, il faut juste présenter les résultats un peu différemment.
  • faire en sorte que les tags puissent être appliqués aux documents en plus des demandes et administrations
  • ajuster le moteur de recherche pour pondérer les résultats différemment
  • ajouter quelques tags DCAT ou schema.org dans les pages pour à terme pouvoir se faire moissonner par les data.gouv et compagnie.

On troque du travail de déploiement/maintenance pour du travail de développement, et la possibilité d’affiner le fonctionnement du système plus finement. En termes de partage de ce code avec les autres alavetelis, c’est probablement plus simple aussi, on peut imaginer de progressivement remonter notre code dans alaveteli même, et à ce stade, il suffit d’une mise à jour sur les autres sites pour qu’ils bénéficient aussi de notre travail.

Ce qu’on évite:

  • 2 système d’indexation / recherche à maintenir en parallèle (xapian pour alaveteli / solr ou elasticsearch de l’autre côté)
  • 2 langages de programmation différents. Il est déjà assez difficile de trouver des gens pour nous aider avec un seul :sweat_smile:
  • un gros boulot de déploiement
  • pas mal de synchronisation entre les bases de données