EVERYTHING IN ITS RIGHT PLACE

Dernière partie d'une série sur la construction d'un morpion imbattable. A ce stade du projet, l'IA fonctionne. Elle est imbattable, elle répond instantanément, elle tourne dans un navigateur sans serveur. Mais il reste une question légitime : est-ce qu'on peut faire mieux ? Et si oui, pourquoi s'en donner la peine sur un jeu aussi simple que le morpion ?

Notre IA est imbattable. Elle explore l'arbre de jeu, élague les branches inutiles, choisit toujours le coup parfait. Techniquement, c'est propre. Mais voilà le problème : personne ne veut jouer dans un terminal. Ou disons : les gens peuvent jouer dans un terminal. Mais ils ne le feront pas. Pas spontanément. Pas avec plaisir. Et si personne ne joue, l'IA la plus brillante du monde n'est qu'un algo qui tourne dans le vide.

Minimax fonctionne. L'IA est imbattable. Tout va bien dans le meilleur des mondes. Sauf que si tu mesures ce qui se passe sous le capot, tu tombes sur un chiffre un peu gênant : sur un plateau vide, minimax visite plus de 500 000 noeuds avant de jouer son premier coup. 500 000 positions analysées. Pour un jeu de morpion. Sur une grille 3x3. C'est le moment où on réalise que "ça marche" et "c'est efficace" sont deux choses très différentes.

Quand tu joues au morpion, tu anticipes peut-être 2 ou 3 coups à l'avance. Un joueur, 4 ou 5. Un machine ? Elle peut simuler tous les coups possibles, jusqu'à la fin de la partie. Chaque branche, chaque scénario, chaque issue. C'est exactement ce que fait Minimax.

Avant même d'imaginer la moindre ligne d'intelligence artificielle, il faut répondre à une question banale en apparence : comment représenter un jeu dans la mémoire d'un ordinateur ? C'est bien simple : on ne peut pas parler d'algorithme sans d'abord répondre à cette question fondamentale.

Le morpion a exactement 9 cases. On est loin des échecs, donc. Un plateau qui tient dans un tableau de 9 entiers. Des règles qu'on explique en 10 secondes. Mais évidemment, quand on ouvre un éditeur de code, rien n'est simple. Version numérique du syndrome de la page blanche (ou du repo vide mais ça claque moins) : Comment représenter le plateau ? Comment détecter une victoire ? Comment générer tous les coups possibles ? Et surtout : comment faire jouer une IA qui ne perde

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.

Dans les anciennes versions, tout se passait dans un notebook. C'est l'endroit idéal pour explorer une idée : on charge des données, on teste un algorithme, on trace quelques graphiques, et on voit si quelque chose d'intéressant se produit. Mais un notebook, ce n'est pas une application. Un notebook sert à répondre à une question simple : Est-ce que cette idée fonctionne ? Une application, elle, doit répondre à une autre question : Que vaut cette idée face à de vrais êtres

Les démos de machine learning mettent souvent la lumière sur le modèle, la prédiction et l'accuracy... on retient moins le travail invisible qui les relit. Et pourtant, dans la plupart des systèmes d'IA, la partie la plus complexe est peut-être moins le modèle que le pipeline qui transforme les données du monde réel en données utilisables.

L'accuracy globale, au final, ce n'est jamais qu'un résumé. Un indicateur. Une note finale. Mais la distribution des erreurs, c'est une carte complète: elle dit où le modèle est fort, où il est faible, quelles confusions sont structurelles, lesquelles sont rares, et surtout : ce qu'il faut améliorer (on est quand même là pour ça). 97% ou 98% ne peut donc pas être un slogan. C'est juste la porte d'entrée trompeuse vers le vrai sujet : les erreurs, et leur forme.

Lien vers l'appli : https://mnist-express.streamlit.app/ Lien vers le repo du projet : https://github.com/vohorgeez/MNIST-Express Dans les articles précédents, nous avons vu deux choses importantes : MNIST, ce sont des images de chiffres converties en vecteurs de 784 dimensions. k-NN fonctionne en comparant des distances dans cet espace gigantesque. Mais ce n'est pas sans poser un vrai problème. Enfilez vos lunettes 784D Une image MNIST, c'est 28x28 pixels. Donc 784 nombres.

k-NN n'est finalement pas si naïf. Il repose sur une idée simple, mais profonde : La similarité est une question de distance. Mais cette idée à des limites : trop de dimensions et les distances deviennent peu informatives ; trop de données et le coût computationnel devient élevé. C'est un algorithme honnête qui ne triche pas : il ne fait que comparer. Et pour ce projet, on ne demande pas mieux !

Au delà du dataset d'images, MNIST est un problème de géométrie en grande dimension. NumPy est l'outil qui permet de transformer des pixels en points dans un espace mathématique. Et c'est seulement une fois qu'on accepte cette transformation mentale — image → vecteur → point dans ℝ⁷⁸⁴ — qu'on commence vraiment à comprendre ce qu'on fait.

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.