From ad73aefe380fd56157da3a60c5140253ac8a95bc Mon Sep 17 00:00:00 2001 From: Thomas Fransolet Date: Wed, 16 Sep 2026 15:29:16 +0200 Subject: [PATCH] =?UTF-8?q?Kanban=20r=C3=A9g=C3=A9n=C3=A9r=C3=A9=20:=2043?= =?UTF-8?q?=20chantiers=20planifi=C3=A9s?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) --- kanban.html | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/kanban.html b/kanban.html index 57af1b4..8a066cb 100644 --- a/kanban.html +++ b/kanban.html @@ -462,7 +462,7 @@
1Migration v3
2Bugs ouverts
12À tester
-
41Planifié
+
43Planifié
9Bascule prod
66Fait récemment
@@ -706,7 +706,7 @@
-

Planifié

41
+

Planifié

43
@@ -975,6 +975,17 @@ todo-features.md — AR
+
+
visitappmatérielNouveau 16/09 · le gros du coût est les Universal/App Links, partagés avec le QR
+

Tags NFC comme déclencheurs de section

+

Troisième déclencheur physique, à côté du QR et du beacon. Analyse et faisabilité : v2/nfc-triggers-plan.md.

+

⚠️ Deux recadrages par rapport à la formulation initiale. (1) Le déclencheur n'est pas un « POI » : dans MyInfoMate le POI est un point posé sur un GLB (VR/3D, immersif-frontiere-plan.md). Le déclencheur physique est une Section — Section.IsBeacon / BeaconId, lu par geo_beacon_trigger_service.dart:177. Le tag NFC se branche au même endroit que le beacon. (2) L'URL /t/{instanceId}/{code} et sa table de mapping n'ont pas d'équivalent existant à réutiliser : les QR d'aujourd'hui portent l'id de section directement dans l'URL (trois formats coexistants, ScannerDialog.dart:31-38), il n'y a aucun endpoint de résolution code → section. v1 = le tag porte la même URL que le QR, donc zéro entité, zéro endpoint, zéro CRUD ; l'indirection ne se justifie que si un client demande un parc de tags réassignables — et elle vaut bien moins qu'en QR, puisque réécrire un NTAG prend deux secondes alors qu'un QR se réimprime.

+

Le vrai coût est ailleurs : les Universal Links (iOS) et App Links (Android) n'existent pas. Aucun assetlinks.json ni apple-app-site-association sur nos domaines (le seul du workspace est dans OpenGlasses, qui n'est pas à nous), et app_links n'est branché que sur le retour de deep link Meta AI (main.dart:69). ✅ Ce lot bénéficie autant au QR : aujourd'hui un QR scanné par l'appareil photo natif n'ouvre pas l'app.

+

Dépendance : le fallback web d'un tag scanné sans app installée, c'est visitapp-web — pas encore déployé (carte « Déployer le visiteur web »). Sans lui, un tag scanné par un visiteur sans l'app tombe dans le vide.

+

Ce qui ne marchera pas, à dire au commercial : pas de lecture NFC depuis visitapp-web (WebNFC est Chrome/Android uniquement, jamais Safari), et l'écriture de tags depuis iOS est trop contrainte — l'écran admin de programmation sera Android-only. En contrepartie, iPhone XS+ lit un tag NDEF sans aucune app, ce qui est l'argument réel du canal.

+ nfc-triggers-plan.md · ScannerDialog.dart:31-38 · Section.cs:57 · main.dart:69 +
+
produitV2 · nouveau 12/08

Écran SuperAdmin — add-on IA & canaux d'une instance

@@ -1000,6 +1011,17 @@ v2/studio-plan.md — §8 (exécutable lots 0-4), §9 (catalogue v0), décisions 22-23
+
+
studiocréditsNouveau 16/09 · le plafond dur a été retiré exprès (décision 22)
+

Seuil d'alerte sur le solde de crédits Studio (pas un nouveau plafond)

+

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.

+ studio-plan.md décisions 17 et 22 · StudioCreditService.cs · studio_credits_section.dart +
+
manager-appvisitapptabletvrDécision arrêtée, à exécuter après la bascule

Loader animé — presets paramétriques, pas de format de fichier