Jane Street, l’une des entreprises de trading quantitatif les plus sélectives au monde, a publié il y a quelques semaines un casse-tête d’interprétabilité mécaniste. Ils ont conçu manuellement un réseau neuronal avec environ 2’500 couches linéaires, des poids entiers, et l’ont lancé au public avec une question : quelle fonction calcule ce réseau ?
La réponse : MD5. Un algorithme de hash cryptographique de 1992, entièrement implémenté avec des multiplications de matrices et fonctions ReLU.
L’intérêt ne réside pas tant dans la réponse que dans le chemin suivi par le gagnant pour y arriver. Car ce chemin est, sans exagération, un manuel de dépannage pour systèmes opaques qui va bien au-delà du machine learning.
L’expérience
Le casse-tête n’était pas une boîte noire classique. Les participants recevaient la spécification complète du modèle : toutes les matrices de poids, tous les biais, toute l’architecture. Pas besoin de deviner la structure. Il fallait comprendre ce que faisait le réseau.
Le réseau acceptait une chaîne de texte en entrée et renvoyait 0 ou 1. L’exemple donné : “vegetable dog” retourne 0.
Avec ses ~2’500 couches linéaires, près de 2 millions de nœuds, et aucune documentation, la question était : quel rapport existe entre l’entrée et la sortie ?
Comment cela a été résolu : une étude de cas en debugging
Le gagnant, Alex, a suivi un processus que chaque ingénieur senior reconnaîtra. Ce n’est pas lié aux outils spécifiques employés, mais à la structure même du raisonnement.
Phase 1 : Observer avant de toucher
La première chose qu’a faite Alex fut de visualiser les matrices de poids. Il n’a pas exécuté le modèle. Il n’a pas essayé de l’entraîner. Il a simplement examiné les données.
Ce qu’il a vu : tous les poids étaient des entiers. Pas des décimaux, pas des flottants. Des entiers.
C’est un signal énorme. Les réseaux neuronaux entraînés par descente de gradient produisent des poids avec beaucoup de décimales. Des poids entiers indiquent que ce réseau a été conçu manuellement pour un but précis. Ce n’était pas un modèle appris, mais bien un programme déguisé.
C’est là un premier schéma typique du debugging chez un senior : observer la structure des données avant d’interpréter leur contenu. Des logs avec des timestamps espacés exactement toutes les 100ms ne sont pas du trafic réel. Un JSON où tous les champs ont exactement 3 éléments ne vient pas de la production. La forme trahit l’origine.
Phase 2 : Réduire l’espace du problème
Alex a tenté de convertir le réseau en un problème de satisfiabilité (SAT). L’idée : si chaque neurone est une contrainte logique, peut-être qu’un solveur SAT peut trouver des entrées qui produisent une sortie égale à 1.
Le processus de réduction a été méthodique :
- Élimination de 80% des neurones effectuants des opérations identité
- Fusion des nœuds avec un seul input de poids 1
- Colapsage des nœuds avec des vecteurs d’entrée identiques
De 2 millions de nœuds, il est passé à 75’000. Puis à 200’000 variables SAT.
Cela n’a pas fonctionné. Le problème restait intraitable par la force brute.
Voici une leçon fondamentale : réduire correctement un problème et constater qu’il reste difficile apporte de l’information, pas un échec. Si, après avoir éliminé toute la complexité accidentelle, le problème reste difficile, la difficulté est inhérente. Cela donne déjà des indications sur la nature du système. Dans ce cas, cela indiquait que la fonction était probablement irréversible — on ne pouvait pas déduire l’entrée à partir de la sortie.
Phase 3 : Reconnaître le schéma
Alex a remarqué que le réseau comportait 32 blocs computationnels qui se répétaient périodiquement. Trente-deux tours identiques. Une fonction irréversible.
Il a interrogé ChatGPT : “Quels algorithmes cryptographiques utilisent 32 tours ?”
MD5.
C’est le moment “eureka”. Mais regardez ce qui l’a rendu possible : ce n’était pas une intuition aléatoire. Ce fut l’accumulation de trois observations préalables (poids entiers → conception manuelle, irréversibilité → cryptographie, 32 tours → protocole spécifique) qui ont convergé en une hypothèse vérifiable.
Ce schéma — accumuler des restrictions jusqu’à ce que l’espace des possibilités se rétrécisse — est exactement la façon dont un senior diagnostique un bug en production. Ce n’est pas qu’il connaisse la réponse à l’avance. C’est que chaque observation élimine des catégories entières de possibilités jusqu’à ce qu’il n’en reste qu’une seule.
Phase 4 : Le bug
C’est là que l’histoire devient intéressante. Alex a vérifié son hypothèse en calculant le MD5 de diverses entrées et en les comparant à la sortie du réseau. Pour les entrées d’au maximum 32 caractères, les résultats correspondaient parfaitement.
Pour les entrées plus longues, non.
Le réseau avait un bug. Les concepteurs avaient fait une erreur dans la façon de coder la longueur du message — un overflow dans les 7 premières couches divergentes du standard MD5 pour les entrées longues.
Alex a traqué l’erreur couche par couche jusqu’à trouver la divergence exacte.
C’est exemplaire : vérifier l’hypothèse dans les cas limites. Si votre modèle mental dit “c’est du MD5”, il ne suffit pas qu’il fonctionne dans les cas favorables. Il faut le tester avec des longues entrées, des entrées vides, des caractères spéciaux. Et lorsqu’il échoue, la divergence indique précisément où se situe l’erreur.
Phase 5 : Résoudre
Avec la fonction identifiée (MD5 avec un bug connu), Alex a extrait le hash cible des biais de l’avant-dernière couche. Ensuite, il a effectué une force brute avec un dictionnaire : la réponse était deux mots en anglais séparés par un espace.
Ce que cela révèle sur le debugging
Le processus d’Alex n’a rien à voir avec le machine learning. C’est du dépannage pur :
| Phase | Dans le casse-tête | Dans un debugging réel |
|---|---|---|
| Observer la structure | Poids entiers → conception manuelle | Logs uniformes → données synthétiques |
| Réduire le problème | 2M nœuds → 75K → SAT | Trace complète → composant isolé |
| Accumuler des restrictions | Irréversible + 32 tours → cryptographie | Échec seulement en production + uniquement le lundi → tâche cron |
| Vérifier dans les cas limites | Fonctionne <32 chars, échoue >32 → bug d’overflow | Fonctionne avec ASCII, échoue avec UTF-8 → encodage |
| Utiliser l’échec comme piste | L’overflow localise les couches exactes | La stack trace indique l’endroit précis |
La structure est identique. Le domaine change, mais le raisonnement reste le même.
Le méta-raisonnement comme avantage compétitif
Un détail mérite l’attention : Alex a utilisé ChatGPT dans la phase 3. Pas pour résoudre le casse-tête, mais pour élargir son espace de recherche. Il avait les restrictions (irréversible, 32 tours). Il avait besoin d’un catalogue de candidats correspondant à ces restrictions.
C’est important. L’outil n’a pas fait le travail intellectuel difficile — les phases d’observation, de réduction et de formulation des restrictions ont été entièrement humaines. Ce que l’outil a fait, c’est agir comme une mémoire associative externe : “Vu ce que je sais, qu’est-ce qui correspond ?”
Ce schéma va définir le travail senior dans les années à venir. La partie précieuse n’est pas de savoir que MD5 comporte 32 tours. Cela, n’importe qui peut le chercher. La partie précieuse est de savoir qu’il faut chercher “algorithme cryptographique de 32 tours” plutôt que “réseau neuronal avec 2’500 couches”. Formuler la bonne question est la compétence qui ne s’automatise pas.
Interprétabilité : le debugging du futur
Le casse-tête de Jane Street est un exercice d’interprétabilité mécaniste — une discipline qui tente de comprendre ce que calculent les réseaux neuronaux, et non seulement d’évaluer si leurs résultats sont corrects.
Aujourd’hui, c’est un champ de recherche. Dans quelques années, ce sera une nécessité opérationnelle.
À mesure que les systèmes critiques incorporent davantage de modèles de ML — du diagnostic médical aux décisions financières —, la question “Pourquoi le modèle a-t-il produit ce résultat ?” ne sera plus académique. Les régulateurs européens l’exigent déjà (AI Act). Les équipes produit en ont besoin pour dépanner les faux positifs. Les équipes légales en ont besoin pour répondre aux réclamations.
Le profil professionnel qui émerge ici est intéressant : quelqu’un qui combine la pensée d’un ingénieur système (couches, réduction, isolation des composants) avec des notions de ML (architectures, fonctions d’activation, représentations internes). Pas un chercheur ML pur. Un débuggeur de modèles.
Dit simplement : si vous savez diagnostiquer pourquoi un système distribué échoue les lundis entre 3:00 et 3:15, alors vous possédez déjà 80% des compétences nécessaires pour diagnostiquer pourquoi un modèle classifie mal les images avec fond bleu. La discipline mentale est la même. Les outils diffèrent.
Les implications pour un senior aujourd’hui
La tentation, en voyant un casse-tête de ce type, est de penser “c’est pour les chercheurs en ML, pas pour moi”. Mais les compétences nécessaires pour le résoudre sont les mêmes qui distinguent un senior d’un mid-level, quel que soit le domaine :
1. Savoir où regarder. Alex n’a pas essayé d’exécuter le réseau des millions de fois pour mapper les entrées et sorties. Il a regardé les poids. Un senior ne cherche pas le bug dans le code modifié hier — il examine les logs, l’infrastructure, le contexte.
2. Savoir quand changer de stratégie. L’approche SAT n’a pas fonctionné. Alex n’a pas insisté. Il a changé pour la reconnaissance de patterns. Un senior qui passe deux heures sur une hypothèse stérile l’abandonne et passe à une autre.
3. Savoir quoi demander. “Quel algorithme comporte 32 tours et est irréversible ?” est une question précise qui fournit une réponse utile. “Pourquoi mon réseau ne fonctionne pas ?” ne l’est pas. La qualité des questions détermine la qualité des réponses — avec les LLMs comme avec les collègues.
4. Utiliser les échecs comme information. Le bug d’overflow n’était pas un obstacle. C’était la preuve que l’hypothèse était correcte (MD5) et une piste pour localiser la divergence. En production, une erreur 500 intermittente n’est pas un problème — c’est un symptôme qui vous mène au vrai problème.
Conclusion
Jane Street a conçu ce casse-tête comme outil de recrutement. Ils cherchent des personnes capables de combiner disciplines, de penser en couches, de savoir quand la force brute échoue et qu’un autre angle est nécessaire.
Mais ce que cela prouve surtout est bien plus large : les compétences en debugging sont transférables entre domaines. Celui qui sait diagnostiquer un système opaque — en déroulant le fil, en accumulant les restrictions, en testant dans les cas limites — peut diagnostiquer n’importe quel système opaque. Peu importe qu’il s’agisse d’un pipeline de données, d’un cluster Kubernetes, ou d’un réseau neuronal de 2’500 couches.
La vraie question pour un senior n’est pas de savoir si vous devez apprendre le ML. C’est de savoir si votre méthodologie de debugging est suffisamment rigoureuse pour fonctionner dans un nouveau domaine. Car les domaines changent. La méthode, si elle est bonne, reste.
Le puzzle original est disponible sur Hugging Face, et un second défi est ouvert, où les couches du réseau sont désorganisées et il faut les réordonner. Si vous aimez les challenges, l’article complet de Jane Street détaille le processus de résolution.