Restitution de l'atelier : "composants opensource pour un outil de qualification des données"

Forme

La première question que l'on s'est posée concernait la forme possible de l'outil de qualification.

Tout le monde s'est accordé à dire que celle-ci devait dépendre du profil de l'utilisateur. Selon qu'il soit producteur, utilisateur, consommateur voire certificateur, il faudra des formes plus ou moins complexes, locales ou déportées.

Le point sur lequel à peu près tout le monde était d'accord était que la création d'un kit de développement API (librairie de fonctions) pour la mesure des différents critères permettait d'envisager le plus de formes possibles : outil web exploitant cette librairie, outil de bureau, serviciel.

Il a été signalé, d'ailleurs, que des outils hybrides existent, qui se déclinent à la fois en outil web et bureau, sur la base d'une API : comme QGIS : QGIS Server, Desktop et son API pyQGIS.

Un exemple a été cité qui est celui de EasyQualif produit par le CRIGE qui, initialement basé sur une chaîne de traitements sous FME, se retrouve transposé sous forme web et, enfin, de guichet depuis lequel des interactions se font entre producteurs et certificateurs. Comme il s'agissait ici de définir un outil libre, la question s'est posée de pouvoir réaliser, sur la base de modules opensource, une infrastructure technique similaire à EasyQualif.

Le côté hybride permettra de s'adapter au maximum d'environnements techniques et organisationnels (idée de gouvernance) et, surtout, d'être accepté par des utilisateurs de profils et niveaux différents.

Composants

Nous avons tenté de définir les composants de l'outil. Et pour cela, il a fallu d'abord réfléchir à la définition de ses modules et de leur articulation.

Sur le point des composants, l'outil :

• s'appuierait en entrée :
  • sur de la donnée spatialisée, mais pas que ! (il a été précisé qu'il fallait aussi parler de données au sens large)
  • des spécifications :
    • un gabarit ou modèle de données
    • un référentiel géographique
  • voire même des méta-données existantes
• ...pour effectuer les différents contrôles. Il a été souligné, sur ce point, que des critères semblent assez facilement automatisables à mesurer tels que le critère de cohérence logique, tandis que d'autres moins, comme la précision de position, altimétrique, planimétrique, voire sémantique
• ...pour produire :
  • des rendus :
    • parlants à des formats interopérables tels que HTML, XML, lisibles tels que PDF
    • visuels sous la forme de graphiques
  • des méta-données décrivant la qualité du produit

Dimension sociale

Une idée a été émise d'intégrer à cet outil des fonctions sociales de partage, de notation de gabarits et modèles afin que ces derniers puissent être facilement intégrés par les utilisateurs en vue de la qualification.

Ergonomie

Sur le point de l'ergonomie, tout le monde s'est accordé à dire que le logiciel devait être le plus convivial possible.

L'interface pourrait intégrer de l'aide au niveau de ses différents champs : à renseigner ou résultats, par exemple pour expliquer la mesure à l'opérateur.

Le terme de "parcours qualité a été donné" : l'outil déroulerait de façon synoptique, un à un, les différents critères. Du reste, la liste de ces derniers serait définie par le profil de l'utilisateur. Ainsi, un certain nombre de critères par défaut se verraient enrichis si le profil de l'utilisateur s'avérait plus spécifique à un domaine, notamment expert.

Briques logicielles

Plusieurs solutions ont été évoquées lors de l'atelier :

• QGIS qui existe à la fois en logiciel client et serveur web. Il a été mentionné qu'il est possible de lancer des traitements à la manière d'un ETL, et donc de FME, depuis la partie web via la librairie Processing. Cet aspect hybride rejoint le critère de forme évoqué tout en haut.
• Talend-SDI, pendant opensource de FME, quoique son développement semble s'être ralenti.
• Dans le même style, Pentaho et son pendant spatial GeoKettle.
• PostgreSQL, PostGIS : citons sa fonction st_isvalid
• Le langage de développement python muni de ses librairies spatiales, qui semble être une lingua franca des développeurs opensource en géomatique.

A la suite des ateliers, ont également été cités :

• Géoxygène, développé par l'IGN qui possède déjà des fonctions très complètes liées à la qualification
• OpenJump qui possède des fonctions utiles de conformité géométrique et d'appariement.

Appariement

Il a été fait mention de la nécessité d'intégrer dans l'outil un module d'appariement afin de qualifier la précision de position d'objets de façon semi-automatisée sachant qu'il s'agit d'un critère difficilement mesurable de façon autonome. Pour cela, il sera possible de s'inspirer des travaux de recherche existants, réalisés par exemple par l'IGN.

Communauté

Le partage du projet en opensource auprès de la communauté sera la clé du succès du projet, qui permettra de fédérer une communauté de développeurs et d'utilisateurs autour de lui.

Il faudra pouvoir relayer facilement les doléances, bugs, souhaits d'implémentations logicielles des utilisateurs auprès des développeurs via un circuit court.

Pour cela, ont été évoqués des portails de partage du code : - github mais qui n'est pas opensource - gitlab - framagit

Qualithon

Aussi, on a parlé d'un qualithon qui, réunissant producteurs, certificateurs et développeurs, serait l'occasion d'imaginer, voire de concevoir, a minima sous la forme d'un POC (proof of concept) cet outil de qualification de données géographiques.

Des idées, comme ça

La question de l'absence de référentiels lors de la qualification a amené à aborder la question du crowd-sourcing, des captchas à la sauce Google.

Aussi, il a été précisé lors de l'atelier que la préparation d'une campagne de terrain, par exemple d'échantillonnage, ne pouvait apparaître dans cet outil, mais plutôt ferait l'objet d'un séparé.