diff --git a/docs/AUDIT_2026-08-14.md b/docs/AUDIT_2026-08-14.md
new file mode 100644
index 0000000..9b54899
--- /dev/null
+++ b/docs/AUDIT_2026-08-14.md
@@ -0,0 +1,269 @@
+# 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.
diff --git a/docs/AUDIT_FONCTIONNEL_ET_ROUTES.md b/docs/AUDIT_FONCTIONNEL_ET_ROUTES.md
index 7438acc..c0905a5 100644
--- a/docs/AUDIT_FONCTIONNEL_ET_ROUTES.md
+++ b/docs/AUDIT_FONCTIONNEL_ET_ROUTES.md
@@ -1,5 +1,9 @@
# Audit fonctionnel, pages, routes et permissions
+> Ce document conserve l'audit historique réalisé avant les phases de
+> sécurisation. Le réaudit de l'état courant et la feuille de route active sont
+> disponibles dans [AUDIT_2026-08-14.md](AUDIT_2026-08-14.md).
+
Date de l'audit : 14 août 2026
Périmètre : application Flask `app_new`, modèles, templates, routes enregistrées, configuration Docker et tests.