Suivre la provenance des données

Ce que vous saurez faire

Consignez l’origine du jeu de données et chaque étape qui l’a modifié, dans l’ordre. Priya pourra alors lui faire confiance, le reproduire et répondre à la question « Pourquoi cette valeur diffère-t-elle de l’exportation? »

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

Le carnet (notebook) Jupyter suit le billet de soutien T-10013 dans les fichiers, lit chaque registre de provenance et vérifie l’origine. Il écrit DATASET.md et scripts/trace.py, puis compare la fiche aux registres. Ses premières cellules installent pandas, téléchargent les données d’exercice et reconstruisent les fichiers des leçons précédentes. Il fonctionne donc sans votre projet local. 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 45 minutes

Ce que vous devez savoir

• Ce qu’est un contrat de données et ce que validate.py vérifie, dans Les règles de validation.
• Ce que fait chaque étape du pipeline :
  • l’extraction, dans Une extraction reproductible;
  • le nettoyage, dans Traiter les valeurs désordonnées;
  • la cible, dans Caractéristiques et moment de la cible;
  • la séparation, dans Choisir une séparation.

Ce qu’il vous faut sur votre ordinateur (seulement pour le parcours local; le carnet et l’encadré de cette page n’en ont pas besoin)

• Le projet ~/projects/ticket-data avec larkfield.db et get_data.py, dans Préparer une base de données d’exercice : créer la base de données. Si la base de données manque ou a changé, réinitialisez la base de données avec python get_data.py --reset.
• L’environnement virtuel .venv avec pandas 3.0.6, dans Profiler avant de modifier : le même profil dans pandas. Activez-le avant d’exécuter un script.
• Les registres de provenance des leçons précédentes :
  • data/extract/manifest.json, dans Une extraction reproductible : créer extract.py.
  • reports/cleaning.json et data/clean/quarantine.csv, dans Traiter les valeurs désordonnées : terminer clean.py.
  • data/model/build_summary.json, dans Caractéristiques et moment de la cible : build_features.py.
  • data/model/split_manifest.json, dans Choisir une séparation : créer et vérifier la séparation.
  • scripts/validate.py et reports/validation.json, dans Les règles de validation : le contrat dans validate.py. python scripts/validate.py doit réussir les 13 vérifications.
• Si un registre manque ou ne correspond pas aux nombres de cette page, exécutez les scripts de nouveau dans cet ordre : extract.py, clean.py, build_features.py, split.py, validate.py. Si un script manque ou ne fonctionne plus, copiez d’abord la version terminée du cours depuis C04/pipeline. Placez-la au même endroit dans votre projet.

Testé avec Python 3.14.6 et pandas 3.0.6 sur macOS. Le carnet a été testé dans Jupyter.

Le parcours d’un billet

Priya ouvre train.csv et trouve le billet T-10013 avec une valeur de commande de 32,6. Grace dit : « Dans le système de soutien, ce billet affiche 3 260. » Qui a raison? Mei suit le billet dans les fichiers :

Emplacement	channel	order_value	Ce qui explique le changement
Table tickets dans larkfield.db	webform	3260.0	L’exportation du 1 juillet 2026 à 6 h.
data/extract/tickets.csv	webform	3260.0	Sélectionné : créé le 6 janvier 2026, dans la sélection de manifest.json.
data/clean/tickets.csv	web_form	32.6	clean.py : orthographe du canal corrigée; cents ÷ 100. La ligne conserve channel_raw = webform, order_value_raw = 3260.0 et order_value_flag = converted_from_cents (converti depuis des cents). cleaning.json compte 24 lignes de ce type.
data/model/train.csv	web_form	32.6	Créé avant le 1 mai 2026, donc dans les données d’entraînement (split_manifest.json).

Les deux ont raison. Grace voit la valeur brute, en cents, provenant de l’ancien formulaire Web. Priya voit la valeur corrigée en dollars. Mei peut montrer chaque étape et le fichier qui la consigne. C’est la traçabilité des données : le registre de l’origine de chaque donnée et de toutes ses modifications, dans l’ordre.

La traçabilité commence par la provenance : l’origine des données. Qui les a créées, quand, comment et avec quelle permission. La provenance répond à « D’où viennent-elles? » La traçabilité répond à « Que leur est-il arrivé depuis? »

La traçabilité du jeu de données livré

Le diagramme montre le parcours complet, des fichiers d’exportation au jeu de données livré. Chaque étape écrit un petit fichier qui consigne ce qu’elle a fait. Les losanges sont des points de contrôle : des vérifications qui arrêtent le parcours si quelque chose ne va pas.

Le contrat du jeu de données et sa traçabilité : chaque étape laisse un registre. Trois points de contrôle arrêtent le pipeline avant qu'un jeu de données défectueux soit livré.

Description textuelle du diagramme

Le diagramme comporte trois parties, de haut en bas.

1. Source et points de contrôle des entrées. generate.py a créé les fichiers d’exportation (customers, tickets, outcomes) avec la graine 2026, sous la licence CC0. Deux points de contrôle les vérifient. get_data.py vérifie que la somme de contrôle de chaque fichier correspond. Si oui, il construit larkfield.db, l’instantané du 1 juillet 2026 à 6 h avec 1 417 lignes de billets. check_input.py vérifie que le schéma est conforme aux attentes. Si l’un des contrôles échoue, le pipeline s’arrête et le message indique le problème.
2. Préparation. Si les deux contrôles réussissent, quatre étapes s’exécutent dans l’ordre et chacune écrit un registre de provenance. extract.py : 1 416 billets et manifest.json. clean.py : 1 398 billets, 4 en quarantaine et cleaning.json. build_features.py : 1 369 lignes et build_summary.json. split.py : train 927, valid 227, test 215 et split_manifest.json.
3. Point de contrôle des sorties et livraison. validate.py vérifie les 13 règles du contrat. Si elles sont respectées, le jeu de données livré comprend les fichiers train, valid et test, avec MANIFEST.json et DATASET.md. Sinon, le pipeline s’arrête et aucun jeu de données n’est livré.

Vous avez déjà écrit la plupart des registres de provenance. Chaque module a ajouté un registre :

Registre	Écrit par	Il répond à la question
Table snapshot dans larkfield.db	get_data.py	De quelle exportation et de quelle version des données s’agit-il?
data/extract/manifest.json	extract.py (module 3)	Quelles lignes ont été sélectionnées, avec quelle requête, et combien ont été exclues?
reports/cleaning.json	clean.py (module 4)	Combien de lignes ont été supprimées, corrigées ou mises en quarantaine, et pourquoi?
data/clean/quarantine.csv	clean.py (module 4)	Quels billets ont été mis de côté, et pour quelle raison chacun?
data/model/build_summary.json	build_features.py (module 5)	Combien de billets étaient trop récents pour avoir une cible définitive?
data/model/split_manifest.json	split.py (module 5)	Quelle règle a produit la séparation, et quelle est la taille de chaque partie?
reports/validation.json	validate.py (ce module)	Le contrat a-t-il été respecté?

Le premier registre se trouve dans la base de données elle-même :

Exécutez du SQL dans votre navigateur

Essayez : le registre de l'instantané

Exécutez la requête. Vous devriez voir 3 lignes : source, exported_at (2026-07-01 06:00:00) et data_version (1.0). Chaque registre suivant part de ces trois valeurs.

Requête SQL (vous pouvez la modifier)SELECT name, value FROM snapshot;

extract.py copie ces valeurs dans son manifeste, avec la sélection et une somme de contrôle de chaque requête :

data/extract/manifest.json

{
  "extracted_at": "2026-10-07T03:05:39+00:00",
  "source": {
    "source": "Larkfield help-desk export (synthetic, Nextia Learning C04)",
    "exported_at": "2026-07-01 06:00:00",
    "data_version": "1.0"
  },
  "selection": {
    "created_from": "2026-01-01",
    "created_before": "2026-07-01",
    "rule": "created_from <= created_at < created_before"
  },
  "ticket_rows_in_source": 1417,
  "ticket_rows_not_selected": 1,
  "files": [
    {
      "query": "queries/extract_tickets.sql",
      "query_sha256": "28a0267e280062b0e02f9727cb5a95d2c8b60309e5fc992a578e44ba61b54338",
      "file": "data/extract/tickets.csv",
      "rows": 1416
    },
    {
      "query": "queries/extract_outcomes.sql",
      "query_sha256": "533e9573c06975a463369aea503c4218c806640b99067d240607c1cea6fdc864",
      "file": "data/extract/outcomes.csv",
      "rows": 1869
    }
  ]
}

Votre valeur extracted_at correspond au moment de votre propre exécution; elle est donc différente. Toutes les autres valeurs doivent être identiques à celles présentées ici.

clean.py écrit les décomptes du module 4. Les nombres concordent : 1 416 lignes en entrée, 14 doublons supprimés, 4 en quarantaine, 1 398 lignes propres.

reports/cleaning.json

{
  "tickets": {
    "input_rows": 1416,
    "exact_duplicates_removed": 14,
    "channel_respelled": 39,
    "order_value_ok": 1179,
    "order_value_not_applicable": 188,
    "order_value_converted_from_cents": 24,
    "order_value_unknown": 11,
    "quarantined": 4,
    "clean_rows": 1398
  },
  "outcomes": {
    "input_rows": 1869,
    "repeated_events_removed": 30,
    "events_of_quarantined_tickets": 5,
    "clean_rows": 1834
  }
}

Provenance : l’origine de l’exportation

La provenance de ce jeu de données comporte trois parties.

Génération synthétique. Les données synthétiques sont des données créées par un programme plutôt qu’enregistrées par un système réel. L’exportation de Larkfield provient de C04/generate.py dans le dépôt nextia-learning-labs. Il utilise seulement la bibliothèque standard de Python. Il ajoute chaque problème volontairement et en quantité connue : les 14 doublons, les cents, les colonnes qui causent des fuites. Les données sont inventées pour ce cours; elles ne représentent aucune personne réelle.

La graine. Le générateur utilise des nombres aléatoires. Une graine est la valeur de départ d’un générateur de nombres aléatoires. Avec la même graine, le générateur produit les mêmes nombres dans le même ordre. generate.py utilise la graine 2026; chaque exécution écrit donc les mêmes fichiers.

Sommes de contrôle. Comment savoir si votre fichier tickets.csv est celui que le générateur a écrit? Une somme de contrôle est une courte empreinte des octets d’un fichier. SHA-256 est une méthode courante. Si un octet change, la somme de contrôle change complètement. get_data.py conserve la somme de contrôle attendue de chaque fichier et refuse les fichiers qui ne correspondent pas. Vous la vérifierez vous-même dans l’exercice guidé.

Licence. Une licence indique ce que vous pouvez faire avec les données. Les fichiers de Larkfield sont sous CC0 1.0 : une déclaration de mise dans le domaine public. Vous pouvez les copier, les modifier et les partager pour tout usage, même commercial, sans permission ni mention de source. Le dépôt des exercices contient une fiche du jeu de données pour l’exportation, C04/data/dataset.md. Elle présente la licence, les sommes de contrôle et la liste des problèmes.

Les données réelles exigent une permission

Avec des données réelles, la licence et la permission passent en premier. Un jeu de données téléchargeable n’est pas toujours un jeu de données que vous pouvez utiliser pour entraîner un modèle. Les billets des clients peuvent contenir des renseignements personnels. Leur utilisation peut nécessiter une base juridique ou le consentement du client. Consignez la licence et la permission dans la provenance avant d’utiliser les données.

Versions du jeu de données

L’exportation a une version, data_version 1,0. Le jeu de données livré par Mei a aussi besoin d’une version. Priya doit pouvoir indiquer quelles données ont servi à entraîner un modèle. Quels changements nécessitent une nouvelle version?

Changement	Nouvelle version?	Pourquoi
Une nouvelle exportation, par exemple celle d’août	Oui	Les lignes sont différentes.
Une règle modifiée dans clean.py, par exemple une nouvelle limite pour word_count	Oui	La même exportation donne des lignes différentes.
Une sélection modifiée, par exemple seulement les billets de février	Oui	Les lignes sont différentes.
Les mêmes scripts exécutés de nouveau sur le même instantané	Non	La sortie doit être identique. La prochaine leçon le prouve avec des sommes de contrôle.

Un numéro de version seul ne prouve rien. Les sommes de contrôle des fichiers de sortie le font. La prochaine leçon les ajoute.

Exemple détaillé : la fiche du jeu de données

Une fiche du jeu de données (aussi appelée fiche technique) est un court document qui accompagne un jeu de données. Elle décrit les données, leur origine, leur création et les usages à éviter. Mei écrit DATASET.md dans le dossier du projet. Elle copie chaque nombre depuis un registre de provenance, plutôt que de se fier à sa mémoire.

DATASET.md

# Dataset card: Larkfield ticket escalation dataset

Prepared by Mei (data engineer) for Priya (data scientist). Version 1.0 of the dataset, made from data version 1.0 of the export.

## What it is

One row per support ticket of Larkfield, a fictional online shop for home and garden products. The target, `escalated_72h`, is 1 if a senior agent took the ticket within 72 hours of its creation. Every feature is known when the ticket is created, so a model can use it at that moment.

| File | Rows | What one row is |
|---|---|---|
| `data/model/train.csv` | 927 | a ticket created before 2026-05-01 |
| `data/model/valid.csv` | 227 | a ticket created in May 2026 |
| `data/model/test.csv` | 215 | a ticket created from 2026-06-01 to 2026-06-27 |
| `data/model/tickets_model.csv` | 1,369 | all three parts together |

Escalation rate: 13.7% overall (188 of 1,369); train 11.7%, valid 19.8%, test 16.3%.

## Provenance

| Field | Value |
|---|---|
| Source | The Larkfield help-desk export: `customers.csv`, `tickets.csv`, `outcomes.csv` |
| Snapshot | Exported 2026-07-01 06:00:00, data version 1.0 (the `snapshot` table in `larkfield.db`) |
| How the source was made | **Synthetic.** `C04/generate.py` in `nextia-learning-labs`, Python standard library only, seed 2026. No real system, customer or agent. |
| Licence | CC0 1.0 (public domain). No attribution needed. |
| Raw file checksums (SHA-256) | `customers.csv` 7b437642f0095524f8311f67a7caeb17100d23eed92618b9cf012cd3d3b79993<br>`tickets.csv` 9c47e08cf2ec5977733d32cc21eb97d0dd01b021d1f5fbf7ec31fef6279b1a28<br>`outcomes.csv` 67b4d9d9275b32061a8888050c351df7314054c11ee1ce29e856c1d5403d0653 |
| Selection | Tickets with `2026-01-01 <= created_at < 2026-07-01` |

## Transformation order

| Step | Script | Rows in → out | Lineage record |
|---|---|---|---|
| 0 | `get_data.py` | 3 CSV files → `larkfield.db` (tickets 1,417 rows) | checksums of the raw files |
| 1 | `scripts/extract.py` | 1,417 → 1,416 ticket rows (1 row created in 2036 is outside the selection); 1,874 → 1,869 outcome events | `data/extract/manifest.json` |
| 2 | `scripts/clean.py` | 1,416 → 1,398 tickets (14 exact duplicates removed, 4 quarantined); 1,869 → 1,834 events | `reports/cleaning.json`, `data/clean/quarantine.csv` |
| 3 | `scripts/build_features.py` | 1,398 → 1,369 (29 tickets are too recent for a final target) | `data/model/build_summary.json` |
| 4 | `scripts/split.py` | 1,369 → train 927, valid 227, test 215 | `data/model/split_manifest.json` |
| 5 | `scripts/validate.py` | 13 rules, no change to the data | `reports/validation.json` |

## Columns

| Column | Type | Missing allowed | Meaning |
|---|---|---|---|
| `ticket_id` | text | no | unique, for example `T-10001` |
| `customer_id` | text | yes (guests) | for example `C-0001` |
| `created_at` | datetime | no | `YYYY-MM-DD HH:MM:SS`, 2026-01-05 to 2026-06-27 |
| `channel` | text | no | `email`, `chat`, `phone`, `web_form`, `unknown` (was missing) |
| `team` | text | no | `delivery`, `returns`, `payment`, `warranty`, `account` |
| `priority` | integer | no | 1 (most urgent) to 3, set at creation |
| `segment` | text | no | `home`, `trade`, `business`, `guest` (no customer), `unknown` (deleted customer) |
| `region` | text | no | `north`, `south`, `east`, `west`, `unknown` |
| `order_value` | number | yes | dollars, 0 to 2,000. Missing for account tickets (no order) and where the order system said "unknown" (−1). January web-form values were cents and are divided by 100. |
| `word_count` | integer | no | words in the first message, 0 to 10,000 |
| `customer_tenure_days` | number | yes (guests, deleted customers) | days from `joined_on` to `created_at` |
| `prior_tickets_90d` | integer | no | the same customer's tickets in the 90 days before this one |
| `created_hour` | integer | no | 0 to 23 |
| `escalated_72h` | integer | no | the target: 0 or 1 |

Never in the dataset: `priority_now`, `first_reply_minutes`, `closed_at`, and anything from the outcome events after creation. They are known only after the ticket is created (leakage).

## Tool versions

Tested on macOS: Python 3.14.6 (SQLite 3.50.4), pandas 3.0.6.

## Known limitations

- **Synthetic data.** The relations between columns are simple and were chosen for teaching. Do not draw conclusions about real help desks or real customers from this data.
- **The escalation rate changes over time.** It rises after 2026-05-01, when a new warranty policy started (Grace, support lead). Train has 11.7%, valid 19.8%. A model trained on train only sees the old policy.
- **Small test set.** 215 tickets, 35 of them escalated. A difference of a few tickets changes a score noticeably.
- **Customers repeat across parts.** 77 of the 89 customers in test also have tickets in train. Results on test say how the model does for known customers; for new customers they can be worse.
- **Corrected values.** 24 order values were converted from cents. 11 "unknown" values (−1) are now missing. The originals are in `data/clean/tickets.csv` (`order_value_raw`, `order_value_flag`).
- **Excluded rows.** 4 tickets are in quarantine (3 created before the customer joined, 1 with 48,210 words). 29 tickets from the last 72 hours before the snapshot have no final target and are not in the dataset.
- **What not to conclude.** The dataset is for learning data preparation. A model trained on it is a demonstration, not a tool for routing real tickets.

## Changes

| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-10-06 | First delivery, from the export of 2026-07-01 06:00 (data version 1.0). |

Trois sections comptent surtout pour Priya :

• Ordre des transformations. Les étapes ne sont pas interchangeables. Par exemple, build_features.py calcule prior_tickets_90d à partir des billets propres. Les 14 doublons doivent donc être supprimés d’abord. Si l’ordre change, les valeurs changent.
• Limites connues. Ce sont les faits qu’un score ne peut pas montrer : le changement de politique, les données de test peu nombreuses, les clients présents dans les données d’entraînement et de test. Le nombre de 77 sur 89 provient de split_manifest.json.
• Ce qu’il ne faut pas conclure. Une fiche du jeu de données protège contre les mauvais usages, pas seulement contre les mauvaises valeurs.

La prochaine leçon ajoute une section avec les sommes de contrôle des fichiers de sortie.

Exercice guidé : vérifier la provenance et suivre un billet

1. Dans le terminal, allez dans le dossier de votre projet et vérifiez que l’environnement est actif.

2. Lancez le mode interactif de Python avec python. Calculez la somme de contrôle de tickets.csv :

   Interactive Python

   >>> import hashlib
   >>> from pathlib import Path
   >>> hashlib.sha256(Path("data/raw/tickets.csv").read_bytes()).hexdigest()
   '9c47e08cf2ec5977733d32cc21eb97d0dd01b021d1f5fbf7ec31fef6279b1a28'

3. Ouvrez get_data.py et trouvez FILES. Comparez la valeur de tickets.csv à votre résultat. Elles doivent être égales.

4. Tapez exit() pour quitter le mode interactif.

5. Créez scripts/trace.py. Il montre dans quels fichiers un billet apparaît :

   scripts/trace.py

   """Show where one ticket is in each file of the pipeline."""
   
   import sys
   from pathlib import Path
   
   FILES = ["data/extract/tickets.csv", "data/clean/tickets.csv", "data/clean/quarantine.csv",
            "data/model/train.csv", "data/model/valid.csv", "data/model/test.csv"]
   
   ticket = sys.argv[1]
   for path in FILES:
       lines = Path(path).read_text(encoding="utf-8").splitlines()
       found = [line for line in lines if line.startswith(ticket + ",")]
       print(f"{path:<26} {len(found)} row(s)")

6. Exécutez-le pour T-10013 :

   python scripts/trace.py T-10013

   data/extract/tickets.csv   1 row(s)
   data/clean/tickets.csv     1 row(s)
   data/clean/quarantine.csv  0 row(s)
   data/model/train.csv       1 row(s)
   data/model/valid.csv       0 row(s)
   data/model/test.csv        0 row(s)

7. Créez DATASET.md dans le dossier du projet, avec les sections de la fiche de Mei. Copiez chaque nombre depuis le registre indiqué dans le tableau ci-dessus.

À vous de jouer : trois billets, trois enregistrements

Retracez trois autres billets avec scripts/trace.py : T-10031, T-10361 et T-10147. Prédisez d’abord le résultat. Pour chaque billet, nommez l’enregistrement de traçabilité qui explique ce qu’il est devenu.

Afficher la réponse

python scripts/trace.py T-10031

data/extract/tickets.csv   2 row(s)
data/clean/tickets.csv     1 row(s)
data/clean/quarantine.csv  0 row(s)
data/model/train.csv       1 row(s)
data/model/valid.csv       0 row(s)
data/model/test.csv        0 row(s)

T-10031 est l’un des 14 doublons exacts : 2 lignes dans l’extraction, 1 après le nettoyage. L’enregistrement est exact_duplicates_removed: 14 (14 doublons exacts supprimés) dans reports/cleaning.json.

python scripts/trace.py T-10361

data/extract/tickets.csv   1 row(s)
data/clean/tickets.csv     0 row(s)
data/clean/quarantine.csv  1 row(s)
data/model/train.csv       0 row(s)
data/model/valid.csv       0 row(s)
data/model/test.csv        0 row(s)

T-10361 est en quarantaine, avec le motif word_count_above_10000 (nombre de mots supérieur à 10 000) dans sa ligne de data/clean/quarantine.csv. cleaning.json le compte dans quarantined: 4 (4 en quarantaine).

python scripts/trace.py T-10147

data/extract/tickets.csv   0 row(s)
data/clean/tickets.csv     0 row(s)
data/clean/quarantine.csv  0 row(s)
data/model/train.csv       0 row(s)
data/model/valid.csv       0 row(s)
data/model/test.csv        0 row(s)

T-10147 n’est dans aucun fichier. C’est le billet daté de 2036, donc il est hors de la sélection. L’enregistrement est ticket_rows_not_selected: 1 (1 ligne de billet non sélectionnée) dans data/extract/manifest.json. Un billet absent de tous les fichiers reste traçable : le manifeste explique pourquoi il n’y est pas.

Erreur courante

Les règles passent, mais la fiche est incorrecte

Symptôme : Priya compte 1 159 lignes dans tickets_model.csv. DATASET.md indique 1 369. validate.py valide les 13 règles.

Cause : Mei a refait l’extraction avec une autre sélection, python scripts/extract.py --created-from 2026-02-01, puis les autres étapes. Les nouveaux fichiers sont valides : 1 204 billets extraits, 1 188 nettoyés, 1 159 dans la table de modélisation, 717 dans les données d’entraînement. Mais personne n’a modifié la fiche. Le contrat vérifie les données, pas le document qui les décrit.

Correction :

1. Comparez la fiche aux enregistrements. La sélection dans data/extract/manifest.json indique "created_from": "2026-02-01" (créés à partir du 1er février 2026). La fiche indique le 1er janvier 2026.
2. Décidez : la nouvelle sélection est-elle voulue? Sinon, refaites les étapes avec la sélection par défaut.
3. Si oui, c’est une nouvelle version du jeu de données. Mettez à jour chaque nombre de la fiche à partir des nouveaux enregistrements, et ajoutez une ligne au tableau Changes (modifications).

En IA : une fiche de modèle ou un article qui cite le mauvais jeu de données est très difficile à corriger ensuite. Les résultats ne sont pas reproductibles, et personne ne sait quelles données ont servi à entraîner le modèle. La prochaine leçon automatise cette vérification : MANIFEST.json consigne la sélection et une somme de contrôle de chaque sortie à chaque exécution.

Vérifiez votre compréhension

Quelle est la différence entre la provenance et la traçabilité? Donnez un exemple de chacune chez Larkfield.

Afficher la réponse

La provenance décrit l’origine : qui a créé les données, quand, comment et sous quelle licence. Exemple : l’exportation du 1er juillet 2026 à 6 h, créée par generate.py avec la graine 2026, sous CC0. La traçabilité comprend la provenance et ajoute toutes les étapes suivantes, dans l’ordre. Exemple : la valeur de commande de T-10013 est passée de 3 260,0 à 32,6 dans clean.py. cleaning.json compte 24 conversions de ce type.

Vérifiez votre compréhension

Prédisez : quelqu'un exécute generate.py avec la graine 2027 et place le nouveau tickets.csv dans data/raw/. Que fait get_data.py?

Afficher la réponse

Une autre graine produit d’autres nombres aléatoires. Le fichier contient donc des octets différents et une somme de contrôle SHA-256 différente. get_data.py détecte que la somme de contrôle ne correspond pas à FILES. Il télécharge de nouveau le fichier original et le vérifie. La base de données est donc construite à partir de la véritable exportation de 2026. La somme de contrôle sert de filtre : un fichier autre que celui attendu ne devient jamais l’instantané.

Vérifiez votre compréhension

Omar demande : « Peut-on publier ce jeu de données sur notre site Web et entraîner un modèle pour de vrais billets? » Répondez aux deux questions.

Afficher la réponse

Publier : oui. L’exportation est sous CC0 1.0. Larkfield peut donc la copier et la partager à toute fin, sans permission ni attribution. Entraîner pour de vrais billets : non. Les données sont synthétiques, et leurs relations ont été choisies pour l’enseignement. La fiche l’indique sous « What not to conclude » (ce qu’il ne faut pas conclure). La licence répond à « Avons-nous le droit de l’utiliser? ». Les limites répondent à « Devrions-nous l’utiliser pour cela? ».

Récapitulatif

• La traçabilité des données consigne leur origine et chaque étape qui les a modifiées, dans l’ordre. La provenance en est le début : qui a créé les données, comment, quand et sous quelle licence.
• Le pipeline écrit déjà les enregistrements de traçabilité : la table snapshot, manifest.json, cleaning.json, quarantine.csv, build_summary.json, split_manifest.json et validation.json.
• L’exportation de Larkfield est synthétique, créée par generate.py avec la graine 2026, sous CC0 1.0. Une somme de contrôle prouve qu’un fichier est bien celui attendu.
• Une nouvelle exportation, une règle modifiée ou une sélection modifiée crée une nouvelle version du jeu de données. Exécuter les mêmes étapes sur le même instantané ne doit pas en créer une.
• DATASET.md est la fiche du jeu de données : provenance, ordre des transformations, colonnes, versions et limites. Copiez chaque nombre à partir d’un enregistrement.

Ensuite, vous regroupez toutes les étapes sous une seule commande. Vous prouvez qu’elle produit deux fois les mêmes fichiers et faites en sorte qu’elle échoue clairement lorsque l’exportation change.

Leçon suivante : Livrer un jeu de données réutilisable