Traduire un besoin

Ce que vous saurez faire

Transformez un besoin d’affaires en problème de prédiction avant d’écrire le code d’un modèle. Précisez qui agit selon la prédiction, pour quelle unité, à quel moment et à partir de quels faits. Un modèle conçu pour un besoin flou peut obtenir un bon score sans aider personne. Et rien ne vous avertit.

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

Le carnet (notebook) Jupyter offre un premier aperçu des données en fonction de la décision. Il montre les lignes, le taux de transfert, la capacité quotidienne de l’équipe senior et un billet au moment de prédiction. Ses cellules de préparation installent pandas et scikit-learn et téléchargent les données d’exercice. Il ne nécessite donc aucune préparation locale. Environ 20 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 50 minutes

Ce que vous devez savoir

• Ce que sont un modèle, l’entraînement et une prédiction, dans Ce qu’est l’apprentissage automatique.
• Les caractéristiques et les étiquettes, dans L’apprentissage supervisé : caractéristiques et étiquettes.
• La classification, la régression et les cas où une règle suffit, dans Choisir la tâche d’apprentissage.
• La cible escalated_72h, le moment de prédiction et la fuite de données, dans Caractéristiques et moment de la cible du cours SQL et préparation des données pour l’IA. Les colonnes connues à la création d’un billet, dans Caractéristiques et moment de la cible : ce que chaque colonne sait.
• La séparation chronologique en données d’entraînement, de validation et de test, dans Choisir une séparation du cours de SQL.
• Le filtrage des lignes et groupby dans pandas, dans Transformer avec Python du cours de SQL.

Ce qu’il vous faut sur votre ordinateur (seulement pour travailler localement; le carnet n’en a pas besoin)

• Rien pour le moment. Vous créerez le dossier de projet ~/projects/ticket-model dans la prochaine leçon, Définir une référence de base : préparer votre projet. D’ici là, utilisez le carnet dans Colab ou Kaggle.
• Si vous avez déjà créé le projet, ses données doivent être complètes. Exécutez python get_data.py dans le dossier du projet. La dernière ligne doit être Ready: train 16939 rows (1983 escalated), valid 1179 (183), test 1002 (157). (prêt : nombre de lignes et de transferts dans chaque partie). Si elle est différente, exécutez python get_data.py --reset.

Le carnet a été testé dans Jupyter sur macOS. Il utilisait Python 3.14.6, pandas 3.0.6 et scikit-learn 1.9.1.

D’un besoin à une question

Un boulanger dit : « Je jette trop de pain chaque soir. » C’est un vrai besoin, mais personne ne peut encore en tirer un modèle. Un modèle donne des réponses. Vous devez donc savoir à quelle question il répond et ce que le boulanger fera de la réponse.

Vous posez donc quelques questions au boulanger. Que ferez-vous différemment? « Je cuirai moins de pains les jours tranquilles. » La prédiction doit donc indiquer combien de pains de chaque sorte se vendront un jour donné. Quand avez-vous besoin de la réponse? « À cinq heures du matin, avant d’allumer les fours. » La prédiction peut donc utiliser seulement les faits connus à cinq heures : jour de la semaine, prévisions météo, jour férié. Elle ne peut pas utiliser le nombre de pains vendus à midi. À cinq heures, ce nombre n’existe pas encore.

Sans ces questions, il est facile de construire la mauvaise chose. Supposons qu’une personne crée un modèle qui prédit le nombre de pains jetés à partir des ventes de la journée. Il pourrait obtenir un excellent score. Mais le boulanger ne peut pas l’utiliser à cinq heures du matin : les ventes de la journée sont encore inconnues. Le score est bon, le modèle est inutile, et rien dans le code ne le signale.

Cette leçon porte sur ces questions. Avant de créer un modèle, vous traduisez un besoin en cinq réponses : décision, unité de prédiction, cible, moment de prédiction et caractéristiques. Chaque réponse limite ce que le modèle peut faire. Vous les écrivez donc d’abord.

Le modèle de Larkfield et ses données

Vous avez découvert Larkfield dans Ce qu’est l’apprentissage automatique. C’est une boutique en ligne fictive de produits pour la maison et le jardin. Les clients contactent le soutien, et chaque contact devient un billet de soutien. Dans le cours de SQL, vous avez préparé les données du service de soutien de Larkfield pour un modèle. Dans ce cours, vous entraînez ce modèle, le testez honnêtement et le transmettez. Les données sont inventées pour ce cours; elles ne représentent aucune personne réelle.

Les données sont maintenant plus nombreuses. Le cours de SQL utilisait un échantillon exporté de 240 clients sur six mois. Cela suffisait pour pratiquer la préparation des données, mais le mois de validation comptait seulement 45 transferts à l’équipe senior. Avec si peu de transferts, toute différence entre deux modèles était plus faible que le bruit. Mei, l’ingénieure de données, a donc appliqué la même préparation à l’exportation complète : environ 1 000 clients sur deux ans, de juillet 2024 à juin 2026. Les colonnes, la cible et la règle de séparation restent celles de la fin du cours de SQL. Les identifiants de billets ont maintenant six chiffres (T-100001) et ceux des clients, cinq (C-00001). Vous ne pouvez donc pas confondre les deux jeux de données.

Vous avez rencontré la plupart des membres de l’équipe dans le module 1. Ce sont les mêmes personnes que dans le cours de SQL. Priya vous guide dans le cours. Les autres apportent chacun leur point de vue :

Personne	Rôle	Dans ce cours
Priya	Scientifique de données	Entraîne et évalue le modèle. Elle vous guide dans le cours.
Grace	Responsable du soutien	Est responsable de la décision. Elle connaît la capacité de l’équipe senior et le coût d’une erreur.
Mei	Ingénieure de données	A préparé les données et est responsable de get_data.py.
Tomás	Ingénieur en IA	Veut le modèle le plus complexe et le meilleur score. Il propose souvent un raccourci.
Omar	Gestionnaire de produit	Demande ce qu’un nombre signifie pour les clients et pour l’entreprise.

Partir de la décision

Grace décrit le problème dans ses propres mots :

« Certains billets ont besoin d’un agent senior. Quand on s’en rend compte tard, le client a déjà attendu une journée dans la file normale. Je veux que ces billets arrivent à l’équipe senior dès leur réception. »

Comme les paroles du boulanger, c’est un besoin, pas encore un problème de prédiction. Priya le transforme en cinq réponses, une à la fois.

D’abord, la décision : l’action qu’une personne change à cause de la prédiction. Ici, l’équipe de Grace envoie un billet signalé directement à l’équipe senior, plutôt que dans la file normale. Une prédiction qui ne change aucune action n’a aucune valeur, même avec un bon score. La décision impose aussi une limite : l’équipe senior peut examiner au plus 1 nouveau billet sur 5 (20 %).

Ensuite, l’unité de prédiction : ce sur quoi porte une prédiction. L’équipe de Grace traite un billet à la fois. L’unité est donc un billet, et les données contiennent une ligne par billet.

Troisièmement, la cible : ce que le modèle apprend précisément à prédire. Dans L’apprentissage supervisé, vous l’appeliez l’étiquette. Ici, c’est escalated_72h : 1 si un agent senior a pris le billet dans les 72 heures suivant sa création, sinon 0. Les 72 heures rendent la cible précise, pour que tout le monde compte les mêmes billets.

Quatrièmement, le moment de prédiction : le moment où le modèle doit donner sa réponse. Grace veut orienter le billet dès son arrivée. Le moment de prédiction est donc celui de la création du billet. Plus tard, c’est trop tard pour la décision.

Cinquièmement, les caractéristiques : les faits que le modèle peut utiliser comme entrées. Chaque caractéristique doit être connue au moment de prédiction. Cette règle donne les 10 colonnes de caractéristiques du cours de SQL, toutes présentes à la création d’un billet.

Les cinq réponses tiennent dans un tableau :

Question	Réponse de Larkfield
Décision : que fait une personne différemment à cause de la prédiction?	L’équipe de Grace envoie un billet signalé directement à l’équipe senior. L’équipe senior peut examiner au plus 1 nouveau billet sur 5 (20 %).
Unité de prédiction : une prédiction porte sur un…	billet.
Cible : que prédit-on exactement?	escalated_72h : 1 si un agent senior a pris le billet dans les 72 heures suivant sa création, sinon 0.
Moment de prédiction : quand la prédiction doit-elle exister?	À la création du billet.
Caractéristiques : quels faits le modèle peut-il utiliser?	Seulement les faits connus au moment de prédiction : les 10 colonnes de caractéristiques du cours de SQL.

Un billet au moment de prédiction

Pour rendre le moment de prédiction concret, regardez une vraie ligne des données. Le billet T-116944 est le premier billet de mai 2026 transféré à l’équipe senior. Un client l’a envoyé par le formulaire Web à 7 h 47 le 1er mai. Le tableau montre chaque valeur et indique si elle existe à 7 h 47 :

Colonne	Valeur	Connue à 7 h 47 le 1er mai?
created_at	2026-05-01 07:47:30	Oui : le moment de prédiction
channel, team, priority	web_form, warranty, 2	Oui
segment, region	trade, west	Oui : dans le dossier du client
order_value, word_count	549.72, 86	Oui
customer_tenure_days, prior_tickets_90d, created_hour	1887, 2, 7	Oui
escalated_72h	1	Non. Connue seulement après 72 heures.

À 7 h 47, le modèle voit toutes les lignes sauf la dernière. À partir de ces faits, il doit dire « envoyer à l’équipe senior » ou « file normale ». Notez la priorité : 2, pas 1. Une règle simple, « envoyer les billets de priorité 1 à l’équipe senior », ne signalerait pas ce billet.

De la décision à la métrique

Une fois la décision claire, elle indique aussi comment juger le modèle. Une métrique est un nombre qui mesure la qualité des prédictions. Choisissez la métrique selon la décision, pas par habitude. Le schéma suit cet enchaînement pour Larkfield.

La décision fixe l'unité, le moment et la cible. Les deux types d'erreurs et leurs coûts déterminent les métriques.

Description textuelle du diagramme

L’enchaînement commence par la décision : l’équipe de Grace envoie un billet signalé à l’équipe senior. La décision fixe la prédiction : un billet, à sa création. La prédiction fixe la cible, escalated_72h : le billet a-t-il été transféré dans les 72 heures? La sortie du modèle devient un signalement, oui ou non, pour chaque nouveau billet. Un signalement peut être erroné de deux façons. Un « non » erroné est un transfert manqué : le client attend environ une journée de plus. Un « oui » erroné est un examen inutile : environ 10 minutes d’un agent senior. Le rappel compte les transferts manqués, et la précision compte les examens inutiles. Les deux mènent aux métriques. La proportion de billets signalés doit être d’au plus 20 %, et le rappel, d’au moins 40 %. Priya rapporte aussi la précision des signalements.

Chaque signalement est correct ou erroné, et un signalement erroné peut l’être de deux façons. Un transfert manqué est un billet que le modèle n’a pas signalé, mais qui a été transféré à l’équipe senior. Le client ayant un problème sérieux attend dans la file normale, souvent une journée de plus. Certains de ces clients quittent Larkfield. Un examen inutile est un billet que le modèle a signalé, mais qui n’a pas été transféré. Un agent senior ouvre alors un billet qu’un agent ordinaire aurait pu résoudre, ce qui coûte environ 10 minutes. Voici les estimations de Grace, côte à côte :

Erreur	Ce qui se passe	Coût
Transfert manqué (non signalé, mais transféré)	Le client ayant un problème sérieux attend dans la file normale.	Souvent une journée de plus. Certains de ces clients quittent Larkfield.
Examen inutile (signalé, mais non transféré)	Un agent senior ouvre un billet qu’un agent ordinaire aurait pu résoudre.	Environ 10 minutes d’un agent senior.

Un transfert manqué coûte beaucoup plus qu’un examen inutile. Omar demande donc : « Pourquoi ne pas signaler tous les billets? Comme ça, on ne manque rien. » La réponse est la capacité. L’équipe senior peut examiner au plus 20 % des nouveaux billets. Chaque examen inutile prend une place qu’un vrai transfert aurait pu occuper. La question pour le modèle est donc : en signalant au plus 20 % des billets, combien de transferts peut-il détecter? Deux nombres y répondent, et chacun compte un type d’erreur :

• Le rappel répond à la question « parmi les billets transférés, combien avons-nous signalés? » Un transfert manqué le réduit.
• La précision répond à la question « parmi les billets signalés, combien ont vraiment été transférés? » Un examen inutile la réduit.

Dans la prochaine leçon, vous mesurez les deux pour des règles simples. Vous voyez aussi d’où vient le 40 % du schéma. Les métriques de classification les explique en détail, avec leurs formules.

Exemple détaillé : le premier aperçu des données

Priya examine maintenant les données à partir des cinq réponses. Chaque bloc de code ci-dessous est une cellule du carnet de la leçon. Ses cellules de préparation ont déjà chargé pandas sous le nom pd. D’abord, elle charge les trois parties de la séparation. Sa fonction read() conserve le texte unknown (inconnu) comme catégorie. Ainsi, seule une cellule vide devient une valeur manquante. (Dans le module 4, read() passe dans le fichier ticket_model.py.)

def read(path):
    """Read a ticket file. Only an empty cell is missing: "unknown" stays a category."""
    return pd.read_csv(path, parse_dates=["created_at"], dtype={"customer_id": "string"},
                       keep_default_na=False, na_values=[""])


train = read("data/train.csv")
valid = read("data/valid.csv")
test = read("data/test.csv")
for name, part in [("train", train), ("valid", valid), ("test", test)]:
    first, last = part["created_at"].min().date(), part["created_at"].max().date()
    print(f"{name}: {len(part)} tickets, {part['escalated_72h'].sum()} escalated "
          f"({part['escalated_72h'].mean():.1%}), {first} to {last}")

La sortie :

train: 16939 tickets, 1983 escalated (11.7%), 2024-07-01 to 2026-04-30
valid: 1179 tickets, 183 escalated (15.5%), 2026-05-01 to 2026-05-31
test: 1002 tickets, 157 escalated (15.7%), 2026-06-01 to 2026-06-27

Environ 1 billet d’entraînement sur 8 a été transféré à l’équipe senior. En mai et juin, le taux est plus élevé. Une nouvelle politique de garantie est entrée en vigueur le 1er mai 2026 (vous l’avez découverte dans le cours de SQL). La séparation suit la même règle que dans le cours de SQL. L’entraînement couvre le passé, les données de validation couvrent mai, et les données de test couvrent juin. Les données excluent les 28, 29 et 30 juin, car ces cibles n’étaient pas définitives au moment de l’exportation. Données d’entraînement, de validation et de test explique le rôle de chaque partie.

Ensuite, Priya convertit la capacité de Grace en nombre de billets par jour, pour mai. Une proportion comme 20 % est difficile à imaginer. L’équipe senior ressent plutôt le nombre de billets par jour :

days = valid["created_at"].dt.date.nunique()
per_day = len(valid) / days
print("May:", days, "days,", round(per_day, 1), "new tickets per day")
print("Capacity, 20% of new tickets:", round(0.2 * per_day, 1), "tickets per day")
print("Escalations per day in May:", round(valid["escalated_72h"].sum() / days, 1))

La sortie :

May: 31 days, 38.0 new tickets per day
Capacity, 20% of new tickets: 7.6 tickets per day
Escalations per day in May: 5.9

L’équipe senior peut examiner environ 7 ou 8 nouveaux billets par jour, et environ 6 billets par jour sont transférés. Une liste parfaite de signalements respecterait donc la capacité. Un vrai modèle fait toutefois des erreurs. Chaque examen inutile occupe une des 7 ou 8 places.

Enfin, Priya vérifie les colonnes qui ne sont pas des caractéristiques. Le fichier extra_features.csv contient quatre colonnes supplémentaires pour chaque billet. Pour T-116944 :

extra = pd.read_csv("data/extra_features.csv")
extra[extra["ticket_id"] == "T-116944"].T

La sortie :

                             16943
ticket_id                 T-116944
prior_escalations_90d            0
order_value_band              high
customer_escalation_rate    0.1739
priority_now                     1

Pour chaque colonne, elle pose une question : quand cette valeur est-elle écrite? Si elle est écrite avant le billet ou à sa création, le modèle peut l’utiliser. Si elle est écrite plus tard, le modèle ne peut pas la connaître à 7 h 47 :

Colonne	Moment où elle est écrite	Caractéristique?
prior_escalations_90d	Avant le billet : les transferts du client dans les 90 jours précédents.	Oui. Sélectionner les caractéristiques utiles la teste.
order_value_band	À la création : none, low, mid ou high (aucune, faible, moyenne ou élevée), selon order_value.	Permise, mais elle répète order_value.
customer_escalation_rate	Après l’exportation : le taux du client sur tous ses billets, y compris les billets ultérieurs.	Jamais. Elle contient des cibles ultérieures.
priority_now	Pendant le traitement du billet. Le service de soutien lui donne la valeur 1 quand un billet est transféré.	Jamais. Le transfert écrit cette valeur.

priority_now vaut 1 pour T-116944, mais sa priority à la création était 2. L’exportation connaît l’avenir de chaque billet. Le modèle, à 7 h 47, ne le connaît pas.

Exercice guidé : le premier aperçu

Faites l’exemple détaillé dans le carnet. Vous n’avez pas besoin d’un projet local.

1. Ouvrez le carnet à partir de l’encadré Faites cette leçon dans un carnet Jupyter, en haut de cette page.
2. Exécutez les cellules de préparation depuis le début. La dernière ligne de la cellule des données est Ready: train 16939 rows (1983 escalated), valid 1179 (183), test 1002 (157).
3. Dans la section 2, écrivez votre prédiction du taux de transfert, puis exécutez la cellule. Vous voyez 11.7% pour l’entraînement et 15.5% pour la validation.
4. Exécutez la cellule de capacité. Vous voyez 7.6 billets par jour.
5. Dans la section 3, exécutez les deux cellules pour T-116944. Vous voyez la priorité 2 dans sa ligne et priority_now = 1 dans les colonnes supplémentaires.
6. Dans la cellule Your turn (à vous de jouer), mettez les noms des colonnes supplémentaires connues à la création dans known_at_creation.
7. Exécutez la cellule de vérification. Elle affiche Check passed (vérification réussie) quand votre liste est correcte.

Afficher la réponse à l’étape 6

known_at_creation = ["prior_escalations_90d", "order_value_band"]

Les deux valeurs existent à la création du billet. customer_escalation_rate et priority_now sont écrites plus tard.

À vous de jouer : une autre décision

Changez une chose : la décision. Omar, le gestionnaire de produit, demande : « Combien de billets arriveront demain? Je planifie les quarts des agents la veille au soir. » Écrivez les cinq réponses pour la décision d’Omar. Dans le carnet (notebook) Jupyter, section 5, chargez data/daily_tickets.csv et calculez le nombre moyen de billets par jour.

Afficher la réponse

Question	Décision d’Omar
Décision	Omar prévoit combien d’agents travailleront demain.
Unité de prédiction	Un jour, pas un billet.
Cible	Le nombre de billets créés ce jour-là (tickets dans daily_tickets.csv).
Moment de la prédiction	La veille au soir.
Caractéristiques	Les faits connus la veille au soir : le jour de la semaine, si c’est la fin de semaine, le mois. Pas les billets du jour lui-même.

La moyenne est de 26,35 billets par jour, sur 730 jours. Le coût d’une erreur change aussi : trop peu d’agents entraîne de longues attentes; trop d’agents entraîne des heures payées sans travail. Une nouvelle décision donne donc une nouvelle unité, une nouvelle cible et de nouveaux coûts. La cible est maintenant un nombre, pas un oui ou un non. C’est donc une tâche de régression, comme dans Choisir la tâche d’apprentissage.

Erreur courante

Une colonne qui vient du futur

Symptôme : Tomás compte les transferts à l’équipe spécialisée pour chaque valeur de priority_now dans les données d’entraînement. Chacun des 1 983 transferts a priority_now = 1. « Cette colonne les trouve tous. Utilisons-la. »

              size   sum  mean
priority_now
1             3814  1983  0.52
2             5140     0  0.00
3             7985     0  0.00
Escalations with priority_now = 1: 1983 of 1983

Cause : priority_now ne prédit pas le transfert; cette colonne l’enregistre. Le service de soutien lui donne la valeur 1 quand un agent expérimenté prend le billet. Au moment de la prédiction, personne n’a encore transféré le billet. priority_now a donc la même valeur que priority. En mai, seulement 61 des 183 billets transférés avaient la priorité 1 à leur création.

Correction : pour chaque colonne, demandez : « Quand cette valeur est-elle enregistrée? » Gardez seulement les colonnes connues au moment de la prédiction. Une colonne qui trouve tous les cas est un signal d’alerte, pas un cadeau.

Conséquence dans le travail en IA : un modèle qui utilise cette colonne obtient un excellent score à l’évaluation. En utilisation réelle, la colonne ne contient aucune information utile. Le modèle trouve donc environ un transfert sur trois. Ce n’est pas mieux qu’une règle simple, et tout le monde s’attendait à beaucoup mieux. C’est une fuite de données, que vous avez vue dans le cours SQL et préparation des données pour l’IA. Dans Sélectionner les caractéristiques utiles, vous mesurez son effet sur le score d’un modèle.

Vérification des connaissances

Vérifiez votre compréhension

Donnez les cinq réponses de Larkfield : la décision, l'unité de prédiction, la cible, le moment de la prédiction et les caractéristiques.

Afficher la réponse

• Décision : l’équipe de Grace envoie un billet signalé directement à l’équipe spécialisée, qui peut examiner au plus 20 % des nouveaux billets.
• Unité de prédiction : un billet.
• Cible : escalated_72h, soit 1 si un agent expérimenté a pris le billet dans les 72 heures suivant sa création, sinon 0.
• Moment de la prédiction : à la création du billet.
• Caractéristiques : seulement les faits connus à la création : les 10 colonnes de variables du cours SQL et préparation des données pour l’IA.

Vérifiez votre compréhension

Prédisez : Tomás ajoute customer_escalation_rate (le taux de transfert du client sur l'ensemble de ses billets) comme variable. Est-elle connue au moment de la prédiction? Que devient le score d'évaluation, et que se passe-t-il en utilisation réelle?

Afficher la réponse

Elle n’est pas connue au moment de la prédiction. Elle provient de tous les billets du client, y compris ceux créés plus tard. Elle contient donc leurs cibles, et parfois la cible du billet lui-même. Le score d’évaluation augmente, car la colonne contient une partie de la réponse. En utilisation réelle, les billets ultérieurs n’existent pas encore. Le modèle fonctionne donc moins bien que son score le laissait croire. Sélectionner les caractéristiques utiles mesure cet effet : le score dépasse largement celui d’une évaluation honnête.

Vérifiez votre compréhension

Quelle action le signalement permet-il chez Larkfield? Que coûte chaque type d'erreur, et pourquoi Grace ne peut-elle pas simplement signaler tous les billets?

Afficher la réponse

Un signalement envoie le billet directement à l’équipe spécialisée. Un problème sérieux reçoit donc de l’aide dès le premier jour. Un transfert manqué laisse le client dans la file normale, souvent une journée de plus, et certains clients partent. Un examen inutile coûte environ 10 minutes à un agent expérimenté. Un transfert manqué coûte plus cher, mais l’équipe spécialisée peut examiner au plus 20 % des nouveaux billets. Cela représente environ 7,6 billets par jour en mai. Chaque examen inutile prend une place qu’un véritable transfert aurait pu occuper.

Récapitulatif

• Un besoin n’est pas encore un problème de prédiction. Avant tout modèle, écrivez cinq réponses : la décision, l’unité de prédiction, la cible, le moment de la prédiction et les caractéristiques.
• Pour Larkfield : un billet signalé va à l’équipe spécialisée, au plus 20 % des nouveaux billets. Un billet, à sa création, avec la cible escalated_72h et les 10 caractéristiques du cours SQL et préparation des données pour l’IA.
• L’exportation complète contient 16 939 billets d’entraînement (11,7 % transférés), 1 179 en mai (15,5 %) et 1 002 en juin (15,7 %). L’équipe spécialisée peut examiner environ 7,6 billets par jour en mai.
• Un transfert manqué coûte environ une journée au client; un examen inutile coûte environ 10 minutes. La capacité limite le nombre d’examens. Les questions sont donc : en signalant au plus 20 % des billets, combien de transferts détectons-nous (rappel)? Combien de signalements sont corrects (précision)?
• Une colonne enregistrée après le moment de la prédiction, comme priority_now, peut sembler parfaite. À la création, elle trouve seulement 61 des 183 transferts.

Ensuite, vous mesurez les prédictions les plus simples, sans modèle, et fixez le résultat qu’un modèle doit dépasser.

Leçon suivante : Définir une référence de base