Livrer un projet de machine learning : dépôt, service testé, rapport traçable et documents qu'un comité lit

Ce que « livré » veut dire

Un projet est livré quand des gens qui ne l'ont pas construit peuvent le relancer, l'interroger, comprendre ses choix et décider de s'en servir.

Le rendu part d'un cahier des charges (scope document) validé tôt, par pull request, et tenu à jour de la même façon : la décision que le modèle éclaire, la cible, la métrique, les garde-fous, les données et le plan. Trois modèles sont ensuite comparés selon les règles de l'étape du champion, un naïf, un meilleur et un lourd, avec intervalles de confiance et une règle du champion déposée en issue avant les résultats.

• Un dépôt public où make reproduce, make compare et les tests tournent, avec une intégration continue (continuous integration, CI) au vert et un README qu'une autre équipe a suivi seule.
• Un service et une page web minimale où l'on saisit un cas et où le modèle répond.
• Un rapport de huit pages au plus, et un court jeu de diapositives.
• Les documents du rendu, complets et non à l'état de brouillon.
• Pour chaque membre, une page qui dit ce qu'il a écrit et ce qu'il a vérifié lui-même, et comment.

Retour au sommaire.

Un rapport court où chaque nombre a une source

Le rapport suit un plan imposé pour que rien d'embarrassant ne soit oublié, et chacun de ses nombres se retrouve dans un fichier produit par le code.

Le plan est imposé et identique pour toutes les équipes, ce qui rend les rapports comparables et oblige à écrire les sections qu'on saute volontiers. Une section peut tenir en un paragraphe quand il y a peu à dire, mais aucune ne peut manquer.

La règle qui tient l'ensemble : chaque nombre du rapport cite le fichier et la clé dont il provient, par exemple une entrée de compare.json. Un nombre tapé à la main ne se vérifie pas, et un relecteur le tiendra pour faux jusqu'à preuve du contraire.

Retour au sommaire.

Les documents qu'un comité lit

Des documents courts, chacun avec un seul rôle, permettent à un lecteur qui n'ouvrira jamais le code de décider, de valider et de surveiller le modèle.

• La fiche de modèle (model card) : métriques avec intervalles, seuil, résultats d'équité, et latences mesurées sur une machine nommée.
• La fiche de données (datasheet) : origine, collecte, licence, et surtout ce que les données ne couvrent pas.
• Plan de surveillance : indicateurs de dérive (drift) comme le PSI et la statistique de Kolmogorov-Smirnov, un seuil d'alerte justifié pour chacun, l'action qu'il déclenche, la personne qui agit, et une politique de réentraînement.
• L'analyse d'écart (gap analysis) à l'AI Act : deux pages qui confrontent le dépôt à la documentation technique exigée par l'annexe IV du règlement européen sur l'IA, quand le sujet y tombe, ou un paragraphe qui explique pourquoi il n'y tombe pas.
• Mémo client : une page en euros pour un décideur (section suivante).
• Journal de décisions et annexe IA : des entrées datées jusqu'au dernier commit, et au moins deux propositions d'IA prouvées fausses.

Ici $e_b$ et $a_b$ sont les parts de cas dans la classe $b$ à l'apprentissage et en production. La formule est la partie facile. Un plan de surveillance vaut quelque chose quand il dit, pour chaque indicateur, à partir de quelle valeur il se passe quelque chose et qui décide ; une liste d'indicateurs sans seuil ni responsable est le troisième piège ci-dessous. Pour l'AI Act, lisez le texte consolidé du règlement plutôt que des diapositives, car ses dates d'application ont déjà bougé une fois.

Retour au sommaire.

Le mémo client : une page, en euros

Le mémo s'adresse à quelqu'un qui ne lira pas le rapport et doit répondre oui ou non, il donne donc sur une page la décision, l'argent, les hypothèses et les limites.

La valeur d'un seuil $t$ additionne ce que la décision rapporte sur les vrais positifs et retranche le coût de chaque type d'erreur. Sur le fil rouge, la décision est binaire ; chaque équipe l'adapte à son sujet. Lue au seuil retenu sur l'ensemble de validation et ramenée à un volume annuel, elle donne le nombre que le décideur demande en premier, celui de la courbe de profit (profit curve).

Cinq zones, dans cet ordre

1. La décision demandée. Une phrase : déployer ce score, à ce seuil, sur ce périmètre.
2. Le gain. Ce que le modèle rapporte par an par rapport à l'absence de modèle, lu sur la courbe de profit.
3. Les hypothèses. Coût de chaque erreur, seuil, volume et taux de base, visibles pour que le lecteur voie de quoi dépend le chiffre.
4. La vérification. Le test A/B qui vérifiera la promesse : taille par bras, durée et règle d'arrêt.
5. Les limites. Équité, dérive, fréquence d'abstention du modèle, et ce que les données ne couvrent pas.

Avant de rendre, essayez-le sur un lecteur extérieur au domaine. Le mémo passe quand ce lecteur sait énoncer, en une phrase, la demande et le gain attendu ; sinon, il faut une nouvelle version.

Retour au sommaire.

Un service de prédiction est un contrat, pas un notebook derrière une route

Un service promet ce qu'il accepte, ce qu'il renvoie et en combien de temps, et des tests d'intégration vérifient ces promesses à chaque push.

Le gabarit expose trois routes avec FastAPI, /predict, /health et /model-info, et une page Streamlit ou Gradio se place devant pour les humains. Le contrat d'entrée est un schéma pydantic typé où chaque variable a un type et un domaine, si bien qu'un âge de 250 ans est rejeté avec un message clair avant d'atteindre le modèle. Le déploiement et l'observabilité en général sont traités dans ingénierie des données, SRE et cloud.

Quatre tests d'intégration qui valent la peine

1. Une propriété métier. Sur l'exemple du crédit, le score de défaut ne doit pas baisser quand le retard de paiement augmente, toutes choses égales par ailleurs ; une violation est un bug ou une trouvaille à consigner. C'est un test fondé sur les propriétés (property-based test).
2. Chargé égale entraîné. Le modèle chargé par le service prédit exactement comme le modèle entraîné.
3. Abstention. Quand l'ensemble de prédiction conforme (conformal prediction) est trop large, le service répond qu'il ne sait pas au lieu de deviner.
4. Identité. Les routes de santé et d'information renvoient la version du modèle et l'empreinte des données d'apprentissage.

La latence se mesure, elle ne s'annonce pas : médiane et 95e centile sur mille appels dans le conteneur de développement, écrits dans la fiche de modèle avec la machine qui les a produits. C'est la première question de l'équipe qui hébergera le modèle.

Retour au sommaire.

Quatre pièges qui reviennent, et ce que demande la production

La plupart des rendus ratés échouent sur la traçabilité et la portabilité plutôt que sur la modélisation, et chaque piège a un contrôle peu coûteux qui l'attrape.

Le piège 1 en chiffres : un rapport qui ne décrit pas le dépôt

1. Le rapport dit 0,781. L'AUC a été recopiée à la main depuis une exécution antérieure du modèle.
2. Le dépôt dit 0,774. Relancer la comparaison donne cette valeur dans le fichier de résultats.
3. L'écart vaut 0,007. Il dépasse la tolérance de 0,005 qu'utilise l'intégration continue pour vérifier la stabilité des résultats.
4. La correction. Régénérer les tableaux depuis le fichier de résultats, citer fichier et clé, et comparer les deux avant de rendre.

• Un service qui ne tourne que sur le portable de son auteur, avec un chemin absolu ou un paquet hors du lockfile. Une autre équipe lance la cible de service et ses tests dans le conteneur de développement.
• Un plan de surveillance sans seuil ni responsable. Pour chaque indicateur, une valeur, une action, une personne.
• Un mémo qui cache les limites. On le lit à côté de la section « limites » du rapport.

Dans une banque, un modèle de score ne passe jamais directement d'un notebook à une décision. Le développement produit le code, les tests et le journal. La validation indépendante, une équipe qui n'a pas construit le modèle, relit les données, les fuites et la comparaison, et doit retrouver les nombres. Un comité accepte le modèle avec un seuil, un périmètre et des limites. Le déploiement apporte un contrat d'entrée, une latence et une version traçable, et la surveillance dure des années. Le rendu est une version réduite de ce circuit, et la soutenance orale qui suit est décrite dans la soutenance du projet. En entretien, peu de gens demanderont votre AUC ; ils demanderont comment elle a été validée et ce qui se passe quand la dérive arrive.

Retour au sommaire.

À retenir

1. Un rendu se juge à ce que d'autres peuvent en faire : le relancer, l'interroger, le lire et décider.
2. On garde le gabarit de dépôt des jalons précédents ; une commande par tâche et une intégration continue au vert sont le ticket d'entrée.
3. Chaque nombre du rapport cite le fichier et la clé dont il vient ; un nombre tapé à la main est faux jusqu'à preuve du contraire.
4. Chaque document a un lecteur et un rôle : fiche de modèle, fiche de données, plan de surveillance, écart à l'AI Act, mémo client, journal.
5. Un service est un contrat : entrées typées avec domaines, une propriété métier sous test, abstention en cas de doute, latence mesurée.
6. Un plan de surveillance sans seuils ni responsables, ou un mémo sans limites, n'est pas terminé.

Glossaire

cahier des charges (scope document)

L'énoncé validé de la décision, de la cible, de la métrique, des garde-fous, des données et du plan.

fiche de modèle (model card)

Court document qui énonce usages, métriques, limites, contrôles d'équité et latence d'un modèle.

fiche de données (datasheet)

Document sur l'origine, la collecte, la licence et les angles morts d'un jeu de données.

dérive (drift)

Changement dans le temps des entrées ou de leur lien avec la cible, qui érode la performance.

PSI

Population stability index : mesure de l'écart entre la distribution par classes d'une variable à l'apprentissage et en production.

prédiction conforme (conformal prediction)

Méthode qui renvoie des ensembles de prédiction avec un taux de couverture garanti.

abstention

Le modèle refuse de répondre quand son incertitude est trop grande.

test fondé sur les propriétés (property-based test)

Test qui vérifie qu'une règle tient sur de nombreuses entrées générées.

courbe de profit (profit curve)

Valeur monétaire de la décision en fonction du seuil.

intégration continue (continuous integration, CI)

Tests et contrôles automatiques lancés à chaque push.

analyse d'écart (gap analysis)

Comparaison entre ce qu'exige un règlement et ce que fournit le projet.

Les autres fiches du cours

Un résumé public par deck, dans l'ordre du cours.

Précédent : Réseaux de neurones, dérive, prédiction conformeSuivant : Soutenir un projet de machine learning

1. IntroductionHivers de l'IA, emploi et méthode
2. OutilsKaggle, GitHub, Python : les outils
3. Séance 1Cadrage de projet et moindres carrés
4. Séance 2Vraisemblance et régression logistique
5. Séance 3Descente de gradient, ridge et lasso
6. Séance 4Seuil de décision et ML reproductible
7. DevoirUn modèle de référence défendable
8. Séance 5Noyaux, SVM et arbres de décision
9. Séance 6Forêts, boosting, comparaison honnête
10. Séance 7SHAP, équité, ACP et partitionnement
11. DevoirUn modèle champion documenté
12. Séance 8Réseaux de neurones, dérive, prédiction conforme
13. DevoirUn projet de machine learning livré
14. Séance 9Soutenir un projet de machine learning
15. RéférenceProjet de score de défaut de crédit
16. RéférenceRendements boursiers : XGBoost et sentiment
17. RéférenceLe code Python de chaque modèle
18. RéférenceDeep learning, l'essentiel
19. RéférenceDonnées ouvertes et projets par secteur
20. RéférenceManuel de l'expert data et IA
21. RéférenceData engineering, SRE et cloud
22. RéférencePanorama des modèles de machine learning

Toutes les fiches, en liste de lecture

L'attention et le transformer, pas à pas

À propos de ces fiches

Écrites par l'enseignant à partir des slides du deck, comme un résumé public : les idées clés, les formules et un exemple calculé. Les exercices, leurs corrigés, les contrôles et la notation restent dans le deck, pour les élèves du cours.

Révision : 16 octobre 2026.