Aller au contenu

O3 - Tenue dans la durée sur des nuits volumineuses

L'application doit gérer une nuit de plusieurs giga-octets de WAV sans dégradation perceptible de la réactivité de l'interface, même après plusieurs minutes d'utilisation continue. Cible jusqu'à 40 Go pour une nuit (cas Samuel en haute saison).

Justification métier

Une nuit standard chez Marie ou Karim fait quelques Go (le sample fourni contient 1572 WAV, ~5 Go). Mais en zone très riche ou avec un PR très sensible, une nuit peut atteindre 40 Go par enregistreur ; Samuel déploie jusqu'à 24 PR en parallèle pendant la haute saison.

Si l'application freeze pendant l'import (la copie protégée et la transformation ×10 + chunks 5 s impliquent de lire/écrire des dizaines de Go), ou si la mémoire JVM gonfle au-delà du raisonnable, l'application ne sera pas utilisée pour les déploiements multi-PR.

Conséquences architecturales

Cet objectif impose des choix structurants :

  • Streaming des WAV : pas de chargement complet en mémoire, lecture par chunks.
  • Pré-production des séquences transformées : la transformation ×10 + découpage 5 s est calculée à l'import et stockée sur disque (E2.S6, R10), pas recalculée à la volée à chaque lecture.
  • Tâches en arrière-plan : la copie SD et la transformation se font en Task<Void> JavaFX (ou équivalent), l'utilisateur peut fermer la fenêtre de progression sans annuler.
  • Indexation paresseuse : la liste des passages se charge à la demande.

Mesure

⚠️ Ordres de grandeur indicatifs, à affiner par un premier benchmark sur les machines IUT en début de Sprint 1.

  • Sur une nuit standard (5-10 Go, ~1500 WAV) :
  • L'import complet termine en quelques minutes.
  • Pas de freeze de l'IHM (> 200 ms) pendant la navigation après import.
  • Empreinte mémoire JVM raisonnable et stabilisée après plusieurs minutes d'utilisation.
  • Test de charge sur une nuit représentative grande taille (≥ 20 Go simulés) : l'IHM reste réactive même pendant la transformation.