J2 — Les données existent

L’objectif du jour : un établissement peuplé à explorer, et savoir lequel des trois outils de données employer la prochaine fois.

Durée réaliste	une demi-journée, dont la moitié à se promener dans l’application
Prérequis	J1 — PostgreSQL démarré, migrations passées

Trois outils, trois besoins

C’est la confusion la plus fréquente à l’arrivée : il y a un moteur et deux façons de s’en servir.

	Ce que c’est	Quand l’employer
packages/dataset-generator	le moteur, pur et déterministe : une recette JSON en entrée, un jeu de données cohérent en sortie. Aucune base, aucun effet de bord	jamais directement — les deux autres l’appellent
bun run demo:seed	le tenant de démonstration figé, « Institut Supérieur Delacroix », reconstruit à l’identique à chaque exécution	explorer un établissement réaliste, reproduire un bug, préparer une démonstration
apps/seeder	l’atelier : une interface pour composer une recette sur mesure et l’insérer comme nouveau tenant	fabriquer un jeu de données pour un cas précis — volumétrie, cas limites, stress du solveur

Les recettes livrées vivent dans packages/dataset-generator/recipes/ : la recette officielle de la démonstration, mais aussi une petite école, une université multi-campus, des cas limites et un jeu de stress pour le solveur.

Dans quel ordre

1. Chargez la démonstration :

   bun run demo:seed

   Le script imprime, en fin d’exécution, les trois comptes qu’il crée — administrateur, enseignant, étudiant — les volumes du jeu et les quatre scénarios câblés.

2. Connectez-vous sur http://localhost:3000 avec le compte administrateur, et ouvrez la grille de planification. C’est la première fois que le produit ressemble à quelque chose.

3. Lancez l’atelier, pour savoir qu’il existe :

   bun run seeder:dev          # http://localhost:3100

   Il ne demande que PostgreSQL : le tenant est créé par le vrai chemin produit — inscription Better Auth, puis création d’organisation dont le hook amorce l’établissement, les rôles, le référentiel standard et le profil de contraintes par défaut. Aucune porte dérobée, dans aucun des deux outils.

4. Ouvrez une recette dans packages/dataset-generator/recipes/ pour voir de quoi une recette est faite. Vous y reviendrez le jour où il vous faudra un jeu que la démonstration ne couvre pas.

Le raccourci du pro

Le générateur est pur : même recette, même jeu de données, octet pour octet. C’est ce qui rend un bug de données reproductible — et ce qui vous permet d’écrire un test qui s’appuie dessus sans le rendre instable.

Comment savoir que c’est bon

Connecté en administrateur sur le tenant de démonstration :

• la grille de planification affiche une semaine dense de l’année 2026-2027 ;
• le cours Algorithmique — TD apparaît dans les cours sans séance placée ;
• la salle B-201 porte une réservation « Conseil pédagogique » en semaine 2, mardi 09:45.

Ces trois repères sont ceux du parcours utilisateur : si vous voulez comprendre ce que le produit fait avant d’en lire le code, le chemin de 2 heures part exactement d’ici.

Le piège du jour

`demo:seed` détruit avant de reconstruire — et refuse de le faire à distance

Deux comportements voulus, qui surprennent la première fois.

Il est destructif. Le script supprime le tenant de démonstration existant — cascade complète sur l’établissement, l’organisation et les trois comptes — puis le reconstruit. C’est ainsi qu’il garantit « même graine, mêmes données ». Tout ce que vous avez saisi à la main dans ce tenant disparaît. Si vous tenez à votre bricolage, fabriquez-vous un tenant avec l’atelier : il en crée un nouveau au lieu d’écraser celui-là.

Il refuse une base non locale. Une garde vérifie l’URL de connexion et interrompt l’exécution si elle ne pointe pas sur une machine locale. On la contourne avec DEMO_ALLOW_REMOTE=1, ce qui est exactement le genre de variable qu’on ne tape pas sans savoir pourquoi : de l’autre côté, la suppression n’a rien de simulé.

Ce qui doit exister à la fin de la journée

• bun run demo:seed s’est terminé sur son récapitulatif, sans erreur
• Vous vous êtes connecté avec le compte administrateur du seed
• La grille de planification affiche une semaine dense
• L’atelier de données répond sur http://localhost:3100
• Vous savez lequel des trois outils employer pour un besoin donné

Demain

J3 — La carte du monorepo : vous avez vu le produit tourner, il est temps de savoir où vivent ses morceaux — et surtout où poser le prochain changement.