# Schéma Stratégique du Numérique OSUG 2021-2025

Fabien Malbet, Françoise Roch, Bernard Boutherin

## ► To cite this version:

Fabien Malbet, Françoise Roch, Bernard Boutherin. Schéma Stratégique du Numérique OSUG 2021-2025. INSU, CNRS; INEE, CNRS; UGA - Université Grenoble Alpes; INRAE; IRD; Météo France. 2022, 82 p. hal-04173038

HAL Id: hal-04173038

https://hal.science/hal-04173038

Submitted on 28 Jul 2023

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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 4.0 International License
OSUG

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

Observatoire des
Sciences de l'Univers
de Grenoble

SSN OSUG

Schéma Stratégique du
Numérique OSUG

18 janvier 2022

Version 3.3

Auteurs: F. Malbet, F. Roch, B. Boutherin
## Historique des versions

<table><tr><td>3.3</td><td>18 janvier 2022</td><td>Version du SSN révisée après les remarques du conseil du 17/02/2022<ul><li>Section 6.2 « gouvernance ASR » : fréquence des réunions</li></ul></td></tr><tr><td>3.2</td><td>11 janvier 2022</td><td>Version du SSN révisée pour le conseil de l'OSUG du 17/01/2022<ul><li>Section 1.3 « méthodologie » : mise à jour du SSN</li><li>Section 2.1 « RH informatique » : situation RH et Fig. 6</li><li>Section 2.2 « équipe ASR OSUG » : comex + task force LECA</li><li>Section 2.3 « équipe OSUG-DC » : RDev</li><li>Nouvelle section 2.7 « référentiel OSUG» et Fig. 8</li><li>Section 2.8 « Calcul intensif » : Gricad + cluster DAHU</li><li>Section 3.1.1 « IGE » : situation nouvelle</li><li>Section 3.2.2 « IR RESIF-EPOS » : poste ISDeform+EPOS-GNSS</li><li>Section 3.5 « services communs » : tableau 4 des services OSUG/Gricad + sauvegarde des postes de travail</li><li>Section 6.1 « support aux labos » : ASR à l'IGE + tableau 7 sur les organisations ASR proposées</li><li>Section 6.3 « centre de données » : poste ISDeform+EPOS-GNSS</li><li>Section 6.4 « calcul intensif » : projet stratégique Labex</li><li>Section 6.6.1 « moyens humains » : tableau 8 des besoins RH à jour</li><li>Section 7.3.1 « annexe IGE » : situation ASR</li><li>Section 7.3.4 « annexe LECA » : situation ASR</li><li>Nouvelle section 7.5 « réponses aux question du conseil de l'OSUG du 20/09/2021 »</li></ul></td></tr><tr><td>2.2</td><td>19 septembre 2021</td><td>Version du SSN pour le conseil de l'OSUG du 20/09/2021</td></tr><tr><td>1.5</td><td>10 septembre 2021</td><td>Version consolidée du SSN partagée avec tout l'OSUG</td></tr><tr><td>1,0</td><td>31 août 2021</td><td>Première version complète du SSN soumise aux contributeurs</td></tr></table>

<figure><img src="image_3.png" /></figure>
## Liste des figures

<table><tr><td>Figure 1 : composition de la fédération OSUG avec les effectifs par unités.</td><td>6</td></tr><tr><td>Figure 2 : tutelles des différentes unités de l'OSUG.</td><td>8</td></tr><tr><td>Figure 3 : calendrier du Schéma Stratégique du Numérique de l'OSUG</td><td>9</td></tr><tr><td>Figure 4 : répartition du personnel informatique permanent par tutelle ou ressource</td><td>11</td></tr><tr><td>Figure 5 : évolution du nombre d'ASR entre 2017 et 2020 par structure</td><td>12</td></tr><tr><td>Figure 6 : répartition au 1/1/2022 des effectifs ASR des laboratoires</td><td>12</td></tr><tr><td>Figure 7 : répartition des emplois BAP-E permanents et non-permanents</td><td>13</td></tr><tr><td>Figure 8 : organigramme du service Système d'Information de l'OSUG au 1er janvier 2022.</td><td>14</td></tr><tr><td>Figure 9 : mode de gouvernance pour les activités ASR</td><td>18</td></tr><tr><td>Figure 10 : architecture de la plateforme de virtualisation de l'OSUG</td><td>18</td></tr><tr><td>Figure 11 : répartition des espaces de stockage mutualisé.</td><td>19</td></tr><tr><td>Figure 12 : architecture logiciel SILOSE du référentiel OSUG.</td><td>20</td></tr><tr><td>Figure 13 : utilisation des ressources CPU de GRICAD et du stockage Bettik.</td><td>22</td></tr><tr><td>Figure 14 : caractéristiques du projet Gaia Data</td><td>41</td></tr><tr><td>Figure 15 : organisation du calcul scientifique en France</td><td>42</td></tr><tr><td>Figure 16 : possible évolution de l'organigramme de l'OSUG à 5 ans.</td><td>51</td></tr><tr><td>Figure 17 : architecture Résif-SI</td><td>73</td></tr><tr><td>Figure 18 : illustration du flux de données de Theia/OZCAR.</td><td>78</td></tr></table>

## Liste des tableaux

<table><tr><td>Tableau 1 : effectifs des composantes de la fédération OSUG au 1er mai 2021</td><td>7</td></tr><tr><td>Tableau 2 : contribution du personnel de la fédération OSUG aux services de site</td><td>14</td></tr><tr><td>Tableau 3 : listes des plateformes de l'OSUG identifiées dans RéGEF</td><td>34</td></tr><tr><td>Tableau 4 : catalogue des services OSUG pour les laboratoires et OSUG-DC</td><td>35</td></tr><tr><td>Tableau 5 : investissement CPER projet CINAURA</td><td>38</td></tr><tr><td>Tableau 6 : historique et prévision de la mutualisation au sein de l'OSUG</td><td>49</td></tr><tr><td>Tableau 7 : organisations des équipes ASR de l'UAR et des laboratoires</td><td>52</td></tr><tr><td>Tableau 8 : besoins humains estimés jusqu'en 2025</td><td>55</td></tr><tr><td>Tableau 9 : coûts annuels informatique UAR OSUG</td><td>65</td></tr></table>

<figure><img src="image_4.png" /></figure>
Le Schéma Stratégique du Numérique (SSN) de l'Observatoire des Sciences de l'Univers de Grenoble (OSUG) est un document qui résulte de nombreuses discussions entre les membres de la fédération OSUG pour établir un cadre stratégique pour le développement du numérique entre ses différentes entités pour les 5 années à venir 2021-2025, conformément aux orientations demandées par les tutelles. Ce document, qui doit être approuvé lors d'un conseil de l'OSUG, permettra de donner une cohérence autour des actions de l'OSUG et de ses membres sur le numérique au sens large.

Un **premier chapitre** permet de présenter l'OSUG, le contexte du SSN et la méthodologie suivie pour construire le cadre et le retranscrire dans ce document. Le **deuxième chapitre** permet d'établir l'état des lieux de l'informatique au sein de l'OSUG ainsi qu'au niveau du site. Le **chapitre 3** fait le point sur chacune des unités et services d'observation de l'OSUG qui ont été consultés. Le **chapitre 4** aborde les jalons et évènements à anticiper pour une bonne préparation du SSN. Le **chapitre 5** est consacré à l'impact environnemental du numérique et donc sa traduction dans le cadre du SSN. Le **chapitre 6** se focalise sur la prospective et la stratégie que nous avons élaborée ensemble ainsi que sur la mise en œuvre de celle-ci. **C'est ce chapitre 6 qui regroupe les conclusions et qui peut être lu en premier pour les personnes qui souhaitent avoir rapidement les réponses proposées par l'OSUG** aux orientations demandées par les tutelles.

Le document est prévu pour être auto-consistant. Le **chapitre 7** regroupe donc les annexes qui détaillent les attendus du SSN et le contenu des discussions avec les différentes structures.

<figure><img src="image_5.png" /></figure>
# 1. Introduction

## 1.1. L'OSUG en bref

L'Observatoire des Sciences de l'Univers de Grenoble est une structure fédérative de laboratoires et d'équipes assurant des missions d'observation, de recherche, de formation et de diffusion des savoirs. La fédération OSUG rassemble actuellement plus de 1300 membres, au sein de 8 unités, 5 équipes de recherche et 2 unités d'appui et de recherche (UAR), sous multi-tutelles d'organismes nationaux (CNRS, IRD, INRAE, Météo-France) sur les campus de l'Université Grenoble Alpes (UGA) de Grenoble et de l'Université Savoie Mont-Blanc (USMB) de Chambéry. L'OSUG œuvre dans tous des domaines des Sciences de l'Univers, de la Terre et de l'Environnement –de l'écologie alpine à l'astronomie en passant par la géophysique, l'hydrologie, la glaciologie et les sciences humaines (géographie humaine, sociologie).

En pratique, l'OSUG regroupe en 2021 (figure 1 et tableau 1):

* 8 unités de recherche

- l'IPAG, Institut de Planétologie & d'Astrophysique de Grenoble,

- l'ISTerre, Institut des Sciences de la Terre,

- l'IGE, Institut des Géosciences de l'Environnement,

- le LECA, Laboratoire d'Écologie Alpine,

- le LEGI, Laboratoire des Écoulements Géophysiques et Industriels,

- le LESSEM, Laboratoire Écosystèmes et Sociétés En Montagne, unité INRAE,

- l'ETNA, Érosion Torrentielle, Neige et Avalanches, unité INRAE,

- EDYTEM, Environnements, Dynamiques et Territoires de Montagne

* 2 unités d'appui et de recherche

- l'administration et les services communs de l'OSUG (UAR OSUG)

- le Lautaret (UAR Lautaret)

* 5 équipes de recherche associées

- l'équipe FAME & FAME-UHD à l'European Synchrotron Radiation Facility (ESRF), équipe dépendant de l'Institut Néel

- l'équipe SigmaPhy, Signal-Images-Physique du Gipsa-Lab, laboratoire Grenoble Images Parole Signal Automatique

<figure><img src="image_6.png" /><figcaption>**Figure 1 :** composition de la fédération OSUG avec les effectifs par unités.</figcaption></figure>
<table><caption>Tableau 1 : effectifs des composantes de la fédération OSUG au 1er mai 2021..</caption><thead><tr><th rowspan="2">Labo/ Équipe</th><th colspan="2">Permanents</th><th colspan="3">Non permanents</th><th rowspan="2">TOTAL</th><th rowspan="2">Permanents</th></tr><tr><th>Ch/EC/CNAP</th><th>IT/Biatss</th><th>Post-docs</th><th>doctorants</th><th>IT/Biatss</th></tr></thead><tbody><tr><td>IPAG</td><td>57</td><td>32</td><td>24</td><td>43</td><td>18</td><td>174</td><td>89</td></tr><tr><td>ISTerre</td><td>107</td><td>43</td><td>42</td><td>78</td><td>23</td><td>293</td><td>150</td></tr><tr><td>IGE</td><td>101</td><td>51</td><td>26</td><td>57</td><td>44</td><td>279</td><td>152</td></tr><tr><td>LECA</td><td>29</td><td>21</td><td>5</td><td>21</td><td>7</td><td>83</td><td>50</td></tr><tr><td>LEGI</td><td>40</td><td>18</td><td>10</td><td>29</td><td>6</td><td>103</td><td>58</td></tr><tr><td>INRAe-LESSEM</td><td>22</td><td>22</td><td>3</td><td>12</td><td>12</td><td>71</td><td>44</td></tr><tr><td>INRAe-ETNA</td><td>21</td><td>7</td><td>6</td><td>10</td><td>3</td><td>47</td><td>28</td></tr><tr><td>EDYTEM</td><td>51</td><td>14</td><td>4</td><td>42</td><td>7</td><td>118</td><td>65</td></tr><tr><td>CNRM/CEN</td><td>8</td><td>18</td><td>6</td><td>9</td><td>2</td><td>43</td><td>26</td></tr><tr><td>GIPSA-lab / SIGMAPHY</td><td>6</td><td>1</td><td>0</td><td>10</td><td>0</td><td>17</td><td>7</td></tr><tr><td>LiPhy / LAME</td><td>6</td><td>4</td><td>2</td><td>3</td><td>0</td><td>15</td><td>10</td></tr><tr><td>PACTE/Environnements</td><td>18</td><td>1</td><td>3</td><td>7</td><td>0</td><td>29</td><td>19</td></tr><tr><td>UAR SAJF</td><td>1</td><td>7</td><td></td><td></td><td>3</td><td>11</td><td>8</td></tr><tr><td>UAR OSUG (& FAME)</td><td>0</td><td>21</td><td>0</td><td>0</td><td>7</td><td>28</td><td>21</td></tr></tbody><tfoot><tr><td>TOTAL</td><td>467</td><td>260</td><td>131</td><td>321</td><td>132</td><td>1311</td><td>727</td></tr></tfoot></table>

- l'équipe CEN, Centre d'Études de la Neige, du CNRM, Centre National de Recherches Météorologiques

- l'équipe « Environnements » du laboratoire Pacte (Politique publiques, Action, politique et TErritoires)

- l'équipe LaME, Lasers, Molécules et Environnement, du LiPhy, laboratoire Interdisciplinaire de Physique

L'OSUG associe ainsi des spécialistes de toutes les disciplines des Sciences de la Terre, de l'Univers et de l'Environnement, mais aussi des experts en traitement du signal et des images, en spectroscopie, en sciences humaines, ainsi qu'en instrumentation de terrain et de laboratoire, bases de données et calcul scientifique de haute performance.

Les tutelles des unités de l'OSUG sont multiples et la meilleure façon de les représenter est le schéma présenté sur la figure 2, où les tutelles locales (l'UGA incluant la composante Grenoble-INP et l'USMB) sont représentées par les formes verticales tandis qu'horizontalement sont représentées les tutelles nationales : le Centre National de la Recherche Scientifique (CNRS) avec ses principaux instituts nationaux thématiques, l'INSU (Institut National des Sciences de l'Univers), l'INEE (Institut National Écologie et Environnement), l'INSIS (Institut National des Sciences de l'Ingénierie et des Systèmes), l'INSHS (Institut National des Sciences Humaines et Sociales), l'Institut de Recherche pour le Développement (IRD), l'Institut National de Recherche pour l'Agriculture, l'alimentation et l'Environnement (INRAE) et Météo-France. Les laboratoires et équipes sont représentés par des formes quadrangulaires de taille correspondant à leurs effectifs et connectant leurs tutelles principales. L'identification des tutelles est importante lorsque l'on s'intéresse aux ressources mises au service des projets.

De par son statut, l'OSUG a pour mission d'organiser, de manière transverse aux unités fédérées en lien et en complément des organisations nationales et internationales existantes, la collecte, l'archivage et la mise à disposition de différents types de données, notamment celles issues des Services Nationaux d'Observation (SNO).

Les équipes des unités de l'OSUG peuvent aussi s'appuyer sur le LabEx OSUG qui a été renouvelé en 2020. Suite à des appels à projets, le LabEx permet de faire fonctionner les équipes de l'OSUG mais aussi d'investir dans des infrastructures matérielles et de financer des ressources humaines communes.
<figure><img src="image_7.png" /><figcaption>**Figure 2 : tutelles des différentes unités de l'OSUG.**</figcaption></figure>

## 1.2. Contexte du Schéma Stratégique du Numérique (SSN)

Les OSU étant des lieux privilégiés de dialogue avec l'université et le CNRS pour tout ce qui concerne le support informatique / calcul / données apporté aux laboratoires, ils ont pour rôle également d'optimiser l'organisation des personnels et des moyens matériels dédiés à ces activités.

En octobre 2019, le CNRS-INSU a donc envoyé une note de cadrage à l'ensemble des Observatoires des Sciences de l'Univers (OSU) français pour clarifier le rôle des différents acteurs liés au numérique localement et en demandant de proposer un « schéma stratégique du numérique » (SSN) à l'échelle de chaque OSU pour définir le niveau et le lieu d'affectation des moyens.

Le schéma stratégique du numérique (voir annexe 7.1) doit comporter les éléments suivants :

- la gestion des données d'observation notamment à travers les SNO en interaction avec les systèmes d'observations locaux ou régionaux et les Infrastructures nationales, européennes et internationales de Recherche (IR) ;

- la gestion des données administrées par l'OSU au service des unités affiliées ou d'autres unités si la plateforme mutualisée a un rôle national ;

- la gestion des moyens de calculs utilisés par ses équipes de recherche et d'observateurs ;

- et le support informatique aux unités de l'OSU ;

avec une évaluation des moyens consacrés aux divers éléments du SSN et une projection priorisée à 5 ans des moyens qui seraient nécessaires pour rendre le meilleur service aux unités affiliées à l'OSU.

Le SSN doit prendre en compte l'environnement offert à l'échelle locale par les autres partenaires et notamment les universités via leurs services dédiés à l'informatique, au calcul (mésocentres) et aux données de façon générale. Le SSN doit inclure également une liste des services
<figure><img src="image_8.png" /><figcaption>Figure 3 : calendrier du Schéma Stratégique du Numérique de l'OSUG</figcaption></figure>

supplémentaires proposés par l'OSU. L'objectif était d'aboutir à une première priorisation des moyens lors de la demande de moyens de l'automne 2020. A cause de la crise sanitaire ce travail est attendu pour la demande de moyens de l'automne 2021. A l'OSUG, nous avons commencé à travailler en janvier 2021 à l'élaboration du SSN car il nous semblait primordial de prendre en compte la vision de la nouvelle direction.

## 1.3. Méthodologie suivie par l'OSUG

L'OSUG souhaite s'appuyer sur l'exercice de construction du SSN pour créer une culture commune du numérique au sein de la fédération OSUG tout en respectant les spécificités de chacun. Cela implique plusieurs niveaux d'interventions :

- poursuivre le travail mené lors du Schéma Directeur de la Mutualisation Informatique pour ce qui concerne l'Administration Système et Réseaux (informatique labos et OSUG)

- poursuivre le travail en commun pour le Centre de Données OSUG (OSUG-DC)

- améliorer le lien pour le calcul entre les utilisateurs et les ressources locales (GRICAD)

- s'inscrire dans la stratégie nationale RéGEF de la mutualisation des plateformes analytiques

La construction du SSN est l'occasion de faire un état des lieux de l'utilisation du numérique dans les unités et permet :

- de définir un socle pour l'appui aux laboratoires et aux équipes en termes de support informatique et de services communs,

- de clarifier le rôle des différents acteurs locaux et de positionner l'UAR comme un point d'entrée pour les infrastructures locales de la DG-DSI et de GRICAD (voir chapitre 2) pour l'accès en particulier aux ressources de calcul, stockage, et aux infrastructures de virtualisation,

- de consolider le soutien RH et d'infrastructure aux services d'observations et aux bases de données,

- de clarifier les besoins pour les plans de « science ouverte » et d'organiser le soutien nécessaire.

Au delà de la demande initiale du CNRS/INSU, ce document permet d'établir une feuille de route pour planifier dans le temps les besoins associés pour obtenir le support de toutes les tutelles (UGA, CNRS/INSU, CNRS/INEE, IRD, INRAE, Météo-France,...).

Pour mettre en œuvre le SSN une gouvernance sera définie et mise en place qui aura la responsabilité de faire les arbitrages des moyens humains et matériels nécessaires au fonctionnement et aux projets.

La première réunion concernant le SSN s'est déroulée début 2020 avec l'équipe de direction OSUG précédente. La crise de la Covid-19 a modifié la planification du travail et la transition avec la nouvelle équipe a démarré en octobre 2020. Il a été entendu que le SSN serait du ressort

<figure><img src="image_9.png" /></figure>
de la nouvelle équipe sous la tutelle du nouveau directeur adjoint de l'OSUG chargé de la donnée et plus largement des systèmes informatiques. Par conséquent le travail s'est déroulé essentiellement dans un calendrier qui s'est étalé entre janvier 2021 et juillet 2021 (figure 3).

Notre méthodologie s'est appuyée sur le Schéma Directeur de la Mutualisation de l'Informatique qui avait été proposé en 2017. Le périmètre du document a été élargi aux données d'observation, au calcul et aux plateformes mutualisées. Nous avons rencontré chaque laboratoire, chaque équipe et chaque service d'observation pour faire le point sur sa situation vis à vis du numérique à l'OSUG. Cela a représenté près de 30 réunions allant de 2h à 3h permettant à la fois de partager la situation de l'informatique à l'OSUG et du côté des entités rencontrées, avec des situations très variées (voir annexe 7.2).

Nous avons rencontré par deux fois la Direction Générale Déléguée des Systèmes d'Information (DGD-SI) de l'UGA et la direction de l'UAR GRICAD qui regroupent les services et calculs mutualisés du site grenoblois.

Chaque début de mois, un point a été fait en comité de direction OSUG qui regroupe l'ensemble des directions des unités de l'OSUG. Nous avons tenu informés mensuellement les membres du centre de données OSUG-DC et les administrateurs systèmes et réseaux de l'OSUG.

Suite à la première présentation du SSN au conseil de l'OSUG (v2.2) effectuée le 20 septembre 2021, quelques additifs ont été apportés pour le conseil de l'OSUG du 17 janvier 2022. Ces ajouts sont notés avec une barre verticale gauche en bleu.

<figure><img src="image_10.png" /></figure>
## 2. État des lieux des moyens et projets mutualisés de la fédération OSUG

Pour faire l'état des lieux de l'informatique au sein de l'OSUG, il faut aborder à la fois les aspects ressources humaines dans la fédération OSUG (section 2.1) dont l'UAR OSUG pour les ASR (section 2.2) et OSUG-DC (section 2.3) et la gouvernance associée (section 2.4), et, les infrastructures de services (section 2.5), de stockage (section 2.6) et de calcul (section 2.7), ainsi que les ressources apportées par le LabEx OSUG (section 2.8).

### 2.1. Ressources humaines informatiques

Nous avons répertorié les ressources humaines (RH) informatiques des 5 laboratoires multi-tutelles (IPAG, ISTERre, IGE, LECA, LEGI). Pour le LESSEM et ETNA, l'INRAE est la seule tutelle pour les ressources informatiques. Enfin le laboratoire EDYTEM dépend de l'USMB. Nous n'avons pas pris en compte les ressources humaines des laboratoires des équipes associées à l'OSUG car elles sont gérées le plus souvent par leur unité d'appartenance.

Le CNRS (INSU, INSIS, INEE) apporte une large majorité des ressources humaines en BAP-E des unités de l'OSUG aussi bien pour les CDD que pour les postes permanents.

Côté permanents, le soutien des tutelles est régulier (hors vacance de poste). Le graphique de la figure 4 montre aussi l'apport du LabEx pour le financement de CDD ; la baisse en 2020 est due à la difficulté à recruter en BAP-E.

Le schéma directeur de la mutualisation établi en 2017 était rédigé dans un contexte de baisse des effectifs en infrastructure ASR. Le plan de recrutement a permis de consolider l'équipe de l'UAR qui offre des services mutualisés pour les laboratoires et les SNO (figure 5). Un assistant

<figure><img src="image_11.png" /><figcaption>Figure 4 : répartition du personnel informatique permanent (haut à gauche), CDD (bas à gauche) et total (à droite) par tutelle ou ressource.</figcaption></figure>

<figure><img src="image_12.png" /></figure>
<figure><img src="image_13.png" /></figure>

**Figure 5 :** évolution du nombre d'ASR entre 2017 et 2020 par structure. Les parties en couleur plus claires correspondent aux CDD alors que les couleurs sombres correspondent aux permanents.

ingénieur de l'UAR offre également du support mutualisé à IPAG et ISTerre. L'organisation choisie s'appuie sur la présence d'un responsable informatique dans chaque laboratoire. L'IGE est resté un an sans ce responsable suite à son départ et à une ouverture de poste NOEMI infructueuse ce qui a mis un frein à différents projets de mutualisation mais depuis novembre 2020 ce poste est pourvu.

L'histogramme de droite de la figure 6 montre l'effectif en infrastructure ramené à l'effectif du laboratoire. Dans cette figure nous distinguons les postes sous la responsabilité de chaque

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

**Figure 6 :** répartition au 1/1/2022 par rapport à la situation au 1/1/2021 des effectifs ASR des laboratoires de la fédération OSUG sauf EDYTEM, LESSEM et ETNA. Les croix rouges indiquent les pertes de personnel ASR durant l'année 2021.

Gauche: équivalent temps plein (ETP) par laboratoire ; droite : ETP normalisé pour 100 personnes. Les couleurs foncées correspondent aux postes permanents, les couleurs claires correspondent aux CDD. Les postes de couleur bleu sont sous la responsabilités des laboratoires alors que les postes de couleur verte sont sous la responsabilité de l'OSUG.

<figure><img src="image_15.png" /></figure>
<figure><img src="image_16.png" /><figcaption>**Figure 7 :** répartition des emplois BAP-E permanents et non-permanents au sein des unités de l'OSUG (sauf EDYTEM, LESSEM, ETNA) par métiers et leurs évolutions sur les 4 dernières années (2017-2020).</figcaption></figure>

laboratoire (couleur bleu) et ceux qui sont des postes mutualisés de la fédération OSUG mis en place dans les laboratoires (couleur verte). On voit que l'IGE et le LECA sont moins dotés en poste permanents pour l'infrastructure. Compte tenu de la différence d'effectifs l'écart correspond à 1,5 poste pour l'IGE et 0.5 poste pour le LECA. A noter que le poste CDD mutualisé à l'OSUG a été financé solidairement par les unités IPAG, ISTerre, IGE, LECA et OSUG jusqu'à juin 2021.

Lors de la campagne de mobilité 2021, les deux personnes en support ASR mutualisé à l'OSUG (celui sur support permanent INSU qui venait d'être doté et celui du CDD mutualisé) ont quitté leur poste. La personne en CDD à l'IGE en soutien aux activités ASR a aussi quitté son poste. Par conséquent, il ne reste plus en ASR labos que les personnes sur des postes titulaires de la figure 6 (les postes barrés par une croix rouge ont disparu).

Nous avons appris aussi cet été (en juillet 2021), que la mobilité FSEP pour le poste de responsable technique du service SSHADE était finalement infructueuse.

Lorsque l'on examine l'évolution de la répartition des métiers dans les unités (figure 7), on constate que :

* À l'IGE, coté infrastructure les effectifs sont en baisse malgré le remplacement fin 2020 de l'ancien responsable informatique parti en 2018. Le soutien au calcul s'est renforcé par le recrutement d'un ingénieur qui a intégré les équipes de recherche. Cet ingénieur consacre néanmoins 20% de son temps à GRICAD.

* À l'IPAG, les ressources globales se maintiennent, mais l'effectif par métier montre que la ressource dédiée à l'infrastructure est en baisse car un ingénieur BAP-E est affecté à une tache de directeur technique pour 80% de son temps depuis 2020. Le soutien au développement logiciel (essentiellement instrumental) au travers de la structure nationale EFISOFT augmente et une personne en CDD a été recrutée en 2020 pour le soutien au calcul scientifique.

* À ISTerre, les ressources sont en nette baisse en raison d'une part du transfert de deux permanents de l'équipe Résif-DC à l'UAR, et d'autre part de la baisse de 8 à 5 ETP en CDD pendant la période. Par ailleurs, ISTerre et son Service Informatique sont sur 2 sites : Grenoble et Chambéry avec la présence d'un ETP AI à 100% à Chambéry.

En termes de ressources humaines, on constate que certains métiers ne sont pas présents sur toutes les unités, comme par exemple le développement de logiciel, que ce soit instrumental ou pour les bases de données (par exemple absent au LEGI). De même le soutien au calcul est
<table><caption>Tableau 2 : contribution du personnel de la fédération OSUG aux services de site (ETP)</caption><thead><tr><th rowspan="2">Unité</th><th colspan="3">Services DGDSI</th><th colspan="3">GRICAD</th><th rowspan="2">Total</th></tr><tr><th>SUMMER</th><th>SPRING</th><th>GLPI</th><th>CIMENT</th><th>NOVA</th><th>GITLAB</th></tr></thead><tbody><tr><td>IPAG</td><td>0.2</td><td>0.1</td><td></td><td></td><td></td><td></td><td>0.3</td></tr><tr><td>ISTERRE</td><td>0.2-0.4</td><td></td><td>0.1</td><td>0.2-0.3</td><td></td><td></td><td>0.5-0.8</td></tr><tr><td>IGE</td><td></td><td>0.2</td><td></td><td>0.2</td><td></td><td></td><td>0.4</td></tr><tr><td>LEGI</td><td></td><td></td><td></td><td>0.3</td><td>0.05</td><td>0.05</td><td>0.4</td></tr><tr><td>UAR OSUG</td><td></td><td>0.1-0.2</td><td></td><td>0.5</td><td>0.1-0.2</td><td>0.05</td><td>0.75-0.95</td></tr><tr><td>Total</td><td>0.4-0.6</td><td>0.4-0.5</td><td>0.1</td><td>1.2-1.3</td><td>0.15-0.25</td><td>0.1</td><td>2.35-2.85</td></tr><tr><td></td><td colspan="3">0.9-1.2</td><td colspan="3">1.45-1.65</td><td></td></tr></tbody></table>

assez massif (en postes CDD mais pas en postes permanents) dans les unités sauf à l'IPAG où un recrutement vient juste d'avoir lieu (mais sur ressources projet sans activité transverse pour le laboratoire). Le soutien au développement de code calcul n'est souvent pas mutualisé dans les unités notamment dans le cas où la taille des codes ne permet pas de passer de l'un à l'autre (ex : NEMO).

L'OSUG privilégie l'utilisation des services de site (voir les services de la DGDSI et GRICAD à la section 3.5) lorsqu'ils répondent aux besoins des utilisateurs. Un certain nombre d'ingénieurs de l'UAR et des unités de l'OSUG participent ainsi à l'administration de ces services (voir tableau 2), à hauteur de 0.9 à 1.2 ETP pour les services de la DGDSI et de 1.35 à 1.65 ETP pour les services GRICAD.

Le service du système d'information de l'OSUG (OSUG-SI) est constitué de deux équipes qui interagissent de façon importante sur de nombreux projets (figure 8) : l'équipe OSUG-ASR en support à la recherche et l'équipe en support aux observations OSUG-DC. Il faut ajouter à ces équipes une ingénieure qui apporte un soutien au calcul intensif.

## 2.2. Équipe mutualisée en support de la recherche (OSUG-ASR)

L'équipe OSUG-ASR est à la mi-2021 constituée de 4 ingénieurs, dont 1 CDD et d'un poste vacant.

<figure><img src="image_17.png" /><figcaption>Figure 8 : organigramme du service Système d'Information de l'OSUG au 1er janvier 2022.</figcaption></figure>

<figure><img src="image_18.png" /></figure>
En 2017, l'équipe était constituée de 2 permanents (1 ingénieur Al chargé des sites Web et des outils collaboratifs, 1 responsable des Systèmes d'information également en charge du Service de calcul intensif), et d'un ingénieur en CDD chargé de la plateforme de virtualisation (avec une participation temporaire des ASR des unités pour assurer le niveau de résilience nécessaire). Suite au départ de cet ingénieur, et grâce au soutien de l'INSU dans notre démarche de mutualisation, nous avons obtenu un poste NOEMI en 2018, notamment pour prendre en charge la plateforme de mutualisation et pérenniser la fonction chef de projet expert infrastructure de l'UAR.

Le budget du LabEx OSUG a permis de conserver un CDD LabEx pendant 2 ans pour assurer un fonctionnement en binôme, assurer la continuité de service, permettre de faire évoluer nos infrastructures, assister les équipes de développement de l'OSUG-DC pour leur fournir les outils leur facilitant le déploiement d'applications.

Cela a également permis à l'OSUG de soutenir le laboratoire IGE, en difficulté suite au départ d'un ingénieur en CDD puis du responsable informatique de l'unité.

Suite au départ de 2 personnels permanents assurant le support respectivement à l'IPAG et à ISTerre, nous avons obtenu un NOEMI (non pourvu) en 2018, puis un poste permanent en 2019, en recrutement externe à l'UAR OSUG pour travailler en alternance (sur des périodes d'une semaine) dans les équipes support de l'IPAG et de l'ISTerre. Au printemps 2021, la personne recrutée a été retenue sur un poste NOEMI hors de l'OSUG et nous a quitté donc au 1er octobre 2021. Nous avons obtenu un NOEMI gestionnaire infrastructure à l'UAR pour la campagne de recrutement en cours depuis décembre 2021, mais sans candidats pour le moment.

L'équipe OSUG-ASR développe des services à destination des unités et de l'OSUG-DC (tableau 3, section 3.5). Pour coordonner les efforts, un comité exécutif ASR (ComEx ASR) a été mis en place suite au Schéma Stratégique de la Mutualisation 2017-2021. Il regroupe les responsables ASR des différentes unités et de l'OSUG pour discuter des harmonisations, mutualisations et travaux en commun qui peuvent être effectués. Ce ComEx est parfois élargi aux membres des directions des unités de l'OSUG, notamment pour les arbitrages. A cause de la crise sanitaire ce ComEx ne s'est plus réuni pendant environ un an (mars 2020-mars 2021), mais les réunions ont redémarré avec la construction du SSN à une fréquence hebdomadaire pendant la phase de construction du SSN puis tous les 15 jours. Cet outil est indispensable pour coordonner les efforts engagés en informatique dans les différentes structures.

L'équipe informatique de l'OSUG participe aussi activement au développement de services au niveau du site Grenoblois : 0,1 à 0,2 ETP pour les projets DGDSI et 0,65 à 0,75 ETP pour les projets GRICAD.

### Taskforce en soutien au LECA.

La situation informatique du LECA est devenue critique le laboratoire n'ayant plus aucun informaticien en support depuis les départs du responsable informatique (mobilité de Patrick Juen de l'IGE) puis d'un des assistants informatiques en CDD (réussite à un concours de Florent Barbault) et l'arrêt de travail prolongé depuis le printemps 2021 de l'assistant informatique titulaire du LECA.

L'UAR-OSUG a donc pris en charge le support informatique de ce laboratoire car la situation était complètement bloquée : plus d'achat de matériel, plus de création de compte informatique, plus de résolution des problèmes des utilisateurs. L'UAR OSUG a monté une « task force » afin de pallier aux demandes informatiques des membres du LECA :

- Un système de gestion de tickets basé sur GLPI a été mis en place pour le LECA. Les tickets sont envoyés aux ASR de l'UAR-OSUG.

- Les configuration et devis pour 7 postes de travail ont été réalisés et les commandes passées. Les nombreux problèmes d'authentification liés à l'utilisation du système Intragère ont été résolus.

- Le planning de réservation de l'OSUG a été étendu au LECA.

<figure><img src="image_19.png" /></figure>
- Le système de sauvegarde backuppc est proposé aux utilisateurs du LECA et commence a être déployé pour eux.

## 2.3. Équipe mutualisée en soutien aux observations (OSUG-DC)

Le Centre de Données OSUG OSUG-DC s'appuie sur une équipe de 10 ingénieurs affectés à l'UAR-OSUG et chargé du soutien informatique aux services d'observations et aux Infrastructures de Recherche des pôles Astronomie-Astrophysique (AA) et Data Terra qui concerne les domaines des Surfaces et Interfaces Continentales (SIC), de la Terre Solide (TS) et de Océan-Atmosphère (OA). Cette équipe regroupe des ingénieurs avec des profils développement, système d'information et base de données.

Les SNO (Services Nationaux d'Observation) ou IR (Infrastructure de Recherche) soutenus par l'équipe OSUG-DC sont à ce jour pour le pôle AA (Astronomie-Astrophysique: JMMC, SPHERE-DC, SSHADE ; et pour l'Infrastructure de Recherche (IR) Data Terra : Résif-DC et Theia/OZCAR.

Un regroupement à l'OSUG des ingénieurs informaticiens qui travaillaient pour ces structures a été entrepris depuis 2017 avec la mobilité de deux ingénieurs de l'IPAG à l'UAR en 2017 puis le remplacement de deux autres ingénieurs de ISTerre par des postes ouverts à l'UAR entre 2019 et 2021.

Pour le projet Theia/OZCAR, un ingénieur d'études en CDD a été recruté par l'IRD puis par l'ANR FairTOIS (portée par l'IGE) dont le but est d'implémenter les principes FAIR dans le système d'information Theia/OZCAR. Cet ingénieur a été affecté à l'UAR-OSUG en 2020. Des démarches ont été entreprises auprès de l'IRD pour pérenniser ce poste à l'UAR. L'ingénieure responsable technique du projet est à ce jour affectée à l'IGE ; il serait logique de poursuivre le regroupement des ingénieurs avec son rattachement à l'UAR-OSUG, des discussions ont commencé.

Il est à noter que les ingénieurs en CDD n'ont pas toujours suivi le regroupement initié en 2017. En effet les budgets permettant d'assurer leurs financements étant le plus souvent gérés par le laboratoire d'accueil des scientifiques, les CDD conservent le plus souvent un rattachement au laboratoire et non à l'UAR-OSUG ce qui n'est pas sans poser quelques difficultés.

### La mutualisation au sein d'OSUG-DC.

Au sein de l'équipe OSUG-DC un certain nombre de bonnes pratiques, d'outils et de moyens sont mis en commun et partagés qui s'appuient largement sur le catalogue de services OSUG décrit dans le tableau 4 :

- **Méthodologie agile** : cette méthodologie de travail est bien adaptée au contexte qui exige des contacts fréquents entre les utilisateurs scientifiques et les développeurs. Une formation agilité et Scrum a été organisée dès 2017 au sein de l'OSUG qui a regroupé les ingénieurs et les scientifiques des services. L'agilité est un principe partagé par l'ensemble des ingénieurs et des scientifiques des SNO et IR concernés.

- **Dépôt GitLab** : En 2016 les projets logiciels d'OSUG-DC étaient répartis sur divers dépôts logiciels, dont certains étaient gérés par les développeurs eux-même. Depuis trois ans un effort a été fait et aujourd'hui l'ensemble des projets logiciels d'OSUG-DC utilise le dépôt logiciel GitLab mutualisé à GRICAD. Ce dépôt fournit des outils pour gérer les projets et pour mettre en musique la méthode agile. Des bonnes pratiques d'usage de ces outils sont partagées au sein de l'OSUG-DC comme par exemple l'organisation d'un tableau de bord des listes d'« issues » pour organiser le travail en « sprints » agile.

- **Monitoring des serveurs et services** : depuis 2015 un service de monitoring des serveurs et des services est installé à l'OSUG. Il est basé sur le système Zabbix. Ce système de monitoring est adopté de façon systématique pour la surveillance des services d'OSUG-DC.

- **Infrastructure de machines virtuelles et de containers.** Le groupe OSUG-DC s'appuie largement sur les infrastructures fournies par l'OSUG pour héberger ses machines virtuelles et ses services. La mutualisation de l'infrastructure de Machines Virtuelles a permis de disposer d'une solution très redondante et d'un niveau de sécurité excellent. De plus cela a déchargé les développeurs d'une partie des tâches d'administration système qui leur incombaient dans le passé. Depuis quelques années la tendance est

<figure><img src="image_20.png" /></figure>
d'aller vers les containers qui permettent d'héberger des micro-services qui peuvent être instanciés à la demande en fonction des besoins des développeurs. L'équipe ASR de l'OSUG a su anticiper et accompagner ce besoin en mettant à disposition les outils nécessaires et en assurant les formations pour que les développeurs puissent intégrer ce nouveau paradigme. A ce jour plus de 150 containers sont déployés à l'OSUG pour offrir des services sur les données.

Le réseau métier RDataDev lancée en 2014 par deux ingénieurs d'OSUG-DC (V. Chaffard et G. Mella) et animé par eux est un réseau métier sur la gestion de données et le développement logiciel. Il regroupe aujourd'hui environ 70 personnes (1/4 chercheurs, 3/4 ingénieurs). Ses objectifs sont de faire partager les savoir-faire autour du développement logiciel et la gestion de données d'observations et de favoriser ainsi le développement des compétences et l'identification des bonnes pratiques.

Fin 2021 P. Bollard a rejoint l'équipe de pilotage de ce réseau ce qui permet à cette équipe de d'avoir un représentant de chacun des pôles d'OSUG-DC : AA (G. Mella), SCOA (V. Chaffard), Terre Solide (P. Bollard).

## 2.4. Gouvernance de l'informatique ASR de l'OSUG

Le COMEX-ASR a été mis en place en 2017 dans le schéma directeur de la mutualisation informatique comme décrit ci-dessous.

Une structure de gouvernance pour les activités ASR mutualisées est essentielle afin de mettre en œuvre et faire évoluer le présent schéma directeur de la mutualisation informatique à l'OSUG. Pour cela, nous avons adopté l'approche la plus simple possible afin que les circuits de décisions soient clairs et efficaces. La gouvernance s'appuie ainsi sur deux comités :

* **ComEx ASR restreint** : comité restreint aux responsables informatiques des unités impliquées dans l'effort de mutualisation informatique à l'échelle de l'OSUG. Le faible nombre de personnes dans ce comité permet des interactions efficaces et la prise de décisions collégiales. Ce groupe possède à la fois l'expertise technique et la connaissance des utilisateurs de leurs unités qui sont nécessaires à l'accomplissement des missions qui lui sont confiées (cf. schéma ci-dessous). Ce comité sera dans un premier temps animé par B. Boutherin, IR CNRS à l'UMS OSUG, puis ce rôle pourra tourner au sein du comité une fois le fonctionnement consolidé.

* **ComEx ASR élargi** : précédent comité élargi aux directions d'unités pour assurer les arbitrages nécessaires au bon fonctionnement de la structure. Pour des raisons de simplicité organisationnelle, ce comité pourra, selon les sujets abordés et le calendrier, se confondre avec le Comité de Direction de l'OSUG auquel seraient invités les membres du ComEx ASR restreint.

<figure><img src="image_21.png" /></figure>
<figure><img src="image_22.png" /><figcaption>Figure 9 : mode de gouvernance pour les activités ASR proposé lors du Schéma Directeur de la Mutualisation ASR en 2017.</figcaption></figure>

Les missions de ces deux comités sont résumées dans le schéma de la figure 9. Cette structure de gouvernance a été présentée et validée à l'occasion du Comité de Direction de l'OSUG du 7 février 2017.

## 2.5. Infrastructure de services : plateforme de virtualisation et containers

Un volet important du schéma directeur de la mutualisation ASR 2017-2021 concernait la rationalisation des infrastructures. Depuis une dizaine d'années, il devient possible de remplacer des serveurs physiques indépendants par des machines virtuelles (virtual machines abrégés en VM) hébergées sur des serveurs physiques peu nombreux dotés de capacités en mémoire et en espace disque importantes. La maintenance matérielle se réduit alors à quelques machines physiques pour plusieurs centaines de machines virtuelles.

L'OSUG a fait le choix de gérer sa propre infrastructure de virtualisation, en étant à la fois compatible et complémentaire avec le service de virtualisation WINTER proposé par la DGDSI

<figure><img src="image_23.png" /><figcaption>Figure 10 : architecture de la plateforme de virtualisation de l'OSUG, 5 serveurs ESX sont répartis dans les datacentres de l'IMAG et le SIMSU</figcaption></figure>

<figure><img src="image_24.png" /></figure>
<figure><img src="image_25.png" /><figcaption>**Figure 11 :** répartition des espaces de stockage mutualisé, à gauche des laboratoires (vert) et des services d'observation (bleu) et à droite de l'OSUG affecté aux machines virtuelles de l'infrastructure (bleu), des laboratoires (orange), et des services d'observation.</figcaption></figure>

de l'UGA (voir section 2.5). Notre choix s'est porté sur le système de virtualisation VMware, avec l'objectif de répondre à des demandes spécifiques qui ne peuvent être satisfaites sur WINTER, en terme de quantité de ressources mémoire, CPU demandées, en terme de flexibilité dans le déploiement et la gestion des configurations de machine.

Nous utilisons aujourd'hui les 2 plateformes OSUG et WINTER, avec environ 150 VMs sur celle de l'OSUG et 50 sur WINTER, pour héberger la quasi totalité des serveurs des unités INSU et des SNO et IR de la fédération OSUG.

Notre infrastructure s'appuie sur 5 serveurs physiques (figure 10), munis chacun de 512 Go de mémoire RAM et de volumétrie constituant le système de stockage distribué VSAN. Les 5 serveurs sont hébergés dans 2 centres de données de l'UGA géographiquement distincts. Cette solution a été dimensionnée pour répondre à nos besoins et assurer une haute disponibilité ainsi que de la fiabilité.

Nous utilisons en parallèle les technologies de container pour l'hébergement de services à la demande, plus légers et plus souples à déployer que les machines virtuelles. Nous avons acquis une expertise dans le domaine de l'orchestration de containers et mis en place une architecture utilisant la technologie Kubernetes et son écosystème. L'objectif est de faciliter le travail des équipes de développement et fluidifier le déploiement d'applications, en limitant les tâches d'administration système. Plusieurs projets (Metabase, Orchamps, Originalps et 3 PTN/SNO/IR : JMMC, OZCAR-Theia, Résif) utilisent déjà ce service. L'infrastructure totalise aujourd'hui environ 150 containers, répartis sur un cluster de production (12 VMs) et un cluster de test (3 VMs).

## 2.6. Infrastructure de stockage mutualisé

L'OSUG s'est fortement investi dans le projet SUMMER de stockage mutualisé de l'UGA. Un certain nombre d'ingénieurs des unités de l'OSUG participent au développement et au support de cette infrastructure de stockage sur le site Grenoblois.

Avec 1,3 Pétaoctets de données sur du stockage mutualisé SUMMER, les laboratoires de l'OSUG jouent clairement le jeu de la mutualisation (figure 11 gauche). L'OSUG a une taille critique qui en fait un usager majeur des services de site. Cela a permis de négocier fin 2019 avec la DGDSI

<figure><img src="image_26.png" /></figure>
une nouvelle offre de type extensif qui divise les coûts du stockage et de la sauvegarde par 3. Cette nouvelle offre a permis le fort développement du stockage mutualisé à l'OSUG.

L'infrastructure de virtualisation de l'OSUG utilise trois types de stockage mutualisés (figure 11 droite) :

- le stockage SUMMER est largement utilisé à la fois pour héberger les systèmes d'exploitation et pour héberger les données via des montages NFS.

- l'infrastructure de virtualisation de l'OSUG dispose de 50To de VSAN. Le VSAN est une technique apportée par VMWARE qui permet d'utiliser le stockage sur SSD et sur disque dur installé sur les cinq serveurs physiques ESX. Le VSAN est un stockage très performant, de plus il permet de mettre en œuvre différents types de redondance du stockage pour pallier les défaillances de disque ou à l'indisponibilité d'un serveur ESX.

- un système de stockage capacitif de 128 To financé par l'IR OZCAR en 2019 et partagé à parts égales pour les usages futurs de Theia/OZCAR et pour la sauvegarde « fichier » des machines virtuelles.

Pour ce qui concerne le stockage pour le calcul, nous verrons dans le paragraphe suivant que des moyens de stockage spécifiques sont associés aux plateformes de calcul, complémentaires aux moyens de stockage SUMMER qui assure un haut niveau de sécurité mais des performances insuffisantes pour le calcul. Les moyens de stockage GRICAD sont à la fois performants (système de fichiers distribué Beegfs), et un système de stockage objet distribué sur les différents clusters (basé sur la technologie IRODS) qui permet d'avoir ses données à disposition sur le cloud, et sert de passerelle entre le stockage sécurisé SUMMER et le stockage performant des clusters. Ces moyens sont adaptés au calcul mais présentent un niveau de résilience et de sécurité moindre que SUMMER.

## 2.7. Référentiel OSUG : un outil de suivi des effectifs pour la fédération

Le projet de référentiel jugé structurant pour la fédération et prioritaire pour les unités UAR-OSUG, IPAG, ISTerre, IGE, LECA a été initié par le COMEX-ASR dès 2021 et un groupe de travail a été constitué avec des informaticiens et des personnes en charge des RH et ASR. Le LEGI et Edytem ont rejoint ce groupe de travail pour intégrer le projet dès sa première version.

Le référentiel OSUG va s'appuyer sur le logiciel SILOSE (figure 12) développé par le LIG entouré d'une dizaine de laboratoires. Ce choix a été validé par les directions des laboratoires en COMEX-ASR élargi en juillet 2021.

<figure><img src="image_27.png" /></figure>
Des applications informatiques pour gérer des authentifications et des listes de diffusion s'appuieront sur la base de données SILOSE. Les données de SILOSE seront consolidées avec celles de BIPER de façon automatique.

Un Ingénieur d'Etudes en CDD a été recruté sur le projet pour développer les fonctionnalités nécessaires pour l'OSUG de février à octobre 2022.

Notre planification prévoit que le logiciel sera en production pour les laboratoires cités ci-dessus en septembre 2022. L'objectif est de simplifier et rendre plus robuste le suivi des effectifs des untés et de la fédération avec toutes les conséquences sur la simplification de la gestion de l'informatique (liste de distribution, droits d'accès aux espaces, etc).

## 2.8. Calcul intensif mutualisé avec GRICAD

Le service commun de calcul intensif (SCCI) de l'Observatoire a été créé en 1991 avec pour objectif d'accompagner les chercheurs, ingénieurs et doctorants dans leurs projets de modélisation et de simulation en leur offrant un accès souple à des plateformes de calcul mutualisées. Le périmètre historique du SCCI est constitué des laboratoires ISTerre et IPAG et de l'équipe SigmaPhy du GIPSA-lab.

Le SCCI est piloté par un responsable scientifique (E. Chaljub, CNAP, ISTerre) et un responsable technique (F. Roch, IR CNRS, UAR OSUG). Les activités en Sciences du climat et de l'environnement étaient fédérées au sein du pôle MIRAGE (périmètre IGE et LEGI dans l'OSUG, et LJK hors OSUG).

Le SCCI et MIRAGE ont rejoint en 1999 le mésocentre de calcul Grenoblois CIMENT (dont le responsable est E. Chaljub depuis 2009 et jusqu'à cette année 2021); le mésocentre a intégré en 2016 le pôle calcul de l'UMS GRICAD<fnref n="1" /> devenue UAR en 2021 dont les missions principales s'articulent autour des infrastructures, du calcul intensif et des données à l'échelle du site.

Aujourd'hui, la communauté des utilisateurs des moyens de calcul de GRICAD est organisée par pôles de recherches : IPAG, ISTerre, IGE, LECA, IRSTEA, UAR OSUG sont dans le pôle PAGE (Physique des particules, astrophysique, géosciences, environnement et écologie); le LEGI est dans PEM (Physique, ingénierie, matériaux); PACTE est dans PSS (Pôle Sciences Sociales).

Les plateformes de GRICAD sont mutualisées et opérées par des comités techniques composés d'ingénieurs de GRICAD et des unités de recherche des différents pôles. Les ingénieurs de l'OSUG participent activement aux comités techniques de GRICAD (environ 1.4 ETP) et ont toujours été présents dans les instances de pilotage (4 personnels OSUG sur 8 membres du bureau du comité des utilisateurs (COMUT) et 11 personnels OSUG dans le COMUT).

Suite à la démission de Emmanuel Chaljub en tant que responsable du COMUT et de son bureau, un nouvel organe de pilotage doit se mettre en place, probablement un comité scientifique de Gricad. Les missions de ce comité sont en cours de rédaction par les responsables de Gricad et devrait être prochainement proposées aux anciens membres du bureau.

Les ressources de calcul de GRICAD sont constituées des plateformes :

- "Froggy", première plateforme HPC mutualisée à l'échelle du site ; elle est aujourd'hui en fin de vie. Elle a été financée grâce à l'Equipex Equip@meso en 2013 et différentes contributions des laboratoires (dont 200 k€ du LabEx OSUG@2020 et 200 k€ CPER 2006-2013).

- Le cluster "Luke" est orienté traitements intensifs de données. Il a été construit au fur et à mesure des besoins et des possibilités de financement depuis 2013, la plupart des serveurs sont financés sur projets qui s'étalent au cours du temps.

- Le cluster "DAHU" : le mésocentre de calcul de GRICAD a obtenu en 2017 un financement de 100 k€ suite à un appel d'offre de l'IDEX afin d'opérer une jouvence de ses moyens. Ce budget, accompagné de différentes contributions des laboratoires et de l'INP, a permis la construction d'un cluster de calcul généraliste de plus de 3000 cores de calcul et 7 nœuds GPU. Trois nouveaux noeuds GPU seront prochainement installés et la partie

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

<footnote n="1">¹ GRICAD : acronyme de Grenoble Alpes Recherche - Infrastructure de Calcul Intensif et de Données</footnote>
<figure><img src="image_29.png" /><figcaption>Figure 13 : utilisation des ressources CPU de GRICAD (gauche) et utilisation du stockage Bettik à l'instant T (droite).</figcaption></figure>

## GPU du cluster va être migrée vers un cluster spécifique regroupant l'ensemble des noeuds GPU

Des moyens de stockage sont associés à ces plateformes :

- un stockage distribué performant "Bettik" (1,3 Po), basé sur la technologie BeeGFS est accessible depuis les clusters,

- le stockage très haute performance « Silenus » (70 To).

- un stockage type cloud de 750 To, accessible depuis tous les clusters, basé sur la technologie IRODS.

La fédération OSUG constitue la communauté d'utilisateurs la plus consommatrice des ressources de calcul et de stockage de GRICAD (figure 13). Pour une consommation totale de 98.6 Millions d'heures.core de janvier 2018 à fin 2021, l'OSUG a consommé 60 Millions d'heures.core, soit environ 60% des heures CPU utilisées sur GRICAD.

Des moyens de calcul (quelques machines en cluster) restent gérés par les laboratoires de l'OSUG. Ils sont plutôt orientés traitements interactifs et ciblés sur des applications spécifiques aux laboratoires, avec un environnement de développement similaire à celui de GRICAD qui leur permet de servir de tremplin vers le mésocentre. Il faut noter une spécificité à ISTerre où les chercheurs/étudiants effectuent toutes sortes de calcul sur des serveurs locaux, ce qui est ressenti comme essentiel pour le bon fonctionnement des projets scientifiques.

L'OSUG est également très utilisateur (et participe largement au support) des différents services (forge Gitlab, plateforme Openstack, Jupyterhub) qui constituent l'écosystème de GRICAD.

## 2.9. LabEx OSUG : « Habitabilité dans des mondes changeants »

Le laboratoire d'Excellence LabEx OSUG a été prolongé pour une durée de 5 ans dans le cadre du Programme Investissements d'Avenir lancé par l'État et mis en œuvre par l'Agence Nationale de la Recherche (ANR) pour la période 2020-2024. Cette deuxième phase du projet sur le thème de l'Habitabilité dans des mondes changeants a vocation à renforcer l'expertise et le savoir-faire de la communauté OSUG pour l'observation, la compréhension et la modélisation des systèmes naturels en abordant une diversité de sujets comprenant les exoplanètes, le système Terre, les ressources naturelles, et les risques. Le LabEx s'appuie sur une forte implication dans les infrastructures de recherche, sur l'utilisation innovante de moyens d'analyse, d'outils de télédétection et de plateformes techniques, ainsi que sur des capacités de traitement et de modélisation des données.

Le LabEx soutient les activités de recherche, d'observation et de formation de l'OSUG. Ainsi il peut financer une partie d'infrastructure mutualisée ou des postes d'informaticiens en appui aux activités retenues par le comité de pilotage de plusieurs manières :

<figure><img src="image_30.png" /></figure>
- les ETPT informatique financés les 5 dernières années par le LabEx sont Jacques Granier (IE) pendant 2 ans, Thomas Baron (IR) pendant 2 ans, et Michel Gravier (IE) depuis mars 2021

- les investissements matériels sont essentiellement l'infrastructure de virtualisation.

<figure><img src="image_31.png" /></figure>
## 3. Expression des besoins informatiques des différents acteurs de l'OSUG

Dans la démarche de construction du SSN, nous avons rencontré tous les acteurs du numérique ou leurs représentants au sein de l'OSUG ainsi que les autres acteurs du site Grenoblois. Les directions des unités ont été fortement mobilisées pour répertorier les équipes directement intéressées par le SSN. Dans cette partie, nous allons résumer plus de 60h de réunions lors d'une trentaine de rencontres (voir annexe 7.2).

Ces rencontres se sont divisées en réunions avec les directions des unités, les responsables de services d'observation ou de pôles de données, de personnels impliqués dans le calcul intensif, des représentants de plateformes mutualisées ainsi que les personnels du système d'information de l'OSUG. Nous n'allons pas résumer de manière exhaustive toutes ces heures de réunion mais identifier les contextes particuliers à chaque structure et leurs besoins au niveau du numérique. Pour les unités et équipes, les détails sont accessibles dans l'annexe 7.3, et, pour les Services Nationaux d'Observation et les Infrastructures de Recherche, les informations détaillées se trouvent dans l'annexe 7.4.

### 3.1. Laboratoires et équipes

#### 3.1.1. Institut des Géosciences de l'Environnement (IGE)

Présentation du laboratoire (Annexe 7.3 IGE)

État des ressources humaines à l'IGE (Annexe 7.3 IGERH)

En ce qui concerne les besoins en infrastructure, un gros travail a été amorcé pour sortir d'une solution maison de gestion du système d'information IntraGere. Des premières actions ont été menées pour la gestion de la messagerie et des listes de diffusion qui sont maintenant celles fournies par le site UGA (Zimbra et Sympa). Il est urgent de mettre en place un outil de gestion RH couplé avec un système d'authentification normalisé dans le cadre du projet référentiel de l'OSUG. L'autre chantier initié concerne la sécurisation des données du laboratoire en particulier le remplacement des serveurs sortis de garantie. Une solution s'appuyant sur le stockage mutualisé SUMMER est en cours de mise en place; 300 To de stockage extensif ont déjà été loués par l'IGE.

L'IGE participe à hauteur de 0,2 ETP au projet SPRING (gestion du réseau SDN) mutualisé avec l'UGA et un ingénieur participe également à hauteur de 0,2 ETP à l'infrastructure de calcul GRICAD.

En 2021, à l'IGE, en plus du remplacement du CDD à mi-temps avec le LECA et financé par une contribution mutualisée des 4 laboratoires CNRS-INSU/INEE et l'OSUG sur moyens propres, un deuxième CDD était financé sur fonds propres. Le CCD à mi-temps avec le LECA ayant réussi un concours et le CCD à temps plein ayant été recruté sur un poste projet, ces deux compléments aux titulaires ASR ont disparu. Les recrutements n'ont pas été fructueux pour le moment par manque de candidats. Par conséquent la situation ASR à l'IGE est préoccupante en 2022.

Par ailleurs, un des AI support et l'ingénieur calcul rattaché au code communautaire NEMO vont partir à la retraite d'ici fin 2022. Pour NEMO un concours externe était ouvert en 2021.

#### 3.1.2. Institut des Sciences de la Terre (ISTerre)

Présentation du laboratoire (Annexe 7.3 ISTERRE)

État des ressources humaines à ISTerre (Annexe 7.3 ISTERRERH.)

Le calcul est une activité importante à ISTerre qui représente une part importante du calcul à l'OSUG et également au niveau national (utilisation des ressources du Tier1 et implication dans le comité technique astrophysique et géophysique CT4).

L'Institut conserve son propre cluster de calcul composé de 10 serveurs. Celui-ci est très utilisé pour le laboratoire et les projets de recherche. Les serveurs de ce cluster sont hébergés dans un datacentre mutualisé. Ce cluster non mutualisé est justifié par l'utilisation de logiciels spécifiques,

<figure><img src="image_32.png" /></figure>
la nécessité d'accéder à des données non disponibles sur Ciment, le besoin de machines de proximité avec un financement propre et un accès réservé.

L'utilisation de l'intelligence artificielle explose à ISTerre entraînant un besoin de serveurs GPU. Une chargée de recherche à IRD qui est spécialiste de machine learning a été recrutée. Cette technique est utilisée en géologie pour la détection de signaux ainsi qu'en imagerie et données satellites. Des équipes sont en lien avec le GIPSA-Lab, expert du domaine.

ISTerre participe par ailleurs aux projets mutualisés de l'OSUG et de l'UGA : 0,2 ETP sont affectés sur des projets mutualisés de stockage SUMMER (DGDSI), 0,1 ETP sur la gestion de tickets GLPI (DGDSI), et 0,2 à 0,3 ETP sur l'infrastructure de calcul CIMENT (GRICAD).

### 3.1.3. Institut de Planétologie & d'Astrophysique de Grenoble (IPAG)

Présentation du laboratoire (Annexe 7.3 IPAG)

État des ressources humaines à l'IPAG (Annexe 7.3 IPAGRH)

Pour ce qui concerne les infrastructures, l'IPAG est un acteur fort de la mutualisation au sein de l'OSUG que ce soit pour le stockage (SUMMER), la messagerie (Zimbra) et l'authentification (LDAP). La quasi-totalité des serveurs (une trentaine) sont quasiment tous virtualisés sur la plateforme de l'OSUG. L'IPAG utilise sa propre solution de travail collaboratif sur Confluence qui donne toute satisfaction mais est limitée en nombre de licences pour les abonnés pour des raisons de coûts.

Un des besoins forts de l'IPAG est la mise en place d'un référentiel laboratoire pour la gestion RH, des comptes informatiques et des listes de diffusion.

L'IPAG participe aux projets de la DGDSI à hauteur de 0,2 ETP pour SUMMER et à hauteur de 0,1 ETP pour SPRING.

Le besoin de soutien au calcul dans les équipes de recherche se fait sentir. Un seul ingénieur calcul est présent au sein du laboratoire. Un renforcement avec la responsable calcul de l'OSUG serait le bienvenu.

### 3.1.4. Laboratoire d'Écologie Alpine (LECA)

Présentation du laboratoire (Annexe 7.3 LECA)

État des ressources humaines au LECA (Annexe 7.3 LECARH)

En terme d'infrastructure, la situation est très similaire à celle de l'IGE mais sans l'appui d'un responsable informatique: authentification, référentiel, stockage, etc... Le LECA pourrait bénéficier pleinement de la mutualisation des efforts ASR et support utilisateurs qui pourraient être mis en place par l'OSUG.

### 3.1.5. Laboratoire des Écoulements Géophysiques et Industriels (LEGI)

Présentation du laboratoire (Annexe 7.3 LEGI)

État des ressources humaines au LEGI (Annexe 7.3 LEGIRH)

Au niveau infrastructure, le LEGI opère une soixantaine de VM et de petits clusters internes avec des codes très lourds en termes mémoire en complément des moyens du site et nationaux. Les problématiques sont :

* de définir une stratégie de sauvegarde des données entre données brutes et réduites.

* le réseau Grenoble INP qui rend difficile l'utilisation du stockage SUMMER et les machines GRICAD en lien avec le stockage local. Le LEGI est favorable à une demande de bascule sur le réseau UGA.

Le LEGI est favorable à la mise en place d'un référentiel commun pour la fédération OSUG et souhaite utiliser plus les outils OSUG (DOI, base de données,...). Le LEGI manque d'outils pour faire des carnets de laboratoires électroniques. Il est très impliqué sur l'utilisation des apprentissages IA profond.

Le LEGI participe à hauteur de 0,4 ETP aux projets CIMENT, NOVA et Gitlab de GRICAD.
### 3.1.6. Environnements, Dynamiques et Territoires de Montagne (EDYTEM)

Présentation du laboratoire (Annexe 7.3 EDYTEM)

État des ressources humaines à EDYTEM (Annexe 7.3 EDYTEMRH)

Infrastructure : la sauvegarde des postes de travail se fait sur un NAS de 30To en local, mais le laboratoire aurait besoin d'une sauvegarde déportée. Le système de base de données interne BDDEDYTEM permet de tenir des cahiers de laboratoire des missions. Des collaborations existent avec l'OSUG sur l'hébergement de certains projets notamment Permafrost. Le mésocentre MUST à l'USMB fournit des ressources de calcul et de stockage. EDYTEM utilise le kit Web CNRS mais devrait basculer sur le kit-labo de l'Observatoire. EDYTEM ne dispose pas d'un Intranet et s'appuie sur les services du CNRS qui ne sont pas satisfaisants. L'unité a accès au réseau RENATER et est intéressé par la virtualisation à l'OSUG. L'utilisation du logiciel Metashape sur GRICAD dépend des possibilités de transfert et de rapatriement des données. EDYTEM n'a pas accès à l'authentification UGA (Agalan), mais des discussions sont en cours sur un accord cadre entre USMB et UGA. Les besoins de licence concernent Matlab via USMB, Argis (site UGA/USMB), labView [OSUG: licences mutualisée Matlab, IDL,...].

### 3.1.7. Laboratoire Écosystèmes et Sociétés En Montagne (LESSEM) et l'unité Érosion Torrentielle, Neige et Avalanches (ETNA) de l'INRAE,

Présentation du laboratoire LESSEM (Annexe 7.3 LESSEM)

Présentation du laboratoire ETNA (Annexe 7.3 ETNA)

État des ressources humaines du LESSEM et de l'ETNA (Annexe 7.3 LESSEM_ETNA_RH)

Ces unités n'utilisent pas de VM ni du stockage de type SUMMER. 7 serveurs de l'ex-IRSTEA et leurs données sont actuellement en cours de migration vers les datacentres de Montpellier et Toulouse. L'offre de calcul sur le site de Grenoble est mieux considérée que celle de la DSI INRAE grâce à la convention historique entre IRSTEA et GRICAD. Les équipes sont structurées avec un plateau de compétence qui gère une grande partie des données, mais des départs à la retraite risquent de réduire les forces d'appui de moitié d'ici 2025 alors qu'il y a besoin de soutien notamment en calcul. Les équipes sont intéressées à trouver des solutions soit à l'INRAE (centre Languedoc Roussillon) soit à l'OSUG. ETNA possède des bases de données en lien avec le LECA et l'IGE : BDOH, SNO Glacio-Clim et Cryobs-Clim. ETNA est l'opérateur de la base de données avalanche pour la DGRP (Département de gestion des risques).

### 3.1.8. Unité d'appui et de recherche OSUG (UAR OSUG)

Présentation du laboratoire (Annexe 7.3 UAROSUG)

État des ressources humaines à l'UAR-OSUG (Annexe 7.3 OSUGRH)

Les aspects infrastructures sont abordés plus tard dans le document.

### 3.1.9. Unité d'appui et de recherche du jardin du Lautaret (Lautaret)

Présentation du laboratoire (Annexe 7.3 Lautaret)

État des ressources humaines au Lautaret (Annexe 7.3 LAUTARETRH)

Le Lautaret est une petite structure qui gagnerait à intégrer une gestion mutualisée des moyens informatiques de l'OSUG. Une aide sur la gestion des bases de données et les sauvegardes serait très appréciée. Une des contributions fortes du Lautaret est pour le Pôle National de Données de Biodiversité en construction et qui devrait à terme faire partie de Data Terra.

### 3.1.10. Équipes associées à l'OSUG

Nous avons rencontré les responsables de 4 des 5 équipes associées à l'OSUG.

* Le Centre d'Etudes de la Neige de Météo-France (CEN)

Présentation (Annexe 7.3 CEN)

État des ressources humaines (Annexe 7.3 CENRH)

<figure><img src="image_33.png" /></figure>
Infrastructure : 5 serveurs locaux avec du stockage installés dans une salle informatique climatisée, sont utilisés notamment pour le traitement des données tomographiques. Une des problématiques est la passerelle réseau entre celui de Météo-France et le réseau UGA pour partager des services et transférer des données. Les besoins qui pourraient s'appuyer sur l'OSUG sont l'accès à des DOI, le serveur de publications, la participation au référentiel, le calcul, la gestion de la base de données tomographique. La direction du CEN est ouverte aux services communs qui pourraient être mise en place à l'OSUG. Elle pourrait également apporter des moyens. Elle pourrait également apporter des moyens.

* L'équipe Environnements du laboratoire PACTE

Présentation (Annexe 7.3 PACTE)

État des ressources humaines (Annexe 7.3 PACTERH)

Pacte utilise les services fournis au niveau national. La plus grosse difficulté est le manque de stockage et d'archivage. Le parc informatique est géré par l'UGA et est essentiellement constitué de machines Windows. L'infrastructure est virtualisée sur NOVA (Openstack GRICAD) et WINTER (VMWARE DGDSI). La question de la confidentialité des données est un point critique en SHS. L'équipe serait preneur de services communs OSUG.

* L'équipe FAME de l'ESRF

Présentation (Annexe 7.3 FAME)

État des ressources humaines (Annexe 7.3 FAMERH)

L'équipe a accès à toute l'infrastructure informatique de l'ESRF, mais a des besoins spécifiques qui pourraient être couvert au sein de l'OSUG. En effet à l'ESRF, les données chaudes sont accessibles pendant 90 jours, puis sont archivées et ne sont plus disponibles pour du post-traitement. L'équipe développe des traitements lourds nécessitant des serveurs puissants et de l'espace de stockage. Une des possibilités pourrait être de participer à GRICAD via l'OSUG en amenant des moyens grâce à l'Equipex Magnifix. Le modèle de fonctionnement de SPHERE-DC leur semble intéressant. Un problème est le transfert de données entre l'ESRF et l'UGA.

* L'équipe Signal-Image-Physique (SigmaPhy) du Gipsa Lab

Présentation (Annexe 7.3 SIGMAPHY)

État des ressources humaines (Annexe 7.3 SIGMAPHYRH)

L'informatique de l'équipe est gérée par le GIPSA Lab, et l'équipe n'a pas de besoin par rapport aux services communs de l'OSUG. Un des membres de Sigmaphy pourrait être intéressé par les aspects infrastructures, systèmes et réseaux. Le développement sur machines GPU est un point commun avec certains laboratoires de l'OSUG. Un ingénieur dans le service plateforme pourrait participer à des projets OSUG avec OSUG-DC ou RDataDev.

* L'équipe "Lasers, Milieux dilués et Environnement" (LaME, ) du LIPhy

Présentation (Annexe 7.3 LAME)

L'équipe LaME qui comprend une quinzaine de personnes dont 10 permanents n'a pas répondu à notre invitation à une rencontre, sans doute parce que l'informatique n'est pas source de questionnement à leur échelle.

Pour conclure cette section, nous constatons que la situation est très contrastée et qu'il y a un réel intérêt à travailler avec des moyens mutualisés en fonction des tutelles ou de la situation géographique des structures appartenant à la fédération OSUG.

## 3.2. Services nationaux d'observation et infrastructures de recherche

### 3.2.1. Centres de traitement, d'archivage et de diffusion de données en Astronomie et Astrophysique

Introduction soutien de l'OSUG aux SNO et IR Introduction_SNO_IR

<figure><img src="image_34.png" /></figure>
=> Description plus complète en Annexe 7.4 (AA)

o SPHERE Data Center

SPHERE-DC s'appuie sur les infrastructures mutualisées de l'OSUG et du site. Le site web est un sous-ensemble du site web SPHERE.

Il y a des besoins pour la mise en place d'un système de tickets ; d'un monitoring plus complet et pour l'écriture d'un Data Management Plan.

Le développement et la réduction des données continuent à être les activités principales. Il y a un enjeu de visibilité par rapport à l'observatoire virtuel (VO) à Marseille et les DOI. En projet la mise en place d'indicateurs pour l'utilisation du service (compter les remerciements) et d'actions pour inciter à citer le service.

Au niveau RH, l'ingénieur responsable technique a un rôle crucial. Le fait qu'il soit seul rend le service vulnérable en son absence. Une ERC (Cobrex) a été obtenue et une personne en CDD a été recrutée, mais les activités restent séparée. Il y a un enjeu à intégrer les développements Cobrex dans le SNO, ainsi que de récupérer les données GPI (Gemini Planet Imager), concurrent de SPHERE

O SSHADE

Au niveau infrastructure SSHADE utilise 3 VM OSUG, et un espace de stockage SUMMER de
50 Gb. Une documentation est mise régulièrement à jour. On recense 310 utilisateurs et 50
partenaires gestionnaires de bases de données enregistrés ce qui pointe vers le besoin d'une
plateforme de gestion de tickets pour les utilisateurs et les gestionnaires partenaires, une gestion
des accès conforme à la réglementation RGPD et l'établissement de statistiques pour les accès
depuis l'observatoire virtuel et un service de listes automatisées. Le monitoring Zabbix est à
renforcer. La génération de DOI utilise un préfixe dédié à SSHADE (à ce jour, plus de 270 DOI
ont été générés automatiquement par SSHADE). La migration de l'ensemble du logiciel de Python
2.7 vers Python 3 étant accomplie, les évolutions futures prévoient la fin de la migration de VM
vers des containers et la réponse aux sollicitations de l'ESRF/FAME. La certification « entrepôts
de données » d'une partie des données de SSHADE est envisagée.

Suite au recrutement du responsable technique (P. Bollard) sur un poste IR permanent à Résif-DC, le besoin d'un nouvel ingénieur permanent est critique pour la pérennité du service et à relativement court terme il faudra un support CNAP pour faire face au départ à la retraite du responsable scientifique.

o JMMC / MOIO

Les besoins du JMMC sont définis par sa communauté d'utilisateurs à travers les « journées du JMMC », des Assemblées Générales annuelles, et un conseil scientifique. Le service fonctionne avec 5 VMs des containers et une volumétrie inférieure à 2 Tb. Un serveur Web donne l'accès pour les utilisateurs aux données et aux logiciels du JMMC. Les évolutions futures comprennent les migrations vers de nouvelles technologies, le besoin de la forge intégrant documentation et et code (migration vers Gitlab). Côté supervision, il est nécessaire de développer des outils pour surveiller les connexions avec d'autres observatoires, notamment des outils mutualisés pour les statistiques. Cela peut être le terreau d'une culture commune entre SNO. Un des points saillants du JMMC est le suivi opérationnel sur plusieurs sites, à consolider avec les Centres d'Expertise Régionaux.

Les 3 services JMMC/MOIO, SSHADE-F, SPHERE-DC ont été regroupés par l'INSU dans le Centre d'Expertise Régional en Astronomie et Astrophysique OSUG-DC. Les ingénieurs BAP-E sont tous localisés au sein de l'UAR OSUG au sein d'OSUG-DC tandis que les responsables scientifiques sont basés à l'IPAG. Les infrastructures matérielles sont hébergées par l'OSUG et hébergés dans les datacentres du site.

3.2.2. Infrastructure de Recherche Résif-EPOS pour l'observation et la compréhension de la dynamique de la Terre interne

=> Description plus complète en Annexe 7.4 (RESIF_EPOS)

<figure><img src="image_35.png" /></figure>
- Résif-DC et SNO RAP

Le centre de données sismologiques national de Résif a pour mission la distribution en Open Data et l'archivage de toutes les données des réseaux sismologiques permanents et mobiles français regroupés au sein de Résif, ou partenaires de Résif. Les données Résif sont hébergées sur la plateforme de stockage SUMMER de l'UGA. Les services de données sont hébergés sur les plateformes de virtualisation de l'Université et de l'OSUG. Les infrastructures réseau sont gérées par l'UGA.

Au sein de Résif, le SNO RAP collecte et valide la donnée sismologique et édite les métadonnées associées. Il transmet données et métadonnées à Résif-DC. Cette activité de production est assurée par un ingénieur (0.4 ETP). Le SNO RAP a identifié le point critique lié au fait que l'activité de production soit assurée exclusivement par une personne et demande un renfort.

Le centre de données Résif-DC, héberge et distribue les données brutes et validées, les métadonnées et des services autour de la donnée sismologique. Deux ingénieurs y sont affectés à plein temps. Les opérations de routine concernant la gestion des données, de l'infrastructure et des logiciels font partie des activités de production courante. Ces deux dernières années, avec l'aide de personnel contractuel supplémentaire, les projets d'infrastructure ont porté sur la rationalisation des ressources, la supervision des systèmes, la reproductibilité et la documentation de l'architecture et la simplification de l'exploitation, ce qui a permis d'alléger les charges opérationnelles évaluées maintenant à 1 ETP.

En terme d'infrastructure, le service Résif-DC est satisfait des services SUMMER et WINTER fournis par l'UGA. Il est nécessaire cependant de rencontrer régulièrement le Comité Technique SUMMER pour connaître les perspectives d'évolution. Les services de Résif-DC sont hébergés sur des VMs et sur des containers. Dans le futur, les VMs vont tendre à être remplacées par des containers. Pour se rapprocher de l'OSUG et bénéficier de son expertise sur les containers, Résif milite pour que le renouvellement de la plateforme de virtualisation de l'OSUG (qui porte les containers OSUG) soit l'occasion de fusionner cette plateforme avec celle de l'UGA (voir &4.1).

Pour Résif, il est essentiel de séparer les opérations de routine et le développement de nouveaux services. Il faudrait 1 personne supplémentaire impliquée sur la partie calcul avec un profil de développeur. En ce qui concerne les Infrastructures de Recherche sur les parties mutualisées, il semble que les RH de GaiaData seront affectées à des activités transverses, mais MARMOR pourrait apporter des RH sur la partie traitement/système d'information.

La partie sismologique ainsi que le système d'information Résif est partie prenante d'OSUG-DC. Les ingénieurs BAP-E sont rattachés à l'UAR OSUG et sont hébergés dans les locaux d'ISTerre. Résif-DC s'appuie sur les infrastructures informatiques du site de l'UGA avec une contribution de l'UAR pour la partie container.

- ISDeform

La chaîne de traitement NSBAS s'appuie sur le logiciel ROI_PAC du Jet Propulsion Laboratory/Calltech pour gérer le traitement des données d'interférométrie radar (InSAR) depuis les données radar brutes fournies par les agences spatiales jusqu'à l'analyse des séries temporelles. Le besoin en terme de stockage est ~100Tb associé avec du calcul. L'objectif est de développer un WebService pour des calculs à la demande offert à la communauté. Il y a actuellement des discussions sur le nombre d'I/O et les priorités à donner.

Le besoin identifié depuis plusieurs années est de recruter un responsable technique qui pourrait être accueilli au sein de l'OSUG pour mettre en place un système de calcul à la demande en lien avec GRICAD dans le cadre de Data Terra/ForM@Ter.

Un poste NOEMI a été attribué fin 2021 par l'INSU.

- Autres SNO en Terre Solide et soutien technique

Sismologie, géodésie et instabilité des versants sont appuyés par les services de ISTerre Geodata et SIG.

Pour ces activités, les personnels utilisent des VMs de l'OSUG géré par l'ASR de ISTerre. La gestion documentaire est sur DokuWiki et apporte satisfaction, la gestion des tickets se fait sur

<figure><img src="image_36.png" /></figure>
GLPI. Pour des raisons historiques le monitoring est opéré sur Nagios géré en interne avec des plugins spécifiques (pas de Zabbix) une migration est envisagée vers la solution nationale Sinapse. Les équipes utilisent GitLab pour partager les codes. Le besoin en termes de stockage est d'environ 20 To. Pour les licences, l'équipe utilise 10 jetons de licence Labview ; une recherche de solution pour mutualiser les licences de CAO serait bienvenue. Une réflexion a été suggérée afin de mutualiser ces questions au niveau de l'OSUG.

### 3.2.3. SNO surfaces continentales et océan atmosphère et Système d'Information Theia/OZCAR

* **SNO surfaces continentales et océan atmosphère**

=> *Description plus complète en annexe 7.4 SNO_SCOA*

- **CLAP** (base de données nationale/internationale, données de l'IR ACTRIS-FR et ACTRIS-EU)

Les données « atmosphère » sont gérées comme données de l'IR ACTRIS sur le Pôle de données AERIS/EBAS en dehors de Grenoble.

- **AMMA-CATCH** (base de données locale (2014), visible dans le SI Theia/OZCAR (janv 2020) et eLTER-RI (sept 2021))

AMMA-CATCH s'appuie sur une base de données PostgreSQL et un serveur d'application. Le SNO a déclaré 42 DOI en 2018 avec les services de l'OSUG : des DOI avec 38 DOI de données, 3 DOI de sites et un DOI pour l'observatoire. Pour le moment, l'applicatif est sur un serveur physique géré par l'IGE. La migration sur une VM OSUG est prévue ainsi que pour les serveurs de base. Les données sont poussées dans le SI Theia/OZCAR depuis janvier 2020.

- **OHM-CV** (base de données locale IGE+OSUG et BDOH d'INRAE)

Une partie des données est sur la base de données hydrologique BDOH (INRAE); une autre sur le cloud OSUG. Ces dernières ont fait l'objet d'un data paper et d'un DOI déposé par l'OSUG-DC ; une dernière partie se trouve à l'OMP dans la base de données HyMeX.

Les données de BDOH sont poussées dans le SI Theia/OZCAR depuis septembre 2021.

- **GLACIOCLIM** (base de données locale IGE+OSUG)

Les données de GLACIOCLIM sont stockées sur SUMMER via la plateforme de l'OSUG. Une partie des données transite également via les pôles de données internationaux (World Glacier Monitoring Service, Global Land Ice Monitoring Service).

- **ELMER** (code communautaire)

Le code ELMER tourne sur GRICAD et les sorties science sont stockées à l'IGE.

- **ORE Draix Bléone** (base de données BDOH d'INRAE)

* **Infrastructure de Recherche sur l'observation de la zone critique OZCAR et le pôle de données et de services Theia**

=> *Description plus complète en Annexe 7.4 (OZCAR_THEIA)*

- **Système d'Information (SI) Theia/OZCAR** (*Description et plus de détail en annexe SI_OZCAR_THEIA*)

Theia/OZCAR est un SI national inter-organisme pour les données in-situ des surfaces continentales. Créé en 2017, il concerne les données de tous les SNO SIC. Pour le moment, parmi les 4 SNO SIC de l'IGE décrits ci-dessus seules les métadonnées d'AMMA-CATCH (depuis 2020 et celles de BDOH (depuis sept. 2021) sont poussées vers Theia/OZCAR faute de format pivot adapté. Theia/OZCAR à travers l'OSUG-DC devrait s'emparer de ce problème pour aider les 3 SNO à entrer dans le SI de Theia/OZCAR.

Au niveau matériel, Theia/OZCAR tourne sur 2 machines virtuelles de la plateforme de virtualisation OSUG depuis fin 2019 que l'IR OZCAR a contribué à financer. A moyen terme il y

<figure><img src="image_37.png" /></figure>
aura un besoin d'étendre les capacités du service dont le volume de stockage qui pourra être pris en compte dans le cadre de l'Equipex+ GaiaData et du mésocentre CIMENT.

Le service est déployé sur l'infra OSUG dans une architecture à base de containers orchestrée par Kubernetes, conforme aux recommandations GaiaData. Au niveau RH, il est indispensable que Theia/OZCAR bénéficie d'un ingénieur permanent supplémentaire avec un profil de développeur.

### 3.2.4. Contribution à l'infrastructure de recherche Data Terra

**=> Description complète en Annexe 7.4 (DATATERRA)**

A Grenoble, l'OSUG est plus particulièrement impliqué dans ForM@ter et la partie in-situ de Theia. Grenoble est identifié comme un des 8 nœuds principaux de l'Equipex GaiaData (Figure 14) ce qui devrait permettre de soutenir les efforts de développement du Centre de Données et de Services GaiaData de Grenoble. A terme, le pôle national de données de biodiversité PNDB devrait rejoindre Data Terra et les travaux à l'OSUG sur ce sujet doivent être abordés dans cette perspective.

Dans ce cadre-là, pour le développement des bases de données et de services, un certain nombre d'infrastructures devraient être accueillies notamment par GRICAD, mais aussi des renforts en moyens humains.

## 3.3. Calcul

Une description de la mutualisation du calcul au sein de l'OSUG et de l'UGA a été faite dans le chapitre précédent (section 2.7). Il s'agit ici de recenser les besoins à court, moyen, et long terme en termes de performances, visualisation, stockage, accès aux machines... suite à une réunion rassemblant des représentants de chaque laboratoire impliqués dans le calcul intensif.

A l'IGE, les équipes s'appuient sur les grands centres nationaux ou internationaux CINES, IDRIS (Jean Zay), mais utilisent les machines mutualisées de GRICAD, Luke, Dahu pour les calculs et Bettik pour le stockage, pour les besoins intermédiaires. La puissance de calcul est disponible et souple, notamment pour l'accès aux données. Cependant il peut y avoir des problèmes de rapatriement, car l'IGE a de gros consommateurs avec des données et des ressources, mais aussi des équipes hétérogènes. Il y a 18 projets actifs sur GRICAD qui permet de mutualiser les ressources (sortir des PC individuels) avec les équipes qui contribuent au financement des équipements. Cependant d'autres personnes ont besoin de ressources locales pour les utiliser avec des licences Matlab ou IDL.

A ISTerre, les moyens de calcul intensif mutualisés de GRICAD sont très utilisés. Cependant des moyens de calcul locaux sont maintenus pour une plus grande souplesse d'utilisation. L'environnement de calcul est homogène avec GRICAD, ce qui permet de passer plus facilement du niveau du labo, au niveau national. Les données des équipes ne sont pas accessibles depuis CIMENT et les règles d'ordonnancement ne sont pas les mêmes (les jobs sont limités en temps CPU sur GRICAD). A ISTerre, il y a 181 utilisateurs locaux. Pour info, la plateforme Bettik (solution de stockage performante pour Luke et Dahu) n'est pas adossée aux labos, mais offre un espace de stockage important de 1,3 Pétaoctets. En lien avec le groupe Calcul/Données, le responsable informatique d'ISTerre assure une communication efficace entre les utilisateurs (experts ou novice) et les moyens informatiques à disposition sur le site à la fois à l'échelle très locale à ISTerre avec les serveurs de calcul et à l'échelle du site avec Gricad/Ciment).

Au LECA, les machines de calcul de GRICAD sont très utilisées par une dizaine de personnels permanents, et une douzaine de non-permanents (master, thésards, post-doctorants) chaque année, avec des sessions de formation en interne. Les machines sont utilisées dans une démarche similaire à celle de l'IGE et ISterre : Luke et Dahu pour des calculs de modélisation ou de traitement de données, et Bettik pour le stockage intermédiaire des données et résultats. Les principaux logiciels utilisés sont R et des logiciels de bioinformatique généralement libres. Les sessions de formation en interne sont appréciées, pour faciliter la première approche et ne pas décourager les utilisateurs peu familiers avec l'environnement UNIX et qui ont du mal à se plonger dans la documentation sans aide. D'ailleurs, la plupart des utilisateurs travaillent uniquement sur

<figure><img src="image_38.png" /></figure>
un cluster à la fois via OAR (et non via CiGri) du fait de la difficulté d'utilisation et/ou du manque de temps d'apprentissage (dans le cas de stagiaires par exemple).

Historiquement à l'IPAG, les calculs concernent surtout des modélisations, mais on voit émerger de plus en plus de traitements de données avec des besoins de stockage. La philosophie est plutôt de ne pas acheter des moyens locaux, mais des nœuds sur Luke. Les chercheurs sont plutôt satisfaits même s'ils font quelques remarques:

- la documentation des services de GRICAD est insuffisante et elle n'évolue pas assez vite ;

- il faudrait que chaque utilisateur puisse être formé sur les moyens de calcul en fonction de ses besoins (ce qui rejoint le problème de documentation)

- il y a un manque de GPU dans GRICAD, même s'il y a des plans pour étendre ces ressources (plutôt destinés à des calculs portés de CPU sur GPU).

Les nœuds de GPU sont très sollicités et il est donc difficile de les tester, même entre machines de développement et de production même s'il y a des « bacs à sable » sur DAHU et Luke, avec un cas particulier sur les GPU.

Les besoins identifiés portent **sur les développements sur GPU**, notamment car il n'y a pas beaucoup de ressources disponibles. Le passage à des machines accélérées (GPU ou autre) est nécessité par les contraintes environnementale (un GPU nécessite environ 5 fois moins d'énergie électrique qu'un CPU à calcul équivalent). C'est la raison pour laquelle tous les calculateurs Tier0 et Tier1 prévus ou installés depuis 2020 en France et en Europe ont une partition accélérée (type GPU), dont notamment la futur machine exascale européenne portée par EuroHPC qui sera mise en production en 2024. Pour ces raisons, il est nécessaire de fédérer un effort, à la fois matériel (machines de test multi-cœurs) et humain (ingénieurs développeurs, physicien numériens) pour écrire des outils capables d'exploiter ces architectures accélérées. En astronomie par exemple, seulement 5 codes sont portés sur GPU sur 90 disponibles. Bien que les machines virtuelles proposées par GRICAD permettent de réaliser les premières étapes de développement en mono-GPU, le développement, le déboggage et le profilage de codes distribués multi-GPU nécessitent l'accès à des machines mutli-GPU physiques interconnectées. L'OSUG peut fédérer ces moyens de test, puis permettre l'accès au niveau national et européen à ces calculateurs accélérés. Notons qu'il y a de nombreux problèmes de recrutement car les compétences nécessaires demandent près d'un an d'expertise, et recruter sur des CDD n'est pas du tout attractif. De plus la maintenance de ces codes de nouvelle génération nécessite une expertise sur le long terme et une veille technologique, assez éloignés de l'expertise d'un physicien.

Au niveau national, l'offre « GPU » déjà très présente à l'IDRIS avec des processeurs NVIDIA Tesla V100, et plus récemment des NVIDIA A100, se renforce encore avec l'installation prochaine au CINES d'une plateforme intégrant des nœuds à base de processeurs AMD EPYC et d'accélérateurs AMD Instinct. Le cluster Dahu possède actuellement des GPUs V100 et A100 qui permettent de développer des codes GPU avant passage sur les calculateurs de l'IDRIS. Une réflexion est en cours au niveau de l'OSUG sur la possibilité d'acquérir des nœuds GPU mutualisés dans le cadre de Gricad et faire bénéficier les utilisateurs d'un accès privilégié à ces ressources locales, avant utilisation d'une infrastructure nationale. Le choix d'accélérateurs AMD Instinct pourrait être judicieux pour élargir l'offre locale des accélérateurs disponibles au niveau national. Des formations pourraient également être organisées sur ces plateformes locales.

**Un autre besoin identifié est la visualisation.** Un terminal graphique directement connecté permettrait d'exploiter des données sur place sur Bettik sans avoir à les rapatrier sur le réseau local. Sur DAHU un nouveau nœud est dédié à la visualisation.

Le calcul étant déjà très mutualisé les implications des utilisateurs se font souvent directement des laboratoires à GRICAD dans les différents comités d'utilisateur et/ou pilotage, sans passer par l'étape OSUG. Le bureau de GRICAD assure le pilotage avec 50% d'utilisateurs et 50% d'ingénieurs dans CIMENT. Il se réunit sur une base mensuelle et fonctionne en mode « best effort », car l'investissement dans le pilotage scientifique n'est pas reconnu par nos tutelles. Le

<figure><img src="image_39.png" /></figure>
comité des utilisateurs (ComUt) représente la recherche scientifique, mais manque de dynamique
car trop grand. Il n'existe que par les efforts mis par chacun. Dans le bureau du ComUt, l'OSUG
est bien représenté. En parallèle, la gouvernance côté OSUG n'est que peu impliquée mais il y
a plus de discussions scientifiques. Il faut un vrai dialogue avec GRICAD, unité qui est rattachée
au CNRS via Mathinfo (INSMI) alors que l'OSUG est rattaché à d'autres instituts du CNRS (INSU,
INEE, INSIS, INSHS,...)

Un constat est fait que l'on ne doit plus séparer calculs et données. En effet l'observatoire est concerné par le calcul, les données et les services (ayant du calcul sur des données). Le lien doit être fait avec les Equipex GaiaData et MESONET (plateforme Openstack sans moyens CPU/GPU);

Une question est soulevée sur la suite donnée à la ferme de calcul DAHU, dernière plateforme achetée par GRICAD et en exploitation depuis 2018. On attend le retour CPER (Contrat Plan Etat Région), dont 4M€ fléchés et la fin des financements des équipements par les labos. Pour le moment, ces infrastructures sont financées par des projets.

En conclusion, il faut trouver la bonne échelle pour les discussions au niveau de l'OSUG. Une suggestion est de créer une liste de diffusion interne plus locale et plus réactive que la liste de GRICAD.

3.4. Plateformes mutualisées et RéGEF

Dans les attendus du SSN, la question des plateformes doit être abordée. A l'OSUG, il existe différentes plateformes qui sont toutes concernées par le projet d'infrastructure de recherche RéGEF: « Réseau Géochimique et Expérimental Français ». Son inscription est attendue dans la feuille de route infrastructure du Ministère qui est en cours de mise à jour et aura des conséquences en terme d'ouverture des équipements et de politique de données.

En effet, le constat est fait que le poids des données de la géochimie/minéralogie dans notre compréhension et notre conceptualisation du système Terre est considérable. Les moyens analytiques et expérimentaux qui produisent ces données représentent un pan majeur de la quantification des processus en Géosciences et Sciences de l'Environnement. Dans le sillage des politiques nationales et internationales de structuration des moyens de la recherche autour d'infrastructures dédiées, RéGEF est une tentative de les rassembler au sein d'un même réseau.

Le montage du projet RéGEF avec les plateformes analytiques et les partenaires s'est étalé sur les années 2016-2018. Depuis 2019, les 12 réseaux de RéGEF fonctionnent dans le cadre de cette infrastructure, et ont mis en commun leurs réflexions pour faire avancer cette structuration. Le réseau RéGEF est une initiative portée par Le CNRS-INSU en partenariat avec les EPST, EPIC et Universités des UMRs qui hébergent les instruments.

RéGEF est une structure transversale qui met en œuvre des moyens pour fournir des mesures aux programmes de recherches, aux Services Nationaux d'Observation, et à d'autres Infrastructures de Recherche.

<figure><img src="image_40.png" /></figure>
<table><caption>Tableau 3 : listes des plateformes de l'OSUG identifiées dans RéGEF.</caption><thead><tr><td>Nom de la Plateforme</td><td>Réseau dans RéGEF</td><td>Unités</td></tr></thead><tbody><tr><td>Chimie analytique</td><td>Géochimie élémentaire</td><td>ISTerre</td></tr><tr><td>PLANETIPAG</td><td>Géochimie organique</td><td>IPAG</td></tr><tr><td>Air - O - Sol</td><td>Géochimie organique</td><td>IGE</td></tr><tr><td>Microanalyses</td><td>Microscopie et micro-analyse électronique</td><td>ISTerre</td></tr><tr><td>Géo-Thermo-chronologie</td><td>Spectrométrie AMS</td><td>ISTerre</td></tr><tr><td>Plateforme de Géo-Thermochronologie</td><td>Spectrométrie Gaz Rares</td><td></td></tr><tr><td>ICE Grenoble</td><td>Spectrométrie Stables</td><td>IGE</td></tr><tr><td>FAME & FAME-UHD</td><td>Spectrométrie et imagerie RX</td><td>OSUG</td></tr><tr><td>Synthèse et caractérisation</td><td>Spectrométrie et imagerie RX</td><td>ISTerre</td></tr><tr><td>Synthèse et caractérisation</td><td>Bio-géochimie expérimentale</td><td>ISTerre</td></tr></tbody></table>

RéGEF regroupe des instruments de mesure, d'imagerie et d'expérimentation au service d'une recherche scientifique qui s'intéresse aux transferts et transformations des éléments chimiques et de leurs combinaisons moléculaires. A Grenoble, les plateformes concernées sont identifiées dans le tableau 3. En ce qui concerne l'informatique, elle est spécifique aux plateformes avec souvent l'utilisation de logiciels propriétaires. Là où le SSN peut avoir du sens c'est d'aider à la mise en place de base de données sauvegardées et sécurisées pour s'engager dans les efforts de mutualisation et partage des données.

A Grenoble, il est important que les utilisateurs puissent accéder à leur données quelle que soit la politique de RéGEF, d'où l'importance de la participation de l'OSUG à GRICAD. Le besoin de GPUs (pas mal d'imagerie) et d'accès à de la CPU remontent; il faut pouvoir faire des traitements sur ces données.

Un des points communs à ces données est le référencement et la faible volumétrie nécessaire. La question de la localisation de l'entrepôt de données sera traitée par RéGEF et l'OSUG propose d'accompagner le mouvement Regef pour stocker et traiter les données en cas de solution locale.

### 3.5. Services communs

Parmi ces services :

- la mise à disposition de machines virtuelles sur une plateforme de virtualisation (voir section 2.5).

- le déploiement de VM, la mise à disposition de templates, la gestion centralisée des configurations (avec l'outil salt), la sauvegarde des VMs avec le logiciel Bacula sur du stockage bas coût. Nous n'avons eu à subir aucun arrêt de notre fait durant l'année 2020, toutes les opérations de maintenance de la plateforme ont pu être effectuées en maintenant les services en exploitation et ont donc été transparentes pour les utilisateurs.

- la mise à disposition et l'orchestration de containers (avec l'outil Kubernetes) est un service qui monte en puissance depuis 2019 avec une expertise grandissante dans notre équipe (présentation aux JRES en 2018, papier retenu aux JRES 2021). Ces solutions sont de plus en plus utilisées par les développeurs de l'OSUG-DC pour faciliter le déploiement d'applications, en les associant à des techniques d'intégration continue. Les développeurs sont ainsi petit à petit formés à l'utilisation de ces nouveaux outils ce qui conduit à une uniformisation progressive des pratiques au sein des services d'observations

- un service de monitoring (basé sur l'outil Zabbix), pour la supervision des services d'infrastructure, pour les laboratoires et les SNOs

<figure><img src="image_41.png" /></figure>
<table><caption>Tableau 4 : catalogue des services OSUG pour les laboratoires et OSUG-DC.</caption><tbody><tr><td rowspan="10">Services (développement et déploiement)</td><td rowspan="4">Méthode et outils projets logiciels</td><td>Formation Agile Scrum</td></tr><tr><td>Gitlab gricad, dépôt logiciel, vue projet, vue Kanban, Intégration Continue</td></tr><tr><td>Tickets OSUG-action TRAC</td></tr><tr><td>Edition collaborative de document UGA; pad UGA</td></tr><tr><td rowspan="2">Machines Virtuelles et containers</td><td>Installation de VM</td></tr><tr><td>Gestion de configuration de VM (Ansible, Salt)</td></tr><tr><td rowspan="2">Surveillance des services</td><td>Sauvegarde et restauration de VM</td></tr><tr><td>Containers en Intégration Continue</td></tr><tr><td rowspan="2">Communication et documentation</td><td>Infrastructure Kubernetes</td></tr><tr><td>Monitoring Zabbix</td></tr><tr><td rowspan="5">Réseau et authentification</td><td>grafana</td></tr><tr><td>Logs ELK</td></tr><tr><td>Web-spip</td></tr><tr><td>Publications</td></tr><tr><td>Wiki</td></tr><tr><td rowspan="10">Données</td><td rowspan="5">Bases de Données PostgreSQL</td><td>@IP, DNS, ouvertures de ports, demande de domaine (UGA)</td></tr><tr><td>SMTP redirection de mails</td></tr><tr><td>Portail HAProxy</td></tr><tr><td>SSH, ssh.osug.fr</td></tr><tr><td>VPN UGA</td></tr><tr><td>Certificat de serveur/service</td></tr><tr><td>Gestion des secrets</td></tr><tr><td>LDAP OSUG</td></tr><tr><td rowspan="2">Hébergement de données</td><td>Fédération d'identité, en prod. intranet OSUG</td></tr><tr><td>Création de BdD</td></tr><tr><td rowspan="4">Gestion des données</td><td>Gestion des accès aux Bases</td></tr><tr><td>Surveillance</td></tr><tr><td>Sauvegarde et restauration</td></tr><tr><td>Espace NFS SUMMER</td></tr><tr><td rowspan="3">Gestion des données</td><td>Folders sur le Cloud</td></tr><tr><td>Stockage objet</td></tr><tr><td>DOI</td></tr><tr><td rowspan="3">Gestion des données</td><td>DMP, template ANR en édition collaborative</td></tr><tr><td>shiny application</td></tr><tr><td>OZCAR Theia utilise MongoDB et Apache Jena Fuseki</td></tr><tr><td>Service OSUG</td><td>Service qui s'appuie sur un service DGDSI ou GRICAD</td></tr></tbody></table>

- la mise à disposition de services Web pour les unités (kit labo et kit intranet), pour les Services d'observations (kit SO-SPIP)

- la mise à disposition d'outils de travail collaboratifs (wiki, cloud, gestion de planning)

- un service de gestion de licences

L'OSUG fournit un certain nombre de services à destination des laboratoires, des Services Nationaux d'Observation et des Infrastructures de Recherche (tableau 4):

- Virtualisation OSUG (VMware)

- Containers et orchestration de containers

- Sites web (kits SO-SPIP, labo et intranet)

- Monitoring Zabbix

- Système de gestion de base de données

- Cloud OSUG

- Gestion de Licences

- Authentification

- Wiki

- DOI

<figure><img src="image_42.png" /></figure>
* Publications : Application pour collecter les publications d'un labo ou d'une entité telle que le LabEx.

Depuis la mi-2021, un système mutualisé de sauvegarde des postes de travail est en cours de déploiement dans les unités UAR-OSUG, IPAG, ISTerre, LECA. L'IGE rejoindra le projet dans un deuxième temps.

Principaux services de site utilisés :

- DGDSI

• Messagerie Zimbra

* Stockage SUMMER

* Virtualisation WINTER

* Réseau Spring

* Only Office cloud

- GRICAD

• Hébergement de serveurs en Datacentre

* Calcul intensif sur CIMENT

* Dépôt logiciel GITLAB

* Service de Cloud OpenStack NOVA

La plupart des services de l'OSUG s'appuient sur les services de la DGDSI tels que l'hébergement le stockage et le réseau. La gestion documentaire type Atrium n'est mise en place qu'à l'IPAG.

<figure><img src="image_43.png" /></figure>
## 4. Jalons et évènements à venir

Dans l'établissement du Schéma Stratégique du Numérique de l'OSUG, il est important de d'anticiper et prendre ne compte les jalons et évènements à venir. Il est illusoire de tout prévoir, mais il est déjà possible d'anticiper les évolutions à venir...

### 4.1. Évolution de l'infrastructure de virtualisation

L'infrastructure de virtualisation, constituée dans un premier temps de 3 serveurs, a subi diverses évolutions : passage à 5 serveurs, doublement de la capacité mémoire, stockage distribué VSAN. Ces opérations étaient nécessaires pour répondre à une montée en charge progressive liée à la migration des serveurs physiques et virtuels des unités sur notre infrastructure commune. Notre infrastructure est aujourd'hui bien dimensionnée pour répondre aux besoins de notre fédération et ne devrait pas subir d'évolution matérielle majeure dans les 2 ans à venir.

Le coût matériel et logiciel de cette plateforme de virtualisation VMware est :

* Matériel : environ 75 k€ avec 7ans de maintenance

* Licences VMware: 32 k€ à l'achat + 13 k€ support annuel

* Coût annuel de l'espace SUMMER (datastores) : 3k€

* Sauvegarde (Bacula) : 12 k€ (achat licence permanente) + 1.8 k€/an (maintenance)

<table><thead><tr><td>Coût total annuel</td><td>Renouvellement annuel</td></tr></thead><tbody><tr><td>34.8 k€ et 1/3 ETP IR</td><td>3k€/an</td></tr><tr><td>Ingénieur de Recherche pour son administration</td><td>Espace de stockage sécurisé SUMMER NFS (mis à disposition sur la plateforme VMware) 30To</td></tr></tbody></table>

Notre infrastructure s'appuie sur 5 serveurs physiques dont les garanties arrivent à échéance au cours du prochain quinquennat (3 fins de garantie début 2022, 2 autres en octobre 2026). La question du prolongement de garantie des 3 premiers serveurs jusqu'à fin 2025 paraît un choix judicieux, le coût est raisonnable (3860 € pour les 3 serveurs) et il permet de rentabiliser l'investissement tant en terme financier que humain (mise en place de l'architecture, montée en compétence sur les outils VMware, mise en place d'outils de déploiement et de gestion de configuration).

En parallèle les technologies évoluent ; nous utilisons en particulier les containers pour l'hébergement de services à la demande, plus légers et plus souples à déployer que les machines virtuelles.

Nous étudions donc différents scénarios d'évolution pour notre infrastructure :

* **Scénario 1** : prolongation de la garantie des 3 premiers serveurs jusqu'à fin 2025, et renouvellement des 5 serveurs en conservant la solution VMware. Les coûts de prolongation de garantie puis de remplacement des serveurs sont à prévoir

* **Scénario 2** : prolongation de la garantie jusqu'à fin 2025. On migre une partie de nos serveurs sur la plateforme de la DGDSI avant la fin 2025, et l'ensemble des serveurs à horizon 2026. Les coûts de contrats Winter sont à prévoir (estimation à faire en se basant sur les caractéristiques des machines virtuelles de notre infrastructure)

* **Scénario 3** : Migration d'une partie de nos machines virtuelles sur la plateforme Winter d'ici 2026 (probablement les machines des unités) et mise en place d'une nouvelle solution innovante pour les besoins plus spécifiques (type SNOs).

Ces différents scénarios seront à étudier, d'une part en regard avec les facilités que Winter pourrait nous autoriser pour l'installation des machines virtuelles, et d'autre part en regard avec les nouvelles technologies (openstack et kubernetes, ou autre technologie qui pourrait voir le jour d'ici fin 2025).

<figure><img src="image_44.png" /></figure>
<table><caption>Tableau 5 : investissement CPER projet CINAURA</caption><thead><tr><th>Infrastructures réseaux<br>2,5 M€</th><th>Infrastructures<br>d'hébergement<br>20,75 M€</th><th>Plateformes numériques<br>mutualisées pour la<br>recherche<br>15 M€</th></tr></thead><tbody><tr><td><strong>Volet 1 :</strong><br>interconnection réseaux<br>Auverdata et Amplivia<br>1 M€</td><td><strong>Volet 1 :</strong><br>convergence<br>datacenters CINAuRA<br>15,75 M€</td><td><strong>Volet 1 :</strong><br>Infrastructures de calcul HPC,<br>HPDA, GPU, IA, cloud et edge<br>computing<br>adossées aux mésocentres<br>UC2A - UGA - UdL<br>11 M€</td></tr><tr><td>—</td><td>Salles<br>UCA, UC2A : 1 M€</td><td>—</td></tr><tr><td><strong>Volet 2 :</strong><br>Raccordement et<br>augmentation des débits<br>des sites ESR distants<br>1 M€</td><td>GR3@, UGA : 10 M€<br>CCDD, UdL : 3 M€<br>ENSL, UdL : 1 M€</td><td><strong>Volet 2 :</strong><br>Infrastructures de stockage<br>4 M€</td></tr><tr><td>—</td><td>ECL, UdL : 0,75 M€</td><td>—</td></tr><tr><td><strong>Volet 3 :</strong><br>Liaisons dédiées<br>datacenter CINAuRA<br>0,5 M€</td><td><strong>Volet 2 :</strong><br>Expérimentations<br>Green Computing<br>« Objectif PUE = 1 »<br>sites UC2A et UdL<br>5 M€</td><td><strong>Pilotage</strong><br>Comité scientifique<br>UC2A - UGA - UdL<br>pour la répartition des<br>ressources numériques</td></tr><tr><td colspan="3"><strong>Pilotage</strong><br>Comité de pilotage UC2A - UGA - UdL :<br>évolution, investissement, modèle économique<br>du réseau de datacenters CINAuRA</td></tr></tbody></table>

Nous avons engagé dès le mois de mai des discussions avec le CT Winter pour voir si notre mode de fonctionnement pourrait être compatible, moyennant quelques adaptations, avec leurs procédures automatisées.

## 4.2. Datacentre GR3A (CPER CINAURA)

En termes d'hébergement de serveurs l'OSUG s'appuie à ce jour sur deux datacentres mutualisés à l'échelle du site : IMAG et SIMSU; le 3ème DC mutualisé : Green-R est situé sur le polygone mais n'est pas utilisé par les unités de l'Observatoire.

Le DC SIMSU étant de conception vétuste et ayant une très mauvaise efficacité énergétique, il est prévu de le remplacer dans le cadre du projet CPER CINAURA par un nouveau DC nommé GR3A. L'objectif national étant de limiter très fortement le nombre de DC par région il est possible que l'ensemble des 3 datacentres SIMSU, IMAG et Green-R soit remplacés à terme par le futur DC GR3A.

GR3A a été labellisé comme DC Grenoblois, l'investissement prévu dans ce DC au titre du CPER est de 10M€ (voir Investissement CPER projet CINAURA du tableau 5).

Dans le cadre d'une coordination des trois sites ESR régionaux, le projet CINAuRA vise à permettre une convergence de l'ensemble des infrastructures de l'ESR régional sur un cluster de data centres « nouvelle génération » et éco-efficients. Le projet prévoit également l'acquisition d'infrastructures de calcul et de stockage à la hauteur de l'excellence scientifique des communautés de recherche régionale dont les besoins sont en très forte augmentation. Cette

<figure><img src="image_45.png" /></figure>
infrastructure va également permettre de répondre aux enjeux industriels en matière de transition numérique et d'innovation. Enfin, la mise en œuvre du projet CINAURA viendra également en soutien aux sites dans le cadre de la modernisation et de la sécurisation des systèmes d'information des établissements.

## Besoins de l'OSUG / CPER CINAURA

Les besoins de l'OSUG en termes d'hébergement qui pourraient être couverts par ce CPER ont évolué de façon importante ces dernières années.

* **Côté hébergement** : les besoins propres de la fédération OSUG ont fortement diminué par rapport aux évaluations d'il y a 5 ans du fait d'une part de la virtualisation et d'autre part de l'utilisation systématique des moyens mutualisés du site, aussi bien en calcul (GRICAD) qu'en stockage (SUMMER). Ainsi nos besoins d'hébergement sont reflétés par une partie des besoins d'hébergement de la DGDSI UGA pour le stockage SUMMER (l'OSUG représente 10% de la volumétrie SUMMER) et une partie des besoins d'hébergement de l'UAR GRICAD pour le calcul intensif (l'OSUG représente environ 60% du calcul intensif de GRICAD).

Les besoins propres d'hébergement résiduels de l'OSUG sont de 2 baies 1/2 pour héberger l'infrastructure de virtualisation de l'OSUG, l'infrastructure de stockage bas coût de l'OSUG, les fermes de calcul propres aux laboratoire ISTerre, IPAG et IGE.

Une incertitude subsiste sur les besoins d'hébergement du LEGI qui dispose encore aujourd'hui d'une salle informatique.

* **Coté plateforme numériques mutualisées pour la recherche** : l'OSUG est un gros utilisateur de ressources de calcul et de stockage avec des besoins en expansion qui pourraient être couverts par le CPER dans le cadre des projets de calcul et de stockage mutualisés à l'échelle du site.

* **Coté réseau informatique** : le projet CPER prévoit de faire évoluer le réseau informatique en région AuRA. Pour l'OSUG cette évolution permettrait de faire des sauvegardes délocalisées sur d'autres sites AuRA, mais ce cas d'utilisation ne peut justifier qu'une infime partie de l'investissement de 2.5M€ prévu dans le CPER.

## Aspects environnementaux

Du point de vue environnemental (voir chapitre 5), l'OSUG est par nature très sensible au caractère écoresponsable de ces investissements. Bien que le projet CPER CINAURA mette en avant des critères environnementaux, il nous parait indispensable que des indicateurs d'impact environnemental du projet soient mis en place et qu'une trajectoire soit définie pour que ce projet soit compatible - en termes de consommation énergétique des DC et d'impact environnemental des serveurs - avec les objectifs du plan climat.

### 4.3. Equipex Mesonet, GaiaData et Terra Forma

Dans le cadre du Programme d'investissements d'avenir, 50 projets d'équipements structurants pour la recherche ont été labellisés EquipEx+ en 2020. Un certain nombre concerne l'UGA et en particulier l'OSUG ainsi que ses partenaires régionaux: Mesonet, GaiaData et TerraForma.

* **Mesonet**

Le projet Mesonet est un projet Equipex national piloté par Genci. Il fait suite à l'Equipex equip@Meso qui a permis de mettre en place sur Grenoble la première plateforme HPC CIMENT mutualisée à l'échelle du site, la machine « Froggy ».

Le projet Mesonet vise d'une part à renforcer les infrastructures réseaux entre les mésocentres et d'autre part à mettre en place pour la communauté HPC, des plateformes nationales à destination de la formation et du développement : Le budget global est de :15M€, RHs : 8 CDDs.

L'objectif du projet Mesonet est de fournir un accès mutualisé aux compétences et équipements dans les domaines HPC/IA. Il s'agit donc d'un projet structurant pour les tiers2, visant à intégrer
un mésocentre par région dans un réseau d'expertise et de ressources pour le HPC, l'IA, le big data.

Il vise la mise en place d'une infrastructure convergée combinant serveur de calcul, stockage mutualisé, avec des connexions réseau adaptées, une offre logicielle appropriée et une offre de service associée. La plupart des mésocentres adressent déjà cette convergence des infrastructures en proposant des solutions de stockage partagé, de cloud, de nœud GPU pour l'IA et de calcul distribué ; ces éléments pourront servir de briques élémentaires pour le développement d'un réseau d'infrastructures convergées dédiés à l'HPC-IA. Il est proposé de renforcer les moyens régionaux en acquérant une machine partagée HPC/IA accessible à tous, dont l'activité sera distribuée sur plusieurs datacentres. Les mésocentres concernés mutualisent l'aide des ingénieurs systèmes des autres mésocentres qui participent à l'effort commun (assistance partagée et distribuée et maintenance par un pool d'ingénieurs systèmes de l'ensemble du réseau).

La machine partagée sera ouverte à l'accès des étudiants pour des modules de formation en lien avec le HPC et l'IA.

Le projet vise également à coordonner l'activité de prospective technologique sur le hardware, le logiciel et les applications entre Genci et les mésocentres en favorisant l'expérimentation technologique.

L'acquisition de prototypes sera encouragée, pour tester les nouvelles architectures de processeurs de différents niveaux de maturité : ARM, Vector ou Quantum. L'accès sera ouvert à tous les partenaires du réseau.

Le mésocentre Grenoblois aura la gestion d'une plateforme Openstack, avec un budget de 1.1 M€ pour son financement.

Une plateforme GPU et une plateforme CPU sont prévues sur 2 autres sites.

Une plateforme de stockage de 20Po IRODS sera également mise en place, distribuée dans les centres Tiiers 2 et Tiers 1 ainsi qu'un système de stockage BeeGFS adossé aux machines.

Ce projet va donc amener des moyens supplémentaires conséquents en terme de ressources de calcul HPC-IA et de stockage.

Le Mesocentre, reste adapté au développement, à l'expérimentation, à la formation, et donc à des calculs de taille intermédiaire. Il n'a pas vocation à se substituer aux centres nationaux. Il doit servir de tremplin vers les centres nationaux quand les simulations nécessitent un passage à l'échelle. Les ressources matérielles et logicielles qui seront mises en place dans le cadre de Mesonet devraient renforcer la coordination entre Tiers 2 et Tiers 1 et faciliter le passage entre les 2 niveaux.

## Gaia Data

Le projet GAIA Data du PIA3 a pour ambition de développer et de mettre en œuvre une infrastructure intégrée et distribuée de données et de services pour l'observation et la modélisation du système Terre et de l'Environnement.

GAIA Data est porté par trois Infrastructures de Recherche inscrites sur la feuille de route nationale des IR à vocation numérique : CLIMERI-France, PNDB, DATA TERRA, ainsi que par 21 partenaires. Il a pour ambition de développer et mettre en œuvre une plateforme intégrée et distribuée de services /données pour l'observation, la modélisation et la compréhension du système Terre, de la biodiversité et de l'Environnement. Destinés à la communauté scientifique ainsi qu'aux acteurs publics et socio-économiques, ces services seront accessibles via des portails permettant des recherches inter et transdisciplinaires. Ils reposent sur des données multi-sources acquises par satellites, navires, avions, drones, submersibles, ballons, dispositifs in situ, inventaires, observatoires et expérimentation, ainsi que sur des données issues de simulations de référence.

Ce dispositif (figure 14), basé sur des centres de données et services, interconnectés et pilotés par la science, permettra d'accéder aux différentes sources de données et de disposer d'un continuum de services distribués de stockage (adaptés aux gros volumes de données pour le

<figure><img src="image_46.png" /></figure>
# GAIA DATA Caractéristiques du projet

## Infrastructure distribuée de services

8 sites principaux
30 sites existants

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

<figure><img src="image_48.png" /><figcaption>Figure 14 : caractéristiques du projet Gaia Data dont l'un des nœuds est à Grenoble</figcaption></figure>

spatial et la modélisation notamment), de traitements (incluant l'utilisation des moyens de calculs et d'IA), de croisement de données, d'analyse et de visualisation.

GaiaData est donc l'équipement qui va permettre de construire Data Terra et ses pôles de données: ForM@Ter, Aéris, Theia, ODATIS mais aussi le service DINAMIS d'accès aux données spatiales et aux services. Il est prévu que le pôle national de données de biodiversité (PNDB) rejoigne ces pôles. A l'OSUG, concernant les données nous sommes particulièrement impliqués dans ForM@Ter avec Résif et les autres services Terre Solide et Theia via le système d'information Theia/OZCAR et bien sûr les autres services. Le directeur de ForM@Ter est E. Chaljub depuis le 1er septembre 2021.

Cette plateforme fournira de manière intégrée des services FAIR tout au long du cycle d'utilisation des données (depuis leur acquisition jusqu'à leur utilisation par une grande diversité d'applications scientifiques) pour : faciliter et accélérer leur accès, leur extraction et leur croisement, favoriser leur réutilisation « intelligente », faciliter leurs interactions, leur contrôle de l'intégrité, de la qualité, de la véracité, et de la provenance dans les différents contextes d'utilisation.

A Grenoble, l'OSUG est impliqué dans les groupes de travail suivants :

- WP3 Gaia Data « Développement des services transversaux » / Tache « Découverte et connaissance » : V. Chaffard (co-responsable)

- WP2 Gaia Data « architecture et Infrastructures des 8 sites ossature » : Franck Thollard et E. Chaljub (co-responsable) sur le projet ForM@Ter

- WP2 tache « authentification SSO » : fédérations RENATER, ORCID ou se créer un compte par les réseaux sociaux avec autorisation et facturation.

- WP3 tache « DMP » : F. Thollard (ForM@Ter) sur les DMP RDA

- GT science : S. Galle (Theai/in-situ) et H. Pedersen (RESIF-SI)

- GT Techniques :

- GT catalogue (V. Chaffard),

- GT architecture (E. Chaljub),

<figure><img src="image_49.png" /></figure>
* GT DMP et SSO (V. Chaffard, F. Thollard)

Pour Gaia Data, l'élargissement de Data Terra à plus de services aura un impact à Grenoble:

- GT « architecture »: avec OSUG-DC (R. Cailletaud, B. Boutherin) et GRICAD (Pierre-Antoine Bouttier)

- GT « SSO/authentification »: avec GRICAD (Pierre-Antoine Bouttier) Mesonet.

C'est donc un moyen de fédérer les efforts dans les données et services du système Terre mais aussi espérer récupérer quelques moyens humains.

## Autres Equipex

Le projet TERRA FORMA permet de fédérer les infrastructures de recherche du réseau eLTER et de mettre en place une nouvelle génération d'observatoire des socio-écosystèmes de « l'Anthropocène ». Le projet TERRA FORMA propose de développer et déployer des réseaux de capteurs intelligents, ce qui implique l'adaptation de nouvelles technologies pour l'environnement et la production massive de données hétérogènes. Ce réseau de capteurs intelligents questionne en particulier l'habitabilité de la Terre à l'heure de l'Anthropocène.

Le projet, porté par les infrastructures de recherche OZCAR (Observatoires de la Zone Critique : Application et Recherche) et RZA (Réseau des Zones Ateliers), repose grandement sur la co-construction avec les divers utilisateurs et les citoyens : aussi bien du point de vue de la conception, que de la réalisation, de l'utilisation, de la formation, de la communication etc..

Le projet repose entièrement sur le principe de la recherche/action et propose la construction d'une infrastructure sociale qui s'appuie sur les développements instrumentaux. Un des aspects importants de TERRA FORMA sera l'aspect numérique qui consistera à récupérer les données pour les insérer dans l'infrastructure de recherche numérique Data Terra.

Il en sera de même aussi probablement pour l'Équipex OBS4CLIM mais qui ne concernera pas des données gérées par OSUG-DC.

## 4.4. Les infrastructures nationales de calcul

En France, les ressources de calcul mises à disposition des chercheurs sont de différents types, allant de moyens locaux ou régionaux aux moyens européens, en passant par le national (figure 15).

<figure><img src="image_50.png" /></figure>
Au niveau régional, les moyens dits de Tier2, d'une puissance de l'ordre de 1 petaflop/s, sont généralement exploités dans les mésocentres comme GRICAD. Avec le projet Equip@meso, porté par GENCI, une dizaine d'entre eux, répartis sur le territoire, ont été renforcés.

Les centres nationaux, dits Tiers1, sont installés et exploités dans trois centres : le CINES, Centre Informatique National de l'Enseignement Supérieur à Montpellier, l'Institut du développement et des ressources en informatique scientifique du CNRS (IDRIS) à Orsay et le Très Grand Centre de Calcul du CEA (TGCC) à Bruyères-le-Châtel. Ces centres cumulent plus d'une quarantaine de pétaflops.

Enfin, au niveau européen, des moyens dits de Tier0 sont accessibles par le biais de l'infrastructure PRACE dont la France, représentée par GENCI, est un des membres fondateur.

Comme expliqué à la section 2.7, le mésocentre CIMENT de GRICAD regroupe des moyens matériels et humains à une échelle typiquement supérieure aux capacités d'un seul laboratoire et inférieure aux centres nationaux. Les mésocentres se situent au centre de la pyramide du calcul et offrent une souplesse d'accès qui permet d'accueillir des projets de calcul de taille intermédiaire et de servir de tremplin pour les utilisateurs ayant des besoins relevant des centres nationaux ou internationaux.

Certains projets de l'OSUG sont très gros consommateurs des moyens de calcul nationaux et européens mis à disposition par GENCI. Pour citer quelques projets :

- la modélisation des couches océaniques par l'équipe MEOM de l'IGE,

- la simulation du champ magnétique à la surface du noyau terrestre par N. Schaeffer,

- les modèles dynamiques de disques protoplanétaires de G. Lesur,

- la formation des grains interstellaires par l'équipe de C. Ceccarreli,

- l'imagerie sismique du sous-sol par inversion du champ d'ondes de l'équipe Seiscope.

- l'étude des processus d'accélération de particules dans les écoulements relativistes de B. Cerutti avec un soutien sur du calcul niveau Européen PRACE pour 27Mh.

De ce fait, ils suivent de très près les jalons donnés par la politique nationale et aussi participent à la définition de cette politique.

<figure><img src="image_51.png" /></figure>
# 5. Impact environnemental

Il est difficile d'établir un schéma stratégique du numérique sans se préoccuper de l'impact environnemental de nos activités. Ce chapitre présente les différents enjeux soulevés par le numérique à l'OSUG dans les prochaines années.

## 5.1. État des lieux

L'impact environnemental a toujours été bien pris en compte dans CIMENT, puis dans GRICAD. D'abord en privilégiant un hébergement mutualisé, dans la salle machine de la SIMSU, puis avec l'expérimentation de solution de refroidissement par ventilation (projet Gofree), puis avec la machine Froggy (solution de refroidissement par eau chaude, intégrée dans la machine, au plus proche du processeur et de la mémoire).

Cet enjeu a aussi été pris en compte en développant :

- le premier gestionnaire de jobs OAR qui intègre une gestion de l'énergie ;

- la grille locale CiGri pour utiliser le temps libre des serveurs de calcul avec les jobs de type multi-paramétrique, et optimiser ainsi l'usage des ressources.

Plusieurs ingénieurs de Ciment puis de GRICAD ont été ou sont des membres très actifs du GDS EcolInfo (groupement de services), qui a été créé et dirigé par Françoise Berthoud, membre de Ciment puis de GRICAD.

## 5.2. Les axes d'action

Nous avons identifié plusieurs axes pour agir et limiter l'empreinte écologique de l'utilisation du numérique :

- **Services** : la quasi totalité des services offerts par l'OSUG, les laboratoires, les SNO et IR sont virtualisés ce qui est le point le plus important du point de vue environnemental. Il subsiste dans certains laboratoires des plateformes de virtualisation historiques destinées à être arrêtées. Pour le choix d'évolution de la plateforme OSUG l'impact environnemental sera considéré mais l'enjeu est assez faible. En effet on parle ici de de 5 serveurs physiques et la différence d'impact entre les serveurs de la plateforme OSUG et celle de la plateforme WINTER n'est pas déterminante.

- **Stockage** : Les volumes de données traitées sont de plus en plus importants, notamment pour ce qui concerne les données de l'environnement. Nous sommes de plus en plus conscients de l'importance d'une gestion propre de la donnée, de l'importance du principe FAIR pour optimiser l'usage de la donnée, éviter sa duplication. Ces éléments sont pris en compte dans les projets qui se mettent en place. Mais il est également important de fournir pour nos chercheurs des infrastructures de stockage qui soient correctement gérées, de veiller au nettoyage de données obsolètes, de veiller à la suppression des données orphelines. Sur les infrastructures de calcul, nous mettons en place des outils de supervision permettant d'identifier les données froides,

- **Calcul** : Les membres de CIMENT qui ont rejoint le pôle calcul de GRICAD ont toujours été particulièrement concernés par les aspects d'eco-responsabilité : premiers à mettre des clusters de laboratoires dans des salles mutualisées, développement d'un gestionnaire de jobs qui a été le premier gestionnaire a prendre en compte la gestion de l'énergie, machine mutualisée Froggy avec un système de refroidissement de PUE proche de 1, choix de composants dans les serveurs optimisant la performance par rapport à la puissance consommée.

- **Postes de travail et imprimantes**

- Des efforts sont à faire sur les imprimantes personnelles : nos utilisateurs ont beaucoup diminué leur usage des imprimantes, il subsiste cependant au niveau de l'administration. Un travail de sensibilisation est à faire auprès des personnels mais la première action est sans doute de supprimer les imprimantes individuelles
dans les bureaux (ce qui diminuera par ailleurs la charge de travail des gestionnaire d'infrastructure).

- Avec le développement du télétravail, nous privilégions l'achat de portable au détriment des PC fixes. A niveau de gamme équivalente, les ordinateurs portables sont moins énergivores et les utilisateurs auront plus facilement tendance à les mettre en veille ou les éteindre.

* **Télétravail** : le télétravail a été largement mis en place dans nos laboratoires dès le premier confinement, la plupart de nos activités pouvant facilement s'effectuer à domicile. Il serait légitime de penser que l'impact en terme d'économie d'énergie est perceptible, puisque les personnels ont énormément diminué leurs déplacements, les routes ont été moins engorgées, que la plupart des gens ont limité leurs achats à des produits de première nécessité. Les études montrent cependant une nette augmentation de la consommation en électricité et en chauffage des domiciles et une augmentation des achats informatiques. Cet impact est à relativiser. Hors période de pandémie, les enfants étant scolarisés, le télétravail provoquerait probablement une moindre hausse de la consommation en électricité et en chauffage et resterait la diminution des trajets domicile travail qui peut être importante, la plupart des personnels habitent loin de leur travail, le coût du logement étant élevé à proximité de Grenoble.

* **Data centres** :

- L'impact environnemental est prise en compte dans projet CINAURA : Comme nous l'avons précisé dans la section 4.2 concernant le projet CINAURA, il nous parait indispensable que des indicateurs d'impact environnemental du projet soient mis en place et nous sommes en contact avec les acteurs du projet pour nous tenir informés de son l'évolution. Nous devons rester vigilant quand aux aspects d'eco-efficience et faire remonter nos éventuelles interrogations.

- Le nouveau datacentre régional ne sera probablement pas en exploitation avant 2024 ou 2025. Nos besoins au niveau des unités ne devraient guère évoluer d'ici là. Par contre de nouvelles ressources de calcul et de stockage des projets PIA3 et Mesonet seront certainement mises en exploitation d'ici là. Le projet de Datacentre dans la maison climat Planète (qui avait été prévu pour l'hébergement de moyens de calcul) a malheureusement dû être abandonné. Nous espérons qu'une extension des capacités du Datacentre IMAG, en attendant CINAURA. Les mesures effectuées dans ce Datacentre indique un PUE moyen de l'ordre de 1,3.

* **Grands projets** (GaiaData, MesoNet) :

- Le projet GaiaData adresse des problématiques environnementales telles que les risques naturels, le changement climatique, les questions liées aux ressources et à la biodiversité. Ces travaux sont nécessaires pour une meilleure compréhension de ces phénomènes naturels, mais les analyses, les traitements liés nécessitent l'exploration de larges domaines de paramètres, la combinaison de données issues de sources diverses, et donc la manipulation de gros volumes de données et des traitements lourds. Le paysage est actuellement fragmenté par domaine de recherche. L'objectif est de permettre l'accès à un continuum d'infrastructures existantes, distribuées, qui seront renforcées, rendues interopérables, et intégrant les ressources de stockage, de calcul et les services. Le projet devrait donc permettre de rationaliser l'infrastructure globale, d'optimiser l'usage des ressources et favoriser une gestion propre de la donnée. Les traitements au plus près des lieux d'observations seront privilégiés. Une architecture de type cloud, distribuée, sera mise en place, privilégiant l'usage des solutions virtualisées, des containers. Le projet GaiaData est associé au projet CPER CINAURA, l'infrastructure sera hébergée dans un datacentre éco-efficient sur le site de Grenoble.

- Le projet Mesonet intègre les aspects d'efficacité énergétique, via la coordination et la mise à jour des équipements et le contrôle des investissements. Il est primordial de tenir compte et limiter la puissance consommé par l'ensemble des

<figure><img src="image_52.png" /></figure>
investissements effectués pour les équipements destinés au HPC, au big data et à l'IA et ainsi réduire l'impact environnemental global. Les membres de GRICAD et les ingénieurs impliqués dans les services de GRICAD sont particulièrement sensibilisés à l'impact environnemental du numérique. Plusieurs ingénieurs, dont des membres de l'OSUG, participent au GDS Ecoinfo et ont effectué des études sur l'impact carbone des moyens de calcul et de stockage de GRICAD. Certaines critères d'éco-efficience sont pris en compte au niveau des choix de composants tels que fréquence d'horloge des processeurs, efficacité des alimentations et des systèmes de refroidissement. Les salles dans lesquelles seront hébergées les machines seront éco-efficientes, comme nous avons pu le voir dans la section 2.7.

### 5.3. Quelles politiques d'évolution des moyens de calcul ?

Une étude a été menée par des membres de EcolInfo pour évaluer l'impact carbone moyenne d'une heure.cœur sur GRICAD en incluant les impacts associés aux déplacements domicile-travail des personnels du service, les équipements utilisés par l'équipe (fabrication), et l'énergie utilisée par l'unité pour son fonctionnement.

L'étude<fnref n="2" /> indique qu'une heure.cœur sur GRICAD génère environ 4.68g CO2e. Les ressources de calcul de GRICAD totalisent 8000 cœurs pour le calcul. L'impact de la fabrication du matériel est presque aussi importante que celle de l'usage des serveurs de calcul, et ces 2 paramètres totalisent presque 3/4 de l'équivalent CO2.

L'étude montre que :

- le fait d'augmenter la durée de vie des équipements est au moins aussi important que l'indicateur PUE (*Power Usage Effectiveness*) des datacentres pour réduire l'impact du service calcul et c'est principalement lié à l'impact de la fabrication des équipements.

- la part d'électricité par heure.cœur (sur l'impact globale) diminue lorsque le taux d'occupation de la machine augmente (la consommation électrique ne varie pas beaucoup en fonction du taux de charge de la machine)

On identifie ainsi des leviers de réduction de l'impact carbone sur lesquels on est en capacité d'agir :

- la réduction du PUE des datacentres (vigilance par rapport au projet CINAURA)

- l'augmentation du taux d'utilisation (utile) des serveurs (viser un taux d'occupation de 100% des serveurs et un bon usage des machines)

- l'augmentation de la durée de vie des équipements (environnement adapté pour éviter de réduire la durée de vie du matériel et maintenance d'au moins 7 ans, voir prolongée à 10 ans)

- sensibiliser les utilisateurs qui ne prennent pas toujours en compte l'impact d'une mauvaise gestion de leur simulation ou d'un code qui n'optimise pas l'usage des ressources. La mise en place de nouvelles ressources est généralement liée à l'arrivée de nouveaux projets ou à une pression forte de la demande sur les calculateurs. Mais il est de plus en plus nécessaire de sensibiliser les utilisateurs pour qu'ils aient une utilisation optimisée et raisonnée des ressources plutôt que compulsive (l'optimisation des performances ne doit pas les amener à faire plus de calculs), pour qu'il utilisent au mieux les ressources qu'ils ont à leur disposition avant d'envisager une extension du parc machine.

Il faut garder en tête les objectifs de la COP 21 qui vise à réduire de 50% notre empreinte carbone d'ici 2030. Quasiment tous les laboratoires de l'OSUG ont calculé (ou sont en train de la faire) leur bilan carbone en prenant en compte l'impact du numérique. Un usage plus sobre de ces

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

<footnote n="2">² https://gricad.univ-grenoble-alpes.fr/documents/GES-h-coeur-GRICAD-2020.pdf</footnote>
outils n'est pas forcément antinomique avec le développement de la recherche et des observations.

L'OSUG pourrait participer aussi au suivi de la réduction des impacts liés au numérique dans les laboratoires. Nous avons l'ambition de réduire l'empreinte carbone de nos activités numériques, de façon concrète en s'appuyant sur les indicateurs existant ou à mettre en place. Cela nécessite par exemple de calculer l'empreinte carbone de la solution de virtualisation de l'OSUG et de la comparer à celle de WINTER.

<figure><img src="image_54.png" /></figure>
## 6. Prospective et stratégie

Ce chapitre est sans doute l'un des plus importants du Schéma Stratégique du Numérique, car il essaye de répondre aux questions qui ont été posées par les tutelles pour les cinq prochaines années. Il est sans doute illusoire de programmer année par année, voire mois après mois, l'évolution du numérique pour les membres de l'OSUG, d'autant que ces évolutions vont dépendre aussi de décisions individuelles, que ce soit les dates de départ à la retraite, les mobilités ou même le succès ou échecs de demandes de soutien à des programmes de recherche. L'objectif de ce chapitre est donc d'essayer de construire un cadre commun et partagé par l'ensemble des membres de l'OSUG et des tutelles.

Dans la réflexion qui s'est établie lors des 6 mois de construction du SSN, il est apparu important de mettre au clair un certain nombre de principes qui revenaient fréquemment parmi les intervenants qu'ils soient responsables de laboratoires ou de services, ou simple contributrice ou contributeur à des groupes de travail...

Ces principes qui ont été adoptés lors des discussions du comité des directions de l'OSUG sont les suivants :

- **Transparence** : les informations et les discussions sont partagées.

- **Équité** : les moyens RH ASR sont adaptés à la taille des unités et des équipes.

- **Subsidiarité** : recherche du niveau pertinent auquel une action doit être réalisée (équipes, laboratoires, fédération OSUG, site local ou échelon national/international).

- **Solidarité** : l'OSUG est une communauté d'intérêts qui crée des liens et des obligations

- **Préservation du fonctionnement des entités élémentaires** : besoin d'un responsable ASR ou responsable informatique par unité.

- **Mutualisation** : choisir des solutions informatiques qui peuvent être partagées par le plus grand nombre. Mise en commun de moyens matériels mais aussi humains.

- **Résilience** : permettre aux unités et services de faire face aux chocs, notamment le départ de personnel qui peut affecter lourdement un service.

- **Sobriété** : choisir des évolutions informatiques qui respectent la diminution de l'empreinte carbone et l'économie des ressources.

- **Gouvernance** : coordination, instruction des projets et arbitrage en fonction des moyens

Dans la suite de ce chapitre, nous allons répondre aux attendus demandés par les tutelles : moyens d'observation, plateformes mutualisées, calculs, support informatique et projection à cinq ans en précisant comment nous allons mettre en œuvre ce schéma. La lettre de mission des tutelles signée des 5 tutelles (CNRS, UGA, IRD, INRAE et Météo France) reçue début septembre 2021 aborde la question informatique :

> « Poursuivre le travail entamé via le Schéma Stratégique du Numérique (SSN), notamment sur l'assistance informatique aux laboratoires, avec un effort porté sur la gouvernance. La notion de service et de proximité revisitée doit être au cœur de la réflexion. Les tutelles seront vigilantes à la progression de cette organisation collective dans l'affectation des moyens. »

Notre analyse montre que le support informatique au sein des laboratoires est en forte tension (section 6.1) et que la poursuite des efforts de mutualisation nécessite un pilotage basé sur une gouvernance partagée (section 6.2). Nous abordons ensuite les pistes d'évolution envisagées pour le centre de données OSUG-DC pour faire vivre les missions nationales et internationales que ses équipes doivent mener (section 6.3), ensuite nous traitons rapidement le sujet du calcul (section 6.4) et les plateformes mutualisées (section 6.5) pour aboutir à la projection à 5 ans des moyens nécessaires (section 6.6).

<figure><img src="image_55.png" /></figure>
<table><caption>Tableau 6 : historique et prévision de la mutualisation au sein de l'OSUG</caption><thead><tr><th></th><th>2017</th><th>2019</th><th>2021</th><th>2023</th><th>2025</th><th>IP<br>AG</th><th>IST<br>err<br>e</th><th>IG<br>E</th><th>LE<br>CA</th><th>OS<br>UG</th></tr></thead><tbody><tr><td>Calculs intensifs</td><td colspan="3">CIMENT GRICAD et quelques clusters labo</td><td colspan="2">Idem + uniformisation des outils de dév.</td><td></td><td></td><td></td><td></td><td>P2</td></tr><tr><td>Logiciels et licences</td><td colspan="3">Matlab IGE-ISTerre, IPAG</td><td colspan="2">Jetons commun OSUG Matlab + IDL</td><td>Licenses du site UGA ?</td><td></td><td></td><td></td><td>-</td></tr><tr><td>Supervision système et applicative</td><td colspan="3">Unités (diverses solutions) et OSUG-DC (Zabbix)</td><td colspan="2">OSUG (Zabbix)</td><td></td><td></td><td></td><td></td><td>-</td></tr><tr><td>Web et Internet</td><td colspan="3">Kit Labo IGE + IPAG</td><td colspan="2">Kit-OSUG labos+projets+intranet hors LECA</td><td>+ LECA</td><td></td><td></td><td></td><td>P1</td></tr><tr><td>Sauvegarde des postes de travail</td><td colspan="3">Par laboratoire ou par personne</td><td colspan="2">Projet backupPC OSUG en cours de développement</td><td>A partir de 2021 déploiement progressif de la solution dans les laboratoires</td><td></td><td></td><td></td><td>P1</td></tr><tr><td>Plateforme de machines virtuelles</td><td colspan="3">Labos et OSUG</td><td colspan="2">OSUG ou UGA 100%</td><td></td><td></td><td></td><td></td><td>-</td></tr><tr><td>Stockage mutualisé (SUMMER) puis pratiques communes</td><td colspan="3">SUMMER ISTERRE-IPAG-UAR</td><td colspan="2">+IGE + LECA</td><td>Harmonisation des usages SUMMER</td><td></td><td></td><td></td><td>P2</td></tr><tr><td>Hébergement de serveurs en DC</td><td colspan="3">Labos</td><td colspan="2">IMAG et SIMSU 100%</td><td>IMAG et GR3A</td><td></td><td></td><td></td><td>-</td></tr><tr><td>Outils collaboratifs</td><td colspan="3">Doku wiki et cloud à l'OSUG</td><td colspan="2">Dokuwiki à l'OSUG Confluence à IPAG Cloud OSUG et UGA</td><td>Outil d'édition collaborative commun ? Cloud UGA</td><td></td><td></td><td></td><td>P3</td></tr><tr><td>Processus commun d'accueil nouvel arrivant</td><td colspan="3">Procédure par unité</td><td colspan="2">Harmonisation</td><td>Service OSUG ?</td><td></td><td></td><td></td><td>P2</td></tr><tr><td>Processus commun de déploiement OS</td><td colspan="3">Procédure par unité</td><td colspan="2">Harmonisation</td><td>Déploiement commun OSUG</td><td></td><td></td><td></td><td>P2</td></tr><tr><td>Installation homgène des postes de travail</td><td colspan="3">Procédure par unité</td><td colspan="2">Harmonisation</td><td>Service OSUG ?</td><td>P2</td><td></td><td></td><td>P2</td></tr><tr><td>Assistance utilisateurs mutualisée</td><td colspan="3">Unités (support indépendants)</td><td colspan="2">Harmonisation</td><td>Une seule instance OSUG sur GLPI UGA</td><td></td><td></td><td></td><td>P2</td></tr><tr><td>Référentiel utilisateurs OSUG</td><td colspan="3">IPAG, ISTERRE et IGE+LECA</td><td colspan="2">Travail commun SILOSE</td><td></td><td>P1</td><td>P1</td><td>P1</td><td>P1</td></tr><tr><td>Authentification et autres services basés sur référentiel</td><td colspan="3">AD IGE-LECA LDAP mutualisé (sauf IRSTEA)</td><td colspan="2">AD (IGE-LECA) et LDAP mutualisé basés sur BIPER (référentiel UGA hors INRAe) Mise en place de la Fédération d'Identité</td><td>AD et LDAP mutualisés Basés sur référentiel OSUG Nbx services basés Fédération d'Identité</td><td>P1</td><td></td><td></td><td>P1</td></tr><tr><td>Archivage des données</td><td colspan="3">Archivage sur LTO dans certains laboratoires</td><td colspan="2">Plus de bande magnétique dans les labo</td><td>?? Solution mutualisée de site??</td><td></td><td></td><td></td><td>P2</td></tr></tbody></table>

## 6.1. Support informatique aux laboratoires

Conformément à la lettre de mission des tutelles, les unités de l'OSUG sont invitées à poursuivre la mutualisation des services ASR dont le support aux utilisateurs via les discussions au ComEx ASR (voir sections 2.4 et 6.2) notamment sur les sujets suivants : référentiel, achats, installation et configuration des postes de travail (déploiement de l'OS), gestion de tickets, stockage donnée/clouds, ...

Les nombreuses discussions lors des réunions du ComEX ASR et du ComDir de l'OSUG ont abouti aux constats suivants :

<figure><img src="image_56.png" /></figure>
- La mutualisation des outils et des pratiques au sein de l'OSUG est déjà avancée. Le tableau 6 résume l'état d'avancement de ces mutualisations. Le code couleur est le suivant : les cases rouges correspondent aux activités peu mutualisées et encore gérées par les laboratoires ou équipes, les cases oranges correspondent aux activités où une mutualisation est commencée, les cases jaunes correspondent aux activités où la mutualisation est partielle et les cases vertes correspondent aux activités mutualisées au sein de l'OSUG et/ou du site.

- Avant de mutualiser le personnel, il faut harmoniser les pratiques et les outils, sinon la mutualisation risque d'être complètement contre-productive.

- Les responsables ASR (à travers le ComEx ASR) doivent être les pilotes de cette harmonisation, c'est-à-dire qu'ils doivent mener ce chantier en tenant compte des forces disponibles dans leur unité.

- La coordination concrète entre les ASR (rôle du ComEx ASR) est privilégiée plutôt qu'un regroupement administratif des ASR.

- L'objectif à terme est de pouvoir mutualiser les ingénieurs de l'OSUG au bénéfice des laboratoires et permettre l'entraide entre les laboratoires.

- En attendant que l'harmonisation des pratiques et des outils soit suffisamment aboutie, il faut maintenir le support aux postes de travail dans les labos en proximité. Pour faire face au travail supplémentaire d'harmonisation, une aide complémentaire transitoire sera requise.

- Il est indispensable d'anticiper les départs (mobilité et retraite) et procéder à leur remplacement.

- Le périmètre du service évoluera d'un périmètre volontairement limité au départ à quelques unités (les 4 laboratoires CNRS INSU-INEE) pour s'ouvrir à d'autres unités quand le besoin se fera sentir (Lautaret par exemple).

Nous avons appris très récemment (printemps 2021) le départ des deux assistants ingénieurs mutualisés dédiés au support utilisateur ainsi que le CCD de l'équipe ASR (figure 6) avec :

- la mobilité de l'AI CNRS basé à l'OSUG (H. Bouchafa) et déployé sur ISTerre et l'IPAG ;

- le recrutement à l'INRAE-ETNA de l'AI CDD mutualisé à l'OSUG (F. Barbault), déployé sur le LECA et l'IGE, et financé par OSUG-IGE-LECA-ISTerre-IPAG + INEE sur la fin ;

- le départ de l'IR ASR à l'IGE en soutien pour la migration du système IntraGère vers un système mutualisable (B. Le Rubrus).

Ces départs affaiblissent le support aux utilisateurs des 4 laboratoires CNRS INSU-INEE et **il est absolument indispensable de les remplacer**. Il est possible de le faire en intégrant ces postes au sein de l'équipe du système d'information de l'OSUG en créant une équipe spécifique de support aux utilisateurs des laboratoires de l'OSUG plus particulièrement chargés des thématiques en cours d'harmonisation.

## Organigramme et prospective à 5 ans, travail en cours de maturation

L'OSUG indépendamment du SSN réfléchit à l'évolution de son organisation. La figure 16 décrit une possible organisation visée dans les 5 ans qui viennent. Comme on peut le constater, le groupe Système d'Information est amené à s'agrandir et à se structurer avec l'apparition d'une équipe ASR mutualisé comprenant deux groupes, l'un pour le support aux utilisateurs et l'autre pour le soutien aux projets, une équipe OSUG-DC avec 4 pôles thématiques, une entité Calcul intensif et une équipe en appui aux unités et aux actions collectives.

Pour passer de la situation actuelle où des personnels étaient mis à disposition des laboratoires par l'UAR à celle visée par l'organigramme de la, il faut constituer une équipe à l'OSUG qui ait une taille critique de 3 ETP sur 3 à 4 personnes. Il faudra donc adapter les demandes DIALOG et DAM en fonction de ces nouveaux éléments. Il ne faudrait pas que les départs fragilisent aussi les priorisations qui avaient été décidées précédemment.

<figure><img src="image_57.png" /></figure>
<figure><img src="image_58.png" /><figcaption>Figure 16 : possible évolution de l'organigramme de l'OSUG à 5 ans.</figcaption></figure>

Le tableau 7 expose les organisations (a) actuelle, (b) transitoire et (c) cible proposées. Le passage de (a) à (c) en passant par (b) permet de préserver le soutien aux unités et de préparer une transition réussie vers une mutualisation plus large. Ce chemin fait l'hypothèse que les laboratoires contribuent pour l'équivalent d'une journée par semaine aux chantiers d'harmonisation et que nous obtenons le soutien de nos tutelles, et du CNRS en particulier, pour le recrutement à l'OSUG :

- d'un Ingénieur d'Études CNRS/INEE qui prendrait la responsabilité de l'informatique du LECA

- d'un Assistant Ingénieur CNRS/INSU en remplacement du départ de H. Bouchafa (Noemi de compensation 2021 infructueuse)

- un soutien pour des CDD dans un premier temps pour faire face à la fois aux travaux de proximité (comme le changement de système d'information à l'IGE et le soutien aux utilisateurs dans toutes les unités) mais aussi le travail en lien avec l'harmonisation des outils et des pratiques.

Ces recrutements permettraient de constituer une équipe de 3 ETP à l'OSUG en charge de la mise en place de pratiques homogènes dans les laboratoires de la fédération en particulier pour les installations et configurations de postes de travail. Cela constitue la première brique nécessaire pour mettre en place un support mutualisé à l'échelle de l'OSUG.

<figure><img src="image_59.png" /></figure>
<caption>Tableau 7 : organisations (a) actuelle, (b) transitoire et (c) cible proposées des équipes ASR de l'UAR et des laboratoires. Code couleur : en rouge les départs prévus en 2021, en orange les absences longue durée, en vert les profils à recruter, en magenta les CDD et en bleu les contributions des unités à l'harmonisation.</caption>

a) ORGANISATION ACTUELLE

<table><thead><tr><th colspan="3">UAR OSUG</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR mutualisé</strong><br>Rémi CAILLETAUD (IR-CNRS)</td></tr><tr><td>Rémi CAILLETAUD (IR-CNRS)</td><td>1</td><td rowspan="3">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Éric DREVET (AI-CNRS)</td><td>1</td></tr><tr><td>Michel GRAVIER (CDD IE-UGA Labex)</td><td>1</td></tr><tr><td><strong>Total</strong></td><td>3</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">IGE</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Patrice NAVARRO (IR-CNRS)</td></tr><tr><td>Patrice NAVARRO (IR-CNRS)</td><td>1</td><td rowspan="4">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Benoit LE RUBUS (CDD IE-CNRS)</td><td>1</td></tr><tr><td>Richard MOUREY (AI-CNRS)</td><td>1</td></tr><tr><td>Wajdi NECHBA (AI-CNRS)</td><td>1</td></tr><tr><td>Florent BARBAULT - 11/2021 (CDD AI-CNRS)</td><td>0.5</td><td></td></tr><tr><td><strong>Total</strong></td><td>3</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">IPAG</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Laurence GLUCK (IR-CNRS)</td></tr><tr><td>Ghislain ESCORNE (IE-CNRS)</td><td>1</td><td rowspan="3">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>David GILLIER (TC-CNRS)</td><td>1</td></tr><tr><td>Frédéric Roussel (IR-CNRS)</td><td>0.2</td></tr><tr><td>Haïd BOUGHAFA - 11/2021 (AI-CNRS)</td><td>0.5</td><td></td></tr><tr><td><strong>Total</strong></td><td>2.2</td><td></td></tr></tbody></table></table>

<table><thead><tr><th colspan="3">ISTERRE</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Jean-Noel BOUVIER (IE-UGA)</td></tr><tr><td>Jean-Noel BOUVIER (IE-UGA)</td><td>1</td><td rowspan="4">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Elodie TOSSATO (TC-CNRS)</td><td>1</td></tr><tr><td>Philippe GENIN (AI-CNRS)</td><td>1</td></tr><tr><td>Haïd BOUGHAFA - 11/2021 (AI-CNRS)</td><td>0.5</td></tr><tr><td><strong>Olivier ROMEYER</strong> (TC-USMB)</td><td>1</td><td></td></tr><tr><td><strong>Total</strong></td><td>4</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">LECA</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>[Responsabilité vacante]</td></tr><tr><td>Ghislain ESCORNE - 11/2021 (AI-CNRS/INEE)</td><td>1</td><td rowspan="3">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Florent BARBAULT - 11/2021 (CDD AI-CNRS)</td><td>0.5</td></tr><tr><td><strong>Total</strong></td><td>0</td></tr></tbody></table></table>

b) ORGANISATION TRANSITOIRE PROPOSÉE

<table><thead><tr><th colspan="3">UAR OSUG</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR mutualisé</strong><br>Rémi CAILLETAUD (IR-CNRS)</td></tr><tr><td>Rémi CAILLETAUD (IR-CNRS)</td><td>1</td><td rowspan="3">Total ETP : 18</td></tr><tr><td>Éric DREVET (AI-CNRS)</td><td>1</td></tr><tr><td>Michel GRAVIER (CDD IE-UGA Labex)</td><td>0.5</td></tr><tr><td>IE à recruter (resp. info LECA)</td><td>0.5</td><td></td></tr><tr><td colspan="3"><strong>Equipe en support aux laboratoires<br>(harmonisation des pratiques)</strong></td></tr><tr><td>Michel GRAVIER (CDD IE-UGA Labex)</td><td>0.5</td><td></td></tr><tr><td>Benjamin Cauchard (CDD IE-UGA)</td><td>0.8</td><td></td></tr><tr><td>IE à recruter (resp. info LECA)</td><td>0.5</td><td></td></tr><tr><td>Al à recruter (rempl. H BOUCHAFA) (CNRS/INSU)</td><td>IGE</td><td></td></tr><tr><td>Al à recruter (rempl. F BARBAULT) (CDD CNRS/INSU)</td><td>Labos</td><td></td></tr><tr><td><strong>Contribution harmonisation (1j/sem)</strong></td><td>0.7</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">IGE</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Patrice NAVARRO (IR-CNRS)</td></tr><tr><td>Patrice NAVARRO (IR-CNRS)</td><td>1</td><td rowspan="4">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Richard MOUREY (AI-CNRS)</td><td>1</td></tr><tr><td>Wajdi NECHBA (AI-CNRS)</td><td>1</td></tr><tr><td>IE à recruter (CDD CNRS)</td><td>1</td></tr><tr><td>Al à recruter (CNRS/INSU)</td><td>0.5</td><td></td></tr><tr><td><strong>Contribution harmonisation (1j/sem)</strong></td><td>-0.2</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">IPAG</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Laurence GLUCK (IR-CNRS)</td></tr><tr><td>Ghislain ESCORNE (IE-CNRS)</td><td>1</td><td rowspan="3">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>David GILLIER (TC-CNRS)</td><td>1</td></tr><tr><td>Frédéric Roussel (IR-CNRS)</td><td>0.2</td></tr><tr><td>Al à recruter (CDD)</td><td>0.5</td><td></td></tr><tr><td><strong>Contribution harmonisation (1j/sem)</strong></td><td>-0.2</td><td></td></tr></tbody></table></table>

<table><thead><tr><th colspan="3">ISTERRE</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Jean-Noel BOUVIER (IE-UGA)</td></tr><tr><td>Jean-Noel BOUVIER (IE-UGA)</td><td>1</td><td rowspan="4">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Elodie TOSSATO (TC-CNRS)</td><td>1</td></tr><tr><td>Philippe GENIN (AI-CNRS)</td><td>1</td></tr><tr><td>Al à recruter (CDD)</td><td>0.5</td></tr><tr><td><strong>Olivier ROMEYER</strong> (TC-USMB)</td><td>1</td><td></td></tr><tr><td><strong>Contribution harmonisation (1j/sem)</strong></td><td>-0.2</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">LECA</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>[IE à recruter à l'OSUG (resp. info LECA)]</td></tr><tr><td>Olivier LONTIN (AI-CNRS/INEE)</td><td>1</td><td rowspan="2">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Al à recruter (CNRS/INSU)</td><td>0.5</td></tr><tr><td><strong>Contribution harmonisation</strong></td><td>-0.1</td><td></td></tr></tbody></table></table>

c) ORGANISATION CIBLE

<table><thead><tr><th colspan="3">UAR OSUG</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR mutualisé</strong><br>Rémi CAILLETAUD (IR-CNRS)</td></tr><tr><td>Rémi CAILLETAUD (IR-CNRS)</td><td>1</td><td rowspan="3">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Rempl. Eric DREVET (AI-CNRS)</td><td>1</td></tr><tr><td>Michel GRAVIER (IE-UGA Labex)</td><td>0.5</td></tr><tr><td>IE à recruter (resp. info LECA)</td><td>0.5</td><td></td></tr><tr><td colspan="3"><strong>Equipe en support aux laboratoires<br>(harmonisation des pratiques)</strong></td></tr><tr><td>Michel GRAVIER (IE-UGA Labex)</td><td>0.5</td><td></td></tr><tr><td>IE à recruter (resp. info LECA)</td><td>0.5</td><td></td></tr><tr><td>Al à recruter (rempl. H BOUCHAFA) (CNRS/INSU)</td><td>1</td><td></td></tr><tr><td>Al à recruter (rempl. F BARBAULT) (CDD)</td><td>1</td><td></td></tr><tr><td><strong>Total</strong></td><td>6</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">IGE</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Patrice NAVARRO (IR-CNRS)</td></tr><tr><td>Patrice NAVARRO (IR-CNRS)</td><td>1</td><td rowspan="4">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Rempl. Richard MOUREY (AI-CNRS)</td><td>1</td></tr><tr><td>Wajdi NECHBA (AI-CNRS)</td><td>1</td></tr><tr><td><strong>Total</strong></td><td>3</td></tr></tbody></table><table><thead><tr><th colspan="3">IPAG</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Laurence GLUCK (IR-CNRS)</td></tr><tr><td>Ghislain ESCORNE (IE-CNRS)</td><td>1</td><td rowspan="3">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>David GILLIER (TC-CNRS)</td><td>1</td></tr><tr><td>Frédéric Roussel (IR-CNRS)</td><td>0.2</td></tr><tr><td><strong>Total</strong></td><td>2.2</td><td></td></tr></tbody></table></table>

<table><thead><tr><th colspan="3">ISTERRE</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>Jean-Noel BOUVIER (IE-UGA)</td></tr><tr><td>Jean-Noel BOUVIER (IE-UGA)</td><td>1</td><td rowspan="4">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Elodie TOSSATO (TC-CNRS)</td><td>1</td></tr><tr><td>Philippe GENIN (AI-CNRS)</td><td>1</td></tr><tr><td>Al à recruter (CDD)</td><td>1</td></tr><tr><td><strong>Olivier ROMEYER</strong> (TC-USMB)</td><td>1</td><td></td></tr><tr><td><strong>Total</strong></td><td>4</td><td></td></tr></tbody></table><table><thead><tr><th colspan="3">LECA</th></tr></thead><tbody><tr><td colspan="3"><strong>ASR</strong><br>[IE à recruter à l'OSUG (resp. info LECA)]</td></tr><tr><td>Olivier LONTIN (AI-CNRS/INEE)</td><td>1</td><td rowspan="2">Total ETP 2021: 16.2<br>Total ETP 2022: 12.2</td></tr><tr><td>Al à recruter (CNRS/INSU)</td><td>0.5</td></tr><tr><td><strong>Total</strong></td><td>1</td><td></td></tr></tbody></table></table>

<figure><img src="image_60.png" /></figure>
## 6.2. Gouvernance de l'informatique ASR et du support informatique

Pour continuer et mener à bien le chantier de mutualisation du support informatique au niveau de la fédération OSUG, il faut que la gouvernance s'appuie sur l'organisation décrite à la section 2.4 avec :

* le COMEX-ASR qui regroupe les responsables informatiques des unités et les responsables du SI et ASR de l'UAR-OSUG.

* le COMEX-ASR élargi identique au COMEX-ASR avec en plus les directeurs des unités.

Une liste de chantiers a été définie par ce COMEX dans le cadre du présent SSN (voir le tableau 6 à la section 6.1). Le fonctionnement et les missions du COMEX-ASR ont été affinés pour piloter ces chantiers.

**COMEX-ASR :**

- Les membres du COMEX ASR réservent un créneau commun (actuellement le jeudi de 14h à 15h30) pour les réunions du COMEX. La fréquence minimale de réunion sera d'une réunion par mois. Un relevé de décision est disponible pour chaque réunion sur le wiki de l'OSUG.

- Le COMEX-ASR complète la liste des chantiers si nécessaire

- Il définit les chantiers prioritaires et l'objectif de calendrier de ces chantiers

- Il établit la liste des participants de chaque laboratoire(*) et de l'équipe harmonisation de l'UAR qui participeront aux chantiers.

- Il suit l'avancement des projets en cours en invitant les chefs de projets.

- Il nomme un chef de projet pour chacun des projets de mutualisation

**Fonctionnement des chantiers d'harmonisation des pratiques du support informatique :**

- Le chef de projet réunit à l'UAR OSUG son groupe de travail dans le respect des participations des laboratoires et anime ce groupe pour

- Faire le point sur les solutions qui existent dans les laboratoires de l'OSUG et en dehors

- Faire la liste des besoins des unités et établir un cahier des charges

- Proposer et mettre en œuvre une solution technique adaptée aux besoins

- Documenter la solution et former les gestionnaires d'infrastructure des laboratoires au déploiement de la solution.

- Le chef de projet est invité régulièrement par le COMEX pour discuter l'avancement du projet et les éventuelles difficultés.

- Le chef de projet s'assure que l'avancement du projet est documenté et que la documentation est accessible par les directions des laboratoires

(*) les laboratoires réservent 0,2 ETP ASR pour participer aux chantiers de mutualisation avec l'équipe d'harmonisation de l'UAR-OSUG. Cette contribution est répartie sur les membres du service ASR, à l'exception du travail au sein du ComEx ASR du responsable de service, et elle est adaptée en fonction de la personne et du temps consacré pour les projets.

## 6.3. Centre de données et gouvernance du centre de données

En ce qui concerne le centre de données OSUG-DC, un certain nombre d'évolutions sont proposées :

- la mise en place d'un comité de coordination scientifique qui regroupe tous les responsables scientifiques des SNO gérés par OSUG-DC qui se réunit plusieurs fois par an (a minima 2 fois par an) pour échanger sur les évolutions de leur SNO et arbitrer aussi les besoins en moyens humains et financier. Au besoin, les responsables techniques seraient invités. L'idée est d'augmenter le partage d'information entre les thématiques. Au-delà des SNO et des pôles de données de l'IR Data Terra déjà impliqués (JMMC-MOIO, SSHADE, SPHERE-DC, Résif-DC, Theia), il est proposé d'inviter les responsables de SNO en cours de labellisation et qui ont vocation à intégrer OSUG-DC (ISDeform et EMAA) ainsi que les locaux de ForM@Ter et Theia/OZCAR

- renforcer certains services ou organisations de travail :

<figure><img src="image_61.png" /></figure>
* formaliser l'accueil complet de Theia/OZCAR à la suite de l'embauche d'un IE-IRD et discuter des conditions d'un transfert possible de la responsable technique au sein d'OSUG-DC avec la personne concernée, sa responsable scientifique et leur direction à l'IGE

* inclure ISDeform à la suite de l'embauche d'un IE-INSU et discussion en relation avec l'équipe GeoData

* accompagner la structuration Data Terra à l'OSUG, à terme celle du PNDB

- organiser le centre de données en 3 pôles thématiques AA, TI et SCOA car la structure commence à être importante et pour favoriser la résilience au sein des SNO. C'est le sens aussi que l'INSU met dans les Centres d'Expertise Régionaux (CER) notamment en AA. L'idée n'est pas de rajouter une couche mais d'améliorer la lisibilité de la structure OSUG-DC.

- développer les services communs : DOI, monitoring, plateforme de virtualisation, prototypes, publications,... Suivre et participer à l'avancement des projets d'entrepôts de site (en particulier projet Dataverse à l'UGA en lien avec la cellule Data Grenoble Alpes) et nationaux pour être prêts à intégrer ces services si leur périmètre est adapté aux besoins de notre communauté.

- soutien à de nouveaux projets ou des SNO en émergence : base de données et site web<fnref n="3" /> en « opendata » pour la collections de roches minéraux et fossiles de l'OSUG, preuve de concept pour le projet EMAA pour la mise à disposition ouverte des données de collision et de spectroscopie des molécules, etc...

Un point de vigilance concerne le départ à la retraite du responsable d'OSUG-DC qu'il faudra anticiper.

Dans les discussions, il est apparu que le nom OSUG-DC qui fait référence à la terminologie anglaise Data Center ne correspond pas aux activités développées par OSUG-DC. En effet un Data Center est un lieu qui héberge des serveurs ce qui n'est plus le cas à l'OSUG puisque l'on s'appuie sur les services de site. Le futur nom pour ce groupe qui rassemble les 3 pôles thématiques sera réfléchi.

Depuis le conseil de l'OSUG de septembre 2021, la coordination scientifique s'est réunie une première fois. Un poste NOEMI a été attribué pour OSUG-DC en soutien ISDeform et EPOS-GNSS, mais il semble qu'aucune candidature n'ait été reçue.

## 6.4. Calcul intensif

Depuis la création du projet CIMENT, un travail important a été réalisé pour mutualiser les moyens de calcul à l'échelle du site. Ce travail a abouti à la création de l'UAR GRICAD.

Environ 2/3 des utilisateurs des ressources de GRICAD sont des membres de l'OSUG et l'OSUG contribue financièrement à l'achat de ressources de calcul et de stockage via des projets ERC ou ANR de ses unités ou via les ressources propres de l'UAR ou sur le LabEx. Il est donc essentiel que les besoins des utilisateurs de la fédération OSUG soient correctement pris en compte.

En accord avec les responsables de GRICAD, nous avons prévu d'organiser des réunions régulières entre les responsables de GRICAD et les responsables informatiques de l'UAR OSUG pour renforcer la coordination entre les 2 UAR.

Suite au lancement des appels d'offre du LabEx OSUG et notamment de l'appel à projets stratégiques, des réunions ont été initiées par la direction adjointe de l'OSUG en charge de la donnée, pour essayer de faire émerger un gros projet structurant. Ce projet pourrait prendre la forme d'un investissement dans des noeuds GPU de type AMD, du recrutement d'ingénieur calcul pour former les équipes au développement de codes sur GPU et de la mise en place de gestionnaire de workflow pour le traitement de données massif en ligne.

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

<footnote n="3">³ https://web.collections.osug.fr</footnote>
## 6.5. Plateformes mutualisées

Les plateformes analytiques au sein de l'OSUG sont bien intégrées au sein de RéGEF. Ce réseau a vocation à se transformer potentiellement en Infrastructure de Recherche Nationale. Évidemment, l'OSUG propose de soutenir les équipes engagées dans ce processus pour les accompagner dans cette mutualisation nationale selon le principe de subsidiarité.

## 6.6. Projection à 5 ans des moyens

Dans la projection à 5 ans des moyens, nous n'avons pas voulu figer les lignes, mais plutôt donner un cadre qui évoluera en fonction des évolutions des projets. Cela concerne à la fois les moyens humains et les moyens financiers pour le fonctionnement et l'investissement.

La philosophie adoptée est de mutualiser quand cela a du sens et au niveau le plus pertinent. Comme décrit dans les sections précédentes, la mutualisation est très avancée dans le calcul, dans le centre de données, et en émergence dans les plateformes analytiques. L'effort principal sera de soutenir l'activité ASR des laboratoires et notamment le soutien aux utilisateurs de la façon la plus harmonisée possible afin de permettre une mutualisation facteur de résilience.

Il sera nécessaire aussi d'envisager la suite des infrastructures qu'elles soient à l'OSUG ou au niveau du site. Néanmoins un budget de fonctionnement récurrent est nécessaire pour maintenir l'offre informatique aux laboratoires, aux SNO et aux utilisateurs.

### 6.6.1. Moyens humains

Le tableau 8 résume les mouvements de personnel et le besoin de création de postes dans le cadre du SSN d'ici 2025. Ce tableau est amené à être amendé en fonction de l'évolution de la situation, ce qui est le cas déjà depuis le dernier conseil de l'OSUG en septembre 2021.

Si tous les départ sont remplacés, alors les postes indiqués en rouge correspondent aux créations nettes demandées aux tutelles (3 postes au CNRS -2 INSU et 1 INEE- et 1 à l'IRD).

Une piste à explorer pour favoriser les recrutements serait aussi de privilégier une élaboration de profil par expertise technique plutôt que par projet, ce qui n'est pas simple dans le contexte où il est demandé de justifier des ouvertures de postes par projet.

### 6.6.2. Moyens financiers pour le fonctionnement et l'investissement

Pour que l'informatique fonctionne correctement, il faut prévoir un budget récurrent de fonctionnement et anticiper les évolutions et les investissements.

<table><caption>Tableau 8 : besoins humains estimés jusqu'en 2025</caption><thead><tr><th>Besoin</th><th>Tutelle</th><th>Service</th><th>2021</th><th>2022</th><th>2023</th><th>2024</th><th>2025</th></tr></thead><tbody><tr><td>SSHADE</td><td>INSU</td><td>OSUG-DC / CER A&A</td><td>-1</td><td></td><td>1</td><td></td><td></td></tr><tr><td>Al mutualisé IPAG/ISTerre/OSUG</td><td>INSU</td><td>ASR support utilisateur</td><td>-1</td><td></td><td>1</td><td>-1</td><td>1</td></tr><tr><td>Al mutualisé IGE / LECA / OSUG</td><td>INSU</td><td>ASR support utilisateur</td><td></td><td>1</td><td></td><td></td><td></td></tr><tr><td>ISDeform InSAR/GNSS</td><td>INSU</td><td>OSUG-DC / DT Form@ter</td><td></td><td>1</td><td></td><td></td><td></td></tr><tr><td>IE ASR infrastructure</td><td>INSU</td><td>ASR infrastructure</td><td></td><td>1</td><td>-1</td><td>1</td><td></td></tr><tr><td>IE IGE (migration Sys. Information)</td><td>CNRS</td><td>ASE infrastructure</td><td>-1</td><td></td><td>1</td><td>-1</td><td></td></tr><tr><td>Al IGE (départ à la retraite)</td><td>INSU</td><td>ASR support utilisateur</td><td></td><td></td><td>-1</td><td>1</td><td></td></tr><tr><td>Web service (départ à la retraite)</td><td>INSU</td><td>ASR infrastructure</td><td></td><td></td><td>-1</td><td>1</td><td></td></tr><tr><td>Direction OSUG-DC</td><td>INSU</td><td>OSUG-DC</td><td></td><td></td><td></td><td>-1</td><td>1</td></tr><tr><td>Resp. SI LECA + container</td><td>INEE</td><td>ASR OSUG</td><td></td><td></td><td>1</td><td></td><td></td></tr><tr><td>Al mutualisé IGE / LECA / OSUG</td><td>INEE</td><td>ASR support utilisateur</td><td>-1</td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td>Mouvement CDD</td><td>-3</td><td>1</td><td>1</td><td>-2</td><td></td></tr><tr><td></td><td>CNRS</td><td>Mouvement postes permanents</td><td>-1</td><td>2</td><td>-1</td><td>2</td><td>2</td></tr><tr><td></td><td></td><td>Solde cumulé</td><td>-4</td><td>-1</td><td>-1</td><td>-1</td><td>1</td></tr><tr><td>IE développement référentiel SILOSE</td><td>UGA</td><td>ASR infrastructure</td><td>1</td><td>-1</td><td></td><td></td><td></td></tr><tr><td>SI Theia / OZCAR (Gaia Data)</td><td>IRD</td><td>OSUG-DC / DT Theia</td><td>-1</td><td>1</td><td></td><td></td><td></td></tr></tbody></table>

<figure><img src="image_63.png" /></figure>
## Budget récurrent de fonctionnement

Le coût annuel récurrent de l'informatique de l'OSUG est détaillé dans le tableau 8.

Une partie incompressible du budget informatique de l'UAR OSUG concerne :

- l'achat de licences mutualisées entre les laboratoires de l'OSUG,

- le support de licences logicielles VMware pour la plateforme de virtualisation mutualisée de l'OSUG,

- le renouvellement de contrat de maintenance de licences logicielles (Bacula, Adobe, Matlab, IDL, Arcgis),

- une prestation de service DGDSI UGA et CNRS : contrat d'hébergement des machines virtuelles à la DGDSI, solution WINTER (hébergeant les services LDAP + rsnapshot + osug-log + osug-test-infra), renouvellement du contrat SUMMER.

- l'achat de matériel pour l'UAR : portables, écrans, matériel de visioconférence ...

## Renouvellement des infrastructures

En 2022 et 2023 nous devons prévoir un contrat de maintenance pour 2 serveurs de la plateforme de virtualisation qui arrivent en fin de garantie. Nous devons décider d'ici 2023 si nous basculons sur la plateforme WINTER de l'UGA ou si nous poursuivons avec notre propre plateforme de virtualisation. Dans le premier cas il faut financer le coût annuel de location des VM à l'UGA, dans le dernier cas, nous devrons prévoir le budget pour le renouvellement des 5 ESX.

Au delà des projets il faut continuer à financer le stockage et les services.

## Contribution à l'achat de ressources GRICAD pour les utilisateurs de l'OSUG

Parmi les labos qui contribuent (hors UAR GRICAD) à l'achat de ressources de calcul ou de stockage, la fédération OSUG est le principal contributeur. Les unités de l'OSUG contribuent (approximativement) à hauteur du niveau d'utilisation des ressources par leurs utilisateurs, via les projets ERC, ANR, Equipex ou encore les budgets de l'UAR OSUG (budgets propres ou LabEx).

## Budget formation alternance

Nous rencontrons depuis quelques années des difficultés à recruter des ingénieurs en informatique. L'alternance nous semble une bonne approche pour accueillir des jeunes étudiants et les aider à poursuivre leur formation tout en acquérant une expérience au sein d'une équipe informatique dynamique, offrant des services s'appuyant sur les dernières technologies tant au niveau des services systèmes et réseaux que du développement et maintien opérationnel de service.

<figure><img src="image_64.png" /></figure>
# 7. Annexes

## 7.1. Note de cadrage du CNRS-INSU sur l'élaboration du SSN (octobre 2019)

### Schéma stratégique du numérique des OSU

Afin de clarifier le rôle des différents acteurs dans l'écosystème local et donc le niveau et le lieu d'affectation des moyens, il convient de définir un schéma stratégique du numérique (SSN) à l'échelle de chaque OSU.

De par leur statut, les OSU ont pour mission d'organiser au sein de leur site universitaire, de manière transverse aux unités qu'ils fédèrent et en lien et en complément des organisations nationales et internationales existantes, la collecte, l'archivage et la mise à disposition de différents types de données :

- Les données issues des services nationaux d'observation (SNO) ou d'autres systèmes d'observations dont ils ont la responsabilité sur le plan local ou régional. Si l'OSU a la responsabilité d'un Centre National de Données, cette responsabilité s'étend à la gestion des données produites par les autres OSU et unités qui alimentent ce service.

- Les données des plateformes administrées par l'OSU au service des unités affiliées ou d'autres unités si la plateforme a un rôle national.

- Progressivement, les données de la recherche produites par les unités qu'ils fédèrent.

Les OSU étant des lieux privilégiés de dialogue avec l'université et le CNRS pour tout ce qui concerne le support informatique/calcul/données apporté aux laboratoires, ils ont pour rôle également d'optimiser l'organisation des personnels et des moyens matériels dédiés à ces activités.

Dans ce contexte, et afin de clarifier le rôle des différents acteurs dans l'écosystème local et donc le niveau et le lieu d'affectation des moyens, il convient de définir un schéma stratégique du numérique (SSN) à l'échelle de chaque OSU.

Un tel schéma devra comporter à minima les éléments suivants :

- Gestion des données d'observation de l'OSU (SNO en interaction avec les infrastructures nationales, européennes et internationales et systèmes d'observations locaux ou régionaux)

- Gestion des données des plateformes mutualisées.

- Gestion des moyens de calculs

- Support informatique aux unités de l'OSU

- Une évaluation des moyens consacrés aux divers éléments du SSN et une projection priorisée à 5 ans des moyens qui seraient nécessaires

Le SSN devra prendre en compte l'environnement offert à l'échelle locale par les autres partenaires et notamment les universités via leurs services dédié à l'informatique, au calcul (mésocentres) et aux données de façon générale. Concernant le support informatique, il conviendra de décrire précisément les options de mutualisation de l'administration du système réseau en lien avec les solutions proposées le cas échéant par l'université, tout en gardant à l'esprit la préservation du lien de proximité et de qualité de service entre les administrateurs du système réseau et les équipes des différentes unités.

Le SSN pourra inclure également une liste des services supplémentaires proposés par l'OSU (gestion de licences communes, gestion des courriels...).

<figure><img src="image_65.png" /></figure>
Enfin, le SSN doit permettre de définir la répartition des missions, donc des moyens, qui rendra
le meilleur service aux unités affiliées à l'OSU.

La définition du schéma stratégique du numérique fera l'objet de discussions au sein des différentes instances de l'OSU (comité de direction, commission d'observation,....) et devra in fine être adopté par le Conseil d'OSU après discussions avec l'ensemble des parties prenantes et notamment des tutelles de l'OSU.

La mise en œuvre des réflexions nécessaires à la construction de ces SSN devra débuter dès le dernier trimestre 2019 pour aboutir à une première priorisation des moyens lors de la demande de moyens de l'automne 2020.

<figure><img src="image_66.png" /></figure>
## 7.2. Listes des rencontres avec les différentes structures et les partenaires de l'OSUG

<table><thead><tr><td>Structures rencontrées</td><td>Nature</td><td>Dates</td></tr></thead><tbody><tr><td>CEN (CNRM)</td><td>Équipe</td><td>1er mars 14h</td></tr><tr><td>EDYTEM</td><td>Laboratoire</td><td>3 mars 9h</td></tr><tr><td>LEGI</td><td>Laboratoire</td><td>5 mars 9h</td></tr><tr><td>Utilisateurs du calcul intensif</td><td>Calcul</td><td>9 mars 14h</td></tr><tr><td>LECA</td><td>Laboratoire</td><td>10 mars 9h</td></tr><tr><td>Lautaret</td><td>Unité</td><td>15 mars 14h</td></tr><tr><td>IGE</td><td>Laboratoire</td><td>16 mars 14h</td></tr><tr><td>IPAG</td><td>Laboratoire</td><td>18 mars 9h</td></tr><tr><td>ISTerre</td><td>Laboratoire</td><td>18 mars 14h</td></tr><tr><td>SNO IPAG JMMC SSHADE SPHERE-DC EMAA</td><td>SNO</td><td>19 mars 9h</td></tr><tr><td>SNO ISTerre ISDeform + GéoData</td><td>SNO</td><td>25 mars 9h</td></tr><tr><td>SNO IGE + SI Theia/OZCAR,</td><td>SNO</td><td>25 mars 14h</td></tr><tr><td>UAR OSUG et LabEx OSUG</td><td>Unité</td><td>30 mars 11h</td></tr><tr><td>SNO ISTerre Résif</td><td>SNO</td><td>31 mars 9h</td></tr><tr><td>Equipex+ GaiaData</td><td>SNO</td><td>1er avril 14h</td></tr><tr><td>FAME</td><td>Équipe</td><td>2 avril 9h</td></tr><tr><td>INRAE (LESSEM et ETNA)</td><td>Laboratoire</td><td>2 avril 13h30</td></tr><tr><td>DGDSI</td><td>Service de site</td><td>15 avril 9h</td></tr><tr><td>SigmaPhy (GipsLab)</td><td>Équipe</td><td>15 avril 11h</td></tr><tr><td>GRICAD</td><td>Service de site</td><td>16 avril 10h</td></tr><tr><td>Environnement (PACTE)</td><td>Équipe</td><td>29 avril 9h15</td></tr><tr><td>SNO EPOS ISTerre</td><td>SNO</td><td>30 avril 9h</td></tr><tr><td>DGDSI</td><td>Service de site</td><td>4 juin 9h</td></tr><tr><td>RéGEF</td><td>Plateformes</td><td>22 juin 14h30</td></tr></tbody></table>

<table><thead><tr><td>Réunions thématiques</td><td>Dates</td></tr></thead><tbody><tr><td>OSUG-DC</td><td>4 mars, 1er avril, 6 mai, 3 juin, 9 juillet, 2 septembre</td></tr><tr><td>Comité coordination scientifique OSUG-DC</td><td>30 juin</td></tr><tr><td>ComEx ASR</td><td>27 mai, 17 et 24 juin, 1er, 8 juillet, 2 et 9 septembre</td></tr><tr><td>Référentiel</td><td>29 avril, 27 mai, 17 et 24 juin, 1er, 8 juillet et 9 septembre</td></tr><tr><td>ComEx ASR élargi</td><td>10 juin (directions) et 9 septembre (ASR)</td></tr></tbody></table>

<figure><img src="image_67.png" /></figure>
## 7.3. Compte-rendus des discussions avec les laboratoires et équipes

Cette annexe détaille les informations échangées lors des rencontres avec les unités.

### 7.3.1. Institut des Géosciences de l'Environnement (IGE)

Créé le 1er janvier 2017, l'unité mixte de recherche IGE (CNRS-INSU, IRD, UGA, Grenoble INP) a rassemblé les laboratoires LTHE et LGGE, mariant glaciologie, hydrologie, océanographie, sciences atmosphériques et environnementales, sciences inter et transdisciplinaires menées avec les SHS et/ou les acteurs socio-économiques. Le projet de l'IGE est centré sur l'étude du climat et l'anthropisation de notre planète, en particulier dans les régions où les enjeux sociétaux et environnementaux sont les plus prégnants : les régions polaires, la zone intertropicale, et les régions de montagne.

L'effectif moyen du laboratoire est d'environ 280 personnes, dont 155 membres permanents (chercheurs·es, enseignant·es-chercheurs·es, ingénieur·es, technicien·nes et personnels administratifs) et environ 120 doctorant·es, post-doctorant·es et personnels en contrat à durée déterminée. Le laboratoire accueille aussi chaque année une centaine de stagiaires et visiteurs scientifiques. Le laboratoire est installé sur deux sites du Campus universitaire de Grenoble, le bâtiment Glaciologie et OSUG-B/bâtiment Maison Climat Planète.

Le laboratoire a subi le départ de son responsable informatique, qui faisait aussi office de responsable informatique pour le LECA. Parti en 2018 ce dernier n'a pu être remplacé qu'en novembre 2020..

Le SI comprend 2 ETP pour l'architecture et systèmes (2 IR dont 1 CDD), 2,5 ETP pour le support et l'exploitation (tous AI dont 0.5 CDD) et 1 ETP base de données sur l'IR Theia/OZCAR (IR). Cette équipe est constituée de 4 permanents et de 2 CDD à stabiliser. L'un de ces CDD est à mi-temps entre le LECA et l'IGE et est financé par une contribution mutualisée des 4 laboratoires CNRS-INSU/INEE et l'OSUG sur moyens propres. Ce CDD a réussi au printemps 2021 un concours de recrutement à l'INRAE et donc va quitter ses fonctions à l'automne. Le deuxième CDD est financé sur fonds propres mais lui aussi est parti en 2021 sur un poste correspondant plus à ses compétences. Dans les personnel BAP E, il y a deux permanents dédiés au calcul intensif dont l'un passe 20% de son temps sur GRICAD. Un des AI support partira à la retraite d'ici fin 2022 comme d'ailleurs l'ingénieur calcul en charge du code communautaire NEMO pour lequel un concours externe est actuellement ouvert. Le besoin urgent est donc de remplacer le CDD ASR et de recruter un AI à mi-temps pour le support tout en prévoyant le remplacement des départs à la retraite. Un certain nombre d'ingénieurs BAP E permanents sont affectés à 100% dans des équipes de recherche.

Il faut noter que l'unité ETNA de l'INRAE devrait rejoindre l'IGE en 2023 avec leur assistant ingénieur informatique.

En ce qui concerne les besoins en infrastructure, un gros travail a été amorcé pour sortir d'une solution maison de gestion du système d'information IntraGere. De premières actions ont été prises pour la gestion de la messagerie qui est maintenant celle fournie par le site UGA (Zimbra) et pour les listes de diffusion (SYMPA). Une des questions urgentes est d'avoir un outil de gestion RH couplé avec un système d'authentification normalisé dans le cadre du projet référentiel de l'OSUG.

L'autre chantier urgent et initié concerne la sécurisation des données du laboratoire en particulier le remplacement des serveurs sortis de garantie. Une solution s'appuyant sur le stockage mutualisé SUMMER est en cours de mise en place; 300 To de stockage extensif ont déjà été loués par l'IGE.

L'IGE participe à hauteur de 0,2 ETP au projet SPRING (gestion du réseau SDN) mutualisé avec l'UGA et un ingénieur participe également à hauteur de 0,2 ETP à l'infrastructure de calcul GRICAD.

Retour Chapitre 3.1 Laboratoires et équipes

### 7.3.2. Institut des Sciences de la Terre (ISTerre)

<figure><img src="image_68.png" /></figure>
ISTerre est une unité mixte de recherche (UGA / CNRS-INSU / USMB / IRD / Univ. Gustave Eiffel) de près de 300 personnes. Organisée en 9 équipes de recherche, l'objectif scientifique d'ISTerre est l'étude physique et chimique de la planète Terre, tout particulièrement en se concentrant sur les couplages entre les observations des objets naturels, l'expérimentation et la modélisation des processus complexes associés. ISTerre assure également les missions d'observations de la Terre solide, hébergé et maintient des parcs nationaux d'instruments géophysiques, ainsi qu'un centre de données. La plus grosse partie du laboratoire est hébergée sur le campus de l'UGA, mais une petite partie est située à Chambéry à l'USMB.

Au niveau informatique, 4 ETP sont en charge de l'infrastructure (1 IE et 1AI) et du support aux utilisateurs (2 TCN dont 1 à Chambéry) avec l'aide d'un AI à mi-temps recruté à l'OSUG et partagé avec l'IPAG. Cet AI vient d'obtenir une mobilité et donc cet apport de l'OSUG va disparaître à l'automne 2021 si personne n'est recruté. Parmi les autres permanents, ISTerre accueille un IR qui est le responsable du service GéoData et une IR calcul. Une petite dizaine de CDD IR travaillent sur des projets de recherche avec leur propre financement (ERC, ANR,...). Le groupe Résif est hébergé à ISTerre mais dépend d'OSUG-DC à l'OSUG. En ce moment un poste CDD ASR sur Résif est vacant avec une grosse difficulté de recrutement. La plupart des permanents sont sous tutelle CNRS-INSU sauf le responsable informatique qui dépend de l'UGA et les techniciens à Chambéry qui dépendent de l'USMB. Aucun BAP E ne dépend de l'IRD ou de l'UGE.

ISTerre participe par ailleurs aux projets mutualisés de l'OSUG et de l'UGA : 0,2 ETP sont affectés sur des projets mutualisés de stockage SUMMER (DGDSI), 0,1 ETP sur la gestion de tickets GLPI (DGDSI), et 0,2 à 0,3 ETP sur l'infrastructure de calcul CIMENT (GRICAD).

Le calcul est une activité importante à ISTerre (voir la consommation CPU sur GRICAD dans le chapitre précédent). L'Institut conserve cependant son propre cluster de calcul avec 10 serveurs. Celui-ci est très utilisé pour le laboratoire et les projets de recherche et est prioritaire. Les serveurs de ce cluster ont été migrés vers le SIMSU. Les 3 raisons pour justifier ce cluster sont que les logiciels utilisés sont très spécifiques, que toutes les données ISTerre ne sont pas accessibles sur CIMENT, et la volonté des équipes de financer et d'avoir les machines à proximité pour un usage réservé. L'utilisation de l'intelligence artificielle explose à ISTerre et le besoin d'un serveur GPU se fait sentir. Une chargée de recherche à IRD qui est spécialiste de machine learning a été recrutée. Cette technique est pas mal utilisée en géologie pour la détection de signaux ainsi qu'en imagerie et données satellites. Des équipes sont en lien avec le GIPSA-Lab, expert du domaine.

Retour Chapitre 3.1 Laboratoires et équipes

### 7.3.3. Institut de Planétologie & d'Astrophysique de Grenoble (IPAG)

L'IPAG est une unité mixte de recherche (UGA / CNRS-INSU) dont les recherches portent sur la formation stellaire et planétaire, sur les phénomènes d'accrétion-éjection autour des objets stellaires jeunes et des objets compacts (trous noirs, étoiles à neutrons), sur les interactions Soleil-Terre, les sub-surfaces planétaires, les petits corps du système solaire, et l'évolution chimique de la matière primitive. Les activités de l'IPAG vont de la mesure en laboratoire au calcul haute performance en passant par l'observation astronomique, la conception et la construction d'une instrumentation de pointe au sol et dans l'espace, par exemple pour le futur télescope géant européen ELT. Environ 170 personnes travaillent à l'IPAG, dont 60 chercheurs et enseignants-chercheurs, 30 ingénieurs, techniciens et administratifs, et 70 personnes sous contrat dont 20 postdocs et 30 doctorants ou apprentis.

Au niveau informatique, l'IPAG est doté de 3 permanents dédiés à l'infrastructure et au support, mais le responsable est devenu en septembre 2020 directeur technique du labo et donc ne peut plus exercer que 20% de son temps. Les deux autres personnes sont IE et TCN et donc une nouvelle responsable issue du développement logiciel instrumental a pris la responsabilité du groupe informatique. En complément, l'OSUG met à disposition la moitié d'un ETP mutualisé pour le support utilisateur (l'autre moitié du temps de cette personne étant affecté à ISTerre). Cet AI vient d'obtenir une mobilité et donc cet apport de l'OSUG va disparaître à l'automne 2021 si personne n'est recruté. Outre la responsable informatique, trois autres ingénieurs interviennent sur le développement instrumental en appui sur du logiciel commande. Des CDD viennent

<figure><img src="image_69.png" /></figure>
compléter le personnel en BAP E dont un en calcul et les autres en développement. Plusieurs services d'observation sont de la responsabilité de l'IPAG avec 3 ingénieurs (2IR et 1 IE) qui ont été transférés sous la responsabilité de l'OSUG en 2017-2018. Ces personnes apportaient des aides ponctuelles au groupe informatique. Les informaticiens participent activement aux comités techniques du site sur SUMMER.

Pour ce qui concerne les infrastructures, l'IPAG est un acteur fort de la mutualisation au sein de l'OSUG que ce soit pour le stockage (SUMMER), la messagerie (Zimbra) l'authentification (LDAP).

L'IPAG participe aux projets de la DGDSI à hauteur de 0,2 ETP pour SUMMER et à hauteur de 0,1 ETP pour SPRING.

Les serveurs sont au nombre d'une trentaine et sont quasiment tous hébergés sur la plateforme de virtualisation de l'OSUG et administrés par l'IPAG. L'IPAG utilise sa propre solution de travail collaboratif sur Confluence qui donne toute satisfaction. Comme tous les logiciels payants, Confluence est limité en nombre de licence (actuellement 500) Ce service collaboratif héberge également d'autres entités (par exemple l'intranet du LabEx FOCUS). Un des besoins forts est la mise en place d'un référentiel laboratoire pour la gestion RH ainsi que des comptes informatiques et des listes de diffusion. Le besoin de soutien au calcul dans les équipes de recherche se fait sentir. Un seul ingénieur calcul est présent au sein du laboratoire. Un renforcement avec la responsable calcul de l'OSUG serait le bienvenu.

Retour Chapitre 3.1 Laboratoires et équipes

### 7.3.4. Laboratoire d'Écologie Alpine (LECA)

Le LECA est une Unité Mixte de Recherche (CNRS-INEE / UGA / USMB) dont l'objectif des recherches est de comprendre le fonctionnement des écosystèmes et le maintien de la biodiversité. Les équipes du LECA qui comptent environ 80 membres dont 50 permanents développent une recherche intégrée pour décrire les patrons (spatiaux, temporels) de biodiversité de l'échelle locale à l'échelle globale, comprendre les processus (évolutifs, écologiques) à leur origine et les mécanismes sous-jacents à leur dynamique sous l'influence de forçages environnementaux (changement climatiques, pollution, changement d'utilisation des terres...). Ces équipes se basent sur l'observation (à court et long terme), l'expérimentation et la modélisation. Les travaux permettent de développer des modèles prédisant la réponse de la biodiversité aux changements et résoudre des questions sociétales en lien avec l'évaluation des services rendus par les écosystèmes, la gestion de l'environnement, la conservation de la biodiversité. Une partie importante des activités est centrée sur les écosystèmes d'altitude.

Une particularité du LECA est d'avoir une équipe informatique réduite et d'avoir eu jusqu'en 2018 comme responsable informatique celui de l'IGE. Cela a perturbé le laboratoire quand celui-ci a quitté l'IGE. Le choix a été fait de ne plus dépendre directement de l'IGE surtout que son nouveau responsable a beaucoup de travail pour remettre à flot l'informatique de l'IGE. Par conséquent depuis 2018, l'informatique du laboratoire repose uniquement sur un permanent AI qui est depuis la mi-2021 en arrêt maladie prolongé et sur l'apport d'un mi-temps d'un CDD AI financé solidairement par les quatre laboratoires CNRS-INSU/INEE et l'OSUG qui vient de réussir un concours de recrutement à l'INRAE. Par conséquent le besoin du LECA est d'avoir un ingénieur IE qui prenne la responsabilité informatique du labo au moins une partie de son temps et qui pourrait contribuer aux projets mutualisés de l'OSUG dont le LECA a besoin (notamment pour le support de l'utilisation des containers). En plus de l'AI en charge de l'informatique et du mi-temps AI de l'OSUG, le LECA a aussi une IE dédiée à l'analyse de données et à l'utilisation de GRICAD. Le LECA se trouvant sans ASR, l'UAR OSUG a mis en place une Task Force pour faire face aux demandes des membres du laboratoire.

En terme d'infrastructure, la situation est très similaire à celle de l'IGE mais sans l'appui d'un responsable informatique: authentification, référentiel, stockage, etc... Le LECA pourrait bénéficier pleinement de la mutualisation des efforts ASR et support utilisateurs qui pourraient être mis en place par l'OSUG.

Retour Chapitre 3.1 Laboratoires et équipes
### 7.3.5. Laboratoire des Écoulements Géophysiques et Industriels (LEGI)

Le LEGI unité mixte de recherche (CNRS-INSIS, UGA) mène des activités d'une grande diversité avec un socle commun de compétences : la recherche en mécanique des fluides et des transferts. Le LEGI développe ainsi des axes de recherches fondamentaux pour répondre aux grands défis scientifiques auxquels la mécanique des fluides est encore aujourd'hui confrontée grâce à de nombreuses méthodes scientifiques avancées. Les expertises développées au LEGI permettent de contribuer aux développements d'applications variées au cœur des grands enjeux sociétaux actuels. La laboratoire héberge une centaine de membres dont une soixantaine de permanents.

Le service informatique assure de nombreuses fonctions vitales pour le laboratoire en termes d'organisation avec 2 personnes (1 IR et 0.8 AI), de calcul et stockage numérique (2 IR), aussi bien au niveau de la modélisation que du traitement de données expérimentales. Le service s'implique par ailleurs dans la politique informatique du site grenoblois, et organise l'accès aux moyens de calcul nationaux et Européens.

Le LEGI participe ainsi à hauteur de 0,4 ETP aux projets CIMENT, NOVA et Gitlab de GRICAD.

Au niveau infrastructure, le LEGI opère une soixantaine de VM et de petits clusters internes avec des codes très lourd en terme mémoire en complément des moyens du site et nationaux. Une des problématiques est de définir une stratégie de sauvegarde des données entre données brutes et réduites. La seconde problématique est l'hébergement des machines et des postes de travail sur le réseau Grenoble INP qui rend difficile l'utilisation du stockage SUMMER et les machines GRICAD en lien avec le stockage local. Le LEGI est favorable à une demande de bascule sur le réseau UGA. Le LEGI est favorable à la mise d'un référentiel commun pour la fédération OSUG et souhaite utiliser plus les outils OSUG (DOI, base de données,...). Le LEGI manque d'outils pour faire des carnets de laboratoires électroniques et est très impliqué sur l'utilisation des apprentissages IA profond.

Retour Chapitre 3.1 Laboratoires et équipes

### 7.3.6. Environnements, Dynamiques et Territoires de Montagne (EDYTEM)

EDYTEM est une unité mixte de recherche (USMB / CNRS-INEE) basée à Chambéry. Elle est née de la volonté de rassembler des chercheurs en géosciences (géologie, hydrogéologie, géomorphologie) et en sciences humaines et sociales (géographie) dans le but de résoudre, par une vision interdisciplinaire, les problématiques environnementales et sociétales propres aux Environnements, Dynamiques et Territoires de Montagne (EDYTEM). Depuis 2020, une équipe de chimiste de l'université Savoie Mont Blanc a rejoint le laboratoire pour compléter les travaux en intégrant plus fortement la chimie environnementale ainsi que la chimie verte et de synthèse. La laboratoire accueille environ 120 personnes dont une grosse soixantaine de permanents.

Au niveau informatique, EDYTEM a une situation particulière car cette unité n'a pas d'ASR, seulement un IR BAP-E CNRS-INEE. L'ancien AI BAP E est parti au LIG et le laboratoire a embauché pendant deux années un CDD qui n'a pas fait l'affaire. Par conséquent le laboratoire fonctionne avec une commission informatique et le service de la DSI de l'USMB avec essentiellement des postes de travail sous Windows mais aussi Macintosh et Linux. Un ASR dans le labo serait trop isolé, et il semble préférable de continuer à travailler avec la DSI de l'USMB, mais les services communs de l'OSUG intéressent EDYTEM (DOI, base de données,...) avec le besoin d'une expertise SQL ou noSQL sur leur base de données.

La sauvegarde des postes de travail se fait sur un NAS en local, environ 30To, mais le laboratoire aurait besoin d'une sauvegarde déportée et est demandeur d'une solution. Le système de base de données interne pour les missions BDDEDYTEM permet de tenir des cahiers de laboratoire des missions. Pour les projets, des liens existent avec l'OSUG, notamment sur le Permafrost. A l'USMB le calcul se fait sur MUST, qui fournit des espaces de stockage. En ce qui concerne le site web, EDYTEM utilise le kit CNRS mais devrait basculer sur le kit-labo de l'Observatoire à terme. Pour le moment, il n'y a pas d'intranet et les membres du laboratoire utilisent les services du CNRS qui ne sont pas satisfaisants. Les discussions montrent qu'EDYTEM est sur le Réseau RENATER et est intéressé par la virtualisation. L'utilisation de Metashape sur GRICAD dépend du transfert et du rapatriement des données. Il n'y a pas de référentiel d'identification UGA

<figure><img src="image_70.png" /></figure>
(Agalan), mais des discussions sont en cours sur un accord cadre entre USMB et UGA. Les utilisateurs utilisent essentiellement des licences Matlab via USMB, Argis (site UGA/USMB), labView [OSUG: licences mutualisée Matlab, IDL,..].

Retour Chapitre 3.1 Laboratoires et équipes

### 7.3.7. Laboratoire Écosystèmes et Sociétés En Montagne (LESSEM) et l'unité Érosion Torrentielle, Neige et Avalanches (ETNA) de l'INRAE,

Le LESSEM est une unité propre de recherche du Centre Lyon-Grenoble de l'INRAE qui développe des recherches sur les dynamiques des socio-écosystèmes en montagne en visant l'équilibre entre approfondissement disciplinaire (écologie; modélisation spatiale; sciences humaines et sociales) et développement de recherches interdisciplinaires, entre apports thématiques et perspectives méthodologiques. Issu de deux unités axées l'une sur l'écologie et l'autre sur les sciences humaines et sociales, le LESSEM mène des recherches aux interfaces des sociétés et des écosystèmes, analyse les différentes composantes des socio-écosystèmes avec des approches disciplinaires diversifiées et complémentaires, contribue à répondre à un ensemble d'enjeux environnementaux, et couvre l'ensemble du continuum entre production académique et appui à la décision. Ses recherches portent en particulier sur les territoires de montagne, des espaces naturels peu anthropisés aux grandes villes en passant par les espaces péri-urbains. Pour répondre à ces défis scientifiques et méthodologiques, le LESSEM s'organise autour de trois équipes de recherche fortement liées entre elles regroupant 70 personnes environ dont une petite cinquantaine de permanents. Le LESSEM participe et contribue fortement à l'animation de la Zone Atelier Alpes (ZAA).

L'unité propre de recherche ETNA du centre Lyon-Grenoble de l'INRAE conduit des recherches relatives à la prévention des risques naturels en montagne (avalanches, transport de neige par le vent, crues et laves torrentielles, chutes de blocs, risques d'origine glaciaire). Ses travaux concernent la formation et le déclenchement des processus, la dynamique des flux et des formes, les interactions avec les enjeux, l'évaluation du risque et l'aide à la décision dans un contexte de changements environnementaux rapides et marqués. L'activité de modélisation physique et numérique y est soutenue, accompagnant des expérimentations de laboratoire et de terrain. Les autres domaines d'activité concernent l'étude des techniques de protection, la cartographie et le développement de systèmes d'information pour la gestion des risques naturels. L'ETNA gère deux bases de données relatives aux avalanches : l'EPA (Enquête Permanente sur les Avalanches) et la CLPA (Carte de Localisation des Phénomènes d'Avalanche) et conduit également des expertises en France et à l'étranger, participe à l'élaboration de guides techniques et mène des actions de formation et de vulgarisation. Cette unité accueille environ 50 personnes dont une trentaine de permanents. Cette unité devrait rejoindre l'IGE vers 2023-2024 au vu de la proximité des sujets de recherche et d'observation.

Ces deux unités ont une seule et même tutelle : l'INRAE, un EPST créé le 1er janvier 2020 et issu de la fusion de l'INRA (Institut national de la recherche agronomique) et IRSTEA (Institut national de recherche en sciences et technologies pour l'environnement et l'agriculture).

L'informatique de ces deux unités est rattachée à la DSI INRAE (service inter-régional SIIR à l'échelle régionale). 3 personnes sont en poste à Grenoble : un ingénieur ASR, un ingénieur spécialisé sur le calcul qui intervient à la maille des projets et une personne qui devrait être embauché à ETNA en 2021. Par ailleurs, les interventions sur les postes de travail /et le ticketing pour la gestion du parc est assuré par un prestataire extérieur (Infogérant) avec un service d'appui sur Lyon-Grenoble.

Ces unités n'utilisent pas de VM ni du stockage de type SUMMER. 7 serveurs de l'ex-IRSTEA et les données sont actuellement en cours de migration vers Montpellier et Toulouse, centre de données pour éviter d'avoir des serveurs dans de petit data centers. L'informatique sur le site de Grenoble est considérée meilleure qu'au sein de la DSI INRAE sans doute grâce à la convention historique entre IRSTEA et GRICAD. Il existe un grand nombre de bases de données PostgreSQL. Les équipes sont structurées avec un plateau de compétence qui gère une grande partie des données, mais des départs à la retraite risquent de réduire les forces d'appui de moitié d'ici 2025 alors qu'il y a besoin de capacité notamment en calcul. Les équipes sont intéressées

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