Quotas

Un quota marqué non mesuré n'est pas à zéro : il n'est pas lu. Il ne reste que l'egress Supabase, que Supabase n'expose par aucune API publique — le chiffre facturé n'existe que sur la page d'usage de l'organisation, d'où le lien « voir ». Et il n'est pas lisible en SQL : edge_logs ne porte content_length que sur une partie des lignes, ce qui donnerait un minorant présenté comme une mesure. Les opérations R2 et les requêtes Workers se comptent au niveau du compte (c'est là qu'est le quota), depuis le 1^er du mois pour R2 et depuis minuit UTC pour Workers, dont le quota est journalier. Voir docs/PLAN_MONITORING_QUOTAS.md.

Plafond retenu : 300 envois sur 24 h glissantes (Google annonce 500 destinataires pour un compte personnel, mais l'envoi par SMTP est souvent bridé plus tôt) — pas par jour calendaire : un envoi d'hier 18 h compte encore aujourd'hui à 17 h. Au-delà, Gmail bloque les envois jusqu'à 24 h, sans prévenir. Le chiffre vient de notification_log : notifications, confirmations de compte parent et refus de demande y sont tracés (ces deux derniers depuis le 18 septembre 2026 seulement). N'y figurent pas : les courriels de Supabase Auth (mot de passe oublié…), s'ils passent par cette même boîte.

C'est le détail, et non le total, qui rend visible une croissance structurelle : en septembre 2026, cron.job_run_details pesait 46 Mo sur 223 — de l'historique d'exécution sans valeur, que la somme seule n'aurait jamais désigné (migration 0161).

Le registre medias_a_purger enregistre, il n'efface pas : la question « suppression d'un message = effacement du fichier, ou simple masquage ? » revient à la direction. Tant qu'elle n'est pas tranchée, relever coûte zéro et effacer serait irréversible.