Premiere commit - Omika

docs/DEPLOIEMENT_PRODUCTION_DIAGNOSTICS.md

@@ -0,0 +1,446 @@
+# Déploiement Production — Diagnostics multi-serveurs (T19/T20)
+
+> Statut : préparation (aucun déploiement réel effectué). Document de référence pour le
+> futur déploiement contrôlé du Diagnostic Center central et de l'API métier/mobile chez
+> chaque client. Aucune valeur de secret (clé, mot de passe) n'est contenue ici.
+
+---
+
+## 1. Responsabilités des composants (§30)
+
+| Composant | Rôle | Installation |
+|---|---|---|
+| **Omika.Api** | API métier/mobile installée **chez chaque client** (licence, bootstrap, métier, `POST /api/diagnostics`). Le mobile ne connaît QUE cette API. | Serveur du client |
+| **Omika.Diagnostics.Api** | API **centrale**, installée **uniquement sur le serveur Omika**. Reçoit les lots des serveurs clients (`POST /api/v1/diagnostics/batches`), authentifie (ClientCode + ApiKey), impose le ClientCode authentifié, écrit le spool central. Aucune logique métier. | Serveur central Omika |
+| **Omika.Diagnostics.Worker** | Import du spool central JSONL → PostgreSQL (`diagnostic_event`). Déduplication par `event_id`. | Serveur central Omika |
+| **Omika.Diagnostics.Web** | Interface de consultation/administration (Dashboard, Diagnostics, Erreurs, Télémétrie, Référentiel, **Clients Diagnostics**, Système). | Serveur central Omika |
+
+Le **mobile** ne connaît jamais `Omika.Diagnostics.Api/Worker/Web`, ni PostgreSQL Diagnostics, ni aucune
+clé central. Le **serveur client** ne connaît jamais la ConnectionString PostgreSQL centrale
+(§43) : seul le composant central autorisé détient cette configuration.
+
+---
+
+## 2. Architecture de flux
+
+```
+APPAREILS MOBILES ──HTTPS──▶ SERVEUR DU CLIENT
+                              Omika.Api (+ Omika.Worker métier)
+                              └─▶ Spool local borné (DiagnosticsForwarding.Spool)
+                                    └─▶ DiagnosticsForwarder (BackgroundService dans Omika.Api)
+                                          └─ HTTPS ──▶ SERVEUR OMIKA CENTRAL
+                                                        Omika.Diagnostics.Api
+                                                        └─▶ Spool central (Diagnostics:Central)
+                                                              └─▶ Omika.Diagnostics.Worker
+                                                                    └─▶ PostgreSQL omika_diagnostics
+                                                                          └─▶ Omika.Diagnostics.Web
+```
+
+---
+
+## 3. Services Windows cibles (§51)
+
+### Serveur client
+- `OmikaApi` (process Omika.Api ; contient le forwarder de diagnostics — **aucun service dédié**).
+- `OmikaWorker` (Worker de synchronisation métier, service réel existant).
+- API Licence / service existant (inchangé).
+
+### Serveur central Omika
+- `OmikaDiagnosticsApi` (API centrale, Kestrel).
+- `OmikaDiagnosticsWorker` (import JSONL → PostgreSQL).
+- `OmikaDiagnosticsWeb` (interface, Kestrel derrière reverse proxy Apache).
+- PostgreSQL (`omika_diagnostics`).
+
+Les noms de services sont posés par les scripts d'activation serveur (`sc.exe` / `New-Service`)
+et doivent correspondre aux valeurs `UseWindowsService(...)` du code.
+
+---
+
+## 4. Ports (§52)
+
+| Service | Port local Développement | Port Production (à confirmer selon convention existante) |
+|---|---|---|
+| Omika.Api (client) | 5097 | défini par `Kestrel:Endpoints` / `appsettings.Production.json` (loopback derrière Apache) |
+| Omika.Diagnostics.Api (central) | 5098 | à définir (loopback Kestrel derrière Apache/HTTPS) |
+| Omika.Diagnostics.Web (central) | 5080 | à définir (loopback Kestrel derrière Apache/HTTPS) |
+| PostgreSQL | 5432 | 5432 (loopback central uniquement) |
+
+**Règle** : les services web sont exposés en **HTTPS** via le reverse proxy Apache ; Kestrel reste
+en HTTP sur loopback. Aucun port n'est choisi arbitrairement : la convention Apache/Kestrel
+existante de `omika.applilogik.fr` s'applique.
+
+---
+
+## 5. HTTPS (§37/§38)
+
+- Le flux **serveur client → API centrale** est **HTTPS uniquement** en Production.
+- `DiagnosticsForwarding:Endpoint` doit être une URL **`https://…`**.
+- **Règle T20** : si l'environnement est **Production** et que l'Endpoint est en **`http://`**,
+  le forwarder **refuse l'envoi** (log explicite une fois), le **métier continue** (fail-open),
+  le spool local est conservé. `Omika.Api` n'est **jamais** arrêté à cause de Diagnostics.
+- Le certificat TLS réel n'est **pas** configuré dans ce document (à poser sur le reverse proxy).
+
+---
+
+## 6. Configuration Omika.Api (§31/§32/§33/§34/§35)
+
+Section `DiagnosticsForwarding` (dans `src/Omika.Api/appsettings.json`, surchargée par variables
+d'environnement / `appsettings.Production.json` **non versionné**) :
+
+| Clé | Défaut | Rôle |
+|---|---|---|
+| `DiagnosticsForwarding:Enabled` | `false` | Kill switch. **`DiagnosticsForwarding__Enabled=true` uniquement lors du déploiement serveur client.** |
+| `DiagnosticsForwarding:Endpoint` | `""` | URL centrale absolue **HTTPS** (ex. `https://…/api/v1/diagnostics/batches`). Laisser vide tant qu'aucune URL réelle. |
+| `DiagnosticsForwarding:ApiKey` | `""` | **Secret** à installer sur le serveur client via `DiagnosticsForwarding__ApiKey`. Jamais dans Git/log/rapport. |
+| `DiagnosticsForwarding:TimeoutSeconds` | `10` | Timeout réseau d'un envoi (le forwarder est background : jamais de blocage métier). |
+| `DiagnosticsForwarding:BatchSize` | `100` | Événements max par lot. |
+| `DiagnosticsForwarding:MaxBatchBytes` | `524288` | Taille max d'un lot (premier seuil). |
+| `DiagnosticsForwarding:RetryInitialSeconds` | `15` | Backoff initial. |
+| `DiagnosticsForwarding:RetryMaxMinutes` | `30` | Plafond du backoff. |
+| `DiagnosticsForwarding:Spool:MaxFileSizeMb` | `10` | Rotation de fichier. |
+| `DiagnosticsForwarding:Spool:MaxTotalSizeMb` | `1024` | Quota disque total. |
+| `DiagnosticsForwarding:Spool:RetentionDays` | `14` | Rétention. |
+
+Le défaut `Enabled=false` est **volontaire** (sécurité, opt-in). Aucun placeholder fictif
+(`https://diagnostics.exemple.fr`) ne doit devenir une valeur réelle accidentellement.
+
+---
+
+## 7. Configuration Omika.Diagnostics.Api (§36)
+
+Section `Diagnostics` (dans `src/Omika.Diagnostics.Api/appsettings.json`, surchargée par variables) :
+
+| Clé | Défaut | Rôle |
+|---|---|---|
+| `ConnectionStrings:DiagnosticsDatabase` (ou `Diagnostics:ConnectionString`) | `""` | PostgreSQL central (secret, injecté serveur). |
+| `Diagnostics:Central:Directory` | `logs/diagnostics-central` | **Spool central** — en Production, chemin explicite (voir §9). |
+| `Diagnostics:Central:MaxRequestBodyBytes` | `524288` | Corps de requête borné. |
+| `Diagnostics:Central:MaxEventsPerBatch` | `100` | Événements max par lot. |
+| `Diagnostics:Central:SchemaVersion` | `1` | Version de schéma de transport. |
+
+URL/port : via `ASPNETCORE_URLS` (ou `Kestrel:Endpoints`) derrière le reverse proxy HTTPS.
+
+---
+
+## 8. Spool client — emplacement Production (§40)
+
+Le service Windows peut démarrer depuis `C:\Windows\System32` : **ne jamais dépendre du current
+working directory**. Utiliser un chemin explicite configurable :
+
+```
+C:\ProgramData\Omika\Diagnostics\Spool
+```
+
+(via `Observability:Remote:Directory` / `DiagnosticsForwarding` — à poser dans la configuration
+serveur client). Le quota (`MaxTotalSizeMb`) et la rétention (`RetentionDays`) évitent un
+remplissage disque : à quota atteint, les fichiers les plus anciens sont supprimés (log du
+nombre), jamais le fichier actif, jamais d'échec métier.
+
+---
+
+## 9. Spool central — emplacement Production (§41)
+
+Même réflexion pour `Omika.Diagnostics.Api` :
+
+```
+C:\ProgramData\Omika\Diagnostics\Central
+```
+
+(via `Diagnostics:Central:Directory`). Le Worker central lit ce dossier (import JSONL → PostgreSQL,
+checkpoint `import-checkpoint.json`).
+
+---
+
+## 10. Permissions Windows (§42)
+
+Principe de moindre privilège (jamais Administrateur inutilement) :
+
+| Compte service | Dossier | Droits |
+|---|---|---|
+| `OmikaApi` | `C:\ProgramData\Omika\Diagnostics\Spool` | lecture + écriture |
+| `OmikaDiagnosticsApi` | `C:\ProgramData\Omika\Diagnostics\Central` | lecture + écriture |
+| `OmikaDiagnosticsWorker` | `C:\ProgramData\Omika\Diagnostics\Central` | lecture (checkpoint → écriture du checkpoint selon le dossier) |
+
+---
+
+## 11. PostgreSQL (§43/§54)
+
+- Base dédiée `omika_diagnostics`. PostgreSQL **ne doit jamais être exposé** aux serveurs clients :
+  seuls les composants centraux autorisés y accèdent (firewall : loopback central uniquement).
+- Rôles : voir migrations `003`/`004`/`009`/`010` (`omika_diagnostics_owner`, `_worker`, `_web`, `_api`).
+  - `omika_diagnostics_api` (LOGIN) : **Omika.Diagnostics.Api** — `SELECT` + `UPDATE(last_seen_at_utc)` sur `diagnostics_clients` uniquement. **Aucun** droit sur `diagnostics_users`.
+  - `omika_diagnostics_web` (LOGIN) : **Omika.Diagnostics.Web** — `SELECT` sur `diagnostic_event` ; `SELECT`/`INSERT`/`UPDATE` sur `diagnostics_clients` (admin `/Clients`) ; `SELECT`/`INSERT`/`UPDATE` (colonnes `password_hash`, `role`, `enabled`, `updated_at_utc`, `password_changed_at_utc`, `last_login_at_utc`) + `USAGE` séquence sur `diagnostics_users` (admin `/Users` + login).
+  - `omika_diagnostics_worker` (LOGIN) : **Omika.Diagnostics.Worker** — `INSERT`/`SELECT`/`DELETE` sur `diagnostic_event` ; **aucun** droit sur `diagnostics_clients` ni `diagnostics_users`.
+- Le serveur client **NE DOIT PAS** connaître la ConnectionString PostgreSQL centrale.
+
+---
+
+## 12. Migrations — inventaire (§44/§45/§46)
+
+Ordre d'application sur le serveur central : `001 → 002 → 003 → 004 → 005 → 006 → 007 → 008 → 009 → 010`.
+
+| Fichier | But | Développement appliqué ? | Production nécessaire ? |
+|---|---|---|---|
+| `001_diagnostics_schema.sql` | `diagnostic_event` + `telemetry_metric_hourly` + index + déduplication `event_id`. | Oui | Oui |
+| `002_actor_key.sql` | Colonnes `actor_key`/`actor_key_version` (HMAC pseudonymisation). | Oui | Oui |
+| `003_diagnostics_roles.sql` | Rôles/grants serveur (`owner`/`worker`/`web`), moindre privilège. | **Non** (à exécuter sur le serveur PostgreSQL Production, en superuser) | Oui |
+| `004_diagnostics_retention.sql` | Grant `SELECT, DELETE` au worker pour la rétention bornée. | **Non** (idem, serveur Production) | Oui |
+| `005_diagnostics_client_context.sql` | Colonnes `client_code`/`server_instance`/`environment`. | Oui | Oui |
+| `006_diagnostics_device_license.sql` | Colonnes appareil/licence. | Oui | Oui |
+| `007_diagnostics_usage.sql` | Colonnes `screen_code`/`feature_code`. | Oui | Oui |
+| `008_diagnostics_clients.sql` | Table `diagnostics_clients` (registre des serveurs clients, hash SHA-256). | Oui | Oui |
+| `009_diagnostics_clients_grants.sql` | Ownership + GRANT moindre privilège de `diagnostics_clients` (`_api`/`_web`), rôle `omika_diagnostics_api`. | **Non** (serveur PostgreSQL Production, superuser) | Oui |
+| `010_diagnostics_web_users.sql` | Table `diagnostics_users` (utilisateurs Web) + ownership `omika_diagnostics_owner` + GRANT moindre privilège `_web` uniquement (aucun droit API/Worker). | **Non** (serveur PostgreSQL Production, superuser) | Oui |
+
+**003/004/009/010** : contiennent des `CREATE ROLE` / `ALTER ROLE` / `GRANT` au niveau **serveur/instance**.
+Elles ne sont **pas** appliquées sur le PC de développement (elles exigent le superuser PostgreSQL
+Production et fixent les comptes de service). Elles devront être exécutées **sur le serveur
+PostgreSQL Production**, dans l'ordre, **avant** le pointage des comptes de service
+Worker/Web/Api (`omika_diagnostics_worker` / `omika_diagnostics_web` / `omika_diagnostics_api`),
+puis les mots de passe posés manuellement (`\password`, jamais dans un script/log).
+Ne pas les exécuter localement « pour du vert ».
+
+> **T22** : `008` crée `diagnostics_clients` **après** `003`/`004`, donc sans ownership ni GRANT
+> applicatif. `009` transfère la propriété à `omika_diagnostics_owner` (même propriétaire logique
+> que `diagnostic_event`/`telemetry_metric_hourly`), crée le rôle `omika_diagnostics_api` (absent du
+> modèle `003`), et pose les GRANT minimum identifiés par l'audit des consommateurs réels :
+> API = `SELECT` + `UPDATE(last_seen_at_utc)` ; Web = `SELECT`/`INSERT`/`UPDATE(enabled, api_key_hash,
+> key_prefix, key_created_at_utc)` + `USAGE` séquence ; Worker = aucun. `009` est idempotent
+> (re-exécutable sans erreur) et utilise `current_database()` pour `GRANT CONNECT` (portable,
+> testé sur `omika_diagnostics_preprod`).
+
+---
+
+## 13. Authentification ApiKey — audit final (§55/§56)
+
+- Clé : **32 octets aléatoires**, **Base64Url**, préfixe **`omkdiag_`**.
+- Stockage : **SHA-256 hexadécimal (64)** uniquement (`diagnostics_clients.api_key_hash`) + `key_prefix`.
+- Vérification : `CryptographicOperations.FixedTimeEquals` ; hash factice si client inconnu (anti-timing).
+- **401** : client inconnu OU mauvaise clé (indistinguables). **403** : client désactivé.
+- **Tenant autoritaire** : tout ClientCode payload ≠ authentifié → **400** + anomalie (jamais de confiance au payload).
+- Réponses sans fuite : jamais de hash, de clé, de stacktrace, ni l'existence précise d'un client.
+
+---
+
+## 14. Procédure — nouveau client Production (§73)
+
+1. `Omika.Diagnostics.Web` → **Clients Diagnostics** (Admin).
+2. **Nouveau client**.
+3. Saisir le **CodeClient exact** (ex. `BATIK.01`, normalisé `UPPER(TRIM)`).
+4. **Créer le client** → la clé est générée.
+5. **Copier immédiatement** la clé (bouton « Copier »).
+6. Installer la clé sur le serveur client : variable `DiagnosticsForwarding__ApiKey`.
+7. Configurer `DiagnosticsForwarding__Endpoint` (URL centrale **HTTPS**).
+8. Activer : `DiagnosticsForwarding__Enabled=true`.
+9. Redémarrer `OmikaApi`.
+10. Vérifier `last_seen_at_utc` dans Clients Diagnostics.
+11. Vérifier un diagnostic réel (Dashboard / Diagnostics).
+
+---
+
+## 15. Clé perdue (§74)
+
+La clé **n'est pas récupérable** (hash seul stocké). Si elle n'a pas été copiée :
+faire **Régénérer la clé**, puis mettre à jour le serveur client avec la nouvelle clé.
+
+---
+
+## 16. Rotation de clé (§75)
+
+Version V1 : **régénération → ancienne clé immédiatement invalide**. Pendant l'intervalle où le
+serveur client n'a pas encore la nouvelle clé, les envois échouent en `401` et le **spool local
+s'accumule** (backlog borné, reprise automatique). Acceptable.
+
+---
+
+## 17. Panne centrale (§76)
+
+- **Ne pas arrêter** `OmikaApi` (le métier continue).
+- **Ne pas vider** le spool manuellement (les événements seront renvoyés).
+- Vérifier l'espace disque (quota/rétention bornent le spool).
+- Vérifier les logs du forwarder.
+- Attendre le rétablissement : reprise automatique (backoff borné 15 s → 30 min).
+
+---
+
+## 18. Disque spool (§77)
+
+- `MaxTotalSizeMb` (défaut 1024) : quota disque total ; à dépassement, suppression des fichiers
+  les plus anciens (jamais le fichier actif, log du nombre supprimé).
+- `RetentionDays` (défaut 14) : purge des fichiers plus anciens.
+- `MaxFileSizeMb` (défaut 10) : rotation de fichier.
+- **Fail-open absolu** : aucune de ces opérations ne bloque le métier.
+
+> **Validation empirique T22** (pipeline réel, panne centrale simulée) :
+> - Quota `MaxTotalSizeMb=1` : 6000 événements fake (~3,6 Mo) → `DiagnosticsForwarder a abandonné
+>   14 fichier(s) de spool`, spool final 768 Ko (≤ 1 Mo), fichier actif préservé, `/health` 200
+>   (aucun crash métier), Working Set stable ~115–125 Mo (backlog sur disque ≠ RAM).
+> - Rétention `RetentionDays=1` : fichier ancien (-2 j) supprimé, fichier récent + fichier actif
+>   conservés, central DOWN pendant tout le test (la maintenance ne dépend pas du central).
+> - **Correctif T22** : `EnforceBounds` (quota/rétention) était appelé uniquement quand le spool
+>   était vide ; pendant une panne centrale (backlog jamais vide), le quota n'était donc pas
+>   appliqué. Il est désormais appelé à chaque passe du forwarder, indépendamment du backlog.
+>   Test : `ForwardOnce_BacklogOverQuota_StillEnforcesBounds`.
+
+---
+
+## 19. Ordre de démarrage (reprise/rollback)
+
+**Démarrage central** : PostgreSQL → `OmikaDiagnosticsWorker` → `OmikaDiagnosticsApi` →
+`OmikaDiagnosticsWeb`.
+
+**Démarrage client** : `OmikaWorker` (métier) → `OmikaApi` (métier + forwarder).
+
+**Rollback** : `DiagnosticsForwarding__Enabled=false` + redémarrage `OmikaApi` coupe immédiatement
+tout envoi central sans toucher au métier ni au spool (aucune perte de données).
+
+---
+
+## 20. Dépendance SQLite (mobile / Desktop local)
+
+> Mise à jour **T22** — audit + correctif CVE.
+
+- **Version retenue** : `Microsoft.Data.Sqlite 10.0.10` (inchangé) + **`SQLitePCLRaw` 2.1.12**
+  épinglé transitivement (`Directory.Packages.props`, `CentralPackageTransitivePinningEnabled=true`).
+- **Raison** : `SQLitePCLRaw.lib.e_sqlite3 2.1.11` (transitif de `Microsoft.Data.Sqlite 10.0.10`)
+  embarque une bibliothèque SQLite native < 3.50.2, vulnérable à **CVE-2025-6965 /
+  GHSA-2m69-gcr7-jv3q** (troncature d'entier dans `findOrCreateAggInfoColumn`, `resolve.c`).
+  Correctif = SQLite native **3.50.2**, livré par le patch **2.1.12** (famille 2.x, drop-in,
+  ABI-compatible). **Pas** de saut vers SQLitePCLRaw 3.x (breaking) ni vers
+  `Microsoft.Data.Sqlite 11` (majeur).
+- **Projets concernés** : `Omika.App.Local` (offline-first : cache métier, brouillons, sync,
+  `DiagnosticOutboxSqliteStore`) → `Omika.App` → têtes `Omika.App.Desktop` / `Omika.App.Android` /
+  `Omika.App.iOS`. Aucun impact sur `Omika.Api`, `Omika.Worker` ni les projets Diagnostics.
+- **Validation** :
+  - `dotnet restore` OK ; `dotnet list package --include-transitive --vulnerable` →
+    **« aucun package vulnérable »** ; arbre confirmé `SQLitePCLRaw.* = 2.1.12`.
+  - Tests SQLite/Outbox ciblés : **148/148**.
+  - Builds Release : `Omika.App.Desktop` 0 erreur, `Omika.App.Android` 0 erreur.
+  - `Omika.App.Desktop` (Debug, flux dev) démarré réellement : ouverture `omika.db` OK +
+    bootstrap `DEV BOOTSTRAP` OK (aucun crash SQLite).
+
+> **Surface réellement exposée** : la vulnérabilité nécessite une requête SQL construite avec un
+> nombre extrême de termes d'agrégation ; Omika n'exécute que des requêtes applicatives fixes et
+> paramétrées (jamais de SQL utilisateur), sur une base **locale** non accessible à distance. Le
+> correctif 2.1.12 est néanmoins appliqué (moindre coût, aucun risque de régression constaté).
+
+---
+
+## 21. Gestion des utilisateurs Diagnostics.Web (T23)
+
+### 21.1 Distinction fondamentale
+
+| Concept | Définition | Identifiant | Stockage |
+|---|---|---|---|
+| **Utilisateur Diagnostics** | personne qui ouvre `Omika.Diagnostics.Web` | `username` | `diagnostics_users` (hash PBKDF2-SHA256) |
+| **Client Diagnostics** | serveur client qui envoie des événements | `ClientCode` | `diagnostics_clients` (hash SHA-256) |
+
+Les deux registres sont **totalement séparés** et ne doivent jamais être confondus.
+
+### 21.2 Modèle utilisateur
+
+- Table `diagnostics_users` (migration `010`) : `id`, `username` (unique, insensible à la casse),
+  `password_hash`, `role` (`Support` / `Admin`), `enabled`, `created_at_utc`, `updated_at_utc`,
+  `password_changed_at_utc`, `last_login_at_utc`.
+- **Aucun mot de passe en clair** : seule la colonne `password_hash` existe. Le hash est produit
+  par `DiagnosticPasswordHasher` (PBKDF2-SHA256, 100 000 itérations, sel aléatoire).
+- **Aucune suppression physique** (V1) : un utilisateur est **désactivé** (`enabled=false`), jamais `DELETE`.
+
+### 21.3 Rôles
+
+| Rôle | Accès |
+|---|---|
+| **Support** | Dashboard, Diagnostics, Erreurs, Traces, Synchronisation, Telemetry, Parc, Versions, Référentiel, Mon compte. |
+| **Admin** | Tout Support + **Clients Diagnostics** + **Utilisateurs** + **Système**. |
+
+`/System`, `/Clients` et `/Users` sont **Admin uniquement**. Un Support y obtient un refus
+(redirection `/AccessDenied`). Un Admin conserve tous les droits de consultation Support.
+
+### 21.4 Actions d'administration (`/Users`, Admin uniquement)
+
+- **Création** : saisie `username` + `password` + `confirmation` + `rôle`. Le Web hache
+  automatiquement (`DiagnosticPasswordHasher.Hash`) ; l'Admin ne génère/copie **jamais** un hash.
+- **Désactivation / Réactivation** (`enabled=false/true`).
+- **Changement de rôle** `Support → Admin` / `Admin → Support`.
+- **Réinitialisation du mot de passe** (nouveau mot de passe + confirmation → hash + UPDATE).
+
+### 21.5 Protections
+
+- **Dernier Admin** : impossible de désactiver ou rétrograder le dernier Admin actif
+  (« Impossible de retirer le dernier administrateur actif. »).
+- **Auto-désactivation** : un Admin ne peut pas désactiver son propre compte.
+- **Auto-rétrogradation** : un Admin ne peut pas retirer son propre rôle Admin.
+
+### 21.6 Règles de validation
+
+- **Username** : obligatoire, `trim`, unicité insensible à la casse, borné (≤ 64), caractères
+  `lettres / chiffres / . / - / _`.
+- **Mot de passe** : non vide, **≥ 12 caractères**, confirmation identique. Pas de politique de
+  complexité superflue (V1).
+
+### 21.7 Connexion (login hybride)
+
+1. Si le `username` existe dans `diagnostics_users` → la DB est **autoritaire** (jamais de fallback).
+   - Vérification PBKDF2 (`DiagnosticPasswordHasher.Verify`) ; `enabled=false` → refus.
+2. Sinon → fallback opérateurs `DiagnosticsAuth:Operators` (bootstrap temporaire).
+3. Message d'échec **générique** : « Identifiants invalides. » (jamais « inconnu » / « désactivé » / « mauvais mot de passe »).
+
+- `last_login_at_utc` est mis à jour (best-effort) après un login DB réussi.
+- Anti-bruteforce léger (in-memory, mono-instance) : 5 échecs / 5 min → blocage 10 min
+  (clé = username + IP). Aucun Redis, aucune session distribuée.
+- Anti-timing : hash factice calculé quand le username est inconnu (même principe que l'ApiKey).
+- Cookie : `HttpOnly`, `SameSite=Lax`, `Secure=Always` hors Développement, expiration 12 h
+  (glissante). Production = HTTPS.
+- Un utilisateur désactivé avec un cookie existant est re-déconnecté à la prochaine
+  re-vérification DB (fréquence bornée ~60 s, cache mémoire mono-instance) ; au pire ~1 minute
+  de grâce, jamais « plusieurs jours ».
+
+### 21.8 « Mon compte » (`/Account`)
+
+- Tout utilisateur authentifié peut changer **son propre** mot de passe :
+  `mot de passe actuel` (vérifié réellement) + `nouveau` + `confirmation`. En cas de mot de passe
+  actuel faux → refus **sans** modifier le hash.
+- Les opérateurs bootstrap (configuration) ne peuvent pas changer leur mot de passe ici.
+
+---
+
+## 22. Bootstrap du premier Admin Production (T23)
+
+Production démarre **sans** utilisateur DB. Conserver la possibilité de configurer
+temporairement un opérateur bootstrap (`DiagnosticsAuth:Operators`) pour créer le premier Admin DB.
+
+### 22.1 Générer le hash bootstrap (hors ligne, pas d'endpoint Web)
+
+Outil console dédié (jamais un endpoint Web anonyme) :
+
+```
+dotnet run --project tools/Omika.DiagnosticHashTool -- "<mot-de-passe-bootstrap>"
+# ou, pour éviter de laisser le mot de passe dans l'historique du shell :
+dotnet run --project tools/Omika.DiagnosticHashTool -- --stdin
+```
+
+> ⚠️ Le **mot de passe** bootstrap ne doit **jamais** être dans Git, dans le rapport, ni dans un
+> `appsettings` versionné. Seul le **hash** est placé dans la configuration / le secret store
+> Production.
+
+### 22.2 Procédure premier déploiement (12 étapes)
+
+1. Déployer `Omika.Diagnostics.Web` (services + reverse proxy HTTPS, cf. §3-§5).
+2. Configurer **temporairement** l'opérateur bootstrap Admin (hash seulement) :
+   `DiagnosticsAuth__Operators__0__Username` / `...__PasswordHash` / `...__Roles__0=Admin`.
+3. Démarrer le service `OmikaDiagnosticsWeb`.
+4. Se connecter avec l'opérateur bootstrap.
+5. Aller sur **`/Users`**.
+6. Créer l'**Admin DB permanent** (username + mot de passe + rôle `Admin`).
+7. Se **déconnecter**.
+8. Tester le login avec l'**Admin DB** (plus le bootstrap).
+9. **Retirer** l'opérateur bootstrap de la configuration (`DiagnosticsAuth:Operators = []`).
+10. Redémarrer le service `OmikaDiagnosticsWeb`.
+11. Confirmer que le **bootstrap est refusé** (login → « Identifiants invalides. »).
+12. Confirmer que l'**Admin DB fonctionne** (Dashboard / Diagnostics / Clients / Users).
+
+### 22.3 Installation Production neuve
+
+Si PostgreSQL Diagnostics Production est créé **de zéro** : appliquer **`001 → 010`** dans l'ordre
+(jamais uniquement les dernières). Si une installation existe déjà : appliquer **uniquement les
+migrations manquantes**, dans l'ordre.