Éléments clés de l'archivage professionnel des photos
Notes de recherche sur les pratiques d'archivage utilisées pour les collections de grands photographes (Magnum Photos, ICP, Getty, archives nationales), pertinentes pour la conception de l'appli "Régine" (gestion de photos, open source, usage CLI).
1. Organisation dès la source
- Trier et organiser tôt, pas après des décennies de fichiers en vrac.
- Hiérarchie à trois niveaux : brut (toutes les images) → sélection/planche-contact (meilleures images repérées) → édition finale (retenues pour publication/exposition).
- Piste appli : permettre de marquer des niveaux de sélection sur les photos, pas juste les stocker.
2. Métadonnées normalisées
- Standard de référence : IPTC Photo Metadata, champs administratifs, descriptifs et de droits.
- S'appuie sur XMP (intégré au fichier) et complète l'EXIF (données techniques : appareil, objectif, exposition).
- Champs typiques : légende/description, mots-clés, lieu, personnes identifiées, crédit photographe, copyright, conditions de licence.
- Intérêt de stocker les métadonnées dans le fichier lui-même : elles survivent aux copies, transferts, changements d'outils.
3. Identifiant unique et nommage
- Chaque image a un identifiant pérenne (numéro de négatif/planche/rouleau) qui ne change jamais, indépendant du nom de fichier.
- Permet de relier les différentes versions d'une même image (scan brut, retouche, tirage) dans le temps.
- 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.
- 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.
4. Formats et pérennité des fichiers
- 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 :
- RAW ou TIFF non compressé : fichier maître par défaut.
- 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.
- 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.
- 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.
- Préférence pour des formats ouverts et documentés plutôt que propriétaires.
- Migrations périodiques planifiées quand un format devient obsolète.
- 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.
5. Sauvegarde et intégrité
- Règle 3-2-1 : au moins 3 copies, sur 2 types de support différents, dont 1 hors site.
- 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.
- Vérification d'intégrité par checksums pour détecter la corruption silencieuse dans le temps.
- 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.
6. Gestion des droits
- Copyright, autorisations d'usage, contrats de licence attachés à chaque image/lot.
- Traçabilité claire : qui a le droit d'utiliser quoi, pour quel usage, jusqu'à quand.
7. Contexte et documentation
- Conserver le contexte au-delà des images : notes de terrain, correspondance, interviews, planches-contact originales.
- Raconte comment le travail a été fait, pas seulement son résultat.
8. Workflow d'édition sécurisé : checkout / réconciliation (NAS comme serveur d'archives)
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.
Principe : Régine gère elle-même l'aller-retour entre l'archive (sur le NAS) et un espace de travail local, avec réconciliation par contenu (hash) avant tout réarchivage. Ça évite d'avoir à bricoler des permissions par extension : l'archive NAS reste un partage normal, et la protection vient du fait que seule Régine lit/écrit l'archive, de façon médiée.
Déroulé :
- 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.
- 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.
- Réconciliation avant réarchivage : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier :
- hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement.
- 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.
- 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.
- 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.
- 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).
- 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.
Points à anticiper pour l'implémentation :
- Espace disque local suffisant pour la copie de travail (un dossier RAW peut peser plusieurs dizaines de Go).
- Temps de transfert réseau au moment du checkout.
- 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.
- 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.
9. Import depuis une carte mémoire
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.
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).
Séquence retenue :
- 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).
- 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.- 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é.
- 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.
- 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.
- 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 :
- Nouveau dossier simple : comportement par défaut, structure à un seul niveau.
- 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.
- 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.
- 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.
- 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.
- 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 :- 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 moisYYYY-MM-DD-DD_Titre(ex.2026-08-11-20_Vacances_Alsace) ; une plage à cheval sur deux mois/années en forme complèteYYYY-MM-DD_YYYY-MM-DD_Titre(la forme compacte ne fonctionne que dans le même mois). - 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). - 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.
- 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.
- 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.
- dossier simple ou étape d'un voyage : un jour unique
- Renommage des fichiers une fois le titre choisi, juste avant le push vers l'archive (le fichier arrive donc déjà sous son nom définitif) : chaque RAW est renommé en
date_titre_nomOrigine.ext, en conservant le nom d'origine donné par l'appareil en suffixe (ex.RD1234.RAF→2026-09-01_Paris_RD1234.RAF). Ça donne un nom de fichier auto-descriptif, lisible même en dehors de l'application, tout en gardant la traçabilité de l'ordre de prise de vue au sein d'un même boîtier.- Fichiers associés : tout fichier partageant le même nom de base que le RAW (JPEG en mode RAW+JPEG, sidecar XMP/DOP) est renommé en même temps et de façon synchronisée, pour ne pas casser l'appariement.
- Désambiguïsation entre boîtiers : le compteur de nom de fichier est propre à chaque appareil, donc deux boîtiers différents (ou le même après un reset) peuvent produire le même nom d'origine.
- 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 auBodySerialNumber. Ç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. - 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
Modelseul 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. - 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).
- Mécanisme principal : le profil de boîtiers déclaré par l'utilisateur (voir en tête de section), comparé au tag EXIF
- 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é.
- 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).
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.
10. Structure d'un dossier, sélection et déchets évidents
Structure retenue pour un dossier (après plusieurs itérations) :
- 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/etjpeg/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. raw/est une catégorie fonctionnelle qui regroupe toutes les extensions RAW (.RAF,.CR2,.NEF,.ARW...), pas un format unique — contrairement àjpeg/ettiff/, qui correspondent chacun à une extension précise.- 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é.
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.
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.
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.
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.
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.
Deux catégories de fichiers non retenus, deux traitements différents. Ne pas tout mettre dans le même panier :
- 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.
- 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.
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.
Limites observées avec DxO PhotoLab, à corriger dans Régine :
- 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.
- 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.
11. Modification des fichiers par les outils d'édition : quand le "fichier maître jamais modifié" tient vraiment
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.
RAW propriétaires (RAF, CR2, NEF, ARW...) : ni Lightroom Classic ni DxO PhotoLab ne réécrivent le fichier RAW original. Les réglages de développement et les métadonnées vont systématiquement dans des sidecars séparés — .xmp (+ .acr pour les réglages avancés récents type masques/débruitage IA) côté Lightroom, .dop (réglages) + .xmp (métadonnées) côté DxO. Le hash du fichier entier reste donc un indicateur fiable d'intégrité pour ces formats : un changement de hash = anomalie réelle.
Point clé, à garder en tête pour toute la suite : le développement RAW est non destructif par nature. Recadrage, exposition, étalonnage — tout ça reste une "recette" de rendu stockée en métadonnées (sidecar ou embarquées), jamais appliquée aux données image elles-mêmes. Ça vaut aussi bien pour un RAW propriétaire que pour un DNG, et pour un JPEG/TIFF traité en non destructif dans DxO/Lightroom (par opposition à un écrasement direct du fichier, qui n'est jamais la façon dont Régine ou ces outils fonctionnent par défaut). Conséquence directe : le fichier maître garde le même contenu pixel — et donc peut être suivi par checksum indéfiniment — quel que soit le nombre de fois où il est retravaillé, tant que ce travail passe par un sidecar/des métadonnées et non par une réécriture directe des pixels.
Exceptions à surveiller, pertinentes pour un boîtier qui produit du DNG (ex. Ricoh GR III) et pour les scans TIFF :
- 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.
- 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.
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 :
- 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. - Solution plus robuste et indépendante du boîtier :
ImageDataHashd'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 APIImageHashType:
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.exiftool -api ImageHashType=SHA256 -ImageDataHash fichier.dng
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).
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.
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 :
- Restaurer depuis une copie saine (règle 3-2-1, section 5).
- 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.
- 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.
12. Manifeste persistant par dossier et compatibilité de format entre versions de Régine
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.
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).
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 :
PRAGMA user_version— un entier libre, à utiliser comme numéro de version du schéma de Régine.PRAGMA application_id— un identifiant numérique enregistré publiquement auprès du projet SQLite pour marquer "ce fichier appartient au format de Régine" (permet à un outil externe, ou àfile, de reconnaître le format).
L'intérêt sur un fichier de version séparé (l'idée initiale d'un Regine.json distinct pour la version) : la version et les données qu'elle décrit ne peuvent jamais se désynchroniser, puisqu'elles vivent dans le même fichier, écrit de façon atomique.
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) :
- changement additif (nouveau champ optionnel) → une version plus ancienne de Régine peut l'ignorer et continuer à fonctionner normalement ;
- 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.
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.
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 —
- 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) ;
- 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.
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 :
- 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.
- 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 (
ATTACHde l'ancienne base,INSERT ... SELECT, suppression de l'ancien fichier) — un coût ponctuel et transactionnel, pas une migration fragile.
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.
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.
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.
13. Copie inter-dossiers pour composer un nouveau projet (livre, sélection thématique)
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.
Pourquoi la copie plutôt qu'une référence (lien symbolique, lien physique) :
- 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.
- 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é.
- 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.
- 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é.
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 :
- RAW propriétaires et JPEG/TIFF traités comme masters : le hash du fichier entier reste stable, retouche comprise.
- 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.
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à.
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.
Piste à vérifier avant de construire un mécanisme maison pour ce cas résiduel : un standard existant pourrait déjà le couvrir. Le schéma XMP Media Management (xmpMM) définit des champs prévus exactement pour ça : DocumentID (identifiant commun à toutes les versions/rendus d'une ressource), OriginalDocumentID (garde la référence du tout premier fichier source, même après plusieurs conversions de format) et DerivedFrom (référence explicite vers le document dont un fichier est dérivé). Lightroom renseigne ces champs automatiquement à l'export d'un dérivé depuis un RAW. Reste à vérifier si DxO PhotoLab fait de même (pas trouvé de confirmation aussi nette pour DxO) — test simple sur un export réel :
exiftool -DocumentID -OriginalDocumentID -DerivedFrom fichier_exporte.tiff
Si DxO renseigne ces champs, Régine n'a pas besoin d'écrire son propre identifiant pérenne pour ce cas : il suffit de lire ce que l'outil d'édition a déjà écrit. L'identifiant pérenne maison (section 3) resterait pertinent seulement si ce test ne donne rien.
Deux mécanismes à prévoir pour la traçabilité, indépendamment du résultat de cette vérification :
- 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.
- 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é.
Pistes de fonctionnalités pour Régine
- Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison.
- Identifiant pérenne par photo, indépendant du nom de fichier — à construire seulement si la vérification du standard XMP
DerivedFrom/OriginalDocumentIDsur 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. - Notion de fichier maître vs dérivés.
- Détection de doublons / vérification d'intégrité par checksum.
- Gestion de niveaux de sélection (brut / sélection / édition finale).
- Champs de droits/licence par photo ou par lot.
- 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.
- 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. - 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/ étapesYYYY-MM-DD_Titre_Lieu), et transformation a posteriori d'un dossier simple en sous-dossier — cf. section 9. - 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. - 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. - 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. - Manifeste persistant en base SQLite unique à la racine du dossier principal (parent + sous-dossiers), avec numéro de format via
PRAGMA user_version/application_iddistinguant 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. - 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.
Sources
- Photo Metadata IPTC
- IPTC Photo Metadata User Guide
- A Guide to Working with Archives — Magnum Photos
- Metadata Standards and Tools for Digital Photography — Library of Congress
- 3-2-1 Backup Rule — Permanent.org
- Negatives and Transparencies storage — U.S. National Archives
- Camera serial numbers — the EXIF fields that link photos to a specific body
- Lightroom Classic — Save metadata to external sidecar files (Adobe)
- DxO Forum — Exact rules for the creation and use of sidecar files
- DNG Confusion from an Experienced User — Lightroom Queen Forums
- Digital Negative (DNG) Specification 1.6.0.0 — Adobe
- ExifTool ImageDataHash — exiftool-vendored.js (PhotoStructure)
- Image::ExifTool — API options incl. ImageHashType — metacpan.org
- SQLite — LoC Recommended Storage Format
- SQLite as an Application File Format
- SQLite PRAGMA statements (user_version, application_id)
- SQLite — ATTACH DATABASE
- XMP Media Management namespace — Adobe Developer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 |
|