Constitution du projet Régine
Core Principles
I. Fichier maître intouchable
Le fichier maître est défini par son rôle, pas automatiquement 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 jamais le modifier. Sont fichiers maîtres par défaut : tout RAW propriétaire,
tout TIFF ou BMP issu d'un scan. Un JPEG issu directement de l'appareil (jamais un export généré
depuis un RAW, qui reste un dérivé) est également fichier maître dans deux cas : lorsqu'il
constitue la seule capture pour cette prise de vue (mode JPEG seul, sans RAW correspondant) ; et,
même en mode RAW+JPEG, lorsque le photographe juge le JPEG satisfaisant pour l'usage prévu et ne
conserve le RAW que pour un usage secondaire (ex. un agrandissement futur qui demanderait plus de
latitude) — décision prise au cas par cas selon l'usage, jamais déduite automatiquement d'une
règle de format. Aucun fichier maître, quel que soit son format, n'est modifié une fois entré
dans l'archive. Toute modification détectée sur un fichier maître par rapport au manifeste de
référence (hash SHA-256, cf. workflow de réconciliation) DOIT être signalée à l'utilisateur comme
anomalie et ne DOIT JAMAIS être réarchivée silencieusement.
Ce statut de fichier maître ne retire aucune protection au fichier qui ne le porte pas dans une
paire RAW+JPEG. Un JPEG issu de l'appareil n'est jamais un simple dérivé jetable du RAW, qu'il
porte ou non le statut de fichier maître de la capture : certaines captures n'existent qu'en JPEG
et sont de ce fait irremplaçables ; et même quand un RAW reste la référence, le JPEG de la même
capture (même nom de fichier hors extension) demeure une version distincte de la photo, pas une
copie de secours. Réciproquement, quand le JPEG est désigné fichier maître, le RAW conservé en
complément n'est pas pour autant jetable. Régine ne DOIT JAMAIS supprimer ou modifier l'un au
seul prétexte que l'autre existe ou porte le statut de fichier maître (cf. Principe II, qui
applique cette protection à l'identique aux deux, indépendamment du statut). Seuls les dérivés
créés par l'utilisateur après capture (exports web, retouches enregistrées à part, sidecars
XMP/DOP) peuvent être créés ou modifiés librement.
Le mécanisme de détection d'une modification dépend du format, et cette dépendance ne relâche en
rien l'interdiction ci-dessus. Pour les RAW propriétaires (RAF, CR2, NEF, ARW...), jamais réécrits
par les outils d'édition courants (Lightroom Classic, DxO PhotoLab — réglages et métadonnées vont
systématiquement en sidecar séparé), un hash du fichier entier suffit : tout changement de hash
est une anomalie réelle. Pour le DNG et pour les masters TIFF/JPEG (scans, ou JPEG promu à la
racine du projet), ces mêmes outils écrivent légitimement les métadonnées et réglages directement
dans le fichier, sans sidecar — un hash du fichier entier y change donc à chaque édition de
métadonnées sans qu'il y ait ni corruption ni altération des pixels. Pour ces formats, Régine DOIT
fonder la détection d'anomalie sur un hash portant uniquement sur les données image (pixels),
stable à travers les éditions de métadonnées, en complément du hash fichier entier — jamais sur le
hash fichier entier seul, sous peine de signaler à tort chaque édition de métadonnées comme une
anomalie et d'éroder la confiance dans les signalements réels.
Rationale: Une capture JPEG seule, ou un JPEG appairé à un RAW, peut être la seule version
existante d'une photo — l'appareil ne produit pas toujours de RAW, et l'utilisateur choisit
parfois le mode JPEG seul, ou juge le JPEG suffisant pour l'usage prévu même quand un RAW existe.
Fixer le statut de fichier maître au format plutôt qu'au rôle empêcherait de refléter ce choix réel
du photographe, sans pour autant justifier de traiter l'un des deux fichiers comme jetable : les
deux restent protégés, seul le rôle de référence peut se déplacer. Quant au hash image-only pour
DNG/TIFF/JPEG, il découle du même comportement vérifié (2026-09-11, Lightroom Classic et DxO
PhotoLab) : sans lui, chaque édition légitime de métadonnées sur ces formats déclencherait une
fausse alerte, ce qui pousserait à terme à ignorer les signalements — l'exact inverse de l'objectif
de ce principe.
II. Confirmation explicite avant toute action à risque
Toute action à risque — écriture sur l'archive, suppression, restauration, écrasement, ou plus
largement toute opération qui modifie l'état persistant de l'archive (portée élargie le
2026-09-18 au-delà de la seule suppression) — DOIT toujours être présentée à l'utilisateur avec un
résumé clair, puis validée explicitement avant d'être exécutée. Cette règle s'applique à
l'identique quelle que soit la façade qui déclenche l'action (CLI, GUI, agent IA) et quelle que
soit la formulation de la demande : une phrase à l'impératif ("supprime X", "archive ce dossier")
reste soumise à confirmation dès lors qu'elle déclenche une écriture. Une action sans risque
(recherche, consultation, prévisualisation, comptage) peut en revanche s'exécuter directement,
sans demander la permission préalable de chercher.
Cette protection s'applique à l'identique aux RAW et aux JPEG pour toute suppression : l'existence
d'un fichier maître de l'autre type ou statut (cf. Principe I) sous le même nom ne justifie jamais
une suppression automatique. Face à une anomalie ambiguë (ex. un fichier maître disparu de la
copie de travail), l'utilisateur choisit lui-même entre les options possibles — confirmer la
suppression dans l'archive, ou restaurer le fichier depuis l'archive — aucune façade ne DOIT
trancher à sa place.
Rationale: Une archive qui perd ou modifie des fichiers sans confirmation humaine perd la
confiance qui justifie son existence. Étendre cette exigence à toute façade, agent IA compris,
évite que la protection dépende du canal utilisé pour piloter Régine plutôt que de la nature de
l'opération.
III. Identité par contenu, jamais par nom de fichier seul
La détection des renommages, déplacements, doublons et promotions (ex. capture promue à la racine
du projet) DOIT s'appuyer sur le hash de contenu (SHA-256) comme source de vérité, jamais sur le
nom de fichier ou le chemin seuls. L'identifiant pérenne attribué à chaque image relie ses
versions dans le temps indépendamment de tout renommage ultérieur. Le nom de fichier identique
hors extension sert à apparier un RAW et son JPEG jumeau (même capture), mais ne fait jamais foi
seul pour décider qu'un des deux fichiers est superflu.
Pour DNG/TIFF/JPEG, ce hash de contenu se décline en deux niveaux à des fins distinctes : le hash
fichier entier identifie et dédoublonne comme pour tout autre format, tandis que le hash
image-only sert spécifiquement à distinguer une édition légitime de métadonnées d'une anomalie
réelle — cf. Principe I pour le détail de ce mécanisme.
Rationale: Les noms de fichiers changent (renommage à l'import, déplacement entre dossiers de
format) ; seul le contenu identifie fiablement une image dans la durée.
IV. Métadonnées ouvertes et embarquées
Les métadonnées descriptives, administratives et de droits (légende, mots-clés, personnes,
crédit, copyright, licence) DOIVENT s'appuyer sur les standards ouverts IPTC/XMP embarqués dans
le fichier, complétés par les données techniques EXIF. Régine ne DOIT PAS faire dépendre ces
informations d'une base de données propriétaire séparée du fichier.
Rationale: Des métadonnées embarquées dans le fichier survivent aux copies, aux transferts et
à un éventuel changement d'outil ou d'application ; une base séparée ne le garantit pas.
V. L'utilisateur décide, Régine suggère
Toute détection automatique à caractère ambigu ou irréversible — découpage d'un import en
plusieurs projets, mise en avant d'un événement dans une plage de dates, association RAW+JPEG en
cas de collision — DOIT être présentée comme suggestion modifiable, jamais appliquée d'autorité.
La décision finale revient toujours à l'utilisateur.
Rationale: Une détection automatique basée sur des horodatages ou des heuristiques n'est
jamais assez fiable pour décider seule d'une réorganisation qui touche l'archive.
VI. Bibliothèque centrale, façades minces
Toute la logique métier de Régine (import, checkout/réconciliation, structure de dossier,
métadonnées, intégrité, profil de boîtiers) DOIT vivre dans une bibliothèque centrale unique. La
CLI, la GUI et l'agent IA sont des façades minces au-dessus de cette bibliothèque : elles
appellent les mêmes modules et formatent le résultat pour leur canal, sans dupliquer ni
réinventer de logique métier — en particulier, aucune façade ne DOIT recalculer une classification
de changement, un critère d'anomalie ou une règle de nommage déjà tranchés par la bibliothèque. La
bibliothèque DOIT renvoyer des objets structurés (comptes, listes, diffs typés), jamais du texte
déjà formaté pour un terminal, pour qu'une façade n'ait jamais à parser une sortie ni à deviner un
chiffre.
Rationale: Les enchaînements de décisions de Régine (destinations d'un import, classification
à la réconciliation, structure par format) sont trop fins pour être ré-implémentés
indépendamment par chaque interface sans diverger tôt ou tard ; une bibliothèque unique garantit
que CLI, GUI et agent IA se comportent identiquement pour une même situation.
Contraintes techniques
- CLI-first : chaque fonctionnalité DOIT être exposée via une interface en ligne de commande
avant toute interface graphique éventuelle, avec un protocole texte in/out (arguments/stdin →
stdout, erreurs → stderr). - Formats ouverts et documentés : Régine privilégie systématiquement les formats ouverts et
documentés (RAW documentés, TIFF) aux formats propriétaires ou peu utilisés (ex. BMP), avec une
migration planifiée quand un format devient obsolète. - Vérification d'intégrité systématique : toute copie de fichier (import carte mémoire,
checkout, réarchivage) DOIT être vérifiée par checksum avant que la source ne soit considérée
comme sûre à effacer ou que la destination ne soit considérée comme fiable. - Vérification périodique indépendante du checkout (scrub) : la vérification faite à chaque
checkout/réarchivage ne couvre pas une corruption survenant pendant que l'archive dort sur le
NAS sans qu'on y touche (bit rot). Régine DOIT prévoir une tâche de vérification périodique (ex.
mensuelle) qui recalcule et compare les hash de l'archive, indépendamment de tout checkout. - Détection ne vaut pas réparation : un hash, quel qu'il soit (fichier entier ou image-only),
détecte une corruption, il ne la répare jamais. La récupération DOIT reposer sur une copie saine
(règle 3-2-1 ci-dessous) ou un mécanisme de redondance/réparation dédié — jamais sur la seule
existence d'un hash. - Règle 3-2-1 comme référence : toute fonctionnalité de sauvegarde ou d'export s'inscrit dans
la logique d'au moins 3 copies, sur 2 types de support différents, dont 1 hors site. Précision du
2026-09-18 : le NAS et le stockage cloud ne comptent que pour 2 copies — l'ordinateur du
photographe ne conserve que des checkouts partiels et temporaires, jamais une copie complète de
l'archive, donc il ne compte jamais comme copie au sens de cette règle. La troisième copie DOIT
être un support physique dédié (ex. disque de sauvegarde local), régulièrement synchronisé avec
le NAS, sur un support différent du NAS et du cloud. - Exécution sans démon : la bibliothèque centrale (cf. Principe VI) s'exécute en import direct,
un seul processus par lancement, pour la CLI comme pour la GUI — pas de service/démon permanent
à installer, gérer ou superviser. La concurrence multi-instances est couverte par le verrou de
checkout (cf. Workflow d'archivage), qui joue ce rôle sans complexité de déploiement
supplémentaire.
Workflow d'archivage
- Séparation checkout / travail local / réconciliation : Régine ne modifie jamais l'archive
directement pendant une phase d'édition. L'archive n'est mise à jour qu'après une réconciliation
explicite, par hash, entre le manifeste de référence pris au checkout et l'état de la copie de
travail. Pour DNG/TIFF/JPEG, cette réconciliation DOIT comparer le hash image-only en plus du
hash fichier entier avant de qualifier un changement d'anomalie (cf. Principe I). - Verrouillage de projet : un dossier « checké out » DOIT être marqué comme tel côté archive,
pour empêcher que deux instances ou deux personnes modifient la même archive en parallèle. - Traçabilité humaine hors application : la convention de nommage lisible
(date_titre_nomOrigine) est maintenue en complément de l'identifiant pérenne, pour que
l'archive reste compréhensible même ouverte dans dix ans sans Régine. - Projets composés par copie, traçables : un projet (livre, sélection thématique) est un
répertoire de travail distinct de la hiérarchie dossier/sous-dossier/dossier parent de
l'archive — jamais rattaché à celle-ci, jamais mis à jour par lien ou déplacement. Il est
composé par copie vérifiée par checksum, à l'identique de tout autre transfert (cf.
Vérification d'intégrité systématique). Chaque copie DOIT être accompagnée d'une fiche de
provenance (dossier source, identifiant pérenne, nom d'origine) enregistrée au moment de la
copie, pour que le fichier copié reste traçable vers son fichier maître d'origine même après un
travail de retouche non destructif.
Governance
Cette constitution prévaut sur toute pratique de développement ponctuelle ou préférence
individuelle. Toute spécification (/speckit-specify), tout plan (/speckit-plan) et toute tâche
(/speckit-tasks) DOIT être conforme à ces principes avant d'être implémenté.
Toute complexité d'implémentation qui contredit un principe DOIT être justifiée explicitement dans
le plan correspondant ; à défaut, le plan DOIT être simplifié pour s'y conformer.
Les amendements à cette constitution suivent le versionnage sémantique :
- MAJOR : suppression ou redéfinition incompatible d'un principe existant.
- MINOR : ajout d'un principe ou d'une section, ou renforcement matériel d'une exigence.
- PATCH : clarification, reformulation, correction sans changement de sens.
Chaque amendement DOIT inclure un rapport d'impact de synchronisation (Sync Impact Report) en
commentaire en tête du fichier, listant la version précédente, la nouvelle version, et les
sections modifiées, ajoutées ou supprimées.
Version: 2.2.0 | Ratified: 2026-09-09 | Last Amended: 2026-09-18
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 |
|