gmao/docs/AUDIT_2026-08-14.md

# Réaudit fonctionnel, technique et UI

Date : 14 août 2026

État audité : branche `main`, commit `8f276b5`

Périmètre : routes Flask, templates actifs, permissions, données MariaDB,
planification, intégrations, Docker, sauvegardes et tests.

## Verdict

Le projet est utilisable comme environnement de développement et de
démonstration. Il n'est pas encore prêt pour une utilisation réelle au collège.
Les principaux blocages sont la planification préventive incohérente, plusieurs
pages en erreur, les vocabulaires de statuts divergents, le compte de test
`admin/admin`, l'autorisation des documents et une stratégie de restauration
incomplète.

Le dépôt était propre et synchronisé au début de l'audit. L'audit n'a modifié ni
la base ni les données de production.

## Mesures et contrôles

- 319 règles d'URL et 317 endpoints enregistrés ;
- 121 routes GET fixes testées avec un compte administrateur ;
- 67 tests automatisés réussis ;
- 163 appels à `render_template`, pour 138 templates distincts ;
- 15 liens `url_for()` invalides dans les templates actifs ;
- 32 noms de templates dupliqués entre le dossier global et les blueprints ;
- 5 pages fixes reproduisent une erreur ;
- 376 équipements et 470 tâches planifiées dans la base auditée ;
- environ 1,15 Mo de HTML pour la liste des 376 équipements.

## Blocages P0

### Authentification

Le compte de test `admin/admin` est actif. Avant ouverture à d'autres
utilisateurs, il faut supprimer ce mot de passe, imposer un changement au
premier accès, refuser les mots de passe faibles et journaliser les échecs de
connexion.

### Planification préventive

La base contient 330 tâches de lot et 470 échéances, dont 300 placées un
week-end. Les 330 tâches importées sont actuellement classées comme
calendaires. Les règles gel, orage, saison, compteur et événement ne sont donc
pas correctement représentées.

Deux chemins de génération coexistent. Le chemin historique ignore une partie
du calendrier de travail. Le moteur récent traite mieux les déclencheurs mais
ne recalcule pas toujours la prochaine date à partir de la dernière réalisation.

Un seul moteur doit :

- partir de la dernière exécution ;
- respecter périodicité, anticipation et jours travaillés ;
- fermer les vacances scolaires par défaut ;
- accepter les jours exceptionnels avec horaires propres à chaque date ;
- distinguer calendrier, saison, météo, événement et compteur ;
- prévisualiser et réconcilier les échéances avant écriture ;
- empêcher les doublons par une contrainte en base.

### Pages en erreur et navigation

Les routes fixes suivantes ont échoué pendant le test :

- `/admin/room-types/new` : template absent ;
- `/planning/availability/leave/new` : endpoint de retour inexistant ;
- `/room-types/new` : formulaire non transmis au template ;
- `/yeastar/api/extensions` : erreur 500 lorsque Yeastar est absent ;
- `/yeastar/config` : accès incorrect à une configuration vide.

La création d'une tâche préventive référence aussi `LotTask` sans import local,
et les routes de formation construisent des attributs absents de leurs modèles.

### Statuts et tableau de bord

Les équipements présents utilisent notamment `en_service`, `en_panne`,
`en_maintenance`, `hs`, `a_jeter` et `jete`, tandis que certains indicateurs
recherchent encore `actif` ou `panne`. Les totaux du tableau de bord peuvent
donc être faux. L'urgence mélange par endroits le statut et la priorité, et le
stock faible est encore fixé à zéro.

Une énumération unique, une migration des valeurs et des tests de statistiques
sont nécessaires.

### Intégrité des interventions

Une intervention générale sans équipement peut être associée silencieusement
au premier équipement de la base. Une intervention doit pouvoir cibler un
équipement, une salle, une zone, un bâtiment, un logement ou aucun objet
patrimonial, sans attribution artificielle.

Le message Outlook ou ENT à l'origine d'une intervention doit être conservé en
lecture seule au lieu d'être supprimé après conversion.

### API, documents et historique

L'authentification API lit un attribut `api_key` absent du modèle clé/valeur.
Les futures clés doivent être hachées, révocables, expirables, limitées par
permission et auditées.

Le blueprint `documents` n'est pas classé explicitement dans les permissions :
la lecture peut hériter d'un droit trop large tandis que les mutations exigent
un droit système. Les droits doivent venir de l'objet parent. Il faut également
contrôler MIME, contenu, taille, checksum et suppression logique.

Les changements de statut et autres historiques ne sont pas réellement
immuables s'ils sont supprimés en cascade avec l'intervention.

### Sauvegarde et exploitation

La sauvegarde actuelle ne constitue pas encore un plan de reprise : les uploads
et la configuration ne sont pas couverts de bout en bout, il n'y a pas de copie
chiffrée hors machine et aucune restauration régulière n'est vérifiée.

Avant production : reverse proxy HTTPS, cookies sécurisés, sauvegarde complète,
copie hors machine, restauration automatisée de contrôle et supervision des
échecs.

## État fonctionnel des données

| Objet | Nombre |
|---|---:|
| Bâtiments | 7 |
| Zones | 22 |
| Salles | 228 |
| Logements | 0 |
| Catégories | 36 |
| Lots | 91 |
| Équipements | 376 |
| Interventions | 0 |
| Tâches de lot | 330 |
| Tâches planifiées | 470 |

Points de qualité : 29 salles n'ont pas de zone, 87 lots déclarés présents
n'ont pas d'équipement directement associé et aucun lot n'est marqué absent.
Le diagnostic des lots devra compter séparément les équipements directs et les
équipements héritant du lot de leur groupe.

## Navigation et pages orphelines

Le contrôle automatique a trouvé 34 routes GET sans lien entrant. Elles ne sont
pas toutes destinées à la navigation : 19 sont des API, exports, redirections
ou formulaires enfants qui doivent être ouverts depuis leur liste parente.

Les accès directs utiles ajoutés au menu sont :

- profil utilisateur ;
- zones et historique des compteurs ;
- ajout de compte et dossiers surveillés Outlook ;
- messages et interprétations ENT ;
- salles, personnels et professeurs PRONOTE ;
- configuration des identifiants et du watchdog DND Yeastar.

Les routes historiques `/admin/room-types`, `/admin/services` et
`/admin/staff` dupliquent des écrans métier existants. Elles ne doivent pas être
ajoutées comme seconds écrans dans le menu : elles doivent être redirigées vers
les pages canoniques puis supprimées. Les API et téléchargements ne sont pas des
pages de menu.

Une vérification automatique de navigation doit être ajoutée à la CI : toute
nouvelle page HTML GET sans paramètre doit soit recevoir un lien, soit être
explicitement déclarée comme page enfant, redirection ou écran interne.

## Proposition UI

### Architecture de navigation

Conserver cinq espaces principaux : Accueil, Patrimoine, Interventions,
Planning et Prévention. Les intégrations et l'administration restent réservées
aux utilisateurs autorisés. À terme, la longue liste actuelle d'intégrations
devrait devenir une page d'accueil « Intégrations » composée de cartes avec
état, configuration, dernière synchronisation et journaux.

### Tableau de bord

Afficher des cartes dépendant du rôle : tâches du jour, retards, urgences,
attente de pièce ou prestataire, contrats proches de l'échéance, stocks faibles,
lots incohérents et temps de prévention. Chaque carte doit ouvrir une liste déjà
filtrée.

### Inventaire

Ne plus rendre l'arbre complet. Charger progressivement : catégorie, bâtiment
ou logement, zone, salle, groupe puis unité. Ajouter recherche instantanée,
filtres mémorisés, sélection multiple et compteurs par niveau.

### Création d'équipements

Proposer trois parcours : fiche rapide, groupe quantitatif et assistant
multi-salles. Les valeurs venant du lot doivent être visibles comme héritées.
La création en masse doit offrir aperçu, validation des anomalies, rapport et
annulation.

### Interventions

Ajouter liste, Kanban et calendrier. La fiche doit utiliser une chronologie
unique pour statut, diagnostic, commentaires, photos, temps, pièces et visite
prestataire. La détection de récurrence doit être paramétrable selon la
catégorie : prise, fenêtre ou luminaire ne se traitent pas comme chaise ou
graffiti.

### Logements

Ajouter historique des occupants, états des lieux, clés, compteurs, documents,
inventaire et interventions. Les données personnelles de l'occupant exigent
une permission séparée de la simple consultation du patrimoine.

### Prévention

Séparer tableau de bord, agents, risques, actions, habilitations, formations,
incidents, DUERP et temps consacré. La cible de 10 % doit être calculée depuis
le temps réellement travaillé et tenir compte de chaque journée exceptionnelle
pendant les petites et grandes vacances.

### Composants et accessibilité

Réduire les pages de plusieurs centaines de lignes et les nombreux styles ou
scripts intégrés. Construire des composants communs pour champs, badges,
tableaux, filtres, états vides et erreurs. Corriger les blocs JavaScript nommés
`scripts` alors que le layout rend `extra_scripts`, ajouter des libellés aux
boutons icône et fournir les ressources critiques localement plutôt que par CDN
seulement.

## Feuille de route

### Lot 1 — Stabilisation

- supprimer le mot de passe de test ;
- corriger les cinq routes en erreur et les 15 liens invalides ;
- réparer création de tâche et formations ;
- unifier les statuts et les statistiques ;
- empêcher l'attribution artificielle des interventions ;
- tester chaque page fixe en CI.

### Lot 2 — Fiabilité métier

- fusionner les moteurs de maintenance ;
- réconcilier les 470 tâches ;
- intégrer complètement calendrier scolaire et horaires exceptionnels ;
- corriger permissions documents et clés API ;
- rendre les historiques non destructibles ;
- tester une restauration complète.

### Lot 3 — Parcours quotidiens

- refondre navigation et tableau de bord ;
- charger l'inventaire progressivement ;
- finaliser la création en masse ;
- compléter les logements ;
- ajouter le workflow et la récurrence des interventions.

### Lot 4 — Fonctions avancées

- générer les visites contractuelles ;
- tracer tous les mouvements de stock ;
- fiabiliser compteurs et consommables ;
- compléter prévention et DUERP ;
- fournir exports métier et suivi des coûts.

### Lot 5 — Mise en production

- HTTPS et configuration de production ;
- dépendances verrouillées et analyse de vulnérabilités ;
- sauvegardes chiffrées hors machine ;
- test de restauration ;
- supervision, accessibilité, tests mobiles et test de charge.