# Recommandations sur les contours d'une offre de service institutionnelle INRAE permettant l'utilisation par ses unités d'un Cahier de Laboratoire Électronique (eLabFTW)

Laurent Cauquil, Eric Cotteux, Fanny Dedet, François Ehrenmann, Olivier Galland, Sébastien Guyader, Maud Pilon, Eric Quinton, Tovo Rabemanantsoa, Fanny Robledo-Garcia

► To cite this version:

Laurent Cauquil, Eric Cotteux, Fanny Dedet, François Ehrenmann, Olivier Galland, et al. Recommandations sur les contours d'une offre de service institutionnelle INRAE permettant l'utilisation par ses unités d'un Cahier de Laboratoire Électronique (eLabFTW). Inrae. 2025. hal-05078839

HAL Id: hal-05078839

https://hal.inrae.fr/hal-05078839v1

Submitted on 22 May 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_1.png" /></figure>

Distributed under a Creative Commons Attribution - ShareAlike 4.0 International License
Recommandations sur les contours d'une offre de
service institutionnelle INRAE permettant l'utilisation
par ses unités d'un Cahier de Laboratoire
Électronique (eLabFTW)

10 Octobre 2023

GT Cahier de Laboratoire Électronique : Eric Cotteux, Fanny Dedet, Laurent Cauquil, Maud Pilon, Sébastien Guyader, Eric Quinton, Olivier Galland, Fanny Robledo-Garcia, François Ehrenmann, Tovo Rabemanantsoa
# Préambule

L'émergence dans les laboratoires des technologies numériques pour l'acquisition de données expérimentales et leur traçabilité amène à faire évoluer les pratiques de recherche au sein des laboratoires, et en particulier à se tourner vers des solutions numériques de traçabilité des opérations de recherche que l'on nomme « cahiers de laboratoire électroniques ». Ceux-ci n'ont pas vocation à remplacer le cahier de laboratoire papier qui est encore employé car utile et fonctionnel, mais plutôt à être un nouvel outil apportant une réelle valeur ajoutée pour certains suivis expérimentaux et domaines de recherche.

## 1. But du document

Ce document a pour but de proposer des recommandations au déploiement d'eLabFTW par les unités INRAE demandeuses. Il présente l'analyse de 3 scénarios et souligne les points d'attention pour le choix, l'implémentation et l'exploitation de l'outil pour chacun de ces scénarios.

## 2. Objectifs et contexte du projet

Ce projet, qui s'inscrit dans le cadre du plan « Données pour la science » de l'institut, vise à mettre à disposition de toutes les communautés de l'établissement un Cahier de Laboratoire Électronique (CLE), véritable outil scientifique, avec deux objectifs :

* faciliter et améliorer la traçabilité des recherches, de l'intégrité scientifique, de la gestion des données, de la recherche d'informations, et de la datation des expériences par l'horodatage

* asseoir la certification de l'origine des travaux et répondre ainsi aux obligations légales et contractuelles en apportant la preuve de la paternité des travaux

Cette réflexion a été menée au sein d'un groupe de travail auquel ont participé dix agents INRAE (ITAs et chercheurs de différents profils). Ils ont été impliqués dans le déploiement et / ou utilisation d'une solution de Cahier de Laboratoire Électronique (CLE), ou ont manifesté un intérêt pour ce projet. Plusieurs directions fonctionnelles d'INRAE telles que la Direction pour la Science Ouverte (DipSO), la Direction des systèmes d'information (DSI), le Domaine de Management de la Qualité (DIAGONAL) ainsi que le Responsable de la Sécurité des Systèmes d'Informations (RSSI) ont également contribué à l'élaboration de ce document.

Le travail du groupe est issu de deux approches :

* expression des souhaits des agents au moyen d'une courte enquête réalisée auprès des unités (voir Analyse de l'enquête sur les cahiers de laboratoire électroniques à INRAE),

* analyse des recommandations du COSO sur les CLE (DOI : 10.52949/3), étude des caractéristiques souhaitées et nécessaires qu'un CLE devrait posséder pour respecter le contexte de l'établissement.

INRAE garantit à tous ses agents l'accès à eLabFTW selon leur demande et donc sans intention de l'imposer. Lorsque d'autres solutions sont utilisées, comme par exemple LabGuru préconisé par l'INSERM qui peut être co-tutelle d'équipe de recherche INRAE, ou suite à une sélection
propre au collectif concerné, l'entité initiatrice est totalement responsable du respect de la
conformité de l'outil choisi, vis-à-vis des objectifs de protection des informations contenues dans
le CLE et décrits dans le présent document.

Pour les entités optant pour un CLE autre que eLabFTW, et plus particulièrement pour celles
soumises aux dispositions de l'arrêté du 3 juillet 2012 sur la Protection du Potentiel Scientifique
et Technique (unités dites « ZRR »), il est indispensable qu'elles se rapprochent du RSSI.

## 3. Scénarios envisagés

Avant la parution de ce document, plusieurs entités (unités, centres, ...) ont déjà mis en production
une instance d'eLabFTW. Le premier scénario décrit essentiellement ce cas de figure. Le second
scénario évoque la mise en service d'un hébergement à la demande qui sera conjointement
opéré par la DSI et la DipSO. Le dernier scénario concerne la souscription d'une offre en
hébergement de type SaaS (Software as a Service) fournie par DELTABLOT, société qui
développe et propose eLabFTW, et d'EASTER-EGGS, société spécialisée dans l'hébergement
et l'infogérance de solutions à base de logiciels libres. Ce duo est la solution choisie par le CNRS
pour la mise en œuvre et l'hébergement de ses instances d'eLabFTW en mode SaaS.

### 3.1 Mono ou multi-instances ?

Avant d'aborder les différents scénarios, il nous semble important d'informer le lecteur sur les
différents arguments permettant de trancher entre les 2 modes de déploiement d'eLabFTW
envisagés, indépendamment des solutions relatives à l'hébergement des enregistrements.

* Un premier mode, dit « *mono-instance* », repose sur une instance unique d'eLabFTW
accueillant tous les utilisateurs liés à INRAE.

* Un second mode, dit « *multi-instances* », consiste dans le déploiement d'autant
d'instances que nécessaire, selon le(s) grain(s) choisis (département, centre, unité, projet,
etc..).

Le tableau ci-dessous synthétise les avantages / inconvénients de chacun de ces deux modes.

<table><thead><tr><th></th><th>Mono-instance</th><th>Multi-instances</th></tr></thead><tbody><tr><th>Avantages</th><td><ul><li>Facilite la coopération</li><li>Maintenance facilitée</li><li>Une équipe de maintenance dédiée spécialisée</li></ul></td><td><ul><li>Souplesse du paramétrage</li><li>Cloisonnement de la sécurité</li></ul></td></tr><tr><th>Inconvénients</th><td><ul><li>SPoF</li><li>Complexité architecturale</li><li>Niveau de sécurité unique</li><li>Équipe à plusieurs ETP</li></ul></td><td><ul><li>Multiplication des ressources nécessaires à la maintenance</li><li>Hétérogénéité dans la gestion</li></ul></td></tr></tbody></table>

* Avantages du Mono-instance

* Facilite la coopération : en termes de gestion des utilisateurs, il suffit de créer différentes équipes pour faire coopérer les agents, là où le multi-instances nécessite une nouvelle instance commune pour y parvenir.

* Maintenance : une seule instance à maintenir (mise à jour, sauvegarde, gestion des compte).
* Besoin de moindre en de temps de travail : une seule équipe pour maintenir l'instance.

* **Inconvénients du Mono-instance**

* SPoF : Single Point of Failure -> si l'instance est défaillante, plus personne n'accède au service.

* Complexité architecturale : obligation de perfection dans l'architecture de l'infrastructure sous peine de dette technologique. Elle devra être redondée, « dimensionnable » et particulièrement robuste.

* Niveau de sécurité unique : nécessite d'être fixé au niveau le plus haut pour toute l'instance, nécessaire aux groupes hébergés.

* Équipe de maintenance à plusieurs ETP : une seule instance institutionnelle nécessite une équipe à temps plein pour l'exploitation.

* **Avantages du Multi-instances**

* Souplesse : chaque instance est libre dans ses choix de maintenance et de gestion.

* Cloisonnement de la sécurité : si une instance est défaillante, les autres ne sont pas impactées.

* **Inconvénients du Multi-instances**

* Multiplication des ressources : il faut autant d'équipe (ressources humaines et matérielles) qu'il y a d'instance pour assurer la maintenance.

* Hétérogénéité dans la gestion : l'institut n'a pas de visibilité sur les manières de gérer les différentes instances déployées.

## 3.2 Description des scénarios

### 3.2.1 Scénario 1 : « On-premise » unité/centre/département

a. Une installation séparée pour chaque entité (unité, projet, centre,...) : eLabFTW pourra être installé de manière autonome par chaque entité qui est en capacité d'en assurer seule l'exploitation et dans le respect du cadre de sécurité défini par l'équipe cybersécurité.

b. Pas d'hébergement de données sensibles / critiques.

c. L'équipe cybersécurité fournit des **Recommandations et mesures de sécurité mode on-premise** à mettre en œuvre et qui sont partagées par la DipSO (PGSSI + POSSI).

d. Hébergement par la DSI ou par l'entité.

* **Avantages** :

i. Plus d'autonomie / Personnalisation logicielle.

ii. Stockage des données « à proximité » / Responsabilité et gestion reposant sur des équipes INRAE.

iii. Souveraineté.

* **Inconvénients** :

i. Le respect du cadre de sécurité et de confidentialité imposé par INRAE peut être complexe à mettre en place d'un point de vue technique.
ii. Exploitation et maintenance coûteuses pour l'entité en termes d'ETP nécessaires.

### 3.2.2 Scénario 2 : « On-demand » DipSO/DSI

a. Une offre de service institutionnelle : conjointement, la DSI et la DipSO offrent aux entités demandeuses un service d'hébergement d'instances eLabFTW à la demande, ainsi que l'ensemble des garanties procurées par le cadre technique défini. Une version en pré-production du service est en cours de développement. Il sera hébergé sur les infrastructures de la DSI et porté par la DipSO.

b. Pas d'hébergement de données sensibles / critiques.

c. Homologation + Sécurité : voir le Rapport d'analyse de risque mode DIPSO / DSI.

d. Hébergement sur l'infrastructure DSI, mais instance gérée par l'équipe opérationnelle CLE (à minima 1 ETP).

* **Avantages :**

i. Coût en termes de maintenance et exploitation.

ii. Stockage des données « à proximité » / Responsabilité reposant sur des équipes INRAE.

iii. Souveraineté.

iv. Souplesse et réactivité pour les MAJ système et applications.

* **Inconvénients :**

i. Si choix du mode multi-instances, nécessité d'avoir du personnel à temps plein pour administrer et exploiter les multiples instances.

ii. Plus de responsabilité pour l'équipe opérationnelle CLE.

### 3.2.3 Scénario 3 : SaaS Deltablot / Easter-Eggs

a. eLabFTW est accessible en mode service web : la DipSO soutient une offre de service hébergée dans le cloud, reposant sur une infrastructure SecNumCloud (DeltaBlot + Easter-Eggs assurent l'exploitation et la maintenance de la solution clé en main).

b. Offre sur la base de trois tailles d'instance différentes, Small, Medium et Large et d'un distinguo entre instances mutualisées (instances séparées, mais partageant la même architecture de frontaux web et de DB) et instance dédiée (une VM dédiée à une instance). Les instances dédiées sont recommandées pour les unités dites sensibles ZRR / SIRR / brevets / données de santé.

c. Hébergement SecNumCloud (pour les données critiques).

d. Mise en service - Infogérance H24 - Maintien en conditions opérationnelles.

e. Sécurité et analyse de risque à réaliser avec DeltaBlot / Easter-Eggs.
* **Avantages :**

i. Installation et exploitation par le prestataire sur un hébergement externe qualifié SecNumCloud (certification HDS si choix 3DS OUTSCALE => non proposée *pour le moment* dans le cadre de cette offre. Cela devra faire l'objet d'une étude spécifique).

ii. Permet aux entités traitant des données sensibles / critiques de pouvoir accéder au CLE.

iii. Haut niveau de sécurité (déport de responsabilité) et meilleur niveau de disponibilité de l'infrastructure.

iv. Architecture technique prévue pour de la haute disponibilité.

v. MAJ automatiques pour l'ensemble des instances hébergées pour les entités.

* **Inconvénients :**

i. Délai de rédaction et de préparation du dossier de mise en marché (cahier des charges fonctionnels, recherche de prestataires, contractualisation).

ii. Dépendance au fournisseur (défaillance, panne ou faillite).

iii. Coût sur le long terme.

## 3.3 Estimation des coûts pour chaque scénario

Au moment d'évaluer le coût de la mise en place d'un tel service, il faudra absolument prendre en compte les points ci-dessous :

* coût du serveur (VM ou physique) :

* matériel

* énergie

* sauvegardes

* coût en terme de ressources humaines :

* installation, configuration, administration

* exploitation

* coût en terme d'accompagnement et support :

* formation des utilisateurs

* formation des administrateurs

* support technique

* formation pilote + référent technique

* coût de sortie :

* quelque soit le scénario, export des données

* coût de migration en cas de changement de scénario ou d'outil

* coût en terme de contraintes pour qu'eLabFTW soit un vrai support pour brevets :

* Horodatage certifié (120 € HT pour un pack de 500 jetons chez Universign)

* signature (par authentification renforcée clé USB / Janus+ ou TOTP)

### Modèle économique

* **Coûts à la charge de l'institut ou également des unités ?**

* L'institut incitant les différentes entités à utiliser un CLE, le GT pense qu'il doit supporter l'ensemble des coûts relatifs à l'infrastructure et à la mise à disposition de l'outil, ainsi que la prise en charge d'un support de premier niveau (assistance à l'installation + assistance utilisateurs + formation
initiale des pilotes CLE). De plus, selon la proposition d'offre de service choisie, il pourrait être perçu un sentiment d'inégalité selon la taille et les fonds disponibles de chaque entité / unité, les moyens de celles-ci étant très hétérogènes au sein de l'institut.

* Vigilance DSI / DipSO du Scénario 2 : moyens humains et/ou personnel dédié pour ce service cahier de laboratoire, qui est un outil important (mais pas stratégique) pour toutes les unités. Mutualisation possible avec d'autres services INRAE.

* Effectifs Infrastructure DSI : actuellement, 5 ou 6 personnes

* Effectifs DipSO : actuellement, 3 administrateurs système, **nous recommandons de prévoir 1 ETP en plus dédié pour le scénario 2.**

* Suite à l'entretien dédié à l'analyse de risque du scénario 3 avec les responsables de DeltaBlot et Easter-Eggs, il a été évoqué la mise en concurrence des scénarios 2 et 3 en terme de coûts (RH + infrastructure informatique). Les coûts estimés pour chacun de ces scénarios seront déterminants pour la prise de décision finale. En effet, des coûts relativement proches pourraient faire pencher la balance vers une solution externalisée totale (scénario 3), ce qui soulagerait les ETP DIPSO / DSI nécessaires au bon fonctionnement du scénario 2 pour la maintenance des infrastructures et des instances déployées. Le scénario 1 resterait une solution pour les unités gérant déjà leur propre instance.

* Après comparatifs des coûts entre les scénarios 2 et 3, et une nette différence de tarif pour l'institut sur le court et long terme (voir le document Coûts par scenarios), **nous recommandons de se diriger vers les scénarios 1 et 2 pour la majorité des entités (données non critiques / sensibles), en mettant l'accent sur le recrutement d'un ETP pour l'administration dans le cadre du scénario 2. Le scénario 3 peut être envisagé uniquement pour les unités manipulant des données critiques (ZRR, santé, OGM, secret défense), avec proposition de la certification SecNumCloud.**

A titre d'information et de comparaison, voir l'annexe 1 en fin de document « Offre de service eLabFTW du CNRS »

Voir l'annexe 2 en fin de document pour les « Tarifs eLabFTW en mode Saas (scénario 3) »

## 3.4 Caractéristiques pour le choix d'un scénario

### 3.4.1 Taille et granularité des instances

* **Scénario 1** : pas de recommandation particulière, mais faire attention au dimensionnement de l'infrastructure (VM / CPU / RAM / HDD). Voir la grille tarifaire des services d'infrastructures informatiques collectives.

* **Scénario 2** :

* VM ajustable en fonction de la taille de l'entité demandeuse (projet, unité, centre, département). Voir la grille tarifaire des services d'infrastructures informatiques collectives.

* Faire attention au cloisonnement des accès et des droits sur des instances accueillant des profils d'utilisateurs différents (privé, inter-EPST, Fac, étranger) cf. gestion des comptes dans Exploitation
* **Scénario 3** : mêmes recommandations que pour le scénario 2. Les tailles des instances sont proposées et gérées par le fournisseur, en fonction du nombre d'utilisateurs actifs sur chacune d'elle :

* Instance taille S (1 - 30 utilisateurs)

* Instance taille M (31 - 100 utilisateurs)

* Instance taille L (101 - 300 utilisateurs)

### 3.4.2 Sensibilité des données

**Pour les scénarios 1 & 2** : données de recherche standard (publiques, diffusion limitée, restreint et confidentiel)

**Pour le scénario 3** : toutes les données + données de recherche confidentielles - critiques (santé, ZRR, OGM, secret défense ... ?)

**Question** : existence ou non de données secret défense à INRAE ?

https://cybersecurite.intranet.inrae.fr/service-et-document/referentiel-documentaire/systeme-de-management-de-la-securite-de-l-information-smsi#echelle

**Données de santé et hébergement dans le cadre des cahiers de laboratoire électroniques**

Une question soulevée concerne les données de santé qui pourraient être traitées dans eLabFTW. Si la solution proposée par Deltablot s'appuie sur un hébergement opéré par une entité de Dassault Systems et habilité SecNumCloud, elle n'est pas homologuée HDS. Dans la discussion, Pierre-Yves Dillard, associé fondateur d'Easter-Eggs, nous informe que le stockage de données de santé ne serait pas astreint à l'homologation HDS dès lors qu'il serait réalisé en interne au service (l'unité) qui les produit, l'homologation ne s'appliquant qu'aux hébergeurs tiers.

La gestion des données externes (données brutes, volume important de données, etc.) ne sera pas réalisée au sein du CLE. En effet, celui-ci ne permet pas le stockage en son sein de grands volumes de données que constituent les résultats des expériences.

Garder en tête que les CLE n'ont pas vocation à stocker des données, mais uniquement des protocoles, des descriptions de manipulations / expériences et des résultats d'expérimentations « légers » en terme de volume de données. Une recommandation d'utilisation d eLabFTW pourrait être faite auprès des utilisateurs pour travailler avec des liens vers NextCloud ou des entrepôts de données dédiés.

### 3.4.3 Ressources

#### Scénario 1

* L'entité doit avoir les ressources humaines (à minima un administrateur système qui se charge des aspects configuration, accès, droits) et financières (coût d'hébergement) nécessaires pour l'installation, la configuration, l'exploitation et le maintien en condition opérationnelle de son instance.

* L'entité doit garantir la pérennité de son infrastructure.

* L'entité garantit la présence d'au minimum un pilote (référent) qui a la formation nécessaire pour promouvoir, déployer et accompagner les utilisateurs sur l'utilisation de eLabFTW.
### Scénario 2

* Mêmes recommandations que scénario 1.

* Additionnellement, les ressources humaines affectées au projet doivent avoir la maîtrise des technologies mises en œuvre.

### Scénario 3

* Veiller à ce que les instances hébergées aient vraiment besoin du niveau de sécurité fourni par l'hébergeur (cas données sensibles / critiques).

Dans tous les scénarios, l'institut devra fournir un espace d'échange autour des bonnes pratiques d'eLabFTW (Forum, FAQ, Base de connaissances, espace collaboratif).

## 3.5 Implémentation

### Infrastructure

**Scénarios 1 et 2** : nous recommandons que les bases de données et applicatifs soient déployés sur deux conteneurs différents, conformément aux recommandations techniques d'installation par l'éditeur.

Il est recommandé également de proposer un stockage maîtrisé, redondant et sauvegardé (sites distants), d'intégrer des sauvegardes régulières et des restaurations.

Afin d'assurer au maximum la traçabilité, la reproductibilité et la maintenance de l'instance, il est fortement recommandé d'utiliser des technologies d'automatisation de déploiement et de configuration des instances (Terraform, Pklumi, Cloudify, Ansible, Puppet, Gitlab CI/CD,...)

Étant donné la place qu'occupe le cahier de laboratoire dans le processus de recherche, il est important d'assurer un maximum de continuité de service. Pour y parvenir, il est recommandé de mettre en place une infrastructure redondée et, si possible, hautement disponible.

Il est recommandé d'avoir une instance de test et de production afin de valider la continuité de service lors de mises à jour applicatifs ou systèmes.

### Ressources humaines

**Scénarios 1 et 2** : l'entité doit identifier au minimum un référent technique qui veillera au bon déroulement de l'implémentation et au respect des règles de sécurité préconisées par le RSSI.

### Sécurité

**Scénarios 1 et 2** : Se référer aux [Recommandations et mesures de sécurité mode on-premise](#)

**Scénario 2** : Se référer au [Rapport d'analyse de risques mode DIPSO / DSI](#)
**Scénario 3** : Se référer au Rapport d'analyse de risques Deltablot / easter-eggs

## 3.6 Exploitation

### Ressources humaines

**Scénarios 1 et 2** : L'entité qui opère l'instance doit avoir une équipe technique qui sera en charge du maintien en conditions opérationnelles et de la maintenance de l'instance (mise à jour, sauvegarde, restauration...) => **1 ETP dédié à minima**

**Tous les scénarios** : L'entité utilisatrice doit identifier au minimum un référent (pilote) qui sera en chargement de l'accompagnement de sa communauté dans la prise en main et l'utilisation d'eLabFTW. Ce référent sera également le contact privilégié avec l'équipe technique en charge de l'exploitation de l'instance.

### Sauvegarde

**Tous les scénarios** : Il est crucial que chaque instance soit sauvegardée sur une infrastructure indépendante et distante de celle de production. Ces sauvegardes devront être sujets à un système de supervision et régulièrement vérifiées/validées. Voir la grille tarifaire des services d'infrastructures informatiques collectives, option « Sauvegarde à la demande ».

vDisk sauvegardé :

* granulométrie pour la récupération (au niveau d'un fichier par exemple)

* rétention des sauvegardes = sauvegarde quotidienne avec rétention sur 1 mois

La politique de sauvegarde devra être clairement énoncée et mise à la connaissance de chaque utilisateur. Il est important d'établir des procédures déterminant :

* la fréquence de sauvegarde,

* la mise en lieu sûr des supports,

* des vérifications de restauration régulières des données.

**S'inspirer de la politique de sauvegarde de RDG ?**

### Authentification / Gestion des comptes

Dans tous les scénarios, pour préserver une cohérence et une homogénéité par rapport à la création des comptes dans eLabFTW, nous recommandons de nous appuyer sur les modes d'authentification centralisés suivants :

* INRAE seulement : identification centralisée INRAE

* INRAE + autres EPST / université : Fédération RENATER

* INRAE + universités et entités publiques étrangères : Fédération EduGAIN

* INRAE + privé : identification centralisée INRAE + comptes locaux ou : fédération Renater avec les comptes CRU

avec récupération de l'attribut correspondant à l'affectation principale (code de l'unité pour INRAE), permettant d'attribuer des droits automatiquement.
L'authentification à 2 facteurs (Authentification à 2 facteurs MFA : Clé Janus+ ou TOTP) est préférable, mais n'ayant pas encore de recommandations de la RSSI au niveau de l'institut, cette décision / organisation serait à la charge de l'entité pour accéder à son instance. **Recommandations du GT : elle doit être imposée (dans le règlement d'utilisation) pour tous les agents disposant du droit « sysadmin » dans l'instance considérée, et optionnelle pour les autres personnes.**

## Archivage

Maintenance + Procédures : définir les durées de conservation et modalités d'archivage ou destruction des données.

# 4. Organisation et accompagnement

Pour faciliter l'adoption de l'outil, il est primordial d'organiser accompagnement dans le parcours de prise en main, de partager les bonnes pratiques et de faciliter l'accès aux connaissances sur l'utilisation.

## 4.1 Proposition de parcours aux entités pour accéder à eLabFTW

1. Organiser des webinaires de présentation de la ou des différentes offres de service.

2. Donner accès aux informations générales sur eLabFTW et à une ou des instances de test le cas échéant (exemple avec instances bordelaise, montpelliéraine, CANULAR pour le scénario 2 ou des instances de test fournies dans le cadre du scénario 3).

3. Mettre à disposition le cadre technique et de sécurité défini par INRAE si l'entité envisage une installation « On-premise » de eLabFTW (scénario 1).

4. Évaluer le nombre d'utilisateurs envisagés dans l'entité.

5. Identifier une personne en tant que pilote CLE dans l'entité (appui, accompagnement, formation) et une personne en tant que référente technique (infrastructure).

6. Sélection du mode d'accès à eLabFTW envisagé (« On-premise » unités OU « On-demand » DipSO / DSI OU « SaaS »).

7. Validation par la direction de l'entité et réalisation de la demande (prévoir formulaire de demande sur le portail ARIANE ?).

8. Décision pour l'attribution de l'offre demandée.

9. Formation pour le pilote CLE d'unité + référent technique pour déployer eLabFTW dans l'entité et accompagner les utilisateurs.

10. Assistance au paramétrage à la charge de l'unité si besoin (en fonction du contrat passé avec DeltaBlot).

11. Prévoir des temps de retour d'expériences entre les premiers pilotes
## 4.2 Pilote CLE de l'entité

La mise en place d'eLabFTW est à la fois un projet qu'il s'agit de préparer, de mettre en place puis de suivre en gérant les droits d'accès et assurant un support de proximité auprès des utilisateurs. Le rôle du ou des Pilotes CLE d'entité est donc de mener avec la direction de l'entité le projet de mise en place d'eLabFTW au sein de celle-ci.

* Mener la réflexion préliminaire sur les éléments essentiels d'organisation liés à eLabFTW.

* Présenter l'outil et ses règles d'utilisation à l'ensemble des personnels de l'entité.

* Assurer l'ouverture et le suivi du ou des CLE de l'entité.

* Diffuser et mettre à disposition les documents d'aide pour l'organisation et l'utilisation d'eLabFTW.

* Assurer un appui de premier niveau auprès des utilisateurs.

* Être le point d'entrée des informations relatives à l'outil et le contact privilégié de l'équipe projet CLE.

Le référencement des Pilotes CLE permettrait de créer une communauté d'utilisateurs d'eLabFTW, qui pourront échanger sur les bonnes pratiques, partager les retours d'expérience, et contribuer ainsi à la vie de l'outil.

## 4.3 Description des types de support et d'accompagnement à mettre en place

Comment accompagner le changement avec l'arrivée d'un nouvel outil amenant une nouvelle organisation et une nouvelle culture ?

Cela nécessite un accompagnement au sein de l'entité en termes :

* de communication pour comprendre le sens global de la démarche, les bénéfices apportés aux utilisateurs et à INRAE plus globalement,

* de formation pour que chaque collaborateur puisse facilement prendre en main le nouveau process, le nouvel outil modifiant leurs usages du cahier jusqu'ici au format papier,

* d'accompagnement afin que les principaux utilisateurs de la solution puissent s'approprier et promouvoir toutes les bonnes pratiques et que les responsables adoptent également la solution comme outil de traçabilité et de collaboration.

Les actions associées doivent être un juste équilibre entre :

* une communication ciblée à plusieurs niveaux afin de sensibiliser au sens du projet, convaincre des bénéfices du projet et promouvoir les bonnes pratiques

* des formations aux utilisateurs sous forme de tutoriels vidéo, ateliers, sessions de retours d'expérience, etc...,

* un accompagnement technique (installation, utilisation et documentation sous forme de manuels utilisateur),

* la création de supports de type guide opérationnel, forum, FAQ, Base de connaissances, Newsletter.
# BILAN DES RECOMMANDATIONS

<table><tr><td>Scénario(s) recommandé(s)</td><td>Scénarios 1 et 2 pour la majorité des entités (données non critiques / sensibles)<br/>Scénario 3 avec SecNumCloud pour ZRR et entités traitant des données critiques / sensibles</td></tr><tr><td>Mono ou multi-instances</td><td>Scénarios 1 et 2 : machines virtuelles avec instances mutualisées<br/>Scénario 3 : 1 machine virtuelle pour 1 instance</td></tr><tr><td>Taille des instances</td><td>Scénarios 1 et 2 : minimum recommandé (1 VM / 2 CPU / 4 RAM / 50 Go Disk) + vDisk sauvegardé)<br/>En fonction du nombre d'utilisateurs actifs (voir coûts scénario 3)</td></tr><tr><td>Sauvegardes / Restaurations</td><td>Scénarios 1 et 2 : option vDisk sauvegardé + tests de restauration<br/>Scénario 3 : politique de sauvegarde, rétention (garanties sur sauvegardes : preuves qu'elles sont faites, répliquées sur d'autres infrastructures physiques, ...)</td></tr><tr><td>Ressources Humaines</td><td>Scénario 1 : administrateur système qui se charge des aspects configuration, accès, droits<br/>Scénarios 2 : 1 ETP AI pour l'administration, le déploiement et le maintien en conditions opérationnelles des instances<br/>Scénario 3 : Administration, déploiement et maintien en conditions opérationnelles par le prestataire. Paramétrage des instances si besoin dans contrat.<br/>Tous les scénarios : 1 pilote CLE par unité</td></tr></table>
<table><tr><td>Authentification / Gestion des comptes</td><td>Tous les scénarios<ul><li>INRAE seulement : identification centralisée INRAE</li><li>INRAE + autres EPST / université : Fédération RENATER</li><li>INRAE + universités et entités publiques étrangères : Fédération EduGAIN</li><li>INRAE + privé : identification centralisée INRAE + comptes locaux ou : fédération Renater avec les comptes CRU</li></ul>Authentification à 2 facteurs pour les sysadmin des instances</td></tr><tr><td>Documentation</td><td>Tous les scénarios : espace d'échange autour des bonnes pratiques (Forum, FAQ, Base de connaissances, espace collaboratif).</td></tr><tr><td>Formation</td><td>Tous les scénarios : création d'une cellule CLE qui prendra en charge les sessions de formation des pilotes CLE des entités et l'appui de second niveau.</td></tr></table>
# Annexes

## Annexe 1 : Étude de scénarios de mise à disposition d'une offre de service CNRS + analyse

L'accès à eLabFTW dans le cadre d'une offre de service du CNRS peut se faire de deux manières

<table><thead><tr><th>Mode On premise</th><th>Mode SAAS</th></tr></thead><tbody><tr><td><p>eLabFTW est installé de manière autonome par les laboratoires en capacité d'en assurer seuls l'exploitation</p><ul><li>Installation et exploitation par le laboratoire dans le respect d'un cadre technique et de sécurité défini par le CNRS</li><li>Assistance à l'installation par le prestataire</li><li>Authentification renforcée Janus+</li><li>Horodatage certifié</li><li>Assistance au paramétrage</li><li>Assistance utilisateurs</li><li>Documentation complète et FAQ</li><li>Formations aux pilotes CLE et supports de formation aux utilisateurs</li></ul></td><td><p>eLabFTW est accessible en mode service web pour les laboratoires n'ayant pas de capacité SI pour une installation propre</p><ul><li>Installation et exploitation par le prestataire dans un cadre technique et de sécurité défini par le CNRS sur un hébergement externe qualifié SecNumCloud</li><li>Authentification renforcée Janus+</li><li>Horodatage certifié</li><li>Assistance au paramétrage</li><li>Assistance utilisateurs</li><li>Documentation complète et FAQ</li><li>Formations aux pilotes CLE et supports de formation aux utilisateurs</li></ul></td></tr></tbody></table>

* 150 instances on-premise + 50 SaaS / Contrat de 1 500 000 euros sur 3 ans / 1 instance par laboratoire mais plusieurs instances possibles sur des VM mutualisées (on-premise et Saas)

* L'offre SaaS est sur serveur Deltablot / Easter-Eggs (déploiement et infogérance) sur du secNumCloud. Une instance est créée par laboratoire. Une VM est dédiée pour les ZRR ou unités ayant des données sensibles - critiques. Possibilité de SaaS avec un hébergement HDS.

* Différentes tailles d'instance : S, M et L (selon nombre d'utilisateurs actifs).

* Selon Deltablot : une grosse instance de 300 utilisateurs sur 2 ans produit environ 40Go de volume de données (à quoi correspond ce volume : BDD et/ou fichiers ?)

* Spécificité : authentification 2 Facteurs par clé USB (Janus +)

* Les deux offres On-premise et SaaS comprennent support, formation et documentation de la part du prestataire. L'offre On-premise comprend assistance à l'installation pour les unités. Pour les unités utilisant déjà eLabFTW et souhaitant intégrer l'offre sécurisée SaaS, la reprise des données est incluse dans la prestation de l'offre de service.

* Toutes les sauvegardes en mode SaaS sont réalisées et stockées sur les serveurs Easter-Eggs (le CNRS ne gère pas ses sauvegardes)
* Deux éléments restent à la charge des unités :

* l'acquisition des clefs physiques FIDO2 d'authentification renforcée JANUS+ (coût unitaire de 25€ par utilisateur);

* l'assistance au paramétrage (facultatif) issue des choix de l'unité à hauteur de 1000€ pour un paramétrage simple ou 2000€ pour un paramétrage avancé

* Horodatage choisi par CNRS : Universign https://www.universign.com/en/timestamp/

* lots de 500 jetons

* horodatage automatique (1 fois / semaine) pour SaaS et on-premise pour éviter l'oubli ou la frénésie de l'horodatage

* facile à implémenter

* Mise en place au CNRS de pilotes CLE : personne support identifiée dans l'unité, responsable du bon paramétrage, support, présentation et documentation du CLE pour le personnel de son unité.

* présence obligatoire dans chaque labo / unité : ils sont formés et font les formations aux utilisateurs (espace réservé pour les pilotes, documents, supports). Pilotes formés par des formateurs internes CNRS (programme = données, gestion, les rôles dans eLabFTW, paramétrage, gestion des équipes / groupes... basé sur les bonnes pratiques https://qualite-en-recherche.cnrs.fr/wp-content/uploads/2022/11/Guide_bonnes_pratiques_CLE_V1.pdf). Instance de formation disponible pour former les utilisateurs.

* Assistance utilisateur sur 2 niveaux :

* **1er niveau**: assurée par le pilote CLE (usages de l'outil, choix d'organisation propre au laboratoire, formation)

* **2ème niveau** : destinée aux pilotes CLE, assurée par le prestataire

* En complément, le CNRS réalisera avec le prestataire des développements pour adapter l'outil aux besoins qui bénéficieront à l'ensemble de la communauté des utilisateurs.
## Parcours d'entrée d'une unité dans l'offre de service des CLE

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

## Programme de formation pour les pilotes CLE CNRS

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