Règles métier¶

Les règles métier du modèle conceptuel. Chaque règle a un identifiant ancré (#r1 à #r32) qui sert de point de référence depuis le reste du dossier (parcours, stories, maquettes).

Site, point, passage¶

R1 : un n° de carré est obligatoirement composé de 6 chiffres, dont les 2 premiers correspondent au numéro de département (avec leading zero pour les départements 1 à 9).
R2 : un code de point est exactement de la forme lettre + chiffre (ex. A1, Z4). Validation à la saisie.
R3 : sur les sites en mode PointFixeStandard (cf. C2), deux passages sont attendus par site et par année :
- passage 1 : entre le 15 juin et le 31 juillet,
- passage 2 : entre le 15 août et le 31 septembre. L'application alerte sans bloquer si l'utilisateur déclare un passage hors fenêtre. Sur les sites en mode PointFixeRecherche (dates personnalisées pour des besoins recherche), cette règle est muette : aucune alerte n'est générée.
R4 : sur les sites en mode PointFixeStandard, intervalle conseillé entre les deux passages d'un même site : ≥ 1 mois. Idéalement, dates « anniversaires » (±10 j) d'une année à l'autre. Sur les sites en mode PointFixeRecherche, cette règle est également muette (l'utilisateur enregistre à la fréquence qui convient à son protocole, y compris plusieurs nuits successives).
R5 : le triplet (Site, Point, Année, n° de passage) est unique : un même point ne peut pas avoir deux passages avec le même n° dans la même année.
R25 : un n° de carré est unique par utilisateur : un même utilisateur ne peut pas déclarer deux fois le même carré (alerte bloquante à la création ou au renommage d'un site ; la vérification exclut le site courant, pour qu'un simple renommage ne se bloque pas lui-même).

Géographie des carrés et des points¶

R26 : un point d'écoute appartient à un carré de 2 km de côté du carroyage national Vigie-Chiro (« carrenat »). Ses coordonnées GPS doivent tomber dans l'emprise de ce carré. À l'édition cartographique des positions, le marqueur est contraint (clampé) au bord de la maille : on ne peut pas glisser un point hors de son carré. L'emprise du carré est déduite du centroïde officiel de la maille (référentiel carrenat embarqué, ≈ 137 000 mailles couvrant la France métropolitaine), avec un repli : si le carré est hors référentiel, l'emprise est reconstruite autour des points géolocalisés du site.
R27 : un point dont les coordonnées GPS ne sont pas (encore) saisies est tout de même situé, au centre de son carré (position approchée, distinguée visuellement d'une position mesurée). Si plusieurs points d'un même carré sont sans GPS, ils sont répartis en éventail autour du centre pour ne pas se superposer. Un point n'est non plaçable que si son carré est hors référentiel et qu'aucun point du site n'est géolocalisé (centre inconnu).

Convention de nommage des fichiers¶

R6 : tout enregistrement original doit être renommé selon le préfixe CarXXXXXX-AAAA-PassN-YY- avant tout dépôt. Les tirets sont des « tirets du 6 » (-, U+002D HYPHEN-MINUS), pas des cadratins ni des demi-cadratins. À n'oublier sous aucun.
R7 : le suffixe original de l'enregistreur (PaRecPR<sn>_<AAAAMMJJ>_<HHMMSS>.wav) est conservé tel quel après le préfixe.
R8 : toute séquence d'écoute reprend le nom de son enregistrement original source en insérant un suffixe _000, _001, … entre le nom de base et l'extension.

Copie protégée¶

R9 : à l'import, l'application copie systématiquement les fichiers depuis la carte SD vers son espace de travail. Aucune écriture sur les originaux sur la SD. C'est une contrainte explicite du protocole Vigie-Chiro pour éviter toute perte de données. La copie est vérifiée bit-à-bit : l'empreinte SHA-256 de la destination est recalculée et comparée à celle de la source ; toute divergence est une erreur (copie non fidèle).

Import : résilience et inspection¶

R29 : l'import est résilient. Un enregistrement original source illisible ou de format invalide est rejeté individuellement et consigné dans un rapport d'import (importés / rejetés / fichiers non pertinents) sans interrompre le traitement des autres fichiers. Le rapport porte aussi ce que l'import a rencontré sans le rejeter : le doublon de nuit quand l'observateur a choisi d'importer une nuit déjà présente, et les anomalies relevées au journal du capteur (réveil non programmé, batterie faible) - elles n'expliquent pas toujours un problème, mais elles éclairent une nuit qui paraît incomplète. Sont rejetés notamment : un en-tête WAV corrompu, une fréquence d'échantillonnage non divisible par 10 (donc non ralentissable ×10, cf. R10), et un enregistrement déjà ralenti (voir R31). Le remplacement d'une session existante est en revanche atomique : si l'import échoue globalement (annulation, tous les WAV rejetés, erreur disque), la session précédente est restaurée - rien n'est perdu.
R30 : à l'inspection d'un dossier (avant import), l'application signale sans bloquer quatre situations, à charge de l'utilisateur de décider : un mélange (le dossier contient des fichiers de plusieurs enregistreurs), une incohérence (le journal du capteur - n° de série, nuit - contredit les WAV), une nuit déjà importée (un passage existe déjà pour le même enregistreur et la même date), et des enregistrements déjà ralentis (fréquence d'échantillonnage trop basse pour un ultrason brut, cf. R31 : ils seront rejetés à l'import). Aucune de ces alertes n'empêche de lancer l'import.
R31 : l'import n'accepte que de vrais enregistrements bruts (ultrason non ralenti). Un enregistrement dont la fréquence d'échantillonnage est trop basse pour un ultrason brut - inférieure à la fréquence d'acquisition déclarée par le journal (Fe…kHz, ex. 384 kHz), ou, à défaut de journal, sous un seuil minimal (96 kHz) - est considéré déjà ralenti ×10 et rejeté (R29). Le transformer le ré-expanserait ×10 (double expansion : fréquences 10× trop basses à l'affichage). L'application ne corrige pas automatiquement un tel fichier : il faut fournir les vrais bruts de l'enregistreur.

Transformation¶

R10 : la transformation d'un enregistrement original le découpe en tranches de 5 s réelles, puis ralentit ×10 chaque tranche (expansion de temps). Le découpage porte donc sur le signal brut, pas sur le signal déjà ralenti : une séquence d'écoute contient 5 s d'enregistrement et dure 50 s à l'écoute. Pour un enregistrement original de durée D (en secondes réelles), on obtient ceil(D / 5) séquences. La dernière séquence peut être plus courte que 5 s. La source doit être un ultrason brut non ralenti (échantillonné à la fréquence d'acquisition, ex. 384 kHz) : un fichier déjà ralenti est rejeté (R31), pas transformé.
R11 : la transformation est deterministe : relancer la transformation sur les mêmes enregistrements originaux produit les mêmes séquences d'écoute au bit près.

Vérification d'enregistrement¶

R12 : une sélection d'écoute est constituée automatiquement à l'ouverture de la vue, avec la méthode RéparTemporel par défaut (séquences réparties uniformément sur la nuit).
R13 : le verdict de chaque fichier son écouté (Bon / Mauvais / Inexploitable) est saisi par l'utilisateur ; le verdict final du passage (OK / Utilisable / Inexploitable, état initial Non vérifié) en est dérivé automatiquement mais reste surchargeable à la main. Aucun seuil obligatoire d'écoute : l'utilisateur écoute tout ou partie de la sélection et reste responsable.
R14 : un passage au verdict final Inexploitable ne peut pas être déposé (alerte bloquante). Pour déposer, il faut le requalifier (re-vérifier jusqu'à un verdict déposable) ; une fois déposé, le verdict est figé.

Préparation du dépôt¶

R31 : préparer le dépôt s'appuie sur une checklist de cohérence vivante (chaque contrôle est affiché, même satisfait : ✓ / ⚠ / ✗). Un contrôle bloquant (✗) interdit la préparation tant qu'il n'est pas corrigé : verdict Inexploitable (R14), transformation incomplète, préfixe de fichier non conforme (R6), journal du capteur absent. Les contrôles non bloquants (⚠) - par exemple un relevé climatique absent (R20) - sont signalés mais laissent préparer. Quand la préparation réussit, le passage passe au statut Prêt à déposer.

Validation taxonomique (SHOULD)¶

R15 : une observation est qualifiée de validée quand taxon observateur = taxon Tadarida et probabilité observateur renseignée.
R16 : une observation est qualifiée de corrigée quand taxon observateur ≠ taxon Tadarida.
R17 : une observation non touchée par l'utilisateur conserve uniquement les colonnes tadarida_*, et l'export _Vu.csv reprend ces valeurs (l'utilisateur conserve ainsi la classification automatique par défaut).
R18 : deux modes de validation coexistent au MVP (au choix de l'utilisateur) :
- Mode inventaire : dès qu'une espèce est validée avec confiance sur une nuit, on ne valide plus les autres détections de la même espèce sur la même nuit.
- Mode activité : toutes les observations doivent être passées en revue (utile pour les études d'activité quantitative).
- 🟠 SHOULD / variante future - Mode inventaire pondéré : variante du mode inventaire qui rouvre la validation pour toute nouvelle détection de l'espèce dont la probabilité Tadarida est supérieure à celle de l'observation déjà validée comme référence. Hybride entre inventaire (gain de temps) et activité (capter les signaux plus francs qui apparaissent en cours de nuit). Origine : suggestion de Samuel - « on pourrait imaginer un 3e mode qui ne valide que les détections dont la proba est supérieure à celle de l'observation validée, qui se rapproche de ce qu'on fait sur certains projets ».
R24 : chaque observation porte un mode de validation (manuel | auto | null) qui trace comment sa valeur courante de taxon observateur a été établie :
- manuel : l'utilisateur a explicitement saisi ou modifié le taxon observateur (validation classique en mode activité, ou validation explicite en mode inventaire).
- auto : le taxon a été propagé automatiquement par le mode inventaire (cf. R18) sans intervention manuelle - la classification dérive d'une validation antérieure sur la même espèce de la même nuit.
- null : aucune validation n'a encore été effectuée (l'observation conserve uniquement les colonnes tadarida_*, cf. R17).
Ce mode est tracé en BD et restituable dans l'export _Vu.csv (colonne optionnelle, à activer selon attentes Vigie-Chiro). Sa principale utilité : permettre à un évaluateur scientifique de distinguer ce qui a été réellement vérifié à l'oreille de ce qui a été propagé sur confiance.
R32 : pendant la validation, une observation peut être marquée « séquence de référence ». L'export de la bibliothèque de sons de référence est constitué exactement de ces observations-là : pour chacune, le taxon retenu est le taxon observateur s'il a été validé, sinon le taxon Tadarida, et le fichier audio correspondant est copié, organisé par taxon.

Suppression de sites et de points¶

R28 : un point d'écoute ou un site qui porte des passages ne peut pas être supprimé (garde-fou contre la perte de données rattachées). La suppression est bloquée tant qu'au moins un passage y est rattaché ; l'interface l'indique (action désactivée avec info-bulle explicative, ou message au clic). Pour supprimer, il faut d'abord retirer les passages concernés.

Données¶

R19 : le journal du capteur est un journal circulaire sur l'enregistreur (place limitée). En cas de saturation de la SD, des entrées plus anciennes peuvent être effacées. L'application n'a pas à reconstituer les pertes - elle exploite ce qui est présent.
R20 : le relevé climatique peut être absent (sonde défaillante ou non installée). Dans ce cas, l'onglet diagnostic du passage le signale clairement plutôt que de masquer la section.

Arborescence sur disque¶

R21 : toutes les données et tous les paramètres de l'application vivent dans un unique dossier « workspace » sur le disque local de l'utilisateur. Ce workspace contient les sessions d'enregistrement, la base SQLite et tout fichier de réglages utilisateur. Aucune donnée n'est dispersée ailleurs.
- Défaut proposé à l'installation : <Documents>/VigieChiro-Companion/ (résolu par OS : ~/Documents/VigieChiro-Companion/ sous Linux/macOS, %USERPROFILE%\Documents\VigieChiro-Companion\ sous Windows).
- Configurable depuis les préférences : utile en particulier pour les gros volumes (Samuel : 24 enregistreurs × 40-50 nuits → To cumulés), qui demanderont à pointer un disque externe.
R22 : une session d'enregistrement occupe un sous-dossier du workspace dont le nom est exactement le préfixe défini par R6 (Car<carre>-<annee>-Pass<n>-<point>). Dans ce sous-dossier :
- les enregistrements originaux, si l'utilisateur a demandé de les conserver, sont rangés dans bruts/ (cf. R7). Ce dossier est absent par défaut : l'application lit les WAV directement depuis la carte et n'en garde pas de copie, la conservation étant une option de ré-analyse (cf. ADR 0036) ;
- les séquences d'écoute sont rangées dans transformes/ (cf. R8) ;
- le journal du capteur (LogPR<n>.txt) est à la racine de la session d'enregistrement (cf. C9) ;
- le relevé climatique (PaRecPR<sn>_THLog.csv), si présent, est aussi à la racine de la session d'enregistrement (cf. C10, R20).
R23 : le fichier de résultats Tadarida (*-observations.csv ou *-observations_Vu.csv) est importé dans le dossier transformes/ de la session d'enregistrement qu'il annote, à côté des séquences d'écoute auxquelles ses observations renvoient.

Arborescence type d'un workspace contenant deux sessions d'enregistrement (un passage 1 et un passage 2 sur le même point) :

text <workspace>/ ← R21 : configurable, défaut <Documents>/VigieChiro-Companion/ ├── Car040962-2026-Pass1-A1/ ← R22 : nom = préfixe R6 │ ├── bruts/ ← R22 : originaux, SEULEMENT si conservation demandée │ │ ├── Car040962-2026-Pass1-A1-PaRecPR1925492_20260622_213045.wav │ │ ├── Car040962-2026-Pass1-A1-PaRecPR1925492_20260622_213101.wav │ │ └── ... │ ├── transformes/ ← R22 : séquences d'écoute R8 │ │ ├── Car040962-2026-Pass1-A1-PaRecPR1925492_20260622_213045_000.wav │ │ ├── Car040962-2026-Pass1-A1-PaRecPR1925492_20260622_213045_001.wav │ │ ├── ... │ │ └── 7a4b8c1d-participation-...-observations.csv ← R23 : CSV Tadarida │ ├── LogPR1925492.txt ← R22 : journal capteur à la racine │ └── PaRecPR1925492_THLog.csv ← R22 : relevé climatique (optionnel) ├── Car040962-2026-Pass2-A1/ │ └── ... ← même structure que ci-dessus └── vigiechiro.db ← R21 : BD SQLite + réglages à la racine

Retour¶

⬅ Modèle conceptuel - Vue d'ensemble