# TODO-API.md

## 📋 Liste des tâches à implémenter

### 🔴 PRIORITÉ HAUTE

#### 1. Système de backup pour les suppressions (DELETE)
**Demandé le :** 20/08/2025
**Objectif :** Sauvegarder toutes les données supprimées (soft delete) dans un fichier SQL pour pouvoir les restaurer en cas d'erreur humaine.

**Détails techniques :**
- Créer un système de backup automatique lors de chaque DELETE
- Stocker les données dans un fichier SQL avec structure permettant la réintégration facile
- Format suggéré : `/backups/deleted/{année}/{mois}/deleted_{table}_{YYYYMMDD}.sql`

**Tables concernées :**
- `ope_pass` (passages) - DELETE /passages/{id}
- `users` (utilisateurs) - DELETE /users/{id}
- `operations` (opérations) - DELETE /operations/{id}
- `ope_sectors` (secteurs) - DELETE /sectors/{id}

**Structure du backup suggérée :**
```sql
-- Backup deletion: ope_pass
-- Date: 2025-08-20 14:30:45
-- User: 9999985 (cv_mobile)
-- Entity: 5
-- Original ID: 19500576

INSERT INTO ope_pass_backup (
    original_id,
    deleted_at,
    deleted_by_user_id,
    deleted_by_entity_id,
    -- tous les champs originaux
    fk_operation,
    fk_sector,
    fk_user,
    montant,
    encrypted_name,
    encrypted_email,
    -- etc...
) VALUES (
    19500576,
    '2025-08-20 14:30:45',
    9999985,
    5,
    -- valeurs originales
    ...
);

-- Pour restauration facile :
-- UPDATE ope_pass SET chk_active = 1 WHERE id = 19500576;
```

**Fonctionnalités à implémenter :**
1. **Service de backup** : `BackupService.php`
   - Méthode `backupDeletedRecord($table, $id, $data)`
   - Génération automatique du SQL de restauration
   - Rotation des fichiers (garder 90 jours)

2. **Intégration dans les controllers**
   - Ajouter l'appel au BackupService avant chaque soft delete
   - Logger l'emplacement du backup

3. **Interface de restauration** (optionnel)
   - Endpoint GET /api/backups/deleted pour lister les backups
   - Endpoint POST /api/backups/restore/{backup_id} pour restaurer

4. **Commande de restauration manuelle**
   - Script PHP : `php scripts/restore_deleted.php --table=ope_pass --id=19500576`

**Avantages :**
- Traçabilité complète des suppressions
- Restauration rapide en cas d'erreur
- Audit trail pour conformité
- Tranquillité d'esprit pour le client

---

### 🟡 PRIORITÉ MOYENNE

#### 2. Amélioration des logs
- Ajouter plus de contexte dans les logs
- Rotation automatique des logs
- Dashboard de monitoring

#### 3. Optimisation des performances
- Cache des requêtes fréquentes
- Index sur les tables volumineuses
- Pagination optimisée

#### 4. Sécurisation des clés Stripe par environnement
**Objectif :** Étudier une approche plus sécurisée pour stocker les clés Stripe

**Problème actuel :**
- Toutes les clés (DEV, REC, PROD) sont dans un seul fichier `AppConfig.php`
- Les clés PRODUCTION sont visibles dans le code DEV/REC
- Risque si accès au container DEV → exposition des clés PROD

**Solutions à étudier :**
1. **Variables d'environnement** (`.env` par container)
   - Fichier `.env.dev`, `.env.rec`, `.env.prod`
   - Chargement dynamique selon l'environnement
   - Exclusion des `.env` du versionning Git

2. **Fichiers de config séparés**
   - `config/stripe.dev.php`, `config/stripe.rec.php`, `config/stripe.prod.php`
   - Déploiement sélectif selon l'environnement
   - Non versionnés (ajoutés au .gitignore)

3. **Secrets management** (avancé)
   - HashiCorp Vault, AWS Secrets Manager, etc.
   - API de récupération sécurisée des secrets

**Recommandation :** Approche #1 (variables d'environnement) pour équilibre sécurité/simplicité

---

### 🟢 PRIORITÉ BASSE

#### 5. Documentation API
- Génération automatique OpenAPI/Swagger
- Documentation interactive
- Exemples de code pour chaque endpoint

#### 6. Tests automatisés
- Tests unitaires pour les services critiques
- Tests d'intégration pour les endpoints
- Tests de charge

---

## 📝 Notes

- Les tâches marquées 🔴 doivent être traitées en priorité
- Chaque tâche implémentée doit être documentée
- Prévoir des tests pour chaque nouvelle fonctionnalité

---

**Dernière mise à jour :** 20/08/2025