# Audit UX/UI et plan de conception du back-office — Walk The Line Management **Phase : audit et conception uniquement — aucune implémentation** **Source analysée :** archive `WTL production.zip` fournie comme version de production **Révision Git embarquée :** `master` — `ab202db` (`FIX(Migration error)`) **Date de l’audit :** 17 septembre 2026 --- ## 1. Cadre, méthode et limites ### 1.1 Règles appliquées - `AGENTS.md` a été lu intégralement avant l’analyse. - Le chantier est traité comme une modification majeure : ce document s’arrête à l’audit et au plan. - Le code courant est la source de vérité pour le fonctionnement réellement disponible. - `SPECIFICATIONS_FONCTIONNELLES.md` et le manuel utilisateur intégré au dashboard ont été confrontés au code. - Les anciens `README_WTL*.md` n’ont pas été utilisés comme source fonctionnelle. - Aucun fichier de l’application, aucune migration et aucun média artistique n’ont été modifiés. - Les règles métier, permissions, isolations projet et invariants documentaires/comptables restent inchangés dans toutes les propositions. ### 1.2 État technique de l’archive Le ZIP contient un dépôt Git sur `master`, au commit `ab202db`. Après extraction, `git status` signale de très nombreux fichiers modifiés parce que les fichiers livrés utilisent des fins de ligne CRLF alors que l’index Git contient des LF. `git diff --ignore-space-at-eol` ne détecte aucune différence de contenu sur ces fichiers. Quelques fichiers suivis ne figurent pas dans l’archive (`.idea/*` et `assets/stage-plan/icons/kakemono.png`). L’audit porte sur les fichiers effectivement livrés comme version de production. ### 1.3 Validation dynamique non réalisée pendant cette phase L’environnement d’audit ne fournit ni exécutable PHP ni Docker. L’application n’a donc pas pu être démarrée et aucune session back-office authentifiée n’a pu être parcourue dans un navigateur pendant cette phase. Les constats reposent sur une analyse statique approfondie des contrôleurs, services, formulaires, templates Twig, CSS, JavaScript, routes, permissions et documents courants. Le plan d’implémentation prévoit explicitement une validation dans un vrai navigateur, avec données représentatives et plusieurs profils de permissions. Les observations visuelles devront être confirmées avant de considérer chaque lot comme terminé. --- ## 2. Synthèse exécutive Le back-office est fonctionnel et cohérent sur le plan métier, mais son interface présente aujourd’hui trois problèmes structurants. 1. **La hiérarchie de l’information ne suit plus la fréquence d’usage.** Le menu peut exposer environ quarante entrées réparties dans sept groupes. Le dashboard place Analytics avant les actions urgentes et cumule six tableaux, des suggestions, huit indicateurs et plusieurs graphiques. 2. **Les listes et dossiers deviennent des surfaces d’action très denses.** La liste des prospections affiche dix colonnes et jusqu’à six actions par ligne. La fiche d’une prospection comporte jusqu’à douze actions métier au même niveau visuel, plusieurs blocs longs, quatre modales et jusqu’à 91 contrôles/boutons dans le template. 3. **Le mobile réduit encore majoritairement l’interface desktop au lieu de proposer une interaction dédiée.** Le menu devient un offcanvas de 280 px contenant toujours toutes les entrées ; les tableaux reposent sur DataTables Responsive ou un scroll horizontal ; les boutons `btn-sm` et les actions uniquement iconographiques sont fréquents ; plusieurs formulaires longs restent dans des modales. La cible recommandée n’est pas une refonte graphique radicale ni l’introduction d’un nouveau framework. Elle repose sur : - une navigation principale courte, orientée tâches ; - une barre d’actions mobile accessible au pouce ; - une action globale **Saisie terrain** ; - des listes en tableaux sur desktop et en cartes métier sur smartphone ; - une action principale contextuelle par écran, les autres actions étant regroupées ; - des dossiers organisés en résumé, suivi, documents, technique et historique ; - des options avancées affichées à la demande ; - du chargement contextuel pour éviter les énormes DOM de modales répétées ; - des retours d’action immédiats, localisés et accessibles. Le parcours terrain peut être ramené à moins d’une minute sans nouvelle entité ni migration : recherche du lieu, création minimale si nécessaire, contact facultatif ou minimal, choix explicite de l’intention commerciale, puis transaction utilisant `Venue`, `VenueContact`, `Prospection`, `ProspectionWorkflowService` et `ProspectionUniquenessService`. --- ## 3. Principes de conception cibles ### 3.1 Une seule action principale visible Chaque page ou carte doit rendre évidente l’action la plus probable. Les opérations secondaires sont placées dans un menu « Autres actions » ou un panneau contextuel. Les opérations destructrices restent séparées et explicitement nommées. ### 3.2 Affichage progressif Les champs et informations sont répartis en trois niveaux : 1. indispensables maintenant ; 2. utiles dans le contexte courant ; 3. avancés ou administratifs, repliés par défaut. Cette progressivité ne supprime aucune donnée ni fonctionnalité. ### 3.3 Mobile sémantique, pas tableau rétréci Sur smartphone, une ligne de tableau devient une carte contenant : identité, état, prochaine échéance, une action principale et un menu complémentaire. Les colonnes secondaires sont disponibles dans le détail, pas masquées sans hiérarchie dans un composant DataTables. ### 3.4 Parcours conservant le contexte Les retours doivent ramener à la liste, au filtre, à l’onglet et à la position utiles. Les nouvelles créations depuis un dossier doivent revenir au dossier. Les paramètres `return_to` éventuels sont générés et validés côté serveur ; une URL libre fournie par le client ne doit jamais devenir une redirection ouverte. ### 3.5 Amélioration progressive et dépendances existantes La cible conserve Symfony/Twig, Bootstrap et le JavaScript existant. Aucun nouveau framework frontend n’est nécessaire. Les actions asynchrones proposées doivent garder un endpoint serveur autorisé, CSRF-protégé et une solution de repli par soumission classique lorsque raisonnable. ### 3.6 Accessibilité intégrée - zones tactiles visées : au moins 44 × 44 px pour les actions courantes ; - libellé accessible pour toute icône ; - focus visible et restauré après fermeture d’un panneau ; - erreurs reliées aux champs et résumées en tête de formulaire ; - retour d’action annoncé dans une zone `aria-live` ; - aucune information transmise uniquement par une couleur ou un survol. --- ## 4. Cartographie des parcours actuels problématiques | Parcours actuel | Friction observée | Conséquence | |---|---|---| | Nouveau lieu + contact + prospection | Depuis la prospection, « Créer un nouveau lieu » ouvre un nouvel onglet ; le formulaire de lieu présente immédiatement identification, adresse, budget, statut, SIRET, TVA et facturation ; l’enregistrement renvoie à la liste ; il faut revenir/recharger le wizard puis sélectionner le lieu et le contact | Parcours incompatible avec une saisie debout en moins d’une minute ; risque d’abandon ou de saisie ailleurs | | Traiter une échéance | Dashboard → ligne « Traiter » → longue fiche → choix parmi de nombreuses actions au même niveau → modale → rechargement | L’utilisateur doit connaître le workflow pour choisir ; surcharge cognitive | | Retrouver un lieu ou un contact | Liste de neuf colonnes, contacts dans une modale par lieu, modification dans une page séparée, retour toujours à la liste | Contexte perdu ; mobile difficile ; création d’un contact trop éloignée de la prospection | | Nouvelle date | Modale en six étapes ; création d’un lieu par une seconde modale imbriquée ; informations publiques et médias demandés avant la création | Parcours essentiel ralenti par des informations facultatives ; modales imbriquées fragiles sur mobile | | Prospection → devis → envoi | Devis accessible dans la liste et le dossier ; génération dans une grande modale ; l’envoi réel se fait ensuite dans le wizard mail avec sélection de pièce jointe | La distinction métier est correcte, mais l’étape suivante n’est pas guidée visuellement | | Consultation d’un dossier de prospection | En-tête avec plusieurs actions, date, checklist, prochaine action, douze actions rapides, lieu/contact, suivi, documents, technique, historique et mails | La fiche expose presque tout simultanément ; scroll important et action attendue difficile à identifier | | Fiche technique | Wizard de six étapes dans une modale allant jusqu’à 1 500 px, incluant un éditeur graphique | Parcours expert utilisable sur grand écran mais très lourd sur smartphone | | Paiement | Même formulaire dupliqué dans dashboard projet, dashboard comptable, liste commerciale, liste prospection et fiche facture | Expérience variable, dette de maintenance et risque de divergence | | Comptabilité quotidienne | Listes larges et formulaires de 10 à 14 champs dans des modales ; justificatif en bas du formulaire | Saisie mobile longue, erreurs plus probables, libellés financiers exposés sans aide contextuelle | | Paramétrage | Nombreuses entrées de menu indépendantes : tarifs, frais, technique, éléments, association, commercial, comptable, lignes, modèles, cinq référentiels, paramètres de prospection, mails, etc. | Le novice ne sait pas où chercher ; le menu opérationnel est pollué par des fonctions rares | --- ## 5. Navigation générale ### Fonctionnement actuel `templates/admin/layout.html.twig` construit une sidebar fixe desktop et un offcanvas mobile. Les liens sont filtrés par `can_permission()`. Le projet actif apparaît dans une carte et dans l’en-tête de page. Le menu peut contenir environ quarante liens, répartis entre Pilotage, Commercial, Production, Configuration du projet, données partagées, finances et Administration. ### Problèmes et impact - La structure reflète l’architecture interne plus que les tâches quotidiennes. - Les réglages rares occupent autant d’espace de navigation que les actions fréquentes. - Sur mobile, l’offcanvas conserve toute la longueur du menu ; changer d’écran implique ouvrir, faire défiler, choisir, puis recommencer. - Le projet actif est utile mais répété dans la sidebar et dans chaque page ; sur petit écran, la répétition consomme de la hauteur. - La navigation n’offre aucune action globale de création rapide. - Le bouton hamburger n’a pas de libellé accessible explicite dans le template. ### Proposition #### Desktop/tablette paysage Navigation principale recommandée : 1. **Accueil** - Tableau de bord - À traiter - Demandes entrantes avec compteur 2. **Commercial** - Prospections - Lieux & contacts - Dates - Devis & factures - Conventions - Simulateur 3. **Production** - Fiches techniques - Plans de scène 4. **Documents** - Bibliothèque - Documents comptables si autorisé 5. **Comptabilité** - Synthèse - Dépenses - Recettes - Merchandising - Contrats - TVA 6. **Paramètres** - page d’entrée organisée en « Projet », « Association », « Référentiels », « Accès et sécurité » ; seuls les sous-liens autorisés sont affichés. Les groupes peuvent être repliables, mais le groupe courant reste ouvert. Les réglages ne sont plus tous visibles en permanence. #### Smartphone Barre inférieure proposée : - Accueil ; - À traiter ; - bouton central **Saisir** ; - Prospections ; - Plus. « Plus » ouvre un bottom sheet contenant les autres destinations autorisées. Le bouton « Saisir » ouvre les actions rapides filtrées par permissions : contact terrain, prospection, date, dépense, recette merch., etc. Le premier choix reste « Nouveau contact terrain ». Le sélecteur de projet reste disponible dans l’en-tête compact. Le projet courant est affiché sur une ligne ; son changement demande une confirmation uniquement si un formulaire contient des modifications non enregistrées. ### Alternative Conserver la sidebar actuelle et rendre seulement ses groupes repliables est moins coûteux, mais ne résout pas l’accès à une main ni la surcharge du menu mobile. Cette alternative n’est pas recommandée comme cible principale. ### Impact technique et fichiers - `templates/admin/layout.html.twig` - `templates/base.html.twig` - `public/css/app.css` - nouveau JavaScript léger, par exemple `public/js/admin-shell.js` - `PermissionExtension` / `PermissionChecker` uniquement pour réutiliser les contrôles existants, sans changer leur sens Aucune migration. Risques : disparition accidentelle d’un lien pour un profil limité, route active incorrecte, régression CSP/CDN. Validation avec plusieurs groupes obligatoire. --- ## 6. Dashboard ### Fonctionnement actuel `AdminController::dashboard()` charge actions à traiter, toutes les suggestions (`suggestions(0, project)`), factures à encaisser, comptes/modes de paiement et Analytics. `templates/admin/dashboard.html.twig` affiche, dans cet ordre, Analytics, actions urgentes, factures, suggestions, huit métriques, progression et graphiques de répartition. ### Problèmes et impact - Analytics précède les opérations urgentes. - Le dashboard cumule pilotage quotidien et reporting détaillé. - Les suggestions peuvent produire une longue table et deux modales par lieu. - Les informations « tunnel historique » et « stock courant » sont utiles mais trop présentes pour une ouverture quotidienne. - Le paiement est répété par une modale spécifique à chaque facture. - Sur mobile, les tableaux et métriques créent un long scroll avant d’atteindre l’information recherchée. ### Proposition Page d’accueil orientée **Aujourd’hui** : 1. action « Saisie terrain » et éventuelles actions rapides ; 2. résumé compact : retards, aujourd’hui, demandes entrantes, factures à encaisser ; 3. liste priorisée des cinq actions les plus urgentes avec action contextuelle ; 4. prochain concert et niveau de préparation lorsqu’il existe ; 5. suggestions limitées aux cinq meilleures, avec « Voir toutes » ; 6. bloc « Suivi et statistiques » replié ou placé dans un onglet secondaire ; 7. Analytics en fin de page ou dans l’onglet statistiques. Sur mobile, les éléments sont des cartes. Une carte d’action montre date, lieu, action, retard et bouton « Faire maintenant ». Les paiements utilisent un composant partagé chargé à la demande. ### Bénéfice L’ouverture du back-office répond immédiatement à « que dois-je faire ? ». Le reporting reste disponible sans dominer le travail quotidien. ### Impact technique et risques - `src/Controller/AdminController.php::dashboard` - `src/Repository/ProspectionRepository::findToProcess`, `dashboardCounts` - `src/Service/ProspectionSuggestionService` - `templates/admin/dashboard.html.twig` - extraction de composants Twig partagés pour cartes/actions/paiement Prévoir limites serveur et requêtes ciblées, pas seulement `slice` Twig. Risques : statistiques cachées au point de paraître supprimées, perte d’une permission dans un composant partagé, N+1. Aucune migration. --- ## 7. « À traiter » ### Fonctionnement actuel `AdminController::toProcess()` rend une table DataTables de neuf colonnes : urgence, date, action, lieu, ville, contact, responsable, statut et ouverture. ### Problèmes - L’utilisateur doit ouvrir chaque dossier pour agir. - La distinction « en retard / à venir » est simple mais il n’existe pas de regroupement Aujourd’hui / En retard / Prochainement. - La table est inadaptée au téléphone. - Aucun filtre rapide « mes actions » n’est visible. ### Proposition - Segments : **En retard**, **Aujourd’hui**, **Cette semaine**, **Plus tard**. - Filtres accessibles : responsable, statut, type d’action, projet si pertinent. - Carte mobile : lieu, action, échéance, contact cliquable (`tel:`/`mailto:`), bouton principal correspondant à l’action recommandée, menu « Ouvrir le dossier ». - Après une action réussie, retirer ou déplacer la carte sans rechargement complet, avec possibilité d’annuler uniquement si l’action métier le permet déjà. Ne jamais inventer de rollback métier. Le bouton contextuel ouvre le même formulaire/action sécurisé que la fiche de prospection. Les événements, auteurs, reports et recalculs restent gérés par `ProspectionWorkflowService`. ### Impact - `templates/admin/to_process.html.twig` - `src/Controller/AdminController::toProcess` - `ProspectionRepository` - composant d’action partagé avec la fiche prospection Aucune migration. Risque principal : dupliquer la logique métier dans JavaScript. La transition doit rester côté service/contrôleur. --- ## 8. Prospection ### 8.1 Liste #### Fonctionnement actuel La liste possède dix colonnes, cinq filtres supplémentaires, DataTables et jusqu’à six actions par ligne. Le contrôleur charge toutes les prospections du projet, tous les documents commerciaux, conventions, comptes et modes de paiement. Le template génère ensuite pour chaque prospection une modale de devis, une modale de documents et éventuellement plusieurs modales de paiement. #### Problèmes - Surcharge visuelle et décisionnelle. - DOM potentiellement très volumineux ; les modales sont créées même si elles ne seront jamais ouvertes. - Les actions « Convention » et « Documents » se chevauchent. - Sur mobile, les actions importantes peuvent finir dans le détail responsive de DataTables. - Aucun filtre rapide Actives / À relancer / Accords sans date / Programmées / Terminées. #### Proposition - Desktop : colonnes principales Lieu, étape, prochaine action, responsable, montant/état synthétique, action. - Filtres métier sous forme de chips : `À traiter`, `Accord sans date`, `Programmées`, `Terminées`, puis panneau « Plus de filtres ». - Smartphone : cartes avec lieu/ville, statut, prochaine action et une action principale. - Menu par ligne : ouvrir, nouveau cycle si autorisé, devis, documents, paiement. - Charger les formulaires lourds à l’ouverture depuis un endpoint HTML contrôlé, ou naviguer vers le dossier ; ne plus rendre toutes les modales dans la liste. - Pagination/recherche serveur à prévoir si le volume le justifie, plutôt que charger toute l’historique dans le DOM. #### Fichiers - `src/Controller/ProspectionController::index` - `templates/admin/prospection/index.html.twig` - `_quote_modal.html.twig`, `_documents_modal.html.twig` - `ProspectionRepository` ### 8.2 Création et modification #### Fonctionnement actuel La création utilise trois étapes. L’étape Suivi contient quatorze champs. Si le lieu n’existe pas, l’utilisateur ouvre une nouvelle page dans un autre onglet puis doit recharger la prospection. La modification abandonne le wizard et affiche tous les champs ensemble. #### Proposition Création standard : 1. **Lieu et contact** : recherche, résumé, contact principal ; création contextuelle dans un panneau, sans nouvel onglet. 2. **Point de départ** : choisir explicitement « aucune démarche encore » ou « premier contact déjà réalisé », puis date/canal si nécessaire. 3. **Compléments** : priorité et note visibles ; conditions commerciales, relances personnalisées, accueil et documents envoyés sous « Options avancées ». Modification : blocs « Cible », « Planification », « Conditions », « Notes et options avancées ». L’action Enregistrer reste collée en bas sur mobile, avec indication de modifications non enregistrées. Ne pas exposer directement un choix arbitraire de statut. Les transitions restent des actions métier dédiées. ### 8.3 Fiche de prospection #### Problèmes - Jusqu’à douze actions rapides ont une importance visuelle proche. - Les actions ne sont pas toutes masquées en lecture seule dans le template ; le serveur protège correctement, mais l’utilisateur peut rencontrer un refus après avoir cliqué. - Documents, technique, suivi, historique et mails sont affichés sur une page très longue. - Les actions Refuser/Annuler/Remplacer utilisent parfois `prompt()` ou `confirm()`, peu adaptés au mobile et peu accessibles. #### Proposition En-tête fixe et compact : lieu, statut, prochaine action, date liée. Puis : - bouton principal = action recommandée par `nextAction`/état ; - bouton secondaire = envoyer un mail lorsque permis ; - menu « Autres actions » groupé : progression, suspendre/report, clôture, administration ; - aucun bouton d’écriture en lecture seule ; afficher « Consultation uniquement » ; - onglets ou sections ancrées : **Résumé**, **Suivi**, **Documents**, **Technique**, **Historique** ; sur mobile, accordéons ou navigation segmentée collante ; - raisons d’annulation/refus/remplacement dans un vrai formulaire avec libellé et aide ; - timeline et logs mails regroupés chronologiquement, avec filtre. Le statut terminal ne doit proposer que les actions autorisées, par exemple Reprogrammer après annulation. L’interface ne doit jamais reconstruire elle-même la matrice de transition : elle consomme une présentation fournie par un service de workflow ou une méthode dédiée. ### 8.4 E-mail Le wizard mail en modale est pertinent, mais doit devenir plein écran sur mobile, avec barre d’étape fixe et résumé des pièces jointes avant envoi. Après succès SMTP, la fiche doit mettre à jour visuellement le statut, le jalon et la timeline sans forcer l’utilisateur à rechercher ce qui a changé. En cas d’échec, conserver tout le contenu saisi et ne déclencher aucun effet métier. ### Risques - Régression de transition ou consommation de report si des actions sont recodées côté client. - Boutons montrés avec une permission insuffisante. - Incohérence entre statut, date, historique, Calendar et documents. - Perte de saisie lors du changement d’onglet/panneau. ### Données Aucune migration recommandée. Les informations nécessaires existent déjà. Éviter un champ « étape UI » persistant. --- ## 9. Lieux et contacts ### Fonctionnement actuel `VenueController::index()` charge tous les lieux partagés et leurs synthèses commerciales. La liste affiche neuf colonnes. Les contacts sont consultés dans une modale générée par lieu. La création d’un lieu demande immédiatement jusqu’à dix-sept informations, même si seules les informations de base sont connues. La création d’un contact est une page séparée qui retourne toujours à la liste. ### Proposition - Recherche unique en tête : nom, ville, contact, téléphone, e-mail. - Filtres : actif/fermé/archivé, type, présence d’un contact, prospection active. - Desktop : table allégée ; smartphone : cartes. - Ajouter une vraie vue « fiche lieu » ou un drawer desktop/full-screen mobile : identité, contacts, historique commercial du projet courant, autres historiques autorisés, actions. - Ajouter/modifier un contact depuis cette fiche sans retour à la liste. - Formulaire de lieu : bloc essentiel ouvert (nom, ville, type, site), puis coordonnées, administratif/facturation et comportement des suggestions repliés. - Retour contextuel : depuis une prospection, la création du lieu revient à la prospection et sélectionne le lieu. ### Prévention des doublons Avant la création, rechercher des candidats par nom/ville, SIRET, e-mail ou téléphone. Une valeur client n’autorise jamais l’accès ni le rattachement ; le serveur recharge et vérifie toute entité. La politique exacte sur les doublons supposés nécessite arbitrage, voir section 22. ### Fichiers et impact - `src/Controller/VenueController.php` - `src/Form/VenueType.php`, `VenueContactType.php` - `src/Entity/Venue.php`, `VenueContact.php` uniquement pour lecture ; aucun changement de mapping prévu - `templates/admin/venue/*` - `VenueCommercialSummaryService` - repository de recherche dédié à créer si nécessaire, sans migration --- ## 10. Workflow mobile « Saisie terrain » ### 10.1 Objectif mesurable Sur un téléphone 390 × 844, avec un lieu inédit et les informations de base disponibles, enregistrer lieu + contact + début de prospection en moins de 60 secondes, sans changement de page complet et sans saisir d’information administrative. ### 10.2 Parcours cible #### Étape 1 — Rechercher le lieu Champ autofocus « Nom du lieu, ville ou contact ». Les résultats apparaissent après quelques caractères : - lieu existant, ville, contact principal, prospection active éventuelle pour le projet ; - bouton « Utiliser ce lieu » ; - si une prospection active existe : bouton « Ouvrir la prospection existante », jamais création silencieuse d’un doublon ; - option « Aucun résultat : créer ce lieu ». #### Étape 2 — Lieu minimal si nécessaire Champs visibles : - nom du lieu ; - ville ; - type facultatif ; - site/réseau social facultatif. Pays = France par défaut, statut = actif. Adresse, jauge, budget, SIRET, TVA et facturation sont dans « Compléter maintenant » mais repliés. #### Étape 3 — Contact Pour un lieu existant : choisir un contact ou « Ajouter la personne rencontrée ». Pour un nouveau lieu : - nom ; - téléphone avec `inputmode="tel"` ; - e-mail avec clavier e-mail ; - fonction/type facultatif ; - contact principal activé par défaut si aucun autre contact n’existe. La création d’un contact peut être ignorée si seule l’information du lieu est connue. #### Étape 4 — Intention commerciale explicite Trois choix recommandés : 1. **Enregistrer seulement le lieu/contact** ; 2. **Créer une prospection à contacter plus tard** ; 3. **Créer la prospection et enregistrer le premier échange maintenant**. Le troisième choix renseigne le vrai jalon de premier contact à la date du jour, avec canal choisi ou « Rencontre en personne » si ce canal existe dans le référentiel. Il ne doit jamais être appliqué implicitement sans choix visible. Priorité et note courte restent facultatives. Le bouton final résume exactement les objets qui seront créés. #### Succès Écran de confirmation : - lieu/contact enregistrés ; - prospection créée ou dossier existant ouvert ; - prochaine action calculée ; - actions immédiates : « Ouvrir le dossier », « Ajouter une note », « Appeler », « Envoyer un e-mail ». ### 10.3 Architecture recommandée - endpoint de recherche GET autorisé et limité ; - endpoint POST unique pour la validation finale ; - DTO/formulaire dédié, sans entité parallèle ; - service d’orchestration transactionnel, par exemple `FieldContactCaptureService` ; - réutilisation de `Venue`, `VenueContact`, `Prospection`, `ProspectionWorkflowService`, `ProspectionScheduleService`, `ProspectionUniquenessService` ; - précontrôle puis gestion de `UniqueConstraintViolationException` pour les requêtes concurrentes ; - aucune confiance dans `venue_id`, `contact_id`, `project_id` reçus ; - projet issu du contexte serveur ; - permission `VENUE_CONTACT` pour créer lieu/contact et `PROSPECTION` pour créer une prospection ; l’interface adapte les choix aux droits réels ; - CSRF, validation Symfony, normalisation raisonnable des chaînes, échappement Twig ; - journalisation métier identique à une création normale. ### 10.4 Modèle de données Aucune nouvelle table ni colonne n’est nécessaire. Les champs secondaires sont déjà facultatifs. Un indicateur « fiche incomplète » peut être calculé à l’affichage ; il n’est pas recommandé d’ajouter un statut de brouillon tant qu’aucun besoin métier distinct n’est validé. ### 10.5 Résilience réseau Sans mode hors ligne, préserver les valeurs saisies en cas d’erreur réseau et proposer « Réessayer ». Ne pas enregistrer de données personnelles dans `localStorage` par défaut. Un vrai mode offline/PWA avec synchronisation et résolution de conflits constituerait un chantier distinct. --- ## 11. Dates de concert ### Fonctionnement actuel Deux onglets À venir/Archives, chacun avec une table de neuf colonnes et de nombreuses actions iconographiques. La création se fait dans une modale de six étapes. La création rapide d’un lieu ouvre une deuxième modale imbriquée ; le code contient déjà un contournement du verrouillage `body`, signe de fragilité. L’édition utilise une modale par date. ### Proposition - Cartes mobile avec date, lieu, état, publication, préparation et action principale. - Desktop : table allégée ; détails et actions dans un drawer. - Actions textuelles dans un menu : modifier, publication, Calendar, annuler, marquer jouée, supprimer. - Remplacer `prompt()` d’annulation par un formulaire accessible. - Création en page/panneau plein écran mobile, sans modale imbriquée. - Trois étapes : 1) lieu + date + horaires ; 2) publication ; 3) vérification. - Titre/description, confidentialité, affiche et liens restent disponibles dans « Informations publiques et médias », replié par défaut si « Ne pas publier » est choisi. - La création minimale conserve le défaut actuel « ne pas publier ». Les effets métier restent dans `ConcertDateController`, `ProspectionWorkflowService`, `ConcertPublicPresenter` et `GoogleCalendarService`. Toute sauvegarde locale est confirmée même si Calendar échoue, avec avertissement distinct. Aucune migration. Risques : perdre des champs facultatifs lors de la simplification, modifier involontairement la visibilité par défaut, contourner l’unicité de prospection active. --- ## 12. Simulateur tarifaire ### Fonctionnement actuel Sept cartes de saisie et un récapitulatif sticky sur desktop. Le lien final reporte uniquement `proposedFee` et `travelFee` vers une nouvelle prospection. ### Proposition - Les sections rares (techniciens, options, autres frais, remise) sont repliées tant que leurs valeurs sont nulles. - Résumé permanent sur desktop ; barre mobile collée en bas avec total et bouton « Utiliser ce montant ». - Expliquer en langage simple Plancher/Cible/Confort par une aide courte. - Si le simulateur est ouvert depuis une prospection, retourner vers cette prospection et remplir le montant sans en créer une nouvelle. - Si ouvert hors dossier, conserver le comportement de nouvelle prospection. ### Impact `SimulatorController`, `templates/admin/simulator/index.html.twig`, éventuellement paramètres de retour signés/validés. Aucune migration. Risque : divergence entre calcul JavaScript et règles configurées ; ajouter des tests sur les calculs ou déplacer le calcul partagé côté service si nécessaire. --- ## 13. Devis, factures, conventions et paiements ### Constats - Les écrans métier sont corrects, mais la même action de paiement est dupliquée dans plusieurs templates. - La génération de devis utilise une table de prestations à six colonnes, difficile sur mobile. - L’envoi réel du devis est séparé métier correctement, mais l’interface ne propose pas une suite de parcours évidente. - Les conventions possèdent une liste active/archive claire, mais beaucoup d’actions iconographiques. ### Proposition - Composant partagé de paiement, chargé à la demande, avec présentation identique partout. - Génération de devis mobile : prestation artistique visible ; prestations complémentaires sous forme de cartes activables, seules les lignes sélectionnées affichent quantité/prix/TVA/note. - Après génération : confirmation « Devis généré, non envoyé » avec deux actions : « Envoyer maintenant » et « Revenir au dossier ». - L’action Envoyer ouvre le wizard mail avec ce devis présélectionné, sans marquer le jalon avant succès SMTP. - Fiche document : action principale selon le type/état ; conversion facture, paiement et convention regroupés dans « Suite du dossier ». - Conventions : libellés textuels Archiver/Restaurer sur mobile ; suppression super-admin dans zone dangereuse. ### Fichiers - `DocumentController`, `ProspectionMailController`, `AccountingController` - `QuoteInvoiceService`, `InvoicePaymentService` - templates `admin/document/*`, `_quote_modal`, wizard mail Aucune migration prévue. Les invariants une facture par devis, une convention active et PDF figés restent inchangés. --- ## 14. Fiches techniques et plans de scène ### Constats Le cycle métier est clair. En revanche, la gestion mêle modèles, paramètres et plans dans l’écran Fiches techniques. Le wizard embarqué dans la prospection peut contenir six étapes et un éditeur graphique. L’éditeur repose sur drag/drop, pointeur, menu contextuel et raccourcis clavier ; certaines fonctions sont difficilement découvrables au tactile. ### Proposition - Séparer visuellement **Documents techniques** et **Configuration technique**. - Dans une prospection, proposer d’abord : - « Associer la fiche standard » — action rapide mobile ; - « Personnaliser » — parcours avancé ; - « Créer une fiche spécifique » — parcours avancé. - Afficher clairement l’état actuel et la prochaine transition autorisée ; les autres dans un menu. - Remplacer les `prompt()` de refus/remplacement par un formulaire. - Sur mobile, rendre excellent le choix d’un modèle, l’association, l’envoi, la validation, le refus et le remplacement. - Pour l’éditeur graphique : interface tablette/desktop privilégiée, contrôles tactiles explicites (ajouter, sélectionner, déplacer, taille, rotation, dupliquer, supprimer), sans dépendre du clic droit ni du clavier. Une vue paysage peut être suggérée. ### Alternative nécessitant décision Optimiser intégralement l’éditeur graphique pour une main sur petit téléphone demanderait un chantier spécialisé important. La recommandation est de garantir sa fonctionnalité tactile en paysage, tout en réservant l’expérience « une main » aux actions techniques courantes. ### Impact - `TechnicalController`, `TechnicalSheetService`, `TechnicalSheetWorkflowService` - templates `admin/technical/*` et `admin/prospection/_technical_sheet_modal.html.twig` - `public/js/technical-wizard.js`, `prospection-technical-wizard.js`, `stage-plan-editor.js` - CSS de l’éditeur Aucune migration attendue. --- ## 15. GED générale et GED comptable ### Constats La bibliothèque générale expose dix colonnes. La GED comptable utilise une arborescence avec recherche et dépliage. Les métadonnées de document sont nombreuses et les notions Public/Presse/Admin/Projets sont techniques pour un novice. ### Proposition - Bibliothèque : recherche dominante, filtres Type/Projet/Accès/État, cartes mobile. - Libellés explicatifs : « Visible sur le site public », « Disponible dans l’espace presse », « Réservé au back-office ». - Résumé humain de portée : « Tous les projets » ou liste de projets ; ne pas exposer seulement des badges techniques. - Actions secondaires dans un menu ; voir/télécharger restent visibles. - GED comptable : recherche collante, filtres année/mois/catégorie, dossiers en cartes sur mobile et fil d’Ariane. - Formulaire d’ajout de pièce en plein écran mobile avec catégorie et période expliquées ; conserver le classement automatique. Les politiques `DocumentAccessPolicy`, `AccountingProjectScope` et `availableProjects` restent la source d’autorisation. Aucune portée ne doit être reconstruite en JavaScript. Aucune migration. --- ## 16. Comptabilité ### Constats La synthèse est pertinente, mais les écrans de saisie reposent sur des tableaux et modales longues. La dépense demande date, libellé, fournisseur, catégorie, quatre valeurs de montant/TVA, projet, compte, mode, date de paiement, justificatif et notes. Les champs financiers sont tous présentés simultanément. ### Proposition - Dashboard comptable : alertes et actions d’abord, agrégats ensuite, mouvements récents en cartes mobile. - Dépense : parcours mobile en blocs : 1. pièce justificative (photo/fichier) ; 2. date, fournisseur, libellé ; 3. montant avec choix explicite « je connais le TTC » / « je connais le HT » ; 4. catégorie, projet, compte et paiement ; 5. vérification. - Utiliser `capture="environment"` comme aide facultative pour photographier un justificatif, tout en conservant le sélecteur de fichier. - Valeurs par défaut raisonnables : date du jour, dernier compte/mode seulement si cette préférence est sûre et personnelle ; ne pas imposer un projet par simple contexte comptable. - Recette/merch/contrat : cartes mobile et formulaire plein écran ; masquer les champs non pertinents selon la nature choisie. - Un composant paiement unique dans toute l’application. ### Risques - Calcul TVA ou précision monétaire ; ne pas déplacer un calcul sensible uniquement côté client. - Mauvaise affectation projet ; toujours charger les projets autorisés depuis le serveur. - Justificatif perdu lors d’une erreur ; afficher l’erreur avant de vider le formulaire. - Données personnelles/confidentielles dans une persistance navigateur ; à éviter. ### Fichiers `AccountingController`, `AccountingCalendarManager`, `AccountingDocumentManager`, `AccountingProjectScope`, `InvoicePaymentService`, templates `admin/accounting/*`. Aucune migration prévue. --- ## 17. Paramétrage ### Constats Le paramétrage est dispersé dans de nombreuses entrées du menu. Certains écrans sont des matrices ou des tables éditables très larges. Le wizard de projet contient onze tableaux et jusqu’à 116 contrôles/boutons. ### Proposition - Une page **Paramètres** servant de catalogue, organisée par audience : - Projet actif : identité, tarifs, frais, technique, scène, site/communications ; - Association : identité, devis/factures, conventions, comptabilité ; - Référentiels : statuts, types de lieu/contact, canaux, priorités ; - Accès et sécurité : utilisateurs, groupes, connexion, maintenance. - Afficher description, niveau de risque et dernier état (« configuré », « à compléter »). - Les référentiels deviennent un écran à onglets plutôt que cinq destinations indépendantes. - Les actions rares et dangereuses restent séparées et jamais placées près de l’action courante. - Sur mobile, les grandes matrices de permissions et les tableaux techniques sont consultables, mais l’édition complexe peut proposer un mode « modifier ce groupe » vertical plutôt qu’une matrice horizontale. ### Impact Principalement `templates/admin/layout.html.twig`, `templates/admin/settings/*`, `lookup`, `permission_group`, `artistic_project/wizard` et leurs contrôleurs. Aucun changement de permission ni migration. --- ## 18. Utilisateurs et permissions ### Constats La page affiche correctement l’avertissement sur les comptes back-office sans projet. La création/modification se fait en modale avec identité, rôle, groupes, projets et super-admin simultanément. Les boutons d’actions sont surtout iconographiques. ### Proposition - Formulaire en deux niveaux : identité/type de compte, puis accès métier. - Choisir « Presse uniquement » masque les groupes/projets back-office non pertinents ; choisir Back-office rend au moins un projet explicitement requis. - Résumé avant validation : « Cet utilisateur pourra accéder à… ». - Afficher les permissions effectives calculées d’un utilisateur sans rendre la matrice globale nécessaire. - Sur mobile, édition en page/panneau plein écran, pas petite modale. Les contrôles serveur de `UserAdminController` et `BackOfficeAccessSubscriber` restent obligatoires. L’interface ne doit jamais être la seule protection. --- ## 19. Composants transversaux à créer ou harmoniser 1. `PageHeader` Twig : titre, contexte, action principale, menu secondaire. 2. `ResponsiveEntityList` : table desktop + cartes smartphone partageant les mêmes données. 3. `ActionMenu` : action principale textuelle + menu secondaire accessible. 4. `StatusBadge` avec libellé et icône, pas couleur seule. 5. `BottomActionBar` mobile. 6. `FormSection` / « Options avancées ». 7. `AsyncPanel` pour drawer/modal chargé à la demande avec repli serveur. 8. `FeedbackRegion` : message inline/toast accessible et erreurs de formulaire. 9. `PaymentForm` partagé. 10. `ProspectionActionForm` partagé, piloté par les transitions autorisées côté serveur. 11. `EmptyState` avec action pertinente. 12. aide contextuelle par page, liée à la section correspondante du manuel. Ces composants restent des partials Twig et du JavaScript natif/Bootstrap ; aucune bibliothèque structurante supplémentaire n’est requise. --- ## 20. Priorisation ### A — gains UX majeurs / priorité élevée - fondations mobile : barre inférieure, zones tactiles, action globale Saisir ; - nouvelle navigation et page Paramètres ; - parcours Saisie terrain ; - dashboard orienté actions ; - « À traiter » actionnable ; - listes Prospections/Lieux/Dates en cartes mobile ; - fiche prospection hiérarchisée et actions contextuelles ; - création de lieu/contact dans le contexte courant ; - cohérence des boutons avec les permissions ; - suppression des modales massivement pré-rendues et chargement contextuel ; - remplacement des `prompt()`/actions iconographiques critiques. ### B — améliorations importantes mais secondaires - création de date simplifiée ; - simulateur avec résumé mobile et retour contextuel ; - génération/envoi de devis guidés ; - composant paiement partagé ; - formulaires comptables progressifs ; - GED et bibliothèque en cartes/filtres ; - fiche technique standard rapide et wizard avancé plein écran ; - aide contextuelle et manuel mieux accessible ; - pagination/recherche serveur des listes volumineuses. ### C — confort / polish - conservation des filtres et onglets lors des retours ; - micro-animations discrètes et skeletons de chargement ; - préférences d’affichage personnelles non sensibles ; - raccourcis clavier desktop documentés ; - états vides enrichis ; - harmonisation fine des libellés, espacements et icônes ; - auto-focus et sélection intelligente supplémentaires. --- ## 21. Plan d’implémentation proposé ### Lot 0 — Référence visuelle et garde-fous - démarrer l’application dans l’environnement Docker prévu ; - créer un jeu de comptes de test par profil et données représentatives ; - capturer les écrans actuels desktop/tablette/mobile ; - écrire la matrice des parcours critiques et des permissions ; - confirmer les arbitrages de la section 22. **Commit proposé :** `test(ux): add back-office journey and viewport baseline` ### Lot 1 — Fondations d’interface et accessibilité - tokens de taille/espacement/touch ; - composants PageHeader, ActionMenu, FeedbackRegion, BottomActionBar ; - libellés accessibles, focus, erreurs ; - aucun changement de parcours métier. **Commits :** 1. `feat(ui): add responsive back-office primitives` 2. `fix(a11y): normalize labels focus and touch targets` ### Lot 2 — Navigation - navigation raccourcie et groupes ; - bottom navigation mobile ; - page Paramètres ; - sélecteur de projet compact ; - contrôle par profils de permission. **Commits :** 3. `feat(nav): reorganize permission-aware desktop navigation` 4. `feat(nav): add mobile bottom navigation and quick actions` 5. `feat(settings): add unified settings entry page` ### Lot 3 — Saisie terrain - recherche de lieux/contacts ; - UI mobile ; - DTO et service transactionnel ; - création minimale et choix d’intention ; - unicité prospection active et permissions ; - tests unitaires/intégration. **Commits :** 6. `feat(field-capture): add scoped venue and contact search` 7. `feat(field-capture): orchestrate transactional quick capture` 8. `feat(field-capture): add one-handed mobile workflow` 9. `test(field-capture): cover permissions duplicates and workflows` ### Lot 4 — Pilotage quotidien - dashboard Aujourd’hui ; - suggestions limitées/lazy ; - À traiter en groupes et cartes ; - composants d’action partagés. **Commits :** 10. `feat(dashboard): prioritize daily operational actions` 11. `feat(tasks): add actionable responsive task cards` 12. `perf(dashboard): bound suggestions and lazy-load secondary panels` ### Lot 5 — Prospection et lieux - listes responsives ; - formulaire de prospection progressif ; - fiche prospection à sections ; - actions contextualisées ; - fiche lieu/drawer et contacts contextuels ; - wizard mail mobile. **Commits :** 13. `feat(prospection): redesign responsive list and filters` 14. `feat(prospection): simplify create and edit forms` 15. `feat(prospection): prioritize workflow actions in dossier view` 16. `feat(venues): add contextual venue and contact workspace` 17. `feat(mail): improve mobile prospection sending flow` ### Lot 6 — Dates - liste/cartes ; - action menu ; - création simplifiée sans modale imbriquée ; - formulaires d’annulation/publication accessibles. **Commits :** 18. `feat(dates): add responsive planning views and actions` 19. `feat(dates): simplify concert creation workflow` ### Lot 7 — Commercial - simulateur ; - génération devis mobile ; - suite Générer → Envoyer ; - paiement partagé ; - conventions. **Commits :** 20. `feat(simulator): add mobile summary and contextual handoff` 21. `feat(commercial): simplify quote and invoice interactions` 22. `refactor(payment-ui): share payment form across workflows` 23. `feat(conventions): improve responsive archive workflow` ### Lot 8 — Production technique - distinction documents/configuration ; - association rapide ; - wizard avancé plein écran ; - contrôles tactiles du plan ; - transitions d’état accessibles. **Commits :** 24. `feat(technical): prioritize standard technical sheet workflow` 25. `feat(technical): improve advanced wizard responsiveness` 26. `feat(stage-plan): add explicit touch controls` ### Lot 9 — GED et comptabilité - bibliothèque responsive ; - GED comptable mobile ; - formulaires progressifs ; - maintien strict de la portée projet. **Commits :** 27. `feat(documents): add responsive scoped library views` 28. `feat(accounting): redesign responsive accounting lists` 29. `feat(accounting): simplify mobile expense and income entry` ### Lot 10 — Administration, documentation et validation finale - utilisateurs/groupes ; - aide contextuelle ; - manuel utilisateur ; - spécifications, CHANGELOG ; - batterie complète de validations. **Commits :** 30. `feat(admin): simplify user and permission management` 31. `docs: update dashboard manual for redesigned workflows` 32. `docs: align functional specifications and changelog` 33. `test(ux): complete browser and permission regression coverage` Les lots 7, 8 et 9 peuvent être développés en parallèle conceptuellement après les lots 1–2, mais ils ne doivent pas être fusionnés avant la stabilisation des composants transversaux. Les lots 3–6 doivent suivre cet ordre afin que le parcours terrain réutilise la nouvelle navigation et que la fiche prospection fournisse les actions communes aux tâches et aux dates. --- ## 22. Arbitrages nécessaires avant implémentation ### Décision 1 — Intention par défaut de la saisie terrain **Recommandation :** afficher trois choix explicites et présélectionner « Premier échange réalisé maintenant » uniquement lorsque l’utilisateur a ouvert l’action nommée « Nouveau contact terrain ». Ne jamais considérer automatiquement la seule création d’une fiche comme un contact commercial. À valider : le choix présélectionné doit-il être celui-ci, ou « Enregistrer seulement » ? ### Décision 2 — Données minimales du contact **Recommandation :** autoriser un lieu sans contact ; si un contact est ajouté, exiger son nom et au moins un moyen de contact (téléphone ou e-mail). Cette règle est plus claire que le comportement actuel qui peut créer un contact nommé automatiquement « Contact principal ». À valider : faut-il conserver la possibilité d’enregistrer un contact sans nom lorsque seul un numéro/e-mail est connu ? ### Décision 3 — Gestion des doublons de lieux **Recommandation :** - correspondance exacte normalisée nom + ville : bloquer la création et proposer le lieu existant, avec action exceptionnelle « Créer quand même » après avertissement ; - correspondance approchée : avertissement non bloquant ; - SIRET identique : blocage fort. À valider : qui peut forcer la création malgré une correspondance exacte ? Tout utilisateur avec écriture Lieux, ou seulement le super-admin ? ### Décision 4 — Navigation mobile **Recommandation :** barre inférieure `Accueil · À traiter · Saisir · Prospections · Plus`, complétée par le projet actif dans l’en-tête. À valider : les Dates doivent-elles remplacer Prospections dans cette barre pour certains profils, ou la barre doit-elle rester identique et seulement masquer les entrées interdites ? ### Décision 5 — Portée mobile de l’éditeur de plan **Recommandation :** actions courantes excellentes sur smartphone ; éditeur graphique pleinement tactile mais optimisé en paysage/tablette/desktop, sans promesse « une main ». À valider : faut-il investir dans une expérience d’édition graphique complète en portrait sur petit téléphone ? ### Décision 6 — Terminologie « GED » **Recommandation :** afficher « Documents comptables » dans la navigation novice et conserver « GED comptable » comme sous-titre/aide. De même, « Bibliothèque documentaire » peut devenir « Documents ». Cette évolution de vocabulaire doit être explicitement validée conformément à `AGENTS.md`. ### Décision 7 — Usage sans réseau **Recommandation :** ne pas inclure de mode offline dans ce chantier ; garantir en revanche la conservation visuelle des champs lors d’un échec réseau et un bouton Réessayer. Une PWA offline implique stockage local de données personnelles, synchronisation, conflits et sécurité : chantier séparé. À valider : une connexion réseau peut-elle être considérée comme disponible lors de la saisie terrain ? --- ## 23. Sécurité et non-régression Chaque lot devra vérifier : - permissions de lecture/écriture/suppression dans l’interface **et** côté serveur ; - projet issu du contexte autorisé, jamais d’un `project_id` client non vérifié ; - rechargement serveur des `venue_id`, `contact_id`, `template_id`, `profile_id`, document et facture ; - CSRF pour toute mutation, y compris requête asynchrone ; - échappement des contenus injectés dans les panneaux et cartes ; éviter `innerHTML` avec données non échappées ; - absence de redirection ouverte via le contexte de retour ; - invariant d’une prospection active par projet + lieu ; - workflow monotone et états terminaux ; - report consommé uniquement par une vraie action ; - transaction et événements d’historique ; - Calendar après transaction locale ; - portée GED et comptable inchangée ; - fichiers uploadés validés comme aujourd’hui ; - aucune donnée sensible dans `localStorage` ou logs ; - aucun nouveau domaine CSP sans nécessité validée. Les composants asynchrones doivent répondre par erreurs structurées mais compréhensibles, sans trace interne. Une erreur secondaire ne doit pas effacer le formulaire ni produire un état métier partiel. --- ## 24. Plan de validation ### 24.1 Contrôles automatiques par lot - `php -l` sur les fichiers PHP modifiés ; - `php bin/console lint:container` ; - `php bin/console lint:twig templates` ; - `php bin/console debug:router` ; - PHPUnit existant ; - tests ciblés nouveaux : service de saisie terrain, recherche/scoping, unicité, permissions, transitions, retour contextuel ; - tests contrôleur avec utilisateurs aux permissions différentes ; - absence de modification Doctrine attendue : `doctrine:schema:validate` et `doctrine:schema:update --dump-sql` doivent rester propres ; - cache clear/warmup. ### 24.2 Matrice navigateur Navigateurs : Chrome/Edge desktop, Firefox desktop, Safari iOS réel si disponible, Chrome Android réel ou émulation complétée par appareil réel. Viewports minimaux : - 1440 × 900 ; - 1024 × 768 ; - 768 × 1024 ; - 390 × 844 ; - 360 × 800. Vérifier portrait et paysage pour dates, fiches techniques et plan de scène. ### 24.3 Profils - super-admin ; - administrateur projet ; - prospecteur ; - technique ; - trésorier ; - lecture seule ; - utilisateur multi-projets ; - utilisateur ne disposant que d’une partie des permissions concernées. ### 24.4 Scénarios essentiels 1. changer de projet et vérifier tout le menu/contexte ; 2. ouvrir chaque destination depuis desktop et mobile ; 3. saisie terrain : lieu existant, nouveau lieu, contact existant, nouveau contact, sans contact ; 4. conflit de prospection active et double soumission ; 5. premier contact réel vs simple enregistrement ; 6. tâche en retard → action → recalcul immédiat ; 7. prospection lecture seule : aucune action d’écriture visible ; 8. accord sans date, programmation, annulation, reprogrammation ; 9. création/modification date et échec Calendar ; 10. génération devis puis envoi réussi/échoué ; 11. facture unique et paiements partiels ; 12. archivage/restauration convention ; 13. fiche technique standard, personnalisée, transitions ; 14. document étranger au projet inaccessible par URL/panneau ; 15. dépense avec justificatif depuis caméra/fichier ; 16. formulaires avec clavier mobile, rotation, zoom 200 %, navigation clavier ; 17. messages d’erreur, focus, retour arrière et conservation du contexte ; 18. CSP : Bootstrap, DataTables, Select2, CKEditor, Calendar/Analytics et login restent fonctionnels. ### 24.5 Critère mesuré de saisie terrain Chronométrer au moins cinq essais sur appareil réel. Cible médiane : moins de 60 secondes pour nouveau lieu + contact + premier contact/prospection, sans erreur et sans aide externe. --- ## 25. Documentation à mettre à jour pendant l’implémentation - `SPECIFICATIONS_FONCTIONNELLES.md` : navigation cible, saisie terrain, comportements d’interface sans réécrire les règles métier. - Manuel utilisateur du dashboard : nouveau menu, saisie terrain pas à pas, cartes/listes, actions contextuelles, mobile, options avancées. - `CHANGELOG.md` : chaque lot visible. - `demarrage_rapide.md` uniquement si dépendance, asset local ou procédure de validation change. - `AGENTS.md` seulement si un invariant durable est validé, par exemple une convention structurelle de composants responsives ; aucune mise à jour n’est nécessaire pour de simples choix visuels. - Les README historiques restent inchangés. --- ## 26. Conclusion La refonte recommandée conserve l’architecture métier et technique actuelle. Le gain principal vient d’une meilleure hiérarchie, d’une interaction mobile dédiée et de la réutilisation de composants transversaux, pas d’un changement de framework. Le premier incrément à forte valeur est le trio **navigation mobile + saisie terrain + pilotage quotidien**. Il répond directement à l’usage en déplacement et fournit les composants réutilisables pour simplifier ensuite prospections, dates, documents, technique et comptabilité. L’implémentation ne doit commencer qu’après validation des sept décisions de la section 22 et du découpage proposé.