Notice technique — Superviseur

Document de référence pour l'intégrateur et l'exploitant technique : architecture, installation, base de données, exploitation du service, sauvegarde, supervision et fiabilité. La notice d'utilisation (opérateur) et la notice installateur font l'objet de documents distincts : notice_utilisation.md et notice_installateur.md.

1. Vue d'ensemble

Le Superviseur supervise des centrales de détection incendie (protocole Modbus, réseaux INIS) en exploitation continue (H24/7). Il se compose de :

• un service backend .NET 9 (service Windows Superviseur-Service) qui interroge les centrales, expose une API REST + temps réel (SignalR) et sert le frontend web ;
• une base PostgreSQL embarquée (service Superviseur-Service-PostgreSQL) ;
• un client de supervision WPF (WebView2) affichant l'interface web en mode poste dédié ;
• un gestionnaire de service (barre des tâches) pour démarrer/arrêter/surveiller le service.

Architecture détaillée : ARCHITECTURE.md. Protocole et profils Modbus : MODBUS.md.

2. Installation et déploiement

La construction de l'installateur et son contenu sont décrits dans deployment/README.md : build (build-all.ps1), installateur Inno Setup, runtime WebView2, binaires PostgreSQL portables, création du service Windows.

Points clés côté poste client :

• Installation dans C:\Program Files\Superviseur\.
• Données d'exploitation dans C:\ProgramData\Superviseur\ (pgdata/, logs/, Uploads/), préservées lors des mises à jour et des désinstallations.
• Service Windows en démarrage automatique, redémarrage automatique sur incident.

3. Base de données

• PostgreSQL via Npgsql. Base firesupervisor, rôle applicatif firesupervisor_app, servie par le cluster embarqué (port 5432). Un backend lancé depuis les sources n'y touche pas : il monte au démarrage son propre cluster, dans le profil de l'utilisateur et sur le port 5433 (appsettings.Development.json). Poste de travail et poste exploité ne partagent donc ni serveur, ni données, ni migrations.
• Chaîne de connexion dans backend/appsettings.json (ConnectionStrings:DefaultConnection) ; le mot de passe est injecté au démarrage depuis le secret applicatif (appsettings.Crypto.prod.json, non versionné). Aucun secret en clair dans les fichiers versionnés.
• Migrations appliquées au démarrage : le schéma est mis à jour automatiquement au boot du service. Le démarrage attend d'abord que la base soit joignable (retries bornés, réglables via Database:StartupConnectRetries et Database:StartupConnectRetryDelaySeconds) afin de tolérer un démarrage plus lent de PostgreSQL sur le même poste. Une migration peut supprimer une colonne devenue sans objet : la montée de version n'est alors pas réversible côté données. Revenir à une version antérieure du service après démarrage impose de restaurer une sauvegarde de la base antérieure à la migration.
• Résilience runtime : EnableRetryOnFailure (5 tentatives) et délai de commande de 20 s pour absorber les coupures transitoires.
• Point de santé : GET /healthz vérifie la connexion PostgreSQL.
• Données stockées en base : journal d'événements (main courante incendie), journal d'audit réglementaire (table dédiée, cf. §4), notes d'exploitation, configuration des centrales et globale, profils Modbus — adresses, incidents, commandes et définitions d'états système —, zones/points, télémétrie Modbus, rapports générés, réseaux INIS. Les images de plans sont sur disque (Uploads/maps/), la base ne conservant que leur URL.

4. Exploitation du service

• Service Windows Superviseur-Service : démarrage automatique, redémarrage automatique sur incident. Le gestionnaire de service (icône barre des tâches) permet de le démarrer/arrêter et d'en suivre l'état.

• Journaux : Serilog en console et fichier journalier (logs/log-.txt), rétention 90 jours (auto-purge).

• Journal d'audit réglementaire : table PostgreSQL dédiée (AuditTrailEntries), distincte de la main courante incendie. Consigne les actions sensibles — sécurité (authentification, comptes, rôles, mots de passe), configuration (centrales, réseaux INIS, réglages, sons), exploitation (commandes, acquittements), données (rapports, exports, sauvegardes/restaurations, réinitialisation usine) et cycle de vie du service — avec acteur (nom, rôle, IP), horodatage, cible et issue. Inaltérable (aucune suppression exposée) et invisible de l'utilisateur : jamais dans l'historique de protection incendie ni dans les rapports. Rétention cinq ans garantie (plancher indépendant de la configuration) ; une tâche de fond quotidienne (AuditTrailRetentionService) purge uniquement au-delà de cette durée, suspend la purge si l'espace disque devient critique, et alerte sur un volume élevé.

  Le consulter. Aucun écran ni export ne l'expose, et il ne figure pas dans les sauvegardes : une archive restaurée n'a pas à réécrire ce qui s'est produit sur cette machine. Il se lit donc en base, sur le poste, par le script déposé auprès du service :

  & "$env:ProgramFiles\Superviseur\backend\audit-trail.ps1"                      # les 100 dernières entrées
  & "$env:ProgramFiles\Superviseur\backend\audit-trail.ps1" -Since 2026-01-01 -Csv C:\Temp\audit.csv

  Le mot de passe demandé est le secret applicatif du poste, celui du compte d'administration saisi à l'installation. Le script rend les horodatages en heure locale — l'enregistrement est en UTC — et traduit la catégorie, stockée en entier. Sa sortie passe par un fichier relu en UTF-8 explicite : faire traverser les libellés accentués par la sortie standard d'un exécutable les expose au décodage de l'hôte, dont la page de code varie d'un poste à l'autre, et « Génération » y devenait « GÚnÚration » ou « Génération » selon qu'elle valait 850 ou 1252. En développement, ajouter -PgBin et -Port 5433.

  Une consultation directe reste possible (psql, DBeaver, extension PostgreSQL de VS Code) sur la base firesupervisor, rôle firesupervisor_app : les noms de table et de colonnes exigent alors des guillemets doubles, que PostgreSQL replierait sinon en minuscules.

• Tâches de fond : supervision Modbus (interrogation, reconnexion à back-off, auto-relance des tâches par centrale), planificateur de rapports, agrégation de télémétrie. Toutes sont conçues pour ne pas interrompre le service en cas d'erreur (journalisation + reprise).

• Robustesse : gestionnaire global d'exceptions HTTP (réponse d'erreur propre, pas de fuite de détails) ; transport chiffré HTTPS (redirection HTTP→HTTPS, HSTS) ; en-têtes de durcissement (dont CSP) ; validation des téléversements (plans, logo, sons).

5. Stockage et dimensionnement

Volumétrie, budget de stockage et spécifications recommandées du poste (SSD, mémoire, onduleur, réglages PostgreSQL, sauvegarde) : DIMENSIONNEMENT.md.

Rappel : le journal d'événements n'est jamais purgé automatiquement (traçabilité intégrale) ; sa croissance reste soutenable (ordre de la dizaine de Go sur une décennie) et son volume est consultable dans l'application.

6. Sauvegarde et restauration

• Sauvegarder : pg_dump régulier de la base firesupervisor vers un support distinct, plus une copie de C:\ProgramData\Superviseur\Uploads\. Ne jamais copier pgdata/ à chaud.
• Restaurer : restaurer le dump PostgreSQL puis les fichiers Uploads/.
• Définir la fréquence et la rétention des sauvegardes selon la politique du site.

7. Supervision en exploitation

• Point de santé GET /healthz.
• Surveiller l'espace disque libre (alerte sous un seuil, cf. dimensionnement).
• Volume du journal d'événements consultable dans l'application (aide à décider d'un archivage manuel).
• Journaux service dans logs/.

8. Outils Modbus (diagnostic & adressage)

Le Scanner Modbus (interface, réservé au rôle SuperAdmin) réunit les outils de diagnostic bas niveau, en marge de la couche de supervision. Deux volets :

• Scan de registres — test de connexion et lecture directe de plages d'adresses fil d'une centrale, avec journal des trames. Valeurs brutes, sans interprétation métier.
• Console Modbus — flux temps réel des trames échangées (SignalR), utile pour observer le trafic pendant une commande ou un incident. Filtres (direction, esclave, recherche, trames brutes) et tampon de 500 trames. L'abonnement au flux est restreint au rôle SuperAdmin côté hub, la diffusion de l'état des centrales à tous les utilisateurs restant inchangée.

La campagne de validation JBUS (GET /api/panels/{id}/jbus-validation, SuperAdmin, centrale INIS-E16 connectée) complète ces volets côté service : JbusValidationService dérive du profil les plages à lire et confronte le modèle « zone IHM / DI IHM » aux bits réellement remontés, en lectures pures. Aucune écriture n'en part.

Deux comportements de diagnostic à connaître pour lire les résultats :

• Exception esclave ≠ panne de liaison. Une réponse « adresse illégale » ou « donnée illégale » est une réponse protocolaire de la centrale : elle ne ferme pas la connexion et ne fait pas basculer la centrale en « déconnectée ». Sonder une adresse absente du firmware est donc sans conséquence sur la supervision en cours.
• Mode dégradé firmware. Une centrale INIS-E16 peut être connectée tout en n'ayant pas ses deux synthèses d'exploitation (neutralisation, mode manuel seul) : son firmware ne sert que les 23 bobines de base. Le journal Modbus porte alors, une fois par centrale, « Table de synthèse étendue absente… synthèses générales non disponibles ». Les états de zone restent fiables ; la sonde est rejouée à la reconnexion et au plus tard après une heure.

9. Fichiers de configuration

Fichier	Rôle	Versionné
app.config.json	Configuration générale (nom, version, Modbus, ports)	Oui
backend/appsettings.json	Configuration runtime ASP.NET (Jwt, Auth, Https, logs, supervision, base)	Oui
backend/appsettings.Crypto.prod.json	Clés revendeurs + secret applicatif (SuperAdmin + rôle PostgreSQL). Scellé au premier démarrage en appsettings.Crypto.prod.protected (DPAPI, portée machine) puis supprimé	Non

Ports par défaut : web 5000 (HTTPS), PostgreSQL 5432 (modifiables dans app.config.json). Le web est servi en TLS : un certificat auto-signé (CN=localhost) est approvisionné et installé dans le magasin racine du poste à l'installation (pour un accès navigateur local), ou fourni via Https:CertificatePath. Le client de bureau accorde en outre sa confiance au certificat directement pour la boucle locale, sans dépendre du magasin racine.

10. Documentation

• Référence API C# (DocFX) et frontend TS (TypeDoc) sont générées en français par docs/generate-docs.ps1 et publiées via le portail VitePress (workflow docs.yml).
• La référence TypeDoc couvre la couche logique du frontend (composables, services, stores, utilitaires, API) ; les composants d'interface .vue ne sont pas parsés par TypeDoc et restent documentés par commentaire d'en-tête et via leurs propriétés.