A1 — Dashboard hebdomadaire

🆕 Évolution proposée — n'existe ni en v1 ni dans la v2 spécifiée

Statut : 🟢 prêt à spécifier, hors canal e-mail (dépend de Q16).

En une phrase

L'application sait dire où on en est aujourd'hui, mais elle est incapable de dire si ça avance. La proposition : figer chaque semaine une photo des indicateurs, pour obtenir enfin une courbe de tendance et un point d'avancement diffusable.

Constat

Toutes les mesures actuelles sont instantanées : le taux d'avancement, la ventilation par métier, le comptage d'anomalies. Aucune n'est datée, aucune n'est conservée. Fermer une semaine et comparer à la précédente est impossible — il faudrait avoir pensé à exporter un Excel chaque vendredi.

Les seules données réellement horodatées sont le journal d'exécution et la date de création des anomalies.

Et §19 est explicite : aucune tâche planifiée, aucun traitement automatique de fond n'existe en v1 — il n'y a rien pour déclencher un figeage hebdomadaire.

Références au code v1. utils/coverage.js est la source unique de calcul : coverageOf() renvoie total / done / pct / ok / ko / nt / blq ; computeCoverage() y ajoute la ventilation par métier et le comptage d'anomalies bloquantes. Les données datées exploitables sont test_runs (groupée par test / campagne / date / login via appendJournal, RG-16) et anomalies.date_creation.

Proposition

Deux livrables

1. Écran « Tableau de bord » — consolidé projet + détail de la campagne active.
2. Instantané hebdomadaire persisté — une collection weeklyReports figée automatiquement chaque lundi 06:00 par un cron Convex, natif à la stack v2 là où la v1 n'avait aucun ordonnanceur.

Métriques retenues

Toutes calculables depuis l'existant, sans nouvelle saisie :

Famille	Indicateur	Source
Avancement	% d'étapes faites (OK+KO / total) — et Δ en points vs semaine N-1	etapes + coverageOf
Avancement	Flux entièrement exécutés / flux du périmètre	etapes groupées par testId
Volume	Étapes exécutées dans la semaine	test_runs (date)
Qualité	Anomalies ouvertes par gravité (Bloquant / Majeur / Gênant)	anomalies
Qualité	Anomalies créées vs fermées dans la semaine ; âge moyen des bloquantes	anomalies.date_creation + statut
Risque	Modules à 0 % d'avancement ; flux KO non rejoués ; flux encore « À rédiger »	etapes, tests.statut
Charge	Exécutions par testeur (inspiré du rapport User (Test Execution) Workload de TestRail)	test_runs.login

⚠️ La ligne Charge mesure « qui a exécuté », pas « qui devait exécuter ». Le rapport de charge prévisionnelle (le vrai User Workload de TestRail) suppose l'assignation d'exécution décrite en A10. A10 est donc un prérequis du volet charge d'A1, pas des six autres familles.

Formats

• Écran web — source de vérité.
• Feuille supplémentaire dans l'export Excel existant (F11), cohérent avec le livrable projet actuel.
• Envoi hebdomadaire par e-mail, en option.

Fréquence

Figeage hebdomadaire, consultation continue. La conservation des instantanés permet une courbe de tendance multi-semaines, aujourd'hui impossible.

Impact

Rien de ce qui existe n'est modifié. On ajoute uniquement un nouvel objet : la photo hebdomadaire (période, projet, campagne, indicateurs, date de figeage). Les campagnes, flux et anomalies restent inchangés.

Nouvelle collection weeklyReports. Aucune modification des collections existantes.

💡 Ce choix n'est pas seulement fonctionnel. Convex est une base transactionnelle, pas analytique : il n'existe ni count() ni projection de champ, et une transaction lit au plus 32 000 documents en 1 seconde de code utilisateur. Pré-agréger dans weeklyReports au lieu de recalculer à chaque affichage est la parade recommandée à cette limite, pas une optimisation prématurée. Le composant @convex-dev/aggregate (agrégats maintenus transactionnellement) est le renfort si des compteurs temps réel deviennent nécessaires. Voir Exigences non-fonctionnelles § 14.1.

Droits

Lecture : tous les rôles authentifiés. Le figeage hebdomadaire n'est déclenchable par personne depuis l'interface — c'est un traitement automatique, ce qui garantit qu'une photo ne peut pas être refaite après coup.

Concrètement : internalMutation déclenchée par un cron Convex, non exposée au client.

Aligné marché

TestRail : rapports générables immédiatement, sur appel API ou sur planification récurrente, avec envoi par e-mail ; plus de 70 rapports prédéfinis. Zephyr Scale : plus de 30 rapports + gadgets Jira. Le reporting planifié et diffusé est un standard, pas un luxe.

À trancher

Réserve principale — l'envoi e-mail suppose un fournisseur d'envoi transactionnel, absent de la v1 comme de la v2 (§16) → Q16. L'écran et l'export, eux, sont spécifiables en l'état.

Le même prérequis technique conditionne les notifications métier (Q15) : une seule décision d'infrastructure débloque les deux sujets.