Leçon 2 — La reproductibilité
Le test qui révèle tout
Posez cette question à propos de n'importe quel modèle en production : « pouvez-vous reproduire exactement ce modèle aujourd'hui ? »
La réponse honnête est très souvent non. Et cela signifie qu'on ne peut ni diagnostiquer une dégradation, ni comparer une amélioration, ni expliquer une décision à un auditeur, ni revenir à la version précédente quand la nouvelle échoue.
La reproductibilité n'est pas une élégance d'ingénieur. C'est la condition de tout le reste.
Les quatre éléments à figer
Les quatre sont nécessaires. Il en manque presque toujours un ou deux, et le plus souvent le premier.
1. Les données
Le code se versionne depuis trente ans. Les données, presque jamais, et c'est le principal trou.
« Le jeu de données clients » n'identifie rien. Le même nom de table, interrogé à un mois d'intervalle, ne renvoie pas les mêmes lignes : des enregistrements ont été ajoutés, corrigés, supprimés. Un entraînement lancé sur « la table clients » n'est pas reproductible.
Les approches, du plus simple au plus complet :
Un instantané figé. Copier le jeu d'entraînement dans un stockage immuable, avec une empreinte cryptographique. C'est peu élégant, très efficace, et suffisant pour la plupart des cas.
Le versionnement par outil. Des outils dédiés — DVC, LakeFS, les formats de tables comme Delta ou Iceberg — versionnent les données comme Git versionne le code, avec des références de version et un historique.
La requête horodatée. Si vos données sont dans un entrepôt qui conserve l'historique, enregistrez la requête et l'horodatage utilisés, avec la possibilité de rejouer l'état à cette date.
Ce qu'il faut enregistrer dans tous les cas : la source, la requête ou le filtre, la date d'extraction, le nombre de lignes, et une empreinte du contenu. Ces cinq informations tiennent en une ligne et changent tout.
2. Le code
Plus simple, parce que l'outillage existe, et il reste deux pièges spécifiques au machine learning.
Le premier piège : le notebook. Un notebook n'est pas reproductible par construction. Les cellules peuvent être exécutées dans n'importe quel ordre, et l'état en mémoire ne correspond pas nécessairement au code affiché. Un notebook qui « marche » peut dépendre d'une cellule exécutée puis modifiée. C'est le problème décrit dans le cours Python.
Le notebook est excellent pour explorer. Il ne doit pas être ce qui entraîne le modèle de production. Le passage obligé est l'extraction du code en modules Python versionnés, appelés par un script.
Le second piège : la divergence entraînement-service. Le code qui prépare les données à l'entraînement et celui qui les prépare en production sont souvent deux implémentations distinctes, écrites par deux personnes, qui divergent subtilement. Une normalisation appliquée d'un côté et pas de l'autre suffit à ruiner les prédictions sans lever d'erreur.
La seule solution robuste : une seule implémentation, sous forme de bibliothèque partagée appelée par les deux chemins. Un magasin de variables — feature store — pousse cette logique plus loin en centralisant le calcul et le stockage des variables, garantissant que l'entraînement et le service voient exactement la même chose.
3. L'environnement
Une mise à jour mineure d'une bibliothèque peut changer un résultat : un algorithme par défaut modifié, une valeur par défaut ajustée, une opération numérique réimplémentée.
Le minimum : un fichier de dépendances avec des versions exactes, jamais « la dernière version ». Un fichier qui autorise les mises à jour automatiques rend l'environnement non reproductible par définition.
Le standard raisonnable : un conteneur. L'image fige le système, l'interpréteur, les bibliothèques et les pilotes. Elle est identifiée par une empreinte, et c'est cette empreinte qu'on enregistre avec le modèle.
À ne pas oublier sur GPU : la version des pilotes et des bibliothèques de calcul influe sur les résultats numériques. Sur du deep learning, deux machines avec des pilotes différents ne produisent pas des poids identiques.
4. Les paramètres et le hasard
Les hyperparamètres se notent facilement. Le hasard est plus insidieux, parce qu'il intervient à plusieurs endroits.
Le découpage entre entraînement, validation et test. L'initialisation des poids. L'ordre de mélange des lots. Le dropout, actif à l'entraînement. Certaines augmentations de données.
Fixer les graines de tous les générateurs utilisés — celui de la bibliothèque de calcul, celui du cadriciel d'apprentissage, celui du langage — est indispensable et parfois insuffisant.
Sur GPU, certaines opérations sont non déterministes par conception : l'ordre d'agrégation des calculs parallèles varie, et l'arithmétique à virgule flottante n'est pas associative. Les cadriciels proposent un mode déterministe, souvent plus lent et parfois indisponible pour certaines opérations.
La position pragmatique : viser une reproductibilité statistique — le même protocole donne des résultats équivalents à une variance connue près — et n'exiger le déterminisme strict que lorsque la conformité l'impose. Mais mesurez cette variance : si deux entraînements identiques diffèrent de trois points, un gain de deux points ne veut rien dire.
Le suivi des expériences
Un projet réel comporte des centaines d'entraînements. Sans traçabilité, on ne sait plus ce qu'on a essayé, et on refait deux fois la même chose.
Ce qu'un suivi d'expériences enregistre automatiquement pour chaque exécution : les hyperparamètres, les métriques sur chaque jeu, la version du code, la référence du jeu de données, l'environnement, la durée, et les artefacts produits — le modèle, les graphiques, les matrices de confusion.
MLflow est l'outil le plus répandu et il en existe d'autres. Ce qui compte est l'habitude, pas l'outil : dès qu'un projet dépasse quelques dizaines d'exécutions, un suivi devient rentable.
Ce que cela permet concrètement : retrouver la configuration qui avait donné le meilleur résultat il y a trois semaines ; comparer objectivement deux approches ; répondre à « pourquoi ce modèle a-t-il été choisi » six mois plus tard.
Le registre de modèles
Le suivi d'expériences trace la recherche. Le registre gère le cycle de vie de ce qui va en production.
Un registre associe à chaque version de modèle : un numéro de version, un stade — candidat, production, retiré —, un lien vers l'exécution qui l'a produit, les métriques de validation, et qui a approuvé la promotion.
Ce que cela résout, et c'est concret : savoir quelle version tourne réellement en production ; pouvoir revenir en arrière en une commande quand la nouvelle version déçoit ; disposer d'une trace d'approbation exploitable en audit.
Sans registre, la réponse à « quelle version est en production » est souvent « celle du fichier sur le serveur, je crois ». Ce n'est pas tenable.
L'ordre de mise en place
Tout n'est pas nécessaire dès le premier jour. L'ordre qui donne le meilleur rendement :
- Figer les données avec une empreinte. Effort minimal, gain maximal.
- Sortir le code du notebook vers des modules versionnés.
- Une seule implémentation de la préparation des données, partagée avec la production.
- Fixer les graines et mesurer la variance entre exécutions identiques.
- Conteneuriser l'environnement d'entraînement.
- Suivre les expériences dès que le nombre d'essais devient ingérable.
- Un registre de modèles quand vous avez plusieurs versions ou plusieurs modèles.
Les étapes 1 à 3 couvrent la majeure partie du risque et se font en quelques jours.
À retenir
- Un modèle reproductible exige quatre éléments figés : données, code, environnement, paramètres.
- Le versionnement des données est le trou le plus fréquent : enregistrez source, requête, date, volume et empreinte.
- Un notebook n'est pas reproductible ; il explore, il n'entraîne pas le modèle de production.
- La divergence entraînement-service se règle par une seule implémentation partagée, ou un magasin de variables.
- Figez les versions exactes des bibliothèques, et de préférence dans un conteneur.
- Le déterminisme strict sur GPU coûte cher ; visez une reproductibilité statistique et mesurez la variance.
- Le suivi d'expériences trace la recherche, le registre de modèles gère ce qui va en production et permet le retour arrière.
Leçon suivante — Le déploiement : lots, temps réel, embarqué →