gmao/docs/ui-audit/REPORT.md

# Rapport d'audit — synthèse actuelle

## Méthodologie

Tests séquentiels avec Playwright et requêtes HTTP contrôlées, un seul compte
super-administrateur, délais longs et retries manuels après indisponibilité.
Aucune correction applicative, aucun nettoyage et aucune action sur les zones
interdites.

## État actuel

Le site est accessible après ajout de ressources VM. Le RBAC initialisé expose
les rôles système et les permissions attendues. Les accès anonymes aux API
retournent 401. La majorité des pages métier répondent 200, mais la liste des
interventions et le tableau de bord répondent désormais 500 après création de
l'intervention de test sans équipement.

## Priorités

- P1 : corriger les deux 500 du module entretien.
- P1 : corriger également le 500 de `/cleaning/stock` apparu après des
  réceptions valides (UI-022).
- P1 : rétablir les bâtiments dans le formulaire de création de salle.
- P1 à confirmer : mesurer la stabilité sous navigation lente et surveiller
  la base/Gunicorn.
- P2 : clarifier Site, Collège, Bâtiment et unités de produit.
- P2 : injecter `GIT_VERSION` dans les images Docker.
- P1 : filtrer le menu et les raccourcis du dashboard selon les permissions
  effectives ; actuellement le backend refuse mais les liens restent visibles.
- P2 : harmoniser la pagination des listes et ajouter une recherche aux
  entreprises.
- P1 : toutes les soumissions vides doivent produire une validation métier,
  jamais un écran 500 (entreprise et intervention reproduits).
- P1 : l'édition d'un produit doit valider les quantités numériques sans
  exception 500 (UI-024).
- P1 : la liste des interventions doit tolérer une intervention sans salle ou
  empêcher cette création ; le détail fonctionne mais la liste renvoie 500.
- P1 : le tableau de bord doit tolérer une intervention sans équipement ; il
  renvoie actuellement 500 lorsque la relation est absente (UI-019).
- P2 : le lien `/documents/` renvoie 404 alors que les documents sont une
  fonction attendue ; les écrans spécialisés `/cleaning/documents` répondent
  toutefois 200 (UI-011).
- P2 : le lien Journaux est visible pour le compte d'audit mais `/logs/`
  renvoie 403 ; le filtrage de menu et la permission de route doivent être
  alignés (UI-020).
- P2 : certains formulaires planning ne rendent pas le champ CSRF côté
  serveur et dépendent de JavaScript (UI-021).
- P2 : les labels des formulaires produits/stock/prévention ne sont pas
  techniquement associés aux champs (UI-026).
- P2 : les habilitations saisies en prévention ne disposent d'aucun récapitulatif
  visible (UI-028).
- P2 : les listes stock/produits sans recherche ni pagination deviendront
  difficiles à exploiter avec un historique réel (UI-029).
- P1 : les documents téléversés sont récupérables mais absents du détail de
  l'intervention ; l'utilisateur n'a aucun retour visuel (UI-030).
- P2 : clarifier `/planning/availability`, qui reprend le titre et la
  structure de `/planning/time`.

## Limites

Les équipements physiques, déplacements, interventions liées à des salles et
uploads de documents restent non testés car la création de
salle est bloquée par UI-003. Le dashboard est également bloqué par UI-019 ;
les écrans de listes et formulaires accessibles ont néanmoins été parcourus.
Le scénario stock indépendant des salles a maintenant été exécuté : le
journal confirme la sélection FEFO du lot à DLU la plus proche, mais l'écran
de stock lui-même est bloqué par UI-022.
Le profil de demande papier et sa fiche imprimable ont également été créés et
consultés ; le catalogue de produits étant non activé pour les demandes, la
fiche de test ne contient pas encore de ligne produit.
L'interface ne permet pas d'activer `request_enabled`, ce qui bloque la
configuration complète des fiches (UI-023).

Le formulaire personnel de prévention a finalement été validé avec l'agent
`TEST_UI_AGENT ENTRETIEN`, laissé volontairement dans la base pour inspection.
Un risque DUERP et une observation de registre de sécurité `TEST_UI_*` ont
également été créés et vérifiés.

Ce document est un checkpoint, pas une déclaration de fin d'audit.

Un smoke responsive sur `/companies/` en 390x844 et 768x1024 n'a pas détecté
de débordement horizontal. Une erreur 401 de ressource est apparue dans la
console au chargement de la session de login ; elle reste à qualifier.

Une soumission isolée du formulaire produit a dépassé 30 secondes. Elle n'a
pas été répétée afin de respecter la faible capacité de la VM ; ce résultat
reste classé comme instabilité à confirmer.

## Correctifs P1 réalisés dans le dépôt local

Une passe corrective a traité les anomalies P1 documentées UI-001, UI-002,
UI-003, UI-012, UI-015, UI-016, UI-017, UI-019, UI-022, UI-024 et UI-030.
Les causes ont été corrigées dans les routes/templates concernés, avec
validation serveur des formulaires et filtrage de navigation via le RBAC
existant. Aucun watchdog, intégration externe, configuration générale ou
utilisateur réel n'a été modifié.

Statut de chaque correctif : **CORRIGÉ DANS LE CODE — À REVALIDER SUR VM DE
TEST**. Les tests locaux ne donnent aucune garantie sur la base distante qui
contient les données `TEST_UI_*`.

Tests locaux exécutés : `tests/integration/test_cleaning_module.py`,
`tests/integration/test_equipment_forms.py`,
`tests/integration/test_intervention_location_and_template_audit.py` et
`tests/integration/test_ui_p1_regressions.py`.

La revalidation VM doit être faite après récupération des commits et, si le
déploiement utilise Docker, après reconstruction de l'image applicative. Aucun
test distant n'a été exécuté depuis cet environnement.

La suite complète locale a produit 117 succès, 1 échec et 1 erreur sur le
test historique de limitation du lookback GMAO et son nettoyage associé. Ces
deux résultats sont hors périmètre et ne sont pas attribués aux correctifs
P1 ; les 16 tests ciblés passent.

La soumission d'un formulaire de personnel prévention a rencontré le même
blocage. Aucun retry rapproché n'a été effectué.

La page `/planning/` a répondu en environ 5,5 secondes pour une réponse de
347 Ko. Ce n'est pas qualifié comme panne sur la VM de test, mais la taille et
le temps perçu justifient une optimisation ou une pagination si le calendrier
grandit.