Les fondations du Machine Learning

Le machine learning a une réputation intimidante : des maths partout, du jargon, des équations grecques. La vérité, c'est que les idées derrière sont étonnamment intuitives — et que ce sont elles qui comptent vraiment. Une bibliothèque écrira les équations à ta place ; personne n'écrira la compréhension à ta place.

Ce cours est là pour ça : te donner une vraie carte mentale du domaine. À la fin, tu sauras de quoi parlent les gens quand ils disent « modèle », « features », « sur-apprentissage » ou « validation » — et surtout, tu sauras pourquoi ces notions existent. On ne cherche pas à maîtriser les maths, on cherche à comprendre les concepts. Les formules n'apparaîtront que là où elles éclairent quelque chose, jamais pour décorer.

Qu'est-ce que le machine learning, vraiment ?

Programmer des règles, ou apprendre des exemples

Pendant des décennies, programmer voulait dire une seule chose : écrire des règles. Si le client a dépassé son découvert, alors bloquer la carte. Si la température dépasse 80°, alors couper le moteur. L'ordinateur ne fait qu'exécuter, à la lettre, ce qu'un humain a anticipé.

Ça marche très bien — tant qu'on sait écrire les règles. Mais essaie d'écrire les règles qui reconnaissent un chat sur une photo. « Si c'est poilu et que ça a des oreilles pointues… » — sauf que le chien aussi, sauf que le chat peut être de dos, dans le noir, roulé en boule. Tu passerais ta vie à rajouter des exceptions sans jamais couvrir tous les cas. Certaines tâches résistent tout simplement aux règles écrites à la main.

Le machine learning renverse complètement l'approche. Au lieu de donner les règles à la machine, on lui donne des exemples, et on la laisse trouver les règles toute seule.

Tu ne dis pas à l'ordinateur comment reconnaître un chat. Tu lui montres dix mille photos étiquetées « chat » ou « pas chat », et il en déduit lui-même ce qui fait un chat.

C'est exactement comme un enfant : on ne lui récite pas la définition zoologique du chat, on pointe du doigt en disant « ça, c'est un chat » jusqu'à ce qu'il généralise. Le machine learning, c'est apprendre par l'exemple, à l'échelle industrielle.

Schéma : à gauche, l'approche classique (Données + Règles → Réponses) ; à droite, l'approche machine learning (Données + Réponses → Règles)

Pourquoi tout le monde en parle maintenant

L'idée n'est pas neuve — elle date des années 1950. Si elle explose seulement aujourd'hui, c'est que trois ingrédients se sont enfin réunis :

Les données. Apprendre par l'exemple demande des exemples. Or le numérique en produit des montagnes : clics, photos, transactions, capteurs. Le réseau Vélib', par exemple, enregistre l'état de chaque station toutes les quelques minutes — des centaines de milliers de mesures par jour, prêtes à nourrir un modèle.
La puissance de calcul. Entraîner un modèle, c'est répéter des milliards d'opérations. Ce qui demandait des semaines il y a vingt ans tient aujourd'hui en quelques minutes sur une carte graphique.
Les algorithmes. Des décennies de recherche ont produit des méthodes de plus en plus efficaces pour apprendre, jusqu'aux réseaux de neurones profonds qui font les gros titres.

Quand les trois sont là, le machine learning passe de curiosité de laboratoire à technologie qui filtre tes mails, recommande tes films, traduit tes pages et conduit des voitures.

Les trois grandes familles d'apprentissage

Toutes les méthodes de machine learning ne se ressemblent pas. On les range en trois grandes familles, selon le type d'exemples dont on dispose et ce qu'on cherche à faire. Bien identifier dans quelle famille tombe un problème, c'est déjà la moitié du travail.

Schéma : les trois familles côte à côte — supervisé (données étiquetées → prédiction), non supervisé (données brutes → structure), renforcement (agent ↔ environnement → récompense)

L'apprentissage supervisé : prédire une réponse connue

C'est de loin la famille la plus utilisée. On dispose d'exemples étiquetés : pour chacun, on connaît déjà la bonne réponse. Le modèle apprend le lien entre les caractéristiques d'un exemple et sa réponse, pour pouvoir ensuite prédire la réponse sur des cas qu'il n'a jamais vus.

Quelques exemples concrets :

Des milliers de mails déjà marqués « spam » ou « légitime » → prédire si un nouveau mail est un spam.
L'historique des ventes de maisons (surface, quartier, nombre de pièces… et prix) → prédire le prix d'une maison à vendre.
L'état passé d'une station Vélib' (heure, météo, jour de la semaine… et taux de remplissage observé) → prédire si elle aura des vélos disponibles dans une heure.

On parle de supervisé parce que, pendant l'entraînement, on « supervise » le modèle : à chaque exemple, on peut comparer sa prédiction à la vraie réponse et le corriger. C'est l'élève qui s'entraîne avec le corrigé sous les yeux.

L'apprentissage non supervisé : trouver de la structure

Ici, pas d'étiquettes. On donne au modèle un tas de données brutes, sans réponse attendue, et on lui demande d'y trouver une structure par lui-même. Comme on n'a pas de « bonne réponse », l'objectif n'est plus de prédire, mais de découvrir.

Le cas le plus courant est le clustering : regrouper les exemples qui se ressemblent. Une enseigne qui analyse ses clients sans idée préconçue peut découvrir qu'ils se répartissent naturellement en groupes — les acheteurs du week-end, les chasseurs de promotions, les fidèles du quotidien — sans que personne n'ait défini ces catégories à l'avance. Le modèle les fait émerger des données.

C'est l'élève qu'on lâche dans une bibliothèque sans consigne, et qui revient en disant « j'ai remarqué que les livres se rangent assez naturellement en quelques grandes familles ». Personne ne lui avait donné les familles ; il les a trouvées.

L'apprentissage par renforcement : apprendre par essais et erreurs

La troisième famille est la plus différente. Pas d'exemples figés du tout. À la place, un agent évolue dans un environnement, prend des actions, et reçoit des récompenses (ou des pénalités) en retour. Son but : trouver la stratégie qui maximise ses récompenses sur le long terme.

C'est ainsi qu'on apprend à une IA à jouer aux échecs ou à un jeu vidéo, ou à un robot à marcher : il tâtonne, encaisse des échecs, engrange des réussites, et affine peu à peu son comportement. Personne ne lui montre le bon coup ; il le découvre en jouant des milliers de parties.

C'est l'apprentissage par l'expérience, exactement comme on apprend à faire du vélo : pas avec un manuel, mais en tombant, en se rééquilibrant, jusqu'à ce que le bon geste devienne naturel.

Dans la suite de ce cours, on se concentre surtout sur l'apprentissage supervisé : c'est le plus répandu, le plus directement utile, et c'est lui qui est à l'œuvre dans le challenge Vélib'.

Les briques de base

Avant d'aller plus loin, posons le vocabulaire. Trois ou quatre mots reviennent en permanence dans le domaine ; une fois qu'on les a en tête, tout le reste devient lisible.

Données, exemples, features et cible

Tout part d'un jeu de données : le plus souvent, un grand tableau. Chaque ligne est un exemple (une station à un instant donné, une maison, un mail). Chaque colonne est une caractéristique — en machine learning, on dit une feature (ou variable).

Parmi ces colonnes, une joue un rôle spécial en apprentissage supervisé : la cible (ou label) — c'est ce qu'on cherche à prédire. Toutes les autres sont les features qui servent à la prédire.

heure	météo	jour	…	taux de remplissage (cible)
8h	pluie	lundi	…	0,12
14h	soleil	dimanche	…	0,76

Une grande partie du métier consiste justement à construire de bonnes features. Donner à un modèle l'heure brute, c'est bien ; lui signaler « heure de pointe / heure creuse », ou « jour ouvré / week-end », c'est souvent beaucoup mieux. Le modèle ne voit que ce qu'on lui donne : la qualité des features pèse souvent plus lourd que le choix de l'algorithme.

Schéma : anatomie d'un jeu de données — les lignes sont les exemples, les colonnes les features, et une colonne mise en évidence est la cible

Un modèle, c'est une fonction

Quand on dit « entraîner un modèle », voici ce qui se passe vraiment. Un modèle est une fonction : on lui donne les features d'un exemple, elle ressort une prédiction.

prédiction = modèle(features)

Cette fonction a des paramètres — des réglages internes, souvent des nombres, qui déterminent son comportement. Au tout début, ils sont aléatoires : le modèle prédit n'importe quoi. Entraîner, c'est ajuster progressivement ces paramètres pour que les prédictions collent de mieux en mieux aux vraies réponses des exemples.

L'image de la console de mixage marche bien : des dizaines de boutons, qu'on tourne petit à petit jusqu'à ce que le son soit juste. L'apprentissage automatique, c'est ce réglage des boutons — automatisé, et répété des millions de fois.

Entraînement et test : la règle d'or

Voici sans doute l'idée la plus importante de tout le machine learning, et celle que les débutants négligent le plus.

Le but d'un modèle n'est pas d'être bon sur les exemples qu'on lui a montrés. Il est d'être bon sur des cas nouveaux, qu'il n'a jamais vus. On appelle ça la généralisation, et c'est tout l'enjeu.

Pour la mesurer honnêtement, on coupe les données en deux dès le départ :

le jeu d'entraînement, sur lequel le modèle apprend ;
le jeu de test, qu'on garde de côté, caché, et qu'on ne sort qu'à la toute fin pour évaluer.

Pourquoi cette séparation est-elle sacrée ? Parce qu'évaluer un modèle sur ses données d'entraînement, c'est faire passer un examen à un élève en lui donnant exactement les questions qu'il a révisées. Il aura 20/20 — et tu ne sauras toujours pas s'il a compris ou simplement appris par cœur. Le jeu de test, ce sont des questions qu'il n'a jamais vues : la seule façon de savoir s'il a vraiment compris.

Règle d'or : on n'évalue jamais un modèle sur des données qui ont servi à l'entraîner. Toute la crédibilité d'un résultat repose là-dessus.

Le cœur du problème : généraliser

Maintenant qu'on a la règle d'or, on peut nommer l'ennemi numéro un de tout praticien : le modèle qui brille à l'entraînement et s'effondre sur le test.

Sur-apprentissage et sous-apprentissage

Reprenons nos deux élèves.

Le premier apprend tout par cœur. Il a mémorisé chaque exercice du livre, mot pour mot, sans en saisir la logique. Tombe sur un exercice du cours : parfait. Change une virgule à l'énoncé : il est perdu. En machine learning, on appelle ça le sur-apprentissage (overfitting) : le modèle a tellement collé aux données d'entraînement — jusqu'à leurs accidents et leur bruit — qu'il a confondu « mémoriser » et « comprendre ». Excellent à l'entraînement, mauvais sur du nouveau.

Le second élève, lui, n'a pas assez travaillé. Sa compréhension est trop grossière pour quoi que ce soit, connu ou nouveau. C'est le sous-apprentissage (underfitting) : le modèle est trop simpliste pour capter ce qui se passe dans les données. Mauvais partout.

L'art consiste à viser entre les deux : un modèle assez riche pour saisir les vraies tendances, mais pas au point d'épouser le moindre hasard.

Schéma : trois courbes sur les mêmes points — sous-apprentissage (droite trop rigide), bon équilibre (courbe souple qui suit la tendance), sur-apprentissage (courbe tortueuse qui passe par chaque point)

Le compromis biais-variance

Derrière ces deux travers se cache un arbitrage permanent, qu'on appelle le compromis biais-variance. Sans entrer dans les maths, l'intuition tient en deux idées :

Un modèle trop simple a un fort biais : il se trompe de façon systématique parce qu'il n'a pas la souplesse de représenter la réalité. (Notre élève paresseux.)
Un modèle trop complexe a une forte variance : ses prédictions partent dans tous les sens selon les données vues, parce qu'il réagit au moindre détail. (Notre élève perroquet.)

Réduire l'un tend à augmenter l'autre. Tout le métier consiste à trouver le point d'équilibre où l'erreur totale est la plus faible — ni trop rigide, ni trop nerveux.

Comment on lutte, concrètement

Heureusement, on a des leviers contre le sur-apprentissage :

Plus de données. C'est le remède le plus efficace : plus on montre d'exemples variés, plus il est difficile de tricher en mémorisant.
Des modèles plus simples, ou volontairement bridés (on parle de régularisation : décourager le modèle de devenir trop alambiqué).
La validation. Plutôt que d'attendre le test final, on garde un petit morceau d'entraînement de côté — le jeu de validation — pour vérifier en cours de route qu'on ne dérape pas, et régler les choix du modèle sans toucher au test.

Comment sait-on qu'un modèle est bon ?

On a beaucoup parlé de modèles « bons » ou « mauvais ». Mais bon selon quoi ? Il faut un chiffre. Choisir ce chiffre — la métrique — est une décision plus subtile qu'elle n'en a l'air, et s'y tromper conduit à des modèles qui semblent excellents tout en étant inutiles.

Mesurer une erreur

L'idée de base est simple : pour chaque exemple du jeu de test, on compare la prédiction du modèle à la vraie réponse, et on agrège.

Quand on prédit un nombre (un prix, un taux de remplissage), on mesure l'écart. Une métrique classique est l'erreur quadratique moyenne : on prend l'écart entre prédiction et réalité, on l'élève au carré (pour que les grosses erreurs pèsent lourd et que les signes ne s'annulent pas), et on fait la moyenne.

erreur d'un exemple = (prédiction − réalité)²
score = moyenne de ces erreurs sur tout le jeu de test

Plus ce score est bas, mieux c'est. Quand on prédit une catégorie (spam ou non, malade ou non), la première métrique qui vient à l'esprit est la justesse (accuracy) : la proportion de prédictions correctes. Et c'est là qu'un piège célèbre attend les débutants.

Le piège de la justesse

Imagine un test de dépistage pour une maladie qui touche 1 personne sur 1000. Je te propose un modèle d'une précision redoutable : il répond toujours « en bonne santé ». Sa justesse ? 99,9 %. Il a raison 999 fois sur 1000. Et pourtant il est totalement inutile — il ne détecte aucun malade, c'est-à-dire précisément ce qu'on lui demandait.

Le problème, ce sont les classes déséquilibrées : quand une réponse domine massivement, un modèle paresseux qui mise tout sur elle obtient un score flatteur sans rien comprendre.

Ce piège est si fondamental qu'il vaut le coup de le vivre. Sur le challenge Vélib', certaines stations sont disponibles plus de 99 % du temps. Un modèle qui prédirait benoîtement « disponible » à tous les coups y afficherait une justesse écrasante — tout en étant strictement sans valeur. C'est exactement le genre de situation où l'accuracy ment, et où il faut une meilleure mesure.

Au-delà de la justesse

Pour ces cas, on dispose de métriques plus fines. Sans entrer dans le détail, deux idées valent d'être connues :

La précision et le rappel décortiquent les erreurs : parmi les cas que le modèle a signalés, combien étaient justes (précision) ? Et parmi les cas qu'il fallait attraper, combien a-t-il attrapés (rappel) ? On les regarde ensemble, parce qu'il est facile d'exceller sur l'un en sacrifiant l'autre.
Certains modèles ne crachent pas une réponse sèche, mais une probabilité (« 80 % de chances que la station soit disponible »). On évalue alors la qualité de cette confiance : un modèle sûr de lui qui se trompe doit être plus pénalisé qu'un modèle prudent. C'est l'esprit du score de Brier, justement la métrique du challenge Vélib' — il récompense les probabilités à la fois justes et bien calibrées.

La leçon à retenir dépasse les formules : choisir la bonne métrique fait partie du problème. Un modèle n'est jamais « bon » dans l'absolu — il est bon au regard de ce qu'on a décidé de mesurer.

Un tour des grandes familles d'algorithmes

On a parlé de modèles sans dire à quoi ils ressemblent. En voici les grandes familles — un survol assumé : chacune mériterait son propre cours, et plusieurs l'auront. L'objectif ici est juste de savoir les situer.

La régression : prédire un nombre

Quand la cible est une quantité continue — un prix, une température, un taux de remplissage — on parle de régression. Le modèle apprend à produire un nombre aussi proche que possible de la réalité. C'est précisément la nature du challenge Vélib' : prédire une valeur entre 0 et 1.

La classification : prédire une catégorie

Quand la cible est une catégorie — spam ou légitime, chat / chien / oiseau, malade ou sain — on parle de classification. Le modèle apprend à ranger chaque exemple dans la bonne case. C'est la famille du filtrage de mails, du diagnostic, de la reconnaissance d'images.

Le clustering : regrouper sans étiquettes

On l'a rencontré côté non supervisé : sans réponse connue, le modèle regroupe les exemples qui se ressemblent. Utile pour explorer des données, segmenter une clientèle, repérer des comportements inhabituels.

Les réseaux de neurones et le deep learning

Ce sont des modèles très flexibles, vaguement inspirés du cerveau, empilant des couches de calculs simples. Leur force : quand les données sont massives et complexes — images, son, texte — ils apprennent eux-mêmes les bonnes features, là où les méthodes classiques attendent qu'on les leur fournisse. C'est ce qui se cache derrière la reconnaissance d'images, la traduction automatique et les IA génératives. Cette puissance a un prix : beaucoup de données, beaucoup de calcul, et des modèles plus difficiles à interpréter. Sur des problèmes tabulaires de taille modeste, des méthodes plus simples restent souvent les plus malines.

Penser un projet de machine learning

Terminons par le plus important — et c'est là que se joue tout l'esprit de cette plateforme.

Tu auras peut-être remarqué qu'on n'a presque pas parlé de code. C'est volontaire. Aujourd'hui, entraîner un modèle tient en quelques lignes : les bibliothèques font le gros du travail mathématique. La partie difficile, celle qui distingue un projet réussi d'un échec coûteux, n'est pas l'algorithme. C'est tout ce qui l'entoure :

Bien poser la question. Que cherche-t-on vraiment à prédire, et pourquoi ? Une cible mal choisie, et tout le reste s'effondre.
Comprendre les données. D'où viennent-elles, que valent-elles, que cachent-elles ? Un modèle n'est jamais meilleur que les données qui le nourrissent.
Construire les bonnes features. On l'a vu : souvent l'étape la plus rentable.
Choisir la bonne métrique. On l'a vu aussi : s'y tromper, c'est optimiser la mauvaise chose.
Juger le résultat avec honnêteté. Le modèle généralise-t-il vraiment ? Son score veut-il dire quelque chose ? Que se passe-t-il quand il se trompe ?

Schéma : le cycle d'un projet de ML — Question → Données → Features → Modèle → Évaluation → (retour à) Question, en boucle

Remarque que ce cycle n'est pas une ligne droite mais une boucle : on évalue, on apprend, on revient en arrière, on affine. Un bon projet de machine learning est avant tout une suite d'allers-retours bien menés.

C'est exactement la compétence que tu viens développer ici : non pas réciter des algorithmes, mais piloter un projet de bout en bout — poser le problème, interroger les données, choisir la mesure, lire les résultats. Le code, les bibliothèques s'en chargent. Le jugement, c'est toi.

La suite ? Chacune des familles survolées ici — régression, classification, clustering, deep learning — aura son cours dédié. Et le meilleur moyen d'ancrer tout ça reste de se lancer : le challenge Vélib' t'attend, avec ses vraies données, son leaderboard, et son fameux piège de la métrique. Tu as maintenant tout le vocabulaire pour comprendre ce qui s'y joue.