Dimensionnement du stockage et spécifications d'hébergement

Ce document dimensionne le stockage nécessaire à une exploitation continue (H24/7) du Superviseur et recommande les caractéristiques du poste d'hébergement. Il tient compte de la décision d'exploitation de ne jamais purger automatiquement le journal d'événements (traçabilité intégrale).

L'hébergement cible est un poste Windows unique exécutant le service backend, la base PostgreSQL embarquée et le client de supervision (WPF + WebView2). Les données d'exploitation résident dans C:\ProgramData\Superviseur\ (pgdata/, logs/, Uploads/), préservées lors des mises à jour.

1. Postes de croissance des données

Source	Borne	Croissance	Remarque
Journal d'événements (SystemLogs, PostgreSQL)	Non borné (aucune purge auto)	Dominant	Écrit sur transition d'état (connexion/déconnexion, changement de zone/point, commande, authentification, configuration), pas à chaque interrogation Modbus.
Télémétrie Modbus (ModbusMetricSnapshots)	Bornée à 90 j (MetricsRetentionDays)	Prévisible	1 ligne agrégée par centrale et par fenêtre de 5 min. Purge automatique en place.
Journaux fichiers du service (logs/)	Bornée à 90 j (Serilog)	Faible	Rotation journalière, purge automatique.
Rapports générés (GeneratedReports)	Non bornée	Faible à modérée	PDF + CSV par échéance planifiée (quotidien/hebdo/mensuel/annuel). Nettoyage manuel possible.
Images de plans (Uploads/maps/)	Bornée par le nombre de plans	Faible	≤ 25 Mo/image (validé), typiquement 0,5–5 Mo.
Socle logiciel (OS, PostgreSQL, backend, client, WebView2)	Fixe	—	~1 Go hors OS.

Modèle de volumétrie du journal d'événements

Taille moyenne d'une ligne SystemLogs, index compris : ~0,5 Ko (identifiant, horodatage, niveau, source, message, utilisateur, détails, type d'événement + surcharge PostgreSQL et index).

Régime	Événements/jour	Par an	Sur 10 ans
Calme (parc stable)	~1 000	~180 Mo	~1,8 Go
Nominal	~5 000	~0,9 Go	~9 Go
Chargé (parc étendu, essais fréquents)	~10 000	~1,8 Go	~18 Go

Conclusion : même sans purge et en régime chargé, le journal reste de l'ordre de la dizaine de gigaoctets sur une décennie. La décision « audit intégral » est donc soutenable sur un SSD standard sans risque de saturation à horizon raisonnable. La supervision du volume reste néanmoins recommandée (cf. §5).

Autres postes (ordres de grandeur)

• Télémétrie Modbus : pour 8 centrales, 8 × 288 lignes/jour × 90 j ≈ 207 000 lignes ≈ ~40 Mo en régime permanent (borné).
• Rapports : ~0,3 Mo par rapport ; une génération quotidienne sur 10 ans ≈ ~1 Go (prévoir un nettoyage manuel périodique si la planification est dense).
• Plans : quelques dizaines à quelques centaines de Mo selon le nombre de plans.

2. Budget de stockage recommandé

Horizon	Données d'exploitation (estimation haute)	Avec socle + OS + marge
1 an	< 3 Go	~60 Go
5 ans	< 12 Go	~70 Go
10 ans	< 25 Go	~80 Go

Le besoin réel en données reste modeste. Le dimensionnement du disque est piloté par le confort d'exploitation (OS, mises à jour, sauvegardes locales, marge) plutôt que par la croissance des données.

3. Spécifications du poste d'hébergement

Composant	Minimum	Recommandé
Processeur	4 cœurs (Intel i5 / Ryzen 5, génération récente)	6–8 cœurs
Mémoire	8 Go	16 Go (PostgreSQL + backend .NET + WebView2 + OS)
Disque	SSD 256 Go	SSD NVMe 512 Go
Système	Windows 10/11 x64	Windows 11 x64
Alimentation	Secteur	Secteur + onduleur (UPS)
Réseau	Ethernet vers la passerelle Modbus/INIS	Ethernet dédié

Justifications :

• SSD (impératif) : la base est sollicitée en écriture continue (journal en ajout). Un disque mécanique dégrade la latence des requêtes d'historique et la robustesse. Le NVMe apporte une marge d'IOPS confortable.
• 16 Go de mémoire : laisse respirer le cache PostgreSQL, le service backend et le client de supervision affiché en continu, sans pression mémoire sur l'OS.
• Onduleur (fortement recommandé) : en H24/7, une coupure secteur pendant une écriture peut corrompre le cluster PostgreSQL. L'onduleur permet un arrêt propre du service et de la base.
• Ethernet filaire : la supervision Modbus/INIS exige une liaison stable et déterministe ; le Wi-Fi est déconseillé pour la liaison de terrain.

4. Réglages PostgreSQL (cluster embarqué)

Pour un hôte de 16 Go dédié :

• shared_buffers ≈ 2–4 Go (≈ 25 % de la RAM).
• effective_cache_size ≈ 8 Go.
• work_mem modéré (16–32 Mo) — suffisant pour les requêtes d'historique paginées.
• autovacuum activé (défaut) : essentiel pour la table SystemLogs en ajout continu.
• Index SystemLogs en place (migration AddSystemLogIndexes) : conserver pour les requêtes filtrées de l'Historique.
• CommandTimeout applicatif = 20 s et EnableRetryOnFailure (5 tentatives) déjà configurés côté EF Core pour absorber les coupures transitoires.

5. Exploitation, sauvegarde et supervision

• Sauvegarde : planifier un pg_dump régulier de la base firesupervisor vers un disque distinct (ou support externe), plus une copie de Uploads/. Ne jamais copier pgdata/ à chaud (cluster vivant) : utiliser pg_dump. Définir la rétention des sauvegardes selon la politique du site.
• Supervision :
  • Point de santé /healthz (vérification de connexion PostgreSQL via Npgsql).
  • Surveiller l'espace disque libre ; bien que la croissance soit lente, alerter sous un seuil (ex. 20 Go libres).
  • Volume du journal d'événements visible dans l'application (nombre d'entrées, plus ancienne date) — aide à décider d'un export/archivage manuel éventuel.
• Archivage manuel du journal (optionnel, jamais automatique) : l'export CSV de l'Historique permet d'archiver hors-ligne avant un éventuel élagage manuel décidé par l'exploitant.
• Démarrage : le service attend la disponibilité de PostgreSQL avant de migrer la base (retries bornés, réglables via Database:StartupConnectRetries et Database:StartupConnectRetryDelaySeconds), ce qui tolère un démarrage plus lent de la base sur un poste mutualisé.