Bonjour à toutes et tous,
La facturation de la solution technique n’étant plus basé sur un quota de nombre de jeux de données. Une question qui m’a été posé « Vous préférez un jeu de données par année ou un jeu de données avec plusieurs années ? ». J’ai ma petite idée.
J’aimerai bien avoir votre avis en tant qu’utilisateur de l’open data.
C’est un peu vague comme question, sans connaitre :
Après, rien n’empêche de proposer un fichier par année, et un fichier consolidé à coté…
Oui, la volumétrie me semble la première raison pour séparer ainsi que la mise à jour (données passées stables).
Le nombre d’années me semble être un facteur indirect, lié à la volumétrie.
Je dirais qu’il n’y a pas forcément de « meilleure » réponse qui conviendrait à tout le monde, mais que le tout est que ce soit 1/ bien documenté et explicite (avec un champ indiquant l’année) 2/ cohérent. Il est important aussi je crois de bien historiciser les données (qu’un millésime n’écrase pas les précédents).
Ce jeu de données par exemple est multi-années et je ne trouve pas du tout ça gênant : Budget participatif - Les projets lauréats — Paris Data
C’est un bon exemple où la volumétrie est faible et donc un jeu global ne pose aucun problème (au contraire même).
Autres raisons de séparer:
Par conséquence une année n’est plus directement comparable à une autre et il vaut mieux séparer (et docmuenter les changements bien sûr pour ceux qui voudraient ré-agréger).
Merci 
pour vos réponses @GuillaumeD, @joel et @cquest
Je vais être plus précis. Mes collègues dépose une fois par an sur open.urssaf.fr des jeux de données sur les marchés :
JDD sur les marchés
Volumétrie par année : assez faible (sauf si demain c’est x22 car toutes les Urssaf mettent les données)
=> Une question qui me vient. A-t-on une idée précise de la taille à partir de laquelle il vaut mieux scinder. Dépend probablement de l’utilisateur (si utilise Excel ou API + BI ou autre)
Structure : pour l’instant c’est la même après ce serait bien de se rapprocher du schéma proposer par data.gouv
Charge interne : je me dis que c’est, peut-être, plus simple pour la documentation et le reste d’avoir un seul jeu avec plusieurs années
Après @GuillaumeD sur ta proposition de faire un fichier par année et un consolidé je me demande si sur la charge interne ça va peser et si c’est vertueux en terme de sobriété numérique. Aucune idée.
Encore merci pour les réponses. C’est top et ça fait réfléchir 
Sur ce cas précis on coche:
Trois bonnes raisons pour n’avoir qu’un jeu de données de mon point de vue.
Il est plus simple de filtrer que d’agréger, surtout sur un portail ODS.
même avis que @cquest. Sur un jeu comme ça je ne vois pas l’intérêt à double publier, ça induit de la confusion, des risques d’écart/erreurs et c’est simple de filtrer avec ODS.
Par contre @DavidG le « schéma » auquel tu fais référence n’est pas « proposé par data.gouv » mais obligatoire de par la loi : schema.data.gouv.fr. Ça n’empêche pas de publier autre chose à côté mais a minima cette obligation devrait être satisfaire…
Tu as un lien vers un texte qui précise cette obligation. J’avais échangé on m’avais plutôt dit que c’était une préconisation.
Merci Christian. Mon intuition me disait aussi de partir sur cette vision. C’est bien de pouvoir échanger et d’avoir des avis sur le sujet.
C’est précisé dans le lien que je t’ai mis : arrêté du 22 mars 2019, pris en application de l’article R2196-1 du Code de la commande publique, lui-même pris en application de l’article L2196-2 du même code.
par ailleurs je m’écarte du sujet mais 1/ néanmoins les DECP (ou certaines ?) remontent bien dans la consolidation nationale (voir db: decp: 101 lignes où where acheteur.id = 18003501600054 sorted by rowid), donc elles doivent être diffusées au format règlementaire, sans doute via e-marchespublics ? 2/ la licence ODBL appliquée à ce jeu de données paraît inutilement restrictive car comme le rappelle souvent @cquest s’agissant de données d’autorité comment pourraient-elles être corrigées par des tiers ?
Merci Joel. Je regarde le point 1/ et pour le 2/ La licence n’est pas géré jeu de données par jeu de données. Elle est valable pour l’ensemble des JDD. On reste ouvert à des évolutions la maturité et les échanges aidant.
Si je résume nos échanges en tentant des propositions « pièces à casser » :
Critères pour partager un JDD multi-année ou année par année :
• Le volume de données
Proposition : si au-dessus de 1 500 000 lignes alors fichier séparé
• La fréquence de mise à jour
Proposition : si les mises à jours conduisent sur la période à dépasser 1 500 000 lignes alors fichier séparé
• Mise à jour de l’historique
Proposition : si la mise à jour du fichier multi-année conduit à revoir l’historique et que cela nuise à l’utilisateur alors fichier séparé
• Comparabilité entre années n’est plus possible (changement de structure, méthode de collecte, …)
Documenter les changements pour permettre les re-agrégations
La mise à disposition d’un fichier multi-année doit être facilité par :
• un champ indiquant l’année dans le jeu de donnée
• permettre une mise à disposition de tout ou partie (filtre) et selon des modes d’export adapté (Excel, Csv, API …)