A12 — Plusieurs campagnes actives en parallèle

🆕 Évolution proposée

Statut : 🟢 prêt à spécifier. Le blocage technique est déjà levé par A3bis — cette évolution est surtout une règle d'état + un point d'UX, pas un chantier de fond. Prérequis : A3 (modèle association + gel ciblé).

En une phrase

Aujourd'hui, une seule campagne peut être active à la fois par projet : activer la campagne B désactive automatiquement la campagne A. La demande : pouvoir mener plusieurs campagnes en parallèle — par exemple une SAT en cours pendant qu'on lance la non-régression d'une montée de version.

Constat — la limite actuelle et d'où elle vient

Le modèle v1 pose une contrainte forte : « une seule campagne active par (organisation, projet) » (F7 — Campagnes, Référentiel & Snapshots). « Active » veut dire la seule campagne où l'on peut saisir des résultats : plan de référence et campagnes désactivées sont en lecture seule.

Pourquoi cette limite existe : elle est un héritage du modèle snapshot. En v1, activer une campagne = créer la photographie inscriptible ; il ne pouvait y en avoir qu'une parce que « active » et « cible d'écriture » étaient le même concept. À la première activation, toute autre campagne active du même projet est désactivée d'office.

Ce que ça donne sur le terrain. L'équipe recette fait tourner une campagne SAT sur l'environnement UAT. L'éditeur livre une montée de version, il faut lancer la non-régression. Aujourd'hui : activer la campagne de non-régression coupe la saisie de la SAT — les testeurs SAT ne peuvent plus rien enregistrer tant qu'on n'a pas re-basculé. On sérialise deux recettes qui, dans la vraie vie, se mènent en même temps.

Références au code / au modèle.

Constat	Où
« une seule campagne active »	campaigns.activate : isActive = true + auto-désactivation des autres · unicité par index Convex + garde de mutation (F7)
Écriture réservée à l'active	garde assertCampaignActive dans les mutations etapes / anomalies (Référentiel & Snapshots)

Exemple concret

Montée de version ERP 2025.1 → 2025.2. À un instant donné, trois recettes coexistent :

Campagne	Type	Environnement	Qui
A	SAT en cours (fin de recette 2025.1)	UAT	consultants métier
B	Non-régression 2025.2 (A6)	TRN	testeurs recette
C	Smoke quotidien	TRN	équipe technique

Ces trois campagnes ont des buts différents, des acteurs différents, et tournent en parallèle — c'est le cas normal en recette ERP (SIT / SAT / non-régression répondent à des questions distinctes). Le modèle « une seule active » les force à s'exclure ; le besoin est qu'elles coexistent.

Le point technique — pourquoi c'est presque déjà fait

A3bis a déjà cassé le lien « active = cible unique ». Dans le modèle hybride, un résultat n'est plus écrit dans un snapshot global : il vit dans etapeResults, clé par campaignId. La cible d'écriture est donc déjà naturellement par-campagne. Concrètement, la même étape peut porter un résultat dans la campagne A et dans la campagne B sans conflit (règle RG-07 déjà relâchée par A3bis : « même étape KO en N puis en N+1 = deux anomalies distinctes »).

Il ne reste donc que deux choses à faire :

1. Retirer l'unicité « une seule active » (l'index + l'auto-désactivation) et remplacer la garde assertCampaignActive (booléen unique) par une garde d'état : « la campagne ciblée est-elle inscriptible ? » = statut En cours et non archivée. Plusieurs campagnes peuvent l'être.
2. Rendre la cible d'écriture explicite côté UX (§ ci-dessous) — le vrai risque de la parallélisation.

• campaigns.activate : supprimer l'auto-désactivation des autres campagnes et l'index d'unicité sur isActive. « Inscriptible » devient dérivé du statut (En cours), plus un booléen global exclusif.
• Renommer la garde assertCampaignActive → assertCampaignWritable(campaignId) : vérifie statut === "En cours" de la campagne ciblée passée en argument, plus « la » campagne active du projet. Portée par la couche ABAC (règle d'état), pas par l'UI.
• Aucune nouvelle table, aucune migration de données. C'est un retrait de contrainte, pas un ajout de structure — compatible directement avec etapeResults (A3bis).

Proposition fonctionnelle

• Plusieurs campagnes en statut En cours par projet, sans exclusion mutuelle.
• Cible d'écriture explicite et toujours visible. Le sélecteur de campagne (déjà prévu, badge « ⚡ ACTIVE ») devient le choix de la campagne de travail courante. Saisir un résultat = l'écrire dans la campagne sélectionnée. Un bandeau permanent « Vous saisissez dans : Campagne B » évite l'erreur n°1 de la parallélisation : enregistrer dans la mauvaise campagne par changement de contexte.
• Cible par utilisateur, pas par projet : un testeur SAT et un testeur non-régression choisissent chacun leur campagne courante et travaillent en parallèle sans se gêner.
• Journalisation inchangée : etapeResults.campaignId porte déjà « dans quelle campagne ce résultat a été saisi ». Rien à ajouter.

Le sélecteur n'est pas un détail cosmétique : c'est la sécurité du dispositif. Tant qu'il n'y avait qu'une campagne active, la question « où est-ce que j'écris ? » ne se posait pas. Dès qu'il y en a plusieurs, elle devient la source d'erreur possible — d'où le bandeau permanent et la cible par utilisateur.

Problèmes réels connus & réponses

Problème (constaté dans les outils du marché)	Réponse dans notre modèle
Saisie dans la mauvaise campagne (changement de contexte) — le risque n°1 dès qu'on parallélise	Cible d'écriture explicite, par utilisateur, affichée en permanence ; écriture « hors campagne » impossible
Reporting brouillé : que veut dire « avancement » quand 3 campagnes tournent ?	L'avancement est déjà par campagne (dénominateur A3bis) ; la vue consolidée projet est le rôle du dashboard A1
Même étape jouée dans deux campagnes	Déjà géré par A3bis : etapeResults clé par campaignId, RG-07 relâchée
Trop de campagnes ouvertes en même temps (bruit, oublis de clôture)	Question de gouvernance, pas de modèle → borne éventuelle à trancher (Q35)

Impact

Léger, et surtout soustractif. On retire une contrainte (l'unicité) plutôt que d'ajouter une structure. Pas de nouvelle table, pas de migration. La seule vraie brique neuve est côté client : le sélecteur de campagne devient le contexte d'écriture et non plus un simple filtre de lecture.

Compatible et complémentaire des autres fiches : A6 (la non-régression tourne en parallèle d'une SAT au lieu de l'interrompre), A10 (l'assignation est déjà par campagne — « Mes flux à exécuter » se lit dans la campagne courante), A1 (la consolidation projet devient réellement utile quand plusieurs campagnes sont vivantes).

Droits

Ouvrir / clôturer une campagne : à confirmer. En v1, activer est réservé à l'admin ; désactiver = admin + consultant. Avec plusieurs campagnes vivantes, ouvrir une campagne est une opération plus courante — faut-il l'ouvrir au consultant ? → Q35. Saisie des résultats dans une campagne inscriptible : inchangé (admin / consultant / testeur).

Aligné marché

Aucun outil étudié n'impose une seule campagne active — c'est même l'inverse :

• TestRail : plusieurs test runs ouverts simultanément, typiquement un par configuration / environnement ; les Test Plans les regroupent. Les modifications de cas ne se répercutent que dans les runs ouverts ; un run fermé garde son instantané.
• Xray : plusieurs Test Executions en parallèle sur la même version.
• Zephyr Scale : plusieurs test cycles simultanés par version / release.

Notre « une seule active » est donc une singularité de v1 (conséquence du modèle snapshot), pas un standard du domaine. Voir Analyse du marché.

À trancher — Q35

• Cible d'écriture par utilisateur (chaque testeur choisit sa campagne courante — recommandé) ou par projet (une campagne « focus » partagée) ?
• Borne au nombre de campagnes ouvertes simultanément (par environnement ? par version ?), ou illimité et laissé à la gouvernance de l'équipe ?
• Qui peut ouvrir une campagne quand il peut y en avoir plusieurs : admin seul (comme aujourd'hui) ou admin + consultant ?

Sources

TestRail — Test case versioning & parallel runs · TestRail — Configurations · TestRail — Cross-environment testing strategy · SIT vs UAT — buts et acteurs distincts · Regression vs UAT — questions distinctes