Installer Python sur Windows n’a rien d’exotique, mais le bon parcours dépend de ce que tu veux faire ensuite: développer en local, automatiser des scripts ou préparer un poste de travail propre pour du backend. Je vais te montrer la méthode que je recommande, comment valider l’installation en quelques commandes, puis comment éviter les pièges classiques autour du PATH, des versions multiples et des environnements virtuels.
Les points essentiels à garder en tête
- Sur Windows 10, Windows 11 ou Server 2022 et plus, je privilégie l’install manager de Python, disponible via le Microsoft Store ou depuis python.org.
- La version du Store et celle téléchargée depuis python.org sont identiques; la différence tient surtout au canal de distribution.
- Sur un PC classique, le choix le plus simple est le paquet 64 bits; ARM64 ne concerne que les machines ARM.
- Après l’installation, je valide toujours avec python --version, py list et python -m pip --version.
- Pour un projet sérieux, je crée un environnement virtuel avec python -m venv .venv.
- Si
pythonouvre le Store ou ne répond pas, le problème vient presque toujours des alias Windows ou du PATH, pas de Python lui-même.
Choisir la bonne méthode avant de télécharger quoi que ce soit
Je fais un tri simple avant toute installation: soit je veux un poste de développement standard, soit je dois composer avec un PC verrouillé, soit je prépare un cas particulier comme l’intégration dans une autre application. Dans le premier cas, l’install manager est le meilleur point de départ. Dans le dernier, le paquet embarqué peut avoir du sens, mais ce n’est pas une option pour apprendre Python ou monter un environnement de dev classique.
| Méthode | Quand je la choisis | Atout principal | Limite |
|---|---|---|---|
| Install manager via le Store ou python.org | Poste Windows moderne, usage dev, scripts, backend | Installation propre, mises à jour intégrées, commandes globales pratiques | Nécessite Windows 10/11 ou Server 2022 et plus |
| Installeur Windows classique depuis python.org | Machine d’entreprise, Store bloqué, besoin de contrôle manuel | Déploiement direct et prévisible | Je dois être plus attentif au PATH et aux alias |
| Paquet embarqué | Intégration dans une application, distribution très ciblée | Environnement minimal | Pas adapté à un usage développeur quotidien |
Si ton poste est contrôlé par une politique d’entreprise, je pars souvent sur le téléchargement direct depuis python.org. Sinon, le Store reste le chemin le plus fluide. Une fois ce choix posé, l’installation elle-même devient très rapide.
Installer Python avec l’install manager
Je privilégie ce chemin parce qu’il simplifie le quotidien: une installation centrale, des commandes globales cohérentes, et moins de bricolage dans le terminal. La documentation officielle de Python place désormais cet outil au centre du workflow Windows, et c’est logique pour un poste de développement moderne.
- Télécharge l’install manager depuis le Microsoft Store ou depuis la page de téléchargements de Python.
- Lance l’installation en gardant les options par défaut, sauf besoin précis de ton équipe ou de ton entreprise.
- Ouvre un terminal et tape
pythonpour démarrer le runtime par défaut. - Si tu dois gérer plusieurs versions, utilise
py listpour voir ce qui est installé etpy list --onlinepour voir ce qui est disponible. - Quand tu veux ajouter une version précise, passe par
py installavec le bon tag ou la bonne version.
Le point important, c’est que la version du Store et celle téléchargée depuis python.org sont identiques. Je choisis donc surtout en fonction du contexte: Store si tout est ouvert, téléchargement direct si le poste est plus strict. Si tu gères plusieurs machines, WinGet peut aussi automatiser le déploiement, mais je ne le considère pas comme le point de départ d’un premier setup.
Vérifier que l’installation répond correctement
Je valide toujours l’installation avec quelques commandes très simples. C’est rapide, et ça évite de découvrir un problème de configuration seulement au moment d’installer les dépendances d’un projet.
| Commande | Ce que je vérifie | Ce que j’attends |
|---|---|---|
python --version |
Que Python est accessible depuis le terminal | Une réponse du type Python 3.14.x ou la branche stable installée |
py list |
Quelles versions sont présentes sur la machine | Une liste claire des runtimes installés |
python -m pip --version |
Que pip est bien lié au bon interpréteur | Une version de pip et le chemin de l’interpréteur |
python -m venv .venv |
Que Python sait créer un environnement local | Un dossier .venv créé sans erreur |
Si python ouvre le Store au lieu de lancer l’interpréteur, je ne pars pas tout de suite du principe que Python est cassé. Dans la majorité des cas, le souci vient des alias d’exécution Windows ou d’un ancien runtime qui prend la main avant le bon exécutable. C’est un problème banal, et il se corrige sans réinstaller tout le système.
Gérer plusieurs versions sans casser tes projets
Dès qu’on fait du web, du backend ou de l’automatisation, on finit presque toujours avec une contrainte simple: la version globale de la machine ne suffit pas à couvrir tous les dépôts. Je préfère donc une règle nette. Une version globale stable pour le travail courant, puis une version explicitement choisie quand un projet l’exige.
Je m’appuie sur py quand je veux être précis
py list me montre ce qui est installé, py list --online ce que je peux ajouter, et py -3.14 ou py -3.13 me permet de lancer une branche précise sans toucher au PATH. Ce réflexe évite beaucoup d’ambiguïtés quand plusieurs runtimes cohabitent sur la même machine.
Lire aussi : Python `pass` - Maîtrisez son usage et évitez les pièges courants
Je fige la version au niveau du projet
Pour un dépôt qui doit rester stable, je documente la version attendue dans le README ou dans la consigne d’installation du projet, puis je m’y tiens dans l’environnement virtuel. Le but n’est pas d’accumuler les installations, mais de rendre le comportement prévisible d’un poste à l’autre. C’est particulièrement utile en équipe, où un backend ou un script d’automatisation doit produire le même résultat partout.
La pièce qui relie tout ça, c’est l’environnement virtuel. Sans lui, on finit vite avec des dépendances qui se mélangent et des symptômes difficiles à relire six mois plus tard.
Travailler avec un environnement virtuel dès le premier projet
Un environnement virtuel isole les dépendances d’un projet. En clair, le requests d’un script, le django d’un backend et les bibliothèques d’un autre dépôt ne se marchent plus dessus. Je le fais systématiquement, même pour un petit test local.
pip est le gestionnaire de paquets de Python; c’est lui qui installe les bibliothèques tierces. Pour éviter les confusions entre plusieurs installations, je préfère presque toujours le lancer via python -m pip.
- Créer l’environnement:
python -m venv .venv - Activer sous PowerShell:
.\.venv\Scripts\Activate.ps1 - Activer dans l’invite de commandes:
.\.venv\Scripts\activate.bat - Installer un paquet:
python -m pip install requests - Vérifier l’état de pip:
python -m pip --version
Je recommande de créer un environnement virtuel par projet, pas un environnement “général” pour toute la machine. C’est la meilleure façon de garder des dépendances nettes, de faciliter les mises à jour et d’éviter les conflits quand un dépôt reste figé sur une version précise. Une fois cette habitude prise, les problèmes Windows deviennent beaucoup moins pénibles à diagnostiquer.
Corriger les blocages les plus fréquents
Les pannes les plus courantes ne viennent pas d’un défaut de Python, mais d’un enchaînement de petites incohérences: un alias Windows encore actif, une vieille installation qui passe avant la bonne, ou un terminal qui n’a pas l’environnement virtuel activé. Je règle d’abord ces points-là avant de chercher plus loin.
| Symptôme | Cause probable | Correction que je fais |
|---|---|---|
python ouvre le Store ou affiche une erreur de commande introuvable |
Alias Windows désactivés ou PATH incomplet | Je vérifie les alias d’exécution des applications et la présence de WindowsApps dans le PATH |
py n’est pas reconnu |
Install manager absent, ancien launcher prioritaire ou PATH mal configuré | Je confirme l’installation de l’install manager, puis je rafraîchis les alias si nécessaire |
pip est introuvable |
Environnement virtuel non activé ou exécutable non exposé | J’active .venv, puis j’utilise python -m pip
|
| Une mauvaise version de Python se lance | Plusieurs runtimes cohabitent sur la machine | Je liste les versions avec py list, puis je retire l’installation obsolète ou je lance explicitement la bonne version |
Je traite d’abord les alias et les vieux runtimes; dans la majorité des cas, le problème se règle là, sans réinstaller Python. Quand tout est propre, il ne reste plus qu’à verrouiller une routine simple pour ne plus y penser au quotidien.
Le réglage que je recommande pour un poste Windows durable
Pour un poste orienté web, scripts ou backend, voici le montage que je trouve le plus robuste: install manager pour l’accès global à Python, runtime stable récent, un environnement virtuel par projet, et python -m pip dès qu’il faut installer quelque chose. C’est sobre, prévisible et facile à maintenir.
- Je choisis l’install manager via le Store ou via python.org selon ce que le poste autorise.
- Je garde une version stable récente comme runtime global.
- Je crée un
.venvpour chaque dépôt. - Je vérifie le setup avec
python --versionetpy list. - Je note la version attendue dans le projet quand l’équipe doit rester alignée.
Ce réglage laisse Windows gérer l’accès à Python sans t’obliger à bricoler le PATH à chaque nouveau projet, tout en gardant assez de contrôle quand une base de code doit rester figée sur une version précise. C’est exactement l’équilibre que je cherche quand je veux aller vite sans transformer la machine en champ de bataille de versions.
