3  Construire un projet d’analyse reproductible

ImportantQuestion de départ

Si vous rouvrez votre analyse dans six mois — ou si vous l’envoyez à un collègue — pourra-t-elle être exécutée sans modifier manuellement les chemins, rechercher les fichiers ou deviner l’ordre des scripts ?

3.1 Objectifs d’apprentissage

À la fin de ce chapitre, vous saurez :

  • expliquer pourquoi une analyse doit être organisée comme un projet plutôt que comme une collection de fichiers dispersés ;
  • créer une arborescence qui sépare données brutes, données dérivées, scripts et sorties ;
  • utiliser des chemins relatifs et éviter les chemins liés à un ordinateur particulier ;
  • distinguer données sources, objets intermédiaires et résultats ;
  • ordonner des scripts pour rendre explicite le workflow ;
  • utiliser Quarto comme document exécutable et comme support de restitution ;
  • comprendre le rôle de Git et de {renv} dans la reproductibilité ;
  • préparer un projet que l’on peut redémarrer depuis une session R vide.

3.2 Prérequis

Il faut savoir créer un objet, exécuter un script, charger un package et reconnaître un data.frame ou un tibble.

3.3 Pourquoi l’organisation fait partie de la méthode

Une analyse statistique n’est pas seulement un ensemble de résultats. C’est une chaîne de transformations : un fichier est importé, contrôlé, nettoyé, recodé, analysé, puis transformé en tableaux et figures. Si cette chaîne n’est pas organisée, plusieurs problèmes apparaissent rapidement :

  • le fichier source est écrasé par une version nettoyée ;
  • un script fonctionne uniquement parce qu’un objet créé la veille est encore dans la mémoire de R ;
  • les chemins contiennent le nom de l’utilisateur ou le bureau de l’ordinateur ;
  • plusieurs versions de données portent des noms comme final, final2, final_vrai ;
  • on ne sait plus quel script produit un graphique ;
  • un collègue ne peut pas réexécuter l’analyse.

Ces difficultés ne sont pas de simples questions de rangement. Elles concernent directement la traçabilité et la possibilité de vérifier les résultats.

NotePrincipe directeur

Un projet reproductible doit permettre de répondre à trois questions : d’où vient ce résultat ? quel code l’a produit ? à partir de quelle version des données ?

3.4 Le projet RStudio comme racine de travail

RStudio permet de regrouper une analyse dans un projet. Lorsqu’un projet est ouvert, son dossier constitue un point de référence stable pour les fichiers (Posit Software, PBC 2026b).

Pour un projet nommé analyse_enquete, une structure minimale peut être :

analyse_enquete/
├── analyse_enquete.Rproj
├── README.md
├── data/
│   ├── raw/
│   └── derived/
├── R/
├── figures/
├── outputs/
└── rapport.qmd

Cette structure n’est pas une loi universelle. L’important est de choisir une organisation compréhensible et stable.

3.4.1 Les dossiers ont des fonctions différentes

data/raw/ contient les données telles qu’elles ont été reçues ou téléchargées. Elles ne sont pas modifiées manuellement.

data/derived/ contient les données produites par le code : version nettoyée, fichier analytique, agrégats intermédiaires.

R/ contient les scripts de traitement ou des fonctions réutilisables.

figures/ et outputs/ contiennent des sorties produites automatiquement : images, tableaux exportés, résultats de modèles, etc.

README.md explique le projet : objectif, provenance des données, structure, ordre d’exécution, éventuelles contraintes d’accès.

AvertissementNe jamais transformer le fichier brut à la main

Corriger une cellule directement dans enquete_brut.xlsx détruit la trace de la correction. Il vaut mieux conserver le fichier source intact et écrire dans un script la règle qui produit enquete_clean.rds.

3.5 Le projet EnquêteR utilisé dans ce livre

Le jeu pédagogique fourni avec ce manuel suit précisément cette logique :

data/
├── raw/
│   ├── enqueter_brut.csv
│   ├── enqueter_brut.xlsx
│   ├── enqueter_brut.dta
│   └── enqueter_vague2.csv
├── documentation/
│   ├── questionnaire_enqueter.pdf
│   ├── dictionnaire_variables.xlsx
│   ├── dictionnaire_variables.csv
│   ├── modalites.csv
│   └── anomalies_pedagogiques.csv
└── derived/
    └── enqueter_clean.csv

Le fichier brut contient volontairement des codes spéciaux, des valeurs impossibles et quelques incohérences. L’objectif n’est pas d’offrir une base immédiatement parfaite, mais de permettre au lecteur de construire pas à pas une version analytique documentée.

3.6 Chemins relatifs : rendre le projet portable

Considérons le chemin suivant :

readr::read_csv("C:/Users/Marie/Documents/Memoire/data/enquete.csv")

Il peut fonctionner sur l’ordinateur de Marie, mais probablement pas sur celui de son directeur de mémoire. Le chemin incorpore une information propre à une machine.

Dans un projet, nous préférons :

readr::read_csv("data/raw/enquete.csv")

Ce chemin est relatif à la racine du projet. Il décrit la position logique du fichier à l’intérieur de l’analyse.

3.6.1 Éviter setwd() comme stratégie d’organisation

setwd() change le répertoire de travail :

setwd("C:/Users/Marie/Documents/Memoire")

Cette commande peut donner l’impression de résoudre le problème, mais elle réintroduit un chemin propre à une machine. Dans un workflow reproductible, nous privilégions un projet bien défini et des chemins relatifs.

3.6.2 Le package {here}

Pour rendre explicite la construction de chemins depuis la racine du projet, {here} fournit here() :

here::here("data", "raw", "enqueter_brut.csv")

L’intérêt n’est pas de remplacer chaque chaîne de caractères par here(), mais de rendre la racine du projet explicite lorsque cela améliore la robustesse du code.

AstuceBon réflexe

Un chemin doit décrire l’organisation du projet, pas l’identité ou le disque dur de la personne qui exécute le code.

3.7 Un workflow explicite avec des scripts numérotés

Pour une analyse d’enquête standard, on peut adopter :

R/
├── 00-setup.R
├── 01-import.R
├── 02-diagnostic.R
├── 03-nettoyage.R
├── 04-recodages.R
├── 05-descriptifs.R
└── 06-modeles.R

Les numéros indiquent l’ordre logique. Cette convention devient particulièrement utile lorsque plusieurs personnes travaillent sur le même projet.

3.7.1 00-setup.R : configuration minimale

Un fichier de configuration peut charger les packages réellement nécessaires :

library(dplyr)
library(tidyr)
library(readr)
library(haven)
library(labelled)

Éviter d’y mettre des centaines de lignes de transformation. Le fichier de configuration doit rester lisible.

3.7.2 Chaque script a une responsabilité

Un bon découpage limite les dépendances implicites :

  • 01-import.R lit les sources et vérifie leur structure ;
  • 02-diagnostic.R produit un audit ;
  • 03-nettoyage.R transforme les anomalies documentées ;
  • 04-recodages.R construit les variables d’analyse ;
  • les scripts suivants consomment la base dérivée.

Cette séparation est préférable à un fichier unique de 3 000 lignes où importation, nettoyage, graphiques et modèles sont entremêlés.

3.8 Donner des noms stables aux objets et fichiers

Les suffixes comme _final2 sont souvent le symptôme d’un workflow manuel. Une convention plus informative est :

enqueter_brut.csv
enqueter_clean.rds
enqueter_analyse.rds

et, si une date est réellement nécessaire :

2026-08-14_enqueter_export.csv

La date doit avoir une fonction : version externe reçue, extraction quotidienne, livraison officielle. Elle ne remplace pas un système de versionnage.

3.8.1 Ne pas confondre version des données et transformation des données

Si enqueter_clean.rds est toujours généré par 03-nettoyage.R, il n’est pas nécessaire d’enregistrer manuellement une nouvelle copie à chaque modification du script. Le code est la recette ; le fichier dérivé est un produit régénérable.

3.9 Démarrer depuis une session propre

Une analyse peut fonctionner par accident parce que l’environnement contient des objets créés auparavant. Pour détecter cette dépendance, il est utile de redémarrer régulièrement R puis de réexécuter le projet.

Dans RStudio, une session propre permet de vérifier que le code crée réellement tout ce dont il a besoin.

Éviter de s’appuyer sur la restauration automatique d’un ancien espace de travail .RData. L’objectif est que les objets soient recréés par les scripts.

AvertissementLe test de la session vide

Si un script ne fonctionne qu’après avoir exécuté manuellement plusieurs commandes non enregistrées, l’analyse n’est pas encore reproductible.

3.10 Quarto : associer texte, code et résultats

Un document Quarto .qmd associe texte en Markdown, métadonnées YAML et blocs de code exécutables. Un projet Quarto peut partager une configuration dans _quarto.yml et rendre un ensemble de documents avec une même structure (Posit Software, PBC 2026a).

Un document minimal :

---
title: "Analyse descriptive"
---

## Âge des répondants


::: {.cell layout-align="center"}

```{.r .cell-code}
mean(enquete$age, na.rm = TRUE)
```
:::

L’intérêt méthodologique est important : la valeur affichée dans le rapport peut être générée directement par le code qui la calcule. Cela limite les erreurs de copier-coller entre R, Excel, Word et une présentation.

3.10.1 Source et sortie

Il faut distinguer :

  • le fichier source .qmd, à conserver et versionner ;
  • le rendu HTML, PDF ou Word, qui peut être régénéré à partir de la source ;
  • les données et figures externes utilisées par le document.

Dans ce livre, Quarto sert à la fois au cours et d’exemple de workflow reproductible.

3.11 Git : versionner le code, pas multiplier les copies

Git conserve l’historique des modifications de fichiers texte. Il permet notamment :

  • de voir ce qui a changé ;
  • de revenir à une version antérieure ;
  • de travailler à plusieurs ;
  • d’associer une modification à un message explicatif.

Un commit utile peut être :

Recoder les valeurs 98/99 du revenu en valeurs manquantes

plutôt que :

modifs

Git ne remplace pas les sauvegardes et ne doit pas conduire à publier des données confidentielles. Dans de nombreux projets d’enquête, le code peut être versionné alors que les données brutes restent sur un espace sécurisé.

3.11.1 .gitignore

Un fichier .gitignore indique les fichiers à ne pas versionner. Par exemple :

.Rhistory
.RData
_book/
.quarto/
data/raw/confidentiel/

Ce mécanisme est utile, mais il ne constitue pas à lui seul une politique de sécurité. Une donnée sensible ne doit pas être placée sur un service distant simplement parce que l’on pense l’avoir ignorée.

3.12 {renv} : enregistrer les dépendances du projet

Un script dépend non seulement de R mais aussi des versions des packages. {renv} crée un environnement de packages associé au projet et un fichier renv.lock qui décrit les versions nécessaires (Ushey et Wickham 2026).

Les trois commandes à retenir sont :

renv::init()
renv::snapshot()
renv::restore()
  • init() initialise l’environnement du projet ;
  • snapshot() enregistre l’état des dépendances dans le lockfile ;
  • restore() réinstalle les versions décrites par ce lockfile.

Le but n’est pas de demander à un étudiant débutant de maîtriser immédiatement la gestion complète des dépendances. Il suffit de comprendre qu’une analyse reproductible dépend aussi de son environnement logiciel.

NoteReproductible ne signifie pas éternellement identique

Un lockfile augmente fortement la capacité à recréer un environnement, mais la reproductibilité dépend également du système d’exploitation, des sources de données, des logiciels externes et parfois de services en ligne. Il faut documenter ce qui compte pour l’analyse.

3.13 Documenter le projet avec un README.md

Un bon README répond rapidement aux questions suivantes :

  1. quel est l’objectif du projet ?
  2. quelle est la source des données ?
  3. où sont les données brutes ?
  4. quel script faut-il exécuter en premier ?
  5. quels fichiers sont générés ?
  6. existe-t-il des restrictions d’accès ou de diffusion ?

Exemple :

# Analyse de l'enquête X

## Données
Les fichiers sources sont conservés dans `data/raw/` et ne sont jamais modifiés.

## Reproduire l'analyse
1. Ouvrir `analyse_enquete.Rproj`.
2. Restaurer l'environnement avec `renv::restore()` si nécessaire.
3. Exécuter les scripts `R/01-...` à `R/04-...`.
4. Rendre `rapport.qmd`.

Ce texte paraît trivial au moment de créer le projet. Quelques mois plus tard, il peut économiser beaucoup de temps.

3.14 Cas particulier : données sensibles

Les enquêtes peuvent contenir des variables identifiantes ou quasi-identifiantes. L’organisation d’un projet doit alors distinguer au minimum :

  • les fichiers bruts sécurisés ;
  • les fichiers pseudonymisés ou minimisés ;
  • les données partageables ;
  • le code publiable ;
  • les sorties vérifiées avant diffusion.

L’absence du nom ou de l’adresse ne garantit pas l’anonymat. Une combinaison rare d’âge, commune, profession et caractéristiques familiales peut permettre une réidentification. Le chapitre 24 approfondira cette question.

3.15 Mise en pratique avec le projet du livre

3.15.1 Étape 1 — Vérifier la racine

Dans RStudio, ouvrez le fichier .Rproj du projet. Ensuite :

getwd()

Le chemin affiché peut être différent d’une machine à l’autre. C’est normal. Ce qui doit rester identique est l’arborescence à l’intérieur du projet.

3.15.2 Étape 2 — Vérifier les fichiers attendus

Afficher le code R 
file.exists("data/raw/enqueter_brut.csv")
file.exists("data/documentation/questionnaire_enqueter.pdf")
file.exists("data/documentation/dictionnaire_variables.xlsx")

Chaque instruction doit renvoyer TRUE si le kit est correctement copié.

3.15.3 Étape 3 — Construire un chemin explicitement

Afficher le code R 
here::here("data", "raw", "enqueter_brut.csv")

3.15.4 Étape 4 — Ne rien modifier dans raw/

Les chapitres suivants créeront les versions dérivées par le code. Le dossier raw/ devient ainsi la référence de départ.

3.16 Mini-exercices

3.16.1 Mini-exercice 1 — Identifier les chemins fragiles

Parmi les chemins suivants, lesquels sont portables ?

C:/Users/Lina/Desktop/memoire/data/enquete.csv
data/raw/enquete.csv
D:/CoursM2/2026/enquete.csv
figures/age.png

data/raw/enquete.csv et figures/age.png sont des chemins relatifs adaptés à une arborescence de projet. Les deux autres contiennent un lecteur ou un dossier propre à une machine.

3.16.2 Mini-exercice 2 — Classer les fichiers

Où placeriez-vous :

  • un fichier SPSS reçu d’un institut ;
  • un fichier RDS nettoyé par votre script ;
  • un graphique PNG produit pour un article ;
  • le dictionnaire de variables reçu avec les données ?

Une solution cohérente serait : SPSS dans data/raw/, RDS dans data/derived/, PNG dans figures/, dictionnaire dans data/documentation/. Le choix exact peut varier ; l’essentiel est de distinguer source, dérivé, documentation et sortie.

3.17 Exercice de synthèse

3.17.1 Niveau A — Appliquer

Créez un nouveau projet RStudio appelé exercice_enquete et les dossiers suivants :

data/raw
data/derived
data/documentation
R
figures
outputs

Ajoutez un README.md de dix lignes maximum expliquant le rôle de chaque dossier.

3.17.2 Niveau B — Choisir

Un collègue vous envoie un projet contenant :

  • analyse_finale.R ;
  • enquete_corrigee_finale2.xlsx ;
  • graph1.png ;
  • plusieurs appels à setwd("C:/Users/Paul/...").

Proposez une stratégie de réorganisation en justifiant ce qui doit être conservé comme source, régénéré, renommé ou supprimé.

3.17.3 Niveau C — Analyser

Concevez l’arborescence d’un projet d’enquête qui contient des données confidentielles non publiables, un code destiné à être ouvert et un article Quarto. Indiquez :

  • quels fichiers seront versionnés avec Git ;
  • quels fichiers seront exclus ;
  • quelles étapes sont nécessaires pour qu’un collaborateur autorisé puisse reproduire l’analyse ;
  • quelles informations le README doit contenir sans révéler de données sensibles.

3.17.4 Correction détaillée

Une réponse attendue distingue d’abord le fichier source reçu d’un fichier modifié manuellement. Le fichier brut original doit être retrouvé si possible et placé dans data/raw/. Les corrections doivent ensuite être écrites dans un script, qui produit un fichier dans data/derived/. Les setwd() absolus sont retirés au profit de chemins relatifs. Le graphique est idéalement régénéré par le code et placé dans figures/. Enfin, l’unique script peut être conservé s’il reste lisible ou scindé par responsabilités si sa taille et ses dépendances le justifient.

Une architecture robuste peut versionner scripts, .qmd, README, métadonnées non sensibles et renv.lock, tout en excluant data/raw/ et tout dérivé contenant des microdonnées confidentielles. La reproduction complète nécessite alors un canal autorisé pour obtenir les données, plus des instructions permettant de les placer au bon endroit. L’ouverture du code n’implique pas l’ouverture des microdonnées.

3.18 À retenir

  • Un projet organise la chaîne complète entre données sources, transformations et résultats.
  • Les données brutes doivent rester intactes ; les corrections doivent être produites par du code.
  • Les chemins relatifs rendent le projet portable entre ordinateurs.
  • setwd() avec un chemin personnel n’est pas une stratégie de reproductibilité.
  • Des scripts numérotés rendent explicite l’ordre du workflow.
  • Une session R vide est un bon test des dépendances implicites.
  • Quarto rapproche calcul et rédaction dans une même source exécutable (Posit Software, PBC 2026a).
  • Git conserve l’histoire du code ; {renv} aide à conserver l’histoire de l’environnement logiciel (Ushey et Wickham 2026).
  • La reproductibilité doit rester compatible avec la confidentialité et les règles d’accès aux données.

3.19 Pour aller plus loin

Les principes de projets Quarto et de métadonnées partagées sont documentés officiellement par Quarto (Posit Software, PBC 2026a). La documentation de {renv} présente le lockfile, snapshot() et restore() (Ushey et Wickham 2026). Les conventions de style ne sont pas obligatoires, mais une convention stable améliore nettement la lisibilité du code (Tidyverse Team 2026).

Dans le chapitre suivant, nous allons enfin ouvrir les fichiers d’enquête. L’objectif ne sera pas seulement de « réussir l’import », mais de vérifier immédiatement ce que R a réellement lu.