# Rapport intermédiaire — refonte UX/UI lots 0 à 6

Date du point de stabilisation : 17 septembre 2026  
Branche : `feature/backoffice-ux-mobile-lots-0-6`  
Base de production : `ab202db`

## Périmètre livré

Le développement s'arrête volontairement après le lot 6. Les lots 7 à 10 ne sont pas commencés.

| Lot | Résultat livré |
|---|---|
| 0 — Référence et garde-fous | Matrice de recette desktop, tablette et mobile ; profils et scénarios de non-régression |
| 1 — Fondations UI/accessibilité | Composants communs, focus visible, lien d'évitement, annonces de résultat, cibles tactiles, états vides et actions adaptées au mobile |
| 2 — Navigation | Menu desktop regroupé, sélecteur de projet compact, hub de paramétrage et barre mobile stable `Accueil · À traiter · Saisir · Prospections · Plus` |
| 3 — Saisie terrain | Parcours transactionnel lieu + contact + prospection, trois intentions explicites, doublons gradués, permissions serveur et reprise après erreur |
| 4 — Pilotage quotidien | Bloc « Aujourd'hui » prioritaire et page « À traiter » sous forme de cartes actionnables sur smartphone |
| 5 — Prospection et lieux | Listes en cartes mobiles, actions contextuelles, informations avancées repliées, fiche lieu dédiée et validation du contact minimal |
| 6 — Dates | Création sur page dédiée sans modale imbriquée, options avancées progressives, cartes mobiles, actions regroupées et annulation accessible |

## Arbitrages appliqués

- **Premier échange réalisé maintenant** est présélectionné uniquement dans **Nouveau contact terrain** ; les trois intentions restent visibles et modifiables.
- Un lieu peut exister sans contact. Un nouveau contact requiert un nom et un téléphone ou un e-mail. Aucun faux contact n'est créé.
- Le SIRET identique bloque ; nom + ville identiques avertissent et permettent une création forcée autorisée ; la similarité approchée avertit sans bloquer.
- La navigation mobile ne substitue jamais **Dates** à **Prospections**. Les entrées interdites sont masquées.
- L'interface emploie **Documents** et **Documents comptables** ; les noms techniques internes restent inchangés.
- Aucune fonction hors ligne n'est ajoutée. Une erreur réseau conserve le formulaire en mémoire de page, sans données personnelles dans `localStorage`.
- Les entités, statuts, permissions, isolations de projet et workflows métier existants sont réutilisés sans nouvelle architecture parallèle.

## Sécurité et non-régression

- Les routes restent protégées par la matrice de permissions côté serveur ; le masquage visuel n'est jamais le seul contrôle.
- Le projet de la saisie terrain vient du contexte serveur et non d'un identifiant soumis par le client.
- Les identifiants de lieu et de contact sont revérifiés ; un contact sélectionné doit appartenir au lieu choisi.
- La création terrain est transactionnelle et protégée contre la double soumission.
- L'invariant d'une seule prospection active par projet et lieu est réappliqué avant création.
- Les formulaires d'écriture utilisent les jetons CSRF existants.
- La création et les actions sur les dates conservent les services métier de workflow, de prochaine action et de synchronisation Google Calendar.
- Aucun média artistique, aucune migration, aucune entité Doctrine et aucune donnée historique n'ont été modifiés.

## Contrôles exécutés dans l'environnement de travail

- `git diff --check` : réussi après chaque bloc ;
- `node --check public/js/admin-ui.js` : réussi ;
- `node --check public/js/field-contact-capture.js` : réussi ;
- recherches statiques des anciennes modales imbriquées et du `prompt()` d'annulation des dates : aucune occurrence dans le module Dates ;
- vérification de l'absence de nouvelle migration et de modification de média : réussie.

L'environnement de travail ne fournit ni exécutable PHP ni moteur Docker. Les commandes Symfony, Doctrine, Twig et PHPUnit, ainsi que la validation visuelle dans un navigateur, ne peuvent donc pas être exécutées ici. Elles constituent la recette obligatoire du livrable et ne doivent pas être considérées comme déjà validées.

## Recette navigateur demandée

La procédure détaillée se trouve dans `docs/UX_VALIDATION_LOTS_0_6.md`. Les points bloquants de la validation intermédiaire sont :

1. tester réellement les largeurs `390×844` et `360×800`, puis tablette et desktop ;
2. parcourir la navigation avec les profils super-admin, administrateur projet, prospecteur écriture, lecture seule, Dates uniquement, multi-projets et sans accès ;
3. contrôler la console, la CSP et le chargement de Bootstrap, DataTables, Select2 et CKEditor ;
4. tester lieu existant/nouveau, avec et sans contact, et les trois intentions terrain ;
5. confirmer le blocage d'une prospection active en doublon ;
6. simuler erreur réseau et erreur serveur, puis réessayer sans ressaisie ;
7. mesurer au téléphone cinq saisies terrain et confirmer une médiane inférieure à 60 secondes ;
8. créer, modifier, publier, annuler et marquer comme jouée une date ;
9. vérifier les workflows existants de prospection et leurs permissions.

Commandes à exécuter dans l'environnement Docker de recette :

```bash
docker compose exec web php bin/console lint:container
docker compose exec web php bin/console lint:twig templates
docker compose exec web php bin/console debug:router
docker compose exec web php bin/console doctrine:schema:validate
docker compose exec web php bin/console doctrine:schema:update --dump-sql
docker compose exec web php bin/console cache:clear
docker compose exec web php bin/console cache:warmup
docker compose exec web php bin/phpunit
```

`doctrine:schema:update --dump-sql` doit rester vide.

## Points à observer avant les lots 7 à 10

- compréhension spontanée des trois intentions de saisie terrain ;
- efficacité du retour vers la création d'une date après création séparée d'un lieu ;
- densité des cartes Dates et Prospections sur un écran de 360 px ;
- facilité à trouver les actions secondaires regroupées sous **Actions** ;
- absence de perte de contexte avec un utilisateur multi-projets ;
- éventuels blocages CSP ou JavaScript invisibles aux contrôles statiques.

Toute correction issue de cette recette doit être intégrée au point de stabilisation avant d'autoriser les lots 7 à 10.

## Correctifs issus de la première recette

- Le bouton de fermeture cible maintenant explicitement le menu latéral responsive, afin que Bootstrap puisse fermer le composant `.offcanvas-lg` sans erreur JavaScript.
- Le contrôle d'unicité des prospections ignore correctement un lieu qui n'a pas encore d'identifiant Doctrine : un lieu nouvellement construit ne peut pas déjà posséder de prospection. Les contrôles SIRET, nom + ville et similarité restent exécutés avant cette étape.
- Les formulaires des modales longues restent désormais dans la surface Bootstrap : le corps défile sans découvrir l'arrière-plan et le pied reste accessible, y compris dans le wizard de fiche technique.
- Le back-office est installable comme PWA depuis `/admin`. Le service worker fonctionne exclusivement en réseau et ne met en cache aucune page ou donnée personnelle ; le mode hors ligne reste hors périmètre.

À retester en priorité : ouverture/fermeture du menu et modales longues à `390×844` et `360×800`, création terrain **Nouveau lieu + Nouveau contact + Premier échange réalisé maintenant**, puis installation et lancement de la PWA sur Android et iPhone.