| @@ -1,10 +1,15 @@ |
| 1 | <!-- | 1 | <!-- |
| 2 | Sync Impact Report | 2 | Sync Impact Report |
| 3 | -Version change: 1.0.0 → 2.0.0 (redéfinition incompatible du Principe I) | 3 | +Version change: 2.0.0 → 2.1.0 (renforcement matériel d'exigences existantes, périmètre des |
| 4 | -Modified principles: I. Fichier maître intouchable — périmètre étendu aux JPEG issus directement | 4 | + principes inchangé) |
| 5 | - de l'appareil (import carte mémoire, JPEG seul ou couple RAW+JPEG), qui ne sont plus traités | 5 | +Modified principles: I. Fichier maître intouchable — précision du mécanisme de détection d'une |
| 6 | - comme des dérivés jetables du RAW. | 6 | + modification : hash fichier entier pour les RAW propriétaires, hash image-only requis en |
| 7 | -Added sections: aucune | 7 | + complément pour DNG/TIFF/JPEG (les outils d'édition courants peuvent légitimement réécrire les |
| | 8 | + métadonnées de ces formats directement dans le fichier). III. Identité par contenu, jamais par |
| | 9 | + nom de fichier seul — renvoi ajouté vers cette distinction à deux niveaux pour éviter toute |
| | 10 | + lecture contradictoire avec le hash unique mentionné au principe. |
| | 11 | +Added sections: aucune (ajout de deux exigences dans « Contraintes techniques » : vérification |
| | 12 | + périodique indépendante du checkout / scrub, et distinction détection vs réparation) |
| 8 | Removed sections: aucune | 13 | Removed sections: aucune |
| 9 | Templates requiring follow-up: aucun contrôle croisé effectué sur plan-template.md / | 14 | Templates requiring follow-up: aucun contrôle croisé effectué sur plan-template.md / |
| 10 | spec-template.md / tasks-template.md dans cette exécution — à vérifier manuellement lors du | 15 | spec-template.md / tasks-template.md dans cette exécution — à vérifier manuellement lors du |
| @@ -31,10 +36,26 @@ JAMAIS supprimer ou modifier un JPEG au seul prétexte qu'un RAW du même nom ex |
| 31 | et réciproquement. Seuls les dérivés créés par l'utilisateur après capture (exports web, | 36 | et réciproquement. Seuls les dérivés créés par l'utilisateur après capture (exports web, |
| 32 | retouches enregistrées à part, sidecars XMP/DOP) peuvent être créés ou modifiés librement. | 37 | retouches enregistrées à part, sidecars XMP/DOP) peuvent être créés ou modifiés librement. |
| 33 | | 38 | |
| | 39 | +Le mécanisme de détection d'une modification dépend du format, et cette dépendance ne relâche en |
| | 40 | +rien l'interdiction ci-dessus. Pour les RAW propriétaires (RAF, CR2, NEF, ARW...), jamais réécrits |
| | 41 | +par les outils d'édition courants (Lightroom Classic, DxO PhotoLab — réglages et métadonnées vont |
| | 42 | +systématiquement en sidecar séparé), un hash du fichier entier suffit : tout changement de hash |
| | 43 | +est une anomalie réelle. Pour le DNG et pour les masters TIFF/JPEG (scans, ou JPEG promu à la |
| | 44 | +racine du projet), ces mêmes outils écrivent légitimement les métadonnées et réglages directement |
| | 45 | +dans le fichier, sans sidecar — un hash du fichier entier y change donc à chaque édition de |
| | 46 | +métadonnées sans qu'il y ait ni corruption ni altération des pixels. Pour ces formats, Régine DOIT |
| | 47 | +fonder la détection d'anomalie sur un hash portant uniquement sur les données image (pixels), |
| | 48 | +stable à travers les éditions de métadonnées, en complément du hash fichier entier — jamais sur le |
| | 49 | +hash fichier entier seul, sous peine de signaler à tort chaque édition de métadonnées comme une |
| | 50 | +anomalie et d'éroder la confiance dans les signalements réels. |
| | 51 | + |
| 34 | **Rationale**: Une capture JPEG seule, ou un JPEG appairé à un RAW, peut être la seule version | 52 | **Rationale**: Une capture JPEG seule, ou un JPEG appairé à un RAW, peut être la seule version |
| 35 | existante d'une photo — l'appareil ne produit pas toujours de RAW, et l'utilisateur choisit | 53 | existante d'une photo — l'appareil ne produit pas toujours de RAW, et l'utilisateur choisit |
| 36 | parfois le mode JPEG seul. Traiter le JPEG comme un simple dérivé jetable du RAW risquerait de | 54 | parfois le mode JPEG seul. Traiter le JPEG comme un simple dérivé jetable du RAW risquerait de |
| 37 | -faire perdre des photos qui n'ont aucune autre copie. | 55 | +faire perdre des photos qui n'ont aucune autre copie. Quant au hash image-only pour DNG/TIFF/JPEG, |
| | 56 | +il découle du même comportement vérifié (2026-09-11, Lightroom Classic et DxO PhotoLab) : sans |
| | 57 | +lui, chaque édition légitime de métadonnées sur ces formats déclencherait une fausse alerte, ce qui |
| | 58 | +pousserait à terme à ignorer les signalements — l'exact inverse de l'objectif de ce principe. |
| 38 | | 59 | |
| 39 | ### II. Confirmation explicite avant toute action destructive | 60 | ### II. Confirmation explicite avant toute action destructive |
| 40 | Aucune suppression de fichier dans l'archive n'est automatique. Qu'elle provienne d'une anomalie | 61 | Aucune suppression de fichier dans l'archive n'est automatique. Qu'elle provienne d'une anomalie |
| @@ -55,6 +76,11 @@ versions dans le temps indépendamment de tout renommage ultérieur. Le nom de f |
| 55 | hors extension sert à apparier un RAW et son JPEG jumeau (même capture), mais ne fait jamais foi | 76 | hors extension sert à apparier un RAW et son JPEG jumeau (même capture), mais ne fait jamais foi |
| 56 | seul pour décider qu'un des deux fichiers est superflu. | 77 | seul pour décider qu'un des deux fichiers est superflu. |
| 57 | | 78 | |
| | 79 | +Pour DNG/TIFF/JPEG, ce hash de contenu se décline en deux niveaux à des fins distinctes : le hash |
| | 80 | +fichier entier identifie et dédoublonne comme pour tout autre format, tandis que le hash |
| | 81 | +image-only sert spécifiquement à distinguer une édition légitime de métadonnées d'une anomalie |
| | 82 | +réelle — cf. Principe I pour le détail de ce mécanisme. |
| | 83 | + |
| 58 | **Rationale**: Les noms de fichiers changent (renommage à l'import, déplacement entre dossiers de | 84 | **Rationale**: Les noms de fichiers changent (renommage à l'import, déplacement entre dossiers de |
| 59 | format) ; seul le contenu identifie fiablement une image dans la durée. | 85 | format) ; seul le contenu identifie fiablement une image dans la durée. |
| 60 | | 86 | |
| @@ -87,6 +113,14 @@ jamais assez fiable pour décider seule d'une réorganisation qui touche l'archi |
| 87 | - **Vérification d'intégrité systématique** : toute copie de fichier (import carte mémoire, | 113 | - **Vérification d'intégrité systématique** : toute copie de fichier (import carte mémoire, |
| 88 | checkout, réarchivage) DOIT être vérifiée par checksum avant que la source ne soit considérée | 114 | checkout, réarchivage) DOIT être vérifiée par checksum avant que la source ne soit considérée |
| 89 | comme sûre à effacer ou que la destination ne soit considérée comme fiable. | 115 | comme sûre à effacer ou que la destination ne soit considérée comme fiable. |
| | 116 | +- **Vérification périodique indépendante du checkout (scrub)** : la vérification faite à chaque |
| | 117 | + checkout/réarchivage ne couvre pas une corruption survenant pendant que l'archive dort sur le |
| | 118 | + NAS sans qu'on y touche (bit rot). Régine DOIT prévoir une tâche de vérification périodique (ex. |
| | 119 | + mensuelle) qui recalcule et compare les hash de l'archive, indépendamment de tout checkout. |
| | 120 | +- **Détection ne vaut pas réparation** : un hash, quel qu'il soit (fichier entier ou image-only), |
| | 121 | + détecte une corruption, il ne la répare jamais. La récupération DOIT reposer sur une copie saine |
| | 122 | + (règle 3-2-1 ci-dessous) ou un mécanisme de redondance/réparation dédié — jamais sur la seule |
| | 123 | + existence d'un hash. |
| 90 | - **Règle 3-2-1 comme référence** : toute fonctionnalité de sauvegarde ou d'export s'inscrit dans | 124 | - **Règle 3-2-1 comme référence** : toute fonctionnalité de sauvegarde ou d'export s'inscrit dans |
| 91 | la logique d'au moins 3 copies, sur 2 types de support différents, dont 1 hors site. | 125 | la logique d'au moins 3 copies, sur 2 types de support différents, dont 1 hors site. |
| 92 | | 126 | |
| @@ -95,7 +129,8 @@ jamais assez fiable pour décider seule d'une réorganisation qui touche l'archi |
| 95 | - **Séparation checkout / travail local / réconciliation** : Régine ne modifie jamais l'archive | 129 | - **Séparation checkout / travail local / réconciliation** : Régine ne modifie jamais l'archive |
| 96 | directement pendant une phase d'édition. L'archive n'est mise à jour qu'après une réconciliation | 130 | directement pendant une phase d'édition. L'archive n'est mise à jour qu'après une réconciliation |
| 97 | explicite, par hash, entre le manifeste de référence pris au checkout et l'état de la copie de | 131 | explicite, par hash, entre le manifeste de référence pris au checkout et l'état de la copie de |
| 98 | - travail. | 132 | + travail. Pour DNG/TIFF/JPEG, cette réconciliation DOIT comparer le hash image-only en plus du |
| | 133 | + hash fichier entier avant de qualifier un changement d'anomalie (cf. Principe I). |
| 99 | - **Verrouillage de projet** : un projet « checké out » DOIT être marqué comme tel côté archive, | 134 | - **Verrouillage de projet** : un projet « checké out » DOIT être marqué comme tel côté archive, |
| 100 | pour empêcher que deux instances ou deux personnes modifient la même archive en parallèle. | 135 | pour empêcher que deux instances ou deux personnes modifient la même archive en parallèle. |
| 101 | - **Traçabilité humaine hors application** : la convention de nommage lisible | 136 | - **Traçabilité humaine hors application** : la convention de nommage lisible |
| @@ -120,4 +155,4 @@ Chaque amendement DOIT inclure un rapport d'impact de synchronisation (Sync Impa |
| 120 | commentaire en tête du fichier, listant la version précédente, la nouvelle version, et les | 155 | commentaire en tête du fichier, listant la version précédente, la nouvelle version, et les |
| 121 | sections modifiées, ajoutées ou supprimées. | 156 | sections modifiées, ajoutées ou supprimées. |
| 122 | | 157 | |
| 123 | -**Version**: 2.0.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-09 | 158 | +**Version**: 2.1.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-11 |