2944fb5a05
Le §23 couvre les réglages du manager, les trois formats de QR (id brut du Fort, URL MDLF, nouvelle URL /download), la page de téléchargement et les notifications de proximité. §9 mis à jour : au premier plan c'est la popup, la notification n'arrive qu'écran verrouillé, et meterZoneGPS sert aux zones GPS, pas aux beacons. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
266 lines
36 KiB
Markdown
266 lines
36 KiB
Markdown
# MyInfoMate — Tableau de bord
|
||
|
||
> Point d'entrée unique : "où j'en suis, qu'est-ce que je peux avancer". Chaque section renvoie vers le document détaillé pertinent — ce fichier ne duplique pas le contenu, il donne juste la vue d'ensemble et l'état.
|
||
>
|
||
> Dernière mise à jour : 2026-09-02.
|
||
|
||
---
|
||
|
||
## 1. Produit — features manquantes / en cours
|
||
|
||
→ Détail complet, granulaire, à jour : **[todo-features.md](todo-features.md)**
|
||
|
||
Résumé de la table de suivi de ce fichier :
|
||
- **Fait** : SectionEvent, Escape/Puzzle games, GuidedPath + progression carte, push, stats tracking, sync agenda/météo, traduction IA, quotas (IA/stockage/stats) par plan, audit log backend fiabilisé, refacto SectionParcours/GuidedPath/SectionGame (backend, vérifié 2026-07-15).
|
||
- **Partiel** : Beacons/geofencing (manager-app UI ⚠️), AI Assistant (manager-app ⚠️), ~~**mode offline**~~ ✅ **corrigé le 2026-08-11 (D1) puis complété le 13/08 (D5)** — le pipeline de collecte n'est plus commenté, une visite embarque désormais contenus, audios et icônes, et une visite incomplète ne s'annonce plus téléchargée. **Reste à confirmer sur device** (§21 / D0), c'est le seul point encore ouvert du volet offline. Repasse UI globale, refacto SectionParcours côté manager-app/visitapp-web/mymuseum-visitapp (UI présente mais sous-comportements non revérifiés en détail — voir section "Refactoring majeur" de todo-features.md).
|
||
- **🧪 Implémenté mais jamais testé (2026-08-05)** : **onboarding self-service complet** — inscription sur myinfomate-landing (`/[lang]/signup`), création auto de l'instance + du premier user, essai 14j, Stripe (customer/Checkout/webhook/Tax), 9 emails Resend (domaine vérifié, envoi réel validé), job Hangfire du cycle d'essai, watermark « Aperçu » visitapp-web, écran Abonnement manager-app, mot de passe oublié + invitation user, plafond IA d'essai. Les 4 repos compilent, migrations appliquées en base locale, **aucun parcours exécuté** → checklist de test dans `todo-features.md` (section "🧪 Checklist de test end-to-end"). Reste à faire côté config : alias mail `onboarding@myinfomate.be`, et `whsec_` de la Stripe CLI pour tester le webhook en local.
|
||
- **🧪 Codé et committé le 2026-09-10 (rien de poussé), pas encore testé** : scan d'id brut (QR du Fort) depuis l'accueil, drapeau « afficher le scan QR » et **nom de l'application** par app (Mobile/Web), liens stores (SuperAdmin), QR du manager vers la nouvelle page **`app.myinfomate.be/download/…`**, suggestions de proximité beacon + GPS avec **notification écran verrouillé** (mobile) et suggestion GPS dans la page (web). Tests : [test-plan.md §23](test-plan.md) ; restes hors code (redirection `web.mymuseum.be`, déclarations stores) : carte kanban « QR codes, nom d'application… ».
|
||
- **À faire** : dashboard super-admin V2, facturation V2. ✅ **Le Stripe Customer Portal est complet le 2026-08-13** (backend + bouton manager-app).
|
||
- ⚠️ **Cette ligne était périmée sur six points, revérifiés dans le code le 2026-08-13.** Sont **faits** : écran audit log manager-app (front livré le 12/08), **rate limiting API Keys** (livré, pas seulement décidé — politique `ai` dans `Startup.cs:279`, `UseRateLimiter()` en `:344`, les deux endpoints décorés), gestion des users par instance (plafond serveur + compteur UI, 12/08), nettoyage `SectionEvent.ParcoursIds` (11/08), et le **backend** du Customer Portal (13/08). L'**unification `QuestionType`** n'est pas « à faire » mais **écartée** : le trio TextLibre/Digicode/ExpectedAnswer n'a jamais existé dans le code, l'enum a trois valeurs et le digicode est un comportement dérivé, pas un type — reste une propreté front, elle aussi livrée (alias nommés, 11/08).
|
||
- **📦 Reporté en V2 (décidé le 2026-08-07)** : **SectionForm**, **ressource 360°**, **AR image tracking (Mind AR)**. Les trois sont spécifiés en détail dans [todo-features.md](todo-features.md) mais sortent du périmètre V1 — aucun n'est un prérequis de la migration Postgres ni de la mise en prod. À reprendre tels quels quand la V1 sera stabilisée.
|
||
- **🐛 Bug ouvert (relevé le 2026-08-25)** : **la jauge de stockage du menu latéral ne se rafraîchit pas** après l’ajout (ni la suppression) d’une ressource. `QuotaBarsWidget` n’appelle `instanceGetQuota` qu’une fois, dans `initState` (`quota_bars_widget.dart:23`), et il vit dans le pied du menu **persistant** (`main_screen.dart:477`) : le chiffre affiché date de l’ouverture de session. ⚠️ **Le comptage serveur est correct** — `storageUsedBytes` est recalculé à chaque appel (`SUM(SizeBytes)`, `InstanceController.cs:383`) et le contrôle d’upload refait un `GET /quota` avant de téléverser (`resources_screen.dart:186-198`). D’où l’incohérence visible : une jauge à « 0 KB » et un refus 413 sur le même chiffre. Détail dans [todo-features.md](todo-features.md) — Quota stockage.
|
||
|
||
**Prochaine chose à faire si tu as 1h** : jouer le **§19.13 cas E** du plan de test (chasse au trésor / carnaval) de bout en bout, depuis la création dans manager-app. C'est le scénario le plus complet — il valide SectionMap + SectionParcours + géodéclenchement + questions + mode jeu d'un coup.
|
||
|
||
---
|
||
|
||
## 1bis. État des builds — mesuré le 2026-08-06
|
||
|
||
> Aucune app n'était buildable au début de l'audit. Deux corrections ont débloqué les 3 apps Flutter.
|
||
> Détail : **[parity-manager-visitapp.md §6](parity-manager-visitapp.md)** · checklist : **[test-plan.md §0](test-plan.md)**
|
||
|
||
| Repo | Build | Note |
|
||
|---|---|---|
|
||
| manager-service | ✅ `dotnet build` et ✅ `dotnet test` **124/124** (2026-08-06) | La remise en route de la suite a révélé un **bug backend réel** : `BuildAuditEntries()` ajoutait un `AuditLog` au contexte *pendant* l'énumération du `ChangeTracker` → `InvalidOperationException: Collection was modified` sur toute écriture d'entité auditée (Section, Resource, Configuration, Device, User, Instance). Corrigé : énumération matérialisée, logs ajoutés après la boucle. Invisible jusque-là parce que les tests ne compilaient plus |
|
||
| manager-app | ✅ `flutter build web` | débloqué : `// @dart=2.18` manquant dans `manager_api_new/lib/api/onboarding_api.dart` (fichier ajouté à la main pour l'onboarding, sans l'annotation de version que porte `api.dart`) — **cassait les 3 apps Flutter d'un coup** |
|
||
| mymuseum-visitapp | ✅ `flutter build apk` — **les 3 flavors, vérifiés le 2026-08-12** (`dev`, `mdlf`, `fortsaintheribert`) | ⛔ **Le ❌ « revérifié le 2026-08-11 » était périmé.** Le build passe, et sa config Android était **déjà à niveau** — c'est `tablet-app` qui était en retard sur lui, pas l'inverse. K5 s'est donc réduit à deux alignements que le build réclamait en avertissement : NDK 27.0.12077973 → **28.2.13676358** (`speech_to_text` le réclame nommément) et Kotlin 2.1.0 → **2.3.10** (seuil 2.2.20 annoncé par Flutter ; même version que `tablet-app`). L'APK passe de 382 à **349 Mo**. Les 4 erreurs Dart Ray-Ban restent hors du graphe de `main.dart` et ne gênent pas le build (§5bis) |
|
||
| visitapp-web | ✅ `npm run build` | débloqué : helper `getGeoPointLatLng()` dans `src/lib/geo.ts`, les 7 erreurs venaient d'un `unknown` non narrowé. ⚠️ ce type d'erreur est **invisible en `next dev`** |
|
||
| tablet-app | ✅ `flutter build apk` — **réparé le 2026-08-12**, APK produit pour la première fois depuis le 16 avril | ⛔ **Le diagnostic « un seul défaut, purement Gradle, peut-être réglé par `5a6701d` » était doublement faux.** Il a tenu des mois parce que personne n'avait lancé la commande. Réalité : **dix crans d'outillage** (Gradle 7.5 → 8.11.1, AGP 7.2.0 → 8.9.1, Kotlin 1.9.0 → 2.3.10, option AGP supprimée, jcenter mort, heap Gradle 1536M → 4096M, Jetifier coupé, `resolutionStrategy` sur `androidx.lifecycle` retiré) — **corrigés le 2026-08-12** — **puis 132 erreurs Dart** que le Gradle masquait : l'app est restée sur **l'ancien contrat d'API**, celui d'avant Postgres v3. Détail complet et suite : **[v1-plan.md lot K](v1-plan.md)** |
|
||
|
||
**Leçon** : `flutter analyze` et `next dev` ne suffisent pas. Seuls `flutter build` / `npm run build` / `dotnet test` disent la vérité — d'où la nouvelle section §0 du plan de test.
|
||
|
||
**Leçon renforcée le 2026-08-12** : un build **jamais lancé** ne vaut pas mieux qu'un build vert supposé. Trois affirmations de ce tableau ont sauté d'un coup dès qu'on a tapé la commande. Corollaire à retenir : *« à reconfirmer par un vrai build »* dans une doc veut dire **que ce n'est pas confirmé**, et un point non confirmé ne doit pas être chiffré comme une demi-heure.
|
||
|
||
⚠️ **Et un piège de vérification à connaître** : `flutter build apk … | tail` renvoie **le code de sortie du `tail`**, pas celui du build. Un échec y ressort en « exit code 0 ». Rediriger vers un fichier et lire `$?` séparément.
|
||
|
||
---
|
||
|
||
## 1ter. Chantier « migration Postgres v3 » — ordre de bataille (ajouté le 2026-08-07)
|
||
|
||
> Postgres n'est pas encore en prod. Trois chantiers ont été analysés le 2026-08-07 et découpés selon une règle unique :
|
||
>
|
||
> **Ce qui touche aux données déjà écrites part avec la migration. Ce qui est purement additif attend.**
|
||
>
|
||
> Chaque ligne est faite pour être attaquée dans une conversation dédiée : lire le doc, faire l'étape.
|
||
>
|
||
> ⚠️ Cette section dit **ce qui doit entrer dans le schéma**, pas comment on remplit la base. L'opération de bascule elle-même — et l'état de `MigrationController` — sont au **§1quinquies**.
|
||
|
||
→ **Détail complet : [status/postgres-v3.md](status/postgres-v3.md)**
|
||
|
||
---
|
||
|
||
## 1quater. Chantier « Guide IA V1 » — ordre d'exécution (arrêté le 2026-08-07)
|
||
|
||
> Cette section ne décrit **rien de neuf** : elle donne l'ordre dans lequel exécuter ce que trois plans détaillent déjà, parce que le chantier les traverse tous les trois et qu'aucun ne porte la vue d'ensemble.
|
||
>
|
||
> **Décision : tout est fait d'un coup, sans mise en prod intermédiaire.** Rien ne part en prod avant que le backlog (kanban + ce fichier) soit terminé — voir §1ter, la base Postgres est vide et c'est une fenêtre à ne pas refermer.
|
||
|
||
→ **Détail complet : [status/guide-ia-v1.md](status/guide-ia-v1.md)**
|
||
|
||
---
|
||
|
||
## 1sexies. Ordre d'exécution de toute la V1 — et le lot design (ajouté le 2026-08-11)
|
||
|
||
> Ce fichier dit **ce qu'il reste**, par domaine. Le kanban dit **où en est chaque chantier**. Ni l'un ni l'autre ne disait **dans quel ordre**, ni ce qui bloque quoi.
|
||
>
|
||
> → **[v1-plan.md](v1-plan.md)** — 9 lots (A à I plus D-bis), 18 liens de dépendance, chemin critique, arbitrages en attente. **4 à 5 semaines**, portées à 5-6 avec le lot design.
|
||
|
||
→ **Détail complet : [status/ordre-execution-v1.md](status/ordre-execution-v1.md)**
|
||
|
||
---
|
||
|
||
## 1quinquies. La bascule elle-même — Mongo → Postgres en prod (ajouté le 2026-08-09)
|
||
|
||
> **Trou identifié le 2026-08-09** : le §1ter dit *ce qui doit entrer dans le schéma avant que la base se remplisse*. Il ne dit nulle part **comment on remplit la base**. L'opération de bascule n'était écrite ni ici, ni dans le kanban, ni dans aucun plan de `v2/`.
|
||
>
|
||
> Rappel : la prod tourne **encore sur MongoDB**. Le transfert se fait par `MigrationController` (`POST /api/migration/run`, paramètres `dryRun` et `instanceId`), qui rejoue Instances → Resources → Users → Configurations → ApplicationInstances → Sections → Devices, puis relie les menus et enrichit les ressources PDF.
|
||
|
||
→ **Détail complet : [status/bascule-prod.md](status/bascule-prod.md)**
|
||
|
||
---
|
||
|
||
## 2. Tests
|
||
|
||
→ Détail complet : **[test-plan.md](test-plan.md)**
|
||
|
||
Checklist manuelle organisée en 20 sections + non-régression. À cocher au fur et à mesure avant une mise en prod. Section "Hors scope" = features non implémentées, pas testées.
|
||
|
||
Ordre conseillé :
|
||
0. **§21 — Visite hors ligne** (ajouté le 2026-08-07) : bugs suspectés d'après le code, à confirmer sur device avant de planifier le chantier
|
||
1. **§0 — Porte d'entrée build** (5 commandes, bloquant absolu)
|
||
2. **§19 — Parité manager-app → apps visiteur**, par type de section : c'est le chapitre qui répond à « tout ce que je configure est-il visible ? ». Le §19.13 (SectionParcours, 5 cas d'usage) est le plus à risque.
|
||
3. §18 — Onboarding self-service (jamais exécuté)
|
||
4. §1-17 — features par lot, §16 non-régression
|
||
|
||
---
|
||
|
||
## 2bis. Parité manager-app → apps visiteur
|
||
|
||
→ **[parity-manager-visitapp.md](parity-manager-visitapp.md)** (audit du 2026-08-05, sur le code réel)
|
||
|
||
- **Couverture par type de section : complète** — les 13 `SectionType` sont dispatchés dans `mymuseum-visitapp` et `visitapp-web`, aucun écran vide.
|
||
- **17 écarts au niveau champ** au moment de l'audit : 7 côté mobile, 10 côté web. Le plus lourd — l'absence d'assistant IA côté web, alors que le plan Essentiel est web-only — est **résolu le 2026-08-06**, et répercuté sur mobile le même jour.
|
||
- Suivi des corrections : table du **[test-plan.md §20](test-plan.md)**.
|
||
|
||
→ **Détail complet : [status/parite-manager-visitapp.md](status/parite-manager-visitapp.md)**
|
||
|
||
---
|
||
|
||
## 3. Sécurité & dette technique
|
||
|
||
→ Audits : **[security/audit-securite-manager-service.md](security/audit-securite-manager-service.md)** et **[security/audit-manager-app.md](security/audit-manager-app.md)** (2026-07-13/14)
|
||
|
||
- **manager-service** — le point critique est la **rotation des secrets committés** (JWT signing key, clés API, connection strings, MQTT, Telegram). Gravité inchangée, mais **déplacée en fin de backlog le 2026-08-11** : les 6 repos sont privés sur un Gitea auto-hébergé. ⚠️ Contrainte à ne pas perdre — **la rotation doit précéder I3** (compose/Traefik prod), sinon la prod naît avec les clés de l'historique et il faut rotationner deux fois. Puis quatre niveaux Haute → Basse.
|
||
- **manager-app** — le critique (`manager_api_new` désynchronisé, 68 erreurs de bruit) est ✅ **résolu le 2026-08-11** : `flutter analyze` passe à 3 issues et redevient un feu vert utilisable. Au passage, les 3 déclencheurs de génération OpenAPI ont été supprimés, ce qui **verrouille la règle « `manager_api_new` s'édite à la main »**. Reste Haute → Basse : duplication du shell de dialog, `build()` monolithiques, i18n contournée, clé AES en dur. → **La duplication du shell de dialog a désormais sa maquette et sa carte** : `DOCS/claude design/refonte-configuration-sections.html` §6 (coquille, inventaire des 29 dialogues, deux dialogues dessinés) et `kanban/cards/5-planifie/290-…`. ⚠️ **Ordre imposé** : les 8 `showNewOrUpdate*` sont *absorbés* par l'éditeur de collection du gabarit B — extraire un scaffold pour eux d'abord, ce serait refactoriser du code à supprimer. Voir la note dans `security/audit-manager-app.md`.
|
||
|
||
→ **Détail complet, par priorité et avec les cases à cocher : [status/securite-dette-technique.md](status/securite-dette-technique.md)**
|
||
|
||
---
|
||
|
||
## 4. Infrastructure & Ops
|
||
|
||
- [x] ✅ **Travail non committé — résorbé. Revérifié le 2026-08-11 (2e passe) : plus rien en attente.** Les **9 repos** (DOCS compris) sont propres (`git status --porcelain` vide partout) **et à jour avec leur remote** (aucun `ahead`/`behind`). L'alerte du 2026-08-09 et sa révision du matin du 11/08 (« ~41 fichiers en working tree dont 9 non suivis ») sont toutes deux **périmées** : le lot 3 RAG est dans `18e4240`, le socle visuel + Guide IA dans `eb8e849`. **L'étape 1 du lot A est terminée** — ne pas la re-planifier
|
||
- Derniers commits par repo : `manager-service` `18e4240` (RAG : pipeline d'ingestion, endpoints du guide IA, journalisation RGPD) · `manager-app` `eb8e849` (socle visuel et écran Guide IA à deux onglets) · `visitapp-web` `473fc3a` · `mymuseum-visitapp` `af44927` · `tablet-app` `5a6701d` (drapeaux du migrateur Flutter) · `myinfomate-landing` `d91cf7f` · `unov-landing` `cfa70c4` · `OpenGlasses` `1d887d7`
|
||
- Rappel de l'état des branches : `manager-service` → `MyInfoMate_3.0`, `manager-app` → `Interface-refacto`, `mymuseum-visitapp` → `Meta-Rayban-Test` (23 commits d'avance sur `master`, voir §5bis), `tablet-app` → `AI-Assistant-test`, `visitapp-web` et les deux landings → `master`
|
||
- [ ] **pg_dump quotidien** pour `manager-service` (Postgres `my_info_mate`), en complément du snapshot OVH. ⚠️ **Bloquant au moment de la bascule** : point 18 du [§1quinquies](#1quinquies-la-bascule-elle-même--mongo--postgres-en-prod-ajouté-le-2026-08-09), le seul filet du jour J
|
||
- 🔨 **Scripts livrés et testés le 2026-09-07** — `manager-service/ManagerService/Deployment/backup/`, installation et restauration documentées dans `README.md` et **`RESTORE.md`**. Cycle complet validé sur la base de dev : dump → vérification de relecture → restauration dans une base jetable → **25 tables aux comptages identiques**. Extraction par instance validée aussi (les deux extractions totalisent exactement le global). Embeddings exclus : dump de 12 Mo → **1,7 Mo**
|
||
- ✅ **Destination créée le 2026-09-07** — projet GCP `myinfomate-backups` (séparé de `mymuseum-3b97f`), bucket `gs://unov-myinfomate-backups` en `EU` multi-région, versioning activé, accès public interdit, lifecycle 400 jours sous `pg/` seulement. Service account `backup-writer` en `objectCreator` + `objectViewer` : **incapable de supprimer, et vérifié** (l'écriture passe, le `rm` renvoie `403 storage.objects.delete denied`). Détail et test rejouable dans `Deployment/backup/README.md`
|
||
- ⛔ **Ce n'est pas encore une sauvegarde** : `rclone` n'est ni installé ni configuré sur le VPS, donc rien ne part encore hors site. Et `notify.sh` n'est branché sur aucun canal — carte kanban « Brancher `notify.sh` sur un canal réel »
|
||
- 📌 **Volume des médias : 1,43 Go** (`gcloud storage du -s gs://mymuseum-3b97f.appspot.com`, 2026-09-07). Le bucket connaissait la réponse que le plan attendait du backfill. Assez petit pour tenir dans le même bucket de sauvegarde sous `media/` — **pas besoin d'OVH Object Storage**, la disposition croisée envisagée le 07/09 est abandonnée pour cette raison
|
||
- ✅ **Versioning activé sur le bucket des médias le 2026-09-07** — `versioning_enabled: True` sur `gs://mymuseum-3b97f.appspot.com`, plus une lifecycle rule qui purge les versions périmées à 30 jours (le bucket n'avait **aucune** règle auparavant, rien n'a été écrasé). L'ordre importait : le filet est en place **avant** que `Firebase:StorageBucket` soit renseignée (carte « Poser `Firebase:StorageBucket` »), jour où la suppression de blob devient réelle. Le bucket portait déjà une soft delete de 7 jours depuis mars 2024
|
||
- 📌 **Décision de conception** : **un dump global, pas un par client.** Une restauration par client se fait par extraction depuis le dump global (`extract-instance.sh`) — 14 tables portent `InstanceId`, 7 tables filles se rattachent par leur parent. Des sauvegardes par client multiplieraient par N les jobs à planifier, les échecs à surveiller et les restaurations à tester, pour la même capacité de récupération
|
||
- ✅ **Médias copiés le 2026-09-07** — 1,43 Go, 2407 objets, `gcloud storage rsync` serveur à serveur vers `gs://unov-myinfomate-backups/media/`. **Taille identique à l'octet**, zéro erreur. C'est la première sauvegarde des médias depuis le début du projet. ⛔ **Pas encore planifiée** : c'est une copie unique. **Storage Transfer Service envisagé puis écarté le 2026-09-07** — 5 attributions IAM et un agent de service avec droit de suppression, pour automatiser une commande à relancer toutes les quelques semaines sur des données qui bougent de ~2 ressources par mois : disproportionné. Le mécanisme reste le `rsync`, qui tourne avec un compte humain sans aucun changement de permission, et sera ajouté aux timers du VPS avec la sauvegarde Postgres
|
||
- 🔍 **L'inventaire des orphelins est à moitié fait, gratuitement** — 27 objets sur 2408 n'appartiennent à aucun client : 19 sous un id à un caractère de celui de MyInfoMate (`…f1` vs `…f2`), 2 sous MNAHA (qui n'existe qu'en base de dev), et 6 fichiers de test à la racine du bucket (`giphy.gif`, une vidéo Cybertruck, des `file_example_*`) qui ne suivent pas le schéma `pictures/{instanceId}/{id}` et sont donc invisibles au quota. Détail et réserves dans [v2/media-storage-plan.md](v2/media-storage-plan.md)
|
||
- ⛔ **Deuxième chose qu'il débloque** : le job `visit-events-purge` (purge des stats au-delà de 13 mois) est codé et enregistré mais **volontairement inactif** — il ne supprimera rien tant que `Stats:RetentionDays` n'est pas défini. Ne l'activer (`Stats__RetentionDays=395`) qu'une fois ce pg_dump réellement hors site
|
||
- [ ] **Fermer le port PostgreSQL exposé publiquement** via Traefik/Docker (détail dans [todo-features.md](todo-features.md), section "Infrastructure — Sécurité réseau") — accès DBeaver via tunnel SSH uniquement
|
||
- [x] 🔨 **Sauvegarde de la prod Mongo — faite le 2026-09-07.** `Deployment/backup/dump-mongo-prod.sh`, lecture seule (aucun `mongorestore` dans le script, volontairement). L'export de référence datait du 1er avril. Delta sur 5 mois : 11 sections créées, 3 supprimées, 17 modifiées, 9 ressources créées. **VisitNamur crée du contenu, MDLF retouche l'existant, Fort Saint Héribert n'a rien touché** — utile à savoir avant de reprendre contact avec eux. ⚠️ Piège : le formatage des dates change entre versions de `mongoexport` (`.420Z` → `.42Z`) et fait apparaître 239 fausses modifications ; normaliser avant de comparer
|
||
- [ ] **Backup Mongo automatique en cron** — le script existe désormais, reste à le planifier. Voir [todo-landing-deploy.md](todo-landing-deploy.md), section 5 (dump + `docker cp` vers l'hôte, pas seulement dans le conteneur)
|
||
- [x] Déploiement landing page (`docker-compose-landing.yml` séparé, ne jamais toucher au compose principal) — voir [todo-landing-deploy.md](todo-landing-deploy.md) pour les règles à respecter
|
||
|
||
---
|
||
|
||
## 5. Roadmap produit — nouveaux canaux & IA
|
||
|
||
Dix-neuf chantiers de canaux et d'IA, chacun avec son plan détaillé. État au 2026-09-02 :
|
||
|
||
- **V1** — **visiteur web** : `visitapp-web` build ✅, les 13 types de section rendus, assistant IA inclus ; **il ne manque que le Dockerfile et l'entrée `app.myinfomate.be` au compose**. Bloquant, le plan Essentiel vendu par l'onboarding est web-only. Plus l'**écran Guide IA**. La **Médiathèque** (basculée en V1 le 2026-09-02) est **codée de bout en bout le même jour** — index inverse des usages, panneau de détail, facettes, suppression protégée, les deux bugs corrigés ; `dotnet test` 236/236 et `flutter build web` verts, **mais la checklist de 15 points reste à passer dans un navigateur** (colonne « À tester » du kanban). Voir [v1-mediatheque-plan.md](v1-mediatheque-plan.md).
|
||
- **Livrés** — export PDF des stats à la demande, historique 13 mois pour tous les plans, refonte de l'écran Statistiques (⚠️ jamais ouvert dans un navigateur).
|
||
- **V2** — module Studio (génération IA d'images), Personnages (une entité `Persona` unifiant trois plans), TTS pré-généré, kiosk web, VR Meta Quest, import IA + RAG. ⛔ **Prérequis dur commun au Studio et au TTS** : le backend ne sait pas écrire dans le bucket (`IResourceBlobService` n'a que `DeleteAsync`).
|
||
- **Abandonné le 2026-09-02** — talking head : son lipsync reposait sur `enable_time_pointing` de Google Cloud TTS, or le code livré tourne sur Gemini TTS. Le plan était sans fondation, pas « à faire ».
|
||
|
||
→ **Détail complet, la table des 19 chantiers : [status/roadmap-canaux.md](status/roadmap-canaux.md)**
|
||
|
||
---
|
||
|
||
## 5bis. Lunettes Ray-Ban Meta — état réel du code (relevé le 2026-08-09)
|
||
|
||
> Cette section corrige une erreur de ce fichier : la roadmap classait l'AR lunettes en « pas commencé, pilote subventionné quand le SDK sort de preview ». **Un POC fonctionnel existe depuis mai-juin 2026**, ~2 700 lignes de Dart dans `mymuseum-visitapp`, sur la branche **`Meta-Rayban-Test`** (23 commits d'avance sur `master`, jamais mergée — c'est la branche de travail courante du repo).
|
||
|
||
→ **Détail complet : [status/rayban-meta.md](status/rayban-meta.md)**
|
||
|
||
---
|
||
|
||
## 5ter. Visibilité — SEO/GEO de la landing & LinkedIn (ouvert le 2026-09-10)
|
||
|
||
→ Plan en 21 actions et suivi : **[myinfomate-landing/audit-seo-geo.md](../myinfomate-landing/audit-seo-geo.md)** (§0) · posts : **[linkedin-posts-lancement.md](linkedin-posts-lancement.md)**
|
||
|
||
- ✅ **Corrections rapides (actions 1 à 5)** faites le 2026-09-10 : titres, schema `Organization` (adresse, TVA), 3 offres dans le schema, 9 modules dans le HTML, liens morts. Build OK, vérifié dans le HTML servi. **Stagées, pas committées.**
|
||
- ✅ **LinkedIn** : vitrine MyInfoMate créée sous Unov, fiche produit soumise à LinkedIn.
|
||
- ✅ **Actions 6 à 8** faites le 2026-09-10 : `llms.txt` en français, **prérendu statique rétabli** (58 pages, le layout racine est désormais `[lang]/layout.tsx`), page **`/{lang}/tarifs`** avec FAQ tarifaire. Stagées, pas committées.
|
||
- ✅ **`/assistant-ia` livrée le 2026-09-10 dans les 4 langues** (relue par Thomas en FR) — 6 FAQ par langue, `hreflang` complet. **62 pages prérendues, 54 URLs au sitemap.** Au passage, les liens légaux des footers sont passés en `<Link>` : le lint est à **0 erreur** (15 avant).
|
||
- ✅ **CGU publiées le 2026-09-10** sur `myinfomate.be/conditions-generales` — le lien de la case de consentement de `/signup` pointait jusque-là vers `/{lang}#`, c'est-à-dire nulle part. Lien ajouté aussi dans les pieds de page des 4 langues et dans le sitemap. **Deux contradictions corrigées dans [cgu-myinfomate.md](cgu-myinfomate.md)** : §6.1 citait Starter/Standard (2 et 10 Go) et §7.1 réservait l'IA aux « plans Standard et Premium ». Ce fichier reste la source ; la page Next en est le rendu, à tenir synchrone.
|
||
- ⚠️ **Reste dû : la validation juridique des CGU** (jamais faite, le document le dit depuis avril) et le **DPA** qu'un acheteur public demandera. Carte kanban dédiée ; à faire **avant** d'ouvrir l'inscription à de vrais clients payants, pas avant la mise en prod technique.
|
||
- ⏭️ **Prochain** : vocabulaire acheteur dans les 6 segments, puis page marchés publics. **Angle validé le 10/09** : MyInfoMate a été retenu sur **cahier des charges publié** par Visit Namur — c'est la preuve à mettre en avant. ⚠️ Aucun document d'appel d'offres n'existe encore (attestations fiscale/ONSS, DPA RGPD, attestations de bonne exécution) : la page ne doit rien promettre à ce sujet.
|
||
- ⚠️ **Posts LinkedIn en deux vagues** : les posts sur des déploiements réels peuvent partir maintenant ; ceux qui poussent à l'inscription (IA, prix, essai) attendent la bascule prod et un onboarding testé.
|
||
|
||
---
|
||
|
||
## 6. Sous-projets MyInfoMate
|
||
|
||
- **MyInfoMate Sport** — pilote Hockey Namur. Vue d'ensemble : [sport/solution-overview.md](sport/solution-overview.md), spec : [sport/myinfomate-sport-spec.md](sport/myinfomate-sport-spec.md), pitch : [sport/pitch-commercial.md](sport/pitch-commercial.md)
|
||
- **MyInfoMate Crèche** — pilote childcare en cours. Vue d'ensemble : [creche/solution-overview.md](creche/solution-overview.md), spec : [creche/myinfomate-creche-spec.md](creche/myinfomate-creche-spec.md), pitch : [creche/pitch-commercial.md](creche/pitch-commercial.md)
|
||
|
||
---
|
||
|
||
## 6bis. Cohérence de la doc — audit du 2026-08-07
|
||
|
||
Passage en revue de tous les fichiers `DOCS/` (hors `sport/` et `creche/`). Corrigé directement :
|
||
|
||
| Fichier | Ce qui était faux |
|
||
|---|---|
|
||
| [roadmap.md](roadmap.md) | Annonçait **Claude API** comme LLM à 4 endroits — c'est **Gemini 2.5 Flash-Lite**. Quota IA en requêtes → tokens |
|
||
| [parity-manager-visitapp.md](parity-manager-visitapp.md) | L'intro du §6 disait « visitapp-web reste cassé » et B2 « tests backend ❌ » alors que les deux sont corrigés depuis le 2026-08-06 — le doc se contredisait lui-même |
|
||
| [v2/tts-pregenerated-plan.md](v2/tts-pregenerated-plan.md) | Chemin Firebase « à confirmer » et faux. Le vrai est `pictures/{instanceId}/{resourceId}`, sans extension. Le refactor uploads est partiellement devancé par `media-storage-plan.md` |
|
||
| [plan-import-ia-stats-subsides.md](plan-import-ia-stats-subsides.md) | « Aucune infra email n'existe » → **Resend est en place** (9 templates, domaine vérifié). Quota `AiRequestsPerMonth` → `AiTokensPerMonth` |
|
||
| [security/audit-securite-manager-service.md](security/audit-securite-manager-service.md) | `ImageHelper` : confirmé **code mort** qui planterait sur Linux. Double `SaveChangesAsync` : à revérifier après le fix `BuildAuditEntries` du 2026-08-06 |
|
||
| [solution-overview.md](solution-overview.md) | Grille tarifaire **Starter/Standard/Premium (69/99/199 €)** — structure abandonnée. Marquée obsolète |
|
||
|
||
### 🔴 Demande ton arbitrage — non corrigé volontairement
|
||
|
||
**[cgu-myinfomate.md](cgu-myinfomate.md) §5 décrit des plans qui n'existent plus** : Starter / Standard / Premium (69 / 99 / 199 € HTVA), quotas IA en requêtes. La réalité est Essentiel / Pro / Premium / Enterprise (39 / 99 / 179 €), quotas en tokens.
|
||
|
||
C'est un **document contractuel** — je ne l'ai pas réécrit. À reprendre en vérifiant d'abord ce que les clients existants ont effectivement signé.
|
||
|
||
### Ménage — décidé le 2026-08-07
|
||
|
||
- **`offre-commerciale.md` : ne pas supprimer.** Vérification faite, il ne contient pas qu'une grille : clients cibles, services complémentaires, forfait événementiel, frais de mise en place, projection de revenus. **Retirer les seules tables de prix** et garder le reste comme document de stratégie commerciale.
|
||
- Quatre documents portaient une grille tarifaire (roadmap, solution-overview, offre-commerciale, cgu) alors que la source de vérité est `myinfomate-landing` → **supprimer les tables, garder un lien**.
|
||
- ✅ **CGU §5 reprises le 2026-08-07** depuis la landing : Essentiel/Pro/Premium/Enterprise (39/99/179/devis), et un §5.1bis qui définit le quota IA **en tokens** en renvoyant au back-office pour les valeurs — plutôt que de figer un chiffre dans un contrat.
|
||
- ✅ **Landing corrigée** — la clé `features.reqPerMonth` n'existe plus dans `myinfomate-landing/src` (vérifié le 2026-08-11). Ce point était encore listé comme ouvert à deux endroits de ce fichier alors que le kanban le donnait fait : c'est le kanban qui avait raison.
|
||
- ⚠️ **Champs morts — partiellement traités.** `FactContent`, `IsStepLocked`, `IsHiddenInitially` sont bien supprimés (migration `RemoveDeadGuidedStepFlags`). **Restent en base** : `SectionEvent.ParcoursIds`, `SectionEvent.IconResourceId`, `SectionMap.MapResourceId` — ce dernier étant en plus mappé vers `iconResourceId` dans son DTO, ce qui ajoute une confusion de nommage.
|
||
- **Champs « morts » — décision révisée le 2026-08-07 après vérification du code.** Deux des trois ne sont pas morts :
|
||
- `SectionMap.MapResourceId` → **à renommer, pas à supprimer.** Il est branché de bout en bout (`SectionFactory:179/511`, `SectionMap.ToDTO:58`, `MigrationController:469`) et exposé au front sous le nom `iconResourceId` : la colonne porte l'icône de la carte, pas une « ressource carte ». Le renommer en `IconResourceId` supprime la confusion. Reste à décider si le web doit l'honorer (écart W10).
|
||
- `SectionEvent.ParcoursIds` → **à investiguer avant de trancher.** Intention produit documentée (depuis un SectionEvent mis en avant, retrouver les parcours liés aux jours d'un carnaval). `GuidedPath.SectionEventId` couvre le lien au niveau *événement* ; reste à vérifier qu'il couvre aussi le niveau *jour / bloc de programme*. Ne pas supprimer tant que ce n'est pas établi.
|
||
- `SectionEvent.IconResourceId` → sans usage visiteur identifié, seul candidat réel à la suppression.
|
||
- **`Section.meterZoneGPS` : à implémenter, pas à retirer.** Le rayon de déclenchement a une vraie raison d'être variable — une salle de musée demande ~10 m, un parcours extérieur comme le Fort en demande 50-100. La constante en dur à 100 m est fausse dans les deux cas.
|
||
|
||
---
|
||
|
||
## 7. Documents de référence (pas des todos — pas besoin de "traiter")
|
||
|
||
- [solution-overview.md](solution-overview.md) — présentation produit core
|
||
- [parity-manager-visitapp.md](parity-manager-visitapp.md) — audit de parité manager-app → apps visiteur (2026-08-05) : couverture par section, 17 écarts au niveau champ, état des builds, méthode pour refaire l'audit
|
||
- [guided-path-types.md](guided-path-types.md) — guide de référence SectionParcours
|
||
- [section-event-map-setup.md](section-event-map-setup.md) — guide setup SectionEvent/SectionMap
|
||
- [design-prompts.md](design-prompts.md) — prompts design pour Google Stitch/Claude Design
|
||
- [competitor-analysis.md](competitor-analysis.md) — comparatif concurrents
|
||
- [cgu-myinfomate.md](cgu-myinfomate.md) — CGU
|
||
- ⚠️ [offre-commerciale.md](offre-commerciale.md) — **obsolète**, source de vérité = myinfomate-landing (voir mémoire `project_pricing_plans`)
|
||
- ⚠️ [roadmap.md](roadmap.md) — contient aussi une table "Modules existants" + une table de prix en dehors de la section XR (section 5 ci-dessus) : cette table de prix est une **ancienne copie**, potentiellement désynchronisée de myinfomate-landing (source de vérité) — à vérifier avant de s'y fier
|
||
- `openwakeword/` — scripts/notebook d'entraînement de modèle wake word (code, pas de la doc à jour manuellement)
|
||
- `claude design/` — mockups HTML générés (MyInfoMate Parcours), à consulter visuellement, pas du texte à synchroniser
|
||
|
||
---
|
||
|
||
## Comment mettre à jour ce fichier
|
||
|
||
> 🗂️ **Le kanban en est le reflet.** Source de vérité du contenu : **[kanban/](kanban/)**, versionné à côté de ce fichier — `kanban.html` en est le rendu généré.
|
||
> Publié à l'adresse https://claude.ai/code/artifact/4c317904-2e23-45d3-ac14-dcca678ae5d3
|
||
>
|
||
> ⚠️ **L'artifact appartient au compte propriétaire.** Lecture et republication **fonctionnent** quand la machine est connectée à ce compte (vérifié le 2026-08-11 ; la note « impossible depuis cette machine » datait d'une session où un autre compte était actif). Si l'artifact n'apparaît pas, basculer de compte. **Avant de republier : lire la version publiée et fusionner** — le fichier du repo et la version en ligne peuvent avoir divergé (constaté le 2026-08-11, une colonne entière de 10 cartes existait en ligne sans être dans le fichier). Jamais de `force:true`. D'où le découpage :
|
||
>
|
||
> | | Qui | Quoi |
|
||
> |---|---|---|
|
||
> | Contenu | n'importe quelle session | éditer `DOCS/kanban/` — **un chantier = un fichier `.md`** — puis `python3 DOCS/tools/build_kanban.py` |
|
||
> | Diffusion | le compte propriétaire | republier `kanban.html` sur l'artifact |
|
||
>
|
||
> ⚠️ **`DOCS/kanban.html` est généré : ne pas l'éditer à la main.** Les compteurs (colonnes **et** bandeau du haut) sont calculés à partir du nombre de fichiers — il n'y a plus rien à compter ni à vérifier. Ajouter = créer un fichier dans le dossier de la colonne ; déplacer = déplacer le fichier ; clore = déplacer vers `kanban/done/`. Détail : [kanban/README.md](kanban/README.md).
|
||
>
|
||
> Un hook `PostToolUse` (`.claude/hooks/status-kanban-reminder.py`) rappelle ce report à chaque écriture sur ce fichier. Il rappelle, il ne publie pas — une correction de formulation ne justifie pas de toucher au tableau.
|
||
|
||
Ce fichier est un index, pas une source de vérité duplicée. **Les sections lourdes vivent dans [status/](status/)** — une section par fichier ; ici ne restent que leur chapeau et le lien. Éditer le détail dans `status/`, et ne toucher au chapeau que si l'état d'ensemble change.
|
||
|
||
- Nouvelle feature terminée/à faire → éditer **todo-features.md**, pas ici (sauf si ça change le résumé de la section 1)
|
||
- Nouveau point sécurité traité → cocher dans **[status/securite-dette-technique.md](status/securite-dette-technique.md)** **et** noter "Déjà corrigé" dans le fichier audit correspondant
|
||
- Nouveau chantier roadmap → ajouter une ligne dans la table de **[status/roadmap-canaux.md](status/roadmap-canaux.md)**, créer le plan détaillé séparément si ça dépasse quelques lignes
|