A9 — Étapes partagées & jeux de données

🆕 Évolution proposée — issue de l'inventaire marché (C03, C05)

Statut : 🟢 prêt à spécifier. ⚠️ À trancher avant A7 : ces deux mécanismes changent la structure du référentiel, donc les colonnes du gabarit d'import.

En une phrase

Les mêmes étapes sont recopiées dans des dizaines de flux, et le même flux existe en plusieurs exemplaires quasi identiques pour changer une valeur. On maintient N fois ce qui devrait être maintenu une fois.

Constat

Dans le modèle actuel, chaque étape appartient à un seul flux. Deux conséquences observées sur un référentiel de recette ERP :

1. Duplication massive des étapes d'amorce. « Se connecter avec le profil X », « Naviguer vers le module Achats », « Sélectionner la société », « Vérifier l'écriture comptable générée » se répètent quasi à l'identique dans des dizaines de flux. Une correction de libellé ou un changement d'écran dans l'ERP oblige à reprendre chaque flux un par un.
2. Explosion combinatoire des variantes. Le même flux joué pour trois sociétés, deux devises ou quatre profils utilisateur existe aujourd'hui en N flux quasi identiques — avec N fois la maintenance et N fois le risque de divergence.

Aucun mécanisme du modèle v1 ne traite l'un ou l'autre.

A9.1 Étapes partagées (C03)

Proposition

• Un bloc d'étapes nommé et réutilisable (ex. « Connexion profil acheteur », « Contrôle de l'écriture comptable »), rédigé une fois.
• Un flux peut insérer ce bloc au lieu de recopier ses étapes.
• Édition unique, propagation automatique : corriger le bloc met à jour tous les flux qui l'utilisent — exactement le comportement des shared steps de TestRail.

Nouvelle collection sharedSteps (bloc = une ou plusieurs étapes : nom, description, jeu, attendu, crimCode). Une ligne de etapes est soit une étape propre, soit une référence (sharedStepId + position).

Interaction avec le gel d'A3bis

C'est le point délicat, et il se résout naturellement :

A3bis fige les libellés d'une étape au moment où quelqu'un l'exécute. Un bloc partagé corrigé après exécution ne remonte donc pas dans les campagnes déjà jouées : l'historique reste opposable. Avant exécution, la correction descend — c'est le comportement voulu.

Aucune règle supplémentaire n'est nécessaire. Le gel d'A3bis couvre déjà le cas.

Garde-fou

La suppression d'un bloc partagé référencé doit être refusée (ou proposer un « détachement » qui recopie les étapes dans chaque flux consommateur). Même logique que la suppression dure interdite d'A3bis.

A9.2 Jeux de données / paramétrage (C05)

Proposition

• Un flux peut porter des paramètres nommés dans ses libellés (ex. Se connecter en tant que sur la société ).
• Une collection datasets associe au flux N jeux de valeurs ({profil: "Acheteur", societe: "FR01"}, {profil: "Valideur", societe: "BE02"}…).
• À l'ajout au périmètre d'une campagne (A3), l'utilisateur choisit quels jeux exécuter → une exécution par jeu, sur une seule définition de flux.

Pourquoi cette décision ne peut pas attendre

Le jeu de données change l'unité de résultat : on ne stocke plus « le résultat de cette étape dans cette campagne », mais « le résultat de cette étape dans cette campagne pour ce jeu de valeurs ». C'est une modification de la clé d'identification des résultats.

Prise au départ, elle est gratuite. Prise après coup, elle oblige à reprendre toute la saisie de résultats sur des données déjà en production.

campaignTests et etapeResults gagnent un datasetId (nullable). La clé d'unicité des résultats passe de (campaignId, etapeId) à (campaignId, etapeId, datasetId) — index d'unicité et chaque mutation de saisie sont concernés.

Effet sur les volumes

Un flux joué sur 3 jeux de données = 1 définition au lieu de 3 flux dupliqués, et 3 séries de résultats. Le référentiel reste petit, seuls les résultats croissent — cohérent avec la logique d'A3bis et avec les limites de la plateforme (Exigences non-fonctionnelles).

Impact sur le gabarit d'import (A7)

Deux colonnes supplémentaires dans la feuille Flux :

Colonne	Rôle
sharedStepRef	référence d'un bloc partagé, à la place des colonnes etapeNom / etapeDescription / jeu / attendu
datasetRef	nom du jeu de données, quand le flux est paramétré (les valeurs vivent dans une feuille JeuxDeDonnees)

➡️ D'où la règle de séquencement : A9 se tranche avant que le gabarit A7 ne soit publié au client. Un client ne re-remplit pas 400 flux parce que le format a changé.

Droits

Création / édition / suppression des blocs partagés et des jeux de données : admin + consultant. Sélection des jeux à exécuter dans une campagne : admin + consultant.

Aligné marché

• TestRail — shared steps : « réutiliser le même ensemble d'étapes dans plusieurs cas, de sorte qu'une modification unique se propage à tous les cas qui l'utilisent ».
• TestRail — parameters : « un cas défini une fois avec des marqueurs, développé en plusieurs exécutions pour les combinaisons ».
• Zephyr — datasets, même principe.

À trancher

• Les deux mécanismes sont-ils voulus, ou seulement les étapes partagées (le plus gros gain de maintenance immédiat) ?
• Un bloc partagé peut-il porter un CRIM propre, ou le CRIM reste-t-il toujours au niveau de l'étape dans le flux consommateur ? (impacte directement la matrice de traçabilité A8)
• Les jeux de données sont-ils globaux (réutilisables entre flux) ou propres à un flux ? Recommandation : propres au flux en première version — le partage est une complexité à ne payer qu'une fois le besoin démontré.