Cadrer un projet de machine learning avant d'écrire du code : la question, la décision, la cible et un cahier des charges en six lignes

La question, en une phrase

Une question utile nomme une décision, une façon de mesurer le succès, un périmètre et la personne qui agira sur la réponse, le tout en une phrase.

« Utiliser l'IA pour la logistique » est une ambition, pas une question : personne ne saurait dire si on y a répondu. La méthode de cadrage du cours, posée dès sa première séance (cadrer avant de modéliser), demande une phrase porteuse de quatre marqueurs. Une décision : quelque chose qu'on fera autrement selon la réponse. Une mesure : ce qui dira que la décision s'est améliorée. Un périmètre : quelle population, quel lieu, quelle période. Un responsable : un rôle qui agira vraiment sur la prédiction. C'est ce qui fait d'un sujet une problématique (problem statement).

Sur le fil rouge du cours, le responsable était un analyste crédit qui revoit des dossiers ; dans l'exemple fictif qui court dans toute la consigne, c'est le responsable d'une agence de livraison qui choisit, chaque soir, quels clients faire appeler pour que les remises du lendemain se passent bien. Si la question réclame deux phrases, elle cache en général deux décisions, et l'équipe doit en retenir une.

Retour au sommaire.

La décision, et ce que coûte chaque erreur

Écrire qui décide, entre quelles options réelles et à quel moment, puis donner un prix à l'action inutile et à l'inaction fautive.

La décision passe en premier parce qu'elle fixe tout le reste. On nomme un rôle plutôt qu'une personne (chef d'exploitation, analyste crédit, acheteur, médecin régulateur), qui devient le responsable de la décision (decision owner), et le moment où ce rôle agit, car ce moment détermine les informations que le modèle a le droit d'utiliser. On liste ensuite deux ou trois options concrètes que la prédiction peut faire basculer.

Toute décision a deux façons de rater : agir alors que ce n'était pas nécessaire, et ne pas agir alors qu'il le fallait. Elles ne coûtent presque jamais la même chose. Écrire les deux prix, même grossièrement, c'est ce qui permettra plus tard de choisir un seuil au lieu d'accepter 0,5 par défaut. « Mieux comprendre les retards » n'est pas une décision, puisque personne n'agit autrement selon la réponse ; un projet sans décideur identifiable finit volontiers en démonstration sans enjeu.

• Qui : un rôle, et l'heure limite à laquelle il agit.
• Quoi : les options réelles, celles que la prédiction peut changer.
• Fausse alerte : le prix d'une action pour rien (un appel inutile, un bon client refusé).
• Raté : le prix d'une action manquée (une réclamation, un défaut accepté).

Retour au sommaire.

Une cible datée, et les fuites qu'elle écarte

La cible est une colonne enregistrée selon une règle à une date connue, et tout ce qui arrive après le moment de la prédiction est interdit comme entrée.

Une cible n'est pas le phénomène lui-même mais sa trace datée, enregistrée selon une règle. Le cahier des charges (scope document) en donne quatre éléments : le nom exact de la colonne et sa règle de calcul, l'horizon de prédiction (prediction horizon), et la date à laquelle on connaît la vraie valeur. Pour la livraison : retard vaut un quand le colis arrive après le créneau promis, prédit la veille au soir, connu à la remise.

Ces dates sont la principale protection contre la fuite de données (data leakage). Une cible déjà connue avant la décision est suspecte, et toute variable enregistrée après le moment de la prédiction est interdite en entrée : dans l'exemple, rien de ce qui se passe pendant la tournée du lendemain. La fiche seuil de décision et ML reproductible montre comment une carte des fuites, colonne par colonne, rend ce contrôle systématique.

On ajoute une phrase sur ce que la colonne ne saisit pas. Dans l'exemple, un client absent est rangé parmi les retards, et une minute de retard pèse autant qu'une journée. Ce n'est pas de la modestie : cela évite de promettre au décideur plus que ce que la colonne mesure réellement.

Retour au sommaire.

Une métrique qui mesure la décision, et des garde-fous vérifiables

On juge le modèle dans l'unité que lit le décideur, on fixe le niveau à partir duquel il devient utile, et on liste ce qu'il ne doit jamais faire, même pour mieux scorer.

La métrique qui compte est celle qui dit si la décision s'est améliorée : un coût attendu (expected cost) en euros, des heures gagnées, des retards évités pour un nombre d'appels donné. On écrit aussi le seuil d'utilité (usefulness threshold), le niveau à partir duquel le modèle fait mieux que ne rien faire, ou que la règle simple déjà en place. Puis on nomme la métrique de modèle qui la suit sur la validation : log-loss ou score de Brier pour des probabilités, PR-AUC pour une classe rare, erreur absolue moyenne pour une quantité.

Un garde-fou (safeguard) dit ce que le modèle ne doit jamais faire. Il y en a trois familles : les variables interdites (un attribut protégé, une donnée qui identifie directement une personne), les personnes à protéger (un groupe qu'une erreur pénaliserait plus que les autres) et les fuites (tout ce qui est connu après la décision). Sur le fil rouge du crédit, le sexe était exclu, la situation familiale et l'âge audités. Un garde-fou ne vaut d'être écrit que s'il se vérifie dans le code ou dans les données, et il gagne en crédibilité quand un rôle nommé le signe et peut arrêter le modèle.

Retour au sommaire.

Des données ouvrables aujourd'hui, un plan à trois modèles, et l'équipe

On nomme une source qu'on peut ouvrir tout de suite, avec sa licence, sa période et ses manques, on prévoit un modèle naïf, un meilleur et un lourd, et on dit qui compose l'équipe.

La ligne des données fait couler plus de projets que toute autre, parce qu'on la remplit en dernier. Il lui faut une adresse qui fonctionne aujourd'hui, pas « on demandera à l'entreprise » ; une licence lue, compatible avec un projet d'école public ; la période couverte et le nombre de lignes, qui disent si une coupe par date est possible ; et une liste franche de ce qui manque : la colonne qu'on aimerait avoir, les trous, les biais connus de la collecte. Si l'accès dépend d'un tiers, on écrit quand on l'attend et on nomme une solution de repli publique équivalente. La fiche sur les projets en données ouvertes recense des sources et montre comment lire une licence rapidement. Une ligne impossible à remplir cette semaine invite à changer de sujet, pas de modèle.

Le plan, en trois modèles

1. Naïf. Le modèle naïf (naive baseline), la référence à battre : un taux historique, une moyenne, ou la règle métier déjà en usage.
2. Meilleur. Le meilleur modèle raisonnable, souvent une régression linéaire ou logistique régularisée.
3. Lourd. Un modèle plus complexe, par exemple du gradient boosting, qui teste si la complexité paie vraiment.

Le plan dit aussi ce qui doit exister à chaque jalon suivant et qui fait quoi, avec trois rôles (données, modèle, revue) qui tournent. Ce n'est pas un engagement figé : le plan changera, et l'historique du fichier le montrera. La consigne termine le gabarit par qui nous sommes, en deux parties. D'abord la persona d'équipe (team persona) : l'entreprise que l'équipe incarne pour le projet, qu'il s'agisse d'un cabinet de conseil au service d'une banque, de la cellule data d'un établissement bancaire, du service des risques d'une fintech ou des quants d'un fonds de crédit, avec son client ou interlocuteur et la personne qui signe. Ensuite un court portrait de l'équipe réelle, une ligne par membre, écrite par le membre lui-même : son parcours, le métier visé (un « je ne sais pas encore » honnête est accepté), pourquoi ce track, ses centres d'intérêt. La persona dit au nom de qui l'équipe parle ; les portraits servent à répartir les rôles, à poser à chacun des questions proches de son futur métier et à relier le projet à ses candidatures.

Retour au sommaire.

Deux exemples : une agence de livraison de colis et le risque de crédit

Une équipe fictive de livraison montre un fichier complet et comment deux prix d'erreur donnent un seuil ; un fichier rempli sur des données publiques de crédit montre le même gabarit sur un sujet de finance.

La consigne remplit tout le gabarit pour une équipe imaginaire, avec des chiffres imaginaires : on lit la forme, pas le fond. Le responsable d'une agence décide chaque soir, avant une heure limite, de faire appeler ou non un client. Un appel inutile est chiffré à 8 euros et un retard non prévenu à 25 euros, parce qu'il entraîne une réclamation. La cible est datée après la décision, la métrique est un coût attendu par soir, les garde-fous interdisent de refuser une livraison et d'utiliser la moindre donnée personnelle du destinataire, et la ligne des données nomme un export anonymisé des tournées passées, une demande d'accès écrite et un repli public avec sa licence, ainsi que la météo manquante, à joindre par date et par commune.

En mots, avec les prix de l'exemple (chiffres illustratifs)

1. Deux prix. Un faux positif est un appel pour rien, $c_{FP} = 8$ ; un faux négatif est un retard manqué, $c_{FN} = 25$ ; une décision juste est comptée gratuite.
2. Comparer. Appeler pour un colis dont la probabilité de retard vaut $p$ coûte en moyenne $8(1-p)$, ne pas appeler coûte $25p$ ; l'appel vaut la peine quand $25p > 8(1-p)$.
3. Le seuil. C'est le cas dès que $p$ dépasse environ 0,24, à condition que les probabilités soient calibrées, d'où la log-loss nommée dans la ligne de la métrique.
4. La référence naïve. Avec 4 % de colis en retard, ne jamais appeler coûte $0{,}04 \times 25 = 1$ euro par colis, appeler tout le monde $0{,}96 \times 8 \approx 7{,}7$ : le modèle n'est utile que sous 1 euro.

Le risque de crédit sur Home Credit Default Risk

La consigne remplit aussi le gabarit sur un vrai jeu de données : Home Credit Default Risk, un concours Kaggle de 2018 bâti sur les données d'un prêteur à la consommation dont les clients ont souvent un historique de crédit mince, voire inexistant. La persona est inventée : Aurore Data Conseil, un cabinet de conseil en données qui travaille pour la direction des risques du prêteur, dont le directeur signe le seuil. La question demande quelles demandes du mois un chargé d'octroi doit orienter vers une revue manuelle, pour faire baisser les impayés sans écarter plus de bons clients qu'aujourd'hui.

• Avant de rendre, on vérifie que la question porte ses quatre marqueurs, que la décision a un rôle et ses deux prix d'erreur, que la cible a un horizon et une date de connaissance, que la métrique a un seuil d'utilité, que chaque garde-fou se vérifie et que la ligne des données a une source, une licence, une période et ses manques.
• On vérifie aussi que le plan, la persona et le portrait de l'équipe sont écrits, et que le fichier est poussé sur la branche principale du dépôt partagé.
• Le test du voisin : une personne d'une autre équipe lit le fichier sans explication et reformule la question, la décision, la cible et la métrique. La moindre hésitation désigne la ligne à réécrire.

Retour au sommaire.

S'entraîner : établir un modèle de référence sur le fil rouge

Sur des données publiques de crédit, une équipe peut répéter la méthode que le jalon suivant appliquera à son propre projet : une référence, une note, une ablation honnête.

La seconde partie de la consigne est un entraînement conseillé sur le fil rouge du défaut de crédit (UCI Default of Credit Card Clients, Yeh et Lien, 2009). Elle répète ce que le jalon suivant demande sur les données de l'équipe. Un modèle de référence (baseline) est le modèle simple et honnête que tout candidat doit battre d'un écart mesuré. La première référence est le modèle constant, qui prédit à chaque client le taux de base $\pi$, environ 22,1 % de défauts ; ses scores se calculent à la main.

Six pièces, dans l'ordre où les ouvrir

1. Un dépôt relançable. Du code, des tests, un lockfile, une intégration continue et une commande unique qui va du CSV brut à un fichier de métriques.
2. Deux modèles à la main. Les moindres carrés par les équations normales et par SVD (moindres carrés), la régression logistique par descente de gradient (régression logistique), chacun confronté à scikit-learn, écart affiché.
3. Une note de deux pages. Page un : cadrage, données, coupe figée, carte des fuites. Page deux : le modèle face au constant, la calibration avec une courbe de fiabilité (reliability curve), le seuil tiré des coûts et ce qui arrive si les coûts bougent d'un cinquième.
4. Une ablation pré-enregistrée. Une étude d'ablation (ablation study) : prédire ce qu'on perd sans chaque groupe de colonnes, déposer la prédiction dans une issue horodatée, calculer sur la validation avec le test scellé, commenter chaque écart. C'est le pré-enregistrement (pre-registration).
5. Un journal de décisions. Des entrées datées, avec l'alternative écartée et la commande qui prouve le chiffre.
6. Une annexe IA. Chaque usage avec son niveau, et deux affirmations de l'assistant prouvées fausses par un test qui échoue, un calcul ou une figure.

La note reprend le plan que lit le comité modèle d'une banque : une équipe de validation indépendante refait les chiffres depuis le dépôt, puis cherche la fuite, le seuil injustifié, la probabilité non calibrée, avant que le comité n'approuve, n'approuve sous conditions ou ne refuse. Chaque chiffre de la note doit sortir du fichier de métriques. Quatre pièges reviennent : un standardiseur ajusté sur tout le CSV avant la coupe (un test compare sa moyenne à celle du pli d'apprentissage), une AUC calculée sur des étiquettes au lieu de probabilités, des graines aléatoires dispersées dans les notebooks au lieu d'un seul fichier de configuration, et un README qui ne tourne que chez son auteur, qu'on ne détecte qu'en faisant cloner le dépôt par quelqu'un d'autre.

Retour au sommaire.

À retenir

1. Écrire la question en une phrase, avec une décision, une mesure, un périmètre et un responsable ; si elle demande deux phrases, choisir une décision.
2. Nommer qui décide, quand, entre quelles options, et chiffrer les deux erreurs : agir pour rien et ne pas agir à temps.
3. Dater la cible et le moment de la prédiction : tout ce qui est enregistré après ce moment est une fuite et ne peut pas servir d'entrée.
4. Mesurer la décision dans l'unité du décideur, avec un seuil d'utilité, et ne jamais s'en remettre à l'exactitude seule sur une classe rare.
5. Écrire des garde-fous vérifiables, une source de données ouvrable aujourd'hui avec sa licence et ses manques, et un plan avec un modèle naïf, un meilleur et un lourd.
6. Établir un modèle de référence avec une référence constante, des modèles écrits à la main, une note traçable et une ablation dont les prédictions ont été déposées d'abord.
7. Dire qui l'on est : l'entreprise que l'équipe incarne, son client et qui signe, puis les vraies personnes derrière elle.

Glossaire

cahier des charges (scope document)

Court fichier qui fixe la question, la décision, la cible, la métrique, les garde-fous, les données et le plan d'un projet.

problématique (problem statement)

La question à laquelle répond un projet, écrite pour que quelqu'un puisse agir sur la réponse.

responsable de la décision (decision owner)

Le rôle qui agit sur la prédiction, à un moment connu.

coût attendu (expected cost)

Coût moyen des décisions prises avec un modèle, chaque erreur pondérée par son prix.

seuil d'utilité (usefulness threshold)

Niveau à partir duquel un modèle fait mieux que ne rien faire ou que la règle existante.

horizon de prédiction (prediction horizon)

Le délai entre le moment de la prédiction et l'événement prédit.

fuite de données (data leakage)

Information indisponible au moment de la décision qui atteint le modèle et gonfle ses scores.

persona d'équipe (team persona)

L'entreprise qu'une équipe incarne pour son projet, avec son client et la personne qui signe.

garde-fou (safeguard)

Ce que le modèle ne doit jamais faire, énoncé assez précisément pour être vérifié.

exactitude (accuracy)

Part des prédictions justes ; trompeuse quand une classe est rare.

modèle naïf (naive baseline)

La référence la plus simple, taux historique, moyenne ou règle métier, que le projet doit battre.

modèle de référence (baseline)

Le modèle simple que tout candidat doit battre d'un écart mesuré.

étude d'ablation (ablation study)

Retrait de groupes d'entrées un à un pour mesurer l'apport de chacun.

pré-enregistrement (pre-registration)

Écrire ses prédictions, horodatées, avant de lancer l'expérience.

courbe de fiabilité (reliability curve)

Fréquence observée contre probabilité prédite ; un modèle calibré suit la diagonale.

Les autres fiches du cours

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

Précédent : Seuil de décision et ML reproductibleSuivant : Noyaux, SVM et arbres de décision

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. DevoirCadrer un projet ML : le cahier des charges
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 simple, une méthode complète
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.