geo/api/TODO-API.md

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 :

-- 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