Feature Specification: Importation de photos depuis une carte mémoire

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152

# Feature Specification: Importation de photos depuis une carte mémoire

**Feature Branch**: `[001-import-photos]`

**Created**: 2026-09-18

**Status**: Draft

**Input**: User description: "utilise les docs pour generer la specification du module d'importation des photos"

## Clarifications

### Session 2026-09-22

- Q: L'import doit-il continuer à pousser automatiquement le dossier fini vers l'archive NAS, ou s'arrêter à une copie de travail locale ? → A: Il s'arrête à une copie de travail locale, classée par dossier de format (`raw/`/`jpeg/`/`tiff/`...). Le photographe doit pouvoir relire et retoucher cette copie avant tout envoi au NAS ; l'archivage devient une action distincte et explicite, déclenchée plus tard (réutilise `regine reconcile`, `specs/005-checkout-reconciliation`, déjà conçu pour traiter un dossier jamais encore archivé comme un ensemble de fichiers "nouveaux" à archiver sur confirmation). Conséquence directe : importer une carte ne nécessite plus que le partage NAS soit monté au moment de l'import (seul son chemin configuré sert à situer où le dossier ira plus tard) — utile aussi pour tester l'import sans accès réel au NAS.
- Q: Les fichiers importés doivent-ils être classés dans un dossier de format (`raw/`, `jpeg/`, `tiff/`...) dès l'import ? → A: Oui — écart trouvé à l'implémentation : cette spec ne le prévoyait pas explicitement alors que `docs/archivage-photo-elements-cles.md` section 10 et `specs/006-gui-tri-consultation` (écran de tri) supposent tous deux cette structure déjà en place dès qu'un dossier existe. Sans ce classement, un dossier fraîchement importé se retrouvait entièrement à plat, ce qui faisait apparaître chaque fichier comme "déjà promu à la racine" dans l'écran de tri — plus rien à trier. Corrigé par une nouvelle étape de classement (FR-020), après le renommage et avant la publication locale.
- Q: Le système doit-il détecter qu'une photo a déjà été importée précédemment, même vers un dossier différent d'un import antérieur ? → A: Oui — écart trouvé par test manuel de l'utilisateur : importer deux fois la même carte vers deux dossiers différents ne déclenchait aucun avertissement, alors que FR-004 (comparaison par somme de contrôle) existait déjà en code mais n'était jamais réellement alimenté par aucun appelant (CLI ou GUI) — la déduplication ne fonctionnait donc dans aucun cas réel, y compris le cas initialement visé (carte non effacée entre deux imports). Corrigé par un historique persistant des sommes de contrôle déjà importées (FR-004 révisé), alimenté à chaque import réussi et consulté avant le suivant ; en cas de correspondance, Régine informe l'utilisateur (fichiers concernés, dossier où ils ont déjà été importés) et laisse le choix de continuer ou d'annuler (Principe V) — jamais un blocage ou une exclusion silencieuse.

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Import simple d'une carte mémoire vers un nouveau dossier (Priority: P1)

Un photographe rentre d'une sortie photo avec une carte mémoire. Il demande à Régine d'importer le contenu de la carte : Régine copie les fichiers en sécurité, propose un titre et un nom de dossier à partir des dates de prise de vue, renomme les fichiers de façon lisible, les classe dans leur dossier de format (`raw/`, `jpeg/`, `tiff/`...), puis les publie dans un nouveau dossier de l'espace de travail local — prêt à être trié et retouché. L'archivage vers le NAS n'a pas lieu automatiquement à l'import : c'est une étape distincte, déclenchée explicitement par le photographe une fois sa sélection terminée (cf. Clarifications, `specs/005-checkout-reconciliation`).

**Why this priority**: C'est le point d'entrée de toute photo dans Régine — sans cette histoire, aucun autre module (tri, sélection, archivage, planche-contact) n'a de matière à traiter. C'est aussi la première fois qu'une carte mémoire peut être effacée en confiance.

**Independent Test**: Peut être testé de façon autonome en branchant une carte mémoire contenant les photos d'une seule journée, en lançant l'import, et en vérifiant qu'un dossier correctement nommé apparaît dans l'espace de travail local, classé par format, avec tous les fichiers renommés et vérifiés — sans dépendre d'aucune autre fonctionnalité de Régine, ni d'un accès à l'archive NAS.

**Acceptance Scenarios**:

1. **Given** une carte mémoire contenant des photos d'une seule journée, jamais importées auparavant, **When** l'utilisateur lance l'import, **Then** Régine copie les fichiers vers un espace de travail local en vérifiant chaque fichier par somme de contrôle avant de signaler la carte comme sûre à effacer.
2. **Given** la copie locale vérifiée d'une carte à une seule journée, **When** Régine analyse les dates de prise de vue, **Then** elle propose un seul groupe couvrant cette journée et invite l'utilisateur à donner un titre.
3. **Given** un titre saisi par l'utilisateur, **When** Régine construit le nom du dossier, **Then** elle produit un nom au format `AAAA-MM-JJ_Titre`, nettoyé des caractères interdits et des espaces, le place sous le répertoire racine déterminé à l'étape de destination (année par défaut, ou catégorie thématique — cf. `specs/004-categorisation-dossiers`), et vérifie qu'aucun dossier identique n'existe déjà sous ce même répertoire racine avant de le créer.
4. **Given** un nom de dossier validé, **When** Régine renomme les fichiers avant publication locale, **Then** chaque fichier maître est renommé en `date_titre_nomOrigine.ext` en conservant le nom d'origine du boîtier en suffixe, et tout fichier associé (JPEG jumeau, sidecar) est renommé de façon synchronisée.
5. **Given** des fichiers renommés localement, **When** Régine les classe par format, **Then** chaque fichier maître rejoint son dossier de format (`raw/` pour les RAW propriétaires, `jpeg/`, `tiff/` pour les scans, un dossier dédié pour un format maître plus marginal — cf. `docs/archivage-photo-elements-cles.md` section 10), et chaque fichier associé rejoint le dossier de son fichier maître.
6. **Given** des fichiers renommés et classés par format, **When** Régine les publie dans l'espace de travail local, **Then** elle présente d'abord un résumé (nombre de fichiers, taille, nom du dossier de destination) et attend une confirmation explicite avant d'écrire quoi que ce soit localement — aucune écriture n'a lieu sur l'archive NAS à ce stade.
7. **Given** une carte dont certains fichiers correspondent, par somme de contrôle, à des fichiers déjà importés lors d'une session précédente vers un dossier différent, **When** l'utilisateur relance un import avec cette carte, **Then** Régine l'informe de ces correspondances (fichiers concernés, dossier où ils ont déjà été importés) avant de poursuivre, et attend sa décision explicite de continuer ou d'annuler.

---

### User Story 2 - Découpage d'un import multi-jours en plusieurs groupes (Priority: P2)

Un photographe importe une carte couvrant plusieurs jours consécutifs (ex. une semaine de vacances incluant un anniversaire). Il veut que l'anniversaire devienne son propre dossier plutôt que d'être noyé dans le dossier de vacances.

**Why this priority**: Une carte couvrant plusieurs jours est un cas courant (voyages, week-ends prolongés) ; sans ce découpage, l'utilisateur devrait réorganiser l'archive manuellement après coup, ce que Régine cherche justement à éviter.

**Independent Test**: Peut être testé en important une carte dont les dates EXIF couvrent une semaine avec un pic de prise de vue isolé sur une journée, en vérifiant que Régine propose ce jour comme candidat au détachement, et que l'utilisateur peut confirmer ou ignorer cette suggestion pour obtenir deux dossiers distincts au lieu d'un.

**Acceptance Scenarios**:

1. **Given** une copie locale vérifiée dont les dates EXIF couvrent une plage contiguë de plusieurs jours, **When** Régine analyse la répartition jour par jour, **Then** elle affiche le nombre de photos et la plage horaire par jour et propose par défaut un seul groupe couvrant toute la plage.
2. **Given** cette répartition jour par jour, **When** un jour présente un pic de prises de vue nettement différent du reste, **Then** Régine met en avant ce jour comme candidat plausible à détacher, sans jamais le détacher elle-même.
3. **Given** la proposition d'un seul groupe, **When** l'utilisateur détache un ou plusieurs jours au milieu de la plage, **Then** Régine crée un groupe séparé pour les jours détachés et conserve pour le groupe restant le nom de la plage d'origine plutôt que de la recalculer.
4. **Given** plusieurs groupes issus du découpage, **When** l'utilisateur valide, **Then** Régine demande la destination et le titre de chaque groupe indépendamment, avant de renommer, classer par format et publier chacun séparément dans l'espace de travail local.

---

### User Story 3 - Import s'intégrant à un voyage en plusieurs étapes (Priority: P3)

Un photographe est en voyage sur plusieurs villes. Pour la deuxième étape, il importe une nouvelle carte et veut qu'elle s'intègre comme sous-dossier du voyage déjà commencé plutôt que de créer un dossier indépendant. Il peut aussi avoir utilisé deux boîtiers ou une carte de secours pour la même étape.

**Why this priority**: Couvre le cas d'usage le plus riche fonctionnellement (structure à deux niveaux, fusion de sources multiples) mais reste un raffinement de l'import simple (P1) : un utilisateur qui ne voyage jamais en plusieurs étapes n'a pas besoin de cette histoire pour tirer de la valeur de Régine.

**Independent Test**: Peut être testé en import et une première carte comme "nouveau dossier parent avec sa première étape", puis en import et une seconde carte en choisissant "nouveau sous-dossier dans un dossier parent existant", et en vérifiant que la structure finale a bien deux niveaux avec les deux étapes correctement nommées et rattachées.

**Acceptance Scenarios**:

1. **Given** un premier import connu comme le début d'un voyage à plusieurs étapes, **When** l'utilisateur choisit la destination "nouveau dossier parent avec sa première étape", **Then** Régine crée directement une structure à deux niveaux (dossier parent au format `AAAA-MM_Titre`, sous-dossier au format `AAAA-MM-JJ_Titre_Lieu`) sous le répertoire racine (année ou catégorie thématique) choisi à ce moment pour l'ensemble du voyage (cf. `specs/004-categorisation-dossiers`).
2. **Given** un dossier parent de voyage déjà existant, **When** l'utilisateur importe une nouvelle carte pour une étape suivante et choisit "nouveau sous-dossier dans un dossier parent existant", **Then** Régine liste les dossiers parents existants (locaux et archivés) pour que l'utilisateur choisisse le bon, puis crée le sous-dossier à l'intérieur en héritant automatiquement du répertoire racine déjà établi pour ce dossier parent, sans reposer la question (cf. `specs/004-categorisation-dossiers`).
3. **Given** deux cartes mémoire couvrant la même étape (deux boîtiers, ou une carte de secours), **When** l'utilisateur choisit "fusion dans un dossier existant" pour la seconde carte, **Then** Régine ajoute directement les nouveaux fichiers au dossier ciblé, sans créer de sous-dossier supplémentaire, en détectant les doublons éventuels par somme de contrôle.
4. **Given** une fusion vers un dossier déjà archivé sur l'archive plutôt que seulement local, **When** Régine prépare la fusion, **Then** elle effectue d'abord un aller-retour de vérification (checkout) sur ce dossier avant d'y intégrer les nouveaux fichiers.
5. **Given** deux boîtiers différents produisant chacun un fichier de même nom d'origine au sein d'un même import, **When** Régine détecte la collision par somme de contrôle, **Then** elle désambiguïse par défaut les deux sources à partir du tag EXIF de modèle de chaque fichier, sans exiger de profil de boîtiers préalablement déclaré, et ne sollicite l'utilisateur (profil, numéro de série, étiquetage manuel) que si ce tag ne suffit pas à distinguer les sources (cf. `specs/002-profil-boitiers-optionnel`).

---

### Edge Cases

- Que se passe-t-il si un fichier ne peut pas être vérifié par somme de contrôle pendant la copie depuis la carte (lecture corrompue) ? La copie de ce fichier DOIT être signalée en échec et la carte ne DOIT PAS être considérée comme sûre à effacer tant que le fichier n'est pas correctement recopié et vérifié.
- Que se passe-t-il si la carte mémoire a une vitesse d'accès en lecture particulièrement faible ? La vérification d'intégrité ne DOIT jamais nécessiter une seconde lecture de la carte pour un même fichier : la comparaison se fait entre la somme de contrôle calculée pendant l'unique lecture de la carte et celle recalculée en relisant la copie locale sur disque, pour ne pas doubler le temps d'import sur une carte lente.
- Comment le système gère-t-il une carte contenant des dates de prise de vue aberrantes (horloge de boîtier réinitialisée, ex. dates en 1980 ou 2002) ? Ces fichiers DOIVENT être exclus du calcul de la plage de dates et signalés à l'utilisateur comme anomalie, plutôt que de fausser silencieusement le découpage en groupes.
- Comment le système gère-t-il une carte dont certains fichiers ont déjà été importés précédemment (non effacés de la carte, ou déjà présents dans un dossier différent d'un import antérieur) ? Le système DOIT signaler ces fichiers à l'utilisateur (dossier où ils ont déjà été importés) et attendre sa décision explicite (continuer ou annuler) avant de poursuivre l'analyse et le découpage en groupes — jamais les exclure ou les inclure silencieusement (cf. FR-004 révisé).
- Que se passe-t-il si le nom de dossier calculé entre en collision avec un dossier existant (local ou archivé) ? Le système DOIT proposer un suffixe ou demander une confirmation explicite, jamais écraser silencieusement le dossier existant.
- Que se passe-t-il si l'espace disque local est insuffisant pour accueillir la copie de travail avant même de commencer la copie ? Le système DOIT vérifier l'espace disponible avant de démarrer la copie et interrompre l'import avec un message clair plutôt que d'échouer en cours de copie.
- Comment le système traite-t-il un fichier présent sur la carte qui n'est ni une photo ni un fichier associé reconnu (ex. vidéo, fichier système du boîtier) ? Ce fichier est hors périmètre de l'import et n'est ni copié ni pris en compte dans l'analyse (cf. Assumptions).
- Que se passe-t-il si le partage réseau de l'archive n'est pas monté ou pas accessible au moment de l'import ? L'import DOIT pouvoir se dérouler jusqu'au bout (copie, découpage, renommage, classement, publication locale) sans dépendre de cette accessibilité, puisqu'aucune écriture n'a lieu sur l'archive à ce stade (cf. Clarifications) — seul le chemin d'archive configuré est nécessaire, pas sa disponibilité effective.

## Requirements *(mandatory)*

### Functional Requirements

- **FR-001**: Le système DOIT copier l'intégralité des fichiers nouveaux d'une carte mémoire vers un espace de travail local en une seule lecture de la carte par fichier, en calculant la somme de contrôle de la source au fil de cette copie. Il DOIT ensuite vérifier l'intégrité de la copie en relisant le fichier déjà écrit sur le disque local — jamais en relisant une seconde fois la carte mémoire — et comparer les deux sommes de contrôle avant de considérer la carte comme sûre à effacer.
- **FR-002**: Le système DOIT lire la date de prise de vue (métadonnée EXIF d'origine, jamais la date de fichier) de chaque fichier nouvellement importé, et construire une répartition jour par jour (nombre de photos, plage horaire) du lot importé.
- **FR-003**: Le système DOIT exclure du calcul de plage les fichiers dont la date de prise de vue est aberrante et signaler cette anomalie à l'utilisateur, plutôt que d'inclure silencieusement ces dates dans la plage détectée.
- **FR-004**: Le système DOIT détecter, par somme de contrôle, qu'un fichier de la carte a déjà été importé lors d'une session précédente — que ce fichier soit resté sur la carte (import répété sans effacement) ou qu'il ait déjà été placé dans un dossier différent d'un import antérieur — en comparant à un historique persistant des imports déjà réalisés (révisé le 2026-09-22 : couvre désormais tous les imports passés, pas seulement la session en cours). Quand une correspondance est trouvée, le système DOIT en informer l'utilisateur (fichiers concernés, dossier où ils ont déjà été importés) avant de poursuivre, et lui laisser le choix explicite de continuer l'import malgré tout ou de l'annuler (Principe V) — jamais une exclusion silencieuse ni un blocage automatique.
- **FR-005**: Le système DOIT proposer par défaut un seul groupe couvrant toute la plage de dates contiguë détectée, et permettre à l'utilisateur de détacher un ou plusieurs jours de cette plage pour former des groupes distincts.
- **FR-006**: Le système PEUT mettre en avant un ou plusieurs jours comme candidats plausibles au détachement (ex. pic de prises de vue isolé), mais ne DOIT jamais détacher un groupe automatiquement sans validation de l'utilisateur.
- **FR-007**: Pour chaque groupe résultant du découpage, le système DOIT demander explicitement à l'utilisateur sa destination, parmi : nouveau dossier simple, nouveau sous-dossier d'un dossier parent existant, fusion dans un dossier existant, ou nouveau dossier parent avec sa première étape — sans jamais retenir un état "voyage en cours" d'un import à l'autre. Pour un nouveau dossier simple ou un nouveau dossier parent (jamais pour un nouveau sous-dossier ni une fusion, qui héritent du placement déjà établi), le système DOIT également demander si ce dossier relève d'une catégorie thématique ou du placement par défaut par année (cf. `specs/004-categorisation-dossiers`).
- **FR-008**: Pour aider l'utilisateur à choisir une destination de sous-dossier ou de fusion, le système DOIT lister les dossiers candidats existants à la fois dans l'espace de travail local et dans l'archive (recherche par titre ou date proche).
- **FR-009**: Lorsqu'une fusion cible un dossier déjà présent dans l'archive (et pas seulement en local), le système DOIT d'abord effectuer une vérification (checkout) de ce dossier avant d'y intégrer les nouveaux fichiers.
- **FR-010**: Le système DOIT demander un titre pour chaque groupe, le nettoyer pour en faire un nom de dossier valide (espaces convertis, caractères interdits refusés), puis le combiner avec la plage de dates selon la granularité appropriée (jour unique, plage dans le même mois, plage à cheval sur deux mois/années, ou granularité mois pour un dossier parent de voyage). Le chemin final DOIT également intégrer le répertoire racine déterminé à l'étape FR-007 (répertoire d'année par défaut, ou répertoire de la catégorie thématique choisie) : ce chemin est appliqué immédiatement à la copie de travail locale, et calculé de façon identique pour l'emplacement futur sur l'archive (cf. `specs/004-categorisation-dossiers`), sans y écrire quoi que ce soit avant l'archivage explicite (cf. Clarifications).
- **FR-011**: Le système PEUT suggérer automatiquement un lieu à partir de coordonnées GPS présentes dans les métadonnées EXIF, mais cette suggestion reste modifiable et ne DOIT jamais être imposée à l'utilisateur.
- **FR-012**: Le système DOIT vérifier, avant de créer un dossier final, qu'aucun dossier de nom identique n'existe déjà sous le même répertoire racine (année ou catégorie thématique — cf. `specs/004-categorisation-dossiers`) ; en cas de collision, il DOIT proposer un suffixe ou demander une confirmation explicite plutôt que d'écraser.
- **FR-013**: Le système DOIT renommer chaque fichier maître importé selon la convention `date_titre_nomOrigine.ext`, en conservant le nom d'origine attribué par le boîtier en suffixe, une fois le titre du groupe choisi et juste avant le classement par format et la publication locale.
- **FR-014**: Le système DOIT renommer de façon synchronisée tout fichier partageant le même nom de base qu'un fichier maître renommé (JPEG jumeau en mode RAW+JPEG, sidecar de réglages), pour préserver leur appariement.
- **FR-015**: Le système DOIT désambiguïser par défaut deux fichiers de même nom d'origine provenant de boîtiers différents à partir du tag EXIF de modèle de chaque fichier, sans exiger qu'un profil de boîtiers ait été préalablement déclaré ; il ne DOIT solliciter l'utilisateur (profil, numéro de série, étiquetage manuel) qu'au moment où une collision réelle est détectée par somme de contrôle et où ce tag ne suffit pas à distinguer les sources (cf. `specs/002-profil-boitiers-optionnel`, qui définit ce mécanisme de désambiguïsation en détail).
- **FR-016**: La détection d'un modèle de boîtier jamais rencontré auparavant dans les métadonnées d'un fichier ne DOIT, en l'absence de toute collision réelle, ni interrompre l'import ni exiger une action sur le profil de boîtiers.
- **FR-017**: Le système DOIT attribuer un identifiant pérenne, indépendant du nom de fichier, à chaque photo importée, et l'inscrire dans les métadonnées embarquées du fichier.
- **FR-018**: Avant d'écrire quoi que ce soit dans l'espace de travail local définitif (création de dossier, publication des fichiers renommés, fusion dans un dossier existant), le système DOIT présenter à l'utilisateur un résumé de l'opération (nombre de fichiers concernés, dossier de destination, y compris son répertoire racine — année ou catégorie thématique, cf. `specs/004-categorisation-dossiers`) et attendre une confirmation explicite.
- **FR-019**: Le système DOIT effectuer le transfert final vers l'espace de travail local définitif à partir de la copie de travail temporaire déjà vérifiée, renommée et classée par format, plutôt que par une copie directe de la carte mémoire. Le système NE DOIT PAS écrire sur l'archive NAS à ce stade (cf. Clarifications) : l'archivage est une action distincte et explicite, hors périmètre de l'import lui-même (cf. Assumptions, `specs/005-checkout-reconciliation`).
- **FR-020**: Le système DOIT classer chaque fichier maître renommé dans son dossier de format (`raw/` pour les RAW propriétaires et le DNG, `jpeg/`, `tiff/` pour les scans, ou un dossier dédié pour un format maître plus marginal — cf. `docs/archivage-photo-elements-cles.md` section 10), créé à la demande selon ce qui est réellement présent dans le groupe. Chaque fichier associé (sidecar) DOIT rejoindre le dossier de format de son fichier maître, jamais un dossier qui lui serait propre.

### Key Entities

- **Carte mémoire** : support source d'un import, contenant des fichiers déjà importés lors de sessions précédentes et des fichiers réellement nouveaux à traiter.
- **Copie de travail temporaire** : copie vérifiée par somme de contrôle des fichiers nouveaux d'une carte, base de toute l'analyse, du renommage et du classement par format, avant publication dans l'espace de travail local définitif (distincte de la copie de travail locale ci-dessous).
- **Groupe d'import** : sous-ensemble de fichiers nouvellement importés partageant une plage de dates contiguë, destiné à devenir un dossier ou un sous-dossier de l'espace de travail local (et, plus tard, de l'archive).
- **Dossier de format** : sous-dossier créé à la demande selon ce qui est réellement présent (`raw/`, `jpeg/`, `tiff/`...), où chaque fichier maître renommé est classé (FR-020) — cf. `docs/archivage-photo-elements-cles.md` section 10, définition détaillée reprise par `specs/006-gui-tri-consultation`.
- **Dossier** : unité de l'espace de travail local résultant d'un groupe simple, avec sa structure par format et sa racine de sélection ; vit sous un répertoire racine (année par défaut ou catégorie thématique — cf. `specs/004-categorisation-dossiers`), à la même position relative qu'il occupera plus tard sur l'archive une fois archivé.
- **Copie de travail locale** : le dossier ci-dessus, une fois publié dans l'espace de travail local — prêt à être trié/retouché, pas encore archivé.
- **Dossier parent / sous-dossier** : structure à deux niveaux résultant d'un import s'intégrant à un voyage en plusieurs étapes, partageant le même répertoire racine (année ou catégorie) que le dossier parent qui les englobe.
- **Profil de boîtiers** : liste optionnelle d'appareils, alimentée à la demande (cf. `specs/002-profil-boitiers-optionnel`), utilisée pour désambiguïser la source d'un fichier lorsqu'une collision réelle de nom d'origine survient et que le tag de modèle seul ne suffit pas à la résoudre.
- **Fichier maître** : photo issue directement du boîtier (RAW ou JPEG selon les cas), renommée à l'import et jamais modifiée une fois archivée.
- **Fichier associé** : fichier partageant le nom de base d'un fichier maître (JPEG jumeau, sidecar de réglages), renommé de façon synchronisée avec lui.
- **Identifiant pérenne** : identifiant attribué à chaque photo importée, indépendant de son nom de fichier, inscrit dans ses métadonnées.
- **Historique des imports** : registre persistant associant chaque somme de contrôle déjà importée au dossier de l'espace de travail local où elle a atterri, alimenté à chaque import réussi et consulté avant tout nouvel import pour détecter un doublon (FR-004 révisé) — distinct de la copie de travail temporaire (éphémère) et de la base de données de travail par dossier (`specs/003-config-contexte-travail`).

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-001**: 100% des fichiers copiés depuis une carte mémoire sont vérifiés par somme de contrôle avant que la carte ne soit signalée comme sûre à effacer, sans qu'aucun fichier ne nécessite plus d'une lecture complète de la carte, quelle que soit sa vitesse d'accès.
- **SC-002**: Pour un import à une seule journée sur un seul boîtier, l'utilisateur obtient un dossier local prêt à trier, correctement nommé, classé par format et vérifié, en validant au plus deux décisions (titre, confirmation de la copie locale).
- **SC-003**: 100% des dates de prise de vue aberrantes détectées sur une carte sont signalées à l'utilisateur plutôt qu'intégrées silencieusement au découpage en groupes.
- **SC-004**: 100% des collisions de nom de dossier sont présentées à l'utilisateur avec un choix explicite ; aucune collision ne provoque d'écrasement silencieux.
- **SC-005**: 100% des paires de fichiers associés (fichier maître + JPEG jumeau ou sidecar) conservent leur appariement (même nom de base) après renommage à l'import.
- **SC-006**: Aucune écriture dans l'espace de travail local définitif (création de dossier, ajout de fichiers) ne survient sans qu'un résumé de l'opération n'ait été présenté et explicitement confirmé par l'utilisateur ; et 100% des imports se terminent sans aucune écriture sur l'archive NAS (cf. Clarifications).
- **SC-007**: Un utilisateur qui importe une carte couvrant un voyage en plusieurs étapes peut obtenir une structure à deux niveaux correctement rattachée sans avoir à renommer ou déplacer manuellement de dossier après l'import.
- **SC-008**: Le répertoire racine de destination (année ou catégorie thématique) est visible dans 100% des résumés présentés avant confirmation de la copie locale (cf. `specs/004-categorisation-dossiers`).
- **SC-009**: 100% des fichiers maîtres publiés localement se trouvent dans leur dossier de format attendu (`raw/`, `jpeg/`, `tiff/`...), et chaque fichier associé dans le dossier de format de son fichier maître.
- **SC-010**: Un import peut être mené jusqu'au bout (copie, groupes, renommage, classement, publication locale) sans qu'un partage d'archive configuré ait besoin d'être monté ou accessible durant l'opération.
- **SC-011**: 100% des fichiers dont la somme de contrôle correspond à un import déjà réalisé (quel que soit son dossier de destination) sont signalés à l'utilisateur avant la poursuite de l'import, avec le dossier où ils ont déjà été importés.

## Assumptions

- Le module d'importation couvre le trajet complet depuis la carte mémoire jusqu'à une copie de travail locale prête, classée par format et vérifiée (cf. Clarifications, 2026-09-22) ; il ne couvre ni le tri ultérieur (sélection, promotion à la racine), ni la suppression de déchets évidents, ni l'archivage effectif vers le NAS, qui relèvent tous du flux de réconciliation lors d'une édition (`specs/005-checkout-reconciliation`, hors périmètre de ce module). L'archivage d'un dossier jamais encore poussé au NAS réutilise `regine reconcile` tel quel : un manifeste vide y est créé au premier appel, donc chaque fichier local y est naturellement classé "nouveau" et archivable sur confirmation explicite — aucune capacité supplémentaire à construire côté `specs/005` pour ce cas. Une façade GUI dédiée à cette étape d'archivage n'est pas couverte par cette révision (CLI uniquement pour l'instant, `regine reconcile`) ; `specs/006-gui-tri-consultation` reste à jour séparément le jour où ce besoin est exprimé.
- Les fichiers présents sur la carte mémoire qui ne sont ni des photos (RAW, JPEG, TIFF) ni des fichiers associés reconnus (sidecars) sont hors périmètre de l'import : ils ne sont ni copiés ni pris en compte dans l'analyse.
- Le profil de boîtiers est une capacité optionnelle, alimentée à la demande et non un prérequis avant le premier import (cf. `specs/002-profil-boitiers-optionnel`, qui révise et détaille ce comportement) : ce module se désambiguïse par défaut via le tag EXIF de modèle, et ne sollicite le profil, un numéro de série, ou un étiquetage manuel qu'en cas de collision réelle non résolue par ce tag seul.
- Le mécanisme de checkout/réconciliation d'un dossier déjà archivé (utilisé au cas de fusion vers un dossier existant sur l'archive) est une capacité déjà disponible ou livrée avant ou avec ce module ; ce module ne redéfinit pas ce mécanisme, il s'appuie dessus.
- La suggestion automatique de lieu par coordonnées GPS dépend de la présence de ces coordonnées dans les métadonnées du fichier ; en leur absence, l'utilisateur saisit le lieu librement, sans que cela bloque l'import.
- Une seule carte mémoire est traitée à la fois par import ; l'import simultané de plusieurs cartes n'est pas couvert par ce module.
- Le placement racine d'un dossier ou d'un dossier parent (répertoire d'année par défaut, ou répertoire de catégorie thématique) est défini par `specs/004-categorisation-dossiers`, que ce module ne redéfinit pas : il s'appuie dessus pour l'étape de destination (FR-007), la construction du chemin final (FR-010), la vérification de collision (FR-012) et le résumé de confirmation (FR-018).
- **Ajouté le 2026-09-22** : l'historique des imports (FR-004 révisé) vit dans la base de contexte centralisée déjà en place (`regine_core.config.db`, `specs/003-config-contexte-travail`), au même titre que la liste des boîtiers rencontrés — pas une base séparée. Il n'enregistre qu'une somme de contrôle, un dossier de destination et une date : aucune donnée personnelle, aucun contenu de fichier. La détection reste locale à l'installation de Régine (un seul jeu de chemins par installation, cf. Assumptions de `specs/003`) ; deux installations distinctes de Régine ne partagent pas leurs historiques.