# Analyse de l'Application `core`

## 1. Introduction

L'application `core` sert de fondation technique au projet. Elle fournit des modèles de données et des logiques réutilisables qui garantissent la cohérence, la traçabilité et la robustesse à travers toutes les autres applications (`banking`, `credits`, `members`, etc.).

Ce document analyse chaque composant de l'application `core` et fournit des recommandations sur son utilisation.

**Recommandation générale :** Tous les futurs modèles de données créés dans le projet devraient, sauf exception justifiée, hériter de `core.models.BaseModel`.

## 2. Analyse des Modèles

### 2.1. `BaseModel` (Modèle Abstrait)

*   **Objectif :** C'est le modèle le plus important de l'application `core`. Il fournit à tous les autres modèles qui en héritent :
    *   Un `id` en UUID comme clé primaire.
    *   Des champs d'horodatage (`created_at`, `updated_at`).
    *   Des champs d'audit utilisateur (`created_by`, `updated_by`).
    *   Une fonctionnalité de "suppression douce" (`is_active` et la méthode `soft_delete()`).
*   **Recommandations d'utilisation :**
    *   **Obligatoire :** Tous les modèles de données métier (`Account`, `Loan`, `ShareSubscription`, etc.) **doivent** hériter de `BaseModel`. Nous venons de faire cette correction, et il faut maintenir cette convention.
    *   Ne jamais redéfinir de champ `id` dans les modèles enfants.

### 2.2. `AuditLog`

*   **Objectif :** Enregistrer une piste d'audit immuable pour toutes les actions critiques effectuées dans le système. Il utilise une `GenericForeignKey` pour se lier à n'importe quel autre objet de la base de données.
*   **Recommandations d'utilisation :**
    *   **Opérations financières :** Doit être utilisé pour tracer chaque décaissement de prêt, chaque remboursement important, ou toute correction de solde manuelle.
        *   *Exemple :* Lors de l'approbation d'une `LoanApplication` dans l'app `credits`, créer une entrée `AuditLog` avec `action_type='approval'`, l'utilisateur approbateur, et un lien vers l'objet `LoanApplication`.
    *   **Modifications sensibles :** Doit être utilisé pour tracer les changements de statut (ex: suspension d'un membre), les modifications de permissions, ou les changements de configuration (`SystemConfiguration`).
    *   **Sécurité :** Le modèle `LoginAttempt` dans l'ancienne app `users` pourrait être remplacé ou complété par des entrées dans `AuditLog` pour les tentatives de connexion échouées.

### 2.3. `SystemConfiguration`

*   **Objectif :** Fournir un système de clé-valeur pour stocker des paramètres de configuration qui peuvent être modifiés par un administrateur sans avoir à redéployer le code.
*   **Recommandations d'utilisation :**
    *   **Paramètres métier :** Idéal pour stocker des valeurs comme le "montant maximum de retrait par jour", les "frais d'adhésion par défaut", ou un "taux de pénalité de retard" global.
    *   **Feature Flags :** Peut être utilisé pour activer ou désactiver des fonctionnalités en production (ex: `MAINTENANCE_MODE = True`).
    *   **Ne pas utiliser pour :** Les secrets (clés d'API, mots de passe). Ceux-ci doivent rester dans les variables d'environnement (`.env`). Le champ `is_sensitive` peut être utilisé pour masquer des valeurs dans l'interface d'administration, mais ce n'est pas un remplacement pour un vrai "secret management".

### 2.4. `Notification`

*   **Objectif :** Un système de notification complet pour informer les utilisateurs d'événements spécifiques, avec support pour les emails.
*   **Recommandations d'utilisation :**
    *   **Cycle de vie des crédits/parts :** Envoyer une notification à un `Member` lorsque sa `LoanApplication` est approuvée ou rejetée, ou lorsqu'un paiement de part sociale (`SharePayment`) est confirmé.
    *   **Alertes bancaires :** Notifier un utilisateur lors d'un dépôt ou d'un retrait important sur son `Account`.
    *   **Communication administrative :** Permet aux administrateurs d'envoyer des messages ciblés à certains utilisateurs.

### 2.5. `Document` et `MediaFile`

*   **Objectif :** Fournir une manière centralisée et robuste de gérer les fichiers uploadés, en s'appuyant sur le `StorageBackendMixin` pour un stockage adaptatif (local ou cloud).
*   **Recommandations d'utilisation :**
    *   **Principe :** Préférer une relation (`ForeignKey` ou `ManyToManyField`) vers ces modèles plutôt que d'ajouter des `FileField` ou `ImageField` directement dans les modèles métier.
    *   **Exemple pour `Customer` :** Au lieu d'un champ `id_card_image` sur le modèle `Customer`, on pourrait avoir une `ForeignKey` vers le modèle `Document` avec un type "Pièce d'identité". Cela permet de stocker plusieurs documents (CNI, passeport, etc.) pour un même client.
    *   **Exemple pour `LoanApplication` :** Une `LoanApplication` devrait avoir une `ManyToManyField` vers `Document` pour permettre à l'utilisateur de joindre plusieurs pièces justificatives (bulletins de paie, factures, etc.).