# Publication de jeux de données scientifiques pour contribuer à la science ouverte

Lucas Frenot

<figure><img src="image_1.png" /></figure>

## To cite this version:

Lucas Frenot. Publication de jeux de données scientifiques pour contribuer à la science ouverte. Génie logiciel [cs.SE]. 2025. hal-05293853

HAL Id: hal-05293853

https://hal.univ-lorraine.fr/hal-05293853v1

Submitted on 2 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Brevet de Technicien Supérieur (BTS) C.I.E.L.
Cybersécurité, Informatique et réseaux, Électronique

Rapport de stage de 1ère année de BTS CIEL

Réalisé au CRAN, unité mixte de recherche n°7039
CNRS-Université de Lorraine

Publication de jeux de données scientifiques pour
contribuer à la science ouverte

<figure><img src="image_3.png" /></figure>
Remerciements

Je tiens à remercier tout particulièrement Monsieur Cédric Jacquemet, Enseignant au Lycée Loritz, sans qui je n'aurais jamais découvert cet univers, ces personnes, et cette opportunité unique. Merci de m'avoir fait confiance, et d'être venu me proposer ce stage en personne.

Je remercie également ma tutrice de stage, Madame Marine Amouroux, Ingénieure de Recherche au CRAN, pour son accompagnement tout au long de ces huit semaines. Malgré un emploi du temps très chargé (réunions, déplacements, projets), elle a toujours pris le temps de m'écouter, de m'orienter et de m'expliquer. Grâce à elle, j'ai pu progresser rapidement, comprendre les enjeux de la gestion des données scientifiques, mais surtout mesurer leur valeur immense pour la recherche.

Je souhaite aussi remercier l'ensemble de l'équipe du CRAN, et en particulier les membres du département BioSiS, pour leur accueil bienveillant, leur disponibilité, et les échanges de qualité que j'ai pu avoir tout au long du stage.

Je remercie également l'équipe supports de Recherche Data Gouv (RDG) notamment Damien Sans qui a répondu via le formulaire de contact que j'avais rempli sur RDG concernant le fonctionnement de RDG ainsi que Thomas Jouneau (du service ADOC Lorraine) pour les informations qu'il m'a apportées concernant la mise en ligne des jeux de données et pour avoir pris le temps d'assister à la démonstration du logiciel que j'ai développé pour le téléversement des données organisées en arborescence.

Enfin, je remercie mes enseignants du Lycée Henri Loritz, et en particulier ceux qui m'ont accompagné dans la préparation et le suivi de ce stage. Cette expérience m'a permis d'appliquer concrètement les compétences acquises en BTS CIEL, et de ressentir, à mon échelle, l'utilité de ce que nous apprenons en cours.

« Parce que la connaissance n'a de valeur que si elle est partagée... Vive la science ouverte ! » - Lucas
Table des matières

<table><tr><td>I. Introduction</td><td>5</td></tr><tr><td>II. Présentation de l'entreprise</td><td>6</td></tr><tr><td>III. Contexte du stage</td><td>7</td></tr><tr><td>1. Projet Photodiagnostic : diagnostic optique des cancers et plaies cutanées</td><td>7</td></tr><tr><td>a) La peau</td><td>7</td></tr><tr><td>2. La science ouverte</td><td>8</td></tr><tr><td>b) Bonnes pratiques</td><td>8</td></tr><tr><td>c) Dataverse : logiciel</td><td>9</td></tr><tr><td>IV. Travail réalisé : publication des jeux de données</td><td>10</td></tr><tr><td>1. Données au format tableau</td><td>10</td></tr><tr><td>a) Présentation des données</td><td>10</td></tr><tr><td>b) Modification à apporter pour que les données soient compatibles avec les contraintes et bonnes pratiques de l'entrepôt national des données</td><td>10</td></tr><tr><td>c) Résultat obtenu</td><td>11</td></tr><tr><td>2. Données au format DICOM</td><td>11</td></tr><tr><td>a) Présentation des données</td><td>11</td></tr><tr><td>b) Modification à apporter pour que les données soient compatibles avec les contraintes et bonnes pratiques de l'entrepôt national des données : retrait et ajout de métadonnées</td><td>12</td></tr><tr><td>c) Problèmes rencontrés</td><td>13</td></tr><tr><td>d) Solutions logicielles développées</td><td>13</td></tr><tr><td>e) Résultat obtenu</td><td>18</td></tr><tr><td>3. Données au format matriciel</td><td>18</td></tr><tr><td>a) Présentation des données</td><td>18</td></tr><tr><td>b) Modification à apporter pour que les données soient compatibles avec les contraintes et bonnes pratiques de l'entrepôt national des données</td><td>19</td></tr><tr><td>c) Solution logicielle développée</td><td>19</td></tr><tr><td>d) Résultat obtenu</td><td>19</td></tr><tr><td>V. Défis techniques rencontrés</td><td>21</td></tr><tr><td>1. DicRAN</td><td>21</td></tr><tr><td>2. RDG ArboDV</td><td>21</td></tr><tr><td>3. SpectroMatViewer</td><td>21</td></tr><tr><td>VI. Publication sur l'entrepôt national des données de la recherche : Recherche Data Gouv</td><td>22</td></tr><tr><td>1. Création d'un dépôt</td><td>22</td></tr><tr><td>2. Métadonnées obligatoires à remplir</td><td>22</td></tr><tr><td>3. Licence</td><td>22</td></tr><tr><td>VII. Conclusion</td><td>24</td></tr><tr><td>VIII. Compétences terminales mobilisées durant le stage</td><td>25</td></tr><tr><td>IX. Ressources bibliographiques</td><td>25</td></tr></table>
# I. Introduction

Dans le cadre de ma formation en BTS CIEL – Cybersécurité, Informatique & réseaux et Electronique, j’ai effectué un stage de 8 semaines au sein du CRAN, laboratoire de recherche qui a deux tutelles, le CNRS et l’Université de Lorraine, situé à Vandœuvre-lès-Nancy. Ce stage s’inscrit dans l’épreuve finale du BTS et a pour but de mobiliser et développer des compétences techniques en lien avec les systèmes numériques, la gestion de données et l’assurance de leur intégrité, tout en travaillant sur des enjeux de communication scientifique.

L'objectif de mon stage était de réaliser le support technique pour la mise en ligne de trois jeux de données scientifiques. En effet, les laboratoires de recherche sont tenus de respecter la Loi pour une République numérique (2016) qui mentionne que les 3 principaux types de productions scientifiques (articles, données et codes ou logiciels) doivent être publiés sur des sites web publics dans le cas où ils ont été produits grâce à au moins 50% de fonds publics. Des sites web appelés « entrepôts » ont été mis en place pour cela par le Ministère de l'Enseignement supérieur, de la Recherche et de l'Innovation :

- La plateforme HAL (hyper-articles en ligne) est une plateforme sur laquelle tous les chercheurs peuvent déposer leurs articles gratuitement : les lecteurs peuvent également gratuitement consulter tous les articles déposés sur HAL,

- La plateforme recherche.data.gouv (RDG) qui permet au chercheurs de déposer (ou de télécharger et utiliser) leurs jeux de données scientifiques, et qui va plus particulièrement concerner mon stage,

- Le plateforme Software Heritage qui héberge les codes et logiciels développés pour les travaux de recherche.

La tutrice de mon stage qui est ingénieure de recherche au CRAN m'a donné comme objectif de publier 3 types de données en respectant les contraintes techniques et les bonnes pratiques de publications des données sur recherche.data.gouv.

Le premier type de données sur lequel j'ai travaillé est un format bien connu du grand public car il s'agit du format issu du logiciel Excel commercialisé par la société Microsoft : comme je l'expliquerai dans le paragraphe V.1 du document, l'entrepôt de données impose des contraintes techniques même pour ce type de fichier très simple qui doit être configuré d'une manière précise pour être correctement téléversé et « ingéré » par le logiciel Dataverse qui assure l'hébergement des différents formats de données sur le site RDG.

Le deuxième jeu de données consistait en plusieurs dossiers contenant des images tridimensionnelles (3D) de peau humaine au format DICOM (.dcm) : il s'agit d'un format couramment utilisé dans le milieu hospitalier et qui présente la particularité d'intégrer des métadonnées comme par exemple des informations concernant le patient (nom, prénom, sexe, âge, etc.) ou concernant l'appareil utilisé pour acquérir les images (modèle, version, année de construction).

Le troisième type de données étaient des images hyperspectrales au format matriciel (.mat). Ces images sont acquises avec une caméra hyperspectrale qui éclaire le patient avec une lumière dont la longueur d'onde est comprise entre 500 et 1000 nm : chaque fichier .mat consiste en une « pile » de 100 images, acquise chacune à une longueur d'onde, tous les 5 nm (500, 505, 510,...,995 nm).

Comme indiqué dans la suite de ce document, pour chaque type de donnée, j'ai dû comprendre comment les fichiers étaient construits, et quelles modifications il fallait apporter pour qu'ils puissent non seulement être téléversés sur l'entrepôt national des données de la recherche recherche.data.gouv mais également être accessibles dans des formats ouverts à la communauté scientifique internationale.

Comme indiqué dans chacun des paragraphes associé à chaque type de données sur lequel j'ai travaillé, j'ai dû développer des logiciels permettant de mettre en forme les données automatiquement, les renommer et les téléverser de manière organisée en conservant une arborescence. Respecter les bonnes pratiques de la Science ouverte nécessite des moyens techniques et donc humains importants que mon stage a permis d'apporter.
## II. Présentation de l'entreprise

Le Centre de Recherche en Automatique de Nancy (CRAN - UMR 7039) est une unité mixte de recherche dépendant à la fois du CNRS (Institut Sciences informatiques et Institut Biologie) et de l'Université de Lorraine. Il est rattaché au pôle scientifique AM2I (Automatique, Mathématiques, Informatique et leurs Interactions) de l'Université de Lorraine.

Créé en 1980, le CRAN est aujourd'hui un acteur majeur de la recherche française. Il est implanté sur neuf sites en Lorraine (à l'IUT de Longwy, à l'ENSTIB à Saint-Dié des Vosges et sur plusieurs sites à Vandœuvre-lès-Nancy dont le campus Brabois-Santé où j'ai réalisé mon stage) et regroupe environ 250 membres, dont 120 enseignants-chercheurs et chercheurs, près de 100 doctorants, et environ 30 personnels d'appui à la recherche comme des ingénieurs, techniciens et des personnels administratifs.
Le laboratoire se caractérise par sa capacité à croiser des disciplines, en alliant les sciences de l'ingénieur, les sciences du numérique et les applications en santé. Sa devise est : "Au cœur des systèmes et de la santé"

Le CRAN mène des recherches fondamentales et appliquées, dans des domaines variés :

* automatique et commande des systèmes dynamiques,

* génie informatique,

* traitement du signal et de l'image,

* systèmes embarqués,

* intelligence artificielle,

* diagnostic médical assisté,

* neurosciences computationnelles,

* cancérologie et imagerie biomédicale.

Ces recherches sont appliquées dans les secteurs de l'industrie du futur, des réseaux intelligents, de la santé (en lien avec le CHRU de Nancy, le CHR Metz-Thionville et l'ICL - Institut de Cancérologie de Lorraine), des transports, ou encore de l'énergie. Le laboratoire est organisé en trois départements scientifiques : CID, MPSI et BioSIS

### CID – Contrôle, Identification, Diagnostic

Ce département traite de l'automatique théorique, des systèmes dynamiques (linéaires, non linéaires, hybrides), de la modélisation, du diagnostic de défauts, de la commande adaptative, etc. Ses applications concernent aussi bien l'aéronautique, que la production d'énergie ou les véhicules autonomes.

### MPSI – Modélisation Pilotage des Systèmes Industriels

Ce département s'intéresse aux systèmes industriels, aux réseaux intelligents, à la sûreté de fonctionnement, à la maintenance prédictive et à la cybersécurité industrielle. Il travaille également sur des thématiques comme l'économie circulaire et la transition énergétique.

### BioSiS – Biologie, Signaux et Systèmes en Cancérologie et Neurosciences

C'est dans ce département que j'ai réalisé mon stage. Il regroupe des chercheurs en biologie, neurosciences et traitement de l'image biomédicale. Il mène des travaux sur des projets comme le photodiagnostic c'est à dire l'utilisation de la lumière pour contribuer au diagnostic des cancers. Ses thématiques couvrent :

* l'imagerie médicale,

* la spectroscopie tissulaire,

* l'analyse de signaux EEG/IRM,

* la chirurgie assistée par l'image.

Ce département travaille en lien étroit avec le CHRU de Nancy, le CHR Metz-Thionville et l'Institut de Cancérologie de Lorraine (ICL) et les médecins qui participent directement aux projets.
### III. Contexte du stage

#### 1. Projet Photodiagnostic : diagnostic optique des cancers et plaies cutanées

Mon stage s'intègre au sein du projet Photodiagnostic, porté par le département BioSiS du CRAN en lien avec l'Institut de Cancérologie de Lorraine (ICL), le CHR Metz-Thionville et le CHRU de Nancy. Ce projet vise à améliorer le diagnostic non invasif des cancers de la peau et des plaies cutanées chroniques grâce à des dispositifs médicaux innovants, certains développés par le CRAN, exploitant les propriétés de la lumière pour déceler d'éventuelles anomalies.

##### a) La peau

La peau est un organe constitué de 3 couches principales : épiderme, derme et hypoderme (Figure 1). Le projet Photodiag vise à apporter une aide automatisée aux professionnels de santé responsables du diagnostic de plusieurs pathologies :

* Les carcinomes cutanés qui sont les cancers de la peau les plus fréquents qui se forment dans les cellules de la couche supérieure de la peau (l'épiderme) : il peut s'agir de carcinomes basocellulaires (peu agressifs mais fréquents) ou de carcinomes spinocellulaires, plus agressifs qui peuvent se propager s'ils ne sont pas traités assez tôt.

* Les plaies chroniques : il s'agit de plaies qui ne cicatrisent pas dans un délai de 3 mois. Il peut s'agir d'ulcères (ce sont des plaies profondes qui guérissent mal) avec ou sans infections bactériennes.

Le diagnostic clinique repose aujourd'hui sur l'observation, la palpation, puis la biopsie. Le projet Photodiagnostic vise à fournir un complément objectif et automatisé, par « biopsie optique », pour contribuer à la décision clinique.

<figure><img src="image_4.png" /><figcaption>Figure 1 : Schéma de la peau. Illustration extraite de https://www.cicatryl-gamme.fr/le-role-de-la-peau</figcaption></figure>

##### ▪ b) Les dispositifs médicaux et les jeux de données

La lumière est utilisée comme outil de diagnostic via plusieurs techniques :

* La spectroscopie optique analyse la lumière réfléchie ou absorbée par les tissus : les données issues d'un dispositif de spectroscopie optique sont des tableurs qui associent une intensité
lumineuse à chaque longueur d'onde (par exemple entre 400 et 800 nm). On obtient des fichiers excel contenant plusieurs colonnes de chiffres ;

* L'imagerie optique par méthode LC-OCT (linefield confocal-optical coherence tomography) qui grâce au principe de l'interféromètre de Michelson permet de créer des images tridimensionnelles de la peau à l'échelle microscopique,

* L'imagerie hyperspectrale qui consiste à superposer un spectre optique à chaque pixel d'une image. Il s'agit alors de données qui se présentent sous la forme de « cubes » de données :

<figure><img src="image_5.png" /><figcaption>Figure 2 : Illustration de deux types de données que j'ai traitées pendant mon stage.
A gauche, les images tridimensionnelles (3D) au format DICOM.dcm (image extraite de : damae-medical.com)
A droite, les images hyperspectrales au format matriciel.mat. (image extraite de : blog.i2s.fr)</figcaption></figure>

Le petit cercle blanc que vous voyez représenter le pointage d'une zone précise et le chiffre donne la valeur pour cette zone (par exemple 58 pour l'oxygène).

## 2. La science ouverte

La science ouverte est la diffusion sans entrave des résultats, des méthodes et des produits de la recherche scientifique [[1]].

Le projet Photodiagnostic du CRAN s'inscrit dans une démarche active de science ouverte. Cela signifie que les données collectées lors des expérimentations ne sont pas conservées uniquement au sein du laboratoire, mais doivent être organisées, anonymisées et publiées dans un entrepôt national qui s'appelle RDG (Recherche Data Gouv).

L'entrepôt national des données consiste en un logiciel Dataverse qui impose des contraintes techniques mais également des bonnes pratiques.

### b) Bonnes pratiques

L'objectif est de rendre les données réutilisables par d'autres chercheurs, dans une logique « FAIR » :

* **Findable** : facile à trouver. Avant de pouvoir réutiliser des données, il faut pouvoir les trouver. Pour que les données soient faciles à trouver, il est recommandé de déposer les données dans un entrepôt (ce qui est bien notre cas en choisissant RDG), attribuer un identifiant unique et pérenne aux jeux de données, comme un DOI par exemple (RDG attribue automatiquement un doi), décrire les données par des métadonnées riches (prévues par DRG).

* **Accessible** : par défaut, les données publiées sur RDG sont librement accessibles bien qu'il soit aussi possible d'en limiter l'accès momentanément (voire d'imposer un embargo d'une durée pouvant aller jusqu'à 5 ans) le temps que, par exemple, les articles présentant les résultats issus de ces jeux de données soient publiés par l'équipe de recherche ayant acquis les données.

* **Interoperable** : lisible par tous les systèmes. Les données doivent pouvoir être lues et modifiées par divers logiciels et applications et être intégrées à d'autres données. Pour que les données soient interopérables, il est recommandé de privilégier des formats de fichiers ouverts ou largement utilisés, mettre à disposition le code source du logiciel nécessaire pour lire, traiter, analyser les données s'il a été développé en interne, privilégier les standards de métadonnées et les vocabulaires standards (dans notre cas, nous avons utilisé le [thesaurus MESH](https://www.medicare.gov/medicare/standards/thesaurus.html) souvent utilisé dans le domaine médical) et si possible, indiquer des liens vers d'autres ressources liées au jeu de données (autres jeux de données, publications, ce que nous avons fait).
* **Reusable**: réutilisable avec une licence claire. Pour que les données soient réutilisables, il est recommandé d'associer une licence de diffusion aux jeux de données et de la documentation pour décrire les données de façon détaillée, les contextualiser, les rendre compréhensibles. C'est ce que nous avons fait : j'ai participé à la rédaction d'un document appelé « Readme » qui explique aux chercheurs voulant réutiliser le jeu de données comment elles sont nommées, organisées et comment ils peuvent les ouvrir.

Dans ce cadre, mon rôle est de préparer ces données pour leur mise en ligne sur la plateforme Recherche Data Gouv, dans le respect des principes FAIR :

* le format ouvert recommandé, .tab plutôt que ..xlsx par exemple,

* l'anonymisation des données : aucune donnée personnelle, retrait des identifiants patients,

* la structuration logique : arborescence, renommage des fichiers pour que les scientifiques retrouvent à quelle démarche scientifique ils correspondent,

* la documentation claire : README, dictionnaire de données, fiches d'appariement entre données brutes (avant qu'elles soient anonymisées ou renommées) et données publiées (renommées et anonymisées) pour que le laboratoire puisse faire le lien entre les données conservées en interne et celles publiées.

### c) Dataverse : logiciel

Dataverse [21] est une application web libre et gratuite, développée à l'origine par l'Université de Harvard. C'est un outil conçu pour aider les chercheurs à partager leurs données de manière fiable et durable. L'idée, c'est de rendre les jeux de données accessibles au plus grand nombre, tout en garantissant leur intégrité et leur traçabilité.

Concrètement, Dataverse permet de déposer des fichiers (données, documents, codes sources...), d'ajouter des métadonnées pour bien les décrire, et de générer automatiquement un identifiant unique (DOI) pour que chaque jeu de données puisse être cité dans une publication scientifique. Cela permet aussi de savoir combien de fois les données ont été vues ou téléchargées.

Un dépôt Dataverse fonctionne un peu comme un grand classeur numérique. Il est composé de collections (appelées aussi "Dataverses"), dans lesquelles on peut ranger des ensembles de données. Chaque collection peut contenir des sous-collections, ce qui permet de structurer les données par université, laboratoire, projet, par exemple.

Chaque ensemble de données contient :

* des fichiers (images, tableaux, scripts...),

* des métadonnées descriptives ( titre, auteur, date, méthode d'acquisition...),

* et parfois des fichiers annexes comme des documents README ou du code pour analyser les données.

L'interface de Dataverse est donc utilisé par Recherche Data Gouv. Elle permet de visualiser les fichiers directement dans le navigateur, d'organiser les dépôts, de gérer les droits d'accès (public, restreint, privé) et de suivre les mises à jour.

Pour ce stage, Dataverse a été l'outil central pour publier les jeux de données traités. Mais à cause de soucis concernant le téléversement d'arborescences, j'ai dû créer une application (GUI) nous permettant de téléverser ces arborescences plus facilement et plus rapidement qu'en utilisant l'outil proposé par l'aide en ligne de RDG.
# IV. Travail réalisé : publication des jeux de données

J'ai travaillé sur 3 types de données : je vais détailler le travail que j'ai réalisé pour chaque type de données dans les 3 paragraphes suivants.

## 1. Données au format tableau

### a) Présentation des données

* Appareil utilisé pour acquérir les données

Ces données ont été acquises avec un dispositif médical de spectroscopie optique développé (et breveté par les personnels du CRAN) utilisé sur des patients (ayant donné leur consentement éclairé) dans le cadre d'un essai clinique réalisé au CHR Metz-Thionville. Au début du stage, j'ai assisté à la démonstration de l'utilisation de ce dispositif afin de comprendre les données contenues dans les fichiers .tab qu'il générait.

* Format et volume du jeu de données

Le fichier .csv que j'ai eu à traiter était un fichier très léger. L'objectif était que je commence à comprendre le fonctionnement de l'entrepôt national des données de la recherche dans le cas d'un fichier simple. Cela m'a permis de comprendre que même ce type de fichier très simple nécessitait une mise en forme conforme aux contraintes de l'entrepôt national des données.

### b) Modification à apporter pour que les données soient compatibles avec les contraintes et bonnes pratiques de l'entrepôt national des données

Lorsque j'ai commencé à travailler sur les fichiers Excel à publier, je pensais que ce serait simple : après tout, c'est un format très courant, utilisé par tout le monde. Mais j'ai vite compris que, pour être accepté par la plateforme Recherche Data Gouv, il y avait des règles à respecter.

J'ai donc appris à structurer correctement un fichier Excel pour qu'il soit bien lu par le logiciel Dataverse, utilisé pour gérer les jeux de données. Par exemple, il faut qu'un seul onglet soit présent dans le fichier, et que chaque colonne ait un nom clair et unique dès la première ligne. On n'a pas le droit d'utiliser de cellules fusionnées, ni de mettre des retours à la ligne dans les cases, et il ne faut pas ajouter de titres ou de légendes dans les cellules.

Autre point important : l'encodage. Le fichier doit être enregistré en UTF-8, surtout s'il contient des caractères spéciaux (accents, symboles, etc.). Pour ça, j'ai utilisé un convertisseur open source, qui permet d'enregistrer facilement un fichier .csv avec l'encodage adapté.

Quand on passe au format .csv, il faut aussi faire attention à bien utiliser la virgule comme séparateur, et le point pour les décimales. Si du texte dans une cellule contient des virgules, il faut le mettre entre guillemets, sinon Dataverse croit que c'est une nouvelle colonne.

Ce sont des détails auxquels on ne pense pas toujours, mais qui sont essentiels pour que les données soient bien comprises, partagées et réutilisées ensuite par d'autres chercheurs.
c) Résultat obtenu

<figure><img src="image_6.png" /><figcaption>Figure 3 : Publication du jeu de données « SpectroLive » sur Recherche Data Gouv</figcaption></figure>

Une fois le jeu de données prêt et publié sur la plateforme Recherche Data Gouv, celle-ci attribue
automatiquement un DOI (Digital Object Identifier). C'est une adresse unique et permanente sur internet,
qui permet d'identifier le jeu de données de manière fiable et pérenne, même si son emplacement change.
Le DOI fonctionne comme un lien "officiel" que l'on peut utiliser dans un article scientifique, un rapport ou
une publication pour citer correctement les données. Autrement dit le DOI est au jeu de données ce que
l'ISBN est à un livre.

Lorsqu'on clique dessus, on est redirigé vers la page du jeu de données publié, avec sa description, ses fichiers, sa licence, et les informations de contact.

2. Données au format DICOM

a) Présentation des données

- Appareil utilisé pour acquérir les données

Le CRAN a utilisé le dispositif médical appelé « deepLive » pour acquérir des images 3D de la peau de 3 personnes volontaires pour participer à une étude sur l'efficacité de transparisation de la peau par des agents chimiques « gras ». Le dispositif deepLive est un dispositif d'imagerie optique par méthode LC-OCT (Linefield Optical Coherence Tomography). Il s'agit d'un dispositif innovant qui est commercialisé par la startup « Damae Medical » (Paris) qui collabore avec le CRAN dans le cadre d'un projet financé par l'Agence Nationale de la Recherche (ANR).

* Il permet d'utiliser une lumière cohérente pour obtenir des images très détaillées de tissus biologiques, avec une résolution proche de celle d'un microscope. Grâce à cette technologie, on peut explorer la peau jusqu'à une profondeur d'environ 400 micromètres c'est-à-dire jusqu'au derme.

* Cela permet de visualiser avec précision les couches supérieures de la peau, notamment l'épiderme (la couche la plus externe) et le derme papillaire (la couche juste en dessous, riche en capillaires).

* Ces images sont précieuses car elles offrent des informations cliniques utiles sans avoir à faire de biopsie. Elles permettent de mieux comprendre certaines pathologies cutanées, comme les cancers de la peau ou les plaies chroniques. L'appareil capture des volumes 3D de la peau (épiderme et derme), utiles dans le cadre du photodiagnostic des cancers cutanés.

* Les données sont exportées sous forme de fichiers au format DICOM (.dcm) contenant plusieurs coupes 2D (on parle de « piles » d'images 2D afin de constituer une image 3D) et de
nombreuses métadonnées (prénom et nom du patient, date d'acquisition des données, paramètres d'acquisition, etc.).

J'ai eu l'occasion d'utiliser le dispositif deepLive sur moi-même pour comprendre comment l'appareil fonctionnait : le fichier de sortie est un .dcm avec d'une part les métadonnées du patient inscrit via le logiciel deepLive ainsi qu'un volume 3D de notre peau.

* Format et volume du jeu de données

Comme dit précédemment, les fichiers générés par le dispositif deepLive sont au format DICOM (.dcm) et contiennent chacun une série d'images en coupe de la peau (qui est empiler via deepLive et nous créer en même temps un volume 3D), associées à un grand nombre de métadonnées techniques et cliniques. Chaque fichier pèse en moyenne entre 250 et 300 Mo, selon le nombre de coupes, la résolution, et les paramètres d'acquisition. Le jeu de données (LC-OCT) traité pendant mon stage comprenait 300 fichiers, représentant un volume total supérieur à 78,6 Go.

## À propos de la norme DICOM

Le format DICOM (Digital Imaging and Communications in Medicine) est une norme internationale utilisée dans le domaine médical pour stocker, transmettre et partager des images issues d'appareils comme les IRM, scanners, échographes ou encore les dispositifs optiques comme celui utilisé dans mon stage.

Cette norme ne se limite pas à l'image : elle intègre également un ensemble très riche de métadonnées, ce qui permet de décrire le contexte d'acquisition, les informations du patient, les paramètres techniques, etc.

Elle est gérée par la communauté internationale du standard DICOM [[3]], et toutes les spécifications sont disponibles publiquement sur leur site officiel

## b) Modification à apporter pour que les données soient compatibles avec les contraintes et bonnes pratiques de l'entrepôt national des données : retrait et ajout de métadonnées

* Retrait de métadonnées : anonymisation

Le format DICOM contient souvent des informations confidentielles, notamment dans les métadonnées : nom et prénom du patient, identifiant interne, date de naissance, nom de l'expérimentateur, etc.

Avant toute mise en ligne, ces champs doivent être soigneusement supprimés ou remplacés pour respecter la réglementation sur la protection des données personnelles (RGPD).

J'ai utilisé mon logiciel DicRAN pour automatiser l'anonymisation des fichiers .dcm tout en conservant certaines informations utiles comme la date d'acquisition ou les paramètres techniques.

* Ajout de métadonnées

Une fois les données anonymisées, il est essentiel d'ajouter des métadonnées scientifiques et descriptives, pour que les futurs utilisateurs comprennent le contenu du fichier.

Dans le cas des images DICOM issues de la machine deepLive, j'ai ajouté des informations comme :

* le prototype du patient (selon l'échelle de Fitzpatrick),

* la localisation anatomique de l'image (ex. dos de la main droite),

* l'agent utilisé (ex. Sucrose_PG),

* le point temporel (ex. T0 à T9).

Ces métadonnées ont été injectées directement dans certains tags DICOM à l'aide de DicRAN, puis regroupées dans un fichier de suivi Excel, lui aussi publié avec les données.
### c) Problèmes rencontrés

Afin de respecter les bonnes pratiques de l'entrepôt national des données, il nous fallait chercher des logiciels open source pour pouvoir offrir une solution à ceux qui veulent utiliser notre jeu de données ainsi qu'une guide les aidant à leur bonne ouverture/présentation. J'ai donc cherché des logiciels gratuits qui permettent d'ouvrir les images 3D : j'ai donc indiqué dans le document « Readme » que les chercheurs pouvaient utiliser les logiciels 3D Slicer ou ImageJ, ce dernier étant moins pratique que 3D Slicer mais plus connu dans le domaine de la recherche en santé.

### d) Solutions logicielles développées

#### ▪ DiCRAN

Dans le cadre de mon stage, j'ai été amené à créer DicRAN, un logiciel conçu pour visualiser, éditer et préparer des fichiers DICOM issus des dispositifs médicaux utilisés au CRAN.
Le format DICOM (.dcm) est un standard médical très utilisé, mais complexe. Il contient non seulement l'image, mais aussi une grande quantité de métadonnées (nom du patient, date d'acquisition, type d'appareil, etc.) qu'il faut analyser, modifier ou supprimer dans une logique d'anonymisation.
Les objectifs de DicRAN :

* Lire, extraire et permettre l'ajout de métadonnée (via le dictionnaire DICOM officiel, car chaque champ à une adresse, il y a plus de 5000 champ) dans un ou plusieurs fichiers .dcm.

* Anonymiser en lot des .dcm certain tag (certain champ par exemple hcamp « Patient Name »)

* Permettre de faire une tâche automatisée pour nos besoins : dans l'onglet CRAN, [a continuer]

* Automatiser le renommage selon un schéma cohérent (date, sexe, âge, phototype, condition expérimentale, repère temporel Tn)

* Garantir un suivi exhaustif via un fichier Excel mis à jour en temps réel

* Offrir une interface simple même pour des volumes importants (arborescence, « Run/Stop », indicateurs de performance)

<figure><img src="image_7.png" /></figure>

Version présentée : V0.3.1

<figure><img src="image_8.png" /></figure>

Figure 4 : Interface utilisateur du logiciel DicRAN : à gauche, l'arborescence des métadonnées d'un fichier .dcm ouvert ; à droite, l'arborescence d'un dossier sélectionné ; en dessous toutes les fonctionnalités du logiciel, réparties par section via des onglets
<figure><img src="image_9.png" /><figcaption>Figure 5 : Interface utilisateur pour ajout, suppression de métadonnée : Possibilité de faire une recherche et d'afficher seulement les résultats, de modifier le champ « Value »;</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Figure 6 : Interface utilisateur pour ajout métadonnée : Il nous permet d'ouvrir le dictionnaire officiel de DICOM et de les insérer dans les champs « Group » ; « Element » ; « VR » et on rentre la « Value » souhaiter.</figcaption></figure>
<figure><img src="image_11.png" /><figcaption>Figure 7 : Choix de la métadonnée à ajouter.</figcaption></figure>

Au cours du développement, plusieurs défis m'ont amené à ajuster l'architecture de mon planning :

<figure><img src="image_12.png" /><figcaption>Figure 8 : Fichier Excel permettant de référencer les nom initiaux et finaux des fichiers (pour assurer leur traçabilité).</figcaption></figure>

1. Intégration de la saisie âge/phototype

o **Problème** : le PatientInfoForm n'existait initialement qu'en version vide, sans constructeur ni propriété pour remonter les données.

o **Solution** : ajout d'un constructeur prenant la liste des patients, d'une propriété publique PatientInfos, et d'un DataGridView pré-rempli.

2. Écriture "live" dans Excel

o **Problème** : initialement, tout était sauvegardé en fin de batch, rendant impossible le suivi en cas de crash partiel.

o **Solution** : Ajouter ligne par ligne

3. Ergonomie "Run / Stop"

o **Problème** : bouton "Run Batch" initial sans possibilité d'interruption.

o **Solution** : bascule automatique du texte du bouton vers "Stop" dès le démarrage, implémentation d'un booléen _cancelProcessing et d'un CancellationToken simulé dans la boucle, permettant de finir la modification en cours et de stopper.
4. Ergonomie "Run / Stop"

o **Problème** : bouton "Run Batch" initial sans possibilité d'interruption.

o **Solution** : bascule automatique du texte du bouton vers "Stop" dès le démarrage, implémentation d'un booléen _cancelProcessing et d'un CancellationToken simulé dans la boucle.

* **Logiciel de téléversement de données en arborescence : logiciel RDG-ArboDV**

Le principal souci que nous avons rencontré lors du dépôt de nos jeux de données est que RDG ne supporte pas le téléversement d'arborescences. Plusieurs options s'offrent aux chercheurs souhaitant téléverser leurs jeux de données organisées en arborescences c'est-à-dire contenant des dossiers et sous-dossiers :

- Téléverser un .zip. Dans ce cas l'arborescence est respectée mais le doi (digital object identifier) n'est attribué qu'au dossier zip et non à chacun des fichiers contenu dans le .zip.

- Modifier le chemin d'accès à chaque fichier manuellement dans RDG afin de le déplacer dans le dossier souhaité : si, cette solution est utilisable pour quelques fichiers, elle est bien sûr inadaptée au téléversement de 900 fichiers comme c'est le cas du jeu de données contenant ls fichiers .dcm que j'ai eu à publier dans le cadre de mon stage.

- Utiliser l'outil « DV上传器 » disponible sur l'aide en ligne de RDG (Figure 9). Ce logiciel est un CLI (commande line interface), autrement dit il ne marche qu'en ligne de commande : tout est bien documenté. Malheureusement après quelques heures de tentatives, je n'ai pas réussi à l'utiliser pour téléverser notre jeu de données. De plus, j'avais à l'esprit que mon travail avait pour objectif de développer des outils permettant de faciliter la publication de jeux de données sur le long erme même après la fin de mon stage. Or les outils en ligne de commande représentent un frein majeur à la publication de jeux de données pour des chercheurs dont la plupart ne sont pas formés à la programmation informatique et ne connaissent pas cet outil.

<figure><img src="image_13.png" /><figcaption>Figure 9. Exemple de lignes de commande proposé par l'aide en ligne de l'entrepôt national des données (recherche.data.gouv) pour utiliser l'outil DV Uploader. https://recherche.data.gouv.fr/fr/categorie/33/guide/dv-uploader</figcaption></figure>

Afin de régler l'ensemble des problèmes décrits ci-dessus c'est ç dire publier une arborescence de manière automatisée et attribuer un doi à tous les fichiers du jeu de données, j'ai donc entrepris de développer un logiciel à interface graphique, simple, rapide. Mon logiciel RDG ArboDV (DataVerse) est un client Windows (WinForms/.NET 6+) permettant de charger en masse des fichiers et dossiers vers un serveur Dataverse via l'API RDG. L'enjeu principal était de gérer de très gros volumes (plusieurs Go, des milliers de fichiers et sous-dossiers), tout en préservant strictement la structure d'arborescence et en offrant un retour d'état précis (débit, ETA, statut).
<figure><img src="image_14.png" /></figure>

Version présentée : V1.0.1

<figure><img src="image_15.png" /><figcaption>Figure 10 : Interface RDG ArboDV</figcaption></figure>

## Algorithme de RDG ArboDV

* Sélection et visualisation

* Import en lot de fichiers ou de dossiers entiers (avec récursion automatique)

* Arborescence interactive (TreeView) avec icônes « dossier » / « fichier » et support du glisser-déposer (à venir)

* Multi-sélection avancée (Ctrl/Shift) + menu contextuel pour suppression ou « aplatir » un dossier

* Conservation de la structure

* Calcul et stockage d'un directoryLabel relatif pour chaque fichier, afin que Dataverse recrée l'arborescence exacte (lorsqu'il lit les données)

* Fonction "Aplatir ce dossier" pour remonter les fichiers/dossiers enfant au dossier parent et supprimer le dossier parent.

* Téléversement fiable et performant

* ProgressableStreamContent : wrapper de HttpContent pour envoyer par chunks, remonter la progression, et gérer l'annulation via CancellationToken

* Calcul automatique de la taille totale, affichage d'une SPBar en Ko, et suivi du débit (Mo/s), de l'ETA et du temps écoulé

* Retry automatique (jusqu'à 3 tentatives avec pause de 5 s) en cas de verrouillage ou d'erreur temporaire, avec journalisation dans upload_retry.log

* Gestion des erreurs HTTP détaillée, logs dans upload_errors.log, et message utilisateur clair

* Contrôle utilisateur

* Bouton Cancel pour stopper immédiatement le téléversement (barre rouge + OperationCanceledException)

* Verrouillage/déverrouillage des contrôles pendant l'opération

* Simplicité & ergonomie

* Interface épurée (sans logos superflus), tout en offrant des indicateurs clés en temps réel

* Adapté aux petits jeux de données (via avertissement) comme aux très gros volumes

* Possibilité de glisser-déposer dossiers ou fichiers depuis l'Explorateur Windows

## Techno & briques principales
* .NET 6+ / C# / WinForms

* Newtonsoftwan JSON pour sérialiser la partie JSON (description + directoryLabel)

*HttpClient partagé, MultipartFormDataContent + headers personnalisés (X-Dataverse-key)

* P/Invoke SendMessage (user32.dll) pour changer l'état de la SPartan-3 (vert/rouge)

* System.Windows Forms.Timer pour afficher le temps écoulé

* MultiSelectTreeView customisée pour gérer correctement Ctrl/Shift et clic droit sans perdre la sélection

e) Résultat obtenu

Une fois tous les fichiers .dcm bien préparés, c'est-à-dire anonymisés, renommés et accompagnés des bonnes métadonnées, j'ai pu publier le jeu de données sur la plateforme Recherche Data Gouv.
Pour faire le dépôt, j'ai utilisé mon propre logiciel RDG ArboDV, que j'ai développé pendant le stage justement pour faciliter ce genre de tâche, car la méthode en ligne de commande n'était pas très pratique.
Quand le dépôt est terminé, la plateforme attribue automatiquement un DOI, c'est-à-dire un lien unique et permanent qui permet de retrouver le jeu de données sur internet, un peu comme une "carte d'identité numérique"

<figure><img src="image_16.png" /><figcaption>Figure 11 : Publication finalisé jeu du 2ème jeu de données sur lequel j'ai travaillé pendant mon stage.</figcaption></figure>

Voici un exemple de DOI que l'on obtient : https://doi.org/10.57745/PUKO1W

Ce lien permet à d'autres chercheurs de citer ou réutiliser les données dans leurs propres travaux. C'est une vraie contribution à la science ouverte, et j'ai trouvé ça valorisant de voir que mes fichiers pouvaient être partagés à cette échelle.

3. Données au format matriciel

a) Présentation des données

* Appareil utilisé pour acquérir les données

Les mesures ont été réalisées avec une caméra hyperspectrale nommée « Tivita » et commercialisée par la société Diaspective (Allemagne). Cette caméra hyperspectrale éclaire la peau des patients sur la plage 400 – 1000 nm. Chaque acquisition génère un cube 3D : deux dimensions spatiales (X, Y) et une dimension spectrale (100 bandes).

* Format et volume du jeu de données

Chaque cube est enregistré dans un fichier MAT-Lab (\*.mat) (≈ 130 Mo).

L'ensemble de la campagne se compose de 861 cubes, soit environ 32,7 Go.
b) Modification à apporter pour que les données soient compatibles avec les contraintes et bonnes pratiques de l'entrepôt national des données

Les fichiers .mat sont des fichiers propriétaire Matlab : bien que la plus part des chercheurs ait une licence
cela ne sera pas le cas de tout le monde, nous pouvions convertir le .mat mais nous avons fait le choix de
le conserver car aucun autre format ne propose une organisation aussi intéressante des données. Nous
devions néanmoins proposer une solution pour les chercheurs ne disposant pas d'une licence du logiciel
Matlab. J'ai alors décidé de créer un logiciel pour ouvrir les spectres contenus dans le .mat avec possibilité
d'extraite les données sous la forme de fichiers .xslx d'un ou bien de plusieurs fichiers/dossiers.

c) Solution logicielle développée

Le logiciel SpectroMatViewer ouvre instantanément chaque cube .mat et en affiche une vignette, il suffit
ensuite de cliquer sur un pixel pour voir son spectre (400-1000 nm), puis d'exporter, d'un simple clic, les
longueurs d'onde et la réflectance dans un fichier Excel avec ou sans la courbe. Il peut même parcourir
automatiquement toute une arborescence de dossiers pour produire les .xsx, le tout sans Matlab grâce
aux bibliothèques csmatio (lecture) et EPPlus (génération Excel).

<figure><img src="image_17.png" /></figure>

<figure><img src="image_18.png" /><figcaption>Figure 12. Logo (gauche) et interface utilisateur (droite) du logiciel SpectroMatViewer que j'ai développé pendant mon stage afin de permettre aux chercheurs utilisant le jeu de données publié sur RDG d'ouvrir les images hyperspectrales (.mat) et d'extraire le spectre en chaque point de l'image.</figcaption></figure>

d) Résultat obtenu

Comme indiqué en Figure 12, le 3ème jeu de données sur lequel j'ai travaillé pendant mon stage a été
publié. La particularité de celui-ci est qu'il est publié avec « accès restreint ». En effet, la tutrice de mon
stage a souhaité profiter de ma présence pour publier le jeu de données mais l'article associé n'étant pas
encore publié, elle a préféré le publier avec accès restreint : de cette manière, contrairement à l'autre
solution appelée « embargo » les métadonnées sont visibles et la restriction d'accès peut être enlevée
quand on le souhaite, dans ce cas, dès que l'article sera publié. Alors qu'en cas d'embargo, la restriction
d'accès (levée d'embargo) ne peut pas être anticipée, elle est fixée au début de la mise d'embargo et ne
peut pas être adaptée à une date de publication d'article inconnue à ce jour et qui ne peut pas être évaluée
précisément.
Hyperspectral images acquired on human skin in vivo for skin oxygen saturation measurement and corresponding spectrum

<figure><img src="image_19.png" /><figcaption>Figure 13 : Publication sur recherche.data.gouv du 3ème jeu de données sur lequel j'ai travaillé pendant mon stage.</figcaption></figure>

Je tiens à préciser que dans le cas des 3 jeux de données sur lesquels j'ai travaillé, je ne peux pas être mentionné parmi les auteurs du jeu de données car je n'ai pas contribué à l'acquisition des données, ni à l'élaboration du protocole aboutissant à leur acquisition. En revanche, comme j'ai contribué à la publication de ces jeux de données et développé des outils sans lesquels il aurait été complexe de réaliser leur publication, j'ai été cité dans les métadonnées de chacun des 3 jeux de données comme « Contributeur ». Comme indiqué en Figure 13, mon nom est donc mentionné dans la métadonnée associée.

<figure><img src="image_20.png" /><figcaption>Figure 14. Capture d'écran des métadonnées relatives au 2ème jeu de données publié (images 3D au format .dcm) indiquant que comme pour les 2 autres jeux de données, mon nom (Lucas Frénot) est mentionné au titre de « Contributeur » afin de rappeler le rôle que j'ai rempli dans la publication des données.</figcaption></figure>
# V. Défis techniques rencontrés

Je rappelle dans ce paragraphe quelques défis techniques que j'ai rencontrés et résolus dans le cadre des développements logiciels réalisés pour la publication des jeux de données.

## 1. DicRAN :

* Suivi de fichiers (communication avec le fichier .xlx et écriture)

* Automatisation (création d'une file d'attente)

* Gestion de profils multiples : prise en charge dynamique de différents jeux de règles (JSON), import/export, permettant de rentrés des paramètres près défini

* Interopérabilité DICOM : usage de fo-dicom pour lire/écrire, adaptation aux VR variés, tests sur fichiers hétérogènes.

* Organisation du code et surtout de l'interface

* Optimisation I/O : réduction des accès au disque

* Fenêtre pour ajouter les métadonnées, les voir, ajouter, supprimer et appliqué les modifications.

## 2. RDG ArboDV

* Microcoupure Wi-Fi : lors d'une coupure de réseau tout s'arrêtait j'ai dû gérer ces exceptions, j'ai donc mis en place un retry automatique de 5 secondes.

* Quand il y avait une erreur je voulais passer la barre de progression en rouge : j'ai rencontré des soucis avec le .NET et le .dll qui gère cela.

* L'arbre devenait indigeste avec des milliers de fichiers : j'ai mis en place un tri alphabétique, des compteurs Terminés, erreurs, en attente.

* J'ai dû améliorer les performances car au-delà d'un certain nombre de fichiers le logiciel s'interrompait.

* Création du JSON d'envoi car l'API Dataverse exige une partie jsonData avec description et directoryLabel. Sérialisation via Newtonsoft.json, car j'ai appris que chaque fichier doit avoir un json associé et RDG lit les json pour créer une arborescence.

## 3. SpectroMatViewer

* Lecture des fichiers .mat en C# : comprendre le format et aller lire le spectre en question.

* Génération d'une image à partir d'un cube hyperspectral : Affichage du graphique + export.

* Export vers .xlx avec EPPlus : apprentissage de la bibliothèque, configuration des graphiques (dans le .xlx exporté).

* Ajout du traitement par lot : prise en charge des sous-dossiers, gestion des erreurs.

* Interaction avec l'utilisateur : ajout d'un choix pour intégrer ou non le graphique dans les exports Excel. Car le graphique posé un soucis pour RDG.
# VI. Publication sur l'entrepôt national des données de la recherche : Recherche Data Gouv

Une fois les données prêtes et le jeu de données organisés selon l'arborescence souhaitée pour la publication sur RDG, elles doivent être téléversées sur l'entrepôt national des données de la recherche : https://www.recherche.data.gouv.fr

Afin de respecter les arborescences, le support technique de RDG propose l'utilisation d'un outil nommé **DV Uploader**. La principale contrainte associée à cet outil est qu'il est complexe à utiliser et non-intuitif : personnellement au bout de 3 heures d'essai, j'ai renoncé à l'utiliser et ai préféré m'atteler à au développement du logiciel RDG-ArboDV déjà présenté précédemment. L'outil DV Uploader représente donc un frein important à la publication de jeux de données par des chercheurs non-spécialistes en programmation informatique.

## 1. Création d'un dépôt

* Un identifiant unique (DOI) est généré automatiquement à la fin du dépôt.

* Un jeton API qui permet d'interagir sur Recherche Data Gouv avec notre compte est également créé automatiquement. Ce jeton nous est utile lorsque nous téléversons une arborescence de fichiers avec le logiciel RDG ArboDV que j'ai développé.

## 2. Métadonnées obligatoires à remplir

* Titre du jeu de données

* Description courte et détaillée

* Mots-clés

* Discipline scientifique

* Type de données

* Méthodes d'acquisition

* Conditions d'utilisation (licence)

* Contact

Lors du téléversement du jeu de données contenant les images du format .dcm, nous n'avions rencontré aucune erreur de téléversement en utilisant mon logiciel RDG ArboDV. Cependant, lors du téléversement du jeu de données contenant les images au format .mat, plusieurs erreurs se sont produites. Dans sa version initiale, le logiciel ne me permettait pas de savoir quel fichier était en cours de téléversement au moment où les erreurs se produisaient. J'ai donc publié une mise à jour (V1.1.0) du logiciel qui nous permet d'avoir cette information ainsi que dans le groupe « Stats » le nombre total de fichiers téléversés, ceux toujours en attente de téléversement et les erreurs.

## 3. Licence

La licence prévue par l'entrepôt RDG est la licence ouverte Etalab 2.0, créée par la mission Etalab (sous l'autorité du Premier ministre) pour encadrer la réutilisation des informations publiques en France. Elle est régie par le Code des relations entre le public et l'administration (CRPA) et la licence est applicable à l'échelle mondiale, de manière non exclusive, gratuite et pour une durée illimitée.
Les droits accordés au ré-utilisateur sont les suivants :

* Reproduire et copier les données, adapter, modifier, transformer pour créer des données dérivées ou de nouveaux services.
* Redistribuer, publier et transmettre les données, il a également de le droit de l'exploiter commercialement, y compris en intégrant les données dans des applications ou produits.

* Le réutilisateur doit néanmoins respecter quelques conditions : mentionner la source, le crédit ne doit pas suggérer ou impliquer une approbation officielle de la part de l'administration, la personne qui va réutiliser nos données est le seul responsable et ne doit pas induire en erreur sur la source ou le contenu.

* Le concédant garantit que les informations ne sont pas soumises à des droits tiers non transférables. S'il détient des droits sur les contenu, il les concède gratuitement au ré-utilisateur pour la durée légale, sans entraver les droits accordés.
## VII. Conclusion

Ce stage de huit semaines au CRAN a été une expérience à la fois enrichissante, exigeante et motivante. Il m'a permis de découvrir le fonctionnement concret d'un laboratoire de recherche, un environnement que je ne connaissais pas du tout et qui m'a beaucoup plu. J'ai été impressionné par le niveau technique des projets en cours, mais aussi par l'implication des équipes et la diversité des compétences mobilisées.
Sur le plan technique, j'ai beaucoup appris sur la gestion des données scientifiques : formats complexes (DICOM, MATLAB), contraintes légales (anonymisation), standards ouverts, structuration, documentation et publication. J'ai aussi découvert l'importance des métadonnées et la rigueur nécessaire pour préparer un jeu de données publiable et réutilisable. Je me suis rendu compte de la difficulté qu'on les chercheurs qui veulent s'ouvrir à la science ouverte, il ne s'agit pas simple de déposé vos données acquise lors de vos recherches.

Ce stage m'a permis d'exploiter les compétences acquises en BTS CIEL (traitement de fichiers, automatisation, pseudo anonymisation, développement logiciel), mais aussi d'en développer de nouvelles, notamment grâce aux logiciels DicRAN, RDG ArboDV et SpectroMatViewer. Créer mes propres outils pour répondre à un besoin réel a été quelque chose que j'ai vraiment aimé faire. Le logiciel dont je suis le plus fière est DicRAN sur le plan technique, il a n'hésité environ 4 semaines de travail mais le logiciel qui sera le plus utilise sera RDG ArboDV tout simple car après avoir finis le traitement de mon première jeux de donnée (LC-OCT) être bloqué sur la publication n'étais pas la chose la plus drôle. Et donc permette aux chercheurs de publié plus facilement une grande quantité de donnée me rend fière de mon travail.
Enfin, cette immersion m'a conforté dans l'idée que je souhaite travailler dans un domaine utile, rigoureux et tourné vers l'innovation. Même si la recherche n'est pas une voie directe pour un BTS, cette expérience m'a montré que les compétences acquises peuvent avoir un vrai impact, même dans des projets scientifiques de haut niveau. J'en ressors donc, que du positif.

Réunion avec l'équipe support de RDG : intérêt pour mon logiciel. On attend la suite pour les déclarations d'invention.

Sur le plan des outils collaboratifs, j'ai aussi appris à utiliser GitLab pour centraliser le code que j'ai produit. Cela permet à l'équipe du laboratoire d'accéder facilement aux outils, de les tester et, potentiellement, de les améliorer. Dans cette logique, j'ai également rédigé trois déclarations d'invention, transmises à la direction de la recherche et à la valorisation de l'Université de Lorraine. L'objectif est d'étudier la possibilité de publier ces logiciels sur l'entrepôt international de logiciels libres Software Heritage, afin de prolonger la démarche de science ouverte jusqu'au bout.

Ce stage m'a également permis de mieux comprendre l'environnement d'un laboratoire, les contraintes réglementaires : à mon arrivée au CRAN, j'ai dû suivre une formation de prévention des risques présents au laboratoire. Cette formation est proposée par le CNRS sous la forme de vidéos à suivre et d'un questionnaire de validation à compléter pour chacun des cinq thèmes suivants : prévention générale, risque biologique, chimique, incendie et radioprotection. Travailler dans un tel cadre m'a donné confiance en mes capacités, et une vraie motivation pour la suite de mes études.

La science ouverte, ce n'est pas « juste » partager des données : c'est contribuer à construire un savoir collectif, utile à tous. Je suis fier d'avoir pu, à mon niveau, y prendre part.
## VIII. Compétences terminales mobilisées durant le stage

Ce stage m'a permis de mettre en pratique les compétences acquises en BTS CIEL (traitement de fichiers, automatisation, pseudo-anonymisation, développement logiciel notamment en C#), mais aussi d'en acquérir de nouvelles, notamment grâce aux logiciels DicRAN, RDG ArboDV et SpectroMatViewer. Créer mes propres outils pour répondre à un besoin réel a été une expérience que j'ai beaucoup appréciée. Le logiciel dont je suis le plus fier est DicRAN : sur le plan technique, il m'a demandé près de 4 semaines de travail, mais c'est l'outil qui, je pense, sera le plus utilisé dans la suite du projet. RDG ArboDV, quant à lui, m'a permis de simplifier la publication d'un jeu de données volumineux, ce qui représentait un véritable obstacle initialement. Pouvoir contribuer à une solution qui sera réutilisée par d'autres chercheurs est une vraie source de satisfaction, et je mettrais à jour le logiciel régulièrement.

Enfin, cette immersion m'a conforté dans l'idée que je souhaite travailler dans un domaine utile, rigoureux et tourné vers l'innovation. Même si la recherche n'est pas une voie classique après un BTS, cette expérience m'a ouvert des perspectives nouvelles. J'ai notamment découvert l'existence de la licence Sciences pour la Santé, une formation située juste à côté du CRAN, qui accueille déjà d'anciens élèves du BTS CIEL. C'est une piste que je garde sérieusement à l'esprit pour la suite de mon parcours, si je ne trouve pas de travail avant la fin de mon BTS.

## IX. Ressources bibliographiques

[1] Ministère de l'Enseignement supérieur et de la Recherche. La science ouverte : définition et enjeux. https://www.ouvrirlascience.fr/initiez-vous-a-la-science-ouverte/

[2] Dataverse Project. About the Dataverse Project. https://dataverse.org/about (consulté en juin 2025).

[3] National Electrical Manufacturers Association (NEMA). Digital Imaging and Communications in Medicine (DICOM) Standard. Disponible sur : https://www.dicomstandard.org

[7 octobre 2026 Loi] https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000033202746

[HAL (hyper-articles en ligne)) https://hal.science/

[recherche.data.gouv] : https://entrepot.recherche.data.gouv.fr/

[Software Heritage] : https://www.softwareheritage.org/?lang=fr