# Audit du catalogue préventif historique

Date : 2026-08-23  
Source de référence : `/opt/gmao/dump_sql_base_remplie.sql` (lecture seule)

## Tables analysées

| Table | Lignes dans le dump | Utilité |
|---|---:|---|
| `equipment_categories` | 36 | catégories patrimoniales |
| `lots` | 92 | lots, catégorie par `category_id`, présence |
| `lot_tasks` | 330 | référentiel historique des actions par `lot_id` |
| `preventive_tasks` | 0 | ancienne table, structure présente mais aucune donnée |
| `scheduled_tasks` | 516 | échéances historiques, pas le catalogue initial |

Le modèle actuel utilise `LotTask`, et non `preventive_tasks`, pour les règles
préventives. Le dump contient 36 catégories et 92 lots, déjà représentés dans
`setup_catalog.py`; il manquait les 330 lignes de `lot_tasks`.

## Durée et périodicité

- 330 tâches ont été extraites sans modification des valeurs historiques ;
- 5 tâches ont une `duree_minutes` renseignée ; 325 ont une durée inconnue ;
- 327 ont une périodicité textuelle ; 3 ont une périodicité vide ;
- les valeurs `jours_entre_interventions`, type, contrat, gestionnaire,
  déclenchement et politiques ont été conservées lorsqu'elles existent.

La valeur de 60 minutes de `LotTask.effective_duration()` n'est pas présente
dans le dump : c'est un fallback du code actuel, pas une donnée historique.
Elle reste temporairement compatible avec les anciennes données, mais une tâche
sans durée doit être signalée avant une validation métier définitive.

## Catalogue embarqué

`app_new/core/preventive_catalog.py` contient une extraction compressée et
figée des 330 tâches. Le dump n'est jamais ouvert par l'application. Le module
expose `LOT_TASKS`, utilisé par le setup wizard et les tests.

Le wizard crée les catégories, les lots sélectionnés et leurs tâches. La clé
fonctionnelle de tâche est `(lot, tache)` ; une ligne déjà existante n'est pas
écrasée, afin de préserver une personnalisation locale. Les éléments manquants
sont ajoutés. La seconde exécution est donc idempotente.

## Relation équipement

`Equipment.lot_id -> Lot.id`, avec héritage par `parent.effective_lot_id`.
Les tâches sont donc visibles via le lot effectif et peuvent générer des
`ScheduledTask` pour les équipements actifs. Un équipement rebuté ou supprimé
ne doit pas produire de nouvelle échéance.

## Première échéance

Le mécanisme actuel `generate_due_tasks()` calcule la première échéance à
partir de la date de génération et de `jours_entre_interventions`/périodicité.
Le dump ne fournit pas une date de première échéance catalogue. Une règle
métier explicite (date d'association, prochaine échéance saisie ou campagne)
reste à valider avant une automatisation plus ambitieuse.

## Écarts et limites

- le catalogue est maintenant complet pour les tables historiques validées ;
- les tâches sans durée restent à renseigner pour une planification fiable ;
- la validation bout en bout par interface (installation, association d'un
  équipement, génération, Ma journée) reste à exécuter avec un compte UI ;
- `preventive_tasks` est documentée mais vide et n'est pas importée.