La réponse peut être assez complexe mais généralement c’est à la tutelle. Des compléments peuvent être trouvés dans les aspects légaux des données de la recherche.
Tout dépend du statut de la plateforme utilisée pour les générer. Les conditions d’utilisation de la plateforme doivent clarifier la problématique des données.
Une FAQ sur le site science ouverte de Couperin précise le périmètre d’application de la loi (à partir de quand on peut déposer, comment, quoi …)
L’UGA prend en charge tout ou partie des frais de publications (APC – Article Processing Charges) uniquement pour les éditeurs avec lesquels elle a passé un accord, vous devez signaler à l’éditeur votre affiliation à l’UGA.
Dans le cas contraire, les frais sont à la charge du laboratoire ou de la structure de recherche.
Pour aller plus loin :
Vous déposez votre article dans la langue dans laquelle il a été publié.
Les dépôts sont répartis pour 1/3 en langue française et 2/3 en langue étrangère, les 2/3 des consultations se font également depuis l’international.
Pour vous aider à identifier une revue de confiance, vous pouvez consulter la fiche pratique sur les revues prédatrices.
En déposant, votre article dans HAL, il est automatiquement protégé par le droit d’auteur. La date de dépôt et l’identifiant unique garantissent l’antériorité scientifique et la paternité de la publication. Ces informations ont une valeur juridique.
Un article visible sous forme numérique est plus facilement détectable par les logiciels de détection de plagiat qui s’appuient sur des corpus disponibles en ligne.
Je ne suis pas obligé de déposer mon article dans HAL sauf si ma publication a bénéficié d’un financement de l’Union Européenne, de l’ANR ou si je suis un chercheur employé par le CNRS.
L’UGA recommande le dépôt de vos articles dans HAL (Charte science ouverte).
Pour vous aider, vous pouvez consulter la page sur les exigences des agences de financement.
Cependant, déposer mon article dans HAL lui donnera une meilleure visibilité (moissonnage par les moteurs de recherche type Google Scholar).
Cela dépend du type de financement de la thèse.
Par exemple, dans le cas d’un financement ANR ou Horizon Europe, le plan de gestion des données (PGD) est un livrable du projet de recherche dont la première version est à fournir 6 mois après le début de la thèse.
Dans tous les cas, le PGD est un outil de planification et de suivi des données. Sa première utilité est de faciliter le déroulement d’un projet de recherche (collecte, organisation, stockage des données..) ainsi que la valorisation des données produites. Il est donc recommandé de rédiger un plan de gestion des données pour votre thèse. La CDGA peut vous accompagner dans ce travail.
En premier lieu, les personnes qui encadrent votre thèse peuvent vous conseiller sur leurs attentes, les bonnes pratiques pour la gestion des données.
Dans de nombreux laboratoires de l’UGA, un-e référent-e données peut également vous aider sur la gestion des données. Vous trouvez la liste des laboratoires disposant de référents ici.
Deux services peuvent vous accompagner tout au long du cycle de vie des données durant toute votre thèse, la Cellule Data Grenoble Alpes et le service Signalement des thèses et accompagnement des doctorants.
Il est recommandé de déposer ses données dans un entrepôt correspondant à sa discipline (par ex, Nakala pour les sciences humaines, CDS pour les données astronomiques, EasyData pour les sciences de l’environnement). Pour vous aider à identifier un entrepôt thématique, le collège des Données de la recherche du Comité Science Ouverte propose une méthode d’identification des entrepôts thématiques de confiance, ainsi qu’une première liste d’entrepôts, évolutive qui sera progressivement complétée. Autre ressource : CAT Opidor et Re3data.
S’il n’existe pas d’entrepôt thématique dans votre communauté, il est recommandé de déposer vos jeux de données sur Data Repository Grenoble Alpes, l’espace institutionnel UGA de l’entrepôt national Recherche Data Gouv. Vos jeux de données seront modérés, ce qui permettra une meilleure accessibilité.
La Cellule Data Grenoble Alpes peut vous aider à identifier un entrepôt de données approprié et à déposer vos jeux de données.
Les métadonnées permettent de valoriser les données de la recherche en les rendant plus visibles via une description approfondie des jeux mis à disposition. Elles leur assurent donc une meilleure ré-utilisabilité et permettent leur citation, pour rendre crédit aux personnes qui les ont produites. Grâce aux métadonnées, il est possible de faire le lien entre les différents produits d’une recherche (publications, données, thèses, codes et logiciels) pour valoriser tous les aspects du travail.
De nombreux éditeurs exigent désormais la mise à disposition des données associées à votre publication. Ils proposent souvent des listes d’entrepôts ou leur propre entrepôt. Votre éditeur ne peut vous contraindre à utiliser son entrepôt : vous gardez dans tous les cas le libre choix de l’entrepôt où diffuser vos données. Si vous rencontrez des difficultés ou si vous souhaitez des conseils, vous pouvez solliciter la Cellule Data Grenoble Alpes.
La licence définit les conditions d’utilisation du logiciel. Elle est donc indispensable si on souhaite partager son code et permettre à d’autres personnes de l’utiliser, voir de le modifier et de le redistribuer. Par contre, pour les personnes salariées ou agents publics (et leurs stagiaires dans la recherche), c’est l’employeur qui possède les droits patrimoniaux et doit choisir la licence.
Dans le cadre du mouvement de la science ouverte, le choix de licence de type open source est recommandé par l’UGA.
Attention cependant si le code inclut d’autres codes : la licence globale doit être compatible avec les licences associées aux codes réutilisés. Dans le cas des licences dites diffusives ou contaminantes, le logiciel doit être distribué selon les mêmes termes que la licence d’origine. C’est par exemple le cas de la licence GPL.
Avant tout, il faut que le code soit accessible. L’idéal est d’utiliser une forge logicielle et un projet public pour diffuser le code, mais aussi permettre à d’autres personnes de contribuer.
Dans ce cas, il y a de fortes chances que le code soit archivé sur l’infrastructure Software Heritage.
Il suffit alors de signaler le code sur HAL via la création d’une notice. Le lien avec l’archive du code à travers l’identifiant SWHID de Software Heritage est très simple. Vous trouverez plus d’informations sur cette page.
L’utilisation de la citation proposée par HAL permet alors de lier sa publication au code.
Si il n’y a pas de notice logiciel sur HAL, on peut aussi citer le code grâce à l’identifiant de Software Heritage.
L’UGA propose une forge logicielle, vous pouvez vous connecter avec vos identifiants agalan.
A noter que cette forge offre la possibilité de comptes externes pour répondre au besoin du travail collaboratif avec des personnes extérieures au site. Par ailleurs, vous pourrez utiliser des services comme l’intégration continue avec des runners partagés et les gitlab pages.
Si le projet est international, il est possible d’utiliser les forges commerciales comme github.com mais il faut rester très prudent avec ces sites.
Le collège codes sources et logiciels du comité pour la science ouverte a publié un rapport sur l’état des lieux des forges existantes.
Les scripts sont des codes qui sont écrits dans un langage interprété qui ne nécessite pas de compilation (comme python par exemple), donc “directement” exécutable.
On utilise ce terme dans plusieurs configurations :
dans le cas de développement web, on appelle script un programme ou un bout de programme informatique qui va exécuter une fonction au moment de l’affichage d’une page web ou de la réalisation d’une action utilisateur.
dans le cas d’outils autonomes, on parle souvent de scripts pour désigner des codes, plutôt de petite taille, sur un seul fichier, et ayant un objectif très précis comme le pré ou post-traitement de données, leur visualisation, l’automatisation de commandes successives …
Si de tels programmes sont des maillons du processus de recherche conduisant à une publication, il est tout aussi important pour des questions de transparence et de reproductibilité, de les diffuser sous licence libre.
La documentation est un point essentiel pour partager un code, mais c’est avant tout également indispensable pour le ou les développeurs eux-mêmes afin d’assurer la compréhension et la réutilisation du code, y compris sur une échelle de temps longue.
Elle intègre différents niveaux :
le premier est fondamental et concerne le code lui-même : il s’agit de s’imposer quelques règles de programmation simples, en particulier pour le nommage des variables et des fonctions. Il est tout aussi important de bien commenter son code. C’est l’effort minimal à réaliser pour soi comme pour les autres.
le deuxième est le fichier README qui est la vitrine du code puisque c’est le fichier qu’on visualise sur un dépôt logiciel. Il s’agit donc de s’assurer qu’il contient les informations indispensables : dépendances, installation, exemples d’utilisation.
enfin, une documentation plus évoluée (éventuellement réalisée grâce à des outils automatiques comme doxygen), adaptées au public : utilisateurs ou développeurs (et donc potentiellement de futurs contributeurs) devient importante si l’ambition est d’accroître la communauté autour du code.
Pouvoir reproduire les résultats d’une publication est un des enjeux essentiels pour assurer la transparence et la confiance en la science.
La reproduction computationnelle est particulièrement complexe car le logiciel dépend de tout un environnement, de dépendances et éventuellement du matériel utilisé.
Pour mettre toutes les chances de son côté, le suivi de bonnes pratiques de programmation est essentiel : utiliser une forge logicielle, bien documenter son code et ses algorithmes, identifier précisément la version utilisée (par exemple via un numéro de commit ou un SWHID, identifiant de Software Heritage).
Il existe également des outils de packaging reproductible comme Guix ou nix. L’utilisation de container peut aussi aider à conserver un environnement stable pour reproduire des résultats.