Aller au contenu

Expiration invest auto H-1 (effet yoyo)

Proposition V1 de cadrage, 2026-08-21. L'exécution vit dans Linear. Les timings vivent sur la vue timeline Figma.

Problème

À l'ouverture d'une collecte, la jauge inclut des réservations invest auto non confirmées. Quelques jours plus tard, une partie expire : la jauge redescend (effet yoyo). Côté investisseur : sensation de bug, bricks bloquées. Côté market : la hype d'ouverture est faussée.

Cause actuelle : l'invest auto expire 4 jours après la mise en ligne, pas avant l'ouverture. (BRI-1605)

Outcome visé

Le % financé affiché à l'ouverture est réel : plus d'expirations invest auto après l'ouverture.

La jauge peut encore reculer à cause du délai légal de rétractation (4 jours après confirmation). Hors scope : on ne le traite pas, le délai reste tel quel.

Baseline data : BRI-1031 (détail chiffré dans le project Linear, pas recopié ici). Target chiffrée : [outcome non formulé] au-delà de « jauge réelle à l'ouverture ».

Hypothèses (falsifiables)

  • Si on expire les réservations non confirmées 1 h avant l'ouverture, alors la jauge d'ouverture ne contient plus que des bricks confirmées, parce que le non-confirmé a déjà sauté.
  • Si on relance (solde + dernier rappel), alors une partie des expirations passives se convertit, parce que l'oubli et le solde insuffisant sont les deux causes distinctes. [à confirmer Product / Market]
  • Kill criteria : [non posé] — pas de test préalable sur la règle actuelle ; les relances partent avec H-1.

Plus petit test (MVP)

Ship H-1 + les deux relances V1, sur les collectes suivantes. Mesure : jauge à l'ouverture vs jauge J+1 / J+4 (plus d'expiration invest auto post-ouverture ; rétractations isolées).

Learning goal

Savoir si H-1 suffit à rendre la jauge d'ouverture réelle, et si les relances convertissent vraiment (solde vs oubli), sans toucher à la rétractation.

Règles V1 (tranchées)

Horloge de référence : ouverture de la collecte (créneau habituel 12h30 ; H-1 = 11h30 si ouverture à 12h30).

Règle Décision
Attribution Toujours le jour de la publication (1er tour).
Vague 2 2e tour, lendemain 16 h. Si elle tomberait après l'ouverture, elle n'a pas lieu (validé tech).
Expiration vague 1 / vague 2 Chaque vague a sa propre horloge : 4 j après cette vague — jusqu'à confirmation tech de Q1.
Expiration H-1 Toutes les non-confirmées sautent 1 h avant l'ouverture.
Destination des bricks Libérées à H-1 → investissement manuel dès l'ouverture. Pas de 3e tour invest auto.
Rétractation 4 j après chaque confirmation. Inchangée. Hors scope.
Preview Pas de durée minimale. Publication à la main ; on évite les previews trop courts, on fait au mieux.

Les deux tours d'allocation (publication + lendemain 16 h) sont le fonctionnement actuel, porté par BRI-1992. H-1 n'ajoute pas de tour.

Relances V1 — à confirmer Product / Market

  1. Relance solde — à la fin de la vague 2, quelle que soit sa durée. CTA recharger (un virement met plusieurs jours). Canal proposé : push + mail.
  2. Dernier rappel — 3 h avant l'expiration (H-3), ancré sur l'heure d'ouverture, pas sur le calendrier. Montant, heure du couperet, confirmation en un tap. Canal proposé : push uniquement.

Sans relance, H-1 purge plus tôt sans faire confirmer davantage. Les relances partent avec H-1 (pas de test sur la règle actuelle).

Q1 — à confirmer avec la tech

Proposition V1 : H-1 pour tout, on retire le plafond de 4 jours. Une seule horloge, calée sur l'ouverture. L'attribution reste le jour de la publication.

  • Si le plafond reste : sur un preview > 4 j, les non-confirmées sautent trop tôt et les bricks restent orphelines (sous-collecte à l'ouverture).
  • Si on le retire : le solde reste bloqué jusqu'à H-1 sur un preview long.

Le project Linear formule déjà H-1 comme V0 (« plus 4 j après mise en ligne »). Q1 = faisabilité tech de cette suppression de plafond.

Lentille design

  • Parcours user couverts : publication → attribution vague 1 → (vague 2 ou skip) → relances → expiration H-1 → ouverture (jauge réelle) → rétractation possible 4 j après confirmation.
  • États couverts : preview 6 j / 3 j / 1 j (timeline). Edge : pas de vague 2 si elle tomberait après l'ouverture ; relance H-3 possible même sur preview d'1 j (ancrage horaire) ; pas de relance solde s'il n'y a pas de vague 2.
  • Niveau de fidélité retenu : FigJam timeline (processus / horloges), pas d'UI high-fi — on spécifie des règles de temps, pas un écran. [fidélité justifiée : apprentissage = croisements d'horloges]
  • Plan de test UX : [non posé] — wording in-app et com plans actifs sont des livrables BRI-1605, pas encore prototyés.
  • Critères de QA design : [QA design non passée] — à faire sur wording confirmation / expiration avant ship.
  • Lien Figma : vue timeline

Points d'attention (specs / com)

  • Jauge d'ouverture plus basse, et c'est voulu — à préparer market / com.
  • Plans existants ont appris « 4 jours après la mise en ligne » — com dédiée, livrable BRI-1605.
  • Preview court : 1 jour = ~23 h pour confirmer ; plus court, pas de filet technique.
  • Solde bloqué jusqu'à H-1 si Q1 passe — tickets support « il me manque de l'argent » déjà connus.

Gouvernance

Exécution

Livrables, issues et statuts : Linear, issue BRI-1605.

Hors scope

Critère note dans la config, surcollecte, désactivation des plans passifs, coche montant exact vs solde, rétractation légale, 3e tour d'allocation à H-1.

Liens