Stockage et historique Aquila PRO V1

L’édition PRO s’appuie sur un stockage persistant pour conserver l’historique des décisions et faciliter l’analyse.

Moteurs supportés

• SQLite :
• idéal pour les environnements simples ou de test ;
• stockage dans un fichier monté en volume Docker.
• PostgreSQL :
• recommandé pour les environnements de production ;
• permet une montée en charge et des requêtes analytiques plus riches.

Le choix du moteur se fait via la configuration (variable d’environnement ou paramètre de démarrage).

Schéma logique

On retrouve généralement au moins :

• une table d’historique détaillé (ex. history) ;
• une table ou vue de dernier état (ex. last_events).

Colonnes usuelles pour l’historique :

• identifiant unique (clé primaire) ;
• timestamp de la décision ;
• repository, pipeline, branche ;
• statut (accepted / refused) ;
• raisons (code, message) ;
• payload brut de la requête (optionnel ou tronqué selon la politique de rétention).

Rétention et purge

La stratégie de rétention est à définir selon les contraintes de l’entreprise. Exemples :

• conservation 30 jours en base puis archivage ;
• conservation 90 jours pour la production, moins pour les environnements de test.

Des tâches planifiées (cron, job Kubernetes, etc.) peuvent exécuter des scripts de purge ou d’archivage.

Bonnes pratiques

• Monitorer l’espace disque (SQLite) ou la volumétrie des tables (PostgreSQL).
• Ne pas stocker d’informations à caractère personnel dans les payloads, ou les anonymiser si nécessaire.
• Documenter les procédures de restauration en cas d’incident (backup/restore).