DOCS/STATUS.md

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

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.
• À 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 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 — 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 · checklist : test-plan.md §0

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

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

---

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

---

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 — 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

---

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

---

2. Tests

→ Détail complet : 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 (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.

→ Détail complet : status/parite-manager-visitapp.md

---

3. Sécurité & dette technique

→ Audits : security/audit-securite-manager-service.md et 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

---

4. Infrastructure & Ops

• ✅ 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, 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
  • ⛔ 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, section "Infrastructure — Sécurité réseau") — accès DBeaver via tunnel SSH uniquement
• 🔨 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, section 5 (dump + docker cp vers l'hôte, pas seulement dans le conteneur)
• Déploiement landing page (docker-compose-landing.yml séparé, ne jamais toucher au compose principal) — voir 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.
• 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

---

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

---

6. Sous-projets MyInfoMate

• MyInfoMate Sport — pilote Hockey Namur. Vue d'ensemble : sport/solution-overview.md, spec : sport/myinfomate-sport-spec.md, pitch : sport/pitch-commercial.md
• MyInfoMate Crèche — pilote childcare en cours. Vue d'ensemble : creche/solution-overview.md, spec : creche/myinfomate-creche-spec.md, pitch : 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	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	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	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	« Aucune infra email n'existe » → Resend est en place (9 templates, domaine vérifié). Quota AiRequestsPerMonth → AiTokensPerMonth
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	Grille tarifaire Starter/Standard/Premium (69/99/199 €) — structure abandonnée. Marquée obsolète

🔴 Demande ton arbitrage — non corrigé volontairement

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 — présentation produit core
• 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 — guide de référence SectionParcours
• section-event-map-setup.md — guide setup SectionEvent/SectionMap
• design-prompts.md — prompts design pour Google Stitch/Claude Design
• competitor-analysis.md — comparatif concurrents
• cgu-myinfomate.md — CGU
• ⚠️ offre-commerciale.md — obsolète, source de vérité = myinfomate-landing (voir mémoire project_pricing_plans)
• ⚠️ 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/, 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.

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/ — 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 et noter "Déjà corrigé" dans le fichier audit correspondant
• Nouveau chantier roadmap → ajouter une ligne dans la table de status/roadmap-canaux.md, créer le plan détaillé séparément si ça dépasse quelques lignes