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.

3.1 KiB Raw Blame History