| @@ -19,39 +19,33 @@ 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 10, 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 (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. |
| 23 | -- **Stockage retenu, cf. section 14** : 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 14** : 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 | - Distinction fichier maître (RAW ou TIFF non compressé, jamais modifié) vs dérivés de diffusion (JPEG, versions web). |
| 28 | - Préférence pour des formats ouverts et documentés plutôt que propriétaires. | 28 | - 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. | 29 | - Migrations périodiques planifiées quand un format devient obsolète. |
| 30 | -- **Nuance importante par format, cf. section 12** : 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. | 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. |
| 31 | | 31 | |
| 32 | ## 5. Sauvegarde et intégrité | 32 | ## 5. Sauvegarde et intégrité |
| 33 | | 33 | |
| 34 | - Règle **3-2-1** : au moins 3 copies, sur 2 types de support différents, dont 1 hors site. | 34 | - Règle **3-2-1** : au moins 3 copies, sur 2 types de support différents, dont 1 hors site. |
| 35 | - Vérification d'intégrité par **checksums** pour détecter la corruption silencieuse dans le temps. | 35 | - 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 12. | 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. |
| 37 | | 37 | |
| 38 | -## 6. Conservation physique (négatifs/tirages argentiques) | 38 | +## 6. Gestion des droits |
| 39 | - | | |
| 40 | -- Température et humidité contrôlées, boîtes/pochettes sans acide. | | |
| 41 | -- Séparation des supports instables (ex. négatifs couleur, plus fragiles). | | |
| 42 | -- Normes ISO 18902 / 18906 et standards des archives nationales. | | |
| 43 | - | | |
| 44 | -## 7. Gestion des droits | | |
| 45 | | 39 | |
| 46 | - Copyright, autorisations d'usage, contrats de licence attachés à chaque image/lot. | 40 | - Copyright, autorisations d'usage, contrats de licence attachés à chaque image/lot. |
| 47 | - Traçabilité claire : qui a le droit d'utiliser quoi, pour quel usage, jusqu'à quand. | 41 | - Traçabilité claire : qui a le droit d'utiliser quoi, pour quel usage, jusqu'à quand. |
| 48 | | 42 | |
| 49 | -## 8. Contexte et documentation | 43 | +## 7. Contexte et documentation |
| 50 | | 44 | |
| 51 | - Conserver le contexte au-delà des images : notes de terrain, correspondance, interviews, planches-contact originales. | 45 | - Conserver le contexte au-delà des images : notes de terrain, correspondance, interviews, planches-contact originales. |
| 52 | - Raconte comment le travail a été fait, pas seulement son résultat. | 46 | - Raconte comment le travail a été fait, pas seulement son résultat. |
| 53 | | 47 | |
| 54 | -## 9. Workflow d'édition sécurisé : checkout / réconciliation (NAS comme serveur d'archives) | 48 | +## 8. Workflow d'édition sécurisé : checkout / réconciliation (NAS comme serveur d'archives) |
| 55 | | 49 | |
| 56 | Constat de départ : aucune marque de NAS (Synology, QNAP, TrueNAS...) ne permet de mélanger, dans un même dossier partagé, des permissions différentes par type de fichier (ex. RAW en lecture seule, XMP en écriture). Les ACL/permissions NAS fonctionnent par dossier/fichier/utilisateur, pas par extension. Séparer physiquement RAW et XMP dans des dossiers aux droits différents est une option, mais l'alternative retenue pour Régine est de déplacer la protection au niveau applicatif plutôt que filesystem. | 50 | Constat de départ : aucune marque de NAS (Synology, QNAP, TrueNAS...) ne permet de mélanger, dans un même dossier partagé, des permissions différentes par type de fichier (ex. RAW en lecture seule, XMP en écriture). Les ACL/permissions NAS fonctionnent par dossier/fichier/utilisateur, pas par extension. Séparer physiquement RAW et XMP dans des dossiers aux droits différents est une option, mais l'alternative retenue pour Régine est de déplacer la protection au niveau applicatif plutôt que filesystem. |
| 57 | | 51 | |
| @@ -59,12 +53,12 @@ Principe : Régine gère elle-même l'aller-retour entre l'archive (sur le NAS) |
| 59 | | 53 | |
| 60 | Déroulé : | 54 | Déroulé : |
| 61 | | 55 | |
| 62 | -- **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 13, 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 13, un sous-projet ne se checkout jamais isolément.** | 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.** |
| 63 | - **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. | 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. |
| 64 | - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier : | 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 : |
| 65 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. | 59 | - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement. |
| 66 | - - 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 12), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.** | 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.** |
| 67 | - - 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 10), et la promotion d'une photo depuis la racine d'un sous-projet vers la racine du projet parent (planche-contact globale, section 11) — un déplacement de fichier à hash inchangé, pas un cas à part.** | 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.** |
| 68 | - 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. | 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. |
| 69 | - 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). | 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). |
| 70 | - 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. | 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. |
| @@ -73,12 +67,12 @@ Points à anticiper pour l'implémentation : |
| 73 | | 67 | |
| 74 | - Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go). | 68 | - Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go). |
| 75 | - Temps de transfert réseau au moment du checkout. | 69 | - Temps de transfert réseau au moment du checkout. |
| 76 | -- 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 13.** | 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.** |
| 77 | - 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. | 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. |
| 78 | | 72 | |
| 79 | -## 10. Import depuis une carte mémoire | 73 | +## 9. Import depuis une carte mémoire |
| 80 | | 74 | |
| 81 | -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 9). 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. | 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. |
| 82 | | 76 | |
| 83 | **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). | 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). |
| 84 | | 78 | |
| @@ -92,7 +86,7 @@ Séquence retenue : |
| 92 | 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 : | 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 : |
| 93 | - **Nouveau projet simple** : comportement par défaut, structure à un seul niveau. | 87 | - **Nouveau projet simple** : comportement par défaut, structure à un seul niveau. |
| 94 | - **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. | 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. |
| 95 | - - **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 9) pour y intégrer les nouveaux fichiers avant de repousser l'ensemble via la réconciliation habituelle. | 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. |
| 96 | - **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. | 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. |
| 97 | - 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. | 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. |
| 98 | 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 : | 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 : |
| @@ -110,9 +104,9 @@ Séquence retenue : |
| 110 | - **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é. | 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é. |
| 111 | 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). | 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). |
| 112 | | 106 | |
| 113 | -**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 9) ; 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 13), ses lignes sont absorbées dans la base du projet parent au même moment — cf. section 13 pour le détail.** | 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.** |
| 114 | | 108 | |
| 115 | -## 11. Structure d'un projet, sélection et déchets évidents | 109 | +## 10. Structure d'un projet, sélection et déchets évidents |
| 116 | | 110 | |
| 117 | Structure retenue pour un projet (après plusieurs itérations) : | 111 | Structure retenue pour un projet (après plusieurs itérations) : |
| 118 | | 112 | |
| @@ -122,27 +116,27 @@ Structure retenue pour un projet (après plusieurs itérations) : |
| 122 | | 116 | |
| 123 | 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. | 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. |
| 124 | | 118 | |
| 125 | -**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 9), rien de spécifique à construire. | 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. |
| 126 | | 120 | |
| 127 | **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. | 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. |
| 128 | | 122 | |
| 129 | -**La promotion vers la racine est une action manuelle de l'utilisateur dans son outil d'édition (DxO ou autre), pas une décision automatique de Régine.** Le rôle de Régine se limite à détecter ce déplacement à la réconciliation (section 9) : un fichier retrouvé à un autre chemin avec le même hash de contenu est traité comme le cas "renommage/déplacement détecté par le contenu" déjà prévu, qu'il s'agisse d'une promotion vers la racine, d'un retour en arrière, ou d'un déplacement entre dossiers de format. Aucun mécanisme supplémentaire à construire pour ça. | 123 | +**La promotion vers la racine est une action manuelle de l'utilisateur dans son outil d'édition (DxO ou autre), pas une décision automatique de Régine.** Le rôle de Régine se limite à détecter ce déplacement à la réconciliation (section 8) : un fichier retrouvé à un autre chemin avec le même hash de contenu est traité comme le cas "renommage/déplacement détecté par le contenu" déjà prévu, qu'il s'agisse d'une promotion vers la racine, d'un retour en arrière, ou d'un déplacement entre dossiers de format. Aucun mécanisme supplémentaire à construire pour ça. |
| 130 | | 124 | |
| 131 | -L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de reposer sur le nom de fichier identique hors extension, garanti par la convention de renommage à l'import (section 10, point 6) — même si RAW et JPEG ne sont jamais dans le même dossier. | 125 | +L'appariement RAW/JPEG d'une même capture (quand les deux existent) continue de reposer sur le nom de fichier identique hors extension, garanti par la convention de renommage à l'import (section 9, point 6) — même si RAW et JPEG ne sont jamais dans le même dossier. |
| 132 | | 126 | |
| 133 | **Deux catégories de fichiers non retenus, deux traitements différents.** Ne pas tout mettre dans le même panier : | 127 | **Deux catégories de fichiers non retenus, deux traitements différents.** Ne pas tout mettre dans le même panier : |
| 134 | | 128 | |
| 135 | -- **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 9) — c'est exactement l'usage prévu de cette étape, pas une entorse à la règle. | 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. |
| 136 | - **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. | 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. |
| 137 | | 131 | |
| 138 | -**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 13, on ne checkout jamais un seul sous-projet sans son projet parent.** | 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.** |
| 139 | | 133 | |
| 140 | **Limites observées avec DxO PhotoLab, à corriger dans Régine :** | 134 | **Limites observées avec DxO PhotoLab, à corriger dans Régine :** |
| 141 | | 135 | |
| 142 | - 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. | 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. |
| 143 | - 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. | 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. |
| 144 | | 138 | |
| 145 | -## 12. Modification des fichiers par les outils d'édition : quand le "fichier maître jamais modifié" tient vraiment | 139 | +## 11. Modification des fichiers par les outils d'édition : quand le "fichier maître jamais modifié" tient vraiment |
| 146 | | 140 | |
| 147 | Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la règle "le fichier maître n'est jamais modifié" (section 4) ne se comporte pas de la même façon selon le format. | 141 | Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la règle "le fichier maître n'est jamais modifié" (section 4) ne se comporte pas de la même façon selon le format. |
| 148 | | 142 | |
| @@ -153,20 +147,20 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r |
| 153 | **Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF :** | 147 | **Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF :** |
| 154 | | 148 | |
| 155 | - **DNG** : traité différemment des autres RAW par Lightroom, qui écrit les métadonnées et réglages _directement dans le fichier DNG_ (pas de sidecar par défaut). Le hash du fichier entier change donc à chaque édition de métadonnées, sans corruption ni changement des pixels. | 149 | - **DNG** : traité différemment des autres RAW par Lightroom, qui écrit les métadonnées et réglages _directement dans le fichier DNG_ (pas de sidecar par défaut). Le hash du fichier entier change donc à chaque édition de métadonnées, sans corruption ni changement des pixels. |
| 156 | -- **TIFF/JPEG** (masters de scan section 11, ou JPEG promu à la racine) : DxO indique explicitement que la "sanctuarisation" du fichier original ne s'applique pas aux fichiers RVB (JPG, TIFF, DNG) — l'écriture de métadonnées peut se faire directement dans le fichier. | 150 | +- **TIFF/JPEG** (masters de scan section 10, ou JPEG promu à la racine) : DxO indique explicitement que la "sanctuarisation" du fichier original ne s'applique pas aux fichiers RVB (JPG, TIFF, DNG) — l'écriture de métadonnées peut se faire directement dans le fichier. |
| 157 | | 151 | |
| 158 | -**Conséquence pour le hash de réconciliation (section 9)** : pour DNG/TIFF/JPEG, un hash sur le fichier entier ne permet plus de distinguer une édition de métadonnées légitime d'une vraie corruption (ex. erreur d'écriture disque). Il faut un hash portant uniquement sur les données image (pixels), stable à travers les éditions de métadonnées : | 152 | +**Conséquence pour le hash de réconciliation (section 8)** : pour DNG/TIFF/JPEG, un hash sur le fichier entier ne permet plus de distinguer une édition de métadonnées légitime d'une vraie corruption (ex. erreur d'écriture disque). Il faut un hash portant uniquement sur les données image (pixels), stable à travers les éditions de métadonnées : |
| 159 | | 153 | |
| 160 | - **Le DNG a un tag natif prévu pour ça** : `RawDataUniqueID` (tag TIFF 0xC65D), défini dans la spec Adobe DNG comme un identifiant dérivé des données image, indépendant des métadonnées. À vérifier au cas par cas : tous les boîtiers ne le renseignent pas de façon fiable. Test rapide : `exiftool -RawDataUniqueID -ImageUniqueID fichier.dng`. | 154 | - **Le DNG a un tag natif prévu pour ça** : `RawDataUniqueID` (tag TIFF 0xC65D), défini dans la spec Adobe DNG comme un identifiant dérivé des données image, indépendant des métadonnées. À vérifier au cas par cas : tous les boîtiers ne le renseignent pas de façon fiable. Test rapide : `exiftool -RawDataUniqueID -ImageUniqueID fichier.dng`. |
| 161 | - **Solution plus robuste et indépendante du boîtier : `ImageDataHash` d'ExifTool.** Calcule un hash (MD5/SHA256/SHA512) sur les seules données image, en excluant les métadonnées. Pas activé par défaut, nécessite l'option API `ImageHashType` : | 155 | - **Solution plus robuste et indépendante du boîtier : `ImageDataHash` d'ExifTool.** Calcule un hash (MD5/SHA256/SHA512) sur les seules données image, en excluant les métadonnées. Pas activé par défaut, nécessite l'option API `ImageHashType` : |
| 162 | ``` | 156 | ``` |
| 163 | exiftool -api ImageHashType=SHA256 -ImageDataHash fichier.dng | 157 | exiftool -api ImageHashType=SHA256 -ImageDataHash fichier.dng |
| 164 | ``` | 158 | ``` |
| 165 | - Utilisé dans ce but précis (détection de corruption indépendamment des éditions de métadonnées) par le projet PhotoStructure, dont l'architecture d'archivage recoupe largement celle de Régine. **C'est aussi le hash qui permet de suivre un DNG par checksum sur la durée, retouche comprise (section 14) : il reste stable tant que seules les métadonnées/réglages changent.** | 159 | + Utilisé dans ce but précis (détection de corruption indépendamment des éditions de métadonnées) par le projet PhotoStructure, dont l'architecture d'archivage recoupe largement celle de Régine. **C'est aussi le hash qui permet de suivre un DNG par checksum sur la durée, retouche comprise (section 13) : il reste stable tant que seules les métadonnées/réglages changent.** |
| 166 | | 160 | |
| 167 | -**Révision proposée pour le manifeste et la réconciliation (section 9)** : stocker, pour les formats DNG/TIFF/JPEG, un hash image-only (`ImageDataHash`) en plus (ou à la place) du hash fichier entier. À la réconciliation : hash fichier changé + hash image-only inchangé → édition de métadonnées légitime, archivable normalement ; hash image-only changé → vraie anomalie, jamais archivé silencieusement (même traitement que pour un RAW propriétaire aujourd'hui). | 161 | +**Révision proposée pour le manifeste et la réconciliation (section 8)** : stocker, pour les formats DNG/TIFF/JPEG, un hash image-only (`ImageDataHash`) en plus (ou à la place) du hash fichier entier. À la réconciliation : hash fichier changé + hash image-only inchangé → édition de métadonnées légitime, archivable normalement ; hash image-only changé → vraie anomalie, jamais archivé silencieusement (même traitement que pour un RAW propriétaire aujourd'hui). |
| 168 | | 162 | |
| 169 | -**Lacune identifiée dans le design actuel** : le workflow de la section 9 ne vérifie les hash qu'au moment d'un checkout/réarchivage. Ça ne détecte pas une corruption survenant plus tard, pendant que l'archive dort sur le NAS sans qu'on y touche (bit rot classique). Il manque une tâche de **vérification périodique** (scrub), indépendante de tout checkout, qui recalcule et compare les hash de l'archive à intervalle régulier (ex. mensuel). **Cette tâche a besoin d'un manifeste persistant sur l'archive plutôt qu'un manifeste éphémère créé à chaque checkout — cf. section 13.** | 163 | +**Lacune identifiée dans le design actuel** : le workflow de la section 8 ne vérifie les hash qu'au moment d'un checkout/réarchivage. Ça ne détecte pas une corruption survenant plus tard, pendant que l'archive dort sur le NAS sans qu'on y touche (bit rot classique). Il manque une tâche de **vérification périodique** (scrub), indépendante de tout checkout, qui recalcule et compare les hash de l'archive à intervalle régulier (ex. mensuel). **Cette tâche a besoin d'un manifeste persistant sur l'archive plutôt qu'un manifeste éphémère créé à chaque checkout — cf. section 12.** |
| 170 | | 164 | |
| 171 | **Détection vs réparation** : un hash (quel qu'il soit) détecte une corruption, il ne la répare pas. Options pour la réparation, à documenter/choisir séparément : | 165 | **Détection vs réparation** : un hash (quel qu'il soit) détecte une corruption, il ne la répare pas. Options pour la réparation, à documenter/choisir séparément : |
| 172 | | 166 | |
| @@ -174,9 +168,9 @@ Vérifié le 2026-09-11 (comportement Lightroom Classic et DxO PhotoLab) : la r |
| 174 | - 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. | 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. |
| 175 | - 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. | 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. |
| 176 | | 170 | |
| 177 | -## 13. Manifeste persistant par projet et compatibilité de format entre versions de Régine | 171 | +## 12. Manifeste persistant par projet et compatibilité de format entre versions de Régine |
| 178 | | 172 | |
| 179 | -Point de départ (2026-09-11) : le manifeste décrit en section 9 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 12), 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. | 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. |
| 180 | | 174 | |
| 181 | **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). | 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). |
| 182 | | 176 | |
| @@ -196,13 +190,13 @@ L'intérêt sur un fichier de version séparé (l'idée initiale d'un `Regine.js |
| 196 | | 190 | |
| 197 | **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 — | 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 — |
| 198 | | 192 | |
| 199 | -- 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 9 et 11) ; | 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) ; |
| 200 | - **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. | 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. |
| 201 | | 195 | |
| 202 | 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 : | 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 : |
| 203 | | 197 | |
| 204 | -- Le projet parent a sa propre racine, qui sert de planche-contact globale sur l'ensemble du voyage (section 11) : 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 9) — sans base séparée, pas besoin de gérer une transition d'une base à l'autre pour ce geste. | 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. |
| 205 | -- Fusionner les checksums d'un projet devenu sous-projet (section 10) 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. | 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. |
| 206 | | 200 | |
| 207 | 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. | 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. |
| 208 | | 202 | |
| @@ -210,23 +204,23 @@ La suggestion `ATTACH DATABASE` pour composer plusieurs bases à la demande devi |
| 210 | | 204 | |
| 211 | **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.** | 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.** |
| 212 | | 206 | |
| 213 | -## 14. Copie inter-projets pour composer un nouveau projet (livre, sélection thématique) | 207 | +## 13. Copie inter-projets pour composer un nouveau projet (livre, sélection thématique) |
| 214 | | 208 | |
| 215 | 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. | 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. |
| 216 | | 210 | |
| 217 | **Pourquoi la copie plutôt qu'une référence (lien symbolique, lien physique) :** | 211 | **Pourquoi la copie plutôt qu'une référence (lien symbolique, lien physique) :** |
| 218 | | 212 | |
| 219 | -- La détection de déplacement par hash (section 9) 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. | 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. |
| 220 | -- Un lien symbolique casse le principe d'auto-suffisance des projets (section 11/13) : il pointe dans le vide si le projet source est déplacé ou renommé. | 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é. |
| 221 | - 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. | 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. |
| 222 | - 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é. | 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é. |
| 223 | | 217 | |
| 224 | -**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 12) — 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 : | 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 : |
| 225 | | 219 | |
| 226 | - RAW propriétaires et JPEG/TIFF traités comme masters : le hash du fichier entier reste stable, retouche comprise. | 220 | - RAW propriétaires et JPEG/TIFF traités comme masters : le hash du fichier entier reste stable, retouche comprise. |
| 227 | -- DNG : le hash du fichier entier bouge à chaque écriture de réglages (comme ailleurs, section 12), mais le hash image-only (`ImageDataHash`) reste stable — c'est donc lui qu'il faut utiliser pour suivre un DNG par checksum sur la durée. | 221 | +- DNG : le hash du fichier entier bouge à chaque écriture de réglages (comme ailleurs, section 11), mais le hash image-only (`ImageDataHash`) reste stable — c'est donc lui qu'il faut utiliser pour suivre un DNG par checksum sur la durée. |
| 228 | | 222 | |
| 229 | -Le checksum (image-only pour DNG, fichier entier pour les autres masters) et le nom de fichier archivé (section 10, tant qu'il n'est pas renommé) couvrent donc, à eux deux, la quasi-totalité des besoins de traçabilité vers l'archive d'origine. Confirmé le 2026-09-11 : c'est suffisant pour l'usage courant, pas la peine d'ajouter de mécanisme pour ce cas-là. | 223 | +Le checksum (image-only pour DNG, fichier entier pour les autres masters) et le nom de fichier archivé (section 9, tant qu'il n'est pas renommé) couvrent donc, à eux deux, la quasi-totalité des besoins de traçabilité vers l'archive d'origine. Confirmé le 2026-09-11 : c'est suffisant pour l'usage courant, pas la peine d'ajouter de mécanisme pour ce cas-là. |
| 230 | | 224 | |
| 231 | **Ce qui échappe réellement à checksum + nom, c'est un export/rendu final** (ex. un TIFF prêt à imprimer pour la mise en page du livre) : un nouveau fichier, avec des pixels effectivement différents du maître puisque les réglages y sont "cuits" en dur au moment de l'export, et un nom qui n'a souvent plus de rapport avec le fichier d'origine (renommé pour l'ordre des pages). C'est là, et seulement là, qu'un lien plus robuste que checksum/nom a un intérêt. | 225 | **Ce qui échappe réellement à checksum + nom, c'est un export/rendu final** (ex. un TIFF prêt à imprimer pour la mise en page du livre) : un nouveau fichier, avec des pixels effectivement différents du maître puisque les réglages y sont "cuits" en dur au moment de l'export, et un nom qui n'a souvent plus de rapport avec le fichier d'origine (renommé pour l'ordre des pages). C'est là, et seulement là, qu'un lien plus robuste que checksum/nom a un intérêt. |
| 232 | | 226 | |
| @@ -240,25 +234,25 @@ Si DxO renseigne ces champs, Régine n'a pas besoin d'écrire son propre identif |
| 240 | | 234 | |
| 241 | **Deux mécanismes à prévoir pour la traçabilité, indépendamment du résultat de cette vérification :** | 235 | **Deux mécanismes à prévoir pour la traçabilité, indépendamment du résultat de cette vérification :** |
| 242 | | 236 | |
| 243 | -- **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 10 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. | 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. |
| 244 | -- **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 13 (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é. | 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é. |
| 245 | | 239 | |
| 246 | ## Pistes de fonctionnalités pour Régine | 240 | ## Pistes de fonctionnalités pour Régine |
| 247 | | 241 | |
| 248 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. | 242 | - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison. |
| 249 | -- Identifiant pérenne par photo, indépendant du nom de fichier — à construire seulement si la vérification du standard XMP `DerivedFrom`/`OriginalDocumentID` sur les exports DxO s'avère négative, cf. section 14 ; sinon lire ces champs standards suffit pour relier un export dérivé à son maître. | 243 | +- Identifiant pérenne par photo, indépendant du nom de fichier — à construire seulement si la vérification du standard XMP `DerivedFrom`/`OriginalDocumentID` sur les exports DxO s'avère négative, cf. section 13 ; sinon lire ces champs standards suffit pour relier un export dérivé à son maître. |
| 250 | - Notion de fichier maître vs dérivés. | 244 | - Notion de fichier maître vs dérivés. |
| 251 | - Détection de doublons / vérification d'intégrité par checksum. | 245 | - Détection de doublons / vérification d'intégrité par checksum. |
| 252 | - Gestion de niveaux de sélection (brut / sélection / édition finale). | 246 | - Gestion de niveaux de sélection (brut / sélection / édition finale). |
| 253 | - Champs de droits/licence par photo ou par lot. | 247 | - Champs de droits/licence par photo ou par lot. |
| 254 | -- 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 9. | 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. |
| 255 | -- 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 10, point 6. | 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. |
| 256 | -- 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 10. | 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. |
| 257 | -- 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 11. | 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. |
| 258 | -- 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 11. | 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. |
| 259 | -- 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 12. Ce même hash image-only permet de suivre un DNG par checksum sur la durée, retouche non destructive comprise. | 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. |
| 260 | -- 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 13. | 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. |
| 261 | -- 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 14. | 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. |
| 262 | | 256 | |
| 263 | ## Sources | 257 | ## Sources |
| 264 | | 258 | |