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.