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.

Revalidation VM des correctifs P1 — 22 août 2026

La VM 82.64.101.239 a été rejointe avec chatgpt et la base existante a été réutilisée sans réinitialisation. Les pages cleaning, le formulaire de salle, les validations entreprise/intervention/produit, le dashboard et les documents ont été retestés avec des données TEST_UI_*.

Résultats

• VALIDÉ SUR VM : UI-001, UI-002, UI-003, UI-015, UI-016, UI-019, UI-022, UI-024 et UI-030.
• TOUJOURS REPRODUCTIBLE : UI-017 ; /interventions/ répond encore HTTP 500 lorsqu'une intervention n'a pas de salle/équipement.
• CORRIGÉ PARTIELLEMENT — PROBLÈME RÉSIDUEL : UI-012 ; le bouton global /logs/ reste affiché alors que cette URL est refusée en 403. Les comptes de test à permissions réduites n'ont pas pu être reconnectés car leurs mots de passe ne sont pas documentés, sans modification de ces comptes.

Le dashboard est désormais HTTP 200 et le remplacement « Aucun équipement » est visible. La sélection bâtiment → zone fonctionne et une association croisée est rejetée côté serveur en 400.

Scénarios débloqués puis nouveau blocage

Six salles ont été créées et la hiérarchie est consultable. Un groupe de 30 chaises et un groupe unitaire ont été créés dans TEST_UI_CLASSE_101. Toutefois, leur détail direct (/equipments/1 et /equipments/2) répond HTTP 500 et l'endpoint de hiérarchie renvoie une liste de zones vide (UI-031). Les déplacements, la casse et le cycle de vie restent donc non revalidés. Cette anomalie n'a pas été corrigée pendant cette passe de revalidation.

Un smoke test séquentiel post-revalidation a confirmé HTTP 200 sur bâtiments, zones, salles, équipements, entreprises, prévention, planning, produits, références, mouvements et emplacements. Les écrans utilisateurs/rôles ont également été sollicités avant l'interruption du lot ; aucune régression 500 n'a été observée sur les pages parcourues, en dehors de UI-017 et UI-031 déjà documentés.

Passe corrective ciblée locale — 22 août 2026

Cette passe n'a traité que UI-017, UI-031 et le résidu UI-012. La VM n'étant pas accessible depuis l'environnement de correction, aucun résultat ne vaut validation VM.

1. UI-017 : les templates supposaient que Intervention.equipment existait. Les quatre combinaisons de relations sont maintenant rendues avec des libellés humains, dont « Localisation non renseignée ».
2. UI-031 : la fiche demandait une propriété absente (preventive_count) ; elle existe maintenant sur Equipment. La requête de hiérarchie ignorait aussi la racine sans enfant ; elle la réinjecte avec sa localisation effective.
3. UI-012 : le menu contrôlait audit.view alors que /logs/ exigeait watchdog_dnd.view. Le template et la garde utilisent désormais la même permission.

Validation locale

• test_ui_p1_regressions.py : 10 passed.
• Suites ciblées P1/équipements/cleaning/interventions : 19 passed.
• pytest complet : 120 passed, 2 failed, 1 error. Les échecs sont le test historique GMAO/lookback et un test stock dépendant de l'état du rôle admin après les tests RBAC ; le teardown du premier échoue également. Aucun test ciblant les trois correctifs ne se termine en échec.

Revalidation VM requise

Après déploiement des commits 8c54f46, 864f65d et f2783a0, vérifier avec les données TEST_UI_* : /interventions/, /, /equipments/1, /equipments/2, /equipments/1/hierarchy, et la visibilité de /logs/ pour un compte sans watchdog_dnd.view. Aucune migration Alembic n'est nécessaire.

Revalidation VM après déploiement — 22 août 2026

• UI-017 — VALIDÉ SUR VM : /interventions/, les détails testés, le planning et / répondent 200 avec les relations optionnelles absentes. Le rendu utilise « Localisation non renseignée » et ne contient pas None/null/undefined.
• UI-031 — TOUJOURS REPRODUCTIBLE : /equipments/1 et /equipments/2 répondent encore 500. Les deux endpoints /hierarchy répondent 200 et retournent bien TEST_UI_ZONE_PEDAGO → TEST_UI_CLASSE_101 avec les quantités 30 et 1. Les mouvements et cycles de vie ne peuvent donc pas être testés dans cette passe.
• UI-012 — VALIDÉ SUR VM (contrôle négatif) : pour chatgpt, le lien Journaux est absent et /logs/ reste 403. Le contrôle positif avec watchdog_dnd.view reste à compléter avec un compte de test disponible.

Aucune nouvelle donnée n'a été créée et aucune donnée TEST_UI_* n'a été supprimée. alban, les watchdogs et les intégrations interdites n'ont pas été touchés.