A11 — Gains rapides (pré-remplissage du défaut, filtres enregistrés, édition en masse)

🆕 Évolution proposée — issue de l'inventaire marché (C38, C16, C12)

Statut : 🟢 prêt à spécifier. Aucune dépendance, aucun impact structurant sur le modèle de données. Effort faible, gain quotidien élevé — à livrer tôt.

Cette fiche regroupe trois manques du même profil : peu coûteux, sans arbitrage d'architecture, et directement ressentis par l'utilisateur à chaque session de test.

A11.1 Pré-remplissage du défaut depuis l'exécution (C38)

Constat

Quand un testeur passe une étape en KO, il ouvre la création d'anomalie et retape à la main ce que l'application connaît déjà : le flux, l'étape, le jeu de données, le résultat attendu. Coût : quelques dizaines de secondes × plusieurs centaines d'anomalies par campagne — et surtout des anomalies incomplètes quand le testeur va vite, donc des allers-retours avec le développeur.

Proposition

À la déclaration d'une anomalie depuis une étape KO, pré-remplir automatiquement :

Champ	D'où il vient
Flux et étape concernés	le contexte d'exécution
Jeu de données	l'étape (dans sa version figée si elle a déjà été jouée)
Résultat attendu	l'étape
CRIM	l'étape
Environnement / version ERP	la campagne
Preuve	la pièce jointe déjà déposée sur l'étape, si elle existe

Le testeur ne saisit plus que le résultat obtenu et la gravité — c'est-à-dire la seule information que l'application n'a pas.

Ces champs alimentent directement l'export « dev » d'A7 : une anomalie pré-remplie est une anomalie exploitable par le développeur sans relance.

A11.2 Filtres et recherches enregistrés (C16)

Constat

Les écrans Synthèse et Anomalies ont des filtres, mais rien n'est mémorisé : chaque utilisateur reconstruit le même filtrage à chaque ouverture (« mon module », « anomalies bloquantes ouvertes », « flux KO non rejoués »).

Proposition

• Enregistrer une combinaison de filtres sous un nom, par utilisateur.
• Partager une vue enregistrée avec l'équipe (portée organisation ou projet).
• Une vue par défaut au chargement de l'écran.

Aucun impact sur les données métier : une vue enregistrée est une préférence d'affichage, pas une donnée de recette.

Collection savedViews (userId, scope, nom, ecran, criteres, isShared).

A11.3 Édition en masse (C12)

Constat

Seul le réordonnancement est possible en masse (moveTest, moveEtape…). Changer le statut de 40 flux de « À rédiger » à « Validé », ou les réaffecter à un autre scénario, se fait un par un.

Proposition

Sélection multiple dans l'arbre + actions groupées : changer le statut, déplacer, archiver (A2), assigner (A10), ajouter au périmètre d'une campagne (A3).

⚠️ À prévoir dès la maquette : une action groupée sur un grand nombre d'éléments n'est pas instantanée et se déroule par lots. L'écran doit afficher une progression et un compte rendu (X modifiés, Y en échec), jamais faire croire à une opération atomique immédiate.

Une mutation Convex écrit au plus 16 000 documents en 1 s de code utilisateur. Découper en lots côté client, ou déporter dans une action qui enchaîne des mutations successives.

Toute action groupée est journalisée comme une action unitaire (qui, quand, combien d'éléments) — sinon la piste d'audit devient inexploitable après un import ou une reprise.

Droits

Action	Rôles
Pré-remplissage du défaut	hérite des droits de déclaration d'anomalie (admin + consultant + testeur)
Vues enregistrées personnelles	tous les rôles authentifiés
Partage d'une vue à l'équipe	admin + consultant
Édition en masse	admin + consultant (chaque action groupée respecte en outre les droits de l'action unitaire)

Aligné marché

Pré-remplissage du défaut depuis un test en échec (TestRail : « pousser un défaut vers Jira avec les détails pré-remplis »), filtres et recherches enregistrés (TestRail, PractiTest), édition en masse (tous).

À trancher

• Les vues enregistrées sont-elles personnelles seulement en première version ? (le partage suppose une notion de portée — organisation ? projet ? — à aligner avec Q11)
• Le pré-remplissage est-il modifiable par le testeur avant enregistrement ? Recommandation : oui — sinon il ment dès que le contexte réel diffère.