# Avancement de l'audit Dernière mise à jour : 22 août 2026 — reprise après interruption. ## État global État : **en cours**. Revalidation VM P1 effectuée ; l'audit fonctionnel doit continuer sur les scénarios encore testables. ## Phase finale locale — 22 août 2026 L'application locale est disponible sur `http://127.0.0.1:5080/`, avec MariaDB restaurée depuis la copie VM. Les contrôles locaux UI-017, UI-031 et UI-012 sont validés et les scénarios équipements (déplacement, quantité, réparation, remise en service, rebut et équipement fixe) sont exécutés sur des données `TEST_UI_*`. Les intégrations interdites et l'utilisateur `alban` n'ont pas été touchés. La version de référence a été incrémentée de **0.1.0-dev.2** à **0.1.0-dev.4** (passage intermédiaire `.3`) dans les commits de release `50d3fd0` et suivants. `VERSION` reste la source de vérité; les valeurs Docker de secours sont alignées sur cette version. Une reconstruction locale est à effectuer pour que le conteneur actuellement exécuté expose cette nouvelle version. La cartographie UX finale et les propositions (menu, onboarding, états vides, formulaires, confirmations, TOP 10 et quick wins) sont dans `docs/ui-audit/UX_PROPOSALS.md`. Aucun changement de refonte UX n'a été implémenté. Contrôle post-rebuild effectué : `/health/` répond 200 avec la version `0.1.0-dev.4`, le commit `b6fbfe6` et une base MariaDB connectée. ## Étude Centre documentaire global — 22 août 2026 Étude d'architecture terminée dans `DOCUMENT_CENTER_PROPOSAL.md`. Le dépôt possède trois modèles documentaires spécialisés, plusieurs conventions de stockage et aucune table commune. La recommandation est une agrégation de lecture par adaptateurs pour la V1, sans migration ni copie de fichier, avec contrôle conjoint `documents.view` et permission du module source. Aucune modification applicative, route, migration ou donnée de test n'a été créée. Couverture estimée : **environ 85 %**. Les principaux workflows patrimoine, interventions, stock, prévention et RBAC ont été testés localement ; restent partiels la recherche documentaire globale, certaines variantes de planning, les tests visuels complets responsive/accessibilité et une installation neuve. ### Suite automatisée finale - Tests ciblés version/P1/cycle de vie : **20 passed**. - RBAC + régressions P1 : **22 passed**. - `pytest` complet après isolation du test RBAC : **122 passed, 1 failed, 1 error** sur 123 tests. Le seul échec restant est le test historique de configuration/lookback GMAO hors périmètre ; son teardown échoue parce que cette configuration de test utilise un `user_id` nul. Le test stock qui dépendait de l'ordre RBAC est désormais isolé et passe. ## Phases | Phase | État | Notes | |---|---|---| | Santé, connexion, version | Terminé | Version 0.1.0-dev.2, commit unknown | | Menu et smoke test | Partiel | Pages principales testées séquentiellement | | RBAC | Partiel avancé | multi-rôles, retrait/deny et accès directs testés ; menu non filtré | | Établissement | Partiel | Sites, bâtiments et zones créés ; confusion site/bâtiment | | Salles | Partiel avancé | Sélection bâtiment/zone corrigée et création/rejet croisé revalidés | | Équipements | Bloqué partiel | Groupes créés, mais détail `/equipments/` en 500 (UI-031) | | Interventions | Partiel | Création/validation et dashboard revalidés ; liste encore en 500 (UI-017) | | Planning | Partiel | time/availability/tâches testés ; disponibilité semble dupliquée | | Prévention | Partiel | Validation invalide et création d'un agent TEST_UI vérifiées | | Stock / produits | Partiel avancé | Produit/référence/conditionnement, emplacements, lots, réception, sortie FEFO, transfert et inventaire testés ; état du stock 500, transvasement/prévision 500 | | Personnel | Partiel | Agent TEST_UI créé et retrouvé dans la page prévention | | Documents | Partiel | `/documents/` 404 ; `/cleaning/documents` 200 ; upload réel non effectué faute de cible publique stable | | Responsive/accessibilité | Partiel | entreprises 390x844 et 768x1024 sans débordement | ## Dernière action réussie - Connexion `chatgpt`. - Vérification HTTP des pages principales. - Création de données `TEST_UI_*` listées dans `CREATED_TEST_DATA.md`. - Smoke responsive `/companies/` en 390x844 et 768x1024 sans débordement. - Formulaire produit ouvert et rempli ; la soumission est restée bloquée plus de 30 secondes, sans nouvelle tentative pour ne pas charger la VM. - Formulaire prévention ouvert et rempli ; la soumission est restée bloquée, sans répétition. ## Blocages - `/cleaning/transvasement` → 500. - `/cleaning/forecast-config` → 500. - `/equipments/rooms/new` → aucun bâtiment dans le sélecteur. - L'instance a déjà subi des indisponibilités temporaires lors d'un crawl trop rapide ; reprendre avec une seule session et des délais longs. - La soumission de `/cleaning/products/new` a de nouveau dépassé le délai lors d'un test isolé ; données de produit à vérifier avant toute répétition. - La soumission d'un agent prévention a également dépassé le délai ; analyser les logs/ressources avant de qualifier le comportement applicatif. - Intervention ID 1 créée sans salle : détail/édition 200, liste principale 500 ; cas ajouté aux bugs UI-017/UI-018. - Reproduction du tableau de bord après cette création : `/` répond 500 ; le journal confirme `dashboard/index.html:495` (`interv.equipment.name` sur une relation nulle), ajouté en UI-019. - Smoke complémentaire : scheduled, meters, consumables, admin-tasks, rules, formations personnelles, prévention, lifecycle, à jeter, anciens, services et types de salles répondent 200 ; `/documents/` répond 404. - Création RBAC : rôles 9/10 et utilisateurs 3/4 ; union multi-rôles, deny individuel et 403 directs vérifiés. - Filtres lots/équipements/interventions testés ; pagination incohérente sur interventions/entreprises et absence de recherche visible sur entreprises. - Validations vides : entreprises et interventions renvoient 500 ; rôles et produits restent sur le formulaire avec validation. - Smoke complémentaire : stock/emplacements/transferts/mouvements/inventaire, création équipement avancée et assistant inventaire, pièces, contrats, formations, services, types de salles, lot, tâches et formulaires de disponibilité/fermeture répondent 200. - Navigation : `/logs/` reste visible dans le HTML mais répond 403 pour `chatgpt`, ajouté en UI-020. - Les liens supplémentaires du menu (exports, logements, compteurs, planificateur, profil, alertes et messagerie) ont répondu 200 ; aucun bouton de synchronisation/intégration n'a été déclenché. - `/planning/` répond 200 en environ 5,5 s et produit une page d'environ 347 Ko sur cette VM ; à surveiller comme performance perçue, sans test de charge. - Dernier contrôle santé : `/health/` répond 200, base MySQL connectée, environnement `development`, version `0.1.0-dev.2`, commit `unknown` ; un accès anonyme à `/` redirige correctement vers la connexion. - Contrôle des identifiants inexistants : équipements, interventions, entreprises, lots, produits, pièces, contrats et formations renvoient tous 404 proprement (aucun 500 observé). - Paramètres de liste invalides (`page=abc`, page négative, recherche avec caractères spéciaux, filtres inconnus) : les quatre URLs testées répondent 200 sans erreur serveur. - Connexion avec identifiants inconnus : le formulaire reste en 200 et affiche un message d'erreur, sans redirection ni ouverture de session. - La validation métier prévention `/prevention/risk` avec unité/danger vides et cotations hors plage redirige vers la page avec message d'erreur, sans créer de donnée. - Création personnel : `TEST_UI_AGENT ENTRETIEN` a été créé via `/prevention/staff`, puis retrouvé dans la page (HTTP 302 puis 200). - Création prévention complémentaire : risque DUERP et entrée de registre `TEST_UI_*` créés, puis retrouvés dans `/prevention/` après redirection. - Export DUERP : `/prevention/duerp.csv` répond 200 avec un CSV UTF-8 et un nom de fichier de téléchargement correct. - Les formulaires de fermeture et de nouvelle tâche planning s'appuient sur l'injection JavaScript du CSRF ; sans ce script, aucun champ caché n'est présent et le serveur renvoie 400 (UI-021). - La vue journalière `/planning/day/2026-08-25` et les écrans planning scheduled/meters/consumables/admin-tasks/rules répondent 200. - API anonyme : `/api/v1/status`, `/api/v1/equipments` et `/api/v1/interventions` renvoient chacun 401 JSON avec un message d'authentification, conformément au deny-by-default. - Les listes pièces, services, contrats et formations ne contenaient pas de lien de détail au moment du test ; le détail de l'entreprise ID 1 répond 200. - Les POST vides avec CSRF valide sur réception, sortie et transfert restent sur le formulaire en 200 ; l'inventaire n'offre aucune ligne d'action tant qu'aucun emplacement n'est disponible. Les POST sans CSRF testés plus tôt renvoient 400. - Scénario stock sans salle : produit, référence, conditionnement, deux emplacements et deux lots créés ; réception 2×5 L et 3×5 L réussie ; sortie d'1 L et transfert de 5 L réussis. Le journal confirme que la sortie a choisi `TEST_UI_LOT_EARLY` (DLU la plus proche), donc FEFO fonctionne sur ce cas. Inventaire validé avec correction tracée ; `/cleaning/stock` répond toutefois 500 après ces opérations (UI-022). - Fiches papier : profil `TEST_UI_PROFIL_ENTRETIEN` créé puis fiche `/cleaning/requests/print/1` vérifiée avec le personnel TEST_UI. Aucun produit n'était autorisé sur les fiches car `request_enabled` est désactivé par défaut ; ce point limite le test des lignes imprimées. - Le champ métier `request_enabled` n'est exposé ni à la création ni à l'édition d'un produit ; aucun produit n'est donc sélectionnable dans le profil (UI-023). - Sorties stock invalides (`-1` puis `999999`) : le formulaire reste en 200 avec message métier, sans mouvement supplémentaire ni stock négatif. - Création d'un produit générique portant un nom déjà existant : le formulaire reste en 200 et affiche « existe déjà », sans doublon détecté. - Édition produit avec `stock_minimum=abc` : HTTP 500 (UI-024), alors que la création gère ce cas avec un message d'erreur. - Création d'une seconde référence commerciale portant le même nom : acceptée sans avertissement, deux lignes apparaissent (UI-025). - Vérification structurelle des formulaires : les labels produits/stock et prévention sont visuellement présents mais non reliés par `for`/`id`, ajouté en UI-026. - L'étiquette du mouvement de réception `/cleaning/labels/1` répond 200 et reprend le produit de test ; les identifiants sans mouvement retournent 404. - Action prévention `TEST_UI_ACTION_SECURITE` créée puis testée avec les statuts `en_cours`, invalide et `cloturee` ; le statut invalide redirige sans modifier l'action et la clôture est persistée. - Le formulaire d'habilitation accepte une date d'expiration antérieure à la date d'émission (POST 302 sans erreur), ajouté en UI-027. - Après cette soumission, aucun tableau d'habilitations n'est rendu sur `/prevention/`, ajouté en UI-028. - Les listes produits, références, mouvements et profils de demande ont été inspectées : aucun champ de recherche, filtre ou pagination visible (UI-029). - Transfert d'une quantité supérieure au stock : le formulaire reste en 200 avec message métier et aucun transfert supplémentaire. - Document artificiel `test_document.pdf` téléversé sur l'intervention 1 : téléchargement ID 1 répond 200, mais le détail ne l'affiche pas (UI-030). - Téléversement d'un fichier `.exe` artificiel : redirection avec rejet et aucun second document téléchargeable (ID 2 renvoie 404). - Vérification responsive structurelle : les pages produits, stock, prévention, planning et intervention contiennent la meta viewport et des classes Bootstrap responsive ; le seul rendu multi-viewport visuel reste celui déjà réalisé sur entreprises, faute de navigateur disponible dans cette reprise. - La prévision détaillée `/cleaning/forecast/1` répond 200 et affiche stock, consommation, sécurité et commande ; la configuration globale a été corrigée dans le dépôt local (UI-002), à revalider sur VM. ## Prochaine étape Qualifier ultérieurement UI-017 et UI-031 dans une passe de code dédiée, puis reprendre les déplacements et cycles de vie d'équipements. Les contrôles stock, formulaires et planning indépendants restent à poursuivre. ## Revalidation VM — 22 août 2026 - **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/` en 500 avec relation salle absente). - **CORRIGÉ PARTIELLEMENT — PROBLÈME RÉSIDUEL** : UI-012 (lien global Journaux encore visible malgré le 403). Le dashboard est revenu en 200 et affiche « Aucun équipement ». Six salles, deux groupes d'équipements, une entreprise, une intervention, un PDF artificiel et un mouvement de transvasement ont été ajoutés et laissés dans la base ; aucune donnée antérieure n'a été supprimée. Contrôle de non-régression séquentiel après revalidation : bâtiments, zones, salles, équipements, entreprises, prévention, planning, produits, références, mouvements et emplacements renvoient 200. La VM reste lente mais stable sur ce lot (environ 0,8 à 3,7 s par page) ; aucun test de charge n'a été lancé. ## Passe de corrections locales P1 — 2026-08-22 État : correctifs implémentés dans le dépôt, revalidation VM requise. Corrigés dans le code : UI-001, UI-002, UI-003, UI-012, UI-015, UI-016, UI-017, UI-019, UI-022, UI-024 et UI-030. Tests locaux ajoutés dans `tests/integration/test_ui_p1_regressions.py` et exécutés avec les suites équipements, nettoyage et audit intervention. À revalider sur VM : création salle avec bâtiments existants, trois pages cleaning sur données `TEST_UI_*`, dashboard/liste avec relations nulles, upload puis affichage d'un document, et visibilité des menus pour les profils RBAC existants. Dernière exécution locale ciblée : **16 passed** (`pytest` sur les quatre fichiers concernés). Suite complète locale : **117 passed, 1 failed, 1 error**. Le test échoué est `test_gmao_config_caps_lookback_at_one_year`, hors périmètre de cette passe (la configuration de contexte GMAO est explicitement exclue) ; son teardown échoue également sur une contrainte `gmao_context.user_id` nulle. Aucun échec des tests ciblés par les correctifs P1. ## Passe corrective ciblée locale — 22 août 2026 UI-017, UI-031 et le résidu UI-012 sont **CORRIGÉS DANS LE CODE — À REVALIDER SUR VM**. UI-017 accepte désormais les quatre combinaisons de relations optionnelles ; UI-031 rend les fiches d'équipement groupé et sa hiérarchie même sans enfant ; UI-012 aligne le bouton Journaux sur `watchdog_dnd.view`. Tests ciblés : **10 passed** ; suites demandées : **19 passed**. Suite complète : **120 passed, 2 failed, 1 error**. Le test historique de lookback GMAO échoue toujours avec son teardown ; un test stock échoue aussi ## Revalidation VM après déploiement — 22 août 2026 Correctifs vérifiés : `8c54f46`, `864f65d`, `f2783a0`, `ce6d8ae`. | Élément | Statut | Résultat observé | |---|---|---| | UI-017 — liste interventions | **VALIDÉ SUR VM** | Liste, détails, planning et dashboard en 200 ; relations absentes affichées par un libellé humain. | | UI-031 — détail équipements | **TOUJOURS REPRODUCTIBLE** | `/equipments/1` et `/equipments/2` en 500 ; hiérarchies JSON en 200 avec zone, salle et quantités. | | UI-012 — lien Journaux | **VALIDÉ SUR VM (négatif)** | `chatgpt` n'a pas le lien et `/logs/` reste 403 ; contrôle positif à compléter. | Les scénarios de déplacement, casse, réparation et mise au rebut restent bloqués par UI-031. Aucun nouveau compte ni objet n'a été créé pendant cette revalidation ; les données `TEST_UI_*` existantes ont été conservées. Les zones interdites et l'utilisateur `alban` n'ont pas été touchés. ### Couverture de cette passe - Contrôle santé et conservation de la base : terminé. - UI-017 : terminé et validé sur VM. - UI-031 : hiérarchie revalidée, détail encore bloqué. - UI-012 : contrôle négatif terminé ; contrôle positif restant. - Scénarios équipements dépendants du détail : non exécutables tant que le 500 persiste. Prochaine étape : corriger UI-031 dans une passe de code distincte, puis revalider sur la VM avant de reprendre les mouvements d'équipements. ## Reprise locale sur copie de VM — 22 août 2026 URL locale : `http://127.0.0.1:5080/`. - Docker : MariaDB, Flask et Adminer démarrés et sains ; migrations Alembic appliquées au démarrage. - Base : copie locale de la VM, données `TEST_UI_*` présentes et conservées. - Build exécuté avec le commit `d4d80a3`, puis relancé avec le correctif `08c5b65`. - Watchdogs/intégrations : non configurés et non sollicités. ### Correctifs et revalidation locale - **UI-017 — VALIDÉ LOCALEMENT SUR COPIE VM** : liste, détails, planning et dashboard en 200 pour les relations optionnelles ; libellés humains. - **UI-031 — VALIDÉ LOCALEMENT SUR COPIE VM** : cause reproduite dans les logs (`TemplateRuntimeError: No filter named 'nl2br'`), filtre enregistré dans la factory, détail et hiérarchie des équipements 1/2 en 200. - **UI-012 — VALIDÉ LOCALEMENT SUR COPIE VM** : contrôle négatif avec `chatgpt` (lien absent/403) et contrôle positif avec `TEST_UI_REVALIDATION_RBAC` (lien présent/`/logs/` en 200). ### Scénarios équipements exécutés Un groupe correctement déclaré `TEST_UI_EQ_CHAISES_GROUP_CORRECT` (ID 3, quantité 30, salle 2) a été créé pour compléter le scénario importé dont le champ historique `is_group` était faux. Déplacements quantitatifs de 1 puis 5 unités vers la salle 3 : mouvement journalisé, groupe cible ID 4 avec 6 unités, refus d'une quantité 999 sans quantité négative. Une unité a été retirée pour réparation (ID 5), l'intervention ID 3 créée, puis la réparation terminée et l'unité remise en service. Une autre unité (ID 6) a été proposée puis confirmée au rebut ; elle est `jete`, sans salle, et conserve ses événements de cycle de vie. Un luminaire fixe `TEST_UI_EQ_LUMINAIRE_LOCAL` (ID 7) a été créé. La tentative de déplacement est refusée par la règle de mobilité fixe et l'équipement reste dans sa salle. ### Contrôle de régression local Le balayage séquentiel des pages principales (patrimoine, interventions, planning, prévention, stock, RBAC, détail équipements) n'a relevé aucun 500. `/documents/` reste un 404 connu (UI-011). Le test ciblé `test_grouped_equipment_detail_and_hierarchy` passe : **1 passed**. après modification du rôle admin par les tests RBAC. Ces résultats sont hors des trois correctifs ciblés. Commits : `8c54f46`, `864f65d`, `f2783a0`. ### Fiches papier UI-023 est corrigé localement : `request_enabled` est désormais visible et modifiable dans `/cleaning/products//edit`. Le produit `TEST_UI_DETERGENT_SOL` a été activé et apparaît dans `/cleaning/requests/new`. Test automatisé associé : **1 passed** (`product_request_enabled_is_editable`). ## Étude d'architecture — centre documentaire V2 et moteur de planning interne Date : 22 août 2026 Étude terminée sans modification du code applicatif. Deux spécifications ont été produites : - `DOCUMENT_CENTER_PROPOSAL_V2.md` : agrégation en lecture par adaptateurs des interventions, équipements et produits, sans table commune ni copie de fichier ; RBAC `documents.view` combiné à la permission source ; - `PLANNING_ENGINE_PROPOSAL.md` : planning interne autonome, saisie manuelle des salles, provenance des créneaux, Pronote facultatif, tâches préventives, administratives et entreprises, urgences, heuristique déterministe et compatibilité multi-techniciens future. Aucune route, migration, permission, modèle, template, synchronisation ou fonctionnalité n'a été créée. Développement conditionné à la validation des questions listées dans les deux documents. ## Phase 1 d'implémentation — fondations documentaires et planning interne Date de reprise : 22 août 2026 — URL locale `http://127.0.0.1:5080/`. La migration `g1a2b3c4d5e6` a été appliquée à la copie locale de la base VM. Elle ajoute les types documentaires intervention/équipement, la provenance et la résolution des créneaux `RoomSchedule`, ainsi que la permission `documents.view`. Les données `TEST_UI_*` et `alban` sont conservées. Fondations livrées et testées localement : - Centre documentaire en lecture `/documents/` et vue FDS `/documents/fds`, agrégation par adaptateurs des interventions, équipements et produits, recherche, filtres, pagination, localisation calculée et téléchargement contrôlé sans stockage parallèle ; - types métier intervention/équipement avec valeur historique `autre` ; - planning interne `/planning/rooms`, saisie manuelle, protection contre la synchronisation, provenance et résolution manuel/Pronote/import ; - service de disponibilité de salle consommant uniquement la vue interne résolue, sans appel direct à Pronote ; préparation de l'usage d'une durée préventive existante. Tests ciblés Phase 1 : **3 passed** ; suites P1/formulaires/stock/interventions : **20 passed**. Le rebuild Docker et la revalidation HTTP sur la copie locale restent à finaliser avant le bilan de phase.