Aller au contenu

P2 - Importer une nuit d'enregistrement 📥

← Retour au sommaire des parcours · Section B - Chaîne de production

Persona principal : Marie / Karim / Samuel. Objectifs qualité visés : O3 Tenue dans la durée (jusqu'à 40 Go), O7 Intégrité, O8 Confidentialité.

Marie vient de récupérer la carte SD de son enregistreur après une nuit d'enregistrement. Elle veut importer cette nuit dans l'application. Le PR a déposé sur la SD un journal du capteur (LogPR<n>.txt), un relevé climatique (PaRecPR<sn>_THLog.csv) et plusieurs centaines de fichiers d'enregistrement.

  1. Marie ouvre l'application. Elle clique sur « Importer une nuit » depuis la vue des sites (parcours P1) ou directement depuis la barre principale.
  2. Elle pointe sur le dossier source (sélecteur ou glisser-déposer sur la modale). L'application inspecte le dossier sans rien y écrire et affiche un premier récapitulatif :
    • journal du capteur détecté ✅, n° de série de l'enregistreur extrait
    • relevé climatique détecté ✅ (ou non, signalé)
    • N enregistrements originaux détectés, taille totale, plage horaire couverte
    • paramètres d'acquisition (Fe, gain, bande de fréquence) extraits du journal du capteur. Si la carte porte plusieurs nuits, le journal porte plusieurs configurations, et chaque nuit reçoit celle de sa session (cf. E2.S9)
    • état du nommage des fichiers : sans préfixe (cas neuf), tous déjà préfixés CarXXXXXX-AAAA-PassN-YY- (cas d'un dossier déjà passé chez LupasRename ou d'un re-import), ou mélangé (cas d'un import précédent partiellement corrompu).

  3. La modale d'import demande à Marie de rattacher la nuit à un site, un point, une année et un n° de passage. Le pré-remplissage de ces 4 champs dépend de l'état du nommage :

    • Cas « sans préfixe » (le plus courant) :
      • Site et point : combobox parmi les sites déclarés (parcours P1). Si l'enregistreur (n° de série) a déjà été utilisé sur un site/point auparavant, la dernière association connue est présélectionnée (modifiable). Si aucune association ni aucun site n'existe, un raccourci « + Créer un nouveau site » ouvre le formulaire de P1 à la volée puis revient à la modale d'import.
      • Année : préremplie avec l'année courante.
      • N° de passage : pré-rempli en auto-incrément sur la base des passages déjà enregistrés pour ce point cette année (max + 1, ou 1 si aucun). Modifiable librement par Marie si elle souhaite saisir une autre valeur (cas d'un protocole non standard ou d'un rattrapage).

    • Cas « déjà préfixés » (re-import ou dossier déjà passé chez LupasRename) : l'inspection l'annonce - « fichiers déjà préfixés (seront copiés et transformés) » - et l'import ne les renomme pas. Si le préfixe des fichiers ne correspond pas au rattachement saisi, l'application bloque l'import et nomme le préfixe qu'elle attendait : « Corrigez le rattachement pour qu'il corresponde à ces fichiers, ou repartez des originaux non préfixés ».

      Bloquant depuis #1493, arbitré en séance sur le constat S2-21 de la recette finale (#1363). Le motif : un fichier estampillé Car130711-… rattaché au carré 640380 partirait tel quel au dépôt, et la participation d'un carré recevrait des fichiers portant le nom d'un autre. Le nom physique ne doit pas contredire le rattachement logique.

      Non réalisé, et délibérément décrit comme tel : l'application ne présélectionne pas le rattachement depuis le préfixe des fichiers, et ne propose pas de réaligner les noms sur la saisie. Ces deux gestes figuraient dans la conception d'origine ; le premier n'a jamais été construit, le second a été remplacé par le blocage ci-dessus. Une version antérieure de ce paragraphe les décrivait au présent, ce qui envoyait le lecteur sur une fausse piste (#4043).

    Cas dégradé : si le dossier mélange fichiers préfixés et non préfixés, l'application bloque l'import avec le message « Le dossier contient un mélange de fichiers nommés et non nommés. Nettoyez le dossier puis réessayez ». 4. Marie valide « Importer ». L'application copie de manière protégée tous les fichiers depuis la SD vers son espace de travail (R9 : aucune écriture sur les originaux SD). Les fichiers copiés reçoivent ou conservent le préfixe CarXXXXXX-AAAA-PassN-YY- (R6, R7, R8). 5. Une fois la copie terminée, l'application transforme automatiquement chaque enregistrement original en séquences d'écoute (découpage en tranches de 5 s réelles, puis expansion ×10, R10). Une barre de progression détaillée informe Marie de l'étape en cours et de l'étape suivante. 6. À la fin, l'application affiche un récapitulatif : nombre de séquences d'écoute produites, durée totale enregistrée, durée écoulée. Le passage est créé en base avec le statut Transformé. L'association enregistreur → site/point est mémorisée pour faciliter les imports suivants. Marie est invitée à enchaîner sur la vérification d'enregistrement (parcours P3).

Notes importantes

  • L'application observe les fichiers de l'utilisateur, elle ne les possède pas. Ce qu'elle range dans son espace de travail est un cache : les enregistrements bruts (copiés seulement si l'on demande de les conserver pour ré-analyse, décoché par défaut) et les séquences transformées, toutes deux recalculables. La seule pièce irremplaçable est la base de données. Trois conséquences de conception, tenues d'un bout à l'autre du produit : l'application n'archive plus et ne purge plus l'audio (« archivé » devient un état observé - les fichiers ne sont plus là où on les attendait -, pas un geste) ; quand l'audio est déjà à l'utilisateur (un NAS, un disque, son arborescence), elle peut s'y référer au lieu de le recopier (à la réactivation, cf. P12) ; et l'utilisateur choisit où vivent son dossier de travail et sa base. Le fil conducteur : changer un pointeur ne déplace pas les données, et l'application ne touche jamais aux fichiers de l'utilisateur à sa place - c'est dit avant chaque choix.
  • Aucun fichier n'est touché tant que le quadruplet (carré, année, n° de passage, point) n'est pas confirmé par l'utilisateur à l'étape 3. L'inspection initiale du dossier source (étape 2) est en lecture seule. Si Marie change d'avis avant de cliquer « Importer », rien ne s'est passé sur disque.
  • Une fois la copie effectuée et les fichiers renommés, changer rétroactivement le n° de passage ou le point d'un passage déjà importé est possible mais déclenche un re-renommage de tous les fichiers du passage (à valider explicitement par l'utilisateur via une action dédiée « Modifier le rattachement »).
  • L'application doit tenir des nuits jusqu'à 40 Go sans freezer l'IHM (cas Samuel en haute saison). L'import et la transformation se font de préférence en arrière-plan, avec possibilité de fermer la fenêtre de progression sans annuler l'opération.
  • Si l'utilisateur lance un import alors qu'un autre est en cours, l'application le met en file d'attente plutôt que de refuser ou de paralléliser (préservation des perfs).
  • Les identifiants observateur et participation présents dans les noms de fichiers ou les CSV sont conservés en local mais ne sont jamais transmis à un service distant (R8 implicite, SC2).

Ce que la fin d'import est devenue

L'enrichissement annoncé ici est livré (#2358, EPIC #2350).

  • La fin d'import rend des comptes en chiffres. Le compte rendu chiffré a remplacé les trois surfaces qui se succédaient : la phrase de succès, le compte rendu textuel et la liste des rejets. Il restitue la ventilation des fichiers de la source, compare le volume lu sur la carte au volume écrit sur le disque, rappelle les réserves d'inspection encore vraies (#1488) et se termine par « Ouvrir le passage » plutôt que par un acquittement.

    Le remplacement n'a été complet qu'à #2654 : jusque-là le ViewModel alimentait encore les deux canaux d'autrefois - le compte rendu textuel et la liste des rejets - que plus aucune surface ne lisait. Ils mentaient sur l'état du code, et leur retrait a demandé de vérifier, cas par cas, que la substance de leurs sept tests avait bien déménagé.