Comment installer scikit-learn (toutes les méthodes)

Notre implication dans cette affaire est pratiquement nulle : nous sommes Geonode et nous vendons des proxys, ce qui n'a rien à voir avec l'installation d'une bibliothèque Python. Le seul point commun mérite toutefois une petite mention : si pip install reste bloqué dans un environnement d’entreprise, il s’agit généralement d’un proxy requis par votre réseau et dont pip n’a pas connaissance, et la solution consiste à utiliser pip install --proxy ou les variables d’environnement standard. Ce cas est abordé à la fin. Tout le reste ne nécessite ici ni infrastructure ni achat.

La réponse courte

python -m venv sklearn-env
source sklearn-env/bin/activate          # Windows: sklearn-env\Scripts\activate
pip install -U scikit-learn

Ou avec conda :

conda create -n sklearn-env -c conda-forge scikit-learn
conda activate sklearn-env

La documentation officielle présente les deux méthodes et insiste particulièrement sur l’environnement : « l’environnement virtuel est facultatif mais fortement recommandé, afin d’éviter d’éventuels conflits avec d’autres paquets ».

Elle ajoute un rappel qui prend régulièrement les utilisateurs au dépourvu : « Vous devez toujours penser à activer l’environnement de votre choix avant d’exécuter toute commande Python lorsque vous démarrez une nouvelle session de terminal. » Une grande partie des signalements du type « ça marchait hier » proviennent d’un nouveau terminal sur lequel aucun environnement n’a été activé.

Pourquoi « pip install sklearn » échoue

C'est la question qui revient le plus souvent dans ce domaine, et la réponse tient à une conception délibérée.

« sklearn » est le nom de l'import. « scikit-learn » est le nom du paquet. En tapant le premier dans pip, vous installez un élément de remplacement dont le seul but est de vous en empêcher.

La description de ce placeholder sur PyPI est sans ambiguïté : « paquet sklearn obsolète, utilisez plutôt scikit-learn », avec la recommandation d’« utiliser pip install scikit-learn plutôt que pip install sklearn » et de « remplacer sklearn par scikit-learn dans vos fichiers de dépendances pip ».

La raison de son existence est liée à la chaîne d’approvisionnement, comme l’indique clairement sa documentation :

Le package sklearn sur PyPI a pour but d’empêcher des acteurs malveillants d’utiliser le package sklearn, car sklearn (le nom d’import) et scikit-learn (le nom du projet) sont parfois utilisés de manière interchangeable.

En d’autres termes, les responsables ont revendiqué ce nom prêt à prêter à confusion afin que personne d’autre ne puisse le faire. Compte tenu du nombre de personnes qui le saisissent, c’était une décision judicieuse.

La documentation du paquet mentionne trois cas particuliers qu’il est utile de connaître si vous y êtes confronté :

• «pip install sklearn==1.1.3 indiquera que la version 1.1.3 n’existe pas, ce qui prête à confusion » — le paquet de remplacement ne dispose que de ses propres numéros de version.
• «pip uninstall sklearn ne désinstallera en réalité pas scikit-learn ; vous pourrez toujours exécuter import sklearn par la suite ».
• Le fait d’avoir les deux dans pip list prête à confusion, mais c’est normal si vous les avez installés tous les deux par erreur.

Il existe une solution de secours — définir SKLEARN_ALLOW_DEPRECATED_SKLEARN_PACKAGE_INSTALL=True — qui est décrite comme « un dernier recours ». Si vous en arrivez à l’utiliser, la véritable solution consiste presque toujours à vérifier qu’une de vos dépendances ne mentionne pas sklearn dans ses exigences. Il vaut mieux suivre le conseil donné par l’auteur de cette solution de secours : « identifiez quel paquet utilise sklearn au lieu de scikit-learn et signalez-le à leur système de suivi des bogues ».

Dans vos propres fichiers, écrivez toujours scikit-learn. Dans votre code, écrivez toujours import sklearn. Cette asymétrie est permanente.

Configuration requise

D'après les métadonnées du paquet pour la version actuelle, vérifiées en septembre 2026.

scikit-learn 1.9.0 a été publié le 2 juin 2026 et nécessite Python 3.11 ou une version ultérieure.

Ses dépendances d'exécution :

Deux remarques concernant ce tableau.

narwhals est un ajout relativement récent et n’apparaîtra pas dans l’ancienne documentation ni dans les tutoriels rédigés pour des versions antérieures. Si vous fixez les dépendances manuellement plutôt que de laisser pip les résoudre, c’est celle-ci que vous risquez le plus d’oublier.

Les exigences de Python évoluent. Le tableau des dépendances de la page d’installation reflète la version qu’il documente, et les exigences ont augmenté au fil des dernières versions. Si vous utilisez une version plus ancienne de Python, pip se rabattra sur une version plus ancienne de scikit-learn plutôt que de renvoyer une erreur — ce qui est généralement acceptable et explique parfois l’absence d’une fonctionnalité dont vous avez entendu parler.

Des dépendances facultatives sont déclarées pour les benchmarks, la documentation, les exemples et les tests, ce qui implique l’utilisation de matplotlib, pandas, polars, pyarrow et d’autres bibliothèques. Aucune d’entre elles n’est nécessaire pour utiliser la bibliothèque.

Installation sans environnement virtuel

Il arrive parfois que l'on souhaite réellement effectuer une installation à l'échelle du système, mais un avertissement s'affiche.

La documentation est très claire concernant Linux en particulier : « Sous Linux notamment, il est déconseillé d’installer des paquets pip parallèlement aux paquets gérés par le gestionnaire de paquets de la distribution (apt, dnf, pacman…). »

La raison en est que pip et le gestionnaire de paquets de votre distribution considèrent tous deux que les fichiers du répertoire site-packages de Python sur le système leur appartiennent, et lorsqu’ils sont en désaccord, il en résulte une installation Python qui se comporte de manière étrange, difficile à démêler. Sur les distributions récentes, pip refusera catégoriquement l’installation en affichant une erreur « environnement géré en externe », ce qui correspond précisément à la mesure prise par l’écosystème de gestion des paquets pour empêcher ce genre de situation.

Si vous rencontrez cette erreur, les options, par ordre de préférence, sont les suivantes : utilisez un environnement virtuel, utilisez pipx pour les outils en ligne de commande, utilisez le paquet python3-sklearn propre à votre distribution s’il en existe un, ou — en sachant ce que vous faites — passez outre avec --break-system-packages, un indicateur nommé ainsi pour vous décourager.

Sous macOS et Windows, la pression est moindre, mais le conseil reste valable. La création d’un environnement virtuel par projet ne prend que dix secondes et permet d’éviter toute une catégorie de problèmes.

Vérification de l'installation

La documentation fournit les commandes nécessaires, et leur exécution ne prend que trente secondes.

python -m pip show scikit-learn    # version and install location
python -m pip freeze              # everything in the environment
python -c "import sklearn; sklearn.show_versions()"

Avec conda :

conda list scikit-learn
conda list

La commande

sklearn.show_versions()

est celle à utiliser pour signaler un problème. Elle affiche la version de scikit-learn, la version et la compilation de Python, ainsi que les versions de la pile numérique sous-jacente — ce qui correspond précisément aux informations que tout responsable de maintenance vous demandera en premier lieu.

Il convient de vérifier l’emplacement d’installation dans pip show

lorsque quelque chose se comporte de manière étrange. S’il pointe vers un emplacement autre que l’environnement dans lequel vous pensez vous trouver, vous avez votre réponse : import sklearn

trouvera la première installation présente dans le chemin d’accès, et ce n’est peut-être pas celle que vous venez d’installer.

conda ou pip

Les deux fonctionnent. Le choix n'a d'importance que si vous les utilisez en parallèle, ce que vous ne devriez pas faire à la légère.

Utilisez conda lorsque vous disposez déjà d’un environnement conda, lorsque vous avez besoin de bibliothèques numériques compilées spécifiques, ou lorsque vous utilisez une plateforme sur laquelle il faudrait sinon compiler à partir du code source. Privilégiez conda-forge comme canal, comme le recommandent les instructions officielles.

Utilisez pip lorsque vous vous trouvez dans un environnement virtuel Python classique, ce qui couvre la plupart des projets. Les paquets « wheels » sont publiés pour les plateformes courantes ; ainsi, aucune compilation n’est nécessaire et l’installation ne prend que quelques secondes.

Ne les mélangez pas dans un même environnement sans y réfléchir. Installer un paquet avec conda puis mettre à jour une dépendance avec pip crée un environnement où les métadonnées de conda ne correspondent plus à la réalité, et les dysfonctionnements qui en résultent sont difficiles à diagnostiquer. Si vous n’avez pas le choix, installez d’abord tout ce que vous pouvez avec conda, puis utilisez pip uniquement pour ce que conda ne propose pas.

Il existe un indice pratique pour savoir dans quel environnement vous vous trouvez : si which python pointe vers un répertoire d’environnement conda, utilisez conda pour cet environnement.

Erreurs courantes après l'installation

ModuleNotFoundError: No module named 'sklearn' après une installation réussie. Il s'agit presque toujours d'un environnement incorrect : un terminal différent, un interpréteur différent ou un noyau de notebook pointant vers un autre emplacement. Vérifiez avec :

import sys; print(sys.executable)

et comparez avec l’environnement dans lequel vous avez effectué l’installation. Dans Jupyter en particulier, le noyau est un choix distinct de l’environnement du terminal, et l’installation dans l’un n’a aucun effet sur l’autre. La commande %pip install scikit-learn à l’intérieur du notebook effectue l’installation dans l’environnement du noyau, ce qui constitue la solution fiable.

ImportError mentionnant NumPy ou une incompatibilité binaire. Il s’agit généralement d’une incompatibilité entre les versions compilées, le plus souvent causée par une mise à jour indépendante de NumPy. La réinstallation simultanée des deux résout le problème :

pip install --force-reinstall --no-cache-dir numpy scipy scikit-learn

Une compilation à partir du code source. Cela signifie qu’aucun fichier wheel ne correspondait à votre plateforme et à votre version de Python — généralement une version très récente de Python avant la publication des fichiers wheel, ou une architecture inhabituelle. Il est plus simple d’attendre quelques semaines ou d’utiliser une version légèrement plus ancienne de Python que d’installer une chaîne d’outils de compilation.

sklearn et scikit-learn sont tous deux présents dans pip list. Vous avez installé le fichier de remplacement à un moment donné. Vous pouvez le supprimer en toute sécurité : pip uninstall sklearn. Comme l’indique la documentation, cela « ne désinstallera en réalité pas scikit-learn ».

Avertissements concernant les threads ou threadpoolctl. scikit-learn l’utilise pour gérer les pools de threads des bibliothèques BLAS sous-jacentes. Définir explicitement OMP_NUM_THREADS résout la plupart de ces problèmes, et cela vaut de toute façon la peine de le faire dans les conteneurs, où une bibliothèque sans contrainte créera sans hésiter un thread par processeur hôte, quelle que soit votre limite de CPU.

Fixer les versions pour garantir la reproductibilité

L'installation ne se fait qu'une seule fois ; le plus difficile est de conserver la même installation le mois suivant, et cela vaut la peine de s'y préparer avant d'en avoir besoin.

Consignez ces versions dans un fichier de dépendances, pas seulement dans votre tête. Une simple commande ``pip install scikit-learn`

` aujourd’hui et la même commande dans six mois vous donneront des versions différentes, et l’API de scikit-learn évolue d’une version mineure à l’autre : les estimateurs gagnent des paramètres, les valeurs par défaut changent, et parfois certains éléments sont supprimés après un cycle de dépréciation :

scikit-learn==1.9.0
numpy==2.3.1
scipy==1.16.0

Fixez également la pile numérique, pas seulement scikit-learn. La plupart des échecs de reproductibilité dans cet écosystème proviennent de modifications apportées à NumPy ou SciPy sous un scikit-learn « épinglé », car les interfaces compilées entre eux sont plus étroites que ne le suggèrent les spécificateurs de version. Épingler le sommet de l’arborescence et laisser le reste flotter est la configuration la plus susceptible de poser problème.

Générez le fichier à partir d’un environnement de travail plutôt que de l’écrire manuellement :

pip freeze > requirements.txt

Cela permet de capturer l’ensemble des dépendances, y compris les dépendances transitives, ce qui est exactement ce qu’il faut pour une application. Pour une bibliothèque que vous publiez, spécifiez plutôt des plages de versions et laissez les utilisateurs les résoudre — une bibliothèque qui fixe des versions exactes se rend impossible à combiner avec quoi que ce soit.

Enregistrez les versions avec vos résultats. Les sorties des modèles dépendent de la version de la bibliothèque, et un modèle enregistré n’est pas portable d’une version à l’autre — le désklearn.show_versions()

d’un estimateur enregistré par une version différente peut générer un avertissement, échouer ou se comporter différemment sans le signaler. Stocker la sortie de l’ à côté de tout modèle persisté transforme un mystère futur en simple recherche.

Et méfiez-vous des modèles « picklés » comme format de stockage. Ils intègrent la structure de classe de la version qui les a créés, ce qui explique pourquoi ils cessent de fonctionner lors des mises à jour, et ils exécutent du code au chargement — ainsi, un fichier « pickle » provenant d’une source non fiable correspond à l’exécution de code arbitraire plutôt qu’à un simple fichier de données. Pour tout ce qui est destiné à durer, privilégiez un format conçu pour l’échange, ou conservez au minimum le code d’entraînement et les données afin de pouvoir reconstruire le modèle.

Installation derrière un proxy d’entreprise

C’est le seul cas où notre sujet est pertinent, et où le symptôme est caractéristique.

Si pip install

se bloque puis expire, au lieu d’afficher rapidement une erreur de résolution de nom, votre réseau nécessite probablement un proxy que pip ne connaît pas.

pip install --proxy http://user:password@proxy.example.com:9000 scikit-learn

Ou via l’environnement, ce qui s’applique également à conda et à la plupart des autres outils :

export https_proxy=http://user:password@proxy.example.com:9000
export http_proxy=http://user:password@proxy.example.com:9000

Deux problèmes surviennent fréquemment dans ce cas.

Les caractères spéciaux dans le mot de passe doivent être encodés en pourcentage. Une URL de proxy contenant @

ou :

divise la chaîne au mauvais endroit, ce qui entraîne un échec d’authentification alors que les identifiants sont corrects.

L’interception TLS empêche la vérification du certificat. Les proxys d’entreprise mettent souvent fin à la connexion TLS, et pip rejette alors le certificat car il a été émis par l’autorité de certification de votre organisation plutôt que par une autorité publique. La solution consiste à indiquer à pip d’utiliser le bundle d’autorités de certification de votre organisation :

pip config set global.cert /path/to/corporate-ca.pem

La solution tentante consiste à utiliser ``--trusted-host pypi.org`

`, qui désactive la vérification pour cet hôte. Comprenez bien ce que cela implique avant de l’utiliser : vous choisissez d’accepter n’importe quel certificat présenté pour le serveur à partir duquel vous téléchargez du code exécutable.

Pour conda, la configuration équivalente se trouve dans ``.condarc`

, sous ``proxy_servers

et ``ssl_verify

`.

Questions fréquentes

Comment installer scikit-learn ?

pip install -U scikit-learn dans un environnement virtuel, ou conda create -n sklearn-env -c conda-forge scikit-learn avec conda. La documentation recommande vivement l'utilisation d'un environnement virtuel pour éviter tout conflit avec d'autres paquets.

Pourquoi l'installation de sklearn via pip échoue-t-elle ?

Parce que « sklearn » est le nom d'importation, et non le nom du paquet. Il existe sur PyPI un paquet factice dont le seul but est de générer une erreur et de vous rediriger — ses responsables ont délibérément choisi ce nom prêt à la confusion afin d'empêcher toute personne malveillante de publier sous ce nom. Installez plutôt scikit-learn.

Quelle est la différence entre sklearn et scikit-learn ?

scikit-learn est le nom du projet et du paquet utilisé avec pip et conda ; sklearn est le nom que vous utilisez dans les instructions « import ». Cette asymétrie est permanente, et c’est la raison pour laquelle le paquet de remplacement existe.

Quelle version de Python est requise pour scikit-learn ?

La version 1.9.0, publiée en juin 2026, nécessite Python 3.11 ou une version ultérieure. Les anciennes versions de scikit-learn prennent en charge des versions plus anciennes de Python, et pip choisira une version compatible plutôt que de renvoyer une erreur — ce qui explique parfois pourquoi une fonctionnalité dont vous avez entendu parler est manquante.

Pourquoi obtiens-je une erreur ModuleNotFoundError après l’installation ?

C’est presque toujours dû à un environnement incorrect. Vérifiez import sys; print(sys.executable) et comparez-le à l’emplacement où vous avez effectué l’installation. Dans Jupyter, l’environnement du noyau est distinct de celui de votre terminal — utilisez %pip install scikit-learn à l’intérieur du notebook pour installer dans le noyau.

Dois-je utiliser pip ou conda ?

Utilisez pip dans un environnement virtuel classique, ce qui convient à la plupart des projets et permet d’installer des wheels précompilés en quelques secondes. Utilisez conda si vous êtes déjà dans un environnement conda ou si vous avez besoin de bibliothèques numériques compilées spécifiques. Évitez de les mélanger dans un même environnement, car les deux gestionnaires de paquets auront une vision divergente de celui-ci.

Comment vérifier quelle version de scikit-learn j’utilise ?

Consultez python -m pip show scikit-learn pour connaître la version et l’emplacement d’installation, ou python -c "import sklearn; sklearn.show_versions()" pour obtenir un rapport complet incluant Python et la pile numérique — c’est ce qu’il faut indiquer lorsque vous signalez un problème.

Comment installer scikit-learn derrière un proxy ?

Utilisez pip install --proxy http://user:pass@host:port scikit-learn, ou définissez http_proxy et https_proxy dans votre environnement afin que conda et les autres outils puissent également les détecter. Encodez les caractères spéciaux du mot de passe en pourcentage et configurez le certificat CA de votre organisation plutôt que de désactiver la vérification.

Conclusion

L'installation en elle-même se résume à une seule commande. La quasi-totalité des difficultés liées à ce sujet provient de deux éléments qui n’ont rien à voir avec le code de scikit-learn lui-même.

Le premier est le nom. « scikit-learn » pour l’installation, « sklearn » pour l’importation, et un paquet de remplacement portant ce nom prêtant à confusion, destiné à vous arrêter et à vous expliquer pourquoi. Ce paquet de remplacement est un petit geste de bonne hygiène de la chaîne logistique, et l’erreur qu’il génère remplit parfaitement son rôle.

Le deuxième élément concerne les environnements. Un grand nombre d’échecs — le module qui disparaît dans un nouveau terminal, le notebook qui ne parvient pas à trouver ce que vous venez d’installer, l’erreur d’importation après une mise à jour sans rapport — relèvent tous d’un même problème d’environnement sous différentes formes. Un environnement virtuel par projet, activé délibérément, permet d’éviter la quasi-totalité de ces problèmes, et la commande print(sys.executable) diagnostique le reste en une seule ligne.

Et si pip se bloque au lieu de renvoyer une erreur, vérifiez votre réseau avant de vous pencher sur Python. Un proxy obligatoire dont pip n’a pas connaissance provoque un délai d’expiration plutôt qu’une erreur, ce qui est une façon déroutante de découvrir les failles de votre propre infrastructure.