Environnements virtuels et dépendances en Python

Un environnement par projet, des versions exactes épinglées — pour que votre code s’exécute de la même façon pour vous, votre CI et la personne suivante, avec le venv et pip de la bibliothèque standard ou le uv plus rapide.

Fini le problème du « ça marche sur ma machine ». Isolez chaque projet Python dans son propre environnement virtuel plutôt que dans l’interpréteur global, installez les paquets avec pip, puis épinglez les versions exactes dans requirements.txt pour que le même code s’exécute de la même façon pour vous, votre CI et la personne suivante — plus la voie rapide moderne avec uv (uv venv, uv add, pyproject.toml et un lockfile). Copiez chaque commande et exécutez-la dans votre terminal.

Date de publication

18 juillet 2026

Modifié

18 juillet 2026

AstucePoints clés
  • Un environnement virtuel par projet — n’installez jamais dans l’interpréteur global. Un environnement virtuel est un dossier privé contenant son propre Python et ses propres paquets, isolé de tout autre projet, si bien que mettre à jour un paquet pour un projet ne peut pas en casser un autre.
  • python -m venv .venv en crée un ; l’activer fait pointer python et pip à l’intérieur. Le module venv est fourni avec Python — rien à installer. Après source .venv/bin/activate, chaque pip install atterrit dans ce projet, pas dans votre Python système.
  • Un simple pip install pandas n’est pas reproductible — épinglez vos dépendances. Capturez les versions exactes avec pip freeze > requirements.txt, et n’importe qui (vous plus tard comme votre CI — intégration continue) recrée le même environnement avec pip install -r requirements.txt.
  • uv est la voie rapide moderne — mêmes concepts, un seul outil, un vrai lockfile. uv venv + uv pip install reproduisent venv et pip ; le workflow de projet (uv add) écrit un pyproject.toml et un uv.lock qui épingle tout l’arbre de dépendances de façon déterministe.
  • Ne validez jamais le dossier de l’environnement — validez la recette. Ajoutez .venv/ à votre .gitignore ; validez plutôt requirements.txt (ou pyproject.toml + uv.lock). L’environnement est jetable ; c’est la recette pour le reconstruire qui compte.

Introduction

Votre script tourne parfaitement. Vous l’envoyez à un collègue et il plante dès la première ligne : ModuleNotFoundError: No module named 'pandas'. Ou pire — il tourne, mais produit des nombres différents, parce qu’il a pandas 1.5 et que vous l’avez conçu avec la 2.2. C’est le problème du « ça marche sur ma machine », et il vient d’une seule habitude : installer les paquets dans l’unique Python partagé qu’utilise chaque projet de votre ordinateur.

La solution est de donner à chaque projet son propre environnement virtuel isolé — un dossier autonome avec son propre interpréteur Python (le programme python qui exécute votre code) et son propre jeu de paquets installés, cloisonné de tout le reste. Installez pandas dans l’environnement d’un projet et aucun autre projet ne le voit. Vous notez ensuite les versions exactes que vous avez utilisées, pour que l’environnement puisse être reconstruit à l’identique n’importe où.

Cette leçon construit cette habitude dans l’ordre où vous l’utiliserez : ce qu’est un environnement virtuel et pourquoi en vouloir un par projet, créer et activer un environnement avec le venv de la bibliothèque standard, y installer des paquets avec pip, et l’étape que tout le monde saute — épingler les versions exactes dans un requirements.txt pour que votre configuration soit reproductible. Puis la voie rapide moderne avec uv, qui fait tout cela avec un seul outil et un vrai lockfile. Tout ici est une commande de terminal : copiez chaque bloc et exécutez-le dans votre propre shell.

Qu’est-ce qu’un environnement virtuel (et pourquoi un par projet)

Par défaut, votre ordinateur possède une seule installation de Python, et chaque pip install dépose les paquets dans son unique répertoire site-packages partagé (le dossier où vivent les paquets installés). C’est le piège : deux projets qui ont besoin de versions différentes du même paquet ne peuvent pas être satisfaits tous les deux, et un seul pip install --upgrade pour le projet A peut casser silencieusement le projet B.

Un environnement virtuel résout cela en créant, par projet, une copie légère qui a son propre interpréteur et son propre site-packages. La documentation officielle de venv le définit comme un répertoire doté « de son propre jeu indépendant de paquets Python installés dans ses répertoires site », isolé de l’installation de base « pour que seuls ceux explicitement installés dans l’environnement virtuel soient disponibles ». Trois propriétés méritent d’être retenues :

  • Isolé — les paquets installés dedans sont invisibles pour les autres environnements et pour votre Python système.
  • Jetable — ce n’est qu’un dossier (nommé par convention .venv) ; supprimez-le et recréez-le à tout moment.
  • Pas pour le contrôle de version — vous ne le validez jamais ; vous validez la liste des paquets et reconstruisez le dossier à partir de là.

La règle qui en découle : un environnement par projet, et n’installez jamais dans l’interpréteur global. Votre Python système reste propre ; chaque projet porte ses propres dépendances.

Créer et activer un environnement avec venv

venv fait partie de la bibliothèque standard, il n’y a donc rien à installer au préalable. Depuis le dossier de votre projet, créez un environnement nommé .venv :

python -m venv .venv

Cette commande crée un dossier .venv/ contenant un interpréteur tout neuf et un site-packages vide. Le créer ne suffit pas — vous devez l’activer, ce qui fait pointer le python et le pip de votre shell vers la copie à l’intérieur de .venv plutôt que vers ceux du système. La commande d’activation dépend de votre système d’exploitation et de votre shell :

# macOS / Linux (bash, zsh)
source .venv/bin/activate

# Windows (PowerShell)
.venv\Scripts\Activate.ps1

# Windows (cmd.exe)
.venv\Scripts\activate.bat

Une fois actif, votre invite affiche (.venv) et python exécute désormais l’interpréteur du projet. Vous pouvez vérifier à tout moment quel interpréteur est actif :

python -c "import sys; print(sys.executable)"

Il affiche un chemin à l’intérieur de votre dossier .venv — la preuve que vous êtes isolé. Quand vous avez terminé, quittez l’environnement avec une seule commande :

deactivate

L’activation compte plus qu’il n’y paraît : si vous la sautez, pip install retourne droit dans l’interpréteur global — l’erreur de débutant la plus courante (voir Problèmes fréquents). Le tableau complet des scripts d’activation multiplateformes figure dans la documentation de venv.

Installer des paquets avec pip — et la faille de reproductibilité

Avec l’environnement actif, installez une dépendance (un paquet dont votre projet a besoin pour fonctionner) avec pip, l’installateur de paquets de Python. Installez un paquet, ou plusieurs :

pip install pandas
pip install pandas matplotlib requests

Tout atterrit dans .venv/, sans toucher aucun autre projet. Jusqu’ici tout va bien — mais il y a une faille cachée. pip install pandas récupère la dernière version disponible le jour où vous l’exécutez, quelle qu’elle soit. Exécutez-le aujourd’hui et vous obtiendrez peut-être pandas 2.2 ; un collègue qui lance la même commande le mois prochain obtient la 2.3, avec un comportement par défaut modifié qui décale vos résultats. La commande n’est pas reproductible — elle ne nomme pas les versions, donc elle ne garantit pas deux fois le même environnement. Le guide de packaging Python parcourt ce même workflow d’installation. Combler cette faille est l’étape suivante.

Épingler les versions exactes dans requirements.txt

Épingler signifie enregistrer la version exacte de chaque paquet installé pour que l’environnement puisse être recréé précisément. pip capture l’état actuel avec pip freeze, qui liste chaque paquet installé à sa version exacte ; redirigez-le vers un fichier — par convention requirements.txt :

pip freeze > requirements.txt

Le fichier obtenu est une liste plate et exacte — un fichier requirements selon la terminologie de pip :

matplotlib==3.9.2
numpy==2.1.1
pandas==2.2.3
requests==2.32.3

Le == est tout l’intérêt : il épingle chaque paquet à une version précise. Validez ce fichier dans votre dépôt, et n’importe qui — un collègue, votre serveur CI, vous plus tard sur un nouvel ordinateur portable — reconstruit l’environnement identique en une seule commande :

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

pip install -r requirements.txt lit le fichier et installe chaque paquet à sa version épinglée. C’est le bénéfice de la reproductibilité : le même code s’exécute désormais avec les mêmes dépendances partout. La grammaire exacte des fichiers requirements (spécificateurs de version, commentaires, hachages) est documentée dans la référence du format de fichier requirements de pip, et pip freeze dans la documentation de pip freeze.

Une réserve à mentionner : pip freeze épingle tout ce que vous avez, y compris les paquets installés incidemment. Sur un projet sérieux, vous passerez à ne lister que vos dépendances directes et à laisser un résolveur épingler le reste — ce qui est exactement ce que uv (ci-après) fait pour vous automatiquement.

La voie rapide moderne : uv

uv est un outil unique et rapide qui gère les environnements virtuels, les installations de paquets et les lockfiles. Il parle les mêmes concepts que vous venez d’apprendre — rien ici ne remplace donc votre modèle mental ; cela le rationalise. (uv est un outil séparé que vous installez une fois, selon le guide d’installation de uv ; pip est fourni avec Python et ne nécessite aucune installation.)

uv comme un venv + pip plus rapide

La voie la plus directe est l’interface compatible pip de uv — un quasi-remplacement direct des commandes ci-dessus, selon le guide des environnements uv :

uv venv                 # create .venv (like python -m venv .venv)
source .venv/bin/activate
uv pip install pandas   # install into it (like pip install pandas)

Même résultat, généralement bien plus vite — uv résout et installe depuis un cache partagé et rapporte des installations 10 à 100× plus rapides que pip dans ses propres benchmarks. Si c’était tout ce qu’il faisait, ce serait une amélioration de vitesse. L’étape la plus importante est son workflow de projet.

Le workflow de projet de uv : pyproject.toml + un lockfile

Au lieu d’un requirements.txt plat, uv gère votre projet via un pyproject.toml (le fichier de projet Python standard) et un lockfile — un fichier qui enregistre la version résolue exacte de votre arbre de dépendances entier, généré automatiquement. Démarrez un projet et ajoutez une dépendance (guide des projets uv) :

uv init myproject       # scaffold a project (pyproject.toml, .python-version)
cd myproject
uv add pandas           # add pandas: updates pyproject.toml AND uv.lock, installs it
                        # (.venv and uv.lock are created lazily on this first uv add)
uv add 'requests==2.32.3'   # add a version-pinned dependency
uv remove pandas        # drop a dependency again

uv add enregistre le paquet parmi les dépendances de votre projet dans pyproject.toml, en suivant la table de dépendances [project] standard définie par PEP 621 :

[project]
name = "myproject"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = [
    "pandas",
    "requests==2.32.3",
]

En même temps, uv écrit un uv.lock — décrit dans le guide des projets uv comme « un lockfile multiplateforme qui contient des informations exactes sur les dépendances de votre projet ». Vous validez uv.lock (mais ne l’éditez jamais à la main) ; c’est ce qui rend les installations reproductibles d’une machine à l’autre. Pour recréer l’environnement exactement, ou pour exécuter votre code dedans, utilisez :

uv sync                 # build .venv to match pyproject.toml + uv.lock exactly
uv run script.py        # run a command in the project env (syncs first if needed)

uv run vérifie que le lockfile est à jour avant chaque exécution, si bien que l’environnement dans lequel votre code s’exécute est toujours celui qui est épinglé — vous activez rarement manuellement. Le pyproject.toml dit de quoi vous dépendez ; le uv.lock dit exactement quelles versions le satisfont. Cette séparation — une liste de dépendances lisible plus un lockfile exact — est la même idée de reproductibilité que requirements.txt, réalisée avec un vrai résolveur.

venv + pip contre uv — lequel choisir

Les deux vous donnent des environnements isolés et reproductibles ; ils diffèrent par l’ergonomie et la vitesse. Ceci est un tableau de référence, pas un verdict — choisissez selon le contexte.

venv + pip uv
Provenance La bibliothèque standard de Python — rien à installer Un outil séparé que vous installez une fois
Créer un environnement python -m venv .venv uv venv
Installer un paquet pip install pandas uv pip install pandas (ou uv add pandas)
Enregistrer les dépendances pip freeze > requirements.txt (manuel, épingle tout) uv.lock, écrit automatiquement (dépendances directes dans pyproject.toml)
Installation reproductible pip install -r requirements.txt uv sync
Lockfile Pas intégré — requirements.txt épingle les versions mais n’est pas un arbre résolu uv.lock — multiplateforme, arbre entièrement résolu
Vitesse Parfaitement correcte Résolution + installation nettement plus rapides (cache partagé)
À choisir quand Vous voulez la base universelle sans installation que tout développeur Python a déjà Vous voulez un travail de projet rapide basé sur un lockfile avec un seul outil

Le résumé honnête : venv + pip est la base universelle — elle est partout, elle ne nécessite aucune installation supplémentaire, et la connaître est non négociable. uv est la voie plus rapide et plus reproductible une fois qu’un projet devient sérieux. Ce ne sont pas tant des rivaux que les mêmes concepts à deux niveaux de finition ; apprenez la base, adoptez uv quand il gagne sa place.

Quand une IA écrit votre configuration

Demandez à un assistant de code d’« installer pandas et lancer cette analyse » et vous obtiendrez souvent un simple pip install pandas — droit dans l’interpréteur qui se trouve être actif, sans épinglage. Ça tourne, donc ça a l’air correct. Mais c’est exactement l’habitude que cette leçon existe pour briser : aucune isolation (cela peut polluer votre Python global ou l’environnement d’un autre projet) et aucun épinglage (rien n’enregistre les versions, donc ce n’est pas reproductible). Le jugement qu’une réponse en une ligne saute est la partie que vous possédez désormais : créez d’abord un environnement, installez-y, et épinglez ce que vous avez installé — python -m venv .venv && source .venv/bin/activate && pip install pandas && pip freeze > requirements.txt, ou uv add pandas. Un extrait généré est un bon point de départ ; c’est vous qui décidez où il installe et comment les versions sont enregistrées. La preuve, c’est de recréer l’environnement à partir de la recette sur une deuxième machine et d’obtenir le même résultat.

🟢 Avec un agent IA

Vous mettez en place un nouveau projet, ou vous essayez de reproduire l’environnement d’un collègue qui refuse de s’installer ? Collez vos lignes pip install ou un requirements.txt cassé et demandez à Prova « transforme ceci en une configuration isolée et épinglée » — ou « convertis mon projet requirements.txt vers uv ». Elle crée l’environnement, épingle les versions, et écrit le requirements.txt ou le pyproject.toml + uv.lock que vous validez — puis vous lancez vous-même la reconstruction et la regardez installer exactement les mêmes versions. Vous ne faites pas confiance à la configuration, vous la reproduisez. The runtime is the judge. Demandez à Prova →

La même idée en R

Vous travaillez dans les deux langages ? R a la même habitude de reproductibilité sous un autre nom. Là où Python isole par projet avec venv et épingle les versions dans requirements.txt (ou uv.lock), R utilise renv : il crée une bibliothèque de paquets locale au projet et enregistre la version exacte de chaque paquet dans un lockfile renv.lock validé, si bien qu’un collègue restaure l’environnement identique avec renv::restore(). Le concept se transpose exactement — isoler par projet, épingler chaque version, valider le lockfile, reconstruire n’importe où. Voir Environnements reproductibles en R avec renv pour le workflow complet, et le pilier Programmation pour les versants R et Python côte à côte.

Problèmes fréquents

Vous avez lancé pip install et le paquet est allé dans votre Python système. Vous avez oublié d’activer (ou de créer) l’environnement d’abord. pip installe dans l’interpréteur actuellement actif, donc si aucun .venv n’est activé, il vise le global. Vérifiez avec python -c "import sys; print(sys.executable)" — le chemin doit être à l’intérieur de votre .venv. Si ce n’est pas le cas, lancez source .venv/bin/activate (en créant d’abord l’environnement avec python -m venv .venv si vous ne l’avez pas fait), puis réinstallez.

Vous avez validé le dossier .venv/ dans git. Ne le faites pas — un environnement virtuel est volumineux, spécifique à la machine, et non portable (il code en dur des chemins et des binaires propres à la plateforme). Ajoutez .venv/ à votre .gitignore et validez plutôt la recette : requirements.txt, ou pyproject.toml + uv.lock. Quiconque clone le dépôt reconstruit l’environnement à partir de cette recette ; personne n’a jamais besoin de votre copie du dossier.

« Ça marche chez moi mais ça casse chez un collègue. » Presque toujours des dépendances non épinglées — votre pip install a attrapé une version, le sien une autre. Épinglez-les : lancez pip freeze > requirements.txt (ou passez à uv, dont le uv.lock épingle tout l’arbre automatiquement), validez le fichier, et faites-lui reconstruire avec pip install -r requirements.txt (ou uv sync). Mêmes versions épinglées, même comportement.

Questions fréquentes

Un environnement virtuel est un dossier isolé et autonome contenant sa propre copie de l’interpréteur Python et son propre jeu de paquets installés, séparé de votre Python système et de tout autre projet. Vous en créez un par projet pour qu’installer ou mettre à jour un paquet pour un projet ne puisse pas en affecter un autre. Ce n’est qu’un répertoire (par convention .venv), il est jetable — vous pouvez le supprimer et le recréer à volonté — et vous ne le validez jamais dans le contrôle de version ; vous validez plutôt la liste des paquets et reconstruisez à partir de là.

Lancez python -m venv .venv dans le dossier de votre projet — le module venv est fourni avec Python, il n’y a donc rien à installer. Cela crée un dossier .venv/. Puis activez-le pour que python et pip pointent à l’intérieur : source .venv/bin/activate sur macOS/Linux, ou .venv\Scripts\Activate.ps1 sous Windows PowerShell. Votre invite affiche (.venv) quand il est actif. Installez des paquets avec pip install, et quittez l’environnement avec deactivate.

venv est l’outil d’environnement intégré à la bibliothèque standard de Python depuis Python 3.3 — c’est celui vers lequel vous vous tournez par défaut, rien à installer. virtualenv est un paquet tiers plus ancien qui précède venv ; il offre quelques fonctionnalités supplémentaires et prend en charge des versions plus anciennes de Python, mais pour la plupart des travaux venv suffit. conda est un autre type d’outil : un gestionnaire de paquets et d’environnements séparé (issu de la distribution Anaconda/Miniconda) qui installe depuis ses propres dépôts et peut aussi gérer des dépendances non-Python, ce qui le rend populaire en science des données et en calcul scientifique. Utilisez venv (ou uv) pour les projets Python standard ; tournez-vous vers conda quand vous avez besoin de son écosystème ou de binaires non-Python complexes.

requirements.txt est un fichier texte qui liste les dépendances de votre projet, une par ligne, généralement épinglées à des versions exactes avec == (par exemple pandas==2.2.3). Vous le générez avec pip freeze > requirements.txt et recréez l’environnement ailleurs avec pip install -r requirements.txt. Le valider dans votre dépôt est ce qui rend votre projet reproductible : quiconque installe à partir de lui obtient les mêmes versions de paquets que vous avez utilisées. C’est l’équivalent, pour pip et venv, de ce que font uv.lock (pour uv) ou renv.lock (pour R).

Les deux fonctionnent, et connaître pip + venv est essentiel — c’est la base universelle fournie avec Python et que tout développeur possède. Tournez-vous vers uv quand vous voulez de la vitesse et une reproductibilité plus forte : il est nettement plus rapide, et son workflow de projet (uv add → pyproject.toml + uv.lock) épingle tout votre arbre de dépendances automatiquement, au lieu de s’appuyer sur un pip freeze manuel. Une bonne valeur par défaut est d’apprendre d’abord venv + pip pour comprendre les concepts, puis d’adopter uv pour les vrais projets. Ils partagent le même modèle — environnements isolés et versions épinglées — donc passer de l’un à l’autre est facile.

Testez vos connaissances

Vous avez un dossier avec un script qui utilise pandas et matplotlib, tous deux installés dans votre Python global. Un collègue n’arrive pas à l’exécuter. Convertissez le projet en une configuration isolée et épinglée qu’il peut reproduire.

Tâche 1. Écrivez la séquence de commandes de terminal qui : crée un environnement virtuel nommé .venv, l’active (macOS/Linux), y installe pandas et matplotlib, et écrit les versions épinglées dans requirements.txt.

Tâche 2. Écrivez la commande unique que votre collègue exécute (après avoir créé et activé son propre .venv) pour installer exactement les mêmes versions.

Tâche 3. En une phrase, nommez le fichier que vous devriez ajouter à .gitignore et le ou les fichiers que vous devriez valider.

L’ordre est toujours créer → activer → installer → freeze. Rappelez-vous que pip vise l’interpréteur actif, donc l’activation doit venir avant les installations. Pour recréer un environnement à partir d’une liste épinglée, pip la lit avec l’option -r. Et ne validez jamais le dossier de l’environnement lui-même — validez la recette.

Tâche 1 — créer, activer, installer, épingler :

python -m venv .venv
source .venv/bin/activate
pip install pandas matplotlib
pip freeze > requirements.txt

Tâche 2 — votre collègue recrée l’environnement exact avec :

pip install -r requirements.txt

Tâche 3 — ajoutez .venv/ à .gitignore (ne validez jamais le dossier de l’environnement) ; validez requirements.txt (la recette pour le reconstruire). Avec uv, la recette équivalente à valider est pyproject.toml + uv.lock.

Vérification rapide. Vous ouvrez un nouveau terminal, lancez aussitôt pip install requests, et cela s’installe dans votre Python système au lieu de votre projet. Qu’avez-vous oublié ?

Vous avez oublié d’activer l’environnement virtuel (source .venv/bin/activate) — un terminal tout neuf démarre sans aucun environnement actif, donc pip vise l’interpréteur global. (Si vous n’aviez pas encore créé l’environnement, lancez d’abord python -m venv .venv, puis activez.) Vérifiez que vous êtes isolé à tout moment avec python -c "import sys; print(sys.executable)" — le chemin doit se trouver à l’intérieur de votre .venv.

Conclusion

Les environnements isolés et épinglés sont ce qui transforme le « ça marche sur ma machine » en « ça marche partout ». L’habitude est modeste et toujours la même : un environnement virtuel par projet (python -m venv .venv, puis activer) pour que les installations ne touchent jamais votre Python global, et des versions épinglées (pip freeze > requirements.txt, reconstruit avec pip install -r requirements.txt) pour que le même code s’exécute avec les mêmes dépendances pour vous, votre CI et la personne suivante. uv vous donne le même modèle avec un outil plus rapide et un vrai lockfile — uv add écrivant un pyproject.toml et un uv.lock validé. Quel que soit celui que vous utilisez, validez la recette, jamais le dossier de l’environnement, et vos projets deviennent reproductibles par défaut.

Leçons connexes

Cette page vous a-t-elle été utile ?

Recevez les nouvelles leçons R & Python par e-mail

Pratique, reproductible, sans spam. Désinscription à tout moment.

Double opt-in. Nous ne partageons jamais votre e-mail.

Partager cette pageXLinkedInRedditHN

Réutilisation

Citation

BibTeX
@online{2026,
  author = {},
  title = {Environnements virtuels et dépendances en Python},
  date = {2026-07-18},
  url = {https://www.datanovia.com/learn/programming/python-tools/virtual-environments-and-dependencies},
  langid = {fr}
}
Veuillez citer ce travail comme suit :
“Environnements virtuels et dépendances en Python.” 2026. July 18. https://www.datanovia.com/learn/programming/python-tools/virtual-environments-and-dependencies.