Documentation

Appearance

Simplification du parcours Campagne — Wizard, saisie collaborative, validation ​

Spécification technique pour Heriade Rapport. Simplifie l'expérience utilisateur de création et de remplissage d'une campagne Budget/Forecast (ForecastCampaign), en masquant la complexité technique déjà existante derrière un parcours en langage métier.

1. Constat ​

ForecastCampaign expose aujourd'hui de nombreux champs techniques (cutoffMonth, baseScenario, baseCampaignId, domain, analysisDepth, dimensionId, chargeRate, inflationDefault, saisieConfig) directement dans le parcours de création. Un DAF ou un CDG n'a pas besoin de comprendre ce que signifie analysisDepth: -1 pour créer un budget — ce niveau de détail doit rester accessible pour un usage avancé (Admin), mais jamais imposé par défaut.

2. Wizard de création de campagne ​

Sur le modèle des wizards KPI et Pastille déjà spécifiés (docs/spec-bibliotheque-kpi.md, docs/spec-bibliotheque-widgets-restitution.md) : langage métier, valeurs par défaut sensées, options avancées repliées.

Étape 1 — Type ​

  • Budget (nouvel exercice, repart de zéro ou d'une base) → cutoffMonth = 0 par défaut, non modifiable à cette étape
  • Forecast (mise à jour en cours d'année) → cutoffMonth déduit automatiquement du dernier mois clôturé disponible dans les données réelles, proposé mais modifiable

Étape 2 — Nom ​

  • Champ unique : nom de la campagne (ex. "Budget 2027", "Forecast P6 2026") → label, year déduit du nom ou saisi séparément si ambigu

Étape 3 — Base de départ (langage métier → baseScenario) ​

  • "Je repars de zéro" → zero_based (cf. docs/spec-planification-forecast-budget.md, base à ajouter en étape 1b)
  • "Je repars du budget de l'an dernier, avec une croissance" → n1_budget_croissance, avec un champ "taux de croissance" en clair
  • "Je repars du dernier réel connu" → n1
  • "Je repars d'une campagne déjà validée" → campaign, avec sélection de la campagne (baseCampaignId) parmi celles marquées frozen (cf. section 4)

Étape 4 — Règles par défaut ​

  • Taux d'inflation par défaut (inflationDefault) — pré-rempli avec la dernière valeur utilisée par l'entreprise, modifiable
  • Taux de charges patronales (chargeRate) — pré-rempli à 0.45 (valeur par défaut actuelle), modifiable
  • Ces deux valeurs restent surchargeables ligne à ligne plus tard dans l'écran de saisie (comportement déjà existant), le wizard ne fixe qu'un défaut global

Options avancées (repliées, réservées Admin) ​

domain, analysisDepth, dimensionId, saisieConfig restent modifiables, mais dans une section explicitement repliée ("Options avancées"), jamais dans le flux principal du wizard. Un Modeleur ne les voit jamais ; un Admin peut les ouvrir s'il a un besoin spécifique.

Validation ​

Bouton final : "Créer [Nom de la campagne]" (ex. "Créer Budget 2027") — pas "Suivant" sur la dernière étape, cohérent avec le pattern déjà établi dans les autres wizards.

3. Espace de saisie collaboratif ​

Le problème actuel ​

La grille de saisie (CampaignsPage.vue) semble aujourd'hui présenter l'ensemble des postes × mois pour toute la campagne, sans distinction de qui doit remplir quoi — source de confusion si plusieurs contributeurs interviennent sur des périmètres différents (ex. un CDG par établissement).

Principe : chaque contributeur ne voit que son périmètre à remplir ​

En s'appuyant sur le modèle de droits déjà existant (docs/permissions-model.md, establishmentsAllowed), l'écran de saisie d'une campagne se filtre automatiquement selon l'utilisateur connecté :

  • Un contributeur avec un périmètre restreint (ex. un seul établissement) ne voit que les postes de cet établissement à compléter
  • Un DAF ou un Admin voit l'ensemble, avec une vue de suivi de complétion (section suivante)

Suivi de progression ​

Un indicateur simple, visible par le porteur de la campagne (DAF/Admin), affichant l'état de complétion par contributeur ou par établissement — sur le modèle du badge déjà utilisé ailleurs dans le produit (ex. badge de comptage sur Modélisation) :

Budget 2027 — 12 / 20 postes complétés
  Val Serein     8/10  ✓ presque terminé
  RES1           4/10  ⚠ en attente

Pas de blocage entre contributeurs : chacun peut saisir dans son périmètre indépendamment, à son rythme, sans attendre les autres — cohérent avec le principe déjà appliqué aux ajustements CDG (saisie asynchrone, pas au même moment).

4. Validation — "Valider V1" ​

Réutilisation du champ existant frozen ​

Le champ frozen de ForecastCampaign existe déjà et sert précisément à ça : une campagne figée devient la base d'atterrissage d'une campagne suivante. Le bouton "Valider V1" dans l'interface ne fait qu'exposer clairement cette action déjà présente techniquement :

  • Geler la campagne (frozen = true)
  • La rendre disponible comme choix de base ("Je repars d'une campagne déjà validée", étape 3 du wizard) pour une prochaine campagne
  • La campagne validée reste consultable en lecture seule, mais n'accepte plus de saisie

Historique de versions ​

Si plusieurs validations successives existent pour un même exercice (V1 initiale, puis une révision), les nommer explicitement dans l'interface (ex. "Budget 2027 — V1", "Budget 2027 — V2") plutôt que de laisser deviner l'ordre chronologique via des dates seules.

5. Ce que ce chantier ne change pas ​

  • Le modèle de données (ForecastCampaign et ses collections filles) reste inchangé — ce travail est une couche d'expérience utilisateur au-dessus de l'existant, pas une refonte du moteur.
  • Les 3 types de projection (A métier, B RH, C comptable) et leurs méthodes (volume, projets, masse_salariale, reste, fiche) restent tels quels dans le moteur de calcul.
  • Le mécanisme de reprise et de détection de divergence (docs/spec-planification-forecast-budget.md, étape 2 révisée) reste une priorité indépendante de ce chantier de simplification — les deux peuvent avancer en parallèle.

6. Phasage suggéré ​

  1. Étape 1 : wizard de création de campagne (section 2), en s'appuyant uniquement sur les bases déjà codées (budget, n1, campaign) — les bases manquantes (zero_based, n1_budget_croissance) suivent le phasage déjà prévu dans docs/spec-planification-forecast-budget.md, étape 1b.
  2. Étape 2 : filtrage de l'écran de saisie par périmètre de droits de l'utilisateur connecté (section 3, principe de base) — réutilise establishmentsAllowed déjà existant, pas de nouveau modèle de droits à créer.
  3. Étape 3 : suivi de progression visible par le porteur de campagne (section 3, indicateur de complétion).
  4. Étape 4 : bouton "Valider V1" et historique de versions explicite (section 4) — expose une fonctionnalité déjà codée (frozen), gain rapide.

7. Point de vigilance ​

Le wizard simplifié ne doit jamais empêcher un Admin d'accéder à la configuration complète si un besoin réel l'exige (ex. un analysisDepth différent de la feuille pour un cas particulier) — les options avancées doivent rester un vrai accès, pas une fonctionnalité supprimée. L'objectif est de masquer la complexité par défaut, pas de la retirer pour les profils qui en ont l'usage légitime.