Travail final

Après les études de cas
environ 4 h

Ce que vous saurez faire

Appliquez chaque module du cours à une nouvelle décision. Livrez un classificateur qu’une autre personne peut exécuter, vérifier et juger fiable. Les données sont les mêmes que dans les leçons, mais la capacité de l’équipe a changé. Vous devez donc refaire chaque choix plutôt que le copier.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 260 minutes

Vous avez terminé les modules 1 à 8. Chaque partie ci-dessous nomme les leçons qu’elle utilise.
Les études de cas du module 9 ne sont pas nécessaires pour ce travail. (Le certificat en exige au moins une.) Pour voir d’abord une démarche semblable sur des données réelles, ouvrez Choisir un modèle pour les réadmissions à l’hôpital. Cette leçon compare des familles de modèles selon un même protocole et choisit un modèle simple à partir de preuves.
Votre projet ticket-model fonctionne. Il comprend data/ obtenu avec get_data.py, l’environnement virtuel avec requirements.txt installé et ticket_model.py avec les 11 caractéristiques de Sélectionner les caractéristiques utiles : modifier ticket_model.py. Si un fichier ne fonctionne plus, exécutez python get_data.py --reset, ou copiez-le depuis le dossier du projet terminé, C05/project.
Créez un nouveau dossier dans votre projet pour ce travail : escalation/. Mettez-y chaque nouveau script, fichier et rapport du travail.
Vous pouvez faire les parties 1 à 6 dans un carnet (notebook) Jupyter (local, Colab ou Kaggle). La partie 7 exige des fichiers et un terminal.
Testé avec Python 3.14.6, pandas 3.0.6 et scikit-learn 1.9.1 sur macOS.

La décision : une équipe d’agents chevronnés plus grande

À partir de juillet, Larkfield compte deux agents chevronnés de plus. Grace dit : « Nous pouvons maintenant examiner 1 nouveau billet de soutien sur 4 (25 %), plutôt que 1 sur 5. Je veux que les billets qui feront l’objet d’une escalade soient dans ces 25 %. » Omar pose la question qui détermine le projet : « Un modèle en vaut-il la peine? Une règle simple ne coûte rien à exécuter. »

Priya vous demande une réponse appuyée par des preuves. Vous créez le classificateur et le comparez à des références de base simples et à deux familles de modèles. Vous rapportez le résultat sur des données qui n’ont servi à aucun choix. Vous consignez aussi chaque expérience et expliquez pourquoi le modèle final n’est pas plus complexe que nécessaire.

Toutes les données proviennent de l’exportation synthétique de Larkfield. Aucune personne réelle.

Partie 1 : cadrer le problème

Utilise Traduire un besoin et Choisir la tâche d’apprentissage.

Rédigez escalation/BRIEF.md, un document de cadrage de la modélisation d’une page. Il doit préciser :

La décision qu’une prédiction change et la personne qui la prend.
L’unité de prédiction, la cible et le moment de la prédiction. Dites exactement quand le modèle s’exécute et ce qui est connu à ce moment.
Les caractéristiques permises et les colonnes interdites, avec une justification d’une phrase pour chacune. Incluez priority_now et customer_escalation_rate.
Le coût de chaque type d’erreur, en mots.
La capacité (25 %) et un objectif de réussite mesurable. Par exemple : « détecter au moins X % des escalades en signalant au plus 25 % des billets ». Choisissez X avant d’entraîner un modèle et expliquez pourquoi.

Partie 2 : références de base

Utilise Définir une référence de base, Les métriques de classification et Le compromis entre précision et rappel.

Commencez escalation/experiment_log.csv, un journal d’expériences semblable à celui de L’apprentissage automatique est itératif, avec les mêmes colonnes. Ajoutez une ligne pour chaque étape ci-dessous, au moment où vous la faites.
Sur les données de validation, calculez la référence de base de la classe majoritaire : exactitude, précision et rappel.
Calculez les résultats de la règle « signaler la priorité 1 » : taux de signalement, précision et rappel.
Écrivez une autre règle qui utilise mieux la nouvelle capacité. Calculez les mêmes valeurs. Comparez son taux de signalement à la capacité.
Présentez les trois références de base dans un tableau. Sous ce tableau, expliquez en une phrase pourquoi l’exactitude n’est pas la bonne métrique pour cette décision.

Partie 3 : deux familles de modèles, une démarche

Utilise Prétraiter avec un pipeline, L’apprentissage automatique est itératif, Les arbres de décision, Contrôler la complexité, Les méthodes d’ensemble, Données d’entraînement, de validation et de test : validation croisée, Régler les hyperparamètres et Quand un modèle simple est meilleur.

Choisissez deux familles de modèles : la régression logistique et un ensemble d’arbres (une forêt aléatoire ou du gradient boosting, renforcement par gradient).
Placez chacun dans le même pipeline avec build_pipeline(). Ainsi, le prétraitement sera ajusté uniquement sur les données d’entraînement.
Pour chaque famille, comparez au moins deux configurations par validation croisée stratifiée à 5 plis sur les données d’entraînement (StratifiedKFold(5, shuffle=True, random_state=0), précision moyenne).
Ajoutez une ligne au journal d’expériences pour chaque configuration : moyenne et écart-type des 5 plis, décision et justification. Indiquez l’erreur-type (l’écart-type ÷ √5) dans la justification.
Choisissez un modèle. Utilisez la règle d’une erreur-type. N’utilisez ni les données de validation ni les données de test à cette étape.
Justifiez la simplicité de votre choix en trois à cinq phrases, sous le titre Pourquoi ce modèle. Répondez à ces questions. La différence entre les deux familles dépasse-t-elle une erreur-type? Qui doit comprendre ou vérifier les scores (l’équipe de Grace, un auditeur)? Quels coûts entraînerait le modèle plus complexe : temps, explication, débogage, surveillance? Si vous choisissez le modèle plus complexe, montrez que son gain dépasse le bruit et justifie ces coûts.
Entraînez le modèle choisi sur les données d’entraînement. Indiquez sa précision moyenne et son aire sous la courbe ROC sur les données de validation.

Partie 4 : le seuil et la calibration

Utilise Seuils et calibration.

Sur les données de validation, choisissez le seuil pour la capacité de 25 %. Prenez le seuil le plus bas, par pas de 0,01, qui signale au plus 25 % des billets. Ajoutez-le au journal d’expériences.
Indiquez la matrice de confusion, le taux de signalement, la précision et le rappel à ce seuil.
Comparez ces résultats aux références de base de la partie 2. Le modèle atteint-il votre objectif de réussite de la partie 1?
Comparez le score moyen au taux d’escalade observé sur les données de validation. Expliquez en une phrase ce que cette différence signifie pour les personnes qui lisent les scores.

Partie 5 : le résultat de test, une seule fois

Utilise Seuils et calibration : tester une seule fois avec evaluate.py.

Figez vos choix : le modèle, ses réglages, les caractéristiques et le seuil. Consignez-les dans votre rapport avant de regarder les données de test.
Exécutez l’évaluation sur les données de test une seule fois, avec le seuil de la partie 4.
Indiquez la matrice de confusion, le taux de signalement, la précision, le rappel, la précision moyenne et l’aire sous la courbe ROC du test. Indiquez aussi les résultats de la règle « signaler la priorité 1 » sur les données de test.
Comparez les résultats de test aux résultats de validation. Expliquez toute différence. Ne changez pas le modèle après les avoir regardés.

Le résultat de test n’est pas une ligne du journal d’expériences. Le journal consigne les choix, et les données de test ne doivent en déterminer aucun.

Partie 6 : erreurs et limites

Utilise L’analyse par sous-groupes, Expliquer les prédictions et L’exploration non supervisée.

Sur les données de validation, comparez le rappel et le taux de signalement dans au moins deux sous-groupes (par exemple team et channel). Affichez le nombre de billets à côté de chaque taux.
Examinez dix escalades manquées (faux négatifs) ayant les scores les plus bas. Décrivez leurs points communs, s’il y en a.
Indiquez les trois caractéristiques sur lesquelles le modèle s’appuie le plus (importance par permutation). Expliquez en une phrase pourquoi cela ne montre pas ce qui cause une escalade.
Nommez au moins un problème de données et une limite du modèle, chacun avec les preuves qui le montrent.

Partie 7 : faire la passation

Utilise Empaqueter les artefacts, Documenter les limites d’utilisation et Planifier les vérifications en production.

Modifiez train.py (dans escalation/, ou une copie) pour votre modèle et la capacité de 25 %. Exécutez-le. Il enregistre le pipeline, model_info.json et l’échantillon de vérification.
Dans un nouveau terminal (un nouveau processus), exécutez python predict.py --check. Il doit indiquer des scores identiques.
Calculez les scores de data/july_tickets.csv avec predict.py. Indiquez le taux de signalement du 1er au 14 juillet et du 15 au 31 juillet, ainsi que les avertissements affichés par predict.py.
Rédigez escalation/MODEL_CARD.md pour votre modèle. Incluez l’utilisation prévue, les utilisations exclues, la justification du modèle, l’évaluation et les limites.
Définissez un déclencheur de réentraînement en une ou deux phrases, avec les valeurs que vous surveilleriez.

Quoi remettre

Un dossier escalation/ contenant :

escalation/
  BRIEF.md            Part 1
  experiment_log.csv  Parts 2 to 4: one row for each baseline, setting, feature change and threshold
  REPORT.md           Parts 2 to 6, and the commands to reproduce every number
  MODEL_CARD.md       Part 7
  train.py            and any other script or notebook that you used
  model/              escalation_model.joblib, model_info.json, check_sample.csv
  requirements.txt    exact versions

experiment_log.csv contient les colonnes du Le journal d’expériences : id, date, change, cv_ap, cv_std, valid_ap, decision, reason. La décision est baseline (référence de base), keep (conserver) ou reject (rejeter). Écrivez chaque ligne au moment du changement, pas à la fin. Laissez une valeur vide lorsqu’elle ne s’applique pas. Un seuil n’a pas de score de validation croisée. Pour une règle, calculez ce score avec rule_scores(), comme dans L’apprentissage automatique est itératif, ou laissez-le vide. valid_ap sert uniquement à un modèle que vous vérifiez une fois sur les données de validation. Écrivez les autres valeurs de validation, comme le taux de signalement et le rappel, dans la justification.

REPORT.md doit contenir ces sections :

# Ticket escalation classifier: evaluation report

## Decision, target and prediction time      (short; the full text is in BRIEF.md)
## Baselines                                  (Part 2: table, and why not accuracy)
## Model selection                            (Part 3: CV table, the choice and the reason)
## Why this model                             (Part 3: three to five sentences on simplicity)
## Threshold for 25% capacity                 (Part 4: threshold, confusion matrix, comparison)
## Calibration                                (Part 4)
## Frozen choices                             (Part 5: written before the test)
## Test result                                (Part 5: once; comparison with validation)
## Errors and limits                          (Part 6: slices with counts, data problem, model limitation)
## July check and retraining trigger          (Part 7)
## How to reproduce                           (commands, versions, the fresh-process check)

Le journal d’expériences et Pourquoi ce modèle sont obligatoires, pas facultatifs. Ils ajoutent peu de travail : le journal consigne des valeurs que les parties 2 à 4 calculent de toute façon. La section Pourquoi ce modèle remplace une courte explication demandée dans la partie 3. Mais ils montrent deux choses qu’un seul score ne peut montrer. Vous avez essayé, mesuré et décidé dans un ordre équitable. Et le modèle final est aussi simple que les preuves le permettent.

Vérifiez votre travail

Ce cours n’a pas encore de réviseur. Évaluez votre travail avec ce tableau, ou demandez à un collègue de l’utiliser. Marquez chaque élément comme démontré, partiellement démontré ou pas encore démontré, avec une justification. Le cours est terminé lorsque chaque élément est démontré. Vous pouvez corriger un élément et le réévaluer aussi souvent que nécessaire.

Preuve requise	Démontré lorsque
Moment de prédiction et cible explicites	Le document de cadrage nomme la décision, l’unité de prédiction, la cible `escalated_72h` et le moment de prédiction (création du billet). Chaque caractéristique est connue à ce moment. `priority_now` et `customer_escalation_rate` sont exclues, chacune pour une raison correcte.
Comparaison des références de base	La classe majoritaire, la règle de priorité 1 et votre règle sont comparées au modèle sur les mêmes données de validation. La comparaison inclut le taux de signalement, la précision et le rappel. Le rapport dit si le modèle vaut son coût, selon les termes d’Omar.
Un choix de modèle consigné et honnête	Le journal d’expériences contient une ligne pour chaque référence de base, configuration de validation croisée, changement de caractéristiques et seuil. Chacune inclut sa décision et sa justification. Pourquoi ce modèle compare la différence entre les familles à une erreur-type. Cette section donne aussi au moins une raison autre qu’un score : qui doit comprendre les scores, coût, débogage ou surveillance.
Validation et choix du seuil sans fuite de données	Le prétraitement est ajusté uniquement sur les données d’entraînement (dans le pipeline). Les réglages et le modèle sont choisis par validation croisée sur les données d’entraînement. Le seuil est choisi sur les données de validation pour la capacité de 25 %. Les choix sont figés avant le test, et le test est utilisé une seule fois. `predict.py --check` réussit dans un nouveau processus.
Analyse des erreurs et limites	Les sous-groupes affichent les nombres de billets à côté des taux, et les petits sous-groupes sont traités avec prudence. Au moins un problème de données et une limite du modèle sont nommés, chacun avec des preuves. L’importance n’est pas décrite comme une cause. La fiche du modèle précise les utilisations exclues.

Un modèle ayant un score élevé et une fuite de données n’est pas un travail terminé. Par exemple, si une caractéristique est calculée à partir de billets ultérieurs, l’élément sur les fuites est pas encore démontré. C’est vrai même si toutes les autres parties sont correctes. De même, un résultat obtenu après avoir modifié le modèle à cause des données de test n’est pas un résultat indépendant.

Afficher les valeurs clés pour vérifier vos résultats

Ouvrez ceci seulement après avoir obtenu vos propres valeurs. Votre règle et votre deuxième famille peuvent différer de celles-ci. Comparez alors la méthode, pas les valeurs.

Références de base (validation, 1 179 billets, 183 escalades) : ne jamais prédire d’escalade : exactitude 0,845, rappel 0. Priorité 1 : 163 signalements (13,8 %), précision 0,374, rappel 0,333. « Priorité 1 ou équipe payment » : 317 signalements (26,9 %, au-delà de la capacité), précision 0,271, rappel 0,470.
Validation croisée (entraînement, précision moyenne) : régression logistique 0,3393 ± 0,0156 (erreur-type 0,0070); gradient boosting avec une profondeur de 2 et un taux d’apprentissage de 0,1 : 0,3424 ± 0,0178 (erreur-type 0,0080). La différence de 0,003 est inférieure à une erreur-type. La régression logistique, plus simple, est donc un bon choix. Si vous avez choisi le boosting avec une justification claire, c’est aussi correct.
Seuil pour 25 % (validation) : régression logistique : 0,16, 291 signalements (24,7 %), vrais positifs 102, faux positifs 189, faux négatifs 81, vrais négatifs 807, précision 0,351, rappel 0,557. Boosting (profondeur 2, taux 0,1) : précision moyenne de validation 0,395, aire sous la courbe ROC 0,754; à 0,16, 275 signalements (23,3 %), précision 0,364, rappel 0,546.
Calibration (validation) : score moyen 0,120, taux observé 0,155. Les scores sont trop bas après le changement de politique de mai. Ils ne représentent donc pas « la probabilité » d’escalade.
Test, une seule fois (régression logistique, 0,16; 1 002 billets, 157 escalades) : aire sous la courbe ROC 0,749, précision moyenne 0,345; 252 signalements (25,1 %), vrais positifs 85, faux positifs 167, faux négatifs 72, vrais négatifs 678, précision 0,337, rappel 0,541. Priorité 1 sur le test : 150 signalements (15,0 %), précision 0,367, rappel 0,350. Le taux de signalement dépasse un peu 25 % sur les nouvelles données. Un seuil choisi sur un mois ne garantit pas le respect de la capacité le mois suivant. Dites-le dans le rapport et surveillez ce taux (partie 7).
Juillet (régression logistique à 0,16) : calculez les résultats avec predict.py. Attendez-vous à des avertissements pour le canal social (réseaux sociaux) à partir du 15 juillet. Le taux de signalement devrait aussi être plus élevé dans la deuxième moitié du mois.

Un court exemple du journal d’expériences (les premières lignes; le vôtre contient vos dates et votre règle) :

id	date	change	cv_ap	cv_std	valid_ap	decision	reason
E01	2026-08-01	Règle : signaler la priorité 1				baseline	La règle à dépasser. Validation : 13.8 % signalés, rappel 0.333.
E02	2026-08-01	Règle : priorité 1 ou équipe payment				reject	Dépasse la capacité de 25 % : 26.9 % signalés en validation (rappel 0.470).
E03	2026-08-02	Régression logistique, C = 1	0.339	0.016	0.391	keep	Première famille de modèles; erreur-type 0.007.
E04	2026-08-02	Boosting, profondeur 2, taux d’apprentissage 0.1	0.342	0.018		reject	Gain de 0.003 : moins d’une erreur-type (0.008).
E05	2026-08-03	Seuil pour 25 % en validation				keep	0.16 : 24.7 % signalés, rappel 0.557. Le seuil le plus bas qui respecte la capacité.

Récapitulatif

Vous pouvez maintenant transformer un besoin d’affaires en modèle qu’une autre personne peut exécuter. Vous cadrez la décision et son moment, et dépassez des références de base simples avec des preuves. Vous essayez des familles de modèles, consignez les résultats et gardez le modèle aussi simple que les preuves le permettent. Vous choisissez un seuil sans fuite des données de test et expliquez les échecs du modèle. Vous faites la passation avec une fiche du modèle et des vérifications en production. Les prochains cours s’appuient sur ces acquis : L’apprentissage profond et les transformeurs expliqués enseigne l’apprentissage profond. Déployer des modèles d’IA pour de vrais utilisateurs permet de déployer un modèle pour de vrais utilisateurs.