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

## Audit local sur copie VM — 22 août 2026

L'application locale (`http://127.0.0.1:5080/`) a été reconstruite avec le
correctif `08c5b65`. Le traceback UI-031 a été reproduit puis supprimé en
enregistrant le filtre Jinja `nl2br` dans la factory. Les détails groupés et
les hiérarchies réelles répondent maintenant 200.

Les trois points ciblés sont validés localement : UI-017, UI-031 et UI-012.
Le contrôle UI-012 a été effectué avec `chatgpt` sans permission (lien absent,
403) et avec le compte temporaire `TEST_UI_REVALIDATION_RBAC` disposant de
`watchdog_dnd.view` (lien présent, `/logs/` 200).

Les scénarios équipements ont été exécutés sur un groupe quantitatif local :
déplacements 1 + 5 unités, refus d'une quantité excessive, individualisation
et réparation d'une unité, rebut confirmé d'une autre, et refus de déplacement
d'un luminaire fixe. Les événements et mouvements sont présents en base.

Un balayage séquentiel des pages principales n'a révélé aucun nouveau 500.
Le seul défaut HTTP connu retrouvé est `/documents/` en 404 (UI-011). Les
watchdogs et intégrations restent hors périmètre et non sollicités.

Le blocage UI-023 est également levé localement : `request_enabled` est
exposé dans le formulaire produit, le produit de test a été activé et il est
désormais proposé dans la création d'une fiche papier.

## Phase finale — synthèse fonctionnelle, UX et version

### Versionnement

La source applicative est `VERSION`, lue par `app_new/version.py`. Le
Dockerfile et les valeurs de secours Compose sont maintenant alignés sur
`0.1.0-dev.5` (après le passage `.4`, commit `676becd`), au lieu
de `0.1.0-dev.2`. La version est
exposée par la configuration Flask et `/health/`. Le contrôle post-rebuild
retourne effectivement `0.1.0-dev.4` et le commit `b6fbfe6`; la base est
connectée. Le test unitaire de lecture de version passe.

### Menus et navigation

Les menus principaux sont accessibles séquentiellement : Accueil, Alertes,
Interventions, Équipements, stock/entretien et Administration. Les contrôles
RBAC locaux confirment l'absence du lien Journaux sans
`watchdog_dnd.view`, tout en conservant le refus backend 403. Les menus
restent toutefois très denses et regroupent des fonctions quotidiennes,
administratives et d'intégration ; la proposition de regroupement par tâches
se trouve dans `UX_PROPOSALS.md` et n'est pas implémentée.

Le Centre documentaire global est désormais implémenté localement sur la
copie VM : `/documents/` et `/documents/fds` agrègent en lecture les documents
d'interventions, d'équipements et de produits sans copier les fichiers. UI-011
est corrigé dans le code et reste à revalider sur une VM distante si exigé.

### Expérience débutant

Les scénarios locaux bâtiment → zone → salle → équipement, déplacement,
réparation, rebut, stock FEFO et fiche papier sont réalisables avec des
données de test, mais l'ordre des prérequis n'est pas suffisamment expliqué
pour un nouvel utilisateur. Les principales recommandations sont : checklist
de premiers pas, états vides actionnables, unités explicites, confirmations
décrivant les conséquences et libellés métier des permissions.

### Responsive et accessibilité

Les contrôles précédents sur plusieurs listes à 390×844 et 768×1024 n'ont pas
révélé de débordement sur les pages parcourues. Une campagne visuelle complète
avec navigateur instrumenté, focus clavier, lecteurs d'écran et mesures de
contraste reste partielle et doit être exécutée avant installation neuve.

### Statut final de cette passe

Audit global estimé à **85 %**. Les résultats détaillés, le TOP 10 UX, les
quick wins, l'arborescence proposée et les sujets nécessitant validation sont
dans `docs/ui-audit/UX_PROPOSALS.md`. Les éléments encore ouverts sont
principalement UI-011, les contrôles UX/accessibilité exhaustifs, certaines
variantes de planning et la validation sur installation neuve.

### Tests automatisés finaux

- Version, P1 et cycle de vie : **20 passed**.
- Phase 1 documentaire/planning et version : **5 passed** ciblés.
- RBAC et régressions P1 : **22 passed** après restauration systématique de la
  permission `stock.view` du rôle système de test.
- Suite complète après Phase 1 : **125 passed, 1 failed, 1 error** sur 126.
  L'unique échec
  restant est `test_gmao_config_caps_lookback_at_one_year`, volontairement
  hors périmètre (contexte/configuration GMAO interdite) ; son teardown échoue
  également sur la contrainte `gmao_context.user_id NOT NULL`. Aucun nouveau
  échec fonctionnel n'a été introduit. La correction d'isolation est dans
  `933f0a5`.

## Phase 1.5 — raccord Pronote

Pronote alimente désormais réellement `RoomSchedule` via une normalisation
déterministe et un import explicite par semaine. Pronote désactivé ou en panne
ne vide pas le planning et ne bloque pas la disponibilité interne. Les conflits
protégés, rapprochements ambigus et suppressions distantes sont conservés et
visibles ; aucun nouveau système de planning n'a été créé.

La couverture Phase 1.5 comprend 7 tests ciblés et **129 passed** dans la
suite complète ; l'unique échec/erreur reste le lookback GMAO historique hors
périmètre.

## Phase 1.6 — synthèse UI/navigation

La navigation a été regroupée par métier sans modifier les URLs ni le RBAC.
70 entrées historiques sont documentées : 25 migrées, 20 regroupées et 25
réservées au référentiel administrateur. Le nouveau menu couvre Accueil, Mon
travail, Patrimoine, Produits & stocks, Entreprises, Documents et
Administration ; aucune entrée n'est perdue silencieusement.

La rubrique principale `Ancien menu` est conservée, complète et transitoire,
parallèle à `Administration`. Elle expose les cinq groupes historiques et
reste réservée aux administrateurs.
Les pages Documents/FDS et Planning des salles disposent d'états vides,
d'actions textuelles et de libellés de provenance plus clairs. La page RBAC
présente désormais les libellés métier des permissions et explique le
comportement administrateur. La validation visuelle réelle reste à faire avec
un navigateur instrumenté.
## Correction de l'inventaire historique — 2026-08-23

ANCIEN TOTAL : 70
ENTRÉES MANQUANTES SIGNALÉES PAR UTILISATEUR : 4
AUTRES ENTRÉES MANQUANTES DÉCOUVERTES : 2
NOUVEAU TOTAL HISTORIQUE : 76
MESSAGES ENT PRÉSENT : OUI
INTERPRÉTATIONS ENT PRÉSENT : OUI
PERSONNEL ENT PRÉSENT : OUI (libellé historique : Personnels ENT)
PRONOTE (SYNC SALLES) PRÉSENT : OUI
GROUPES HISTORIQUES : Principal, Interventions, Équipements, Documents, Configuration
CAUSE DES OUBLIS : comparaison initiale limitée au composant de navigation
refactoré et à une matrice manuelle ; les entrées conditionnelles des
intégrations et les liens Outlook secondaires n'avaient pas été extraits du
template desktop pré-Phase 1.6.
ENTRÉES HISTORIQUES SANS CLASSEMENT : 0
ENDPOINTS CASSÉS : 0 constaté dans les routes enregistrées
NOUVEAU MENU MODIFIÉ : NON
RBAC MODIFIÉ : NON
INTÉGRATIONS MODIFIÉES : NON
VERSION : 0.1.0-dev.6
## Phase 2 — première tranche implémentée

La vue `Ma journée` propose chronologiquement les tâches `ScheduledTask`,
`Intervention` et `AdminTask` accessibles à l'utilisateur. Les choix sont
déterministes, non persistés et expliqués. Les horaires de travail et les
pauses sont des contraintes fortes ; les salles sont vérifiées via le
planning interne résolu. Pronote, ENT, Outlook, IA et watchdogs ne sont pas
appelés.

La proposition reste partielle pour les urgences avec replanification,
l'accompagnement multi-segments des entreprises et le multi-techniciens.
## Phase 2.1 — validation métier de Ma journée

La validation locale montre que le moteur ne perd pas de tâche, respecte la
pause et les horaires, utilise les occupations internes résolues et conserve
les rendez-vous fixes. Une urgence qui chevauche un rendez-vous fixe produit un
conflit explicite au lieu d'une suppression automatique. La replanification
minimale est disponible pour les interventions et tâches planifiées, avec
contrôles serveur.
# Requalification Phase 2.1 — synthèse

La phase est **PARTIELLEMENT VALIDÉE**. Les horaires sont maintenant
administrables par technicien et isolés dans `DayPlanner`. En revanche, la
chaîne préventive complète n'a pas été configurée depuis l'UI : les données
Phase 2.1 historiques venaient de scripts/fixtures. Aucun lot ou équipement
marqué Phase 2.1 n'était présent dans la copie VM inspectée.

## Phase 2.1b

La durée par élément et les périmètres d'équipements sont persistants et
modifiables. Les passages entreprise disposent de trois modes et d'un suivi
réalisé/non-venue. La phase reste **PARTIELLEMENT VALIDÉE** : la sélection en
masse et le scénario de bout en bout n'ont pas encore été rejoués entièrement
depuis l'interface.
### Phase 2.1c (état intermédiaire)

La clôture technique ajoute la migration `j5e6f7a8b9c0` : nature de tâche, propriétés interruptible/fractionnable et segments d'exécution. La création en masse de locaux et l'affichage de la maintenance couverte par contrat sont disponibles. La validation visuelle et le scénario UI complet restent à effectuer avant toute qualification définitive.
