---
# System prepended metadata

title: "#\_Discussions VULCAIN Rouen 30"
tags: ['2023', document de travail]

---

# Discussions VULCAIN / RZINE / GTNOTEBOOK

Rouen 30/11/2023 14h - 17h

## Participants

Sébastien Rey-Coyrehourcq
Stéphane Pouyllau
Raphaelle Krummeich 
Hugues Pecout
Antoine de Sacy (excusé)

## ODJ

- Positionnement de Vulcain au sein du HN Lab (SP)
    - Rôle des _POC_ réalisées par le HN Lab
    - Limites actuelles de Vulcain
    - Evolutions possibles

- Discussion croisées autour des initiatives en cours et des perspectives offertes (Hugues, Raphaelle, Sébastien)
    -  RZine
    -  GT DataPaper
    -  GT Notebook
    -  GeoPlateforme Labo (ANR Plateforme)
    -  autre exemple : Journal of Digital History (Jupyter NB)
    https://journalofdigitalhistory.org/en/article/m7DWqDjY3hoV
    

## Synthèse des discussions

HNLab Postdoc interdisciplinaire
HNLab un des poles d'Humanum
Changement de status UPS vers UAR pour pouvoir ouvrir thésard / postdoc.

- Rappel de l'architecture et du pilotage de Humanum et HNLab
    - HNLab validé par le comité scientifique et comité pilotage sur 4 ans
    - HNLab pas représentatif des communautés de recherche, il ne représente que lui-même. 
    - Communautés de recherche qui doivent dire ce dont ils ont besoin.
    - Aspect scientifique, accueil de postdoc et doctorants
- Présentation de l'initiative et des limites de Callisto
    - Objectifs : 
        - Voir le retour d'XP complet : https://hackmd.io/-lt1lerKQEW9rankt7e7_Q#Pr%C3%A9sentation-de-15-min---Nicolas-Sauret-MCF
    - Le pourquoi de l'arrêt de l'initiative : 
        - trop séparés des besoins et du niveaux des communautés: "humanité numérique trop numérique et pas assez ancré dans la thématique"
        - Au bout de 3 mois, trop de demandes : 40, puis 180 
        - Essentiellement des historiens, sociologues
        - Grande partie des demandes confondent l'outil et la méthode
        - Sort du rôle du lab ("recherche")
    - Pas vu d'intérêt à la poursuite de l'expérience au niveau du copil ?
      > il faut interpréter cela ainsi : la preuve de concept a été faite (émergence des pratiques, réponse à un besoin, faisabilité), mais elle n'a pas passé la barre de l'industrialisation/mise en production par manque de ressources, c'est-à-dire par manque de volonté (pour allouer les ressources nécessaires) [name=nicolas]
- Présentation de l'initiative Vulcain : 
    - Authentification Orcid, Jupyter hub / lab + forge gitlab + git 
    - Front-end "didactique" pour le choix des ressources (kernel, langage, etc.) à déployer + documentation associés : 4 niveaux de questions prévues par Antoine De Sacy
    - Orcid → création d'un utilisateur local sur la machine → création des multiples espaces gitlab, etc. → Utilisateur autonome dans son espace.
    - Peupler l'existant : 
        - Collaboration avec DataActivist pour faire un premier paquet de Notebooks.
          > Voir [_io_ sur le gitlab d'Huma-Num](https://gitlab.huma-num.fr/io) : « _io_ (en référence à Callisto) est un programme du HN Lab d'Huma-Num en coopération avec Datactivist qui vise a mettre à disposition des communautés SHS des modèles en SHS entrainés pour l'IA sous la forme de Notebooks Jupyter.» : https://gitlab.huma-num.fr/io [name=nicolas]
        - Antoine De Sacy (thèse litterature, support CDI) : embarque des chercheurs de son domaine sur des corpus textuels.
    - Moyens :
        - Support du CNRS qui avait une idée équivalente (7 machines dont 2 GPU)
        - Petite équipe flexible, plus flexible que Humanum : Antoine DS + Post-doc à 50% sur de la plateforme, 50% sur IA (ISIDORE 2030)
- Objectifs : 
    - Faire communauté autour de la plateforme pour peser auprès d'Humanum
    - Trouver un mode de Gouvernance au delà HNLab/Humanum
- Perspectives :
    - Support stockage des données, Nakala serait le plus logique mais cela reste à faire.

- Discussions plus générales : 
    - Existant avec Onyxia : Kubernetes (k8s) 
        - → Trop couteux, frein dans l'ESR + Humanum à tous les niveaux sur ces technologies en général, externalisation.
        - → Trop complexe vis à vis de l'objectif poursuivi, *empowerment* technique (autoformation, autonomie, etc.), cad maitrise de la chaine de traitement, des outils et des méthologies associées. 
    - Utilisation "Global vs Local"
        - Observation de cette rupture dans le passage du local au global
        - Local (arguments): 
            - Les utilisateurs ont conscience de l'environnement technique qu'ils manipulent
            - Permet la montée en compétence en interne chez les utilisateurs et le personnels supports (IE/IGR) 
        - Global (arguments) 
            - Limite du local c'est le problème de puissance, souvent accessible seulement en global
            - Les gens redeviennent un peu consommateur, ce qui est tout autant bénéfique (abaissement de l'accès) que négatif (effet boite noire)

    - Diversité des workflows/usages autour du Notebook 
        - Exemple : Importance de la Répétabilité / Reproductibilité pour les Notebooks  : 
            - argument contre la répétabilité :
                - reproductibilité suffisante, ce qui compte c'est la méthode !
                - effet "wow" du déploiement à la demande : pourquoi faire ? Aucune utilité dans 90% des cas ? => cout écologique
                - Complexité disparait (infrastructure, logiciel/lib) => Pousse au clic boutton plutôt qu'à l'empowerment, etc.
            - argument pour la répétabilité :
                - reproductibilité ne suffit pas, il faut prévoir l'évolution ou la disparition des libs/packages/etc. pour que la méthode continue d'exister
                - tout ne doit pas forcément être reproductible => curation, responsabilisation 
                - mise à l'étrier, accompagnement pédagogique, 
                    - abaissement des barrières techniques, 
                    - modification aisée (données d'entrées) et rejouabilité directe sans nécessité de compétence ou à finalité d'acquisition de compétences 
                
        - Relecture de ces arguments doit se faire au prisme de l'usage :
            - Répétabilité dans le cadre d'un workflow pour un reviewer serait un plus : abaisse le coût pour la review/annotation du code (ie: pas besoin de tout installer sur sa machine)
            - Répétabilité clic bouton (binder) pour le lectorat se discute, du fait du cout en temps et écologique, cela peut être utile avec un accompagnement pédagogique en classe, mais inutile pour le tout venant sur le web, tout en étant certifié/possible par ailleurs : téléchargement d'un Docker, ou usage de Guix. 

- Perspectives croisées : 
    - Rencontres HumaNum en Juin, proposer des communications pour rendre visible une communauté autour de cette thématique.
    - Sur le volet Opérationnel RZine, pipeline facile, clic boutton déploiement de RZine à Vulcain. 
        - Stéphane propose de regarder ce qu'il est possible en CI avec la génération d'images/container adhoc Vulcain.
        - A plus longue échéance, Le GT Notebook continue de regarder aussi côté Guix et [réseau recherche reproductible](https://www.recherche-reproductible.fr/), une alternative  à Docker pour la reproductibilité au niveau OS.
    - Etudier la possibilité d'un consortium HumaNum, nécessite une lettre d'intention et un programme scientifique portée par des chercheurs et ingénieurs. Horizon à étudier lors de la journée d'étude 2024 ? 
    - Journal Of Digital History => voir comment ils ont géré la partie gitlab CI, notamment pour la partie review ? 

---

## Contenu en vrac des discussions


### Callisto / Vulcain 

### Historique 

Programme HNLab validé par le comité scientifique et comité pilotage sur 4 ans

Callisto faisait parti du 1er programme et on a du stopper du fait du changement de status.

Pas mal de succès 40 demandes puis 180 demandes, donc on a du arreter aussi car on sortait de l'expérimentation  : historien et socio essentiellement d'ailleur

Callisto expérimentation / voir le retour d'expérience webinaire 0 janvier 2023  :
https://hackmd.io/-lt1lerKQEW9rankt7e7_Q#Pr%C3%A9sentation-de-15-min---Nicolas-Sauret-MCF

Designer un service pour le mettre dans l'infra, pas forcément anticipé : 
- s'est heurté à l'IN2P3 qui dit en avoir déjà un.
- comment on fait pour avoir un dispositif avec le moins de frein pour l'usage des chercheurs. 

On a stopper car beaucoup de demande, en 3 mois on sortait du role du lab. En discutant, DSI CNRS, a peu pres la même idée dans les cartons. Ils ont fournis les 5 machines avec la maintenance. Donc on a pu redesigner le truc. Et maintenant on est sur 7 machines avec 2 machines GPU.

Retravail avec Antoine De Sacy, peuplé l'instrument avec de l'existant. On a fait çà : 
- DataActivist pour faire un premier paquet de Notebook.
- Maintenant avec Antoine De Sacy (thèse litterature, support CDI) avec R, et il a embarqué des chercheurs de son domaine sur du textuel.

2 nouveaux postdoc en plus qui démarre en septembre et en octobre : ISIDORE 2030. Ils bossent aussi sur Vulcain (portabilité des Notebook, pérénité, etc.) 50% sur de la plateforme, 50% sur IA

Si on continue Vulcain il faut en faire une vrai plateforme communautaire. Il faut que cela aille au delà, avec un modèle de gouvernance qui soit pas limité à HNLab / Humanum.

Humanum prendra le dispositif si il y a une communauté qui l'utilise. Expression du besoin.

Vulcain : orcid + git/gitlab + jupyter hub + jupyter lab
Petite équipe flexible, plus flexible que Humanum.

=> Vulcain sert un peu de support.

Vulcain, limite validé Copil, HNLab pas représentatif des communauté de recherche, il représente que lui-même. Communauté de recherche qui doivent dire ce dont ils ont besoin : 
 => Voie du consortium et conseil scientifique par exemple.
 => Rencontres annuelles humanum / Consortiums, proposition de communication, si possible autour de Vulcain par exemple. 

Dispositif de publication, si possible statique et pas dynamique. 

Renouvellement RStudio => Posit, tractation assez longue, augmentation du prix :  500 / 1000 personnes environ utilisateurs.


Rencontres HumaNum en Juin, proposer des communications pour rendre visibl une communauté autour de cette thématique.


Niveau de demande d'ouverture de compte pour callisto = 200 (trop pour une gestion au sein de HNLab)

DHNord / JOurnal Of Digital History 

K8s/Onyxia => Rejet complet Humanum, cout humain très important, sous traitance.

Idées de fabrique avec des briques un peu appropriable. Les gens veulent un truc qui marche, donc ils signent un cheque.
On veut pas être dans un truc de consommateur, les gens finissent par confondre.

Etre un peu dans un **système intermédiaire** : monter en compétence, démarrage de l'apprentissage pour être plus exigeant dans des couches un peu plus hautes.

Expertise FSI / niveau très différents côté anglo-saxon, niveau appréhension stat/math beaucoup plus elevé. Importance de réflechir à ce qu'il y a dans le pipeline de données, pour la crédibilité des projets.

IDE - git - plateforme de publication

Question du local / global de l'infra complexe.
Limite du local c'est le problème de puissance

IL faut que les gens aient conscience de ce qui se passe. 

En amont de Vulcain, le fait de "questionner" en amont. On pose des questions. Idée d'Antoine ce serait de faire des étapes, référencés avec les bonnes ressources pour se former ? Front de Vulcain. 4 niveaux.

Question de la montée en compétence, global vs local, il y a une rutpure dans cette montée lorsqu'on est en global. Les gens redeviennent un peu consommateur et c'est quelque chose que l'on expérimente à la fois dans les labo mais aussi côté Calisto/Vulcain.


- Github/ Gitlab  => problème de la communauté, limite qui revient.
- Problématique stockage données sur Vulcain, Nakala est une réponse logique, et c'est pas vraiment un problème

Consortium ? => Il y a des biais, avec de la construction, reconstruction indépendante par rapport à ce que propose humanum aussi. Tension dans cette articulation.

Sur le volet Opérationnel RZine, pipeline facile, clic boutton déploiement de RZine à Vulcain.

Inverser le processus par rapport à ce qui est prévu dans Vulcain, quelqu'un tombe la dessus RZine et j'ai ce qu'il faut pour pouvoir le réexecuter => niveau d'automatisation il faut le créé.

Clic bouton intéressant pour le lectorat (pour le volet pédagogique), mais aussi pour le volet éditorial.

Journal Of Digital History => voir comment ils ont géré la partie gitlab CI, notamment pour la partie review ?

Orcid, on créé un utilisateur local sur la machine, création des multiples espaces gitlab, etc. => autonome dans son espace.

GPU => Serveur de GPU et tu les monte dans les VM => plus simple.

Différents phases : 
- edition / review
- lectorat consultation

Reproductibilité prime sur la répétabilité pour Hugues quelque part. 

Les fragments c'est intéressant, mais est ce qu'on a besoin de tout répliqué ? Est-ce que c'est intéressant de relancer toute la fiche d'un coup ? En terme d'usage ? 

RZine c'est la méthode qui va primer, depuis le début, c'est vrai que la répétabilité, surtout de la fiche tout entière, qu'est ce que cela apporte ? Débat intéressant. Rejoint ce que dit Konrad aussi sur ce qui doit être reproductible ou pas ?

Consortium de la 3D pourquoi pas un consortium sur çà, multidiscipline des SHS et consort ? => Autonomie / Périmètre . Consortium => Lettre d'intention, plusieurs équipes de différentes disciplines, programme sur 4 ans. Il faut des chercheurs.





