Refondre les parcours UI/UX de LMNP Organizer après l’audit du 2 septembre 2026 #160

Open
opened 2026-09-02 23:07:06 +02:00 by nessar · 24 comments
nessar commented 2026-09-02 23:07:06 +02:00 (Migrated from 172.24.0.1:8928)

Problem Statement

LMNP Organizer présente une interface sombre cohérente, une navigation persistante, des composants homogènes et de bonnes bases sémantiques. L'audit réalisé le 2 septembre 2026 dans une session authentifiée, sur grand écran de 2174 px puis sur mobile de 390 px, montre néanmoins que l'application reste inutilement coûteuse à utiliser.

Les difficultés principales ne sont pas esthétiques. Plusieurs messages décrivent correctement un prérequis manquant sans permettre au Bailleur de le résoudre. Les formulaires Appartement, Bail et Inventaire du mobilier imposent de très longues pages sans progression utile ni action d'enregistrement persistante. Les états vides répètent l'absence de données au lieu de guider vers la prochaine action. Les listes prévues pour de petits portefeuilles n'emploient qu'une fraction du grand écran. Les dates, montants, titres d'onglet, actions et libellés accessibles ne sont pas uniformes. Le parcours fiscal ne rend pas toujours assez clairement son état de validation et les conséquences de l'enregistrement.

Ces incohérences créent des impasses, augmentent le risque de perte de saisie et donnent parfois à une absence de configuration l'apparence d'une erreur technique ou d'une valeur réellement nulle. Elles touchent les douze rubriques principales et les principaux écrans secondaires, avec un coût particulièrement élevé dans l'Inventaire du mobilier, les Baux, la fiche Appartement, les Loyers, les Amortissements et la Fiscalité.

Solution

Refondre les parcours concernés autour de quelques règles communes : chaque prérequis manquant mène à l'action corrective et conserve le contexte de retour ; les états techniques, métier et vides sont distincts ; les formulaires longs deviennent des ensembles de rubriques courtes avec complétude visible et enregistrement explicite ; les listes utilisent des grilles responsives adaptées à des portefeuilles individuels de un à vingt Appartements ; les actions destructives quittent le premier niveau ; les dates, montants, titres et libellés accessibles sont homogènes en français.

Le Profil bailleur complet reste l'unique prérequis global bloquant après authentification. Une fois ce profil enregistré, l'application n'impose aucun assistant global : le Tableau de bord propose deux parcours indépendants, « Mettre en location » et « Préparer la comptabilité », et chaque écran ne bloque que les opérations dont les prérequis métier sont réellement absents.

La refonte réutilise l'architecture existante. Elle conserve les agrégats versionnés, les sauvegardes atomiques, le contrôle des modifications non enregistrées, le Calendrier en liste sur mobile, la distinction Justificatif de dépense/Dépense et les snapshots historiques. Elle n'introduit pas de système générique de brouillons, de nouvelle bibliothèque, de tableau alternatif, de pagination, de recherche, de certification fiscale ni de vérification externe du SIRET.

User Stories

  1. En tant que Bailleur, je veux distinguer immédiatement une panne technique, un prérequis métier manquant et une liste réellement vide, afin de comprendre la prochaine action utile.
  2. En tant que Bailleur, je veux qu'un prérequis métier manquant propose un accès direct à sa résolution, afin de ne pas devoir retrouver manuellement l'écran concerné.
  3. En tant que Bailleur, je veux revenir à mon contexte initial après avoir résolu un prérequis, afin de poursuivre le parcours interrompu.
  4. En tant que Bailleur, je veux que « Réessayer » soit réservé aux erreurs techniques, afin de ne pas relancer une opération dont la cause métier reste inchangée.
  5. En tant que Bailleur, je veux des chargements, rafraîchissements, soumissions et erreurs fidèles à l'opération en cours, afin de ne jamais confondre une attente avec un résultat vide.
  6. En tant que Bailleur, je veux conserver le contenu déjà chargé pendant un rafraîchissement, afin d'éviter les écrans vides et les déplacements de mise en page.
  7. En tant que Bailleur, je veux que chaque route affiche un titre d'onglet descriptif terminé par « LMNP Organizer », afin d'identifier la page dans l'historique et les onglets du navigateur.
  8. En tant que Bailleur, je veux des libellés d'ajout, de retour, d'enregistrement et de confirmation cohérents, afin d'anticiper le résultat d'une action.
  9. En tant que Bailleur, je veux que les commandes de rechargement sans utilité métier disparaissent des pages chargées automatiquement, afin de réduire le bruit visuel.
  10. En tant que Bailleur, je veux que les commandes métier conservées décrivent leur effet réel, afin de ne pas les confondre avec un simple rechargement.
  11. En tant que Bailleur, je veux que les actions destructives soient placées dans un menu secondaire ou une zone de danger, afin d'éviter une activation accidentelle.
  12. En tant que Bailleur, je veux confirmer explicitement toute suppression, afin de comprendre précisément la ressource affectée.
  13. En tant que Bailleur, je veux que les listes d'Appartements, de Locataires et de Baux utilisent l'espace disponible, afin de parcourir efficacement mon portefeuille sur grand écran.
  14. En tant que Bailleur, je veux que ces listes restent lisibles et manipulables à 390 px, afin d'utiliser l'application sur mobile.
  15. En tant que Bailleur, je veux des formulaires qui conservent une action d'enregistrement visible, afin de ne pas parcourir toute une longue page pour sauvegarder.
  16. En tant que Bailleur, je veux être averti avant de quitter une saisie non enregistrée, afin de ne pas perdre mon travail.
  17. En tant que Bailleur, je veux que le premier envoi invalide affiche un résumé actionnable et place le focus sur le premier champ invalide, afin de corriger rapidement le formulaire.
  18. En tant qu'utilisateur du clavier ou d'une technologie d'assistance, je veux des noms accessibles français, un ordre de focus logique et un focus visible, afin d'utiliser les mêmes parcours sans ambiguïté.
  19. En tant que Bailleur, je veux retrouver les rubriques dans les groupes Pilotage, Location, Finances et fiscalité et Système, afin de comprendre la structure fonctionnelle de l'application.
  20. En tant que Bailleur sur desktop, je veux que les groupes de navigation restent visibles, afin d'accéder directement aux rubriques sans ouvrir des sous-menus répétitifs.
  21. En tant que Bailleur sur mobile, je veux que le menu « Plus » reprenne les mêmes groupes, afin de conserver la même carte mentale qu'au desktop.
  22. En tant que Bailleur sur mobile, je veux voir « Accueil » plutôt que « Tableau de bord » dans la navigation basse, afin d'éviter un libellé tronqué.
  23. En tant qu'Administrateur, je veux accéder à Administration dans un espace séparé et réservé à mon rôle, afin de ne pas mélanger les fonctions système et le portefeuille locatif.
  24. En tant que Bailleur non administrateur, je veux que l'entrée Administration soit absente, afin de ne pas voir une fonction inaccessible.
  25. En tant que Bailleur venant de m'authentifier, je veux devoir compléter mes prénom, nom, e-mail, téléphone et adresse postale avant d'accéder aux fonctions authentifiées, afin que les documents futurs disposent de l'identité requise.
  26. En tant que Bailleur bloqué sur le Profil bailleur, je veux pouvoir me déconnecter, afin de ne jamais rester prisonnier d'un dialogue obligatoire.
  27. En tant que Bailleur bloqué sur le Profil bailleur, je veux une erreur d'enregistrement explicite et réessayable, afin de distinguer un formulaire incomplet d'une panne technique.
  28. En tant que Bailleur ayant complété son Profil bailleur, je veux que les autres modules restent indépendants hors prérequis réels, afin de ne pas suivre un assistant artificiellement obligatoire.
  29. En tant que Bailleur débutant, je veux voir un parcours « Mettre en location », afin de connaître la prochaine étape entre Appartement, Locataire, Bail, Inventaire du mobilier, État des lieux d'entrée et Loyers.
  30. En tant que Bailleur préparant sa gestion financière, je veux voir un parcours « Préparer la comptabilité », afin de connaître la prochaine étape entre Appartement, Dépenses ou Prêt immobilier, Plan d'amortissement et Exercice fiscal.
  31. En tant que Bailleur, je veux une seule prochaine action par parcours, afin de progresser sans être confronté à une checklist indistincte.
  32. En tant que Bailleur ayant un seul élément à compléter, je veux être dirigé directement vers celui-ci, afin d'éviter un choix inutile.
  33. En tant que Bailleur ayant plusieurs Appartements ou éléments à compléter, je veux choisir dans une liste compacte, afin que l'application ne décide pas arbitrairement à ma place.
  34. En tant que Bailleur ayant terminé un parcours, je veux retrouver le Tableau de bord normal sans statut global « configuration terminée », afin que les modules facultatifs restent facultatifs.
  35. En tant que Bailleur sans Exercice fiscal disponible, je veux une seule explication précise et une action corrective, afin de ne pas lire plusieurs cartes « Période indisponible » identiques.
  36. En tant que Bailleur sans Exercice fiscal disponible, je veux conserver la vue opérationnelle calculable, afin que le Tableau de bord reste utile.
  37. En tant que Bailleur sans données financières affichables, je veux que les grands graphiques vides soient remplacés par le démarrage contextuel, afin de réduire le défilement inutile.
  38. En tant que Bailleur disposant d'Exercices fiscaux, je veux sélectionner explicitement l'année suivie, afin de comprendre la période de tous les indicateurs financiers.
  39. En tant que Bailleur, je veux que le Tableau de bord n'affiche plus une carte Compte dupliquée, afin de réserver l'espace aux informations de gestion.
  40. En tant que Bailleur, je veux que la section opérationnelle reste distincte des indicateurs rattachés à l'Exercice fiscal, afin de ne pas confondre leurs périodes.
  41. En tant que Bailleur, je veux créer un Appartement en renseignant uniquement son nom, son adresse, sa Date d'acquisition immobilière et son prix d'acquisition, afin d'entrer rapidement dans sa fiche.
  42. En tant que Bailleur, je veux que le prix d'acquisition soit initialement vide avec un exemple, afin de ne pas confondre zéro avec une valeur réellement déclarée.
  43. En tant que Bailleur, je veux être conduit vers la fiche de l'Appartement après sa création, afin de compléter les informations nécessaires à mon rythme.
  44. En tant que Bailleur, je veux ouvrir la fiche d'un Appartement depuis son nom ou sa carte, afin de disposer d'une action de consultation naturelle.
  45. En tant que Bailleur, je veux que la fiche Appartement organise séparément les informations principales, juridiques, énergétiques, les équipements et les Espaces privatifs, afin de ne pas subir un seul flux très long.
  46. En tant que Bailleur, je veux connaître la complétude de chaque rubrique de la fiche Appartement, afin de savoir ce qui manque avant une opération contractuelle.
  47. En tant que Bailleur, je veux pouvoir gérer Dépenses, Prêts immobiliers et Plans d'amortissement même si le profil juridique de l'Appartement est incomplet, afin que seules les dépendances réelles bloquent une action.
  48. En tant que Bailleur, je veux que la génération ou la finalisation d'un Bail indique précisément les informations juridiques manquantes de l'Appartement, afin de les corriger depuis le bon contexte.
  49. En tant que Bailleur, je veux que les actions « Ajouter une dépense », « Voir les prêts » et « Créer le plan d'amortissement » soient regroupées et espacées, afin de pouvoir les distinguer et les activer facilement.
  50. En tant que Bailleur sur mobile, je veux que ces actions occupent chacune toute la largeur, afin d'éviter les collisions et les petites cibles.
  51. En tant que Bailleur, je veux que la correction d'une Date d'acquisition immobilière ou d'un prix déjà référencé conserve les protections métier existantes, afin de ne pas réécrire silencieusement l'historique.
  52. En tant que Bailleur, je veux supprimer un Appartement depuis une action secondaire confirmée, afin que cette commande ne concurrence pas l'ouverture de sa fiche.
  53. En tant que Bailleur, je veux saisir directement un Locataire déjà connu ou géré hors de l'application, afin de ne pas dépendre d'une Candidature.
  54. En tant que Bailleur, je veux qu'un Locataire issu d'une Candidature et un Locataire saisi directement utilisent la même fiche, afin de ne pas créer deux catégories artificielles de personnes contractantes.
  55. En tant que Bailleur, je veux que la carte Locataire affiche le nombre de Pièces jointes plutôt que leurs noms bruts, afin de conserver une liste lisible.
  56. En tant que Bailleur, je veux voir dans la fiche Locataire le nom de fichier tronqué visuellement, son nom complet accessible, son type et sa taille, afin d'identifier chaque Pièce jointe sans casser la mise en page.
  57. En tant que Bailleur, je veux une seule commande d'ajout de fichiers annoncée aux technologies d'assistance, afin d'éviter deux actions équivalentes.
  58. En tant que Bailleur, je veux utiliser directement l'e-mail et le téléphone d'un Locataire, afin de le contacter depuis l'appareil courant.
  59. En tant que Bailleur, je veux voir les Baux associés dans la fiche Locataire avec leur statut, afin de retrouver son historique contractuel.
  60. En tant que Bailleur, je veux ouvrir un Bail associé depuis la fiche Locataire, afin de passer directement au bon dossier.
  61. En tant que Bailleur sélectionnant une Candidature, je veux choisir explicitement entre créer un Locataire et associer un Locataire existant, afin d'éviter les doublons ou rapprochements imposés.
  62. En tant que Bailleur, je veux qu'aucune ressemblance de nom, d'e-mail ou de téléphone ne fusionne automatiquement deux personnes, afin de garder le contrôle sur leurs identités.
  63. En tant que Bailleur associant une Candidature à un Locataire existant, je veux conserver les coordonnées actuelles de ce Locataire, afin qu'une association n'écrase pas silencieusement ses données.
  64. En tant que Bailleur, je veux parcourir les cinq rubriques d'un Bail dans un ordre non linéaire, afin de compléter d'abord les informations disponibles.
  65. En tant que Bailleur, je veux que la rubrique Parties déverrouille les rubriques qui dépendent de l'Appartement et des Locataires, afin de ne pas saisir des données sans contexte.
  66. En tant que Bailleur, je veux enregistrer un Bail brouillon dont certaines rubriques restent incomplètes, afin de reprendre le travail ultérieurement.
  67. En tant que Bailleur, je veux que les valeurs déjà renseignées soient validées à l'enregistrement, afin de ne pas conserver des formats ou invariants locaux invalides.
  68. En tant que Bailleur, je veux que la complétude contractuelle soit exigée avant la génération d'une Révision du document de bail ou la Finalisation, afin que le brouillon reste souple sans affaiblir les opérations irréversibles.
  69. En tant que Bailleur, je veux voir l'état de complétude de chaque rubrique du Bail, afin de savoir où intervenir sans pourcentage trompeur.
  70. En tant que Bailleur, je veux une revue exhaustive seulement au moment de générer ou finaliser le Bail, afin de ne pas maintenir un résumé latéral permanent et encombrant.
  71. En tant que Bailleur, je veux que les explications des clauses légales restent synthétiques avec le détail à la demande, afin de prendre une décision sans parcourir des blocs juridiques continus.
  72. En tant que Bailleur, je veux qu'une seule action principale soit mise en avant selon le statut du Bail, afin de distinguer consultation, reprise, génération, finalisation et clôture.
  73. En tant que Bailleur, je veux que les autres actions d'un Bail soient regroupées dans un menu secondaire, afin de ne pas afficher cinq commandes concurrentes sur une carte étroite.
  74. En tant que Bailleur, je veux que les Baux utilisent une grille de cartes adaptée au grand écran, afin d'employer l'espace sans introduire de vue tableau parallèle.
  75. En tant que Bailleur, je veux une sauvegarde atomique du Bail avec contrôle de version, afin qu'une rubrique enregistrée ne laisse pas le brouillon dans un état partiellement remplacé.
  76. En tant que Bailleur, je veux que les modifications non enregistrées du Bail soient protégées lors de la navigation, afin de ne pas perdre une longue saisie.
  77. En tant que Bailleur, je veux déclarer chaque catégorie réglementaire de mobilier comme Non vérifiée, Présente ou Absente, afin de distinguer l'absence d'examen d'une absence réelle.
  78. En tant que Bailleur, je veux saisir une quantité positive seulement lorsque le mobilier est Présent, afin de ne pas dupliquer ou contredire la déclaration de présence.
  79. En tant que Bailleur, je veux qu'un mobilier Absent ait automatiquement une quantité nulle, afin de préserver un état cohérent.
  80. En tant que Bailleur, je veux que « Description » ne prétende pas décrire l'état du mobilier, afin de réserver l'état au constat de l'État des lieux.
  81. En tant que Bailleur, je veux laisser temporairement une ligne d'Inventaire du mobilier dans « À attribuer », afin que le catalogue initial ne devine pas une pièce incorrecte.
  82. En tant que Bailleur, je veux attribuer chaque ligne à un Espace privatif réel avant que l'Inventaire soit complet ou figé, afin que le document contractuel reste précis.
  83. En tant que Bailleur, je veux voir les lignes groupées dans l'ordre des Espaces privatifs, précédées des lignes « À attribuer », afin de préparer une visite de façon naturelle.
  84. En tant que Bailleur sur desktop, je veux modifier l'Inventaire dans des lignes compactes, afin de réduire fortement le défilement.
  85. En tant que Bailleur sur mobile, je veux modifier l'Inventaire dans des cartes ou groupes repliables, afin de conserver des contrôles utilisables à 390 px.
  86. En tant que Bailleur, je veux voir un résumé de complétude des onze catégories réglementaires, afin d'identifier les déclarations encore manquantes.
  87. En tant que Bailleur, je veux enregistrer explicitement l'Inventaire depuis une barre d'actions persistante, afin de conserver la maîtrise de la sauvegarde.
  88. En tant que Bailleur, je veux conserver l'enregistrement atomique et versionné de l'Inventaire, afin qu'une concurrence ne remplace pas silencieusement mon travail.
  89. En tant que Bailleur ouvrant un État des lieux d'entrée sans Inventaire complet, je veux voir « Compléter l'inventaire » comme action principale, afin de résoudre réellement le blocage.
  90. En tant que Bailleur revenant de l'Inventaire, je veux utiliser explicitement « Reprendre l'état des lieux », afin de choisir quand revenir sans redirection automatique surprenante.
  91. En tant que Bailleur, je veux que le contexte de retour vers l'État des lieux soit conservé, afin de retrouver le Bail et l'étape concernés.
  92. En tant que Bailleur, je veux que « Réessayer » apparaisse sur l'État des lieux seulement après une panne technique, afin de ne pas confondre prérequis et incident.
  93. En tant que Bailleur, je veux que la page des Loyers s'intitule « Échéances et règlements », afin de décrire précisément son contenu.
  94. En tant que Bailleur sans Bail, je veux que l'état vide me propose de créer un Bail, afin de commencer le parcours utile.
  95. En tant que Bailleur ayant un Bail brouillon, je veux que l'état vide me propose de reprendre ce Bail, afin de poursuivre plutôt que recommencer.
  96. En tant que Bailleur ayant un Bail prêt mais non finalisé, je veux que l'état vide me propose de le finaliser, afin de créer les Échéances de loyer attendues.
  97. En tant que Bailleur ayant plusieurs éléments possibles, je veux choisir dans une liste compacte plutôt que subir une sélection arbitraire, afin d'agir sur le bon Appartement ou Bail.
  98. En tant que Bailleur sans échéance ni règlement, je veux un seul bloc compact, afin de ne pas parcourir deux grandes zones vides.
  99. En tant que Bailleur créant un Justificatif de dépense, je veux d'abord enregistrer son émetteur, ses dates et sa référence, afin de respecter la distinction entre le document source et les Dépenses qu'il justifie.
  100. En tant que Bailleur venant de créer un Justificatif de dépense, je veux accéder immédiatement à une checklist « Ajouter un fichier » et « Ajouter une dépense », afin de terminer le dossier sans croire que le montant appartient au document source.
  101. En tant que Bailleur, je veux que le formulaire d'un nouveau Justificatif remplace temporairement la liste ou l'état vide, afin de ne pas gérer deux contextes concurrents.
  102. En tant que Bailleur choisissant une politique de traitement des frais d'acquisition, je veux une explication accessible de son caractère global et irrévocable et de ses conséquences concrètes, afin de confirmer en connaissance de cause.
  103. En tant que Bailleur, je veux ensuite voir seulement un statut compact de cette politique, afin qu'une décision déjà prise ne monopolise plus la page.
  104. En tant que Bailleur sans Prêt immobilier, je veux une seule action « Ajouter un prêt », afin d'éviter un doublon entre l'en-tête et l'état vide.
  105. En tant que Bailleur ayant déjà un Prêt immobilier, je veux retrouver l'action d'ajout dans l'en-tête, afin d'étendre la liste sans dupliquer l'état vide.
  106. En tant que Bailleur créant un Prêt immobilier, je veux que le formulaire remplace temporairement la liste ou l'état vide, afin de me concentrer sur la saisie.
  107. En tant que Bailleur préparant un Prêt immobilier, je veux comprendre ce que montrera la prévisualisation du Tableau d'amortissement, afin de savoir pourquoi cette étape précède l'enregistrement.
  108. En tant que Bailleur saisissant un Prêt immobilier, je veux conserver la prévisualisation avant création, afin de vérifier les échéances attendues.
  109. En tant que Bailleur consultant les Amortissements par Exercice fiscal, je veux que chaque Appartement sans plan propose « Configurer le plan », afin de résoudre le blocage depuis la liste.
  110. En tant que Bailleur suivant cette action, je veux que l'Appartement soit présélectionné et le retour vers l'Exercice fiscal conservé, afin de ne pas reconstruire mon contexte.
  111. En tant que Bailleur, je veux lire « Modèle standard de décomposition du logement » plutôt que LOGEMENT_STANDARD_V1, afin de ne pas être exposé à un identifiant interne.
  112. En tant que Bailleur, je veux consulter la référence BOFiP pertinente dans une aide ou un détail, afin de conserver la source officielle sans encombrer le parcours principal.
  113. En tant que Bailleur, je veux que « Frais incorporés » et les autres valeurs monétaires affichent toujours leur unité, afin de ne pas interpréter un nombre nu.
  114. En tant que Bailleur configurant un Plan d'amortissement, je veux voir l'étape courante et la complétude des étapes, afin de reprendre le travail sans estimation d'effort artificielle.
  115. En tant que Bailleur renseignant son Profil fiscal LMNP, je veux que le SIRET soit formaté lisiblement et validé immédiatement comme quatorze chiffres avec une clé correcte, afin de corriger une erreur locale avant l'enregistrement.
  116. En tant que Bailleur, je veux savoir que LMNP Organizer ne consulte aucun registre et ne certifie pas mon établissement, afin de comprendre la portée de cette validation.
  117. En tant que Bailleur, je veux utiliser l'action « Enregistrer le profil fiscal », afin de comprendre qu'il s'agit d'une donnée modifiable et non d'une confirmation irréversible.
  118. En tant que Bailleur, je veux connaître les effets de l'enregistrement du Profil fiscal LMNP et la façon dont les Clôtures en figent une copie, afin de comprendre ce qui reste modifiable.
  119. En tant que Bailleur, je veux éviter un écran récapitulatif supplémentaire avant l'enregistrement du Profil fiscal LMNP, afin de ne pas allonger inutilement le parcours.
  120. En tant que Bailleur, je veux être protégé contre la perte d'une saisie fiscale non enregistrée, afin qu'un départ ou un rechargement ne supprime pas silencieusement mon travail.
  121. En tant que Bailleur, je veux que les erreurs fiscales apparaissent au premier essai d'enregistrement avec un résumé et un focus utile, afin de ne pas parcourir le formulaire à l'aveugle.
  122. En tant que Bailleur, je veux que toutes les dates civiles affichées et saisies utilisent le français tout en conservant leur valeur ISO, afin qu'aucun changement de fuseau ne décale le jour métier.
  123. En tant qu'utilisateur d'une technologie d'assistance, je veux que tous les boutons de calendrier soient annoncés en français, afin de ne pas rencontrer « Open calendar » dans une interface française.
  124. En tant que Bailleur, je veux saisir une date au clavier ou la choisir dans le calendrier avec le même résultat, afin d'utiliser le mode le plus efficace.
  125. En tant que Bailleur sur mobile, je veux conserver la liste chronologique du Calendrier, afin de consulter les événements sans grille mensuelle compressée.
  126. En tant que Bailleur sur mobile, je ne veux pas de sélecteur Mois/Liste tant qu'un besoin réel n'est pas observé, afin de conserver un écran simple.
  127. En tant que Bailleur ouvrant une boîte de dialogue du Calendrier, je veux un bouton de fermeture visible en plus d'Annuler, afin de fermer immédiatement l'overlay.
  128. En tant que Bailleur, je veux que les montants des tableaux comptables et fiscaux utilisent systématiquement deux décimales, afin d'aligner les valeurs détaillées.
  129. En tant que Bailleur, je veux que les cartes et résumés omettent les décimales inutiles mais conservent les centimes réels, afin de faciliter la lecture sans perdre d'information.
  130. En tant que Bailleur, je veux que toute valeur monétaire nulle porte le symbole euro, afin de ne pas confondre montant, quantité et compteur.
  131. En tant que Bailleur, je veux que les petits textes secondaires restent lisibles dans chaque thème, afin que les aides et métadonnées ne disparaissent pas visuellement.
  132. En tant que Bailleur, je veux que « Enregistrer le profil » tienne sur une ligne lorsque l'espace desktop le permet, afin que l'action conserve une apparence stable.
  133. En tant que Bailleur, je veux que l'enregistrement du profil soit inactif quand aucune donnée n'a changé puis redevienne disponible après une modification, afin de connaître l'état réel du formulaire.
  134. En tant que Bailleur sur mobile, je veux conserver dans Réglages une section Session avec les actions de compte, afin de compenser l'absence des informations de session de la barre latérale desktop.
  135. En tant que Bailleur, je ne veux pas une nouvelle rubrique de préférences de langue, formats ou notifications dans cette refonte, afin de ne pas ajouter des réglages non nécessaires à l'interface française actuelle.
  136. En tant qu'Administrateur, je veux lire « Fichiers stockés », « Espace utilisé » et « Appartements enregistrés », afin de comprendre les métriques sans vocabulaire d'infrastructure.
  137. En tant qu'Administrateur, je veux que les libellés respectent la casse française, afin d'éviter des formulations comme « Nombre actuel d'Appartements ».
  138. En tant qu'Administrateur, je veux que la page Administration reste limitée aux faits déjà disponibles, afin de ne pas présenter des tendances, quotas ou sauvegardes fictifs.
  139. En tant que Bailleur, je veux que toutes les opérations asynchrones désactivent seulement les commandes concernées pendant leur exécution, afin que le reste de la page reste utilisable.
  140. En tant que Bailleur, je veux que les boutons de soumission restent utilisables avant la première tentative lorsque le formulaire n'est pas occupé ou en lecture seule, afin d'obtenir des erreurs complètes et actionnables plutôt qu'un bouton mystérieusement inactif.

Implementation Decisions

Principes transverses

  • Conserver Angular Material, les composants partagés, la palette sémantique et les tokens Sass existants. Aucun nouveau paquet d'interface, de formulaire, de formatage, de grille ou d'accessibilité n'est ajouté.
  • Utiliser les termes français du glossaire dans l'interface et conserver les noms anglais dans le code et les contrats techniques, conformément à la stratégie de localisation existante.
  • Distinguer trois états : erreur technique avec action « Réessayer » ; prérequis métier avec action corrective et contexte de retour ; collection valide vide avec explication et création facultative.
  • Transporter le contexte d'origine lors des actions correctives. Après résolution, afficher une action de reprise explicite ou revenir au contexte lorsque la décision le prévoit ; ne pas introduire de redirection automatique surprenante.
  • Retirer les actions « Actualiser » qui ne font que répéter un chargement automatique. Conserver les nouvelles tentatives techniques et les commandes métier explicites, par exemple le prolongement d'un Échéancier lorsqu'il s'agit réellement d'une mutation.
  • Toute opération asynchrone expose son propre état. Le premier chargement utilise un squelette adapté au contenu ; un rafraîchissement conserve les données établies ; une mutation affiche une progression locale et empêche uniquement sa duplication.
  • Les boutons de soumission restent actifs hors attente et lecture seule. La première tentative invalide affiche un résumé lié aux champs, rend les erreurs locales visibles et concentre le premier contrôle invalide.
  • Les formulaires longs utilisent une barre d'actions persistante, une indication de rubriques complètes ou incomplètes et une protection contre la navigation avec modifications locales. Aucun moteur générique de brouillons ni autosauvegarde transversale n'est créé.
  • L'État des lieux conserve son autosauvegarde existante. Le Bail, l'Appartement, l'Inventaire du mobilier et le Profil fiscal LMNP utilisent des enregistrements explicites et atomiques.
  • Les suppressions quittent le premier niveau des cartes. Une carte conserve son action principale ; la suppression se trouve dans un menu secondaire ou dans la zone de danger de la fiche et utilise la boîte de confirmation Material existante.
  • Ajouter des titres de route descriptifs sous la forme « — LMNP Organizer » et les vérifier lors de chaque navigation, y compris les écrans secondaires.

Navigation, largeur et compte

  • La navigation desktop est structurée en groupes toujours ouverts : Pilotage contient Tableau de bord et Calendrier ; Location contient Appartements, Locataires, Baux et Échéances et règlements ; Finances et fiscalité contient Dépenses, Prêts, Amortissements et Fiscalité ; Système contient Réglages.
  • Administration reste une entrée séparée, protégée par le rôle Administrateur et absente pour les autres Bailleur.
  • Le menu mobile « Plus » reprend les mêmes groupes. Les entrées primaires mobiles restent Accueil, Loyers et Dépenses, avec « Accueil » comme libellé court affiché pour le Tableau de bord.
  • Les listes Appartements, Locataires et Baux utilisent une grille responsive de cartes pour la cible initiale de un à vingt Appartements. Il n'existe ni vue tableau parallèle, ni pagination, ni recherche avant qu'un besoin mesuré ne les justifie.
  • La carte de compte est supprimée du Tableau de bord. Les informations de session restent dans la barre latérale desktop et dans Réglages afin de demeurer accessibles sur mobile.

Dates, montants et accessibilité ciblée

  • Achever le travail de standardisation des Dates civiles déjà engagé : remplacer tous les contrôles natifs date restants par le contrôle Angular Material existant, réutiliser l'adaptateur de Date civile et les formats français, et conserver l'échange API en YYYY-MM-DD sans conversion en instant UTC.
  • Fournir les libellés français du datepicker via le mécanisme internationalisé d'Angular Material, notamment l'ouverture du calendrier et les commandes de navigation. Les noms accessibles ne sont pas codés séparément dans chaque formulaire.
  • Centraliser le formatage monétaire en réutilisant les mécanismes Angular/Intl existants : deux décimales dans les tableaux comptables et fiscaux ; zéro à deux décimales dans les cartes et résumés ; symbole euro toujours présent, y compris pour zéro.
  • Mesurer et corriger les contrastes insuffisants des petits textes, métadonnées, états et contrôles au moyen des tokens de palette. Cette spec exige les corrections observées, la navigation clavier, les noms accessibles français et le focus visible, mais ne revendique pas une certification globale WCAG 2.2 AA ou AAA.
  • Les contrôles de fichiers exposent un seul bouton utilisateur aux technologies d'assistance ; l'input technique correspondant n'est pas une seconde action annoncée.

Profil bailleur et Tableau de bord

  • Le Profil bailleur complet reste le seul prérequis global. Le dialogue de complétion ne peut pas être fermé pour entrer dans l'espace authentifié, mais propose toujours la déconnexion et des états d'enregistrement ou d'erreur actionnables.
  • Aucun autre assistant global obligatoire n'est ajouté. Après le Profil bailleur, les dépendances sont contextuelles et limitées à l'opération concernée.
  • Quand aucun Exercice fiscal n'est disponible, remplacer l'ensemble financier répétitif par un état unique qui explique la cause et propose l'action adéquate. La vue opérationnelle indépendante reste affichée lorsqu'elle est calculable.
  • Les graphiques financiers ne réservent pas de grandes zones vides. Ils apparaissent seulement lorsque leur période et leurs données sont disponibles.
  • Le sélecteur d'Exercice fiscal est visible dès que la liste autoritative contient au moins une année ; l'absence d'année est expliquée dans l'état unique plutôt que par un sélecteur artificiel.
  • Ajouter deux parcours d'onboarding indépendants : Location suit Profil bailleur → Appartement → Locataire → Bail → Inventaire du mobilier → État des lieux d'entrée → Échéances et règlements ; Comptabilité suit Appartement → Dépense ou Prêt immobilier → Plan d'amortissement → Exercice fiscal.
  • Chaque parcours expose seulement sa prochaine action. S'il existe exactement une cible, l'action mène directement à celle-ci ; s'il en existe plusieurs, l'interface présente une liste compacte sans sélection automatique.
  • Le Tableau de bord reste une vue de lecture conforme à son snapshot autoritatif existant. Cette refonte ne déplace aucun calcul financier dans Angular et ne crée aucun nouveau modèle persistant de dashboard.

Appartements

  • La création initiale exige seulement le nom, l'adresse, la Date d'acquisition immobilière et le prix d'acquisition. Le prix est vide par défaut et accompagné d'un exemple ; zéro n'est jamais injecté comme valeur implicite.
  • Après création, naviguer vers la fiche de l'Appartement. La route d'édition existante devient cette fiche de travail ; aucune route de consultation parallèle n'est créée.
  • La fiche orchestre des rubriques repliables et focalisées : informations essentielles, profil juridique, performance énergétique, équipements et Espaces privatifs. Chaque rubrique expose sa complétude sans pourcentage global.
  • Les données facultatives ou non requises pour l'action courante ne bloquent pas les autres modules. Les exigences contractuelles du profil juridique sont contrôlées avant la génération ou la Finalisation d'un Bail.
  • Le nom et la carte de l'Appartement ouvrent la fiche. La carte garde une action contextuelle principale et déplace Supprimer dans son menu secondaire.
  • Regrouper les accès Dépenses, Prêts immobiliers et Plan d'amortissement dans un conteneur d'actions secondaires en flex avec retour à la ligne, espacement de 12 px et marge verticale de 24 px. À la largeur mobile, les actions sont empilées et occupent toute la largeur.
  • Conserver les règles existantes de correction de la Date d'acquisition immobilière et du prix lorsque l'Appartement est référencé ; la refonte ne rend pas ces champs ordinaires silencieusement modifiables.

Locataires

  • Les cartes Locataire affichent les coordonnées utiles et un nombre de Pièces jointes, jamais la liste brute de leurs noms.
  • La fiche affiche chaque Pièce jointe avec un nom visuellement tronqué mais entièrement accessible, son type et sa taille. Aucune date de téléversement n'est inventée et aucun nouveau champ persistant n'est ajouté pour ce seul affichage.
  • Les e-mails utilisent un lien mailto: et les numéros de téléphone un lien tel: lorsque leur valeur est disponible.
  • La fiche récupère les Baux avec le service existant, filtre localement ceux dont les tenantIds contiennent le Locataire puis affiche leur statut et un lien vers la liste des Baux focalisée sur la carte correspondante. La taille de portefeuille retenue rend ce filtrage suffisant ; aucun endpoint Locataire–Baux ni nouvelle route de détail n'est ajouté.
  • Un Locataire peut être saisi directement ou provenir d'une Candidature, sans champ d'origine ajouté au formulaire ou à la carte.
  • Le futur parcours de sélection d'une Candidature doit offrir explicitement « Créer un Locataire » ou « Associer un Locataire existant ». Aucun rapprochement automatique n'est effectué et l'association ne remplace aucune coordonnée existante.

Baux

  • Le formulaire conserve une seule route et un seul agrégat versionné, mais ses cinq rubriques deviennent navigables non linéairement. La rubrique Parties doit identifier l'Appartement et au moins un Locataire avant de déverrouiller les rubriques dépendantes.
  • La création d'un premier Bail brouillon exige uniquement les Parties nécessaires à son identité. Les révisions suivantes acceptent des rubriques contractuelles incomplètes ; chaque valeur fournie reste soumise à ses contraintes de forme et invariants locaux.
  • Adapter directement le contrat de développement et le modèle du brouillon afin de représenter les faits contractuels absents, puis mettre à jour tous les appelants et tests. Aucun format de compatibilité ni double contrat n'est conservé.
  • L'enregistrement remplace atomiquement le brouillon complet avec sa révision attendue. Il n'existe ni endpoint par rubrique ni service générique de sauvegarde partielle.
  • Un évaluateur de complétude unique fournit les rubriques manquantes à l'interface et aux gardes de génération/Finalisation. La navigation et l'enregistrement du brouillon ne dépendent pas de cette complétude globale.
  • Les cinq rubriques affichent des états simples tels que « À compléter » et « Complet ». La revue exhaustive apparaît uniquement avant la génération d'une Révision du document de bail ou la Finalisation.
  • Les clauses légales utilisent les aides structurées existantes : résumé dans le formulaire, détail accessible à la demande, sans masquer les avertissements juridiques versionnés du domaine.
  • La carte Bail met en avant une action selon son statut et son avancement. Les actions secondaires, dont Supprimer lorsque le domaine l'autorise, sont dans un menu.

Inventaire du mobilier et État des lieux

  • Étendre une ligne d'Inventaire brouillon pour accepter un privateAreaId absent. Le préremplissage des onze catégories réglementaires laisse toutes les lignes dans « À attribuer » au lieu d'utiliser arbitrairement le premier Espace privatif.
  • Le contrat frontend représente l'Espace privatif comme facultatif dans le brouillon. La réponse et la requête versionnée conservent cette absence jusqu'à l'attribution explicite.
  • La complétude et le gel exigent que chaque ligne, réglementaire ou libre, référence un Espace privatif existant. Une référence inconnue reste invalide dès l'enregistrement ; seule l'absence temporaire est permise.
  • Conserver séparément presence et quantity. Une catégorie Non vérifiée porte une présence absente et une quantité nulle ; Présente exige une quantité positive ; Absente force une quantité nulle.
  • L'état physique du mobilier ne fait pas partie de l'Inventaire du mobilier. Renommer le champ en « Description » et laisser l'État des lieux porter le constat d'état.
  • Le backend et le frontend utilisent directement le nouveau modèle de développement. Aucune migration ou compatibilité d'anciennes données n'est créée ; les données de développement peuvent être supprimées ou reseedées.
  • L'interface groupe les lignes par Espace privatif dans leur ordre de visite et place « À attribuer » en premier. Desktop utilise une présentation compacte en lignes ; mobile utilise des cartes ou groupes repliables sans vue parallèle configurable.
  • La complétude des onze catégories réglementaires est résumée séparément de leur présence. Une catégorie Absente est déclarée et peut produire l'avertissement juridique existant ; elle n'est pas « manquante ».
  • Conserver une sauvegarde explicite, atomique et versionnée avec une barre d'actions persistante. Ne pas ajouter d'autosauvegarde à l'Inventaire.
  • Le blocage de l'État des lieux affiche « Compléter l'inventaire » comme action principale et transporte le Bail ainsi que l'État des lieux d'origine. L'Inventaire affiche ensuite « Reprendre l'état des lieux » ; aucune redirection automatique n'est effectuée.

Échéances et règlements, Dépenses et Prêts immobiliers

  • Renommer la page utilisateur « Échéances et règlements » tout en conservant les termes métier Échéance de loyer et Règlement de loyer.
  • L'état vide choisit une action selon le progrès réel : créer un Bail lorsqu'il n'en existe aucun ; reprendre un brouillon ; finaliser un Bail prêt. Une cible unique est ouverte directement et plusieurs cibles sont proposées sans choix automatique.
  • Tant qu'aucune Échéance de loyer ni aucun Règlement de loyer n'existe, utiliser un seul état compact au lieu de deux grands panneaux vides.
  • Conserver le parcours Justificatif de dépense en deux temps. Le formulaire initial ne reçoit ni montant, ni Nature de dépense, ni fichier : après sa création, sa fiche met immédiatement en avant « Ajouter un fichier » et « Ajouter une dépense ».
  • Lorsqu'un formulaire de création de Justificatif de dépense ou de Prêt immobilier est actif, masquer temporairement la liste et l'état vide. Annuler ou enregistrer ramène à la liste appropriée.
  • La politique globale de traitement des frais d'acquisition conserve sa confirmation existante, mais son explication expose clairement les conséquences et son irrévocabilité. Après décision, remplacer le grand contenu par un statut compact.
  • Sur Prêts, afficher l'action d'ajout dans l'état vide lorsqu'il n'existe aucun Prêt immobilier, sinon dans l'en-tête, jamais aux deux endroits.
  • Conserver la prévisualisation du Tableau d'amortissement avant la création d'un Prêt immobilier. Ajouter une explication courte du résultat attendu ; ne pas déplacer ce parcours vers une nouvelle route ou une boîte de dialogue.

Amortissements et Fiscalité

  • Dans la vue par Exercice fiscal, chaque Appartement sans Plan d'amortissement affiche « Configurer le plan ». L'action présélectionne l'Appartement et conserve l'Exercice fiscal comme contexte de retour.
  • Remplacer LOGEMENT_STANDARD_V1 par « Modèle standard de décomposition du logement » dans le parcours normal. La référence BOFiP et sa date restent disponibles dans une aide ou une section de détail ; l'identifiant interne n'est pas exposé.
  • Toutes les valeurs de frais et bases affichent une unité monétaire conforme au format transversal.
  • Les étapes du Plan d'amortissement conservent leur progression et sauvegardent l'avancement existant. Aucune estimation d'effort n'est ajoutée sans donnée fiable.
  • Le SIRET est normalisé à partir de quatorze chiffres, formaté pour la lecture et validé localement avec sa clé. Aucun appel à un registre externe n'est ajouté et l'interface précise que l'application ne certifie ni l'existence ni l'activité de l'établissement.
  • Renommer l'action fiscale « Enregistrer le profil fiscal ». Expliquer que le Profil fiscal LMNP reste modifiable et que chaque Clôture d'exercice fiscal en conserve une copie historique.
  • Ne pas ajouter d'écran récapitulatif séparé avant cet enregistrement. Utiliser la validation progressive, le résumé d'erreurs et la protection contre les modifications non enregistrées.
  • Les confirmations irréversibles existantes, notamment les Clôtures, restent distinctes de l'enregistrement modifiable du Profil fiscal LMNP.

Calendrier, Réglages et Administration

  • Conserver la grille mensuelle structurée sur desktop et la liste chronologique sur mobile. Ne pas ajouter de commutateur Mois/Liste dans ce périmètre.
  • Ajouter une commande de fermeture visuelle aux boîtes de dialogue du Calendrier tout en conservant Annuler et la gestion de focus Material.
  • Élargir l'action « Enregistrer le profil » sur desktop. La désactiver lorsque le formulaire est inchangé, puis l'activer après une modification même si une première tentative doit encore révéler les erreurs de validation.
  • Conserver la section Session dans Réglages pour les vues où le bloc de session latéral n'est pas visible. Ne pas ajouter de réglages de langue, format régional ou notification.
  • Remplacer dans Administration les termes techniques par « Fichiers stockés », « Espace utilisé » et « Appartements enregistrés » et corriger la casse française.
  • Ne pas créer de métriques, quotas, historiques, tendances, informations de sauvegarde ou état de service que les contrats actuels ne fournissent pas.

Ordre de livraison

  • Livrer en premier les impasses actionnables : État des lieux, Amortissements et Échéances et règlements.
  • Achever ensuite la localisation des Dates civiles, des libellés du calendrier et des titres de route.
  • Refaire l'Inventaire du mobilier, y compris son changement de modèle brouillon, avant de réorganiser le Bail qui en dépend.
  • Réorganiser ensuite les formulaires Bail et Appartement, puis les états vides et les deux parcours du Tableau de bord.
  • Terminer par les grilles desktop, la navigation groupée, les Locataires, les autres formulaires et l'harmonisation de la microcopie, des montants et des actions.
  • Chaque incrément reste livrable et testé séparément, sans refactorisation sans rapport avec le comportement concerné.

Testing Decisions

  • Un bon test vérifie un résultat observable : contenu rendu, action disponible, navigation produite, focus déplacé, requête publique, règle métier acceptée ou refusée. Il ne dépend pas des classes CSS internes, de l'ordre privé des méthodes ni de la structure d'un signal.
  • Le seam frontend principal est le composant de page avec les services HTTP remplacés par des réponses contrôlées et le routeur réel de test. Les tests existants du Tableau de bord, des Appartements, Locataires, Baux, Échéances et règlements, Inventaire, Calendrier, Amortissements, Prêts, Dépenses, Fiscalité, Réglages et Navigation servent de prior art.
  • Les tests de navigation vérifient les groupes desktop, le menu « Plus », « Accueil » à 390 px, la visibilité d'Administration selon le rôle, les routes correctives, le contexte de retour et les titres d'onglet.
  • Les tests des états vérifient séparément premier chargement, rafraîchissement avec contenu conservé, erreur technique réessayable, prérequis métier actionnable, collection vide et réussite de mutation.
  • Les tests de formulaires vérifient l'enregistrement occupé, la prévention des doublons, le résumé d'erreurs, le focus du premier champ invalide, la protection contre la navigation et la barre d'actions persistante sans tester son positionnement pixel par pixel.
  • Les tests Appartement couvrent la création minimale, le prix initialement vide, l'ouverture de la fiche, les rubriques de complétude, les actions secondaires espacées et la conservation des protections de correction d'acquisition.
  • Les tests Locataire couvrent le nombre de Pièces jointes sur les cartes, les métadonnées disponibles dans la fiche, l'unique commande accessible de téléversement, mailto:, tel: et le filtrage des Baux existants à partir de leurs tenantIds sans nouvel endpoint.
  • Les tests Bail couvrent l'accès non linéaire aux rubriques, le verrouillage des rubriques dépendantes avant les Parties, l'enregistrement d'un brouillon incomplet, les valeurs locales invalides, les statuts de complétude, la revue finale et l'action principale propre au statut.
  • Le seam backend du Bail reste le service de brouillon et son contrat HTTP versionné. Les tests de domaine, de service et web existants vérifient qu'un brouillon incomplet peut être créé ou révisé, qu'une valeur présente mais invalide est refusée, qu'une concurrence échoue proprement et que génération et Finalisation refusent les faits obligatoires absents.
  • Le seam backend de l'Inventaire est l'agrégat puis son endpoint versionné. Les tests couvrent le préremplissage non attribué, la sauvegarde d'une ligne sans Espace privatif, le refus d'un identifiant inconnu, les invariants Non vérifiée/Présente/Absente, la complétude et le refus de figer tant qu'une ligne reste non attribuée.
  • Les tests de l'État des lieux couvrent la différence entre erreur technique et Inventaire incomplet, l'action « Compléter l'inventaire », le contexte transmis puis « Reprendre l'état des lieux » sans redirection automatique.
  • Les tests Échéances et règlements couvrent les quatre états utiles : aucun Bail, Bail brouillon, Bail prêt à finaliser et Échéances existantes, ainsi que la sélection explicite lorsque plusieurs cibles sont possibles.
  • Les tests Dépenses et Prêts couvrent l'unicité de l'appel à l'action, le remplacement temporaire de la liste par le formulaire, l'annulation, la création réussie, le parcours en deux temps du Justificatif de dépense et l'explication de prévisualisation du Prêt immobilier.
  • Les tests Amortissements couvrent l'action « Configurer le plan », la présélection de l'Appartement, le retour vers l'Exercice fiscal, le libellé utilisateur du modèle, l'accès secondaire à la référence BOFiP et les unités monétaires.
  • Les tests fiscaux couvrent normalisation, formatage et validation locale du SIRET, absence d'appel externe, libellé d'enregistrement, explication des snapshots de Clôture, erreurs focalisées et modifications non enregistrées.
  • Les tests de Date civile complètent le prior art de l'adaptateur existant : saisie clavier et datepicker produisent la même date ISO, aucun contrôle natif date ne subsiste, aucun fuseau ne décale le jour et tous les boutons de calendrier ont un nom accessible français.
  • Les tests de formatage couvrent montant entier, centimes, zéro et valeur négative dans un résumé puis dans un tableau comptable ou fiscal.
  • Un parcours Playwright ciblé utilise les mécanismes d'authentification et de données existants, vérifie les groupes de navigation, un blocage corrigé avec retour, une date en français, l'absence de débordement horizontal et l'accès clavier à 2174 px puis 390 px.
  • Les parcours Playwright existants de navigation responsive, d'Inventaire du mobilier, d'édition Locataire, de Finalisation du Bail, de prévisualisation du Prêt immobilier et de Fiscalité constituent le prior art. Les scénarios sont étendus plutôt que dupliqués.
  • L'absence d'objectif global WCAG ne supprime aucun test explicitement demandé ici. Les tests ciblés vérifient les noms, rôles, focus, clavier et contrastes observés sans prétendre fournir une certification exhaustive.
  • La vérification finale exécute le formatage, le lint, le typecheck, les tests frontend pertinents, les tests backend de domaine/service/web, les parcours navigateur ciblés et les builds. Toute commande non exécutée est signalée.

Out of Scope

  • Une refonte visuelle de marque, un nouveau thème, une nouvelle palette ou une bibliothèque de composants concurrente d'Angular Material.
  • Une certification globale WCAG 2.2 AA ou AAA ; les défauts d'accessibilité explicitement décrits restent bien dans le périmètre.
  • Une vue tableau, un sélecteur carte/tableau, une recherche, des filtres avancés ou une pagination pour Appartements, Locataires ou Baux.
  • Un dimensionnement au-delà de la cible initiale de un à vingt Appartements sans mesure démontrant le besoin.
  • Un assistant global obligatoire après le Profil bailleur, un statut global « configuration terminée » ou une séquence unique imposée entre Location et Comptabilité.
  • Un système générique de brouillons, une autosauvegarde du Bail, de l'Appartement, de l'Inventaire ou du Profil fiscal LMNP, ou un endpoint de sauvegarde par rubrique.
  • Une route de consultation Appartement distincte de sa fiche de travail ou un nouveau parcours Locataire uniquement pour afficher ses Baux.
  • Un endpoint backend Locataire–Baux, un index ou un cache destiné au filtrage d'un petit portefeuille.
  • Une date de téléversement ajoutée aux Pièces jointes du Locataire uniquement pour enrichir leur affichage.
  • Le chiffrement des Locataires, Baux ou Pièces jointes, qui reste coordonné par le ticket dédié existant.
  • L'implémentation complète des Candidatures, du Déverrouillage des candidatures ou de la sélection ; seule la compatibilité de la définition du Locataire et la décision d'association explicite sont consignées ici.
  • Tout rapprochement automatique ou toute fusion de personnes à partir du nom, de l'e-mail ou du téléphone.
  • Une affectation automatique des catégories de mobilier à une pièce supposée.
  • Un état du mobilier dans l'Inventaire contractuel ; cet état appartient à l'État des lieux.
  • Une redirection automatique depuis l'Inventaire vers l'État des lieux.
  • Un commutateur Mois/Liste ou une grille mensuelle compressée sur mobile.
  • L'ajout du montant, de la Nature de dépense ou du fichier au formulaire initial de Justificatif de dépense.
  • Une nouvelle route ou boîte de dialogue pour créer un Prêt immobilier.
  • Une recherche externe du SIRET, une certification de l'établissement ou une validation de son activité LMNP.
  • Un écran récapitulatif fiscal supplémentaire, une transmission fiscale, un conseil juridique ou une modification du moteur de Simulation fiscale.
  • Des préférences de langue, de format régional ou de notifications.
  • De nouvelles métriques d'Administration, tendances, quotas, informations de sauvegarde ou états de service sans source existante.
  • Une migration, un adaptateur de compatibilité ou une double lecture des données de développement ; les contrats et schémas changent directement avec leurs appelants et tests.

Further Notes

  • Cette spec synthétise l'audit du 2 septembre 2026 et les trente-huit décisions prises pendant sa revue détaillée. En cas d'écart, les décisions explicites de cette spec prévalent sur les suggestions exploratoires de l'audit initial.
  • Elle respecte la séparation entre Profil bailleur et Profil fiscal LMNP, la stratégie de localisation française, Angular Material et les thèmes existants, le Tableau de bord en lecture seule, la séparation Comptabilité/Fiscalité et la cible de petits portefeuilles enregistrée par ADR.
  • L'issue fermée #73 demandait déjà qu'aucun contrôle natif de Date civile ne subsiste. Le code en contient de nouveau ou encore ; cette spec achève cette standardisation et couvre aussi les libellés accessibles français du datepicker.
  • L'issue ouverte #121 conserve actuellement une carte de compte dans ses décisions. Cette spec la remplace uniquement sur ce point : la carte Compte est supprimée du Tableau de bord, tandis que le reste du snapshot et de ses responsabilités demeure inchangé.
  • L'issue ouverte #156 impose actuellement que la sélection d'une Candidature crée toujours un nouveau Locataire. Elle doit être réalignée avant implémentation de ce parcours afin d'offrir aussi l'association explicite à un Locataire existant, sans rapprochement ni écrasement automatique. La présente spec n'implémente pas ce système de Candidatures.
  • La présence de Baux associés à un Locataire est déjà déductible du contrat de liste des Baux et de leurs tenantIds. Le frontend doit réutiliser cette donnée plutôt que créer une API redondante.
  • Les données de l'application ne sont pas en production. Les changements du brouillon de Bail et de l'Inventaire du mobilier remplacent directement les contrats et schémas de développement ; les jeux de données incompatibles peuvent être supprimés ou reseedés.
  • Les changements doivent être découpés en incréments selon l'ordre indiqué, avec de petits commits cohérents et sans refactorisation étrangère. Le ticket reste la spécification commune de la refonte ; son implémentation peut être distribuée en tickets enfants si la taille opérationnelle l'exige.
## Problem Statement LMNP Organizer présente une interface sombre cohérente, une navigation persistante, des composants homogènes et de bonnes bases sémantiques. L'audit réalisé le 2 septembre 2026 dans une session authentifiée, sur grand écran de 2174 px puis sur mobile de 390 px, montre néanmoins que l'application reste inutilement coûteuse à utiliser. Les difficultés principales ne sont pas esthétiques. Plusieurs messages décrivent correctement un prérequis manquant sans permettre au Bailleur de le résoudre. Les formulaires Appartement, Bail et Inventaire du mobilier imposent de très longues pages sans progression utile ni action d'enregistrement persistante. Les états vides répètent l'absence de données au lieu de guider vers la prochaine action. Les listes prévues pour de petits portefeuilles n'emploient qu'une fraction du grand écran. Les dates, montants, titres d'onglet, actions et libellés accessibles ne sont pas uniformes. Le parcours fiscal ne rend pas toujours assez clairement son état de validation et les conséquences de l'enregistrement. Ces incohérences créent des impasses, augmentent le risque de perte de saisie et donnent parfois à une absence de configuration l'apparence d'une erreur technique ou d'une valeur réellement nulle. Elles touchent les douze rubriques principales et les principaux écrans secondaires, avec un coût particulièrement élevé dans l'Inventaire du mobilier, les Baux, la fiche Appartement, les Loyers, les Amortissements et la Fiscalité. ## Solution Refondre les parcours concernés autour de quelques règles communes : chaque prérequis manquant mène à l'action corrective et conserve le contexte de retour ; les états techniques, métier et vides sont distincts ; les formulaires longs deviennent des ensembles de rubriques courtes avec complétude visible et enregistrement explicite ; les listes utilisent des grilles responsives adaptées à des portefeuilles individuels de un à vingt Appartements ; les actions destructives quittent le premier niveau ; les dates, montants, titres et libellés accessibles sont homogènes en français. Le Profil bailleur complet reste l'unique prérequis global bloquant après authentification. Une fois ce profil enregistré, l'application n'impose aucun assistant global : le Tableau de bord propose deux parcours indépendants, « Mettre en location » et « Préparer la comptabilité », et chaque écran ne bloque que les opérations dont les prérequis métier sont réellement absents. La refonte réutilise l'architecture existante. Elle conserve les agrégats versionnés, les sauvegardes atomiques, le contrôle des modifications non enregistrées, le Calendrier en liste sur mobile, la distinction Justificatif de dépense/Dépense et les snapshots historiques. Elle n'introduit pas de système générique de brouillons, de nouvelle bibliothèque, de tableau alternatif, de pagination, de recherche, de certification fiscale ni de vérification externe du SIRET. ## User Stories 1. En tant que Bailleur, je veux distinguer immédiatement une panne technique, un prérequis métier manquant et une liste réellement vide, afin de comprendre la prochaine action utile. 2. En tant que Bailleur, je veux qu'un prérequis métier manquant propose un accès direct à sa résolution, afin de ne pas devoir retrouver manuellement l'écran concerné. 3. En tant que Bailleur, je veux revenir à mon contexte initial après avoir résolu un prérequis, afin de poursuivre le parcours interrompu. 4. En tant que Bailleur, je veux que « Réessayer » soit réservé aux erreurs techniques, afin de ne pas relancer une opération dont la cause métier reste inchangée. 5. En tant que Bailleur, je veux des chargements, rafraîchissements, soumissions et erreurs fidèles à l'opération en cours, afin de ne jamais confondre une attente avec un résultat vide. 6. En tant que Bailleur, je veux conserver le contenu déjà chargé pendant un rafraîchissement, afin d'éviter les écrans vides et les déplacements de mise en page. 7. En tant que Bailleur, je veux que chaque route affiche un titre d'onglet descriptif terminé par « LMNP Organizer », afin d'identifier la page dans l'historique et les onglets du navigateur. 8. En tant que Bailleur, je veux des libellés d'ajout, de retour, d'enregistrement et de confirmation cohérents, afin d'anticiper le résultat d'une action. 9. En tant que Bailleur, je veux que les commandes de rechargement sans utilité métier disparaissent des pages chargées automatiquement, afin de réduire le bruit visuel. 10. En tant que Bailleur, je veux que les commandes métier conservées décrivent leur effet réel, afin de ne pas les confondre avec un simple rechargement. 11. En tant que Bailleur, je veux que les actions destructives soient placées dans un menu secondaire ou une zone de danger, afin d'éviter une activation accidentelle. 12. En tant que Bailleur, je veux confirmer explicitement toute suppression, afin de comprendre précisément la ressource affectée. 13. En tant que Bailleur, je veux que les listes d'Appartements, de Locataires et de Baux utilisent l'espace disponible, afin de parcourir efficacement mon portefeuille sur grand écran. 14. En tant que Bailleur, je veux que ces listes restent lisibles et manipulables à 390 px, afin d'utiliser l'application sur mobile. 15. En tant que Bailleur, je veux des formulaires qui conservent une action d'enregistrement visible, afin de ne pas parcourir toute une longue page pour sauvegarder. 16. En tant que Bailleur, je veux être averti avant de quitter une saisie non enregistrée, afin de ne pas perdre mon travail. 17. En tant que Bailleur, je veux que le premier envoi invalide affiche un résumé actionnable et place le focus sur le premier champ invalide, afin de corriger rapidement le formulaire. 18. En tant qu'utilisateur du clavier ou d'une technologie d'assistance, je veux des noms accessibles français, un ordre de focus logique et un focus visible, afin d'utiliser les mêmes parcours sans ambiguïté. 19. En tant que Bailleur, je veux retrouver les rubriques dans les groupes Pilotage, Location, Finances et fiscalité et Système, afin de comprendre la structure fonctionnelle de l'application. 20. En tant que Bailleur sur desktop, je veux que les groupes de navigation restent visibles, afin d'accéder directement aux rubriques sans ouvrir des sous-menus répétitifs. 21. En tant que Bailleur sur mobile, je veux que le menu « Plus » reprenne les mêmes groupes, afin de conserver la même carte mentale qu'au desktop. 22. En tant que Bailleur sur mobile, je veux voir « Accueil » plutôt que « Tableau de bord » dans la navigation basse, afin d'éviter un libellé tronqué. 23. En tant qu'Administrateur, je veux accéder à Administration dans un espace séparé et réservé à mon rôle, afin de ne pas mélanger les fonctions système et le portefeuille locatif. 24. En tant que Bailleur non administrateur, je veux que l'entrée Administration soit absente, afin de ne pas voir une fonction inaccessible. 25. En tant que Bailleur venant de m'authentifier, je veux devoir compléter mes prénom, nom, e-mail, téléphone et adresse postale avant d'accéder aux fonctions authentifiées, afin que les documents futurs disposent de l'identité requise. 26. En tant que Bailleur bloqué sur le Profil bailleur, je veux pouvoir me déconnecter, afin de ne jamais rester prisonnier d'un dialogue obligatoire. 27. En tant que Bailleur bloqué sur le Profil bailleur, je veux une erreur d'enregistrement explicite et réessayable, afin de distinguer un formulaire incomplet d'une panne technique. 28. En tant que Bailleur ayant complété son Profil bailleur, je veux que les autres modules restent indépendants hors prérequis réels, afin de ne pas suivre un assistant artificiellement obligatoire. 29. En tant que Bailleur débutant, je veux voir un parcours « Mettre en location », afin de connaître la prochaine étape entre Appartement, Locataire, Bail, Inventaire du mobilier, État des lieux d'entrée et Loyers. 30. En tant que Bailleur préparant sa gestion financière, je veux voir un parcours « Préparer la comptabilité », afin de connaître la prochaine étape entre Appartement, Dépenses ou Prêt immobilier, Plan d'amortissement et Exercice fiscal. 31. En tant que Bailleur, je veux une seule prochaine action par parcours, afin de progresser sans être confronté à une checklist indistincte. 32. En tant que Bailleur ayant un seul élément à compléter, je veux être dirigé directement vers celui-ci, afin d'éviter un choix inutile. 33. En tant que Bailleur ayant plusieurs Appartements ou éléments à compléter, je veux choisir dans une liste compacte, afin que l'application ne décide pas arbitrairement à ma place. 34. En tant que Bailleur ayant terminé un parcours, je veux retrouver le Tableau de bord normal sans statut global « configuration terminée », afin que les modules facultatifs restent facultatifs. 35. En tant que Bailleur sans Exercice fiscal disponible, je veux une seule explication précise et une action corrective, afin de ne pas lire plusieurs cartes « Période indisponible » identiques. 36. En tant que Bailleur sans Exercice fiscal disponible, je veux conserver la vue opérationnelle calculable, afin que le Tableau de bord reste utile. 37. En tant que Bailleur sans données financières affichables, je veux que les grands graphiques vides soient remplacés par le démarrage contextuel, afin de réduire le défilement inutile. 38. En tant que Bailleur disposant d'Exercices fiscaux, je veux sélectionner explicitement l'année suivie, afin de comprendre la période de tous les indicateurs financiers. 39. En tant que Bailleur, je veux que le Tableau de bord n'affiche plus une carte Compte dupliquée, afin de réserver l'espace aux informations de gestion. 40. En tant que Bailleur, je veux que la section opérationnelle reste distincte des indicateurs rattachés à l'Exercice fiscal, afin de ne pas confondre leurs périodes. 41. En tant que Bailleur, je veux créer un Appartement en renseignant uniquement son nom, son adresse, sa Date d'acquisition immobilière et son prix d'acquisition, afin d'entrer rapidement dans sa fiche. 42. En tant que Bailleur, je veux que le prix d'acquisition soit initialement vide avec un exemple, afin de ne pas confondre zéro avec une valeur réellement déclarée. 43. En tant que Bailleur, je veux être conduit vers la fiche de l'Appartement après sa création, afin de compléter les informations nécessaires à mon rythme. 44. En tant que Bailleur, je veux ouvrir la fiche d'un Appartement depuis son nom ou sa carte, afin de disposer d'une action de consultation naturelle. 45. En tant que Bailleur, je veux que la fiche Appartement organise séparément les informations principales, juridiques, énergétiques, les équipements et les Espaces privatifs, afin de ne pas subir un seul flux très long. 46. En tant que Bailleur, je veux connaître la complétude de chaque rubrique de la fiche Appartement, afin de savoir ce qui manque avant une opération contractuelle. 47. En tant que Bailleur, je veux pouvoir gérer Dépenses, Prêts immobiliers et Plans d'amortissement même si le profil juridique de l'Appartement est incomplet, afin que seules les dépendances réelles bloquent une action. 48. En tant que Bailleur, je veux que la génération ou la finalisation d'un Bail indique précisément les informations juridiques manquantes de l'Appartement, afin de les corriger depuis le bon contexte. 49. En tant que Bailleur, je veux que les actions « Ajouter une dépense », « Voir les prêts » et « Créer le plan d'amortissement » soient regroupées et espacées, afin de pouvoir les distinguer et les activer facilement. 50. En tant que Bailleur sur mobile, je veux que ces actions occupent chacune toute la largeur, afin d'éviter les collisions et les petites cibles. 51. En tant que Bailleur, je veux que la correction d'une Date d'acquisition immobilière ou d'un prix déjà référencé conserve les protections métier existantes, afin de ne pas réécrire silencieusement l'historique. 52. En tant que Bailleur, je veux supprimer un Appartement depuis une action secondaire confirmée, afin que cette commande ne concurrence pas l'ouverture de sa fiche. 53. En tant que Bailleur, je veux saisir directement un Locataire déjà connu ou géré hors de l'application, afin de ne pas dépendre d'une Candidature. 54. En tant que Bailleur, je veux qu'un Locataire issu d'une Candidature et un Locataire saisi directement utilisent la même fiche, afin de ne pas créer deux catégories artificielles de personnes contractantes. 55. En tant que Bailleur, je veux que la carte Locataire affiche le nombre de Pièces jointes plutôt que leurs noms bruts, afin de conserver une liste lisible. 56. En tant que Bailleur, je veux voir dans la fiche Locataire le nom de fichier tronqué visuellement, son nom complet accessible, son type et sa taille, afin d'identifier chaque Pièce jointe sans casser la mise en page. 57. En tant que Bailleur, je veux une seule commande d'ajout de fichiers annoncée aux technologies d'assistance, afin d'éviter deux actions équivalentes. 58. En tant que Bailleur, je veux utiliser directement l'e-mail et le téléphone d'un Locataire, afin de le contacter depuis l'appareil courant. 59. En tant que Bailleur, je veux voir les Baux associés dans la fiche Locataire avec leur statut, afin de retrouver son historique contractuel. 60. En tant que Bailleur, je veux ouvrir un Bail associé depuis la fiche Locataire, afin de passer directement au bon dossier. 61. En tant que Bailleur sélectionnant une Candidature, je veux choisir explicitement entre créer un Locataire et associer un Locataire existant, afin d'éviter les doublons ou rapprochements imposés. 62. En tant que Bailleur, je veux qu'aucune ressemblance de nom, d'e-mail ou de téléphone ne fusionne automatiquement deux personnes, afin de garder le contrôle sur leurs identités. 63. En tant que Bailleur associant une Candidature à un Locataire existant, je veux conserver les coordonnées actuelles de ce Locataire, afin qu'une association n'écrase pas silencieusement ses données. 64. En tant que Bailleur, je veux parcourir les cinq rubriques d'un Bail dans un ordre non linéaire, afin de compléter d'abord les informations disponibles. 65. En tant que Bailleur, je veux que la rubrique Parties déverrouille les rubriques qui dépendent de l'Appartement et des Locataires, afin de ne pas saisir des données sans contexte. 66. En tant que Bailleur, je veux enregistrer un Bail brouillon dont certaines rubriques restent incomplètes, afin de reprendre le travail ultérieurement. 67. En tant que Bailleur, je veux que les valeurs déjà renseignées soient validées à l'enregistrement, afin de ne pas conserver des formats ou invariants locaux invalides. 68. En tant que Bailleur, je veux que la complétude contractuelle soit exigée avant la génération d'une Révision du document de bail ou la Finalisation, afin que le brouillon reste souple sans affaiblir les opérations irréversibles. 69. En tant que Bailleur, je veux voir l'état de complétude de chaque rubrique du Bail, afin de savoir où intervenir sans pourcentage trompeur. 70. En tant que Bailleur, je veux une revue exhaustive seulement au moment de générer ou finaliser le Bail, afin de ne pas maintenir un résumé latéral permanent et encombrant. 71. En tant que Bailleur, je veux que les explications des clauses légales restent synthétiques avec le détail à la demande, afin de prendre une décision sans parcourir des blocs juridiques continus. 72. En tant que Bailleur, je veux qu'une seule action principale soit mise en avant selon le statut du Bail, afin de distinguer consultation, reprise, génération, finalisation et clôture. 73. En tant que Bailleur, je veux que les autres actions d'un Bail soient regroupées dans un menu secondaire, afin de ne pas afficher cinq commandes concurrentes sur une carte étroite. 74. En tant que Bailleur, je veux que les Baux utilisent une grille de cartes adaptée au grand écran, afin d'employer l'espace sans introduire de vue tableau parallèle. 75. En tant que Bailleur, je veux une sauvegarde atomique du Bail avec contrôle de version, afin qu'une rubrique enregistrée ne laisse pas le brouillon dans un état partiellement remplacé. 76. En tant que Bailleur, je veux que les modifications non enregistrées du Bail soient protégées lors de la navigation, afin de ne pas perdre une longue saisie. 77. En tant que Bailleur, je veux déclarer chaque catégorie réglementaire de mobilier comme Non vérifiée, Présente ou Absente, afin de distinguer l'absence d'examen d'une absence réelle. 78. En tant que Bailleur, je veux saisir une quantité positive seulement lorsque le mobilier est Présent, afin de ne pas dupliquer ou contredire la déclaration de présence. 79. En tant que Bailleur, je veux qu'un mobilier Absent ait automatiquement une quantité nulle, afin de préserver un état cohérent. 80. En tant que Bailleur, je veux que « Description » ne prétende pas décrire l'état du mobilier, afin de réserver l'état au constat de l'État des lieux. 81. En tant que Bailleur, je veux laisser temporairement une ligne d'Inventaire du mobilier dans « À attribuer », afin que le catalogue initial ne devine pas une pièce incorrecte. 82. En tant que Bailleur, je veux attribuer chaque ligne à un Espace privatif réel avant que l'Inventaire soit complet ou figé, afin que le document contractuel reste précis. 83. En tant que Bailleur, je veux voir les lignes groupées dans l'ordre des Espaces privatifs, précédées des lignes « À attribuer », afin de préparer une visite de façon naturelle. 84. En tant que Bailleur sur desktop, je veux modifier l'Inventaire dans des lignes compactes, afin de réduire fortement le défilement. 85. En tant que Bailleur sur mobile, je veux modifier l'Inventaire dans des cartes ou groupes repliables, afin de conserver des contrôles utilisables à 390 px. 86. En tant que Bailleur, je veux voir un résumé de complétude des onze catégories réglementaires, afin d'identifier les déclarations encore manquantes. 87. En tant que Bailleur, je veux enregistrer explicitement l'Inventaire depuis une barre d'actions persistante, afin de conserver la maîtrise de la sauvegarde. 88. En tant que Bailleur, je veux conserver l'enregistrement atomique et versionné de l'Inventaire, afin qu'une concurrence ne remplace pas silencieusement mon travail. 89. En tant que Bailleur ouvrant un État des lieux d'entrée sans Inventaire complet, je veux voir « Compléter l'inventaire » comme action principale, afin de résoudre réellement le blocage. 90. En tant que Bailleur revenant de l'Inventaire, je veux utiliser explicitement « Reprendre l'état des lieux », afin de choisir quand revenir sans redirection automatique surprenante. 91. En tant que Bailleur, je veux que le contexte de retour vers l'État des lieux soit conservé, afin de retrouver le Bail et l'étape concernés. 92. En tant que Bailleur, je veux que « Réessayer » apparaisse sur l'État des lieux seulement après une panne technique, afin de ne pas confondre prérequis et incident. 93. En tant que Bailleur, je veux que la page des Loyers s'intitule « Échéances et règlements », afin de décrire précisément son contenu. 94. En tant que Bailleur sans Bail, je veux que l'état vide me propose de créer un Bail, afin de commencer le parcours utile. 95. En tant que Bailleur ayant un Bail brouillon, je veux que l'état vide me propose de reprendre ce Bail, afin de poursuivre plutôt que recommencer. 96. En tant que Bailleur ayant un Bail prêt mais non finalisé, je veux que l'état vide me propose de le finaliser, afin de créer les Échéances de loyer attendues. 97. En tant que Bailleur ayant plusieurs éléments possibles, je veux choisir dans une liste compacte plutôt que subir une sélection arbitraire, afin d'agir sur le bon Appartement ou Bail. 98. En tant que Bailleur sans échéance ni règlement, je veux un seul bloc compact, afin de ne pas parcourir deux grandes zones vides. 99. En tant que Bailleur créant un Justificatif de dépense, je veux d'abord enregistrer son émetteur, ses dates et sa référence, afin de respecter la distinction entre le document source et les Dépenses qu'il justifie. 100. En tant que Bailleur venant de créer un Justificatif de dépense, je veux accéder immédiatement à une checklist « Ajouter un fichier » et « Ajouter une dépense », afin de terminer le dossier sans croire que le montant appartient au document source. 101. En tant que Bailleur, je veux que le formulaire d'un nouveau Justificatif remplace temporairement la liste ou l'état vide, afin de ne pas gérer deux contextes concurrents. 102. En tant que Bailleur choisissant une politique de traitement des frais d'acquisition, je veux une explication accessible de son caractère global et irrévocable et de ses conséquences concrètes, afin de confirmer en connaissance de cause. 103. En tant que Bailleur, je veux ensuite voir seulement un statut compact de cette politique, afin qu'une décision déjà prise ne monopolise plus la page. 104. En tant que Bailleur sans Prêt immobilier, je veux une seule action « Ajouter un prêt », afin d'éviter un doublon entre l'en-tête et l'état vide. 105. En tant que Bailleur ayant déjà un Prêt immobilier, je veux retrouver l'action d'ajout dans l'en-tête, afin d'étendre la liste sans dupliquer l'état vide. 106. En tant que Bailleur créant un Prêt immobilier, je veux que le formulaire remplace temporairement la liste ou l'état vide, afin de me concentrer sur la saisie. 107. En tant que Bailleur préparant un Prêt immobilier, je veux comprendre ce que montrera la prévisualisation du Tableau d'amortissement, afin de savoir pourquoi cette étape précède l'enregistrement. 108. En tant que Bailleur saisissant un Prêt immobilier, je veux conserver la prévisualisation avant création, afin de vérifier les échéances attendues. 109. En tant que Bailleur consultant les Amortissements par Exercice fiscal, je veux que chaque Appartement sans plan propose « Configurer le plan », afin de résoudre le blocage depuis la liste. 110. En tant que Bailleur suivant cette action, je veux que l'Appartement soit présélectionné et le retour vers l'Exercice fiscal conservé, afin de ne pas reconstruire mon contexte. 111. En tant que Bailleur, je veux lire « Modèle standard de décomposition du logement » plutôt que `LOGEMENT_STANDARD_V1`, afin de ne pas être exposé à un identifiant interne. 112. En tant que Bailleur, je veux consulter la référence BOFiP pertinente dans une aide ou un détail, afin de conserver la source officielle sans encombrer le parcours principal. 113. En tant que Bailleur, je veux que « Frais incorporés » et les autres valeurs monétaires affichent toujours leur unité, afin de ne pas interpréter un nombre nu. 114. En tant que Bailleur configurant un Plan d'amortissement, je veux voir l'étape courante et la complétude des étapes, afin de reprendre le travail sans estimation d'effort artificielle. 115. En tant que Bailleur renseignant son Profil fiscal LMNP, je veux que le SIRET soit formaté lisiblement et validé immédiatement comme quatorze chiffres avec une clé correcte, afin de corriger une erreur locale avant l'enregistrement. 116. En tant que Bailleur, je veux savoir que LMNP Organizer ne consulte aucun registre et ne certifie pas mon établissement, afin de comprendre la portée de cette validation. 117. En tant que Bailleur, je veux utiliser l'action « Enregistrer le profil fiscal », afin de comprendre qu'il s'agit d'une donnée modifiable et non d'une confirmation irréversible. 118. En tant que Bailleur, je veux connaître les effets de l'enregistrement du Profil fiscal LMNP et la façon dont les Clôtures en figent une copie, afin de comprendre ce qui reste modifiable. 119. En tant que Bailleur, je veux éviter un écran récapitulatif supplémentaire avant l'enregistrement du Profil fiscal LMNP, afin de ne pas allonger inutilement le parcours. 120. En tant que Bailleur, je veux être protégé contre la perte d'une saisie fiscale non enregistrée, afin qu'un départ ou un rechargement ne supprime pas silencieusement mon travail. 121. En tant que Bailleur, je veux que les erreurs fiscales apparaissent au premier essai d'enregistrement avec un résumé et un focus utile, afin de ne pas parcourir le formulaire à l'aveugle. 122. En tant que Bailleur, je veux que toutes les dates civiles affichées et saisies utilisent le français tout en conservant leur valeur ISO, afin qu'aucun changement de fuseau ne décale le jour métier. 123. En tant qu'utilisateur d'une technologie d'assistance, je veux que tous les boutons de calendrier soient annoncés en français, afin de ne pas rencontrer « Open calendar » dans une interface française. 124. En tant que Bailleur, je veux saisir une date au clavier ou la choisir dans le calendrier avec le même résultat, afin d'utiliser le mode le plus efficace. 125. En tant que Bailleur sur mobile, je veux conserver la liste chronologique du Calendrier, afin de consulter les événements sans grille mensuelle compressée. 126. En tant que Bailleur sur mobile, je ne veux pas de sélecteur Mois/Liste tant qu'un besoin réel n'est pas observé, afin de conserver un écran simple. 127. En tant que Bailleur ouvrant une boîte de dialogue du Calendrier, je veux un bouton de fermeture visible en plus d'Annuler, afin de fermer immédiatement l'overlay. 128. En tant que Bailleur, je veux que les montants des tableaux comptables et fiscaux utilisent systématiquement deux décimales, afin d'aligner les valeurs détaillées. 129. En tant que Bailleur, je veux que les cartes et résumés omettent les décimales inutiles mais conservent les centimes réels, afin de faciliter la lecture sans perdre d'information. 130. En tant que Bailleur, je veux que toute valeur monétaire nulle porte le symbole euro, afin de ne pas confondre montant, quantité et compteur. 131. En tant que Bailleur, je veux que les petits textes secondaires restent lisibles dans chaque thème, afin que les aides et métadonnées ne disparaissent pas visuellement. 132. En tant que Bailleur, je veux que « Enregistrer le profil » tienne sur une ligne lorsque l'espace desktop le permet, afin que l'action conserve une apparence stable. 133. En tant que Bailleur, je veux que l'enregistrement du profil soit inactif quand aucune donnée n'a changé puis redevienne disponible après une modification, afin de connaître l'état réel du formulaire. 134. En tant que Bailleur sur mobile, je veux conserver dans Réglages une section Session avec les actions de compte, afin de compenser l'absence des informations de session de la barre latérale desktop. 135. En tant que Bailleur, je ne veux pas une nouvelle rubrique de préférences de langue, formats ou notifications dans cette refonte, afin de ne pas ajouter des réglages non nécessaires à l'interface française actuelle. 136. En tant qu'Administrateur, je veux lire « Fichiers stockés », « Espace utilisé » et « Appartements enregistrés », afin de comprendre les métriques sans vocabulaire d'infrastructure. 137. En tant qu'Administrateur, je veux que les libellés respectent la casse française, afin d'éviter des formulations comme « Nombre actuel d'Appartements ». 138. En tant qu'Administrateur, je veux que la page Administration reste limitée aux faits déjà disponibles, afin de ne pas présenter des tendances, quotas ou sauvegardes fictifs. 139. En tant que Bailleur, je veux que toutes les opérations asynchrones désactivent seulement les commandes concernées pendant leur exécution, afin que le reste de la page reste utilisable. 140. En tant que Bailleur, je veux que les boutons de soumission restent utilisables avant la première tentative lorsque le formulaire n'est pas occupé ou en lecture seule, afin d'obtenir des erreurs complètes et actionnables plutôt qu'un bouton mystérieusement inactif. ## Implementation Decisions ### Principes transverses - Conserver Angular Material, les composants partagés, la palette sémantique et les tokens Sass existants. Aucun nouveau paquet d'interface, de formulaire, de formatage, de grille ou d'accessibilité n'est ajouté. - Utiliser les termes français du glossaire dans l'interface et conserver les noms anglais dans le code et les contrats techniques, conformément à la stratégie de localisation existante. - Distinguer trois états : erreur technique avec action « Réessayer » ; prérequis métier avec action corrective et contexte de retour ; collection valide vide avec explication et création facultative. - Transporter le contexte d'origine lors des actions correctives. Après résolution, afficher une action de reprise explicite ou revenir au contexte lorsque la décision le prévoit ; ne pas introduire de redirection automatique surprenante. - Retirer les actions « Actualiser » qui ne font que répéter un chargement automatique. Conserver les nouvelles tentatives techniques et les commandes métier explicites, par exemple le prolongement d'un Échéancier lorsqu'il s'agit réellement d'une mutation. - Toute opération asynchrone expose son propre état. Le premier chargement utilise un squelette adapté au contenu ; un rafraîchissement conserve les données établies ; une mutation affiche une progression locale et empêche uniquement sa duplication. - Les boutons de soumission restent actifs hors attente et lecture seule. La première tentative invalide affiche un résumé lié aux champs, rend les erreurs locales visibles et concentre le premier contrôle invalide. - Les formulaires longs utilisent une barre d'actions persistante, une indication de rubriques complètes ou incomplètes et une protection contre la navigation avec modifications locales. Aucun moteur générique de brouillons ni autosauvegarde transversale n'est créé. - L'État des lieux conserve son autosauvegarde existante. Le Bail, l'Appartement, l'Inventaire du mobilier et le Profil fiscal LMNP utilisent des enregistrements explicites et atomiques. - Les suppressions quittent le premier niveau des cartes. Une carte conserve son action principale ; la suppression se trouve dans un menu secondaire ou dans la zone de danger de la fiche et utilise la boîte de confirmation Material existante. - Ajouter des titres de route descriptifs sous la forme « <Page> — LMNP Organizer » et les vérifier lors de chaque navigation, y compris les écrans secondaires. ### Navigation, largeur et compte - La navigation desktop est structurée en groupes toujours ouverts : Pilotage contient Tableau de bord et Calendrier ; Location contient Appartements, Locataires, Baux et Échéances et règlements ; Finances et fiscalité contient Dépenses, Prêts, Amortissements et Fiscalité ; Système contient Réglages. - Administration reste une entrée séparée, protégée par le rôle Administrateur et absente pour les autres Bailleur. - Le menu mobile « Plus » reprend les mêmes groupes. Les entrées primaires mobiles restent Accueil, Loyers et Dépenses, avec « Accueil » comme libellé court affiché pour le Tableau de bord. - Les listes Appartements, Locataires et Baux utilisent une grille responsive de cartes pour la cible initiale de un à vingt Appartements. Il n'existe ni vue tableau parallèle, ni pagination, ni recherche avant qu'un besoin mesuré ne les justifie. - La carte de compte est supprimée du Tableau de bord. Les informations de session restent dans la barre latérale desktop et dans Réglages afin de demeurer accessibles sur mobile. ### Dates, montants et accessibilité ciblée - Achever le travail de standardisation des Dates civiles déjà engagé : remplacer tous les contrôles natifs `date` restants par le contrôle Angular Material existant, réutiliser l'adaptateur de Date civile et les formats français, et conserver l'échange API en `YYYY-MM-DD` sans conversion en instant UTC. - Fournir les libellés français du datepicker via le mécanisme internationalisé d'Angular Material, notamment l'ouverture du calendrier et les commandes de navigation. Les noms accessibles ne sont pas codés séparément dans chaque formulaire. - Centraliser le formatage monétaire en réutilisant les mécanismes Angular/Intl existants : deux décimales dans les tableaux comptables et fiscaux ; zéro à deux décimales dans les cartes et résumés ; symbole euro toujours présent, y compris pour zéro. - Mesurer et corriger les contrastes insuffisants des petits textes, métadonnées, états et contrôles au moyen des tokens de palette. Cette spec exige les corrections observées, la navigation clavier, les noms accessibles français et le focus visible, mais ne revendique pas une certification globale WCAG 2.2 AA ou AAA. - Les contrôles de fichiers exposent un seul bouton utilisateur aux technologies d'assistance ; l'input technique correspondant n'est pas une seconde action annoncée. ### Profil bailleur et Tableau de bord - Le Profil bailleur complet reste le seul prérequis global. Le dialogue de complétion ne peut pas être fermé pour entrer dans l'espace authentifié, mais propose toujours la déconnexion et des états d'enregistrement ou d'erreur actionnables. - Aucun autre assistant global obligatoire n'est ajouté. Après le Profil bailleur, les dépendances sont contextuelles et limitées à l'opération concernée. - Quand aucun Exercice fiscal n'est disponible, remplacer l'ensemble financier répétitif par un état unique qui explique la cause et propose l'action adéquate. La vue opérationnelle indépendante reste affichée lorsqu'elle est calculable. - Les graphiques financiers ne réservent pas de grandes zones vides. Ils apparaissent seulement lorsque leur période et leurs données sont disponibles. - Le sélecteur d'Exercice fiscal est visible dès que la liste autoritative contient au moins une année ; l'absence d'année est expliquée dans l'état unique plutôt que par un sélecteur artificiel. - Ajouter deux parcours d'onboarding indépendants : Location suit Profil bailleur → Appartement → Locataire → Bail → Inventaire du mobilier → État des lieux d'entrée → Échéances et règlements ; Comptabilité suit Appartement → Dépense ou Prêt immobilier → Plan d'amortissement → Exercice fiscal. - Chaque parcours expose seulement sa prochaine action. S'il existe exactement une cible, l'action mène directement à celle-ci ; s'il en existe plusieurs, l'interface présente une liste compacte sans sélection automatique. - Le Tableau de bord reste une vue de lecture conforme à son snapshot autoritatif existant. Cette refonte ne déplace aucun calcul financier dans Angular et ne crée aucun nouveau modèle persistant de dashboard. ### Appartements - La création initiale exige seulement le nom, l'adresse, la Date d'acquisition immobilière et le prix d'acquisition. Le prix est vide par défaut et accompagné d'un exemple ; zéro n'est jamais injecté comme valeur implicite. - Après création, naviguer vers la fiche de l'Appartement. La route d'édition existante devient cette fiche de travail ; aucune route de consultation parallèle n'est créée. - La fiche orchestre des rubriques repliables et focalisées : informations essentielles, profil juridique, performance énergétique, équipements et Espaces privatifs. Chaque rubrique expose sa complétude sans pourcentage global. - Les données facultatives ou non requises pour l'action courante ne bloquent pas les autres modules. Les exigences contractuelles du profil juridique sont contrôlées avant la génération ou la Finalisation d'un Bail. - Le nom et la carte de l'Appartement ouvrent la fiche. La carte garde une action contextuelle principale et déplace Supprimer dans son menu secondaire. - Regrouper les accès Dépenses, Prêts immobiliers et Plan d'amortissement dans un conteneur d'actions secondaires en flex avec retour à la ligne, espacement de 12 px et marge verticale de 24 px. À la largeur mobile, les actions sont empilées et occupent toute la largeur. - Conserver les règles existantes de correction de la Date d'acquisition immobilière et du prix lorsque l'Appartement est référencé ; la refonte ne rend pas ces champs ordinaires silencieusement modifiables. ### Locataires - Les cartes Locataire affichent les coordonnées utiles et un nombre de Pièces jointes, jamais la liste brute de leurs noms. - La fiche affiche chaque Pièce jointe avec un nom visuellement tronqué mais entièrement accessible, son type et sa taille. Aucune date de téléversement n'est inventée et aucun nouveau champ persistant n'est ajouté pour ce seul affichage. - Les e-mails utilisent un lien `mailto:` et les numéros de téléphone un lien `tel:` lorsque leur valeur est disponible. - La fiche récupère les Baux avec le service existant, filtre localement ceux dont les `tenantIds` contiennent le Locataire puis affiche leur statut et un lien vers la liste des Baux focalisée sur la carte correspondante. La taille de portefeuille retenue rend ce filtrage suffisant ; aucun endpoint Locataire–Baux ni nouvelle route de détail n'est ajouté. - Un Locataire peut être saisi directement ou provenir d'une Candidature, sans champ d'origine ajouté au formulaire ou à la carte. - Le futur parcours de sélection d'une Candidature doit offrir explicitement « Créer un Locataire » ou « Associer un Locataire existant ». Aucun rapprochement automatique n'est effectué et l'association ne remplace aucune coordonnée existante. ### Baux - Le formulaire conserve une seule route et un seul agrégat versionné, mais ses cinq rubriques deviennent navigables non linéairement. La rubrique Parties doit identifier l'Appartement et au moins un Locataire avant de déverrouiller les rubriques dépendantes. - La création d'un premier Bail brouillon exige uniquement les Parties nécessaires à son identité. Les révisions suivantes acceptent des rubriques contractuelles incomplètes ; chaque valeur fournie reste soumise à ses contraintes de forme et invariants locaux. - Adapter directement le contrat de développement et le modèle du brouillon afin de représenter les faits contractuels absents, puis mettre à jour tous les appelants et tests. Aucun format de compatibilité ni double contrat n'est conservé. - L'enregistrement remplace atomiquement le brouillon complet avec sa révision attendue. Il n'existe ni endpoint par rubrique ni service générique de sauvegarde partielle. - Un évaluateur de complétude unique fournit les rubriques manquantes à l'interface et aux gardes de génération/Finalisation. La navigation et l'enregistrement du brouillon ne dépendent pas de cette complétude globale. - Les cinq rubriques affichent des états simples tels que « À compléter » et « Complet ». La revue exhaustive apparaît uniquement avant la génération d'une Révision du document de bail ou la Finalisation. - Les clauses légales utilisent les aides structurées existantes : résumé dans le formulaire, détail accessible à la demande, sans masquer les avertissements juridiques versionnés du domaine. - La carte Bail met en avant une action selon son statut et son avancement. Les actions secondaires, dont Supprimer lorsque le domaine l'autorise, sont dans un menu. ### Inventaire du mobilier et État des lieux - Étendre une ligne d'Inventaire brouillon pour accepter un `privateAreaId` absent. Le préremplissage des onze catégories réglementaires laisse toutes les lignes dans « À attribuer » au lieu d'utiliser arbitrairement le premier Espace privatif. - Le contrat frontend représente l'Espace privatif comme facultatif dans le brouillon. La réponse et la requête versionnée conservent cette absence jusqu'à l'attribution explicite. - La complétude et le gel exigent que chaque ligne, réglementaire ou libre, référence un Espace privatif existant. Une référence inconnue reste invalide dès l'enregistrement ; seule l'absence temporaire est permise. - Conserver séparément `presence` et `quantity`. Une catégorie Non vérifiée porte une présence absente et une quantité nulle ; Présente exige une quantité positive ; Absente force une quantité nulle. - L'état physique du mobilier ne fait pas partie de l'Inventaire du mobilier. Renommer le champ en « Description » et laisser l'État des lieux porter le constat d'état. - Le backend et le frontend utilisent directement le nouveau modèle de développement. Aucune migration ou compatibilité d'anciennes données n'est créée ; les données de développement peuvent être supprimées ou reseedées. - L'interface groupe les lignes par Espace privatif dans leur ordre de visite et place « À attribuer » en premier. Desktop utilise une présentation compacte en lignes ; mobile utilise des cartes ou groupes repliables sans vue parallèle configurable. - La complétude des onze catégories réglementaires est résumée séparément de leur présence. Une catégorie Absente est déclarée et peut produire l'avertissement juridique existant ; elle n'est pas « manquante ». - Conserver une sauvegarde explicite, atomique et versionnée avec une barre d'actions persistante. Ne pas ajouter d'autosauvegarde à l'Inventaire. - Le blocage de l'État des lieux affiche « Compléter l'inventaire » comme action principale et transporte le Bail ainsi que l'État des lieux d'origine. L'Inventaire affiche ensuite « Reprendre l'état des lieux » ; aucune redirection automatique n'est effectuée. ### Échéances et règlements, Dépenses et Prêts immobiliers - Renommer la page utilisateur « Échéances et règlements » tout en conservant les termes métier Échéance de loyer et Règlement de loyer. - L'état vide choisit une action selon le progrès réel : créer un Bail lorsqu'il n'en existe aucun ; reprendre un brouillon ; finaliser un Bail prêt. Une cible unique est ouverte directement et plusieurs cibles sont proposées sans choix automatique. - Tant qu'aucune Échéance de loyer ni aucun Règlement de loyer n'existe, utiliser un seul état compact au lieu de deux grands panneaux vides. - Conserver le parcours Justificatif de dépense en deux temps. Le formulaire initial ne reçoit ni montant, ni Nature de dépense, ni fichier : après sa création, sa fiche met immédiatement en avant « Ajouter un fichier » et « Ajouter une dépense ». - Lorsqu'un formulaire de création de Justificatif de dépense ou de Prêt immobilier est actif, masquer temporairement la liste et l'état vide. Annuler ou enregistrer ramène à la liste appropriée. - La politique globale de traitement des frais d'acquisition conserve sa confirmation existante, mais son explication expose clairement les conséquences et son irrévocabilité. Après décision, remplacer le grand contenu par un statut compact. - Sur Prêts, afficher l'action d'ajout dans l'état vide lorsqu'il n'existe aucun Prêt immobilier, sinon dans l'en-tête, jamais aux deux endroits. - Conserver la prévisualisation du Tableau d'amortissement avant la création d'un Prêt immobilier. Ajouter une explication courte du résultat attendu ; ne pas déplacer ce parcours vers une nouvelle route ou une boîte de dialogue. ### Amortissements et Fiscalité - Dans la vue par Exercice fiscal, chaque Appartement sans Plan d'amortissement affiche « Configurer le plan ». L'action présélectionne l'Appartement et conserve l'Exercice fiscal comme contexte de retour. - Remplacer `LOGEMENT_STANDARD_V1` par « Modèle standard de décomposition du logement » dans le parcours normal. La référence BOFiP et sa date restent disponibles dans une aide ou une section de détail ; l'identifiant interne n'est pas exposé. - Toutes les valeurs de frais et bases affichent une unité monétaire conforme au format transversal. - Les étapes du Plan d'amortissement conservent leur progression et sauvegardent l'avancement existant. Aucune estimation d'effort n'est ajoutée sans donnée fiable. - Le SIRET est normalisé à partir de quatorze chiffres, formaté pour la lecture et validé localement avec sa clé. Aucun appel à un registre externe n'est ajouté et l'interface précise que l'application ne certifie ni l'existence ni l'activité de l'établissement. - Renommer l'action fiscale « Enregistrer le profil fiscal ». Expliquer que le Profil fiscal LMNP reste modifiable et que chaque Clôture d'exercice fiscal en conserve une copie historique. - Ne pas ajouter d'écran récapitulatif séparé avant cet enregistrement. Utiliser la validation progressive, le résumé d'erreurs et la protection contre les modifications non enregistrées. - Les confirmations irréversibles existantes, notamment les Clôtures, restent distinctes de l'enregistrement modifiable du Profil fiscal LMNP. ### Calendrier, Réglages et Administration - Conserver la grille mensuelle structurée sur desktop et la liste chronologique sur mobile. Ne pas ajouter de commutateur Mois/Liste dans ce périmètre. - Ajouter une commande de fermeture visuelle aux boîtes de dialogue du Calendrier tout en conservant Annuler et la gestion de focus Material. - Élargir l'action « Enregistrer le profil » sur desktop. La désactiver lorsque le formulaire est inchangé, puis l'activer après une modification même si une première tentative doit encore révéler les erreurs de validation. - Conserver la section Session dans Réglages pour les vues où le bloc de session latéral n'est pas visible. Ne pas ajouter de réglages de langue, format régional ou notification. - Remplacer dans Administration les termes techniques par « Fichiers stockés », « Espace utilisé » et « Appartements enregistrés » et corriger la casse française. - Ne pas créer de métriques, quotas, historiques, tendances, informations de sauvegarde ou état de service que les contrats actuels ne fournissent pas. ### Ordre de livraison - Livrer en premier les impasses actionnables : État des lieux, Amortissements et Échéances et règlements. - Achever ensuite la localisation des Dates civiles, des libellés du calendrier et des titres de route. - Refaire l'Inventaire du mobilier, y compris son changement de modèle brouillon, avant de réorganiser le Bail qui en dépend. - Réorganiser ensuite les formulaires Bail et Appartement, puis les états vides et les deux parcours du Tableau de bord. - Terminer par les grilles desktop, la navigation groupée, les Locataires, les autres formulaires et l'harmonisation de la microcopie, des montants et des actions. - Chaque incrément reste livrable et testé séparément, sans refactorisation sans rapport avec le comportement concerné. ## Testing Decisions - Un bon test vérifie un résultat observable : contenu rendu, action disponible, navigation produite, focus déplacé, requête publique, règle métier acceptée ou refusée. Il ne dépend pas des classes CSS internes, de l'ordre privé des méthodes ni de la structure d'un signal. - Le seam frontend principal est le composant de page avec les services HTTP remplacés par des réponses contrôlées et le routeur réel de test. Les tests existants du Tableau de bord, des Appartements, Locataires, Baux, Échéances et règlements, Inventaire, Calendrier, Amortissements, Prêts, Dépenses, Fiscalité, Réglages et Navigation servent de prior art. - Les tests de navigation vérifient les groupes desktop, le menu « Plus », « Accueil » à 390 px, la visibilité d'Administration selon le rôle, les routes correctives, le contexte de retour et les titres d'onglet. - Les tests des états vérifient séparément premier chargement, rafraîchissement avec contenu conservé, erreur technique réessayable, prérequis métier actionnable, collection vide et réussite de mutation. - Les tests de formulaires vérifient l'enregistrement occupé, la prévention des doublons, le résumé d'erreurs, le focus du premier champ invalide, la protection contre la navigation et la barre d'actions persistante sans tester son positionnement pixel par pixel. - Les tests Appartement couvrent la création minimale, le prix initialement vide, l'ouverture de la fiche, les rubriques de complétude, les actions secondaires espacées et la conservation des protections de correction d'acquisition. - Les tests Locataire couvrent le nombre de Pièces jointes sur les cartes, les métadonnées disponibles dans la fiche, l'unique commande accessible de téléversement, `mailto:`, `tel:` et le filtrage des Baux existants à partir de leurs `tenantIds` sans nouvel endpoint. - Les tests Bail couvrent l'accès non linéaire aux rubriques, le verrouillage des rubriques dépendantes avant les Parties, l'enregistrement d'un brouillon incomplet, les valeurs locales invalides, les statuts de complétude, la revue finale et l'action principale propre au statut. - Le seam backend du Bail reste le service de brouillon et son contrat HTTP versionné. Les tests de domaine, de service et web existants vérifient qu'un brouillon incomplet peut être créé ou révisé, qu'une valeur présente mais invalide est refusée, qu'une concurrence échoue proprement et que génération et Finalisation refusent les faits obligatoires absents. - Le seam backend de l'Inventaire est l'agrégat puis son endpoint versionné. Les tests couvrent le préremplissage non attribué, la sauvegarde d'une ligne sans Espace privatif, le refus d'un identifiant inconnu, les invariants Non vérifiée/Présente/Absente, la complétude et le refus de figer tant qu'une ligne reste non attribuée. - Les tests de l'État des lieux couvrent la différence entre erreur technique et Inventaire incomplet, l'action « Compléter l'inventaire », le contexte transmis puis « Reprendre l'état des lieux » sans redirection automatique. - Les tests Échéances et règlements couvrent les quatre états utiles : aucun Bail, Bail brouillon, Bail prêt à finaliser et Échéances existantes, ainsi que la sélection explicite lorsque plusieurs cibles sont possibles. - Les tests Dépenses et Prêts couvrent l'unicité de l'appel à l'action, le remplacement temporaire de la liste par le formulaire, l'annulation, la création réussie, le parcours en deux temps du Justificatif de dépense et l'explication de prévisualisation du Prêt immobilier. - Les tests Amortissements couvrent l'action « Configurer le plan », la présélection de l'Appartement, le retour vers l'Exercice fiscal, le libellé utilisateur du modèle, l'accès secondaire à la référence BOFiP et les unités monétaires. - Les tests fiscaux couvrent normalisation, formatage et validation locale du SIRET, absence d'appel externe, libellé d'enregistrement, explication des snapshots de Clôture, erreurs focalisées et modifications non enregistrées. - Les tests de Date civile complètent le prior art de l'adaptateur existant : saisie clavier et datepicker produisent la même date ISO, aucun contrôle natif `date` ne subsiste, aucun fuseau ne décale le jour et tous les boutons de calendrier ont un nom accessible français. - Les tests de formatage couvrent montant entier, centimes, zéro et valeur négative dans un résumé puis dans un tableau comptable ou fiscal. - Un parcours Playwright ciblé utilise les mécanismes d'authentification et de données existants, vérifie les groupes de navigation, un blocage corrigé avec retour, une date en français, l'absence de débordement horizontal et l'accès clavier à 2174 px puis 390 px. - Les parcours Playwright existants de navigation responsive, d'Inventaire du mobilier, d'édition Locataire, de Finalisation du Bail, de prévisualisation du Prêt immobilier et de Fiscalité constituent le prior art. Les scénarios sont étendus plutôt que dupliqués. - L'absence d'objectif global WCAG ne supprime aucun test explicitement demandé ici. Les tests ciblés vérifient les noms, rôles, focus, clavier et contrastes observés sans prétendre fournir une certification exhaustive. - La vérification finale exécute le formatage, le lint, le typecheck, les tests frontend pertinents, les tests backend de domaine/service/web, les parcours navigateur ciblés et les builds. Toute commande non exécutée est signalée. ## Out of Scope - Une refonte visuelle de marque, un nouveau thème, une nouvelle palette ou une bibliothèque de composants concurrente d'Angular Material. - Une certification globale WCAG 2.2 AA ou AAA ; les défauts d'accessibilité explicitement décrits restent bien dans le périmètre. - Une vue tableau, un sélecteur carte/tableau, une recherche, des filtres avancés ou une pagination pour Appartements, Locataires ou Baux. - Un dimensionnement au-delà de la cible initiale de un à vingt Appartements sans mesure démontrant le besoin. - Un assistant global obligatoire après le Profil bailleur, un statut global « configuration terminée » ou une séquence unique imposée entre Location et Comptabilité. - Un système générique de brouillons, une autosauvegarde du Bail, de l'Appartement, de l'Inventaire ou du Profil fiscal LMNP, ou un endpoint de sauvegarde par rubrique. - Une route de consultation Appartement distincte de sa fiche de travail ou un nouveau parcours Locataire uniquement pour afficher ses Baux. - Un endpoint backend Locataire–Baux, un index ou un cache destiné au filtrage d'un petit portefeuille. - Une date de téléversement ajoutée aux Pièces jointes du Locataire uniquement pour enrichir leur affichage. - Le chiffrement des Locataires, Baux ou Pièces jointes, qui reste coordonné par le ticket dédié existant. - L'implémentation complète des Candidatures, du Déverrouillage des candidatures ou de la sélection ; seule la compatibilité de la définition du Locataire et la décision d'association explicite sont consignées ici. - Tout rapprochement automatique ou toute fusion de personnes à partir du nom, de l'e-mail ou du téléphone. - Une affectation automatique des catégories de mobilier à une pièce supposée. - Un état du mobilier dans l'Inventaire contractuel ; cet état appartient à l'État des lieux. - Une redirection automatique depuis l'Inventaire vers l'État des lieux. - Un commutateur Mois/Liste ou une grille mensuelle compressée sur mobile. - L'ajout du montant, de la Nature de dépense ou du fichier au formulaire initial de Justificatif de dépense. - Une nouvelle route ou boîte de dialogue pour créer un Prêt immobilier. - Une recherche externe du SIRET, une certification de l'établissement ou une validation de son activité LMNP. - Un écran récapitulatif fiscal supplémentaire, une transmission fiscale, un conseil juridique ou une modification du moteur de Simulation fiscale. - Des préférences de langue, de format régional ou de notifications. - De nouvelles métriques d'Administration, tendances, quotas, informations de sauvegarde ou états de service sans source existante. - Une migration, un adaptateur de compatibilité ou une double lecture des données de développement ; les contrats et schémas changent directement avec leurs appelants et tests. ## Further Notes - Cette spec synthétise l'audit du 2 septembre 2026 et les trente-huit décisions prises pendant sa revue détaillée. En cas d'écart, les décisions explicites de cette spec prévalent sur les suggestions exploratoires de l'audit initial. - Elle respecte la séparation entre Profil bailleur et Profil fiscal LMNP, la stratégie de localisation française, Angular Material et les thèmes existants, le Tableau de bord en lecture seule, la séparation Comptabilité/Fiscalité et la cible de petits portefeuilles enregistrée par ADR. - L'issue fermée #73 demandait déjà qu'aucun contrôle natif de Date civile ne subsiste. Le code en contient de nouveau ou encore ; cette spec achève cette standardisation et couvre aussi les libellés accessibles français du datepicker. - L'issue ouverte #121 conserve actuellement une carte de compte dans ses décisions. Cette spec la remplace uniquement sur ce point : la carte Compte est supprimée du Tableau de bord, tandis que le reste du snapshot et de ses responsabilités demeure inchangé. - L'issue ouverte #156 impose actuellement que la sélection d'une Candidature crée toujours un nouveau Locataire. Elle doit être réalignée avant implémentation de ce parcours afin d'offrir aussi l'association explicite à un Locataire existant, sans rapprochement ni écrasement automatique. La présente spec n'implémente pas ce système de Candidatures. - La présence de Baux associés à un Locataire est déjà déductible du contrat de liste des Baux et de leurs `tenantIds`. Le frontend doit réutiliser cette donnée plutôt que créer une API redondante. - Les données de l'application ne sont pas en production. Les changements du brouillon de Bail et de l'Inventaire du mobilier remplacent directement les contrats et schémas de développement ; les jeux de données incompatibles peuvent être supprimés ou reseedés. - Les changements doivent être découpés en incréments selon l'ordre indiqué, avec de petits commits cohérents et sans refactorisation étrangère. Le ticket reste la spécification commune de la refonte ; son implémentation peut être distribuée en tickets enfants si la taille opérationnelle l'exige.
nessar commented 2026-09-02 23:18:12 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #161

mentioned in issue #161
nessar commented 2026-09-02 23:18:16 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #162

mentioned in issue #162
nessar commented 2026-09-02 23:18:22 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #163

mentioned in issue #163
nessar commented 2026-09-02 23:18:27 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #164

mentioned in issue #164
nessar commented 2026-09-02 23:18:32 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #165

mentioned in issue #165
nessar commented 2026-09-02 23:18:36 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #166

mentioned in issue #166
nessar commented 2026-09-02 23:18:40 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #167

mentioned in issue #167
nessar commented 2026-09-02 23:18:45 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #168

mentioned in issue #168
nessar commented 2026-09-02 23:18:51 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #169

mentioned in issue #169
nessar commented 2026-09-02 23:18:56 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #170

mentioned in issue #170
nessar commented 2026-09-02 23:19:01 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #171

mentioned in issue #171
nessar commented 2026-09-02 23:19:05 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #172

mentioned in issue #172
nessar commented 2026-09-02 23:19:09 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #173

mentioned in issue #173
nessar commented 2026-09-02 23:19:14 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #174

mentioned in issue #174
nessar commented 2026-09-02 23:19:19 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #175

mentioned in issue #175
nessar commented 2026-09-02 23:19:24 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #176

mentioned in issue #176
nessar commented 2026-09-02 23:19:28 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #177

mentioned in issue #177
nessar commented 2026-09-02 23:19:33 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #178

mentioned in issue #178
nessar commented 2026-09-02 23:19:38 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #179

mentioned in issue #179
nessar commented 2026-09-02 23:19:42 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #180

mentioned in issue #180
nessar commented 2026-09-02 23:19:47 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #181

mentioned in issue #181
nessar commented 2026-09-02 23:19:52 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in issue #182

mentioned in issue #182
nessar commented 2026-09-27 17:27:32 +02:00 (Migrated from 172.24.0.1:8928)

mentioned in commit 1be3d20b48

mentioned in commit 1be3d20b48fd8deea61f9f7389203167d18368cc

Preserved GitLab #160 history: source attribution, exact timestamps, discussion grouping and review positions. Historical diff snapshots: 0; visible source notes: 23.

gitlab-47-issue-160.md (SHA-256 af0fe3cd658c559130b7cc772313e2b7e430f4eec756fb04df24f7fe0620af58)

gitlab-47-issue-160.json (SHA-256 e4f96bce52a7d5fb2e247b74e1a84f6d68229d03375b0d4f08a6e6909ef92b6b)

Old CI job execution and reports are omitted. Original source files and rollback backups remain protected.

<!-- gitlab-to-gitea-history:47:Issue:160 --> Preserved GitLab #160 history: source attribution, exact timestamps, discussion grouping and review positions. Historical diff snapshots: 0; visible source notes: 23. [gitlab-47-issue-160.md](https://gitea.nessar.fr/attachments/1cc90fde-b97d-4465-8437-3273c9568dba) (SHA-256 `af0fe3cd658c559130b7cc772313e2b7e430f4eec756fb04df24f7fe0620af58`) [gitlab-47-issue-160.json](https://gitea.nessar.fr/attachments/b4f65966-6afb-44bd-a292-ae073555f394) (SHA-256 `e4f96bce52a7d5fb2e247b74e1a84f6d68229d03375b0d4f08a6e6909ef92b6b`) Old CI job execution and reports are omitted. Original source files and rollback backups remain protected.
gitea-emergency added this to the Development project 2026-10-11 22:14:35 +02:00
gitea-emergency moved this to need-human-test in Development on 2026-10-11 22:14:35 +02:00
gitea-emergency added this to the Development — Parents project 2026-10-11 22:14:40 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: nessar/lmnp-organizer#160