Bonnes pratiques pour les projets statistiques

Une formation aux bonnes pratiques avec Git et R

Lino Galiana

Insee

Pierre Lamarche

Insee

Introduction

Version pour les manageurs de la formation aux bonnes pratiques avec et

Retour à la page d’accueil pour explorer les autres versions

Introduction

Pourquoi les bonnes pratiques ?

Origine : communauté des développeurs logiciels
Constats :
- le “code est plus souvent lu qu’écrit” (Guido Van Rossum)
- la maintenance d’un code est très coûteuse
Conséquence : un ensemble de règles informelles, conventionnellement acceptées comme produisant des logiciels fiables, évolutifs et maintenables

Pourquoi intéresser les statisticiens aux bonnes pratiques ?

L’activité du statisticien / datascientist tend à se rapprocher de celle du développeur (notion de citizen developers) :

projets intenses en code
projets collaboratifs et de grande envergure
complexification des données et donc des infrastructures
déploiement d’applications pour valoriser les analyses

Pourquoi intéresser les managers aux bonnes pratiques ?

Projets en production (automatisée ou ponctuelle) impliquent:
- La coordination entre plusieurs acteurs (aux niveaux techniques différents)
- La répétition d’opérations dans le temps
- Des évolutions sur des maillons de chaînes, sans la déstabiliser

Le tout dans un environnement changeant (données, infrastructures, équipes…)

Bonnes pratiques ( et ): manière de réduire le poids de la maintenance
- Sans brider la phase d’expérimentation

Erreur de ne pas penser ensemble les enjeux organisationnels, humains et techniques
- Derrière le sujet technique, opportunité pour faire évoluer l’organisation…
- … pour produire des statistiques plus nombreuses, de meilleure qualité, en souffrant moins

eedd

Enjeux de la formation bonnes pratiques

Un point de départ commun

Enjeux de la formation bonnes pratiques

Un point de départ commun

Une structuration de projet plus viable

Messages clés de la formation aux agents

Des standards communautaires qui favorisent la reproductibilité et la maintenabilité
De multiples outils pour simplifier leur mise en oeuvre
Un coût d’autant plus faible que l’on se place en amont
Le mouvement de modernisation du self est l’occasion d’une montée en compétence collective

Lignes directrices de la formation aux agents

1️⃣ Versionner son projet pour historiciser et archiver proprement

2️⃣ Construire des codes de qualité (lisibles, reproductibles, auto-documentés…)

3️⃣ Adopter une structure modulaire et évolutive

4️⃣ Utiliser des formats de données adaptés

5️⃣ Comment construire des environnements reproductibles

6️⃣ Enjeux de la mise en production de projets statistiques

Ressources communautaires

Canaux de discussion
- À l’Insee
  - Pour toute question sur Git : Insee-Git-Gitlab
  - Pour toute question stat/self : Insee - Outils Stats v2
  - Pour toute question spécifique à AUS/LS3 : Insee-DSI-Plateformes-Internes-Datascience
- Plus largement sur
  - Sur Tchap : Langage R (Tchap)
  - Sur Slack : r-grrr
Documentation
- Service datascience Insee
- UtilitR
Formation : Espace formation du SSP Cloud
Réseau data science : SSPHub

Plan

Présentation des enjeux avec des exemples concrets
Qualité et structure des projets
Pourquoi et comment faire du bon ?
Format et sécurité des données
Ouverture à l’open source

Illustration: l’élaboration d’une statistique

Le cas d’usage classique à l’Insee

Il faut distinguer deux types de processus de production :

celui qui est entièrement automatisé, et où l’intervention humaine est limitée ;
celui qui nécessite du travail humain (vérifications ex post non automatisables, etc.) de la part du statisticien, et donc fait l’objet de tâtonnements :
- calcul du taux de pauvreté avec ERFS et SRCV ;
- micro-simulation avec le modèle INES ;
- des processus de suivi conjoncturels…

Pourquoi répond-il bien aux enjeux de la production ?

Exemple avec calcul du taux de pauvreté dans SRCV

Les tâtonnements supposent des allers et retours sur différentes hypothèses :

prise en compte évolutive des phénomènes affectant l’indicateur (défiscalisation de revenus, nouvelles prestations sociales, etc.) ;
production de différentes variantes que l’on veut pouvoir comparer les unes aux autres ;
comprendre ce qui a été fait pour les précédentes productions, éventuellement qui a fait quoi.

Quels concepts ?

les variantes peuvent se décliner sous la notion de branches ;
en traçant l’ensemble des modifications du code, facilite la complète reproductibilité des tâtonnements ;
au travers de l’historique, il permet de retracer l’ensemble du cheminement ;
le git blame permet de voir qui a fait quoi ;
mais cela nécessite une discipline sur l’usage de .

⇒ deux notions essentielles : reproductibilité et traçabilité

Gestion du cycle de vie d’un projet

Changement de paradigme : le code self doit être maintenu
- Changement de version de et des packages ;
- Quelles solutions connaissez-vous ?
renv et la notion de lockfile
anticiper les montées de version des logiciels :
- on peut envisager un protocole pour cela

Gestion du cycle de vie d’un projet: `renv`

Exemple de renv.lock

Observer la composition de ce fichier (100 premières lignes)

renv.lock

{
  "R": {
    "Version": "4.3.3",
    "Repositories": [
      {
        "Name": "CRAN",
        "URL": "https://packagemanager.posit.co/cran/latest"
      }
    ]
  },
  "Packages": {
    "BH": {
      "Package": "BH",
      "Version": "1.84.0-0",
      "Source": "Repository",
      "Repository": "CRAN",
      "Hash": "a8235afbcd6316e6e91433ea47661013"
    },
    "DBI": {
      "Package": "DBI",
      "Version": "1.2.2",
      "Source": "Repository",
      "Repository": "CRAN",
      "Requirements": [
        "R",
        "methods"
      ],
      "Hash": "164809cd72e1d5160b4cb3aa57f510fe"
    },
    "DT": {
      "Package": "DT",
      "Version": "0.33",
      "Source": "Repository",
      "Repository": "RSPM",
      "Requirements": [
        "crosstalk",
        "htmltools",
        "htmlwidgets",
        "httpuv",
        "jquerylib",
        "jsonlite",
        "magrittr",
        "promises"
      ],
      "Hash": "64ff3427f559ce3f2597a4fe13255cb6"
    },
    "KernSmooth": {
      "Package": "KernSmooth",
      "Version": "2.23-22",
      "Source": "Repository",
      "Repository": "CRAN",
      "Requirements": [
        "R",
        "stats"
      ],
      "Hash": "2fecebc3047322fa5930f74fae5de70f"
    },
    "MASS": {
      "Package": "MASS",
      "Version": "7.3-60.0.1",
      "Source": "Repository",
      "Repository": "CRAN",
      "Requirements": [
        "R",
        "grDevices",
        "graphics",
        "methods",
        "stats",
        "utils"
      ],
      "Hash": "b765b28387acc8ec9e9c1530713cb19c"
    },
    "Matrix": {
      "Package": "Matrix",
      "Version": "1.6-5",
      "Source": "Repository",
      "Repository": "CRAN",
      "Requirements": [
        "R",
        "grDevices",
        "graphics",
        "grid",
        "lattice",
        "methods",
        "stats",
        "utils"
      ],
      "Hash": "8c7115cd3a0e048bda2a7cd110549f7a"
    },
    "R6": {
      "Package": "R6",
      "Version": "2.5.1",
      "Source": "Repository",
      "Repository": "RSPM",
      "Requirements": [
        "R"
      ],
      "Hash": "470851b6d5d0ac559e9d01bb352b4021"
    },
    "RColorBrewer": {

Ce que renv évite

On retrouve parfois sur internet un code similaire à celui-ci :

# A ne pas reproduire chez vous 😨
if (!requireNamespace("dplyr", quietly = TRUE)) {
  install.packages("dplyr")
}

Gestion du cycle de vie d’un projet

Gérer le cycle de vie:
- du code
- de son environnement d’exécution
- des données mobilisées en entrée du projet et produites de manière intermédiaire.
Définir responsabilités et organisation à la fois :
- sur la maintenance du code ;
- sur gitlab.insee.fr.

Qualité du code et structure des projets

Enjeux

D’une vision utilitariste du code à une vision du code comme outil de communication
Favoriser la lisibilité et la maintenabilité
Assurer la transparence méthodologique
La modularité pour éviter les monolithes

Les outils à recommander aux agents

Deux outils pratiques aident à respecter les standards :

linter : programme qui vérifie que le code est formellement conforme à un certain guidestyle
- signale problèmes formels, sans corriger
formatter : programme qui reformate un code pour le rendre conforme à un certain guidestyle
- modifie directement le code

Note

Il existe un guide de référence pour bien coder en : le Tidyverse style guide.

La modularité des projets

Favoriser l’utilisation de fonctions
- Limite les risques d’erreur liés aux copier/coller
- Rend le code plus lisible et plus compact
- Unicité de la source de vérité
Les packages
- Idéal pour favoriser la réutilisation du code
- Coût de maintenance élevé

Bien documenter

Grands principes :
- Documenter le pourquoi plutôt que le comment
- Privilégier l’auto-documentation via des nommages pertinents
Documenter le projet (contexte, objectifs, fonctionnement) dans un fichier README
- Quelques modèles : utilitR, DoReMIFaSol

Pourquoi et comment faire du bon `Git` ?

1️⃣ Archiver son code proprement

pour en finir avec ça :

1️⃣ Archiver son code proprement

ou ça :

1️⃣ Archiver son code proprement

ou encore ça :

prior <- read_csv(prior_path)
prior <- prior |>
    select(id, proba_inter, proba_build, proba_rfl) |>
    separate(id, into = c('nidt', 'grid_id'), sep = ":") |>
    group_by(nidt) |>
    mutate(
        proba_build = proba_build/sum(proba_build),
        proba_rfl = proba_rfl/sum(proba_rfl),
        ) |>
    unite(col = "id", nidt, grid_id, sep = ":")

# Test
# prior_test <- prior |>
#    mutate(
#        proba_inter = round(proba_inter, 4)
#        proba_build = round(proba_build, 4)
#        proba_rfl = round(proba_rfl, 4)
#    )

write_csv(prior_round, "~/prior.csv")

1️⃣ Archiver son code proprement

Pour arriver à ça :

Source : ThinkR

2️⃣ Voyager dans le temps (de votre projet)

Concepts

`Git`, `GitHub`, `GitLab`… quelles différences ?

est un logiciel ;
Utilisation en ligne de commandes
Différentes interfaces graphiques (RStudio, VS Code…)

Concepts

`Git`, `GitHub`, `GitLab`… quelles différences ?

GitHub et GitLab sont des forges logicielles
Forge: espace d’archivage de code
Des fonctionalités supplémentaires : réseau social du code

Astuce

GitHub : utilisation pour les projets open-source
GitLab : utilisation pour les projets internes