Cet argument ne peut être opposé à l’ouverture des données. Je suis d’accord avec vous.
Dans ce cas c’est inquiétant (et le plus souvent assez faux) : comment font les services qui doivent les utiliser pour bosser aujourd’hui ?
En revanche, la qualité et la mise à jour peuvent hélas avoir des conséquences dans l’utilisation par « les services ». Pour exemple le TA annule une partie du PADDUC de Corse sur la base de la cartographie des espaces stratégiques agricoles. Sur le fond certains ESA étaient des lotissements depuis longtemps. Il existait une donnée à jour, une vieille de plus de 12 ans toutes deux en open data.
Sur le fond certains ESA étaient des lotissements depuis longtemps. Il existait une donnée à jour, une vieille de plus de 12 ans toutes deux en open data.
Je ne dis pas que ce n’est pas un défi de le gérer. Ce sont bien souvent des processus complexes à mettre en oeuvre pour faire travailler tout le monde, citoyens et services en harmonie.
En revanche dire que les données ne sont pas de qualité est peu crédible, puisque des gens travaillent avec aujourd’hui.
En revanche dire que les données ne sont pas de qualité est peu crédible
L’exemple des données RPG 2017 que je cite plus bas est effectivement peu crédible, ce jeux de données étant de plus « retravaillé » par un EPA bien connu dans le cadre d’un marché public.
Je rejoins @CecileLG, il serait bon d’avoir davantage des plans de réponse à ces poncifs qu’on retrouve dans le bingo.
la pauvre qualité des données n’empêche probablement pas les gens qui bossent avec de bosser avec, c’est juste qu’ils pourraient peut être répondre mille fois plus vite aux besoins des citoyens. ça ne m’étonnerait pas du tout que la plupart des jeux de données dont disposent les administrations soient réellement de piètre qualité et presque inutilisable. tout est dans le presque, c’est l’occasion d’améliorer tout cela et de répondre a des modèles de données propres.
que donner aux administrations alors comme modèle ? l’ISO-9001 suffit il ?
Bonjour,
Après trente cinq années de code je suis victime de déformation professionnelle et j’ai tendance à voir les choses sous l’angle « object modeling ».
ISO ou autre : Objectif : obtenir une traçabilité de la donnée. Méthode de prod en fonction de l’époque.
(saisie manuelle, scan, injection par système info …).
Certification de la données : publique, déclarative (from user), industrielle …
Interface : implémenter les interfaces standard : géomètries ISO, proj légales, règles codage chaîne de caractères, formats standards ouverts.
Il faut distinguer deux argumentaires, l’un pour le producteur d’opendata, l’autre pour le consommateur (ou utilisateur).
Trois types de producteurs
Acteur public, Citoyen, entreprise.
Qui sont aussi les trois types de consommateurs. L’argumentaire pour ou contre varie selon le rôle, le même acteur peut être pour en tant que consommateur et contre en tant que producteur
Pour établir un argumentaire solde et positif, il faut aussi aborder l’opendata sous la forme du flux entre acteurs. Le consommateur doit toujours devenir producteur : soit en corrigeant le dataset original, soit en l’enrichissant. C’est la qualité et la richesse des flux de circulation de données ouvertes qui fait la viabilité et la richesse (au sens économique) du modèle.
C’est une bonne surprise de trouver cette discussion ici sûr les arguments anti les données ouvertes et comment les répondre.
Oui, c’était moi qu’ai construit le bingo.dadosabertos.social, après le travail de Fernanda et le groupe italien Spaghetti Open Data. Cependant, ce n’est pas bien qu’une traduction, mais une adaptation à la réalité brésilienne. Quelques parts ont été traduits directement, bien sur. Toutefois, par exemple, les références à la législation italienne ont été changé à la législation brésilienne.
Si vous avez des questions sûr le bingo, n’hésitez pas à me demander.
Je prends ce thread en retard… Il y a longtemps avec @Armelle on avait rédigé un document complet sur ce sujet :
Il avait fait l’objet de plusieurs ateliers qui fonctionnait un peu comme une sorte de groupe de parole pour les agents motivés qui racontaient les obstacles rencontrés dans leur travail. À l’époque ça me paraissait dérisoire mais les participants semblaient trouver beaucoup de satisfaction dans cet atelier.
Personnellement je prends ça comme un argument supplémentaire pour ne plus utiliser le terme de « standard » qui a tendance à sacraliser les schémas de données, dont la portée normative est largement exagérée (hormis pour ceux qui sont fixés par des textes règlementaires).
Je ne vois aucune raison d’employer un autre terme que « schéma de données », et s’il le faut il devrait règler plus de problèmes qu’il n’en pose (contrairement à « standard », donc).
Entendu récemment, à plusieurs endroits et dans un contexte que je peux pas indiquer ici :
« Nous ne pouvons pas ouvrir nos données patrimoniales, car cela encouragerait différentes entreprises à nous démarcher pour renouveler notre parc de matériel selon un rythme que nous conviendrait pas ».
Le patrimoine en question est visible sur le domaine public.
Entendu au détour d’une réunion où la conviction était forte d’un côté comme de l’autre pour faire pencher la balance de son côté.
« Nous ne sommes pas concernés par l’obligation de publier des documents administratifs parce que les bases de données n’en sont pas. Le document, c’est le papier tamponné qui est produit à partir de la base de données ».
A ce niveau on se demande si ça n’est pas enregistré pour tester notre réaction. C’est le Truman show.
« Le code n’est pas ouvert car on a indiqué dans notre homologation de sécurité qu’il était sur un repo privé, il faudrait refaire un homologation même si ce qui est à protéger ce sont les données et pas le code »
