Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

1/ Qu’est-ce qu’un concédant ?

Le concédant désigne la personne qui met à disposition la base de données initiale et cède les droits dont il dispose sur celle-ci. Par ailleurs, une plateforme de diffusion peut publier des données de plusieurs producteurs. De ce fait, le terme de « concédant » peut désigner tant le producteur de la base de données, que le diffuseur (voire les deux en présence de bases de données modifiées).

2/ Est-ce que la licence couvre les données à caractère personnel ?

Cette licence ne se substitue pas aux dispositions législatives, elle peut donc être utilisée pour des bases de données qui contiendraient des données à caractère personnel, sous réserve du respect de ces dernières. Chaque réutilisateur est responsable au regard de l’usage et des finalités de ses traitements.

3/ La réutilisation d’une base de données sous licence ODbL peut-elle donner lieu à la perception d’une redevance par le Concédant (art 3.2) ?

La licence ODbL est une licence internationale. Elle fait donc état de cas d’usage internationaux. Concernant la France, le régime de gratuité par défaut des données publiques est prévu par l’article L324.1 du code des relations entre le public et l’administration, nonobstant quelques cas d’exception encadrés par les articles R324-4-1 et suivants du même code. C’est donc l’article 3.2 alinéa c) qui s’applique.

4/ Je suis réutilisateur de la base de données initiale, puis-je faire payer la distribution d’une base de données initiale ou d’une base dérivée ?

Non. Si je suis une personne publique, je ne peux pas faire payer cette distribution.

Oui. Si je ne suis pas une personne publique, alors l’ODbL n’empêche en aucun cas leur commercialisation, néanmoins celle-ci ne peut être directement liée à la revente de la base de données initiale ou de ses enrichissements. D’autres réutilisateurs pourront ultérieurement ré-utiliser et rediffuser la base de données sans contrepartie financière.

5/ Comment mentionner la source (« la paternité ») de la base de données ?

Lorsque vous réutilisez une base de données soumise à la licence ODbL, ou une partie de cette base, vous devez mentionner les noms des différents concédants (c’est-à-dire toutes les personnes ayant contribué à ladite base) ainsi que le fait que la base de donnée est soumise à la licence ODBL. Il est possible de créer une page web dédiée « mentions légales » ou « sources des données » référençant la liste des concédants avec les liens vers leurs portails open data. La source devra être mentionnée de la façon suivante : « [Nom de la base de données], [Producteur de la base de données], [date], sous licence ODbL. » (par exemple, « Éclairage public — Mairie de Paris, sous licence ODbL »).

6/ Comment assurer le repartage dans les mêmes conditions ? Si j’ai enrichi les données d’une base de données initiale sous licence ODbL avec d’autres données, suis-je obligé de les redistribuer ?

Vous n’êtes obligé de redistribuer la base de données enrichie (base de données initiale à laquelle s’ajoutent vos propres données) qu’à partir du moment où vous en faites une réutilisation publique. C’est-à-dire que vous utilisez ces données dans un produit ou un service mis à disposition du public, ou encore que vous distribuez une Création produite grâce à cette base de données.

A contrario, dans le cas d’un usage privé (pour vous) ou privatif (pour un cercle restreint d’utilisateur sur lesquels vous détenez un pouvoir décisionnaire) vous n’avez pas d’obligation de repartage des données enrichies sous les mêmes conditions de licence.

7/ Pourquoi la licence prévoit-elle l’obligation d’effectuer un repartage dans les mêmes conditions ?

Même s’il s’agit d’un usage interne, repartager vos données modifiées, dans la plupart des cas, est pour vous un investissement source d’efficacité et de pérennité. Vous vous donnez ainsi une chance de ne pas être obligé de corriger à nouveau vos données lorsque la base originale sera mise à jour. Abonder la qualité de la base de référence est une bonne pratique pour vous et tout votre écosystème.

8/ Comment effectuer ce repartage dans les mêmes conditions ?

Les données enrichies doivent être rendues disponibles à partir d’un lien ou d’une API facilement accessibles depuis le service proposé. Cette mise à disposition doit être immédiate et mise à jour à chaque nouvelle version de la base de données enrichie et au minimum avec la même périodicité que la base de données initiale. Elle doit être gratuite en cas de distribution en ligne ou à un coût raisonnable en cas de distribution physique.

9/ Viralité et propagation

La licence ODbL est souvent dite propageante ou contaminante ou encore « à réciprocité ». Elle s’applique et se généralise à l’ensemble de la base de données enrichie par une base de données soumise à la licence ODbL. Les mots « contamination » ou « propagation » et « viralité » sont communément utilisés pour expliquer les effets des licences de ce type. Il existe d’autres termes comme « héritage » plutôt que « viralité » et « généralisation » pour « contamination ». Néanmoins, nous resterons sur la notion la plus généralement utilisée de « partage dans les mêmes conditions. »

10/ Quelle obligation de réciprocité (“propagation”) pour la licence ?

La licence doit être étendue aux bases de données dérivées. L’enjeu pour les collectivités est donc de savoir jusqu’où elles considèrent que la licence d’un jeu de données en ODbL peut raisonnablement s’étendre au reste de la base de données du réutilisateur. Il est ainsi précisé que pour les collectivités la clause de « partage dans les mêmes conditions » figurant à l’article 4.4 concerne les informations de même nature, de même granularité, de mêmes conditions temporelles et de même emprise géographique.

La thématique est notamment définie en fonction des méta-tags de la base de données. Cela ne concerne que les données qui sont, soit de même nature que les données existantes, soit intimement liées et qui, à ce titre, enrichissent la base de données initiale. Cette extension est subordonnée à deux conditions cumulatives :

• identité de thème (notamment exprimée à travers les métadonnées c’est-à-dire les « mots clés » de la base de données),

• et identité de secteur géographique de la base de données initiale.

Exemple 1 : Pour une base de données fictive sur les boulangeries d’une ville dont les mots-clés sont : pain, viennoiseries, pâtisserie, commerce de proximité.

L'utilisation de la base de données initiale des boulangeries entraine l’extension de l’ODbL à toutes les données relatives aux boulangeries (prix, horaires, etc.) présentes dans le service proposé par le réutilisateur pour les données relevant d’une « emprise géographique » équivalente. Il en va de même pour toute donnée se raccrochant aux mots-clés définissant la base de données publique mise à disposition.

Exemple 2 : Pour une base de données des emplacements des stations d’un service de vélos partagés sur le territoire d’une ville dont les mots-clés sont : vélo, station, borne, piste, mode doux, location.

L’utilisation des données de la base de données initiale des stations de vélos partagés entraîne le passage sous ODbL de toute données relatives à des services de vélo partagés sur le territoire concerné.

Cette obligation de réciprocité doit être vue comme un cadre minimal de diffusion des données : les données initialement non ODbL peuvent toujours parallèlement être « licenciées » sous d’autres termes par leur producteur originel.

11/ Quelles sont les règles d’extension de la licence et le rôle de l’emprise géographique ?

Prenons pour exemple une base de données dérivée construite par le croisement d’une base de données A sous ODbL et d’une base de données B sous Licence Ouverte. L’extension de la licence est toujours descendante, c’est-à-dire qu’elle se fait depuis la base de données A vers la base de données dérivée. Elle ne s’étend pas à l’autre base de données utilisée.

Dans le cas où l’emprise géographique de la base de données A est plus petite que celle de la base de données B (soit territoire A < territoire B), seules les données de la base de données dérivée correspondant à l’emprise géographique de la base initiale A passent sous licence ODbL.

Cas concret : Les horaires de bus de l’opérateur de transport de Toulouse (Base de données A sous licence ODbL) sont croisés avec les horaires de bus interurbain publiés par le Conseil Départemental 31 (Base de données B)

Certains points de départ ou d’arrivée situés à Toulouse se superposent. Pour la base de données dérivée, seuls les horaires des bus circulant dans le périmètre de la base de données A passent en ODbL

12 / Quel est le droit applicable et la juridiction compétente ?

En cas de litige, les tribunaux compétents et le droit applicable sont ceux du ressort dans lequel le concédant a son siège ou son domicile. C’est-à-dire que pour un concédant basé en France, une base de données sous licence ODbL est soumise au droit français.

• Lorsqu’il s’agit d’une administration, la juridiction compétente est le tribunal administratif

• Lorsqu’il s’agit d’une entreprise (personne morale) basée en France, la juridiction compétente est le tribunal de commerce.

• Lorsqu’il s’agit d’un citoyen basé en France, la juridiction compétente est le tribunal d’instance.

13/ Puis-je distribuer les données d’une base de données initiale ou d’une base de données dérivée sous une autre licence ?

Il n'est pas possible de changer la licence (article 4.8), sauf pour utiliser une version ultérieure ou compatible de la licence (article 4.4). En revanche, il faut distinguer les données du produit ou service utilisant ces données dans la mesure où le produit ou le service constitue une création produite.

14/ Que se passe-t-il en présence de deux licences aux termes incompatibles ?

Lorsque deux bases de données sont soumises à des termes contradictoires (par exemple si l’une impose le repartage du tout et l’autre l’interdit ; ou les deux imposant l’utilisation de leurs termes sur leurs uniques termes), il peut être impossible de les combiner si l’une au moins des licences ne contient pas une clause expresse de compatibilité au bénéfice de l’autre.

À cet égard, il est très important de lire chacune des licences et de veiller à les respecter toutes, au risque sinon d’engager votre responsabilité. La licence ODbL est par principe incompatible avec la majorité des autres licences à réciprocité (telle que la CC By-SA 4.0), sauf mention expresse du concédant, et totalement incompatible avec les licences qui ne sont pas conformes à la définition de l’Open Data. Elle est en revanche parfaitement compatible avec la Licence Ouverte (version 1 et 2).

15/ Puis-je utiliser les données d’une base de données initiale pour vérifier la véracité de mes propres données sans avoir ensuite à placer les données sous licence ODbL ?

Il est possible de comparer les jeux de données, mais vous ne pouvez pas mettre à jour de façon automatique vos données, à moins que vous ne placiez votre base de données sous licence ODbL.

Néanmoins, vous pouvez apporter des corrections ponctuelles manuellement sans être tenu de placer votre base de données sous la licence ODbL (tout en ne dépassant pas l’usage normal qui pourrait être fait de la base de données initiale).

Vous avez d'autres interrogations ?

Vous pouvez saisir Open Data France concernant la lecture de la licence ODbL qui en est faite par ses membres (collectivités) ou l’usage de certains jeux de données sous cette licence. Les membres d’Open Data France s’engagent à vous répondre pour vous aider dans vos réutilisations des données sous cette licence.

Votre nom : Votre mail : Le ou les jeu(x) de données concernés (préciser l’URL) Votre questionnement

à envoyer à contact@opendatafrance.email

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Contexte

Les enjeux posés par l’open data du point de vue de la protection des données à caractère personnel

L’open data ne concerne pas initialement les données à caractère personnel (voir cette notion dans le glossaire en annexe). En effet, la majorité des informations du secteur public mises à disposition des internautes ne comportent aucune donnée à caractère personnel. Cependant, le champ de l’open data s’élargit. Par exemple depuis la Loi pour une République Numérique, il concerne des domaines tels que les décisions de justice, les données sanitaires, des données en matière de tourisme, d’énergie ou d’immobilier, ainsi que plus classiquement, celui des élus et des organigrammes de l’administration… De ce fait, un nombre croissant de données à caractère personnel sont susceptibles d’être concernées par les obligations en matière d’open data. L’essor sans précédent du numérique entraîne des possibilités croissantes de réidentification des personnes concernées par des données pourtant anonymisées. C’est pourquoi sur ce sujet, il faut régulièrement se référer aux mises à jour des recommandations de la CNIL.

Le développement de l’open data soulève donc la question de l’équilibre entre le droit d’accès à l’information publique, c’est-à-dire la transparence administrative, et la nécessaire protection des données à caractère personnel et de la vie privée. Ainsi, c’est le contexte dans lequel s’inscrit l’open data qui doit nous inciter à la vigilance : informatisation de la société, des administrations comme des acteurs privés ; diffusion spontanée de données personnelles par les internautes ; indexation de données nominatives par de puissants moteurs de recherche ; développement du Big Data...

Pour la CNIL, les objectifs parfaitement légitimes poursuivis par la politique d’ouverture des données publiques sont pleinement conciliables avec la protection des personnes et de leur vie privée. Plus encore, la prise en compte de cet impératif permettra de favoriser la confiance des différentes parties prenantes de ce mouvement (autorités publiques, citoyens, entreprises), qui constitue une condition essentielle de la réussite de toute politique publique. Pour ce faire, un cadre juridique existe depuis la fin des années 70 visant précisément à articuler les objectifs de transparence administrative et de protection des données personnelles. Ce cadre juridique a été renouvelé par la loi pour une République numérique et le RGPD. Ainsi, la loi pour une République numérique a, entre autres, renforcé les missions de la CADA et de la CNIL. La CNIL a par ailleurs été dotée d’un pouvoir de certification et d’homologation de processus d’anonymisation (voir cette notion dans le glossaire en annexe) des données. Elle publie régulièrement des packs de conformité pour accompagner au mieux les acteurs à protéger les données à caractère personnel ; dans ce cadre, elle a d’ailleurs annoncé la publication conjointement avec la CADA d’un pack open data. Ainsi, si la CNIL est le guichet unique pour toutes les plaintes des personnes estimant qu’il y a une atteinte à leurs droits en matière de protection des données à caractère personnel, la CADA demeure compétente pour répondre à des demandes d’accès portant sur des bases de données comprenant, par exemple des données personnelles. Sur la base de leurs compétences respectives, les présidents de ces deux organismes peuvent conjointement choisir de réunir la CNIL et la CADA en un collège unique lorsqu’il est question de la protection des données à caractère personnel dans le cadre de l’open data. Ainsi, elles pourront être amenées à examiner ensemble des demandes d’accès aux données.

Les dispositions générales

Bonnes pratiques

Dés que vous travaillez sur des données à caractère personnel, vous devez vous assurer que vous êtes habilités pour traiter de telles données. En cas de doutes, demandez à votre Délégué à la Protection des Données. Vous devez vérifier que le fichier contenant des données caractère personnel est référencé dans le répertoire idoine et prendre connaissance du niveau de risque(s) associé(s) à ce fichier. Vous devez aussi appliquer précisément les dispositions préconisées pour la protection de ces données.

Rappel sur les conditions requises pour ouvrir les données depuis la loi pour une République numérique

Les acteurs publics de plus de 3500 habitants et de plus de 50 agents qui ont des documents produits ou reçus dans le cadre d’une mission de service public et sous format électronique, doivent mettre en ligne, dans un format ouvert et réutilisable, les bases de données et les données régulièrement mises à jour, qui présentent un intérêt économique, social, sanitaire ou environnemental.

Pour les principaux documents produits et détenus par les administrations, contenant des informations publiques et figurant dans le répertoire des documents administratifs, ces dispositions sont effectives dès le 7 octobre 2017, soit un an après la promulgation de la Loi pour une République numérique). Pour les autres documents cela s’applique au plus tard le 7 octobre 2018.

La loi prévoit que les demandeurs peuvent solliciter, afin d’accéder à un document administratif, la publication en ligne de ce dernier. Cette diffusion publique doit être faite dans un standard ouvert, aisément réutilisable et exploitable par un système de traitement automatisé (en format .csv pour un tableur par exemple). Les documents communiqués par l’administration à la suite d’une demande doivent être mis en ligne ainsi que leurs versions mises à jour. Tout document communicable (à tous) est publiable sur Internet. Les documents comportant des secrets, ou portant atteinte à la vie privée des personnes ou des données à caractère personnel (voir glossaire) ne peuvent en revanche pas être publiés sauf sous certaines conditions (voir plus bas).

Les documents diffusables peuvent faire l’objet d’une libre réutilisation, dès lors qu’ils ne comportent pas de données grevées par des droits de propriété intellectuelle de tiers. Ce point est facilité puisque toute communication ou publication - « se fait dans un standard ouvert, aisément réutilisable et exploitable par un système de traitement automatisé ».

Les données contenant des données à caractère personnel

Nous rappelons que le principe général retenu est qu’il y a une interdiction de diffusion de données à caractère personnel dans le cadre de l’open data. Il y trois conditions alternatives qui sont prévues pour permettre la publication de documents comportant des données à caractère personnel :

• une disposition légale particulière,

• le consentement explicite des personnes concernées (voir ci-dessous),

• la mise en œuvre d’un traitement permettant de rendre impossible l’identification de ces personnes (anonymisation).

Plus précisément, le consentement est une notion encadrée par les dispositions applicables aux données à caractère personnel. Il joue un rôle de plus en plus central avec l’adoption du RGPD. C’est pourquoi, il faut être particulièrement vigilant dans les conditions encadrant l’obtention du consentement. Il s’agit d’une démarche active de la personne. Il doit être :

• explicite, spécifique, et éclairé,

• de préférence de forme écrite,

• produit librement par l’intéressé,

• préalable à la collecte des données (bonne pratique).

Par exemple, dans un formulaire en ligne, le consentement peut se matérialiser, par une case à cocher. Elle doit, par défaut, être décochée. Les questions à se poser pour une publication en open data des données à caractère personnel :

• La publication de la donnée à caractère personnel est-elle précisée par une loi ?

• La diffusion est-elle totale ou réservée aux intéressés ?

• De quand date la donnée à caractère personnel ?

• Si la donnée à caractère personnel ne concerne pas la vie publique de la personne et que la donnée est récente, le consentement de publication de cette donnée est-il explicite de la part de la personne concernée ?

• La personne est-elle vivante ?

Quelles conditions sont à réunir pour réutiliser des données contenant des données à caractère personnel ?

Le réutilisateur des jeux de données ouverts contenant des données à caractère personnel devra respecter les dispositions de la Loi Informatique et Libertés, ainsi que les termes de la licence. En effet, dès que le réutilisateur clique pour télécharger un fichier contenant des données à caractère personnel, il devient au sens du RGPD, responsable de traitement (voir glossaire). Ainsi, il devra obtenir le consentement des personnes dont les données à caractère personnel sont réutilisées (voir ci-dessus pour les conditions de validité du consentement). Il ne peut bénéficier du consentement obtenu par la collectivité puisqu’il est spécifique au traitement réalisé en vue de communiquer ou de diffuser les données. En effet, la réutilisation des données constitue un nouveau traitement distinct du premier (le responsable n’est pas le même, les finalités sont différentes).

Ainsi, outre quelques exceptions, « les documents contenant des données à caractère personnel doivent être rendus anonymes avant diffusion, sauf si une disposition législative (...) en prévoit autrement ou que l’administration concernée obtient l’accord des personnes intéressées. ». Voir article de la CADA.

Les données à caractère personnel à ne pas publier en open data

Les données à caractère personnel relevant de la vie privée et concernant les intéressés (citoyen, agent)

Une donnée à caractère personnel peut être transmise à la personne concernée. La règle veut que les documents administratifs contenant des informations à caractère personnel (voir glossaire) ne puissent être mis à disposition, ni réutilisables en l’état. Lorsque ces informations sont contenues dans des documents qui peuvent être publiés en open data tels que les délibérations, elles sont à anonymiser car cela fait partie de la vie privée de la personne. De tels documents peuvent être publiés soit :

• après mise en œuvre d’un traitement permettant de rendre impossible l’identification de ces personnes (occultation, pseudonymisation, anonymisation…)

• le consentement explicite de la personne concernée,

• une disposition légale particulière (par exemple au delà d’un délai de 50 ans).

Quant au Règlement Général sur la Protection des Données, il donne aux citoyens plus de contrôle sur leurs informations privées. Cet important texte sur le sujet n’apporte pas de nouveaux éléments en matière d’ouverture des données.

Les données de l’état civil

Seul le maire ou ses adjoints et les agents municipaux habilités à établir ou exploiter les actes d'état civil peuvent avoir accès au fichier de l'état civil. La Cnil précise que « les traitements mis en œuvre sur les fichiers d’état civil ne peuvent servir à d'autres finalités ou à alimenter d'autres fichiers, en particulier la constitution d'un fichier de population. Les informations nominatives enregistrées par les services d'état civil à l'occasion de l'établissement ou de l'actualisation d'un acte ne peuvent être utilisées que pour l'accomplissement des missions dont sont investis les maires en leur qualité d'officier de l'état civil et ne doivent être communiquées qu'aux destinataires habilités à les connaître. Les informations enregistrées ne peuvent, en particulier, être utilisées à des fins commerciales. Aucune cession du fichier de l'état civil ne peut avoir lieu. » Pour quelques missions de services publics de la commune (donc pour un usage interne de ces données), il est toutefois possible de produire des extraits pour alimenter « le fichier de vaccination de la commune, le fichier de recensement des jeunes en vue de la journée d'appel de préparation à la défense ou la commission administrative chargée de la révision des listes électorales, (mais) pour ces seules fins et dans la limite des textes existants. » « Les registres de l'état civil sont conservés à la mairie pendant cent ans à compter de leur clôture » mais « les informations collectées aux fins d'alimentation des bulletins statistiques de l'INSEE lors de l'établissement des actes de l'état civil ne doivent pas être conservées plus de six mois après leur transmission à l'INSEE ni utilisée par la mairie. ». Donc les données de l’état civil contenant des données à caractère personnel ne peuvent pas être publiées en open data, sauf délai de 75 ans.Pour ouvrir des données de l’état civil ne contenant pas de données à caractère personnel se reporter à la fiche Socle Commun des Données Locales.

Les données de bans de mariages

Les données de bans de mariages sont des données d’état civil (voir paragraphe précédent). Elles ne sont pas à publier en open data selon l’avis Cada, sauf après un délai de 75 ans. Ce sont des documents de l’état civil, ainsi les bans sont soumis au droit d'accès uniquement par les intéressés. Toutefois pendant la période de l’affichage, les bans de mariage sont des informations publiques, mais cet affichage contient des données à caractère personnel, une telle réutilisation ne serait possible, qu'après avoir recueilli le consentement des personnes concernées ou après anonymisation (voir glossaire) par la commune. La CADA considère que le code du patrimoine, qui régit l'accès aux archives publiques permet la publication à l'expiration du délai de 75 ans. Aller plus loin : http://cada.data.gouv.fr/search?q=bans+de+mariage

Les données de naissance

Les données de naissance sont des données d’état civil (voir paragraphe précédent). Elles ne sont pas à publier en open data, sauf après un délai de 75 ans. Si elles sont anonymisées, elles peuvent peuvent être publiées. Pour mettre les données d’état civil en open data, il est possible de s’appuyer sur le travail de standardisation d’OpenDataFrance relatif aux prénoms

Les données de décès

Les données de décès sont des données d’état civil, les mêmes règles s’appliquent (voir paragraphe ci-dessus). En plus de la rédaction de l’acte de décès et de sa mention en marge de l’acte de naissance, le maire a la responsabilité de nombreuses transmissions d’informations concernant le décès d’une personne. Le maire est responsable du traitement des données d’état civil. « Les informations nominatives enregistrées aux fins d'inscription d'un acte sur le registre de l'état civil ne peuvent être utilisées par les élus municipaux à des fins de message de félicitations ou de condoléances, ou ne peuvent être publiées dans la presse, que dans la mesure où, au moment de l'établissement de l'acte, les personnes concernées ont donné leur accord à ce message personnalisé ou à cette publication. Les informations collectées pour ces seules fins ne peuvent être conservées ni alimenter un fichier permanent. »

Les données transmises par internet doivent être chiffrées et les expéditeurs et destinataires identifiés.

Les dispositions sectorielles

Au-delà de ces dispositions générales sur l’open data, il existe de nombreuses dispositions sectorielles permettant la mise à disposition, à des fins d’intérêt général, de données publiques particulières ou de données détenues par des opérateurs privés, ainsi que des dispositions visant à favoriser la circulation de ces données dans la société par l’obligation de les mettre à disposition dans des standards ouverts et réutilisables.

L’open data des décisions de justice

Afin de faciliter l’accès au droit tout en protégeant la vie privée des personnes concernées par ces décisions, les données de décisions de justices « sont mis(es) à la disposition du public à titre gratuit dans le respect de la vie privée des personnes concernées », toutefois cette mise à disposition « est précédée d’une analyse du risque de réidentification des personnes ».

La pseudonymisation (voir cette notion dans le glossaire en annexe) en amont de ces données par la puissance publique et le contrôle de la CNIL sur leur réutilisation, en particulier sur l’absence de réidentification des personnes et sur le caractère effectif et continu du respect des droits des personnes concernées (rectification et opposition notamment), permettra ainsi de maintenir le délicat équilibre entre accès au droit et protection de la vie privée. Le décret en Conseil d’Etat qui doit déterminer les conditions d’application de ces nouvelles obligations devra en effet déterminer les modalités d’analyse de risque de réidentification des personnes et la CNIL pourra ainsi apporter toute son expertise sur ce sujet, dans le cadre de son avis sur ce décret. Il existe une foisonnante littérature sur cette question comme par exemple :

• Rapport de Loïc Cadiet sur "l'open data" des décisions de Justice,

• Livre Blanc sur l’open data jurisprudentiel...

L’open data en matière d’énergie

Depuis 2015, la CNIL participe aux travaux gouvernementaux portant sur l’anonymisation (voir glossaire) de données énergétiques. La loi pour une République numérique a prévu dans ce cadre de nouvelles dispositions, selon lesquelles les gestionnaires des réseaux de transport et de distribution d’électricité et de gaz naturel mettent à disposition du public les données détaillées de consommation et de production issues de leurs systèmes de comptage d’énergie, dans l’objectif de favoriser notamment le développement d’offres d’énergie, d’usages et de services énergétiques, « sous une forme agrégée garantissant leur caractère anonyme ». Pour ouvrir de telles données, il est recommandé de s’appuyer sur le pack de conformité compteurs communicants et de prendre connaissance du décret et de l’arrêté d’application.

L’open data de la santé

En matière de santé : la loi du 26 janvier 2016 de modernisation de notre système de santé, les données du système national des données de santé (SNDS) précise les conditions de leurs mise à disposition auprès du public, soit sous la forme de statistiques agrégées ou de données individuelles dans des conditions telles que l’identification, directe ou indirecte, des personnes concernées est impossible. La loi prévoit que la réutilisation de ces données ne peut avoir ni pour objet ni pour effet d’identifier les personnes concernées. La CNIL peut dès lors fixer les opérations techniques permettant l’anonymisation (voir glossaire) de ces données particulièrement sensibles (voir glossaire). Aller plus loin sur les données de santé : https://www.cnil.fr/fr/sante

L’open data de l’immobilier

Dans le domaine de l’immobilier, il est proposé une ouverture aux professionnels du secteur des données foncières détenues par l’administration fiscale.Pour ouvrir de telles données, il est recommandé de s’appuyer sur le pack de conformité logement social.

Questions fréquentes

Quelles sont les sanctions en cas de publication et de réutilisation de données à caractère personnel dans le non-respect de la loi ?

En cas de publication de données à caractère personnel non-conforme aux dispositions en matière d’open data (CRPA) et de protection des données à caractère personnel (Loi Informatique et Liberté) dans le cadre de la, la collectivité encourt des :

• sanctions administratives auprès de la CNIL. Elles peuvent atteindre 3 millions d’euros. Les sanctions prévues par le règlement européen (RGPD) applicable à partir du 25 mai 2018 pourront aller jusqu’à 20 millions d'euros ou 4% du chiffre d’affaire mondial, si cela se justifie. La CNIL peut également prononcer des avertissements pouvant être rendus public ;

• sanctions pénales qui peuvent aller de 1 500 euros à 300 000 euros d’amende et 5 ans d’emprisonnement en fonction du type de violation dont il est question (exemple : non-respect des finalités, absence d’information des personnes concernées).

En cas de réutilisation des informations publiques à des fins commerciales de manière non conforme à la licence ou aux prescriptions du code des relations du public et de l’administration, les montants sont désormais portés à :

• un million d’euro, en cas de réutilisation illégale ou non conforme aux prescriptions contractuelles des informations publiques ;

• deux millions d’euros, en cas de manquement réitéré.

Les montants sont différents lorsque les données sont utilisés à des fins non commerciales et peuvent atteindre 3 millions d’euros. Les sanctions prévues par le règlement européen applicable à partir du 25 mai 2018 pourront aller jusqu’à 20 millions d'euros ou 4% du chiffre d’affaire mondial, si cela se justifie. Par ailleurs, le réutilisateur peut également se voir appliquer des sanctions administratives prononcées par la CNIL (voir ci-dessus).

Aller plus loin : Article L 326-1 du CRPA et règlement européen de protection des données personnelles applicable à partir du 25 mai 2018.

Comment anonymiser les données à caractère personnel ?

La loi pour une République numérique fait évoluer les missions de la CNIL et, elle peut désormais homologuer des méthodologies d’anonymisation. À ce titre, les administrations pourront soumettre à la CNIL des méthodologies d’anonymisation pour homologation/certification de la CNIL. Ces méthodologies préciseront le traitement d’anonymisation mis en œuvre en fonction de la nature des données. La CNIL a relevé que les administrations doivent avoir une « vigilance particulière » à l’égard de la condition d’anonymisation (voir glossaire) et doivent mettre en œuvre des moyens « significatifs » mais qui ne doivent pas entraîner des efforts disproportionnés pour les administrations.

La CNIL et la CADA rédigent actuellement un « pack de conformité » en collaboration avec la DINSIC pour accompagner les administrations dans l’ouverture des données publiques.

Au sujet de la procédure à suivre pour la publication et l’anonymisation des données, l'INSEE présente dans « La gestion de la confidentialité́ pour les données individuelles », les cinq étapes à suivre en se basant sur ce même travail réalisé par Hundepool et al. (2012).

1. Il est donc nécessaire avant toute chose de déterminer la pertinence de l’anonymisation des données à publier : de quel type de diffusion des données s’agit-il ? Il s’agira aussi de se référer aux cadres législatifs nationaux et européens. De même, il faut cerner les enjeux de la publication des données au regard de leur type de diffusion. Par exemple, les fichiers MFR (Microdata File for Research purposes) sont réservés à la recherche scientifique et les fichiers PUF (Public Use File) sont accessibles par tous.

2. La deuxième étape porte sur la définition et la mesure des risques de divulgation et donc du choix de la ou des méthodes de protection des données en établissant tous les scénarios possibles: occultation, pseudonymisation...

3. La troisième étape concerne le choix des mesures de protection pour lesquels vous allez opter en fonction des critères fixés.

4. La quatrième et dernière étape porte sur la mise en œuvre et l’expertise du fichier qui a été produit en procédant à quatre étapes :

   1. le choix d’un logiciel de protection,

   2. la mesure des risques avec l’outil choisi,

   3. la quantification de l’information perdue,

   4. le contrôle du processus de protection et la réalisation d’un document synthétique sur les méthodes de protection avec un bilan de l’information perdue.

Au chapitre 3, Maxime B. présente les méthodes de protection des données, exemples à l’appui et par la résolution d’équations mathématiques.

En attendant le pack de conformité sur l’anonymisation, des ressources sur le sujet de l’anonymisation des données ont été rassemblées par l’Administrateur général des données, qui a également élaboré un outil informatique, intitulé Anonymizer. D’autres solutions existent, tel que l’outil d’anonymisation financé par des fonds européens : Amnesia.

Ressources

L'anonymisation des données personnelles vue par la CNIL : https://www.cnil.fr/fr/lanonymisation-de-donnees-personnelles

La publication en ligne et la réutilisation des données publiques (« open data ») : https://www.cnil.fr/fr/publication-en-ligne-et-reutilisation-des-donnees-publiques-open-data

Conclusion

Le triple filtre prévu (interdiction de publication de documents portant atteinte à la vie privée ; publication sous condition de documents comportant des données personnelles ; réutilisation de telles données dans le respect de la loi Informatique et Libertés) permet de garantir la protection des données des personnes concernées par les informations publiques.

L’étendue exacte des secrets protégés par la loi en matière de publication de données, les modalités de recueil du consentement des personnes concernées par celles-ci ou le caractère anonyme ou non des informations diffusées constituent des points d’interrogations récurrents de la part des différentes parties prenantes du mouvement de l’open data. Dans ce contexte, la CADA et la CNIL souhaitent améliorer l’accompagnement de ces acteurs en élaborant un « pack de conformité » dédié à l’ouverture des données publiques.

La présence des données à caractère personnel ne rend pas les documents communicables uniquement à l'intéressé. L'obligation d'open data par défaut persiste. Dans ce cadre l'anonymisation est présentée comme une étape préalable obligatoire à la diffusion sauf si elle engendre pour l’acteur public des efforts disproportionnés.

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Contexte

Les métadonnées sont de l’information structurée qui décrit, explique, localise ou facilite l’obtention, l’utilisation ou la gestion d’une ressource d’information.

Les métadonnées fournissent des informations permettant de comprendre des données. Par exemple, dans les achats de tous les jours, une étiquette fournit des informations sur un produit (composition, origine, date limite de consommation), c’est une métadonnée. Les métadonnées sont des “données sur les données”. Ce sont plus précisement une description normalisée du contenu des jeux de données publiées, c’est donc un élément essentiel dans le processus de publication des données.

Il est important de s’appuyer sur des formats de métadonnées reconnus pour s’assurer de leur pertinence (les données nécessaires) et de leur format (la façon dont on les a structuré et codifié). Les métadonnées ainsi homogénéisées permettent le fonctionnement des plateformes d’échange de métadonnées, qui peuvent à leur tour réduire les barrières d'accès aux ressources, conduisant à une meilleure visibilité, et donc augmentent leur potentiel de réutilisation. Dans de nombreux cas, c’est le portail qui héberge les données qui propose un format pour les métadonnées. Ceux-ci sont généralement en conformité avec les standards internationaux.

Utilisation des normes existantes

Il est important de s’appuyer sur des standards internationaux pour rendre les métadonnées cohérentes et exploitables. Il en existe de nombreuses (c’est un défaut...) mais elles ont des points communs et sont assez structurantes :

Normes et spécifications à usage général : ● Dublin Core pour les documents publiés (textes, images), http://dublincore.org/documents/dcmi-terms

Norme spécifique pour les ensembles de données : ● Vocabulaire pour les Catalogue de Données DCAT, http://www.w3.org/TR/vocab-dcat/

Usage spécifique de DCAT et d’autres vocabulaires pour soutenir l'interopérabilité des portails de données à travers l'Europe: ● Profil applicatif DCAT pour les portails de données en Europe, http://joinup.ec.europa.eu/asset/dcat_application_profile/description

Dans le cadre du projet OpenDataLocale, la norme DCAT, la plus courante et adaptée à l’open data, a été utilisée et légèrement simplifiée pour un usage courant. Le contenu et le format de métadonnées est décrit dans la spécification du jeu de donnée CATALOGUE du Socle Commun des Données Locales.

Quelles sont les métadonnées essentielles ?

Les données d'un catalogue sont essentiellement :

• Titre du jeu de données

• Description libre de l'objet et du contenu de la donnée

• Thème du jeu de données

• Nom de la structure qui diffuse la donnée

• Nom de la structure qui crée produit la donnée

• ​Nom de la structure qui gère la donnée

• Couverture spatiale sur lequel s'appliquent les données

• Début/Fin de la Plage temporelle couverte par les données

• ​Fin de la Plage temporelle couverte par les données

• ​Date de la première publication

• ​Fréquence de la mise à jour

• ​Date de la dernière mise à jour publiée

• Mots-clés permettant des recherches libres

• ​Licence appliquée sur le jeu de données

• Liste des formats dans lesquels sont publiées les données

• Code de la projection géographique quand cela s’applique

• Langue du jeu de données

• Liens vers les ressources accessibles

Focus sur certaines métadonnées

THEME​

Les thèmes peuvent être choisis et codifiés librement par les collectivités (voirie, transport, ...). Il est cependant souhaitable de les normaliser pour faciliter des recherches croisées et des sélections dans les gisements de données publiées au niveau national. Un projet de normalisation des thèmes est en cours d’élaboration. Il est recommandé de l’appliquer.

PRODUCTEUR

Ce champ permet de désigner le service ou l’organisme qui produit la donnée.

MOT_CLES

Ce champ permet d’attribuer des tags (ou mots-clés) pour faciliter la recherche des données. Les mots-clés sont totalement libres pour les collectivités. (par ex : “jardins”, “points d’eau”, “mobilité”).

LICENCE

C’est une donnée indispensable qui attribue une licence à un jeu de données. La pratique d’attribution d’une licence à un portail est abusive, même si elle permet de simplifier les déclarations des licences de chaque jeu de données qui héritent ainsi de la licence indiqué sur le portail. Les Licences décrivent le droits et devoirs des Producteurs et des Réutilisateurs du jeu de données concerné.

En pratique, dans le cas des données publiées à titre gratuit, et en vertu du décret publié par l’état sur les licences homologuées, le choix se porte sur deux licences :

• Licence Ouverte

• ODBL (OpenDataBaseLicence)

Un document produit dans le cadre d’OpenDataLocale présente les licences, leur portée et les avantages/inconvénients. Dans la majorité des cas, la Licence Ouverte, LO v2​, répond très bien aux besoins des collectivités. L'usage d'ODBL doit être fait avec prudence en raison des restrictions qu'elle engendre.

Gestion des métadonnées

Les métadonnées doivent être gérées pour assurer leur :

• Disponibilité : les métadonnées doivent être stockées où elles peuvent être consultées et indexées afin de pouvoir être trouvées

• Qualité : les métadonnées doivent être de qualité constante afin que les utilisateurs sachent qu'ils peuvent y faire confiance

• Persistance : les métadonnées doivent être entretenues au fil du temps

• Licence ouverte : les métadonnées devraient être disponibles sous une licence du domaine public pour permettre leur réutilisation

Le cycle de vie de métadonnées est plus grand que le cycle de vie des données :

• Les métadonnées peuvent être créées avant que les données ne soient créées ou capturées, par exemple, pour informer sur les données qui seront disponibles dans le futur.

• Les métadonnées doivent être conservées après que les données ont été supprimées, par exemple, pour informer sur les données qui ont été déclassées ou retirées.

Création des métadonnées

La création de métadonnées peut être prise en charge par des processus (semi)automatiques :

• Les propriétés de documents générées par des outils bureautiques, par exemple la date de création d’un document.

• Informations spatiales et temporelles capturées par des caméras, des capteurs

• Informations issues du processus de publication, par exemple l'emplacement de fichier ou l'URL.

Cependant, d'autres caractéristiques requièrent une intervention humaine :

• L'objet de la ressource (par exemple un lien vers le vocabulaire d’un sujet)?

• L'utilisation de la ressource (par exemple un lien vers une licence)?

• L'information sur la ressource (par exemple un lien vers un site Web ou de la documentation qui décrit la ressource)?

• Comment de l'information de qualité peut être incluse?

Stocker les métadonnées : quelles sont les options?

En fonction des exigences opérationnelles, les métadonnées peuvent être intégrées avec les données ou stockées séparément des données.

• Intégrer les métadonnées dans les données (par ex. onglet d’un fichier tabulaire) facilite l'échange de données.

• La séparation des métadonnées et des données avec des liens vers des fichiers de données correspondants rend la gestion plus facile. C’est le cas le plus courant que l’on retrouve dans la plupart des portails open data

Qualité des métadonnées

La qualité et l'exhaustivité des métadonnées de description des données influent directement sur leur visibilité et leur réutilisation.

• La précision des métadonnées : est-ce que les caractéristiques de la ressource suffisamment éditorialisées (par ex. indiquer le bon titre, une licence explicite)

• L‘exhaustivité des métadonnées : est-ce que toutes les caractéristiques pertinentes de la ressource sont documentées ? (par ex. la fréquence de mise à jour permet de s’assurer de la fraicheur de la donnée)

• La conformité des métadonnées aux normes acceptées : est ce que les métadonnées sont conformes à une norme spécifique de métadonnées ? (par ex. la description d’un ensemble de données doit être conforme à la normalisation du Socle Commun des Données Locales ou le référentiel international DCAT).

• La cohérence et la provenance des métadonnées : sont-elles basées sur des sources fiables (en général le Producteur) ?

• La capacité de traitement des métadonnées : les métadonnées sont-elles correctement lisibles par machine? (par ex. en rendant disponible les métadonnées en RDF et/ou XML, et non en texte libre).

Quelques exemples de fiches métadonnées

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Qu’est-ce une licence ?

Les finalités

Pour toute diffusion d’information, il est nécessaire de fixer un cadre juridique dans lequel se fait la mise à disposition des données ouvertes. On utilise pour cela une “licence” qui est attachée à chaque jeu de données.

Au carrefour du droit et de l’économie, les licences sont directement liées à la notion de propriété intellectuelle. Une licence est un document qui précise les droits et les devoirs des producteurs et des réutilisateurs de données. Elle présente la nature des engagements des parties prenantes dans le cas d’une collaboration ponctuelle ou récurrente. Elle crée ainsi un cadre qui assure la pérennité et la collaboration.

La démarche d’ouverture vise à faciliter la diffusion et la réutilisation des données publiques, sans faire de discrimination dans les possibles réutilisations. Le choix de la licence est donc fondamental. Un nombre réduit de licences sont aujourd’hui utilisées et recommandées par l’état.

Dans son rapport sur les redevances sur les données publiques, le magistrat de la cour des comptes Trojette souligne l’importance de ne pas noyer les utilisateurs dans les méandres de licences spécifiques : « dans un contexte de concurrence avec des données produites hors du service public, les contraintes ainsi imposées aux réutilisateurs doivent être aussi simples à appréhender et à accepter que possible : une jeune pousse du secteur des Big data, désireuse de réutiliser les données publiques de différentes administrations (et dans des pays différents) ne consentira pas à faire appel à un avocat pour étudier toutes les licences types non standards de l’administration.

Dès lors, l’administration devrait privilégier des licences-types auxquelles d’éventuelles licences spécifiques seraient automatiquement compatibles. Ces licences pourraient avoir l’avantage d’une formulation compatible avec les standards internationaux – pour la définition desquels la France a un rôle à jouer – et faire l’objet d’une traduction pour accroître l’attractivité des plateformes hors de France. »

Les licences “libres”

Les licences libres sont apparues au milieu des années 1980, lorsque le droit d’auteur a été adapté et étendu aux logiciels.

C'est une licence qui s'applique à une œuvre de l'esprit par laquelle l'auteur concède tout ou partie des droits que lui confère le droit d'auteur, en laissant au minimum quatre droits considérés fondamentaux aux utilisateurs :

• usage de l'œuvre ;

• étude de l'œuvre pour comprendre son fonctionnement ou l'adapter à ses besoins ;

• modification (amélioration, extension et transformation) ou incorporation de l'œuvre en une œuvre dérivée ;

• redistribution de l'œuvre, c'est-à-dire sa diffusion à d'autres usagers, y compris commercialement.

Ces libertés peuvent être soumises à conditions, notamment l'application systématique de la même licence, ou d'une licence prodiguant les mêmes droits aux utilisateurs, aux copies de l'œuvre et aux œuvres dérivées : un principe nommé copyleft.

Les licences libres sont donc :

• des contrats de licence non exclusive,

• de droits de propriété intellectuelle

• consentis pour le monde entier,

• par lesquels un titulaire de droits autorise un licencié à copier, modifier, utiliser et distribuer des données (et plus généralement une création)

Le succès d’une licence est rattaché à ses qualités intrinsèques, mais aussi à de multiples facteurs externes (ses “supporters” industriels ou communautaires, sa langue, les projets leaders, etc.).

Choix des licences

Dans les faits, sauf cas exceptionnels, les collectivités choisiront leurs licences parmi celles homologuées par l’état.

A ce jour (déc.2018), il s’agit essentiellement de :

• Licence Ouverte v2.0

• ODbL

Dans la majorité des cas, la collectivité produit par elle-même, ou par un prestataire, les données qu’elle publie en open data. La règle générale recommandée par l’état est l’utilisation de la Licence Ouverte, qui est une licence simple et dite “permissive” car les réutilisations engendrent peu de contraintes.

Lorsque les données ont été produites dans le cadre d’une collaboration forte avec la société civile (contribution citoyenne) ou lorsque les données sont considérées comme un “bien commun informationnel”, il peut être légitime de protéger cette ressources en imposant un partage à l’identique, c’est à dire la contribution des réutilisateurs à l’enrichissement de ces données. C’est le sens général des licences de type “copy-left” et particulièrement de la licence ODbL.

Licences Contributives versus Permissives

On distingue deux classes : les licences copyleft et les licences “permissives”.

• Au sein d’une licence copyleft, ou Contributive, les contributions et modifications doivent être reversées sous la même licence (« obligation de réciprocité »).

• Les licences permissives autorisent la diffusion de la création finale ou des contributions sous n’importe quelle autre licence tant que sont conservées certaines obligations généralement peu contraignantes (garder a minima le texte de la licence et indiquer le nom de l’auteur).

Règles et usages à respecter

Il est nécessaire préciser clairement sous quelle licence les données utilisées et/ou mises à disposition sont utilisées et utilisables sur une plateforme.

Pour cela il faut donner le nom complet de la licence choisie (et si on le souhaite, son acronyme) ainsi qu’un résumé des droits et restrictions qu’elle suppose. Il est également nécessaire de donner accès au texte complet de la licence (via un lien hypertexte ou un document à télécharger / à consulter en ligne).

Il peut être utile de préciser à l’utilisateur de quelle manière il devra créditer la plateforme. On peut également mettre à disposition du code informatique permettant d’établir un lien et d’associer des métadonnées à l’œuvre ou aux données d’origine.

Présentation des licences homologuées

Afin d’éviter la prolifération des licences, la loi pour une République Numérique a prévu la création d’une liste, fixée par décret, de licences qui peuvent être utilisées par les administrations pour la réutilisation à titre gratuit de leurs informations publiques, qu’il s’agisse de données ou de code source d’un logiciel (article D.323-2-1 du code des relations entre le public et l’administration (CRPA)).

Décret n° 2017-638 du 27 avril 2017 relatif aux licences de réutilisation à titre gratuit des informations publiques et aux modalités de leur homologation

Source Etalab > https://www.data.gouv.fr/fr/licences

Lorsqu’ aucune licence prévue dans le décret ne répond aux besoins d’une administration et qu’elle souhaiterait recourir à une licence spécifique, cette licence devra être homologuée par l’Etat, en l’occurrence la DINSIC, selon les critères fixés par le décret.

Licence Ouverte

Dans le cadre de la politique du Gouvernement en faveur de l’ouverture des données publiques, Etalab a conçu la « Licence Ouverte / Open Licence ». Cette licence, élaborée en concertation avec l’ensemble des acteurs concernés, facilite et encourage la réutilisation des données publiques mises à disposition gratuitement.

La publication du décret n° 2017-638 prévu par l’article L 323-2 du CRPA fait de la LO 2.0 la licence de référence pour les administrations pour la publication de données publiques, aux côtés de l’ODbL, et permet ainsi son utilisation par l’ensemble des administrations.

La « Licence Ouverte / Open Licence » présente les caractéristiques suivantes :

Une grande liberté de réutilisation des informations :

• Une licence ouverte, libre et gratuite, qui apporte la sécurité juridique nécessaire aux producteurs et aux réutilisateurs des données publiques ;

• Une licence qui promeut la réutilisation la plus large en autorisant la reproduction, la redistribution, l’adaptation et l’exploitation commerciale des données ;

• Une licence qui s’inscrit dans un contexte international en étant compatible avec les standards des licences Open Data développées à l’étranger et notamment celles du gouvernement britannique (Open Government Licence) ainsi que les autres standards internationaux (ODC-BY, CC-BY 2.0).

Une transparence des sources

• Une exigence forte de transparence de la donnée et de qualité des sources en rendant obligatoire la mention de la paternité.

Une volonté de standardisation au service de l'accessibilité des données publiques

• Une opportunité de mutualisation pour les autres données publiques en mettant en place un standard réutilisable par les collectivités territoriales qui souhaiteraient se lancer dans l’ouverture des données publiques.

Le logo de la « Licence Ouverte / Open Licence » est également librement réutilisable : https://www.etalab.gouv.fr/licence-ouverte-open-licence

Le texte de la licence : https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf

Pour l’essentiel, cette licence indique :

Le « Concédant » concède au « Réutilisateur » un droit non exclusif et gratuit de libre « Réutilisation » de l’« Information » objet de la présente licence, à des fins commerciales ou non, dans le monde entier et pour une durée illimitée, dans les conditions exprimées ci-dessous.Le « Réutilisateur » est libre de réutiliser l‘ « Information » :

• de la reproduire, la copier,

• de l‘adapter, la modifier, l‘extraire et la transformer, pour créer des « Informations dérivées », des produits ou des services,

• de la communiquer, la diffuser, la redistribuer, la publier et la transmettre,

• de l’exploiter à titre commercial, par exemple en la combinant avec d’autres informations, ou en l’incluant dans son propre produit ou application.

Sous réserve de :

• mentionner la paternité de l’ « Information » : sa source (au moins le nom du « Concédant ») et la date de dernière mise à jour de l’ « Information » réutilisée.

Suivi de paragraphes relatifs :

• aux données à caractère personnel,

• aux droits de propriété intellectuelle,

• à la responsabilité des producteurs et des réutilisateurs

• à la compatibilité avec d’autres licences existantes

• au droit applicable (français)

ODbL (pour OpenDatabaseLicence)

L'Open Database License (ODbL) est un contrat licence de base de données favorisant la libre circulation des données. Elle est issue du projet opendatacommons.org de l'Open Knowledge Foundation.

Source originale : https://opendatacommons.org/licenses/odbl/1-0/

Traduction française : http://vvlibri.org/fr/licence/odbl-10/legalcode/unofficial

Présentation générale

ODbL est comparable à Licence Ouverte sur les points :

• pas de responsabilité pour le producteur,

• possibilité de complète réutilisation y compris à des fins commerciale,

• sous réserve de respecter l'intégrité des données (ne pas les modifier, ne pas les détourner) et de citer la source (notion de paternité)

Elle ajoute cependant une notion très importante : Partage à l'identique (ou Share-Alike)

Elle est proche de la licence CC-BY-SA (BY pour paternité et SA pour Share-Alike), qui elle n'est pas homologuée puisque assez redondante avec OBdL. Certains continuent cependant à utiliser CC-BY-SA car elle inclut plus facilement la protection de ressources numériques qui ne sont à proprement parler des données : support multimédia (image, sons, vidéos, ..)

Approfondissement de la licence ODbL

De nombreuses considérations et questions ont été précisées dans le document suivant :

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Qu'est-ce qu'un portail open data ?

Lorsqu'une collectivité souhaite publier les données qu'elle possède, le choix de l'espace de publication est une étape importante. Les données publiées sont extraites des bases-métiers, nettoyées et formatées en vue de leur publication sous la forme de fichiers (le cas le plus général) ou d'interface applications (API ou WebService).

Deux services sont nécessaires : le stockage des données open data et le site de consultation des données publiées.

C'est surtout le site de consultation qui correspond à la terminologie "Portail open data". Le stockage des données est un point important, surtout sur les aspects de la Disponibilité, de la Performance et de la Sécurité, mais il n'est pas spécifique à l'open data (il s’agit d’un “entrepôt de données”).

Un portail open data est donc un espace de présentation des données publiques ouvertes avec les grandes fonctions suivantes :

• recherche des jeux de données,

• présentation détaillée des jeux de données,

• accès aux données brutes open data, sous différents formats, y compris API,

• présentation graphique des données quand cela est possible,

• outils d'extraction ou de transfert des données,

• dispositifs éditoriaux pour animer le projet open data.

Comment choisir un portail de publication des données publiques ?

Une liste de critères utiles pour choisir un portail open data a été établie.

Ces critères ne sont pas absolus : ils peuvent être complétés ou amendés par chaque collectivité au regard de leurs objectifs et de leurs priorités.

L’offre de portail Opendata en France

L’offre de service

Il existe plusieurs solutions techniques ou offres d’hébergement de portail en France, citons quelques exemples qui ne sont pas exhaustifs :

• ...

Les acteurs publics peuvent offrir des solutions d’hébergement (gratuites) pour les collectivités :

• Les portails des collectivités :

  • Régions
• Départements
• Les Syndicats Mixtes (périmètre généralement départemental)

  • SICTIAM (06)
• Les portails de métropole :

Il est bien entendu possible de faire réaliser un portail “à la demande” avec son service informatique ou un prestataire de service.

Les coûts

Portail spécifique développé à façon (dév. Interne ou sous-traité)

Les prix de mise en œuvre varient de 10 à 80 Keuro selon les fonctionnalités et le prestataire retenu. Les coûts de Maintenance doivent être pris en compte. Si l’application a un seul client (la collectivité qui a passé le marché), les coûts de maintenance et d’évolution ne seront pas mutualisés avec d’autres clients ce qui peut devenir un poste relativement important dans la durée.

Les prix de mise en œuvre et de maintenance sont connus assez précisément lors de la négociation. L’ensemble des coûts de développement et de maintenance sont mutualisés entre les différents clients, ce qui entraîne des coûts plus faibles pour chaque client. Normalement, cette optimisation devrait se retrouver dans le prix payé par les clients…

Les prix du marché sont assez variables, ils dépendent grandement des fonctionnalités retenues, des volumes, du trafic et de la négociation. Cela varie entre quelques Keuro et plusieurs dizaines de Keuro par an.

A voir avec les différents prestataires.

Portail hébergé au niveau inter-communal ou national

Dans le cas d’une offre d’hébergement des données par un acteur public de niveau supérieur (EPCI, Département ou Région) les coûts d’utilisation de la plateforme sont généralement nuls. C’est aussi le cas de l’hébergement sur le site de l’état data.gouv.fr

Dans le cas d’une offre mutualisée hébergée par un acteur public (ou privé), par exemple un Syndicat Mixte, un modèle économique peut être proposé, il est généralement beaucoup plus avantageux qu’une commande individuelle auprès d’un prestataire.

Quelques exemples de portail open data

Pages de publication intégrées au site web de la collectivité

Portail local dédié à la publication des données

Spécifique

Externalisé (plateforme en marque blanche)

Portail hébergé sur une structure territoriale de plus haut-niveau

Agglomération ou Métropole (EPCI)

Régional

3.4 - Espace de publication hébergé sur la plateforme nationale

Données publiées par la collectivité

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Contexte

Les données publiables

La Loi pour une République Numérique rend obligatoire la publication par défaut de toutes les données d’intérêt économique, social, sanitaire ou environnemental, qui ne sont pas protégées (données à caractère personnel, relevant d’un secret commercial ou pouvant mettre en danger la sécurité publique).

Selon les compétences détenues par la collectivité, cela représente de très nombreuses données. Face à cette volumétrie, il est utile de se concentrer sur quelques jeux de données dont l’intérêt est prioritaire. OpenDataFrance a souhaité proposé un socle de données prioritaires pour aider au démarrage de la politique d'ouverture des données complémentaires aux données prioritaires définies par l'Etat par voie réglementaire.

La méthode utilisée pour définir le socle commun des données locales

La demande

Dans le cadre du projet OpenDataLocale, nous avons d’abord posé la question aux collectivités engagées de longue date dans l’open data. Quelles données ont été le plus demandées ? Quelles sont celles qui sont le plus consultées, téléchargées ? quelles sont celles qui ont donné lieu aux réutilisations les plus fréquentes ?

La pertinence

Nous avons ensuite proposé 3 critères pour évaluer la pertinence des données :

• Politique : transparence, suivi des politiques publiques, exercice démocratique, ...

• Service & Economique : quelles sont les données à priori les plus utiles pour améliorer les services publics, que ce soit la création de nouveaux services, l’enrichissement de l’offre publique ou l’optimisation de services existants.

• Usage : accès à des informations publiques d’intérêt général (cartographie, statistique, description de l’espace public, ..)

L’accès à l’information

Nous avons aussi évalué la disponibilité et la relative facilité d’accéder à ces informations. La répartition des compétence entre plusieurs administrations, ou plusieurs services, peut par exemple rendre assez complexe la collecte de certaines données. La délégation de compétences auprès d’acteurs privés peut engendrer aussi des freins, tout comme la nature des données et leur mode de production (données peu structurées, données temps réel, ...).

Pourquoi définir des données prioritaires ?

L’identification de quelques données prioritaires présente plusieurs avantages :

• Identification des premières données publiées,

• Normalisation du contenu (nature et format des données),

• Mise à disposition d’outillage d’extraction et de publication,

• Constitution d’une base de données commune à toutes les collectivités.

Les collectivités peuvent bien entendu publier d’autres données en fonction de ses possibilités ou de ses propres priorités (un chantier prioritaire mené par la collectivité sur un thème particulier et qui nécessite -ou facilite- la publication de données spécifiques).

Les données prioritaires

Le Socle Commun des Données locales

Ces données sont décrites dans le Socle Commun des Données Locales. La nature des champs et leur format sont précisés.

Les réglementations existantes

En application de la loi pour une République Numérique, l’état a publié des décrets et arrêtés précisant le contenu de certains jeux de données qui sont considérés par l’état comme prioritaires pour constituer des référentiels nationaux.

Données essentielles de la commande publique

Ces données ont été intégrées dans le Socle Commun des Données Locales. Elles contiennent essentiellement : l’acheteur qui passe le marché, l’identifiant du marché, la date de notification, le(s) titulaire(s), l’objet, le montant, la nature, le lieu d’exécution, la durée du marché, les modifications apportées éventuellement sur ces données.

Données essentielles des subventions

Ces données ont été intégrées dans le Socle Commun des Données Locales. Elles contiennent essentiellement : l’autorité administrative qui attribue la subvention, la date de convention, le(s) bénéficiaire(s), l’objet, le montant, la nature, les dates et conditions de versement.

Plan Local d’Urbanisme

Publication des documents d’urbanisme selon les formats en cours d’établissement par e CNIG et ayant vocation à être publier sur le site Géoportail de l’urbanisme (https://www.geoportail-urbanisme.gouv.fr/a-propos/)

Vitesse Limite

Base nationale des vitesse maximales autorisées en vigueur sur leurs réseaux routiers (applicable à partir du 1 janvier 2018).

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Crédits : Ce document a été réalisé à partir du tutoriel publié par OpendataLab (Préfecture de région Occitanie) et le SICOVAL pour accompagner les communes se lançant dans l’opendata. Ce document s’est lui-même appuyé sur le guide d’utilisation de l’API Data.gouv produit par la mission Etalab : Il a été complété par OpenDataFrance lorsqu’il a été nécessaire de généraliser la fiche pour un usage au niveau national. Nous remercions la préfecture de région Occitanie et le SICOVAL pour leur contribution.

Contexte

Le portail national data.gouv.fr permet à tout acteur public de créer un domaine pour sa collectivité et d’y publier gratuitement tous les jeux de données qu’il souhaite ouvrir.

Qui est considéré comme producteur de données ?

Le producteur d'une base de données, entendu comme la personne qui prend l'initiative et le risque des investissements correspondants, bénéficie d'une protection du contenu de la base lorsque la constitution, la vérification ou la présentation de celui-ci atteste d'un investissement financier, matériel ou humain substantiel. Cette protection est indépendante et s'exerce sans préjudice de celle résultant du droit d'auteur ou d'un autre droit sur la base de données ou un de ses éléments constitutifs. Source

Les services publics certifiés

Les organisations inscrites sur la plateforme « data.gouv.fr » estimant assurer une mission de service public peuvent effectuer une demande en ligne pour être reconnue comme telle. Une organisation certifiée bénéficie d’un meilleur référencement. Pour devenir un service public certifié, inscrivez-vous sur le site en tant qu’organisation, puis effectuez la demande sur la page suivante : . Une vérification par email ou courrier vous sera demandée. Vous pouvez néanmoins commencer à publier vos jeux de données avant d’obtenir le badge de certification.

Qu'est qu'un jeu de données ?

Un jeu de données peut contenir plusieurs ressources (fichiers de données, fichiers d'explications, API, liens...) qui constituent un lot cohérent sur un thème donné. Par exemple «La Réserve Parlementaire», contiendra plusieurs ressources, typiquement un fichier par année.

Comment en tant que producteur, puis-je publier des jeux de données ?

Créez un compte sur « data.gouv.fr ». Dès que vous serez inscrit, vous pourrez «contribuez» et «publier un jeu de données».

Un jeu de données peut être publié simplement avec un titre et une ressource. Pour autant, il sera mieux référencé s'il contient des informations supplémentaires qui le décrivent : période couverte, fréquence de mise à jour, territoire couvert, thématiques…

Publier un jeu de données sur data.gouv.fr

Créer un compte

Créer l'organisation

Publication d'un jeu de données

Vous serez ainsi certain.e de publier vos données dans un format déjà défini, d'en vérifier la structure et la conformité à son schéma.

Affectation de Ressources à un jeu de données

Un jeu de données peut contenir plusieurs ressources (exemple : le jeu de données des statistiques des bibliothèques de Grenoble comprend la liste des 17 bibliothèques municipales de Grenoble, puis 6 éléments statistiques concernant ces bibliothèques (Nombre de prêts annuels de 2008 jusqu'à 2016, Nombre d'inscrits de 2008 jusqu'à 2016, Nombre d'emprunteurs de 2008 jusqu'à 2016, Nombre de visiteurs de 2008 jusqu'à 2016, Catégorie socio-professionnelle des emprunteurs depuis 2012 jusqu'à 2016....

Source originale : FING, juin 2017, v1.1, Licence : Creative Commons 3.0 Attribution France.

Version : v2.0, OpenDataFrance - Licence : CC-BY-SA, date : juillet 2022

Contexte

Le format CSV est le standard le plus simple et le plus répandu pour échanger des données numériques organisées en tableau. Que ce soit pour un projet open data ou pour tout autre projet d’échange de données, sa connaissance est primordiale. Pour réaliser un fichier de qualité, ce document propose 3 modes de lecture. ➔ Pour le lecteur averti

Aguerri aux données ? Ce simple encart devrait vous suffire.

➔ Pour le lecteur curieux

Le reste de ce document explique le pourquoi et le comment de la norme ainsi que les bonnes pratiques pour produire un CSV.

➔ Pour le lecteur néophyte mais pressé

En annexe (2 dernières pages), nous avons détaillé chaque étape pratique à partir des deux tableurs les plus répandus, Excel et LibreOffice Calc.

Qu’est-ce que le CSV ? Pourquoi le CSV ?

Le format CSV est le standard le plus simple et le plus répandu pour échanger des données numériques organisées en tableau. Il se présente sous une forme simple à interpréter par un logiciel ou toute autre forme de programme informatique. Mais il est également lisible par un humain car sa forme et sa syntaxe sont rudimentaires : il s’agit d’un fichier texte contenant des valeurs séparées par un caractère spécial — en anglais, CSV signifie Comma Separated Values soit littéralement “valeurs séparées par des virgules”. Voici comment se présente, dans un éditeur de texte, un fichier CSV simple :

Prénom,Nom,Age Marie,Durand,37 Bernard,Martin,29

Dans un tableur, ce fichier donnera le résultat suivant :

Si votre fichier est correctement produit, il sera lisible sans effort par des logiciels et/ou programmes informatiques usuels : tableurs, logiciels de statistique, logiciels de traitement de données spécialisés, etc. Autrement dit, si vous souhaitez partager correctement vos données, il est important de les publier sous forme d’un fichier CSV de bonne qualité.

Quelles données ?

Son aspect rudimentaire fait du CSV un format très simple à réutiliser. Ce côté rudimentaire à d’autres conséquences pratiques : il ne mémorise pas les couleurs, les onglets, les cellules fusionnées, les tailles de caractère... Il n’est adapté qu’à des tableaux simples où tous les enregistrements, c’est-à-dire toutes les lignes, ont la même forme. C’est strictement un format de données qui ne peut pas accepter de mise en forme. Certains tableaux, pensés comme des documents autant que des données devront faire l’objet d’une préparation pour être exporté en CSV.

Nommer un fichier CSV

Il n’existe aucune norme pour nommer un fichier mais rappelons quelques points de bon sens :

• un nom trop générique, comme “liste.csv”, risque d’entraîner des confusions

• un nom trop long sera difficile à manipuler

• un nom contenant des caractères spéciaux ou accentués risque de poser des problèmes d’interopérabilité

L’idéal est de vous fixer deux ou trois règles simples et de vous y tenir. Une bonne pratique consiste à composer ce nom avec une partie qui vous identifie (code INSEE ou SIREN). La présence d’une date peut aider. Par exemple : 34172_Geoloc_ArbresRemarquables_2014.csv renseigne sur le contenu sans avoir à ouvrir le fichier.

L’encodage du fichier

L’encodage d’un fichier c’est la norme utilisée pour coder chaque caractère par une suite de 0 et de 1 compréhensible par une machine. L’US-ASCII, l’ISO-Latin-1 et l’UTF-8 sont les plus répandus en France. L’encodage est le premier facteur de difficulté d’usage : il oblige les réutilisateurs à des opérations de conversion laborieuses ; certains outils ne comprennent pas certains encodages ; etc.

Le type de fin de ligne

Un fichier CSV est constitué de lignes représentant chacune un enregistrement. Par exemple, le code suivant contient 3 enregistrements (la première ligne, l’en-tête, n’est pas comptée) :

“Prénom”,”Nom”,”Note” “Marie”,”Durand”,”13,4” “Bernard”,”Martin”,”12” “Célestin”,”Lampion”,”9”

Détecter et modifier l’encodage et les fins de lignes de mon fichier

Il existe de très nombreuses façons de faire. Une des plus simples consiste à utiliser un éditeur de texte. Les éditeurs suivants (logiciels libres, non limitatif) gèrent plutôt bien les caractères de fin de ligne et l’encodage :

Geany, en particulier, affiche l’encodage en bas de l’écran et possède un menu spécial pour changer l’encodage et les caractères de fin de ligne. Voici les étapes nécessaires :

• Ouvrir le fichier concerné avec Geany.

• Observer au bas de la fenêtre le “mode” de fins de ligne et le “codage” du fichier

• Si le “mode” et le “codage” ne correspondent pas à “CRLF” et “UTF-8” :

  • Menu Document > Définir les fins de lignes > Convertir en CRLF (Windows)

  • Menu Document > Définir l’encodage > Unicode > Unicode (UTF-8)

  • Menu Fichier > Enregistrer. Et voilà !

Le séparateur utilisé

Le séparateur, ou délimiteur, est le caractère qui permet à un programme de distinguer les cellules les unes des autres. Dans le cas suivant le séparateur est la virgule : Prénom,Nom,Note Marie,Durand,13,4 Bernard,Martin,12 Célestin,Lampion,9

Le séparateur est aussi fréquemment un point-virgule, une tabulation [⭾] ou le caractère | (dit barre verticale ou tube en français, ou “pipe” en anglais). Le délimiteur peut encore être n’importe quel caractère du moment qu’il permette de séparer les champs sans ambiguïté.

Cependant, la norme CSV désigne la virgule comme le caractère à utiliser.

Cet usage peut nous poser problème à nous autres français, car cette dernière est notamment utilisée comme séparateur décimal… Un “3,5” caché au milieu de nombres entiers pourra passer inaperçu et provoquera des erreurs de lecture. Pour autant de nombreux outils de traitement du format CSV attendent par défaut l’usage de la virgule. Le séparateur idéal reste donc la virgule mais il faut alors encapsuler chaque champ entre des guillemets (au moins ceux qui contiennent une virgule) :

“Prénom”,”Nom”,”Note” “Martin”,”Durand”,”13,4”

L’en-tête de description des champs

La première ligne peut être utilisée pour nommer chaque colonne, on l’appelle alors l’en-tête (comme dans l’exemple ci-contre). Prénom,Nom,Date_naissance Marie,Durand,1972 Bernard,Martin,1978

L’en-tête n’est pas obligatoire mais il augmente sensiblement la qualité du jeu de données puisqu’il permet d’identifier chaque colonne et donc de lever d’éventuelles ambiguïtés. Il est plus approprié de nommer une colonne “Age” que de la désigner par “la quatrième colonne” cela permet au lecteur de comprendre rapidement le sens du champ concerné. De plus, au fur et à mesure de l’évolution du jeu de données, “la quatrième colonne” pourrait se trouver à une autre place. Bien nommer les colonnes rend le fichier et sa documentation plus compréhensibles et faciles à utiliser, comme le fait un index. Enfin, ce procédé est très facile à mettre en oeuvre. Il est dommage de s’en priver !

Contrôle syntaxique minimal

Il est très difficile de contrôler à la main des centaines de lignes d’un fichier CSV. Une erreur, quelle qu’elle soit, a pu se glisser dans les étapes successives de production des données. Un contrôle syntaxique automatique doit permettre de garantir qu’un fichier pourra être exploité par n’importe quel outil, logiciel ou programme informatique.

Pour ce faire, nous présentons ici CSV Lint, solution simple à mettre en oeuvre. Nous proposons également plus bas une autre solution pour les utilisateurs avancés, csvclean.

Documenter un fichier CSV

Sans documentation, un jeu de données quel qu’il soit, est très compliqué à utiliser. Les futurs utilisateurs ont besoin de comprendre ce qu’il contient, à quoi correspondent les différentes composantes du fichier, comment les données ont été collectées, etc. Document spécifique publié à part, il devrait idéalement contenir les rubriques suivantes :

• Le titre du jeu de données.

• La description du jeu : il s’agit de quelques paragraphes décrivant le jeu de données : son usage, son contexte et son mode de production, ses producteurs.

• La fréquence de mise à jour des données.

• La date de création du jeu.

• La date de dernière mise à jour du jeu.

• La couverture temporelle (ex. année 2014, période 2009-2016...).

• La granularité de la couverture temporelle (tous les 2 ans, annuelle, trimestrielle…)

• La granularité de la couverture territoriale.

• La license appliquée au jeu de données.

• La description de chaque champ du jeu de données :

  • le libellé du champ (le nom que vous avez retenu pour la colonne)

  • sa position (colonne 1 ou colonne 2 ou …)

  • sa description “sémantique” : que signifie-t-il ?

  • mais aussi sa syntaxe : sa longueur maximum, son type de contenu (chaîne de caractère ? nombre ? booléen ? date ?...), son format

En guise de conclusion pour aller plus loin : la norme de description Table Schema

Pour aller plus loin

Exemples

Un CSV de qualité avec Excel

Nous avons utilisé Excel 2016 pour rédiger ce court tutoriel.

• J’ouvre avec Excel mon fichier à convertir

• Je clique sur le menu “Fichier” en haut à gauche

• J’ai une interface spécifique qui s’affiche, où je peux sélectionner “Enregistrer sous…” (colonne de gauche)

Dans la partie principale centrale haute de l’écran je peux alors sélectionner, à l’aide d’un menu déroulant, les différents formats de fichier dont “CSV UTF-8 (délimité par des virgules) (*.csv)”

Si je veux changer le fichier d’emplacement, je clique sur le menu “Parcourir” grâce auquel j’obtiens une nouvelle fenêtre dans laquelle je peux préciser l’emplacement, mais aussi le type que je sélectionne dans un menu déroulant comme précédemment : “CSV UTF-8 (délimité par des virgules) (*.csv)”

• Mon fichier est prêt ! Je peux le publier avec sa documentation.

Un CSV de qualité avec LibreOffice Calc

Nous avons utilisé LibreOffice 6.4 (2022) pour rédiger ce court tutoriel.

• J’ouvre avec LibreOffice Calc (ou OpenOffice Calc) mon fichier à convertir

• Je sélectionne le menu “Fichier > Enregistrer sous...”

• Je sélectionne “[x] Éditer les paramètres du filtre” et “Texte CSV (.csv)” dans le menu déroulant des formats.

• S’ouvre alors la boîte de dialogue suivante qui permet de choisir l’encodage et le séparateur : je choisi comme indiqué ci-dessous

• Mon fichier est prêt ! Je peux le publier avec sa documentation.

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Méthode

Ce, a été réalisé par Datactivist pendant l’été 2017 dans le cadre du projet Dododata1 à partir d’une quinzaine de portails d’agglomération Les candidats retenus pour cette analyse étaient : Angers, Bordeaux, Grenoble, Lille, Lyon, Marseille, Martigues, Montpellier, Nantes, Nice, Paris, Poitiers, Rennes, Saint Malo, Strasbourg, Toulouse. 400 jeux de données ont été classifiés selon les rubriques suivantes : Administration, Budget, Citoyenneté, Commerce, Culture, Economie, Elections, Energie, Environnement, Equipements, Logement, Mobilité, Patrimoine, Politique, Religion, Santé, Sécurité, Social, Sport, Télécommunications, Tourisme, Transport, Urbanisme.

Des données ont été publiées dans chacun de ces domaines, mais sont valorisés ci-dessous uniquement les domaines pour lesquels au moins la moitié des acteurs ont publié ces données.

Liste des principaux domaines de publication

Administration

Dans la catégorie administration, c’est le catalogue des jeux de données qui arrive en tête. Un tel catalogue peut être mise en place dès la publication des premiers jeux de données. Si vous souhaitez mettre en place un catalogue de vos jeux de données, nous vous recommandons de vous reporter au travail élaboré par les membres d’Opendata France. 70% des acteurs ont publié les limites administratives de leurs communes et la moitié ont publié le découpage administratif des communes et des cantons.

Budget

Ces obligations s’inscrivent dans la politique de transparence de la vie publique. Elle permettra les agrégations de données et de disposer de moyens de connaissance sur la dépense publique.

Citoyenneté

Dans la catégorie Citoyenneté, 75% des collectivités du panel ont publié les statistiques d’état civil « décès », « mariages », « naissances » ou/et « prénoms » et un peu moins concernant les données sur les cimetières.

Côté vie politique, plus de 80% du panel publient les emplacements des bureaux de vote et un peu moins de 70% au moins une fois les résultats d’élections.

Culture

La moitié des acteurs publient leurs statistiques de prêt en bibliothèque.

Scolaire

Plus de 80% des acteurs publient la liste des établissements scolaires. Parfois il ne s’agit que des écoles primaires, parfois la liste s’étend aux collèges, lycées et autres établissements relevant de la formation initiale.

Environnement

Dans le domaine de l’environnement, 75% des collectivités du panel publient la liste des lieux concernés par les déchets : tri du vert, lieux d’apports volontaire, mobilier urbain.

Une grosse moitié des acteurs publient des informations sur les espaces verts, les équipements et les arbres.

La moitié des acteurs ont publié des données en relations avec les inondations (zones humides, zones inondables, débordements de cours d’eau).

transport

Dans le domaine de la mobilité, 88% des collectivités du panel publient des données sur le réseau cyclable et la moitié sur les équipements dédiés y compris les vélos en libre-service. 88% des acteurs publient des informations sur le réseau de transport en commun : points d’arrêt, circuits mais seulement 63% des acteurs publient les horaires de transport en commun, pourtant la publication des horaires est une obligation légale.

Plus de 60% des collectivités du panel publient des donnés sur les cheminements pour piéton (zones apaisées, cheminements doux, zones 20 ou 30).

La moitié des collectivités du panel publient des données sur le stationnement.

Sport

Dans le domaine du sport, 70% des collectivités du panel publient la liste des équipements sportifs.

La moitié publient la liste des associations sportives et les sentiers de randonnées.

Urbanisme

Dans le domaine de l’urbanisme, seul un acteur parmi les collectivités du panel ne publie pas les adresses de son territoire.

70% publient la liste des tronçons de rues , 63% le Plan Local d'Urbanimes (PLU).

La moitié des acteurs publient le relief et l’emplacement des toilettes publiques.

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Les étapes pour préparer les données avant publication

Identifier les données ou les bases de données

Cela exige de procéder par de multiples approches car il est rare d'avoir un inventaire exhaustif des données. Les services les plus compétents pour aider dans cette démarche sont les services d'archive, de documentation, d'informatique, d'information géographique, du numérique, d'observatoire, de pilotage, de dgs, de communication. On sera vigilant à récupérer des données brutes et non des données travaillées, comme par exemple sous forme de statistiques.

Identifier si une standardisation existe

OpenDataFrance propose le , il s’agit des données que les collectivités doivent publier en priorité, dans un format normalisé.

Un premier périmètre de données “prioritaires” a été établi autour des données suivantes :

• Catalogue : dictionnaire des données publiées

• Délibérations : données déclaratives (date, objet, type), sans données personnelles

• Marchés Publics : date, nature, montant et identification des tiers bénéficiaires

• Subventions : date, nature, montant et identification des tiers bénéficiaires

• Équipements Collectifs Publics : inventaire géolocalisé des équipements collectifs publics implantés sur un territoire

• État Civil : statistiques sur les prénoms des nouveaux-nés

• Base Adresse Locale : correspondance entre l'adresse et la géolocalisation précise

• Infrastructures de Recharge de Véhicules Électriques : localisation géographique et caractéristiques techniques des stations et des points de recharge pour véhicules électriques

• Normalisation des éléments de base : codification normalisée des champs habituellement utilisés

Choisir le modèle d’extraction, le format et la licence

Si une standardisation existe vous devrez essayer de l’appliquer au plus près. Cette opération peut être plus ou moins facile.

Votre modèle d’extraction est l’occasion de faire un premier niveau de nettoyage, autrement dit, l’occasion de sortir les données qui n’apportent rien au fichier tels que des identifiants techniques internes, ou des données qui font l’objet d’une législation qui empêchent leur publication.

Certains acteurs choisissent de publier leurs données dans plusieurs formats, comme le fait par exemple Bordeaux métropole qui pour ses données géographiques a choisi les formats suivants : ESRI Shapefile RGF93/CC45, ESRI Shapefile RGF93/Lambert93, Google KMZ, WebService OGC WMS, WebService OGC WFS, Fichier CSV, AutoCAD DWG.

En ce qui concerne la licence, elle aura été probablement choisie en amont et annoncée dans la délibération donnant le cadre de l’ouverture des données. Mais il est toutefois utile de se poser la question avant la publication de chaque jeu de données.

Si les données ne sont pas dans un système d’information : convertir les données dans un format ouvert

Il arrive que les données qui sont dans des fichiers, pour en faciliter les lectures et traitements sont "esthétisées": les cases des tableurs sont esthétisées, des cellules sont fusionnées, des textes sont en italique ou graissés... Certains fichiers de type tableur, peuvent être organisés en onglets ou bénéficier de "macro" plus ou moins complexes.

L'ensemble de ces aménagements spécifiques éloignent le fichier de son potentiel de réutilisation. Un fichier qui aurait au moins une de ces “fantaisies” ne répond pas aux standards de l'ouverture.

Si les données sont dans un SI : identifier les opérations d'exportation des données

Chaque base de données ou application métier a ses opérations préalables à l'exportation. Parfois, il y a aura un bouton ou un menu “exporter les données”, dans d'autres cas il sera possible de présélectionner les données avant de les exporter, dans d'autres cas encore, rien n'est prévu nativement pour exporter les données. Dans cette hypothèse, il faudra mettre en place une opération technique qui réalise l'export, opération souvent désignée comme "moulinette" ou "patch". La "moulinette" peut être une simple ligne de commande ou bien réalisée par un programme ou un outil d'extraction tels que les ETL (Extract, Transform, Load) : Talend, Knime, Pentaho Data Integration...

Ces derniers outils permettent d'extraire des données de n'importe quel format (fichiers, bases de données, pages html...) pour ensuite les traiter si besoin (changer le nom des entêtes, corriger les formats de dates, uniformiser les différences de nommage de certains champs, croiser des données entre-elles...) pour ensuite les réinjecter dans un entrepôt de données spécifique pour l'opendata, dans des fichiers csv ou tout autre format.

Certains standards, comme GTFS, demandent beaucoup de rigueur pour répondre à leurs exigences. L'export des données va exposer les données sous une nouvelle réalité. En effet, tant que les données sont dans leur environnement logiciel, elles ont une cohérence utile aux exploitations quotidiennes, mais sorties de leur contexte usuel, elles peuvent faire apparaître des "défauts" de qualité. Dans cette phase, il est vraiment important de faire un travail avec les agents qui s'occupent de l'alimentation des données à la source pour que les erreurs repérées puissent être corrigées au plus prés de l'alimentation source.

Si possible, on organisera le SI de sorte à ne pas activer la “moulinette” manuellement mais à appliquer des procédés automatisés. La solution usuellement retenue est la mise en place d’API, simple à mettre en place et appréciée des réutilisateurs.

Évaluer les données brutes

Lorsque les données viennent d'être exportées, il faut avoir un regard général pour cette nouvelle forme de présentation. Dans certains cas, il y a aura des défaut des formes; par exemples, les caractères accentués s'afficheront mal. Dans d'autres cas, il y aura des habitudes de services, les agents, dans leur travail quotidien, utilisant des abréviations ou diverses expressions, sorte d'argot professionnel. Une personne extérieure au service, n'aura pas facilement les significations des différents termes utilisés, à moins qu'ils soient documentés. Dans d'autres cas, la nouvelle mise en forme des données fait apparaître des notions dérangeantes : un lieu est privilégié, un élu est sur ou sous exposé, les effets des politiques du moment ne se voient pas dans les données qui sont représentatives des mois antérieurs.... La diffusion des données pourraient venir perturber les missions de services publics. Par exemple, diffuser les sections des tuyaux des réseaux d'assainissement pourrait favoriser des explorations dans les tuyaux dans lesquels il est possible de tenir debout. Enfin, l'ouverture des données pourrait être contrainte pour une disposition réglementaire spécifique.

Rendre les données intelligibles

Faire en sorte que la prochaine diffusion de données se fasse facilement

Le fichier de données brutes pour répondre aux attendus d’intelligibilités des humains et des machines a subit de nombreuses transformations. Certaines transformations sont des transformations de mises à niveau pour une ouverture facilitée. Il est souhaitable qu'elles soient le plus nombreuses possibles et qu'il ne soit plus obligé de revenir dessus pour chaque mises à jour. Les transformations de mises à jour sont le minimum des transformations qu'il faut opérer pour publier la nouvelle version du jeu de données. Par exemple, il est souhaitable que la publication mensuelle du fichier des marchés publics ne demande qu'un changement de date dans le nom du fichier. Cette étape peut être l'objet d'une réorganisation plus ou moins profonde du travail de production de données ou peut révéler un besoin de formation…

Valider les données prêtes à faire publier

Dans bien des cas, avant l'ouverture du jeu de données, l'agent producteur aura validé les données prêtes pour l’application. Et à son tour, il aura fait valider le fichier à un de ses responsables hiérarchiques. C’est l’occasion de conforter le rythme des mises à jour.

Mettre en scène la publication des données

Il faudra produire un texte qui présente le service producteur et les données afin de mettre en avant le jeu de données sur le site internet ou les éventuels messages dans les communiqués de presse ou sur les réseaux sociaux.

Il faudra également savoir si le jeu de données est présenté ou non sous forme de datavisualisation.

Il existe peut-être un événement ou un document qui est en lien avec l’ouverture de ces données. Par exemple, l’ouverture des données des vélos en libre service peut être présentée dans un encadré sur le flyers de la semaine de la mobilité.

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Contexte

La plateforme « data.gouv.fr » offre plusieurs moyens plus ou moins avancés d’intégrer les données disponibles en open data sur vos propres sites :

1. de manière unitaire si vous souhaitez n’afficher qu’un ou quelques jeu(x) de données particulier(s) ;

2. de manière plus générale si vous souhaitez afficher tous les jeux de données relatifs à un territoire ou à une organisation ;

3. pour une gestion fine de l’habillage et des données affichées, nous vous recommandons l’API ;

4. pour avoir votre propre portail fondé sur le moteur de la plateforme.

Ces différents cas d’intégration correspondent généralement à différents profils :

1. un journaliste traitant d’une problématique donnée va être intéressé par l’inclusion de jeux de données directement au sein de son article ;

2. une mairie va être intéressée par l’intégration des jeux de données relatifs à son territoire sur son site internet ;

3. une association pourrait être intéressée par la création d’une page personnalisée compilée à partir de données issues de sources multiples ;

4. un pays se lançant dans l’open data va chercher à créer son propre portail.

Méthodes d'intégration

Celles-ci ont été décrites initialement dans la documentation de data.gouv :

Intégration ponctuelle de jeux de données

Chaque jeu de données est intégrable sur n’importe quelle page en ajoutant quelques lignes de HTML, deux versions existent :

ET En remplaçant l’IDENTIFIANT DU JEU DE DONNÉES par l’identifiant disponible sur sa page dédiée, dans l'onglet Métadonnées sous la rubrique ID :

La première version de code proposée est accessible directement depuis l'onglet Action du jeu de données souhaité. Il suffit de copier le code proposé dans la rubrique "INTÉGRER SUR VOTRE SITE"

Selon le code utilisé, vous verrez apparaître l'une ou l'autre des versions d'intégration sur votre site. Sur cet exemple le premier cartouche correspond à la première version du code proposé et le second à la seconde version. Ces cartouches contiennent les informations relatives au jeu de données choisis de la manière suivante :

Voici un autre exemple d’intégration sur le blog d’Etalab, ici avec les données de consommation d’électricité des ministères. Il est possible d’intégrer plusieurs jeux de données à la fois en dupliquant la ligne correspondant à l’élément <div> avec un nouvel identifiant. Vous pouvez personnaliser l’apparence du rendu du cartouche grâce à la classe CSS dataset-card.

Intégration pour une organisation ou un territoire

Le mécanisme pour afficher tous les jeux de données relatifs à une organisation ou un territoire est le même que celui pour l’intégration d’un seul jeu de données décrit précédemment. Cet usage est recommandé si vous êtes responsable de cette organisation ou de ce territoire et souhaitez faire la promotion des jeux de données associés. Par exemple dans la cadre de la loi Notre, il est demandé aux communes de plus de 3500 habitants de rendre accessible en open data certaines données. L’usage de la plateforme « data.gouv.fr » pour déposer ces données puis les intégrer sur son propre site est rendue possible par cette solution.

Intégration d’une organisation

En remplaçant l’IDENTIFIANT DE L’ORGANISATION par l’identifiant disponible sur sa page dédiée (l'ID se trouve en bas de page de description de l'organisation, dans les informations techniques, rubrique ID). Vous devriez alors voir apparaître sur votre site un cartouche contenant les informations relatives aux jeux de données de cette organisation. Optionnellement, il est possible d’afficher une barre de recherche pour laisser la possibilité au visiteur de filtrer la liste des jeux de données affichés. Cela est activé en passant l’option {withSearch: true} à la méthode loadOrganization() ci-dessus.

L'exemple ci-dessous montre l'intégration des jeux de données de la ville de Grenoble sur une page web avec cette méthode et l'option de filtrage activée :

Intégration pour une page personnalisée

Voici un exemple de restitution :

Données publiées sur data.gouv.fr :

Données vues sur le site web de Castelnaudary.fr via métaclic

Intégration d’un portail open data complet avec Udata

Les outils développés sont disponibles en open-source. Ils sont le fruit d’un effort international pour créer des synergies autour de la donnée ouverte et mutualiser nos efforts de développement. La gouvernance est inclusive et la licence est permissive. Nous participons à l’animation autour du développement de la plate-forme car nous souhaitons produire un bien commun réutilisable par tous.

Exemples

Le code est alors :

> via l’API METACLIC

> Via l’API data.gouv

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Contexte

Quelque soit le jeu de données publiés par les collectivités, certains champs doivent avoir un format unifié au niveau national pour éviter les disparités dans leur présentation. Dans quelques cas, il est aussi indispensable que des champs “pivots” soient respectés pour faciliter les liens entre les bases et la récupération de nombreuses données contextuelles. Enfin, de bonnes pratiques émergent pour produire des jeux de données identifiables, exploitables et de qualité. Bien qu’un peu éloigné de l’open data, on pourra aussi consulter le Référentiel Général d’Intéropérabilité, ou RGI, produit par l’Etat (DINSIC) qui décrit des standards d’interopérabilité : information sur les formats d’échange (synthèse des standards retenu pour l’interopérabilité syntaxique), interopérabilité sémantique (définition à retenir par tous pour les principaux concepts liés à l’interopérabilité, etc.). Nous rassemblons ici quelques règles générales et bonnes pratiques, sans prétendre à l’exhaustivité.

Format des données

Des nombreuses données sont soumises à des normes (plus ou moins connues ou appliquées) nationales ou internationales. Les lister ici serait fastidieux, probablement incomplet et peu opérationnel. Nous indiquons ci-après des champs courants dans les jeux de données produits par les collectivités qui gagneraient à respecter des standards reconnus. Leur normalisation favorise l’interopérabilité et la compréhension des données, donc leur qualité et réutilisabilité.

• Date : format AAAA-MM-JJ (2016-07-23), conforme à la norme internationale ISO8601 (voir aussi https://fr.wikipedia.org/wiki/Heure)

• Heure (pour les données temps-réel notamment), heure/minutes/seconde et période de temps : format HH:MM:SS (éventuellement suivi d'une virgule ',' puis de décimales de seconde), conforme à la norme internationale ISO8601. (voir aussi https://fr.wikipedia.org/wiki/Heure)

• Nombre : dans le cas des données décimales, on privilégiera le séparateur décimal point “.” (la virgule étant réservée à la séparation des champs dans un fichier CSV)

Il existe aussi des référentiels pour codifier les langues (ISO 639-1, cas des données régionales), pour les pays (ISO3166), pour les monnaies (ISO 4217), etc. que nous ne détaillons pas ici.

• Adresse : la norme officielle pour coder les adresses est assez lourde. Elle est décrite dans le document AFNOR NF Z 10-011 En pratique, nous recommandons de décrire une adresse avec les champs suivants :

  • numero

    • Titre : Numéro d’adresse

    • Description : Numéro d’adresse dans la voie et, dans le cas des voies sans adresse, la valeur “99999” est attendue

    • Type : nombre entier

    • Exemple : 130

  • suffixe

    • Titre : Information suffixée qui complète et précise le numéro d’adresse

    • Description : Indice de répétition et/ou complément d'adresse (nom d’entrée d’immeuble) normalisé en minuscules sans espace

    • Type : chaîne de caractères

    • Exemple : ter

  • voie_nom

    • Titre : Nom complet de la voie

    • Description : Concaténation du type et du nom de la voie en majuscules et minuscules accentuées Le nom de la voie peut également être un lieu-dit

    • Type : chaîne de caractères

    • Exemple : Rue du Rempart

  • commune_nom

    • Titre : Nom officiel de la commune

    • Description : Texte libre qui permet d’identifier rapidement la commune dans laquelle l’adresse est située

    • Type : chaîne de caractères

    • Exemple : Brest

• Géolocalisation :

  Les adresses peuvent être exprimées dans un des deux référentiels de référence :

  • WGS84 Ce référentiel est proposé car cela correspond à un usage très courant, notamment un contexte international et la plupart des équipements et services de géolocalisation (GPS). Il s’applique à certaines zones du territoire français (DOM-TOM).

  • RGF93 (ou Lambert93) Ce référentiel est préconisé par la réglementation pour le territoire métropolitain français. Il est cependant peu utilisé dans un contexte international.

• Cas des Longitudes et Latitudes exprimées dans le format WGS84

  • Exprimé LAT (Latitude) et LONG (Longitude)

  • Nombre de décimale : Le nombre de décimale dépend de la précision de la localisation. 5 décimales correspondent à une précision au mètre et permettent de couvrir la majorité des usages.

  • Exemple : Latitude : 48.87079, Longitude : 2.31689

• Cas des Longitudes et Latitudes exprimées dans le format RGF93

  • Généralement appelé X (pour la longitude) et Y (pour la latitude)

  • Exemple : Centre-ville de la ville de Tours :

    X=1525240,99 (ou EST) et Y =6246398,33 (ou NORD) dans RGF93-CC47

  • Ce qui correspond dans le référentiel WGS84 à : LAT=47,39414(59) LONG=0,68467(36)

  • Les outils géomatiques savent générer ou convertir les coordonnées d’un point dans un référentiel ou un autre.

Format des données “pivots”

Certains champs peuvent servir de “pivots” au niveau national. Ce sont des champs qui permettent de retrouver de façon univoque, claire ou complète des données dans des bases de référence nationale (en particulier dans les bases du Service Public de la Données).

On rappelle les principaux ci-après :

• Identification d’une collectivité

  • Code COG (connu aussi sous le nom de code INSEE) :

    • Le Code officiel géographique (COG) est la référence légale éditée par l’Insee, qui rassemble les codes et libellés des communes, des cantons, des arrondissements, des départements, des régions, des collectivités d'outre-mer, des pays et territoires étrangers. On se réfère souvent à l'un ou l'autre de ces codes géographiques en parlant de code Insee :

      • Le code région contient deux chiffres.

      • Le code département contient deux à trois chiffres ou lettres. Il se retrouve sur les plaques d'immatriculation.

      • Le code arrondissement contient un chiffre.

      • Le code canton contient deux chiffres.

      • Le code commune contient cinq chiffres ou lettres (concaténation du code département et de la codification de la commune de deux à trois chiffres). Il est le plus employé.

• Code SIRENE :

  • Cet identifiant est plus précis qu’un code INSEE lorsqu’un désigne un acteur public, car il n’existe pas de code INSEE pour un EPCI (Etablissement Public de Coopération Intercommunale)

  • Identifiant du Système d'Identification du Répertoire des Entreprises (et dans notre cas aussi des Collectivités)

  • Chaîne numérique 9 (correspondant à l’entité juridique)

  • Ex : 797681236

• Code SIRET :

  • Cet identifiant est à choisir lorsque l’on veut désigner un établissement au sein d’une organisation. Cela est souvent pertinent lorsque l’on s’intéresse à un budget ou une décision locale.

  • Identifiant du Système d'Identification du Répertoire des Établissements

  • Chaîne numérique 9+5 (ces 5 derniers chiffres correspondant à l’établissement de l’entité juridique indiquée par la première chaîne de 9 chiffres)

  • Ex : 79768123600015

• Identification d’une entité juridique (entreprises, organismes -dont les collectivités- et associations)

  • Code SIRENE ou SIRET selon si l’on parle de l’entité juridique ou de l’établissement (une personne, un budget) : Voir ci-dessus

  • Se voient attribuer un numéro SIREN par l’INSEE :

    • des personnes physiques :

      • toutes celles exerçant une profession non salariée de façon indépendante (professions libérales, commerçants, etc.) ;

      • des loueurs de biens immobiliers non inscrits au RCS mais signalées à l’Insee à la demande des centres des impôts ;

      • et, à des fins de gestion donc hors accès public, les associés-gérants signalés à l’Insee par les URSSAF

    • les groupements de droit privé non dotés de la personnalité morale (indivisions, sociétés de fait, sociétés en participation, etc.)

    • et toutes les personnes morales, c’est-à-dire :

      • les personnes morales de droit privé (SA, SARL, GIE, sociétés civiles, associations, syndicats, etc.) ;

      • les personnes morales de droit public soumises au droit commercial (entreprises publiques) ;

      • les personnes morales de droit étranger ayant un établissement ou un bureau de liaison en France ;

      • les personnes morales (ou organismes assimilés comme telles) soumises au droit administratif (comme les institutions et services de l’État, les collectivités territoriales, etc.) ;

      Il existe cependant une exception pour les personnes morales : les associations loi de 1901 n’ont l'obligation d’avoir un SIREN que dans trois cas seulement :

      • si elles sont employeuses ;

      • si elles sont soumises à la TVA ;

      • si elles souhaitent l’obtention de subventions auprès d’administrations publiques.

• Identification d'une association : code RNA (RépertoireNational des Associations)

  • L'inscription d’une association au RNA donne lieu à une immatriculation sous la forme d'un “numéro RNA”, composé de la lettre W suivie de 9 chiffres. (ex. W123456789)

  • Cet identifiant est unique mais les données associées dans la base RNA ne sont pas toujours mises à jour (il s’agit plutôt de l’acte de déclaration à la création de l’association). La base SIRENE fournit généralement des informations plus fiables.

Produire des données de qualité

Produire un fichier CSV de qualité :

• Un travail approfondi a été mené par plusieurs acteurs sous la conduite de la Fing pour énoncer des règles de base de production et de contrôle d’un fichier tabulaire au format CSV.

Documenter le jeu de donnée

Documenter dans un fichier séparé (ou autre) le sens des données contenus dans le jeu de données :

• nom explicite de chaque champ (pas uniquement des codes plus ou moins compréhensibles),

• portée de chaque donnée et condition particulière de production,

• sens des codifications lorsque le cas se présente

On trouvera un exemple de documentation dans les jeux de données du Socle Commun des Données Locales.

Produire des données selon plusieurs formats.

• Données tabulaires

  • Le principe de l’opendata est de publier des données à un format ouvert non prioritaire, on privilégiera donc le format “CSV” et le format “ODT” (lisible par un logiciel libre tel que Libre Office)

  • On acceptera le format “XLS” qui, bien que de propriétaire (Microsoft), peut être lisible par des logiciels libre comme LibreOffice.

  • On pourra aussi produire les données au format "XML" qui est un standard ouvert et reconnu pour les jeux de données de structure un peu plus complexe (xml)

• Données textuelles

  • Format “TXT” :

  • Format “JSON” : JSON est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Le principal avantage de JSON est qu’il est simple à mettre en œuvre par un développeur tout en étant complet. Au rang des avantages, on peut également citer : peu verbeux, ce qui le rend lisible aussi bien par un humain que par une machine.

  • ODF (ou ODT) : OpenDocument est un format ouvert de données pour les applications bureautiques : traitements de texte, tableurs, présentations, diagrammes, dessins et base de données bureautique. OpenDocument est la désignation d'usage d'une norme dont l'appellation officielle est OASIS (Open Document Format for Office Applications, également abrégée par le sigle ODF)

  • RDF

• Données géographiques

  • GéoJSON

  • Shapefile

  • OWS

  • KML

  • ...

• Données temps-réel

  • (rédaction ultérieure)

Source : OpenDataFrance - Licence : CC-BY-SA

Version : v2.0, date : juillet 2022

Nous indiquons ici les prestataires Conseil et Formation connus pour leur capacité à faire de l'accompagnement open data. Il en existe sans doute d'autres de qualité. Si vous connaissez des prestataires qui méritent de figurer dans cette liste, merci d'adresser un message à contact@ opendatafrance.email