venv Python ne s’active pas ? 5 correctifs qui fonctionnent vraiment

Un environnement virtuel Python (venv) “qui ne s’active pas” est presque toujours un symptôme, pas la cause. L’activation n’est qu’un mécanisme de confort : elle modifie votre shell pour que python et pip pointent vers l’interpréteur et les paquets du venv. Si l’activation échoue, vous pouvez souvent quand même utiliser le venv en appelant directement son interpréteur, mais il vaut mieux corriger la racine du problème.

Ce tutoriel explique pourquoi l’activation peut échouer et propose 5 correctifs concrets, avec des commandes réelles pour Windows, macOS et Linux. Il inclut aussi des méthodes de diagnostic et des vérifications pour être sûr que vous utilisez le bon Python.

Comprendre ce que fait vraiment “activer” un venv

Avant de corriger, il faut comprendre ce que l’activation fait (et ne fait pas) :

• Elle préfixe votre PATH pour que python et pip résolvent vers le venv.
• Elle définit généralement une variable VIRTUAL_ENV (selon shell/OS).
• Elle change parfois le prompt ((venv) devant votre invite).
• Elle ne lance pas Python et n’installe pas de paquets.
• Elle n’est pas obligatoire : vous pouvez exécuter ./venv/bin/python (Linux/macOS) ou .\venv\Scripts\python.exe (Windows) sans activer.

Vérifier si vous êtes dans le bon Python (diagnostic rapide)

Exécutez ces commandes avant et après activation :

macOS / Linux

which python
python -c "import sys; print(sys.executable)"
python -m pip -V
echo "$VIRTUAL_ENV"

Windows (PowerShell)

Get-Command python
python -c "import sys; print(sys.executable)"
python -m pip -V
echo $env:VIRTUAL_ENV

Windows (CMD)

where python
python -c "import sys; print(sys.executable)"
python -m pip -V
echo %VIRTUAL_ENV%

Si sys.executable pointe vers un Python système (ex: /usr/bin/python ou C:\Users\...\AppData\Local\Microsoft\WindowsApps\python.exe) alors votre venv n’est pas actif.

Pré-requis : créer un venv “propre” (pour repartir sur une base saine)

Si vous suspectez un venv cassé, recréez-le. C’est souvent plus rapide que de le “réparer”.

1) Supprimer le venv existant

• macOS/Linux :

rm -rf venv

• Windows (PowerShell) :

Remove-Item -Recurse -Force .\venv

2) Recréer avec le bon Python

• macOS/Linux :

python3 -m venv venv

• Windows :

py -m venv venv

3) Mettre à jour pip dans le venv (recommandé)

• macOS/Linux :

./venv/bin/python -m pip install --upgrade pip

• Windows :

.\venv\Scripts\python.exe -m pip install --upgrade pip

Ensuite, passez aux correctifs ci-dessous selon votre symptôme.

Correctif 1 — Vous utilisez le mauvais script d’activation (shell/OS)

C’est la cause la plus fréquente : le script d’activation dépend du shell.

Sur macOS / Linux

Bash / Zsh (cas le plus courant)

source venv/bin/activate

Ou équivalent :

. venv/bin/activate

Fish

source venv/bin/activate.fish

Csh / Tcsh

source venv/bin/activate.csh

Indice : si vous tapez venv\Scripts\activate sur macOS/Linux, ça ne peut pas fonctionner (c’est un chemin Windows).

Sur Windows

PowerShell

.\venv\Scripts\Activate.ps1

CMD (Invite de commandes)

venv\Scripts\activate.bat

Git Bash (MINGW64) sur Windows

Git Bash se comporte comme un shell Unix :

source venv/Scripts/activate

Indice : si vous tapez source venv/bin/activate sur Windows “pur” (CMD/PowerShell), ça échoue car source et le chemin bin/ ne s’appliquent pas.

Vérification après activation

• macOS/Linux :

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

• Windows :

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

Vous devez voir un chemin contenant venv/bin/python ou venv\Scripts\python.exe.

Correctif 2 — PowerShell bloque l’exécution des scripts (Execution Policy)

Symptôme typique sur Windows : en PowerShell, vous lancez .\venv\Scripts\Activate.ps1 et vous obtenez un message du type :

• “running scripts is disabled on this system”
• “l’exécution de scripts est désactivée sur ce système”

Pourquoi ça arrive ?

PowerShell applique une politique de sécurité (Execution Policy) qui peut empêcher l’exécution de scripts .ps1, dont fait partie l’activateur du venv.

Solution recommandée (scope utilisateur, non global)

Ouvrez PowerShell en tant qu’utilisateur (pas forcément admin) et exécutez :

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Puis fermez et rouvrez PowerShell, et réessayez :

.\venv\Scripts\Activate.ps1

Alternative : contourner sans changer la policy (moins confortable)

Vous pouvez aussi utiliser directement l’interpréteur du venv sans activer :

.\venv\Scripts\python.exe -m pip install requests
.\venv\Scripts\python.exe main.py

Vérifier la policy actuelle

Get-ExecutionPolicy -List

Bon compromis : RemoteSigned au niveau CurrentUser permet d’exécuter des scripts locaux non signés (comme ceux générés par venv) tout en gardant une barrière pour des scripts téléchargés.

Correctif 3 — Vous n’êtes pas dans le bon dossier (chemins relatifs, projet, VS Code)

Symptôme : “No such file or directory”, “Le chemin d’accès spécifié est introuvable”, ou vous activez “quelque chose” mais ce n’est pas le bon venv.

Pourquoi ça arrive ?

Les commandes d’activation utilisent souvent un chemin relatif (venv/...). Si vous n’êtes pas dans le dossier racine du projet (celui qui contient venv/), l’activation échoue.

Étape 1 : vérifier la présence du dossier venv

• macOS/Linux :

ls -la
ls -la venv

• Windows (PowerShell) :

Get-ChildItem
Get-ChildItem .\venv

Si venv n’apparaît pas, vous n’êtes pas au bon endroit (ou le venv n’existe pas).

Étape 2 : trouver où vous êtes

• macOS/Linux :

pwd

• Windows (PowerShell) :

Get-Location

Étape 3 : activer avec un chemin absolu (pour éliminer le doute)

• macOS/Linux :

source /chemin/absolu/vers/projet/venv/bin/activate

• Windows :

& "C:\chemin\absolu\vers\projet\venv\Scripts\Activate.ps1"

Cas fréquent : VS Code n’utilise pas le bon interpréteur

Même si vous activez dans le terminal, VS Code peut exécuter un autre Python.

1. Afficher l’interpréteur sélectionné :

• Palette de commandes → Python: Select Interpreter

2. Choisir celui qui pointe vers :

• macOS/Linux : .../venv/bin/python
• Windows : ...\venv\Scripts\python.exe

Vérifiez dans le terminal intégré :

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

Si VS Code “revient” à un autre interpréteur, assurez-vous que le dossier venv/ est bien dans le workspace et qu’il n’y a pas de configuration qui force un autre Python (fichiers .vscode/settings.json).

Correctif 4 — Conflit entre plusieurs Python (pyenv, conda, Microsoft Store, alias)

Symptôme : vous activez le venv, mais python continue de pointer vers un autre interpréteur. Ou pip installe “au mauvais endroit”. Ou encore python lance une version inattendue.

Pourquoi ça arrive ?

Votre système peut avoir plusieurs “sources” de Python :

• macOS/Linux : Python système, Homebrew (/opt/homebrew/bin/python3), pyenv, etc.
• Windows : Python.org, Microsoft Store (alias), py launcher, Anaconda/Miniconda.
• Certains shells ont des hash de commandes (ils mémorisent le chemin de python), ce qui peut donner l’impression que le PATH n’a pas changé.

Étape A : identifier quel python est réellement utilisé

macOS/Linux

type -a python
type -a python3
which -a python3
python -c "import sys; print(sys.executable, sys.version)"

Windows (PowerShell)

Get-Command python -All
py -0p
python -c "import sys; print(sys.executable, sys.version)"

• py -0p liste les Pythons installés (Windows) avec leurs chemins.

Étape B : vider le cache de résolution des commandes (shell)

Sur certains shells (bash), après activation, python peut rester “caché” en cache.

• Bash :

hash -r

Puis :

which python

Étape C : désactiver les alias Microsoft Store (Windows)

Sur Windows, python peut pointer vers un stub du Microsoft Store.

1. Ouvrez : Paramètres → Applications → Paramètres avancés des applications → Alias d’exécution d’application
2. Désactivez les alias python.exe et python3.exe si nécessaire.

Ensuite, rouvrez le terminal et retestez :

Get-Command python
python --version

Étape D : attention à conda (si vous l’utilisez)

Si vous êtes dans un environnement conda, activer un venv par-dessus peut créer des comportements confus. Choisissez une stratégie :

• Soit conda uniquement :

conda activate monenv

• Soit venv uniquement (désactivez conda) :

conda deactivate

Puis activez le venv.

Étape E : règle d’or — utiliser python -m pip

Même avec un venv actif, évitez pip tout court. Utilisez :

python -m pip install <package>
python -m pip -V

Cela garantit que pip correspond au python que vous exécutez.

Correctif 5 — Le venv est cassé ou non portable (déplacement de dossier, mise à jour Python)

Symptôme : l’activation fonctionne “à moitié”, ou python dans le venv échoue, ou les chemins internes pointent vers un ancien emplacement. Parfois vous voyez des erreurs liées à pyvenv.cfg, à des chemins introuvables, ou à un python absent.

Pourquoi ça arrive ?

Un venv contient des chemins qui dépendent :

• de l’emplacement du projet
• de l’interpréteur utilisé pour le créer
• parfois de la version de Python

Si vous :

• déplacez le dossier du projet (ex: C:\Users\A\... → D:\Dev\...)
• changez de Python (désinstallation/réinstallation)
• passez d’une architecture à une autre … alors le venv peut devenir incohérent.

Étape 1 : inspecter pyvenv.cfg

Dans le dossier venv/, il y a un fichier pyvenv.cfg.

• macOS/Linux :

cat venv/pyvenv.cfg

• Windows :

type .\venv\pyvenv.cfg

Vous y verrez des infos comme home = ... (chemin vers le Python “base”). Si ce chemin n’existe plus, votre venv est suspect.

Étape 2 : vérifier que l’interpréteur du venv existe

• macOS/Linux :

ls -la venv/bin/python
./venv/bin/python -V

• Windows :

Test-Path .\venv\Scripts\python.exe
.\venv\Scripts\python.exe -V

Si le fichier n’existe pas ou ne s’exécute pas, le venv est à recréer.

Solution fiable : supprimer et recréer

C’est la méthode la plus robuste :

• macOS/Linux :

rm -rf venv
python3 -m venv venv
source venv/bin/activate
python -m pip install --upgrade pip

• Windows :

Remove-Item -Recurse -Force .\venv
py -m venv venv
.\venv\Scripts\Activate.ps1
python -m pip install --upgrade pip

Réinstaller les dépendances

Si vous avez un requirements.txt :

python -m pip install -r requirements.txt

Si vous utilisez pyproject.toml (pip moderne) :

python -m pip install .

Conseil : gardez toujours une liste de dépendances (requirements / lockfile). Un venv est considéré comme jetable : on doit pouvoir le reconstruire rapidement.

Section diagnostic : erreurs courantes et interprétation

Erreur : “activate: No such file or directory”

• Vous êtes sur le mauvais OS (chemin Windows vs Unix), ou pas dans le bon dossier.
• Vérifiez la structure :
  • macOS/Linux : venv/bin/activate
  • Windows : venv\Scripts\Activate.ps1 / activate.bat

Erreur : “Permission denied” (macOS/Linux)

Souvent, vous essayez d’exécuter le script au lieu de le sourcer.

Mauvais :

venv/bin/activate

Bon :

source venv/bin/activate

Erreur : “cannot be loaded because running scripts is disabled” (Windows PowerShell)

C’est le Correctif 2 (Execution Policy).

Le prompt ne change pas, mais le venv semble actif

Le changement de prompt dépend du script et de votre configuration shell. Ne vous fiez pas au prompt : fiez-vous à :

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

pip install installe au mauvais endroit

Utilisez systématiquement :

python -m pip install ...

et vérifiez :

python -m pip -V

Le chemin affiché doit contenir venv.

Méthode “sans activation” (utile en CI, scripts, ou quand l’activation échoue)

Même si l’activation ne marche pas, vous pouvez travailler :

macOS/Linux

./venv/bin/python -m pip install -r requirements.txt
./venv/bin/python app.py

Windows

.\venv\Scripts\python.exe -m pip install -r requirements.txt
.\venv\Scripts\python.exe app.py

Pourquoi c’est utile ?

• En CI/CD, on préfère souvent des chemins explicites.
• Dans des scripts, l’activation dépend du shell (bash vs sh vs pwsh).
• Cela élimine les problèmes de PATH.

Bonnes pratiques pour éviter que le problème revienne

1. Nommer le venv de manière standard : venv/ ou .venv/.
2. Ne pas versionner le venv dans Git :
   • Ajoutez à .gitignore :

     venv/
     .venv/

3. Toujours utiliser python -m pip plutôt que pip.
4. Recréer plutôt que réparer quand le venv est suspect.
5. Documenter la procédure dans un README.md :
   • création
   • activation
   • installation des dépendances
   • commandes de lancement

Exemple minimal de README (extrait) :

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

## Lancer
python app.py

Checklist finale (en 60 secondes)

1. Le dossier venv/ existe-t-il ?
   • ls / Get-ChildItem
2. Utilisez-vous le bon script d’activation pour votre shell ?
   • source venv/bin/activate (Unix)
   • .\venv\Scripts\Activate.ps1 (PowerShell)
3. Sur PowerShell, la policy autorise-t-elle les scripts ?
   • Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
4. Après activation, sys.executable pointe-t-il vers le venv ?
   • python -c "import sys; print(sys.executable)"
5. Si ça reste instable, recréez le venv et réinstallez les dépendances.

Conclusion

Quand venv “ne s’active pas”, la solution dépend presque toujours de l’un de ces 5 points :

1. Script d’activation inadapté au shell/OS
2. PowerShell bloque les scripts (ExecutionPolicy)
3. Mauvais répertoire (chemin relatif vers venv/)
4. Conflits multi-Python (alias, conda, pyenv, cache de shell)
5. venv cassé/non portable (déplacement, changement de Python)

Avec les commandes de diagnostic (sys.executable, python -m pip -V, which/where/Get-Command) vous pouvez confirmer objectivement où pointe votre Python, au lieu de vous fier au prompt.

Si vous me donnez votre OS, votre shell (PowerShell/CMD/bash/zsh), le message d’erreur exact et la sortie de python -c "import sys; print(sys.executable)", je peux vous indiquer précisément lequel de ces correctifs appliquer.