gmao/docs/ui-audit/PREVENTIVE_CATALOG_AUDIT.md

# 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 historique de 60 minutes n'est pas présente dans le dump : c'était
un fallback du code, pas une donnée métier. Il est maintenant supprimé : une
tâche sans durée retourne 0 et doit être renseignée avant planification
automatique.

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

## Requalification des durées et des exécutants

Les 330 tâches ont été classées et documentées dans
`PREVENTIVE_TASK_DURATION_PROPOSAL.md`. Les durées historiques sont toutes
marquées non fiables ; aucune n'est utilisée comme référence. Les tâches
internes sont proposées en durée par élément, les espaces verts en durée par
zone, et les tâches externes en durée de passage à confirmer.

Le workflow entreprise, les rendez-vous, passages libres, non-venues,
accompagnements et périmètres d'équipements sont décrits dans
`EXTERNAL_MAINTENANCE_WORKFLOW.md`. Cette passe ne crée pas encore de migration
pour ces concepts.