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 : 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 : 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).
• P1 : 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 : clarifier /planning/availability, qui reprend le titre et la structure de /planning/time.

Limites

Les équipements physiques, déplacements, interventions liées à des salles, scénarios FEFO 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.

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.

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.