En vue d’une formation, chez Datactivist nous avons produit ce support d’activité pour évaluer un jeu de données en vue de son ouverture. Sous forme de check list, il vise à se poser les bonnes questions et estimer le travail à faire avant ouverture afin de prioriser (mettre en haut de la pile un jeu de données plutôt qu’un autre par exemple).
Je comprendre l’ironie @cquest.
Le fait est que dans nos séances d’acculturation ou d’accompagnement ces sujets reviennent souvent. Des agents de collectivités ont souvent besoin d’une validation hiérarchique avant ouverture. L’idée est d’identifier avec eux ce qui pourrait bloquer et les aider à lever les freins, préparer une argumentation par exemple.
On ne donne pas ce document sans accompagnement. On le remplit avec eux, on discute, on échange, on les aide à aller vers l’ouverture.
C’est la grille parfaite pour trouver les raisons de ne pas ouvrir.
Je ne vois aucune raison d’ouvrir pour rétablir l’équilibre:
jeu de données déjà demandé
jeu de données déjà ouvert par des collectivités similaire à la nôtre (et avec des réutilisations)
jeu de donnée dont l’ouverture est prévue par des textes (oui, le CRPA)
Il y a énormément de mauvaises pratiques, j’ai juste eu l’impression en lisant cette grille d’avoir le bingo habituel.
Faites-le recto-verso ce document, avec l’autre version qui va dans l’autre sens de l’autre côté… et promis je rangerai ma casquette de commissaire politique.
jeu de données dont la Cada a donné un avis positif pour l’ouverture
Faisabilité:
à la place de propriétaire => producteur
je mettrai données sensibles tout court. En gros données sensibles => besoin d’un arbitrage. Disons que la validation politique n’est peut-être pas forcément nécessaire, juste un arbitrage sur la maille, supprimer une ou plusieurs colonnes,…
Pour les persona, l’âge me parait superflu. je trouve que ca alourdit le doc.
Je ne vois pas de lien entre les étoiles de notes en bas et le fait de remplir la grille => pas de corrélation
Fiabilité
J’ai peur que ce contrôle de fiabilité fasse peur et dissuade les CT d’ouvrir.
A la rigueur, on peut faire une échelle sur 4 sur 3-4 item qualité, car c’est rarement OUI ou NON
Je ne vois rien sur la documentation et les métadonnées, ni sur la licence qui devra être choisie.
Les grands esprits se rencontrent ! J’avais ajouté l’avis Cada dans la version intégrant les suggestions de @cquest !
Pourriez vous m’expliquer pourquoi vous proposer de modifier « propriétaire » en « producteur » ?
Concernant les données sensibles je vous rejoins bien volontiers mais j’ai besoin d’une formulation ou le « oui » serait positif et le « non » négatif pour compter les points en quelques sortes et permettre l’évaluation.
je retire l’âge vous avez raison
il y a bien corrélation entre la grille et les étoiles en bas de chaque colonne mais tous les éléments cochés ne se valent pas (que se soit des freins ou du travail à faire avant l’ouverture) donc je voulais laisser la possibilité de pondérer comme on le souhaite sans donner un barème précis pour chaque coche verte ou rouge.
les métadonnées, la documentation ou la licence font plutot l’objet d’un autre atelier pratique. C’est l’étape suivante !
Mouais… c’est une direction dangereuse, car on saute facilement à un effet inverse: pas d’avis CADA… on ne sait pas si on peut ouvrir, voire penser que l’avis CADA soit une sorte de passage obligé.
L’avis CADA c’est quand même déjà aller vers une forme de contentieux.
propriétaire > producteur « mais pas que »… document (donnée) produit ou reçu dit la Loi.
données sensibles: ça n’existe pas légalement. Soit le cas est prévu par le CRPA, soit il ne l’est pas. La « sensibilité » est souvent suggestive et politique.
Rappel du L311-5 pour les documents non communicables :
a) Au secret des délibérations du Gouvernement et des autorités responsables relevant du pouvoir exécutif ;
b) Au secret de la défense nationale ;
c) A la conduite de la politique extérieure de la France ;
d) A la sûreté de l’Etat, à la sécurité publique, à la sécurité des personnes ou à la sécurité des systèmes d’information des administrations ;
e) A la monnaie et au crédit public ;
f) Au déroulement des procédures engagées devant les juridictions ou d’opérations préliminaires à de telles procédures, sauf autorisation donnée par l’autorité compétente ;
g) A la recherche et à la prévention, par les services compétents, d’infractions de toute nature ;
h) Ou sous réserve de l’article L. 124-4 du code de l’environnement, aux autres secrets protégés par la loi.
Le reste même « sensible » est communicable, souvent en passant par la CADA et/ou le Tribunal Administratif… malheureusement.
Pour tenir compte et tenter de lier vos remarques @cquest@gendy54, j’ai changé le nom de l’encart en « appuis à l’ouverture ». Ainsi, @cquest on inscrit les éléments favorables et on n’estime pas que l’absence de ces éléments favorables empêchent l’ouverture. Voyons les plutôt comme des accélérateurs.
Pour les termes « propriétaires » ou « producteurs » qui étaient réducteurs, nous proposons « nous produisons ou sommes destinataires des données »
Le but n’est pas seulement de dire si on peut ouvrir les données, mais aussi de prioriser le travail à faire dessus. Oui la loi c’est l’ouverture par défaut, mais dans les faits les producteurs se forment, apprennent, organisent et planifient le travail à faire pour ouvrir les données.
C’est complètement HS, mais au-delà de la gestion des jeux de données à publier et prioriser, y a t-il qqch dans le processus pour les retours des utilisateurs? Je m’explique.
L’analyse de la qualité est importante mais peut-être bloquante si on considère que la donnée n’est pas très présentable et pourtant, je pense qu’on est une majorité à préférer un jeu de données améliorable qu’un jeu (presque) parfait mais pas publié. En gros, la question est: dans le processus de publication, y a t-il un processus de gestion de retours utilisateurs (boucle de rétroaction) qui est souvent un point qui pêche et qui pourtant est pour beaucoup un point essentiel?
Bonjour, je m’invite dans le débat.
Je rajouterai une remarque sur « le contenu des données est satisfaisant » : par rapport à quoi ? Ce qui est « suffisant » pour un usage ne le sera sans doute pas pour un autre. Cette grille me semble être un support pédagogique intéressant sur tous les éléments à prendre en compte lorsque l’on manipule une donnée, mais me semble effectivement peu opérationnelle pour évaluer un potentiel d’ouverture et en faire un argumentaire pour convaincre.
D’autres questions pourraient être : Quel usage ? Est ce important de publier pour la collectivité ? ça oblige à des réponse un peu plus complexes, mais ça peut contrebalancer des points négatifs.
Bonne journée
L’idée de proposer un mini guide pour évaluer le contenu d’un jeu de donnée et identifier le travail à faire pour le publier me parait utile . Comme le dit @cquest, ce ne doit pas être une frein pour fermer la donnée considérée mais Il me semble que c’est la façon dont on va s’en servir qui fera la différence. On ouvre oui, mais quelles précautions doit-on prendre? quels travail a effectuer?
Il sera intéressant de voir à l’usage comment ce questionnaire répond (c’est à dire lorsqu’une collectivité se penchera sur une donnée particulière en vue de sa publication).
Sur le fond du document, quelques suggestions ;
je ne comprends pas bien ce que veut dire « données déclaratives ». C’est ce que l’on retrouve plus loin sous un terme plus explicite de DCP (Donnée à Caractère Personnel ?
lorsqu’on aborde les métadonnées, pourquoi ne pas indiquer directement la valeur (spécialisation : EPCI, temporalité : année, granularité : commune, etc selon le cas) ?
Sur le chapitre Exploitabilité (ou Qualité) des données : sont présentés 2 critères (valeur vide et incohérence) mais il en a bcp plus (l’encodage, les séparateurs, les formats numériques, la précision, etc.). Avez-vous fait un choix volontairement restrictif et prioritaire ?
Standardisation : compléter le champ : Un standard existe et il est applicable ? indiquer le standard : … Comme à priori le jeu de donnée n’est pas déjà normalisé, la question est de savoir si les données essentielles s’y trouvent (réponse binaire) et quel effort de traitement doit être fait pour normaliser le jeux de donnée (réponse non binaire).
De façon générale, le chapitre Standard ne devrait pas être aussi précis sur quelques aspects (INSEE ou code postal par exemple peuvent être inadaptés si le std impose le SIRET. D’autres champs sont normalisés comme les séparateurs, les unités, etc.). Ce ne sont pas des critères pour évaluer l’opportunité de publication, c’est un traitement nécessaire, difficile à évaluer dans une fiche aussi synthétique.
remplacer le pictogramme Travail sous forme de par par exemple
Pas forcément non plus (hors standard)… c’est sûr qu’on peut prioriser d’ouvrir des données plus « présentables » que d’autres, mais il ne faudrait pas laisser penser qu’une mise en qualité est indispensable avant publication.
Pour un jeu de données pour lequel un standard non obligatoire existe, le respecter est plus un investissement pour augmenter ses chances d’agrégation et donc de réutilisation. Les standards obligatoires ne sont pas si nombreux à ce qu’il me semble.
Les principes de l’opendata (et les textes réglementaires) n’imposent pas qu’un travail particulier soit fait avant ouverture, à part les « traitement d’usage courant » en particulier liés aux données à caractère personnel.
Je trouve même intéressant, en tant que citoyen, de voir la qualité des données, y compris quand elle est mauvaise (et on a un paquet d’exemples)… et oui, c’est un « risque » d’avoir des critiques sur la qualité mais à moduler avec la différence entre l’usage interne pour lesquels cette qualité peut être suffisante, et les ré-utilisations qui
Une mise en qualité a aussi un impact interne, mais peut se faire après coup. Souvenir de la base des arrêts de bus de la RATP… il y en avait en fait une demie-douzaine en interne, l’une d’elles a été publiée, très moche, les retours négatifs ont mis en évidence ces bases-silos, un effort interne a été fait pour une base commune, tout le monde y a gagné.
L’ouverture peut aussi permettre qu’une mise en qualité soit faite par la multitude
C’est là où data.gouv est formidable car on peut facilement partager les jeux de données améliorés.
Dommage que les autres plateformes ou outils soient si orientés top-down !
Bonjour @LaureHuguenin,
Les usages sont ici envisagés avec les persona qui se trouvent en bas à gauche. Ici c’est en version simplifiée mais nous avons la même activité où il faut envisager les usages pour chacun d’entre eux, ainsi que les freins. Tout dépend du temps dont on dispose en formation ou en atelier.
Voici le document en question :
Merci, je pensais également usage/partage. Ex : une collectivité qui peut redistribuer des données à une échelle infra et/ou les agréger avec d’autres = granularité « suffisante » dépend des usages.
Super document ! Ce que ça m’inspire et à la suite des discussions avec des producteurs : la demande par des réutilisateurs / citoyens / que sais-je est un super levier parce que ça permet de justifier le temps passé, j’ai vu que @cquest avait proposé ça.
Et dans ces leviers, on peut aussi dire que ça peut intéresser d’autres services / des collègues.
En tant que ré-utilisateur, dans la dernière le Code Insee est évoqué, à privilégier au code postal. C’est top, mais peut-être étendre à une colonne « pivot » qui permette les classements : code Insee pour une collectivité, SIREN ou RSA pour association et tout autre élément mais ça rentre peut-être un peu trop dans les détails.
Je ne sais pas ce que veut dire DECP, mais je suis un peu comme Christian, j’ai toujours peur que de parler de données personnelles donne plutôt des raisons de ne rien ouvrir, alors qu’en réalité, très peu de jeux de données contiennent des « vraies » données personnelles et que les problématiques d’anonymisation (en dehors d’une adresse, d’un nom de responsable, ou autre) soient très peu fréquentes.
Peut-être un truc à rajouter sur une documentation facile à rédiger, ou sur une prise en main facile pour un novice, ça permet de prioriser.
. Comme le dit 
par 
par exemple 
