Un environnement de travail en Python et en R

Pourquoi cette leçon n’est pas facultative

La raison la plus fréquente pour laquelle une analyse de suivi-évaluation cesse d’être reproductible n’est pas une erreur statistique. C’est que la personne qui l’a écrite a installé un paquet un après-midi, n’a jamais noté lequel, puis est partie. Six mois plus tard, le script échoue à l’import sur un portable de bureau terrain relié par satellite, et le rapport trimestriel redevient un travail manuel sur tableur.

Dix minutes de mise en place aujourd’hui, c’est ce qui évite cela.

Python : utilisez uv, pas l’interpréteur du système

Votre système d’exploitation est livré avec un Python. N’analysez pas de données avec celui-là : il est là pour faire fonctionner le système, et le modifier peut casser des choses dont vous ignoriez qu’elles en dépendaient.

uv installe un Python isolé et résout les paquets assez vite pour rester utilisable sur une connexion lente. Il écrit aussi un fichier de verrouillage, ce qui rend l’environnement reproductible sur la machine de quelqu’un d’autre.

# Installer uv (macOS et Linux)
curl -LsSf https://astral.sh/uv/install.sh | sh

# Créer un projet et fixer un interpréteur
uv init muac-analysis
cd muac-analysis
uv python install 3.13

# Ajouter ce que cette formation utilise
uv add pandas pyarrow matplotlib

uv add écrit à la fois pyproject.toml (ce que vous avez demandé) et uv.lock (ce qui a exactement été installé, empreinte comprise). Versionnez les deux. Un collègue reproduit alors votre environnement en une commande :

uv sync

Derrière un proxy ou hors ligne, uv sait installer depuis un dossier local de paquets. Télécharger ces paquets une fois, sur une clé USB, et installer depuis celle-ci est un mode de travail courant dans le secteur : il vaut la peine de le préparer avant d’en avoir besoin.

R : utilisez les Projets et renv

Le problème équivalent en R, c’est la bibliothèque globale — des paquets installés dans un emplacement partagé, utilisés sans le savoir par toutes vos analyses, et mis à jour silencieusement sous vos pieds.

# Une fois par machine
install.packages("renv")

# Une fois par analyse, depuis un Projet RStudio
renv::init()

# Ajouter ce que cette formation utilise
install.packages(c("readr", "dplyr", "tidyr", "ggplot2", "janitor"))

# Consigner exactement ce qui est installé
renv::snapshot()

renv.lock est l’équivalent de uv.lock. Versionnez-le. Un collègue exécute renv::restore() et obtient votre bibliothèque, pas la sienne.

Deux habitudes comptent autant que l’outillage :

• Travaillez dans un Projet. Le répertoire de travail est alors la racine du projet, pour tout le monde, toujours. Des chemins comme data/raw/muac.csv fonctionnent sur n’importe quelle machine.
• N’écrivez jamais setwd(). Cela inscrit votre nom d’utilisateur dans l’analyse et garantit son échec chez la personne suivante.

Une organisation de projet qui survit à une passation

La même structure convient aux deux langages. Elle vaut la peine d’être adoptée telle quelle, car sa valeur tient à sa prévisibilité et non à son ingéniosité.

muac-analysis/
  data/
    raw/          # exactement tel qu'arrivé. Lecture seule. Jamais modifié.
    interim/      # résultats intermédiaires. Jetables.
    processed/    # prêt à l'analyse. Régénérable depuis raw + code.
  scripts/
    01-lecture.py
    02-nettoyage.py
    03-indicateurs.py
  output/
    figures/
    tables/
  README.md

Une règle porte l’essentiel : data/raw/ est en lecture seule. Si vous ouvrez l’export dans Excel, corrigez trois cellules et enregistrez, vous avez détruit la seule trace de ce qui est réellement arrivé, et plus personne — vous compris — ne pourra jamais distinguer l’original de la correction.

Tout ce qui se trouve en aval de data/raw/ doit pouvoir être reproduit en le supprimant puis en relançant les scripts. Si ce n’est pas le cas, une opération est faite à la main, et c’est précisément cette opération-là qui cassera.

Un test utile : supprimez entièrement data/processed/ et output/, relancez vos scripts, et vérifiez que vous retrouvez les mêmes résultats. Si vous ne vous résolvez pas à essayer, vous connaissez déjà la réponse.

Le même premier script, dans les deux langages

Lire le registre, examiner sa forme, afficher les premières lignes. Rien de plus — il s’agit seulement de confirmer que l’environnement fonctionne avant d’en dépendre.

import pandas as pd

muac = pd.read_csv("data/raw/muac-screening-artibonite-2024.v1.csv")

print(muac.shape)
print(muac.head())
print(muac.dtypes)

library(readr)
library(dplyr)

muac <- read_csv("data/raw/muac-screening-artibonite-2024.v1.csv")

dim(muac)
head(muac)
glimpse(muac)

Les deux doivent annoncer 4 218 lignes et 8 colonnes. Si ce n’est pas le cas, arrêtez-vous ici : un nombre de lignes en désaccord avec la source est l’erreur la moins coûteuse que vous détecterez jamais, et elle devient bien plus chère trois scripts plus loin.

Ce sur quoi les deux langages divergent

Vous utiliserez les deux ; autant savoir où ils diffèrent de manière conséquente.

Aspect	pandas	dplyr / readr
Valeur manquante	NaN, et None pour les objets	NA, typé par colonne
Lecture d’un CSV	pd.read_csv devine les types	read_csv devine et le signale
Enchaînement d’étapes	Chaînage de méthodes ou réaffectation	Le tube, |>
Synthèse par groupe	groupby().agg()	group_by() |> summarise()
Catégories	Type category, sur demande	Les facteurs, et ils mordent

Aucun n’est meilleur. Celui qui compte est celui que votre équipe utilise déjà, et si cette formation enseigne les deux, c’est parce que vous changerez d’équipe.

La suite

La leçon suivante lit l’export correctement — ce qui est plus difficile que read_csv(chemin), car les valeurs par défaut abîmeront discrètement les identifiants, les dates et le code de valeur manquante avant que vous n’ayez regardé quoi que ce soit.