betagouv
diff --git a/‎.vscode/settings.json‎
Lines changed: 1 addition & 2 deletions b/‎.vscode/settings.json‎
Lines changed: 1 addition & 2 deletions
diff --git a/‎CLAUDE.md‎
Lines changed: 179 additions & 18 deletions b/‎CLAUDE.md‎
Lines changed: 179 additions & 18 deletions
diff --git a/‎docs/adr/0002-architecture-ddd-engine.md‎
Lines changed: 104 additions & 0 deletions b/‎docs/adr/0002-architecture-ddd-engine.md‎
Lines changed: 104 additions & 0 deletions
@@ -1,6 +1,5 @@
 {
-  "typescript.preferences.importModuleSpecifier": "relative",
-  "javascript.preferences.importModuleSpecifier": "relative",
+  "js/ts.preferences.importModuleSpecifier": "relative",
   "editor.formatOnSave": true,
   "editor.defaultFormatter": "esbenp.prettier-vscode",
   "[typescript]": {
 
@@ -89,6 +89,65 @@ Cette règle s'applique à :
 - Tests : `*.spec.ts` / `*.spec.tsx`
 - Hooks personnalisés : `use*.ts`
 
+### 5. Commentaires : simples et brefs
+
+Les commentaires doivent être **courts** et n'expliquer que le **pourquoi** (jamais le quoi évident).
+
+```typescript
+// INTERDIT - verbeux, paraphrase le code, multi-lignes inutiles
+/**
+ * Cette fonction prend en entrée les inputs du simulateur Abattoirs
+ * et applique successivement toutes les règles métier PPA définies
+ * dans la spécification DOCX du 2026-05-12 pour produire en sortie
+ * un objet contenant les 7 sorties attendues du moteur.
+ */
+export function evaluateAbattoir(inputs: AbattoirsInputs): AbattoirsOutputs { ... }
+
+// CORRECT - bref, va à l'essentiel
+// Orchestre les 5 règles. Spec : docs/sources/abattoirs-formules-20260512.docx
+export function evaluateAbattoir(inputs: AbattoirsInputs): AbattoirsOutputs { ... }
+```
+
+Règles :
+
+- Pas de commentaires qui paraphrasent le code (le code est déjà lisible).
+- Pas de docblocks JSDoc longs sauf si la fonction a une sémantique non évidente.
+- Un commentaire d'une ligne suffit dans 90 % des cas.
+- Préférer un nom de variable/fonction explicite à un commentaire d'explication.
+- Référencer la source réglementaire (chemin de fichier) en une ligne, pas en paragraphe.
+
+### 6. CSS : DSFR + Tailwind, pas de CSS custom
+
+Pour toute UI, **ordre de priorité strict** :
+
+1. **DSFR** (dernière version, **`@gouvfr/dsfr` 1.14+`** à date) — classes `fr-*`, composants documentés sur [systeme-de-design.gouv.fr](https://www.systeme-de-design.gouv.fr/). C'est le défaut absolu pour layout, formulaires, boutons, badges, alertes, etc.
+2. **Tailwind CSS** (v4) — uniquement pour les ajustements utilitaires que le DSFR ne couvre pas (espacements fins, grille spécifique, responsive ponctuel).
+3. **CSS custom** (fichier `.css` dédié ou inline) — **uniquement** si DSFR + Tailwind ne suffisent pas, et **après avoir justifié** dans un commentaire pourquoi.
+
+```tsx
+// CORRECT — DSFR pour la structure, Tailwind pour le détail
+<div className="fr-card fr-card--shadow flex items-center gap-2">
+  <span className="fr-badge fr-badge--success">Autorisé</span>
+</div>
+
+// INTERDIT — CSS inline alors qu'une classe DSFR existe
+<div style={{ padding: 16, border: "1px solid #ddd" }}>...</div>
+
+// TOLÉRÉ — uniquement si justifié
+<div
+  className="fr-grid-row"
+  // Hauteur min imposée par la maquette, non couverte par DSFR
+  style={{ minHeight: "320px" }}
+>
+```
+
+Règles :
+
+- Ne jamais réinventer un composant DSFR existant (callout, alert, accordion, badge, etc.).
+- En cas de doute, chercher d'abord dans la doc DSFR avant d'écrire du Tailwind.
+- Si une override de style DSFR est nécessaire, utiliser `mt-0!` (Tailwind v4 important) plutôt qu'un fichier CSS séparé.
+- Pas de framework UI tiers (Material UI, Chakra, etc.) — la conformité Beta.gouv impose DSFR.
+
 ## Workflow obligatoire
 
 ### Vérification post-implémentation
@@ -124,6 +183,47 @@ Quand une tâche implique un **choix architectural significatif**, créer automa
 
 Ne PAS créer d'ADR pour les corrections de bugs, refactorings mineurs ou fonctionnalités qui suivent un pattern existant.
 
+### Commits : simples et conventionnels
+
+Suivre **Conventional Commits** : un titre court, une seule ligne de description.
+
+Format :
+
+```
+<type>(<scope?>): <titre court à l'impératif>
+
+<description en une seule ligne, le pourquoi plus que le quoi>
+```
+
+**Types courants** : `feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `style`, `perf`, `build`, `ci`.
+
+**Exemples** :
+
+```
+feat(abattoirs): moteur de règles + oracle 2744 cas
+
+Implémentation des 5 règles métier dans une architecture DDD pour préparer l'arrivée du 2e simulateur.
+```
+
+```
+fix(marque): corrige le cas ZRII MR-PPA dest non MCA
+
+Le LPS retournait null à tort pour la zone destinataire ZRI.
+```
+
+```
+docs: ADR architecture DDD du moteur
+
+Justifie le découpage en bounded contexts et la séparation data/validation/logique.
+```
+
+Règles :
+
+- Titre **sous 70 caractères**, à l'impératif, en minuscules.
+- **Une seule ligne** de description (pas de listes à puces, pas de paragraphes).
+- Préférer le **pourquoi** au quoi (le diff montre déjà le quoi).
+- **Aucune mention d'auteur ou de co-auteur** dans le corps du commit (pas de `Co-Authored-By`, pas de `Generated with`, etc.). L'auteur git suffit.
+
 ### Compaction du contexte
 
 Lors de la compaction automatique ou manuelle (`/compact`), TOUJOURS préserver :
@@ -164,37 +264,98 @@ pnpm preview                # Prévisualisation du build
 
 ## Architecture
 
-Structure organisée par features, avec un moteur de règles isolé en TypeScript pur :
+Structure organisée par features (UI) avec un moteur de règles isolé en TypeScript pur, organisé en **DDD propre mais simple** :
 
 ```
 src/
-├── engine/                 # Moteur de règles TypeScript pur (sans React)
-│   ├── types.ts            # Types des inputs/outputs des simulateurs
-│   ├── rules.ts            # Règles métier PPA
-│   └── evaluate.ts         # Fonction d'évaluation principale
-├── features/               # Une feature = un parcours utilisateur
+├── engine/                       # Moteur de règles (TypeScript pur, sans React)
+│   ├── index.ts                  # Public API du moteur (re-exports)
+│   ├── shared/                   # Shared kernel : concepts communs aux contexts
+│   │   ├── types.ts              # Enums communs (Zone, Statut, Marque, ...)
+│   │   └── index.ts
+│   ├── abattoirs/                # Bounded context #1
+│   │   ├── index.ts              # API publique du context
+│   │   ├── types.ts              # AbattoirsInputs, AbattoirsOutputs
+│   │   ├── schema.ts             # Schémas Zod (data definition)
+│   │   ├── parse.ts              # Fonctions de validation (parse/safeParse)
+│   │   ├── evaluate.ts           # Orchestrateur (evaluateAbattoir)
+│   │   ├── evaluate.spec.ts      # Test oracle (fixture 2 744 cas)
+│   │   └── rules/                # Règles métier atomiques
+│   │       └── *.ts + *.spec.ts
+│   └── etablissements/           # Bounded context #2 (placeholder)
+├── features/                     # Une feature = un parcours utilisateur
 │   ├── home/pages/
-│   └── simulateurs/        # Sous-domaine simulateurs (regroupe les 2 parcours)
+│   └── simulateurs/
 │       ├── abattoirs/pages/
 │       └── etablissements/pages/
-└── shared/                 # Composants, hooks, utilitaires partagés
-    ├── components/
-    │   ├── SimulatorForm.tsx
-    │   ├── ResultPanel.tsx
-    │   └── layout/Layout.tsx   # Header DSFR + Footer DSFR
-    ├── config/routes.config.ts
-    ├── hooks/
-    └── utils/
+└── shared/                       # Composants UI, hooks, utilitaires
 ```
 
+### Principes DDD appliqués
+
+- **Bounded contexts** : un dossier par simulateur sous `src/engine/`. **Aucun import croisé** entre contexts.
+- **Shared kernel minimal** : `src/engine/shared/` contient uniquement les concepts vraiment partagés (enums communs aux simulateurs).
+- **Public API par context** : un `index.ts` expose les entry points (evaluator, types, parser). Le reste de l'app importe via cet `index.ts` ou via `src/engine/index.ts`.
+- **Séparation des couches dans un context** : data (`schema.ts`), validation (`parse.ts`), logique (`rules/` + `evaluate.ts`) sont des fichiers distincts.
+- **Pas de couches inutiles** : pas de Repository, pas de Domain Service abstrait, pas de DI container. On reste pragmatique tant que le besoin ne le justifie pas.
+
 **Règle d'or** : le moteur (`src/engine/`) ne doit JAMAIS importer de React ni de dépendances UI. Il doit être testable en pur TypeScript.
 
 ## Logique métier
 
-Les règles PPA (Peste Porcine Africaine) sont implémentées dans `src/engine/rules.ts`. Toute modification de ces règles DOIT être accompagnée :
+Les règles PPA (Peste Porcine Africaine) sont implémentées dans `src/engine/<context>/rules/`. Toute modification de ces règles DOIT être accompagnée :
+
+1. d'un test Vitest qui couvre le nouveau cas (`*.spec.ts` co-localisé)
+2. d'une référence à la source réglementaire (instruction technique, arrêté, ou fichier dans `docs/sources/`) dans un commentaire
+
+## Versionnage des règles métier
+
+Chaque simulateur a son fichier de versions lié aux arrêtés officiels :
+
+- Source de vérité : `src/engine/<context>/versions.ts` (tableau antéchronologique, `[0]` = version courante)
+- Affichage : date dans le panneau résultats + page `/historique-versions`
+- Procédure PR « nouvel arrêté » détaillée dans [`docs/versions.md`](./docs/versions.md)
+
+Quand un nouvel arrêté entre en vigueur :
+
+1. Copier les sources datées dans `docs/sources/`
+2. Régénérer la fixture (`pnpm fixture:abattoirs`)
+3. Adapter les règles jusqu'à `pnpm test` vert
+4. **Ajouter une entrée en tête de `ABATTOIRS_VERSIONS`** avec `dateEffet` (ISO), `arrete`, `sources`, `changements`, `pullRequest`
+5. `pnpm validate`
+6. Commit `feat(<context>): nouvelle version YYYY-MM-DD`
+
+La spec `versions.spec.ts` garantit l'ordre antéchronologique strict et le format ISO des dates.
+
+## Monitoring des erreurs
+
+Pas de Sentry — solution maison légère, RGPD-friendly, zéro dépendance.
+
+**Pipeline (Phase 1)** :
+
+1. `installGlobalHandlers()` dans `src/main.tsx` pose `window.error` + `unhandledrejection`.
+2. `<ErrorBoundary>` dans `src/App.tsx` wrappe `<Routes>` et capture les erreurs de rendu React.
+3. Tous les chemins appellent `reportError(error, context)` qui log un payload structuré via `console.error("[ODICE error]", { … })`.
+
+**Visibilité actuelle** : DevTools utilisateur uniquement (console).
+
+**Phase 2 (à venir)** : `reportError` POSTera le payload vers un endpoint configurable via `VITE_ERROR_ENDPOINT` (Mattermost webhook ou petit endpoint Scalingo Node).
+
+**Fichiers** :
+
+- `src/shared/monitoring/error-reporter.ts` — `reportError(error, context)`
+- `src/shared/monitoring/install-global-handlers.ts` — listeners globaux
+- `src/shared/components/ErrorBoundary.tsx` — boundary React
+- `src/features/error/pages/ErrorFallbackPage.tsx` — UI de fallback
+
+**Tester en local** :
+
+```ts
+// dans n'importe quel composant
+throw new Error("test ErrorBoundary");
+```
 
-1. d'un test Vitest qui couvre le nouveau cas (`src/engine/evaluate.spec.ts`)
-2. d'une référence à la source réglementaire (instruction technique, arrêté, etc.) dans un commentaire
+Ou depuis la console DevTools : `throw new Error("test")` (capté par `window.error`).
 
 ## Tests
 
 
@@ -0,0 +1,104 @@
+# ADR-0002 : Architecture DDD « propre mais simple » pour le moteur ODICE
+
+**Date** : 2026-05-23
+**Statut** : Accepté
+
+## Contexte
+
+Le moteur ODICE doit héberger deux simulateurs distincts (Abattoirs, Autres Établissements) qui partagent certains concepts (zones réglementaires, marques sanitaires…) mais ont chacun leur propre logique métier, leurs propres inputs et leurs propres outputs.
+
+L'arborescence initiale (`src/engine/{types,rules,evaluate}.ts` à plat) ne tient pas la charge dès qu'on commence à implémenter les 5 fonctions de règles + leurs schémas Zod + leurs tests. On observe :
+
+- un fichier `types.ts` qui mélange enums partagés et types spécifiques à un simulateur,
+- un fichier `schemas.ts` qui mélange définitions de données (schémas Zod) et logique de validation (fonctions parse),
+- aucun frontière nette entre les deux simulateurs (risque d'imports croisés involontaires).
+
+## Décision
+
+> Nous structurons `src/engine/` en **bounded contexts DDD**, avec un shared kernel minimal et une séparation explicite des responsabilités dans chaque context, sans introduire de patterns plus lourds (Repository, DI, Domain Service abstrait…).
+
+Structure :
+
+```
+src/engine/
+├── index.ts                       # Public API du moteur (re-exports)
+├── shared/                         # Shared kernel
+│   ├── types.ts                    # Enums communs (Zone, Statut, Marque, ...)
+│   └── index.ts
+├── abattoirs/                     # Bounded context #1
+│   ├── index.ts                    # API publique du context
+│   ├── types.ts                    # AbattoirsInputs, AbattoirsOutputs
+│   ├── schema.ts                   # Schémas Zod (data definition pure)
+│   ├── parse.ts                    # Fonctions de validation
+│   ├── evaluate.ts                 # Orchestrateur
+│   ├── evaluate.spec.ts            # Test oracle (fixture 2 744 cas)
+│   └── rules/                      # Règles atomiques
+│       └── *.ts + *.spec.ts
+└── etablissements/                # Bounded context #2 (placeholder)
+```
+
+## Options envisagées
+
+### Option A — DDD « propre mais simple » (retenue)
+
+- Avantages :
+  - Isolation forte entre simulateurs (aucun import croisé possible par convention).
+  - Public API explicite via `index.ts` par context.
+  - Séparation des couches data / validation / logique à l'intérieur d'un context.
+  - Évolutif : ajouter un nouveau simulateur = créer un nouveau dossier sans toucher l'existant.
+- Inconvénients :
+  - Plus de fichiers que le « flat » initial.
+  - Un peu plus de boilerplate (index.ts par dossier).
+
+### Option B — Flat (`src/engine/{types,rules,evaluate}.ts`)
+
+- Avantages :
+  - Très peu de fichiers.
+- Inconvénients :
+  - Ne tient pas la charge à plus d'un simulateur.
+  - Pas de frontière naturelle entre simulateurs.
+  - Mélange data definition / validation / logique dans un même fichier.
+
+### Option C — DDD « tactical » complet (Aggregates, Domain Services, Value Objects, Repository, DI…)
+
+- Avantages :
+  - Architecture la plus pure.
+- Inconvénients :
+  - Sur-ingénierie pour un moteur de règles déterministe sans persistance.
+  - Cohérence avec le style « pragmatique Beta.gouv » discutable.
+  - Coût d'entrée pour les contributeurs.
+
+## Conséquences
+
+### Positives
+
+- Le moteur reste pur TypeScript, testable sans React (règle d'or maintenue).
+- Chaque simulateur peut évoluer indépendamment.
+- Les imports sont prévisibles : `@engine` (racine), `@engine/abattoirs`, `@engine/shared`.
+- L'arrivée du 2e simulateur (Établissements) ne nécessitera aucun refactor — il suffira de remplir le dossier `etablissements/`.
+
+### Négatives / Risques
+
+- Surface plus large à parcourir au démarrage. **Mitigation** : section Architecture du `CLAUDE.md` explicite.
+- Tentation d'ajouter des couches au fil du temps. **Mitigation** : règle « pas de couches inutiles » dans CLAUDE.md.
+
+### Migration
+
+Effectuée dans cette même PR :
+
+1. Création de `shared/`, `abattoirs/`, `etablissements/` avec leurs `index.ts`.
+2. Éclatement de `types.ts` → `shared/types.ts` (enums communs) + `<context>/types.ts` (types spécifiques).
+3. Split de `schemas.ts` → `abattoirs/schema.ts` (Zod pur) + `abattoirs/parse.ts` (fonctions).
+4. Suppression des anciens fichiers racine (`types.ts`, `schemas.ts`, `evaluate.ts`, `evaluate.spec.ts`, `rules.ts`).
+5. Création de `src/engine/index.ts` qui re-export tout.
+6. Ajout de l'alias `@engine` (sans wildcard) dans tsconfig (Vite/Vitest l'avaient déjà).
+7. Adaptation de `src/shared/components/ResultPanel.tsx` (1 ligne d'import).
+8. Migration du script de fixture `.mjs` → `.ts` avec imports typés depuis les enums du moteur (typecheck garantit la cohérence du mapping xlsx → enum).
+
+`pnpm validate` reste vert après chacune des étapes.
+
+## Liens
+
+- Documentation métier : [`docs/simulateur-abattoirs.md`](../simulateur-abattoirs.md)
+- Points à valider avec l'équipe métier : [`docs/simulateur-abattoirs-points-a-valider.md`](../simulateur-abattoirs-points-a-valider.md)
+- CLAUDE.md, section « Architecture »
Original file line number	Diff line number	Diff line change
`@@ -1,6 +1,5 @@`
`1`	`1`	`{`
`2`		`- "typescript.preferences.importModuleSpecifier": "relative",`
`3`		`- "javascript.preferences.importModuleSpecifier": "relative",`
	`2`	`+ "js/ts.preferences.importModuleSpecifier": "relative",`
`4`	`3`	`"editor.formatOnSave": true,`
`5`	`4`	`"editor.defaultFormatter": "esbenp.prettier-vscode",`
`6`	`5`	`"[typescript]": {`