ADR : écarter la redistribution récursive de l'invest auto au profit d'une projection puis attribution¶
Statut :
accepted. Le flow v4 est validé le 24/08 (FigJam 95:2609). On n'y touche plus, sauf contrainte technique découverte pendant le dev back (BRI-1284).
Contexte¶
Le chantier BRI-1282 ajoute deux configs à côté du Partiel actuel (innommé) : Strict (ce montant, sinon rien) et Souple (prorata OK + prendre le solde dispo × 10 €). La revue du 10/08 avait identifié un effet de seuil : plusieurs plans Strict se concurrencent, chacun retombe sous son montant, et personne n'est servi alors qu'en Partiel la collecte se serait remplie (BRI-1992).
Le schéma v2.3 proposé le 17/08 corrigeait cet effet par une élimination itérative : on retire les plans sous leur minimum, leurs bricks retournent au pool, on recalcule le cycle, on répète jusqu'à convergence. Le kickoff du 19/08 avec le produit et la tech a écarté cette mécanique.
Éléments de fonctionnement actuel établis pendant l'atelier (ils n'étaient documentés nulle part) :
- Le script d'attribution peut tourner jusqu'à 24 minutes sur un gros projet (plusieurs millions de collecte, cas cité : résidence à Marseille).
- Quand le système sait à l'avance qu'il n'y aura pas assez de bricks pour tout le monde, les investisseurs sont mélangés et servis de façon aléatoire.
- Quand il y a assez de bricks pour au moins une brick par personne, priorité aux plans qui demandent le moins de bricks.
- Si le wallet ne couvre pas le montant configuré, l'investisseur est exclu (puis retry J+1 à 16 h) — il n'y a pas d'adaptation au solde aujourd'hui, contrairement à ce qu'affirme BRI-1282 à l'époque (« adaptation = comportement actuel »). Le comportement actuel est Partiel, pas Souple. Les plans existants restent Partiel.
- Des erreurs d'attribution surviennent rarement : solde consommé entre la simulation et l'attribution réelle, ce qui explique les totaux d'invest auto inférieurs à 100 % du projet.
Options envisagées¶
Option A : redistribution récursive (schéma v2.3)¶
- Description : élimination itérative des plans sous leur minimum, retour des bricks au pool, recalcul du cycle jusqu'à convergence.
- Avantages : résultat le plus juste ; aucune brick laissée de côté tant qu'un demandeur peut l'absorber ; convergence démontrable.
- Inconvénients : chaque libération entraîne une redistribution ; le récursif est évité par principe côté code (risque de boucle qui ne se termine pas, verrous DB tenus plus longtemps, plus une tâche est longue plus elle échoue) ; ne répond pas à la question de savoir qui éliminer en premier.
- Coût estimé : jugé prohibitif au regard des 24 minutes déjà constatées.
Option B : exclusion par tranches aléatoires¶
- Description : partir de 100 % des demandeurs, retirer 20 % au hasard, recalculer, répéter jusqu'à ce que l'allocation tienne.
- Avantages : borne le nombre de passes ; l'aléatoire évite d'avoir à justifier un ordre d'élimination.
- Inconvénients : reste multi-passes ; exclut potentiellement des plans qu'il n'était pas nécessaire d'exclure ; explicabilité faible.
- Coût estimé : non chiffré, jugé plus complexe que l'option C.
Option C : projection puis attribution (retenue)¶
- Description : en trois temps.
- Projection — on rejoue la distribution complète des bricks sans écrire l'attribution en base. C'est le même calcul qu'aujourd'hui, sans la partie DB.
- Exclusion — on repère tous les plans dont le seuil configuré ne serait pas atteint dans cette projection, et on les sort du calcul final. Ne restent que les plans dont le seuil est inférieur ou égal à ce que la projection leur attribuait.
- Attribution — le calcul réel tourne sur la liste restante.
- Les bricks des plans exclus ne sont pas remises dans le pool du même tour. Elles restent pour le second tour (retry J+1 à 16 h : non servis + stock restant + Stricts exclus au tour 1), puis à l'achat manuel. Pas de 3e tour.
- Avantages : deux passes bornées, aucune récursion ; l'ordre d'élimination disparaît comme question puisque tous les plans sous leur seuil sortent en une fois, sur la même projection ; explicable au care (« des bricks se sont libérées parce que d'autres plans ne les ont pas prises »).
- Inconvénients : le calcul est fait deux fois ; un Strict exclu au premier tour ne revient pas dans le même tour. Il peut revenir au tour 2 (J+1 16h).
- Coût estimé :
[non chiffré]— l'économie réelle de la projection sans écriture DB reste un point d'interrogation, à vérifier par la tech.
Décision¶
Option retenue : C — projection puis attribution.
Elle retire de la complexité au lieu d'en ajouter, ce qui compte d'autant plus que le volume d'utilisateurs et de projets de l'invest auto va croître : les estimations de coût doivent être tenables en scénario dégradé, pas seulement aujourd'hui. L'edge case laissé de côté est assumé : c'est une fonctionnalité de confort pour des investisseurs qui ne veulent pas gérer les petites lignes, pas une promesse d'allocation optimale.
Conséquences¶
Positives attendues¶
- Pas de récursion : le temps de traitement reste borné et prévisible.
- La question « qui élimine-t-on en premier ? » disparaît : l'exclusion est simultanée et fondée sur une projection unique.
- Le comportement est explicable en une phrase au service client.
- Les bricks non prises restent disponibles à l'achat manuel — elles ne sont pas perdues pour la collecte.
Négatives acceptées¶
- Un Strict exclu au premier tour ne revient pas dans ce tour. Il peut revenir au tour 2 (J+1 16h). Pas de 3e tour.
- Le calcul est exécuté deux fois ; si la projection s'avère aussi coûteuse que l'attribution, le temps de traitement double.
- Mettre un seuil, surtout élevé, réduit fortement les chances de recevoir des bricks — en situation de pénurie, la majorité des plans à seuil seront exclus. À dire clairement dans l'interface.
- Le mélange aléatoire existant en cas de pénurie reste en place : un plan dont le seuil est bas et atteignable y est soumis comme les autres.
Reversibilité¶
- Coût d'annulation : bas. Aucune migration de données ; la règle vit dans le script d'attribution.
Plan d'implémentation¶
- [x] Mettre à jour le schéma cible et les tickets de cadrage. (design) — v4 validée le 24/08.
- [ ] Implémenter le flow dans BRI-1284 (front + back). Si le back bloque sur le coût de la projection, on le dit.
- Ownership : Rémy porte le cadrage ; le build est BRI-1284.
- Risques / edge cases : verrous DB tenus pendant un traitement long ; solde consommé entre la projection et l'attribution ; publication rapprochée de plusieurs projets qui se disputent le même solde.
Métriques de succès¶
Reprises de BRI-1992 : taux de remplissage des collectes par l'invest auto et nombre de comptes distincts servis, mesurés en simulation contre le comportement actuel. Secondaire : taux de refus des attributions (BRI-1282).
Vérification post-implémentation¶
Comparer, sur les premières collectes après mise en production, la durée du traitement d'attribution avec la durée constatée avant changement (référence : jusqu'à 24 min sur un gros projet), le taux d'erreurs d'attribution, et le total invest auto rapporté au montant du projet. Prévenir le service client avant activation.
Review produit¶
- Pari acté : expliciter le choix « ce montant minimum ou rien » réduit les refus et les annulations d'attribution, sans dégrader le remplissage des collectes.
- Outcomes attendus : voir Métriques de succès — fenêtre de mesure
[non définie], à poser avec la data. - Plus petit test : le mode « minimum d'achat / adaptation au solde » (prendre le maximum disponible sur le wallet, arrondi au multiple de 10 €) est jugé simple techniquement — un changement de contrôle sur le solde — et entre dans le même périmètre de livraison.
- Kill criteria : si la data montre que le mode seuil ne concerne qu'une poignée
d'investisseurs, on ne développe pas ce mode et on livre uniquement l'adaptation au solde. Seuil
chiffré
[non défini]. - Date de review :
[à définir]après la sortie data.
Review design¶
- Parcours user impactés : configuration du plan invest auto (choix du mode et saisie du montant), notification d'attribution.
- États / edge cases couverts : seuil non atteint → aucune attribution, aucun gel ; solde inférieur au montant configuré → rien + retry J+1 (Partiel / Strict), ou prise du dispo × 10 € (Souple) ; Strict exclu au tour 1 peut revenir au tour 2.
- Niveau de fidélité retenu : zoning, suffisant pour le cadrage ; la maquette détaillée reste au ticket de build.
- Plan de test UX :
[non défini]. - Critères de QA design : le libellé doit faire comprendre qu'un seuil élevé réduit les chances de recevoir des bricks, sans promettre un montant garanti, et rester compréhensible sans connaître l'algorithme d'allocation.
- Lien Figma : v4 — projection puis attribution
- Impact DS :
[pas d'impact DS]— la configuration réutilise les composants existants.
Stratégie de release (tranchée en atelier) : les 3 configs sortent dans le même lot, avec un patch note unique et un effort d'éducation (vulgarisation, support vidéo, brief service client), plutôt que deux changements de règles à un mois d'intervalle. À anticiper : d'autres critères viendront s'ajouter à la configuration (score, typologie, géographie), ce qui pose la question d'un mode avancé.
Sources¶
- BRI-1992 — cadrage de l'algorithme d'allocation.
- BRI-1282 — règles d'adaptation du montant.
- BRI-1284 — ticket de build.
- Transcript du kickoff du 19/08/2026 :
inbox/leexi/transcripts/2026-08-19-kickoff-invest-auto-plan-avec-seuils.md(local, non versionné). - resources/produit-bricks/investauto.md — fonctionnement documenté côté care.