MNIST Express - 8/8 - Ce que le projet m'a appris sur le Machine Learning

Lien vers l'appli : https://mnist-express.streamlit.app/

Lien vers le repo du projet : https://github.com/vohorgeez/MNIST-Express

Ah, ça y est, le dernier article, le bout du tunnel... Et la fin du projet ! Le moment de se retourner et de faire le bilan de ce qu'on a appris...

Un mot d'abord sur MNIST : on le présente souvent comme le "Hello World" du Machine Learning. Et c'est vrai : un dataset simple, des chiffres en noir et blanc, un problème de classification presque scolaire. Commencer par là était une sorte d'évidence cosmique.

Sur le papier, tout semble clair : on entraîne un modèle, on mesure une accuracy, et on passe à autre chose (des trucs plus palpitants par exemple ?).

En construisant MNIST Express, je pensais d'abord suivre ce chemin. Pondre un projet vite fait, histoire de cocher la case "vu" ✅ et basta... Mais en réalité, avec toutes les libs à disposition (coucou scikit-learn) et surtout à l'ère de l'IA et du vibecoding, il y a une différence nette entre "pondre un projet" et comprendre son fonctionnement en profondeur. C'est même la raison d'être de ces articles : comprendre le fonctionnement profond est plus intéressant que juste peupler un portfolio...

Et surtout, ce projet en particulier m'a montré que le Machine Learning, comme tout autre type de projet, devient intéressant - et plus complexe - dès qu'il quitte le notebook.

Un modèle ne voit jamais le monde comme un humain

Dans un dataset comme MNIST, tout est propre:

• les chiffres sont bien centrés

• les dimensions sont fixes (28x28)

• le bruit est contrôlé

Un utilisateur, lui, ne respecte absolument rien de tout ça (et hors de question d'exiger ça de lui).

Il dessine trop petit, trop grand, décalé, mal centré... c'est là que le vrai travail commence.

Avant même de faire une prédiction, il faut transformer ce dessin en quelque chose de comparable au dataset d'entraînement. Dans le projet, cela passe par toute une chaîne de traitement :

• binarisation pour détecter les pixels utiles

• détection de la zone pertinente

• recadrage

• redimensionnement

• recentrage via le centre de masse

Autrement dit, le modèle ne voit jamais le dessin brut : il n'en voit qu'une interprétation (ce n'est finalement pas si différent du travail de traduction d'une langue à une autre).

C'est sans doute la première leçon importante (et qui ramène le ML dans le monde réel) :

en Machine Learning appliqué, le problème n'est pas seulement d'entraîner un modèle, mais de rendre les données comparables.

Une bonne accuracy n'est que la partie émergée de l'iceberg

Inutile de refaire ici notre précédent article sur l'accuracy. Mais c'est vrai qu'il est tentant de s'en tenir à ce chiffre, au début.

Rien de plus simple avec MNIST cependant, puisque ce chiffre est assez facilement très bon.

Mais en creusant un peu, on découvre rapidement :

• que certaines classes sont mieux reconnues que d'autres

• que certaines erreurs reviennent régulièrement

• que des chiffres visuellement proches (comme 8 et 9) posent plus de problèmes

La confusion matrix devient alors plus intéressante que l'accuracy globale. Elle montre où le modèle se trompe, pas seulement à quel point il est "bon".

Et surtout, elle révèle une chose essentielle :

une moyenne flatteuse peut masquer des comportements fragiles.

Dans un contexte réel, ces erreurs localisées comptent souvent plus que la performance globale. Parce que ce sont elles que l'utilisateur va voir.

Optimiser un modèle, ce n'est pas seulement améliorer son score

Un autre piège classique consiste à croire que le progrès en Machine Learning passe uniquement par de meilleurs modèles.

Dans ce projet, j'ai comparé plusieurs stratégies pour k-NN :

• brute force

• KD-Tree

• Ball-Tree

Intuitivement, on pourrait penser que les structures les plus avancées sont les plus efficaces. Et bien, en pratique, il s'avère que dans un espace à 784 dimensions, ce n'est pas le cas.

Le résultat est presque contre-intuitif :

• toutes les méthodes donnent la même accuracy

• la méthode la plus "simple" (brute) est la plus rapide

Autrement dit :

plus complexe ne veut pas dire meilleur

Mais le vrai gain ne vient même pas de là. Il vient du batching d'inférence : plutôt que de prédire un point à la fois, on regroupe les requêtes.

Résultat :

• un débit multiplié

• des performances bien plus adaptées à une application réelle

Une prédiction : juste un chiffre ?

Dans un notebook, une prédiction se résume souvent à une classe. Dans une application, ce n'est pas suffisant. Dans MNIST Express, chaque prédiction s'accompagne :

• d'une probabilité (niveau de confiance)

• un top 3 des classes possibles

• un temps d'inférence

Le modèle ne dit plus seulement "c'est un 7", il préfère dire :

ALORS, je PENSE que c'est un 7, j'en suis sûr à 92%, mais il y a une chance non nulle que ce soit en fait un 1 ou un 9, et dans tous les cas j'ai mis 12 ms à répondre.

Grosso modo.

On passe d'un système qui produit une réponse à un système qui explique et contextualise cette réponse (et en plus, il gagne en prudence, ce qui est toujours appréciable... non ?).

Le Machine Learning réel est aussi un problème d'ingénierie

Enfin, ce projet m'a appris quelque chose de très concret : le Machine Learning ne se résume pas à un modèle. Il faut aussi :

• séparer clairement entraînement (offline) et inférence (online)

• éviter tout 'fit' en production

• versionner les artefacts

• centraliser la configuration

• structurer le code en modules cohérents

• écrire des tests, même sur des comportements flous

L'architecture du projet reflète ces contraintes :

• un module pour le preprocessing

• un module pour l'entraînement

• un module pour l'inférence

• un module pour les métriques

• un module pour le monitoring

Et pourtant, même avec cette architecture, tout n'est pas parfaitement aligné. Certaines décisions sont des compromis et c'est normal.

Un projet réel n'est jamais une implémentation parfaite d'un design théorique, mais plutôt une série d'arbitrages entre propreté, temps et pragmatisme.

Conclusion

Au départ, MNIST Express était un exercice simple : reconnaître des chiffres manuscrits.

Mais au final, ce projet m'en a beaucoup appris (et ce "beaucoup" tient dans 8 articles !).

Il m'a appris que le Machine Learning réel, ce n'est pas :

• seulement un modèle

• ni seulement une métrique

C'est un ensemble de problèmes :

• transformer des données imparfaites

• comprendre ses erreurs

• optimiser les performances

• exposer des résultats compréhensibles

• observer le comportement du système

• structurer correctement le code

In other words :

Le Machine Learning commence vraiment quand on regarde ailleurs que juste le modèle.

Comme quoi, un simple projet sur des chiffres n'aura pas été vain !