MyInfoMate — tableau de chantiers

Port PostgreSQL exposé publiquement

À fermer via Traefik/Docker. Accès DBeaver par tunnel SSH uniquement.

L'API publique répond sans clé API

Constaté le 08/09 sur la préprod, depuis internet, sans authentification :

curl "https://api.mymuseum.be/api/Configuration?instanceId=633ee379d9405f32f166f047"
          → 200, avec le contenu complet et ses traductions

La même requête avec X-Api-Key renvoie le même 200. Cause exacte, vérifiée le 08/09 : Get (ConfigurationController.cs:52) et GetDetailAsync (:117) portent un [AllowAnonymous] explicite. Ce n'est donc pas une clé mal vérifiée, c'est une ouverture assumée — probablement héritée de la v2, où les apps visiteur n'avaient pas de clé. Les apps l'envoient pourtant (client.dart:54), et le mécanisme existe et fonctionne : ApiKeyAuthenticationHandler + la policy AppReadAccess, déjà utilisée par byPin (:83) et export (:383) du même contrôleur.

Ce que ça expose : le contenu éditorial de n'importe quelle instance, à qui connaît un instanceId — lequel se lit en clair dans un APK de flavor, ou se devine à partir d'un export. Pas de données personnelles, mais tout le travail éditorial d'un client.

✅ Audit complet fait le 12/09 — 40 routes anonymes recensées, dont 2 seulement contrôlent la clé (Configuration/{id}/export et Instance/{id}, tous deux corrigés en septembre). Le trou est donc général, pas ponctuel : 24 routes de contenu sont ouvertes — Configuration (2), Section (4), Resource (2), SectionMap (3), SectionEvent (3), SectionAgenda (2), SectionParcours (2), SectionQuiz (1), ApplicationInstance (2).

🔴 Trouvaille plus grave que la carte, corrigée le 12/09. GET /api/Instance/slug/{slug} était anonyme et sans filtrage : il rendait le pinCode — celui qui ouvre l'appairage des tablettes et des casques — plus l'adresse de facturation, le numéro de TVA, les quotas et le plan du client. Et le slug n'est pas un secret : c'est l'URL du site visiteur (app.myinfomate.be/{slug}). La fonction de filtrage StripCommercialFields existait déjà, avec un commentaire qui nommait le risque du pinCode — elle n'était simplement pas appelée ici. Corrigé sur slug et sur byPin, avec 3 tests qui verrouillent le contrat (243 tests au vert). Deux champs restent exposés à dessein : publicApiKey, sans laquelle visitapp-web ne peut pas s'amorcer, et isTrialActive, qui sert au filigrane d'essai affiché au visiteur.

⚠️ Ce que fermer les 24 routes apportera vraiment — et ce que ça n'apportera pas. La clé s'obtient anonymement : par le slug (qui est dans l'URL) ou par app-key avec le pincode. Après fermeture, le contenu ne sera donc pas confidentiel : il sera lisible par qui lit une URL, au lieu de qui devine un instanceId. Le gain réel est ailleurs, et il compte : plus d'énumération par identifiant, un accès tracé et révocable, et un seul chemin d'entrée au lieu de vingt-quatre. Rendre le contenu réellement privé serait un autre chantier, avec une autre décision produit.

Reste à faire : fermer les 24 routes de contenu. Deux obstacles connus. Un : [Authorize] de classe et d'action se combinent — c'est pour ça qu'export passe par [AllowAnonymous] + contrôle manuel ; il faut donc un attribut réutilisable, pas un simple changement de policy. Deux : deux routes doivent rester anonymes et c'est écrit dans le code de visitapp-web — instance/slug/{slug} (l'amorce, qui distribue la clé) et ApplicationInstance?instanceId= (la page /download, où le visiteur arrive d'un QR imprimé sans slug ni clé).

Le bucket Firebase est ouvert en écriture et en suppression à tous

Relevé le 14/09 sur le projet mymuseum-3b97f (release firebase.storage/mymuseum-3b97f.appspot.com, ruleset 025f98db-…, inchangé depuis le 08/01/2024) :

match /{allPaths=**} {
            allow read, write; //: if request.time < timestamp.date(2024, 1, 12)
          }

La garde temporelle du template Firebase a été commentée pour qu'elle n'expire pas. N'importe qui connaissant le nom du bucket — il est dans l'URL de chaque image, donc public — peut lire, lister, écrire et supprimer le contenu de tous les clients. Vérifié sans aucune authentification : GET firebasestorage.googleapis.com/v0/b/mymuseum-3b97f.appspot.com/o répond 200 avec la liste des fichiers.

Pourquoi ce n'est pas déjà fermé : le manager-app déployé écrit dans le bucket sans Firebase Auth. Fermer avant de déployer casse ses uploads. La fermeture est donc séquencée après la mise en production du lot 0 du Studio (upload par URL signée + ingestion serveur), comme le prévoit v2/studio-plan.md §8. ⚠️ La date de ce déploiement est donc une date de sécurité, pas seulement une date de feature — ne pas mettre la version actuelle en production sans traiter ce point dans la foulée.

Piège à traiter dans le même geste : le CORS du bucket de prod n'a aucun responseHeader. Le jour du déploiement, le PUT signé portant Content-Type et x-goog-content-length-range sera refusé au préflight et tous les uploads casseront. À corriger sur le bucket avant la bascule. Le bucket de dev mymuseum-3b97f-dev, lui, est déjà configuré correctement (CORS, cycle de vie incoming/, règles fermées) et sert de modèle.

Une piste applicable avant le déploiement, à vérifier : restreindre read/list seul. Les apps visiteur lisent par URL à jeton, qui ne passe pas par les règles ; reste à confirmer qu'aucun code client ne lit par le SDK Firebase.

Retirer la suppression de blob de manager-app

show_resource_popup.dart:130-137 supprime l'objet du bucket après avoir supprimé la ligne, et avale l'échec dans un print — un échec laissait un orphelin définitif que le quota ne comptait plus. Depuis C3 (12/08) le serveur supprime le blob avant la ligne : le client tombe désormais sur un objet déjà absent. Ce n'est plus dangereux, c'est devenu inutile. ⚠️ Ne pas le retirer avant d'avoir renseigné Firebase:StorageBucket en prod (carte « Bascule prod ») : la clé est vide par défaut, et sans elle le serveur ne supprime rien — retirer le code client ferait perdre la fonction au lieu de la déplacer.

La jauge de stockage ne bouge pas après un ajout de ressource

QuotaBarsWidget appelle instanceGetQuota une seule fois, dans initState (quota_bars_widget.dart:23), et il est monté dans le pied du menu latéral persistant (main_screen.dart:477) — jamais reconstruit en naviguant. Le chiffre affiché date de l'ouverture de la session ; ajouter ou supprimer un média ne le fait pas bouger avant un rechargement complet de la page.

⚠️ Le comptage lui-même est correct — ne pas partir chercher le bug côté serveur. storageUsedBytes est recalculé à chaque appel (SUM(SizeBytes), InstanceController.cs:383), et SizeBytes est renseigné à la création sur les deux chemins (multipart :277, JSON :341) puis confirmé à l'Update avec la taille réelle après compression. Le contrôle d'upload, lui, refait un GET /quota juste avant de téléverser (resources_screen.dart:186-198) : d'où l'incohérence visible pour le client — une jauge à « 0 KB » et un refus 413 sur le même chiffre, lu à deux moments différents.

Correctif : exposer un rafraîchissement de la jauge et le déclencher en fin de create() et de suppression de ressource. Pas de plomberie d'état à introduire pour ça.

La taille du téléchargement n'est jamais affichée

Le visiteur ne sait jamais combien il télécharge. Le dialogue de configurations_list.dart annonce « il est nécessaire de télécharger du contenu supplémentaire » sans chiffre, et l'écran de progression n'affiche qu'un pourcentage. Or une visite du Fourneau, c'est un ordre de grandeur de plusieurs centaines de Mo sur la 4G du visiteur.

Google Play exige que la taille des téléchargements complémentaires soit annoncée avant de les lancer — c'est une condition de publication, pas un confort.

Rien à ajouter côté serveur : ResourceDTO.sizeBytes existe déjà et arrive dans ExportConfigurationDTO.resources. La somme se calcule côté client, et sur les seules ressources réellement à télécharger — isResourceOutdated filtre déjà celles qui sont à jour, donc une mise à jour de visite doit annoncer le delta, pas le total.

Deux endroits : le dialogue de confirmation (avant), et l'écran de progression (« 128 / 412 Mo » plutôt qu'un pourcentage nu). ⚠️ La taille annoncée dans le dialogue suppose d'avoir déjà appelé configurationExport pour connaître la liste — aujourd'hui cet appel n'a lieu qu'après la confirmation.

Dock de filtres en paysage — carte et parcours

Deux calques se disputaient le coin bas-droit. Le lanceur de l'assistant est monté pour toutes les sections ([configId]/layout.tsx, right:20/bottom:20/z-1200) et recouvrait la bascule Carte/Liste de MapSection (z-1000) : c'est elle qui disparaissait. En parallèle le panneau de filtres, posé left-3 right-3, masquait en paysage la carte qu'on filtrait.

Le parti vient de tablet-app (Screens/Map/geo_point_filter.dart) : en paysage, colonne vitrée à gauche — recherche, catégories, liste des points — la bascule Carte/Liste disparaît puisque le dock est la liste, et la fiche du point passe en colonne droite. Portrait inchangé, feuille basse. Même traitement pour la progression cartographiée de ParcoursSection (étapes à gauche, étape en cours à droite).

⚠️ Rien n'a été vu tourner : next build passe, mais /api/ApplicationInstance répond [] — la base est vide, il n'existe aucune instance à ouvrir. À reprendre dès qu'un jeu de données existe, et à éprouver dans les quatre combinaisons (téléphone/tablette × portrait/paysage), plus le cas < 420 px de haut où le dock doit démarrer replié.

Primitives partagées, à réutiliser plutôt qu'à recopier : ui/FloatingPanel.tsx (dock ↔ feuille basse selon l'orientation), ui/PointFilter.tsx (recherche sans accents, cases, groupes), et surtout --mim-assistant-inset-y/-x + .mim-clear-assistant dans globals.css — l'encombrement de l'assistant est déclaré une fois, sinon la collision revient à la section suivante.

Latence vocale et commandes multilingues — à valider sur le terrain

Cinq réglages livrés le 13/08 dans voice_orchestrator.dart, tous à éprouver en visite réelle avec Viva et Marco, sur lunettes et téléphone.

1. done.mp3 retardait la réponse de toute sa durée — await _playDoneSound() juste avant speak(), et dans just_audio le future de play() ne se résout qu'à la fin de la lecture. En prime un doublon : la parole est le signal de fin. Retiré, helper et constante supprimés.

2. Sons préchargés — setAsset décodait à chaque wake word, sur le chemin le plus sensible à la latence du pipeline. 3. Escalade du son de réflexion — silence 700 ms, puis fondu d'entrée à 45 % ; une réponse rapide ne déclenche plus aucun son. ⚠️ stop() n'appelait pas _stopThinkingLoop() : le timer pouvait jouer une nappe après l'arrêt de l'orchestrateur.

4. Les commandes n'existaient qu'en français — _isStopCommand et les trois autres cherchaient « répète », « arrête », « prends » en dur. Les quatre listes couvrent FR/NL/EN/DE, et le matching passe de contains à mot entier. ⛔ Ce changement a révélé deux faux positifs déjà présents : « je ne comprends pas » déclenchait une photo, « raconte encore une histoire » rejouait la réponse précédente. Et code nu ne déclenche plus de scan QR (« what's the code of this painting »). 16 cas joués via dart run, 16/16.

5. Limite 4 langues actée dans le code. flutter analyze lib/Services/Glasses/ → 0 erreur.

Écran Statistiques refondu + export PDF

Écrit et analysé, jamais ouvert dans un navigateur. À vérifier sur données réelles : la règle mono-canal, le rendu des titres longs dans les barres. Sur le PDF : les accents, et le logo — s'il manque, c'est le CORS du bucket Firebase, le rapport doit se générer quand même. Et après database update : que les instances soient bien passées à 395 jours (pas seulement les plans), et que le job visit-events-purge déclenché à la main ne supprime rien.

Visite hors ligne sur device

15 cas : images d'articles, audios, extensions de fichiers, fraîcheur, dégradation des types non offline. Conditionne l'urgence de tous les bugs hors ligne.

✅ Débloqué par K5 (12/08, les trois flavors construisent). Valide désormais aussi D2, D3 et D4, livrés le 12/08 — audio/mpeg reconnu, purge des fichiers obsolètes réactivée, filtre de fraîcheur sur dateUpdate.

⚠️ Deux cas à ajouter au §21 avant de le jouer, ouverts par D2 : (1) montée v3 → v4 de la base locale sur un device portant déjà une visite — elle ne doit rien re-télécharger ; (2) device portant des <id>.unknown — le MP3 doit être re-téléchargé et devenir lisible. Le second est le seul qui prouve que D3 répare le parc existant, pas seulement les installations neuves.

iBeacons sur device réel — Android et iOS

Les 5 cas du §9 sont écrits et aucun n'est coché : le déclenchement par balise n'a jamais été observé sur un téléphone. Vendu dans Pro et Premium (« Offline + beacons BLE » sur la landing), donc à prouver avant la première vente, pas après. Exige du matériel en main — d'où la carte de sourcing en « Planifié ».

⚠️ Le piège est iOS, et il est dans le code. geo_beacon_trigger_service.dart:148-155 ne pose une région filtrée que sur iOS, avec un proximityUUID en dur (FDA50693-A4E2-4FB1-AFCF-C6EB07647825) ; Android scanne Region(identifier: 'GlassesBeacon') sans filtre. Conséquence : une balise réglée sur un autre UUID marche sur Android et reste invisible sur iOS — et le test passerait sur le seul device qu'on a sous la main. Soit les balises commandées émettent cet UUID, soit il devient configurable. À trancher avec le sourcing, pas pendant le test.

⚠️ Deux chemins de scan à jouer séparément, ils ne partagent pas leur code : configuration_page.dart:197-205 (notification beaconFound) et geo_beacon_trigger_service.dart:166-189 (déclenchement proactif de l'assistant). ⚠️ Et configuration_page.dart:43 dit int meterToBeacon = 100; // 15 meters — le commentaire et la valeur se contredisent, et Section.meterZoneGPS, configurable par section dans manager-app, est ignoré. Un test à 100 m ne mesure rien : la distance de déclenchement est la seule chose que ce chapitre doit établir.

À mesurer sur place, pas au bureau : portée réelle derrière un mur, temps entre l'entrée en zone et la notification, et absence de spam quand on stationne devant un POI (le cooldown).

Onboarding self-service complet

Inscription, création d'instance, essai 14 j, Stripe, 9 emails Resend, job de cycle d'essai. Code écrit et compilé, aucun parcours joué. Reste l'alias onboarding@ et le whsec_ Stripe CLI.

Chasse au trésor / carnaval — cas E

Le scénario le plus complet : SectionMap + SectionParcours + géodéclenchement + questions + mode jeu, d'un seul tenant.

Parité par type de section

« Tout ce que je configure est-il visible ? » — le chapitre qui valide les 13 types sur les deux apps visiteur.

Porte d'entrée build

5 commandes, bloquant absolu. flutter analyze et next dev ne prouvent rien — seuls les vrais builds disent la vérité.

Médiathèque codée de bout en bout — checklist à passer au navigateur

Home v3 — téléchargement hors ligne porté, et mort de l'ancienne home

Trois trous de home_3.0.dart comblés le 2026-09-08, aucun vu tourner sur device.

(1) Les configurations désactivées s'affichaient. isActive ne vit pas sur ConfigurationDTO mais sur le lien config↔canal (AppConfigurationLinkDTO.isActive, ce que bascule app_configuration_link_screen:407). Ni le fetch par liens ni le set mobileConfigIds ne le lisaient. ⚠️ L'ancienne home avait le même bug — ce n'était pas une régression de la v3. La référence était à côté : visitapp-web/src/lib/api/client.ts:170 filtre déjà link.isActive && link.configuration.

(2) Une visite hors ligne était un cul-de-sac. Pas de bouton télécharger, pas de garde : la tuile ouvrait ConfigurationPage, et body.dart:250 lisant ses sections uniquement en base locale quand isOffline est vrai, le visiteur voyait un détail vide, sans message ni erreur. Porté depuis configurations_list.dart : badge en pastille de verre sur la tuile bento (↓ / ✓), tuile ternie tant qu'elle n'est pas prête, dialogue sombre choix de langue + progression (DownloadConfigurationWidget réutilisé tel quel). Zéro nouvelle clé i18n, tout existait dans les 10 langues.

⚠️ Piège trouvé en câblant : alreadyDownloaded se déduisait des lignes de la table configurations — table dans laquelle le fetch écrit une ligne par visite pour cacher order/gridSpan. Au deuxième lancement, toutes les visites se seraient déclarées téléchargées, et le clic aurait rouvert un détail vide. L'état se déduit maintenant des sections en base locale, ce que lit le détail.

(3) Passe visuelle. Nouveau Components/GlassPill.dart (verre dépoli, 3 usages) : le cog devient Icons.tune + drapeau de la langue courante en pastille, GlassesStatusWidget passe sur la même pastille, et la feuille de réglages passe en sombre — une feuille blanche dans une app noire était le contraste le plus violent de l'écran.

✅ À supprimer une fois validé sur device : Screens/Home/home.dart et Screens/Home/configurations_list.dart. Ils ne sont plus référencés par personne — HomePage est orphelin, CustomAppBar, main.dart:220, body.dart:122 et menu_page.dart:136 pointent tous sur HomePage3. Ils n'étaient gardés que pour le téléchargement, qui vient d'être porté. Ne les supprimer qu'après avoir joué §21 du test-plan sur device : ce sont les seules références du comportement d'origine si le portage se révèle incomplet.

⚠️ Deux verrues mises en lumière, pas corrigées. downloadPrompt annonce « 39,8MB » en dur dans les 10 langues et aucune donnée de poids n'existe côté DTO (la colonne weightMasonryGrid a été abandonnée en v3) : soit la taille entre dans l'export, soit le chiffre sort du texte. Et home_3.0.dart:904 porte isOnline = true; // Todo remove if not local test — la branche hors ligne ne s'exécute jamais (l'analyzer le confirme, dead_code juste après) : une visite téléchargée s'ouvre, mais l'accueil en mode avion passe quand même par le réseau.

QR codes, nom d'application, page /download et notifications de proximité

Codé dans les quatre repos, rien n'est committé :

• ApplicationInstance (par app, Mobile ≠ Web) : IsQRCodeEnabled (défaut true), AppName (traductions), AppStoreUrl/PlayStoreUrl (modifiables par un SuperAdmin seulement, contrôlé côté API). Migration AddAppNameQrAndStoresToApplicationInstance.
• Scan mobile : id brut (QR du Fort) résolu via la section puis sa visite, y compris depuis l'accueil ; les URL web.mymuseum.be (MDLF) restent lues ; nouvelle URL app.myinfomate.be/download/…. QR d'une autre instance refusé.
• QR du manager : app.myinfomate.be/download/{instance}/{config}/{section} — ou la section web directement pour une instance web seule.
• visitapp-web : page /download (nom, image principale, liens stores), bouton de scan conditionné, nom de l'app sur l'accueil et dans l'onglet, suggestion de proximité GPS dans la page. Slugs download/demo/api réservés.
• Proximité mobile : beacon + zones GPS (meterZoneGPS). App ouverte → popup ; écran verrouillé pendant une visite → notification, dont le tap ouvre la section. Android : service de premier plan location ; iOS : mode d'arrière-plan location. App tuée : rien, par choix.

⚠️ Reste à faire hors code :

• Redirection 301 web.mymuseum.be/{i}/{c}/{s} → app.myinfomate.be/download/{i}/{c}/{s}, pour les QR MDLF scannés à l'appareil photo. Le domaine n'est routé dans aucun compose des repos : à poser là où il est servi.
• app.myinfomate.be n'est pas encore déployé (carte 210) : les QR générés par le manager y mènent, les deux partent en prod ensemble.
• Stores : déclarer le service de premier plan de type location dans la Play Console ; justifier le mode location à la revue Apple.

Bug corrigé au passage : la popup beacon (BeaconArticleFound) lisait les maps JSON brutes de currentSections comme des SectionDTO et plantait.

Porter l'orientation paysage dans les deux apps Flutter

Le web a pris de l'avance sur deux écrans : ArticleSection (deux volets côte à côte, lecteur audio ancré) et maintenant le dock de filtres de la carte. Les équivalents Flutter n'ont aucune règle d'orientation — grep Orientation sur mymuseum-visitapp ne ramène que quizz_page.dart.

⚠️ Une question précède l'écran : mymuseum-visitapp autorise-t-elle seulement le paysage ? Coder un rendu paysage pour une app verrouillée en portrait, ce serait du code mort. À lire dans main.dart avant de commencer.

tablet-app n'est pas une cible pour la carte : verrouillée en paysage (main.dart:105), c'est elle qui possède le panneau flottant d'origine, et le web n'a fait que l'emprunter. Y reste l'article deux volets, et l'harmonisation du panneau (verre, pastille de repli, compteur) avec ce que le web vient de poser.

Découpage du TTS par phrase — le seul vrai levier de latence

Le time-to-first-audio est aujourd'hui la somme de tout : LlmClient.chat() retourne un future de réponse complète (pas de flux) et GeminiTtsEngine._synthesize() fait un generateContent unaire qui attend tout le PCM avant d'écrire le WAV. C'est ce trou que la nappe de réflexion bouche.

Le remède ne dépend d'aucune API nouvelle : découper result.reply en phrases, synthétiser et jouer la première pendant que les suivantes se préparent. Le time-to-first-audio tombe à LLM + TTS(1 phrase). Contenu dans GeminiTtsEngine — ni l'orchestrateur ni le backend ne bougent.

⏸️ Volontairement pas fait avec le reste du lot du 13/08 : c'est le seul chantier structurant des six, il mérite un feu vert séparé. ⚠️ À vérifier avant : :streamGenerateContent émet-il des chunks audio progressifs sur gemini-2.5-flash-preview-tts ? Test curl de 20 min — à faire, pas à supposer.

Accusé de réception parlé à la place du bip du wake word

Remplacer wake_detected.mp3 par une phrase dans la langue et la voix du visiteur — « Oui, je vous écoute » — avec 2-3 variantes, un visiteur entendant l'ack des dizaines de fois sur une visite.

Retenu, mais explicitement après les tests : ça demande de générer et valider à l'oreille ~40 fichiers (2 voix × 4 langues × 5 phrases), et une partie du besoin que l'ack compense disparaît si le découpage par phrase fait baisser la latence. Décider avant d'avoir entendu le flux, ce serait décider à l'aveugle.

⚠️ Trois pièges déjà identifiés. pubspec.yaml:133 déclare assets/sounds/ mais les déclarations de dossier ne sont pas récursives en Flutter. Générer avec exactement le même voicePrompt que le runtime, sinon le timbre décroche entre l'ack et la réponse — et Gemini TTS n'est pas déterministe, prévoir plusieurs prises. ⛔ Et une règle de cohérence non négociable : sans GEMINI_API_KEY le moteur retombe sur la voix système Android — des acks en Sulafat suivis d'une réponse en voix système seraient pires que le bip. Acks actifs seulement si le moteur runtime est Gemini et que la voix correspond à guideVoiceId.

Ordonnancement à calibrer sur place : ouvrir le micro à player.duration - 150ms plutôt que de faire de l'AEC — sur Ray-Ban, micro et haut-parleur partagent la monture.

Live API Gemini — audio natif bidirectionnel

Supprimerait les trois maillons Whisper → LLM → Gemini TTS au profit d'un WebSocket permanent : flux micro brut en entrée (PCM 16 kHz), flux audio en sortie (24 kHz), sans jamais passer par du texte. Débloque trois choses que l'architecture actuelle ne peut structurellement pas faire : le barge-in (couper la parole à l'assistant), le VAD côté serveur (fin du timeout: 5 secondes en dur de _listenForFollowUp) et une latence de l'ordre de la seconde. Les voix prébuilt sont de la même famille — Viva/Marco survivraient.

Le point dur n'est pas l'audio, c'est le tool calling. Les outils (GetSectionDetail, RAG) vivent dans manager-service. Deux options : l'app parle directement à Gemini (latence minimale, mais logique métier déplacée dans le client et jetons éphémères obligatoires — on ne met pas une clé Gemini dans un APK de visiteurs), ou manager-service proxifie le WebSocket (clé au chaud, prompt et stats gardés, mais relais audio temps réel en C# avec sessions, reconnexions et backpressure). C'est l'option B qui a du sens, et c'est elle qui coûte cher.

⚠️ Le modèle de coût change de nature : plus à la requête mais à la session ouverte, avec des jetons audio bien plus chers. 80 visiteurs simultanés = 80 sessions. À chiffrer, les tarifs ne sont pas connus ici. ⚠️ Sessions à durée limitée, reprise à gérer sur réseau mobile en bâtiment de pierre. ⛔ Modèles en preview — après l'historique ElevenLabs → Gemini, y accrocher une fonction vendue serait imprudent. Verdict : spike chiffré d'une journée avant toute décision.

Nettoyer downloadConfiguration.dart

Trouvé en livrant D4 le 12/08, laissé volontairement hors périmètre du lot D. Deux blocs morts dans le même fichier :

1. ~130 lignes de classe commentée — /*class DownloadConfiguration { ligne 328 jusqu'au */ ligne 461. C'est ce bloc qui a fait croire au plan V1 que « les deux chemins de téléchargement divergent » : la ligne citée comme preuve vivait dedans. Un doublon commenté qui ressemble à du code actif coûte plus cher que pas de code du tout — il a produit un diagnostic faux.

2. cleanLocalResources, appelée nulle part — et non réactivable telle quelle : la table locale resources n'a pas de colonne configurationId, elle est globale à toutes les visites, et le paramètre configuration de la fonction n'est jamais utilisé. Deux issues : la supprimer, ou lui donner un périmètre en ajoutant la colonne. ⚠️ Conséquence à assumer si on supprime : les lignes DB des ressources retirées d'une visite ne sont purgées par personne. Impact réel faible — rien ne les lit pour le rendu, CachedCustomResource retrouve le fichier en listant le répertoire — mais la table croît sans borne.

Carte hors ligne — tile packs Mapbox

Aujourd'hui aucune carte ne fonctionne hors ligne, et ce n'est pas une question de données : MapDTO porte déjà points, centerLatitude, zoom et iconResourceId, et les icônes sont téléchargées avec la visite. C'est le fond qui manque — les tuiles sont chargées en réseau, sans cache.

Le GPS, lui, n'est pas le problème : geolocator ^13.0.0 lit le GNSS, qui est autonome. Seule réserve à annoncer au client : sans A-GPS, le premier point peut demander 30 à 60 s sous couvert forestier.

Le chemin court existe déjà dans le pubspec : la version résolue est 2.8.0 (pas 2.0.0 comme le laisse croire la contrainte), et le paquet installé contient bien OfflineManager, TileStore, StylePackLoadOptions, TileRegionLoadOptions et TileRegion — vérifié dans le cache pub, pas supposé. On télécharge une emprise bornée au moment du téléchargement de la visite ; pour un domaine comme le Fourneau, quelques dizaines de Mo.

✅ Mapbox est désormais le fournisseur par défaut (04/09) : le null retombait sur Google dans map_page.dart (deux endroits) et map_config.dart. ⚠️ Effet de bord à surveiller — les sections carte existantes de MDLF et Fort Saint-Héribert dont le mapProvider est null basculent silencieusement de Google à Mapbox. Le token est déjà en place, en dur dans main.dart:60.

⚠️ Ce n'est pas gratuit, et le compteur est le mauvais : ce qui coûte n'est pas la surface de l'emprise mais le nombre de téléchargements — un tile pack par visiteur. La facture monte donc avec la fréquentation, c'est-à-dire avec le succès du client. Grille à vérifier chez Mapbox, ligne « tile packs » et pas seulement « map loads ». C'est exactement ce calcul que supprime v2/plan-illustre-plan.md.

⛔ Google est une impasse, et pas seulement techniquement. Le SDK Maps pour Android n'expose aucune API de tuiles hors ligne — les « zones hors connexion » sont une fonction de l'app Google Maps, pas du SDK intégrable. Et le code n'utilise même pas ce SDK pour les sections carte : il passe par flutter_map sur https://mt1.google.com/vt/lyrs=m&x={x}&y={y}&z={z}, un endpoint non documenté dont la mise en cache est explicitement interdite. Conclusion : Mapbox devient le fournisseur du mode hors ligne, Google reste en ligne seulement.

⚠️ Tant que ce chantier n'est pas fait, SectionType.Map reste volontairement hors de offlineCapableSectionTypes (downloadConfiguration.dart) : l'ajouter donnerait une carte grise, ce qui est pire que ne pas la proposer. Une fois les tuiles packagées, c'est une ligne à ajouter dans cette constante.

Plan illustré — un 3^e fournisseur de carte, sans tuiles

Un musée de plein air ne distribue pas un fond OpenStreetMap, il distribue son plan dessiné. Conception complète, modèle de données et périmètre par repo : DOCS/v2/plan-illustre-plan.md. Rien n'est implémenté.

La décision qui structure tout : les repères se posent directement sur l'image, à la main, et c'est cette position qui fait foi — un plan dessiné n'étant ni à l'échelle ni orienté au nord, projeter des GeoPoint depuis leurs coordonnées les ferait tomber à côté des bâtiments. Le calage GPS ne sert qu'à afficher le visiteur, et devient donc facultatif.

⚠️ Deux affirmations de la première version de cette carte étaient fausses, corrigées le 04/09 : on ne projette pas les repères, et deux points d'ancrage ne suffisent pas — il en faut trois pour une transformation affine qui absorbe rotation et étirement, et pour pouvoir vérifier le calage au lieu de diluer l'erreur.

✅ Le calage se fait assis : cliquer le même angle de bâtiment sur le plan puis sur une carte réelle en regard. GeolocInputContainer ouvre déjà un FlutterLocationPicker (vraie carte, recherche d'adresse) — le composant est écrit, il faut le mettre à côté du plan. Plus besoin de prestation d'installation.

✅ Hors ligne gratuit : le plan est une Resource, une ligne dans GetReferencedResourceIds() et le pipeline existant l'embarque. Aucun tiers, aucun quota — contrairement aux tile packs Mapbox, facturés par visiteur.

⚠️ Conséquence web à trancher : visitapp-web reste sur Leaflet (lot E, W1), et mapProviderMobileOnlyNote le dit déjà au client. Pour un plan illustré c'est bloquant — le plan est le produit. Soit on porte le rendu en CSS dans la foulée, soit le plan Essentiel, web-only, n'y a pas droit.

Livrable qui se vend seul : le plan sans calage — téléversement, pose des repères, rendu, hors ligne. C'est le produit que les audioguides vendent depuis trente ans.

Les swagger.yaml embarqués sont périmés

Relevé en livrant D2 le 12/08. Les trois lib/api/swagger.yaml (manager-app, mymuseum-visitapp, tablet-app) décrivent un ResourceDTO qui n'a ni sizeBytes (ajouté à l'époque de C1/C3) ni dateUpdate (D2).

Ce sont des artefacts de génération, et le client s'édite à la main : ils ne sont plus la source de vérité. Le risque n'est pas fonctionnel — rien ne les lit à l'exécution — mais ils contredisent le code en silence, et c'est exactement ce qui a coûté du temps sur le « fallback Voice → Mobile » du lot F : une doc affirmative et fausse. Deux issues : les régénérer une fois et les tenir, ou les supprimer et assumer que le Swagger en ligne est la seule référence.

La colonne path de la table resources est écrasée à vide

Trouvé en livrant D2 le 12/08. DatabaseHelper.insert fait un UPDATE de la ligne entière quand l'id existe déjà : la boucle qui enregistre la charge de ressources (héritée de D1) repasse derrière la boucle de téléchargement et réécrit path avec la valeur par défaut de ResourceModel, soit "".

Sans effet aujourd'hui : personne ne lit cette colonne pour le rendu. Mais elle est NOT NULL et prétend porter le chemin local — le premier code qui s'y fiera trouvera une chaîne vide, sans erreur. Même famille que le dateUpdate effacé par la même boucle, corrigé en D2 parce que lui, il est lu. Deux issues : renseigner path dans les deux boucles, ou retirer la colonne et assumer que le répertoire fait foi.

Se référencer dans l'annuaire Fournisseurs des Musées (OCIM)

Le site est édité par l'OCIM (Office de Coopération et d'Information Muséales) avec France Edition Multimédia — pas un annuaire SEO anonyme, mais la porte d'entrée que des musées francophones utilisent réellement pour chercher un prestataire. Deux mécanismes distincts sur le site : l'annuaire (fiche permanente, inscription annoncée comme gratuite, formulaire demandant coordonnées, contact et exactement trois thématiques — « multimédia » est la catégorie évidente pour MyInfoMate) et SOS Fournisseurs, où un musée décrit un besoin et reçoit des propositions.

Ce qui reste à investiguer, et qui décide de la valeur réelle : les demandes SOS sont-elles diffusées à tous les inscrits de la thématique ou faut-il une formule payante pour les recevoir ? Le tarif n'est affiché nulle part — à demander, pas à supposer (contact@francedit.com). Vérifier aussi ce que donne l'annuaire une fois dedans : combien de fiches en « multimédia », comment elles sont classées, et si une fiche gratuite est visible ou noyée.

⏸️ Pas avant que la prod soit stabilisée — même raison que la reprise de contact avec le Musée d'Ixelles : une fiche publique renvoie vers un produit qu'il faut pouvoir montrer. ⚠️ Le site est orienté France ; vérifier qu'un fournisseur belge y est accepté et bien référencé.

Reprendre contact avec Louise Smets — Musée d'Ixelles

Une fois la prod stabilisée, pas avant : on n'ouvre pas une conversation en montrant un produit en cours de bascule. Premier temps d'écoute — comprendre ce qu'est réellement son travail au quotidien et sur quoi elle bute — avant de parler de MyInfoMate. L'entraide se décide ensuite, pas dans le premier message. ⚠️ Rien n'est su de son rôle exact à ce stade : à ne pas supposer.

Rapport de stats — envoi mensuel automatique

Le rapport à la demande est livré (07/08, généré côté client). Reste l'envoi automatique, seule partie qui exige vraiment le backend : personne n'a son navigateur ouvert le 1^er à 6 h. QuestPDF + Hangfire, config destinataires/fréquence, et une méthode d'envoi avec pièce jointe — les 10 méthodes d'IEmailService sont des templates figés sans attachement. ⚠️ QuestPDF exige libfontconfig1 + une police, absents du Dockerfile : ça marche en local sous Windows et casse dans le conteneur.

AuditLog n'a aucune purge

VisitEvent purge à 13 mois, VisitorQuestion à 90 jours, AuditLog à jamais. C'est un sujet RGPD et rien d'autre : la table porte UserId, et les valeurs avant-après d'une modification de User contiennent e-mail, prénom et nom. Ce n'est pas un sujet de volume — l'inondation par WeatherSyncService est coupée depuis le 12/08, la table croît désormais au seul rythme des éditions humaines. Donc à traiter au lot J, pas au lot F. Recommandation : 12 mois, uniforme, via un AuditLogPurgeService calqué sur VisitEventPurgeService — 12 et non 13, le 13 mois des stats existe pour comparer une saison à la précédente et le recopier ici serait du mimétisme. ⚠️ Reprendre le même verrou : purge inerte tant qu'Audit:RetentionDays n'est pas défini, le pg_dump quotidien n'étant toujours pas en place — supprimer des lignes d'audit sans restauration fine est la pire combinaison. Écarté : garder les Delete plus longtemps que les Create/Update, ça double les règles pour un cas qu'une sauvegarde couvre déjà.

RAG sur le contenu CMS — vector store, jobs, outil SearchKnowledge

Persona simple : réponses sourcées sur le contenu existant. Pas d'ingestion documentaire, pas d'OCR, pas de TTS — c'est ce qui le rend tenable en V1.

Livré le 10/08 : IngestionService (chargement des collections filles par sous-type, un jeu de morceaux par langue), serveur Hangfire dédié à 2 workers, garde AiTokensPerMonth > 0 — plan-starter est à 0 — et SearchKnowledge ajouté aux outils d'AssistantService plutôt qu'un /ask concurrent, avec sa règle dans les 4 prompts.

Joué contre la vraie base et la vraie API le 10/08 : 52 sections → 2150 morceaux en 53 s. Deux défauts que seule l'exécution pouvait montrer, corrigés dans la foulée. 1) Les gabarits de LanguageInit étaient indexés : les cinq premiers résultats d'une question en néerlandais étaient des NL - Title NL - Description, le bonus de langue suffisant à les faire passer devant du vrai contenu français — le cas même que le cross-lingue devait servir. 2) Le même paragraphe occupait trois des cinq résultats, au même score : DistinctBy(Text) avant le Take. ⚠️ Le post-filtrage HNSW reste non éprouvé à plusieurs instances — il n'y en a qu'une en base locale, soit le cas où le problème ne se voit pas.

Les deux angles morts du découpage sont fermés : HTML retiré avant l'embedding, et ligne trop longue recoupée à la fin de phrase — sans quoi un article dépassait l'entrée max de gemini-embedding-001 et l'échec emportait les 50 morceaux du lot.

Déclenchement unifié : l'Enqueue par contrôleur et un intercepteur EF ont coexisté une demi-journée. Retenu : SectionIndexingInterceptor seul — les 5 sous-contrôleurs totalisaient 30 SaveChanges et 0 Enqueue, donc ajouter 40 points d'intérêt à une carte ne réindexait rien.

RGPD — ce qui reste est juridique, plus du code

✅ Tout le volet codable est livré le 13/08 : table d'agrégats de thèmes, job de regroupement, interrupteur de collecte par instance, mention affichée dans l'assistant. Voir « Fait récemment ».

Reste, et rien de tout ça ne s'écrit en Dart ou en C# : la relecture juridique du §8 des CGU (rédigé côté produit, jamais validé — priorité au §8.6 sous-traitants et au §8.5 transfert hors UE), la vérification des conditions réelles de Google (l'API Gemini offre-t-elle une résidence européenne ? un DPA est-il signé ? la réponse réécrit le §8.5), et la décision sur un DPA séparé — l'article 28 exige un acte écrit, et une commune ou un musée subsidié en demandera un en annexe.

⚠️ Deux traductions à commander avec cette relecture. La mention aux visiteurs n'existe qu'en FR/NL/EN alors que l'app porte 10 langues : les 7 autres replient sur l'anglais, faute de traduction relue. Traduire soi-même une mention de protection des données n'est pas une coquille d'interface qu'on rattrape après.

⚠️ Et une question ouverte au passage : activer WHISPER_API_KEY ajouterait OpenAI comme sous-traitant, que le §8.5 ne mentionne pas — il ne parle que de Google. La clé est vide aujourd'hui, c'est le moteur du device qui transcrit. À trancher avant de l'activer, pas après.

✅ L'échéance n'est pas la bascule mais la première question d'un visiteur réel — rien n'est collecté aujourd'hui, le délai de 90 jours n'a pas commencé à courir.

Écrans du lot design — vérification à l'œil

Deux écrans neufs compilent (flutter build web ✅) mais n'ont jamais été affichés dans un navigateur — le défaut récurrent de ce tableau. Le Guide IA (coquille à onglets, aperçu de conversation, carte de connaissance) et l'éditeur de parcours refondu (rail d'étapes, panneau, questions dépliées, enregistrement à la saisie).

Exige un manager-service qui tourne et une session ouverte : flutter run -d chrome, puis comparaison côte à côte avec claude design/guide-ia-screen.html et claude design/sectionparcours-refonte-flux.html. Pour le parcours, rejouer aussi test-plan.md §19.13 cas 0.

Ingestion documentaire + OCR

PdfPig avec cascade OCR Gemini (~0,03 $ / 100 pages). Word, PowerPoint, images. Legacy .doc/.ppt refusés à l'upload.

TTS pré-généré — audioguide multilingue

Le produit que les musées achètent depuis toujours, à coût marginal quasi nul. Aucun concurrent de cette gamme ne le fait.

Précisé le 28/08 — le volet commercial, absent du plan technique jusqu'ici. Audio par POI, pré-généré et embarqué dans le bundle offline : ce n'est plus « des textes sur un téléphone » qu'on vend mais un audioguide, face à des audioguides physiques à plusieurs milliers d'euros. La catégorie de produit change, donc l'argumentaire aussi.

⚠️ Facturer la génération, pas le stockage. Sinon la correction d'une coquille relance un cycle TTS complet sur toutes les langues, sans qu'un octet stocké n'ait bougé — le client paierait le mauvais compteur. ⚠️ Prérequis avant toute annonce sur le site : pilotable en self-service depuis le back-office ; à défaut, badge « Bientôt » et rien de plus. Un client qui doit nous écrire pour régénérer un audio n'achète pas une fonctionnalité, il achète une prestation.

Argument accessibilité — déficients visuels, FALC, seniors : souvent exigé en secteur public, parfois clé de subside. À rapprocher du chantier WCAG. Premier upsell identifié : le Fourneau Saint-Michel, une fois ses 20 bâtiments saisis.

Sourcing balises iBeacon extérieures — écrire à Holyiot, sinon Feasycom

Premier geste, un mail à Holyiot (vendeur AliExpress) : reste-t-il du 22044-beacon-BP-3a-V1.0 ou une révision ultérieure ? Trois exigences à faire confirmer par écrit, pas déduites d'une fiche produit : piles AA ou AAA remplaçables (une CR2450 soudée ou non accessible disqualifie le modèle — on ne redéploie pas 20 balises pour changer une pile), UUID / major / minor configurables, et remontée de l'état de batterie. Sans réponse ou sans stock : même demande à Feasycom, sur la référence FSC-BP104D (IP67, 2×AAA, multi-slot iBeacon + Eddystone UID/URL/TLM) — la faire confirmer sur les trois mêmes points plutôt que sur sa fiche produit.

⚠️ La batterie doit passer par le major, pas par le minor — vérifié dans le code le 28/08 : l'app identifie le POI par le seul minorId (geo_beacon_trigger_service.dart:177 et configuration_page.dart:205, comparés à beaconSection.minorBeaconId). Encoder un niveau de batterie dans le minor casserait l'identification du point d'intérêt. Le major, lui, n'est lu nulle part dans les deux apps : c'est le seul champ libre. À demander tel quel au fournisseur — « batterie dans le major », pas « batterie dans major ou minor ».

⚠️ Et à faire confirmer avec : l'UUID d'émission. iOS ne voit que l'UUID codé en dur dans le service (voir la carte de test §9). Une balise non réglable sur cet UUID impose de rendre le champ configurable — c'est du code, donc à savoir avant de commander, pas à la réception.

Alternative propre si les fournisseurs bloquent sur le major : une balise multi-slot émettant iBeacon + Eddystone-TLM en parallèle, le TLM portant tension et température par construction. ⚠️ Mais c'est un second mécanisme de scan à écrire — le beacon_scanner actuel travaille sur les régions iBeacon, et sur iOS CoreLocation n'expose pas les données d'annonce brutes : il faudrait un scan BLE parallèle et une corrélation. Le major est le pis-aller qui ne coûte aucune ligne de code ; le TLM est plus juste et plus cher. Trancher au vu des réponses, pas avant.

Commander 2 ou 3 exemplaires avant tout volume, et exiger une photo du boîtier ouvert. Autres critères pour le plein air (Fourneau Saint-Michel) : IP67, couvercle à vis ou quart de tour, doc CE/RED — exigible en marché public. Piles lithium primaires (L91/L92) plutôt qu'alcalines : tenue au froid, pas de coulure ; contrepartie, leur décharge est plate, donc surveiller aussi l'âge de pose. Joint à regraisser à chaque changement, sachet déshydratant dans le boîtier, pas de fixation sur métal.

Le raccourci à garder en tête : le bois est transparent au BLE. Monter les balises à l'intérieur des bâtiments côté entrée règle la plupart des POI du Fourneau, et réserve l'IP67 aux points réellement isolés — moins de matériel exposé, moins de piles à changer sous la pluie.

Chiffrer les frais de mise en place sur la page tarifs

Le défaut est de confiance, pas de design. La carte Pro annonce €99/mois et, juste dessous, setupFeeNote = « Frais de mise en place + engagement 12 mois (app mobile) » — sans aucun chiffre (translations.ts:272, repris tel quel en EN/NL/DE). L'acheteur budgète 1 200 €/an, puis découvre le setup en rendez-vous : c'est le pire moment pour l'apprendre. Remède : « à partir de X € selon le volume de contenu », dans les 4 langues. Priorité n°1 de la passe.

⚖️ Arbitré le 10/09 : pas de montant affiché. Thomas ne veut pas publier de plancher. Mesure de repli appliquée le même jour, dans les 4 langues : setupFeeNote devient « Frais de mise en place uniques, chiffrés dans le devis + engagement 12 mois », et la FAQ de la nouvelle page /tarifs précise ce que couvrent ces frais (configuration et publication sur les stores) et qu'ils sont chiffrés avant signature. L'acheteur sait donc qu'une ligne s'ajoute, et quand il en connaîtra le montant. Ce qui reste ouvert : si un plancher est un jour décidé, c'est cette carte qui le porte.

Secondaire, même passe : badge « IA incluse » sur Premium — le badge « Recommandé » reste sur Pro (HomeClient.tsx:525), il ne se déplace pas ; regrouper assistant IA + traduction automatique + audio sous un intitulé unique type « Studio IA » plutôt que trois lignes de features indistinctes ; remplacer le stockage en GB (1 / 15 / 50 GB, en dur dans HomeClient.tsx et SegmentPageClient.tsx) par une métrique que l'acheteur sait évaluer : POI / parcours / langues / sites. Personne ne sait ce que pèsent ses contenus en gigaoctets.

⚠️ Le « Bientôt disponible » sur Essentiel n'existe pas dans le code — vérifié le 28/08 : le seul badge « Bientôt » de la landing est sur le 4^e mode de déploiement (XR, HomeClient.tsx:154), et la carte Essentiel pointe déjà vers /signup. Ce qui bloque réellement Essentiel est le déploiement de app.myinfomate.be (carte dédiée dans ce tableau). L'arbitrage est donc : déployer, ou ajouter un badge honnête en attendant — pas retirer un badge absent.

Plan SEO/GEO de la landing et lancement LinkedIn

Audit du 09/09 : 21 actions classées par rapport impact/effort. Faites le 10/09 et vérifiées dans le HTML servi : titres h2/h3, schema Organization ancré en Belgique avec la TVA, trois offres dans le schema, les 9 modules de la home enfin dans le HTML, liens morts, llms.txt en français, prérendu statique rétabli (58 pages, le layout racine est passé dans [lang]) et une page /tarifs avec FAQ tarifaire. Stagé, pas committé.

/assistant-ia est écrite le 10/09, en français seulement (~850 mots, 6 FAQ, schema FAQPage) : en attente de relecture, puis traduction NL/EN/DE. Les autres langues répondent 404, c'est volontaire.

Vocabulaire acheteur injecté dans les 6 segments FR le 10/09 : une FAQ RGPD partout, une FAQ marchés publics dans les 5 segments publics, une FAQ accessibilité qui assume l'absence de certification Access-i. ⚠️ Pas encore traduit en NL/EN/DE.

Ajouté ensuite le même jour : FAQ de la page d'accueil (8 questions ×4 langues + FAQPage), BreadcrumbList sur toutes les pages profondes, et de vraies dates dans le sitemap à la place de la date de build.

Puis 42 items de FAQ traduits en EN/NL/DE (parité dans les 4 langues) et images recompressées : 1,1 Mo économisé, sharp en installation temporaire seulement. ⚠️ public/google-maps-route.png (699 Ko) n'est référencé nulle part. Puis captures d'écran renouvelées avec les vraies vues de la V3 (accueil bento sombre, fiche article, liste des sections) et textes alternatifs localisés dans les 4 langues.

Le 10/09 également : trois pages en 4 langues — /marches-publics, /borne-kiosk, /visite-hors-ligne — un gabarit partagé ContentPage.tsx, une colonne « Solutions » dans le pied de page, et sharp en dépendance (mesuré : 64 Ko de JPEG servis sans lui, 26 Ko de WebP avec — ⚠️ à confirmer au premier build Docker).

Suite : pages comparatives — preuve à mettre en avant, confirmée le 10/09 : Visit Namur a été gagné sur cahier des charges publié, mais ⚠️ aucun document d'appel d'offres n'existe encore, donc ne rien promettre. Les frais de mise en place restent sans montant, par décision de Thomas (carte 180).

LinkedIn : vitrine MyInfoMate créée sous Unov, fiche produit soumise. Huit posts rédigés en deux vagues : ⚠️ ceux qui poussent à l'inscription attendent la bascule prod.

Génération de visites à la demande

« Un parcours de 45 min pour familles ». Marche sur le smartphone du visiteur, aucun hardware. Vendable aux villes comme balade sonore IA.

Faire valider les CGU par un juriste belge

Les CGU sont en ligne depuis le 10/09 — publier valait mieux que faire cocher « j'accepte » sur un lien mort — mais elles n'ont jamais été relues par un juriste, ce que le document source dit lui-même depuis avril. Deux points appellent un œil professionnel : le §8 (RGPD), réécrit le 11/08 quand le guide IA s'est mis à enregistrer les questions des visiteurs, et le §9 (SLA à 99 %), qui est un engagement chiffré tenu par une infrastructure mono-serveur.

Deux sources à garder synchrones : DOCS/cgu-myinfomate.md fait foi, la page Next en est le rendu. Toute correction du juriste passe par les deux.

⏱️ À faire avant d'ouvrir l'inscription self-service à de vrais clients payants, pas avant la mise en prod technique. Prévoir aussi le contrat de traitement des données (DPA) qu'un acheteur public demandera — il n'existe pas encore.

Guides multiples & guide thématique

Plusieurs personas, assignables à une section ou une configuration. Le modèle part en V1 (liste, pas champ unique) ; le comportement attend — qui répond depuis l'accueil, et sur quel périmètre de contenu, est une vraie question de conception.

Déployer le visiteur web — app.myinfomate.be

L'app existe : build ✅, 13 types de section rendus, assistant IA inclus depuis le 06/08. Il ne manque que le Dockerfile et l'entrée Traefik dans le compose. Le plan Essentiel vendu en self-service est web-only — sans ce déploiement, l'onboarding vend un produit inaccessible.

Kiosk web (Flutter Web)

Extension web de tablet-app pour les clients ne voulant pas d'installation native. Reporté en V2 le 07/08 : aucun client demandeur. ⚠️ Le second motif est tombé le 12/08 — « la cible native ne compile même plus » n'est plus vrai, l'APK est produit depuis K1.

Repasse visuelle de la borne — bento, types, orientation

Arbitré le 12/08 : paysage seul en V1, portrait en V2. Une seule maquette à dessiner, les six règles de la maquette K3/K7 s'étendant aux neuf autres types. ⚠️ Mais pas « paysage en dur » : le portrait étant un objectif V2 assumé, les décisions liées à l'orientation (sens de partage, côté du rail média, position de la carte) passent par un point de décision unique et nommé qui renvoie « paysage » pour l'instant. Surcoût V1 nul, et la V2 devient un branchement au lieu d'une réécriture. Pas de maquette portrait, pas de if portrait spéculatif.

a) L'écran principal en bento — le seul code vraiment neuf, et moins cher que prévu. ⚠️ Vérifié le 12/08 : le kiosk n'a pas le bento — main_view.dart:403-405 est un GridView à crossAxisCount fixe, toutes les tuiles de même taille, et myinfomate_layout n'est pas dans son pubspec.yaml. ✅ Mais la donnée est déjà là : les spans vivent sur AppConfigurationLinkDTO.gridColSpan/gridRowSpan, donc par canal, réglables dans manager-app — et K2 a déjà posé TabletAppContext.currentAppConfigurationLink. Il reste à ajouter la dépendance locale et appeler bentoLayout() comme home_3.0.dart:538. Bénéfice de bord : l'aperçu de manager-app cesse de montrer au client un bento que sa borne ne rend pas.

b) Inventaire par type, tranché le 12/08. À revoir : Slider (le plus faible), Weather (retouche légère). À garder comme référence : Agenda — les autres s'alignent dessus. Réputés bons, à confirmer à l'œil : Game, Web, Map, Video. Non tranchés, à regarder dans la même passe : Menu, Quiz, PDF. Article et Event sont déjà couverts par K3/K7 et ne se rouvrent pas — mais sont à repasser sur le point de décision d'orientation, sinon la V2 aura deux idiomes.

c) Vimeo — un vrai trou, passé en V1. ⚠️ SectionVideo.cs:21 annonce « URL YouTube/Vimeo » et le kiosk a bien son video_viewer_youtube.dart — mais vimeo n'apparaît nulle part dans le Dart des deux apps visiteur : une URL Vimeo tombe dans le lecteur de fichier et ne lit rien. Lecteur à écrire sur le modèle de l'existant, branché aux deux mêmes points de dispatch. ⚠️ Les trois fichiers concernés existent en double, une copie par app : écrire une fois, copier sciemment. ⚠️ Comme YouTube, une URL reste indisponible hors ligne (SectionVideo.cs:25-27) — c'est voulu, ne pas le « corriger ».

⚠️ Non bloquant pour la bascule, contrairement à K2/K3/K4 qui réparaient un contrat d'API cassé : c'est du confort visuel, publiable après K6 au prix d'une seconde publication d'APK qui ne coûte rien sur un parc géré. Premier poste à sacrifier si la date serre. 4 à 6 jours, dont ~1 de maquette.

SectionForm — formulaires visiteurs

Nouveau type de section : le lieu compose un questionnaire (texte, texte long, choix unique, choix multiple, note 1-5), le visiteur y répond anonymement, l'admin lit les réponses agrégées dans un onglet de la section, avec export CSV. Enquête de satisfaction, livre d'or, sondage d'exposition.

Reporté en V2 le 07/08 : purement additif, aucun impact sur le schéma existant. Analysé dans le code le 15/09 — plan complet dans v2/section-form-plan.md, décisions arrêtées, ne pas refaire l'analyse.

Ce qui remonte aujourd'hui du visiteur est uniquement dérivé (VisitEvent, VisitorQuestion) : c'est le premier mécanisme qui permet à un lieu de poser une question. La moitié de la plomberie existe déjà — StatsController.TrackEvent pour l'écriture anonyme, SectionQuiz/QuizQuestion pour la structure, VisitorQuestionPurgeService pour la rétention.

Trois fronts visiteur, kiosk compris. Piège propre à tablet-app : sur borne fixe le visiteur suivant hérite de l'écran du précédent — reset après soumission et sur inactivité. Et un piège backend : GetEmbeddableText doit indexer les libellés de questions mais jamais les réponses, sinon le guide IA récite les avis des visiteurs précédents.

AR image tracking (Mind AR)

Modèle ArAnchor, microservice Node de compilation des .mind, et remplacement du scanner visiteur par une WebView unifiée QR + image. Le plus lourd des trois, fort effet démo. Reporté en V2 le 07/08 — ni la migration ni la mise en prod n'en dépendent.

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

Donner l'IA à un client Pro se fait en SQL : AiTokensPerMonth n'est dans aucun DTO, IsAssistant est à poser deux fois (instance et ApplicationInstance), et le rattrapage d'indexation ne partant que depuis UpdateInstance en C#, il faut penser au bouton de relance. Exposer le quota dans InstanceDTO ramènerait ça à un formulaire. Reporté en V2 le 12/08 : la V1 n'a besoin d'aucun add-on — les 4 clients de la bascule sont affectés à leur plan, et l'activation manuelle reste un geste interne, fait une fois, sur une base qu'on contrôle. À faire d'un bloc avec l'endpoint de mise à jour d'ApplicationInstance (canaux activables) : c'est le même écran.

Troisième add-on à poser dans le même écran, décidé le 31/08 : l'add-on « Contenu immersif » à partir de 70 €/mois (image 360 + vidéo 360 + modèles GLB). Techniquement c'est le patron d'IsAssistant à l'identique — Instance.HasImmersiveContent plus un relèvement de StorageQuotaBytes, l'Instance recopiant déjà localement les valeurs du plan (Instance.cs:87-98). Pas de nouvelle ligne de plan, pas de table de jointure, ~1 j. ⚠️ Mais l'enveloppe de stockage n'est pas optionnelle : un client Pro a un quota Pro et une vidéo 360 de 5 min pèse des Go.

Module Studio — génération d'images sous identité visuelle

✅ 15/09 : lots 5 et 6 codés, calibrage §9.4 fait. Mention IA dans le fichier (XMP IPTC) + gravure en option. Calibrage sur 61 générations (Fourneau en gravure, Fort en aquarelle) : trois défauts corrigés avant tout client — négatif en double négation, titre de fiche recopié en légende, date d'un objet effacée. Coût réel fal : 0,03 $ l'image + 0,015 $ par référence ; unité arrêtée : 1 crédit = 0,015 $ de coût, vendu avec marge (≈ 0,05 €). Planches dans outputs/studio-calibrage-2026-09-15/. Reste : jugement visuel de Thomas, test du conservateur (gate lot 4), push de la branche.

🛠️ Lots 0 à 4 codés le 13/09 sur la branche studio (manager-service, manager-app, mymuseum-visitapp) : ingestion serveur, crédits, identité visuelle (menu Studio), génération fal.ai derrière IGenerationProvider (fournisseur interchangeable), onglet Générer dans le sélecteur de ressource, image d'étape rattachée à une ressource. Reste avant le gate : bucket de dev + CORS, clé fal.ai (Studio__Fal__Key), migrations appliquées, calibrage et prix (§9.4), puis le test du conservateur.

✅ Plan consolidé le 13/09. Le §8 donne, pour les lots 0 à 4, les prérequis, les étapes, les vérifications et le gate. Le §9 contient un catalogue v0 (8 styles, règle de préambule, 3 gabarits) à calibrer en fin de lot 3. Six décisions ont été prises : upload par URL signée + ingestion serveur (bucket fermé aux clients, gros fichiers hors VPS), MVP limité à « depuis le texte » et « depuis une image » (objets et lieux), prix différés avec Grant manuel, une recharge qui prolonge tout le solde, plafonds d'upload prudents, catalogue calibré au lot 3. Le webhook fal.ai est signé en ED25519, pas en HMAC.

Le produit n'est pas l'accès aux modèles, c'est la cohérence. N'importe qui peut générer une image ailleurs. La valeur : qu'un conservateur qui ne sait pas prompter obtienne, en trois champs, une image raccord avec les quarante autres du même parcours. Une VisualIdentity par instance (style verrouillé, époque, palette, exclusions, 1-5 images de référence) + surcharge optionnelle par configuration — le parcours Halloween a sa propre identité, exactement comme Configuration porte déjà ses PrimaryColor/Languages. Injectée côté serveur dans chaque prompt, jamais retapée. Boutons « Générer » dans l'éditeur de contenu, pas dans un playground ; gabarits métier, prompt libre en mode avancé seulement.

⛔ Prérequis dur, carte séparée : le backend ne sait pas écrire dans le bucket. Sans le lot 0, rien du Studio ne tourne.

⚠️ Quatre pièges déjà tranchés. Une URL Firebase à jeton est publique — un brouillon dans pictures/ serait servable au visiteur : préfixe studio-drafts/ + proxy authentifié. Le quota IA existant ne tient pas sur des jobs parallèles (CheckQuota avant / incrément après : dix jobs Hangfire passent avant le premier débit) → réservation en deux temps sur un CreditLedger. Le plafond dur n'arrête pas le stagiaire — c'est un plafond par utilisateur et par jour qu'il faut, pas un plafond organisation. Et GuidedStep.ImageUrl est une URL, pas un ResourceId : les images générées de l'escape game ne partiraient pas offline (GuidedStep.cs:74) — migration à faire dans le lot MVP.

🚫 Pas de watermark gravé dans les pixels (tranché le 01/09) : irréversible, et laid sur une illustration de musée. L'AI Act exige que le visiteur soit informé, pas que l'image soit tatouée. Provenance complète en Resource.AiProvenance (modèle, prompt effectif, refs, auteur, version d'identité, rightsHolder = le client) + badge « image générée par IA » dans l'UI visiteur, traduit dans les langues de la configuration. Gravure en option par instance pour l'institution qui l'exigerait par écrit.

MVP = escape game, images seulement. Faible enjeu scientifique, fort besoin de cohérence, gros volume. Crédits en monnaie dédiée, distincte des tokens IA — griller son quota d'images ne doit pas priver les visiteurs du guide. Catalogue de modèles en base, pas dans le code (fal.ai comme passerelle unique : FLUX.2 pro, Nano Banana Pro, Recraft V3 ; Kling/Veo et Meshy/Tripo plus tard). 🧪 Le test de réussite se joue à la fin du lot 4 : installer un conservateur devant l'écran et le laisser produire 10 images cohérentes seul. Si je dois prompter à sa place, l'UX a échoué — les lots suivants n'y changeront rien. Gros volume de test à prévoir.

👤 Trois entrées distinctes dans le panneau de génération, à ne pas confondre (précisé le 02/09) : l'identité visuelle donne le style du projet, l'image source donne cet objet-ci (la vraie pièce de la collection, avec un curseur de fidélité : rien / le sujet / sujet + pose / cadrage exact), et le personnage donne cette figure récurrente — « c'est Léon qui est dans le donjon ». Le canon part en référence et ses paramètres (époque, costume, âge) sont injectés en texte : une image de référence seule ne porte pas « capote d'officier ».

⚠️ Deux personnages dans une image coûtent la cohérence du style. Le plafond de références est celui du modèle (10 pour FLUX.2) : un personnage à 4 vues + 4 références d'identité + 1 source = 9/10, mais deux personnages font tronquer l'identité — donc le style dérive précisément sur l'image la plus ambitieuse. Priorité serveur au canon, troncature de l'identité ensuite, jauge visible dans l'UI et avertissement dès le deuxième. Un personnage par image, et on compose la scène autour de lui.

🖼️ Attention aux personnes identifiables. « Modifier une image » sur la photo d'une personne réelle, chez des institutions publiques, c'est du traitement de ressemblance : consentement écrit et tracé. La réponse produit est de rediriger vers les personnages — un avatar généré n'est le portrait de personne.

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

Aujourd'hui le loader est une image fixe : Configuration.LoaderImageUrl / LoaderImageId, rendus par loading_common.dart dans les deux apps Flutter et par SplashScreen côté web. Le besoin : que le client compose un loader animé depuis le manager, sans fournir de fichier.

Décision : pas de format de fichier animé. On transporte des paramètres. Un nouveau champ de configuration porte {preset, couleurs[], logoResourceId, vitesse} — quelques centaines d'octets — et chaque front implémente nativement les 5-6 mêmes presets : AnimationController en Flutter, CSS/Canvas en Next.js, animation Unity côté casque. Le preset n°1 existe déjà et tourne : manager-app/lib/Components/loader_animated_pieces.dart (6 pièces vectorielles, onde d'opacité, rotation, flottement) — il suffit d'en sortir les couleurs et les timings, aujourd'hui en dur.

Les couleurs sont pré-remplies depuis VisualIdentityDTO.palette, qui existe déjà. Aucun crédit Studio débité : le rendu est local au navigateur, rien ne passe par un modèle.

⛔ Le SVG animé est écarté : flutter_svg ignore <animate>, SMIL et les keyframes CSS — il rendrait une image figée dans les trois apps Flutter — et Unity n'a aucun rendu SVG. Un seul des quatre fronts l'afficherait.

⛔ Lottie est écarté à ce stade, malgré son écosystème. Format de fait et non norme, gouverné par une société unique (LottieFiles) sur une spec récente ; surtout, aucun runtime moteur de jeu n'est listé sur le site officiel. Les deux options Unity sont fragiles : thorvg.unity (Android arm64 annoncé, mais 26 commits et 14 étoiles, successeur de Lottity archivé en 11/2025) et unity-rlottie (plus fourni mais en experimental, avec un ticket ouvert sur une texture NULL en build Android). Les deux rastérisent en Texture2D à chaque frame côté CPU — inacceptable sur Quest à 72-90 Hz pour un écran de chargement.

Porte de sortie assumée : le jour où un client veut apporter sa propre animation faite par une agence, on ajoute Lottie sur les 3 fronts 2D seulement, avec le PNG de première frame en repli côté VR. Le champ loader accepte alors soit des paramètres, soit une URL — rien de ce qui est fait ici n'est à refaire.

Coût réel : les presets. Chacun est du code dans 4 dépôts, à tester sur les 4 fronts. En sortir 5-6, pas 20 : au-delà le client ne choisit plus, il se perd. Stocker les paramètres permet la réédition six mois plus tard.

⚠️ Pas un bloquant V1 — le loaderImageUrl actuel fait le travail avec un PNG. À ouvrir après la bascule prod.

Refonte visuelle des écrans Configuration & Section, et de leurs dialogues

Lots 1 à 5 codés le 04/09 (flutter analyze sans erreur, flutter build web passe ; rien de vérifié à l'écran). Pilote select_resource_modal : coquille standard, corps souple, plus de double défilement, showValues mort supprimé, largeur 0,85 conservée. Lot 1 : text_field_container sans width: double.infinity ni rayon 29, compteur discret dans rounded_input_field. Lot 2 : libellé au-dessus et plus d'auto-centrage dans string_/multi_string_/resource_/check_input_container. Lot 3 : grille responsive de sections, réordonnancement par Draggable/DragTarget (ReorderableListView ne fait pas de grille, et pas de dépendance nouvelle), tuile « Ajouter » à la place du bouton vert. Lot 4 : les deux écrans de détail en EditorHeader + EditorColumns + Pane (nouveau Components/pane.dart), _buildFooter supprimé, le QR devient le rail « Diffusion ». Lot 5 : grille de types dans new_section_popup, modal de traduction en rail de langues + IndexedStack, et multi_input_modal réduit à une redirection isHTML: false. 24 clés i18n ajoutées en FR/EN/NL.

🐛 Le bug des catégories est confirmé et corrigé : showCreateOrUpdateCategories recevait un newValues vide de l'appelant et le renvoyait tel quel — valider sans rien toucher effaçait les catégories. Le tampon part maintenant des catégories existantes, et les libellés en dur sont passés par AppLocalizations.

Lot 6 entamé : Components/collection_editor.dart existe — liste ordonnée à gauche (réordonnancement par poignée), élément édité en place à droite, ligne « Ajouter » en fin de liste, suppression dans l'en-tête du détail. Trois types migrés : Slider et Article (via un ContentFields partagé, extrait de showNewOrUpdateContentSlider) et PDF (le bloc figé 70 × 440 disparaît). Les filtres d'envoi au backend sont conservés à l'identique (contenus sans ressource exclus, champs d'article recopiés).

⚠️ Trois fichiers sont devenus du code mort mais ne sont pas supprimés : pdf_file_input_container.dart, pdf_list.dart, new_update_pdfFile.dart. Ils portent des modifications non committées d'un autre lot — les effacer perdrait ce travail. À supprimer une fois l'arbre propre.

Lot 6 terminé pour le gabarit B. Décision prise le 04/09 (artifact 4af75171) : CollectionEditor reçoit un mode distant (RemoteCollection : create / delete / reorder asynchrones, voile de chargement, retour à l'état d'avant si l'appel échoue). Quiz l'utilise : la modale de question disparaît, les messages de score remontent en tête de carte, les réponses gardent QuizzResponseList tel quel. Menu garde la navigation vers sub_section_edit_screen — une sous-section est une section complète — et prend la grille de tuiles, extraite en SectionGrid et partagée avec les sections d'une configuration. Parcours : liste qui suit son contenu, les deux SizedBox(height: 500) de event_config et section_parcours_config retirés, éditeur à fenêtre unique inchangé.

🐛 Le rang en double est corrigé dans Quiz et Menu : ils n'écrivaient que l'order de l'élément déplacé, les autres gardaient le leur. La liste entière est renumérotée et envoyée en un Future.wait, comme le faisait déjà Parcours.

Agenda n'a pas été migré, et c'est délibéré : ses événements sont groupés par langue (_displayGroups, pastilles de langue quand un groupe en compte plusieurs) et n'ont pas d'ordre — une liste ordonnée à édition en place perdrait le groupement. Il reçoit ce qui lui revient : hauteur pilotée par le contenu (le height: 600 saute), lignes au système de tokens, modale conservée.

Gabarit C — Jeu est fait, Map et Événement sont dégrossis. game_config devient champs à gauche + canevas à droite : le canevas montre le découpage réel de l'image en rows × cols, seule décision que le formulaire ne montrait pas. Au passage, son TabBar n'en était pas un — les deux onglets construisaient le même formulaire et ne servaient qu'à écrire gameType : c'est devenu un choix à deux valeurs, et le SizedBox(height: 650) a disparu. geoloc_input_container passe à la coquille standard et affiche les coordonnées retenues au lieu d'un bouton « Changer la localisation », la carte prenant la hauteur disponible. Côté map_config : en-tête en grille de tokens, height: 700 et height: 70 retirés. Côté event_config : height: 600 retiré, la liste des blocs suit son contenu.

Reste : le canevas de Map et d'Événement — et il est maintenant maquetté : DOCS/claude design/refonte-gabarit-canevas.html (diffusion : artifact caf400b5). Liste des points, fiche, carte côte à côte ; les points non sélectionnés restent visibles en gris ; MapGeometryPicker sort de son dialogue pour devenir le canevas (déplacement, pas écriture) ; les informations pratiques d'un point (5 champs sur 9) sont repliées derrière un compteur. Absorbe showNewOrUpdateGeoPoint (362 l.), geometry_input_container et showNewOrUpdateMapAnnotation (182 l.). Une question produit reste ouverte : que montre le canevas d'Événement quand baseSectionMapId est nul — carte vide, ou invitation à choisir un plan d'abord (ma proposition).

Étape 1 du canevas faite le 04/09 : Components/map_canvas.dart — le dessin est sorti du dialogue. Il reçoit une géométrie, la rend modifiable, rend la main à chaque changement (pas de bouton « Enregistrer » : c'est l'écran qui enregistre), et affiche les autres tracés en fond via MapCanvasGhost. Barre d'outils compacte sur la carte, pied qui donne les coordonnées et ce qu'on modifie, bouton « agrandir » optionnel. MapGeometryPicker n'est plus qu'une coquille autour de lui, donc etape_fields et showNewOrUpdateEventAgenda ne bougent pas. Au passage, ses libellés « Ligne » / « Polygone » en dur sont passés par AppLocalizations. Taille tranchée : 420 px par défaut + mode agrandi, pas une interface centrée carte — un point porte neuf champs traduits, la carte n'en porte qu'un.

Étapes 2 à 4 faites : le gabarit C est en place dans Map. Map/geo_point_editor.dart — liste des points à gauche, fiche au centre, carte à droite ; les points non sélectionnés apparaissent en fond ; le mode agrandi replie la fiche et garde le rail. Les neuf champs traduits sont rangés par fréquence : titre, catégorie, description et image visibles, les cinq informations pratiques repliées derrière un compteur. map_config passe de 937 à ~510 lignes : la modale showNewOrUpdateGeoPoint n'est plus appelée, getElement et son boxDecoration sont supprimés, et recherche + catégories filtrent désormais la liste et la carte par un seul calcul. Les points sont créés, modifiés et supprimés directement par l'API (sectionMapCreate / Update / Delete), la suppression passant par la confirmation destructive.

Étape 5 faite : le canevas d'Événement. Les annotations passent dans l'éditeur de collection en mode distant, avec le canevas dans le panneau d'édition. Plan par défaut retenu (décision Thomas) : le premier plan disponible est pris quand baseSectionMapId est nul, plutôt que de bloquer. 🐛 Trouvé en chemin : MapAnnotationDTO portait déjà un champ geometry que l'ancienne modale ne remplissait jamais — elle ne réglait que geometryType. Une annotation déclarait donc une forme sans jamais recevoir de coordonnées ; le canevas les lui donne. Enfin showMultiStringInputAndResourceHTML est passé à la coquille standard : plus aucun dialogue de ce chantier sur l'ancienne.

Plan de test : DOCS/test-plan-refonte-config-section.md, 14 sections. Rien n'a été vérifié à l'écran — flutter analyze propre et flutter build web qui passe, c'est tout.

Reste : supprimer le code mort une fois l'arbre git propre — showNewOrUpdateGeoPoint, showNewOrUpdateMapAnnotation, pdf_file_input_container, pdf_list, new_update_pdfFile, listView_card_subSection, new_update_question_quizz ; et geometry_input_container quand etape_fields et showNewOrUpdateEventAgenda auront leur canevas.

Maquette prête et complète : DOCS/claude design/refonte-configuration-sections.html (diffusion : artifact 4d0c2ad6). Elle contient le diagnostic, les deux écrans, les 3 gabarits qui couvrent les 13 types de section, la coquille de dialogue, et deux dialogues dessinés — traduction et choix du type. Rien à décider côté design : tout est tranché.

Le blanc ne vient pas des écrans mais de 4 composants partagés. text_field_container.dart impose width: double.infinity + rayon 29 ; string_input_container.dart met le label à gauche dans un Row ; multi_string_input_container et resource_input_container se centrent eux-mêmes ; section_reorderList.dart réserve 0,3 × hauteur pour une liste horizontale de cartes 150×150. On les corrige une fois, les 13 types en héritent.

⚠️ Aucune direction visuelle à inventer : constants.dart porte déjà le système (kSpace1..8, kRadiusInput 5 / Card 8 / Shell 10 / Pill, kTitleCard, kLabelField, kTextHint) et confirmation_dialog.dart + resource_picker.dart l'appliquent déjà. Ces deux écrans sont simplement antérieurs au système.

Premier pas conseillé : select_resource_modal.dart, pas les composants partagés. Un fichier, ~15 lignes, zéro ligne dans ResourcesScreen, et ça corrige un vrai bug — AlertDialog dispose de hauteur − 48 mais le contenu en demande 0,85 × hauteur plus titre plus actions, d'où un défilement dans un défilement. Ça sert de pilote avant de toucher aux composants qui irriguent 30 écrans. ⛔ Ne pas toucher à la largeur 0,85 : la règle du rail de facettes de v1-mediatheque-plan.md §3.3 est écrite sur cette hypothèse et déjà codée.

⚠️ Deux pièges qui ne sont pas du visuel. D'abord, manager-app n'a que 3 tests, aucun sur ces composants : vérification manuelle, et il reste des conteneurs à hauteur figée (height: 70, 100, SizedBox(height: 250)) autour — ce qui rentrait juste débordera. Ensuite un chemin d'écriture est câblé dans les composants : section_detail_screen.dart:270 déclenche un save(true, …) depuis MultiStringInputContainer.onGetResult, et la ligne 381 un save(false, …) depuis la case iBeacon. À ne pas perdre ni dédoubler.

⚠️ Le piège Quill (remonté de mémoire par Thomas, confirmé dans le code). Ça marche aujourd'hui parce que l'empilement vertical monte toutes les langues : _controllers est bâtie une fois dans initState (translation_input_container.dart:52) et libérée seulement dans dispose. Le rail de langues de la maquette casse cette propriété s'il reconstruit l'éditeur à chaque bascule. Règle : map construite une fois pour toutes les langues, bascule par IndexedStack/Offstage, jamais de TabBarView (construction paresseuse, enfants lâchés hors écran sans AutomaticKeepAliveClientMixin). Trace d'une tentative abandonnée : translation_tab.dart existe en TabBar, son appel est en commentaire dans multi_input_modal.dart:46-51. À retester en priorité : la traduction IA (ligne 142) et « appliquer à toutes les langues » (ligne 183), les deux chemins qui libèrent et recréent les contrôleurs.

Deux fusions et un ménage décidés dans la maquette : multi_input_modal.dart est le jumeau sans HTML du modal de traduction (même travail, deux implémentations) → une coquille, deux corps, Quill si isHTML et champ simple sinon ; les 8 showNewOrUpdate* et les 2 sélecteurs géo disparaissent dans les gabarits B et C ; showValues est mort en double (select_resource_modal.dart:64 et multi_input_modal.dart:186, appel commenté ligne 53).

⚠️ Conflit résolu avec l'audit — security/audit-manager-app.md recommandait d'extraire un FormDialogScaffold pour les 15 occurrences des showNewOrUpdate*. Or la refonte les supprime : les extraire d'abord, ce serait refactoriser du code à jeter. Ordre imposé : absorber d'abord (gabarits B et C), extraire ensuite sur ce qui survit — traduction, nouvelle section, nouvelle configuration, sélecteur de couleur, fichiers PDF, catégories. L'audit et STATUS.md ont été annotés en ce sens le 2026-09-04.

🐛 Trouvé en passant, à vérifier : pdf_file_input_container.dart et category_input_container.dart sont un copier-coller — mêmes dimensions, même structure — mais le second a ses libellés en dur (« Annuler », « Valider ») et son onGetResult(result) commenté. Une catégorie de carte modifiée ne remonte peut-être pas à la volée. Lecture de code, pas testé.

Socle de stockage — URL d'envoi signée et ingestion serveur

🛠️ Code livré le 13/09 (branche studio) : URL signée, ResourceIngestionService, ImageSharp, upload avec progression dans manager-app, SDK Firebase retiré. Reste l'infra ci-dessous, puis la checklist du §8.

IResourceBlobService n'expose que DeleteAsync : tout l'upload est fait par le navigateur en direct, à deux endroits de resources_screen.dart. Or le Studio et le TTS pré-généré produiront côté serveur.

⚠️ Trou de sécurité actuel, indépendant du Studio. manager-app n'a pas de Firebase Auth (firebase_storage sans firebase_auth) et écrit pourtant dans le bucket : les règles Storage sont très probablement ouvertes en écriture. Aucun storage.rules dans le repo — à relever dans la console.

✅ Tranché le 13/09 : URL signée + ingestion. L'API délivre une URL V4 signée (15 min, un objet, taille bornée), le navigateur envoie directement chez Google dans incoming/, puis POST /ingest : un ResourceIngestionService unique — le même pour le Studio et le TTS — mesure la taille réelle, applique quota et plafond, post-traite les images (2 à la fois au plus) et range sous pictures/. Les vidéos, 360 et GLB sont copiés côté Google, jamais lus par le VPS. Les écritures clientes sont ensuite fermées dans les règles.

Infra : CORS du bucket pour le PUT, règle de cycle de vie à 1 jour sur incoming/, et fermeture des règles après le déploiement du nouveau manager-app. À caser dans le même lot : suppression de la route upload morte et d'ImageHelper, Firebase:StorageBucket renseigné, et LB (luxembourgeois).

Le watermark des images est inactif depuis l'upload direct

Constat du 13/09. Le seul code de watermark vivait dans ResourceController.Upload (base64, System.Drawing) : il écrivait le texte « fortsaintheribert.be » en dur, en Arial. manager-app n'en applique aucun. Depuis que l'upload passe du navigateur à Firebase, aucune image n'est filigranée, même sur une instance où Instance.IsImageWatermark est activé.

Le lot 0 du Studio supprime ce code mort et ne réimplémente rien : pas de régression par rapport à la prod actuelle, mais le drapeau ment.

À trancher avant de le refaire, dans le ResourceIngestionService du lot 0 (le seul endroit qui voit passer toutes les images) :

• le Fort le veut-il encore ?
• texte ou logo, et par instance au lieu d'un nom de domaine en dur ;
• une police embarquée dans le repo — Arial n'existe pas dans le conteneur aspnet:8.0 Linux — via SixLabors.ImageSharp.Drawing ;
• jamais sur une Image360, comme la compression.

Distinct de la gravure « générée par IA » du Studio (Instance.IsAiWatermarkBurned, décision 6), qui réutilisera le même chemin.

Personnages — un objet, quatre facettes

🛠️ Lot 7 en cours (15/09). Entité Persona, écran Personnages, TtsVoice en base, migration des colonnes Instance.Guide* faits. Figures des 12 archétypes générées et embarquées. Reste : l'écoute des voix (échantillons audio à produire, pas de clé Gemini en local), puis le lot 8 (narration attribuée).

Trois plans décrivaient le même objet sans se croiser (relevé le 01-02/09) : le canon visuel (studio-plan.md), les 3 frames de lipsync (talking-head-plan.md) et PersonaConfig { WakewordId, GuideName, PersonaPrompt, VoiceName } (tts-pregenerated-plan.md). Une entité Persona les remplace : identité, visage (canon en jeu de vues), voix + intonation, parole.

⛔ Le talking head est abandonné, sa dépendance était déjà cassée. talking-head-plan.md:11 anime ses frames « selon les timestamps retournés par Google Cloud TTS » (enable_time_pointing) — or le code livré tourne sur Gemini TTS (GeminiTtsEngine, gemini-2.5-flash-preview-tts) : aucune source de timestamps. Remplacé par le portrait canon statique à côté du lecteur audio, puis une boucle vidéo 6-8 s si du mouvement est voulu. En-tête d'abandon posé sur le fichier.

⚠️ « Le visiteur choisit entre Viva et Marco » était un choix de voix déguisé en choix de guide. Le besoin réel est celui du Bastogne War Museum : 3-4 personnages qui narrent chacun leurs stations, avec leur voix et leur intonation. Le conservateur assigne (NarratorPersonaId sur GuidedStep/GeoPoint/SectionArticle), le visiteur ne choisit rien. Bonne nouvelle : ça divise le stockage TTS par deux au lieu de le multiplier — chaque contenu n'existe plus qu'en une voix.

Le wakeword devient une exigence du canal, pas une propriété du personnage. Il corrigeait un bug latent : GuideName est du texte libre sans lien avec le modèle OpenWakeWord, donc le visiteur dirait « Marco » à quelqu'un qui se présente comme « Léon ». Nouvelle règle : nom libre par défaut, contraint à un modèle disponible seulement si un canal mains-libres est actif (lunettes, casque VR). Mobile/web/kiosk : push-to-talk.

Deux champs à ajouter : Persona.VoicePrompt (l'intonation — aujourd'hui la constante de build kGeminiTtsPrompt, visitapp constants.dart:27) et une table TtsVoice à la place des deux constantes : deux voix ne suffisent pas à quatre narrateurs. Migration : les 4 colonnes Instance.Guide* deviennent une ligne Persona.

🔄 Révisé le 02/09 : le Kind Guide/Narrateur est abandonné. Un guide n'est rien d'autre qu'un personnage dont la facette parole est remplie. Donc un seul objet, et ce qu'il sait faire découle des facettes renseignées : VoiceId → il narre, SystemPrompt → il peut être guide, WakewordId → on l'appelle à la voix. Quatre combinaisons valides, y compris visage seul — une silhouette de décor qui revient huit fois a besoin d'un canon, pas d'une voix.

Un guide par visite est possible : Configuration.GuidePersonaId ?? Instance.GuidePersonaId. Donc le gouverneur peut narrer les étapes 1, 3, 5 et répondre aux questions sur ce parcours, en personnage. Assignation : le défaut se pose sur tout conteneur, la surcharge sur toute feuille — narrateur sur Instance → Configuration → GuidedPath/SectionMap, surchargeable sur GuidedStep, GeoPoint, SectionArticle.

✅ Le mains-libres n'est pas la limite que je croyais (vérifié dans le code le 02/09) : NativeWakeWordEngine fait tourner N modèles en parallèle et l'événement dit lequel a déclenché (detected:hey_marco). Quatre tournent déjà, en dur (voice_controller.dart:105), sans lien avec le CMS. Cinq modèles sont embarqués : hey_viva, hey_marco, hey_alba, hey_vasco, hey_visit. La vraie contrainte est que le catalogue de noms est fini et embarqué au build — un autre prénom demande un entraînement et une republication de l'app.

🐛 Bug relevé au passage — le chemin mains-libres Android est cassé. Le moteur passe le nom du modèle dans onDetectedWithCommand, que VoiceOrchestrator._onWakeWordWithCommand (voice_orchestrator.dart:132) interprète comme la question du visiteur et envoie à _dispatch(). Le visiteur dit « Hey Marco », l'assistant répond à la question « hey_marco » et n'ouvre jamais le cycle d'écoute. À corriger indépendamment du Studio.

⚠️ VisitorQuestion a ConfigurationId, AppType, IsVoice, ThemeId — mais pas de PersonaId. Sans lui, impossible de ventiler les stats par personnage, donc de voir qu'un personnage répond mal.

Test « faire vivre un lieu » — 8 s au Fourneau

Une photo d'un bâtiment du Fourneau → sa version d'époque → un personnage en boucle de 8 s. Le but n'est pas de produire un asset, c'est de répondre à la seule question dont dépend tout le reste : est-ce que ça a l'air crédible, ou est-ce que ça décroche ? En patrimoine la crédibilité est la valeur — si le rendu est inquiétant, la fonctionnalité n'existe pas, quels que soient le prix et la facilité.

Le principe à valider : le text-to-video pur est écarté (il invente la géométrie du lieu). Le lieu réel reste la base, l'IA n'ajoute que le mouvement — c'est « Point de départ » du Studio transposé à la vidéo, donc aucun mécanisme nouveau en base : Kind = Video et sourceFidelity existent déjà, c'est un gabarit de plus.

Respecter les contraintes pendant le test, sinon il ne prouve rien : 6-10 s en boucle, une seule personne, mouvements simples, caméra calme, plan large ou moyen, jamais de gros plan sur les mains ou le visage.

⚠️ Deux choses déjà tranchées, à ne pas rejouer. Le motion transfer part en prestation Unov, pas dans le produit : il demande un tournage et un consentement écrit, ce qui échoue par construction le critère du §0 (« un conservateur produit sans intervention »). Et le cadrage de vente est resserré à « là où il ne reste rien » — bâtiment disparu, métier éteint, site réduit à ses fondations : partout où des archives existent, une vraie photo d'époque bat une boucle générée.

⛔ Ne bloque rien et n'est bloqué par rien — c'est justement l'intérêt de le faire tôt. Mais la fonctionnalité, elle, reste derrière le prérequis dur du Studio : IResourceBlobService n'expose toujours que IsConfigured et DeleteAsync, le backend ne sait pas écrire dans le bucket.

Meta Quest — app Unity + Meta XR SDK

Stack tranchée le 31/08 : Unity 6 LTS + OpenXR + Meta XR feature group. Le contenu se récupère par GET /api/configuration/{id}/export — un seul appel qui renvoie configuration, sections et ressources, donc aucun DTO C# à réécrire endpoint par endpoint. Unity n'est pas une nécessité technique : le mode kiosk vient de la gestion d'appareil, pas du moteur. Unity gagne sur l'exploitation sans surveillance — cache offline multi-Go, décodage 8K, et un build figé là où le navigateur du casque s'auto-mettrait à jour et pourrait casser la borne un mardi matin. Retenu : WebXR pour la maquette, Unity pour la borne, à rouvrir si l'usage devient « casque 5 min avec un agent à côté ».

✅ Le POC est écrit en entier — E0 à E10, entre le 11 et le 12/09. Unity 6000.0.83f1, projet URP dans vr-app/, APK sideloadé sur un Quest 2 (Horizon OS v207). Mesuré sur casque : un décor glTF de 50 Mo charge en 1,4 s et tient 72 FPS, GPU au maximum.

⚠️ Rien de E2 à E10 n'a jamais tourné — ni contre un vrai serveur, ni sur le casque. Le code compile, c'est tout ce qu'on sait. Plan de test §25, 9 blocs, écrit pour ça ; son §25.7 (déclarer une 360 dans le manager) se joue sans casque.

⚠️ Le risque est produit, pas technique, et il est intact. Le CMS est 2D : un Article sur un panneau flottant est moins bon qu'une tablette. La valeur du canal vient du contenu 360°, que peu de clients possèdent. Go/no-go conditionné à un client pilote disposant déjà de vidéos 360° — rien de ce qui a été codé ne répond à cette question-là.

🟡 XR-5, la supervision de flotte : l'essentiel est écrit (12/09). Un battement HTTP toutes les 3 min remplit enfin les colonnes batterie / version / dernier vu de l'onglet XR, qui affichaient « — » faute d'alimentation — Update n'écrivait ni AppVersion ni LastSeen. Pas de MQTT : à 1-3 casques il coûterait dix fois plus de code pour remonter trois chiffres ; il redeviendra utile pour pousser vers le casque, pas pour remonter. Reste : le client MQTT le jour où l'on voudra recharger une configuration à distance, et une alerte quand un casque ne donne plus signe.

🟡 E7, la maquette 3D, est écrit aussi (12/09). SectionModel3D est un vrai type de section — une maquette n'a ni fond cartographique, ni zoom, ni coordonnées terrestres — mais il réutilise le GeoPoint, qui portait déjà deux rattachements : les points gardent titre, description, audio et multilingue. ✅ L'« éditeur de placement 3D », annoncé comme le seul morceau non trivial du lot, n'était pas à écrire : vr-app/viewer sait déjà le faire et son protocole postMessage existait déjà, pensé pour ce cas. Le manager le monte en iframe, comme il le fait déjà trois fois ailleurs. Côté casque, rien de dessiné non plus : on construit un manifeste et on le passe au moteur de la piste S. ⚠️ Le viewer n'a jamais tourné, et doit être servi sous le même domaine que le manager.

Reste au lot : E11 (distribution : Horizon Store ou canal privé, à revérifier avant toute offre). ⚠️ MDM rétrogradé le 31/08 : inutile à 1-3 casques, sideload + mode appareil suffisent.

Pages XR de la landing — lunettes connectées et casque VR

Deux pages, pas une (arbitré le 10/09) : /lunettes-connectees pour l'add-on Ray-Ban Meta et /casque-vr pour le canal immersif Meta Quest. Les deux publics et les deux modèles économiques diffèrent — un add-on mensuel d'un côté, un palier Immersif de l'autre — et les mettre sur une seule page brouillerait les deux.

Aujourd'hui, la landing n'en dit qu'une ligne : « Meta Quest et lunettes connectées » dans le 4^e mode de déploiement, avec un badge « Bientôt ». C'est honnête et c'est suffisant tant qu'il n'y a rien à montrer.

⏱️ Condition d'écriture : un module démontrable. Publier une page produit sur une fonctionnalité qu'on ne peut pas faire tourner en rendez-vous se retourne contre nous — c'est le même raisonnement que pour la vague 2 des posts LinkedIn. Le reste du contenu (positionnement, prix, arguments) est déjà écrit dans les deux docs de la colonne source.

Rotation des secrets committés en clair

Clé de signature JWT, clés API Gemini et OpenWeather, connection strings prod, mot de passe MQTT, token Telegram. Le dossier RELEASE/ republie d'anciens secrets.

Déplacée depuis « Urgent » le 11/08, à la demande : les 6 repos sont privés, sur un Gitea auto-hébergé — l'exposition réelle est celle d'un poste de dev, pas d'un dépôt public. La gravité ne bouge pas, la fenêtre d'urgence oui.

⚠️ Ce qui ne se négocie pas : elle doit précéder la création de l'environnement prod (étape 16), sinon la prod naît avec les clés de l'historique et il faut rotationner deux fois. Et comme le test d'onboarding exige app.myinfomate.be déployé, ça veut dire avant la fin du lot de tests, pas au tout dernier moment. Elle remonte en « Urgent » immédiatement si un repo passe public, gagne un collaborateur externe, ou est cloné par un CI tiers.

Dry run + comparaison des comptages

dryRun=true n'écrit rien. 🔨 Joué le 11/08 sur l'export du 1ᵉʳ avril, et automatisé en test (MigrationDryRunTests, qui se saute si aucun Mongo n'écoute — la suite reste verte sans dépendance).

Il a trouvé du premier coup ce qu'aucune lecture de code n'avait vu : 327 sections dans Mongo, 307 migrées, et Erreurs : 0. Les 20 manquantes référencent deux configurations supprimées dans Mongo — 19 articles et un slider, du contenu MDLF bien réel (« Senteur : fraises », « Pupitre vigne », « Ruche 7 »). Ce n'est pas un défaut de la migration : les sections sont collectées configuration par configuration, donc les orphelines n'étaient jamais énumérées. Le défaut était le silence — elles partent maintenant dans Skipped, et le test affirme migrées + signalées = Mongo.

⚠️ Décision produit : recréer les 2 configurations dans Mongo avant la bascule pour récupérer ces 20 sections, ou acter leur perte. À trancher avec MDLF.

⚠️ À rejouer sur un dump frais : l'export a 4 mois et la prod tourne encore sur Mongo. Et MigrationController lit un Mongo vivant, pas ces fichiers — recette d'import dans v1-plan.

Créer l'environnement prod Postgres

Deployment/Dockerfile.postgres (digest épinglé), compose prod, Traefik, port 5432 fermé. Puis dotnet ef database update sur la base vide et vérifier que postgis et vector répondent. Ne pas créer la prod avec les clés encore committées.

pg_dump avant / après + cron quotidien

Scripts écrits et testés le 07/09 dans manager-service/ManagerService/Deployment/backup/ : dump -Fc avec vérification de relecture et rotation, test de restauration comparant les comptages table par table (25 tables identiques), extraction par instance, contrôle de fraîcheur, units systemd, et une procédure de restauration écrite (RESTORE.md).

La destination existe depuis le 07/09 : BACKUP_DEST=gcs:unov-myinfomate-backups/pg, service account incapable de supprimer (vérifié par un 403). Voir la carte close « Trancher la destination des sauvegardes hors site ».

Ce qui reste : rclone n'est ni installé ni configuré sur le VPS, et il n'y a de toute façon pas encore de base Postgres en prod à sauvegarder. Cette carte est donc une étape à l'intérieur de « Créer l'environnement prod Postgres », pas un chantier parallèle — une vingtaine de minutes le jour venu, plus l'acheminement de la clé du service account en chmod 600.

Deux constats du test : les embeddings exclus font passer le dump de 12 Mo à 1,7 Mo, et le « collation version mismatch » du README s'est reproduit — il bloque createdb, donc toute restauration.

Brancher notify.sh sur un canal réel

Trois surveillances sont en place — échec du script (OnFailure=), sauvegarde plus vieille que 48 h, test de restauration mensuel — et toutes appellent backup/notify.sh, qui ne fait aujourd'hui qu'un logger.

Le mode de panne réel n'est pas « le script plante » : c'est « le script ne tourne plus depuis trois semaines et personne ne l'a vu ». C'est précisément celui qu'un OnFailure n'attrape pas et que le contrôle de fraîcheur attrape — à condition que l'alerte sorte de la machine. Renseigner BACKUP_ALERT_WEBHOOK, ou brancher le canal mail du service.

Rejouer pour de vrai, instance par instance

Le paramètre instanceId existe précisément pour ça. Commencer par la plus petite instance : si quelque chose casse, ça casse sur le plus petit périmètre possible.

Poser Firebase:StorageBucket, puis lancer le backfill

Deux gestes que C2 et C3 laissent à la mise en prod. 1) La clé Firebase:StorageBucket (<project-id>.appspot.com) est vide par défaut : sans elle, Delete ne supprime aucun blob — il ne casse rien, il ne nettoie pas. C'est aussi le verrou de la carte « retirer la suppression de blob de manager-app ». 2) Lancer le backfill : POST /api/Resource/backfill-storage?dryRun=true, relire Orphans et Unsized, puis dryRun=false. Sans lui le quota de C3 porte sur des SizeBytes à 0 pour tout l'existant, donc il laisse tout passer (L10).

⚠️ Piège de build repéré le 12/08 : dotnet restore échoue en 401 si la source NuGet git.dev-espaces-naturels.lu est déclarée dans l'image — elle n'a rien à voir avec ce projet. Google.Cloud.Storage.V1 étant le premier paquet ajouté depuis longtemps, le prochain build d'image la rencontrera.

Vérifications post-bascule

Login manager-app, une app visiteur avec sa clé API, un parcours, une carte, un PDF, un quiz avec ses questions. Les défauts « silencieux » ne se voient qu'ici — pas dans le rapport de migration.

Bascule par coexistence sur deux serveurs

Décidé le 12/08, remplace la bascule DNS. Un second serveur porte la nouvelle prod Postgres, les nouvelles versions des apps pointent vers lui, et l'ancienne prod Mongo continue de servir les apps déjà installées. Aucun DNS ne bouge, pas de fenêtre de maintenance, et un retour arrière qui consiste à ne rien faire.

C'est la seule réponse au problème que L19 pose : on ne force pas la mise à jour du téléphone d'un visiteur.

Ce qui rend la coexistence saine — une seule source d'écriture : dès que le back-office pointe sur la nouvelle prod, l'ancienne est figée de fait. Les vieilles apps voient un contenu gelé au jour J, ce qui est tenable quelques semaines, et les deux bases ne divergent jamais.

⚠️ Ce qui ne marche pas : « recopier de la nouvelle prod vers l'ancienne ». Il n'existe pas de chemin Postgres → Mongo ; MigrationController va dans un seul sens et écrire l'inverse coûterait autant, pour alimenter une base qu'on éteint. L'ancienne prod se fige, elle ne se synchronise pas.

À tenir : une date d'extinction décidée d'avance (sinon l'ancienne prod survit trois ans), le coût d'un second serveur OVH le temps de la transition, et un plan de rollback réécrit — il ne s'agit plus de restaurer un dump mais de republier l'app qui pointe vers l'ancienne adresse, ce qui déplace le risque sur les délais de validation des stores.