 \section{Recommandations relatives à l'interopérabilité entre différents outils}
 \label{interop}
 
%*******************************************
\subsection{Interopérabilité}

Dans sa définition communément admise \footnote{https://fr.wikipedia.org/wiki/Interop\%C3\%A9rabilit\%C3\%A9}, l’interopérabilité est la capacité que possède un produit ou un système à fonctionner avec d’autres produits ou systèmes existants ou futurs et ce sans restriction d’accès ou de mise en œuvre. L’interopérabilité concerne uniquement le comportement externe des produits et n’influe pas leur conception interne. Cette capacité est assurée par des normes et des formats connus. En France, ces normes peuvent être décrites dans le référentiel général de l’interopérabilité (RGI)\footnote{https://www.numerique.gouv.fr/publications/interoperabilite/} dont la version actuelle a été approuvée par l’arrêté du 20 avril 2016\footnote{https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000032438896}. Le RGI est un document décrivant un ensemble de normes et bonnes pratiques communes aux administrations publiques françaises dans le domaine informatique. \\

Les enjeux de l’interopérabilité se situent sur les formats des données échangées entre les différents produits ainsi que sur les interfaces et protocoles de communication. \\

Un laboratoire de recherche a, généralement, un écosystème numérique riche que l’on qualifie souvent de système d’information (SI). Il peut être composé d’infrastructures de gestion de données (bases de données, gestion documentaire, entrepôt, etc.), d‘infrastructures de calcul (HPC, \textit{Notebook}, chaînes de traitements, etc.), d’environnement virtuels de recherche (VRE) ou tout simplement d’outils bureautique. Le personnel de recherche a également accès à des ressources se situant au-delà du périmètre du laboratoire tels que les entrepôts de données publiques, des catalogues et des espaces de stockage et/ou de calcul. Pour que l’adoption d’un ELN apporte une valeur ajoutée, celui-ci devra s’interfacer au maximum avec les éléments du SI existant. L’interopérabilité de l’ELN est l’élément majeur de son intégration dans le SI.


%*******************************************
\subsection{Recommandations}
\subsubsection{Co-tutelles}
Quand chaque tutelle préconise ou utilise déjà un ELN, il est important que chaque ELN puisse exporter son contenu dans un format homogène, ouvert et documenté. Cela permettra aux différents scientifiques de faire circuler et partager les contenus et, ainsi, de décloisonner les travaux de recherche. \\

Étant donné qu’actuellement, aucun format standard n’existe pour les contenus d’ELN, l’accessibilité et de l’utilisabilité de ces formats d’export sont primordiales afin de créer les passerelles entre les ELN existants. \\

Il est vital que l’ELN puisse attribuer, \textit{a minima}, un identifiant pérenne (\textit{Persistent IDentifier} ou PID) et un horodatage à chacune de ses entrées. Dans l’idéal, il faudrait que l’ELN puisse adresser directement ces identifiants à travers des référentiels (DOI, ORCID, etc.)


\subsubsection{Intégration}

Privilégier les ELN qui s’intègrent de manière transparente avec les outils déjà utilisés dans l’établissement. \\

Cette intégration peut se faire nativement sans nécessité de programmation mais peut également se réaliser à travers l’usage d’interfaces de programmation (API). Dans ce cas, privilégier un ELN dont les API sont bien documentés. \\

L’ELN doit pouvoir s’interfacer avec les systèmes déjà présents tels que la gestion des identités, les GED, les VRE, entrepôts (Dataverse, forge logicielle, etc.) ou encore les environnements de calculs (\textit{notebooks} tels que Jupyter et Scilab, R-studio etc.)


\subsubsection{Accès aux données}

Considérer la capacité de l’ELN à accéder et à lire les données stockées en dehors du système et plus particulièrement les grands jeux de données qui ne peuvent y être importés. \\

Il est important que l’ELN puisse accéder aux données et métadonnées stockées dans les dépôts (Dataverse, CKAN, etc.) afin de permettre la réutilisation des données de la recherche.


\subsubsection{Sauvegarde et archivage}

Dans le cas où l’ELN embarque un mécanisme de sauvegarde, il doit pouvoir être paramétrable et opérable sans limitation aux responsables de l’établissement utilisateur. Les éléments sauvegardés doivent être accessibles et restaurables à gré. \\

Dans le cas contraire, la structure de l’ELN doit le permettre. La sauvegarde des données de l’ELN doit pouvoir s’effectuer de l’extérieur à travers des images de l’arborescence du système de fichiers et des bases de données de l’ELN. Ces images doivent être restaurables, a minima, sur la même version de l’ELN et, dans l’idéal, avec une compatibilité ascendante et descendante. \\

Dans tous les cas, l’établissement utilisateur a tout intérêt à pouvoir accéder à un historique des contenus de l’ELN qu’il utilise. En cas de corruption ou de perte de données, il doit pouvoir faire face à travers une restauration de cet historique. \\

L’ELN doit pouvoir exporter tout ou partie de ses entrées dans un format ouvert afin de devenir une archive pérenne. Ces exportations doivent inclure toutes les métadonnées, médias associés et références nécessaires afin qu’ils puissent être exploitables indépendamment de l’ELN.


%*******************************************
\subsection{Résumé}

Veiller à ce que l’ELN puisse stocker et manipuler des données aux formats ouverts en entrée ET en sortie. \\

Veiller à ce que l’ELN offre une API bien documentée pour faciliter son intégration dans l’écosystème informatique s’il ne le fait pas nativement. \\

Veiller à ce que le contenu de l’ELN puisse être sauvegardé et archivé.



