Aller au contenu

ADR: Rattacher chaque demande de déblocage de fonds travaux à une seule facture

Contexte

Le parcours PDP de « tirage travaux » est renommé « demande de déblocage de fonds de travaux » ; les modales de demande et de suivi ont été revues [source locale non partagée].

Historique du modèle : 1. Initialement, une demande de tirage = une facture [source locale non partagée]. Le 2026-10-08, un cadrage explore une demande pouvant regrouper plusieurs factures, chaque facture gardant son cycle de validation ; la règle d'acceptation partielle reste à vérifier [source locale non partagée]. 2. Le 2026-10-12, un modèle « plusieurs factures par demande » est présenté comme prêt, pour éviter une demande par facture [source locale non partagée]. 3. Le même jour, une revue de la page est demandée : le parcours impose aux utilisateurs une complexité qui n'est pas la leur [source locale non partagée].

Options envisagées

Option A : plusieurs factures par demande

  • Description : une demande regroupe plusieurs factures et envoie un lot de demandes de déblocage [source locale non partagée].
  • Inconvénients : complexité imposée aux utilisateurs [source locale non partagée].

Option B : une facture par demande, regroupement au moment du tirage

  • Description : côté app PDP, gestion de factures avec statut (accepter, refuser, commenter, payer) ; côté admin, acceptation / refus facture par facture ; le tirage est émis à la volée et peut regrouper plusieurs factures dans un même flux d'argent [source locale non partagée].

Décision

Option retenue : B — retour à « une demande = une facture » pour la demande et le suivi [source locale non partagée].

Conséquences

Positives attendues

  • Statut lisible par facture côté PDP et administration [source locale non partagée].

Négatives acceptées

  • Soumission répétée quand il y a beaucoup de factures ; compensée par une modale de confirmation qui propose d'enchaîner une nouvelle demande, sans réintroduire d'envoi groupé [source locale non partagée].

Reversibilité

  • Coût d'annulation : moyen [non sourcé].

Plan d'implémentation

  • [ ] Adapter le parcours : demande et suivi par facture, modale « créer une autre demande » [source locale non partagée].
  • [ ] Préparer une démo avec de petites PR fonctionnelles et les revues de code nécessaires [source locale non partagée].
  • Risques / edge cases : migration des factures existantes — analyse à mener avant l'implémentation [source locale non partagée].

Métriques de succès

[outcome non formulé]

Review design

  • Parcours user impactés : demande et suivi de déblocage de fonds travaux (app PDP).
  • États / edge cases couverts : [états non listés] — cas « une vingtaine de factures » identifié.
  • Niveau de fidélité retenu : [fidélité non justifiée]
  • Plan de test UX : [non sourcé]
  • Critères de QA design : [QA design non passée]
  • Lien Figma : [non sourcé]
  • Impact DS : [pas d'impact DS] [non sourcé]

Sources

Révisions

  • 2026-10-14 : créée (status: proposed) — à valider par Rémy / William
  • 2026-10-14 : contexte et options réécrits depuis les transcripts bruts (historique 1=1 → multi → 1=1)