# Validation UX — lots 0 à 6

Ce document est la référence de recette intermédiaire de la refonte du back-office.
Il ne remplace ni les spécifications fonctionnelles ni le manuel utilisateur.

## Périmètre du point de stabilisation

- fondations visuelles, tactiles et accessibles ;
- navigation desktop et navigation mobile stable ;
- parcours « Nouveau contact terrain » ;
- tableau de bord et page « À traiter » ;
- prospections, lieux et contacts ;
- dates de concert.

Les simulateurs, documents commerciaux, conventions, fiches techniques, plans de scène,
documents génériques, comptabilité et administration détaillée restent fonctionnellement
inchangés avant les lots 7 à 10.

## Viewports de référence

| Cible | Dimensions | Attendu principal |
|---|---:|---|
| Desktop | 1440 × 900 | Navigation latérale, contenu sans chevauchement |
| Petit desktop/tablette paysage | 1024 × 768 | Navigation et formulaires utilisables sans zoom |
| Tablette portrait | 768 × 1024 | Cartes ou tableaux maîtrisés, actions tactiles |
| Smartphone | 390 × 844 | Barre inférieure, action principale accessible au pouce |
| Petit smartphone | 360 × 800 | Aucun débordement horizontal de page |

Tester aussi le paysage sur smartphone pour les dates et les écrans denses.

## Profils à préparer

1. super-administrateur ;
2. administrateur de projet ;
3. prospecteur avec écriture Prospections et Lieux & contacts ;
4. prospecteur en lecture seule ;
5. utilisateur Dates uniquement ;
6. utilisateur multi-projets ;
7. utilisateur sans accès aux modules concernés.

La structure de la barre mobile reste `Accueil · À traiter · Saisir · Prospections · Plus`.
Une entrée interdite est masquée : elle n'est jamais remplacée par une autre entrée.

## Parcours de non-régression

### Navigation et sécurité

- changer de projet et vérifier que le contexte est conservé sur chaque destination ;
- vérifier chaque entrée avec les sept profils ;
- tenter les URL directes sans permission ;
- vérifier que le menu ne révèle pas une fonction interdite ;
- contrôler le focus clavier, le bouton d'évitement et l'annonce des messages flash.

### Nouveau contact terrain

- retrouver un lieu existant et sélectionner un contact existant ;
- retrouver un lieu existant et créer un contact ;
- créer un lieu sans contact ;
- créer un lieu avec un contact nommé et téléphone uniquement ;
- créer un lieu avec un contact nommé et e-mail uniquement ;
- refuser un contact sans nom ou sans téléphone/e-mail ;
- bloquer un SIRET identique et proposer le lieu existant ;
- avertir fortement sur nom + ville identiques, puis tester « Créer quand même » ;
- avertir sans bloquer sur une correspondance approchée ;
- vérifier les trois intentions : lieu/contact seuls, prospection à contacter, premier échange réalisé ;
- vérifier que « Premier échange réalisé maintenant » est présélectionné uniquement ici ;
- refuser la création d'une seconde prospection active pour le même projet et le même lieu ;
- double-cliquer sur Enregistrer : une seule opération doit être créée ;
- provoquer une erreur réseau/serveur et vérifier que les champs restent affichés ;
- contrôler que le projet vient du contexte serveur et qu'aucun identifiant client ne contourne les permissions.

### Pilotage, prospections et dates

- agir depuis une tâche en retard et constater le recalcul métier existant ;
- parcourir la liste et la fiche d'une prospection sur les cinq viewports ;
- vérifier qu'un profil en lecture seule ne voit aucune action d'écriture ;
- créer puis modifier une date sans modale imbriquée ;
- annuler, reprogrammer, publier/masquer et marquer comme jouée selon le workflow courant ;
- vérifier les messages d'échec Calendar sans perte de données ;
- vérifier que le site public et les médias artistiques ne sont pas modifiés.

## Mesure du parcours terrain

Sur un téléphone réel, chronométrer au moins cinq essais avec un utilisateur connaissant le
métier mais pas l'écran. La cible est une médiane inférieure à 60 secondes pour créer un
nouveau lieu, son contact et une prospection avec premier échange réalisé, sans aide externe.

Noter pour chaque essai : durée, hésitations, erreurs, champs abandonnés et utilisation du
bouton Retour. Une validation technique seule ne valide pas ce critère.

## Contrôles techniques attendus au point de stabilisation

```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
```

Le résultat de `doctrine:schema:update --dump-sql` doit rester vide : aucun changement de
modèle ou migration n'est prévu dans les lots 0 à 6.

## Contrôle CSP et JavaScript

Ouvrir la console du navigateur et contrôler l'absence d'erreur ou de ressource bloquée sur :

- login ;
- dashboard ;
- listes Prospections, Lieux et Dates ;
- formulaire de prospection ;
- saisie terrain ;
- écran de création/modification d'une date ;
- Select2, DataTables, Bootstrap et CKEditor sur une page qui les utilise encore.