Johan LEROY
f8d08c8686
`execution_timeout` plafonne une tentative, pas la tâche. Avec deux reprises, quinze minutes par tentative autorisaient quarante-neuf minutes par tâche et quatre-vingt-dix-huit pour l'enchaînement, quand le commentaire annonçait une somme tenant sous le pas horaire. Le plafond passe à cinq minutes, ce qui borne le pire cas à trente-huit minutes, et le test d'intégrité calcule désormais ce pire cas plutôt que la somme des plafonds : reprises et délais d'attente compris, c'est la durée qu'un `max_active_runs=1` fait payer à l'exécution suivante. La CI vérifie aussi `app.cli generate-recommendations --help` sans réseau. C'est la seconde commande du DAG, et son import tire FastAPI, les repositories et les services, donc une part de l'environnement `/opt/backend` que la détection seule ne touche pas. `10-infra.md` nomme enfin ce que le décalage de quinze minutes ne garantit pas : le plafond de `ml_score` valant trente minutes, un scoring qui déborde prive la règle `anomaly` de la prédiction de l'heure, qu'elle ne retrouvera au passage suivant que si sa fenêtre la couvre encore.
Documentation
adr: décisions d'architecture, une par fichier, numérotées et immuables.architecture: les vues du système. Point d'entrée : architecture/README.md.
Décisions en vigueur
| ADR | Sujet |
|---|---|
| 0001 | PostgreSQL avec l'extension TimescaleDB |
| 0002 | Authentification par JWT d'accès et jeton de rafraîchissement opaque |
| 0003 | Autorisation RBAC à trois rôles, relecture du compte à chaque requête |
| 0004 | Journal d'audit en ajout seul, garanti par PostgreSQL |
| 0005 | LightGBM pour la prédiction de consommation, un modèle global |
| 0006 | Le moteur de règles de recommandation vit dans le backend, pas dans ml/ |
| 0007 | Terminaison TLS par un reverse proxy Nginx, en Docker Compose |
| 0008 | Airflow exécute le code du backend en sous-processus, dans son propre environnement |