#Analyse de l'UX de Création de Contrat Cash Pooling

Date: Février 2026
Références: DAT_Cash_Pooling.md, CDC_SPEC_Cashpooling_31072015_v07.pdf

---

#1. Vue d'ensemble du flux existant

Le flux de création de contrat se compose de 4 étapes :

1. Step 1 - Sélection (step-selection.tsx): Sélection du compte centralisateur
2. Step 2 - Structure (step-structure.tsx): Construction de la hiérarchie et configuration du nivellement
3. Step 3 - Validation (step-validation.tsx): Récapitulatif et validation
4. Step 4 - Contrat (step-contract.tsx): Génération et affichage du contrat

---

#2. Mapping des champs existants

#2.1 Entité Contract (DAT §4.2)

Champ DAT	Champ UI Existant	Localisation	Statut
contractId	id	unified-subscription-flow.tsx:71	✅ OK
contractNumber	contractNumber	unified-subscription-flow.tsx:72 (généré)	✅ OK
clientCode	❌ MANQUANT	-	❌ À ajouter
clientRef	❌ MANQUANT	-	❌ À ajouter
companyName	clientName	unified-subscription-flow.tsx:77	⚠️ Nom différent
rcNumber	❌ MANQUANT	-	❌ À ajouter
address	❌ MANQUANT	-	❌ À ajouter
levelingType	❌ MANQUANT	-	❌ À ajouter (DIRECT/INDIRECT)
levelingMode	poolingConfig.mode	hierarchy-builder.tsx:496 (par compte)	⚠️ Par compte, pas au niveau contrat
transferType	❌ MANQUANT	-	❌ À ajouter (BALANCE/VALUE_DATE/OPERATION)
transferPeriodicity	scheduling.frequency	scheduling-config.tsx:38	⚠️ Présent mais pas au niveau contrat
transferDays	scheduling.weeklyDay	scheduling-config.tsx:68	⚠️ Présent mais pas au niveau contrat
monthlyTransferDay	scheduling.monthlyDay	scheduling-config.tsx:92	⚠️ Présent mais pas au niveau contrat
quarterlyDates	❌ MANQUANT	-	❌ À ajouter
semiAnnualDates	❌ MANQUANT	-	❌ À ajouter
annualDate	❌ MANQUANT	-	❌ À ajouter
masterAccountId	masterAccountId	unified-subscription-flow.tsx:73	✅ OK
billingAccountId	❌ MANQUANT	-	❌ À ajouter
billingType	❌ MANQUANT	-	❌ À ajouter
billingAmount	❌ MANQUANT	-	❌ À ajouter
billingPeriodicity	❌ MANQUANT	-	❌ À ajouter
alertEmail1	❌ MANQUANT	-	❌ À ajouter
alertEmail2	❌ MANQUANT	-	❌ À ajouter
effectiveStartDate	❌ MANQUANT	-	❌ À ajouter
status	status	unified-subscription-flow.tsx:78	✅ OK
version	❌ MANQUANT	-	❌ À ajouter
createdAt	createdAt	unified-subscription-flow.tsx:81	✅ OK
updatedAt	updatedAt	unified-subscription-flow.tsx:82	✅ OK

Résumé Contract:

• ✅ Champs OK: 7/25 (28%)
• ❌ Champs manquants: 18/25 (72%)

#2.2 Entité Account (DAT §4.3)

Champ DAT	Champ UI Existant	Localisation	Statut
accountId	id	types.ts:13	✅ OK
contractId	❌ MANQUANT	-	❌ À ajouter (lien vers contrat)
accountNumber	accountNumber	types.ts:14	✅ OK
accountType	accountType	types.ts:20	✅ OK (MASTER/SOURCE/INTERMEDIATE)
parentAccountId	parentAccountId	hierarchy-builder.tsx:375	✅ OK
mirrorAccountId	❌ MANQUANT	-	⚠️ Hors scope MVP (Indirect)
customLabel	❌ MANQUANT	-	❌ À ajouter (max 14 caractères)
currency	currency	types.ts:18	✅ OK
status	status	types.ts:19	✅ OK
createdAt	createdAt	types.ts:21	✅ OK
updatedAt	❌ MANQUANT	-	❌ À ajouter

Résumé Account:

• ✅ Champs OK: 7/11 (64%)
• ❌ Champs manquants: 3/11 (27%)
• ⚠️ Hors scope: 1/11 (9%)

#2.3 Entité PoolingRule (DAT §4.6)

Champ DAT	Champ UI Existant	Localisation	Statut
ruleId	❌ MANQUANT	-	❌ À générer
contractId	❌ MANQUANT	-	❌ À ajouter
accountId	accountId	hierarchy-builder.tsx:134	✅ OK
thresholdTBA	targetBalance	hierarchy-builder.tsx:519	✅ OK
thresholdFBA1	minBalance	hierarchy-builder.tsx:536	✅ OK
thresholdFBA2	maxBalance	hierarchy-builder.tsx:546	✅ OK
thresholdFBAUser	❌ MANQUANT	-	❌ À ajouter (seuil cible FBA)
isActive	isActive	hierarchy-builder.tsx:103	✅ OK
createdAt	❌ MANQUANT	-	❌ À ajouter
updatedAt	❌ MANQUANT	-	❌ À ajouter

Résumé PoolingRule:

• ✅ Champs OK: 5/10 (50%)
• ❌ Champs manquants: 5/10 (50%)

---

#3. Champs manquants critiques

#3.1 Informations client (CDC §1.1)

Champs obligatoires manquants:

• clientCode (Code tiers) - OBLIGATOIRE
• clientRef (Référence tiers GRC) - OBLIGATOIRE
• rcNumber (N° RC) - OBLIGATOIRE (chargé depuis GRC)
• address (Adresse client) - OBLIGATOIRE (chargé depuis GRC)

Note: Le CDC indique que ces champs doivent être chargés depuis la GRC lors de la sélection de la raison sociale.

#3.2 Configuration de nivellement (CDC §1.1, DAT §4.2)

Champs obligatoires manquants:

• levelingType (DIRECT/INDIRECT) - OBLIGATOIRE
  • Actuellement, seul DIRECT est implémenté (MVP)
  • INDIRECT est hors scope MVP
• levelingMode (ZBA/TBA/FBA) - OBLIGATOIRE au niveau contrat
  • Actuellement configuré par compte dans hierarchy-builder.tsx
  • Selon DAT, doit être au niveau contrat avec possibilité de surcharge par compte
• transferType (BALANCE/VALUE_DATE/OPERATION) - OBLIGATOIRE
  • Absent complètement
  • Détermine comment les transferts sont calculés

#3.3 Périodicité de transfert (CDC §1.1, DAT §4.2)

Champs conditionnels manquants:

• quarterlyDates (4 dates JJ/MM) - Si périodicité trimestrielle
• semiAnnualDates (2 dates JJ/MM) - Si périodicité semestrielle
• annualDate (1 date JJ/MM) - Si périodicité annuelle

Note: La périodicité est actuellement gérée via SchedulingConfig mais n'est pas liée au contrat selon le modèle DAT.

#3.4 Tarification (CDC §1.1, DAT §4.2)

Champs obligatoires manquants:

• billingAccountId (Compte de facturation) - OBLIGATOIRE
• billingType (FLAT_FEE/PER_ACCOUNT) - OBLIGATOIRE
• billingAmount (Montant tarification) - OBLIGATOIRE
• billingPeriodicity (MONTHLY/QUARTERLY/ANNUAL) - OBLIGATOIRE

Note: Le DAT indique que le module de tarification est traité séparément, mais les champs doivent être présents dans le contrat.

#3.5 Alertes (DAT §4.2)

Champs obligatoires manquants:

• alertEmail1 (Email principal) - OBLIGATOIRE
• alertEmail2 (Email secondaire) - Optionnel

#3.6 Dates et versioning (DAT §4.2)

Champs manquants:

• effectiveStartDate (Date effective de démarrage) - OBLIGATOIRE
• version (Version du contrat) - OBLIGATOIRE (incrémentée à chaque modification)

#3.7 PoolingRule - Seuil FBA User (DAT §4.6)

Champ manquant:

• thresholdFBAUser (Seuil cible FBA) - OBLIGATOIRE si mode=FBA
  • Actuellement, seuls thresholdFBA1 (min) et thresholdFBA2 (max) sont collectés
  • Le seuil cible (thresholdFBAUser) est requis pour déterminer le montant à atteindre

#3.8 Account - Libellé personnalisé (DAT §4.3)

Champ optionnel manquant:

• customLabel (Libellé personnalisé, max 14 caractères) - Optionnel

---

#4. Champs redondants ou incohérents

#4.1 Notional Pooling (Hors scope MVP)

Problème: Le Cash Pooling Notionnel est implémenté dans l'UI (hierarchy-builder.tsx:192-303, notional-pooling-config.tsx) mais est explicitement exclu du MVP selon le DAT §6.1.

Recommandation:

• Retirer cette fonctionnalité de l'UI ou la marquer clairement comme "Hors scope MVP"
• Le DAT indique: "Cash Pooling Indirect n'est pas couvert par ce MVP"

#4.2 Investment Config (Hors scope DAT)

Problème: La configuration de placement OPCVM (InvestmentConfig) est présente dans l'UI mais n'est pas mentionnée dans le DAT comme faisant partie du modèle de données canonique.

Recommandation:

• Clarifier si cette fonctionnalité fait partie du MVP
• Si oui, l'ajouter au DAT
• Si non, la retirer ou la marquer comme "Fonctionnalité future"

#4.3 Debit Coverage (Non documenté)

Problème: La couverture automatique des soldes débiteurs (DebitCoverageConfig) est implémentée (hierarchy-builder.tsx:557-628) mais n'est pas documentée dans le DAT ou le CDC.

Recommandation:

• Clarifier si cette fonctionnalité fait partie du périmètre
• Si oui, documenter dans le DAT
• Si non, la retirer

#4.4 LevelingMode au niveau compte vs contrat

Problème: Le levelingMode (ZBA/TBA/FBA) est configuré par compte dans l'UI actuelle, mais selon le DAT §4.2, il devrait être au niveau contrat avec possibilité de surcharge par compte via PoolingRule.

Recommandation:

• Ajouter levelingMode au niveau contrat
• Conserver la configuration par compte comme surcharge (via PoolingRule)
• Valider les contraintes métier (DAT §4.2 contraintes)

#4.5 Scheduling au niveau Investment vs Contract

Problème: La configuration de planification (SchedulingConfig) est actuellement liée à InvestmentConfig mais devrait également être au niveau du contrat pour la périodicité de nivellement.

Recommandation:

• Séparer la planification du nivellement (niveau contrat) de la planification des placements OPCVM
• Implémenter transferPeriodicity et champs associés au niveau contrat

---

#5. Règles de validation backend à implémenter

#5.1 Contraintes Contract (DAT §4.2)

À valider côté backend:

1. ✅ Un seul contrat actif par groupe (unicité sur clientCode + status=ACTIVE)
2. ❌ levelingType=INDIRECT implique levelingMode=ZBA uniquement (hors scope MVP)
3. ❌ levelingMode=FBA implique transferType=BALANCE uniquement
4. ❌ levelingMode=TBA implique transferType in (BALANCE, OPERATION)
5. ❌ Périodicité > DAILY implique levelingMode=ZBA et transferType=BALANCE

#5.2 Contraintes Account (DAT §4.3)

À valider côté backend:

1. ✅ Un contrat possède exactement un compte de type MASTER
2. ✅ Un contrat possède au moins un compte de type SOURCE
3. ✅ Un compte SOURCE peut avoir un compte parent (INTERMEDIATE ou MASTER)
4. ✅ Un compte n'appartient qu'à une seule branche de la hiérarchie
5. ✅ accountType=MASTER implique parentAccountId=NULL

#5.3 Contraintes PoolingRule (DAT §4.6)

À valider côté backend:

1. ❌ Une règle par couple (contractId, accountId)
2. ❌ thresholdFBA1 < thresholdFBAUser < thresholdFBA2
3. ❌ Modification du seuil TBA implique redémarrage de la branche

#5.4 Contraintes CDC (CDC §1.1)

À valider côté backend:

1. ✅ Un groupe d'entreprise ne peut disposer que d'un seul contrat Cash Pooling
2. ✅ Un contrat doit absolument avoir un seul compte centralisateur et au moins un compte source
3. ✅ Un compte centralisateur peut avoir plusieurs comptes sources
4. ✅ Un contrat a une seule tarification
5. ✅ Un contrat a un seul compte de facturation

---

#6. Résumé des actions requises

#6.1 Champs à ajouter (Priorité Haute)

Étape 1 - Sélection:

• Ajouter recherche/sélection par raison sociale (GRC)
• Charger automatiquement: clientCode, clientRef, rcNumber, address depuis GRC

Nouvelle étape - Configuration Contrat:

• levelingType (DIRECT/INDIRECT) - Radio buttons
• levelingMode (ZBA/TBA/FBA) - Select au niveau contrat
• transferType (BALANCE/VALUE_DATE/OPERATION) - Select
• transferPeriodicity (DAILY/WEEKLY/MONTHLY/QUARTERLY/SEMI_ANNUAL/ANNUAL) - Select
• transferDays (si WEEKLY) - Multi-select jours
• monthlyTransferDay (si MONTHLY) - Select jour 1-28
• quarterlyDates (si QUARTERLY) - 4 dates JJ/MM
• semiAnnualDates (si SEMI_ANNUAL) - 2 dates JJ/MM
• annualDate (si ANNUAL) - 1 date JJ/MM
• effectiveStartDate - Date picker
• billingAccountId - Select compte de facturation
• billingType (FLAT_FEE/PER_ACCOUNT) - Radio buttons
• billingAmount - Input numérique
• billingPeriodicity (MONTHLY/QUARTERLY/ANNUAL) - Select
• alertEmail1 - Input email (obligatoire)
• alertEmail2 - Input email (optionnel)

Étape 2 - Structure (modifications):

• Ajouter thresholdFBAUser pour mode FBA
• Ajouter customLabel pour chaque compte (optionnel)
• Déplacer levelingMode au niveau contrat (garder surcharge par compte)
• Retirer ou désactiver Notional Pooling (hors scope MVP)

#6.2 Validations backend à implémenter

• Toutes les contraintes DAT §4.2, §4.3, §4.6
• Toutes les contraintes CDC §1.1
• Validation des combinaisons Mode/Type de transfert (DAT §7.2)
• Validation des contraintes de périodicité (DAT §7.3)

#6.3 Nettoyage (Priorité Moyenne)

• Retirer ou marquer Notional Pooling comme "Hors scope MVP"
• Clarifier le statut d'Investment Config (ajouter au DAT ou retirer)
• Clarifier le statut de Debit Coverage (documenter ou retirer)

---

#7. Mapping des écrans existants

#7.1 Step 1 - Sélection (step-selection.tsx)

Champs collectés:

• ✅ masterAccount (sélection)

Champs à ajouter:

• ❌ Recherche par raison sociale (GRC)
• ❌ Chargement automatique: clientCode, clientRef, rcNumber, address

#7.2 Step 2 - Structure (step-structure.tsx)

Champs collectés:

• ✅ Hiérarchie (comptes intermédiaires et secondaires)
• ✅ levelingMode par compte (ZBA/TBA/FBA)
• ✅ thresholdTBA (si TBA)
• ✅ thresholdFBA1 et thresholdFBA2 (si FBA)
• ✅ isActive par compte
• ✅ debitCoverage (non documenté)
• ✅ notionalConfig (hors scope MVP)
• ✅ investmentConfig (non documenté dans DAT)

Champs à ajouter:

• ❌ thresholdFBAUser (si FBA)
• ❌ customLabel par compte
• ❌ transferType (au niveau contrat)
• ❌ levelingMode au niveau contrat

Champs à retirer/désactiver:

• ⚠️ notionalConfig (hors scope MVP)

#7.3 Step 3 - Validation (step-validation.tsx)

Affichage:

• ✅ Récapitulatif de la hiérarchie
• ✅ Configuration du nivellement par compte
• ✅ Configuration OPCVM (si activée)
• ✅ Configuration Notionnel (si activée - hors scope)

À ajouter:

• ❌ Récapitulatif des champs contrat (levelingType, transferType, périodicité, etc.)
• ❌ Récapitulatif tarification
• ❌ Récapitulatif alertes

#7.4 Step 4 - Contrat (step-contract.tsx)

Affichage:

• ✅ Informations de base (référence, client, devise, dates)
• ✅ Compte centralisateur
• ✅ Comptes secondaires
• ✅ Configuration OPCVM (si activée)

À ajouter:

• ❌ Tous les champs manquants du contrat
• ❌ Informations tarification
• ❌ Informations alertes
• ❌ Configuration de nivellement au niveau contrat

---

#8. Notes importantes

#8.1 Conformité DAT/CDC

• Strict: Suivre le DAT comme référence technique unique
• Strict: Suivre le CDC comme référence fonctionnelle unique
• Interdit: Inventer de nouvelles fonctionnalités non documentées
• Interdit: Cash Pooling Indirect (hors scope MVP)

#8.2 Architecture batch-driven

• Tous les traitements sont batch (pas de temps réel)
• Pas d'orchestrateur applicatif interne
• La planification est externe (scheduler, cron, Control-M)

#8.3 Modèle de données canonique

• Tous les champs doivent correspondre au modèle DAT
• Aucun champ ne doit être ajouté sans validation DAT/CDC
• Les champs optionnels doivent être explicitement marqués

---

Fin du document