Ce poste restitue le contexte et le résultat de l’atelier R-SNDS tenu lors du congrès émois 2024
Utilisation de R dans le SNDS : Comment peut-on collaborer ?
Constat : Nous sommes de plus en plus nombreux à utiliser R dans le SNDS, mais il existe peu de partage sur cette utilisation à l’heure actuelle.
Objectif : Session collective afin d’identifier les besoins, les attentes sur R dans le SNDS et les moyens pour répondre à ces besoins.
Format de l’atelier (1h) : Trois thèmes ont été abordés : les besoins, les moyens de collaborer et la contribution de chacun. Quatre groupes ont été formés en début d’atelier. Pour chaque thème, un des organisateurs a présenté la question, puis chaque groupe a réfléchi au thème pendant cinq minutes ; enfin l’animateur a collecté les réponses de la part de chaque groupe pendant une restitution collective de dix minutes.
Les organisateurs : Octave Guinebretière, Antoine Belloir, Thomas Nedelec (ICM), Julie Kamionka, Vincent Reduron, Pierre-Louis Bithorel (Drees), Thomas Soeiro (AP-HM), Catherine Bisquay, Adeline Degremont, Matthieu Doutreligne (HAS)
Les participants : Une cinquantaine de participants étaient présents lors de l’atelier et sept personnes étaient à distance. Le lien vers une fiche de présence a été diffusé en début et en fin d’atelier, puis rediffusé via les organisateurs : 43 personnes ont renseigné leur mail. L’étude des domaines des adresses mails montre la diversité des institutions présentes : HAS, ministère de la santé, assurance maladie, ARS, ATIH, CHU (AP-HP, AP-HM, Brest, Bordeaux, Lille), Santé Publique France, EHESP, IRDES, et autres établissements de soin.
Thème 1 - Les besoins : Quels sont vos besoins, vos attentes sur l’utilisation de R dans le SNDS ?
Les besoins remontés sont principalement des évolutions logicielles et techniques concernant la plateforme de l’assurance maladie, ainsi que des formations sur la prise en main de R.
Même s‘ils ne relèvent pas directement de la thématique de la collaboration, les besoins remontés en premier lieu concernent des évolutions de la plateforme de l’assurance maladie. Les participants sont conscients de la difficulté de mettre en place ces évolutions mais ont jugé bons de les formuler explicitement dans le cadre de cet atelier : installer des packages extérieurs ou développés spécifiquement sur le SNDS (ex: cartographie, rmarkdown), avoir une forge logiciel (ex. gitlab), avoir plus de mémoire RAM en cas de besoin.
Concernant les besoins de formation et de documentation spécifiques à R, sont remontés les questions suivantes : comment se connecter sur oracle via R, comment gérer les fichiers img, html, comment passer de tables SAS à des formats R compatibles (et réciproquement) ou disposer d’un moyen de ne pas passer par SAS pour les tables agrégés. Ce genre d’éléments manque actuellement pour faciliter le passage de SAS à R. Plusieurs besoins remontés illustrent un besoin de formation supplémentaire sur le fonctionnement du portail (export de fichiers, dossiers partagés).
Des besoins de partage de scripts ou de bonnes pratiques R ont également été évoqués, pour des utilisateurs plus aguerris de R dans le SNDS : le partage de codes d’extraction ou de listes de codes de nomenclature (par exemple pour des populations cibles spécifiques), la traduction en R de code existant en SAS pour certaines études.
Thème 2 – Les moyens de collaborer : Quels sont les modalités possibles de partage sur l’utilisation de R dans le SNDS, les canaux de collaboration ?
Il manque actuellement différents niveaux de communication :
Le besoin d’identifier et de contacter des experts référents sur des sujets spécifique a été formulé. Un des moyens proposés pour faciliter les échanges a été la création d’un annuaire référençant les noms des personnes, leur institution, les sujets sur lesquels elles travaillent et un moyen de les contacter informellement. L’utilisation d’un sharepoint a également été évoqué.
Les participants ont relevé la possibilité d’avoir des espaces de discussion de type forum (ex. forum SNDS) pour poser des questions, mais également un espace de discussion en temps réel (ex. Slack group R grrr, tchap). Plusieurs fois est remonté le fait que de multiples canaux existent et qu’il n’est pas forcément pertinent d’en rajouter un nouveau. Quel que soit le moyen de communication, celui-ci doit être simple d’utilisation et peu chronophage. Il serait pertinent de centraliser les références et les outils existants à un seul endroit afin d’éviter la redondance d’information.
Concernant le code informatique, le gitlab du HDH a été évoqué comme un moyen pratique de partager des lignes de code ; la documentation du HDH est pertinente mais la maintenance (identification des mainteneurs, besoin de mise à jour) est problématique. Partager du pseudo-code multi-langage serait à développer.
Thème 3 – La contribution de chacun : Quel pourrait être l’implication de chacun sur le partage ?
Contribuer doit passer par une participation aux fils de discussions lorsqu’on est concerné, une participation active de tout le monde (avec des modérateurs), l’utilisation de templates simplifiant et encadrant la participation. Le code doit être publié lisible mais sans attendre la perfection, par exemple en passant par un forum pour publier des choses non finalisées.
Les contributions doivent être identifiées et valorisées : Cela peut passer par le dépôt de code (sur arxiv ? sur github/gitlab ?), mais d’autres moyens de reconnaissance doivent être imaginés. Cette reconnaissance des contributions doit également être plus institutionnalisée. Partager du code nécessite des efforts supplémentaires, or la politique de partage des données n’est pas forcément développée au sein des différentes institutions employeuses. L’ajout (à quel niveau ?) d’une charte de partage des données pourrait encourager l’open source. Le partage est encore vu trop négativement par les employeurs. Il faut mobiliser les hiérarchies de chaque institution pour souligner que le passage au langage R nécessite obligatoirement du temps de formation et de partage de la part des agents. La sur sollicitation de certains, identifiés comme personnes référentes, doit être évitée.
Plus de rencontres ont été demandées, en présentiel, et pas seulement à Paris.
Il faut qu’il y ait un pilote qui en partant des besoins et des contributions puissent arbitrer sur une feuille de route afin de concentrer les efforts là où il y a le plus de retour sur investissement pour l’ensemble des acteurs.
Propositions de prochaines actions
- Partage de ce compte rendu avec la CNAM
- Partage de ce compte rendu avec le HDH pour présenter ces besoins et quelques propositions :
- Ouvrir plus largement des rôles de mainteneur sur le gitlab du HDH
- Mise en place de sprint de documentation
- Création d’une catégorie partage de snippets de code sur le forum d’entraide
- Proposition d’ouvrir un programme 10% SNDS sur le modèle du programme 10% de la DINUM
- Meetup SNDS - R (HDH-CNAM) à la rentrée avec des mini présentations de 20-30 min
- Publication de ce compte-rendu sur le forum d’entraide du HDH.
