Aller au contenu principal

Module 9 — Environnements virtuels, pip et dépendances

« Ça marche sur ma machine » est la phrase la plus coûteuse de la science des données : le notebook qui tournait en janvier casse en juin, le collègue n'arrive pas à reproduire vos chiffres, la mise en production révèle des versions incompatibles. Tout ce module tient dans une discipline simple : un projet = un environnement isolé = un fichier de dépendances versionné.

Le problème : une seule installation Python pour tous les projets​

Sans isolation, chaque pip install modifie l'unique installation partagée par tous vos projets. Le projet A exige pandas 1.x, le nouveau projet B installe pandas 2.x — et le projet A casse rétroactivement, sans avoir changé d'une ligne. Multipliez par les dizaines de dépendances transitives d'un projet de données, et l'installation globale devient un terrain miné où plus personne ne sait quelle version de quoi fait tourner quoi.

La solution : l'environnement virtuel​

Un environnement virtuel est un dossier contenant un interpréteur Python et ses propres paquets, indépendants du reste de la machine. L'outil standard, venv, est inclus dans Python :

# À la racine du projet — une fois
python -m venv .venv

# Activation — à chaque session de travail
source .venv/bin/activate        # macOS / Linux
.venv\Scripts\activate           # Windows

# Le prompt affiche (.venv) : tout pip install atterrit ICI
(.venv) pip install pandas matplotlib seaborn

Une fois activé, python et pip désignent ceux de l'environnement. deactivate en sort. Le dossier .venv/ se recrée en une minute : il ne se versionne pas (une ligne dans .gitignore), contrairement au fichier qui suit.

Dans l'écosystème data, conda joue le même rôle avec un atout historique sur les paquets à composantes compilées, et uv accélère radicalement les installations. Les concepts sont identiques ; venv + pip reste la base universelle à maîtriser d'abord.

requirements.txt : la liste qui rend le projet installable​

# requirements.txt
pandas==2.2.3
numpy==2.1.2
matplotlib==3.9.2
seaborn==0.13.2
jupyter==1.1.1

N'importe qui — dont vous dans six mois — reconstruit alors l'environnement en deux commandes :

python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

Deux écoles pour le produire. pip freeze > requirements.txt capture tout, dépendances transitives comprises : reproductibilité maximale, lisibilité minimale. L'alternative artisanale — n'y écrire à la main que les paquets directement utilisés, épinglés à leur version — reste lisible et suffit à la plupart des projets d'analyse. Les outils modernes (uv, Poetry) réconcilient les deux avec un fichier de contraintes et un fichier de verrouillage ; le principe ne change pas.

Épingler les versions n'est pas de la paranoïa

pandas sans version signifie « la version du jour de l'installation » : deux installations à six mois d'écart divergent, et les mises à jour majeures cassent des API réelles. pandas==2.2.3 garantit l'identique. Pour un projet qui doit durer, notez aussi la version de Python elle-même (dans le README ou un fichier .python-version).

Le kit de reproductibilité complet​

L'environnement n'est qu'une des trois pattes. Un projet réellement reproductible fixe :

  1. Les dépendances — requirements.txt versionné avec le code.
  2. L'aléatoire — toute opération aléatoire reçoit une graine : np.random.default_rng(42), random_state=42 dans scikit-learn, df.sample(n, random_state=42). Sans graine, chaque exécution produit des chiffres différents, et « reproduire le résultat du rapport » devient impossible.
  3. Les données — au minimum : ne jamais écraser les fichiers bruts (un dossier data/brut/ en lecture seule, les transformations écrivent dans data/prepare/), et noter la date et la source d'extraction.
projet/
├── .venv/               # ignoré par git
├── .gitignore           # .venv/, data/
├── requirements.txt     # versionné
├── data/
│   ├── brut/            # intouchable
│   └── prepare/         # regénérable par le code
├── nettoyage.py
└── analyse.ipynb

Le test décisif — mental ou réel : un collègue clone le dépôt, crée l'environnement, lance le code : obtient-il vos chiffres ? Chaque « non » désigne une dépendance cachée : paquet non listé, chemin absolu vers votre bureau, graine absente, fichier modifié à la main.

Ce qu'il faut retenir​

  • Une installation Python partagée entre projets finit toujours en conflit de versions ; l'environnement virtuel isole chaque projet.
  • python -m venv .venv, activation, pip install : trois gestes qui deviennent automatiques ; .venv/ dans le .gitignore.
  • requirements.txt versionné, versions épinglées (==) : le projet se réinstalle en deux commandes, aujourd'hui comme dans deux ans.
  • Reproductibilité complète = dépendances figées + graines aléatoires + données brutes intouchées.
  • Le critère : quelqu'un d'autre peut-il obtenir vos chiffres à partir du dépôt seul ?

Dernier module technique : les notebooks Jupyter — l'outil de travail quotidien, ses forces réelles et le piège de l'état caché.