## 2026-05-04 14:34:37 — Back office MVP structure en place **Objectif** Acter l’état du back office RenoValid MVP dans le workspace. **Actions** - Création du dossier reno-app/backoffice - Création des fichiers Python FastAPI - Création des routes référentiels, codes postaux, projets et statistiques - Création des CSV d’exemple - Adaptation du projet pour Python 3.7 et retrait de pandas **Résultat** Structure MVP du back office en place. Les dépendances restent à installer côté serveur pour rendre l’API exécutable, mais l’état de travail est considéré comme OK pour poursuivre la conception fonctionnelle. **Prochaines étapes** - Préparer la première interface admin simple - Définir les écrans back office prioritaires - Ajouter authentification admin et journal d’audit --- ## 2026-05-05 — Nettoyage du périmètre mobile-lite Le dossier projet a été nettoyé de façon réversible. Périmètre actif conservé : - `reno-app/mobile-lite/` : application mobile MVP active - `reno-app/backoffice/` : back office MVP Éléments sortis du périmètre actif et déplacés dans l’archive : - `reno-app/mobile/` - `reno-app/data/` - `reno-app/assets/` - `reno-app/tools/` - `reno-app/index.html` - `reno-app/script.js` - `reno-app/style.css` Archive créée : - `reno-app/_archive_unused/2026-05-05/` Raison : ces éléments concernent l’ancienne app web, une app mobile secondaire ou des outils ponctuels. Ils ne sont pas nécessaires au MVP mobile-lite actuel. Aucune suppression définitive n’a été faite. ## 2026-05-05 — Visualisation et raccord mobile-lite Corrections effectuées : - La documentation `VISUALISER.md` ne pointe plus vers l’ancienne app web. - L’écran admin `backoffice/admin/index.html` ne renvoie plus vers `index.html` archivé. - Ajout d’un fichier de contrôle mobile : `mobile-lite/src/data/backoffice-control.js`. - Raccord initial de `mobile-lite/src/data/pricing-catalog.js` au contrôle back office. - Raccord initial de `mobile-lite/src/data/region-profiles.js` au contrôle back office. État du pilotage : partiel mais réel. Le back office peut maintenant influencer le catalogue de prix et les multiplicateurs régionaux via `backoffice-control.js`. Le moteur complet `project-estimate.js` contient encore des prix en dur à externaliser ensuite. ## 2026-05-05 — Externalisation du moteur d’estimation mobile-lite Objectif : rendre le moteur de calcul `mobile-lite` pilotable par le back office. Fichiers créés / modifiés : - Créé : `mobile-lite/src/data/estimate-rates.js` - Modifié : `mobile-lite/src/data/backoffice-control.js` - Modifié : `mobile-lite/src/utils/project-estimate.js` - Créé : `backoffice/MOBILE_PILOTAGE.md` Résultat : - Les multiplicateurs d’état et de finition sont externalisés. - Les frais par défaut sont externalisés. - Les postes curage, toiture, façade, chauffage, équipements, division, second œuvre, finitions, extension, création/suppression de pièces et aléas utilisent maintenant `ESTIMATE_RATES`. - Le fichier `backoffice-control.js` expose `estimateRateOverrides`, qui permettra au back office de surcharger les taux publiés. État : le pilotage du calcul mobile-lite est maintenant fonctionnel au niveau référentiel code. Il reste à construire l’écran admin éditable pour modifier ces valeurs sans toucher au code. ## 2026-05-05 — Écran Tarifs & Barèmes détaillé Objectif : ne plus limiter l’interface back office au multiplicateur global. Fichiers modifiés : - `backoffice/admin/index.html` - `backoffice/admin/style.css` - `backoffice/admin/rates.js` Résultat : L’écran admin affiche désormais les principaux paramètres pilotables du moteur mobile-lite : - multiplicateurs état / finition - préparation et démolition - toiture et façade - équipements et réseaux - second œuvre et finitions - extension et pièces créées - frais et aléas L’interface génère un bloc JSON d’overrides destiné à `mobile-lite/src/data/backoffice-control.js`. État : édition visuelle disponible côté back office MVP. La sauvegarde automatique directe dans le fichier ou via API reste à ajouter. ## 2026-05-05 — Publication vers mobile-lite Objectif : permettre à l’écran back office de publier les overrides vers l’app mobile MVP. Fichiers créés / modifiés : - Créé : `backoffice/admin/publish-control.php` - Créé : `backoffice/admin/publish.js` - Modifié : `backoffice/admin/index.html` - Modifié : `backoffice/admin/style.css` Résultat : L’écran admin contient maintenant un bouton `Publier vers mobile-lite`. Ce bouton envoie le JSON généré à `publish-control.php`, qui écrit dans : - `mobile-lite/src/data/backoffice-control.js` Le script crée aussi une sauvegarde préalable dans : - `backoffice/data/publication-backups/` État : publication MVP disponible côté interface. À tester depuis le navigateur, car le POST dépend de l’accès HTTP réel au fichier PHP. ## 2026-05-05 — Publication back office confirmée La publication depuis l’interface admin vers `mobile-lite` fonctionne. Version publiée confirmée : - `mobile-lite-mvp-20260505-110349` Fichier publié vérifié : - `reno-app/mobile-lite/src/data/backoffice-control.js` Le fichier contient bien les overrides générés depuis l’écran `Tarifs & Barèmes`, notamment les paramètres du moteur d’estimation dans `estimateRateOverrides`. État : le bouton `Publier vers mobile-lite` est opérationnel. ## 2026-05-05 — Page Codes postaux / communes Objectif : ajouter une page back office pour piloter le référentiel de communes consommé par `mobile-lite`. Fichiers créés / modifiés : - Créé : `backoffice/admin/postal-codes.html` - Créé : `backoffice/admin/postal-codes.js` - Créé : `backoffice/admin/publish-postal-codes.php` - Modifié : `backoffice/admin/index.html` - Modifié : `backoffice/admin/style.css` - Modifié : `mobile-lite/src/data/postal-codes.js` Résultat : Le référentiel mobile `postal-codes.js` fusionne maintenant les codes postaux de base avec les overrides publiés dans `backoffice-control.js`. L’interface admin permet de saisir un CSV simple `postal_code,commune`, de prévisualiser les overrides et de publier vers `mobile-lite`. État : page Codes postaux / communes disponible et raccordée au mécanisme de publication MVP. ## 2026-05-05 09:14:04 — Recherche source base codes postaux communes **Objectif** Identifier les sources fiables pour alimenter une base complète codes postaux / communes dans le back office RenoValid. **Actions** - Recommander les sources publiques officielles françaises - Préparer les options d’intégration future dans la page Codes postaux / communes **Résultat** À documenter côté réponse utilisateur : privilégier data.gouv.fr / Base officielle des codes postaux La Poste, COG INSEE, BAN pour adresses plus fines. **Prochaines étapes** - Ajouter un import CSV complet dans le back office - Prévoir mapping postal_code, commune, insee_code, department_code, region --- ## 2026-05-05 09:21:47 — Clarification format codes postaux **Objectif** Acter la règle de formatage des codes postaux français dans le back office et mobile-lite. **Actions** - Confirmer que les codes postaux doivent être conservés sur 5 caractères - Rappeler que les codes commençant par 0 doivent rester en texte et non en nombre **Résultat** Règle retenue : toujours stocker et publier les codes postaux comme chaînes de 5 caractères, par exemple 01140 et 02380. **Prochaines étapes** - Vérifier que les imports CSV conservent les zéros initiaux - Ajouter une normalisation padStart(5, '0') dans les écrans/imports si nécessaire --- ## 2026-05-05 09:38:26 — Base codes postaux complétée **Objectif** Acter la validation de la publication du référentiel codes postaux / communes vers mobile-lite. **Actions** - Validation utilisateur de la publication codes postaux - Confirmation que la base de données codes postaux / communes a été complétée - Rappel de la règle de stockage des codes postaux sur 5 caractères **Résultat** La page back office Codes postaux / communes est opérationnelle et la base a été complétée côté utilisateur. La publication vers mobile-lite fonctionne. **Prochaines étapes** - Créer la page back office de suivi des simulations et projets enregistrés - Prévoir ensuite statistiques de saisie terrain --- ## 2026-05-05 09:41:43 — Page projets simulations créée **Objectif** Ajouter au back office une page de suivi des simulations, brouillons et projets enregistrés par mobile-lite. **Actions** - Lecture du stockage mobile-lite dans src/storage/projects.js - Création de backoffice/admin/projects.html - Création de backoffice/admin/projects.js - Ajout du lien depuis l’accueil admin - Ajout des styles KPI et tableau **Résultat** La page Projets / simulations est disponible. Elle lit localStorage avec la clé renovalid.projects.v1 quand accessible et accepte aussi un import JSON manuel. **Prochaines étapes** - Tester depuis le navigateur avec des projets sauvegardés dans mobile-lite - Prévoir une synchronisation API native pour les projets mobile si nécessaire - Créer ensuite la page Statistiques terrain --- ## 2026-05-05 09:45:50 — Clarification domaine back office mobile-lite **Objectif** Expliquer pourquoi le back office et mobile-lite peuvent ou non partager le même stockage navigateur. **Actions** - Clarifier la différence entre fichiers sur le même serveur et origine navigateur - Identifier les cas où localStorage est partagé - Identifier les cas où l’app native Expo ne partage pas le localStorage du back office **Résultat** Le back office et mobile-lite partagent localStorage uniquement s’ils sont ouverts dans le même navigateur avec exactement la même origine protocole + domaine + port. Une app mobile native Expo ne partagera pas ce localStorage avec une page back office web. **Prochaines étapes** - Prévoir une synchronisation API des projets mobile-lite vers le back office - Conserver l’import JSON comme solution MVP temporaire --- ## 2026-05-05 10:04:14 — Base multi-utilisateurs et synchronisation projets **Objectif** Préparer le back office RenoValid à centraliser les données de plusieurs utilisateurs mobile-lite. **Actions** - Ajout des modèles UserAccount, ApiSession et PasswordResetToken - Ajout de user_id et device_id sur les projets sauvegardés - Création des routes /auth pour inscription, connexion, profil, mot de passe oublié et reset mot de passe - Création de /sync/projects pour synchroniser les projets mobile-lite vers la base centrale - Ajout des services mobile-lite backoffice-api.js et project-sync.js - Branchement de la synchronisation après saveProjectSnapshot - Ajout de la documentation MULTI_USER_SYNC.md **Résultat** La structure multi-utilisateurs et synchronisation est en place côté code. Les projets peuvent désormais être rattachés à un utilisateur et synchronisés via API avec token Bearer. Le reset mot de passe est prévu avec envoi SMTP ou fallback dans email-outbox. **Prochaines étapes** - Créer les écrans mobile-lite inscription / connexion / mot de passe oublié - Configurer l’URL réelle de l’API back office dans mobile-lite - Mettre à jour la page back office Projets pour lire directement l’API centrale - Configurer SMTP pour les emails de réinitialisation --- ## 2026-05-05 10:12:25 — Écrans mobile-lite compte utilisateur **Objectif** Créer les écrans mobile-lite nécessaires pour connecter chaque utilisateur à son espace et permettre la synchronisation des projets vers le back office. **Actions** - Ajout de app/account/login.js - Ajout de app/account/register.js - Ajout de app/account/forgot-password.js - Déclaration des écrans dans app/_layout.js - Ajout d’un accès Connexion / compte depuis l’accueil mobile - Enrichissement du service backoffice-api.js avec inscription, profil et déconnexion locale **Résultat** Les écrans mobiles de connexion, inscription et mot de passe oublié sont créés. La connexion et l’inscription stockent le token utilisateur puis déclenchent une synchronisation des projets locaux vers le back office. **Prochaines étapes** - Configurer l’URL réelle du back office dans mobile-lite/src/services/backoffice-api.js - Tester register/login depuis l’app mobile - Créer un écran de profil / état de synchronisation - Brancher la page admin Projets sur l’API centrale --- ## 2026-05-05 10:28:48 — Correction UX mobile compte et accueil **Objectif** Corriger l’approche mobile-lite pour séparer accueil, compte utilisateur et historique des simulations. **Actions** - Suppression de l’historique des projets de la page d’accueil mobile - Refonte de l’accueil mobile en écran compact orienté action - Ajout de l’option Rester connecté sur connexion et inscription - Mise à jour du stockage de token pour gérer session persistante ou session mémoire - Documentation des décisions UX dans MOBILE_UX_ACCOUNT.md **Résultat** L’accueil mobile ne liste plus les simulations. Les écrans connexion et inscription proposent maintenant de rester connecté sur l’appareil. Les projets restent sauvegardés localement et seront synchronisés après connexion, mais l’historique devra être placé sur un écran dédié ultérieur. **Prochaines étapes** - Créer un écran dédié historique/projets utilisateur - Tester les écrans sur format mobile réel ou simulateur - Configurer l’URL réelle de l’API back office ---