Définir une référence de base

Ce que vous saurez faire

Mesurez les prédictions les plus simples avant d’entraîner un modèle, puis notez le résultat qu’un modèle doit atteindre. Sans référence de base, un score de 84,5 % semble bon, même si le modèle ne détecte rien.

Carnet JupyterFaites cette leçon dans un carnetColab · Kaggle · GitHub · en anglais

Le carnet (notebook) Jupyter calcule chaque référence de base de cette page, d’abord sur dix billets de soutien, puis sur les 1 179 billets de mai. Vous testez aussi une autre règle et remplissez la fiche de modélisation. Ses cellules de préparation installent pandas et scikit-learn et téléchargent les données d’exercice. Aucune configuration locale n’est donc nécessaire. Environ 30 minutes.

Ouvrir dans ColabOuvrir dans KaggleVoir sur GitHub

Le carnet est en anglais. Colab et Kaggle ouvrent votre propre copie. Il faut un compte Google ou Kaggle gratuit. Vous êtes bloqué ? Consultez le carnet de solution.

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

Ce que vous devez savoir

• La décision, la capacité de 20 % et les deux types d’erreurs. Le rappel et la précision, expliqués avec des mots. Ces notions viennent de Traduire un besoin : de la décision à la métrique.
• La classification et les réponses qui ne nécessitent aucun modèle (une règle), dans Choisir la tâche d’apprentissage.
• Les environnements virtuels et requirements.txt, dans Isoler les dépendances du cours Python pour l’ingénierie de l’IA en pratique. Les carnets et leur noyau, dans De la rigueur dans le carnet du cours de Python. Vous en avez besoin seulement pour le projet local.

Ce qu’il vous faut sur votre ordinateur (seulement pour travailler localement; le carnet n’exige rien de tout cela)

• Python 3.12 ou une version ultérieure, dans Installer et vérifier Python du cours de Python.
• VS Code, dans Installer et vérifier Python : Étape 3 : obtenir un éditeur de code.
• Une connexion Internet et environ 500 Mo d’espace disque libre : l’environnement utilise environ 450 Mo sur macOS, et les données, 2,5 Mo. Aucun compte.
• Cette leçon crée le dossier de projet ~/projects/ticket-model, dans Préparer votre projet. Toutes les leçons suivantes du cours peuvent l’utiliser.

Testé sur macOS. La configuration utilisait Python 3.14.6, pandas 3.0.6, scikit-learn 1.9.1, matplotlib 3.11.2 et ipykernel 7.4.0. Les commandes pour Windows et Linux n’ont pas été testées. Le carnet a été testé dans Jupyter.

Avant d’acheter une application météo

Imaginez une application météo payante qui promet : « Nos prévisions pour demain sont justes 70 % du temps. » Est-ce bon? Vous ne pouvez pas encore le savoir. Essayez la prévision la plus simple que tout le monde peut faire gratuitement : « Demain sera comme aujourd’hui. » Dans bien des endroits, cette prévision gratuite est juste la plupart des jours, car la météo change lentement. Si elle est juste 65 % du temps, l’application coûteuse apporte peu. Si elle est juste 80 % du temps, l’application fait moins bien qu’une approche toute simple.

La même question se pose avant chaque modèle. Un nombre comme 70 % ou 84,5 % ne signifie rien à lui seul. Il prend un sens seulement quand on le compare au résultat obtenu sans aucun modèle. Avant tout entraînement, vous mesurez donc les prédictions les plus simples sur les mêmes données, avec les mêmes mesures. Ces prédictions simples sont les références de base, et chaque modèle de ce cours leur est comparé.

Ce qu’est une référence de base

Une référence de base est la prédiction la plus simple que tout le monde peut faire sans modèle. Elle ne nécessite aucun apprentissage, ou seulement un nombre appris à partir des données d’entraînement. Vous la mesurez d’abord, sur les mêmes données et avec les mêmes mesures que le modèle. Chaque résultat du modèle a alors un point de comparaison. Un modèle est utile seulement s’il fait clairement mieux que ses références de base. Une référence de base difficile à dépasser est aussi une information utile : une règle simple pourrait être la bonne réponse.

Pour la question oui/non de Larkfield, deux références de base décident de signaler ou non chaque billet :

• Classe majoritaire : toujours prédire la réponse la plus fréquente. La plupart des billets ne font pas l’objet d’une escalade, donc cette référence de base ne signale jamais rien. C’est le « demain sera comme aujourd’hui » de la classification : elle ne coûte rien et donne souvent la bonne réponse.
• Une règle : signaler les billets de priorité 1. Elle utilise un fait auquel l’équipe de soutien fait déjà confiance.

Dix billets, comptés à la main

Voici dix billets fictifs. Deux ont fait l’objet d’une escalade : T-1 et T-5.

Billet	Priorité	Équipe	Escalade
T-1	1	payment	1
T-2	3	delivery	0
T-3	2	returns	0
T-4	1	delivery	0
T-5	2	warranty	1
T-6	3	account	0
T-7	2	delivery	0
T-8	3	returns	0
T-9	1	account	0
T-10	2	payment	0

La classe majoritaire ne signale jamais rien et laisse donc passer les deux escalades. Elle donne la bonne réponse pour les 8 billets sans escalade, donc 8 fois sur 10. La règle signale T-1, T-4 et T-9. T-1 a fait l’objet d’une escalade : la règle l’a donc détecté. T-4 et T-9 n’ont pas fait l’objet d’une escalade. Ce sont donc deux fausses alertes : des examens inutiles. T-5 a fait l’objet d’une escalade sans être signalé : la règle l’a donc manqué. Les 6 autres billets ont été correctement laissés de côté. La règle donne donc la bonne réponse 7 fois sur 10.

Ces quatre nombres donnent trois proportions, présentées avec des mots dans la leçon précédente :

• Rappel : combien d’escalades avons-nous détectées? La règle en a détecté 1 sur 2, donc son rappel est de 0,5. La classe majoritaire n’en a détecté aucune : 0.
• Précision : combien de billets signalés ont vraiment fait l’objet d’une escalade? C’est le cas de 1 des 3 billets signalés par la règle : 0,333. La classe majoritaire ne signale rien, donc elle n’a pas de précision.
• Exactitude : pour combien de billets le signalement (ou son absence) était-il juste? 8 sur 10 pour la classe majoritaire, 7 sur 10 pour la règle.

Le tableau présente les nombres côte à côte :

	Classe majoritaire : ne jamais signaler	Règle : priorité 1
Détectés (signalés, avec escalade)	0	1 (T-1)
Fausses alertes (signalés, sans escalade)	0	2 (T-4, T-9)
Manqués (non signalés, avec escalade)	2 (T-1, T-5)	1 (T-5)
Correctement laissés de côté (non signalés, sans escalade)	8	6
Rappel : détectés ÷ escalades	0 ÷ 2 = 0,0	1 ÷ 2 = 0,5
Précision : détectés ÷ signalés	aucun signalement	1 ÷ 3 = 0,333
Exactitude : réponses justes ÷ tous les billets	8 ÷ 10 = 0,8	7 ÷ 10 = 0,7

Regardez la dernière ligne. La classe majoritaire n’aide jamais Grace, et son exactitude est plus élevée. La règle détecte une des deux escalades, et son exactitude est plus faible. Gardez cela en tête pour les données réelles. Les métriques de classification donne à ces quatre nombres leurs noms habituels et explique pourquoi l’exactitude se comporte ainsi.

Un score constant

Les modèles de ce cours ne donnent pas simplement un oui ou un non. Ils donnent à chaque billet un score de 0 à 1. Un score plus élevé signifie « plus susceptible de faire l’objet d’une escalade ». L’équipe spécialisée examine ensuite les billets ayant les scores les plus élevés. Un score a donc besoin de sa propre référence de base : le score constant, identique pour chaque billet. Le taux d’escalade des données d’entraînement est un choix naturel.

Deux mesures évaluent un score avant toute séparation entre oui et non. Le compromis entre précision et rappel explique les deux. Pour l’instant, une phrase pour chacune suffit :

• ROC AUC : la probabilité qu’un billet avec escalade choisi au hasard obtienne un score supérieur à un autre billet choisi au hasard. 0,5 correspond au hasard, et 1,0 à un classement parfait.
• Précision moyenne (AP) : la qualité de la précision quand vous descendez la liste des billets, à partir du score le plus élevé. Pour un score qui ne peut pas du tout classer les billets, elle égale le taux d’escalade.

Sur les dix billets, le score constant donne 0,2 à chaque billet, soit leur taux d’escalade. Avec le même score pour chaque billet, aucun billet avec escalade ne peut se trouver au-dessus d’un autre billet. La ROC AUC est donc de 0,5, et l’AP de 0,2, soit le taux. C’est le minimum à dépasser pour chaque modèle : une ROC AUC supérieure à 0,5 et une AP supérieure au taux d’escalade.

Exemple détaillé : les références de base de Priya pour mai

Priya calcule les références de base sur les données de validation, les 1 179 billets de mai. (Données d’entraînement, de validation et de test explique pourquoi on mesure un résultat sur des billets qui n’ont pas servi à l’apprentissage.) Chaque référence de base apprend seulement à partir des données d’entraînement. La classe la plus fréquente et le taux d’escalade viennent des billets d’entraînement, et la règle ne nécessite aucune donnée. Chaque bloc de code est une cellule du carnet de la leçon. Les cellules de préparation y ont déjà chargé pandas sous le nom pd et numpy sous le nom np.

D’abord, elle écrit une fonction qui compte les quatre types de résultats et calcule les proportions. C’est le comptage manuel ci-dessus, en code :

def flag_report(y, flags):
    """Compare 0/1 flags with the real 0/1 answers: four counts and four shares."""
    y = np.asarray(y, dtype=bool)
    flags = np.asarray(flags, dtype=bool)
    caught, false_alarms = int((flags & y).sum()), int((flags & ~y).sum())
    missed, correctly_left = int((~flags & y).sum()), int((~flags & ~y).sum())
    return {"flagged": caught + false_alarms, "share flagged": round((caught + false_alarms) / len(y), 3),
            "caught": caught, "false alarms": false_alarms, "missed": missed, "correctly left": correctly_left,
            "precision": round(caught / (caught + false_alarms), 3) if caught + false_alarms else None,
            "recall": round(caught / (caught + missed), 3), "accuracy": round((caught + correctly_left) / len(y), 3)}

Sur les dix billets, elle donne les nombres du tableau ci-dessus. Priya charge ensuite les données. read() est la même fonction que dans Traduire un besoin :

TARGET = "escalated_72h"
train = read("data/train.csv")
valid = read("data/valid.csv")
majority_class = train[TARGET].mode()[0]
train_rate = round(train[TARGET].mean(), 3)
print("Most common class in train:", majority_class, "  train escalation rate:", train_rate)

La sortie :

Most common class in train: 0   train escalation rate: 0.117

Avant d’exécuter la cellule suivante, Priya demande à Omar quelle référence de base aura la meilleure exactitude. Il répond : « La règle, bien sûr. Elle trouve les escalades. »

y = valid[TARGET]
baselines = pd.DataFrame([flag_report(y, [majority_class] * len(valid)),
                          flag_report(y, valid["priority"] == 1)],
                         index=["majority: never escalate", "rule: flag priority 1"])
baselines

La sortie :

                          flagged  share flagged  caught  false alarms  missed  correctly left  precision  recall  accuracy
majority: never escalate        0          0.000       0             0     183             996        NaN   0.000     0.845
rule: flag priority 1         163          0.138      61           102     122             894      0.374   0.333     0.810

Lisez chaque ligne :

• Aucune escalade donne la bonne réponse pour 996 des 1 179 billets : une exactitude de 84,5 %. Elle ne détecte aucune des 183 escalades. Sa précision est NaN (pas un nombre), car elle ne signale rien et 0 ÷ 0 n’a pas de valeur.
• Signaler la priorité 1 signale 163 billets, soit 13,8 %, ce qui respecte la capacité de 20 %. Parmi les billets signalés, 61 ont fait l’objet d’une escalade, donc sa précision est de 0,374. Elle détecte 61 des 183 escalades, donc son rappel est de 0,333 : une sur trois. Son exactitude, de 81,0 %, est inférieure à celle de la référence de base inutile.

Omar avait tort, comme la plupart des gens la première fois. Le cas d’échec ci-dessous montre le piège, et Les métriques de classification l’explique en détail. Enfin, Priya essaie le score constant, avec le taux d’entraînement de 0,117 pour chaque billet de mai. Les deux fonctions de métriques viennent de sklearn.metrics; le carnet les importe dans la section 2 :

constant_scores = [train_rate] * len(valid)
print("ROC AUC:", roc_auc_score(y, constant_scores))
print("Average precision:", round(average_precision_score(y, constant_scores), 3))
print("Escalation rate in valid:", round(y.mean(), 3))

La sortie :

ROC AUC: 0.5
Average precision: 0.155
Escalation rate in valid: 0.155

La ROC AUC d’un modèle doit donc dépasser 0,5, et son AP doit dépasser 0,155, sur les données de mai. Voici les trois références de base réunies :

Référence de base (sur les données de validation, mai 2026)	Signalés	Précision	Rappel	Exactitude
Classe majoritaire : aucune escalade	0 (0 %)	—	0,000	0,845
Règle : signaler la priorité 1	163 (13,8 %)	0,374	0,333	0,810
Score constant de 0,117 (le taux d’entraînement)	—	ROC AUC de 0,5; AP de 0,155 (le taux)

L’objectif d’amélioration

Une référence de base indique votre point de départ. Un objectif d’amélioration indique le résultat qui rend un modèle utile. Formulez-le dans les termes de la décision, et écrivez-le avant de voir le score d’un modèle. Si vous l’écrivez après, il est trop facile de modifier l’objectif pour qu’il corresponde au résultat.

La décision de Grace impose deux conditions. L’équipe spécialisée peut examiner au plus 20 % des nouveaux billets. Dans cette limite, la règle détecte déjà 33 % des escalades. Un modèle doit en détecter clairement plus, sinon la règle suffit. Grace et Priya s’entendent sur cet objectif :

Signaler au plus 20 % des nouveaux billets (la capacité) et détecter au moins 40 % des escalades (la règle en détecte 33 %).

Dans les termes de la leçon précédente : la proportion signalée doit être d’au plus 20 %, et le rappel d’au moins 40 %. Aucune des deux références de base n’atteint l’objectif :

	Proportion signalée (au plus 20 %)	Rappel (au moins 40 %)	Atteint l’objectif
Aucune escalade	0 %	0,000	Non
Signaler la priorité 1	13,8 %	0,333	Non : elle en détecte trop peu

Chaque modèle de ce cours doit atteindre cet objectif. Vous le vérifiez sur les données de validation pendant votre travail, puis une seule fois sur les données de test, à la fin. Dans le carnet, la fonction meets_target() le vérifie :

def meets_target(report):
    """True if the flags fit the capacity (at most 20%) and catch at least 40%."""
    return report["share flagged"] <= 0.20 and report["recall"] >= 0.40


rule = flag_report(y, valid["priority"] == 1)
print("Rule meets the target:", meets_target(rule))

La sortie :

Rule meets the target: False

Préparer votre projet

Vous pouvez suivre tout le cours dans les carnets des leçons, sur Colab ou Kaggle, sans installation. Au module 8, vous aurez aussi besoin de fichiers et de commandes sur votre ordinateur. La passation d’un modèle consiste en fichiers et en commandes. Cette section crée ce projet local dès maintenant pour qu’il soit prêt. Cela prend environ 15 minutes. Si vous utilisez seulement les carnets pour le moment, passez à la Pratique guidée. Revenez ici avant le module 8.

À la fin, vous aurez ce dossier :

ticket-model/
  .venv/              the virtual environment
  requirements.txt    the packages and their versions
  get_data.py         downloads and checks the data
  data/               train.csv valid.csv test.csv and five more files

Vérifier Python

Ouvrez un terminal et vérifiez la version de Python. Il vous faut la version 3.12 ou une version ultérieure.

macOS

python3 --version

Windows

python --version

Linux

python3 --version

Vous devriez voir Python 3.12 ou un nombre supérieur, par exemple Python 3.14.6. Si vous voyez Python 3.11 ou une version antérieure, ou « command not found » (commande introuvable), installez Python. Suivez Installer et vérifier Python.

Créer le dossier du projet

1. Créez le dossier ~/projects/ticket-model et placez-vous dans ce dossier :

   macOS

   mkdir -p ~/projects/ticket-model
   cd ~/projects/ticket-model

   Windows

   mkdir ~\projects\ticket-model
   cd ~\projects\ticket-model

   Si le dossier existe déjà, mkdir affiche une erreur. Vous pouvez l’ignorer.

   Linux

   mkdir -p ~/projects/ticket-model
   cd ~/projects/ticket-model

2. Vérifiez où vous êtes. Exécutez pwd. Le chemin se termine par projects/ticket-model (sur Windows, projects\ticket-model).

Exécutez toutes les commandes du reste du cours dans ce dossier.

Créer l’environnement

Un environnement virtuel sépare les paquets de ce projet de ceux des autres projets. C’est ce qu’explique Isoler les dépendances dans le cours Python pour l’ingénierie de l’IA en pratique.

1. Créez l’environnement :

   macOS

   python3 -m venv .venv

   Windows

   python -m venv .venv

   Linux

   python3 -m venv .venv

2. Activez-le :

   macOS

   source .venv/bin/activate

   Windows

   .venv\Scripts\Activate.ps1

   Si PowerShell indique que l’exécution des scripts est désactivée, exécutez Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser une fois. Puis activez l’environnement de nouveau. Isoler les dépendances, dans le cours Python pour l’ingénierie de l’IA en pratique, explique cette erreur.

   Linux

   source .venv/bin/activate

   Si la sortie indique que ensurepip n’est pas disponible, exécutez d’abord sudo apt install python3-venv. Puis créez l’environnement de nouveau.

3. Vérifiez que l’invite de commande commence par (.venv). À partir de maintenant, tapez python sur tous les systèmes.

Installer les paquets

1. Dans VS Code, ouvrez le dossier ticket-model (File › Open Folder — fichier › ouvrir un dossier).

2. Créez-y un fichier requirements.txt avec ces quatre lignes :

   requirements.txt

   pandas==3.0.6
   scikit-learn==1.9.1
   matplotlib==3.11.2
   ipykernel

3. Enregistrez le fichier.

4. Dans le terminal, installez les paquets :

   python -m pip install -r requirements.txt

   Cela prend une ou deux minutes. La dernière ligne commence par Successfully installed (installation réussie). La liste comprend pandas-3.0.6 et scikit-learn-1.9.1. Si pip indique aussi qu’une nouvelle version de pip est disponible, vous pouvez ignorer ce message.

5. Vérifiez les versions :

   python -c "import pandas, sklearn; print(pandas.__version__, sklearn.__version__)"

   Vous devriez voir 3.0.6 1.9.1.

Voici le rôle de chaque ligne : pandas lit et modifie les tableaux. scikit-learn fournit les modèles et les métriques. matplotlib trace les graphiques dans les carnets. ipykernel permet à VS Code d’exécuter un carnet avec le Python de cet environnement. Les trois premiers ont une version exacte (==), pour que vos nombres correspondent à ceux des leçons. Au module 8, vous ajouterez deux autres versions exactes, car un modèle enregistré en a besoin.

Télécharger les données

Le script get_data.py de Mei télécharge les huit fichiers de données et vérifie la somme de contrôle de chacun. Il utilise seulement la bibliothèque standard de Python.

1. Téléchargez le script dans le dossier du projet :

   macOS

   curl -fsSL -O https://raw.githubusercontent.com/Nextia-Intelligence/nextia-learning-labs/main/C05/get_data.py

   Windows

   curl.exe -fsSL -O https://raw.githubusercontent.com/Nextia-Intelligence/nextia-learning-labs/main/C05/get_data.py

   Tapez curl.exe, pas curl. Dans Windows PowerShell, curl est une autre commande.

   Linux

   curl -fsSL -O https://raw.githubusercontent.com/Nextia-Intelligence/nextia-learning-labs/main/C05/get_data.py

   Si la sortie est curl: command not found (commande curl introuvable), exécutez d’abord sudo apt install curl (ou sudo dnf install curl).

2. Exécutez-le :

   python get_data.py

   La sortie :

   Downloaded train.csv
   Downloaded valid.csv
   Downloaded test.csv
   Downloaded split_manifest.json
   Downloaded extra_features.csv
   Downloaded daily_tickets.csv
   Downloaded july_tickets.csv
   Downloaded july_labels.csv
   Ready: train 16939 rows (1983 escalated), valid 1179 (183), test 1002 (157).

3. Exécutez-le une deuxième fois. Il affiche maintenant seulement la ligne Ready: (prêt), car tous les fichiers sont présents et corrects.

La dernière ligne sert de vérification. Les données d’entraînement comptent 16 939 billets de soutien, dont 1 983 transférés à l’équipe spécialisée. Les données de mai en comptent 1 179, dont 183 transférés, et celles de juin, 1 002, dont 157 transférés. Si un fichier est endommagé ou différent, get_data.py le télécharge de nouveau.

Ouvrir un carnet dans VS Code

Les carnets des leçons fonctionnent aussi sur votre ordinateur, avec l’environnement que vous venez de créer.

1. Dans VS Code, installez les extensions Python et Jupyter de Microsoft (View › Extensions — affichage › extensions, puis cherchez chaque nom).
2. Créez un dossier notebooks dans le projet.
3. Téléchargez-y le carnet d’une leçon. Utilisez View on GitHub (voir sur GitHub) dans l’encadré du carnet, puis le bouton de téléchargement.
4. Ouvrez le carnet dans VS Code.
5. Sélectionnez Select Kernel › Python Environments (sélectionner le noyau › environnements Python), puis l’entrée contenant .venv.
6. Exécutez les cellules depuis le début, comme dans Colab.

Les cellules de préparation d’un carnet travaillent dans leur propre dossier ticket-model, à côté du carnet. Elles y téléchargent leur propre copie des données. Chaque carnet reste ainsi autonome et ne modifie jamais le dossier data/ de votre projet.

Pour vérifier l’environnement dans un carnet, créez un carnet avec File › New File (fichier › nouveau fichier), puis Jupyter Notebook (carnet Jupyter). Enregistrez-le dans le dossier du projet, sélectionnez le noyau .venv et exécutez cette cellule :

import pandas as pd, sklearn
print("pandas", pd.__version__, "  scikit-learn", sklearn.__version__)
train = pd.read_csv("data/train.csv")
print(len(train), "train tickets,", train["escalated_72h"].sum(), "escalated")

La sortie :

pandas 3.0.6   scikit-learn 1.9.1
16939 train tickets, 1983 escalated

Si vous voyez ModuleNotFoundError: No module named 'sklearn' (aucun module nommé sklearn), le carnet utilise un autre Python. Sélectionnez de nouveau le noyau .venv (étape 5). Si vous voyez FileNotFoundError (fichier introuvable) pour data/train.csv, le carnet n’est pas dans le dossier du projet. Enregistrez-le dans ticket-model, à côté de data/.

Ou utiliser Colab ou Kaggle

Vous n’avez besoin d’aucune des étapes précédentes pour les carnets des leçons. Dans l’encadré du carnet, sélectionnez Open in Colab (ouvrir dans Colab, avec un compte Google gratuit). Ou sélectionnez Open in Kaggle (ouvrir dans Kaggle, avec un compte Kaggle gratuit). Les premières cellules installent les mêmes versions de pandas et de scikit-learn et téléchargent les données. Dans Kaggle, activez d’abord Internet dans les paramètres du carnet. Kaggle demande un numéro de téléphone vérifié pour cela.

Réinitialiser le projet

Pour revenir à un état connu :

• Données : exécutez python get_data.py --reset. Cette commande supprime data/ et télécharge tous les fichiers de nouveau. La dernière ligne est la ligne Ready: présentée plus haut.
• Environnement : fermez le terminal, supprimez le dossier .venv et refaites Créer l’environnement et Installer les paquets. requirements.txt reste en place.
• Un fichier de projet d’une leçon ultérieure : copiez le fichier terminé du cours depuis C05/project. Son README indique quelle leçon crée chaque fichier.

Pratique guidée : les références de base dans le carnet

1. Ouvrez le carnet depuis l’encadré Faire cette leçon dans un carnet en haut de cette page. Ou ouvrez-le dans VS Code avec le noyau .venv, comme dans Ouvrir un carnet dans VS Code.
2. Exécutez les cellules de préparation. La cellule des données se termine par la ligne Ready:.
3. Dans la section 1, calculez à la main l’exactitude des deux références de base sur les dix billets. Puis exécutez la cellule. Vous voyez 0.8 pour la majorité et 0.7 pour la règle.
4. Dans la section 2, exécutez le score constant sur les dix billets. Vous voyez ROC AUC: 0.5 (aire sous la courbe ROC) et Average precision: 0.2 (précision moyenne).
5. Dans la section 3, écrivez votre prédiction, puis exécutez les vraies références de base. Pour la majorité, vous voyez une exactitude de 0.845 et un rappel de 0.000. Pour la règle, vous voyez 163 billets signalés et un rappel de 0.333.
6. Exécutez le score constant sur les données de mai. Vous voyez Average precision: 0.155.
7. Dans la section 4, exécutez meets_target(). Vous voyez Rule meets the target: False (la règle atteint l’objectif : faux).

À vous de jouer : la règle de Grace

Changez une seule chose : la règle. Grace dit : « Depuis la nouvelle politique de garantie du 1er mai, les billets de garantie sont plus souvent transférés. Signalez les billets de priorité 1 ou de garantie. » Avant de l’exécuter, faites une prédiction : détectera-t-elle plus de transferts que la règle de priorité 1? Respectera-t-elle la capacité? Dans la section 5 du carnet, créez grace_flags, calculez son flag_report et exécutez la cellule de vérification.

Afficher la réponse

grace_flags = (valid["priority"] == 1) | (valid["team"] == "warranty")
grace = flag_report(y, grace_flags)
print(grace)
print("Meets the target:", meets_target(grace))

{'flagged': 312, 'share flagged': 0.265, 'caught': 98, 'false alarms': 214, 'missed': 85, 'correctly left': 782, 'precision': 0.314, 'recall': 0.536, 'accuracy': 0.746}
Meets the target: False

La règle de Grace détecte 98 des 183 transferts : un rappel de 0,536, supérieur à l’objectif de 40 %. Mais elle signale 312 billets, soit 26,5 %, plus que l’équipe spécialisée peut examiner. Elle n’atteint donc pas l’objectif. Une règle signale les billets qui correspondent à ses critères. Vous ne pouvez pas lui faire signaler exactement 20 % des billets. Un modèle donne un score, et vous pouvez fixer un seuil à n’importe quel niveau. Le compromis entre précision et rappel montre comment faire. Seuils et calibration choisit le seuil qui respecte les 20 %.

Le carnet contient une cellule facultative pour votre propre règle. Essayez-en une ou deux au maximum. Chaque règle testée sur les billets de mai et retenue pour son bon résultat rend les nombres de mai un peu trop favorables. Données d’entraînement, de validation et de test explique pourquoi.

Erreur courante

L'exactitude choisit la référence de base inutile

Symptôme : Tomás compare les trois règles selon l’exactitude, « la mesure standard », et recommande la première :

                        flagged  recall  accuracy
never escalate                0   0.000     0.845
priority 1                  163   0.333     0.810
priority 1 or warranty      312   0.536     0.746

Exactitude de trois règles sur les 1 179 billets de mai. La règle qui ne signale jamais rien arrive première.

Description textuelle du graphique

Un graphique à trois colonnes sur un axe de 0 à 100 %. Ne jamais transférer : 84,5 %. Signaler la priorité 1 : 81,0 %. Signaler la priorité 1 ou la garantie : 74,6 %. La règle qui ne signale rien a la meilleure exactitude.

Transferts détectés par les trois mêmes règles. L'ordre est inversé.

Description textuelle du graphique

Un graphique en colonnes montre les transferts signalés par chaque règle, sur les 183 de mai. Ne jamais transférer en détecte 0. Signaler la priorité 1 en détecte 61. Signaler la priorité 1 ou la garantie en détecte 98. L’ordre est l’inverse du classement par exactitude.

Cause : 84,5 % des billets de mai n’ont pas été transférés. Une règle qui dit toujours « non » a raison pour tous ces billets. L’exactitude compte chaque « non » correct, mais la décision de Grace porte sur les « oui ». Quand une réponse est rare, l’exactitude mesure surtout la réponse fréquente. Les métriques de classification explique ce piège en détail.

Correction : choisissez les mesures selon la décision, comme dans Traduire un besoin. Pour Larkfield : la proportion signalée par rapport à la capacité, ainsi que le rappel et la précision des signalements. Pour les scores, utilisez AP et ROC AUC. Présentez toujours les références de base à côté d’un résultat.

Conséquence dans le travail en IA : une équipe qui optimise l’exactitude ici obtient un modèle qui ne signale presque rien. Elle annonce un nombre élevé, personne ne voit d’erreur et les transferts attendent dans la file normale comme avant. C’est l’erreur qui consiste à « optimiser une métrique qui ne correspond pas à la décision ». Elle revient au module 3.

Vérification des connaissances

Vérifiez votre compréhension

Un collègue annonce : notre modèle de transfert a une exactitude de 84 % en mai. Que demandez-vous avant de croire qu'il est utile?

Afficher la réponse

Demandez les références de base et les mesures de la décision. En mai, une règle qui ne signale rien a une exactitude de 84,5 % et ne détecte rien. Une exactitude de 84 % peut donc être pire que ne rien faire. Demandez quelle proportion des billets le modèle signale (au plus 20 %). Demandez combien de transferts il détecte (son rappel, au moins 40 %). Demandez combien de ses signalements sont corrects (sa précision). Comparez ces résultats avec la règle « signaler la priorité 1 » : 13,8 % signalés, rappel de 0,333, précision de 0,374.

Vérifiez votre compréhension

La règle de Grace détecte 53,6 % des transferts de mai. Pourquoi n'atteint-elle pas l'objectif d'amélioration? Pourquoi un modèle avec un score peut-il l'atteindre?

Afficher la réponse

Elle signale 26,5 % des billets, plus que les 20 % que l’équipe spécialisée peut examiner. L’objectif a deux conditions, et la règle ne respecte pas celle de la capacité. Une règle est fixe : elle signale ce qui correspond à ses critères. Un modèle donne un score à chaque billet. Vous pouvez donc choisir le seuil qui correspond exactement à la capacité. La question devient alors : combien de transferts se trouvent dans ces 20 % les mieux classés?

Exercice du module

L’exercice du module vous demande une fiche de cadrage de modélisation d’une page pour le transfert des billets, avant tout modèle. Cette fiche rassemble toutes les décisions du module : la décision, la cible, les données, les coûts, les références de base et l’objectif d’amélioration. Grace, Omar et Tomás peuvent alors la lire et exprimer leurs désaccords avant qu’une personne travaille sur un modèle. Un désaccord sur une page coûte quelques minutes. Le même désaccord après deux semaines de modélisation coûte ces deux semaines.

Exemple détaillé : le gabarit

Copiez le gabarit dans un fichier reports/modelling-brief.md de votre projet ou dans la dernière cellule Markdown du carnet. Chaque partie demande une ou deux phrases, avec les nombres de ce module.

reports/modelling-brief.md

# Modelling brief: ticket escalation

| Part | Answer |
|---|---|
| Decision and owner | Who acts on the prediction, and what do they do? |
| Prediction unit | One prediction is about one … |
| Prediction time | When must the prediction exist? |
| Target | The exact definition, with its time window. |
| Features | The columns known at the prediction time. |
| Never features | The columns written after the prediction time. |
| Data and split | Which rows, which split, how many in each part. |
| Cost of a missed escalation | What happens to the customer? |
| Cost of an unnecessary review | What does it cost the team? |
| Capacity | How many flags can the team handle? |
| Baselines (on valid) | The numbers of the simple predictions. |
| Measures | Which measures, and why not accuracy. |
| Improvement target | The result that makes a model worth using. |
| Why not only a rule | What the best rule cannot do. |
| Risks | What can make the model worse in real use. |

Votre tâche : la fiche de cadrage du transfert des billets

Remplissez chaque partie pour le modèle de transfert de Larkfield. Utilisez les nombres de Traduire un besoin et de cette leçon. Puis comparez votre fiche avec celle de Priya. Vous pouvez utiliser d’autres mots. Vérifiez que les décisions et les nombres sont les mêmes.

Afficher la fiche de Priya

Partie	Réponse
Décision et responsable	Grace (responsable du soutien) en est responsable. Son équipe envoie un billet signalé directement à l’équipe spécialisée plutôt que dans la file normale.
Unité de prédiction	Un billet.
Moment de la prédiction	À la création du billet.
Cible	escalated_72h : 1 si un agent spécialisé a pris le billet dans les 72 heures après created_at, sinon 0.
Caractéristiques	Les 10 colonnes du cours SQL et préparation des données pour l’IA : channel, team, priority, segment, region, order_value, word_count, customer_tenure_days, prior_tickets_90d, created_hour. À tester au module 6 : prior_escalations_90d (connue à la création).
Variables à ne jamais utiliser	priority_now (le transfert la définit), customer_escalation_rate (utilise des cibles ultérieures) et toute valeur écrite après la création : première réponse, heure de fermeture, événements de résultat.
Données et séparation	L’exportation complète, séparée selon le temps comme dans le cours SQL et préparation des données pour l’IA. Entraînement : 16 939 billets, de juillet 2024 à avril 2026, 11,7 % transférés. Validation : 1 179, mai 2026, 15,5 %. Test : 1 002, du 1er au 27 juin 2026, 15,7 %. Les données de test servent une seule fois, à la fin.
Coût d’un transfert manqué	Le client attend dans la file normale, souvent une journée de plus. Certains clients quittent Larkfield.
Coût d’un examen inutile	Environ 10 minutes du temps d’un agent spécialisé et une place d’examen qu’un vrai transfert aurait pu prendre.
Capacité	Au plus 20 % des nouveaux billets : environ 7,6 billets par jour en mai.
Références de base (sur la validation)	Ne jamais transférer : exactitude de 0,845, rappel de 0. Score constant de 0,117 : ROC AUC de 0,5, AP de 0,155. Signaler la priorité 1 : 13,8 % signalés, précision de 0,374, rappel de 0,333.
Mesures	La proportion signalée (par rapport à la capacité), ainsi que le rappel et la précision à cette proportion. Pour les scores : AP et ROC AUC. Pas l’exactitude : ne jamais transférer donne la meilleure exactitude.
Objectif d’amélioration	Signaler au plus 20 % des nouveaux billets et détecter au moins 40 % des transferts. Vérifier sur la validation; confirmer une fois sur le test.
Pourquoi pas seulement une règle	La priorité 1 détecte 33 %. La priorité 1 ou la garantie détecte 53,6 %, mais signale 26,5 %, au-delà de la capacité. Une règle ne permet pas de fixer un seuil à exactement 20 %; un score le permet.
Risques	Le taux de transfert a augmenté après la politique de garantie du 1er mai 2026 (11,7 % à l’entraînement, 15,5 % en mai). Un modèle entraîné sur d’anciens billets peut donner des scores trop faibles. Les invités n’ont pas d’historique. Certains clients ont tendance à demander un transfert, et aucune colonne ne l’indique.

Une fiche complète contient trois éléments faciles à oublier. La cible a sa fenêtre de temps (72 heures). La capacité est un nombre. Les références de base sont des nombres, pas seulement des noms.

Vérification du module

Vérifiez votre compréhension

Rappel : nommez les trois références de base de ce module et donnez un nombre pour chacune sur les billets de mai.

Afficher la réponse

• Classe majoritaire, ne jamais transférer au niveau supérieur : exactitude de 0,845, rappel de 0. Aucun des 183 transferts n’est détecté.
• Score constant, le taux d’entraînement de 0,117 pour chaque billet : aire sous la courbe ROC de 0,5, précision moyenne de 0,155 (le taux de transfert de mai).
• Règle, signaler la priorité 1 : 163 billets signalés (13,8 %), précision de 0,374, rappel de 0,333.

Vérifiez votre compréhension

Prédire et expliquer : un premier modèle signale 19 % des billets de mai, avec un rappel de 0,38 et une précision de 0,37. Atteint-il la cible d'amélioration? Est-il meilleur que la règle qui signale la priorité 1?

Afficher la réponse

Il n’atteint pas la cible. Il respecte la capacité (19 % ne dépasse pas 20 %), mais son rappel de 0,38 est inférieur à 0,40. Son rappel est un peu meilleur que celui de la règle (0,38 contre 0,333). Mais il signale aussi plus de billets (19 % contre 13,8 %), avec à peu près la même précision. Le gain est donc faible, et une partie vient seulement du plus grand nombre de billets signalés. Priya ne l’utiliserait pas encore. Elle chercherait un modèle qui détecte au moins 40 % des transferts en respectant la limite de 20 %.

Vérifiez votre compréhension

Vérification finale : expliquez à Omar quelle action une prédiction permet chez Larkfield et ce que coûte chaque type d'erreur. Utilisez la capacité et les nombres de ce module.

Afficher la réponse

L’action : à la création d’un billet, un signalement l’envoie directement à l’équipe principale. Un client qui a un problème grave obtient alors un agent expérimenté dès le premier jour. Il n’attend pas dans la file normale.

Le coût d’un « non » incorrect (un transfert manqué) : le client attend, souvent une journée de plus, et certains clients quittent Larkfield. La règle « signaler la priorité 1 » manque 122 des 183 transferts de mai.

Le coût d’un « oui » incorrect (un examen inutile) : environ 10 minutes du temps d’un agent expérimenté. Il prend aussi une place d’examen qu’un vrai transfert aurait pu occuper. L’équipe principale peut examiner au plus 20 % des nouveaux billets, soit environ 7,6 par jour en mai. Les examens inutiles prennent donc la place des vrais transferts.

Ce que cela signifie pour le modèle : un transfert manqué coûte plus cher qu’un examen, mais la capacité est fixe. Le modèle doit donc détecter le plus de transferts possible en signalant au plus 20 % des billets. Il doit en détecter au moins 40 %, contre 33 % pour la règle. L’exactitude ne montre pas cela, car ne jamais transférer donne la meilleure exactitude (84,5 %).

Une réponse complète nomme l’action, les deux erreurs et leurs coûts, ainsi que la capacité, puis les relie aux mesures.

Récapitulatif

Dans ce module, vous avez transformé le besoin de Grace en problème de prédiction permettant d’évaluer un modèle :

• Le problème : un billet signalé va à l’équipe principale, dans une limite de 20 % des nouveaux billets. Un billet, à sa création, avec la cible escalated_72h et les 10 variables du cours SQL et préparation des données pour l’IA. Jamais priority_now ni customer_escalation_rate.
• Les références de base pour mai : ne jamais transférer donne une exactitude de 84,5 % et ne détecte rien. Un score constant donne une aire sous la courbe ROC de 0,5 et une précision moyenne (AP) de 0,155. La règle « signaler la priorité 1 » signale 13,8 % des billets, avec une précision de 0,374 et un rappel de 0,333.
• La cible d’amélioration : signaler au plus 20 % des billets et détecter au moins 40 % des transferts.
• Le projet : ~/projects/ticket-model avec .venv, requirements.txt, get_data.py et data/. Pour le réinitialiser, exécutez python get_data.py --reset, ou recréez .venv, comme dans Réinitialiser le projet.

Ensuite, dans le module 3, vous apprendrez comment évaluer un modèle avant d’en créer un. Première question : pourquoi faut-il tester un modèle sur des données qu’il n’a pas utilisées pour apprendre?

Leçon suivante : Données d'entraînement, de validation et de test