Lexique
3761475 parent: 846589a modified
docs/archivage-photo-elements-cles.md +55 -50 | @@ -19,12 +19,16 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections | ||
| 19 | 19 | |
| 20 | 20 | - Chaque image a un identifiant pérenne (numéro de négatif/planche/rouleau) qui ne change jamais, indépendant du nom de fichier. |
| 21 | 21 | - Permet de relier les différentes versions d'une même image (scan brut, retouche, tirage) dans le temps. |
| 22 | -- Complémentaire à ça, le nom de fichier archivé suit désormais une convention lisible qui encode la provenance (projet/date) — voir section 9, point 6. Les deux coexistent : l'identifiant pérenne sert à relier les versions dans le temps même si le fichier change de nom ou de projet ; le nom de fichier sert à la traçabilité humaine directe, y compris hors de l'application. | |
| 22 | +- Complémentaire à ça, le nom de fichier archivé suit désormais une convention lisible qui encode la provenance (dossier/date) — voir section 9, point 6. Les deux coexistent : l'identifiant pérenne sert à relier les versions dans le temps même si le fichier change de nom ou de dossier ; le nom de fichier sert à la traçabilité humaine directe, y compris hors de l'application. | |
| 23 | 23 | - **Stockage retenu, cf. section 13** : l'identifiant pérenne doit être écrit dans les métadonnées du fichier lui-même (XMP), pas seulement dans la base SQLite de Régine — utile en particulier pour relier un export/rendu dérivé à son fichier maître, puisque cette dérivée a par nature un contenu (et donc un checksum) différent du maître. **À vérifier avant de construire quoi que ce soit de maison, cf. section 13** : un standard existant (XMP Media Management, `DerivedFrom`/`OriginalDocumentID`) pourrait déjà couvrir ce besoin sans que Régine ait à inventer son propre champ. |
| 24 | 24 | |
| 25 | 25 | ## 4. Formats et pérennité des fichiers |
| 26 | 26 | |
| 27 | -- Distinction fichier maître (RAW ou TIFF non compressé, jamais modifié) vs dérivés de diffusion (JPEG, versions web). | |
| 27 | +- **Fichier maître : défini par son rôle, pas par son format (précisé le 2026-09-18).** C'est le fichier faisant autorité pour une capture donnée, celui à conserver indéfiniment sans le modifier — pas automatiquement le RAW : | |
| 28 | + - RAW ou TIFF non compressé : fichier maître par défaut. | |
| 29 | + - **JPEG, quand c'est le seul fichier produit par l'appareil** (capture en JPEG seul, sans RAW) : fichier maître de fait, il n'y a rien d'autre à archiver comme référence. | |
| 30 | + - **JPEG, même en mode RAW+JPEG, quand le photographe juge le JPEG satisfaisant pour l'usage prévu et ne garde le RAW que pour un usage secondaire** (ex. agrandissement exigeant qui demanderait plus de latitude) : le JPEG devient alors le fichier maître de cette capture, le RAW n'étant conservé qu'en complément, pas comme référence automatique. Cette décision se prend au cas par cas selon l'usage prévu, pas selon une règle de format fixe. | |
| 31 | + - Un export de diffusion (JPEG généré à l'export d'un développement RAW, versions web...) reste un **dérivé**, même s'il partage le même format qu'un JPEG fichier maître — c'est le rôle qui distingue les deux, pas l'extension. | |
| 28 | 32 | - Préférence pour des formats ouverts et documentés plutôt que propriétaires. |
| 29 | 33 | - Migrations périodiques planifiées quand un format devient obsolète. |
| 30 | 34 | - **Nuance importante par format, cf. section 11** : cette règle "jamais modifié" tient nativement pour les RAW propriétaires (RAF, CR2, NEF, ARW...), mais pas pour le DNG ni pour les masters TIFF/JPEG, que les outils d'édition courants (Lightroom, DxO PhotoLab) peuvent réécrire pour les métadonnées sans toucher aux pixels. |
| @@ -32,6 +36,7 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections | ||
| 32 | 36 | ## 5. Sauvegarde et intégrité |
| 33 | 37 | |
| 34 | 38 | - Règle **3-2-1** : au moins 3 copies, sur 2 types de support différents, dont 1 hors site. |
| 39 | +- **Application correcte pour Régine (précisé le 2026-09-18)** : le NAS et le cloud ne font que 2 copies, pas 3 — l'ordinateur du photographe ne conserve que des checkouts partiels et temporaires (section 8), jamais une copie complète de l'archive, donc il ne compte pas comme copie au sens de cette règle. Il faut une troisième copie dédiée : un disque de backup local (ex. disque USB), régulièrement synchronisé avec le NAS, sur un support physique différent. Une fois ce disque en place : NAS (copie 1, sur site) + disque de backup (copie 2, sur site, support différent) + cloud (copie 3, hors site) satisfont la règle. | |
| 35 | 40 | - Vérification d'intégrité par **checksums** pour détecter la corruption silencieuse dans le temps. |
| 36 | 41 | - Un checksum ne fait que détecter une corruption, il ne la répare pas : la récupération dépend soit d'une copie saine (règle 3-2-1), soit d'un mécanisme de redondance/réparation dédié — cf. section 11. |
| 37 | 42 | |
| @@ -53,45 +58,45 @@ Principe : Régine gère elle-même l'aller-retour entre l'archive (sur le NAS) | ||
| 53 | 58 | |
| 54 | 59 | Déroulé : |
| 55 | 60 | |
| 56 | -- **Checkout** : Régine copie le contenu d'un projet/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3). **Ce manifeste n'est plus un objet jetable propre au checkout : il correspond à un instantané de la base persistante décrite en section 12, qui vit en permanence à côté du projet sur le NAS. Le checkout porte toujours sur le projet complet (le projet parent avec tous ses sous-projets, s'il y en a) — cf. section 12, un sous-projet ne se checkout jamais isolément.** | |
| 61 | +- **Checkout** : Régine copie le contenu d'un dossier/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3). **Ce manifeste n'est plus un objet jetable propre au checkout : il correspond à un instantané de la base persistante décrite en section 12, qui vit en permanence à côté du dossier sur le NAS. Le checkout porte toujours sur le dossier complet (le dossier parent avec tous ses sous-dossiers, s'il y en a) — cf. section 12, un sous-dossier ne se checkout jamais isolément.** | |
| 57 | 62 | - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps. |
| 58 | 63 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : |
| 59 | 64 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. |
| 60 | 65 | - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. **Pour DNG/TIFF/JPEG, ce critère doit porter sur le hash image-only (section 11), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.** |
| 61 | - - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier de projet entier (ex. transformation d'un projet simple en sous-projet, section 9), et la promotion d'une photo depuis la racine d'un sous-projet vers la racine du projet parent (planche-contact globale, section 10) — un déplacement de fichier à hash inchangé, pas un cas à part.** | |
| 66 | + - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier entier (ex. transformation d'un dossier simple en sous-dossier, section 9), et la promotion d'une photo depuis la racine d'un sous-dossier vers la racine du dossier parent (planche-contact globale, section 10) — un déplacement de fichier à hash inchangé, pas un cas à part.** | |
| 62 | 67 | - hash du manifeste absent de la copie de travail → suppression → jamais propagée automatiquement ; confirmation explicite de l'utilisateur requise avant de toucher à l'archive. |
| 63 | 68 | - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local). |
| 64 | 69 | - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS. |
| 65 | 70 | |
| 66 | 71 | Points à anticiper pour l'implémentation : |
| 67 | 72 | |
| 68 | -- Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go). | |
| 73 | +- Espace disque local suffisant pour la copie de travail (un dossier RAW peut peser plusieurs dizaines de Go). | |
| 69 | 74 | - Temps de transfert réseau au moment du checkout. |
| 70 | -- Verrou/marqueur côté NAS pendant qu'un projet est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle. **Le travail à plusieurs (verrouillage fin, édition concurrente de deux sous-projets d'un même projet parent) est mis de côté pour le moment — cf. section 12.** | |
| 75 | +- Verrou/marqueur côté NAS pendant qu'un dossier est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle. **Le travail à plusieurs (verrouillage fin, édition concurrente de deux sous-dossiers d'un même dossier parent) est mis de côté pour le moment — cf. section 12.** | |
| 71 | 76 | - Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW. |
| 72 | 77 | |
| 73 | 78 | ## 9. Import depuis une carte mémoire |
| 74 | 79 | |
| 75 | -Cas d'usage : fin de journée de prise de vue, ou retour de vacances — intégrer le contenu d'une carte mémoire dans un ou plusieurs projets, en préparation de l'archivage (en amont du workflow de la section 8). Inclut le cas d'un voyage en plusieurs étapes (ex. plusieurs villes), où les imports successifs doivent pouvoir s'organiser en projet parent + sous-projets plutôt qu'en projets indépendants. | |
| 80 | +Cas d'usage : fin de journée de prise de vue, ou retour de vacances — intégrer le contenu d'une carte mémoire dans un ou plusieurs dossiers, en préparation de l'archivage (en amont du workflow de la section 8). Inclut le cas d'un voyage en plusieurs étapes (ex. plusieurs villes), où les imports successifs doivent pouvoir s'organiser en dossier parent + sous-dossiers plutôt qu'en dossiers indépendants. | |
| 76 | 81 | |
| 77 | 82 | **Profil de boîtiers** (prérequis pour le point 6) : à l'installation, l'utilisateur déclare les boîtiers qu'il possède (marque + modèle) ; ce profil reste modifiable à tout moment par la suite (achat, revente, prêt), pas figé une fois pour toutes. Il sert de base à la désambiguïsation entre sources au moment du renommage (point 6). |
| 78 | 83 | |
| 79 | 84 | Séquence retenue : |
| 80 | 85 | |
| 81 | -1. **Copie brute vers un dossier temporaire local** (nom neutre, pas encore le nom final du projet), avec vérification checksum fichier par fichier pendant la copie. Ne jamais considérer la carte comme "sûre à effacer" tant que cette vérification n'est pas passée (idéalement tant qu'une deuxième copie n'existe pas non plus, cf. règle 3-2-1 en section 5). | |
| 86 | +1. **Copie brute vers un dossier temporaire local** (nom neutre, pas encore le nom final du dossier), avec vérification checksum fichier par fichier pendant la copie. Ne jamais considérer la carte comme "sûre à effacer" tant que cette vérification n'est pas passée (idéalement tant qu'une deuxième copie n'existe pas non plus, cf. règle 3-2-1 en section 5). | |
| 82 | 87 | 2. **Analyse EXIF** de la copie locale : lecture de la date de prise de vue (`DateTimeOriginal`, pas la date de fichier) sur chaque fichier importé, pour construire une répartition jour par jour (nombre de photos, plage horaire) du lot. |
| 83 | 88 | - Ne prendre en compte que les fichiers réellement nouveaux pour cet import (comparaison par checksum avec les imports précédents), pas d'anciens fichiers restés sur la carte d'un import antérieur non effacé. |
| 84 | 89 | - Détecter les dates aberrantes (horloge d'appareil réinitialisée après batterie vide, ex. dates en 1980/2002) : les exclure du calcul de plage et signaler l'anomalie à l'utilisateur plutôt que fausser silencieusement la plage détectée. |
| 85 | 90 | 3. **Proposition de découpage en un ou plusieurs groupes** à partir de cette répartition jour par jour. Par défaut, un seul groupe pour toute la plage contiguë détectée, mais l'utilisateur doit pouvoir détacher un ou plusieurs jours (cas type : une semaine de vacances avec un anniversaire au milieu, à isoler à part). Régine peut mettre en avant des candidats plausibles (ex. un pic de photos concentré sur quelques heures, différent du reste), mais seulement comme suggestion — une détection automatique et définitive du type d'événement à partir des seuls horodatages n'est pas fiable et ne doit pas décider à la place de l'utilisateur. |
| 86 | 91 | 4. **Destination de chaque groupe résultant** : pour chaque groupe issu du découpage, Régine demande explicitement où il doit aller, parmi quatre cas — posée à chaque import, sans état "voyage en cours" retenu en mémoire d'une fois sur l'autre : |
| 87 | - - **Nouveau projet simple** : comportement par défaut, structure à un seul niveau. | |
| 88 | - - **Nouveau sous-projet dans un projet parent existant** : cas d'un voyage déjà en plusieurs étapes — Régine liste les projets existants pour que l'utilisateur choisisse le parent. | |
| 89 | - - **Fusion dans un projet existant** : ajout direct des fichiers à un projet déjà là, sans nouveau sous-dossier — cas de deux cartes mémoire (deux boîtiers, ou une carte de secours) couvrant la même sortie. Réutilise directement la désambiguïsation par profil de boîtiers (point 6) et la détection de doublons par checksum déjà prévues (point 2 ci-dessus). Si le projet ciblé est déjà archivé sur le NAS (pas seulement local), la fusion implique d'abord un checkout de ce projet (section 8) pour y intégrer les nouveaux fichiers avant de repousser l'ensemble via la réconciliation habituelle. | |
| 90 | - - **Nouveau projet parent avec sa première étape** : à choisir dès le tout premier import d'un ensemble qu'on sait multi-parties (ex. un voyage) — Régine crée directement la structure à deux niveaux (dossier parent + premier sous-dossier enfant) dès cet import, plutôt qu'un projet plat qu'il faudrait restructurer plus tard. | |
| 91 | - - Pour proposer un choix pertinent (2ᵉ et 3ᵉ cas), Régine liste les projets existants aussi bien en local (espace de travail) que dans l'archive NAS (recherche par titre/date proche) — pas seulement une liste éphémère en mémoire de session. | |
| 92 | + - **Nouveau dossier simple** : comportement par défaut, structure à un seul niveau. | |
| 93 | + - **Nouveau sous-dossier dans un dossier parent existant** : cas d'un voyage déjà en plusieurs étapes — Régine liste les dossiers existants pour que l'utilisateur choisisse le parent. | |
| 94 | + - **Fusion dans un dossier existant** : ajout direct des fichiers à un dossier déjà là, sans nouveau sous-dossier — cas de deux cartes mémoire (deux boîtiers, ou une carte de secours) couvrant la même sortie. Réutilise directement la désambiguïsation par profil de boîtiers (point 6) et la détection de doublons par checksum déjà prévues (point 2 ci-dessus). Si le dossier ciblé est déjà archivé sur le NAS (pas seulement local), la fusion implique d'abord un checkout de ce dossier (section 8) pour y intégrer les nouveaux fichiers avant de repousser l'ensemble via la réconciliation habituelle. | |
| 95 | + - **Nouveau dossier parent avec sa première étape** : à choisir dès le tout premier import d'un ensemble qu'on sait multi-parties (ex. un voyage) — Régine crée directement la structure à deux niveaux (dossier parent + premier sous-dossier enfant) dès cet import, plutôt qu'un dossier plat qu'il faudrait restructurer plus tard. | |
| 96 | + - Pour proposer un choix pertinent (2ᵉ et 3ᵉ cas), Régine liste les dossiers existants aussi bien en local (espace de travail) que dans l'archive NAS (recherche par titre/date proche) — pas seulement une liste éphémère en mémoire de session. | |
| 92 | 97 | 5. **Titre et nom de dossier** demandé pour chaque groupe, nettoyé pour servir de nom de dossier (espaces → underscores, interdiction des caractères invalides `/ \ : * ? " < >`), puis combiné à la plage de dates : |
| 93 | - - projet simple ou étape d'un voyage : un jour unique `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`) ou, pour une étape de voyage, `YYYY-MM-DD_Titre_Lieu` (ex. `2026-08-12_Montenegro_Kotor`) ; une plage dans le même mois `YYYY-MM-DD-DD_Titre` (ex. `2026-08-11-20_Vacances_Alsace`) ; une plage à cheval sur deux mois/années en forme complète `YYYY-MM-DD_YYYY-MM-DD_Titre` (la forme compacte ne fonctionne que dans le même mois). | |
| 94 | - - projet parent (voyage) : granularité mois, `YYYY-MM_Titre` (ex. `2026-08_Montenegro`) — la date de fin n'est pas connue au moment du premier import. Peut être affiné a posteriori avec la plage réelle une fois le voyage terminé, sans obligation (le nom du dossier n'a pas besoin d'être une description exacte). | |
| 98 | + - dossier simple ou étape d'un voyage : un jour unique `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`) ou, pour une étape de voyage, `YYYY-MM-DD_Titre_Lieu` (ex. `2026-08-12_Montenegro_Kotor`) ; une plage dans le même mois `YYYY-MM-DD-DD_Titre` (ex. `2026-08-11-20_Vacances_Alsace`) ; une plage à cheval sur deux mois/années en forme complète `YYYY-MM-DD_YYYY-MM-DD_Titre` (la forme compacte ne fonctionne que dans le même mois). | |
| 99 | + - dossier parent (voyage) : granularité mois, `YYYY-MM_Titre` (ex. `2026-08_Montenegro`) — la date de fin n'est pas connue au moment du premier import. Peut être affiné a posteriori avec la plage réelle une fois le voyage terminé, sans obligation (le nom du dossier n'a pas besoin d'être une description exacte). | |
| 95 | 100 | - le lieu (ville, étape) est saisi librement par l'utilisateur, avec suggestion automatique optionnelle si des coordonnées GPS sont présentes en EXIF (les smartphones en ont, la plupart des boîtiers dédiés non) — en simple suggestion, jamais imposée, même prudence que pour la détection de jours particuliers au point 3. |
| 96 | 101 | - si un jour est extrait du milieu d'une plage contiguë, le groupe restant garde le nom de la plage d'origine plutôt que de recalculer un nom qui ne refléterait que les jours effectivement inclus. |
| 97 | 102 | - vérification de collision avant de créer le dossier final : si un nom identique existe déjà, proposer un suffixe ou demander confirmation plutôt que d'écraser. |
| @@ -101,22 +106,22 @@ Séquence retenue : | ||
| 101 | 106 | - **Mécanisme principal : le profil de boîtiers déclaré par l'utilisateur** (voir en tête de section), comparé au tag EXIF `Model` — quasi universellement renseigné, contrairement au `BodySerialNumber`. Ça suffit à distinguer deux sources dans l'immense majorité des cas (marques ou modèles différents), sans recourir au numéro de série ni redemander à chaque import. Un modèle détecté mais absent du profil déclenche un signalement ponctuel ("modèle non reconnu, l'ajouter au profil ?"), jamais un ajout silencieux. |
| 102 | 107 | - **Repli**, réservé au cas plus rare de deux unités strictement identiques (même marque, même modèle) possédées en parallèle, où le `Model` seul ne suffit plus : le tag EXIF **BodySerialNumber** (`0xA431`, introduit par Exif 2.3) quand il est présent et exploitable (non vide, non valeur placeholder), sinon étiquetage manuel de la source à l'import. Ce champ n'est pas garanti sur tous les boîtiers : fiable chez Canon et Nikon sur la plupart des modèles récents, inconsistant chez Sony, variable chez Fujifilm/Panasonic/Olympus selon le modèle. |
| 103 | 108 | - Dans tous les cas, un élément disambiguant n'est ajouté qu'en cas de collision réelle (détectée par comparaison de checksum, pas juste par nom de fichier identique). |
| 104 | - - **Ordre de prise de vue** : le nom d'origine en suffixe ne garantit l'ordre chronologique qu'au sein d'un même appareil. Pour un tri fiable entre plusieurs boîtiers dans un même projet, s'appuyer sur la date EXIF (déjà lue à l'étape 2), pas sur un tri alphabétique du nom de fichier renommé. | |
| 109 | + - **Ordre de prise de vue** : le nom d'origine en suffixe ne garantit l'ordre chronologique qu'au sein d'un même appareil. Pour un tri fiable entre plusieurs boîtiers dans un même dossier, s'appuyer sur la date EXIF (déjà lue à l'étape 2), pas sur un tri alphabétique du nom de fichier renommé. | |
| 105 | 110 | 7. Une fois le(s) dossier(s) finalisé(s) et les fichiers renommés en local, ils sont poussés vers l'archive NAS — même logique de copie vérifiée qu'à l'étape 1, plutôt qu'une copie directe carte → NAS (plus lente et plus fragile aux coupures réseau). |
| 106 | 111 | |
| 107 | -**Transformer un projet existant en sous-projet, a posteriori.** Si l'utilisateur n'a pas anticipé qu'un import allait devenir le début d'un voyage à plusieurs étapes (4ᵉ cas du point 4), rien n'empêche de corriger après coup : déplacer le dossier du projet existant à l'intérieur d'un nouveau (ou d'un autre) projet parent, en renommant si besoin le dossier et ses fichiers. C'est une opération légère, pas une limitation à contourner : le déplacement et le renommage ne changent aucun octet, donc les checksums restent identiques (cas déjà couvert par la détection de déplacement par hash, section 8) ; les side files (XMP/DOP) suivent leur fichier associé puisqu'ils sont déjà renommés de façon synchronisée (point 6 ci-dessus) ; et l'identifiant pérenne (section 3), pensé justement pour être indépendant du chemin et du nom de fichier, reste inchangé tout du long. Si le projet à transformer est déjà archivé, l'opération passe par le cycle checkout/réconciliation habituel plutôt que par une modification directe du NAS hors de Régine. **Si le projet devenu sous-projet avait déjà sa propre base de checksums (section 12), ses lignes sont absorbées dans la base du projet parent au même moment — cf. section 12 pour le détail.** | |
| 112 | +**Transformer un dossier existant en sous-dossier, a posteriori.** Si l'utilisateur n'a pas anticipé qu'un import allait devenir le début d'un voyage à plusieurs étapes (4ᵉ cas du point 4), rien n'empêche de corriger après coup : déplacer le dossier existant à l'intérieur d'un nouveau (ou d'un autre) dossier parent, en renommant si besoin le dossier et ses fichiers. C'est une opération légère, pas une limitation à contourner : le déplacement et le renommage ne changent aucun octet, donc les checksums restent identiques (cas déjà couvert par la détection de déplacement par hash, section 8) ; les side files (XMP/DOP) suivent leur fichier associé puisqu'ils sont déjà renommés de façon synchronisée (point 6 ci-dessus) ; et l'identifiant pérenne (section 3), pensé justement pour être indépendant du chemin et du nom de fichier, reste inchangé tout du long. Si le dossier à transformer est déjà archivé, l'opération passe par le cycle checkout/réconciliation habituel plutôt que par une modification directe du NAS hors de Régine. **Si le dossier devenu sous-dossier avait déjà sa propre base de checksums (section 12), ses lignes sont absorbées dans la base du dossier parent au même moment — cf. section 12 pour le détail.** | |
| 108 | 113 | |
| 109 | -## 10. Structure d'un projet, sélection et déchets évidents | |
| 114 | +## 10. Structure d'un dossier, sélection et déchets évidents | |
| 110 | 115 | |
| 111 | -Structure retenue pour un projet (après plusieurs itérations) : | |
| 116 | +Structure retenue pour un dossier (après plusieurs itérations) : | |
| 112 | 117 | |
| 113 | -- **Un dossier par format, créé à la demande** selon ce qui est réellement présent dans le projet — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, `tiff/` pour les scans. Un format plus marginal, s'il apparaît, est traité exactement de la même façon (un dossier créé à la demande), sans logique ni migration spécifique pour des formats périmés — pas la peine de complexifier le design pour des cas anecdotiques. | |
| 118 | +- **Un dossier de format, créé à la demande** selon ce qui est réellement présent dans le dossier — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, `tiff/` pour les scans. Un format plus marginal, s'il apparaît, est traité exactement de la même façon (un dossier de format créé à la demande), sans logique ni migration spécifique pour des formats périmés — pas la peine de complexifier le design pour des cas anecdotiques. | |
| 114 | 119 | - `raw/` est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (`.RAF`, `.CR2`, `.NEF`, `.ARW`...), pas un format unique — contrairement à `jpeg/` et `tiff/`, qui correspondent chacun à une extension précise. |
| 115 | -- **Racine du projet** : la sélection, prête à être vue directement (y compris en rouvrant le projet dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF sélectionné. | |
| 120 | +- **Racine du dossier** : la sélection, prête à être vue directement (y compris en rouvrant le dossier dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF sélectionné. | |
| 116 | 121 | |
| 117 | 122 | Ce découpage par format plutôt que par statut (sélection/reste) remplace le dossier "autres" envisagé précédemment : ce qui n'est pas promu à la racine reste simplement dans son dossier de format. |
| 118 | 123 | |
| 119 | -**Un projet parent est un projet comme les autres, avec sa propre racine.** Un sous-projet (étape d'un voyage) a sa propre structure complète (dossiers de format + sa propre racine, sélection au niveau de l'étape). Le projet parent a en plus sa propre racine à lui, qui sert de planche-contact globale sur l'ensemble du voyage : une photo peut être promue une deuxième fois, de la racine de son étape vers la racine du projet parent, pour apparaître dans cette vue d'ensemble. **Promotion en deux temps** (racine de l'étape, puis racine du voyage), pas un raccourci direct depuis le dossier de format de l'étape — deux gestes distincts, correspondant à deux niveaux de sélection réels (la meilleure photo de l'étape, puis les meilleures du voyage entier). Techniquement, ce deuxième déplacement est un cas de plus couvert par la détection de déplacement par hash déjà en place (section 8), rien de spécifique à construire. | |
| 124 | +**Un dossier parent est un dossier comme les autres, avec sa propre racine.** Un sous-dossier (étape d'un voyage) a sa propre structure complète (dossiers de format + sa propre racine, sélection au niveau de l'étape). Le dossier parent a en plus sa propre racine à lui, qui sert de planche-contact globale sur l'ensemble du voyage : une photo peut être promue une deuxième fois, de la racine de son étape vers la racine du dossier parent, pour apparaître dans cette vue d'ensemble. **Promotion en deux temps** (racine de l'étape, puis racine du voyage), pas un raccourci direct depuis le dossier de format de l'étape — deux gestes distincts, correspondant à deux niveaux de sélection réels (la meilleure photo de l'étape, puis les meilleures du voyage entier). Techniquement, ce deuxième déplacement est un cas de plus couvert par la détection de déplacement par hash déjà en place (section 8), rien de spécifique à construire. | |
| 120 | 125 | |
| 121 | 126 | **Cas des scans TIFF** : un scan (négatif, tirage papier) n'a pas de "RAW" à côté — le TIFF est directement le fichier maître au sens de la section 4, à conserver sans jamais le modifier, au même titre qu'un RAW. |
| 122 | 127 | |
| @@ -129,12 +134,12 @@ L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de | ||
| 129 | 134 | - **Déchets évidents** (test d'exposition, déclenchement accidentel, photo des pieds...) : suppression légitime, tous formats compris, avant même le tri par format. Ça ne contredit pas le principe de fichier maître jamais modifié silencieusement (section 4) : la suppression passe par la confirmation explicite déjà prévue à l'étape de réconciliation (section 8) — c'est exactement l'usage prévu de cette étape, pas une entorse à la règle. |
| 130 | 135 | - **Captures correctement prises mais non sélectionnées** (pas les meilleures, ni des déchets) : jamais supprimées ; elles restent simplement dans leur dossier de format, non promues à la racine. |
| 131 | 136 | |
| 132 | -**Checkout partiel pour aller vite.** Pour un usage type vacances où la vitesse prime, Régine peut ne faire sortir que le dossier `jpeg/` (et la racine) dans l'espace de travail local, sans le `raw/`, pour un tri/traitement rapide dans l'outil du moment. Les RAW correspondants restent dans l'archive, non modifiés, récupérables séparément si un cas se révèle finalement difficile à traiter. Cette structure par format rend ce checkout partiel immédiat (un dossier entier à exclure), plus simple qu'avec un tri par statut où RAW et JPEG étaient mélangés. **Ce "partiel" porte sur les formats à l'intérieur d'un projet complet, pas sur un sous-projet isolé du reste — cf. section 12, on ne checkout jamais un seul sous-projet sans son projet parent.** | |
| 137 | +**Checkout partiel pour aller vite.** Pour un usage type vacances où la vitesse prime, Régine peut ne faire sortir que le dossier `jpeg/` (et la racine) dans l'espace de travail local, sans le `raw/`, pour un tri/traitement rapide dans l'outil du moment. Les RAW correspondants restent dans l'archive, non modifiés, récupérables séparément si un cas se révèle finalement difficile à traiter. Cette structure par format rend ce checkout partiel immédiat (un dossier entier à exclure), plus simple qu'avec un tri par statut où RAW et JPEG étaient mélangés. **Ce "partiel" porte sur les formats à l'intérieur d'un dossier complet, pas sur un sous-dossier isolé du reste — cf. section 12, on ne checkout jamais un seul sous-dossier sans son dossier parent.** | |
| 133 | 138 | |
| 134 | 139 | **Limites observées avec DxO PhotoLab, à corriger dans Régine :** |
| 135 | 140 | |
| 136 | 141 | - Pas d'association visuelle entre un RAW et son JPEG jumeau (mode RAW+JPEG) : les deux apparaissent comme deux entrées séparées dans la liste, ce qui pousse à en supprimer un juste pour désencombrer l'affichage. Objectif pour Régine : regrouper une paire RAW+JPEG comme une seule entrée à l'écran, même si elles vivent dans des dossiers différents. |
| 137 | -- Navigation limitée au dossier courant, pas de vue combinée racine + sous-dossiers. Objectif pour Régine : permettre une vue multi-dossiers d'un même projet. | |
| 142 | +- Navigation limitée au dossier courant, pas de vue combinée racine + sous-dossiers. Objectif pour Régine : permettre une vue combinant plusieurs dossiers de format d'un même dossier. | |
| 138 | 143 | |
| 139 | 144 | ## 11. Modification des fichiers par les outils d'édition : quand le "fichier maître jamais modifié" tient vraiment |
| 140 | 145 | |
| @@ -168,11 +173,11 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r | ||
| 168 | 173 | - Fichiers de parité **PAR2** (Parchive) stockés à côté du master : permettent de réparer une corruption partielle sans disposer d'une deuxième copie complète du fichier. |
| 169 | 174 | - Système de fichiers à checksums auto-réparants (**ZFS**, **Btrfs**) avec redondance (miroir/RAID) : détection et réparation automatiques à la lecture, au niveau du NAS plutôt que de l'application. |
| 170 | 175 | |
| 171 | -## 12. Manifeste persistant par projet et compatibilité de format entre versions de Régine | |
| 176 | +## 12. Manifeste persistant par dossier et compatibilité de format entre versions de Régine | |
| 172 | 177 | |
| 173 | -Point de départ (2026-09-11) : le manifeste décrit en section 8 n'existait jusqu'ici que comme un instantané pris au moment d'un checkout, recréé à chaque fois plutôt que conservé. Deux besoins poussent à le rendre persistant, stocké en permanence à côté de chaque projet sur le NAS : la vérification périodique (scrub, section 11), qui a besoin d'un état de référence stable dans le temps et pas seulement au moment d'une édition ; et la nécessité qu'une version ancienne de Régine ne puisse pas ouvrir/écrire un projet dont le format a évolué depuis, pour éviter une corruption silencieuse par mécompréhension du format. | |
| 178 | +Point de départ (2026-09-11) : le manifeste décrit en section 8 n'existait jusqu'ici que comme un instantané pris au moment d'un checkout, recréé à chaque fois plutôt que conservé. Deux besoins poussent à le rendre persistant, stocké en permanence à côté de chaque dossier sur le NAS : la vérification périodique (scrub, section 11), qui a besoin d'un état de référence stable dans le temps et pas seulement au moment d'une édition ; et la nécessité qu'une version ancienne de Régine ne puisse pas ouvrir/écrire un dossier dont le format a évolué depuis, pour éviter une corruption silencieuse par mécompréhension du format. | |
| 174 | 179 | |
| 175 | -**Choix de format : SQLite plutôt qu'un fichier JSON pour les checksums.** Un JSON plat contenant les checksums de tout un projet (potentiellement des milliers de fichiers) et réécrit intégralement à chaque réconciliation est vulnérable à une coupure (crash, perte d'alimentation) en plein milieu de l'écriture — un comble pour un mécanisme censé protéger contre la corruption. SQLite écrit de façon transactionnelle : pas d'état intermédiaire corrompu possible. C'est aussi cohérent avec le principe de section 4 ("formats ouverts et documentés plutôt que propriétaires") : la Bibliothèque du Congrès américaine recommande explicitement SQLite comme format de stockage pour l'archivage à long terme (déclaration 2025-2026), et SQLite lui-même documente son usage comme format de fichier applicatif à part entière (transactions, requêtes indexées, un seul fichier auto-suffisant). | |
| 180 | +**Choix de format : SQLite plutôt qu'un fichier JSON pour les checksums.** Un JSON plat contenant les checksums de tout un dossier (potentiellement des milliers de fichiers) et réécrit intégralement à chaque réconciliation est vulnérable à une coupure (crash, perte d'alimentation) en plein milieu de l'écriture — un comble pour un mécanisme censé protéger contre la corruption. SQLite écrit de façon transactionnelle : pas d'état intermédiaire corrompu possible. C'est aussi cohérent avec le principe de section 4 ("formats ouverts et documentés plutôt que propriétaires") : la Bibliothèque du Congrès américaine recommande explicitement SQLite comme format de stockage pour l'archivage à long terme (déclaration 2025-2026), et SQLite lui-même documente son usage comme format de fichier applicatif à part entière (transactions, requêtes indexées, un seul fichier auto-suffisant). | |
| 176 | 181 | |
| 177 | 182 | **La version de format doit vivre dans la base elle-même, pas dans un fichier séparé.** SQLite prévoit exactement ce besoin avec deux pragmas intégrés à l'en-tête du fichier : |
| 178 | 183 | |
| @@ -184,36 +189,36 @@ L'intérêt sur un fichier de version séparé (l'idée initiale d'un `Regine.js | ||
| 184 | 189 | **Version d'appli vs version de format : deux choses différentes à ne pas confondre.** La version de Régine (numéro de release, change souvent) ne doit pas être le critère de compatibilité — la plupart des mises à jour de l'appli ne toucheront jamais la structure des données sur disque. Le critère doit porter sur un numéro de format qui n'augmente que lorsque la structure change réellement, avec deux niveaux de gravité (à la manière de `core.repositoryformatversion` dans Git, qui bloque uniquement sur les extensions de format inconnues, ou du versionnage interne de SQLite) : |
| 185 | 190 | |
| 186 | 191 | - changement additif (nouveau champ optionnel) → une version plus ancienne de Régine peut l'ignorer et continuer à fonctionner normalement ; |
| 187 | -- changement structurel (renommage, suppression, changement de sens d'un champ, nouvel algorithme de hash) → refus explicite d'ouvrir le projet avec une version de Régine trop ancienne, plutôt qu'une mauvaise interprétation silencieuse. | |
| 192 | +- changement structurel (renommage, suppression, changement de sens d'un champ, nouvel algorithme de hash) → refus explicite d'ouvrir le dossier avec une version de Régine trop ancienne, plutôt qu'une mauvaise interprétation silencieuse. | |
| 188 | 193 | |
| 189 | -**Migration à anticiper dès la conception, même sans l'implémenter tout de suite.** Le jour où un changement structurel impose ce refus, il faut qu'une version récente de Régine sache mettre à niveau un projet ancien en place. Sans ça, un projet ancien devient lisible par une seule version précise de l'appli — contraire à l'objectif d'archivage long terme de tout le projet. | |
| 194 | +**Migration à anticiper dès la conception, même sans l'implémenter tout de suite.** Le jour où un changement structurel impose ce refus, il faut qu'une version récente de Régine sache mettre à niveau un dossier ancien en place. Sans ça, un dossier ancien devient lisible par une seule version précise de l'appli — contraire à l'objectif d'archivage long terme de tout le projet. | |
| 190 | 195 | |
| 191 | -**Portée retenue : une base SQLite unique à la racine du projet principal, couvrant aussi ses sous-projets.** Révision du 2026-09-11 par rapport à la première version de cette section (qui proposait une base par sous-projet, composée à la demande via `ATTACH DATABASE`) : cette première version reposait sur deux hypothèses que Fabien a corrigées entre-temps — | |
| 196 | +**Portée retenue : une base SQLite unique à la racine du dossier principal, couvrant aussi ses sous-dossiers.** Révision du 2026-09-11 par rapport à la première version de cette section (qui proposait une base par sous-dossier, composée à la demande via `ATTACH DATABASE`) : cette première version reposait sur deux hypothèses que Fabien a corrigées entre-temps — | |
| 192 | 197 | |
| 193 | -- un sous-projet n'est **jamais checké out isolément** : c'est le projet global (parent + sous-projets) qui constitue l'unité de gestion, pas chaque étape individuellement (cf. sections 8 et 10) ; | |
| 194 | -- **le travail à plusieurs (verrouillage fin par sous-projet pour permettre l'édition concurrente de deux étapes) est mis de côté pour le moment**, ce qui retire l'argument principal en faveur de bases séparées. | |
| 198 | +- un sous-dossier n'est **jamais checké out isolément** : c'est le dossier global (parent + sous-dossiers) qui constitue l'unité de gestion, pas chaque étape individuellement (cf. sections 8 et 10) ; | |
| 199 | +- **le travail à plusieurs (verrouillage fin par sous-dossier pour permettre l'édition concurrente de deux étapes) est mis de côté pour le moment**, ce qui retire l'argument principal en faveur de bases séparées. | |
| 195 | 200 | |
| 196 | -Avec ces deux précisions, une base unique par projet (le projet parent, sous-projets inclus) est le choix le plus simple et le plus cohérent, pour deux raisons supplémentaires : | |
| 201 | +Avec ces deux précisions, une base unique par dossier (le dossier parent, sous-dossiers inclus) est le choix le plus simple et le plus cohérent, pour deux raisons supplémentaires : | |
| 197 | 202 | |
| 198 | -- Le projet parent a sa propre racine, qui sert de planche-contact globale sur l'ensemble du voyage (section 10) : promouvoir une photo de la racine d'une étape vers la racine du projet parent est alors un déplacement de plus, couvert nativement par la détection de renommage/déplacement par hash déjà en place (section 8) — sans base séparée, pas besoin de gérer une transition d'une base à l'autre pour ce geste. | |
| 199 | -- Fusionner les checksums d'un projet devenu sous-projet (section 9) dans la base de son nouveau parent reste une opération bon marché avec SQLite (`ATTACH` de l'ancienne base, `INSERT ... SELECT`, suppression de l'ancien fichier) — un coût ponctuel et transactionnel, pas une migration fragile. | |
| 203 | +- Le dossier parent a sa propre racine, qui sert de planche-contact globale sur l'ensemble du voyage (section 10) : promouvoir une photo de la racine d'une étape vers la racine du dossier parent est alors un déplacement de plus, couvert nativement par la détection de renommage/déplacement par hash déjà en place (section 8) — sans base séparée, pas besoin de gérer une transition d'une base à l'autre pour ce geste. | |
| 204 | +- Fusionner les checksums d'un dossier devenu sous-dossier (section 9) dans la base de son nouveau parent reste une opération bon marché avec SQLite (`ATTACH` de l'ancienne base, `INSERT ... SELECT`, suppression de l'ancien fichier) — un coût ponctuel et transactionnel, pas une migration fragile. | |
| 200 | 205 | |
| 201 | -La suggestion `ATTACH DATABASE` pour composer plusieurs bases à la demande devient donc inutile dans ce modèle — un seul fichier à interroger. Si le travail à plusieurs est repris plus tard, la question du verrouillage par sous-projet (plutôt que par projet entier) sera à rouvrir à ce moment-là ; ce n'est pas un renoncement définitif, juste une simplification volontaire pour l'instant. | |
| 206 | +La suggestion `ATTACH DATABASE` pour composer plusieurs bases à la demande devient donc inutile dans ce modèle — un seul fichier à interroger. Si le travail à plusieurs est repris plus tard, la question du verrouillage par sous-dossier (plutôt que par dossier entier) sera à rouvrir à ce moment-là ; ce n'est pas un renoncement définitif, juste une simplification volontaire pour l'instant. | |
| 202 | 207 | |
| 203 | -**Un petit fichier JSON complémentaire reste utile, mais avec un rôle différent** : pas les checksums, une simple fiche d'identité du projet lisible sans outil (nom, identifiant pérenne, date de création, copie du numéro de format pour un coup d'œil rapide sans ouvrir la base SQLite). À écrire selon la même discipline que tout fichier qui ne doit jamais être observé à moitié écrit : écriture dans un fichier temporaire puis renommage atomique, plutôt que réécriture directe du fichier final. | |
| 208 | +**Un petit fichier JSON complémentaire reste utile, mais avec un rôle différent** : pas les checksums, une simple fiche d'identité du dossier lisible sans outil (nom, identifiant pérenne, date de création, copie du numéro de format pour un coup d'œil rapide sans ouvrir la base SQLite). À écrire selon la même discipline que tout fichier qui ne doit jamais être observé à moitié écrit : écriture dans un fichier temporaire puis renommage atomique, plutôt que réécriture directe du fichier final. | |
| 204 | 209 | |
| 205 | -**Un sous-projet garde sa propre base, elle ne fusionne pas dans celle du parent — voir la portée révisée plus haut dans cette section.** | |
| 210 | +**Un sous-dossier garde sa propre base, elle ne fusionne pas dans celle du parent — voir la portée révisée plus haut dans cette section.** | |
| 206 | 211 | |
| 207 | -## 13. Copie inter-projets pour composer un nouveau projet (livre, sélection thématique) | |
| 212 | +## 13. Copie inter-dossiers pour composer un nouveau projet (livre, sélection thématique) | |
| 208 | 213 | |
| 209 | -Point de départ (2026-09-11) : au-delà du "Bestof" évoqué comme exemple, le cas général est de piocher dans l'archive pour composer un nouveau projet autonome (un livre, une expo) en **copiant** les fichiers choisis depuis leurs projets d'origine, plutôt qu'en les déplaçant ou en les référençant. Confirmé : ces projets restent des projets séparés et indépendants, pas rattachés les uns aux autres par une hiérarchie parent/sous-projet — le livre est son propre projet. | |
| 214 | +Point de départ (2026-09-11) : au-delà du "Bestof" évoqué comme exemple, le cas général est de piocher dans l'archive pour composer un nouveau projet autonome (un livre, une expo) en **copiant** les fichiers choisis depuis leurs dossiers d'origine, plutôt qu'en les déplaçant ou en les référençant. Confirmé : ces projets restent des projets séparés et indépendants, pas rattachés les uns aux autres par une hiérarchie parent/sous-dossier — le livre est son propre projet. | |
| 210 | 215 | |
| 211 | 216 | **Pourquoi la copie plutôt qu'une référence (lien symbolique, lien physique) :** |
| 212 | 217 | |
| 213 | -- La détection de déplacement par hash (section 8) ne fonctionne qu'à l'intérieur d'un seul projet, entre sa copie de travail et son propre manifeste — elle n'a jamais été prévue pour repérer un fichier traversant deux projets différents. Une référence entre projets ne serait donc de toute façon suivie par aucun mécanisme existant. | |
| 214 | -- Un lien symbolique casse le principe d'auto-suffisance des projets (section 10/12) : il pointe dans le vide si le projet source est déplacé ou renommé. | |
| 218 | +- La détection de déplacement par hash (section 8) ne fonctionne qu'à l'intérieur d'un seul dossier, entre sa copie de travail et son propre manifeste — elle n'a jamais été prévue pour repérer un fichier traversant deux dossiers différents. Une référence entre dossiers ne serait donc de toute façon suivie par aucun mécanisme existant. | |
| 219 | +- Un lien symbolique casse le principe d'auto-suffisance des dossiers (section 10/12) : il pointe dans le vide si le dossier source est déplacé ou renommé. | |
| 215 | 220 | - Un lien physique (hardlink) semble économiser l'espace disque, mais défait justement l'objectif recherché : les deux entrées pointant sur les mêmes octets, modifier les métadonnées de l'original dans DxO changerait aussi silencieusement la copie dans le nouveau projet. |
| 216 | -- Une vraie copie physique reste cohérente avec le principe déjà posé : chaque projet doit rester lisible et autonome, y compris sans les autres projets présents à côté. | |
| 221 | +- Une vraie copie physique reste cohérente avec le principe déjà posé : chaque dossier doit rester lisible et autonome, y compris sans les autres dossiers présents à côté. | |
| 217 | 222 | |
| 218 | 223 | **Le checksum reste un lien valable indéfiniment pour retrouver un fichier maître copié — correction du 2026-09-11 par rapport à la première version de cette section.** Cette première version affirmait qu'une "vraie retouche" (recadrage, étalonnage) pour le travail de cohérence du livre change les pixels et donc le checksum, ne laissant que l'identifiant pérenne comme lien fiable. C'était une erreur : le développement RAW est non destructif par nature (section 11) — recadrage, exposition, étalonnage restent des réglages stockés en sidecar (RAW propriétaires, JPEG/TIFF traités en non destructif) ou en métadonnées embarquées (DNG), jamais appliqués aux pixels eux-mêmes. Le fichier maître copié dans le projet livre garde donc son contenu image intact quel que soit le travail de cohérence effectué dessus, tant que ce travail reste non destructif — ce qui est déjà la règle partout ailleurs dans l'archive, pas une exception ici. Concrètement : |
| 219 | 224 | |
| @@ -234,8 +239,8 @@ Si DxO renseigne ces champs, Régine n'a pas besoin d'écrire son propre identif | ||
| 234 | 239 | |
| 235 | 240 | **Deux mécanismes à prévoir pour la traçabilité, indépendamment du résultat de cette vérification :** |
| 236 | 241 | |
| 237 | -- **Fiche de provenance au moment de la copie** : quand Régine effectue la copie (copie vérifiée par checksum, même logique que l'import carte mémoire section 9 point 1, avec la même vérification de collision de nom), elle enregistre directement dans la base du nouveau projet une petite fiche de provenance (projet source, identifiant du fichier, nom d'origine). Traçabilité immédiate dans le cas courant, sans recherche. | |
| 238 | -- **Recherche inter-projets par identifiant ou checksum, en dernier recours** : pour le cas où la fiche de provenance serait perdue, ou le fichier retrouvé par un autre biais (y compris un export dérivé). Matérialise concrètement le besoin d'index inter-projets déjà anticipé comme "à construire plus tard" en section 12 (recherche en lecture seule dans l'archive) — un outil qui parcourt les bases SQLite de chaque projet (ou un index reconstruit à partir d'elles) pour localiser un identifiant ou un hash donné. | |
| 242 | +- **Fiche de provenance au moment de la copie** : quand Régine effectue la copie (copie vérifiée par checksum, même logique que l'import carte mémoire section 9 point 1, avec la même vérification de collision de nom), elle enregistre directement dans la base du nouveau projet une petite fiche de provenance (dossier source, identifiant du fichier, nom d'origine). Traçabilité immédiate dans le cas courant, sans recherche. | |
| 243 | +- **Recherche inter-dossiers par identifiant ou checksum, en dernier recours** : pour le cas où la fiche de provenance serait perdue, ou le fichier retrouvé par un autre biais (y compris un export dérivé). Matérialise concrètement le besoin d'index inter-dossiers déjà anticipé comme "à construire plus tard" en section 12 (recherche en lecture seule dans l'archive) — un outil qui parcourt les bases SQLite de chaque dossier (ou un index reconstruit à partir d'elles) pour localiser un identifiant ou un hash donné. | |
| 239 | 244 | |
| 240 | 245 | ## Pistes de fonctionnalités pour Régine |
| 241 | 246 | |
| @@ -247,12 +252,12 @@ Si DxO renseigne ces champs, Régine n'a pas besoin d'écrire son propre identif | ||
| 247 | 252 | - Champs de droits/licence par photo ou par lot. |
| 248 | 253 | - Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 8. |
| 249 | 254 | - Profil de boîtiers configurable (déclaré à l'installation, modifiable à tout moment) comme mécanisme principal de désambiguïsation des sources par EXIF `Model`, `BodySerialNumber`/étiquetage manuel gardés en repli pour deux unités identiques du même modèle — cf. section 9, point 6. |
| 250 | -- Import carte mémoire avec quatre destinations possibles à chaque fois (nouveau projet simple, nouveau sous-projet d'un parent existant, fusion dans un projet existant, nouveau projet parent avec sa première étape), recherche des projets candidats en local et dans l'archive, structure voyage (parent `YYYY-MM_Titre` / étapes `YYYY-MM-DD_Titre_Lieu`), et transformation a posteriori d'un projet simple en sous-projet — cf. section 9. | |
| 251 | -- Structure de projet par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, extensible à d'autres formats sans traitement spécifique) avec sélection à la racine (promotion manuelle, par fichier) à deux niveaux pour un projet parent (racine de l'étape, puis racine du voyage comme planche-contact globale), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF — cf. section 10. | |
| 252 | -- Interface de tri/culling propre à Régine : association visuelle RAW+JPEG même dans des dossiers différents, navigation multi-dossiers d'un même projet, checkout partiel (`jpeg/` seul) pour un tri rapide sans toucher aux RAW archivés, suppression de déchets évidents via la confirmation de réconciliation — cf. section 10. | |
| 255 | +- Import carte mémoire avec quatre destinations possibles à chaque fois (nouveau dossier simple, nouveau sous-dossier d'un parent existant, fusion dans un dossier existant, nouveau dossier parent avec sa première étape), recherche des dossiers candidats en local et dans l'archive, structure voyage (parent `YYYY-MM_Titre` / étapes `YYYY-MM-DD_Titre_Lieu`), et transformation a posteriori d'un dossier simple en sous-dossier — cf. section 9. | |
| 256 | +- Structure de dossier par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, extensible à d'autres formats sans traitement spécifique) avec sélection à la racine (promotion manuelle, par fichier) à deux niveaux pour un dossier parent (racine de l'étape, puis racine du voyage comme planche-contact globale), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF — cf. section 10. | |
| 257 | +- Interface de tri/culling propre à Régine : association visuelle RAW+JPEG même dans des dossiers différents, navigation combinant plusieurs dossiers de format d'un même dossier, checkout partiel (`jpeg/` seul) pour un tri rapide sans toucher aux RAW archivés, suppression de déchets évidents via la confirmation de réconciliation — cf. section 10. | |
| 253 | 258 | - Hash d'intégrité à deux niveaux (fichier entier + image-only via ExifTool `ImageDataHash`) pour distinguer édition de métadonnées et vraie corruption sur DNG/TIFF/JPEG, plus une tâche de vérification périodique (scrub) indépendante du checkout — cf. section 11. Ce même hash image-only permet de suivre un DNG par checksum sur la durée, retouche non destructive comprise. |
| 254 | -- Manifeste persistant en base SQLite unique à la racine du projet principal (parent + sous-projets), avec numéro de format via `PRAGMA user_version`/`application_id` distinguant changement additif (toléré par une version ancienne) vs structurel (refus explicite + migration à prévoir) ; checkout et verrou portent sur le projet complet, jamais un sous-projet isolé — le travail à plusieurs (verrouillage fin par sous-projet) est mis de côté pour le moment — cf. section 12. | |
| 255 | -- Copie vérifiée inter-projets pour composer un nouveau projet (livre, sélection thématique) à partir de l'archive : checksum + nom de fichier suffisent pour retrouver un fichier maître copié (retouche non destructive comprise) ; fiche de provenance enregistrée au moment de la copie et outil de recherche inter-projets en dernier recours, utiles surtout pour le cas résiduel d'un export dérivé — cf. section 13. | |
| 259 | +- Manifeste persistant en base SQLite unique à la racine du dossier principal (parent + sous-dossiers), avec numéro de format via `PRAGMA user_version`/`application_id` distinguant changement additif (toléré par une version ancienne) vs structurel (refus explicite + migration à prévoir) ; checkout et verrou portent sur le dossier complet, jamais un sous-dossier isolé — le travail à plusieurs (verrouillage fin par sous-dossier) est mis de côté pour le moment — cf. section 12. | |
| 260 | +- Copie vérifiée inter-dossiers pour composer un nouveau projet (livre, sélection thématique) à partir de l'archive : checksum + nom de fichier suffisent pour retrouver un fichier maître copié (retouche non destructive comprise) ; fiche de provenance enregistrée au moment de la copie et outil de recherche inter-dossiers en dernier recours, utiles surtout pour le cas résiduel d'un export dérivé — cf. section 13. | |
| 256 | 261 | |
| 257 | 262 | ## Sources |
| 258 | 263 | |
| @@ -19,12 +19,16 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections | |||
| 19 | 19 | ||
| 20 | - Chaque image a un identifiant pérenne (numéro de négatif/planche/rouleau) qui ne change jamais, indépendant du nom de fichier. | 20 | - Chaque image a un identifiant pérenne (numéro de négatif/planche/rouleau) qui ne change jamais, indépendant du nom de fichier. |
| 21 | - Permet de relier les différentes versions d'une même image (scan brut, retouche, tirage) dans le temps. | 21 | - Permet de relier les différentes versions d'une même image (scan brut, retouche, tirage) dans le temps. |
| 22 | -- Complémentaire à ça, le nom de fichier archivé suit désormais une convention lisible qui encode la provenance (projet/date) — voir section 9, point 6. Les deux coexistent : l'identifiant pérenne sert à relier les versions dans le temps même si le fichier change de nom ou de projet ; le nom de fichier sert à la traçabilité humaine directe, y compris hors de l'application. | 22 | +- Complémentaire à ça, le nom de fichier archivé suit désormais une convention lisible qui encode la provenance (dossier/date) — voir section 9, point 6. Les deux coexistent : l'identifiant pérenne sert à relier les versions dans le temps même si le fichier change de nom ou de dossier ; le nom de fichier sert à la traçabilité humaine directe, y compris hors de l'application. |
| 23 | - **Stockage retenu, cf. section 13** : l'identifiant pérenne doit être écrit dans les métadonnées du fichier lui-même (XMP), pas seulement dans la base SQLite de Régine — utile en particulier pour relier un export/rendu dérivé à son fichier maître, puisque cette dérivée a par nature un contenu (et donc un checksum) différent du maître. **À vérifier avant de construire quoi que ce soit de maison, cf. section 13** : un standard existant (XMP Media Management, `DerivedFrom`/`OriginalDocumentID`) pourrait déjà couvrir ce besoin sans que Régine ait à inventer son propre champ. | 23 | - **Stockage retenu, cf. section 13** : l'identifiant pérenne doit être écrit dans les métadonnées du fichier lui-même (XMP), pas seulement dans la base SQLite de Régine — utile en particulier pour relier un export/rendu dérivé à son fichier maître, puisque cette dérivée a par nature un contenu (et donc un checksum) différent du maître. **À vérifier avant de construire quoi que ce soit de maison, cf. section 13** : un standard existant (XMP Media Management, `DerivedFrom`/`OriginalDocumentID`) pourrait déjà couvrir ce besoin sans que Régine ait à inventer son propre champ. |
| 24 | 24 | ||
| 25 | ## 4. Formats et pérennité des fichiers | 25 | ## 4. Formats et pérennité des fichiers |
| 26 | 26 | ||
| 27 | -- Distinction fichier maître (RAW ou TIFF non compressé, jamais modifié) vs dérivés de diffusion (JPEG, versions web). | 27 | +- **Fichier maître : défini par son rôle, pas par son format (précisé le 2026-09-18).** C'est le fichier faisant autorité pour une capture donnée, celui à conserver indéfiniment sans le modifier — pas automatiquement le RAW : |
| 28 | + - RAW ou TIFF non compressé : fichier maître par défaut. | ||
| 29 | + - **JPEG, quand c'est le seul fichier produit par l'appareil** (capture en JPEG seul, sans RAW) : fichier maître de fait, il n'y a rien d'autre à archiver comme référence. | ||
| 30 | + - **JPEG, même en mode RAW+JPEG, quand le photographe juge le JPEG satisfaisant pour l'usage prévu et ne garde le RAW que pour un usage secondaire** (ex. agrandissement exigeant qui demanderait plus de latitude) : le JPEG devient alors le fichier maître de cette capture, le RAW n'étant conservé qu'en complément, pas comme référence automatique. Cette décision se prend au cas par cas selon l'usage prévu, pas selon une règle de format fixe. | ||
| 31 | + - Un export de diffusion (JPEG généré à l'export d'un développement RAW, versions web...) reste un **dérivé**, même s'il partage le même format qu'un JPEG fichier maître — c'est le rôle qui distingue les deux, pas l'extension. | ||
| 28 | - Préférence pour des formats ouverts et documentés plutôt que propriétaires. | 32 | - Préférence pour des formats ouverts et documentés plutôt que propriétaires. |
| 29 | - Migrations périodiques planifiées quand un format devient obsolète. | 33 | - Migrations périodiques planifiées quand un format devient obsolète. |
| 30 | - **Nuance importante par format, cf. section 11** : cette règle "jamais modifié" tient nativement pour les RAW propriétaires (RAF, CR2, NEF, ARW...), mais pas pour le DNG ni pour les masters TIFF/JPEG, que les outils d'édition courants (Lightroom, DxO PhotoLab) peuvent réécrire pour les métadonnées sans toucher aux pixels. | 34 | - **Nuance importante par format, cf. section 11** : cette règle "jamais modifié" tient nativement pour les RAW propriétaires (RAF, CR2, NEF, ARW...), mais pas pour le DNG ni pour les masters TIFF/JPEG, que les outils d'édition courants (Lightroom, DxO PhotoLab) peuvent réécrire pour les métadonnées sans toucher aux pixels. |
| @@ -32,6 +36,7 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections | |||
| 32 | ## 5. Sauvegarde et intégrité | 36 | ## 5. Sauvegarde et intégrité |
| 33 | 37 | ||
| 34 | - Règle **3-2-1** : au moins 3 copies, sur 2 types de support différents, dont 1 hors site. | 38 | - Règle **3-2-1** : au moins 3 copies, sur 2 types de support différents, dont 1 hors site. |
| 39 | +- **Application correcte pour Régine (précisé le 2026-09-18)** : le NAS et le cloud ne font que 2 copies, pas 3 — l'ordinateur du photographe ne conserve que des checkouts partiels et temporaires (section 8), jamais une copie complète de l'archive, donc il ne compte pas comme copie au sens de cette règle. Il faut une troisième copie dédiée : un disque de backup local (ex. disque USB), régulièrement synchronisé avec le NAS, sur un support physique différent. Une fois ce disque en place : NAS (copie 1, sur site) + disque de backup (copie 2, sur site, support différent) + cloud (copie 3, hors site) satisfont la règle. | ||
| 35 | - Vérification d'intégrité par **checksums** pour détecter la corruption silencieuse dans le temps. | 40 | - Vérification d'intégrité par **checksums** pour détecter la corruption silencieuse dans le temps. |
| 36 | - Un checksum ne fait que détecter une corruption, il ne la répare pas : la récupération dépend soit d'une copie saine (règle 3-2-1), soit d'un mécanisme de redondance/réparation dédié — cf. section 11. | 41 | - Un checksum ne fait que détecter une corruption, il ne la répare pas : la récupération dépend soit d'une copie saine (règle 3-2-1), soit d'un mécanisme de redondance/réparation dédié — cf. section 11. |
| 37 | 42 | ||
| @@ -53,45 +58,45 @@ Principe : Régine gère elle-même l'aller-retour entre l'archive (sur le NAS) | |||
| 53 | 58 | ||
| 54 | Déroulé : | 59 | Déroulé : |
| 55 | 60 | ||
| 56 | -- **Checkout** : Régine copie le contenu d'un projet/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3). **Ce manifeste n'est plus un objet jetable propre au checkout : il correspond à un instantané de la base persistante décrite en section 12, qui vit en permanence à côté du projet sur le NAS. Le checkout porte toujours sur le projet complet (le projet parent avec tous ses sous-projets, s'il y en a) — cf. section 12, un sous-projet ne se checkout jamais isolément.** | 61 | +- **Checkout** : Régine copie le contenu d'un dossier/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3). **Ce manifeste n'est plus un objet jetable propre au checkout : il correspond à un instantané de la base persistante décrite en section 12, qui vit en permanence à côté du dossier sur le NAS. Le checkout porte toujours sur le dossier complet (le dossier parent avec tous ses sous-dossiers, s'il y en a) — cf. section 12, un sous-dossier ne se checkout jamais isolément.** |
| 57 | - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps. | 62 | - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps. |
| 58 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : | 63 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : |
| 59 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. | 64 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. |
| 60 | - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. **Pour DNG/TIFF/JPEG, ce critère doit porter sur le hash image-only (section 11), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.** | 65 | - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. **Pour DNG/TIFF/JPEG, ce critère doit porter sur le hash image-only (section 11), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.** |
| 61 | - - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier de projet entier (ex. transformation d'un projet simple en sous-projet, section 9), et la promotion d'une photo depuis la racine d'un sous-projet vers la racine du projet parent (planche-contact globale, section 10) — un déplacement de fichier à hash inchangé, pas un cas à part.** | 66 | + - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier entier (ex. transformation d'un dossier simple en sous-dossier, section 9), et la promotion d'une photo depuis la racine d'un sous-dossier vers la racine du dossier parent (planche-contact globale, section 10) — un déplacement de fichier à hash inchangé, pas un cas à part.** |
| 62 | - hash du manifeste absent de la copie de travail → suppression → jamais propagée automatiquement ; confirmation explicite de l'utilisateur requise avant de toucher à l'archive. | 67 | - hash du manifeste absent de la copie de travail → suppression → jamais propagée automatiquement ; confirmation explicite de l'utilisateur requise avant de toucher à l'archive. |
| 63 | - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local). | 68 | - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local). |
| 64 | - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS. | 69 | - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS. |
| 65 | 70 | ||
| 66 | Points à anticiper pour l'implémentation : | 71 | Points à anticiper pour l'implémentation : |
| 67 | 72 | ||
| 68 | -- Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go). | 73 | +- Espace disque local suffisant pour la copie de travail (un dossier RAW peut peser plusieurs dizaines de Go). |
| 69 | - Temps de transfert réseau au moment du checkout. | 74 | - Temps de transfert réseau au moment du checkout. |
| 70 | -- Verrou/marqueur côté NAS pendant qu'un projet est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle. **Le travail à plusieurs (verrouillage fin, édition concurrente de deux sous-projets d'un même projet parent) est mis de côté pour le moment — cf. section 12.** | 75 | +- Verrou/marqueur côté NAS pendant qu'un dossier est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle. **Le travail à plusieurs (verrouillage fin, édition concurrente de deux sous-dossiers d'un même dossier parent) est mis de côté pour le moment — cf. section 12.** |
| 71 | - Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW. | 76 | - Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW. |
| 72 | 77 | ||
| 73 | ## 9. Import depuis une carte mémoire | 78 | ## 9. Import depuis une carte mémoire |
| 74 | 79 | ||
| 75 | -Cas d'usage : fin de journée de prise de vue, ou retour de vacances — intégrer le contenu d'une carte mémoire dans un ou plusieurs projets, en préparation de l'archivage (en amont du workflow de la section 8). Inclut le cas d'un voyage en plusieurs étapes (ex. plusieurs villes), où les imports successifs doivent pouvoir s'organiser en projet parent + sous-projets plutôt qu'en projets indépendants. | 80 | +Cas d'usage : fin de journée de prise de vue, ou retour de vacances — intégrer le contenu d'une carte mémoire dans un ou plusieurs dossiers, en préparation de l'archivage (en amont du workflow de la section 8). Inclut le cas d'un voyage en plusieurs étapes (ex. plusieurs villes), où les imports successifs doivent pouvoir s'organiser en dossier parent + sous-dossiers plutôt qu'en dossiers indépendants. |
| 76 | 81 | ||
| 77 | **Profil de boîtiers** (prérequis pour le point 6) : à l'installation, l'utilisateur déclare les boîtiers qu'il possède (marque + modèle) ; ce profil reste modifiable à tout moment par la suite (achat, revente, prêt), pas figé une fois pour toutes. Il sert de base à la désambiguïsation entre sources au moment du renommage (point 6). | 82 | **Profil de boîtiers** (prérequis pour le point 6) : à l'installation, l'utilisateur déclare les boîtiers qu'il possède (marque + modèle) ; ce profil reste modifiable à tout moment par la suite (achat, revente, prêt), pas figé une fois pour toutes. Il sert de base à la désambiguïsation entre sources au moment du renommage (point 6). |
| 78 | 83 | ||
| 79 | Séquence retenue : | 84 | Séquence retenue : |
| 80 | 85 | ||
| 81 | -1. **Copie brute vers un dossier temporaire local** (nom neutre, pas encore le nom final du projet), avec vérification checksum fichier par fichier pendant la copie. Ne jamais considérer la carte comme "sûre à effacer" tant que cette vérification n'est pas passée (idéalement tant qu'une deuxième copie n'existe pas non plus, cf. règle 3-2-1 en section 5). | 86 | +1. **Copie brute vers un dossier temporaire local** (nom neutre, pas encore le nom final du dossier), avec vérification checksum fichier par fichier pendant la copie. Ne jamais considérer la carte comme "sûre à effacer" tant que cette vérification n'est pas passée (idéalement tant qu'une deuxième copie n'existe pas non plus, cf. règle 3-2-1 en section 5). |
| 82 | 2. **Analyse EXIF** de la copie locale : lecture de la date de prise de vue (`DateTimeOriginal`, pas la date de fichier) sur chaque fichier importé, pour construire une répartition jour par jour (nombre de photos, plage horaire) du lot. | 87 | 2. **Analyse EXIF** de la copie locale : lecture de la date de prise de vue (`DateTimeOriginal`, pas la date de fichier) sur chaque fichier importé, pour construire une répartition jour par jour (nombre de photos, plage horaire) du lot. |
| 83 | - Ne prendre en compte que les fichiers réellement nouveaux pour cet import (comparaison par checksum avec les imports précédents), pas d'anciens fichiers restés sur la carte d'un import antérieur non effacé. | 88 | - Ne prendre en compte que les fichiers réellement nouveaux pour cet import (comparaison par checksum avec les imports précédents), pas d'anciens fichiers restés sur la carte d'un import antérieur non effacé. |
| 84 | - Détecter les dates aberrantes (horloge d'appareil réinitialisée après batterie vide, ex. dates en 1980/2002) : les exclure du calcul de plage et signaler l'anomalie à l'utilisateur plutôt que fausser silencieusement la plage détectée. | 89 | - Détecter les dates aberrantes (horloge d'appareil réinitialisée après batterie vide, ex. dates en 1980/2002) : les exclure du calcul de plage et signaler l'anomalie à l'utilisateur plutôt que fausser silencieusement la plage détectée. |
| 85 | 3. **Proposition de découpage en un ou plusieurs groupes** à partir de cette répartition jour par jour. Par défaut, un seul groupe pour toute la plage contiguë détectée, mais l'utilisateur doit pouvoir détacher un ou plusieurs jours (cas type : une semaine de vacances avec un anniversaire au milieu, à isoler à part). Régine peut mettre en avant des candidats plausibles (ex. un pic de photos concentré sur quelques heures, différent du reste), mais seulement comme suggestion — une détection automatique et définitive du type d'événement à partir des seuls horodatages n'est pas fiable et ne doit pas décider à la place de l'utilisateur. | 90 | 3. **Proposition de découpage en un ou plusieurs groupes** à partir de cette répartition jour par jour. Par défaut, un seul groupe pour toute la plage contiguë détectée, mais l'utilisateur doit pouvoir détacher un ou plusieurs jours (cas type : une semaine de vacances avec un anniversaire au milieu, à isoler à part). Régine peut mettre en avant des candidats plausibles (ex. un pic de photos concentré sur quelques heures, différent du reste), mais seulement comme suggestion — une détection automatique et définitive du type d'événement à partir des seuls horodatages n'est pas fiable et ne doit pas décider à la place de l'utilisateur. |
| 86 | 4. **Destination de chaque groupe résultant** : pour chaque groupe issu du découpage, Régine demande explicitement où il doit aller, parmi quatre cas — posée à chaque import, sans état "voyage en cours" retenu en mémoire d'une fois sur l'autre : | 91 | 4. **Destination de chaque groupe résultant** : pour chaque groupe issu du découpage, Régine demande explicitement où il doit aller, parmi quatre cas — posée à chaque import, sans état "voyage en cours" retenu en mémoire d'une fois sur l'autre : |
| 87 | - - **Nouveau projet simple** : comportement par défaut, structure à un seul niveau. | 92 | + - **Nouveau dossier simple** : comportement par défaut, structure à un seul niveau. |
| 88 | - - **Nouveau sous-projet dans un projet parent existant** : cas d'un voyage déjà en plusieurs étapes — Régine liste les projets existants pour que l'utilisateur choisisse le parent. | 93 | + - **Nouveau sous-dossier dans un dossier parent existant** : cas d'un voyage déjà en plusieurs étapes — Régine liste les dossiers existants pour que l'utilisateur choisisse le parent. |
| 89 | - - **Fusion dans un projet existant** : ajout direct des fichiers à un projet déjà là, sans nouveau sous-dossier — cas de deux cartes mémoire (deux boîtiers, ou une carte de secours) couvrant la même sortie. Réutilise directement la désambiguïsation par profil de boîtiers (point 6) et la détection de doublons par checksum déjà prévues (point 2 ci-dessus). Si le projet ciblé est déjà archivé sur le NAS (pas seulement local), la fusion implique d'abord un checkout de ce projet (section 8) pour y intégrer les nouveaux fichiers avant de repousser l'ensemble via la réconciliation habituelle. | 94 | + - **Fusion dans un dossier existant** : ajout direct des fichiers à un dossier déjà là, sans nouveau sous-dossier — cas de deux cartes mémoire (deux boîtiers, ou une carte de secours) couvrant la même sortie. Réutilise directement la désambiguïsation par profil de boîtiers (point 6) et la détection de doublons par checksum déjà prévues (point 2 ci-dessus). Si le dossier ciblé est déjà archivé sur le NAS (pas seulement local), la fusion implique d'abord un checkout de ce dossier (section 8) pour y intégrer les nouveaux fichiers avant de repousser l'ensemble via la réconciliation habituelle. |
| 90 | - - **Nouveau projet parent avec sa première étape** : à choisir dès le tout premier import d'un ensemble qu'on sait multi-parties (ex. un voyage) — Régine crée directement la structure à deux niveaux (dossier parent + premier sous-dossier enfant) dès cet import, plutôt qu'un projet plat qu'il faudrait restructurer plus tard. | 95 | + - **Nouveau dossier parent avec sa première étape** : à choisir dès le tout premier import d'un ensemble qu'on sait multi-parties (ex. un voyage) — Régine crée directement la structure à deux niveaux (dossier parent + premier sous-dossier enfant) dès cet import, plutôt qu'un dossier plat qu'il faudrait restructurer plus tard. |
| 91 | - - Pour proposer un choix pertinent (2ᵉ et 3ᵉ cas), Régine liste les projets existants aussi bien en local (espace de travail) que dans l'archive NAS (recherche par titre/date proche) — pas seulement une liste éphémère en mémoire de session. | 96 | + - Pour proposer un choix pertinent (2ᵉ et 3ᵉ cas), Régine liste les dossiers existants aussi bien en local (espace de travail) que dans l'archive NAS (recherche par titre/date proche) — pas seulement une liste éphémère en mémoire de session. |
| 92 | 5. **Titre et nom de dossier** demandé pour chaque groupe, nettoyé pour servir de nom de dossier (espaces → underscores, interdiction des caractères invalides `/ \ : * ? " < >`), puis combiné à la plage de dates : | 97 | 5. **Titre et nom de dossier** demandé pour chaque groupe, nettoyé pour servir de nom de dossier (espaces → underscores, interdiction des caractères invalides `/ \ : * ? " < >`), puis combiné à la plage de dates : |
| 93 | - - projet simple ou étape d'un voyage : un jour unique `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`) ou, pour une étape de voyage, `YYYY-MM-DD_Titre_Lieu` (ex. `2026-08-12_Montenegro_Kotor`) ; une plage dans le même mois `YYYY-MM-DD-DD_Titre` (ex. `2026-08-11-20_Vacances_Alsace`) ; une plage à cheval sur deux mois/années en forme complète `YYYY-MM-DD_YYYY-MM-DD_Titre` (la forme compacte ne fonctionne que dans le même mois). | 98 | + - dossier simple ou étape d'un voyage : un jour unique `YYYY-MM-DD_Titre` (ex. `2026-09-09_Anniversaire`) ou, pour une étape de voyage, `YYYY-MM-DD_Titre_Lieu` (ex. `2026-08-12_Montenegro_Kotor`) ; une plage dans le même mois `YYYY-MM-DD-DD_Titre` (ex. `2026-08-11-20_Vacances_Alsace`) ; une plage à cheval sur deux mois/années en forme complète `YYYY-MM-DD_YYYY-MM-DD_Titre` (la forme compacte ne fonctionne que dans le même mois). |
| 94 | - - projet parent (voyage) : granularité mois, `YYYY-MM_Titre` (ex. `2026-08_Montenegro`) — la date de fin n'est pas connue au moment du premier import. Peut être affiné a posteriori avec la plage réelle une fois le voyage terminé, sans obligation (le nom du dossier n'a pas besoin d'être une description exacte). | 99 | + - dossier parent (voyage) : granularité mois, `YYYY-MM_Titre` (ex. `2026-08_Montenegro`) — la date de fin n'est pas connue au moment du premier import. Peut être affiné a posteriori avec la plage réelle une fois le voyage terminé, sans obligation (le nom du dossier n'a pas besoin d'être une description exacte). |
| 95 | - le lieu (ville, étape) est saisi librement par l'utilisateur, avec suggestion automatique optionnelle si des coordonnées GPS sont présentes en EXIF (les smartphones en ont, la plupart des boîtiers dédiés non) — en simple suggestion, jamais imposée, même prudence que pour la détection de jours particuliers au point 3. | 100 | - le lieu (ville, étape) est saisi librement par l'utilisateur, avec suggestion automatique optionnelle si des coordonnées GPS sont présentes en EXIF (les smartphones en ont, la plupart des boîtiers dédiés non) — en simple suggestion, jamais imposée, même prudence que pour la détection de jours particuliers au point 3. |
| 96 | - si un jour est extrait du milieu d'une plage contiguë, le groupe restant garde le nom de la plage d'origine plutôt que de recalculer un nom qui ne refléterait que les jours effectivement inclus. | 101 | - si un jour est extrait du milieu d'une plage contiguë, le groupe restant garde le nom de la plage d'origine plutôt que de recalculer un nom qui ne refléterait que les jours effectivement inclus. |
| 97 | - vérification de collision avant de créer le dossier final : si un nom identique existe déjà, proposer un suffixe ou demander confirmation plutôt que d'écraser. | 102 | - vérification de collision avant de créer le dossier final : si un nom identique existe déjà, proposer un suffixe ou demander confirmation plutôt que d'écraser. |
| @@ -101,22 +106,22 @@ Séquence retenue : | |||
| 101 | - **Mécanisme principal : le profil de boîtiers déclaré par l'utilisateur** (voir en tête de section), comparé au tag EXIF `Model` — quasi universellement renseigné, contrairement au `BodySerialNumber`. Ça suffit à distinguer deux sources dans l'immense majorité des cas (marques ou modèles différents), sans recourir au numéro de série ni redemander à chaque import. Un modèle détecté mais absent du profil déclenche un signalement ponctuel ("modèle non reconnu, l'ajouter au profil ?"), jamais un ajout silencieux. | 106 | - **Mécanisme principal : le profil de boîtiers déclaré par l'utilisateur** (voir en tête de section), comparé au tag EXIF `Model` — quasi universellement renseigné, contrairement au `BodySerialNumber`. Ça suffit à distinguer deux sources dans l'immense majorité des cas (marques ou modèles différents), sans recourir au numéro de série ni redemander à chaque import. Un modèle détecté mais absent du profil déclenche un signalement ponctuel ("modèle non reconnu, l'ajouter au profil ?"), jamais un ajout silencieux. |
| 102 | - **Repli**, réservé au cas plus rare de deux unités strictement identiques (même marque, même modèle) possédées en parallèle, où le `Model` seul ne suffit plus : le tag EXIF **BodySerialNumber** (`0xA431`, introduit par Exif 2.3) quand il est présent et exploitable (non vide, non valeur placeholder), sinon étiquetage manuel de la source à l'import. Ce champ n'est pas garanti sur tous les boîtiers : fiable chez Canon et Nikon sur la plupart des modèles récents, inconsistant chez Sony, variable chez Fujifilm/Panasonic/Olympus selon le modèle. | 107 | - **Repli**, réservé au cas plus rare de deux unités strictement identiques (même marque, même modèle) possédées en parallèle, où le `Model` seul ne suffit plus : le tag EXIF **BodySerialNumber** (`0xA431`, introduit par Exif 2.3) quand il est présent et exploitable (non vide, non valeur placeholder), sinon étiquetage manuel de la source à l'import. Ce champ n'est pas garanti sur tous les boîtiers : fiable chez Canon et Nikon sur la plupart des modèles récents, inconsistant chez Sony, variable chez Fujifilm/Panasonic/Olympus selon le modèle. |
| 103 | - Dans tous les cas, un élément disambiguant n'est ajouté qu'en cas de collision réelle (détectée par comparaison de checksum, pas juste par nom de fichier identique). | 108 | - Dans tous les cas, un élément disambiguant n'est ajouté qu'en cas de collision réelle (détectée par comparaison de checksum, pas juste par nom de fichier identique). |
| 104 | - - **Ordre de prise de vue** : le nom d'origine en suffixe ne garantit l'ordre chronologique qu'au sein d'un même appareil. Pour un tri fiable entre plusieurs boîtiers dans un même projet, s'appuyer sur la date EXIF (déjà lue à l'étape 2), pas sur un tri alphabétique du nom de fichier renommé. | 109 | + - **Ordre de prise de vue** : le nom d'origine en suffixe ne garantit l'ordre chronologique qu'au sein d'un même appareil. Pour un tri fiable entre plusieurs boîtiers dans un même dossier, s'appuyer sur la date EXIF (déjà lue à l'étape 2), pas sur un tri alphabétique du nom de fichier renommé. |
| 105 | 7. Une fois le(s) dossier(s) finalisé(s) et les fichiers renommés en local, ils sont poussés vers l'archive NAS — même logique de copie vérifiée qu'à l'étape 1, plutôt qu'une copie directe carte → NAS (plus lente et plus fragile aux coupures réseau). | 110 | 7. Une fois le(s) dossier(s) finalisé(s) et les fichiers renommés en local, ils sont poussés vers l'archive NAS — même logique de copie vérifiée qu'à l'étape 1, plutôt qu'une copie directe carte → NAS (plus lente et plus fragile aux coupures réseau). |
| 106 | 111 | ||
| 107 | -**Transformer un projet existant en sous-projet, a posteriori.** Si l'utilisateur n'a pas anticipé qu'un import allait devenir le début d'un voyage à plusieurs étapes (4ᵉ cas du point 4), rien n'empêche de corriger après coup : déplacer le dossier du projet existant à l'intérieur d'un nouveau (ou d'un autre) projet parent, en renommant si besoin le dossier et ses fichiers. C'est une opération légère, pas une limitation à contourner : le déplacement et le renommage ne changent aucun octet, donc les checksums restent identiques (cas déjà couvert par la détection de déplacement par hash, section 8) ; les side files (XMP/DOP) suivent leur fichier associé puisqu'ils sont déjà renommés de façon synchronisée (point 6 ci-dessus) ; et l'identifiant pérenne (section 3), pensé justement pour être indépendant du chemin et du nom de fichier, reste inchangé tout du long. Si le projet à transformer est déjà archivé, l'opération passe par le cycle checkout/réconciliation habituel plutôt que par une modification directe du NAS hors de Régine. **Si le projet devenu sous-projet avait déjà sa propre base de checksums (section 12), ses lignes sont absorbées dans la base du projet parent au même moment — cf. section 12 pour le détail.** | 112 | +**Transformer un dossier existant en sous-dossier, a posteriori.** Si l'utilisateur n'a pas anticipé qu'un import allait devenir le début d'un voyage à plusieurs étapes (4ᵉ cas du point 4), rien n'empêche de corriger après coup : déplacer le dossier existant à l'intérieur d'un nouveau (ou d'un autre) dossier parent, en renommant si besoin le dossier et ses fichiers. C'est une opération légère, pas une limitation à contourner : le déplacement et le renommage ne changent aucun octet, donc les checksums restent identiques (cas déjà couvert par la détection de déplacement par hash, section 8) ; les side files (XMP/DOP) suivent leur fichier associé puisqu'ils sont déjà renommés de façon synchronisée (point 6 ci-dessus) ; et l'identifiant pérenne (section 3), pensé justement pour être indépendant du chemin et du nom de fichier, reste inchangé tout du long. Si le dossier à transformer est déjà archivé, l'opération passe par le cycle checkout/réconciliation habituel plutôt que par une modification directe du NAS hors de Régine. **Si le dossier devenu sous-dossier avait déjà sa propre base de checksums (section 12), ses lignes sont absorbées dans la base du dossier parent au même moment — cf. section 12 pour le détail.** |
| 108 | 113 | ||
| 109 | -## 10. Structure d'un projet, sélection et déchets évidents | 114 | +## 10. Structure d'un dossier, sélection et déchets évidents |
| 110 | 115 | ||
| 111 | -Structure retenue pour un projet (après plusieurs itérations) : | 116 | +Structure retenue pour un dossier (après plusieurs itérations) : |
| 112 | 117 | ||
| 113 | -- **Un dossier par format, créé à la demande** selon ce qui est réellement présent dans le projet — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, `tiff/` pour les scans. Un format plus marginal, s'il apparaît, est traité exactement de la même façon (un dossier créé à la demande), sans logique ni migration spécifique pour des formats périmés — pas la peine de complexifier le design pour des cas anecdotiques. | 118 | +- **Un dossier de format, créé à la demande** selon ce qui est réellement présent dans le dossier — pas une liste figée à l'avance. `raw/` et `jpeg/` sont les cas les plus courants pour des prises de vue récentes, `tiff/` pour les scans. Un format plus marginal, s'il apparaît, est traité exactement de la même façon (un dossier de format créé à la demande), sans logique ni migration spécifique pour des formats périmés — pas la peine de complexifier le design pour des cas anecdotiques. |
| 114 | - `raw/` est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (`.RAF`, `.CR2`, `.NEF`, `.ARW`...), pas un format unique — contrairement à `jpeg/` et `tiff/`, qui correspondent chacun à une extension précise. | 119 | - `raw/` est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (`.RAF`, `.CR2`, `.NEF`, `.ARW`...), pas un format unique — contrairement à `jpeg/` et `tiff/`, qui correspondent chacun à une extension précise. |
| 115 | -- **Racine du projet** : la sélection, prête à être vue directement (y compris en rouvrant le projet dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF sélectionné. | 120 | +- **Racine du dossier** : la sélection, prête à être vue directement (y compris en rouvrant le dossier dans 10 ans, sans outil spécialisé). Une capture peut avoir son RAW promu à la racine, son JPEG, ou les deux indépendamment — le choix se fait fichier par fichier, pas par paire. Même logique pour un scan TIFF sélectionné. |
| 116 | 121 | ||
| 117 | Ce découpage par format plutôt que par statut (sélection/reste) remplace le dossier "autres" envisagé précédemment : ce qui n'est pas promu à la racine reste simplement dans son dossier de format. | 122 | Ce découpage par format plutôt que par statut (sélection/reste) remplace le dossier "autres" envisagé précédemment : ce qui n'est pas promu à la racine reste simplement dans son dossier de format. |
| 118 | 123 | ||
| 119 | -**Un projet parent est un projet comme les autres, avec sa propre racine.** Un sous-projet (étape d'un voyage) a sa propre structure complète (dossiers de format + sa propre racine, sélection au niveau de l'étape). Le projet parent a en plus sa propre racine à lui, qui sert de planche-contact globale sur l'ensemble du voyage : une photo peut être promue une deuxième fois, de la racine de son étape vers la racine du projet parent, pour apparaître dans cette vue d'ensemble. **Promotion en deux temps** (racine de l'étape, puis racine du voyage), pas un raccourci direct depuis le dossier de format de l'étape — deux gestes distincts, correspondant à deux niveaux de sélection réels (la meilleure photo de l'étape, puis les meilleures du voyage entier). Techniquement, ce deuxième déplacement est un cas de plus couvert par la détection de déplacement par hash déjà en place (section 8), rien de spécifique à construire. | 124 | +**Un dossier parent est un dossier comme les autres, avec sa propre racine.** Un sous-dossier (étape d'un voyage) a sa propre structure complète (dossiers de format + sa propre racine, sélection au niveau de l'étape). Le dossier parent a en plus sa propre racine à lui, qui sert de planche-contact globale sur l'ensemble du voyage : une photo peut être promue une deuxième fois, de la racine de son étape vers la racine du dossier parent, pour apparaître dans cette vue d'ensemble. **Promotion en deux temps** (racine de l'étape, puis racine du voyage), pas un raccourci direct depuis le dossier de format de l'étape — deux gestes distincts, correspondant à deux niveaux de sélection réels (la meilleure photo de l'étape, puis les meilleures du voyage entier). Techniquement, ce deuxième déplacement est un cas de plus couvert par la détection de déplacement par hash déjà en place (section 8), rien de spécifique à construire. |
| 120 | 125 | ||
| 121 | **Cas des scans TIFF** : un scan (négatif, tirage papier) n'a pas de "RAW" à côté — le TIFF est directement le fichier maître au sens de la section 4, à conserver sans jamais le modifier, au même titre qu'un RAW. | 126 | **Cas des scans TIFF** : un scan (négatif, tirage papier) n'a pas de "RAW" à côté — le TIFF est directement le fichier maître au sens de la section 4, à conserver sans jamais le modifier, au même titre qu'un RAW. |
| 122 | 127 | ||
| @@ -129,12 +134,12 @@ L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de | |||
| 129 | - **Déchets évidents** (test d'exposition, déclenchement accidentel, photo des pieds...) : suppression légitime, tous formats compris, avant même le tri par format. Ça ne contredit pas le principe de fichier maître jamais modifié silencieusement (section 4) : la suppression passe par la confirmation explicite déjà prévue à l'étape de réconciliation (section 8) — c'est exactement l'usage prévu de cette étape, pas une entorse à la règle. | 134 | - **Déchets évidents** (test d'exposition, déclenchement accidentel, photo des pieds...) : suppression légitime, tous formats compris, avant même le tri par format. Ça ne contredit pas le principe de fichier maître jamais modifié silencieusement (section 4) : la suppression passe par la confirmation explicite déjà prévue à l'étape de réconciliation (section 8) — c'est exactement l'usage prévu de cette étape, pas une entorse à la règle. |
| 130 | - **Captures correctement prises mais non sélectionnées** (pas les meilleures, ni des déchets) : jamais supprimées ; elles restent simplement dans leur dossier de format, non promues à la racine. | 135 | - **Captures correctement prises mais non sélectionnées** (pas les meilleures, ni des déchets) : jamais supprimées ; elles restent simplement dans leur dossier de format, non promues à la racine. |
| 131 | 136 | ||
| 132 | -**Checkout partiel pour aller vite.** Pour un usage type vacances où la vitesse prime, Régine peut ne faire sortir que le dossier `jpeg/` (et la racine) dans l'espace de travail local, sans le `raw/`, pour un tri/traitement rapide dans l'outil du moment. Les RAW correspondants restent dans l'archive, non modifiés, récupérables séparément si un cas se révèle finalement difficile à traiter. Cette structure par format rend ce checkout partiel immédiat (un dossier entier à exclure), plus simple qu'avec un tri par statut où RAW et JPEG étaient mélangés. **Ce "partiel" porte sur les formats à l'intérieur d'un projet complet, pas sur un sous-projet isolé du reste — cf. section 12, on ne checkout jamais un seul sous-projet sans son projet parent.** | 137 | +**Checkout partiel pour aller vite.** Pour un usage type vacances où la vitesse prime, Régine peut ne faire sortir que le dossier `jpeg/` (et la racine) dans l'espace de travail local, sans le `raw/`, pour un tri/traitement rapide dans l'outil du moment. Les RAW correspondants restent dans l'archive, non modifiés, récupérables séparément si un cas se révèle finalement difficile à traiter. Cette structure par format rend ce checkout partiel immédiat (un dossier entier à exclure), plus simple qu'avec un tri par statut où RAW et JPEG étaient mélangés. **Ce "partiel" porte sur les formats à l'intérieur d'un dossier complet, pas sur un sous-dossier isolé du reste — cf. section 12, on ne checkout jamais un seul sous-dossier sans son dossier parent.** |
| 133 | 138 | ||
| 134 | **Limites observées avec DxO PhotoLab, à corriger dans Régine :** | 139 | **Limites observées avec DxO PhotoLab, à corriger dans Régine :** |
| 135 | 140 | ||
| 136 | - Pas d'association visuelle entre un RAW et son JPEG jumeau (mode RAW+JPEG) : les deux apparaissent comme deux entrées séparées dans la liste, ce qui pousse à en supprimer un juste pour désencombrer l'affichage. Objectif pour Régine : regrouper une paire RAW+JPEG comme une seule entrée à l'écran, même si elles vivent dans des dossiers différents. | 141 | - Pas d'association visuelle entre un RAW et son JPEG jumeau (mode RAW+JPEG) : les deux apparaissent comme deux entrées séparées dans la liste, ce qui pousse à en supprimer un juste pour désencombrer l'affichage. Objectif pour Régine : regrouper une paire RAW+JPEG comme une seule entrée à l'écran, même si elles vivent dans des dossiers différents. |
| 137 | -- Navigation limitée au dossier courant, pas de vue combinée racine + sous-dossiers. Objectif pour Régine : permettre une vue multi-dossiers d'un même projet. | 142 | +- Navigation limitée au dossier courant, pas de vue combinée racine + sous-dossiers. Objectif pour Régine : permettre une vue combinant plusieurs dossiers de format d'un même dossier. |
| 138 | 143 | ||
| 139 | ## 11. Modification des fichiers par les outils d'édition : quand le "fichier maître jamais modifié" tient vraiment | 144 | ## 11. Modification des fichiers par les outils d'édition : quand le "fichier maître jamais modifié" tient vraiment |
| 140 | 145 | ||
| @@ -168,11 +173,11 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r | |||
| 168 | - Fichiers de parité **PAR2** (Parchive) stockés à côté du master : permettent de réparer une corruption partielle sans disposer d'une deuxième copie complète du fichier. | 173 | - Fichiers de parité **PAR2** (Parchive) stockés à côté du master : permettent de réparer une corruption partielle sans disposer d'une deuxième copie complète du fichier. |
| 169 | - Système de fichiers à checksums auto-réparants (**ZFS**, **Btrfs**) avec redondance (miroir/RAID) : détection et réparation automatiques à la lecture, au niveau du NAS plutôt que de l'application. | 174 | - Système de fichiers à checksums auto-réparants (**ZFS**, **Btrfs**) avec redondance (miroir/RAID) : détection et réparation automatiques à la lecture, au niveau du NAS plutôt que de l'application. |
| 170 | 175 | ||
| 171 | -## 12. Manifeste persistant par projet et compatibilité de format entre versions de Régine | 176 | +## 12. Manifeste persistant par dossier et compatibilité de format entre versions de Régine |
| 172 | 177 | ||
| 173 | -Point de départ (2026-09-11) : le manifeste décrit en section 8 n'existait jusqu'ici que comme un instantané pris au moment d'un checkout, recréé à chaque fois plutôt que conservé. Deux besoins poussent à le rendre persistant, stocké en permanence à côté de chaque projet sur le NAS : la vérification périodique (scrub, section 11), qui a besoin d'un état de référence stable dans le temps et pas seulement au moment d'une édition ; et la nécessité qu'une version ancienne de Régine ne puisse pas ouvrir/écrire un projet dont le format a évolué depuis, pour éviter une corruption silencieuse par mécompréhension du format. | 178 | +Point de départ (2026-09-11) : le manifeste décrit en section 8 n'existait jusqu'ici que comme un instantané pris au moment d'un checkout, recréé à chaque fois plutôt que conservé. Deux besoins poussent à le rendre persistant, stocké en permanence à côté de chaque dossier sur le NAS : la vérification périodique (scrub, section 11), qui a besoin d'un état de référence stable dans le temps et pas seulement au moment d'une édition ; et la nécessité qu'une version ancienne de Régine ne puisse pas ouvrir/écrire un dossier dont le format a évolué depuis, pour éviter une corruption silencieuse par mécompréhension du format. |
| 174 | 179 | ||
| 175 | -**Choix de format : SQLite plutôt qu'un fichier JSON pour les checksums.** Un JSON plat contenant les checksums de tout un projet (potentiellement des milliers de fichiers) et réécrit intégralement à chaque réconciliation est vulnérable à une coupure (crash, perte d'alimentation) en plein milieu de l'écriture — un comble pour un mécanisme censé protéger contre la corruption. SQLite écrit de façon transactionnelle : pas d'état intermédiaire corrompu possible. C'est aussi cohérent avec le principe de section 4 ("formats ouverts et documentés plutôt que propriétaires") : la Bibliothèque du Congrès américaine recommande explicitement SQLite comme format de stockage pour l'archivage à long terme (déclaration 2025-2026), et SQLite lui-même documente son usage comme format de fichier applicatif à part entière (transactions, requêtes indexées, un seul fichier auto-suffisant). | 180 | +**Choix de format : SQLite plutôt qu'un fichier JSON pour les checksums.** Un JSON plat contenant les checksums de tout un dossier (potentiellement des milliers de fichiers) et réécrit intégralement à chaque réconciliation est vulnérable à une coupure (crash, perte d'alimentation) en plein milieu de l'écriture — un comble pour un mécanisme censé protéger contre la corruption. SQLite écrit de façon transactionnelle : pas d'état intermédiaire corrompu possible. C'est aussi cohérent avec le principe de section 4 ("formats ouverts et documentés plutôt que propriétaires") : la Bibliothèque du Congrès américaine recommande explicitement SQLite comme format de stockage pour l'archivage à long terme (déclaration 2025-2026), et SQLite lui-même documente son usage comme format de fichier applicatif à part entière (transactions, requêtes indexées, un seul fichier auto-suffisant). |
| 176 | 181 | ||
| 177 | **La version de format doit vivre dans la base elle-même, pas dans un fichier séparé.** SQLite prévoit exactement ce besoin avec deux pragmas intégrés à l'en-tête du fichier : | 182 | **La version de format doit vivre dans la base elle-même, pas dans un fichier séparé.** SQLite prévoit exactement ce besoin avec deux pragmas intégrés à l'en-tête du fichier : |
| 178 | 183 | ||
| @@ -184,36 +189,36 @@ L'intérêt sur un fichier de version séparé (l'idée initiale d'un `Regine.js | |||
| 184 | **Version d'appli vs version de format : deux choses différentes à ne pas confondre.** La version de Régine (numéro de release, change souvent) ne doit pas être le critère de compatibilité — la plupart des mises à jour de l'appli ne toucheront jamais la structure des données sur disque. Le critère doit porter sur un numéro de format qui n'augmente que lorsque la structure change réellement, avec deux niveaux de gravité (à la manière de `core.repositoryformatversion` dans Git, qui bloque uniquement sur les extensions de format inconnues, ou du versionnage interne de SQLite) : | 189 | **Version d'appli vs version de format : deux choses différentes à ne pas confondre.** La version de Régine (numéro de release, change souvent) ne doit pas être le critère de compatibilité — la plupart des mises à jour de l'appli ne toucheront jamais la structure des données sur disque. Le critère doit porter sur un numéro de format qui n'augmente que lorsque la structure change réellement, avec deux niveaux de gravité (à la manière de `core.repositoryformatversion` dans Git, qui bloque uniquement sur les extensions de format inconnues, ou du versionnage interne de SQLite) : |
| 185 | 190 | ||
| 186 | - changement additif (nouveau champ optionnel) → une version plus ancienne de Régine peut l'ignorer et continuer à fonctionner normalement ; | 191 | - changement additif (nouveau champ optionnel) → une version plus ancienne de Régine peut l'ignorer et continuer à fonctionner normalement ; |
| 187 | -- changement structurel (renommage, suppression, changement de sens d'un champ, nouvel algorithme de hash) → refus explicite d'ouvrir le projet avec une version de Régine trop ancienne, plutôt qu'une mauvaise interprétation silencieuse. | 192 | +- changement structurel (renommage, suppression, changement de sens d'un champ, nouvel algorithme de hash) → refus explicite d'ouvrir le dossier avec une version de Régine trop ancienne, plutôt qu'une mauvaise interprétation silencieuse. |
| 188 | 193 | ||
| 189 | -**Migration à anticiper dès la conception, même sans l'implémenter tout de suite.** Le jour où un changement structurel impose ce refus, il faut qu'une version récente de Régine sache mettre à niveau un projet ancien en place. Sans ça, un projet ancien devient lisible par une seule version précise de l'appli — contraire à l'objectif d'archivage long terme de tout le projet. | 194 | +**Migration à anticiper dès la conception, même sans l'implémenter tout de suite.** Le jour où un changement structurel impose ce refus, il faut qu'une version récente de Régine sache mettre à niveau un dossier ancien en place. Sans ça, un dossier ancien devient lisible par une seule version précise de l'appli — contraire à l'objectif d'archivage long terme de tout le projet. |
| 190 | 195 | ||
| 191 | -**Portée retenue : une base SQLite unique à la racine du projet principal, couvrant aussi ses sous-projets.** Révision du 2026-09-11 par rapport à la première version de cette section (qui proposait une base par sous-projet, composée à la demande via `ATTACH DATABASE`) : cette première version reposait sur deux hypothèses que Fabien a corrigées entre-temps — | 196 | +**Portée retenue : une base SQLite unique à la racine du dossier principal, couvrant aussi ses sous-dossiers.** Révision du 2026-09-11 par rapport à la première version de cette section (qui proposait une base par sous-dossier, composée à la demande via `ATTACH DATABASE`) : cette première version reposait sur deux hypothèses que Fabien a corrigées entre-temps — |
| 192 | 197 | ||
| 193 | -- un sous-projet n'est **jamais checké out isolément** : c'est le projet global (parent + sous-projets) qui constitue l'unité de gestion, pas chaque étape individuellement (cf. sections 8 et 10) ; | 198 | +- un sous-dossier n'est **jamais checké out isolément** : c'est le dossier global (parent + sous-dossiers) qui constitue l'unité de gestion, pas chaque étape individuellement (cf. sections 8 et 10) ; |
| 194 | -- **le travail à plusieurs (verrouillage fin par sous-projet pour permettre l'édition concurrente de deux étapes) est mis de côté pour le moment**, ce qui retire l'argument principal en faveur de bases séparées. | 199 | +- **le travail à plusieurs (verrouillage fin par sous-dossier pour permettre l'édition concurrente de deux étapes) est mis de côté pour le moment**, ce qui retire l'argument principal en faveur de bases séparées. |
| 195 | 200 | ||
| 196 | -Avec ces deux précisions, une base unique par projet (le projet parent, sous-projets inclus) est le choix le plus simple et le plus cohérent, pour deux raisons supplémentaires : | 201 | +Avec ces deux précisions, une base unique par dossier (le dossier parent, sous-dossiers inclus) est le choix le plus simple et le plus cohérent, pour deux raisons supplémentaires : |
| 197 | 202 | ||
| 198 | -- Le projet parent a sa propre racine, qui sert de planche-contact globale sur l'ensemble du voyage (section 10) : promouvoir une photo de la racine d'une étape vers la racine du projet parent est alors un déplacement de plus, couvert nativement par la détection de renommage/déplacement par hash déjà en place (section 8) — sans base séparée, pas besoin de gérer une transition d'une base à l'autre pour ce geste. | 203 | +- Le dossier parent a sa propre racine, qui sert de planche-contact globale sur l'ensemble du voyage (section 10) : promouvoir une photo de la racine d'une étape vers la racine du dossier parent est alors un déplacement de plus, couvert nativement par la détection de renommage/déplacement par hash déjà en place (section 8) — sans base séparée, pas besoin de gérer une transition d'une base à l'autre pour ce geste. |
| 199 | -- Fusionner les checksums d'un projet devenu sous-projet (section 9) dans la base de son nouveau parent reste une opération bon marché avec SQLite (`ATTACH` de l'ancienne base, `INSERT ... SELECT`, suppression de l'ancien fichier) — un coût ponctuel et transactionnel, pas une migration fragile. | 204 | +- Fusionner les checksums d'un dossier devenu sous-dossier (section 9) dans la base de son nouveau parent reste une opération bon marché avec SQLite (`ATTACH` de l'ancienne base, `INSERT ... SELECT`, suppression de l'ancien fichier) — un coût ponctuel et transactionnel, pas une migration fragile. |
| 200 | 205 | ||
| 201 | -La suggestion `ATTACH DATABASE` pour composer plusieurs bases à la demande devient donc inutile dans ce modèle — un seul fichier à interroger. Si le travail à plusieurs est repris plus tard, la question du verrouillage par sous-projet (plutôt que par projet entier) sera à rouvrir à ce moment-là ; ce n'est pas un renoncement définitif, juste une simplification volontaire pour l'instant. | 206 | +La suggestion `ATTACH DATABASE` pour composer plusieurs bases à la demande devient donc inutile dans ce modèle — un seul fichier à interroger. Si le travail à plusieurs est repris plus tard, la question du verrouillage par sous-dossier (plutôt que par dossier entier) sera à rouvrir à ce moment-là ; ce n'est pas un renoncement définitif, juste une simplification volontaire pour l'instant. |
| 202 | 207 | ||
| 203 | -**Un petit fichier JSON complémentaire reste utile, mais avec un rôle différent** : pas les checksums, une simple fiche d'identité du projet lisible sans outil (nom, identifiant pérenne, date de création, copie du numéro de format pour un coup d'œil rapide sans ouvrir la base SQLite). À écrire selon la même discipline que tout fichier qui ne doit jamais être observé à moitié écrit : écriture dans un fichier temporaire puis renommage atomique, plutôt que réécriture directe du fichier final. | 208 | +**Un petit fichier JSON complémentaire reste utile, mais avec un rôle différent** : pas les checksums, une simple fiche d'identité du dossier lisible sans outil (nom, identifiant pérenne, date de création, copie du numéro de format pour un coup d'œil rapide sans ouvrir la base SQLite). À écrire selon la même discipline que tout fichier qui ne doit jamais être observé à moitié écrit : écriture dans un fichier temporaire puis renommage atomique, plutôt que réécriture directe du fichier final. |
| 204 | 209 | ||
| 205 | -**Un sous-projet garde sa propre base, elle ne fusionne pas dans celle du parent — voir la portée révisée plus haut dans cette section.** | 210 | +**Un sous-dossier garde sa propre base, elle ne fusionne pas dans celle du parent — voir la portée révisée plus haut dans cette section.** |
| 206 | 211 | ||
| 207 | -## 13. Copie inter-projets pour composer un nouveau projet (livre, sélection thématique) | 212 | +## 13. Copie inter-dossiers pour composer un nouveau projet (livre, sélection thématique) |
| 208 | 213 | ||
| 209 | -Point de départ (2026-09-11) : au-delà du "Bestof" évoqué comme exemple, le cas général est de piocher dans l'archive pour composer un nouveau projet autonome (un livre, une expo) en **copiant** les fichiers choisis depuis leurs projets d'origine, plutôt qu'en les déplaçant ou en les référençant. Confirmé : ces projets restent des projets séparés et indépendants, pas rattachés les uns aux autres par une hiérarchie parent/sous-projet — le livre est son propre projet. | 214 | +Point de départ (2026-09-11) : au-delà du "Bestof" évoqué comme exemple, le cas général est de piocher dans l'archive pour composer un nouveau projet autonome (un livre, une expo) en **copiant** les fichiers choisis depuis leurs dossiers d'origine, plutôt qu'en les déplaçant ou en les référençant. Confirmé : ces projets restent des projets séparés et indépendants, pas rattachés les uns aux autres par une hiérarchie parent/sous-dossier — le livre est son propre projet. |
| 210 | 215 | ||
| 211 | **Pourquoi la copie plutôt qu'une référence (lien symbolique, lien physique) :** | 216 | **Pourquoi la copie plutôt qu'une référence (lien symbolique, lien physique) :** |
| 212 | 217 | ||
| 213 | -- La détection de déplacement par hash (section 8) ne fonctionne qu'à l'intérieur d'un seul projet, entre sa copie de travail et son propre manifeste — elle n'a jamais été prévue pour repérer un fichier traversant deux projets différents. Une référence entre projets ne serait donc de toute façon suivie par aucun mécanisme existant. | 218 | +- La détection de déplacement par hash (section 8) ne fonctionne qu'à l'intérieur d'un seul dossier, entre sa copie de travail et son propre manifeste — elle n'a jamais été prévue pour repérer un fichier traversant deux dossiers différents. Une référence entre dossiers ne serait donc de toute façon suivie par aucun mécanisme existant. |
| 214 | -- Un lien symbolique casse le principe d'auto-suffisance des projets (section 10/12) : il pointe dans le vide si le projet source est déplacé ou renommé. | 219 | +- Un lien symbolique casse le principe d'auto-suffisance des dossiers (section 10/12) : il pointe dans le vide si le dossier source est déplacé ou renommé. |
| 215 | - Un lien physique (hardlink) semble économiser l'espace disque, mais défait justement l'objectif recherché : les deux entrées pointant sur les mêmes octets, modifier les métadonnées de l'original dans DxO changerait aussi silencieusement la copie dans le nouveau projet. | 220 | - Un lien physique (hardlink) semble économiser l'espace disque, mais défait justement l'objectif recherché : les deux entrées pointant sur les mêmes octets, modifier les métadonnées de l'original dans DxO changerait aussi silencieusement la copie dans le nouveau projet. |
| 216 | -- Une vraie copie physique reste cohérente avec le principe déjà posé : chaque projet doit rester lisible et autonome, y compris sans les autres projets présents à côté. | 221 | +- Une vraie copie physique reste cohérente avec le principe déjà posé : chaque dossier doit rester lisible et autonome, y compris sans les autres dossiers présents à côté. |
| 217 | 222 | ||
| 218 | **Le checksum reste un lien valable indéfiniment pour retrouver un fichier maître copié — correction du 2026-09-11 par rapport à la première version de cette section.** Cette première version affirmait qu'une "vraie retouche" (recadrage, étalonnage) pour le travail de cohérence du livre change les pixels et donc le checksum, ne laissant que l'identifiant pérenne comme lien fiable. C'était une erreur : le développement RAW est non destructif par nature (section 11) — recadrage, exposition, étalonnage restent des réglages stockés en sidecar (RAW propriétaires, JPEG/TIFF traités en non destructif) ou en métadonnées embarquées (DNG), jamais appliqués aux pixels eux-mêmes. Le fichier maître copié dans le projet livre garde donc son contenu image intact quel que soit le travail de cohérence effectué dessus, tant que ce travail reste non destructif — ce qui est déjà la règle partout ailleurs dans l'archive, pas une exception ici. Concrètement : | 223 | **Le checksum reste un lien valable indéfiniment pour retrouver un fichier maître copié — correction du 2026-09-11 par rapport à la première version de cette section.** Cette première version affirmait qu'une "vraie retouche" (recadrage, étalonnage) pour le travail de cohérence du livre change les pixels et donc le checksum, ne laissant que l'identifiant pérenne comme lien fiable. C'était une erreur : le développement RAW est non destructif par nature (section 11) — recadrage, exposition, étalonnage restent des réglages stockés en sidecar (RAW propriétaires, JPEG/TIFF traités en non destructif) ou en métadonnées embarquées (DNG), jamais appliqués aux pixels eux-mêmes. Le fichier maître copié dans le projet livre garde donc son contenu image intact quel que soit le travail de cohérence effectué dessus, tant que ce travail reste non destructif — ce qui est déjà la règle partout ailleurs dans l'archive, pas une exception ici. Concrètement : |
| 219 | 224 | ||
| @@ -234,8 +239,8 @@ Si DxO renseigne ces champs, Régine n'a pas besoin d'écrire son propre identif | |||
| 234 | 239 | ||
| 235 | **Deux mécanismes à prévoir pour la traçabilité, indépendamment du résultat de cette vérification :** | 240 | **Deux mécanismes à prévoir pour la traçabilité, indépendamment du résultat de cette vérification :** |
| 236 | 241 | ||
| 237 | -- **Fiche de provenance au moment de la copie** : quand Régine effectue la copie (copie vérifiée par checksum, même logique que l'import carte mémoire section 9 point 1, avec la même vérification de collision de nom), elle enregistre directement dans la base du nouveau projet une petite fiche de provenance (projet source, identifiant du fichier, nom d'origine). Traçabilité immédiate dans le cas courant, sans recherche. | 242 | +- **Fiche de provenance au moment de la copie** : quand Régine effectue la copie (copie vérifiée par checksum, même logique que l'import carte mémoire section 9 point 1, avec la même vérification de collision de nom), elle enregistre directement dans la base du nouveau projet une petite fiche de provenance (dossier source, identifiant du fichier, nom d'origine). Traçabilité immédiate dans le cas courant, sans recherche. |
| 238 | -- **Recherche inter-projets par identifiant ou checksum, en dernier recours** : pour le cas où la fiche de provenance serait perdue, ou le fichier retrouvé par un autre biais (y compris un export dérivé). Matérialise concrètement le besoin d'index inter-projets déjà anticipé comme "à construire plus tard" en section 12 (recherche en lecture seule dans l'archive) — un outil qui parcourt les bases SQLite de chaque projet (ou un index reconstruit à partir d'elles) pour localiser un identifiant ou un hash donné. | 243 | +- **Recherche inter-dossiers par identifiant ou checksum, en dernier recours** : pour le cas où la fiche de provenance serait perdue, ou le fichier retrouvé par un autre biais (y compris un export dérivé). Matérialise concrètement le besoin d'index inter-dossiers déjà anticipé comme "à construire plus tard" en section 12 (recherche en lecture seule dans l'archive) — un outil qui parcourt les bases SQLite de chaque dossier (ou un index reconstruit à partir d'elles) pour localiser un identifiant ou un hash donné. |
| 239 | 244 | ||
| 240 | ## Pistes de fonctionnalités pour Régine | 245 | ## Pistes de fonctionnalités pour Régine |
| 241 | 246 | ||
| @@ -247,12 +252,12 @@ Si DxO renseigne ces champs, Régine n'a pas besoin d'écrire son propre identif | |||
| 247 | - Champs de droits/licence par photo ou par lot. | 252 | - Champs de droits/licence par photo ou par lot. |
| 248 | - Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 8. | 253 | - Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 8. |
| 249 | - Profil de boîtiers configurable (déclaré à l'installation, modifiable à tout moment) comme mécanisme principal de désambiguïsation des sources par EXIF `Model`, `BodySerialNumber`/étiquetage manuel gardés en repli pour deux unités identiques du même modèle — cf. section 9, point 6. | 254 | - Profil de boîtiers configurable (déclaré à l'installation, modifiable à tout moment) comme mécanisme principal de désambiguïsation des sources par EXIF `Model`, `BodySerialNumber`/étiquetage manuel gardés en repli pour deux unités identiques du même modèle — cf. section 9, point 6. |
| 250 | -- Import carte mémoire avec quatre destinations possibles à chaque fois (nouveau projet simple, nouveau sous-projet d'un parent existant, fusion dans un projet existant, nouveau projet parent avec sa première étape), recherche des projets candidats en local et dans l'archive, structure voyage (parent `YYYY-MM_Titre` / étapes `YYYY-MM-DD_Titre_Lieu`), et transformation a posteriori d'un projet simple en sous-projet — cf. section 9. | 255 | +- Import carte mémoire avec quatre destinations possibles à chaque fois (nouveau dossier simple, nouveau sous-dossier d'un parent existant, fusion dans un dossier existant, nouveau dossier parent avec sa première étape), recherche des dossiers candidats en local et dans l'archive, structure voyage (parent `YYYY-MM_Titre` / étapes `YYYY-MM-DD_Titre_Lieu`), et transformation a posteriori d'un dossier simple en sous-dossier — cf. section 9. |
| 251 | -- Structure de projet par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, extensible à d'autres formats sans traitement spécifique) avec sélection à la racine (promotion manuelle, par fichier) à deux niveaux pour un projet parent (racine de l'étape, puis racine du voyage comme planche-contact globale), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF — cf. section 10. | 256 | +- Structure de dossier par format créée à la demande (`raw/`, `jpeg/`, `tiff/`, extensible à d'autres formats sans traitement spécifique) avec sélection à la racine (promotion manuelle, par fichier) à deux niveaux pour un dossier parent (racine de l'étape, puis racine du voyage comme planche-contact globale), gérant uniformément prises de vue récentes, collections JPEG anciennes et scans TIFF — cf. section 10. |
| 252 | -- Interface de tri/culling propre à Régine : association visuelle RAW+JPEG même dans des dossiers différents, navigation multi-dossiers d'un même projet, checkout partiel (`jpeg/` seul) pour un tri rapide sans toucher aux RAW archivés, suppression de déchets évidents via la confirmation de réconciliation — cf. section 10. | 257 | +- Interface de tri/culling propre à Régine : association visuelle RAW+JPEG même dans des dossiers différents, navigation combinant plusieurs dossiers de format d'un même dossier, checkout partiel (`jpeg/` seul) pour un tri rapide sans toucher aux RAW archivés, suppression de déchets évidents via la confirmation de réconciliation — cf. section 10. |
| 253 | - Hash d'intégrité à deux niveaux (fichier entier + image-only via ExifTool `ImageDataHash`) pour distinguer édition de métadonnées et vraie corruption sur DNG/TIFF/JPEG, plus une tâche de vérification périodique (scrub) indépendante du checkout — cf. section 11. Ce même hash image-only permet de suivre un DNG par checksum sur la durée, retouche non destructive comprise. | 258 | - Hash d'intégrité à deux niveaux (fichier entier + image-only via ExifTool `ImageDataHash`) pour distinguer édition de métadonnées et vraie corruption sur DNG/TIFF/JPEG, plus une tâche de vérification périodique (scrub) indépendante du checkout — cf. section 11. Ce même hash image-only permet de suivre un DNG par checksum sur la durée, retouche non destructive comprise. |
| 254 | -- Manifeste persistant en base SQLite unique à la racine du projet principal (parent + sous-projets), avec numéro de format via `PRAGMA user_version`/`application_id` distinguant changement additif (toléré par une version ancienne) vs structurel (refus explicite + migration à prévoir) ; checkout et verrou portent sur le projet complet, jamais un sous-projet isolé — le travail à plusieurs (verrouillage fin par sous-projet) est mis de côté pour le moment — cf. section 12. | 259 | +- Manifeste persistant en base SQLite unique à la racine du dossier principal (parent + sous-dossiers), avec numéro de format via `PRAGMA user_version`/`application_id` distinguant changement additif (toléré par une version ancienne) vs structurel (refus explicite + migration à prévoir) ; checkout et verrou portent sur le dossier complet, jamais un sous-dossier isolé — le travail à plusieurs (verrouillage fin par sous-dossier) est mis de côté pour le moment — cf. section 12. |
| 255 | -- Copie vérifiée inter-projets pour composer un nouveau projet (livre, sélection thématique) à partir de l'archive : checksum + nom de fichier suffisent pour retrouver un fichier maître copié (retouche non destructive comprise) ; fiche de provenance enregistrée au moment de la copie et outil de recherche inter-projets en dernier recours, utiles surtout pour le cas résiduel d'un export dérivé — cf. section 13. | 260 | +- Copie vérifiée inter-dossiers pour composer un nouveau projet (livre, sélection thématique) à partir de l'archive : checksum + nom de fichier suffisent pour retrouver un fichier maître copié (retouche non destructive comprise) ; fiche de provenance enregistrée au moment de la copie et outil de recherche inter-dossiers en dernier recours, utiles surtout pour le cas résiduel d'un export dérivé — cf. section 13. |
| 256 | 261 | ||
| 257 | ## Sources | 262 | ## Sources |
| 258 | 263 | ||
modified
docs/interface-agent-ia.md +7 -7 | @@ -4,7 +4,7 @@ Premier draft (2026-09-11). Définit comment un agent IA (assistant conversation | ||
| 4 | 4 | |
| 5 | 5 | ## 1. Position dans l'architecture |
| 6 | 6 | |
| 7 | -L'agent IA est une **quatrième façade** au-dessus de la bibliothèque centrale, au même titre que la CLI et la (future) GUI — pas un système parallèle avec sa propre logique. Il ne réinvente ni la classification des changements à la réconciliation, ni les règles de nommage, ni les critères d'anomalie : il appelle les mêmes modules (`import`, `archive`, `project`, `integrity`, `metadata`, `camera_profile`) et reformule leurs résultats en langage naturel. | |
| 7 | +L'agent IA est une **quatrième façade** au-dessus de la bibliothèque centrale, au même titre que la CLI et la (future) GUI — pas un système parallèle avec sa propre logique. Il ne réinvente ni la classification des changements à la réconciliation, ni les règles de nommage, ni les critères d'anomalie : il appelle les mêmes modules (`import`, `archive`, `dossier`, `integrity`, `metadata`, `camera_profile`) et reformule leurs résultats en langage naturel. | |
| 8 | 8 | |
| 9 | 9 | Conséquence pour la bibliothèque : ses fonctions doivent renvoyer des **objets structurés** (comptes, listes, diffs typés) plutôt que du texte déjà formaté pour un terminal. L'agent construit son résumé à partir de ces données ; il ne doit jamais avoir à parser une sortie texte de la CLI ni à deviner un chiffre. |
| 10 | 10 | |
| @@ -15,7 +15,7 @@ Ce principe existe déjà dans la bibliothèque (section 9 des notes d'archivage | ||
| 15 | 15 | - **Action à risque** (écriture sur l'archive NAS, suppression, restauration, écrasement, tout ce qui modifie l'état persistant) → toujours un point de pause avec résumé clair, puis attente d'une réponse explicite de l'utilisateur avant d'exécuter. |
| 16 | 16 | - **Action sans risque** (recherche, consultation, prévisualisation, comptage) → peut s'exécuter directement ; l'agent rapporte ce qu'il a trouvé, sans demander la permission de chercher. |
| 17 | 17 | |
| 18 | -Ce qui distingue une demande "à risque" d'une demande anodine, c'est la nature de l'opération dans la bibliothèque, pas la formulation de l'utilisateur — une phrase à l'impératif ("crée le projet...") reste soumise à confirmation si elle déclenche une écriture. | |
| 18 | +Ce qui distingue une demande "à risque" d'une demande anodine, c'est la nature de l'opération dans la bibliothèque, pas la formulation de l'utilisateur — une phrase à l'impératif ("crée le dossier...") reste soumise à confirmation si elle déclenche une écriture. | |
| 19 | 19 | |
| 20 | 20 | ## 3. Format de réponse : court, concret, actionnable |
| 21 | 21 | |
| @@ -29,21 +29,21 @@ Pas de jargon technique, pas de rappel des règles de l'architecture, pas de pav | ||
| 29 | 29 | |
| 30 | 30 | ## 4. Cas type 1 : commande de composition/création |
| 31 | 31 | |
| 32 | -Exemple — reprend le cas "Bestof" déjà anticipé en section 14 des notes d'archivage (copie inter-projets pour composer un nouveau projet autonome) : | |
| 32 | +Exemple — reprend le cas "Bestof" déjà anticipé en section 14 des notes d'archivage (copie inter-dossiers pour composer un nouveau projet autonome) : | |
| 33 | 33 | |
| 34 | 34 | > **Utilisateur** : Crée un projet avec les copies des photos 5 étoiles de 2025. |
| 35 | 35 | > |
| 36 | -> **Régine** : Je crée le projet `2025_Best_of` avec les fichiers 5 étoiles de l'année 2025. 47 photos concernées, réparties sur 6 projets sources (voir liste). On y va ? | |
| 36 | +> **Régine** : Je crée le projet `2025_Best_of` avec les fichiers 5 étoiles de l'année 2025. 47 photos concernées, réparties sur 6 dossiers sources (voir liste). On y va ? | |
| 37 | 37 | |
| 38 | -Ce que l'agent fait sous le capot, sans le dire sauf si on lui demande : recherche inter-projets par critère de sélection et date, copie vérifiée par checksum, fiche de provenance enregistrée dans la base du nouveau projet (section 14). L'utilisateur n'a pas besoin de connaître ce mécanisme pour valider la demande — seulement le résultat et son ampleur. | |
| 38 | +Ce que l'agent fait sous le capot, sans le dire sauf si on lui demande : recherche inter-dossiers par critère de sélection et date, copie vérifiée par checksum, fiche de provenance enregistrée dans la base du nouveau projet (section 14). L'utilisateur n'a pas besoin de connaître ce mécanisme pour valider la demande — seulement le résultat et son ampleur. | |
| 39 | 39 | |
| 40 | -Si la liste est longue, l'agent la résume (ex. par projet source) plutôt que d'énumérer 47 noms de fichiers ; le détail complet reste disponible sur demande ("montre-moi la liste complète"). | |
| 40 | +Si la liste est longue, l'agent la résume (ex. par dossier source) plutôt que d'énumérer 47 noms de fichiers ; le détail complet reste disponible sur demande ("montre-moi la liste complète"). | |
| 41 | 41 | |
| 42 | 42 | ## 5. Cas type 2 : anomalie détectée pendant l'archivage |
| 43 | 43 | |
| 44 | 44 | Exemple — reprend le cas de réconciliation anormale (section 9 : "hash RAW/JPEG changé sous le même nom → anomalie... à signaler, jamais archivé silencieusement") : |
| 45 | 45 | |
| 46 | -> **Utilisateur** : Archive le projet XXX. | |
| 46 | +> **Utilisateur** : Archive le dossier XXX. | |
| 47 | 47 | > |
| 48 | 48 | > **Régine** : Archivage de XXX : j'ai détecté des effacements de fichiers maîtres. Ça ne devrait normalement pas arriver. Voici les fichiers concernés — je ne les pousse pas sans votre accord. Deux choix : je confirme la suppression dans l'archive, ou je restaure ces fichiers maîtres depuis l'archive pour remplacer ce qui a disparu en local. Qu'est-ce que je fais ? |
| 49 | 49 | |
| @@ -4,7 +4,7 @@ Premier draft (2026-09-11). Définit comment un agent IA (assistant conversation | |||
| 4 | 4 | ||
| 5 | ## 1. Position dans l'architecture | 5 | ## 1. Position dans l'architecture |
| 6 | 6 | ||
| 7 | -L'agent IA est une **quatrième façade** au-dessus de la bibliothèque centrale, au même titre que la CLI et la (future) GUI — pas un système parallèle avec sa propre logique. Il ne réinvente ni la classification des changements à la réconciliation, ni les règles de nommage, ni les critères d'anomalie : il appelle les mêmes modules (`import`, `archive`, `project`, `integrity`, `metadata`, `camera_profile`) et reformule leurs résultats en langage naturel. | 7 | +L'agent IA est une **quatrième façade** au-dessus de la bibliothèque centrale, au même titre que la CLI et la (future) GUI — pas un système parallèle avec sa propre logique. Il ne réinvente ni la classification des changements à la réconciliation, ni les règles de nommage, ni les critères d'anomalie : il appelle les mêmes modules (`import`, `archive`, `dossier`, `integrity`, `metadata`, `camera_profile`) et reformule leurs résultats en langage naturel. |
| 8 | 8 | ||
| 9 | Conséquence pour la bibliothèque : ses fonctions doivent renvoyer des **objets structurés** (comptes, listes, diffs typés) plutôt que du texte déjà formaté pour un terminal. L'agent construit son résumé à partir de ces données ; il ne doit jamais avoir à parser une sortie texte de la CLI ni à deviner un chiffre. | 9 | Conséquence pour la bibliothèque : ses fonctions doivent renvoyer des **objets structurés** (comptes, listes, diffs typés) plutôt que du texte déjà formaté pour un terminal. L'agent construit son résumé à partir de ces données ; il ne doit jamais avoir à parser une sortie texte de la CLI ni à deviner un chiffre. |
| 10 | 10 | ||
| @@ -15,7 +15,7 @@ Ce principe existe déjà dans la bibliothèque (section 9 des notes d'archivage | |||
| 15 | - **Action à risque** (écriture sur l'archive NAS, suppression, restauration, écrasement, tout ce qui modifie l'état persistant) → toujours un point de pause avec résumé clair, puis attente d'une réponse explicite de l'utilisateur avant d'exécuter. | 15 | - **Action à risque** (écriture sur l'archive NAS, suppression, restauration, écrasement, tout ce qui modifie l'état persistant) → toujours un point de pause avec résumé clair, puis attente d'une réponse explicite de l'utilisateur avant d'exécuter. |
| 16 | - **Action sans risque** (recherche, consultation, prévisualisation, comptage) → peut s'exécuter directement ; l'agent rapporte ce qu'il a trouvé, sans demander la permission de chercher. | 16 | - **Action sans risque** (recherche, consultation, prévisualisation, comptage) → peut s'exécuter directement ; l'agent rapporte ce qu'il a trouvé, sans demander la permission de chercher. |
| 17 | 17 | ||
| 18 | -Ce qui distingue une demande "à risque" d'une demande anodine, c'est la nature de l'opération dans la bibliothèque, pas la formulation de l'utilisateur — une phrase à l'impératif ("crée le projet...") reste soumise à confirmation si elle déclenche une écriture. | 18 | +Ce qui distingue une demande "à risque" d'une demande anodine, c'est la nature de l'opération dans la bibliothèque, pas la formulation de l'utilisateur — une phrase à l'impératif ("crée le dossier...") reste soumise à confirmation si elle déclenche une écriture. |
| 19 | 19 | ||
| 20 | ## 3. Format de réponse : court, concret, actionnable | 20 | ## 3. Format de réponse : court, concret, actionnable |
| 21 | 21 | ||
| @@ -29,21 +29,21 @@ Pas de jargon technique, pas de rappel des règles de l'architecture, pas de pav | |||
| 29 | 29 | ||
| 30 | ## 4. Cas type 1 : commande de composition/création | 30 | ## 4. Cas type 1 : commande de composition/création |
| 31 | 31 | ||
| 32 | -Exemple — reprend le cas "Bestof" déjà anticipé en section 14 des notes d'archivage (copie inter-projets pour composer un nouveau projet autonome) : | 32 | +Exemple — reprend le cas "Bestof" déjà anticipé en section 14 des notes d'archivage (copie inter-dossiers pour composer un nouveau projet autonome) : |
| 33 | 33 | ||
| 34 | > **Utilisateur** : Crée un projet avec les copies des photos 5 étoiles de 2025. | 34 | > **Utilisateur** : Crée un projet avec les copies des photos 5 étoiles de 2025. |
| 35 | > | 35 | > |
| 36 | -> **Régine** : Je crée le projet `2025_Best_of` avec les fichiers 5 étoiles de l'année 2025. 47 photos concernées, réparties sur 6 projets sources (voir liste). On y va ? | 36 | +> **Régine** : Je crée le projet `2025_Best_of` avec les fichiers 5 étoiles de l'année 2025. 47 photos concernées, réparties sur 6 dossiers sources (voir liste). On y va ? |
| 37 | 37 | ||
| 38 | -Ce que l'agent fait sous le capot, sans le dire sauf si on lui demande : recherche inter-projets par critère de sélection et date, copie vérifiée par checksum, fiche de provenance enregistrée dans la base du nouveau projet (section 14). L'utilisateur n'a pas besoin de connaître ce mécanisme pour valider la demande — seulement le résultat et son ampleur. | 38 | +Ce que l'agent fait sous le capot, sans le dire sauf si on lui demande : recherche inter-dossiers par critère de sélection et date, copie vérifiée par checksum, fiche de provenance enregistrée dans la base du nouveau projet (section 14). L'utilisateur n'a pas besoin de connaître ce mécanisme pour valider la demande — seulement le résultat et son ampleur. |
| 39 | 39 | ||
| 40 | -Si la liste est longue, l'agent la résume (ex. par projet source) plutôt que d'énumérer 47 noms de fichiers ; le détail complet reste disponible sur demande ("montre-moi la liste complète"). | 40 | +Si la liste est longue, l'agent la résume (ex. par dossier source) plutôt que d'énumérer 47 noms de fichiers ; le détail complet reste disponible sur demande ("montre-moi la liste complète"). |
| 41 | 41 | ||
| 42 | ## 5. Cas type 2 : anomalie détectée pendant l'archivage | 42 | ## 5. Cas type 2 : anomalie détectée pendant l'archivage |
| 43 | 43 | ||
| 44 | Exemple — reprend le cas de réconciliation anormale (section 9 : "hash RAW/JPEG changé sous le même nom → anomalie... à signaler, jamais archivé silencieusement") : | 44 | Exemple — reprend le cas de réconciliation anormale (section 9 : "hash RAW/JPEG changé sous le même nom → anomalie... à signaler, jamais archivé silencieusement") : |
| 45 | 45 | ||
| 46 | -> **Utilisateur** : Archive le projet XXX. | 46 | +> **Utilisateur** : Archive le dossier XXX. |
| 47 | > | 47 | > |
| 48 | > **Régine** : Archivage de XXX : j'ai détecté des effacements de fichiers maîtres. Ça ne devrait normalement pas arriver. Voici les fichiers concernés — je ne les pousse pas sans votre accord. Deux choix : je confirme la suppression dans l'archive, ou je restaure ces fichiers maîtres depuis l'archive pour remplacer ce qui a disparu en local. Qu'est-ce que je fais ? | 48 | > **Régine** : Archivage de XXX : j'ai détecté des effacements de fichiers maîtres. Ça ne devrait normalement pas arriver. Voici les fichiers concernés — je ne les pousse pas sans votre accord. Deux choix : je confirme la suppression dans l'archive, ou je restaure ces fichiers maîtres depuis l'archive pour remplacer ce qui a disparu en local. Qu'est-ce que je fais ? |
| 49 | 49 | ||
modified
docs/interface-cli-gui-architecture.md +7 -7 | @@ -4,23 +4,23 @@ Notes de conception sur la façon dont la logique métier de Régine (décrite d | ||
| 4 | 4 | |
| 5 | 5 | ## Principe général |
| 6 | 6 | |
| 7 | -Une bibliothèque centrale porte toute la logique métier : import carte mémoire, checkout/réconciliation, structure de projet, métadonnées, intégrité. La CLI et l'interface graphique (GUI) sont deux façades minces au-dessus de cette bibliothèque, sans logique métier dupliquée de leur côté — chacune se contente d'appeler la bibliothèque et d'afficher/formatter le résultat. | |
| 7 | +Une bibliothèque centrale porte toute la logique métier : import carte mémoire, checkout/réconciliation, structure de dossier, métadonnées, intégrité. La CLI et l'interface graphique (GUI) sont deux façades minces au-dessus de cette bibliothèque, sans logique métier dupliquée de leur côté — chacune se contente d'appeler la bibliothèque et d'afficher/formatter le résultat. | |
| 8 | 8 | |
| 9 | -Justification : les enchaînements décrits dans les notes de conception (les quatre destinations possibles d'un import carte mémoire, la classification des changements à la réconciliation, la structure de projet par format) sont des séquences de décisions, pas de simples opérations CRUD. Les garder dans une seule bibliothèque évite que CLI et GUI divergent sur leur comportement. | |
| 9 | +Justification : les enchaînements décrits dans les notes de conception (les quatre destinations possibles d'un import carte mémoire, la classification des changements à la réconciliation, la structure de dossier par format) sont des séquences de décisions, pas de simples opérations CRUD. Les garder dans une seule bibliothèque évite que CLI et GUI divergent sur leur comportement. | |
| 10 | 10 | |
| 11 | 11 | ## Décisions actées |
| 12 | 12 | |
| 13 | 13 | - **Langage de la bibliothèque : Python.** Écosystème riche pour EXIF/IPTC/XMP (exiftool, pillow) et pour l'extraction d'aperçus RAW (rawpy), développement rapide, bien outillé pour ce domaine. |
| 14 | 14 | - **Mode d'exposition : import direct, un seul processus par lancement.** La CLI et la GUI importent la bibliothèque comme du code, chacune dans son propre processus à chaque exécution — pas de service/daemon permanent à installer, gérer ou superviser. |
| 15 | -- **Concurrence multi-instances : déjà couverte, pas de mécanisme supplémentaire à construire.** La section 9 des notes de conception (workflow checkout/réconciliation) prévoit déjà un verrou/marqueur côté NAS pendant qu'un projet est "checké out", justement pour éviter que deux instances de Régine modifient le même projet en parallèle. Ce verrou remplit le rôle qu'un daemon central aurait pu jouer, sans en avoir la complexité de déploiement. | |
| 15 | +- **Concurrence multi-instances : déjà couverte, pas de mécanisme supplémentaire à construire.** La section 9 des notes de conception (workflow checkout/réconciliation) prévoit déjà un verrou/marqueur côté NAS pendant qu'un dossier est "checké out", justement pour éviter que deux instances de Régine modifient le même dossier en parallèle. Ce verrou remplit le rôle qu'un daemon central aurait pu jouer, sans en avoir la complexité de déploiement. | |
| 16 | 16 | |
| 17 | 17 | ## GUI : reportée, mais cadrée |
| 18 | 18 | |
| 19 | 19 | La GUI n'est pas construite dans l'immédiat, mais deux modes d'usage ont été identifiés pour la suite : |
| 20 | 20 | |
| 21 | -1. **Tri/culling pendant l'édition** — sur un projet checké out en local : visualiser les photos, les sélectionner (promotion à la racine du projet). Deux limites observées avec DxO PhotoLab (section 11 des notes de conception) sont explicitement à corriger dans cette interface : l'absence d'association visuelle entre un RAW et son JPEG jumeau (à regrouper comme une seule entrée à l'écran même s'ils vivent dans des dossiers différents), et la navigation limitée au dossier courant (à remplacer par une vue combinée racine + sous-dossiers d'un même projet). | |
| 21 | +1. **Tri/culling pendant l'édition** — sur un dossier checké out en local : visualiser les photos, les sélectionner (promotion à la racine du dossier). Deux limites observées avec DxO PhotoLab (section 11 des notes de conception) sont explicitement à corriger dans cette interface : l'absence d'association visuelle entre un RAW et son JPEG jumeau (à regrouper comme une seule entrée à l'écran même s'ils vivent dans des dossiers différents), et la navigation limitée au dossier courant (à remplacer par une vue combinée racine + sous-dossiers au sein d'un même dossier). | |
| 22 | 22 | |
| 23 | -2. **Consultation en lecture seule de l'archive** — parcourir l'archive sur le NAS sans passer par un checkout complet, typiquement pour retrouver et restaurer un fichier précis (ex. un RAW supprimé par erreur). Ce mode s'apparente à un navigateur/visualiseur au-dessus de l'archive, avec recherche (projet, date, texte) et une action de restauration vers un emplacement local — plus léger qu'un aller-retour complet avec manifeste et réconciliation. | |
| 23 | +2. **Consultation en lecture seule de l'archive** — parcourir l'archive sur le NAS sans passer par un checkout complet, typiquement pour retrouver et restaurer un fichier précis (ex. un RAW supprimé par erreur). Ce mode s'apparente à un navigateur/visualiseur au-dessus de l'archive, avec recherche (dossier, date, texte) et une action de restauration vers un emplacement local — plus léger qu'un aller-retour complet avec manifeste et réconciliation. | |
| 24 | 24 | |
| 25 | 25 | ### Options techniques discutées pour la GUI (non tranchées) |
| 26 | 26 | |
| @@ -37,8 +37,8 @@ Poser les frontières de modules de la bibliothèque, dont la CLI et la (future) | ||
| 37 | 37 | |
| 38 | 38 | - `metadata` — lecture/écriture IPTC/XMP/EXIF. |
| 39 | 39 | - `archive` — manifeste, hash, checkout/réconciliation. |
| 40 | -- `import` — carte mémoire → projet. | |
| 41 | -- `project` — structure par format, sélection/promotion à la racine. | |
| 40 | +- `import` — carte mémoire → dossier. | |
| 41 | +- `dossier` — structure par format, sélection/promotion à la racine. | |
| 42 | 42 | - `integrity` — hash à deux niveaux (fichier entier + image-only), scrub périodique. |
| 43 | 43 | - `camera_profile` — profil de boîtiers déclaré par l'utilisateur, désambiguïsation des sources à l'import. |
| 44 | 44 | |
| @@ -4,23 +4,23 @@ Notes de conception sur la façon dont la logique métier de Régine (décrite d | |||
| 4 | 4 | ||
| 5 | ## Principe général | 5 | ## Principe général |
| 6 | 6 | ||
| 7 | -Une bibliothèque centrale porte toute la logique métier : import carte mémoire, checkout/réconciliation, structure de projet, métadonnées, intégrité. La CLI et l'interface graphique (GUI) sont deux façades minces au-dessus de cette bibliothèque, sans logique métier dupliquée de leur côté — chacune se contente d'appeler la bibliothèque et d'afficher/formatter le résultat. | 7 | +Une bibliothèque centrale porte toute la logique métier : import carte mémoire, checkout/réconciliation, structure de dossier, métadonnées, intégrité. La CLI et l'interface graphique (GUI) sont deux façades minces au-dessus de cette bibliothèque, sans logique métier dupliquée de leur côté — chacune se contente d'appeler la bibliothèque et d'afficher/formatter le résultat. |
| 8 | 8 | ||
| 9 | -Justification : les enchaînements décrits dans les notes de conception (les quatre destinations possibles d'un import carte mémoire, la classification des changements à la réconciliation, la structure de projet par format) sont des séquences de décisions, pas de simples opérations CRUD. Les garder dans une seule bibliothèque évite que CLI et GUI divergent sur leur comportement. | 9 | +Justification : les enchaînements décrits dans les notes de conception (les quatre destinations possibles d'un import carte mémoire, la classification des changements à la réconciliation, la structure de dossier par format) sont des séquences de décisions, pas de simples opérations CRUD. Les garder dans une seule bibliothèque évite que CLI et GUI divergent sur leur comportement. |
| 10 | 10 | ||
| 11 | ## Décisions actées | 11 | ## Décisions actées |
| 12 | 12 | ||
| 13 | - **Langage de la bibliothèque : Python.** Écosystème riche pour EXIF/IPTC/XMP (exiftool, pillow) et pour l'extraction d'aperçus RAW (rawpy), développement rapide, bien outillé pour ce domaine. | 13 | - **Langage de la bibliothèque : Python.** Écosystème riche pour EXIF/IPTC/XMP (exiftool, pillow) et pour l'extraction d'aperçus RAW (rawpy), développement rapide, bien outillé pour ce domaine. |
| 14 | - **Mode d'exposition : import direct, un seul processus par lancement.** La CLI et la GUI importent la bibliothèque comme du code, chacune dans son propre processus à chaque exécution — pas de service/daemon permanent à installer, gérer ou superviser. | 14 | - **Mode d'exposition : import direct, un seul processus par lancement.** La CLI et la GUI importent la bibliothèque comme du code, chacune dans son propre processus à chaque exécution — pas de service/daemon permanent à installer, gérer ou superviser. |
| 15 | -- **Concurrence multi-instances : déjà couverte, pas de mécanisme supplémentaire à construire.** La section 9 des notes de conception (workflow checkout/réconciliation) prévoit déjà un verrou/marqueur côté NAS pendant qu'un projet est "checké out", justement pour éviter que deux instances de Régine modifient le même projet en parallèle. Ce verrou remplit le rôle qu'un daemon central aurait pu jouer, sans en avoir la complexité de déploiement. | 15 | +- **Concurrence multi-instances : déjà couverte, pas de mécanisme supplémentaire à construire.** La section 9 des notes de conception (workflow checkout/réconciliation) prévoit déjà un verrou/marqueur côté NAS pendant qu'un dossier est "checké out", justement pour éviter que deux instances de Régine modifient le même dossier en parallèle. Ce verrou remplit le rôle qu'un daemon central aurait pu jouer, sans en avoir la complexité de déploiement. |
| 16 | 16 | ||
| 17 | ## GUI : reportée, mais cadrée | 17 | ## GUI : reportée, mais cadrée |
| 18 | 18 | ||
| 19 | La GUI n'est pas construite dans l'immédiat, mais deux modes d'usage ont été identifiés pour la suite : | 19 | La GUI n'est pas construite dans l'immédiat, mais deux modes d'usage ont été identifiés pour la suite : |
| 20 | 20 | ||
| 21 | -1. **Tri/culling pendant l'édition** — sur un projet checké out en local : visualiser les photos, les sélectionner (promotion à la racine du projet). Deux limites observées avec DxO PhotoLab (section 11 des notes de conception) sont explicitement à corriger dans cette interface : l'absence d'association visuelle entre un RAW et son JPEG jumeau (à regrouper comme une seule entrée à l'écran même s'ils vivent dans des dossiers différents), et la navigation limitée au dossier courant (à remplacer par une vue combinée racine + sous-dossiers d'un même projet). | 21 | +1. **Tri/culling pendant l'édition** — sur un dossier checké out en local : visualiser les photos, les sélectionner (promotion à la racine du dossier). Deux limites observées avec DxO PhotoLab (section 11 des notes de conception) sont explicitement à corriger dans cette interface : l'absence d'association visuelle entre un RAW et son JPEG jumeau (à regrouper comme une seule entrée à l'écran même s'ils vivent dans des dossiers différents), et la navigation limitée au dossier courant (à remplacer par une vue combinée racine + sous-dossiers au sein d'un même dossier). |
| 22 | 22 | ||
| 23 | -2. **Consultation en lecture seule de l'archive** — parcourir l'archive sur le NAS sans passer par un checkout complet, typiquement pour retrouver et restaurer un fichier précis (ex. un RAW supprimé par erreur). Ce mode s'apparente à un navigateur/visualiseur au-dessus de l'archive, avec recherche (projet, date, texte) et une action de restauration vers un emplacement local — plus léger qu'un aller-retour complet avec manifeste et réconciliation. | 23 | +2. **Consultation en lecture seule de l'archive** — parcourir l'archive sur le NAS sans passer par un checkout complet, typiquement pour retrouver et restaurer un fichier précis (ex. un RAW supprimé par erreur). Ce mode s'apparente à un navigateur/visualiseur au-dessus de l'archive, avec recherche (dossier, date, texte) et une action de restauration vers un emplacement local — plus léger qu'un aller-retour complet avec manifeste et réconciliation. |
| 24 | 24 | ||
| 25 | ### Options techniques discutées pour la GUI (non tranchées) | 25 | ### Options techniques discutées pour la GUI (non tranchées) |
| 26 | 26 | ||
| @@ -37,8 +37,8 @@ Poser les frontières de modules de la bibliothèque, dont la CLI et la (future) | |||
| 37 | 37 | ||
| 38 | - `metadata` — lecture/écriture IPTC/XMP/EXIF. | 38 | - `metadata` — lecture/écriture IPTC/XMP/EXIF. |
| 39 | - `archive` — manifeste, hash, checkout/réconciliation. | 39 | - `archive` — manifeste, hash, checkout/réconciliation. |
| 40 | -- `import` — carte mémoire → projet. | 40 | +- `import` — carte mémoire → dossier. |
| 41 | -- `project` — structure par format, sélection/promotion à la racine. | 41 | +- `dossier` — structure par format, sélection/promotion à la racine. |
| 42 | - `integrity` — hash à deux niveaux (fichier entier + image-only), scrub périodique. | 42 | - `integrity` — hash à deux niveaux (fichier entier + image-only), scrub périodique. |
| 43 | - `camera_profile` — profil de boîtiers déclaré par l'utilisateur, désambiguïsation des sources à l'import. | 43 | - `camera_profile` — profil de boîtiers déclaré par l'utilisateur, désambiguïsation des sources à l'import. |
| 44 | 44 | ||
added
docs/lexique.md +78 -0 | new file mode 100644 | ||
| @@ -0,0 +1,78 @@ | ||
| 1 | +# Lexique Régine | |
| 2 | + | |
| 3 | +Référence terminologique pour tous les docs du projet : ce que chaque terme désigne, pour éviter les ambiguïtés entre docs et dans le temps. Tout nouveau terme structurant introduit dans un doc devrait être répercuté ici. | |
| 4 | + | |
| 5 | +## 1. Les quatre termes à ne pas confondre : dossier, sous-dossier, dossier parent, projet | |
| 6 | + | |
| 7 | +C'est la distinction la plus importante du lexique — deux familles de concepts qui se ressemblent mais ne se recouvrent pas. | |
| 8 | + | |
| 9 | +| Terme | Définition | | |
| 10 | +|---|---| | |
| 11 | +| **dossier** | Unité créée à l'import d'une carte mémoire (import carte mémoire → archivage/NAS). Structure interne par format (`raw/`, `jpeg/`, `tiff/`...) + racine de sélection. C'est l'unité de checkout/réconciliation et de verrouillage. | | |
| 12 | +| **sous-dossier** | Étape d'un dossier multi-parties (ex. une ville dans un voyage). A sa propre structure complète (dossiers de format + racine). Ne se checkout jamais isolément — toujours via son dossier parent. | | |
| 13 | +| **dossier parent** | Dossier englobant plusieurs sous-dossiers. A sa propre racine, qui sert de planche-contact globale sur l'ensemble (ex. les meilleures photos de tout le voyage, pas juste d'une étape). | | |
| 14 | +| **projet** | Répertoire de travail **séparé**, composé par **copie** de fichiers piochés dans un ou plusieurs dossiers de l'archive, pour un usage autonome (livre, expo, sélection thématique). Ne fait pas partie de la hiérarchie dossier / sous-dossier / dossier parent — c'est un objet en aval, indépendant. Chaque fichier copié est traçable vers son dossier d'origine via une **fiche de provenance**. | | |
| 15 | + | |
| 16 | +À retenir : **dossier** = comment les photos arrivent et sont archivées (immuable, structure de l'archive). **projet** = ce qu'on en fait ensuite pour produire quelque chose (mutable, composé par copie, ne touche jamais l'archive). | |
| 17 | + | |
| 18 | +**Piste ouverte, non tranchée** : à terme, un projet pourrait ne conserver que les fichiers dérivés générés (JPEG, PDF) sans garder les copies RAW ayant servi à les produire — à trancher plus tard, voir `archivage-photo-elements-cles.md` section 13. | |
| 19 | + | |
| 20 | +**Point de vigilance** : le mot "dossier" désigne aussi, dans les docs, les sous-répertoires par format à l'intérieur d'une unité (`raw/`, `jpeg/`, `tiff/` — appelés "dossier de format"). Il porte donc deux niveaux de sens selon le contexte : le dossier Régine dans son ensemble, ou un dossier de format à l'intérieur. Désambiguïsé par le contexte partout où ça apparaît, mais à garder en tête en écrivant. | |
| 21 | + | |
| 22 | +## 2. Structure et sélection | |
| 23 | + | |
| 24 | +- **dossier de format** — sous-répertoire créé à la demande selon les formats réellement présents (`raw/`, `jpeg/`, `tiff/`...). `raw/` est une catégorie fonctionnelle regroupant toutes les extensions RAW, pas une extension unique. | |
| 25 | +- **racine** — niveau (du dossier, du sous-dossier, ou du dossier parent) où vivent les fichiers sélectionnés/promus, prêt à être consulté directement sans outil. | |
| 26 | +- **promotion** — action de faire remonter un fichier vers une racine. En deux temps pour un dossier parent : racine du sous-dossier d'abord, puis racine du dossier parent (planche-contact globale). | |
| 27 | +- **fiche de provenance** — enregistrement créé au moment de la copie vers un projet : dossier source, identifiant pérenne du fichier, nom d'origine. | |
| 28 | + | |
| 29 | +## 3. Fichiers et intégrité | |
| 30 | + | |
| 31 | +- **fichier maître** — défini par son rôle, pas par son format : le fichier faisant autorité pour une capture, à conserver indéfiniment sans le modifier. RAW ou TIFF non compressé par défaut, mais aussi un JPEG quand c'est le seul fichier produit par l'appareil, ou même en mode RAW+JPEG quand le photographe juge le JPEG satisfaisant et ne garde le RAW que pour un usage secondaire (précisé le 2026-09-18, voir `archivage-photo-elements-cles.md` section 4). | |
| 32 | +- **dérivé** — export de diffusion (JPEG, versions web, rendu final imprimable...), distinct d'un fichier maître par son rôle et non par son format — un export JPEG généré depuis un RAW reste un dérivé même quand un autre JPEG, ailleurs, fait office de fichier maître. | |
| 33 | +- **sidecar** — fichier associé portant les réglages/métadonnées sans toucher au maître (`.xmp`, `.dop`, `.acr`). | |
| 34 | +- **checksum** — empreinte de contenu (SHA-256 par défaut) utilisée pour détecter une corruption ou un renommage/déplacement. | |
| 35 | +- **hash image-only (`ImageDataHash`)** — checksum portant uniquement sur les pixels, stable même quand les métadonnées d'un DNG/TIFF/JPEG changent. | |
| 36 | +- **manifeste** — état de référence persistant (base SQLite) par dossier : chemin, taille, hash, identifiant pérenne de chaque fichier. | |
| 37 | +- **identifiant pérenne** — identifiant indépendant du nom de fichier et du chemin, qui relie les versions d'une même image dans le temps. | |
| 38 | +- **scrub** — vérification périodique et indépendante du checkout, qui recalcule les hash de l'archive pour détecter une corruption silencieuse (bit rot). | |
| 39 | +- **checkout** — copie d'un dossier du NAS vers un espace de travail local, avec manifeste de référence. | |
| 40 | +- **réconciliation** — comparaison des hash de la copie de travail au manifeste avant réarchivage, pour classer chaque changement (normal, anomalie, renommage, suppression, nouveau fichier). | |
| 41 | +- **réarchivage** — écriture des changements validés depuis la copie de travail vers l'archive NAS. | |
| 42 | +- **anomalie** — changement suspect (ex. hash d'un fichier maître modifié) : jamais archivé silencieusement, toujours signalé à l'utilisateur. | |
| 43 | +- **point avant archive** — récapitulatif des changements classés que l'utilisateur valide avant toute écriture sur le NAS. | |
| 44 | + | |
| 45 | +## 4. Métadonnées et standards photo | |
| 46 | + | |
| 47 | +- **IPTC** — standard de métadonnées photo (légende, mots-clés, droits...). Champs notables : `Event` (événement nommé) et `Job Id` / `Transmission Reference` (identifiant de mission/commande). | |
| 48 | +- **XMP** — métadonnées intégrées au fichier. | |
| 49 | +- **XMP Media Management** — sous-schéma XMP pour la traçabilité entre versions d'un même fichier (`DocumentID`, `OriginalDocumentID`, `DerivedFrom`). | |
| 50 | +- **EXIF** — données techniques (appareil, objectif, exposition, date de prise de vue...). | |
| 51 | +- **profil de boîtiers** — liste des appareils déclarée par l'utilisateur, modifiable à tout moment, utilisée pour désambiguïser les sources à l'import via le tag EXIF `Model`. | |
| 52 | +- **`BodySerialNumber`** — tag EXIF de repli pour désambiguïser deux boîtiers identiques quand `Model` seul ne suffit pas. | |
| 53 | + | |
| 54 | +## 5. Archivage numérique (standards externes, référence) | |
| 55 | + | |
| 56 | +- **OAIS** — cadre conceptuel : SIP (ce qui arrive, l'import carte mémoire), AIP (ce qui est conservé, l'archive NAS + manifeste), DIP (ce qui sort, la copie de travail locale). | |
| 57 | +- **BagIt** — format de packaging avec preuve d'intégrité auto-portante (`manifest-sha256.txt`, `bagit.txt`, `bag-info.txt`). | |
| 58 | +- **PREMIS** — vocabulaire normalisé pour décrire les événements de préservation (type, agent, horodatage, résultat). | |
| 59 | +- **NDSA Levels of Digital Preservation** — grille d'auto-évaluation à 5 lignes × 4 niveaux pour situer la maturité d'un système d'archivage. | |
| 60 | + | |
| 61 | +## 6. Architecture logicielle | |
| 62 | + | |
| 63 | +- **bibliothèque centrale** — porte toute la logique métier ; la CLI, la GUI et l'agent IA sont des façades minces au-dessus, sans logique dupliquée. | |
| 64 | +- **façade** — CLI, GUI ou agent IA : chacune appelle la bibliothèque et formatte le résultat pour son canal. | |
| 65 | +- **module** — `metadata`, `archive`, `import`, `dossier`, `integrity`, `camera_profile` : découpage de la bibliothèque par domaine de responsabilité. | |
| 66 | +- **action à risque / action sans risque** — distingue ce qui modifie l'état persistant (écriture NAS, suppression, restauration → toujours confirmation explicite) de ce qui ne fait que consulter (recherche, prévisualisation → exécution directe). | |
| 67 | +- **point de pause** — moment où l'agent IA (ou toute façade) attend une réponse explicite avant d'exécuter une action à risque. | |
| 68 | +- **mode consultation** — navigation en lecture seule de l'archive NAS, sans checkout complet. | |
| 69 | + | |
| 70 | +## 7. Hébergement et stockage (service cloud) | |
| 71 | + | |
| 72 | +- **règle 3-2-1** — au moins 3 copies, sur 2 supports différents, dont 1 hors site. **Précision du 2026-09-18** : le NAS local et le stockage cloud ne comptent que pour 2 copies, pas 3 — l'ordinateur du photographe ne garde que des checkouts partiels et temporaires (pas la totalité de l'archive), donc il ne compte pas comme copie. Il faut un troisième support : un disque de backup local (ex. disque USB), régulièrement synchronisé avec le NAS. NAS (copie 1, sur site) + disque de backup (copie 2, sur site, support différent) + cloud (copie 3, hors site) respectent alors la règle. | |
| 73 | +- **Multi-AZ / One Zone** — classes de stockage Scaleway : Multi-AZ réplique sur plusieurs zones (résilience supérieure, ~2× le prix), One Zone ne réplique pas. | |
| 74 | +- **Glacier (froid)** — classe de stockage à coût réduit pour des données rarement consultées, avec latence d'accès plus élevée. | |
| 75 | + | |
| 76 | +## Historique | |
| 77 | + | |
| 78 | +Avant le 2026-09-18, les mots "projet" et "sous-projet" désignaient l'unité d'import/tri décrite ici sous "dossier"/"sous-dossier", et "projet" n'avait pas de sens distinct pour le concept de composition par copie (section 1 ci-dessus). Le renommage a été appliqué dans tous les docs du dépôt à cette date. | |
| new file mode 100644 | |||
| @@ -0,0 +1,78 @@ | |||
| 1 | +# Lexique Régine | ||
| 2 | + | ||
| 3 | +Référence terminologique pour tous les docs du projet : ce que chaque terme désigne, pour éviter les ambiguïtés entre docs et dans le temps. Tout nouveau terme structurant introduit dans un doc devrait être répercuté ici. | ||
| 4 | + | ||
| 5 | +## 1. Les quatre termes à ne pas confondre : dossier, sous-dossier, dossier parent, projet | ||
| 6 | + | ||
| 7 | +C'est la distinction la plus importante du lexique — deux familles de concepts qui se ressemblent mais ne se recouvrent pas. | ||
| 8 | + | ||
| 9 | +| Terme | Définition | | ||
| 10 | +|---|---| | ||
| 11 | +| **dossier** | Unité créée à l'import d'une carte mémoire (import carte mémoire → archivage/NAS). Structure interne par format (`raw/`, `jpeg/`, `tiff/`...) + racine de sélection. C'est l'unité de checkout/réconciliation et de verrouillage. | | ||
| 12 | +| **sous-dossier** | Étape d'un dossier multi-parties (ex. une ville dans un voyage). A sa propre structure complète (dossiers de format + racine). Ne se checkout jamais isolément — toujours via son dossier parent. | | ||
| 13 | +| **dossier parent** | Dossier englobant plusieurs sous-dossiers. A sa propre racine, qui sert de planche-contact globale sur l'ensemble (ex. les meilleures photos de tout le voyage, pas juste d'une étape). | | ||
| 14 | +| **projet** | Répertoire de travail **séparé**, composé par **copie** de fichiers piochés dans un ou plusieurs dossiers de l'archive, pour un usage autonome (livre, expo, sélection thématique). Ne fait pas partie de la hiérarchie dossier / sous-dossier / dossier parent — c'est un objet en aval, indépendant. Chaque fichier copié est traçable vers son dossier d'origine via une **fiche de provenance**. | | ||
| 15 | + | ||
| 16 | +À retenir : **dossier** = comment les photos arrivent et sont archivées (immuable, structure de l'archive). **projet** = ce qu'on en fait ensuite pour produire quelque chose (mutable, composé par copie, ne touche jamais l'archive). | ||
| 17 | + | ||
| 18 | +**Piste ouverte, non tranchée** : à terme, un projet pourrait ne conserver que les fichiers dérivés générés (JPEG, PDF) sans garder les copies RAW ayant servi à les produire — à trancher plus tard, voir `archivage-photo-elements-cles.md` section 13. | ||
| 19 | + | ||
| 20 | +**Point de vigilance** : le mot "dossier" désigne aussi, dans les docs, les sous-répertoires par format à l'intérieur d'une unité (`raw/`, `jpeg/`, `tiff/` — appelés "dossier de format"). Il porte donc deux niveaux de sens selon le contexte : le dossier Régine dans son ensemble, ou un dossier de format à l'intérieur. Désambiguïsé par le contexte partout où ça apparaît, mais à garder en tête en écrivant. | ||
| 21 | + | ||
| 22 | +## 2. Structure et sélection | ||
| 23 | + | ||
| 24 | +- **dossier de format** — sous-répertoire créé à la demande selon les formats réellement présents (`raw/`, `jpeg/`, `tiff/`...). `raw/` est une catégorie fonctionnelle regroupant toutes les extensions RAW, pas une extension unique. | ||
| 25 | +- **racine** — niveau (du dossier, du sous-dossier, ou du dossier parent) où vivent les fichiers sélectionnés/promus, prêt à être consulté directement sans outil. | ||
| 26 | +- **promotion** — action de faire remonter un fichier vers une racine. En deux temps pour un dossier parent : racine du sous-dossier d'abord, puis racine du dossier parent (planche-contact globale). | ||
| 27 | +- **fiche de provenance** — enregistrement créé au moment de la copie vers un projet : dossier source, identifiant pérenne du fichier, nom d'origine. | ||
| 28 | + | ||
| 29 | +## 3. Fichiers et intégrité | ||
| 30 | + | ||
| 31 | +- **fichier maître** — défini par son rôle, pas par son format : le fichier faisant autorité pour une capture, à conserver indéfiniment sans le modifier. RAW ou TIFF non compressé par défaut, mais aussi un JPEG quand c'est le seul fichier produit par l'appareil, ou même en mode RAW+JPEG quand le photographe juge le JPEG satisfaisant et ne garde le RAW que pour un usage secondaire (précisé le 2026-09-18, voir `archivage-photo-elements-cles.md` section 4). | ||
| 32 | +- **dérivé** — export de diffusion (JPEG, versions web, rendu final imprimable...), distinct d'un fichier maître par son rôle et non par son format — un export JPEG généré depuis un RAW reste un dérivé même quand un autre JPEG, ailleurs, fait office de fichier maître. | ||
| 33 | +- **sidecar** — fichier associé portant les réglages/métadonnées sans toucher au maître (`.xmp`, `.dop`, `.acr`). | ||
| 34 | +- **checksum** — empreinte de contenu (SHA-256 par défaut) utilisée pour détecter une corruption ou un renommage/déplacement. | ||
| 35 | +- **hash image-only (`ImageDataHash`)** — checksum portant uniquement sur les pixels, stable même quand les métadonnées d'un DNG/TIFF/JPEG changent. | ||
| 36 | +- **manifeste** — état de référence persistant (base SQLite) par dossier : chemin, taille, hash, identifiant pérenne de chaque fichier. | ||
| 37 | +- **identifiant pérenne** — identifiant indépendant du nom de fichier et du chemin, qui relie les versions d'une même image dans le temps. | ||
| 38 | +- **scrub** — vérification périodique et indépendante du checkout, qui recalcule les hash de l'archive pour détecter une corruption silencieuse (bit rot). | ||
| 39 | +- **checkout** — copie d'un dossier du NAS vers un espace de travail local, avec manifeste de référence. | ||
| 40 | +- **réconciliation** — comparaison des hash de la copie de travail au manifeste avant réarchivage, pour classer chaque changement (normal, anomalie, renommage, suppression, nouveau fichier). | ||
| 41 | +- **réarchivage** — écriture des changements validés depuis la copie de travail vers l'archive NAS. | ||
| 42 | +- **anomalie** — changement suspect (ex. hash d'un fichier maître modifié) : jamais archivé silencieusement, toujours signalé à l'utilisateur. | ||
| 43 | +- **point avant archive** — récapitulatif des changements classés que l'utilisateur valide avant toute écriture sur le NAS. | ||
| 44 | + | ||
| 45 | +## 4. Métadonnées et standards photo | ||
| 46 | + | ||
| 47 | +- **IPTC** — standard de métadonnées photo (légende, mots-clés, droits...). Champs notables : `Event` (événement nommé) et `Job Id` / `Transmission Reference` (identifiant de mission/commande). | ||
| 48 | +- **XMP** — métadonnées intégrées au fichier. | ||
| 49 | +- **XMP Media Management** — sous-schéma XMP pour la traçabilité entre versions d'un même fichier (`DocumentID`, `OriginalDocumentID`, `DerivedFrom`). | ||
| 50 | +- **EXIF** — données techniques (appareil, objectif, exposition, date de prise de vue...). | ||
| 51 | +- **profil de boîtiers** — liste des appareils déclarée par l'utilisateur, modifiable à tout moment, utilisée pour désambiguïser les sources à l'import via le tag EXIF `Model`. | ||
| 52 | +- **`BodySerialNumber`** — tag EXIF de repli pour désambiguïser deux boîtiers identiques quand `Model` seul ne suffit pas. | ||
| 53 | + | ||
| 54 | +## 5. Archivage numérique (standards externes, référence) | ||
| 55 | + | ||
| 56 | +- **OAIS** — cadre conceptuel : SIP (ce qui arrive, l'import carte mémoire), AIP (ce qui est conservé, l'archive NAS + manifeste), DIP (ce qui sort, la copie de travail locale). | ||
| 57 | +- **BagIt** — format de packaging avec preuve d'intégrité auto-portante (`manifest-sha256.txt`, `bagit.txt`, `bag-info.txt`). | ||
| 58 | +- **PREMIS** — vocabulaire normalisé pour décrire les événements de préservation (type, agent, horodatage, résultat). | ||
| 59 | +- **NDSA Levels of Digital Preservation** — grille d'auto-évaluation à 5 lignes × 4 niveaux pour situer la maturité d'un système d'archivage. | ||
| 60 | + | ||
| 61 | +## 6. Architecture logicielle | ||
| 62 | + | ||
| 63 | +- **bibliothèque centrale** — porte toute la logique métier ; la CLI, la GUI et l'agent IA sont des façades minces au-dessus, sans logique dupliquée. | ||
| 64 | +- **façade** — CLI, GUI ou agent IA : chacune appelle la bibliothèque et formatte le résultat pour son canal. | ||
| 65 | +- **module** — `metadata`, `archive`, `import`, `dossier`, `integrity`, `camera_profile` : découpage de la bibliothèque par domaine de responsabilité. | ||
| 66 | +- **action à risque / action sans risque** — distingue ce qui modifie l'état persistant (écriture NAS, suppression, restauration → toujours confirmation explicite) de ce qui ne fait que consulter (recherche, prévisualisation → exécution directe). | ||
| 67 | +- **point de pause** — moment où l'agent IA (ou toute façade) attend une réponse explicite avant d'exécuter une action à risque. | ||
| 68 | +- **mode consultation** — navigation en lecture seule de l'archive NAS, sans checkout complet. | ||
| 69 | + | ||
| 70 | +## 7. Hébergement et stockage (service cloud) | ||
| 71 | + | ||
| 72 | +- **règle 3-2-1** — au moins 3 copies, sur 2 supports différents, dont 1 hors site. **Précision du 2026-09-18** : le NAS local et le stockage cloud ne comptent que pour 2 copies, pas 3 — l'ordinateur du photographe ne garde que des checkouts partiels et temporaires (pas la totalité de l'archive), donc il ne compte pas comme copie. Il faut un troisième support : un disque de backup local (ex. disque USB), régulièrement synchronisé avec le NAS. NAS (copie 1, sur site) + disque de backup (copie 2, sur site, support différent) + cloud (copie 3, hors site) respectent alors la règle. | ||
| 73 | +- **Multi-AZ / One Zone** — classes de stockage Scaleway : Multi-AZ réplique sur plusieurs zones (résilience supérieure, ~2× le prix), One Zone ne réplique pas. | ||
| 74 | +- **Glacier (froid)** — classe de stockage à coût réduit pour des données rarement consultées, avec latence d'accès plus élevée. | ||
| 75 | + | ||
| 76 | +## Historique | ||
| 77 | + | ||
| 78 | +Avant le 2026-09-18, les mots "projet" et "sous-projet" désignaient l'unité d'import/tri décrite ici sous "dossier"/"sous-dossier", et "projet" n'avait pas de sens distinct pour le concept de composition par copie (section 1 ci-dessus). Le renommage a été appliqué dans tous les docs du dépôt à cette date. | ||