Interface agent IA : principes d'interaction avec Régine

Premier draft (2026-09-11). Définit comment un agent IA (assistant conversationnel) pilote Régine à la demande de l'utilisateur, en complément de la CLI et de la GUI décrites dans interface-cli-gui-architecture.md.

1. Position dans l'architecture

L'agent IA est une quatrième façade au-dessus de la bibliothèque centrale, au même titre que la CLI et la (future) GUI — pas un système parallèle avec sa propre logique. Il ne réinvente ni la classification des changements à la réconciliation, ni les règles de nommage, ni les critères d'anomalie : il appelle les mêmes modules (import, archive, dossier, integrity, metadata, camera_profile) et reformule leurs résultats en langage naturel.

Conséquence pour la bibliothèque : ses fonctions doivent renvoyer des objets structurés (comptes, listes, diffs typés) plutôt que du texte déjà formaté pour un terminal. L'agent construit son résumé à partir de ces données ; il ne doit jamais avoir à parser une sortie texte de la CLI ni à deviner un chiffre.

2. Principe cardinal : aucune action à risque sans confirmation explicite

Ce principe existe déjà dans la bibliothèque (section 9 des notes d'archivage : une suppression n'est "jamais propagée automatiquement", une anomalie n'est "jamais archivée silencieusement"). L'agent hérite de cette règle, il ne l'ajoute pas :

Action à risque (écriture sur l'archive NAS, suppression, restauration, écrasement, tout ce qui modifie l'état persistant) → toujours un point de pause avec résumé clair, puis attente d'une réponse explicite de l'utilisateur avant d'exécuter.
Action sans risque (recherche, consultation, prévisualisation, comptage) → peut s'exécuter directement ; l'agent rapporte ce qu'il a trouvé, sans demander la permission de chercher.

Ce qui distingue une demande "à risque" d'une demande anodine, c'est la nature de l'opération dans la bibliothèque, pas la formulation de l'utilisateur — une phrase à l'impératif ("crée le dossier...") reste soumise à confirmation si elle déclenche une écriture.

3. Format de réponse : court, concret, actionnable

L'agent ne doit pas exposer le fonctionnement interne (hash, réconciliation, manifeste) sauf quand ce détail est justement ce que l'utilisateur doit trancher (cas d'anomalie, section 5). Dans le cas normal, une réponse tient en une à trois phrases :

Ce qui va être fait, en langage courant.
Les chiffres qui permettent de décider (nombre de fichiers, taille, liste si elle est courte).
Une question fermée appelant une réponse oui/non ou un choix parmi options nommées.

Pas de jargon technique, pas de rappel des règles de l'architecture, pas de pavé explicatif — l'utilisateur doit pouvoir lire et décider en quelques secondes.

4. Cas type 1 : commande de composition/création

Exemple — reprend le cas "Bestof" déjà anticipé en section 14 des notes d'archivage (copie inter-dossiers pour composer un nouveau projet autonome) :

Utilisateur : Crée un projet avec les copies des photos 5 étoiles de 2025.

Régine : Je crée le projet 2025_Best_of avec les fichiers 5 étoiles de l'année 2025. 47 photos concernées, réparties sur 6 dossiers sources (voir liste). On y va ?

Ce que l'agent fait sous le capot, sans le dire sauf si on lui demande : recherche inter-dossiers par critère de sélection et date, copie vérifiée par checksum, fiche de provenance enregistrée dans la base du nouveau projet (section 14). L'utilisateur n'a pas besoin de connaître ce mécanisme pour valider la demande — seulement le résultat et son ampleur.

Si la liste est longue, l'agent la résume (ex. par dossier source) plutôt que d'énumérer 47 noms de fichiers ; le détail complet reste disponible sur demande ("montre-moi la liste complète").

5. Cas type 2 : anomalie détectée pendant l'archivage

Exemple — reprend le cas de réconciliation anormale (section 9 : "hash RAW/JPEG changé sous le même nom → anomalie... à signaler, jamais archivé silencieusement") :

Utilisateur : Archive le dossier XXX.

Régine : Archivage de XXX : j'ai détecté des effacements de fichiers maîtres. Ça ne devrait normalement pas arriver. Voici les fichiers concernés — je ne les pousse pas sans votre accord. Deux choix : je confirme la suppression dans l'archive, ou je restaure ces fichiers maîtres depuis l'archive pour remplacer ce qui a disparu en local. Qu'est-ce que je fais ?

Points à respecter dans ce cas :

L'agent ne choisit jamais à la place de l'utilisateur entre confirmer et restaurer — l'anomalie reste une anomalie humaine à trancher, comme le prévoit déjà la bibliothèque.
La liste des fichiers concernés doit être visible ou accessible en un mot ("montre-moi"), pas seulement comptée — contrairement au cas 1, ici chaque fichier peut avoir son importance individuelle.
Le ton reste factuel, jamais alarmiste : on signale une anomalie, on ne fait pas la morale.
Tant que l'utilisateur n'a pas répondu, rien n'est écrit sur le NAS.

6. Autres cas à couvrir (à étoffer)

Import carte mémoire en langage naturel ("importe cette carte, c'est la suite du voyage à Kotor") → l'agent doit quand même faire confirmer la destination et le titre proposé (section 10, point 4) avant de renommer/pousser quoi que ce soit, même si la demande initiale semblait déjà trancher.
Restauration ciblée d'un fichier retrouvé par recherche (mode consultation de l'archive, cf. interface-cli-gui-architecture.md § GUI, mode 2) → confirmation avant d'écrire en local, léger mais toujours explicite.
Rapport de scrub périodique (section 12) → résumé des anomalies détectées sur la dernière vérification, formaté selon les mêmes règles de concision ; pas d'action automatique, juste un signalement suivi d'options.
Questions de droits/licence → réponse directe à partir des métadonnées, sans action à confirmer (lecture seule).

7. Ce qui reste à trancher

Canal d'accès : agent intégré à la CLI (wrapper autour des mêmes commandes), à la GUI, ou assistant séparé qui appelle la bibliothèque directement.
Forme exacte des objets retournés par la bibliothèque pour que l'agent construise ses résumés sans recalculer ni halluciner de chiffres (contrat d'interface à définir module par module).
Persistance de la confirmation : si l'utilisateur ne répond pas tout de suite, l'action proposée doit-elle expirer, rester en attente, ou redemander confirmation à la reprise ?

 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


# Interface agent IA : principes d'interaction avec Régine

Premier draft (2026-09-11). Définit comment un agent IA (assistant conversationnel) pilote Régine à la demande de l'utilisateur, en complément de la CLI et de la GUI décrites dans `interface-cli-gui-architecture.md`.

## 1. Position dans l'architecture

L'agent IA est une **quatrième façade** au-dessus de la bibliothèque centrale, au même titre que la CLI et la (future) GUI — pas un système parallèle avec sa propre logique. Il ne réinvente ni la classification des changements à la réconciliation, ni les règles de nommage, ni les critères d'anomalie : il appelle les mêmes modules (`import`, `archive`, `dossier`, `integrity`, `metadata`, `camera_profile`) et reformule leurs résultats en langage naturel.

Conséquence pour la bibliothèque : ses fonctions doivent renvoyer des **objets structurés** (comptes, listes, diffs typés) plutôt que du texte déjà formaté pour un terminal. L'agent construit son résumé à partir de ces données ; il ne doit jamais avoir à parser une sortie texte de la CLI ni à deviner un chiffre.

## 2. Principe cardinal : aucune action à risque sans confirmation explicite

Ce principe existe déjà dans la bibliothèque (section 9 des notes d'archivage : une suppression n'est "jamais propagée automatiquement", une anomalie n'est "jamais archivée silencieusement"). L'agent hérite de cette règle, il ne l'ajoute pas :

- **Action à risque** (écriture sur l'archive NAS, suppression, restauration, écrasement, tout ce qui modifie l'état persistant) → toujours un point de pause avec résumé clair, puis attente d'une réponse explicite de l'utilisateur avant d'exécuter.
- **Action sans risque** (recherche, consultation, prévisualisation, comptage) → peut s'exécuter directement ; l'agent rapporte ce qu'il a trouvé, sans demander la permission de chercher.

Ce qui distingue une demande "à risque" d'une demande anodine, c'est la nature de l'opération dans la bibliothèque, pas la formulation de l'utilisateur — une phrase à l'impératif ("crée le dossier...") reste soumise à confirmation si elle déclenche une écriture.

## 3. Format de réponse : court, concret, actionnable

L'agent ne doit pas exposer le fonctionnement interne (hash, réconciliation, manifeste) sauf quand ce détail est justement ce que l'utilisateur doit trancher (cas d'anomalie, section 5). Dans le cas normal, une réponse tient en une à trois phrases :

1. **Ce qui va être fait**, en langage courant.
2. **Les chiffres qui permettent de décider** (nombre de fichiers, taille, liste si elle est courte).
3. **Une question fermée** appelant une réponse oui/non ou un choix parmi options nommées.

Pas de jargon technique, pas de rappel des règles de l'architecture, pas de pavé explicatif — l'utilisateur doit pouvoir lire et décider en quelques secondes.

## 4. Cas type 1 : commande de composition/création

Exemple — reprend le cas "Bestof" déjà anticipé en section 14 des notes d'archivage (copie inter-dossiers pour composer un nouveau projet autonome) :

> **Utilisateur** : Crée un projet avec les copies des photos 5 étoiles de 2025.
>
> **Régine** : Je crée le projet `2025_Best_of` avec les fichiers 5 étoiles de l'année 2025. 47 photos concernées, réparties sur 6 dossiers sources (voir liste). On y va ?

Ce que l'agent fait sous le capot, sans le dire sauf si on lui demande : recherche inter-dossiers par critère de sélection et date, copie vérifiée par checksum, fiche de provenance enregistrée dans la base du nouveau projet (section 14). L'utilisateur n'a pas besoin de connaître ce mécanisme pour valider la demande — seulement le résultat et son ampleur.

Si la liste est longue, l'agent la résume (ex. par dossier source) plutôt que d'énumérer 47 noms de fichiers ; le détail complet reste disponible sur demande ("montre-moi la liste complète").

## 5. Cas type 2 : anomalie détectée pendant l'archivage

Exemple — reprend le cas de réconciliation anormale (section 9 : "hash RAW/JPEG changé sous le même nom → anomalie... à signaler, jamais archivé silencieusement") :

> **Utilisateur** : Archive le dossier XXX.
>
> **Régine** : Archivage de XXX : j'ai détecté des effacements de fichiers maîtres. Ça ne devrait normalement pas arriver. Voici les fichiers concernés — je ne les pousse pas sans votre accord. Deux choix : je confirme la suppression dans l'archive, ou je restaure ces fichiers maîtres depuis l'archive pour remplacer ce qui a disparu en local. Qu'est-ce que je fais ?

Points à respecter dans ce cas :

- L'agent **ne choisit jamais à la place de l'utilisateur** entre confirmer et restaurer — l'anomalie reste une anomalie humaine à trancher, comme le prévoit déjà la bibliothèque.
- La liste des fichiers concernés doit être visible ou accessible en un mot ("montre-moi"), pas seulement comptée — contrairement au cas 1, ici chaque fichier peut avoir son importance individuelle.
- Le ton reste factuel, jamais alarmiste : on signale une anomalie, on ne fait pas la morale.
- Tant que l'utilisateur n'a pas répondu, rien n'est écrit sur le NAS.

## 6. Autres cas à couvrir (à étoffer)

- **Import carte mémoire en langage naturel** ("importe cette carte, c'est la suite du voyage à Kotor") → l'agent doit quand même faire confirmer la destination et le titre proposé (section 10, point 4) avant de renommer/pousser quoi que ce soit, même si la demande initiale semblait déjà trancher.
- **Restauration ciblée** d'un fichier retrouvé par recherche (mode consultation de l'archive, cf. `interface-cli-gui-architecture.md` § GUI, mode 2) → confirmation avant d'écrire en local, léger mais toujours explicite.
- **Rapport de scrub périodique** (section 12) → résumé des anomalies détectées sur la dernière vérification, formaté selon les mêmes règles de concision ; pas d'action automatique, juste un signalement suivi d'options.
- **Questions de droits/licence** → réponse directe à partir des métadonnées, sans action à confirmer (lecture seule).

## 7. Ce qui reste à trancher

- Canal d'accès : agent intégré à la CLI (wrapper autour des mêmes commandes), à la GUI, ou assistant séparé qui appelle la bibliothèque directement.
- Forme exacte des objets retournés par la bibliothèque pour que l'agent construise ses résumés sans recalculer ni halluciner de chiffres (contrat d'interface à définir module par module).
- Persistance de la confirmation : si l'utilisateur ne répond pas tout de suite, l'action proposée doit-elle expirer, rester en attente, ou redemander confirmation à la reprise ?