27. Améliorations & Évolutions

🆕 Section prospective — à lire différemment du reste du site

Les sections §1 à §26 décrivent l'existant : le périmètre fonctionnel relevé sur recette-erp v1 et sa cible de réimplémentation v2. Cette section-ci décrit ce qui n'existe pas encore : des propositions d'évolution, chiffrées et argumentées, mais non engagées.

Toutes ses pages portent un accent ambre (au lieu de l'indigo du reste du site) pour éviter toute confusion entre « ce que fait l'outil » et « ce qu'on propose qu'il fasse ».

27.0 Origine et sources

Cette section répond à une demande d'évolution du responsable de projet (juillet 2026) et s'appuie sur quatre sources :

1. la lecture du code de recette-erp v1 ;
2. l'état réel du dépôt v2 ;
3. une étude comparative de six solutions du marché (voir Analyse du marché) ;
4. un inventaire exhaustif de 78 fonctionnalités du marché, confronté à notre existant (voir Inventaire des fonctionnalités).

📎 Addendum du 26/07/2026. Une demande complémentaire, de nature différente, a été formulée oralement le 26/07/2026 : une brique de ticketing/TMA, optionnelle et indépendante du cœur recette (voir A13). Son étude de marché est autonome — un marché différent (ticketing/ITSM, pas gestion de tests) — et ne modifie pas les six solutions retenues ci-dessus pour A1 – A12. Discussion de cadrage prévue le 27/07/2026.

27.0bis Fenêtre d'opportunité — pourquoi maintenant

À ce jour, la v2 est au stade échafaudage : la structure du projet est posée, mais aucune fonctionnalité n'est encore développée et la structure des données n'est pas encore définie.

C'est une situation qui ne se représentera pas. Toutes les évolutions décrites ici peuvent être intégrées dès la conception initiale, sans rien reprendre ensuite. C'est le moment le moins coûteux pour les trancher — et le seul où certaines (A2, A3bis, A4) ne coûtent quasiment rien.

Passé ce stade, la même décision suppose de rouvrir chaque écran et chaque traitement déjà écrit, avec un risque d'oubli à chaque endroit manqué.

État réel du dépôt.

• packages/backend/convex/schema.ts contient defineSchema({}) — schéma vide ;
• packages/backend/convex/lib/authz.ts est un squelette (ROLE_PERMISSIONS vide) ;
• apps/recette-erp/src/ ne contient que app/layout.tsx, app/page.tsx, app/providers.tsx, le handler d'authentification et lib/.

27.0ter Ce que la section contient

Page	Contenu
Analyse du marché	Comparatif TestRail / Xray / Zephyr Scale sur nos cinq axes, et ce qu'on en retient
Inventaire des fonctionnalités	Les 78 fonctionnalités recensées chez TestRail, Xray, Zephyr, qTest, PractiTest, Qase et Jira, confrontées à notre existant
A1 … A12	Une fiche par évolution : constat référencé au code, proposition, impact modèle de données, droits, statut
A13	Brique TMA (ticketing) — même gabarit, mais nature différente : module optionnel indépendant, pas un ajustement du cœur recette (voir l'addendum ci-dessus)
Non-régression & montées de version	Le sujet expliqué (quoi, pourquoi, pièges du marché) en appui de la fiche A6 — explications, exemple, problèmes réels et solutions
Perspectives	Ce qui peut suivre à moyen terme — non demandé aujourd'hui, listé pour cadrer la trajectoire

Chaque fiche suit le même gabarit : Constat (ce qui existe et pourquoi ça bloque, avec les références au code v1) → Proposition → Impact modèle → Droits → Aligné marché → À trancher.

27.5 Récapitulatif & séquencement proposé

#	Sujet	Statut	Dépendance	Effort
A4	Gestion utilisateur	🟢 prêt à spécifier	—	S
A2	Masquage / archivage de flux	🟢 prêt à spécifier	—	S
A11	Gains rapides (pré-remplissage du défaut, filtres enregistrés)	🟢 prêt à spécifier	—	S
A3	Permissivité référentiel ↔ campagnes	🟢 prêt à spécifier	arbitrage tranché (A3bis)	M
A7	Imports / Exports Excel	🟢 prêt à spécifier	— (le référentiel doit exister)	M
A9	Étapes partagées & jeux de données	🟢 prêt à spécifier	à poser avant A7 (change le gabarit d'import)	M
A6	Non-régression & montées de version	🟢 modèle prêt · 🟠 règles à cadrer	requiert A3	M
A10	Assignation & configurations d'exécution	🟢 prêt à spécifier	—	M
A8	Matrice de traçabilité	🟢 prêt à spécifier	s'appuie sur A3bis	M
A1	Dashboard hebdomadaire	🟢 prêt (hors e-mail)	cron Convex · Q16 pour l'e-mail · A10 pour la charge par testeur	M
A5	IA — génération depuis DCF / SFD	🟠 POC préalable	Q20	L
A12	Campagnes actives multiples	🟢 prêt à spécifier	requiert A3 (blocage déjà levé par A3bis)	S
A13	Brique TMA (ticketing)	🟠 à cadrer	aucune (brique indépendante) — discussion de cadrage le 27/07	L

Trois ordres à respecter (dépendances techniques réelles)

1. A3 avant A6 — l'assistant de constitution du périmètre de non-régression alimente exactement la mutation campaigns.addTestsFromReferentiel d'A3. Les deux demandes partagent la même brique.
2. A9 avant A7 — les étapes partagées et les jeux de données changent la structure du référentiel, donc les colonnes du gabarit d'import. Livrer A7 d'abord imposerait de republier un gabarit incompatible au client.
3. A10 avant le volet « charge par testeur » d'A1 — sans assignation d'exécution, le rapport User Workload de TestRail n'est calculable que a posteriori depuis test_runs.login, c'est-à-dire « qui a exécuté », pas « qui devait exécuter ».

Les quatre décisions à prendre avant d'écrire la première ligne

💡 A2 (archivage), A4 (champs utilisateur), A6 (noyau de non-régression) et surtout le modèle A3bis (périmètre de campagne) doivent être tranchés avant que la structure des données ne soit définie. Décidés maintenant, ils ne coûtent presque rien. Décidés après, ils imposent de reprendre l'ensemble de ce qui aura été développé.

Concrètement : archivedAt (A2), fonction / isActive (A4), regressionCore (A6), et les collections campaignTests + etapeResults (A3bis) dans la première version de packages/backend/convex/schema.ts. Les ajouter après l'implémentation des 7 features imposerait de reprendre chaque mutation.

27.6 Questions ouvertes

Les questions de cadrage issues de cette section (Q16 – Q39, plus Q40 – Q45 pour la brique TMA A13) sont centralisées avec les autres dans Questions pour l'atelier de cadrage ; celles déjà tranchées (Q17, Q22 – Q28) sont archivées dans Décisions actées. Les questions bloquantes y sont signalées 🔴.