Aller au contenu principal

Leçon 4 — scikit-learn

Si vous ne devez retenir qu'une bibliothèque de cette leçon, c'est celle-là. scikit-learn couvre à peu près tout le machine learning classique, et sa vraie contribution n'est pas d'avoir inventé des algorithmes : c'est de les avoir tous mis derrière la même interface.

Ce que « la même interface » veut dire

Avant scikit-learn, chaque implémentation d'algorithme avait sa propre façon de faire. Changer de modèle voulait dire réécrire le code autour, avec des conventions différentes pour les données d'entrée, l'entraînement et la prédiction. Comparer trois approches coûtait trois fois le travail.

scikit-learn a imposé trois verbes, identiques pour tous les modèles :

  • fit — apprends sur ces données d'entraînement.
  • predict — donne-moi une prédiction pour ces nouvelles données.
  • score — dis-moi à quel point tu es bon sur ces données.

Conséquence : passer d'une régression logistique à une forêt aléatoire, ou à un réseau de neurones simple, revient à changer une seule ligne. Le reste du programme ne bouge pas.

Pourquoi c'est plus important qu'il n'y paraît

En machine learning, on ne sait pas à l'avance quel modèle conviendra. La bonne méthode est d'en essayer plusieurs et de les comparer honnêtement. Une bibliothèque qui rend l'essai gratuit change la façon de travailler : vous testez cinq familles de modèles en une demi-heure au lieu d'en défendre une par attachement.

Ce que la bibliothèque contient

Ce n'est pas seulement une collection de modèles. C'est une chaîne de traitement complète.

Les modèles supervisés. Régression linéaire et logistique, arbres de décision, forêts aléatoires, gradient boosting, machines à vecteurs de support, k plus proches voisins, réseaux de neurones simples.

Les modèles non supervisés. Partitionnement avec k-moyennes et DBSCAN, réduction de dimension avec l'analyse en composantes principales, détection d'anomalies.

La préparation. Mise à l'échelle des variables numériques, encodage des variables catégorielles, imputation des valeurs manquantes, construction de variables polynomiales.

L'évaluation. Découpage entraînement/test, validation croisée, métriques de classification et de régression, matrice de confusion, recherche systématique des meilleurs réglages.

Les pipelines. L'objet qui enchaîne préparation et modèle en un seul bloc, et qui est la réponse au piège le plus dangereux du domaine.

Les pipelines, et la fuite de données

C'est la partie de cette leçon qui vous évitera une vraie déconvenue.

Imaginons une préparation banale : vous mettez vos variables numériques à l'échelle, en soustrayant la moyenne et en divisant par l'écart type. Question : cette moyenne, vous la calculez sur quoi ?

Si vous la calculez sur l'ensemble des données avant de découper en entraînement et test, la moyenne contient l'information des lignes de test. Votre modèle a donc vu, indirectement, quelque chose du test pendant son entraînement. Le score de test devient optimiste, parfois de plusieurs points, et la déception arrive en production.

C'est ce qu'on appelle une fuite de données (data leakage). Elle est silencieuse : aucune erreur, aucun avertissement, juste un chiffre trop beau.

Un pipeline règle le problème structurellement. Vous déclarez la suite des étapes — imputer, mettre à l'échelle, entraîner — et scikit-learn garantit que chaque étape apprend ses paramètres sur l'entraînement seul, puis les applique au test. En validation croisée, il refait ce travail correctement à chaque découpage.

Règle non négociable

Toute transformation qui apprend quelque chose des données — une moyenne, un écart type, une liste de catégories, un choix de variables — doit vivre dans le pipeline. Si vous l'appliquez à la main avant le découpage, vous avez très probablement fabriqué une fuite sans le savoir.

Ce que scikit-learn ne fait pas

Connaître les limites évite les mauvais choix.

Pas de deep learning sérieux. Il existe bien un perceptron multicouche, mais il ne tourne pas sur GPU et n'a aucune des briques nécessaires aux réseaux modernes : convolutions, attention, couches récurrentes. Pour des images, du son ou du texte brut, il faut PyTorch ou TensorFlow.

Pas de données qui ne tiennent pas en mémoire. L'hypothèse de base est que vos données tiennent dans la RAM. Au-delà, on passe à des outils distribués comme Spark MLlib, ou à des bibliothèques prévues pour l'apprentissage par lots successifs.

Pas les meilleurs gradient boosting. L'implémentation interne est correcte, mais XGBoost, LightGBM et CatBoost sont plus rapides et plus précis, et sont devenus le standard de fait sur données tabulaires. Bonne nouvelle : les trois respectent l'interface scikit-learn et s'insèrent dans un pipeline comme n'importe quel autre modèle.

Pas de gestion du cycle de vie. Versionner un modèle, le déployer, le surveiller, le réentraîner : rien de tout cela n'est du ressort de la bibliothèque. C'est le domaine du MLOps.

Le réflexe à prendre

Devant un nouveau problème sur données tabulaires, la séquence efficace est presque toujours la même :

  1. Un modèle de référence trivial — prédire la classe majoritaire, ou la moyenne. Il donne le score à battre, et il arrive plus souvent qu'on ne le croit qu'un modèle sophistiqué ne le batte pas.
  2. Une régression logistique ou linéaire dans un pipeline. Rapide, explicable, souvent honorable.
  3. Un gradient boosting (LightGBM ou XGBoost). C'est en général là que se trouve le meilleur résultat.
  4. Ne passer au deep learning que si les données ne sont pas tabulaires, ou si les trois étapes précédentes ont échoué pour une raison que vous savez expliquer.

Cette discipline vous fera gagner des semaines, et elle vous laissera un modèle que vous pouvez justifier devant un auditeur.


En trois phrases

scikit-learn a standardisé le machine learning classique derrière trois verbes — fit, predict, score — ce qui rend le changement de modèle presque gratuit et l'expérimentation honnête. Son objet le plus important est le pipeline, qui garantit que toute transformation apprend ses paramètres sur l'entraînement seul et empêche structurellement les fuites de données. Elle s'arrête au deep learning, aux données qui ne tiennent pas en mémoire et au cycle de vie des modèles, ce qui définit exactement le moment de passer à PyTorch ou au MLOps.


SuiteLeçon 5 : frameworks et environnements →