1 files changed, 54 insertions, 1 deletions
diff --git a/docs/fr/source/principes.rst b/docs/fr/source/principes.rst
index e3caaa1c9..22ca5004f 100644
--- a/docs/fr/source/principes.rst
+++ b/docs/fr/source/principes.rst
@@ -97,11 +97,64 @@ Par ailleurs au niveau de la configuration d'instance Ishtar un certain de nombr
 Structure de la base de données
 ===============================
 
-La base de données ne va pas être détaillée table par table mais nous allons vous présenter les grandes notions utilisées.
+La base de données n'est pas détaillée table par table dans cette documentation mais nous allons vous présenter les grandes notions utilisées.
+La structure présentée peut apparaître rigide mais c'est un mal nécessaire pour une certaine standardisation de données archéologiques. Par ailleurs les concepts sont très larges et d'expérience s'adapte très bien à la plupart des contextes.
 
 .. image:: _static/graphique-structure-ishtar.png
 
 
+Opération archéologique
+-----------------------
+
+L'opération archéologique est le cœur du modèle de données d'Ishtar.
+Au sein d'Ishtar, l'opération archéologique est définie comme une action (ou un projet d'action) permettant d'acquérir des données archéologiques, sous la responsabilité d'une personne (exemples : découverte fortuite, diagnostic, fouille programmée, prospection, etc.) et dans un lieu si possible défini.
+
+Il est possible de créer des liens entre des opérations, soit en les associant à un même dossier source (avec le module « administratif », ex. : un permis de construire qui est associé à un diagnostic et une fouille préventive), soit en définissant une relation entre des opérations globales (ex. : PCR, suivi d'autoroutes, etc.) et d'autres plus ponctuelles (phases, tranches, secteurs, etc.). Le regroupement d'opérations est également pratique en contexte de fouilles programmées, où il peut être utile d'avoir des inventaires pour chaque opération par année, mais également une vision globale de la succession des fouilles (opération globale). En contexte de grande opération préventive, ce système peut servir à individualiser des secteurs de fouilles disposant de modes d’enregistrements spécifiques. L'utilisateur a toute latitude pour organiser les opérations entres elles selon ses besoins, du moment que ces éléments clefs représentent bien des lots documentaires et mobilier a priori cohérents.
+
+
+Site/entité archéologique
+-------------------------
+
+L'opération archéologique a été préférée au site ou l'entité archéologique comme centre des données dans Ishtar parce que les sites/entités sont une interprétation (comme toute interprétation, sujette à évolution dans le temps) des données, alors que l'opération est l'information qui permet au mieux de regrouper un corpus documentaire cohérent mettant en lien des documents (plans, rapports, photos, etc.) et du mobilier.
+
+Malgré cela, Ishtar gère pleinement les sites (ou entité - notion paramétrable en administration) archéologiques et la migration depuis une base orientée site est tout à fait envisageable.
+
+Parcelle
+--------
+
+Les parcelles sont gérées précisément au sein d'Ishtar en étant directement rattachées aux UE. Cela permet de faciliter la gestion des questions légales concernant le mobilier (réalisation du « partage » ou responsabilité en cas de restauration). Si la parcelle de l'UE n'est pas connue ou si elle n'est pas sujette a contrainte légale il est possible d'associer une parcelle virtuelle ou de ne pas renseigner ce champ.
+
+Unité d'enregistrement
+----------------------
+
+La notion d'Unité d'enregistrement (UE) est à prendre comme un concept large. Elle se défini comme étant un volume (ou une surface) référencé dans l'espace (précisément ou non), associé à des informations archéologiques et contenant (ou pas) du mobilier. La proue du navire, la tranchée 3, la structure ST25, l'US137 ou le quart NE du carré A3 sont tous des UE valides pour Ishtar.
+
+Ishtar gère les relations entre UE. Cela permet notamment de définir des UE emboîtées (par exemple : tranchée > structure > US) mais aussi de gérer les relations stratigraphiques entre US.
+
+
+Mobilier - Traitement
+---------------------
+
+Le mobilier tel qu'habituellement compris se découpe en deux sous-éléments au sein d'Ishtar :
+
+- le mobilier d'origine ;
+- le mobilier (actuel).
+
+Le mobilier d'origine comprend les informations invariantes tout au long de la vie de l'objet, telle que son contexte de découverte, son inventeur, etc.
+Le mobilier actuel (généralement juste appelé « mobilier » au sein d'Ishtar) permet de caractériser l'objet tout au long de sa vie.
+
+Le distinguo entre de ces deux notions permet notamment une gestion fine des traitements simples (destructif ou non) et complexes (tri, remontage, etc.) avec une connaissance précise de l'historique de l'objet (lieux, responsables et documentations peuvent être associées à chaque traitement).
+
+Sur la figure ci-dessous chaque « Fiche mobilier » correspond à un élément « mobilier actuel » en base de données. Chaque élément et chaque traitement a une fiche associée.
+
+.. image:: _static/traitement.png
+
+Document
+--------
+
+Les documents sont gérés de manière transversale et peuvent être librement associé à un ou plusieurs éléments (opération, site, UE, traitement, mobilier, etc.) de la base de données. Des méta-données peuvent être renseignées pour chacun de ces documents et une image, un fichier peuvent être le cas échéant adjoint.
+
+
 ..
   TODO:
   Parler d'historisation