# Architecture — Bati Univers

## Vision

Bati Univers est un **monorepo léger** qui regroupe 4 applications BTP autonomes sous une porte d'entrée commune (hub HTML). Il s'agit d'une fusion **structurelle**, pas d'une refonte de code.

## Schéma global

```
┌──────────────────────────────────────────────────────────────────┐
│  Bati Univers  (~/Library/Mobile Documents/com~apple~CloudDocs/) │
│                                                                  │
│  ┌──────────────────┐                                            │
│  │ hub/index.html   │  ← Porte d'entrée unifiée                  │
│  │ (4 cartes)       │                                            │
│  └─────────┬────────┘                                            │
│            │                                                     │
│   ┌────────┴────────┬──────────────┬──────────────┐              │
│   ▼                 ▼              ▼              ▼              │
│ ┌─────────┐  ┌──────────────┐  ┌──────────┐  ┌──────────┐        │
│ │ Mesure  │  │ Rapport      │  │ Plan     │  │ Terrain  │        │
│ │ (apps/) │  │ (apps/)      │  │ (apps/)  │  │ squelette│        │
│ │         │  │              │  │          │  │          │        │
│ │ Mono-   │  │ Mono-fichier │  │ Vite     │  │ TODO     │        │
│ │ repo    │  │ HTML 1.41 Mo │  │ + React  │  │          │        │
│ │ Turbo   │  │ PWA offline  │  │ + Three  │  │          │        │
│ │ Fastify │  │              │  │ + idb    │  │          │        │
│ │ + RN    │  │              │  │          │  │          │        │
│ │ + PG/   │  │              │  │          │  │          │        │
│ │ Couch   │  │              │  │          │  │          │        │
│ └─────────┘  └──────────────┘  └──────────┘  └──────────┘        │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘
```

## Principes architecturaux

### 1. Apps autonomes
Chaque `apps/<module>/` est un projet indépendant avec :
- Son propre `package.json` (ou `MISSING.md` pour terrain)
- Son propre cycle de build/test/dev
- Ses propres dépendances
- Son propre déploiement (futur)

Cela permet de :
- Faire évoluer un module sans casser les autres.
- Choisir la stack optimale pour chaque domaine.
- Faciliter la maintenance par des contributeurs différents.

### 2. Pas de SPA unifiée
Une option aurait été de fusionner les 4 apps en une seule SPA avec routes `/mesure /report /plan /terrain`. **Cette option a été rejetée** car :
- Les stacks sont incompatibles (mono-fichier HTML vs monorepo Turbo).
- La fusion casserait au moins l'un des projets.
- Le bénéfice "URL unique" est faible vs le coût de refactor.

À la place : un **hub statique** (`hub/index.html`) qui présente les 4 modules visuellement et redirige vers chacun. Simple, robuste, sans dépendance JS.

### 3. iCloud comme storage primaire
Le projet vit dans `~/Library/Mobile Documents/com~apple~CloudDocs/BatiUnivers/`.

Avantages :
- Sync automatique vers tous les appareils Apple de l'utilisateur.
- Backup automatique côté Apple.
- Pas de configuration cloud supplémentaire.

Limites :
- Conflits possibles en cas d'édition simultanée multi-device.
- Performance : peut être plus lent qu'un SSD local (surtout sur fichiers volumineux).
- `node_modules/` à NE PAS stocker dans iCloud (exclus de toutes les copies).

### 4. Backup à 3 niveaux

| Niveau | Emplacement | Rôle |
|---|---|---|
| 1. Sources Desktop | `/Users/genius/Desktop/Bureau.../{mesurepro,mesurepro-next,batireport,batiplan}` | Sources actives connectées à GitHub |
| 2. Pristine BatiUnivers | `_original_sources/` (iCloud) | Copie immuable post-fusion (vérifiée SHA-256) |
| 3. Apps de travail | `apps/` (iCloud) | Code modifié pour le contexte Bati Univers |

En cas de problème, on peut revenir au niveau supérieur. Plus l'archive `_archive_safe/mesurepro-legacy-v3d/` pour le legacy V3D.

### 5. Hub HTML statique, pas de framework
Le hub utilise du HTML/CSS pur (avec un peu de CSS variables pour le mode sombre). Aucune dépendance JavaScript. Avantages :
- Ouvrable directement avec `open hub/index.html`.
- Résistant à l'obsolescence (pas de framework qui peut casser).
- Léger (< 10 Ko).

## Modèles de données

Chaque module a ses propres modèles. Voir :
- `apps/mesure/api/prisma/schema.prisma` (PostgreSQL multi-tenant)
- `apps/report/reference/schema.sql` (futur backend V2)
- `apps/plan/src/modules/` (IndexedDB côté client)

Aucun modèle commun pour l'instant. Une harmonisation est un projet futur (ex : type `Client` partagé via `packages/shared/`).

## Flux d'authentification

- **mesure** : Auth0 + JWT RS256 (multi-tenant)
- **report** : local-first, pas d'auth (futur : JWT propriétaire)
- **plan** : local-first, pas d'auth
- **terrain** : N/A

Une SSO commune est un projet d'évolution potentiel.

## Communications inter-modules

**Aucune.** Chaque app est isolée.

Si un module a besoin d'appeler un autre (ex : générer un rapport `report` depuis un projet `plan`), il faudra :
- Exposer une API REST publique côté module appelé.
- L'appeler depuis le module appelant.
- Pour l'instant : pas de cas d'usage concret.

## Évolution future

### Court terme (1-3 mois)
- Initialiser git pour Bati Univers.
- Push Bati Univers sur GitHub privé (`Geniuspro71/bati-univers`).
- Compléter le module terrain quand un projet sera désigné.

### Moyen terme (3-6 mois)
- Créer `packages/shared/` avec types/utils communs (ex : i18n, validation TVA BE).
- Aligner versions React 18.2 ↔ 18.3 si partage de composants.
- Documentation utilisateur unifiée.

### Long terme (6-12 mois)
- Une SSO commune (Auth0).
- Une API gateway commune.
- Un dashboard cross-modules (KPIs business agrégés).
- Migration progressive du mono-fichier batireport vers une stack modulable (NestJS).