CR_2021_10_08
La communauté utilitR comporte une trentaine de membres dont un cœur très actif d’une dizaine de personnes.
Plusieurs de ces contributeurs actifs sont membres ou anciens membres du réseau LS².
Lino et Olivier sont les 2 coordinateurs (comporte notamment un rôle d’impulsion) de la communauté.
Il faudrait enrôler de nouveaux membres dans utilitR.
Loïc demandera aux deux Sylvie qu’utilitR puisse être présenté dans le cadre d’une réunion du CPS (réunion des chefs de SSM) qui est un meilleur relais que le GiTiSSP pour faire connaître utilitR dans tous les SSM et ainsi que de nouveaux membres intègrent la communauté. Loïc parlera également de la communauté aux deux chefs de services développement qui ont des équipes de développement travaillant en R.
utilitR apporte des gains collectifs pour les statisticiens/data scientist mais les coûts sont individuels. Il faut inciter la hiérarchie des contributeurs Insee à utilitR à leur octroyer du temps de travail dédié à utilitR. Loïc relaiera cette demande en CD lorsqu’on présentera le plan de conversion annuelle de programme self SAS en R (suite aux recommandations du rapport IG récent sur ce sujet). En particulier, il est impératif que les coordonnateurs puissent bénéficier de temps de travail dédié à utilitR.
La communauté envisage d’ouvrir des travaux documentaires d’une part sur shiny et d’autre part sur la cartographie (c’est un sujet énorme). Il serait également intéressant que les statisticiens disposent de shapefiles standardisés. Loïc propose d’organiser un échange avec le groupe géographie du service développement de Paris.
Il serait intéressant d’avoir une documentation équivalente pour Python.
Un premier pas dans cette direction est en cours avec le portage récent du package R doremifasol (données Insee publiques) en python (package pynsee) qui est en cours de test dans l'enseignement en 2e année d'ENSAE.
La communauté envisage de créer une documentation sur les bonnes pratiques de développement, inspiré de conventions adoptées par les approches DevOps et DataOps. Ce guide serait agnostique au langage de développement utilisé, chaque pratique pouvant être illustrée par des exemples en R et/ou Python par exemple. En outre, cette façon de faire pourrait permettre d’enrôler des contributeurs python. Il s'agit d'un approfondissement du guide déjà existant
La communauté envisage de présenter ces bonnes pratiques selon plusieurs niveaux graduels. A l'heure actuelle, les niveaux suivants sont envisagés:
- Versionner / collaborer
- Grammaire/syntaxe du code
- Gestion des dépendances
- Modularisation / fonctionalisation
- CI/CD, dockers, kubernetes
Le premier ensemble de niveaux est le socle minimal de bonnes pratiques qu’il faut toujours mettre en œuvre à savoir : bien rédiger le code ) , bien structurer les dossiers, versionner le code, bien gérer les dépendances (via renv), encoder en utf8. Avec ce socle on vise la population des selfeurs sur AUS ou sur machine en local.
Ensuite, le second ensemble de niveaux correspond à des pratiques plus avancées comme l’intégration continue, la mise en place de log lorsque cela est adapté (ex : dans le cas de batchs statistiques pérennes de production), les tests unitaires, le découpage de longs scripts en fonctions, les tests sur de petits jeux de données, la gestion des exceptions.
La communauté envisage de proposer des templates de projet c’est à dire quelques lignes de code « standard » permettant de bien paramétrer un projet à son démarrage (usethis ou cookiecutter).
Les débats sont présents dans une issue dédiée
Certains statisticiens/data scientist ont besoin d’aide notamment au démarrage d’un projet R (projet nouveau ou conversion d’un code SAS). Comment répondre à ce besoin ?
Il serait intéressant que la DIIT ait un échange avec ces équipes projet au démarrage pour évaluer le niveau de maturité en développement de l’équipe : cela nécessite une ou deux heures d’échange.
Ensuite, il faut pouvoir orienter les équipes encore peu matures vers une communauté support.
Loïc estime que cette communauté support doit être constituée de praticiens du quotidien en R et pas d’une équipe centrale dédiée à 100 % sur du support.
Il s’agit d’une communauté distincte de la communauté utilitR mais certains membres d’utilitR pourraient peut-être souhaiter l’intégrer.
Ce sujet reste à maturer (combien de personnes au minimum faudrait-il ? Quelle quotité de travail ? Comment organiser le travail ? Quelle animation ? Il faudrait sans doute planifier un minimum le travail, les membres de la communauté support ne pouvant pas se libérer dès qu’une demande est formulée donc il faut un peu d’anticipation).
