Le répertoire de travail en R : setwd(), getwd() et nettoyer l'espace de travail

Ce qu'est le répertoire de travail

Chaque session R tourne « dans » exactement un dossier : le répertoire de travail. Dès que tu utilises un chemin relatif - un chemin qui ne part pas de la racine du système de fichiers - R le résout par rapport à ce dossier. read.csv("data.csv") ne veut pas dire « trouve data.csv quelque part sur mon ordinateur » ; ça veut dire « ouvre le fichier appelé data.csv dans le répertoire de travail ».

Ce seul fait explique l'erreur de débutant la plus courante en R :

read.csv("data.csv")
# Error in file(file, "rt") : cannot open the connection
# In addition: Warning message: cannot open file 'data.csv': No such file or directory

Le fichier existe - juste pas dans le dossier que R regarde actuellement. Ton appel à read.csv n'a rien de faux ; le répertoire de travail de la session et l'emplacement du fichier ne sont pas d'accord. Les deux fonctions ci-dessous transforment ça d'un mystère en un diagnostic de dix secondes.

getwd() et setwd()

getwd() (get working directory) te dit où R regarde en ce moment :

print(getwd())

Lance-le et tu verras un chemin absolu - le dossier auquel cette session est ancrée. setwd() (set working directory) le change :

setwd("C:/Users/rosa/projects/sales-analysis")   # Windows: use / not \
setwd("/Users/rosa/projects/sales-analysis")     # macOS / Linux
getwd()                                          # confirm it took

Deux notes mécaniques. Sous Windows, écris les chemins avec / (ou des \\ doublés) - un \ seul est un caractère d'échappement dans les chaînes R, donc "C:\Users" est une erreur de syntaxe. Et setwd() lève une erreur immédiatement si le dossier n'existe pas, ce qui est l'échec le plus sympathique de ta journée : il ne peut pas te laisser silencieusement pointé au mauvais endroit.

La routine de débogage pour toute erreur « cannot open file » est donc : getwd() pour voir où R regarde, puis compare avec l'endroit où le fichier se trouve réellement.

list.files() : voir ce que R voit

Le troisième outil de la trousse liste le contenu du répertoire de travail - littéralement l'ensemble des noms qu'un chemin relatif peut atteindre :

print(list.files())

Si le fichier que tu essaies de lire apparaît dans cette sortie, read.csv("cefichier.csv") le trouvera. Sinon, retaper la ligne read.csv n'aidera pas - c'est le répertoire de travail qu'il faut corriger. list.files("data") jette un œil dans un sous-dossier, et list.files(pattern = "\\.csv$") ne garde que les CSV. Quand un nom de fichier semble correct mais reste introuvable, list.files() expose aussi les coupables classiques : une extension .txt invisible ajoutée par un éditeur de texte, ou Data.csv contre data.csv sur un système sensible à la casse.

Pourquoi un setwd() en dur casse

Passons à la partie qui prend parti. Tu verras des scripts qui s'ouvrent sur :

setwd("C:/Users/me/Desktop/stuff/project3/final_FINAL")

Cette ligne fonctionne sur exactement une machine : celle de l'auteur. Sur ton portable, le Mac de ton collègue, le serveur du département, ou ton propre ordinateur après une réorganisation, elle échoue dès la ligne 1. Coder un chemin absolu en dur grave l'arborescence d'une seule personne dans du code censé lui survivre.

La solution consiste à inverser la responsabilité : ne demande pas au script de trouver le dossier - démarre R dans le bon dossier, et utilise des chemins relatifs dans le script. Concrètement :

• Utilise les projets RStudio. Ouvrir un fichier .Rproj fixe le répertoire de travail au dossier du projet automatiquement, sur n'importe quelle machine. Dans le script, read.csv("data/sales.csv") fonctionne alors pour tous ceux qui ont le projet.
• Lancer depuis un terminal fait le même travail : Rscript analysis.R utilise comme répertoire de travail le dossier depuis lequel tu le lances (voir lancer des scripts R).
• Le package here va un cran plus loin pour ceux qui le veulent - here::here("data", "sales.csv") construit les chemins à partir de la racine du projet quoi qu'il arrive au répertoire de travail - mais les projets plus les chemins relatifs couvrent l'essentiel des besoins sans lui.

setwd() en soi n'est pas diabolique - il convient très bien en interactif, quand on explore. Ce qui sent mauvais, c'est précisément un setwd() absolu, spécifique à une machine, versionné en tête d'un script partagé.

L'espace de travail : ls() et rm()

À côté du « dans quel dossier suis-je » se trouve le second morceau d'état de session : l'espace de travail (l'environnement global) - tous les objets que tu as créés cette session. ls() les liste, rm() les supprime :

x <- 10
y <- "hello"
print(ls())

rm(x)             # remove one object
print(ls())

rm(list = ls())   # remove everything: the "clear environment" idiom
print(ls())

Le dernier ls() affiche character(0) - un espace de travail vide. L'incantation rm(list = ls()) paraît étrange jusqu'à ce que tu la décomposes : ls() renvoie le vecteur de caractères de tous les noms d'objets, et rm(list = ...) efface chaque nom de ce vecteur. C'est l'équivalent en code de l'icône balai du panneau Environment de RStudio.

Sache ce qu'elle ne fait pas : les packages chargés avec library() restent chargés, les options restent définies, et le répertoire de travail ne bouge pas. Elle efface les objets, rien d'autre - ce n'est donc pas un substitut au redémarrage de R quand tu veux repartir vraiment de zéro.

Vider la console, et le piège du .RData

Vider la console - l'historique des commandes et de la sortie - est cosmétique et distinct du vidage de l'espace de travail. Dans RStudio c'est Ctrl+L ; en code, le curieux cat("\014") envoie le caractère de saut de page, que la plupart des consoles interprètent comme « efface l'écran ». Ni l'un ni l'autre ne touche à tes objets.

Enfin, le piège. Quand tu quittes R, il propose « save workspace image ? » - écrire tous tes objets dans un fichier caché .RData qui se recharge silencieusement au prochain démarrage de R dans ce dossier. Refuse, et désactive-le définitivement (RStudio : Tools → Global Options → décoche « Restore .RData », mets « Save workspace » sur Never). Un espace de travail restauré signifie que ta session démarre polluée par des objets d'il y a plusieurs jours, créés par du code que tu as peut-être modifié ou supprimé depuis. Ton script semble fonctionner - parce qu'il s'appuie sur un model_v2 périmé que plus rien dans le fichier ne crée - jusqu'au jour où il tourne sur une machine propre et s'effondre.

L'habitude professionnelle est l'inverse : démarre propre, et relance le script. Si ton analyse est un script qui s'exécute de haut en bas dans une session neuve, elle est reproductible par construction ; l'espace de travail est une sortie jetable, jamais un état précieux. Redémarre R souvent (RStudio : Session → Restart R) précisément pour prouver que ton script tient encore debout tout seul.

Ce que tu retiens

• Les chemins relatifs se résolvent par rapport au répertoire de travail ; getwd() le montre, setwd() le change, list.files() montre ce qui est atteignable.
• « Cannot open file » signifie presque toujours que le répertoire de travail et le dossier du fichier divergent - diagnostique avec getwd() + list.files().
• Ne versionne jamais un setwd() absolu dans un script partagé - utilise les projets RStudio (ou lance le script depuis son dossier) et des chemins relatifs.
• ls() liste les objets de l'espace de travail ; rm(x) en supprime un ; rm(list = ls()) les efface tous - les packages et les options restent.
• Ctrl+L (ou cat("\014")) n'efface que le texte de la console.
• N'enregistre/ne restaure pas automatiquement le .RData : démarre propre et relance le script - c'est ce qui rend ton travail reproductible.

Prochaine étape : lire de vraies données - read.csv() et compagnie, maintenant que R regarde dans le bon dossier pour les trouver.