125813c34e
La limite demandée existe déjà deux fois — le solde prépayé est le plafond, et StudioPerUserDailyCap borne la journée d'un utilisateur. Ce qui manque est l'alerte : aujourd'hui le premier signal reçu est une génération qui échoue en InsufficientCredits, et l'expiration à 12 mois fait s'évaporer un solde sans prévenir. Seuil configurable par instance, mail au franchissement et rappel d'expiration à J-30. Carte kanban 282. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.7 KiB
title, area, horizon, tags, flag, src
| title | area | horizon | tags | flag | src |
|---|---|---|---|---|---|
| Seuil d'alerte sur le solde de crédits Studio (pas un nouveau plafond) | backend manager | v2 | studio, crédits | warn | Nouveau 16/09 · le plafond dur a été retiré exprès (décision 22) | studio-plan.md décisions 17 et 22 · StudioCreditService.cs · studio_credits_section.dart |
La limite demandée existe déjà, deux fois. Avec des crédits prépayés (décision 17), le solde est le plafond — c'est exactement pour ça que la décision 22 a retiré le plafond dur organisation le 13/09. Et le garde-fou contre le stagiaire qui vide le budget en une après-midi, c'est Instance.StudioPerUserDailyCap, déjà appliqué dans StudioCreditService.ReserveAsync (CreditError.DailyCapReached). Rien à ajouter de ce côté : ne pas recréer un plafond organisation.
⚠️ Le modèle n'est pas celui de Google AI Studio ni de fal.ai. Là-bas on est en postpayé : sans budget alert ni hard cap, on découvre la facture. Ici le client a payé avant ; il ne peut pas se faire surprendre par une dépense, seulement par une indisponibilité — et ça, ça ne se règle pas avec un plafond, mais avec un préavis.
Ce qui manque vraiment : le préavis. Aujourd'hui aucune alerte n'existe. studio_credits_section.dart affiche disponible / solde / réservé / expiration, mais il faut aller ouvrir l'écran Facturation pour les voir ; une génération qui échoue en InsufficientCredits est le premier signal reçu par le conservateur. Et surtout, l'expiration à 12 mois (décision 17) est le vrai piège : un solde qui s'évapore sans prévenir, sur une institution publique, c'est un litige — pas une notification manquée.
À faire : Instance.StudioCreditsAlertThreshold (en crédits, 0 = désactivé) + StudioCreditsAlertSentAt pour ne pas renvoyer le mail à chaque génération ; déclenchement dans StudioCreditService.Record quand le solde passe sous le seuil, et dans ExpireDueAsync (déjà un job quotidien) pour un rappel d'expiration à J-30. Envoi par IEmailService / ResendEmailService, déjà en place. Côté manager-app : un champ dans l'écran Facturation et un bandeau dans le popover de la jauge du pied de menu, i18n FR/EN/NL.
Petit lot : 2 colonnes, un hook, un template de mail, un champ d'UI. À faire après la fixation des prix (décision 16, fin du lot 3) — un seuil en crédits n'a pas de valeur par défaut tant que l'unité de crédit n'est pas arrêtée.