Les éléments d'un jeu de données

Ce que vous saurez faire

Avant de compter, joindre ou nettoyer quoi que ce soit, vous devez savoir ce que représente une ligne de chaque table. Si vous vous trompez, tous les nombres qui suivent seront faux, sans qu’aucune erreur vous avertisse.

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

Le carnet (notebook) Jupyter contient chaque requête, tâche et vérification de cette leçon, avec les consignes. Sa première cellule télécharge les données d’exercice et crée la base de données. Vous n’avez donc rien à installer sur votre ordinateur. Lisez les explications ici et exécutez le code dans le carnet.

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 40 minutes

Ce que vous devez savoir

• Ce qu’est un fichier CSV, avec Lire et écrire des fichiers : CSV et JSON dans Python pour l’ingénierie de l’IA en pratique. Vous n’avez pas besoin de connaître SQL.
• Pour le carnet : exécutez les cellules dans l’ordre après un redémarrage, comme dans De la rigueur dans le carnet : redémarrer et tout exécuter.

Ce qu’il vous faut sur votre ordinateur

• Rien. Les blocs SQL de cette leçon s’exécutent dans votre navigateur; la première exécution charge environ 1 Mo. Le carnet du bloc ci-dessus s’exécute dans Colab ou Kaggle. Vous créerez la base de données sur votre ordinateur dans Préparer une base de données d’exercice, la dernière leçon de ce module.
• Les données sont inventées pour ce cours. Elles ne contiennent aucune personne ni entreprise réelle.

Les blocs du navigateur utilisent SQLite 3.49.1. Le carnet a été testé dans Jupyter.

L’exportation du service de soutien

Larkfield est une boutique en ligne fictive de produits pour la maison et le jardin. Quand un client a un problème, il contacte l’équipe de soutien. Le système du service de soutien enregistre alors un billet de soutien. À l’arrivée d’un billet, Larkfield veut savoir s’il nécessitera un agent expérimenté dans les 72 heures. Le transfert d’un billet à un agent expérimenté est une escalade. La boutique peut ainsi envoyer ces billets à un agent expérimenté plus tôt.

Priya, une scientifique des données, entraînera un modèle pour cette tâche. Elle demande les données à Mei, l’ingénieure de données. Mei obtient une exportation : une copie des données du service de soutien, enregistrée dans des fichiers à un moment précis. L’exportation contient trois fichiers CSV :

Fichier	Ce qu’il contient
customers.csv	Les clients qui peuvent contacter le soutien
tickets.csv	Les billets : qui a demandé de l’aide, quand, par quel canal et à quel sujet
outcomes.csv	Ce qui est arrivé à chaque billet ensuite : résolution, escalade, réouverture

Mei charge les trois fichiers dans une base de données : un fichier contenant plusieurs tables et permettant de les interroger. Dans ce cours, la base de données est SQLite, qui conserve toute la base dans un seul fichier. Python inclut SQLite. Vous n’avez donc besoin ni de serveur ni de compte.

Lignes, colonnes et valeurs de quatre billets

Voici quatre billets de l’exportation, avec seulement cinq de leurs colonnes :

ticket_id	customer_id	created_at	channel	priority
T-10001	C-0228	2026-01-05 07:30:24	email	2
T-10002	C-0207	2026-01-05 09:09:23	email	3
T-10003	C-0119	2026-01-05 13:22:27	Email	2
T-10064	NULL	2026-01-13 11:42:05	email	2

• Une table est un ensemble de données en lignes et en colonnes, avec un nom. Celle-ci s’appelle tickets.
• Une ligne est une ligne de la table. Ici, chaque ligne décrit un billet. (Certains livres parlent d’« enregistrement » ou de « tuple ». Ces mots désignent aussi une ligne.)
• Une colonne a un nom et contient un même type d’information pour chaque ligne, par exemple channel.
• Une valeur est le contenu d’une colonne pour une ligne : le channel (canal) de T-10003 est Email (courriel).
• NULL signifie « aucune valeur ». Ce n’est ni zéro ni un texte vide. T-10064 n’a pas de client associé : il vient d’une personne qui a acheté sans compte.

Regardez encore T-10003. Son canal est Email, avec un E majuscule. Pour une personne, email (courriel) et Email sont identiques. Pour un ordinateur, ce sont deux valeurs différentes. Vous rencontrerez plusieurs problèmes discrets comme celui-ci dans le cours. Ici, vous ne faites que le remarquer.

Types, identifiants et horodatages

Chaque colonne a un type : le genre de valeur qu’elle contient. SQLite utilise quelques types simples :

Type	Contenu	Exemple de colonne	Exemple de valeur
TEXT	Lettres, chiffres et symboles	channel	email
INTEGER	Nombres entiers	priority	2
REAL	Nombres avec une partie décimale	order_value	47.25

La description de toutes les tables, de leurs colonnes et de leurs types est le schéma. Le schéma indique ce que les données peuvent contenir. Il n’indique pas ce qu’elles contiennent réellement. Pour le savoir, vous examinez les données.

Deux types de colonnes demandent une attention particulière :

• Un identifiant est une valeur qui désigne une chose, comme T-10001 pour un billet ou C-0228 pour un client. Vous ne faites pas de calculs avec les identifiants. Vous les utilisez pour trouver une chose et relier une ligne d’une table à une ligne d’une autre table. Dans tickets, customer_id indique quel client a ouvert le billet.
• Un horodatage indique quand quelque chose s’est produit, par exemple created_at. SQLite n’a pas de type particulier pour les dates. L’exportation écrit les horodatages sous forme de texte au format YYYY-MM-DD HH:MM:SS (année-mois-jour heures:minutes:secondes). Ainsi, 2026-01-05 07:30:24 correspond au 5 janvier 2026, à 7 h 30 du matin. Avec ce format, l’ordre du texte correspond aussi à l’ordre chronologique. Vous pouvez donc trier et comparer les horodatages comme du texte.

En IA, les horodatages comptent pour une deuxième raison. Ils indiquent quand une valeur était connue. Un modèle qui prédit à la création du billet peut utiliser seulement ce qui était connu à ce moment. Le module 5 s’appuie sur cette idée.

Exécuter votre première requête

Une requête est une question posée à la base de données, écrite en SQL (langage de requête structuré). Le bloc suivant demande toutes les colonnes (*) de la table tickets, mais seulement les 5 premières lignes (LIMIT 5).

Exécutez du SQL dans votre navigateur

Essayez : les cinq premiers billets

Appuyez sur Run (exécuter). Vous devriez voir 5 lignes et 11 colonnes. La première ligne est T-10001. Faites défiler vers la droite pour voir toutes les colonnes. Remplacez ensuite 5 par 10 et exécutez la requête de nouveau.

Requête SQL (vous pouvez la modifier)SELECT * FROM tickets LIMIT 5;

La table contient 11 colonnes. Certains noms sont clairs, comme team (équipe) et word_count (nombre de mots). D’autres demandent l’aide d’une personne qui connaît le service de soutien. Grace, la responsable du soutien, en explique trois :

• priority (priorité) est définie à l’arrivée du billet : 1 est la plus urgente, 3 la moins urgente.
• priority_now (priorité actuelle) est la priorité aujourd’hui. Elle peut changer après la création.
• closed_at (date de fermeture) indique quand le billet a été fermé. Sa valeur est NULL quand le billet est encore ouvert.

Mei note ces définitions. Les prochains modules les utilisent.

La première question : que représente une ligne?

La granularité d’une table est ce qu’une ligne représente. Posez cette question avant de compter quoi que ce soit. Examinez un petit échantillon de chaque table.

customers — une ligne représente un client.

customer_id	segment	region	joined_on
C-0001	home	north	2024-10-18
C-0002	home	west	2023-11-17
C-0003	trade	west	2025-09-27

tickets — une ligne représente un billet. Le client C-0001 a trois billets. C-0001 apparaît donc dans trois lignes ici :

ticket_id	customer_id	created_at	team
T-10270	C-0001	2026-02-08 14:01:04	warranty
T-10530	C-0001	2026-03-12 09:39:06	returns
T-10714	C-0001	2026-04-02 22:48:49	account

outcomes — une ligne représente un événement dans la vie d’un billet. Le billet T-10014 a été résolu, puis le client l’a rouvert, puis il a été résolu de nouveau. Cela fait trois événements, donc trois lignes :

outcome_id	ticket_id	recorded_at	status
O-00019	T-10014	2026-01-08 16:03:30	resolved
O-00028	T-10014	2026-01-09 17:26:31	reopened
O-00036	T-10014	2026-01-10 09:17:41	resolved

Les trois tables ont trois granularités différentes. Compter les lignes de outcomes, c’est compter des événements, pas des billets. Mei écrit la granularité de chaque table en haut de ses notes :

Table	Une ligne représente	Identifiant de la ligne
customers	un client	customer_id
tickets	un billet	ticket_id
outcomes	un événement dans la vie d’un billet	outcome_id

L’instantané

Le service de soutien change chaque minute. De nouveaux billets arrivent et des billets ouverts se ferment. L’exportation est un instantané : l’état des données à un moment précis. Elle ne contient rien de ce qui s’est produit après ce moment. La base de données contient une petite table qui enregistre ce moment.

Exécutez du SQL dans votre navigateur

Essayez : quand l'exportation a-t-elle été créée?

Exécutez la requête. Vous devriez voir 3 lignes. La ligne exported_at (date d’exportation) contient la valeur 2026-07-01 06:00:00.

Requête SQL (vous pouvez la modifier)SELECT * FROM snapshot;

L’instantané explique certaines valeurs. 12 billets ont la valeur NULL dans closed_at. Ils étaient encore ouverts à 6 h le 1 juillet. Ils peuvent se fermer plus tard, mais cette exportation ne peut pas le savoir. Si vous obtenez une nouvelle exportation le mois prochain, les nombres changeront. Notez donc le moment de l’instantané à côté de chaque nombre présenté : « 1 417 lignes de billets dans l’exportation du 1 juillet 2026 à 6 h ».

Exemple détaillé : quelle est la taille de chaque table?

Priya demande à Mei : « Quelle quantité de données avons-nous? » Mei compte les lignes de chaque table. COUNT(*) compte les lignes. Mei exécute une requête pour chaque table :

SELECT COUNT(*) FROM customers;   -- 240
SELECT COUNT(*) FROM tickets;     -- 1417
SELECT COUNT(*) FROM outcomes;    -- 1874

Elle ne s’arrête pas aux nombres. Elle interprète chacun selon la granularité :

• 240 clients. Une ligne représente un client. Larkfield a donc 240 clients dans l’exportation.
• 1 417 lignes de billets. Une ligne devrait représenter un billet. Mei écrit « lignes de billets », pas « billets », jusqu’à ce qu’elle vérifie qu’aucun billet n’apparaît deux fois. Vous ferez cette vérification dans la prochaine leçon.
• 1 874 lignes d’événements. Une ligne représente un événement. Il y a plus d’événements que de billets, car un billet peut avoir plusieurs événements. Donc, 1 874 n’est pas un nombre de billets.

Les études de cas à la fin du cours

Les leçons utilisent un seul jeu de données, l’exportation du service de soutien de Larkfield. Vous pouvez ainsi vous concentrer sur chaque idée. Le cours se termine par trois études de cas sur des données publiques réelles : ventes d’une boutique, demandes de réparation d’une ville et trajets de vélos en libre-service. Chacune transforme une exportation réelle désordonnée en tables, en vérifications et en résultat utilisable pour agir. Chaque sortie est expliquée.

Études de cas de ce cours

À la fin du cours, vous appliquez ce que vous avez appris à un projet réaliste, des données jusqu’à la recommandation. Terminez-en au moins une pour obtenir le certificat; les autres sont facultatives.

• Expliquer les ventes d'une boutique en ligneTransformer l'exportation réelle d'une boutique en tables, rapprocher les revenus et les retours, et répondre à des questions de planification avec des fonctions de fenêtrage et des cohortes.
• Préparer une table sans fuite pour les demandes de réparation d'une villeCréer un pipeline reproductible qui passe d'une exportation désordonnée du 311 de NYC à une table de modélisation documentée et sans fuite.
• Planifier le rééquilibrage des vélos pendant la nuitTrouver les défauts d'exportation et les déplacements de camionnettes dans de vrais trajets de vélopartage, et construire une cible par station à partir des jours précédents seulement.

Vous devez terminer au moins une étude de cas pour obtenir le certificat. Chacune est aussi une réalisation pour votre portfolio. Elles utilisent tout le cours. La plupart des personnes les commencent donc après le module 6.

Exercice guidé : compter et observer

1. Dans le bloc ci-dessous, exécutez la requête. Elle compte les lignes de customers. Vous devriez voir une ligne avec la valeur 240.
2. Remplacez customers par tickets. Avant l’exécution, prédisez le nombre. Exécutez ensuite la requête. Vous devriez voir 1417.
3. Remplacez la table par outcomes et exécutez la requête. Vous devriez voir 1874.
4. Remplacez la requête par SELECT * FROM outcomes LIMIT 6; et exécutez-la. Regardez la colonne ticket_id. Les lignes suivent l’ordre d’enregistrement des événements, pas l’ordre des billets : T-10002 vient en premier.

Exécutez du SQL dans votre navigateur

Essayez : compter les lignes

Suivez les étapes ci-dessus. Chaque exécution utilise une nouvelle copie de la base de données. Vous ne pouvez donc pas l’endommager.

Requête SQL (vous pouvez la modifier)SELECT COUNT(*) FROM customers;

À vous : les billets d’un client

La requête du bloc affiche tous les événements du billet T-10014. WHERE (où) garde seulement les lignes pour lesquelles la condition est vraie. Vous apprendrez à utiliser WHERE dans le module 2.

Modifiez la requête pour afficher toutes les colonnes de chaque billet du client C-0001. Prédisez d’abord le nombre de lignes.

Exécutez du SQL dans votre navigateur

À vous : les billets de C-0001

La vérification compare votre résultat au nôtre. Les valeurs textuelles demandent des apostrophes simples : 'C-0001'.

Requête SQL (vous pouvez la modifier)SELECT * FROM outcomes WHERE ticket_id = 'T-10014';

Afficher l’exemple de réponse

SELECT *
FROM tickets
WHERE customer_id = 'C-0001';

Le résultat contient 3 lignes : T-10270, T-10530 et T-10714. Il fallait changer deux éléments : la table (tickets) et la colonne de la condition (customer_id). La granularité vous indique quelle table utiliser. Les « billets d’un client » sont des lignes de tickets. Les « événements d’un billet » sont des lignes de outcomes.

Erreur courante

Compter des événements comme des billets

Symptôme : Omar, le responsable produit, demande combien de billets ont été résolus. Tomás exécute cette requête et répond « 1 533 » :

SELECT COUNT(*)
FROM outcomes
WHERE status = 'resolved';

La requête s’exécute sans erreur. Mais 1 533 dépasse le nombre de billets différents dans l’exportation (1 403). Ce nombre ne peut pas être un nombre de billets.

Cause : la granularité de outcomes est un événement, pas un billet. Un billet résolu, rouvert et résolu de nouveau, comme T-10014, a deux lignes resolved (résolu). La requête a compté des événements.

Correction : comptez chaque billet une seule fois. COUNT(DISTINCT ticket_id) compte les identifiants de billets différents. Vous l’apprendrez dans le module 2.

SELECT COUNT(DISTINCT ticket_id)
FROM outcomes
WHERE status = 'resolved';

Le résultat est de 1 396 billets. Avant de compter, dites la granularité de la table à voix haute : « une ligne représente un événement ».

En IA : la même erreur produit une table d’entraînement avec une ligne par événement plutôt qu’une ligne par billet. Les billets avec beaucoup d’événements comptent alors plusieurs fois. Le modèle apprend davantage à partir de ces billets que des autres.

Vérifiez votre compréhension

La table outcomes contient 1 874 lignes. Larkfield a-t-elle 1 874 billets avec un résultat? Expliquez avec la granularité.

Afficher la réponse

Non. La granularité de outcomes est un événement dans la vie d’un billet, pas un billet. Un billet peut avoir plusieurs événements, par exemple une résolution, une réouverture et une nouvelle résolution. Donc, 1 874 est un nombre d’événements. Le nombre de billets avec au moins un événement est plus petit. Vous le comptez avec COUNT(DISTINCT ticket_id).

Vérifiez votre compréhension

12 billets ont la valeur NULL dans closed_at. L'exportation a-t-elle oublié leurs données? Que notez-vous à leur sujet dans un rapport?

Afficher la réponse

Ce n’est pas une erreur. NULL dans closed_at signifie que le billet était encore ouvert au moment de l’instantané, le 1 juillet 2026 à 6 h. La valeur peut exister dans une exportation ultérieure. Dans un rapport, notez le moment de l’instantané avec les nombres : « 12 billets étaient ouverts lors de l’exportation du 1 juillet 2026 à 6 h ».

Vérifiez votre compréhension

Une table contient les colonnes order_id, line_number, product et quantity. Chaque commande peut contenir plusieurs produits. Quelle est la granularité?

Afficher la réponse

Une ligne représente une ligne de produit dans une commande, pas une commande. La colonne line_number le montre : une commande a une ligne 1, une ligne 2, et ainsi de suite. Donc, COUNT(*) compte les lignes de commande. Pour compter les commandes, comptez les valeurs différentes de order_id.

Récapitulatif

• Une table contient des lignes et des colonnes. Chaque colonne a un type : TEXT, INTEGER ou REAL dans SQLite. NULL signifie « aucune valeur ».
• Le schéma indique ce que les tables peuvent contenir. Seules les données indiquent ce qu’elles contiennent réellement.
• Un identifiant désigne une chose. Un horodatage indique quand quelque chose s’est produit et quand une valeur était connue.
• La granularité est ce qu’une ligne représente : un client, un billet ou un événement dans la vie d’un billet. Dites-la avant de compter.
• L’exportation est un instantané du 1 juillet 2026 à 6 h. Notez le moment de l’instantané à côté de vos nombres.

Ensuite, vous relierez les trois tables avec des clés et vérifierez si les clés de l’exportation sont fiables.

Leçon suivante : Les concepts relationnels