Données synthétiques

Toutes les données du dépôt sont synthétiques, inventées par data/generate.py. Aucune donnée du client, aucun jeu public pour l'instant (donc aucune provenance externe à documenter). Le domaine simulé est l'hôtellerie : établissements, comp sets, activité quotidienne, réservations, tarifs concurrents. Description de référence : data/README.md.

Les générateurs sont déterministes : chaque série est tirée d'un générateur aléatoire initialisé par une chaîne qui combine la graine (7 par défaut), l'hôtel et la date. La valeur réalisée d'une date ne dépend donc jamais de la fenêtre demandée.

Référentiel

Source unique, lue à la fois par le générateur et par dbt :

Seed	Contenu
`dbt/seeds/hotels.csv`	Cinq hôtels fictifs `h001` à `h005` : `hotel_name`, `city`, `rooms_capacity` (60 à 120), `currency` (`EUR`), `base_adr` (prix moyen de base)
`dbt/seeds/comp_sets.csv`	Trois concurrents par hôtel (`h001_c1` à `h005_c3`)

Modèle de demande

true_series(hotel, start, end, seed=7) produit, pour chaque date d'activité, le nombre final de chambres vendues et le chiffre d'affaires chambres. Le taux d'occupation est borné entre 0,15 et 0,98 et combine un profil par jour de semaine (plus fort le vendredi et le samedi), une saisonnalité annuelle, une hausse les jours fériés et vacances scolaires du calendrier synthétique, et un bruit gaussien. Le prix moyen croît avec l'occupation. Cette série « réalisée » alimente les trois sources.

Sources simulées

Source	Format	Fichier landing	Colonnes
`pms`	CSV, un fichier par hôtel et par date de dépôt	`landing/pms/<date>/pms_<hôtel>.csv`	`hotel_id`, `business_date`, `rooms_available`, `rooms_sold`, `room_revenue`, `currency`
`bookings`	JSON lignes, une réservation par ligne	`landing/bookings/<date>/bookings_<hôtel>.json`	`hotel_id`, `reservation_id`, `stay_date`, `rooms`, `room_revenue`, `booked_at`, `status`, `extracted_at`
`rate_shop`	CSV	`landing/rate_shop/<date>/rate_shop_<hôtel>.csv`	`hotel_id`, `competitor_id`, `stay_date`, `rate`, `currency`, `shopped_at`

`pms`

Chaque export couvre une fenêtre de dates d'activité (history_days, 7 par défaut) se terminant à la date de dépôt.
Les deux derniers jours sont provisoires : une chambre vendue en moins (et le chiffre d'affaires ajusté). L'export d'une date ultérieure les corrige ; en standardized, le dernier export d'une date d'activité gagne.
pms_rows accepte un ensemble missing_sold_on de dates dont rooms_sold et room_revenue sont laissés vides. Ces valeurs restent NULL en raw, puis NULL avec confidence_class = 'unknown' en standardized. La commande landing n'utilise pas ce paramètre : les cellules vides ne sont produites que par les tests.

`bookings`

Réservations à bord à la date d'extraction pour les 60 dates de séjour suivantes (BOOKING_HORIZON_DAYS).
Courbe de réservation : la part déjà réservée d'une date de séjour croît à l'approche de l'arrivée (de 5 % à 97 % des chambres finalement vendues). La valeur connue à une date passée diffère donc du réalisé final, ce qui exerce les covariables as-of de la prévision.
Réservations de 1 à 3 chambres, statut confirmed, extraction horodatée à 06:00 UTC.

`rate_shop`

Tarifs relevés sur les trois concurrents de l'hôtel pour les 60 dates de séjour suivantes, relevé horodaté à 05:00 UTC.
Tarif de base de l'hôtel majoré le vendredi et le samedi et les jours fériés ou de vacances, plus un bruit gaussien.

Calendrier partagé (`shared_calendar`)

holidays(year) produit, pour chaque année, cinq jours fériés fixes (1er janvier, 1er mai, 14 juillet, 11 novembre, 25 décembre) et deux périodes de vacances scolaires de 14 jours (à partir du 10 février et du 20 octobre), région all. calendar_rows(from, to) les filtre sur une période.

Ce calendrier simule un jeu du Marketplace : il est écrit dans analytics.shared_calendar.calendar_days par ingest.shared_snapshots.write_calendar_snapshot, un snapshot daté (snapshot_date) couvrant un an avant et 730 jours après la date (voir collecte-retraitement.md).

Générateur en ligne de commande

uv run python -m data.generate landing --root <dossier> --as-of 2026-10-22 [--history-days 7]

Écrit les quinze fichiers d'une date (trois sources, cinq hôtels) sous <dossier>/<source>/<date>/.
Un fichier déjà présent n'est jamais remplacé (la commande s'arrête) : immutabilité du landing.
Le dépôt dans MinIO se fait par ingest.landing.LandingStore.put (exemple dans exploitation.md). landing_files(as_of, history_days, seed) renvoie les mêmes fichiers en mémoire, sans passer par le disque.

Données produites par les tests

Les tests d'intégration écrivent dans la pile réelle avec des marqueurs reconnaissables : dates de dépôt fictives tirées entre 2100 et 2108 pour le landing, dates de snapshot de calendrier entre 2099 et 2107, as_of_date de prévision à partir de 2099, schémas raw scratch it_raw_<id> et tables scratch it_*. Les tables scratch sont supprimées en fin de test, mais certaines traces restent (tables scratch it_*, lignes datées dans les tables intake, fichiers landing et snapshots de calendrier à dates fictives). Elles sont synthétiques et ne gênent pas l'usage, mais faussent un comptage naïf des tables ou des lignes.