MNIST Express v4 - 1/8 - Pourquoi reconstruire ce projet ?

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

Il existe deux types de projets étudiants.

1. Ceux qu'on fait pour valider une note (ne détournez pas le regard, on l'a tous fait)

2. Ceux qu'on fait pour se challenger et s'améliorer.

La v4 de MNIST Express doit clairement appartenir à la deuxième catégorie.

Le problème avec les projets "démo"

Tout le monde a déjà vu MNIST. (Si vous ne l'avez pas vu, on se donne RDV au deuxième article #teasing)

Le dataset de chiffres manuscrits. Un modèle. Une accuracy. Fin de l'histoire.

C'est le "Hello World" du Machine Learning.

Mais justement : si c'est si basique... pourquoi y revenir ?

Parce que la vraie question n'est pas :

"Est-ce que mon modèle reconnaît des chiffres ?"

La vraie question est :

"Est-ce que je sais construire un projet ML propre, structuré, maintenable, testable et industrialisable ?"

Vous conviendrez que... c'est pas pareil.

MNIST Express v1 -> v3 : le prototype

Les versions précédentes fonctionnaient plutôt bien. J'ai pu expérimenter l'implémentation (ô combien satisfaisante) sur notebook, découvrir l'algorithme k-NN, mesurer une accuracy, construire une petite interface avec Streamlit (mon vieil ami sur mes premiers projets, à jamais dans mon ❤️), le tout en quelques fichiers à peine.

Et ça tournait bien.

Mais "ça marche" ne veut pas dire :

• que l'architecture soit claire

• que les responsabilités soient séparées

• que le tout soit correctement testé (ah bon ? Faut tester ? 👀)

• correctement monitoré

• que les artefacts soient bien gérés

• que le tout soit parfaitement reproductible

• bref, que la vision du projet s'inscrive sur le long terme

Un prototype permet de montrer qu'une idée fonctionne en quelques lignes de code. Reste à construire une version suffisamment sérieuse pour devenir un produit.

Pourquoi tout reconstruire ?

Parce que reconstruire est un exercice en soi, bien différent de la création brute.

Créer, c'est intuitif.

Reconstruire, c'est analytique.

Pour faire un parallèle avec la musique : avoir une idée de mélodie, même bien harmonisée avec une super grille d'accords, ça n'est pas encore composer. Accoucher (dans la douleur) d'une structure couplet/refrain/pont/final à partir de cette idée, c'est ça composer. Et bien en dev, c'est pareil : étonnant, non ?

Quand on reconstruit, on découpe, on formalise, on documente (oui), on anticipe les éventuelles erreurs, bref, on pense "prod".

Plus question que ce repo reste un simple dossier avec un notebook.

A ce jour, la structure a été dessinée, la voici :

app/
artifacts/
docs/
mnist_express/
notebooks/
tests/

Pas mal, non ? Disons que ça fait de suite plus sérieux.

Et surtout :

docs/
	ARCHITECTURE.md
	ROADMAP.md
	SPEC.md
	TEST_PLAN.md

La sacro-sainte documentation, que l'on écrit toujours avec un immense plaisir... C'est malgré tout, je pense, ce qui différencie un projet improvisé d'une démarche d'ingénierie.

La vision long terme

MNIST Express v4, loin d'être un projet isolé, est un terrain d'expérimentation. Dans cette version, nous allons intégrer :

• version brute-force

• version KD-Tree

• version PCA optionnelle

• gestion d'artefacts via joblib

• monitoring minimal

• tests de pré-traitement

• temps d'inférence

L'objectif assumé est de viser le mini-labo d'ingénierie ML (aussi modeste soit-il) plutôt qu'un simple classifieur de plus (ce qui n'aurait pas grand intérêt à mon sens).

Et surtout, sans oublier que le code peut, à tout moment dans le futur... évoluer !

Aujourd'hui : MNIST

Demain : autre dataset

Après-demain : autre modèle.

Pourquoi documenter publiquement ?

Parce qu'un projet invisible n'existe pas.

Cette série de 8 articles aura trois objectifs :

1. Expliquer simplement des concepts techniques à un public... large ;

2. Montrer la progression, pas juste le résultat final (c'est quand même plus intéressant) ;

3. Laisser une trace, professionnelle, de mon parcours d'apprentissage.

Finalement, le raisonnement a peut-être plus de valeur et d'intérêt que le produit fini.

Pourquoi passer par ce projet MNIST

Parce que reconstruire volontairement un projet simple est un choix. On pourrait se jeter à corps perdu dans un modèle plus "complexe", faire du deep learning, empiler des frameworks, et bourriner comme il se doit...

Mais la sophistication technique ne remplace pas la maîtrise.

Enfonçons une porte ouverte : si on ne sait pas structurer un projet simple, on ne saura jamais structurer un projet complexe.

En bref

La v4 de MNIST Express ne doit plus être une démo, mais un exercice de maturité technique : repartir de zéro, volontairement, pour faire mieux.

Documenter chaque décision, expliciter chaque choix, structurer chaque composant.

C'est tout sauf spectaculaire. C'est même un peu moins excitant.

Mais j'ose croire que la qualité de mon travail ne pourra que s'en trouver grandie.

Après cette petite introspection, dans le prochain article nous parlerons du coeur du projet : on parlera de MNIST tout simplement, ce que c'est, pourquoi c'est devenu un standard mondial. On parlera aussi de NumPy, le magicien sans qui rien n'est possible.