L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.
Vous travaillez sur deux projets Python : l'un utilise Django 3.2, l'autre Django 4.2. Sans isolation, installer la nouvelle version écraserait l'ancienne et casserait votre premier projet. Les environnements virtuels résolvent ce problème en créant un espace isolé pour chaque projet, avec ses propres versions de packages.
Un environnement virtuel est un dossier contenant une copie de Python et un espace dédié pour les packages. Quand vous l'activez, toutes les commandes pip install n'affectent que cet environnement, votre système reste intact, vos autres projets aussi.
Ce guide vous montre comment créer, utiliser et gérer des environnements virtuels avec venv (l'outil intégré à Python), puis explore les alternatives comme pipenv et uv.
Ce guide couvre tout le cycle de vie des environnements virtuels Python. Chaque section est accompagnée de commandes que vous pouvez exécuter immédiatement.
À la fin de ce guide, vous saurez :
Comprendre le problème des conflits de dépendances et pourquoi l'isolation est nécessaire
Créer un environnement virtuel avec venv en une commande
Activer et désactiver l'environnement selon votre système d'exploitation
Installer des packages de manière isolée avec pip
Gérer les dépendances avec requirements.txt pour des environnements reproductibles
Choisir la bonne alternative entre venv, virtualenv, pipenv et uv
Avec un environnement virtuel, chaque projet a son propre espace :
Avec des environnements virtuels, chaque projet a son propre dossier .venv : Django 3.2 et Python 3.9 pour A, Django 4.2 et Python 3.11 pour B, Flask 2.3, SQLAlchemy 2.0 et Python 3.10 pour C, sans conflit.Projet AProjet BProjet C.venv/.venv/.venv/Django==3.2requests==2.25Python 3.9Django==4.2requests==2.31Python 3.11Flask==2.3SQLAlchemy==2.0Python 3.10
Créer l'environnement ne l'active pas automatiquement. L'activation modifie votre terminal pour utiliser le Python de l'environnement au lieu du Python global.
La mise à jour d'un package installe la dernière version disponible sur PyPI compatible avec votre version de Python, sans demander de confirmation. Elle touche aussi les dépendances transitives si la nouvelle version en exige d'autres. Sur un projet dont le requirements.txt est versionné, régénérez ce fichier juste après, sinon votre environnement local et celui de vos collègues divergent silencieusement.
Lisez ce tableau par la colonne Cas d'usage plutôt que par les points forts : ces outils ne se remplacent pas les uns les autres, ils répondent à des contraintes différentes. La ligne conda est à part, c'est le seul de la liste qui installe aussi des bibliothèques système non Python (BLAS, CUDA, GDAL), ce que pip ne sait pas faire. Les quatre autres se limitent aux paquets Python et diffèrent surtout par la vitesse d'installation et par le format de verrouillage des versions.
Plus ancien que venv, dont il est l'ancêtre direct, virtualenv crée les environnements plus vite parce qu'il embarque une copie de pip au lieu de la reconstruire à chaque fois. Attention à une idée reçue tenace : virtualenv ne crée plus d'environnements Python 2 depuis la version 20.22.0 d'avril 2023, et depuis la 21.5.0 de juin 2026 il exige un interpréteur Python 3.9 ou supérieur, aussi bien pour tourner que pour la cible. Si vous devez encore servir du Python 2, il vous faut une ancienne version figée de virtualenv.
Outil moderne écrit en Rust, annoncé par son éditeur Astral comme 10 à 100 fois plus rapide que pip pour l'installation de packages. L'installation ci-dessous récupère l'archive binaire publiée sur GitHub et le fichier d'empreinte associé, puis refuse de continuer si les deux ne concordent pas. La commande sha256sum --check doit répondre OK ; toute autre réponse signifie que l'archive a été altérée ou tronquée, n'extrayez rien dans ce cas.
Fenêtre de terminal
# Installation de uv par archive vérifiée (version testée : 0.11.31)
Certains outils Python sont des CLI globaux (black, flake8, httpie...) que vous voulez utiliser partout, pas dans un projet spécifique.
Problème : les installer avec pip globalement peut créer des conflits.
Solution : pipx installe chaque outil dans son propre environnement isolé, tout en rendant la commande disponible globalement.
Un détail d'installation piège les lecteurs sous Debian 12+, Ubuntu 23.04+ et Fedora récentes : ces distributions marquent leur Python système comme externally managed (fichier /usr/lib/python3.X/EXTERNALLY-MANAGED, défini par la PEP 668), et pip install hors environnement virtuel y échoue avec error: externally-managed-environment. Passez donc par le paquet de la distribution.
Fenêtre de terminal
# Installer pipx (Debian / Ubuntu récents : le paquet système est la voie officielle)
Le script d'activation ne fait qu'une chose : modifier des variables du shell courant, dont PATH et VIRTUAL_ENV. C'est pour cela que la troisième ligne du tableau est trompeuse, un script d'activation lancé comme un programme (./activate au lieu de source) s'exécute dans un sous-shell qui disparaît aussitôt, sans erreur visible et sans effet. Vérifiez donc d'abord comment vous appelez le script avant de soupçonner l'environnement lui-même.
Deux causes couvrent la quasi-totalité des cas. La première est l'usage de sudo, qui remplace votre PATH par le secure_path défini dans /etc/sudoers : sudo pip install ignore donc systématiquement l'environnement actif et écrit dans les paquets système. La seconde est un environnement déplacé ou renommé. Le lanceur .venv/bin/pip est un script dont le shebang contient le chemin absolu de l'interpréteur, figé à la création ; déplacer le dossier du projet rend ce chemin invalide et produit un cannot execute: required file not found. Dans ce cas, recréez l'environnement, il n'est pas réparable. Le contrôle par le chemin complet ci-dessous distingue les deux situations sans dépendre du PATH.
pip check ne s'exécute pas pendant l'installation, il relit après coup les métadonnées des paquets déjà présents et signale les exigences non satisfaites. C'est utile parce que pip install accepte de casser une dépendance existante : il affiche bien une ligne ERROR: pip's dependency resolver does not currently take into account all the packages that are installed, mais termine quand même par Successfully installed et rend le code de retour 0. Un pipeline CI qui se fie au seul code de retour ne voit donc rien. Lancez donc pip check après chaque série d'installations : une sortie No broken requirements found. est le seul résultat acceptable avant de figer un requirements.txt.
Vérifiez que l'essentiel de ce guide est acquis. Les questions portent
uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
6 questions
6 min.
70% requis
Informations
Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
⏱️--:--
0 / 6
Vérification
(0/0)
--:--
0%
0Correctes
0À revoir
0:00Temps
-Niveau
Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Ces quatre gestes forment le cycle complet d'un environnement. Faites-les dans l'ordre sur un dossier vide : si which python renvoie encore le Python système après activation, arrêtez-vous là, tout ce qui suit dans ce guide reposerait sur une activation qui n'a pas pris.
Le point qui fait vraiment la différence est l'avant-dernier. Tant que vous n'avez pas rejoué pip install -r requirements.txt dans un environnement neuf, vous ne savez pas si votre fichier de dépendances est complet ; un paquet installé à la main et oublié dans l'export ne se manifeste qu'au moment où un collègue clone le projet.
Ces quatre points relèvent de l'hygiène du projet plutôt que de son fonctionnement. Le troisième est celui qu'on saute le plus souvent : installer un outil de ligne de commande comme black ou httpie avec pip dans le projet le rend indisponible ailleurs et l'ajoute au requirements.txt alors qu'il ne fait pas partie des dépendances de l'application. pipx sépare les deux usages.