DMP/PGD

Notions générales

Un Plan de Gestion de Données (PGD (ou DMP pour Data Management Plan en anglais¹)), c'est un document dans lequel on décrit la façon dont les données utilisées ou produites seront gérées durant un projet de recherche. C'est un document descriptif qui est amené à évoluer en tout au long du projet et qui sert principal d'aide ou de guide pour les membres de ce projet.

Je sais bien que ça peut paraître contraignant et long, "encore un truc administratif relou à gérer", mais je peux vous garantir que les DMP m'ont souvent aidé à bien prévoir les besoins en terme d'accès aux données et à leur stockage. Ça évite les mauvaises surprises au milieu de missions de terrains durant lesquelles on n'a pas toujours accès aux infrastructures (ou consommables) nécessaires.

Les plans de gestion de données sont aussi là pour garantir que les données seront décrites et déposées, et ainsi assurer les principes FAIR (je vous renvoie sur la page du CCSD du CNRS sur le FAIR). La façon dont les données sont créés, stockées et utilisées durant le projet, ainsi que leur statut et dépôt après sa fin.

¹. Oui, alors je sais que j'alterne beaucoup entre "DMP" et "PGD". Pour des raisons pratiques, DMP est plus souvent usité, même si c'est de l'anglais. Les deux acronymes sont totalement interchangeables et c'est moi qui écris, donc c'est la vie ! ↩

DMP - OPIDoR

Nous avons beaucoup de chance, il existe un outil d'aide à la rédaction des PGD, DMP-OPIDoR. Il est opéré par l'INIST (l'Institut de l'Information Scientifique et Technique) et vous êtes guidés tout au long de la rédaction de votre PGD. Avant de passer à la rédaction (et après vous être créé un compte, évidemment), j'insiste un peu sur le fait que votre PGD n'est jamais définitif, vous pouvez le reprendre autant que vous le désirez et que vous n'avez pas à tout remplir du tout, plein de catégories ne seront pas adaptées à vos projets.

Dans les sections qui suivent, nous allons voir très brièvement comment réaliser un PGD. Nous n'entrerons pas dans les détails car il existe déjà beaucoup de supports et de guides en ligne, certains sont d'ailleurs indiqués dans la page des ressources.

Créer son PGD

Quand vous vous identifiez dans DMP-OPIDoR, vous accédez à votre tabe;au de bord sur lequel sont affichés vos DMP et ceux auxquels vous êtes associés (si l'association a été faite sur la même adresse mail que celle que vous utilisez pour votre compte). Si jamais c'est votre première fois ici, le tableau est probablement vide, pas de soucis, on va aller sur "Créer un plan".

Les première étapes sont celles de création initiale du plan.

1. Choisir entre la création ou la ré-utilisation d'un modèle
2. Si vous créez vote PGD dans le cadre d'un projet, il faut ensuite choisir "Pour un projet de recherche". "Pour une entité de recherche"est plutôt adapté à une plateforme ou une unité de service, par exemple (comme c'est d'ailleurs indiqué en dessous).Dans le cadre d'une plateforme, cela permet de donner un cadre (technique, légal, la façon dont elles seront citées) à l'ensemble des données produites.
3. Choix de la langue (bon là, peut-être pas besoin d'explications)
4. Le choix du modèle nous amène à la section suivante. Ici, j'en profiterai pour dire que "structuré" signifie que le modèle produira un PGD lisible par les machines (machine-actionable DMP). L'export au format JSON ou XML pourra alors être lu automatiquement par des entrepôts de données, des systèmes de moissonnage ou des agences de financement. C'est la direction recommandée aujourd'hui, notamment par Science Europe. Un modèle "non structuré" reste un document textuel libre, plus simple à remplir mais moins interopérable.

Les modèles

Comme vous pouvez le voir, DMP OPIDoR propose un modèle, Science Europe , par défaut. Il faut donc le prendre. C'est un modèle global à l'échelle européenne, c'est pas si mal. En dessous, vous pouvez choisir d'autres modèles, notamment par institution. Si vous y tenez vraiment, prenez-les, mais bon...

Bon, ça n'engage que moi, mais je vois peu l'intérêt de créer plein de variations par institution, par groupe… À moins que votre unité ou plateforme soit une usine à ANR/ERC, et dans ce cas… je garde mes remarques pour moi.

Les recommandations

Dans DMP OPIDoR, les recommandations sont des guides contextuels qui s'affichent à côté de chaque champ du formulaire. Elles expliquent ce que l'on attend comme réponse, donnent des exemples concrets et orientent vers les bonnes pratiques disciplinaires ou institutionnelles.

Ces recommandations varient selon le modèle choisi. Pour un même modèle (par exemple ANR), plusieurs jeux de recommandations peuvent être disponibles : celles de l'ANR elle-même, celles d'un établissement partenaire, ou des recommandations génériques Science Europe. Il vaut mieux choisir le jeu le plus adapté à votre contexte avant de commencer à remplir votre plan.

Ne négligez pas ces recommandations, elles sont souvent très bien faites et vous éviteront de rater des informations importantes. Et non, personne ne les lit jamais. C'est dommage.

Les licences

Choisir une licence pour ses données est une étape souvent sous-estimée, mais elle est indispensable : sans licence explicite, les potentiels réutilisateurs ne savent pas ce qu'ils ont le droit de faire avec vos données, même si elles sont déposées dans un entrepôt public.

Pourquoi choisir une licence ?

Une licence clarifie légalement les droits d'utilisation, de modification et de redistribution. Elle protège également l'auteur en imposant des conditions (comme la citation obligatoire).

Les Creative Commons

Les licences Creative Commons sont les plus utilisées pour les données et les documents de recherche. Elles se composent de modules combinables :

Les licences les plus courantes en recherche ouverte sont :

• CC0 — renonciation totale aux droits, domaine public. Maximum de réutilisabilité.
• CC BY 4.0 — attribution obligatoire. C'est la licence recommandée par défaut pour les données de recherche financées sur fonds publics.
• CC BY-SA 4.0 — attribution + partage dans les mêmes conditions.
• CC BY-NC 4.0 — attribution + usage non commercial seulement. À éviter si vous souhaitez que vos données soient vraiment FAIR.

Pour les données de recherche, CC0 ou CC BY sont les choix à privilégier. Les modules NC et ND restreignent fortement la réutilisation et sont déconseillés sauf raison impérative.

Pour les bases de données

Les Creative Commons ne sont pas techniquement adaptées aux bases de données (qui relèvent du droit sui generis des bases de données en Europe). On utilisera plutôt les licences Open Data Commons :

• ODbL (Open Database License) — équivalent CC BY-SA pour les bases de données.
• ODC-By — équivalent CC BY pour les bases de données.
• PDDL — équivalent CC0 pour les bases de données.

Pour les codes et scripts

Si votre projet produit des scripts ou des logiciels, il faut leur appliquer une licence logicielle distincte :

• MIT, Apache 2.0 : licences permissives, proches de CC BY.
• GPL v3 : licence copyleft, le code dérivé doit rester sous GPL.

Lien avec le choix de l'entrepôt

Certains entrepôts imposent ou suggèrent des licences spécifiques. Zenodo, par exemple, accepte toutes les licences Creative Commons et propose CC0 par défaut. Nakala (Huma-Num) recommande également CC BY ou CC0. Il vaut mieux vérifier les conditions de l'entrepôt cible avant de choisir votre licence.

Rédiger son PGD : les grandes rubriques

Maintenant qu'on a vu comment créer et configurer son plan dans OPIDoR, voyons ce qu'il faut concrètement remplir. Le modèle ANR (comme Science Europe) structure le PGD en six grandes rubriques. On va les passer en revue.

Rappel important : vous n'avez pas à tout remplir. Certaines rubriques ne s'appliqueront tout simplement pas à votre projet. L'outil OPIDoR vous permet de laisser des sections vides en le justifiant brièvement.

1. Description des données

C'est le cœur du PGD. Il s'agit de décrire les données que vous utilisez (données existantes réutilisées) et celles que vous produisez (données nouvelles).

Questions clés à se poser :

• Quels types de données ? Observationnelles (terrain, capteurs), expérimentales (labo), de simulation (modèles numériques), documentaires (archives, corpus textuels)…
• Quels formats ? Préférez les formats ouverts et pérennes : CSV, TSV, JSON, XML, TIFF, NetCDF, HDF5, ODP/ODS… plutôt que des formats propriétaires (Excel .xlsx, Photoshop .psd…). Si vous devez utiliser un format propriétaire pour des raisons techniques, indiquez-le et précisez s'il existe une alternative ouverte.
• Quel volume ? Ordre de grandeur en Go ou To. Cela conditionne les choix de stockage.
• D'où viennent les données réutilisées ? Source, licence d'origine, conditions de réutilisation.

2. Documentation et métadonnées

Des données sans documentation sont des données inutilisables — même par vous-même six mois plus tard.

• Standards de métadonnées : certains sont disciplinaires (DDI pour les sciences sociales, EML pour l'écologie, DarwinCore pour la biodiversité, FITS pour l'astronomie…), d'autres sont génériques (Dublin Core, DataCite). Choisissez celui qui correspond à votre domaine.
• Fichiers README : un simple fichier texte qui décrit le contenu d'un dossier, la signification des colonnes d'un tableau, les conventions de nommage utilisées. Sous-estimé, mais indispensable.
• Cahiers de laboratoire : électroniques (eLabFTW, Jupyter Notebook…) ou papier — l'essentiel est de tracer les conditions d'acquisition des données.
• Vocabulaires contrôlés et thésaurus : si vos données utilisent des termes spécialisés, précisez le référentiel utilisé (MESH pour la médecine, AGROVOC pour l'agriculture, GeoNames pour la géographie…).

3. Stockage et sauvegarde pendant le projet

Cette rubrique concerne la vie des données pendant le projet, avant tout dépôt final.

La règle de base est la règle des 3-2-1 :

• 3 copies des données
• sur 2 supports différents (disque local + serveur réseau, par exemple)
• dont 1 hors site (cloud institutionnel, autre bâtiment…)

Quelques points à aborder :

• Solutions institutionnelles : espaces réseau de votre laboratoire ou université, stockage cloud CNRS (Nextcloud institutionnel), serveurs de calcul avec espace de stockage…
• Sécurité et contrôle d'accès : qui a accès aux données brutes ? Les données sont-elles chiffrées ? Y a-t-il des données sensibles nécessitant un accès restreint ?
• Nommage et organisation des fichiers : une convention de nommage cohérente dès le début du projet évite énormément de confusion. Exemple : YYYYMMDD_nomOperation_Version.csv.

4. Aspects légaux et éthiques

Cette rubrique est souvent négligée mais peut être critique selon le type de projet.

• RGPD : dès que vos données contiennent des informations sur des personnes identifiables (données médicales, questionnaires, images de visages, données de géolocalisation…), le RGPD s'applique. Il faut prévoir l'anonymisation ou la pseudonymisation, les durées de conservation, et informer les personnes concernées.
• Éthique de la recherche : votre projet nécessite-t-il un avis d'un comité d'éthique (expérimentation animale, recherche sur des personnes…) ? Si oui, indiquez le numéro d'agrément.
• Propriété intellectuelle : qui détient les droits sur les données produites ? L'établissement, le chercheur, un partenaire industriel ? Des accords de confidentialité (NDA) sont-ils en jeu ?
• Données issues de fouilles ou de collections patrimoniales : certaines données sont soumises à des réglementations spécifiques (code du patrimoine, permis de fouilles…).

5. Partage et dépôt en fin de projet

L'objectif final d'un PGD est de s'assurer que les données seront accessibles et réutilisables après la fin du projet.

• Choix de l'entrepôt : il existe des entrepôts disciplinaires (PANGAEA pour les sciences de la Terre, GenBank pour les séquences biologiques, NAKALA pour les SHS…) et des entrepôts généralistes (Zenodo, Recherche Data Gouv…). Le catalogue re3data.org ou cat.opidor.fr peut vous aider à trouver l'entrepôt adapté à votre discipline.
• Identifiants pérennes : un DOI (Digital Object Identifier) attribué par l'entrepôt garantit que vos données restent citables et localisables sur le long terme.
• Embargo : si des contraintes de publication, de brevet ou de confidentialité l'imposent, vous pouvez déposer vos données avec un accès différé. Précisez la durée et la justification.
• Niveau d'ouverture : open data (accès libre), accès restreint (sur demande motivée), ou fermé (avec justification obligatoire). La tendance est à l'ouverture maximale : "aussi ouvert que possible, aussi fermé que nécessaire".

6. Responsabilités et ressources

Une dernière rubrique souvent expédiée, mais qui évite bien des malentendus dans une équipe.

• Qui est responsable des données ? Désigner un data steward ou responsable des données dans l'équipe, même informellement.
• Quelles sont les ressources prévues ? Certains entrepôts sont payants au-delà d'un certain volume. Le stockage à long terme a un coût. La curation des données (nettoyage, documentation) prend du temps. Anticipez ces éléments.
• Formation : les membres de l'équipe sont-ils formés à la gestion des données ? Doranum, Urfist, formations institutionnelles… des ressources existent.

Partager et exporter son PGD

Un PGD n'est pas un document figé et privé. OPIDoR permet de :

• Inviter des collaborateurs à co-rédiger le plan (via leur adresse mail).
• Choisir la visibilité : le plan peut rester privé, être partagé avec des personnes spécifiques, ou rendu public (ce qui peut alimenter les bases de PGD publics et servir d'exemple).
• Exporter le plan en PDF (pour le soumettre à un financeur), en JSON (format machine-actionable pour les entrepôts) ou en formats texte.

N'oubliez pas de mettre à jour votre PGD régulièrement : en début de projet lors de sa rédaction initiale, à mi-parcours si les données ont évolué, et en fin de projet pour refléter ce qui a réellement été produit et déposé.