diff --git a/kanban.html b/kanban.html
index da49790..569aee0 100644
--- a/kanban.html
+++ b/kanban.html
@@ -1,5 +1,5 @@
-
-<title>MyInfoMate — Tableau de chantiers</title>
+
+<title>MyInfoMate — Tableau de chantiers</title>
 
 <style>
   :root {
@@ -444,23 +444,23 @@
 
   <header class="masthead">
     <div>
-      <h1>MyInfoMate — tableau de chantiers</h1>
-      <p>Vue d'état consolidée depuis <code>DOCS/</code>. Source de vérité : <code>STATUS.md</code> — cette page en est le reflet, pas le remplaçant. Filtrez sur <strong>V1</strong> pour ne voir que ce qui reste avant la mise en prod. <strong>L'ordre d'exécution</strong>, lui, est dans <code>v1-plan.md</code> : ce tableau dit où en est chaque chantier, pas lequel bloque lequel.</p>
+      <h1>MyInfoMate — tableau de chantiers</h1>
+      <p>Vue d'état consolidée depuis <code>DOCS/</code>. Source de vérité : <code>STATUS.md</code> — cette page en est le reflet, pas le remplaçant. Filtrez sur <strong>V1</strong> pour ne voir que ce qui reste avant la mise en prod. <strong>L'ordre d'exécution</strong>, lui, est dans <code>v1-plan.md</code> : ce tableau dit où en est chaque chantier, pas lequel bloque lequel.</p>
     </div>
     <div class="stamp">
-      Mise à jour · 2026-08-12<br>
-      Postgres v3 · pas encore en prod
+      Mise à jour · 2026-08-12<br>
+      Postgres v3 · pas encore en prod
     </div>
   </header>
 
-  <section class="summary" aria-label="Chiffres clés">
+  <section class="summary" aria-label="Chiffres clés">
     <div class="stat"><span class="n n-critical">1</span><span class="k">Urgent</span></div>
     <div class="stat"><span class="n n-info">1</span><span class="k">Migration v3</span></div>
     <div class="stat"><span class="n n-warn">2</span><span class="k">Bugs ouverts</span></div>
-    <div class="stat"><span class="n">6</span><span class="k">À tester</span></div>
-    <div class="stat"><span class="n">23</span><span class="k">Planifié</span></div>
+    <div class="stat"><span class="n">6</span><span class="k">À tester</span></div>
+    <div class="stat"><span class="n">23</span><span class="k">Planifié</span></div>
     <div class="stat"><span class="n n-gate">8</span><span class="k">Bascule prod</span></div>
-    <div class="stat"><span class="n n-good">48</span><span class="k">Fait récemment</span></div>
+    <div class="stat"><span class="n n-good">48</span><span class="k">Fait récemment</span></div>
   </section>
 
   <div class="filters" role="group" aria-label="Filtrer par domaine">
@@ -476,11 +476,11 @@
   <div class="filters filters-horizon" role="group" aria-label="Filtrer par horizon">
     <span class="lead">Horizon</span>
     <button class="chip-btn" type="button" data-horizon-filter="all" aria-pressed="true">Tout</button>
-    <button class="chip-btn" type="button" data-horizon-filter="v1" aria-pressed="false">V1 — reste à faire</button>
-    <button class="chip-btn" type="button" data-horizon-filter="v2" aria-pressed="false">V2 — reporté</button>
+    <button class="chip-btn" type="button" data-horizon-filter="v1" aria-pressed="false">V1 — reste à faire</button>
+    <button class="chip-btn" type="button" data-horizon-filter="v2" aria-pressed="false">V2 — reporté</button>
   </div>
 
-  <p class="empty-msg hidden" role="status">Aucun chantier ne correspond à ces deux filtres.</p>
+  <p class="empty-msg hidden" role="status">Aucun chantier ne correspond à ces deux filtres.</p>
 
   <div class="board">
 
@@ -490,10 +490,10 @@
       <div class="stack">
 
         <article class="card" data-area="infra">
-          <div class="card-meta"><span class="tag">infra</span><span class="flag f-critical">Sécurité</span></div>
-          <h3>Port PostgreSQL exposé publiquement</h3>
-          <p>À fermer via Traefik/Docker. Accès DBeaver par tunnel SSH uniquement.</p>
-          <span class="src">todo-features.md — Sécurité réseau</span>
+          <div class="card-meta"><span class="tag">infra</span><span class="flag f-critical">Sécurité</span></div>
+          <h3>Port PostgreSQL exposé publiquement</h3>
+          <p>À fermer via Traefik/Docker. Accès DBeaver par tunnel SSH uniquement.</p>
+          <span class="src">todo-features.md — Sécurité réseau</span>
         </article>
 
 
@@ -508,8 +508,8 @@
         <article class="card" data-area="manager">
           <div class="card-meta"><span class="tag">manager-app</span><span class="flag f-warn">code mort depuis C3</span></div>
           <h3>Retirer la suppression de blob de manager-app</h3>
-          <p><code>show_resource_popup.dart:130-137</code> supprime l'objet du bucket <em>après</em> avoir supprimé la ligne, et avale l'échec dans un <code>print</code> — un échec laissait un orphelin définitif que le quota ne comptait plus. Depuis C3 (12/08) le serveur supprime le blob <strong>avant</strong> la ligne : le client tombe désormais sur un objet déjà absent. Ce n'est plus dangereux, c'est devenu inutile. ⚠️ <strong>Ne pas le retirer avant d'avoir renseigné <code>Firebase:StorageBucket</code> en prod</strong> (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.</p>
-          <span class="src">v1-plan.md lot C — C6 · STATUS.md §1sexies</span>
+          <p><code>show_resource_popup.dart:130-137</code> supprime l'objet du bucket <em>après</em> avoir supprimé la ligne, et avale l'échec dans un <code>print</code> — un échec laissait un orphelin définitif que le quota ne comptait plus. Depuis C3 (12/08) le serveur supprime le blob <strong>avant</strong> la ligne : le client tombe désormais sur un objet déjà absent. Ce n'est plus dangereux, c'est devenu inutile. ⚠️ <strong>Ne pas le retirer avant d'avoir renseigné <code>Firebase:StorageBucket</code> en prod</strong> (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.</p>
+          <span class="src">v1-plan.md lot C — C6 · STATUS.md §1sexies</span>
         </article>
 
       </div>
@@ -522,273 +522,273 @@
 
                 <article class="card" data-area="visitapp">
           <div class="card-meta"><span class="tag">visitapp</span></div>
-          <h3>Échecs de téléchargement silencieux</h3>
-          <p>Un fichier raté fait un <code>print</code> et passe. La visite est annoncée téléchargée alors qu'elle est incomplète.</p>
+          <h3>Échecs de téléchargement silencieux</h3>
+          <p>Un fichier raté fait un <code>print</code> et passe. La visite est annoncée téléchargée alors qu'elle est incomplète.</p>
           <span class="src">v2/offline-visit-plan.md</span>
         </article>
 
         <article class="card" data-area="visitapp">
           <div class="card-meta"><span class="tag">mobile</span><span class="tag">M3</span></div>
-          <h3>meterZoneGPS ignoré</h3>
-          <p>Le rayon de déclenchement configuré par section n'a aucun effet — une constante en dur à 100 m le remplace.</p>
-          <p>✅ <strong>Périmètre tranché le 12/08 : <code>mymuseum-visitapp</code> + <code>visitapp-web</code>.</strong> <code>tablet-app</code> est exclu — SectionParcours est hors périmètre kiosk (tranché en K3), le code n'y serait jamais exécuté.</p>
-          <p>⚠️ <strong>Confirmé le 12/08 : la colonne est correctement mappée côté serveur</strong> (les 13 sous-types dans <code>SectionFactory</code>), et <strong>aucun</strong> code des trois apps ne la lit — seulement les swagger et les modèles générés. Le trou est entièrement côté visiteur.</p>
-          <p>⚠️ <strong>Trouvé le 12/08 : il y a DEUX implémentations de géodéclenchement qui s'ignorent</strong>, et ça change le chantier.</p>
-          <p><strong>1. La vivante</strong> — <code>configuration_page.dart:43</code> : <code>int meterToBeacon = 100; // 15 meters</code>. <strong>La valeur dit 100, le commentaire dit 15.</strong> C'est la constante que M3 désigne.<br><strong>2. La morte</strong> — <code>GeoBeaconTriggerService</code> : 20 m en dur pour le GPS, 3 m pour les beacons, jamais démarrée (aucun appel à <code>start()</code>).</p>
-          <p><strong>Aucune des deux ne lit <code>meterZoneGPS</code>.</strong> Corriger la première en laissant la seconde, c'est se préparer à re-trouver le même bug. ✅ <strong>Fusionné le 12/08 avec le branchement du mode proactif</strong> (carte « Déclenchement proactif ») : décider laquelle devient la bonne, puis lui faire lire le rayon configuré par section. Un seul chantier, même raisonnement que L5.</p>
-          <span class="src">v1-plan.md lot F — proactif &amp; M3 · parity-manager-visitapp.md §2</span>
+          <h3>meterZoneGPS ignoré</h3>
+          <p>Le rayon de déclenchement configuré par section n'a aucun effet — une constante en dur à 100 m le remplace.</p>
+          <p>✅ <strong>Périmètre tranché le 12/08 : <code>mymuseum-visitapp</code> + <code>visitapp-web</code>.</strong> <code>tablet-app</code> est exclu — SectionParcours est hors périmètre kiosk (tranché en K3), le code n'y serait jamais exécuté.</p>
+          <p>⚠️ <strong>Confirmé le 12/08 : la colonne est correctement mappée côté serveur</strong> (les 13 sous-types dans <code>SectionFactory</code>), et <strong>aucun</strong> code des trois apps ne la lit — seulement les swagger et les modèles générés. Le trou est entièrement côté visiteur.</p>
+          <p>⚠️ <strong>Trouvé le 12/08 : il y a DEUX implémentations de géodéclenchement qui s'ignorent</strong>, et ça change le chantier.</p>
+          <p><strong>1. La vivante</strong> — <code>configuration_page.dart:43</code> : <code>int meterToBeacon = 100; // 15 meters</code>. <strong>La valeur dit 100, le commentaire dit 15.</strong> C'est la constante que M3 désigne.<br><strong>2. La morte</strong> — <code>GeoBeaconTriggerService</code> : 20 m en dur pour le GPS, 3 m pour les beacons, jamais démarrée (aucun appel à <code>start()</code>).</p>
+          <p><strong>Aucune des deux ne lit <code>meterZoneGPS</code>.</strong> Corriger la première en laissant la seconde, c'est se préparer à re-trouver le même bug. ✅ <strong>Fusionné le 12/08 avec le branchement du mode proactif</strong> (carte « Déclenchement proactif ») : décider laquelle devient la bonne, puis lui faire lire le rayon configuré par section. Un seul chantier, même raisonnement que L5.</p>
+          <span class="src">v1-plan.md lot F — proactif &amp; M3 · parity-manager-visitapp.md §2</span>
         </article>
 
               </div>
     </section>
 
-    <!-- À TESTER -->
+    <!-- À TESTER -->
     <section class="col" style="--stripe: var(--brand)">
-      <div class="col-head"><h2>À tester</h2><span class="count">6</span></div>
+      <div class="col-head"><h2>À tester</h2><span class="count">6</span></div>
       <div class="stack">
 
         <article class="card" data-area="manager">
-          <div class="card-meta"><span class="tag">manager-app</span><span class="flag f-warn">Jamais lancé</span></div>
-          <h3>Écran Statistiques refondu + export PDF</h3>
-          <p>É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 — <strong>s'il manque, c'est le CORS du bucket Firebase</strong>, le rapport doit se générer quand même. Et après <code>database update</code> : que les <em>instances</em> soient bien passées à 395 jours (pas seulement les plans), et que le job <code>visit-events-purge</code> déclenché à la main <strong>ne supprime rien</strong>.</p>
-          <span class="src">test-plan.md §8bis, §8ter, §8quater</span>
+          <div class="card-meta"><span class="tag">manager-app</span><span class="flag f-warn">Jamais lancé</span></div>
+          <h3>Écran Statistiques refondu + export PDF</h3>
+          <p>É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 — <strong>s'il manque, c'est le CORS du bucket Firebase</strong>, le rapport doit se générer quand même. Et après <code>database update</code> : que les <em>instances</em> soient bien passées à 395 jours (pas seulement les plans), et que le job <code>visit-events-purge</code> déclenché à la main <strong>ne supprime rien</strong>.</p>
+          <span class="src">test-plan.md §8bis, §8ter, §8quater</span>
         </article>
 
         <article class="card" data-area="visitapp backend">
-          <div class="card-meta"><span class="tag">§21</span><span class="flag f-critical">En premier</span></div>
+          <div class="card-meta"><span class="tag">§21</span><span class="flag f-critical">En premier</span></div>
           <h3>Visite hors ligne sur device</h3>
-          <p>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.</p>
-          <p>✅ <strong>Débloqué par K5</strong> (12/08, les trois flavors construisent). Valide désormais aussi <strong>D2, D3 et D4, livrés le 12/08</strong> — <code>audio/mpeg</code> reconnu, purge des fichiers obsolètes réactivée, filtre de fraîcheur sur <code>dateUpdate</code>.</p>
-          <p>⚠️ <strong>Deux cas à ajouter au §21 avant de le jouer</strong>, ouverts par D2 : (1) <strong>montée v3 → v4 de la base locale</strong> sur un device portant déjà une visite — elle ne doit <strong>rien</strong> re-télécharger ; (2) <strong>device portant des <code>&lt;id&gt;.unknown</code></strong> — le MP3 doit être re-téléchargé et devenir lisible. Le second est le seul qui prouve que D3 répare le <strong>parc existant</strong>, pas seulement les installations neuves.</p>
-          <span class="src">test-plan.md §21</span>
+          <p>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.</p>
+          <p>✅ <strong>Débloqué par K5</strong> (12/08, les trois flavors construisent). Valide désormais aussi <strong>D2, D3 et D4, livrés le 12/08</strong> — <code>audio/mpeg</code> reconnu, purge des fichiers obsolètes réactivée, filtre de fraîcheur sur <code>dateUpdate</code>.</p>
+          <p>⚠️ <strong>Deux cas à ajouter au §21 avant de le jouer</strong>, ouverts par D2 : (1) <strong>montée v3 → v4 de la base locale</strong> sur un device portant déjà une visite — elle ne doit <strong>rien</strong> re-télécharger ; (2) <strong>device portant des <code>&lt;id&gt;.unknown</code></strong> — le MP3 doit être re-téléchargé et devenir lisible. Le second est le seul qui prouve que D3 répare le <strong>parc existant</strong>, pas seulement les installations neuves.</p>
+          <span class="src">test-plan.md §21</span>
         </article>
 
         <article class="card" data-area="backend manager doc">
-          <div class="card-meta"><span class="tag">§18</span><span class="flag f-warn">Jamais exécuté</span></div>
+          <div class="card-meta"><span class="tag">§18</span><span class="flag f-warn">Jamais exécuté</span></div>
           <h3>Onboarding self-service complet</h3>
-          <p>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 <code>onboarding@</code> et le <code>whsec_</code> Stripe CLI.</p>
-          <span class="src">test-plan.md §18</span>
+          <p>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 <code>onboarding@</code> et le <code>whsec_</code> Stripe CLI.</p>
+          <span class="src">test-plan.md §18</span>
         </article>
 
         <article class="card" data-area="manager visitapp">
-          <div class="card-meta"><span class="tag">§19.13</span></div>
-          <h3>Chasse au trésor / carnaval — cas E</h3>
-          <p>Le scénario le plus complet : SectionMap + SectionParcours + géodéclenchement + questions + mode jeu, d'un seul tenant.</p>
-          <span class="src">test-plan.md §19.13</span>
+          <div class="card-meta"><span class="tag">§19.13</span></div>
+          <h3>Chasse au trésor / carnaval — cas E</h3>
+          <p>Le scénario le plus complet : SectionMap + SectionParcours + géodéclenchement + questions + mode jeu, d'un seul tenant.</p>
+          <span class="src">test-plan.md §19.13</span>
         </article>
 
         <article class="card" data-area="manager visitapp">
-          <div class="card-meta"><span class="tag">§19</span></div>
-          <h3>Parité par type de section</h3>
-          <p>« Tout ce que je configure est-il visible ? » — le chapitre qui valide les 13 types sur les deux apps visiteur.</p>
-          <span class="src">test-plan.md §19</span>
+          <div class="card-meta"><span class="tag">§19</span></div>
+          <h3>Parité par type de section</h3>
+          <p>« Tout ce que je configure est-il visible ? » — le chapitre qui valide les 13 types sur les deux apps visiteur.</p>
+          <span class="src">test-plan.md §19</span>
         </article>
 
         <article class="card" data-area="infra">
-          <div class="card-meta"><span class="tag">§0</span></div>
-          <h3>Porte d'entrée build</h3>
-          <p>5 commandes, bloquant absolu. <code>flutter analyze</code> et <code>next dev</code> ne prouvent rien — seuls les vrais builds disent la vérité.</p>
-          <span class="src">test-plan.md §0</span>
+          <div class="card-meta"><span class="tag">§0</span></div>
+          <h3>Porte d'entrée build</h3>
+          <p>5 commandes, bloquant absolu. <code>flutter analyze</code> et <code>next dev</code> ne prouvent rien — seuls les vrais builds disent la vérité.</p>
+          <span class="src">test-plan.md §0</span>
         </article>
 
       </div>
     </section>
 
-    <!-- PLANIFIÉ -->
+    <!-- PLANIFIÉ -->
     <section class="col" style="--stripe: var(--ink-3)">
-      <div class="col-head"><h2>Planifié</h2><span class="count">23</span></div>
+      <div class="col-head"><h2>Planifié</h2><span class="count">23</span></div>
 
 
       <div class="stack">
 
         <article class="card" data-area="commercial" data-horizon="v1">
-          <div class="card-meta"><span class="tag">après prod</span><span class="tag">relationnel</span></div>
-          <h3>Reprendre contact avec Louise Smets — Musée d'Ixelles</h3>
-          <p><strong>Une fois la prod stabilisée</strong>, pas avant : on n'ouvre pas une conversation en montrant un produit en cours de bascule. Premier temps d'<strong>écoute</strong> — 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.</p>
-          <span class="src">STATUS.md §1quinquies — Après la bascule</span>
+          <div class="card-meta"><span class="tag">après prod</span><span class="tag">relationnel</span></div>
+          <h3>Reprendre contact avec Louise Smets — Musée d'Ixelles</h3>
+          <p><strong>Une fois la prod stabilisée</strong>, pas avant : on n'ouvre pas une conversation en montrant un produit en cours de bascule. Premier temps d'<strong>écoute</strong> — 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.</p>
+          <span class="src">STATUS.md §1quinquies — Après la bascule</span>
         </article>
 
         <article class="card" data-area="backend" data-horizon="v2">
-          <div class="card-meta"><span class="tag">priorité 1</span><span class="flag f-warn">V2</span></div>
-          <h3>Rapport de stats — envoi mensuel automatique</h3>
-          <p><strong>Le rapport à la demande est livré</strong> (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<sup>er</sup> à 6 h. QuestPDF + Hangfire, config destinataires/fréquence, et une méthode d'envoi <em>avec pièce jointe</em> — les 10 méthodes d'<code>IEmailService</code> sont des templates figés sans attachement. ⚠️ QuestPDF exige <code>libfontconfig1</code> + une police, absents du Dockerfile : ça marche en local sous Windows et casse dans le conteneur.</p>
-          <span class="src">plan-import-ia-stats-subsides.md §1</span>
+          <div class="card-meta"><span class="tag">priorité 1</span><span class="flag f-warn">V2</span></div>
+          <h3>Rapport de stats — envoi mensuel automatique</h3>
+          <p><strong>Le rapport à la demande est livré</strong> (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<sup>er</sup> à 6 h. QuestPDF + Hangfire, config destinataires/fréquence, et une méthode d'envoi <em>avec pièce jointe</em> — les 10 méthodes d'<code>IEmailService</code> sont des templates figés sans attachement. ⚠️ QuestPDF exige <code>libfontconfig1</code> + une police, absents du Dockerfile : ça marche en local sous Windows et casse dans le conteneur.</p>
+          <span class="src">plan-import-ia-stats-subsides.md §1</span>
         </article>
 
         <article class="card" data-area="backend" data-horizon="v1">
-          <div class="card-meta"><span class="tag">manager-service</span><span class="flag f-warn">RGPD · lot J</span></div>
+          <div class="card-meta"><span class="tag">manager-service</span><span class="flag f-warn">RGPD · lot J</span></div>
           <h3><code>AuditLog</code> n'a aucune purge</h3>
-          <p><code>VisitEvent</code> purge à 13 mois, <code>VisitorQuestion</code> à 90 jours, <code>AuditLog</code> <strong>à jamais</strong>. <strong>C'est un sujet RGPD et rien d'autre</strong> : la table porte <code>UserId</code>, et les valeurs avant-après d'une modification de <code>User</code> contiennent e-mail, prénom et nom. <strong>Ce n'est pas un sujet de volume</strong> — l'inondation par <code>WeatherSyncService</code> est coupée depuis le 12/08, la table croît désormais au seul rythme des éditions humaines. <strong>Donc à traiter au lot J, pas au lot F.</strong> Recommandation : <strong>12 mois, uniforme</strong>, via un <code>AuditLogPurgeService</code> calqué sur <code>VisitEventPurgeService</code> — 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. ⚠️ <strong>Reprendre le même verrou</strong> : purge inerte tant qu'<code>Audit:RetentionDays</code> n'est pas défini, <strong>le pg_dump quotidien n'étant toujours pas en place</strong> — supprimer des lignes d'audit sans restauration fine est la pire combinaison. Écarté : garder les <code>Delete</code> plus longtemps que les <code>Create</code>/<code>Update</code>, ça double les règles pour un cas qu'une sauvegarde couvre déjà.</p>
-          <span class="src">v1-plan.md lot F · STATUS.md §1sexies</span>
+          <p><code>VisitEvent</code> purge à 13 mois, <code>VisitorQuestion</code> à 90 jours, <code>AuditLog</code> <strong>à jamais</strong>. <strong>C'est un sujet RGPD et rien d'autre</strong> : la table porte <code>UserId</code>, et les valeurs avant-après d'une modification de <code>User</code> contiennent e-mail, prénom et nom. <strong>Ce n'est pas un sujet de volume</strong> — l'inondation par <code>WeatherSyncService</code> est coupée depuis le 12/08, la table croît désormais au seul rythme des éditions humaines. <strong>Donc à traiter au lot J, pas au lot F.</strong> Recommandation : <strong>12 mois, uniforme</strong>, via un <code>AuditLogPurgeService</code> calqué sur <code>VisitEventPurgeService</code> — 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. ⚠️ <strong>Reprendre le même verrou</strong> : purge inerte tant qu'<code>Audit:RetentionDays</code> n'est pas défini, <strong>le pg_dump quotidien n'étant toujours pas en place</strong> — supprimer des lignes d'audit sans restauration fine est la pire combinaison. Écarté : garder les <code>Delete</code> plus longtemps que les <code>Create</code>/<code>Update</code>, ça double les règles pour un cas qu'une sauvegarde couvre déjà.</p>
+          <span class="src">v1-plan.md lot F · STATUS.md §1sexies</span>
         </article>
 
         <article class="card" data-area="backend">
-          <div class="card-meta"><span class="tag">priorité 2</span><span class="flag f-good">Exécuté 10/08 — 2150 morceaux</span></div>
-          <h3>RAG sur le contenu CMS — vector store, jobs, outil <code>SearchKnowledge</code></h3>
-          <p>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.</p>
-          <p><strong>Livré le 10/08</strong> : <code>IngestionService</code> (chargement des collections filles par sous-type, un jeu de morceaux par langue), serveur Hangfire dédié à 2 workers, garde <code>AiTokensPerMonth &gt; 0</code> — <code>plan-starter</code> est à 0 — et <code>SearchKnowledge</code> ajouté aux outils d'<code>AssistantService</code> plutôt qu'un <code>/ask</code> concurrent, avec sa règle dans les <strong>4</strong> prompts.</p>
-          <p><strong>Joué contre la vraie base et la vraie API le 10/08 : 52 sections → 2150 morceaux en 53 s.</strong> Deux défauts que seule l'exécution pouvait montrer, corrigés dans la foulée. <strong>1)</strong> Les gabarits de <code>LanguageInit</code> étaient indexés : les <em>cinq</em> premiers résultats d'une question en néerlandais étaient des <code>NL - Title NL - Description</code>, le bonus de langue suffisant à les faire passer devant du vrai contenu français — le cas même que le cross-lingue devait servir. <strong>2)</strong> Le même paragraphe occupait trois des cinq résultats, au même score : <code>DistinctBy(Text)</code> avant le <code>Take</code>. ⚠️ Le post-filtrage HNSW reste non éprouvé <strong>à plusieurs instances</strong> — il n'y en a qu'une en base locale, soit le cas où le problème ne se voit pas.</p>
-          <p>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 <code>gemini-embedding-001</code> et l'échec emportait les 50 morceaux du lot.</p>
-          <p><strong>Déclenchement unifié</strong> : l'<code>Enqueue</code> par contrôleur et un intercepteur EF ont coexisté une demi-journée. Retenu : <code>SectionIndexingInterceptor</code> seul — les 5 sous-contrôleurs totalisaient <strong>30 <code>SaveChanges</code> et 0 <code>Enqueue</code></strong>, donc ajouter 40 points d'intérêt à une carte ne réindexait rien.</p>
-          <span class="src">STATUS.md §1quater — lot 3 · v2/rag-indexing-trigger-decision.md · v2/rag-pgvector-integration-plan.md §3, §4</span>
+          <div class="card-meta"><span class="tag">priorité 2</span><span class="flag f-good">Exécuté 10/08 — 2150 morceaux</span></div>
+          <h3>RAG sur le contenu CMS — vector store, jobs, outil <code>SearchKnowledge</code></h3>
+          <p>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.</p>
+          <p><strong>Livré le 10/08</strong> : <code>IngestionService</code> (chargement des collections filles par sous-type, un jeu de morceaux par langue), serveur Hangfire dédié à 2 workers, garde <code>AiTokensPerMonth &gt; 0</code> — <code>plan-starter</code> est à 0 — et <code>SearchKnowledge</code> ajouté aux outils d'<code>AssistantService</code> plutôt qu'un <code>/ask</code> concurrent, avec sa règle dans les <strong>4</strong> prompts.</p>
+          <p><strong>Joué contre la vraie base et la vraie API le 10/08 : 52 sections → 2150 morceaux en 53 s.</strong> Deux défauts que seule l'exécution pouvait montrer, corrigés dans la foulée. <strong>1)</strong> Les gabarits de <code>LanguageInit</code> étaient indexés : les <em>cinq</em> premiers résultats d'une question en néerlandais étaient des <code>NL - Title NL - Description</code>, le bonus de langue suffisant à les faire passer devant du vrai contenu français — le cas même que le cross-lingue devait servir. <strong>2)</strong> Le même paragraphe occupait trois des cinq résultats, au même score : <code>DistinctBy(Text)</code> avant le <code>Take</code>. ⚠️ Le post-filtrage HNSW reste non éprouvé <strong>à plusieurs instances</strong> — il n'y en a qu'une en base locale, soit le cas où le problème ne se voit pas.</p>
+          <p>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 <code>gemini-embedding-001</code> et l'échec emportait les 50 morceaux du lot.</p>
+          <p><strong>Déclenchement unifié</strong> : l'<code>Enqueue</code> par contrôleur et un intercepteur EF ont coexisté une demi-journée. Retenu : <code>SectionIndexingInterceptor</code> seul — les 5 sous-contrôleurs totalisaient <strong>30 <code>SaveChanges</code> et 0 <code>Enqueue</code></strong>, donc ajouter 40 points d'intérêt à une carte ne réindexait rien.</p>
+          <span class="src">STATUS.md §1quater — lot 3 · v2/rag-indexing-trigger-decision.md · v2/rag-pgvector-integration-plan.md §3, §4</span>
         </article>
 
         <article class="card" data-area="manager backend" data-horizon="v1">
-          <div class="card-meta"><span class="tag">manager-app</span><span class="flag f-warn">Front fait · backend à faire</span></div>
-          <h3>RGPD &amp; conformité — lot J, dernier avant la bascule</h3>
-          <p><strong>Reporté en fin de backlog le 11/08.</strong> Tenable <em>parce que</em> la porte « rien en prod avant la fin du backlog » tient : d'ici là la journalisation ne tourne que sur des bases de développement, aucun visiteur réel n'est concerné. Si un déploiement anticipé était décidé, ce lot redeviendrait bloquant.</p>
-          <p><strong>Déjà fait le 11/08</strong> : CGU §8 réécrites (elles décrivaient un service qui ne collectait que des statistiques anonymes, citaient des durées de plans abandonnés, et ne mentionnaient <em>aucun sous-traitant</em> alors que la question du visiteur part chez Google), texte d'information visiteurs en FR/NL/EN, et purge à 90 jours active sans condition de configuration — une durée écrite dans un contrat n'est pas un réglage.</p>
-          <p><strong>Reste</strong> : la <strong>table d'agrégats de thèmes</strong> (les CGU promettent que les regroupements survivent à la purge, or <code>ThemeId</code> est une colonne de la ligne supprimée — au 91<sup>e</sup> jour le client perdrait tout), le job de regroupement, un <strong>interrupteur de collecte par instance</strong> (⚠️ le client est responsable de traitement mais ne peut pas refuser la collecte), la mention à afficher côté visiteur, la <strong>relecture juridique du §8</strong> et la vérification des conditions réelles de Google.</p>
-          <p>✅ <strong>Périmètre tranché le 12/08 : job de regroupement <em>et</em> table d'agrégats, les deux.</strong> Donc le §8.4 des CGU n'est <strong>pas</strong> à amender — c'était l'alternative. La table ne porte que des compteurs <code>(instance, mois, thème, n)</code>, aucune donnée personnelle : elle survit légitimement à la purge. ⚠️ <strong>L'échéance n'est pas la bascule mais la première question d'un visiteur réel</strong> — rien n'est collecté aujourd'hui, le délai de 90 jours n'a pas commencé à courir. C'est le plus gros poste du lot, ~3-4 jours.</p>
-          <span class="src">v1-plan.md — lot J · cgu-myinfomate.md §8 · mention-information-visiteurs.md</span>
+          <div class="card-meta"><span class="tag">manager-app</span><span class="flag f-warn">Front fait · backend à faire</span></div>
+          <h3>RGPD &amp; conformité — lot J, dernier avant la bascule</h3>
+          <p><strong>Reporté en fin de backlog le 11/08.</strong> Tenable <em>parce que</em> la porte « rien en prod avant la fin du backlog » tient : d'ici là la journalisation ne tourne que sur des bases de développement, aucun visiteur réel n'est concerné. Si un déploiement anticipé était décidé, ce lot redeviendrait bloquant.</p>
+          <p><strong>Déjà fait le 11/08</strong> : CGU §8 réécrites (elles décrivaient un service qui ne collectait que des statistiques anonymes, citaient des durées de plans abandonnés, et ne mentionnaient <em>aucun sous-traitant</em> alors que la question du visiteur part chez Google), texte d'information visiteurs en FR/NL/EN, et purge à 90 jours active sans condition de configuration — une durée écrite dans un contrat n'est pas un réglage.</p>
+          <p><strong>Reste</strong> : la <strong>table d'agrégats de thèmes</strong> (les CGU promettent que les regroupements survivent à la purge, or <code>ThemeId</code> est une colonne de la ligne supprimée — au 91<sup>e</sup> jour le client perdrait tout), le job de regroupement, un <strong>interrupteur de collecte par instance</strong> (⚠️ le client est responsable de traitement mais ne peut pas refuser la collecte), la mention à afficher côté visiteur, la <strong>relecture juridique du §8</strong> et la vérification des conditions réelles de Google.</p>
+          <p>✅ <strong>Périmètre tranché le 12/08 : job de regroupement <em>et</em> table d'agrégats, les deux.</strong> Donc le §8.4 des CGU n'est <strong>pas</strong> à amender — c'était l'alternative. La table ne porte que des compteurs <code>(instance, mois, thème, n)</code>, aucune donnée personnelle : elle survit légitimement à la purge. ⚠️ <strong>L'échéance n'est pas la bascule mais la première question d'un visiteur réel</strong> — rien n'est collecté aujourd'hui, le délai de 90 jours n'a pas commencé à courir. C'est le plus gros poste du lot, ~3-4 jours.</p>
+          <span class="src">v1-plan.md — lot J · cgu-myinfomate.md §8 · mention-information-visiteurs.md</span>
         </article>
 
         <article class="card" data-area="visitapp" data-horizon="v1">
-          <div class="card-meta"><span class="tag">visitapp</span><span class="flag f-critical">Périmètre V1 neuf — 12/08</span></div>
-          <h3>Déclenchement proactif pour tous, pas seulement les lunettes</h3>
-          <p><strong>Tranché le 12/08.</strong> Un téléphone qui parle à l'approche d'une œuvre, écouteurs aux oreilles, <strong>c'est l'audioguide de musée classique</strong> — vendable bien au-delà des Ray-Ban, et sur du matériel que le visiteur a déjà.</p>
-          <p>⚠️ <strong>Ce n'est pas « retirer une garde », c'est câbler une fonction morte.</strong> Mesuré le 12/08 : <code>GeoBeaconTriggerService.instance.start()</code> <strong>n'est appelé nulle part</strong>, <code>glassesEnabled</code> est déclaré <code>= false</code> et <strong>jamais assigné</strong>, <code>proactiveModeEnabled</code> non plus, et <code>geoPoints</code> porte le commentaire « à peupler depuis la configuration » — ce qui n'est fait nulle part. Quatre choses à brancher.</p>
-          <p><strong>Le service couvre GPS <em>et</em> beacons</strong> : entrée dans le rayon d'un <code>GeoTriggerPoint</code> (20 m par défaut) ou beacon BLE à moins de 3 m, avec 30 s de cooldown par point.</p>
-          <p><strong>À faire</strong> : la garde redevient <code>proactiveModeEnabled</code> seul — <strong>ce que la doc de la classe décrivait déjà</strong>, le <code>&amp;&amp; glassesEnabled</code> n'y a jamais figuré (sixième « le commentaire dit autre chose que le code » du projet) ; un appel à <code>start()</code> ; <code>geoPoints</code> peuplé depuis la configuration ; un réglage visiteur ; et <code>VoiceSource</code> qui devient <strong>obligatoire</strong> — un prompt automatique atterrit dans <code>VisitorQuestion</code> comme s'il venait du visiteur.</p>
-          <p>✅ <strong>Écouteurs : ne pas les détecter.</strong> Le mode est opt-in, le visiteur qui l'active a choisi d'être parlé — détecter la sortie audio ajoute une dépendance pour arbitrer ce qu'il a déjà tranché. À revoir si le test dit le contraire.</p>
-          <p>⚠️ <strong>Fusionne avec le bug M3</strong> (carte « meterZoneGPS ignoré ») : deux implémentations de géodéclenchement s'ignorent, aucune ne lit le rayon configuré. Un seul chantier. <strong>~2 à 3 jours, M3 compris.</strong> Nouveau périmètre V1 assumé, à arbitrer contre la date de bascule au même titre que K9.</p>
-          <span class="src">v1-plan.md lot F — proactif &amp; M3</span>
+          <div class="card-meta"><span class="tag">visitapp</span><span class="flag f-critical">Périmètre V1 neuf — 12/08</span></div>
+          <h3>Déclenchement proactif pour tous, pas seulement les lunettes</h3>
+          <p><strong>Tranché le 12/08.</strong> Un téléphone qui parle à l'approche d'une œuvre, écouteurs aux oreilles, <strong>c'est l'audioguide de musée classique</strong> — vendable bien au-delà des Ray-Ban, et sur du matériel que le visiteur a déjà.</p>
+          <p>⚠️ <strong>Ce n'est pas « retirer une garde », c'est câbler une fonction morte.</strong> Mesuré le 12/08 : <code>GeoBeaconTriggerService.instance.start()</code> <strong>n'est appelé nulle part</strong>, <code>glassesEnabled</code> est déclaré <code>= false</code> et <strong>jamais assigné</strong>, <code>proactiveModeEnabled</code> non plus, et <code>geoPoints</code> porte le commentaire « à peupler depuis la configuration » — ce qui n'est fait nulle part. Quatre choses à brancher.</p>
+          <p><strong>Le service couvre GPS <em>et</em> beacons</strong> : entrée dans le rayon d'un <code>GeoTriggerPoint</code> (20 m par défaut) ou beacon BLE à moins de 3 m, avec 30 s de cooldown par point.</p>
+          <p><strong>À faire</strong> : la garde redevient <code>proactiveModeEnabled</code> seul — <strong>ce que la doc de la classe décrivait déjà</strong>, le <code>&amp;&amp; glassesEnabled</code> n'y a jamais figuré (sixième « le commentaire dit autre chose que le code » du projet) ; un appel à <code>start()</code> ; <code>geoPoints</code> peuplé depuis la configuration ; un réglage visiteur ; et <code>VoiceSource</code> qui devient <strong>obligatoire</strong> — un prompt automatique atterrit dans <code>VisitorQuestion</code> comme s'il venait du visiteur.</p>
+          <p>✅ <strong>Écouteurs : ne pas les détecter.</strong> Le mode est opt-in, le visiteur qui l'active a choisi d'être parlé — détecter la sortie audio ajoute une dépendance pour arbitrer ce qu'il a déjà tranché. À revoir si le test dit le contraire.</p>
+          <p>⚠️ <strong>Fusionne avec le bug M3</strong> (carte « meterZoneGPS ignoré ») : deux implémentations de géodéclenchement s'ignorent, aucune ne lit le rayon configuré. Un seul chantier. <strong>~2 à 3 jours, M3 compris.</strong> Nouveau périmètre V1 assumé, à arbitrer contre la date de bascule au même titre que K9.</p>
+          <span class="src">v1-plan.md lot F — proactif &amp; M3</span>
         </article>
 
         <article class="card" data-area="visitapp" data-horizon="v1">
           <div class="card-meta"><span class="tag">visitapp</span><span class="tag">lunettes</span><span class="flag f-warn">Nouveau 12/08</span></div>
           <h3>Miroir de la conversation vocale dans le chat</h3>
-          <p><strong>Tranché le 12/08</strong> : ouvrir l'assistant pendant que les lunettes tournent doit montrer <strong>la même conversation</strong>, transcrite au fil de l'eau. Une conversation, deux surfaces.</p>
-          <p>⚠️ <strong>Le coût n'est pas l'affichage, c'est l'unification des historiques.</strong> <code>MyInfoMateLlmClient</code> construit <strong>son propre</strong> <code>AssistantService</code> (<code>maxHistory: 6</code>), distinct de celui du chat écrit : poser une question aux lunettes puis ouvrir le chat donne aujourd'hui un interlocuteur qui ne sait rien de ce qu'on vient de demander. La transcription, elle, est déjà là — <code>VoiceOrchestrator</code> expose <code>lastTranscription</code> et <code>lastTtsText</code>, personne ne les affiche.</p>
-          <p>✅ <strong>Bénéfice de bord</strong> : <code>VisitorQuestion.ConversationId</code> est un GUID de session, « seul lien entre deux tours ». Deux historiques = deux conversations en base pour un visiteur qui a juste changé de surface. <strong>Unifier répare aussi les agrégats du Guide IA</strong>, donc ce que le job de thèmes du lot J regroupera. ⛔ Écarté : l'affichage passif dans <code>VoiceModeSheet</code> (2-3 h) — ça montrait que ça marche sans réparer la coupure. ~1 à 2 jours.</p>
-          <p>⚠️ <strong>Ne rien redessiner, l'UI existe.</strong> <code>GlassesStatusWidget</code> est monté en haut à droite de l'accueil (<code>home_3.0.dart:465</code>) : état par couleur, pastille de mode actif, tap → <code>VoiceModeSheet</code> (connexion, choix de mode, désactivation). <code>GlassesDebugPanel</code> existe et <strong>se garde</strong> — c'est l'outil de test. Seul écart avec « tout le temps présente », et il est volontaire : l'icône se cache si <code>applicationInstanceDTO?.isAssistant != true</code> (<code>GlassesStatusWidget.dart:32</code>) — invisible chez MDLF et le Fort, visible sur l'instance MyInfoMate. <strong>À savoir avant de tester chez un client et de croire à un bug.</strong></p>
-          <span class="src">v1-plan.md lot F — miroir vocal</span>
+          <p><strong>Tranché le 12/08</strong> : ouvrir l'assistant pendant que les lunettes tournent doit montrer <strong>la même conversation</strong>, transcrite au fil de l'eau. Une conversation, deux surfaces.</p>
+          <p>⚠️ <strong>Le coût n'est pas l'affichage, c'est l'unification des historiques.</strong> <code>MyInfoMateLlmClient</code> construit <strong>son propre</strong> <code>AssistantService</code> (<code>maxHistory: 6</code>), distinct de celui du chat écrit : poser une question aux lunettes puis ouvrir le chat donne aujourd'hui un interlocuteur qui ne sait rien de ce qu'on vient de demander. La transcription, elle, est déjà là — <code>VoiceOrchestrator</code> expose <code>lastTranscription</code> et <code>lastTtsText</code>, personne ne les affiche.</p>
+          <p>✅ <strong>Bénéfice de bord</strong> : <code>VisitorQuestion.ConversationId</code> est un GUID de session, « seul lien entre deux tours ». Deux historiques = deux conversations en base pour un visiteur qui a juste changé de surface. <strong>Unifier répare aussi les agrégats du Guide IA</strong>, donc ce que le job de thèmes du lot J regroupera. ⛔ Écarté : l'affichage passif dans <code>VoiceModeSheet</code> (2-3 h) — ça montrait que ça marche sans réparer la coupure. ~1 à 2 jours.</p>
+          <p>⚠️ <strong>Ne rien redessiner, l'UI existe.</strong> <code>GlassesStatusWidget</code> est monté en haut à droite de l'accueil (<code>home_3.0.dart:465</code>) : état par couleur, pastille de mode actif, tap → <code>VoiceModeSheet</code> (connexion, choix de mode, désactivation). <code>GlassesDebugPanel</code> existe et <strong>se garde</strong> — c'est l'outil de test. Seul écart avec « tout le temps présente », et il est volontaire : l'icône se cache si <code>applicationInstanceDTO?.isAssistant != true</code> (<code>GlassesStatusWidget.dart:32</code>) — invisible chez MDLF et le Fort, visible sur l'instance MyInfoMate. <strong>À savoir avant de tester chez un client et de croire à un bug.</strong></p>
+          <span class="src">v1-plan.md lot F — miroir vocal</span>
         </article>
 
         <article class="card" data-area="backend manager" data-horizon="v1">
-          <div class="card-meta"><span class="tag">manager-service</span><span class="tag">manager-app</span><span class="flag f-warn">Confirmé V1 le 12/08</span></div>
-          <h3>Stripe Customer Portal — changer sa carte</h3>
-          <p><strong>État réel, mesuré le 12/08 — moins grave que le plan ne le disait, mais bien cassé.</strong> L'e-mail d'échec de paiement pointe vers <code>{managerAppUrl}/billing</code> (<code>StripeWebhookController:124</code>), donc vers un écran à toi, pas vers une URL Stripe fantôme. Et cet écran <strong>existe</strong> (<code>Screens/Billing/subscription_screen.dart</code>).</p>
-          <p>⚠️ <strong>Mais il ne sait faire qu'une chose : lancer un Checkout de souscription.</strong> Scénario réel : la carte d'un client expire, il reçoit l'e-mail, clique, et arrive sur un écran qui lui propose de souscrire l'abonnement qu'il a déjà. Il t'appelle. À 4 clients c'est gérable, en self-service non.</p>
-          <p><code>StripeService</code> sait créer un client et une Checkout Session, mais pas de session de portail. Endpoint <code>Stripe.BillingPortal</code> + bouton dans l'écran existant — Stripe héberge la page, il n'y a <strong>aucune UI de paiement à écrire</strong>. ~1 jour.</p>
-          <span class="src">v1-plan.md lot F · STATUS.md §1 « À faire »</span>
+          <div class="card-meta"><span class="tag">manager-service</span><span class="tag">manager-app</span><span class="flag f-warn">Confirmé V1 le 12/08</span></div>
+          <h3>Stripe Customer Portal — changer sa carte</h3>
+          <p><strong>État réel, mesuré le 12/08 — moins grave que le plan ne le disait, mais bien cassé.</strong> L'e-mail d'échec de paiement pointe vers <code>{managerAppUrl}/billing</code> (<code>StripeWebhookController:124</code>), donc vers un écran à toi, pas vers une URL Stripe fantôme. Et cet écran <strong>existe</strong> (<code>Screens/Billing/subscription_screen.dart</code>).</p>
+          <p>⚠️ <strong>Mais il ne sait faire qu'une chose : lancer un Checkout de souscription.</strong> Scénario réel : la carte d'un client expire, il reçoit l'e-mail, clique, et arrive sur un écran qui lui propose de souscrire l'abonnement qu'il a déjà. Il t'appelle. À 4 clients c'est gérable, en self-service non.</p>
+          <p><code>StripeService</code> sait créer un client et une Checkout Session, mais pas de session de portail. Endpoint <code>Stripe.BillingPortal</code> + bouton dans l'écran existant — Stripe héberge la page, il n'y a <strong>aucune UI de paiement à écrire</strong>. ~1 jour.</p>
+          <span class="src">v1-plan.md lot F · STATUS.md §1 « À faire »</span>
         </article>
 
         <article class="card" data-area="manager" data-horizon="v1">
           <div class="card-meta"><span class="tag">manager-app</span><span class="flag f-warn">Jamais ouvert</span></div>
-          <h3>Écrans du lot design — vérification à l'œil</h3>
-          <p>Deux écrans neufs compilent (<code>flutter build web</code> ✅) mais <strong>n'ont jamais été affichés dans un navigateur</strong> — le défaut récurrent de ce tableau. Le <strong>Guide IA</strong> (coquille à onglets, aperçu de conversation, carte de connaissance) et l'<strong>éditeur de parcours</strong> refondu (rail d'étapes, panneau, questions dépliées, enregistrement à la saisie).</p>
-          <p>Exige un <code>manager-service</code> qui tourne et une session ouverte : <code>flutter run -d chrome</code>, puis comparaison côte à côte avec <code>claude design/guide-ia-screen.html</code> et <code>claude design/sectionparcours-refonte-flux.html</code>. Pour le parcours, rejouer aussi <code>test-plan.md §19.13 cas 0</code>.</p>
-          <span class="src">v1-plan.md — DB5</span>
+          <h3>Écrans du lot design — vérification à l'œil</h3>
+          <p>Deux écrans neufs compilent (<code>flutter build web</code> ✅) mais <strong>n'ont jamais été affichés dans un navigateur</strong> — le défaut récurrent de ce tableau. Le <strong>Guide IA</strong> (coquille à onglets, aperçu de conversation, carte de connaissance) et l'<strong>éditeur de parcours</strong> refondu (rail d'étapes, panneau, questions dépliées, enregistrement à la saisie).</p>
+          <p>Exige un <code>manager-service</code> qui tourne et une session ouverte : <code>flutter run -d chrome</code>, puis comparaison côte à côte avec <code>claude design/guide-ia-screen.html</code> et <code>claude design/sectionparcours-refonte-flux.html</code>. Pour le parcours, rejouer aussi <code>test-plan.md §19.13 cas 0</code>.</p>
+          <span class="src">v1-plan.md — DB5</span>
         </article>
 
         <article class="card" data-area="backend manager" data-horizon="v2">
-          <div class="card-meta"><span class="tag">priorité 2</span><span class="flag f-warn">V2</span></div>
+          <div class="card-meta"><span class="tag">priorité 2</span><span class="flag f-warn">V2</span></div>
           <h3>Ingestion documentaire + OCR</h3>
-          <p>PdfPig avec cascade OCR Gemini (~0,03 $ / 100 pages). Word, PowerPoint, images. Legacy <code>.doc</code>/<code>.ppt</code> refusés à l'upload.</p>
+          <p>PdfPig avec cascade OCR Gemini (~0,03 $ / 100 pages). Word, PowerPoint, images. Legacy <code>.doc</code>/<code>.ppt</code> refusés à l'upload.</p>
           <span class="src">v2/rag-pgvector-integration-plan.md</span>
         </article>
 
         <article class="card" data-area="backend" data-horizon="v2">
-          <div class="card-meta"><span class="tag">priorité 3</span><span class="flag f-warn">V2</span></div>
-          <h3>TTS pré-généré — audioguide multilingue</h3>
-          <p>Le produit que les musées achètent depuis toujours, à coût marginal quasi nul. Aucun concurrent de cette gamme ne le fait.</p>
+          <div class="card-meta"><span class="tag">priorité 3</span><span class="flag f-warn">V2</span></div>
+          <h3>TTS pré-généré — audioguide multilingue</h3>
+          <p>Le produit que les musées achètent depuis toujours, à coût marginal quasi nul. Aucun concurrent de cette gamme ne le fait.</p>
           <span class="src">v2/tts-pregenerated-plan.md</span>
         </article>
 
         <article class="card" data-area="backend visitapp" data-horizon="v2">
-          <div class="card-meta"><span class="tag">priorité 4</span><span class="flag f-warn">V2</span></div>
-          <h3>Génération de visites à la demande</h3>
-          <p>« Un parcours de 45 min pour familles ». Marche sur le smartphone du visiteur, aucun hardware. Vendable aux villes comme balade sonore IA.</p>
-          <span class="src">plan-import-ia-stats-subsides.md §3</span>
+          <div class="card-meta"><span class="tag">priorité 4</span><span class="flag f-warn">V2</span></div>
+          <h3>Génération de visites à la demande</h3>
+          <p>« Un parcours de 45 min pour familles ». Marche sur le smartphone du visiteur, aucun hardware. Vendable aux villes comme balade sonore IA.</p>
+          <span class="src">plan-import-ia-stats-subsides.md §3</span>
         </article>
 
         <article class="card" data-area="manager backend" data-horizon="v2">
           <div class="card-meta"><span class="tag">guide IA</span><span class="flag f-warn">V2</span></div>
-          <h3>Guides multiples &amp; guide thématique</h3>
-          <p>Plusieurs personas, assignables à une section ou une configuration. Le <em>modèle</em> 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.</p>
-          <span class="src">v2/tts-pregenerated-plan.md — PersonaConfig</span>
+          <h3>Guides multiples &amp; guide thématique</h3>
+          <p>Plusieurs personas, assignables à une section ou une configuration. Le <em>modèle</em> 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.</p>
+          <span class="src">v2/tts-pregenerated-plan.md — PersonaConfig</span>
         </article>
 
         <article class="card" data-area="visitapp infra" data-horizon="v1">
           <div class="card-meta"><span class="tag">visitapp-web</span><span class="flag f-critical">Bloque l'offre Essentiel</span></div>
-          <h3>Déployer le visiteur web — <code>app.myinfomate.be</code></h3>
-          <p>L'app <strong>existe</strong> : 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.</p>
-          <span class="src">architecture-web-saas.md — À faire</span>
+          <h3>Déployer le visiteur web — <code>app.myinfomate.be</code></h3>
+          <p>L'app <strong>existe</strong> : 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.</p>
+          <span class="src">architecture-web-saas.md — À faire</span>
         </article>
 
         <article class="card" data-area="visitapp manager" data-horizon="v2">
           <div class="card-meta"><span class="tag">tablet-app</span><span class="flag f-warn">V2</span></div>
           <h3>Kiosk web (Flutter Web)</h3>
-          <p>Extension web de <code>tablet-app</code> pour les clients ne voulant pas d'installation native. <strong>Reporté en V2 le 07/08</strong> : aucun client demandeur. ⚠️ <em>Le second motif est tombé le 12/08</em> — « la cible native ne compile même plus » n'est plus vrai, l'APK est produit depuis K1.</p>
-          <span class="src">architecture-web-saas.md — Kiosk web</span>
+          <p>Extension web de <code>tablet-app</code> pour les clients ne voulant pas d'installation native. <strong>Reporté en V2 le 07/08</strong> : aucun client demandeur. ⚠️ <em>Le second motif est tombé le 12/08</em> — « la cible native ne compile même plus » n'est plus vrai, l'APK est produit depuis K1.</p>
+          <span class="src">architecture-web-saas.md — Kiosk web</span>
         </article>
 
         <article class="card" data-area="visitapp" data-horizon="v1">
-          <div class="card-meta"><span class="tag">tablet-app</span><span class="flag f-warn">K9 · élargi 12/08</span></div>
-          <h3>Repasse visuelle de la borne — bento, types, orientation</h3>
-          <p><strong>Arbitré le 12/08 : paysage seul en V1, portrait en V2.</strong> Une seule maquette à dessiner, les six règles de la maquette K3/K7 s'étendant aux neuf autres types. ⚠️ <strong>Mais pas « paysage en dur »</strong> : 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 <strong>un point de décision unique et nommé</strong> 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 <code>if portrait</code> spéculatif.</p>
-          <p><strong>a) L'écran principal en bento — le seul code vraiment neuf, et moins cher que prévu.</strong> ⚠️ Vérifié le 12/08 : le kiosk n'a <em>pas</em> le bento — <code>main_view.dart:403-405</code> est un <code>GridView</code> à <code>crossAxisCount</code> fixe, toutes les tuiles de même taille, et <code>myinfomate_layout</code> n'est pas dans son <code>pubspec.yaml</code>. ✅ Mais la donnée est déjà là : les spans vivent sur <code>AppConfigurationLinkDTO.gridColSpan/gridRowSpan</code>, donc <strong>par canal</strong>, réglables dans manager-app — et <strong>K2 a déjà posé <code>TabletAppContext.currentAppConfigurationLink</code></strong>. Il reste à ajouter la dépendance locale et appeler <code>bentoLayout()</code> comme <code>home_3.0.dart:538</code>. <strong>Bénéfice de bord : l'aperçu de manager-app cesse de montrer au client un bento que sa borne ne rend pas.</strong></p>
-          <p><strong>b) Inventaire par type, tranché le 12/08.</strong> À revoir : <strong>Slider</strong> (le plus faible), <strong>Weather</strong> (retouche légère). À garder comme référence : <strong>Agenda</strong> — 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.</p>
-          <p><strong>c) Vimeo — un vrai trou, passé en V1.</strong> ⚠️ <code>SectionVideo.cs:21</code> annonce « URL YouTube/<strong>Vimeo</strong> » et le kiosk a bien son <code>video_viewer_youtube.dart</code> — mais <strong><code>vimeo</code> n'apparaît nulle part dans le Dart des deux apps visiteur</strong> : 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 <strong>en double</strong>, une copie par app : écrire une fois, copier sciemment. ⚠️ Comme YouTube, une URL reste <strong>indisponible hors ligne</strong> (<code>SectionVideo.cs:25-27</code>) — c'est voulu, ne pas le « corriger ».</p>
-          <p>⚠️ <strong>Non bloquant pour la bascule</strong>, 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é. <strong>Premier poste à sacrifier si la date serre.</strong> 4 à 6 jours, dont ~1 de maquette.</p>
-          <span class="src">v1-plan.md lot K — K9 · maquette kiosk-paysage-article-event.html</span>
+          <div class="card-meta"><span class="tag">tablet-app</span><span class="flag f-warn">K9 · élargi 12/08</span></div>
+          <h3>Repasse visuelle de la borne — bento, types, orientation</h3>
+          <p><strong>Arbitré le 12/08 : paysage seul en V1, portrait en V2.</strong> Une seule maquette à dessiner, les six règles de la maquette K3/K7 s'étendant aux neuf autres types. ⚠️ <strong>Mais pas « paysage en dur »</strong> : 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 <strong>un point de décision unique et nommé</strong> 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 <code>if portrait</code> spéculatif.</p>
+          <p><strong>a) L'écran principal en bento — le seul code vraiment neuf, et moins cher que prévu.</strong> ⚠️ Vérifié le 12/08 : le kiosk n'a <em>pas</em> le bento — <code>main_view.dart:403-405</code> est un <code>GridView</code> à <code>crossAxisCount</code> fixe, toutes les tuiles de même taille, et <code>myinfomate_layout</code> n'est pas dans son <code>pubspec.yaml</code>. ✅ Mais la donnée est déjà là : les spans vivent sur <code>AppConfigurationLinkDTO.gridColSpan/gridRowSpan</code>, donc <strong>par canal</strong>, réglables dans manager-app — et <strong>K2 a déjà posé <code>TabletAppContext.currentAppConfigurationLink</code></strong>. Il reste à ajouter la dépendance locale et appeler <code>bentoLayout()</code> comme <code>home_3.0.dart:538</code>. <strong>Bénéfice de bord : l'aperçu de manager-app cesse de montrer au client un bento que sa borne ne rend pas.</strong></p>
+          <p><strong>b) Inventaire par type, tranché le 12/08.</strong> À revoir : <strong>Slider</strong> (le plus faible), <strong>Weather</strong> (retouche légère). À garder comme référence : <strong>Agenda</strong> — 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.</p>
+          <p><strong>c) Vimeo — un vrai trou, passé en V1.</strong> ⚠️ <code>SectionVideo.cs:21</code> annonce « URL YouTube/<strong>Vimeo</strong> » et le kiosk a bien son <code>video_viewer_youtube.dart</code> — mais <strong><code>vimeo</code> n'apparaît nulle part dans le Dart des deux apps visiteur</strong> : 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 <strong>en double</strong>, une copie par app : écrire une fois, copier sciemment. ⚠️ Comme YouTube, une URL reste <strong>indisponible hors ligne</strong> (<code>SectionVideo.cs:25-27</code>) — c'est voulu, ne pas le « corriger ».</p>
+          <p>⚠️ <strong>Non bloquant pour la bascule</strong>, 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é. <strong>Premier poste à sacrifier si la date serre.</strong> 4 à 6 jours, dont ~1 de maquette.</p>
+          <span class="src">v1-plan.md lot K — K9 · maquette kiosk-paysage-article-event.html</span>
         </article>
 
         <article class="card" data-area="backend manager visitapp" data-horizon="v2">
           <div class="card-meta"><span class="tag">produit</span><span class="flag f-warn">V2</span></div>
-          <h3>SectionForm — formulaires personnalisés</h3>
-          <p>Nouveau type de section + table de réponses anonymes, constructeur de formulaire et page de résultats agrégés. <strong>Reporté en V2 le 07/08</strong> : purement additif, aucun impact sur le schéma existant — rien n'oblige à le faire passer avec la migration.</p>
-          <span class="src">todo-features.md — SectionForm</span>
+          <h3>SectionForm — formulaires personnalisés</h3>
+          <p>Nouveau type de section + table de réponses anonymes, constructeur de formulaire et page de résultats agrégés. <strong>Reporté en V2 le 07/08</strong> : purement additif, aucun impact sur le schéma existant — rien n'oblige à le faire passer avec la migration.</p>
+          <span class="src">todo-features.md — SectionForm</span>
         </article>
 
         <article class="card" data-area="backend manager visitapp" data-horizon="v2">
           <div class="card-meta"><span class="tag">produit</span><span class="flag f-warn">V2</span></div>
-          <h3>Ressource 360° — images panoramiques</h3>
-          <p>Une valeur d'enum (<code>Panorama360</code>) et un branchement dans l'affichage des ressources : s'affiche partout où une ressource s'affiche, sans toucher aux sections. <strong>Reporté en V2 le 07/08</strong> — le plus petit des trois, à reprendre en premier.</p>
-          <span class="src">todo-features.md — Ressource 360°</span>
+          <h3>Ressource 360° — images panoramiques</h3>
+          <p>Une valeur d'enum (<code>Panorama360</code>) et un branchement dans l'affichage des ressources : s'affiche partout où une ressource s'affiche, sans toucher aux sections. <strong>Reporté en V2 le 07/08</strong> — le plus petit des trois, à reprendre en premier.</p>
+          <span class="src">todo-features.md — Ressource 360°</span>
         </article>
 
         <article class="card" data-area="backend manager visitapp" data-horizon="v2">
           <div class="card-meta"><span class="tag">produit</span><span class="flag f-warn">V2</span></div>
           <h3>AR image tracking (Mind AR)</h3>
-          <p>Modèle <code>ArAnchor</code>, microservice Node de compilation des <code>.mind</code>, et remplacement du scanner visiteur par une WebView unifiée QR + image. Le plus lourd des trois, fort effet démo. <strong>Reporté en V2 le 07/08</strong> — ni la migration ni la mise en prod n'en dépendent.</p>
-          <span class="src">todo-features.md — AR</span>
+          <p>Modèle <code>ArAnchor</code>, microservice Node de compilation des <code>.mind</code>, et remplacement du scanner visiteur par une WebView unifiée QR + image. Le plus lourd des trois, fort effet démo. <strong>Reporté en V2 le 07/08</strong> — ni la migration ni la mise en prod n'en dépendent.</p>
+          <span class="src">todo-features.md — AR</span>
         </article>
 
         <article class="card" data-area="manager" data-horizon="v2">
-          <div class="card-meta"><span class="tag">produit</span><span class="flag f-warn">V2 · nouveau 12/08</span></div>
-          <h3>Écran SuperAdmin — add-on IA &amp; canaux d'une instance</h3>
-          <p>Donner l'IA à un client Pro se fait en SQL : <code>AiTokensPerMonth</code> n'est dans aucun DTO, <code>IsAssistant</code> est à poser deux fois (instance <em>et</em> <code>ApplicationInstance</code>), et le rattrapage d'indexation ne partant que depuis <code>UpdateInstance</code> en C#, il faut penser au bouton de relance. Exposer le quota dans <code>InstanceDTO</code> ramènerait ça à un formulaire. <strong>Reporté en V2 le 12/08</strong> : 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'<code>ApplicationInstance</code> (canaux activables) : <strong>c'est le même écran</strong>.</p>
-          <span class="src">STATUS.md §1sexies — add-on IA</span>
+          <div class="card-meta"><span class="tag">produit</span><span class="flag f-warn">V2 · nouveau 12/08</span></div>
+          <h3>Écran SuperAdmin — add-on IA &amp; canaux d'une instance</h3>
+          <p>Donner l'IA à un client Pro se fait en SQL : <code>AiTokensPerMonth</code> n'est dans aucun DTO, <code>IsAssistant</code> est à poser deux fois (instance <em>et</em> <code>ApplicationInstance</code>), et le rattrapage d'indexation ne partant que depuis <code>UpdateInstance</code> en C#, il faut penser au bouton de relance. Exposer le quota dans <code>InstanceDTO</code> ramènerait ça à un formulaire. <strong>Reporté en V2 le 12/08</strong> : 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'<code>ApplicationInstance</code> (canaux activables) : <strong>c'est le même écran</strong>.</p>
+          <span class="src">STATUS.md §1sexies — add-on IA</span>
         </article>
 
         <article class="card" data-area="visitapp" data-horizon="v2">
           <div class="card-meta"><span class="tag">polish</span><span class="flag f-warn">V2</span></div>
-          <h3>Talking head — avatar animé</h3>
-          <p>Trois frames par persona, lipsync sur les timestamps Google TTS. Quelques jours, effet démo. Bouche-trou entre deux chantiers.</p>
+          <h3>Talking head — avatar animé</h3>
+          <p>Trois frames par persona, lipsync sur les timestamps Google TTS. Quelques jours, effet démo. Bouche-trou entre deux chantiers.</p>
           <span class="src">v2/talking-head-plan.md</span>
         </article>
 
         <article class="card" data-area="doc" data-horizon="v2">
-          <div class="card-meta"><span class="tag">XR</span><span class="flag f-warn">V2 · subventionné</span></div>
-          <h3>Meta Quest — borne VR</h3>
-          <p>Pilote presse uniquement, quand le SDK sort de preview. Profil d'appel à projets, pas de ligne produit. ⚠️ <strong>Les Ray-Ban ne sont plus dans cette carte : elles passent en V1 le 12/08</strong> (carte suivante).</p>
-          <span class="src">roadmap.md — section XR</span>
+          <div class="card-meta"><span class="tag">XR</span><span class="flag f-warn">V2 · subventionné</span></div>
+          <h3>Meta Quest — borne VR</h3>
+          <p>Pilote presse uniquement, quand le SDK sort de preview. Profil d'appel à projets, pas de ligne produit. ⚠️ <strong>Les Ray-Ban ne sont plus dans cette carte : elles passent en V1 le 12/08</strong> (carte suivante).</p>
+          <span class="src">roadmap.md — section XR</span>
         </article>
 
         <article class="card" data-area="visitapp" data-horizon="v1">
           <div class="card-meta"><span class="tag">visitapp</span><span class="tag">lunettes</span><span class="flag f-warn">Nouveau 12/08</span></div>
-          <h3>Canal Vocal des stats — l'émission côté visiteur</h3>
-          <p><strong>Décidé le 12/08 : les Ray-Ban entrent en V1.</strong> Activation manuelle, instance par instance — <strong>au démarrage la seule instance concernée est MyInfoMate</strong>, celle de test, pour observer des stats vocales réelles avant de proposer quoi que ce soit. Aucune promesse externe ne dépend de cette date.</p>
-          <p>⚠️ <strong>L'écran est déjà fait, c'est l'émission qui manque</strong> — donc <strong>zéro ligne dans manager-app</strong> : <code>statistics_screen.dart</code> traite déjà <code>AppType.Voice</code> (libellé <code>:189</code>, part du vocal <code>:205-210</code>, KPI conditionnel <code>:533-541</code>, takeaway <code>:480</code>). Tout le travail est dans <code>mymuseum-visitapp</code>.</p>
-          <p><strong>Trois trous mesurés le 12/08.</strong> (1) <code>MyInfoMateLlmClient:40</code> envoie <code>AppType.Mobile</code> alors que son commentaire <code>:9</code> annonce Voice. (2) <code>StatisticsService</code> est construit en dur avec <code>appType: 'Mobile'</code> (<code>home_3.0.dart:715</code>), son champ étant documenté <code>// "Mobile" or "Tablet"</code>. (3) <strong>Le plus lourd : le flux lunettes n'émet aucun <code>VisitEvent</code></strong> — tous les <code>track()</code> sont dans des écrans d'interface ; <code>Services/Glasses/</code>, <code>wake_word_service</code> et <code>geo_beacon_trigger_service</code> n'en appellent aucun. Une visite vocale ne produit aujourd'hui ni session, ni section vue, ni durée.</p>
-          <p><strong>Périmètre tranché : session + contenu lu à voix haute.</strong> Une session <code>Voice</code> à l'activation, un <code>sectionView</code> quand le guide lit réellement une section (QR, beacon ou question). ⛔ <strong>Pas d'événement par question</strong> : elles sont déjà dans <code>VisitorQuestion</code> et remontent dans l'onglet Guide IA — les compter ici serait le même fait dans deux écrans. Ce périmètre fait marcher les KPI existants et l'export PDF <strong>sans retouche</strong>.</p>
-          <p>⛔ <strong>Le « fallback Voice → Mobile » n'existe pas</strong> — <code>guide-ia-screen-plan.md:226</code> l'affirmait et le commentaire d'<code>AiController:356</code> le répétait : les deux étaient faux et se confirmaient mutuellement. Le code fait un <code>FirstOrDefault</code> sur le canal exact puis <code>Forbid()</code> (<code>:357-361</code>) : envoyer <code>Voice</code> au chat sans <code>ApplicationInstance</code> de ce type rendrait <strong>403 à chaque question</strong>, extinction silencieuse des lunettes. ✅ <strong>Le chat reste donc en <code>Mobile</code></strong> : les lunettes tournent <em>dans</em> l'app mobile, qui a déjà chargé son canal — un canal Voice la ferait jongler entre deux, piège déjà rencontré en K2 avec <code>getConfigurations</code>.</p>
-          <p>⛔ <strong>CORRECTION du 12/08, quelques heures après : les <code>VisitEvent</code> ne portent pas <code>Voice</code> non plus. Le vocal n'est pas un canal, c'est un attribut.</strong> La décision du miroir vocal (carte suivante) rend explicite qu'un visiteur passe des lunettes à l'écran <strong>dans une même session</strong>. Or <code>StatisticsService</code> génère <strong>un seul <code>sessionId</code> par lancement</strong>, et <code>AppTypeDistribution</code> compte une entrée par session en tranchant l'ambiguïté sur <strong>l'événement le plus ancien</strong> (<code>StatsController:196-203</code>) : commencer au doigt puis mettre les lunettes ⇒ session comptée <code>Mobile</code>, vocal invisible ; l'inverse ⇒ session comptée <code>Voice</code>, navigation tactile comprise. Le KPI dirait « sessions <em>démarrées</em> en vocal », pas « part du vocal ».</p>
-          <p>✅ <strong>Retenu : marquer les événements consommés à la voix dans <code>VisitEvent.Metadata</code></strong> — colonne JSON <strong>déjà existante</strong>, déjà exploitée par <code>GetSummary</code> pour six agrégats : <strong>aucune migration, le gel du lot B tient</strong>. KPI juste : « part des sessions ayant utilisé le vocal ». <strong>C'est la conception déjà appliquée ailleurs</strong> — <code>VisitorQuestion</code> n'a pas de canal vocal, il a <code>IsVoice</code> <em>à côté</em> de son <code>AppType</code>. <code>AppType.Voice</code> retrouve son sens d'origine : un déploiement lunettes <strong>autonome</strong>, cas pour lequel l'enum a été créé et qui n'est pas celui-ci. ⚠️ <strong>Conséquence : « zéro ligne dans manager-app » devient faux</strong> — <code>_voiceSessions</code> lit <code>appTypeDistribution['Voice']</code> (<code>statistics_screen.dart:205-206</code>) et devra lire un nouvel agrégat. ~3 h.</p>
-          <p>⚠️ Deux réserves qui survivent : la branche <code>Meta-Rayban-Test</code> <strong>n'est toujours pas mergée</strong> (question déjà ouverte avant K6, et plus pressante puisqu'on ne publie plus un POC mais une fonction V1), et <strong>ne pas vendre l'add-on avant la bascule TTS ElevenLabs → Gemini</strong>.</p>
-          <span class="src">v1-plan.md lot F — canal Vocal · v2/guide-ia-screen-plan.md</span>
+          <h3>Canal Vocal des stats — l'émission côté visiteur</h3>
+          <p><strong>Décidé le 12/08 : les Ray-Ban entrent en V1.</strong> Activation manuelle, instance par instance — <strong>au démarrage la seule instance concernée est MyInfoMate</strong>, celle de test, pour observer des stats vocales réelles avant de proposer quoi que ce soit. Aucune promesse externe ne dépend de cette date.</p>
+          <p>⚠️ <strong>L'écran est déjà fait, c'est l'émission qui manque</strong> — donc <strong>zéro ligne dans manager-app</strong> : <code>statistics_screen.dart</code> traite déjà <code>AppType.Voice</code> (libellé <code>:189</code>, part du vocal <code>:205-210</code>, KPI conditionnel <code>:533-541</code>, takeaway <code>:480</code>). Tout le travail est dans <code>mymuseum-visitapp</code>.</p>
+          <p><strong>Trois trous mesurés le 12/08.</strong> (1) <code>MyInfoMateLlmClient:40</code> envoie <code>AppType.Mobile</code> alors que son commentaire <code>:9</code> annonce Voice. (2) <code>StatisticsService</code> est construit en dur avec <code>appType: 'Mobile'</code> (<code>home_3.0.dart:715</code>), son champ étant documenté <code>// "Mobile" or "Tablet"</code>. (3) <strong>Le plus lourd : le flux lunettes n'émet aucun <code>VisitEvent</code></strong> — tous les <code>track()</code> sont dans des écrans d'interface ; <code>Services/Glasses/</code>, <code>wake_word_service</code> et <code>geo_beacon_trigger_service</code> n'en appellent aucun. Une visite vocale ne produit aujourd'hui ni session, ni section vue, ni durée.</p>
+          <p><strong>Périmètre tranché : session + contenu lu à voix haute.</strong> Une session <code>Voice</code> à l'activation, un <code>sectionView</code> quand le guide lit réellement une section (QR, beacon ou question). ⛔ <strong>Pas d'événement par question</strong> : elles sont déjà dans <code>VisitorQuestion</code> et remontent dans l'onglet Guide IA — les compter ici serait le même fait dans deux écrans. Ce périmètre fait marcher les KPI existants et l'export PDF <strong>sans retouche</strong>.</p>
+          <p>⛔ <strong>Le « fallback Voice → Mobile » n'existe pas</strong> — <code>guide-ia-screen-plan.md:226</code> l'affirmait et le commentaire d'<code>AiController:356</code> le répétait : les deux étaient faux et se confirmaient mutuellement. Le code fait un <code>FirstOrDefault</code> sur le canal exact puis <code>Forbid()</code> (<code>:357-361</code>) : envoyer <code>Voice</code> au chat sans <code>ApplicationInstance</code> de ce type rendrait <strong>403 à chaque question</strong>, extinction silencieuse des lunettes. ✅ <strong>Le chat reste donc en <code>Mobile</code></strong> : les lunettes tournent <em>dans</em> l'app mobile, qui a déjà chargé son canal — un canal Voice la ferait jongler entre deux, piège déjà rencontré en K2 avec <code>getConfigurations</code>.</p>
+          <p>⛔ <strong>CORRECTION du 12/08, quelques heures après : les <code>VisitEvent</code> ne portent pas <code>Voice</code> non plus. Le vocal n'est pas un canal, c'est un attribut.</strong> La décision du miroir vocal (carte suivante) rend explicite qu'un visiteur passe des lunettes à l'écran <strong>dans une même session</strong>. Or <code>StatisticsService</code> génère <strong>un seul <code>sessionId</code> par lancement</strong>, et <code>AppTypeDistribution</code> compte une entrée par session en tranchant l'ambiguïté sur <strong>l'événement le plus ancien</strong> (<code>StatsController:196-203</code>) : commencer au doigt puis mettre les lunettes ⇒ session comptée <code>Mobile</code>, vocal invisible ; l'inverse ⇒ session comptée <code>Voice</code>, navigation tactile comprise. Le KPI dirait « sessions <em>démarrées</em> en vocal », pas « part du vocal ».</p>
+          <p>✅ <strong>Retenu : marquer les événements consommés à la voix dans <code>VisitEvent.Metadata</code></strong> — colonne JSON <strong>déjà existante</strong>, déjà exploitée par <code>GetSummary</code> pour six agrégats : <strong>aucune migration, le gel du lot B tient</strong>. KPI juste : « part des sessions ayant utilisé le vocal ». <strong>C'est la conception déjà appliquée ailleurs</strong> — <code>VisitorQuestion</code> n'a pas de canal vocal, il a <code>IsVoice</code> <em>à côté</em> de son <code>AppType</code>. <code>AppType.Voice</code> retrouve son sens d'origine : un déploiement lunettes <strong>autonome</strong>, cas pour lequel l'enum a été créé et qui n'est pas celui-ci. ⚠️ <strong>Conséquence : « zéro ligne dans manager-app » devient faux</strong> — <code>_voiceSessions</code> lit <code>appTypeDistribution['Voice']</code> (<code>statistics_screen.dart:205-206</code>) et devra lire un nouvel agrégat. ~3 h.</p>
+          <p>⚠️ Deux réserves qui survivent : la branche <code>Meta-Rayban-Test</code> <strong>n'est toujours pas mergée</strong> (question déjà ouverte avant K6, et plus pressante puisqu'on ne publie plus un POC mais une fonction V1), et <strong>ne pas vendre l'add-on avant la bascule TTS ElevenLabs → Gemini</strong>.</p>
+          <span class="src">v1-plan.md lot F — canal Vocal · v2/guide-ia-screen-plan.md</span>
         </article>
 
       </div>
@@ -800,69 +800,69 @@
       <div class="stack">
 
         <article class="card" data-area="backend infra">
-          <div class="card-meta"><span class="tag">étape 0</span><span class="flag f-critical">Sécurité — avant l'étape 16</span></div>
-          <h3>Rotation des secrets committés en clair</h3>
-          <p>Clé de signature JWT, clés API Gemini et OpenWeather, connection strings prod, mot de passe MQTT, token Telegram. Le dossier <code>RELEASE/</code> republie d'anciens secrets.</p>
-          <p><strong>Déplacée depuis « Urgent » le 11/08</strong>, à la demande : les 6 repos sont <strong>privés, sur un Gitea auto-hébergé</strong> — 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.</p>
-          <p>⚠️ <strong>Ce qui ne se négocie pas</strong> : 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 <code>app.myinfomate.be</code> déployé, <strong>ça veut dire avant la fin du lot de tests</strong>, 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.</p>
-          <span class="src">security/audit-securite-manager-service.md · v1-plan.md L1, I0</span>
+          <div class="card-meta"><span class="tag">étape 0</span><span class="flag f-critical">Sécurité — avant l'étape 16</span></div>
+          <h3>Rotation des secrets committés en clair</h3>
+          <p>Clé de signature JWT, clés API Gemini et OpenWeather, connection strings prod, mot de passe MQTT, token Telegram. Le dossier <code>RELEASE/</code> republie d'anciens secrets.</p>
+          <p><strong>Déplacée depuis « Urgent » le 11/08</strong>, à la demande : les 6 repos sont <strong>privés, sur un Gitea auto-hébergé</strong> — 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.</p>
+          <p>⚠️ <strong>Ce qui ne se négocie pas</strong> : 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 <code>app.myinfomate.be</code> déployé, <strong>ça veut dire avant la fin du lot de tests</strong>, 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.</p>
+          <span class="src">security/audit-securite-manager-service.md · v1-plan.md L1, I0</span>
         </article>
 
                                         <article class="card" data-area="backend infra">
-          <div class="card-meta"><span class="tag">étape 15</span><span class="flag f-good">Sans risque</span></div>
+          <div class="card-meta"><span class="tag">étape 15</span><span class="flag f-good">Sans risque</span></div>
           <h3>Dry run + comparaison des comptages</h3>
-          <p><code>dryRun=true</code> n'écrit rien. <strong>🔨 Joué le 11/08</strong> sur l'export du 1ᵉʳ avril, et automatisé en test (<code>MigrationDryRunTests</code>, qui se saute si aucun Mongo n'écoute — la suite reste verte sans dépendance).</p>
-          <p><strong>Il a trouvé du premier coup ce qu'aucune lecture de code n'avait vu</strong> : 327 sections dans Mongo, <strong>307 migrées, et <code>Erreurs : 0</code></strong>. Les 20 manquantes référencent deux configurations <em>supprimées</em> 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. <strong>Le défaut était le silence</strong> — elles partent maintenant dans <code>Skipped</code>, et le test affirme <code>migrées + signalées = Mongo</code>.</p>
-          <p>⚠️ <strong>Décision produit</strong> : recréer les 2 configurations dans Mongo avant la bascule pour récupérer ces 20 sections, ou acter leur perte. À trancher avec MDLF.</p>
-          <p>⚠️ <strong>À rejouer sur un dump frais</strong> : l'export a 4 mois et la prod tourne encore sur Mongo. Et <code>MigrationController</code> lit un Mongo <em>vivant</em>, pas ces fichiers — recette d'import dans v1-plan.</p>
-          <span class="src">STATUS.md §1quinquies — étape 15</span>
+          <p><code>dryRun=true</code> n'écrit rien. <strong>🔨 Joué le 11/08</strong> sur l'export du 1ᵉʳ avril, et automatisé en test (<code>MigrationDryRunTests</code>, qui se saute si aucun Mongo n'écoute — la suite reste verte sans dépendance).</p>
+          <p><strong>Il a trouvé du premier coup ce qu'aucune lecture de code n'avait vu</strong> : 327 sections dans Mongo, <strong>307 migrées, et <code>Erreurs : 0</code></strong>. Les 20 manquantes référencent deux configurations <em>supprimées</em> 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. <strong>Le défaut était le silence</strong> — elles partent maintenant dans <code>Skipped</code>, et le test affirme <code>migrées + signalées = Mongo</code>.</p>
+          <p>⚠️ <strong>Décision produit</strong> : recréer les 2 configurations dans Mongo avant la bascule pour récupérer ces 20 sections, ou acter leur perte. À trancher avec MDLF.</p>
+          <p>⚠️ <strong>À rejouer sur un dump frais</strong> : l'export a 4 mois et la prod tourne encore sur Mongo. Et <code>MigrationController</code> lit un Mongo <em>vivant</em>, pas ces fichiers — recette d'import dans v1-plan.</p>
+          <span class="src">STATUS.md §1quinquies — étape 15</span>
         </article>
 
         <article class="card" data-area="infra">
-          <div class="card-meta"><span class="tag">étape 16-17</span><span class="flag f-critical">Après rotation des secrets</span></div>
-          <h3>Créer l'environnement prod Postgres</h3>
-          <p><code>Deployment/Dockerfile.postgres</code> (digest épinglé), compose prod, Traefik, <strong>port 5432 fermé</strong>. Puis <code>dotnet ef database update</code> sur la base vide et vérifier que <code>postgis</code> <em>et</em> <code>vector</code> répondent. Ne pas créer la prod avec les clés encore committées.</p>
-          <span class="src">STATUS.md §1quinquies — étapes 16-17</span>
+          <div class="card-meta"><span class="tag">étape 16-17</span><span class="flag f-critical">Après rotation des secrets</span></div>
+          <h3>Créer l'environnement prod Postgres</h3>
+          <p><code>Deployment/Dockerfile.postgres</code> (digest épinglé), compose prod, Traefik, <strong>port 5432 fermé</strong>. Puis <code>dotnet ef database update</code> sur la base vide et vérifier que <code>postgis</code> <em>et</em> <code>vector</code> répondent. Ne pas créer la prod avec les clés encore committées.</p>
+          <span class="src">STATUS.md §1quinquies — étapes 16-17</span>
         </article>
 
         <article class="card" data-area="infra">
-          <div class="card-meta"><span class="tag">étape 18</span><span class="flag f-critical">Filet du jour J</span></div>
-          <h3>pg_dump avant / après + cron quotidien</h3>
-          <p>Noté comme « à faire » depuis juillet et jamais fait. Ici ça cesse d'être une bonne pratique : c'est la seule chose qui permette de recommencer si la bascule tourne mal.</p>
-          <span class="src">STATUS.md §4 · §1quinquies — étape 18</span>
+          <div class="card-meta"><span class="tag">étape 18</span><span class="flag f-critical">Filet du jour J</span></div>
+          <h3>pg_dump avant / après + cron quotidien</h3>
+          <p>Noté comme « à faire » depuis juillet et jamais fait. Ici ça cesse d'être une bonne pratique : c'est la seule chose qui permette de recommencer si la bascule tourne mal.</p>
+          <span class="src">STATUS.md §4 · §1quinquies — étape 18</span>
         </article>
 
         <article class="card" data-area="backend infra">
-          <div class="card-meta"><span class="tag">étape 19</span></div>
+          <div class="card-meta"><span class="tag">étape 19</span></div>
           <h3>Rejouer pour de vrai, instance par instance</h3>
-          <p>Le paramètre <code>instanceId</code> 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.</p>
-          <span class="src">STATUS.md §1quinquies — étape 19</span>
+          <p>Le paramètre <code>instanceId</code> 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.</p>
+          <span class="src">STATUS.md §1quinquies — étape 19</span>
         </article>
 
         <article class="card" data-area="backend infra">
-          <div class="card-meta"><span class="tag">étape I9</span><span class="flag f-warn">nouveau 12/08</span></div>
+          <div class="card-meta"><span class="tag">étape I9</span><span class="flag f-warn">nouveau 12/08</span></div>
           <h3>Poser <code>Firebase:StorageBucket</code>, puis lancer le backfill</h3>
-          <p>Deux gestes que C2 et C3 laissent à la mise en prod. <strong>1)</strong> La clé <code>Firebase:StorageBucket</code> (<code>&lt;project-id&gt;.appspot.com</code>) est <strong>vide par défaut</strong> : sans elle, <code>Delete</code> 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 ». <strong>2)</strong> Lancer le backfill : <code>POST /api/Resource/backfill-storage?dryRun=true</code>, relire <code>Orphans</code> et <code>Unsized</code>, puis <code>dryRun=false</code>. Sans lui le quota de C3 porte sur des <code>SizeBytes</code> à 0 pour tout l'existant, donc il laisse tout passer (<strong>L10</strong>).</p>
-          <p>⚠️ <strong>Piège de build repéré le 12/08</strong> : <code>dotnet restore</code> échoue en 401 si la source NuGet <code>git.dev-espaces-naturels.lu</code> est déclarée dans l'image — elle n'a rien à voir avec ce projet. <code>Google.Cloud.Storage.V1</code> étant le premier paquet ajouté depuis longtemps, le prochain build d'image la rencontrera.</p>
-          <span class="src">v1-plan.md lot I — I9 · STATUS.md §1sexies</span>
+          <p>Deux gestes que C2 et C3 laissent à la mise en prod. <strong>1)</strong> La clé <code>Firebase:StorageBucket</code> (<code>&lt;project-id&gt;.appspot.com</code>) est <strong>vide par défaut</strong> : sans elle, <code>Delete</code> 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 ». <strong>2)</strong> Lancer le backfill : <code>POST /api/Resource/backfill-storage?dryRun=true</code>, relire <code>Orphans</code> et <code>Unsized</code>, puis <code>dryRun=false</code>. Sans lui le quota de C3 porte sur des <code>SizeBytes</code> à 0 pour tout l'existant, donc il laisse tout passer (<strong>L10</strong>).</p>
+          <p>⚠️ <strong>Piège de build repéré le 12/08</strong> : <code>dotnet restore</code> échoue en 401 si la source NuGet <code>git.dev-espaces-naturels.lu</code> est déclarée dans l'image — elle n'a rien à voir avec ce projet. <code>Google.Cloud.Storage.V1</code> étant le premier paquet ajouté depuis longtemps, le prochain build d'image la rencontrera.</p>
+          <span class="src">v1-plan.md lot I — I9 · STATUS.md §1sexies</span>
         </article>
 
         <article class="card" data-area="backend manager visitapp">
-          <div class="card-meta"><span class="tag">étape 20</span><span class="flag f-warn">Le vrai test</span></div>
-          <h3>Vérifications post-bascule</h3>
-          <p>Login manager-app, une app visiteur avec sa clé API, un parcours, une carte, un PDF, <strong>un quiz avec ses questions</strong>. Les défauts « silencieux » ne se voient qu'ici — pas dans le rapport de migration.</p>
-          <span class="src">STATUS.md §1quinquies — étape 20</span>
+          <div class="card-meta"><span class="tag">étape 20</span><span class="flag f-warn">Le vrai test</span></div>
+          <h3>Vérifications post-bascule</h3>
+          <p>Login manager-app, une app visiteur avec sa clé API, un parcours, une carte, un PDF, <strong>un quiz avec ses questions</strong>. Les défauts « silencieux » ne se voient qu'ici — pas dans le rapport de migration.</p>
+          <span class="src">STATUS.md §1quinquies — étape 20</span>
         </article>
 
         <article class="card" data-area="infra">
-          <div class="card-meta"><span class="tag">étape 21-22</span></div>
+          <div class="card-meta"><span class="tag">étape 21-22</span></div>
           <h3>Bascule par coexistence sur deux serveurs</h3>
-          <p><strong>Décidé le 12/08, remplace la bascule DNS.</strong> Un second serveur porte la nouvelle prod Postgres, les <strong>nouvelles versions des apps</strong> 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.</p>
-          <p>C'est la seule réponse au problème que <strong>L19</strong> pose : on ne force pas la mise à jour du téléphone d'un visiteur.</p>
-          <p><strong>Ce qui rend la coexistence saine — une seule source d'écriture</strong> : 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 <strong>les deux bases ne divergent jamais</strong>.</p>
-          <p>⚠️ <strong>Ce qui ne marche pas : « recopier de la nouvelle prod vers l'ancienne ».</strong> Il n'existe pas de chemin Postgres → Mongo ; <code>MigrationController</code> va dans un seul sens et écrire l'inverse coûterait autant, pour alimenter une base qu'on éteint. L'ancienne prod <strong>se fige, elle ne se synchronise pas</strong>.</p>
-          <p>À tenir : une <strong>date d'extinction</strong> 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 <strong>plan de rollback réécrit</strong> — 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.</p>
-          <span class="src">v1-plan.md lot I — stratégie de coexistence</span>
+          <p><strong>Décidé le 12/08, remplace la bascule DNS.</strong> Un second serveur porte la nouvelle prod Postgres, les <strong>nouvelles versions des apps</strong> 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.</p>
+          <p>C'est la seule réponse au problème que <strong>L19</strong> pose : on ne force pas la mise à jour du téléphone d'un visiteur.</p>
+          <p><strong>Ce qui rend la coexistence saine — une seule source d'écriture</strong> : 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 <strong>les deux bases ne divergent jamais</strong>.</p>
+          <p>⚠️ <strong>Ce qui ne marche pas : « recopier de la nouvelle prod vers l'ancienne ».</strong> Il n'existe pas de chemin Postgres → Mongo ; <code>MigrationController</code> va dans un seul sens et écrire l'inverse coûterait autant, pour alimenter une base qu'on éteint. L'ancienne prod <strong>se fige, elle ne se synchronise pas</strong>.</p>
+          <p>À tenir : une <strong>date d'extinction</strong> 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 <strong>plan de rollback réécrit</strong> — 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.</p>
+          <span class="src">v1-plan.md lot I — stratégie de coexistence</span>
         </article>
 
       </div>
@@ -871,275 +871,275 @@
   </div>
 
   <section class="done">
-    <h2>Fait récemment</h2>
-    <p>Quarante-huit chantiers clos entre le 5 et le 12 août 2026.</p>
+    <h2>Fait récemment</h2>
+    <p>Quarante-huit chantiers clos entre le 5 et le 12 août 2026.</p>
     <div class="done-grid">
 
       <div class="done-item">
-        <strong>C4 — compression des images à l'upload, 2560 px / JPEG q82</strong>
-        <span><code>flutter build web</code> vert. Un seul helper appelé par les <strong>deux</strong> chemins d'upload de <code>resources_screen</code> — le motif exact qui a fait diverger <code>Create</code> et <code>Upload</code> côté serveur, sur <code>StoragePath</code> en C1 puis sur le pré-vol de quota en C3. ⚠️ <strong>La compression se fait avant <code>resourceCreate</code>, pas avant l'upload</strong> : le quota de C3 porte sur <code>sizeBytes</code> à la création, donc compresser après aurait fait décider le serveur sur la taille d'origine — et un quota qui compte 12× trop se remplit 12× trop vite.</span>
-        <span>⚠️ <strong>Écart assumé à l'énoncé</strong> : un PNG à canal alpha reste un PNG. Le passer en JPEG remplirait la transparence de noir et abîmerait logos et filigranes ; seul l'encodage diffère, le redimensionnement s'applique aux deux, et le type MIME suit. Si le ré-encodage grossit l'original — ce qui arrive sur une petite image déjà bien encodée — l'original est conservé. ⚠️ <strong>Défaut préexistant trouvé au passage</strong> : le second chemin d'upload ne renseignait <code>sizeBytes</code> ni avant ni après. Tout ce qui est passé par là compte <strong>0 octet au quota</strong> sur l'existant.</span>
+        <strong>C4 — compression des images à l'upload, 2560 px / JPEG q82</strong>
+        <span><code>flutter build web</code> vert. Un seul helper appelé par les <strong>deux</strong> chemins d'upload de <code>resources_screen</code> — le motif exact qui a fait diverger <code>Create</code> et <code>Upload</code> côté serveur, sur <code>StoragePath</code> en C1 puis sur le pré-vol de quota en C3. ⚠️ <strong>La compression se fait avant <code>resourceCreate</code>, pas avant l'upload</strong> : le quota de C3 porte sur <code>sizeBytes</code> à la création, donc compresser après aurait fait décider le serveur sur la taille d'origine — et un quota qui compte 12× trop se remplit 12× trop vite.</span>
+        <span>⚠️ <strong>Écart assumé à l'énoncé</strong> : un PNG à canal alpha reste un PNG. Le passer en JPEG remplirait la transparence de noir et abîmerait logos et filigranes ; seul l'encodage diffère, le redimensionnement s'applique aux deux, et le type MIME suit. Si le ré-encodage grossit l'original — ce qui arrive sur une petite image déjà bien encodée — l'original est conservé. ⚠️ <strong>Défaut préexistant trouvé au passage</strong> : le second chemin d'upload ne renseignait <code>sizeBytes</code> ni avant ni après. Tout ce qui est passé par là compte <strong>0 octet au quota</strong> sur l'existant.</span>
       </div>
 
       <div class="done-item">
-        <strong>K8 — la borne revient à l'accueil après 5 min sans interaction</strong>
-        <span>Un visiteur part sans fermer l'écran ; le suivant trouvait le contenu du précédent. <strong>Écrit une seule fois</strong>, dans <code>section_page_detail</code>, qui enveloppe les treize types et portait déjà les crochets des statistiques — dans les écrans, il aurait été écrit treize fois.</span>
-        <span><strong>Bénéfice de bord qui n'en est pas un</strong> : le retour passe par le même <code>dispose</code>, donc il émet un <code>sectionLeave</code> avec sa durée réelle. Sans lui, une consultation abandonnée restait ouverte jusqu'au visiteur suivant et gonflait la durée mesurée d'autant — <strong>K8 répare une statistique en plus d'un écran</strong>. <code>Listener</code> plutôt que <code>GestureDetector</code> pour réarmer : il observe les pointeurs sans concurrencer les gestes des écrans en dessous. ⚠️ Non vérifié : le comportement après 5 minutes réelles, et le fait que l'accueil soit bien la première route de la pile.</span>
+        <strong>K8 — la borne revient à l'accueil après 5 min sans interaction</strong>
+        <span>Un visiteur part sans fermer l'écran ; le suivant trouvait le contenu du précédent. <strong>Écrit une seule fois</strong>, dans <code>section_page_detail</code>, qui enveloppe les treize types et portait déjà les crochets des statistiques — dans les écrans, il aurait été écrit treize fois.</span>
+        <span><strong>Bénéfice de bord qui n'en est pas un</strong> : le retour passe par le même <code>dispose</code>, donc il émet un <code>sectionLeave</code> avec sa durée réelle. Sans lui, une consultation abandonnée restait ouverte jusqu'au visiteur suivant et gonflait la durée mesurée d'autant — <strong>K8 répare une statistique en plus d'un écran</strong>. <code>Listener</code> plutôt que <code>GestureDetector</code> pour réarmer : il observe les pointeurs sans concurrencer les gestes des écrans en dessous. ⚠️ Non vérifié : le comportement après 5 minutes réelles, et le fait que l'accueil soit bien la première route de la pile.</span>
       </div>
 
       <div class="done-item">
-        <strong>La borne couvre 12 des 13 types — SectionArticle (K7) et SectionEvent (K3) livrés</strong>
-        <span><code>flutter build apk --debug</code> <strong>vert</strong>, APK produit. Seul <code>SectionParcours</code> reste dehors, et <strong>définitivement</strong> — un parcours guidé fait marcher le visiteur. Les deux écrans suivent la maquette paysage : rail média ancré + colonne de lecture plafonnée pour l'article, bande héros à 26 % + programme + carte vive pour l'événement, détail d'un bloc <strong>sous la carte</strong> et non en <code>showModalBottomSheet</code>.</span>
-        <span>⚠️ <strong>La barre de pied de la maquette n'appartenait pas aux écrans</strong> : <code>section_page_detail</code> dessine déjà le bouton retour, avec les clés <code>back</code>/<code>menu</code> selon <code>isFromMenu</code>. Les dessiner aurait donné deux boutons. ⚠️ <strong>Un seul constructeur de marqueurs au lieu des quatre de mymuseum</strong> : <code>MapAnnotationDTO</code> et <code>MapAnnotation</code> ont des champs rigoureusement identiques mais sont deux types Dart distincts. Normalisé par une classe interne à deux fabriques — c'est L5 appliqué au front, et il porte d'autant plus que la convention <code>[lng, lat]</code> est l'endroit exact où une divergence <em>ne lève aucune erreur</em>.</span>
-        <span>⚠️ <strong>L'audio d'article se résout dans <code>contents</code> avant l'API</strong> : <code>ContentDTO</code> porte son <code>resource</code> complet, donc l'audio est trouvé sans appel réseau quand il est embarqué — donc hors ligne aussi. Mymuseum appelle l'API systématiquement en ligne. ⚠️ <strong>Clé i18n <code>event.live</code> ajoutée aux 10 langues</strong> — sans les 10, <code>getFromLocale</code> renvoie <code>""</code> et la pastille rendrait une boîte vide. <strong>PL, CN, UK et AR sont de ma main et demandent une relecture humaine.</strong></span>
-        <span>⚠️ <strong>Ce qui n'est pas prouvé : le rendu.</strong> Aucun des deux écrans n'a été vu à l'œil — un build vert ne dit rien d'une mise en page, c'est la leçon du §1bis appliquée au design. Et <strong>aucun <code>SectionEvent</code> n'existe en base</strong>, le type étant né avec Postgres v3 : c'est le §19.13 cas E qui en créera un.</span>
+        <strong>La borne couvre 12 des 13 types — SectionArticle (K7) et SectionEvent (K3) livrés</strong>
+        <span><code>flutter build apk --debug</code> <strong>vert</strong>, APK produit. Seul <code>SectionParcours</code> reste dehors, et <strong>définitivement</strong> — un parcours guidé fait marcher le visiteur. Les deux écrans suivent la maquette paysage : rail média ancré + colonne de lecture plafonnée pour l'article, bande héros à 26 % + programme + carte vive pour l'événement, détail d'un bloc <strong>sous la carte</strong> et non en <code>showModalBottomSheet</code>.</span>
+        <span>⚠️ <strong>La barre de pied de la maquette n'appartenait pas aux écrans</strong> : <code>section_page_detail</code> dessine déjà le bouton retour, avec les clés <code>back</code>/<code>menu</code> selon <code>isFromMenu</code>. Les dessiner aurait donné deux boutons. ⚠️ <strong>Un seul constructeur de marqueurs au lieu des quatre de mymuseum</strong> : <code>MapAnnotationDTO</code> et <code>MapAnnotation</code> ont des champs rigoureusement identiques mais sont deux types Dart distincts. Normalisé par une classe interne à deux fabriques — c'est L5 appliqué au front, et il porte d'autant plus que la convention <code>[lng, lat]</code> est l'endroit exact où une divergence <em>ne lève aucune erreur</em>.</span>
+        <span>⚠️ <strong>L'audio d'article se résout dans <code>contents</code> avant l'API</strong> : <code>ContentDTO</code> porte son <code>resource</code> complet, donc l'audio est trouvé sans appel réseau quand il est embarqué — donc hors ligne aussi. Mymuseum appelle l'API systématiquement en ligne. ⚠️ <strong>Clé i18n <code>event.live</code> ajoutée aux 10 langues</strong> — sans les 10, <code>getFromLocale</code> renvoie <code>""</code> et la pastille rendrait une boîte vide. <strong>PL, CN, UK et AR sont de ma main et demandent une relecture humaine.</strong></span>
+        <span>⚠️ <strong>Ce qui n'est pas prouvé : le rendu.</strong> Aucun des deux écrans n'a été vu à l'œil — un build vert ne dit rien d'une mise en page, c'est la leçon du §1bis appliquée au design. Et <strong>aucun <code>SectionEvent</code> n'existe en base</strong>, le type étant né avec Postgres v3 : c'est le §19.13 cas E qui en créera un.</span>
       </div>
 
       <div class="done-item">
-        <strong>K5 — l'APK <code>mymuseum-visitapp</code> se construit, et le lot n'était pas ce qu'on croyait</strong>
-        <span><strong>La prémisse était périmée.</strong> Trois documents annonçaient « <code>flutter build apk</code> échoue côté Gradle/NDK », revérifié le 11/08. Les <strong>trois flavors</strong> (<code>dev</code>, <code>mdlf</code>, <code>fortsaintheribert</code>) construisent en exit 0, APK à l'appui. Sa config Android était <strong>déjà à niveau</strong> — Gradle 8.11.1, AGP 8.9.0, <code>-Xmx4096M</code>, <code>enableJetifier=false</code>, aucun forçage d'<code>androidx.lifecycle</code>. Les dix crans du 12/08 ont amené <strong>tablet-app jusqu'à mymuseum</strong> ; il ne restait pas la même migration à refaire ici. Le « réflexe du diff » noté la veille donnait la réponse en deux <code>cat</code> — appliqué, il l'a donnée.</span>
-        <span><strong>Le contenu réel du lot</strong> : les deux avertissements du build. NDK <strong>27.0.12077973 → 28.2.13676358</strong> (<code>speech_to_text</code> le réclame nommément) et Kotlin <strong>2.1.0 → 2.3.10</strong> (sous le seuil 2.2.20 annoncé comme rupture par Flutter ; <strong>aligne sur tablet-app</strong>, aucune version neuve introduite). Six builds au total — les trois flavors avant, les trois après — logs relus intégralement, codes de sortie lus hors redirection, APK datés vérifiés sur disque : les trois pièges de vérification du 12/08 sont couverts. Effet mesuré : l'APK passe de <strong>382 à 349 Mo</strong>.</span>
-        <span>⚠️ <strong>Un cran de plus existe, délibérément non pris.</strong> Kotlin réglé, le validateur Flutter en révèle deux autres — Gradle 8.11.1 → 8.14.0 et AGP 8.9.0 → 8.11.1, « soon be dropped ». Même cascade que les dix crans de tablet-app. Arrêté là parce que c'est du <strong>terrain neuf pour les deux repos</strong> (tablet-app est à 8.11.1/8.9.1, mêmes avertissements latents) : le faire ici seul <em>désaligne</em> les deux apps au lieu de les aligner. À faire d'un bloc sur les deux, ou pas du tout — le plan parke déjà cette dette en V2.</span>
-        <span>⚠️ <strong>Une question ouverte pour K6</strong> : le travail V1 récent de ce repo (D1, lot E, lot A) est committé sur <code>Meta-Rayban-Test</code>, pas sur <code>master</code>. C'est la branche de travail réelle, alors que le §5bis la décrit comme « un POC jamais mergé ». À trancher <strong>avant de publier</strong>. <code>tablet-app</code> est dans le même cas, sur <code>AI-Assistant-test</code>. <strong>Ce que K5 débloque</strong> : D0 / test-plan §21 sur device, donc la mesure des bugs offline D2-D5 et la confirmation du volet visiteur de D1, qui ne tient aujourd'hui que sur <code>flutter analyze</code>.</span>
+        <strong>K5 — l'APK <code>mymuseum-visitapp</code> se construit, et le lot n'était pas ce qu'on croyait</strong>
+        <span><strong>La prémisse était périmée.</strong> Trois documents annonçaient « <code>flutter build apk</code> échoue côté Gradle/NDK », revérifié le 11/08. Les <strong>trois flavors</strong> (<code>dev</code>, <code>mdlf</code>, <code>fortsaintheribert</code>) construisent en exit 0, APK à l'appui. Sa config Android était <strong>déjà à niveau</strong> — Gradle 8.11.1, AGP 8.9.0, <code>-Xmx4096M</code>, <code>enableJetifier=false</code>, aucun forçage d'<code>androidx.lifecycle</code>. Les dix crans du 12/08 ont amené <strong>tablet-app jusqu'à mymuseum</strong> ; il ne restait pas la même migration à refaire ici. Le « réflexe du diff » noté la veille donnait la réponse en deux <code>cat</code> — appliqué, il l'a donnée.</span>
+        <span><strong>Le contenu réel du lot</strong> : les deux avertissements du build. NDK <strong>27.0.12077973 → 28.2.13676358</strong> (<code>speech_to_text</code> le réclame nommément) et Kotlin <strong>2.1.0 → 2.3.10</strong> (sous le seuil 2.2.20 annoncé comme rupture par Flutter ; <strong>aligne sur tablet-app</strong>, aucune version neuve introduite). Six builds au total — les trois flavors avant, les trois après — logs relus intégralement, codes de sortie lus hors redirection, APK datés vérifiés sur disque : les trois pièges de vérification du 12/08 sont couverts. Effet mesuré : l'APK passe de <strong>382 à 349 Mo</strong>.</span>
+        <span>⚠️ <strong>Un cran de plus existe, délibérément non pris.</strong> Kotlin réglé, le validateur Flutter en révèle deux autres — Gradle 8.11.1 → 8.14.0 et AGP 8.9.0 → 8.11.1, « soon be dropped ». Même cascade que les dix crans de tablet-app. Arrêté là parce que c'est du <strong>terrain neuf pour les deux repos</strong> (tablet-app est à 8.11.1/8.9.1, mêmes avertissements latents) : le faire ici seul <em>désaligne</em> les deux apps au lieu de les aligner. À faire d'un bloc sur les deux, ou pas du tout — le plan parke déjà cette dette en V2.</span>
+        <span>⚠️ <strong>Une question ouverte pour K6</strong> : le travail V1 récent de ce repo (D1, lot E, lot A) est committé sur <code>Meta-Rayban-Test</code>, pas sur <code>master</code>. C'est la branche de travail réelle, alors que le §5bis la décrit comme « un POC jamais mergé ». À trancher <strong>avant de publier</strong>. <code>tablet-app</code> est dans le même cas, sur <code>AI-Assistant-test</code>. <strong>Ce que K5 débloque</strong> : D0 / test-plan §21 sur device, donc la mesure des bugs offline D2-D5 et la confirmation du volet visiteur de D1, qui ne tient aujourd'hui que sur <code>flutter analyze</code>.</span>
       </div>
 
       <div class="done-item">
-        <strong>Lot médias terminé côté serveur — backfill (C2) et quota autoritaire (C3)</strong>
-        <span><strong>C2</strong> : <code>POST /api/Resource/backfill-storage</code>, SuperAdmin, <code>dryRun</code> à <strong>true par défaut</strong> — la migration se joue sur une base vide, ce backfill sur des lignes de production. La méthode annoncée au plan (« <code>SizeBytes</code> par listing du bucket Firebase ») était <strong>inapplicable</strong> : le serveur n'avait aucun client de stockage. Le sondage passe par HEAD, et <strong>le sondeur est extrait plutôt que recopié</strong> (<code>ResourceSizeProbe</code>, partagé avec la migration — même raisonnement que L5). ⚠️ <strong>L'extraction a bouché un trou que personne ne cherchait</strong> : l'original ne notait l'échec que dans son <code>catch</code>, or un HEAD sur un blob absent <strong>ne lève pas</strong> — il répond 404 sans <code>Content-Length</code>. Ces ressources arrivaient à 0 octet <em>sans figurer dans le rapport</em>. Le « 37 sur 45 » du plan n'étant pas vérifiable d'ici, le backfill rend son propre inventaire, <code>Orphans</code> et <code>Unsized</code> séparés — deux causes distinctes, jamais additionnées.</span>
-        <span><strong>C3</strong> : ⚠️ le pré-vol <strong>existait déjà à moitié et ce n'était écrit nulle part</strong> — <code>Upload</code> (multipart) contrôlait, <code>Create</code> (JSON) ne contrôlait rien, or c'est le chemin qu'emprunte manager-app. ⚠️ Et les deux lectures du quota <strong>divergeaient</strong> : <code>Upload</code> lisait le <em>plan</em>, <code>GetQuota</code> l'<em>instance</em> avec le plan en repli — une instance à quota surchargé (le mécanisme de l'add-on) affichait un chiffre et se faisait bloquer sur un autre. Fermé par <code>StorageQuota</code>. <code>Delete</code> supprime le blob <strong>avant</strong> la ligne et renvoie <strong>502</strong> en la conservant si le bucket échoue : une ressource encore listée se rattrape, un blob que plus aucune ligne ne désigne est facturé à l'aveugle. ✅ L'angle mort laissé par C1 était une <strong>fausse crainte</strong> : <code>PathFor</code> ne construit qu'un <code>pictures/{instanceId}/{resourceId}</code>, le type n'entre pas dans le chemin. <strong>Aucun secret nouveau</strong> : <code>FirebaseAdmin</code> était déjà là pour le push, <code>Google.Cloud.Storage.V1</code> réutilise le même credential. <code>dotnet test</code> <strong>163/163</strong>.</span>
+        <strong>Lot médias terminé côté serveur — backfill (C2) et quota autoritaire (C3)</strong>
+        <span><strong>C2</strong> : <code>POST /api/Resource/backfill-storage</code>, SuperAdmin, <code>dryRun</code> à <strong>true par défaut</strong> — la migration se joue sur une base vide, ce backfill sur des lignes de production. La méthode annoncée au plan (« <code>SizeBytes</code> par listing du bucket Firebase ») était <strong>inapplicable</strong> : le serveur n'avait aucun client de stockage. Le sondage passe par HEAD, et <strong>le sondeur est extrait plutôt que recopié</strong> (<code>ResourceSizeProbe</code>, partagé avec la migration — même raisonnement que L5). ⚠️ <strong>L'extraction a bouché un trou que personne ne cherchait</strong> : l'original ne notait l'échec que dans son <code>catch</code>, or un HEAD sur un blob absent <strong>ne lève pas</strong> — il répond 404 sans <code>Content-Length</code>. Ces ressources arrivaient à 0 octet <em>sans figurer dans le rapport</em>. Le « 37 sur 45 » du plan n'étant pas vérifiable d'ici, le backfill rend son propre inventaire, <code>Orphans</code> et <code>Unsized</code> séparés — deux causes distinctes, jamais additionnées.</span>
+        <span><strong>C3</strong> : ⚠️ le pré-vol <strong>existait déjà à moitié et ce n'était écrit nulle part</strong> — <code>Upload</code> (multipart) contrôlait, <code>Create</code> (JSON) ne contrôlait rien, or c'est le chemin qu'emprunte manager-app. ⚠️ Et les deux lectures du quota <strong>divergeaient</strong> : <code>Upload</code> lisait le <em>plan</em>, <code>GetQuota</code> l'<em>instance</em> avec le plan en repli — une instance à quota surchargé (le mécanisme de l'add-on) affichait un chiffre et se faisait bloquer sur un autre. Fermé par <code>StorageQuota</code>. <code>Delete</code> supprime le blob <strong>avant</strong> la ligne et renvoie <strong>502</strong> en la conservant si le bucket échoue : une ressource encore listée se rattrape, un blob que plus aucune ligne ne désigne est facturé à l'aveugle. ✅ L'angle mort laissé par C1 était une <strong>fausse crainte</strong> : <code>PathFor</code> ne construit qu'un <code>pictures/{instanceId}/{resourceId}</code>, le type n'entre pas dans le chemin. <strong>Aucun secret nouveau</strong> : <code>FirebaseAdmin</code> était déjà là pour le push, <code>Google.Cloud.Storage.V1</code> réutilise le même credential. <code>dotnet test</code> <strong>163/163</strong>.</span>
       </div>
 
       <div class="done-item">
-        <strong>tablet-app construit à nouveau — APK produit pour la première fois depuis avril</strong>
-        <span><code>flutter build apk --debug</code> <strong>vert</strong>. K1, K2 et K4 sont livrés et <em>prouvés par un build</em>, pas seulement par <code>flutter analyze</code>. L'outillage a demandé <strong>dix crans</strong>, pas les six annoncés en cours de journée : ce compte datait du moment où la chaîne Gradle passait, avant que la compilation Kotlin ne révèle la suite — heap à 4096M, Jetifier coupé, forçage <code>androidx.lifecycle</code> retiré, Kotlin porté à 2.3.10. ⚠️ <strong>Trois de ces quatre derniers crans étaient de simples alignements sur mymuseum-visitapp</strong>, qui utilise le même plugin mapbox sans rencontrer aucun de ces problèmes : les causes ont été cherchées une par une alors qu'un <code>diff</code> des deux <code>gradle.properties</code> les donnait toutes d'un coup. <strong>Réflexe pour K5 : commencer par ce diff.</strong><br><br>Le cran le plus instructif : un <code>resolutionStrategy</code> forçait <code>androidx.lifecycle</code> à 2.4.0 sous le commentaire « To fix mapbox issue ». Il réglait un problème d'il y a trois ans et <strong>causait</strong> celui d'aujourd'hui — <code>mapbox_maps_flutter</code> 2.21.1 appelle <code>setViewTreeLifecycleOwner</code>, absent de 2.4.0. Du contournement fossilisé, comme les trois blocs commentés qui ont fait mentir les diagnostics le même jour. K4 apporte au passage à la tablette le <strong>puzzle glissant</strong>, le bouton d'indice et un dimensionnement au ratio de l'image.</span>
+        <strong>tablet-app construit à nouveau — APK produit pour la première fois depuis avril</strong>
+        <span><code>flutter build apk --debug</code> <strong>vert</strong>. K1, K2 et K4 sont livrés et <em>prouvés par un build</em>, pas seulement par <code>flutter analyze</code>. L'outillage a demandé <strong>dix crans</strong>, pas les six annoncés en cours de journée : ce compte datait du moment où la chaîne Gradle passait, avant que la compilation Kotlin ne révèle la suite — heap à 4096M, Jetifier coupé, forçage <code>androidx.lifecycle</code> retiré, Kotlin porté à 2.3.10. ⚠️ <strong>Trois de ces quatre derniers crans étaient de simples alignements sur mymuseum-visitapp</strong>, qui utilise le même plugin mapbox sans rencontrer aucun de ces problèmes : les causes ont été cherchées une par une alors qu'un <code>diff</code> des deux <code>gradle.properties</code> les donnait toutes d'un coup. <strong>Réflexe pour K5 : commencer par ce diff.</strong><br><br>Le cran le plus instructif : un <code>resolutionStrategy</code> forçait <code>androidx.lifecycle</code> à 2.4.0 sous le commentaire « To fix mapbox issue ». Il réglait un problème d'il y a trois ans et <strong>causait</strong> celui d'aujourd'hui — <code>mapbox_maps_flutter</code> 2.21.1 appelle <code>setViewTreeLifecycleOwner</code>, absent de 2.4.0. Du contournement fossilisé, comme les trois blocs commentés qui ont fait mentir les diagnostics le même jour. K4 apporte au passage à la tablette le <strong>puzzle glissant</strong>, le bouton d'indice et un dimensionnement au ratio de l'image.</span>
       </div>
 
       <div class="done-item">
-        <strong>tablet-app rebranché sur le contrat d'API de Postgres v3 (K2)</strong>
-        <span>Les <strong>132 erreurs Dart</strong> que le Gradle masquait sont tombées : <code>flutter analyze lib</code> ne renvoie plus que les 6 <code>PuzzleDTO</code> de K4. Livré : <code>TabletAppContext.currentAppConfigurationLink</code> (copie du getter de mymuseum), <code>lib/Helpers/geo.dart</code> avec l'extension <code>lat</code>/<code>lng</code>, 67 accès <code>roundedValue</code> rebranchés, <code>main_view</code> et les 4 vues carte portées. La formule de clé par coordonnées de <code>geo_point_filter</code>, <strong>dupliquée à quatre endroits</strong> alors que les deux côtés de l'appariement doivent produire la même valeur, ne vit plus qu'à un seul.<br><br>⚠️ <strong>Deux bugs latents trouvés — la raison pour laquelle un chercher-remplacer aurait été dangereux.</strong> <strong>(1)</strong> <code>applicationInstanceDTO</code> n'était assigné <em>que si</em> l'instance avait l'IA : il servait de drapeau d'assistant. Ce DTO portant désormais les <code>AppConfigurationLink</code>, le nouveau getter aurait renvoyé <code>null</code> sur <strong>toute instance sans IA — donc MDLF et le Fort</strong> — et les cinq réglages d'affichage seraient retombés sur leurs défauts, <em>sans erreur ni log</em>. Drapeau rendu explicite (<code>isAssistantEnabled</code>), en préservant le ET instance × canal. <strong>(2)</strong> <code>ConfigurationDTO.isTablet</code> ayant disparu, le filtre « configurations pour tablette » n'avait plus de source : il porte maintenant sur les liens du canal <code>AppType.Tablet</code>. <strong>À valider sur device</strong> — une configuration non rattachée au canal tablette rendra l'écran de sélection vide.</span>
+        <strong>tablet-app rebranché sur le contrat d'API de Postgres v3 (K2)</strong>
+        <span>Les <strong>132 erreurs Dart</strong> que le Gradle masquait sont tombées : <code>flutter analyze lib</code> ne renvoie plus que les 6 <code>PuzzleDTO</code> de K4. Livré : <code>TabletAppContext.currentAppConfigurationLink</code> (copie du getter de mymuseum), <code>lib/Helpers/geo.dart</code> avec l'extension <code>lat</code>/<code>lng</code>, 67 accès <code>roundedValue</code> rebranchés, <code>main_view</code> et les 4 vues carte portées. La formule de clé par coordonnées de <code>geo_point_filter</code>, <strong>dupliquée à quatre endroits</strong> alors que les deux côtés de l'appariement doivent produire la même valeur, ne vit plus qu'à un seul.<br><br>⚠️ <strong>Deux bugs latents trouvés — la raison pour laquelle un chercher-remplacer aurait été dangereux.</strong> <strong>(1)</strong> <code>applicationInstanceDTO</code> n'était assigné <em>que si</em> l'instance avait l'IA : il servait de drapeau d'assistant. Ce DTO portant désormais les <code>AppConfigurationLink</code>, le nouveau getter aurait renvoyé <code>null</code> sur <strong>toute instance sans IA — donc MDLF et le Fort</strong> — et les cinq réglages d'affichage seraient retombés sur leurs défauts, <em>sans erreur ni log</em>. Drapeau rendu explicite (<code>isAssistantEnabled</code>), en préservant le ET instance × canal. <strong>(2)</strong> <code>ConfigurationDTO.isTablet</code> ayant disparu, le filtre « configurations pour tablette » n'avait plus de source : il porte maintenant sur les liens du canal <code>AppType.Tablet</code>. <strong>À valider sur device</strong> — une configuration non rattachée au canal tablette rendra l'écran de sélection vide.</span>
       </div>
 
       <div class="done-item">
-        <strong>tablet-app : dix crans d'outillage Android rattrapés</strong>
-        <span>Le premier vrai build depuis des mois. Chaque erreur dictait le correctif suivant : Gradle <strong>7.5 → 8.11.1</strong> (le plugin Kotlin exigeait ≥ 7.6.3), AGP <strong>7.2.0 → 8.5.0</strong> puis <strong>8.7.3</strong> (minimum Flutter) puis <strong>8.9.1</strong> (réclamé par <code>androidx.browser</code> et <code>core-ktx</code>), suppression de <code>android.bundle.enableUncompressedNativeLibs</code> (retirée en AGP 8.1), <code>jcenter()</code> → <code>mavenCentral()</code> (arrêté depuis 2021), <code>jvmargs</code> <strong>1536M → 4096M</strong> et <code>enableJetifier</code> <strong>true → false</strong> (Jetifier ne sert plus à rien depuis qu'AndroidX est partout, et c'est lui qui saturait la heap), et Kotlin <strong>1.9.0 → 2.3.10</strong> (les dépendances tirent <code>kotlin-stdlib 2.3.10</code>, métadonnées incompatibles avec un compilateur 2.0).</span>
-        <span>⚠️ <strong>Le cran le plus instructif</strong> : un <code>resolutionStrategy</code> forçait <code>androidx.lifecycle</code> en <strong>2.4.0</strong> avec le commentaire « To fix mapbox issue ». Il réglait un problème mapbox d'il y a trois ans et <strong>causait</strong> celui d'aujourd'hui — <code>mapbox_maps_flutter</code> 2.21.1 appelle <code>setViewTreeLifecycleOwner</code>, absent de 2.4.0. Retiré, avec un commentaire pour qu'on ne le remette pas. ⚠️ Et un <strong>bloc <code>buildscript</code> entièrement commenté</strong> déclarait AGP 8.5.0/Kotlin 2.0.10 pendant que la vraie config vivait dans <code>settings.gradle</code> en 7.2.0/1.9.0 : il a fait conclure deux fois à une configuration qui n'était pas celle du build — supprimé. <strong>Troisième piège « bloc commenté »</strong> du projet.</span>
-        <span><strong>Trois de ces crans sont des alignements sur <code>mymuseum-visitapp</code></strong>, qui utilise le même plugin mapbox sans rencontrer aucun de ces problèmes. Réflexe à garder : comparer les deux <code>gradle.properties</code> et les deux <code>build.gradle</code> avant de chercher. Ce que ça débloque : <code>compileSdkVersion 36</code>, sans lequel plus aucune mise à jour n'est publiable sur le store. ⚠️ Le compte de « six crans » annoncé plus tôt dans la journée était provisoire — il datait du moment où la chaîne Gradle passait, avant que la compilation Kotlin ne révèle la suite.</span>
+        <strong>tablet-app : dix crans d'outillage Android rattrapés</strong>
+        <span>Le premier vrai build depuis des mois. Chaque erreur dictait le correctif suivant : Gradle <strong>7.5 → 8.11.1</strong> (le plugin Kotlin exigeait ≥ 7.6.3), AGP <strong>7.2.0 → 8.5.0</strong> puis <strong>8.7.3</strong> (minimum Flutter) puis <strong>8.9.1</strong> (réclamé par <code>androidx.browser</code> et <code>core-ktx</code>), suppression de <code>android.bundle.enableUncompressedNativeLibs</code> (retirée en AGP 8.1), <code>jcenter()</code> → <code>mavenCentral()</code> (arrêté depuis 2021), <code>jvmargs</code> <strong>1536M → 4096M</strong> et <code>enableJetifier</code> <strong>true → false</strong> (Jetifier ne sert plus à rien depuis qu'AndroidX est partout, et c'est lui qui saturait la heap), et Kotlin <strong>1.9.0 → 2.3.10</strong> (les dépendances tirent <code>kotlin-stdlib 2.3.10</code>, métadonnées incompatibles avec un compilateur 2.0).</span>
+        <span>⚠️ <strong>Le cran le plus instructif</strong> : un <code>resolutionStrategy</code> forçait <code>androidx.lifecycle</code> en <strong>2.4.0</strong> avec le commentaire « To fix mapbox issue ». Il réglait un problème mapbox d'il y a trois ans et <strong>causait</strong> celui d'aujourd'hui — <code>mapbox_maps_flutter</code> 2.21.1 appelle <code>setViewTreeLifecycleOwner</code>, absent de 2.4.0. Retiré, avec un commentaire pour qu'on ne le remette pas. ⚠️ Et un <strong>bloc <code>buildscript</code> entièrement commenté</strong> déclarait AGP 8.5.0/Kotlin 2.0.10 pendant que la vraie config vivait dans <code>settings.gradle</code> en 7.2.0/1.9.0 : il a fait conclure deux fois à une configuration qui n'était pas celle du build — supprimé. <strong>Troisième piège « bloc commenté »</strong> du projet.</span>
+        <span><strong>Trois de ces crans sont des alignements sur <code>mymuseum-visitapp</code></strong>, qui utilise le même plugin mapbox sans rencontrer aucun de ces problèmes. Réflexe à garder : comparer les deux <code>gradle.properties</code> et les deux <code>build.gradle</code> avant de chercher. Ce que ça débloque : <code>compileSdkVersion 36</code>, sans lequel plus aucune mise à jour n'est publiable sur le store. ⚠️ Le compte de « six crans » annoncé plus tôt dans la journée était provisoire — il datait du moment où la chaîne Gradle passait, avant que la compilation Kotlin ne révèle la suite.</span>
       </div>
 
       <div class="done-item">
-        <strong>Lot F côté manager-service : les quatre chantiers de dette backend, en une passe</strong>
-        <span><code>dotnet test</code> <strong>163 → 200</strong>, aucun test sauté, quatre commits, <code>manager-service</code> seul. <strong>1) Le journal d'audit voyait tout sauf le contenu</strong> : <code>AuditedTypes.Contains(entry.Entity.GetType())</code> exigeait l'égalité <strong>exacte</strong>, or <code>Section</code> est abstraite — aucune des 13 sortes de section n'était journalisée, soit précisément ce que l'écran du 12/08 devait tracer. <code>Resource</code>, <code>Configuration</code>, <code>Device</code>, <code>User</code> et <code>Instance</code> passaient, eux : ils sont concrets, <strong>et c'est ce qui rendait le trou invisible</strong>. <strong>Tranché : normalisation côté serveur</strong> — <code>EntityType</code> porte <code>Section</code>, donc le filtre déjà présent dans l'écran se met à rendre des lignes <strong>sans toucher <code>manager-app</code></strong> ; élargir le filtre front aurait coûté 13 entrées et 39 clés i18n <em>et</em> laissé tout futur sous-type sortir du filtre en silence — la classe de panne exacte qu'on ferme. Le sous-type n'est pas perdu : le discriminateur TPH est sérialisé dans <code>NewValues</code>, un test le vérifie. 8 tests, dont un <strong>par réflexion</strong> sur les 13 sous-types — la liste d'origine n'obligeait personne à la suivre, c'est ce qui l'a laissée devenir fausse.</span>
-        <span><strong>2) Plafond de 5 utilisateurs</strong> : <code>CreateUser</code> rend <strong>422</strong>. <strong>5 en dur</strong> (le faire varier par plan serait une colonne, donc une migration après le gel du lot B — dette V1 assumée) et <strong>SuperAdmin exempté</strong>, seule porte de service tant qu'aucun champ ne permet de relever la limite d'un client. Rien à retoucher côté front. <strong>3) <code>GetSummary</code> agrège en SQL</strong> au lieu de charger 13 mois en mémoire ; les six agrégats qui se lisent dans le JSON de <code>Metadata</code> ne remontent plus que <strong>deux colonnes</strong>, pour leur seul type d'événement, et les stats avancées ne sont plus calculées puis effacées pour les plans qui n'y ont pas droit. ⚠️ <strong>La branche « stats avancées » n'était couverte par aucun test</strong> : les cas existants ne seedent pas d'<code>Instance</code>, donc <code>hasAdvancedStats</code> était toujours faux et la moitié de la méthode n'était jamais exécutée.</span>
-        <span><strong>4) Le vector store est éprouvé à DEUX instances, sur un vrai Postgres</strong> — 14 tests Testcontainers sur l'image de <code>Dockerfile.postgres</code>, qui se sautent proprement sans démon Docker (186 passés / 14 sautés / 0 échec). pgvector <strong>0.8.6</strong> : le <code>SET hnsw.iterative_scan</code> que pose <code>SearchAsync</code> est accepté — sur une version antérieure, <strong>toute recherche échouait en production</strong>. À 30 contre 1, la recherche rend le bon nombre de résultats, tous de la bonne instance, aucune fuite. ⚠️ <strong>Deux résultats contraires à ce que le plan supposait</strong> : ce qui protège du post-filtrage <strong>n'est pas le parcours itératif mais l'index sur <code>(InstanceId, ContentType)</code></strong> — le planificateur filtre d'abord et trie exactement, l'index HNSW n'est jamais touché (vérifié à 620 lignes et à 22 000) ; et cet index retiré, <code>relaxed_order</code> <strong>ne rattrape rien</strong>, le parcours s'épuisant après ~335 lignes sans atteindre l'instance minoritaire. Le même jeu de données avec l'index HNSW construit <em>après</em> l'insertion rend bien ses 20 lignes : c'est la connectivité du graphe qui décide, et nos migrations créent l'index sur une table vide. <strong>Outillage</strong> : Testcontainers épinglé en 3.10.0 (la 4.x parle l'API Docker 1.44, l'engine local plafonne à 1.43) et image construite par le CLI docker — le constructeur de Testcontainers ne sait pas parser le <code>tag@sha256:</code> du Dockerfile, digest qui protège la base d'un changement de glibc sous ses index et ne se retire pas pour un test.</span>
-        <span>⚠️ <strong>Et une régression du point 1, trouvée et corrigée le même jour.</strong> <code>WeatherSyncService</code> écrit <code>section.WeatherResult</code> sur cron, à <strong>6 h et 13 h</strong>. Le job était bénin tant que les sections n'étaient pas auditées ; depuis, chaque rafraîchissement produisait une ligne portant la <strong>prévision OpenWeather complète en avant ET en après</strong> — quelques dizaines de Ko, deux fois par jour, par section météo. Le stockage est le moindre problème : <strong>ce bruit noie les modifications humaines</strong> que l'écran existe pour montrer. Correctif : colonnes machine (<code>WeatherResult</code>, <code>WeatherUpdatedDate</code>, <code>DateUpdate</code>) exclues du journal, et <strong>aucune ligne produite</strong> quand une modification ne touche qu'elles — plutôt qu'une ligne au diff vide, qui aurait déplacé le bruit sans le retirer. <code>DateUpdate</code> y est pour une raison distincte : estampillé à chaque <code>SaveChanges</code>, il figurait dans tous les diffs sans rien y apprendre — <strong>et le signal était déjà là</strong>, un test écrit le matin même devait l'écarter à la main pour rester lisible. <code>AgendaSyncService</code> vérifié au passage : il écrit des <code>EventAgenda</code>, non audités. ⚠️ <strong>Trouvé en cherchant à justifier un index sur <code>Timestamp</code> signalé par réflexe</strong> — la question « pourquoi un index ? » a montré que ce qui faisait grossir la table n'était pas ce que je croyais. <strong>L'index est retiré du backlog</strong> : pas de migration, gel du lot B intact. <code>dotnet test</code> <strong>203/203</strong>.</span>
+        <strong>Lot F côté manager-service : les quatre chantiers de dette backend, en une passe</strong>
+        <span><code>dotnet test</code> <strong>163 → 200</strong>, aucun test sauté, quatre commits, <code>manager-service</code> seul. <strong>1) Le journal d'audit voyait tout sauf le contenu</strong> : <code>AuditedTypes.Contains(entry.Entity.GetType())</code> exigeait l'égalité <strong>exacte</strong>, or <code>Section</code> est abstraite — aucune des 13 sortes de section n'était journalisée, soit précisément ce que l'écran du 12/08 devait tracer. <code>Resource</code>, <code>Configuration</code>, <code>Device</code>, <code>User</code> et <code>Instance</code> passaient, eux : ils sont concrets, <strong>et c'est ce qui rendait le trou invisible</strong>. <strong>Tranché : normalisation côté serveur</strong> — <code>EntityType</code> porte <code>Section</code>, donc le filtre déjà présent dans l'écran se met à rendre des lignes <strong>sans toucher <code>manager-app</code></strong> ; élargir le filtre front aurait coûté 13 entrées et 39 clés i18n <em>et</em> laissé tout futur sous-type sortir du filtre en silence — la classe de panne exacte qu'on ferme. Le sous-type n'est pas perdu : le discriminateur TPH est sérialisé dans <code>NewValues</code>, un test le vérifie. 8 tests, dont un <strong>par réflexion</strong> sur les 13 sous-types — la liste d'origine n'obligeait personne à la suivre, c'est ce qui l'a laissée devenir fausse.</span>
+        <span><strong>2) Plafond de 5 utilisateurs</strong> : <code>CreateUser</code> rend <strong>422</strong>. <strong>5 en dur</strong> (le faire varier par plan serait une colonne, donc une migration après le gel du lot B — dette V1 assumée) et <strong>SuperAdmin exempté</strong>, seule porte de service tant qu'aucun champ ne permet de relever la limite d'un client. Rien à retoucher côté front. <strong>3) <code>GetSummary</code> agrège en SQL</strong> au lieu de charger 13 mois en mémoire ; les six agrégats qui se lisent dans le JSON de <code>Metadata</code> ne remontent plus que <strong>deux colonnes</strong>, pour leur seul type d'événement, et les stats avancées ne sont plus calculées puis effacées pour les plans qui n'y ont pas droit. ⚠️ <strong>La branche « stats avancées » n'était couverte par aucun test</strong> : les cas existants ne seedent pas d'<code>Instance</code>, donc <code>hasAdvancedStats</code> était toujours faux et la moitié de la méthode n'était jamais exécutée.</span>
+        <span><strong>4) Le vector store est éprouvé à DEUX instances, sur un vrai Postgres</strong> — 14 tests Testcontainers sur l'image de <code>Dockerfile.postgres</code>, qui se sautent proprement sans démon Docker (186 passés / 14 sautés / 0 échec). pgvector <strong>0.8.6</strong> : le <code>SET hnsw.iterative_scan</code> que pose <code>SearchAsync</code> est accepté — sur une version antérieure, <strong>toute recherche échouait en production</strong>. À 30 contre 1, la recherche rend le bon nombre de résultats, tous de la bonne instance, aucune fuite. ⚠️ <strong>Deux résultats contraires à ce que le plan supposait</strong> : ce qui protège du post-filtrage <strong>n'est pas le parcours itératif mais l'index sur <code>(InstanceId, ContentType)</code></strong> — le planificateur filtre d'abord et trie exactement, l'index HNSW n'est jamais touché (vérifié à 620 lignes et à 22 000) ; et cet index retiré, <code>relaxed_order</code> <strong>ne rattrape rien</strong>, le parcours s'épuisant après ~335 lignes sans atteindre l'instance minoritaire. Le même jeu de données avec l'index HNSW construit <em>après</em> l'insertion rend bien ses 20 lignes : c'est la connectivité du graphe qui décide, et nos migrations créent l'index sur une table vide. <strong>Outillage</strong> : Testcontainers épinglé en 3.10.0 (la 4.x parle l'API Docker 1.44, l'engine local plafonne à 1.43) et image construite par le CLI docker — le constructeur de Testcontainers ne sait pas parser le <code>tag@sha256:</code> du Dockerfile, digest qui protège la base d'un changement de glibc sous ses index et ne se retire pas pour un test.</span>
+        <span>⚠️ <strong>Et une régression du point 1, trouvée et corrigée le même jour.</strong> <code>WeatherSyncService</code> écrit <code>section.WeatherResult</code> sur cron, à <strong>6 h et 13 h</strong>. Le job était bénin tant que les sections n'étaient pas auditées ; depuis, chaque rafraîchissement produisait une ligne portant la <strong>prévision OpenWeather complète en avant ET en après</strong> — quelques dizaines de Ko, deux fois par jour, par section météo. Le stockage est le moindre problème : <strong>ce bruit noie les modifications humaines</strong> que l'écran existe pour montrer. Correctif : colonnes machine (<code>WeatherResult</code>, <code>WeatherUpdatedDate</code>, <code>DateUpdate</code>) exclues du journal, et <strong>aucune ligne produite</strong> quand une modification ne touche qu'elles — plutôt qu'une ligne au diff vide, qui aurait déplacé le bruit sans le retirer. <code>DateUpdate</code> y est pour une raison distincte : estampillé à chaque <code>SaveChanges</code>, il figurait dans tous les diffs sans rien y apprendre — <strong>et le signal était déjà là</strong>, un test écrit le matin même devait l'écarter à la main pour rester lisible. <code>AgendaSyncService</code> vérifié au passage : il écrit des <code>EventAgenda</code>, non audités. ⚠️ <strong>Trouvé en cherchant à justifier un index sur <code>Timestamp</code> signalé par réflexe</strong> — la question « pourquoi un index ? » a montré que ce qui faisait grossir la table n'était pas ce que je croyais. <strong>L'index est retiré du backlog</strong> : pas de migration, gel du lot B intact. <code>dotnet test</code> <strong>203/203</strong>.</span>
       </div>
 
       <div class="done-item">
-        <strong>Écran d'audit log et compteur d'utilisateurs — le lot F côté manager-app</strong>
-        <span>Deux chantiers dans la même passe, <code>manager-app</code> seul. <strong>Écran « Activité »</strong> sur <code>GET /api/Audit</code> : filtres instance / type d'entité / utilisateur / plage de dates, pagination 50, clic sur une ligne → détail avant-après en table, entrée de menu réservée à <code>role.value == 0</code> comme la policy de l'endpoint. Les ids sont résolus en noms, un id inconnu restant affiché tel quel — le journal doit rester lisible après la disparition de ce qu'il décrit. <strong>Compteur « X / 5 utilisateurs »</strong> et bouton d'ajout désactivé au plafond, <strong>SuperAdmin exclu</strong> : sa liste couvre toutes les instances, la compter contre un plafond <em>par instance</em> n'aurait aucun sens. <strong><code>manager_api_new</code> n'a pas été touché</strong> — <code>http.get</code> direct au Bearer, comme le Guide IA : une lecture seule ne justifie pas d'étendre un client qui s'édite à la main. 40 clés i18n FR/EN/NL, <code>flutter build web</code> ✅. ⚠️ <strong>Trois pièges relevés en câblant</strong> : <code>AuditController</code> renvoie les entités <strong>brutes</strong>, pas un DTO ; <code>invokeAPI</code> <strong>ne lève pas</strong> sur code d'erreur et son résultat était ignoré, donc un e-mail déjà pris (409) ne produisait aucun message — corrigé ; et <code>DropdownButtonFormField</code> <strong>ne relit pas <code>initialValue</code></strong> sur reconstruction, donc « Réinitialiser les filtres » vidait la requête sans vider l'affichage — remplacé par un <code>DropdownButton</code> piloté. Les deux dettes serveur qu'il ouvre sont sur leur propre carte, en Planifié.</span>
+        <strong>Écran d'audit log et compteur d'utilisateurs — le lot F côté manager-app</strong>
+        <span>Deux chantiers dans la même passe, <code>manager-app</code> seul. <strong>Écran « Activité »</strong> sur <code>GET /api/Audit</code> : filtres instance / type d'entité / utilisateur / plage de dates, pagination 50, clic sur une ligne → détail avant-après en table, entrée de menu réservée à <code>role.value == 0</code> comme la policy de l'endpoint. Les ids sont résolus en noms, un id inconnu restant affiché tel quel — le journal doit rester lisible après la disparition de ce qu'il décrit. <strong>Compteur « X / 5 utilisateurs »</strong> et bouton d'ajout désactivé au plafond, <strong>SuperAdmin exclu</strong> : sa liste couvre toutes les instances, la compter contre un plafond <em>par instance</em> n'aurait aucun sens. <strong><code>manager_api_new</code> n'a pas été touché</strong> — <code>http.get</code> direct au Bearer, comme le Guide IA : une lecture seule ne justifie pas d'étendre un client qui s'édite à la main. 40 clés i18n FR/EN/NL, <code>flutter build web</code> ✅. ⚠️ <strong>Trois pièges relevés en câblant</strong> : <code>AuditController</code> renvoie les entités <strong>brutes</strong>, pas un DTO ; <code>invokeAPI</code> <strong>ne lève pas</strong> sur code d'erreur et son résultat était ignoré, donc un e-mail déjà pris (409) ne produisait aucun message — corrigé ; et <code>DropdownButtonFormField</code> <strong>ne relit pas <code>initialValue</code></strong> sur reconstruction, donc « Réinitialiser les filtres » vidait la requête sans vider l'affichage — remplacé par un <code>DropdownButton</code> piloté. Les deux dettes serveur qu'il ouvre sont sur leur propre carte, en Planifié.</span>
       </div>
 
       <div class="done-item">
-        <strong>Alerte de budget GCP posée</strong>
-        <span>Le bucket est en Europe : aucun quota gratuit, facturation dès le premier octet. L'alerte est posée dans la console GCP — rien à vérifier dans le code, et c'est la seule protection réelle contre une surprise de facture pendant les tests de charge du lot H.</span>
+        <strong>Alerte de budget GCP posée</strong>
+        <span>Le bucket est en Europe : aucun quota gratuit, facturation dès le premier octet. L'alerte est posée dans la console GCP — rien à vérifier dans le code, et c'est la seule protection réelle contre une surprise de facture pendant les tests de charge du lot H.</span>
       </div>
 
       <div class="done-item">
-        <strong>Le rattrapage d'indexation ne brûle plus le quota Gemini en boucle</strong>
-        <span><code>BackfillInstanceAsync</code> parcourait les sections d'une instance <em>en boucle dans un seul job</em>. Avec <code>[AutomaticRetry(Attempts = 2)]</code> posé sur la classe, un échec d'embedding à la 280ᵉ section faisait retenter le job entier par Hangfire — donc <strong>ré-embedder les 279 déjà indexées, deux fois</strong>. Des appels facturés pour rien, et autant de chances de retomber sur la limite de débit qui avait causé le premier échec. Elle met désormais en file <strong>un job par section</strong> : l'unité de reprise devient la section, <code>ReplaceAsync</code> la rend idempotente, et le chemin de backfill cesse d'être un chemin à part — c'est celui de l'intercepteur, déjà éprouvé. Effet de bord utile : l'avancement se lit section par section dans <code>/hangfire</code> au lieu d'un job opaque. Complété par un <strong>backoff sur 429/503</strong> dans <code>GoogleEmbeddingService</code> (3 tentatives, <code>Retry-After</code> s'il est fourni, exponentiel sinon), qui absorbe la rafale courte sans jamais remonter jusqu'à Hangfire. <code>dotnet test</code> 148/148. Découvert en préparant l'activation de l'IA sur MDLF et le Fort — deux instances Pro à doter à la main pour éprouver le post-filtrage HNSW sur 4 instances plutôt que 2.</span>
+        <strong>Le rattrapage d'indexation ne brûle plus le quota Gemini en boucle</strong>
+        <span><code>BackfillInstanceAsync</code> parcourait les sections d'une instance <em>en boucle dans un seul job</em>. Avec <code>[AutomaticRetry(Attempts = 2)]</code> posé sur la classe, un échec d'embedding à la 280ᵉ section faisait retenter le job entier par Hangfire — donc <strong>ré-embedder les 279 déjà indexées, deux fois</strong>. Des appels facturés pour rien, et autant de chances de retomber sur la limite de débit qui avait causé le premier échec. Elle met désormais en file <strong>un job par section</strong> : l'unité de reprise devient la section, <code>ReplaceAsync</code> la rend idempotente, et le chemin de backfill cesse d'être un chemin à part — c'est celui de l'intercepteur, déjà éprouvé. Effet de bord utile : l'avancement se lit section par section dans <code>/hangfire</code> au lieu d'un job opaque. Complété par un <strong>backoff sur 429/503</strong> dans <code>GoogleEmbeddingService</code> (3 tentatives, <code>Retry-After</code> s'il est fourni, exponentiel sinon), qui absorbe la rafale courte sans jamais remonter jusqu'à Hangfire. <code>dotnet test</code> 148/148. Découvert en préparant l'activation de l'IA sur MDLF et le Fort — deux instances Pro à doter à la main pour éprouver le post-filtrage HNSW sur 4 instances plutôt que 2.</span>
       </div>
 
       <div class="done-item">
-        <strong>La visite hors ligne embarque enfin ses médias</strong>
-        <span>Le <code>switch</code> qui collecte les ressources d'une configuration était commenté <strong>des deux côtés</strong> : 157 lignes mortes dans <code>ConfigurationController.Export</code>, 126 dans <code>Import</code>, et le pendant dans <code>downloadConfiguration.dart</code>. Une visite téléchargée n'embarquait donc que l'image de la configuration, celle du loader et l'image de chaque section — <strong>ni contenus d'articles, ni audios, ni icônes de carte, ni images de quiz</strong>. Remplacé par <code>GetReferencedResourceIds()</code>, qui existait déjà sur les 13 sous-types et n'attendait que d'être appelée. Côté import et côté client, la charge est enregistrée <em>en une passe</em> au lieu d'être redécouverte section par section : le serveur sait maintenant ce qu'il envoie, le client n'a plus à le deviner — et ça répare au passage la purge des fichiers obsolètes, pilotée par la même liste d'ids utilisés. 4 tests, dont un qui vérifie <strong>par réflexion que les 13 sous-types implémentent la collecte</strong> : le trou venait d'un <code>switch</code> où un type oublié passait dans le <code>default</code> sans bruit, et c'est exactement ce qu'il ne faut plus pouvoir refaire. <code>dotnet test</code> 148/148. ⚠️ Le volet visiteur ne tient que sur l'analyse — l'APK ne compile pas — <strong>confirmation sur device au §21</strong>, carte « Visite hors ligne sur device » déjà en attente.</span>
+        <strong>La visite hors ligne embarque enfin ses médias</strong>
+        <span>Le <code>switch</code> qui collecte les ressources d'une configuration était commenté <strong>des deux côtés</strong> : 157 lignes mortes dans <code>ConfigurationController.Export</code>, 126 dans <code>Import</code>, et le pendant dans <code>downloadConfiguration.dart</code>. Une visite téléchargée n'embarquait donc que l'image de la configuration, celle du loader et l'image de chaque section — <strong>ni contenus d'articles, ni audios, ni icônes de carte, ni images de quiz</strong>. Remplacé par <code>GetReferencedResourceIds()</code>, qui existait déjà sur les 13 sous-types et n'attendait que d'être appelée. Côté import et côté client, la charge est enregistrée <em>en une passe</em> au lieu d'être redécouverte section par section : le serveur sait maintenant ce qu'il envoie, le client n'a plus à le deviner — et ça répare au passage la purge des fichiers obsolètes, pilotée par la même liste d'ids utilisés. 4 tests, dont un qui vérifie <strong>par réflexion que les 13 sous-types implémentent la collecte</strong> : le trou venait d'un <code>switch</code> où un type oublié passait dans le <code>default</code> sans bruit, et c'est exactement ce qu'il ne faut plus pouvoir refaire. <code>dotnet test</code> 148/148. ⚠️ Le volet visiteur ne tient que sur l'analyse — l'APK ne compile pas — <strong>confirmation sur device au §21</strong>, carte « Visite hors ligne sur device » déjà en attente.</span>
       </div>
 
       <div class="done-item">
-        <strong>MigrationController — trois des huit écarts n'existaient pas</strong>
-        <span>Le plan les décrivait en « perte de données ». L'export Mongo, lu plutôt que supposé, dit qu'il n'y a rien à perdre. <strong>(a) « 11 types de section sur 13 »</strong> : les 327 sections de l'export ne contiennent que les types 0 à 10 — <code>SectionEvent</code> et <code>SectionParcours</code> sont nés avec Postgres v3, le <code>default</code> est un filet et non un trou, et le « scénario carnaval » qu'on croyait menacé est du contenu <em>à créer</em>, pas à migrer. <strong>(f) les trois booléens forcés à false</strong> : ces colonnes n'existent pas dans Mongo, <code>false</code> est le bon défaut — et le contrôle inverse a été fait, les cinq réglages qui <em>existent</em> vraiment dans l'export (<code>IsDate</code>, <code>IsHour</code>, <code>IsSectionImageBackground</code>, <code>RoundedValue</code>, <code>ScreenPercentageSectionsMainPage</code>) sont bien mappés sur <code>AppConfigurationLink</code>. <strong>(g)</strong> était tombé avec le rename du lot B. Trois cartes de la colonne « Bascule prod » se ferment sans une ligne de code.</span>
+        <strong>MigrationController — trois des huit écarts n'existaient pas</strong>
+        <span>Le plan les décrivait en « perte de données ». L'export Mongo, lu plutôt que supposé, dit qu'il n'y a rien à perdre. <strong>(a) « 11 types de section sur 13 »</strong> : les 327 sections de l'export ne contiennent que les types 0 à 10 — <code>SectionEvent</code> et <code>SectionParcours</code> sont nés avec Postgres v3, le <code>default</code> est un filet et non un trou, et le « scénario carnaval » qu'on croyait menacé est du contenu <em>à créer</em>, pas à migrer. <strong>(f) les trois booléens forcés à false</strong> : ces colonnes n'existent pas dans Mongo, <code>false</code> est le bon défaut — et le contrôle inverse a été fait, les cinq réglages qui <em>existent</em> vraiment dans l'export (<code>IsDate</code>, <code>IsHour</code>, <code>IsSectionImageBackground</code>, <code>RoundedValue</code>, <code>ScreenPercentageSectionsMainPage</code>) sont bien mappés sur <code>AppConfigurationLink</code>. <strong>(g)</strong> était tombé avec le rename du lot B. Trois cartes de la colonne « Bascule prod » se ferment sans une ligne de code.</span>
       </div>
 
       <div class="done-item">
-        <strong>MigrationController — les cinq écarts réels, corrigés</strong>
-        <span><strong>(b)</strong> <code>QuizQuestions = new()</code> jetait les questions : mesuré sur l'export, <strong>5 sections quiz en portent 41</strong>, réponses comprises. Migrées, en <code>MultipleChoice</code> puisque le type de validation n'existait pas dans l'ancien modèle. Les agendas (aucun événement dans Mongo) et les parcours (inexistants avant) gardent leurs collections vides à raison. <strong>(d)</strong> était pire que décrit : Mongo <strong>n'a pas de champ Role</strong>, donc les 10 utilisateurs y avaient un accès complet, et le <code>ContentEditor</code> en dur les dégradait <em>tous</em> en silence — plus personne n'aurait pu gérer les utilisateurs de son instance. Passé à <code>InstanceAdmin</code> ; aucun SuperAdmin n'est créé par la migration, à poser à la main. <strong>(c)</strong> tout est généré ou dérivé, la source ne contenant que 4 champs. <strong>(e)</strong> <code>StoragePath</code> n'était pas écrit du tout : passe par le calculateur commun, et l'échec du <code>HEAD</code>, jusqu'ici avalé, remonte dans le rapport. <strong>(h)</strong> transaction unique, et surtout <strong>500 au lieu de 200 OK</strong> sur échec fatal — le piège était qu'un script de bascule testant le code HTTP concluait au succès. <code>dotnet test</code> 143/143.</span>
+        <strong>MigrationController — les cinq écarts réels, corrigés</strong>
+        <span><strong>(b)</strong> <code>QuizQuestions = new()</code> jetait les questions : mesuré sur l'export, <strong>5 sections quiz en portent 41</strong>, réponses comprises. Migrées, en <code>MultipleChoice</code> puisque le type de validation n'existait pas dans l'ancien modèle. Les agendas (aucun événement dans Mongo) et les parcours (inexistants avant) gardent leurs collections vides à raison. <strong>(d)</strong> était pire que décrit : Mongo <strong>n'a pas de champ Role</strong>, donc les 10 utilisateurs y avaient un accès complet, et le <code>ContentEditor</code> en dur les dégradait <em>tous</em> en silence — plus personne n'aurait pu gérer les utilisateurs de son instance. Passé à <code>InstanceAdmin</code> ; aucun SuperAdmin n'est créé par la migration, à poser à la main. <strong>(c)</strong> tout est généré ou dérivé, la source ne contenant que 4 champs. <strong>(e)</strong> <code>StoragePath</code> n'était pas écrit du tout : passe par le calculateur commun, et l'échec du <code>HEAD</code>, jusqu'ici avalé, remonte dans le rapport. <strong>(h)</strong> transaction unique, et surtout <strong>500 au lieu de 200 OK</strong> sur échec fatal — le piège était qu'un script de bascule testant le code HTTP concluait au succès. <code>dotnet test</code> 143/143.</span>
       </div>
 
       <div class="done-item">
-        <strong>Le schéma est gelé — lot B, et le lot G peut enfin commencer</strong>
-        <span>Le point d'articulation du plan : tant qu'un changement de modèle restait ouvert, réécrire <code>MigrationController</code> revenait à l'écrire deux fois. <strong>Une seule migration EF</strong> porte les trois changements. <code>SectionMap.MapResourceId</code> → <code>IconResourceId</code>, ce qui fait tomber l'<strong>écart (g)</strong> de la bascule tout seul — et il fallait renommer la propriété de navigation <code>MapResource</code> avec, sinon la convention EF fabriquait un FK fantôme. Point vérifié plutôt que supposé : EF a produit un <code>RenameColumn</code>, <em>pas</em> un drop+add — les icônes déjà configurées survivent. <code>SectionEvent.ParcoursIds</code> supprimé (l'avertissement de perte de données d'EF ne porte que sur lui, c'est l'intention). Filigrane : <code>Instance.IsImageWatermark</code> remplace le <code>instanceId == "633ee379…"</code> en dur. <strong>Référence tenue : 130/130 tests avant comme après</strong>, build Debug <em>et</em> Release verts.</span>
+        <strong>Le schéma est gelé — lot B, et le lot G peut enfin commencer</strong>
+        <span>Le point d'articulation du plan : tant qu'un changement de modèle restait ouvert, réécrire <code>MigrationController</code> revenait à l'écrire deux fois. <strong>Une seule migration EF</strong> porte les trois changements. <code>SectionMap.MapResourceId</code> → <code>IconResourceId</code>, ce qui fait tomber l'<strong>écart (g)</strong> de la bascule tout seul — et il fallait renommer la propriété de navigation <code>MapResource</code> avec, sinon la convention EF fabriquait un FK fantôme. Point vérifié plutôt que supposé : EF a produit un <code>RenameColumn</code>, <em>pas</em> un drop+add — les icônes déjà configurées survivent. <code>SectionEvent.ParcoursIds</code> supprimé (l'avertissement de perte de données d'EF ne porte que sur lui, c'est l'intention). Filigrane : <code>Instance.IsImageWatermark</code> remplace le <code>instanceId == "633ee379…"</code> en dur. <strong>Référence tenue : 130/130 tests avant comme après</strong>, build Debug <em>et</em> Release verts.</span>
       </div>
 
       <div class="done-item">
         <strong>Le backdoor d'authentification, et deux fuites de moins</strong>
-        <span>Trouvé en cherchant le « backdoor <code>#if DEBUG</code> » du rapport d'audit : dans <code>AuthenticationController.Authenticate</code>, un bloc <strong>écrasait l'email et le mot de passe reçus</strong> par un compte de test — toute compilation en Debug authentifiait n'importe quelle saisie en tant que <code>test@email.be</code>. Retiré. <code>EnableSensitiveDataLogging</code> (qui écrit les valeurs des paramètres dans les logs : hashes, clés API, données de visiteurs) passe sous <code>#if DEBUG</code>, l'idiome déjà employé dans ce même fichier pour le CORS et Hangfire — et le Dockerfile publiant en <code>-c Release</code>, c'est un vrai verrou, ce qu'un build Release a confirmé. Les autres <code>#if DEBUG</code> du repo sont légitimes.</span>
+        <span>Trouvé en cherchant le « backdoor <code>#if DEBUG</code> » du rapport d'audit : dans <code>AuthenticationController.Authenticate</code>, un bloc <strong>écrasait l'email et le mot de passe reçus</strong> par un compte de test — toute compilation en Debug authentifiait n'importe quelle saisie en tant que <code>test@email.be</code>. Retiré. <code>EnableSensitiveDataLogging</code> (qui écrit les valeurs des paramètres dans les logs : hashes, clés API, données de visiteurs) passe sous <code>#if DEBUG</code>, l'idiome déjà employé dans ce même fichier pour le CORS et Hangfire — et le Dockerfile publiant en <code>-c Release</code>, c'est un vrai verrou, ce qu'un build Release a confirmé. Les autres <code>#if DEBUG</code> du repo sont légitimes.</span>
       </div>
 
       <div class="done-item">
-        <strong>Le client généré nettoyé — et la règle « pas de régénération » enfin verrouillée</strong>
-        <span>Le compte exact : <code>api.dart</code> déclarait <strong>139 <code>part</code> pour 153 fichiers</strong>. Les 14 restants portaient <code>part of openapi.api;</code> sans être listés par leur bibliothèque — en Dart, <strong>hors du graphe de compilation</strong> : l'analyzer les lisait, le compilateur ne les voyait jamais. Toute l'asymétrie qui a coûté du temps était là, et avec elle la garantie que les supprimer ne pouvait pas casser un build. Mesuré : <code>flutter analyze</code> sur le package passe de <strong>67 à 3 issues</strong>, et l'analyse globale de manager-app de <em>68 erreurs de bruit</em> à <strong>3 erreurs</strong>, toutes dans <code>test/widget_test.dart</code> (cassé et connu) — <code>flutter analyze</code> redevient un feu vert utilisable, ce qui débloque les lots design. <code>flutter build web</code> ✅ avant comme après.</span>
+        <strong>Le client généré nettoyé — et la règle « pas de régénération » enfin verrouillée</strong>
+        <span>Le compte exact : <code>api.dart</code> déclarait <strong>139 <code>part</code> pour 153 fichiers</strong>. Les 14 restants portaient <code>part of openapi.api;</code> sans être listés par leur bibliothèque — en Dart, <strong>hors du graphe de compilation</strong> : l'analyzer les lisait, le compilateur ne les voyait jamais. Toute l'asymétrie qui a coûté du temps était là, et avec elle la garantie que les supprimer ne pouvait pas casser un build. Mesuré : <code>flutter analyze</code> sur le package passe de <strong>67 à 3 issues</strong>, et l'analyse globale de manager-app de <em>68 erreurs de bruit</em> à <strong>3 erreurs</strong>, toutes dans <code>test/widget_test.dart</code> (cassé et connu) — <code>flutter analyze</code> redevient un feu vert utilisable, ce qui débloque les lots design. <code>flutter build web</code> ✅ avant comme après.</span>
       </div>
 
       <div class="done-item">
-        <strong>Trois déclencheurs de génération, pas un</strong>
-        <span>Le verrou ne tenait que dans manager-app. <code>mymuseum-visitapp/lib/api/openApiTest.dart</code> générait depuis <strong>son propre swagger</strong> vers un <code>manager_api_new</code> local — un second client divergent dans un repo qui consomme celui de manager-app par <code>path:</code> — et <code>tablet-app/lib/api/openApi.dart</code> faisait de même sous un autre nom de fichier, ce qui lui avait permis d'échapper à toutes les recherches sur « openApiTest ». Plus un résidu <code>tablet-app/manager_api_new/</code> réduit à un <code>pubspec.lock</code>, non suivi par git, daté d'avril. Les trois sont supprimés : ce ne sont pas des fichiers morts, c'était <em>le moyen d'écraser les éditions manuelles</em> — <code>onboarding_api.dart</code>, le câblage d'<code>AIApi</code>, le mapping <code>isGood</code> → <code>isCorrect</code>. Contrôle de non-régression : <code>grep -rl "@Openapi" */lib</code> doit rester vide.</span>
+        <strong>Trois déclencheurs de génération, pas un</strong>
+        <span>Le verrou ne tenait que dans manager-app. <code>mymuseum-visitapp/lib/api/openApiTest.dart</code> générait depuis <strong>son propre swagger</strong> vers un <code>manager_api_new</code> local — un second client divergent dans un repo qui consomme celui de manager-app par <code>path:</code> — et <code>tablet-app/lib/api/openApi.dart</code> faisait de même sous un autre nom de fichier, ce qui lui avait permis d'échapper à toutes les recherches sur « openApiTest ». Plus un résidu <code>tablet-app/manager_api_new/</code> réduit à un <code>pubspec.lock</code>, non suivi par git, daté d'avril. Les trois sont supprimés : ce ne sont pas des fichiers morts, c'était <em>le moyen d'écraser les éditions manuelles</em> — <code>onboarding_api.dart</code>, le câblage d'<code>AIApi</code>, le mapping <code>isGood</code> → <code>isCorrect</code>. Contrôle de non-régression : <code>grep -rl "@Openapi" */lib</code> doit rester vide.</span>
       </div>
 
       <div class="done-item">
-        <strong>Fournisseur de carte en web — tranché, et pas comme prévu</strong>
-        <span>Option a retenue : <strong>le web reste sur Leaflet quoi que le client configure</strong>. Ni MapBox (token payant) ni Google Maps JS (clé facturée + seconde librairie carto à maintenir) — aucun coût récurrent ajouté avant la prod. Mais l'option annoncée disait « retirer le champ pour les instances web », et <strong>c'est impossible</strong> : le fournisseur est porté par la <em>section</em> (<code>SectionMap.MapMapProvider</code>, <code>SectionAgenda.AgendaMapProvider</code>), pas par l'instance — et une même Configuration est liée à plusieurs <code>ApplicationInstance</code> via <code>AppConfigurationLink</code>, donc servie au mobile <em>comme</em> au web. Masquer le champ aurait supprimé le réglage mobile. Il est donc conservé, et manager-app <strong>cesse de laisser croire qu'il vaut pour le web</strong> : mention explicite sous les deux sélecteurs. Zéro ligne côté visitapp-web — Leaflet inconditionnel était déjà le comportement ; ce qui manquait n'était pas du code mais une phrase honnête dans l'interface.</span>
+        <strong>Fournisseur de carte en web — tranché, et pas comme prévu</strong>
+        <span>Option a retenue : <strong>le web reste sur Leaflet quoi que le client configure</strong>. Ni MapBox (token payant) ni Google Maps JS (clé facturée + seconde librairie carto à maintenir) — aucun coût récurrent ajouté avant la prod. Mais l'option annoncée disait « retirer le champ pour les instances web », et <strong>c'est impossible</strong> : le fournisseur est porté par la <em>section</em> (<code>SectionMap.MapMapProvider</code>, <code>SectionAgenda.AgendaMapProvider</code>), pas par l'instance — et une même Configuration est liée à plusieurs <code>ApplicationInstance</code> via <code>AppConfigurationLink</code>, donc servie au mobile <em>comme</em> au web. Masquer le champ aurait supprimé le réglage mobile. Il est donc conservé, et manager-app <strong>cesse de laisser croire qu'il vaut pour le web</strong> : mention explicite sous les deux sélecteurs. Zéro ligne côté visitapp-web — Leaflet inconditionnel était déjà le comportement ; ce qui manquait n'était pas du code mais une phrase honnête dans l'interface.</span>
       </div>
 
       <div class="done-item">
-        <strong>PDF en média d'étape — et le dispatcher qui n'était pas le bon</strong>
-        <span>Les trois volets sont faits. La liste de types du sélecteur de médias devient un paramètre : l'étape passe désormais « types du slider + PDF » là où c'était figé en dur. Côté web, le cas PDF réutilise le <code>PdfViewer</code> existant <em>et</em> son proxy <code>/api/pdf</code> — le contournement CORS était déjà écrit, il n'y avait qu'à le brancher. <strong>Côté Flutter, la carte indiquait le mauvais endroit</strong> : <code>showElementForResource</code> fait un <code>return CachedCustomResource(...)</code> <em>avant</em> son <code>switch</code>, donc tout ce switch est du code mort depuis un moment — ajouter le cas PDF là n'aurait rien changé et aurait été « vérifié » sans rien prouver. Le vrai dispatcher est <code>CachedCustomResource</code>, et il a <strong>deux</strong> switch (ressource distante / fichier déjà téléchargé pour l'offline) qui tombaient tous deux sur <code>Text("Not supported type")</code> : les deux sont traités, le distant devant télécharger avant d'afficher puisque <code>PDFView</code> n'accepte qu'un chemin de fichier. Au passage : l'enum du client s'appelle <code>ResourceType.Pdf</code>, pas <code>PDF</code>. <code>npm run build</code> ✅, <code>flutter build web</code> ✅ — le volet mymuseum ne tient que sur l'analyse, son APK ne compilant pas.</span>
+        <strong>PDF en média d'étape — et le dispatcher qui n'était pas le bon</strong>
+        <span>Les trois volets sont faits. La liste de types du sélecteur de médias devient un paramètre : l'étape passe désormais « types du slider + PDF » là où c'était figé en dur. Côté web, le cas PDF réutilise le <code>PdfViewer</code> existant <em>et</em> son proxy <code>/api/pdf</code> — le contournement CORS était déjà écrit, il n'y avait qu'à le brancher. <strong>Côté Flutter, la carte indiquait le mauvais endroit</strong> : <code>showElementForResource</code> fait un <code>return CachedCustomResource(...)</code> <em>avant</em> son <code>switch</code>, donc tout ce switch est du code mort depuis un moment — ajouter le cas PDF là n'aurait rien changé et aurait été « vérifié » sans rien prouver. Le vrai dispatcher est <code>CachedCustomResource</code>, et il a <strong>deux</strong> switch (ressource distante / fichier déjà téléchargé pour l'offline) qui tombaient tous deux sur <code>Text("Not supported type")</code> : les deux sont traités, le distant devant télécharger avant d'afficher puisque <code>PDFView</code> n'accepte qu'un chemin de fichier. Au passage : l'enum du client s'appelle <code>ResourceType.Pdf</code>, pas <code>PDF</code>. <code>npm run build</code> ✅, <code>flutter build web</code> ✅ — le volet mymuseum ne tient que sur l'analyse, son APK ne compilant pas.</span>
       </div>
 
       <div class="done-item">
-        <strong>QuestionType — la fin des comparaisons par entier brut</strong>
-        <span>Descendu du lot B, où il ne restait plus qu'une propreté de front. La cause était dans le client généré : le générateur nomme les valeurs <code>number0/1/2</code>, et le front finissait donc par écrire <code>?.value == 2 ? 'Puzzle' : …</code> — lisible seulement si l'on connaît l'ordre de l'enum serveur par cœur. Des alias nommés d'après le serveur (<code>simple</code>, <code>multipleChoice</code>, <code>puzzle</code>) sont ajoutés à la main dans <code>question_type.dart</code>, sans toucher à <code>values</code> : ce sont les mêmes trois valeurs, pas de nouvelles. Les deux sites visés par le plan sont corrigés, plus les 7 usages <code>number*</code> du dialogue de question — il ne reste <strong>aucun</strong> <code>QuestionType.number</code> dans les trois apps.</span>
+        <strong>QuestionType — la fin des comparaisons par entier brut</strong>
+        <span>Descendu du lot B, où il ne restait plus qu'une propreté de front. La cause était dans le client généré : le générateur nomme les valeurs <code>number0/1/2</code>, et le front finissait donc par écrire <code>?.value == 2 ? 'Puzzle' : …</code> — lisible seulement si l'on connaît l'ordre de l'enum serveur par cœur. Des alias nommés d'après le serveur (<code>simple</code>, <code>multipleChoice</code>, <code>puzzle</code>) sont ajoutés à la main dans <code>question_type.dart</code>, sans toucher à <code>values</code> : ce sont les mêmes trois valeurs, pas de nouvelles. Les deux sites visés par le plan sont corrigés, plus les 7 usages <code>number*</code> du dialogue de question — il ne reste <strong>aucun</strong> <code>QuestionType.number</code> dans les trois apps.</span>
       </div>
 
       <div class="done-item">
-        <strong>Parcours — on ne perd plus son travail sans être averti</strong>
-        <span>Le défaut était pire que décrit : <strong>trois</strong> dialogues faisaient <code>Navigator.pop</code> sur « Annuler » sans rien demander, pas un — Parcours, Étape et Question, chacun jetant tout ce qui était saisi <em>sous</em> lui. Le plus coûteux est le plus profond : une question de quiz avec ses réponses. Ce n'était pas « la croix » comme le disait cette carte, c'était le bouton Annuler, et le clic hors fenêtre était déjà neutralisé — le vrai chemin de perte restant est le <strong>retour arrière du navigateur</strong>, couvert par <code>PopScope</code>. Détection des modifications par instantané JSON, pris <strong>après la première frame</strong> : le dialog Question normalise ses réponses pendant sa construction, un instantané pris avant aurait déclaré « modifié » une fenêtre intacte. Réutilise <code>showConfirmationDialog</code> plutôt que d'ouvrir un second composant de confirmation. 3 clés i18n FR/EN/NL, <code>flutter build web</code> ✅. <strong>Retiré le jour même par la carte suivante</strong> — c'était l'issue prévue : un garde-fou n'a plus d'objet quand il n'y a plus rien à perdre.</span>
+        <strong>Parcours — on ne perd plus son travail sans être averti</strong>
+        <span>Le défaut était pire que décrit : <strong>trois</strong> dialogues faisaient <code>Navigator.pop</code> sur « Annuler » sans rien demander, pas un — Parcours, Étape et Question, chacun jetant tout ce qui était saisi <em>sous</em> lui. Le plus coûteux est le plus profond : une question de quiz avec ses réponses. Ce n'était pas « la croix » comme le disait cette carte, c'était le bouton Annuler, et le clic hors fenêtre était déjà neutralisé — le vrai chemin de perte restant est le <strong>retour arrière du navigateur</strong>, couvert par <code>PopScope</code>. Détection des modifications par instantané JSON, pris <strong>après la première frame</strong> : le dialog Question normalise ses réponses pendant sa construction, un instantané pris avant aurait déclaré « modifié » une fenêtre intacte. Réutilise <code>showConfirmationDialog</code> plutôt que d'ouvrir un second composant de confirmation. 3 clés i18n FR/EN/NL, <code>flutter build web</code> ✅. <strong>Retiré le jour même par la carte suivante</strong> — c'était l'issue prévue : un garde-fou n'a plus d'objet quand il n'y a plus rien à perdre.</span>
       </div>
 
       <div class="done-item">
-        <strong>Parcours — les quatre fenêtres empilées deviennent une seule</strong>
-        <span>Option A livrée, l'arbitrage tombe avec. Les trois <code>showNewOrUpdate…</code> sont supprimés au profit d'un <strong>rail d'étapes toujours visible</strong> à gauche, d'un panneau de détail à droite, et d'une question qui <strong>se déplie sur place</strong> au lieu d'ouvrir une quatrième fenêtre : la profondeur maximale retombe à <strong>2</strong> — l'éditeur, puis la traduction. Les champs sont d'abord sortis en trois widgets autonomes (<code>ParcoursFields</code>, <code>EtapeFields</code>, <code>QuestionFields</code>) — c'est ce qui a rendu la refonte possible sans tout réécrire, et ce qui resterait transposable si l'écran plein cadre revenait un jour.</span>
-        <span><strong>Plus de bouton « Sauvegarder » : tout part à la saisie</strong> (débounce 700 ms ; les ajouts, suppressions et réordonnancements partent sans attendre). Deux pièges du backend, trouvés en lisant le contrôleur plutôt qu'en le supposant : <code>UpdateGuidedPath</code> <strong>supprime les étapes absentes du DTO</strong>, donc le payload n'emporte que celles qui ont déjà un id — les autres attendent leur <code>CreateGuidedStep</code> et seraient dupliquées ; et comme les questions n'ont <em>pas</em> d'endpoint propre (c'est voulu, elles partent avec leur étape), leur id entier est récupéré après coup <strong>par <code>order</code></strong>, seul repère stable entre la liste locale et celle du serveur. Le parcours est créé <strong>à la première modification</strong>, pas à l'ouverture : une fenêtre neuve refermée intacte ne laisse rien en base. Si une écriture échoue, la fenêtre refuse de se fermer et le pied de page porte un « Réessayer ». 14 clés i18n FR/EN/NL, 3 retirées, <code>flutter build web</code> ✅. <strong>Reste la vérification à l'œil</strong> (DB5).</span>
+        <strong>Parcours — les quatre fenêtres empilées deviennent une seule</strong>
+        <span>Option A livrée, l'arbitrage tombe avec. Les trois <code>showNewOrUpdate…</code> sont supprimés au profit d'un <strong>rail d'étapes toujours visible</strong> à gauche, d'un panneau de détail à droite, et d'une question qui <strong>se déplie sur place</strong> au lieu d'ouvrir une quatrième fenêtre : la profondeur maximale retombe à <strong>2</strong> — l'éditeur, puis la traduction. Les champs sont d'abord sortis en trois widgets autonomes (<code>ParcoursFields</code>, <code>EtapeFields</code>, <code>QuestionFields</code>) — c'est ce qui a rendu la refonte possible sans tout réécrire, et ce qui resterait transposable si l'écran plein cadre revenait un jour.</span>
+        <span><strong>Plus de bouton « Sauvegarder » : tout part à la saisie</strong> (débounce 700 ms ; les ajouts, suppressions et réordonnancements partent sans attendre). Deux pièges du backend, trouvés en lisant le contrôleur plutôt qu'en le supposant : <code>UpdateGuidedPath</code> <strong>supprime les étapes absentes du DTO</strong>, donc le payload n'emporte que celles qui ont déjà un id — les autres attendent leur <code>CreateGuidedStep</code> et seraient dupliquées ; et comme les questions n'ont <em>pas</em> d'endpoint propre (c'est voulu, elles partent avec leur étape), leur id entier est récupéré après coup <strong>par <code>order</code></strong>, seul repère stable entre la liste locale et celle du serveur. Le parcours est créé <strong>à la première modification</strong>, pas à l'ouverture : une fenêtre neuve refermée intacte ne laisse rien en base. Si une écriture échoue, la fenêtre refuse de se fermer et le pied de page porte un « Réessayer ». 14 clés i18n FR/EN/NL, 3 retirées, <code>flutter build web</code> ✅. <strong>Reste la vérification à l'œil</strong> (DB5).</span>
       </div>
 
       <div class="done-item">
-        <strong>Plus rien sur un seul disque — les 9 repos sont propres</strong>
-        <span>La carte la plus ancienne de la colonne « Urgent » se referme. L'alerte du 09/08 (« rien depuis le 17/07 », 75 + 40 + 14 + 4 fichiers) avait déjà été révisée le matin du 11/08 en « ~41 fichiers dont 9 non suivis » ; <strong>les deux versions sont maintenant périmées</strong>. Vérifié au <code>git status --porcelain</code> sur les huit repos : vide partout, et aucun <code>ahead</code>/<code>behind</code> face au remote. Le lot 3 RAG est dans <code>18e4240</code>, le socle visuel et l'écran Guide IA dans <code>eb8e849</code>. Ce qui rendait le point urgent — neuf fichiers non suivis qui n'existaient nulle part ailleurs et disparaissaient au premier <code>git checkout</code> — n'existe plus. À ne pas re-planifier : c'était l'étape 1 du lot A.</span>
+        <strong>Plus rien sur un seul disque — les 9 repos sont propres</strong>
+        <span>La carte la plus ancienne de la colonne « Urgent » se referme. L'alerte du 09/08 (« rien depuis le 17/07 », 75 + 40 + 14 + 4 fichiers) avait déjà été révisée le matin du 11/08 en « ~41 fichiers dont 9 non suivis » ; <strong>les deux versions sont maintenant périmées</strong>. Vérifié au <code>git status --porcelain</code> sur les huit repos : vide partout, et aucun <code>ahead</code>/<code>behind</code> face au remote. Le lot 3 RAG est dans <code>18e4240</code>, le socle visuel et l'écran Guide IA dans <code>eb8e849</code>. Ce qui rendait le point urgent — neuf fichiers non suivis qui n'existaient nulle part ailleurs et disparaissaient au premier <code>git checkout</code> — n'existe plus. À ne pas re-planifier : c'était l'étape 1 du lot A.</span>
       </div>
 
       <div class="done-item">
         <strong>Les maquettes sortent du compte Claude et entrent dans le repo</strong>
-        <span>Cause diagnostiquée d'un défaut qui se répétait : les trois maquettes vivaient dans des artifacts d'un <strong>autre compte</strong>, illisibles depuis la machine de dev — chaque session redessinait. D'où un écran Guide IA « livré » à la moitié de sa spec et des stats d'assistant à zéro. Le HTML est rapatrié dans <code>claude design/</code>, JS interactif compris. Même découpage que ce tableau : <strong>contenu dans le repo, diffusion par artifact</strong>. Constat en ouvrant les fichiers : Guide IA et Statistiques déclarent des tokens <strong>rigoureusement identiques</strong> — c'était déjà un design system, jamais porté en Dart — et <code>--brand #264863</code> <em>est</em> <code>kPrimaryColor</code>.</span>
+        <span>Cause diagnostiquée d'un défaut qui se répétait : les trois maquettes vivaient dans des artifacts d'un <strong>autre compte</strong>, illisibles depuis la machine de dev — chaque session redessinait. D'où un écran Guide IA « livré » à la moitié de sa spec et des stats d'assistant à zéro. Le HTML est rapatrié dans <code>claude design/</code>, JS interactif compris. Même découpage que ce tableau : <strong>contenu dans le repo, diffusion par artifact</strong>. Constat en ouvrant les fichiers : Guide IA et Statistiques déclarent des tokens <strong>rigoureusement identiques</strong> — c'était déjà un design system, jamais porté en Dart — et <code>--brand #264863</code> <em>est</em> <code>kPrimaryColor</code>.</span>
       </div>
 
       <div class="done-item">
-        <strong>Socle visuel — 11 tailles de police deviennent 11 rôles</strong>
-        <span>Mesuré dans <code>lib/Components/</code> : onze tailles différentes (9 à 25 px), aucune échelle, <code>constants.dart</code> portant encore <code>// TO FILL WITH CORRECT COLOR</code> et deux styles. L'échelle, les espacements et les rayons sont extraits du CSS des maquettes ; <strong>les couleurs restent celles de l'app</strong> — un écran neuf se fond dans manager-app, il n'y ouvre pas une seconde palette. Seules les valeurs sans équivalent existant sont reprises : remplissages discrets, bordures, gris atténué, ambre. Pas de thème sombre. La reprise des écrans existants reste son propre chantier, pas un effet de bord.</span>
+        <strong>Socle visuel — 11 tailles de police deviennent 11 rôles</strong>
+        <span>Mesuré dans <code>lib/Components/</code> : onze tailles différentes (9 à 25 px), aucune échelle, <code>constants.dart</code> portant encore <code>// TO FILL WITH CORRECT COLOR</code> et deux styles. L'échelle, les espacements et les rayons sont extraits du CSS des maquettes ; <strong>les couleurs restent celles de l'app</strong> — un écran neuf se fond dans manager-app, il n'y ouvre pas une seconde palette. Seules les valeurs sans équivalent existant sont reprises : remplissages discrets, bordures, gris atténué, ambre. Pas de thème sombre. La reprise des écrans existants reste son propre chantier, pas un effet de bord.</span>
       </div>
 
       <div class="done-item">
-        <strong>Écran Guide IA — la coquille à onglets, et ce que le guide sait vraiment</strong>
-        <span>L'écran passe de cinq cartes en colonne à la structure de la maquette : deux onglets, deux colonnes. <strong>L'aperçu de conversation interroge le vrai <code>/api/AI/chat</code></strong>, pas une simulation — au passage, <code>AIApi</code> était dans le client généré mais <strong>exposé nulle part</strong> dans <code>client.dart</code>, où les 18 autres façades sont. Câblé. Nouveau <code>GET /api/Ai/knowledge/{id}</code> pour la carte « Ce que connaît votre guide » : tout est agrégé sur <code>ContentEmbedding</code>, donc sur ce qui est <em>réellement indexé</em> — compter les sections publiées donnerait un chiffre plus flatteur et faux, une section désactivée étant purgée de l'index. Le « points d'intérêt » de la maquette devient « morceaux de contenu » : les points d'une carte sont indexés dans le texte de leur SectionMap, les compter à part répondrait à une autre question. 34 clés i18n FR/EN/NL, <code>dotnet test</code> 130/130, <code>flutter build web</code> ✅.</span>
+        <strong>Écran Guide IA — la coquille à onglets, et ce que le guide sait vraiment</strong>
+        <span>L'écran passe de cinq cartes en colonne à la structure de la maquette : deux onglets, deux colonnes. <strong>L'aperçu de conversation interroge le vrai <code>/api/AI/chat</code></strong>, pas une simulation — au passage, <code>AIApi</code> était dans le client généré mais <strong>exposé nulle part</strong> dans <code>client.dart</code>, où les 18 autres façades sont. Câblé. Nouveau <code>GET /api/Ai/knowledge/{id}</code> pour la carte « Ce que connaît votre guide » : tout est agrégé sur <code>ContentEmbedding</code>, donc sur ce qui est <em>réellement indexé</em> — compter les sections publiées donnerait un chiffre plus flatteur et faux, une section désactivée étant purgée de l'index. Le « points d'intérêt » de la maquette devient « morceaux de contenu » : les points d'une carte sont indexés dans le texte de leur SectionMap, les compter à part répondrait à une autre question. 34 clés i18n FR/EN/NL, <code>dotnet test</code> 130/130, <code>flutter build web</code> ✅.</span>
       </div>
 
       <div class="done-item">
         <strong>Le changement de plan donne enfin ce qu'il vend</strong>
-        <span>Trois défauts qui se tenaient la main. <strong>1)</strong> <code>Updateinstance</code> changeait <code>SubscriptionPlanId</code> mais ne recopiait jamais les quotas du nouveau plan — <code>CreateInstance</code> le faisait, pas lui : passer un client de Starter à Premium ne lui donnait ni stockage ni jetons IA. <strong>2)</strong> <code>CheckQuota</code> ne bloquait que si <code>quota &gt; 0</code> : à 0 jeton, <strong>ni blocage ni compteur</strong> — l'ambiguïté vient du code lui-même, où <code>0</code> veut dire <em>illimité</em> pour le stockage et <em>pas d'IA</em> pour les jetons. Une instance Starter avec <code>IsAssistant</code> à true consommait donc gratuitement et sans compteur, et <strong>toute instance migrée depuis Mongo arrive à 0</strong> (écart c du §1quinquies). Corrigé en 403 avant tout appel au modèle. <strong>3)</strong> <code>BackfillInstanceAsync</code> n'était appelé par personne : branché automatiquement quand <code>AiTokensPerMonth</code> passe de 0 à une valeur, plus un bouton de relance <strong>réservé au SuperAdmin</strong> dans l'écran Guide IA — outil de réparation, pas fonctionnalité : exposé au client il serait cliqué à chaque réponse décevante, pour un coût d'embedding complet et sans rien améliorer. <code>IBackgroundJobClient</code> injecté au lieu de la façade statique, qui lève sans <code>JobStorage</code> et cassait les tests. 130/130.</span>
+        <span>Trois défauts qui se tenaient la main. <strong>1)</strong> <code>Updateinstance</code> changeait <code>SubscriptionPlanId</code> mais ne recopiait jamais les quotas du nouveau plan — <code>CreateInstance</code> le faisait, pas lui : passer un client de Starter à Premium ne lui donnait ni stockage ni jetons IA. <strong>2)</strong> <code>CheckQuota</code> ne bloquait que si <code>quota &gt; 0</code> : à 0 jeton, <strong>ni blocage ni compteur</strong> — l'ambiguïté vient du code lui-même, où <code>0</code> veut dire <em>illimité</em> pour le stockage et <em>pas d'IA</em> pour les jetons. Une instance Starter avec <code>IsAssistant</code> à true consommait donc gratuitement et sans compteur, et <strong>toute instance migrée depuis Mongo arrive à 0</strong> (écart c du §1quinquies). Corrigé en 403 avant tout appel au modèle. <strong>3)</strong> <code>BackfillInstanceAsync</code> n'était appelé par personne : branché automatiquement quand <code>AiTokensPerMonth</code> passe de 0 à une valeur, plus un bouton de relance <strong>réservé au SuperAdmin</strong> dans l'écran Guide IA — outil de réparation, pas fonctionnalité : exposé au client il serait cliqué à chaque réponse décevante, pour un coût d'embedding complet et sans rien améliorer. <code>IBackgroundJobClient</code> injecté au lieu de la façade statique, qui lève sans <code>JobStorage</code> et cassait les tests. 130/130.</span>
       </div>
 
       <div class="done-item">
         <strong>La dimension 768 n'est plus un pari</strong>
-        <span><code>IEmbeddingService</code> + <code>GoogleEmbeddingService</code> (batch par 50), et surtout <strong>vérifiés contre l'API réelle</strong>. Trois choses qu'aucun plan ne disait : le modèle sort en <strong>3072 dimensions par défaut</strong> — <code>dimensions: 768</code> est obligatoire ; les vecteurs réduits <strong>ne sont pas normalisés</strong> (norme mesurée 0,578, pas 1) et sans normalisation côté client le classement cosinus serait faussé <em>sans lever d'erreur</em> ; et Google ne renvoie pas le champ <code>index</code> du contrat OpenAI. Recherche cross-lingue jouée en base : question NL → contenu NL 0,8145, FR pertinent 0,7982, FR hors-sujet 0,4818. L'écart NL/FR n'étant que de 0,016, le <strong>bonus de score par langue</strong> est bien nécessaire.</span>
+        <span><code>IEmbeddingService</code> + <code>GoogleEmbeddingService</code> (batch par 50), et surtout <strong>vérifiés contre l'API réelle</strong>. Trois choses qu'aucun plan ne disait : le modèle sort en <strong>3072 dimensions par défaut</strong> — <code>dimensions: 768</code> est obligatoire ; les vecteurs réduits <strong>ne sont pas normalisés</strong> (norme mesurée 0,578, pas 1) et sans normalisation côté client le classement cosinus serait faussé <em>sans lever d'erreur</em> ; et Google ne renvoie pas le champ <code>index</code> du contrat OpenAI. Recherche cross-lingue jouée en base : question NL → contenu NL 0,8145, FR pertinent 0,7982, FR hors-sujet 0,4818. L'écart NL/FR n'étant que de 0,016, le <strong>bonus de score par langue</strong> est bien nécessaire.</span>
       </div>
 
       <div class="done-item">
-        <strong>L'historique des stats passe à 13 mois pour tous</strong>
-        <span>L'axe « durée » disparaît du découpage commercial : <code>HasAdvancedStats</code> devient le seul différenciateur stats, et <strong>l'export PDF est inclus dès qu'il y a les stats</strong>. Motif : un dossier de subside est annuel — plafonné à 30 jours le rapport n'était envoyable à personne. Et la landing ne promettait aucune durée (la chaîne « 30 jours » existe dans <code>translations.ts</code> mais n'est affichée nulle part). Migration <code>UnifyStatsRetentionTo13Months</code> — elle met à jour les plans <em>et reprend les instances en SQL</em>, sans quoi les clients actuels seraient restés à 30 jours : c'est <code>Instance.StatsHistoryDays</code> que lit le contrôleur. <code>dotnet test</code> 124/124. ⛔ La purge associée est codée mais <strong>inactive</strong> jusqu'à la mise en place du pg_dump.</span>
+        <strong>L'historique des stats passe à 13 mois pour tous</strong>
+        <span>L'axe « durée » disparaît du découpage commercial : <code>HasAdvancedStats</code> devient le seul différenciateur stats, et <strong>l'export PDF est inclus dès qu'il y a les stats</strong>. Motif : un dossier de subside est annuel — plafonné à 30 jours le rapport n'était envoyable à personne. Et la landing ne promettait aucune durée (la chaîne « 30 jours » existe dans <code>translations.ts</code> mais n'est affichée nulle part). Migration <code>UnifyStatsRetentionTo13Months</code> — elle met à jour les plans <em>et reprend les instances en SQL</em>, sans quoi les clients actuels seraient restés à 30 jours : c'est <code>Instance.StatsHistoryDays</code> que lit le contrôleur. <code>dotnet test</code> 124/124. ⛔ La purge associée est codée mais <strong>inactive</strong> jusqu'à la mise en place du pg_dump.</span>
       </div>
 
       <div class="done-item">
-        <strong>Configuration des parcours — 4 correctifs</strong>
-        <span>Relecture du 09/08 de l'écran refondu le 06/08. Le plus sérieux : un parcours créé sans toucher à la question de progression <em>affichait</em> « Dans l'ordre » et <em>enregistrait</em> « Libre ». Les 12 tests de <code>progression_mode</code> ne pouvaient pas le voir — ils couvrent la relecture des booléens, pas le DTO fabriqué par la popup. Aussi : vidéos et audios d'étape rendus en dur comme des images dans les deux apps visiteur, « Quelle ambiance ? » restée en case à cocher, menu « Carte de base » disparaissant sans un mot. À valider — test-plan §19.13 cas 0.</span>
+        <strong>Configuration des parcours — 4 correctifs</strong>
+        <span>Relecture du 09/08 de l'écran refondu le 06/08. Le plus sérieux : un parcours créé sans toucher à la question de progression <em>affichait</em> « Dans l'ordre » et <em>enregistrait</em> « Libre ». Les 12 tests de <code>progression_mode</code> ne pouvaient pas le voir — ils couvrent la relecture des booléens, pas le DTO fabriqué par la popup. Aussi : vidéos et audios d'étape rendus en dur comme des images dans les deux apps visiteur, « Quelle ambiance ? » restée en case à cocher, menu « Carte de base » disparaissant sans un mot. À valider — test-plan §19.13 cas 0.</span>
       </div>
 
       <div class="done-item">
-        <strong>Le schéma du RAG est en base</strong>
-        <span>Image <code>postgis + pgvector</code> (0.8.6, base <strong>épinglée par digest</strong>), table <code>ContentEmbedding</code> avec index HNSW, 7 colonnes IA/stockage sur <code>Resource</code>, table <code>VisitorQuestion</code>. 62 migrations, <code>dotnet test</code> 124/124, données intactes. Deux surprises : la base locale avait <strong>une migration de retard</strong> — les colonnes <code>Guide*</code> du lot 1 n'existaient pas, toute requête sur <code>Instances</code> aurait planté ; et un <strong>warning de collation</strong> (glibc 2.36→2.31) qui désalignait les index texte, corrigé par <code>REINDEX</code> puis <code>REFRESH COLLATION VERSION</code> — dans cet ordre. D'où l'épinglage par digest.</span>
+        <strong>Le schéma du RAG est en base</strong>
+        <span>Image <code>postgis + pgvector</code> (0.8.6, base <strong>épinglée par digest</strong>), table <code>ContentEmbedding</code> avec index HNSW, 7 colonnes IA/stockage sur <code>Resource</code>, table <code>VisitorQuestion</code>. 62 migrations, <code>dotnet test</code> 124/124, données intactes. Deux surprises : la base locale avait <strong>une migration de retard</strong> — les colonnes <code>Guide*</code> du lot 1 n'existaient pas, toute requête sur <code>Instances</code> aurait planté ; et un <strong>warning de collation</strong> (glibc 2.36→2.31) qui désalignait les index texte, corrigé par <code>REINDEX</code> puis <code>REFRESH COLLATION VERSION</code> — dans cet ordre. D'où l'épinglage par digest.</span>
       </div>
 
       <div class="done-item">
         <strong>Le guide lit enfin sa configuration</strong>
-        <span>L'écran Guide IA ne pilote plus dans le vide. En ouvrant le fichier : <strong>quatre</strong> blocs de prompt et non deux — le relevé s'était arrêté au scope configuration. Les quatre lisent le nom, la personnalité et les messages de repli du client ; le ton imposé (« tu es chaleureux ») est retiré, la politique de repli divergente de la ligne 550 réconciliée. <strong>Deux prompts sur quatre n'avaient aucune règle hors-sujet</strong> — sur web et mobile, un visiteur pouvait demander une recette de tarte. Le tirage du repli est fait côté serveur pour que la phrase du client soit reprise mot pour mot. <code>dotnet test</code> 124/124, jamais vu tourner.</span>
+        <span>L'écran Guide IA ne pilote plus dans le vide. En ouvrant le fichier : <strong>quatre</strong> blocs de prompt et non deux — le relevé s'était arrêté au scope configuration. Les quatre lisent le nom, la personnalité et les messages de repli du client ; le ton imposé (« tu es chaleureux ») est retiré, la politique de repli divergente de la ligne 550 réconciliée. <strong>Deux prompts sur quatre n'avaient aucune règle hors-sujet</strong> — sur web et mobile, un visiteur pouvait demander une recette de tarte. Le tirage du repli est fait côté serveur pour que la phrase du client soit reprise mot pour mot. <code>dotnet test</code> 124/124, jamais vu tourner.</span>
       </div>
 
       <div class="done-item">
-        <strong>Écran Statistiques refondu, export PDF compris</strong>
-        <span>Les 7 défauts corrigés, <em>aucun changement backend</em> : barres horizontales monochromes, filtres sur une seule ligne avec le volume de chaque canal, règle mono-canal, 4 KPI portant chacun leur variation, bandeau « à retenir », courbe en aire. La période précédente s'obtient en rappelant le même endpoint. <strong>Le rapport PDF se génère dans le navigateur</strong> (paquet <code>pdf</code> Dart déjà présent) et partage les valeurs calculées de l'écran — un chiffre ne peut pas diverger entre l'écran et le document envoyé à la commune. Le test de génération a attrapé deux plantages qui seraient sortis au premier clic. Au passage : <code>VisitEvent</code> porte bien l'<code>AppType</code>, le canal vocal est branché ; et <strong>deux puces du sommaire promettaient des données inexistantes</strong> (parcours terminés, questions au guide IA), retirées.</span>
+        <strong>Écran Statistiques refondu, export PDF compris</strong>
+        <span>Les 7 défauts corrigés, <em>aucun changement backend</em> : barres horizontales monochromes, filtres sur une seule ligne avec le volume de chaque canal, règle mono-canal, 4 KPI portant chacun leur variation, bandeau « à retenir », courbe en aire. La période précédente s'obtient en rappelant le même endpoint. <strong>Le rapport PDF se génère dans le navigateur</strong> (paquet <code>pdf</code> Dart déjà présent) et partage les valeurs calculées de l'écran — un chiffre ne peut pas diverger entre l'écran et le document envoyé à la commune. Le test de génération a attrapé deux plantages qui seraient sortis au premier clic. Au passage : <code>VisitEvent</code> porte bien l'<code>AppType</code>, le canal vocal est branché ; et <strong>deux puces du sommaire promettaient des données inexistantes</strong> (parcours terminés, questions au guide IA), retirées.</span>
       </div>
 
       <div class="done-item">
-        <strong>Les builds sont débloqués</strong>
+        <strong>Les builds sont débloqués</strong>
         <span>3 apps Flutter + visitapp-web + <code>dotnet test</code> 124/124. Un seul fichier sans <code>// @dart=2.18</code> cassait les trois apps Flutter d'un coup.</span>
       </div>
 
       <div class="done-item">
-        <strong>Bug backend révélé par les tests</strong>
-        <span><code>BuildAuditEntries()</code> modifiait le <code>ChangeTracker</code> pendant son énumération — exception sur toute écriture d'entité auditée. Invisible tant que les tests ne compilaient plus.</span>
+        <strong>Bug backend révélé par les tests</strong>
+        <span><code>BuildAuditEntries()</code> modifiait le <code>ChangeTracker</code> pendant son énumération — exception sur toute écriture d'entité auditée. Invisible tant que les tests ne compilaient plus.</span>
       </div>
 
       <div class="done-item">
         <strong>Assistant IA en web + alignement mobile</strong>
-        <span>Débloque l'add-on IA sur le plan Essentiel, qui est web-only. Suggestions dérivées du contenu réel, zéro configuration client.</span>
+        <span>Débloque l'add-on IA sur le plan Essentiel, qui est web-only. Suggestions dérivées du contenu réel, zéro configuration client.</span>
       </div>
 
       <div class="done-item">
         <strong>Refonte de la progression des parcours</strong>
-        <span>9 booléens sur 3 niveaux remplacés par 3 questions. <code>IsStepLocked</code> supprimé : il rendait une étape définitivement infranchissable même après réussite.</span>
+        <span>9 booléens sur 3 niveaux remplacés par 3 questions. <code>IsStepLocked</code> supprimé : il rendait une étape définitivement infranchissable même après réussite.</span>
       </div>
 
       <div class="done-item">
-        <strong>Centrage de carte, horaires, icônes</strong>
-        <span>M1, M2 et W2 corrigés — des champs que le client saisissait sans qu'ils aient le moindre effet.</span>
+        <strong>Centrage de carte, horaires, icônes</strong>
+        <span>M1, M2 et W2 corrigés — des champs que le client saisissait sans qu'ils aient le moindre effet.</span>
       </div>
 
       <div class="done-item">
-        <strong>Audit de cohérence de la doc</strong>
-        <span>Le LLM annoncé était Claude à 4 endroits (c'est Gemini), l'infra email « inexistante » (Resend est en place), et deux docs se contredisaient sur l'état des builds.</span>
+        <strong>Audit de cohérence de la doc</strong>
+        <span>Le LLM annoncé était Claude à 4 endroits (c'est Gemini), l'infra email « inexistante » (Resend est en place), et deux docs se contredisaient sur l'état des builds.</span>
       </div>
 
       <div class="done-item">
-        <strong>CGU reprises et landing corrigée</strong>
-        <span>Les CGU décrivaient des plans abandonnés (Starter/Standard/Premium 69/99/199 €). Alignées sur la landing, avec un quota IA défini en tokens renvoyant au back-office plutôt qu'un chiffre figé dans un contrat. Landing : « req/mois » → « questions de visiteurs / mois » en 4 langues.</span>
+        <strong>CGU reprises et landing corrigée</strong>
+        <span>Les CGU décrivaient des plans abandonnés (Starter/Standard/Premium 69/99/199 €). Alignées sur la landing, avec un quota IA défini en tokens renvoyant au back-office plutôt qu'un chiffre figé dans un contrat. Landing : « req/mois » → « questions de visiteurs / mois » en 4 langues.</span>
       </div>
 
       <div class="done-item">
-        <strong>Écran Guide IA — onglet Configuration livré</strong>
-        <span>Migration additive (4 colonnes nullable), champs sur <code>Instance</code>, client généré étendu à la main, écran avec 35 clés i18n FR/EN/NL. <code>dotnet build</code> et <code>flutter build web</code> passent. Menu conditionné à <code>isAssistant</code>, le même drapeau que la garde d'<code>AiController</code>.</span>
+        <strong>Écran Guide IA — onglet Configuration livré</strong>
+        <span>Migration additive (4 colonnes nullable), champs sur <code>Instance</code>, client généré étendu à la main, écran avec 35 clés i18n FR/EN/NL. <code>dotnet build</code> et <code>flutter build web</code> passent. Menu conditionné à <code>isAssistant</code>, le même drapeau que la garde d'<code>AiController</code>.</span>
       </div>
 
       <div class="done-item">
         <strong>Rate limiting sur les endpoints IA</strong>
-        <span>La clé API publique est <strong>lisible dans le navigateur</strong> dès que visitapp-web est en ligne, et rien n'empêchait d'y boucler jusqu'à vider le quota de jetons d'un client. <code>AddRateLimiter</code> natif .NET 8, <strong>partition par instance</strong> — c'est l'instance qui porte le quota protégé, l'abus chez l'un ne doit pas ralentir les autres — fenêtre fixe 120 req/min, 429 avec <code>Retry-After</code>. Appliqué à <code>chat</code> <strong>et <code>translate</code></strong> : les deux consomment des jetons, et <code>translate</code> est atteignable avec la même clé. Ordre du pipeline choisi, pas subi : <strong>après <code>UseCors</code></strong> (un 429 posé avant les en-têtes CORS s'affiche comme une erreur CORS et le client ne voit jamais le vrai code) et <strong>après <code>UseAuthentication</code></strong> (sinon la partition n'a pas le claim d'instance et tout le monde tombe dans le même seau). <code>dotnet build</code> ✅, <code>dotnet test</code> <strong>203/203</strong>. ⚠️ <strong>Jamais exercé à l'exécution</strong> : le projet n'a aucune infrastructure de test HTTP (pas de <code>WebApplicationFactory</code>), et en monter une pour ce seul contrôle serait disproportionné. Vérification manuelle à faire une fois : une boucle de 130 appels sur <code>/api/AI/chat</code> doit basculer en 429 vers le 121<sup>e</sup>.</span>
+        <span>La clé API publique est <strong>lisible dans le navigateur</strong> dès que visitapp-web est en ligne, et rien n'empêchait d'y boucler jusqu'à vider le quota de jetons d'un client. <code>AddRateLimiter</code> natif .NET 8, <strong>partition par instance</strong> — c'est l'instance qui porte le quota protégé, l'abus chez l'un ne doit pas ralentir les autres — fenêtre fixe 120 req/min, 429 avec <code>Retry-After</code>. Appliqué à <code>chat</code> <strong>et <code>translate</code></strong> : les deux consomment des jetons, et <code>translate</code> est atteignable avec la même clé. Ordre du pipeline choisi, pas subi : <strong>après <code>UseCors</code></strong> (un 429 posé avant les en-têtes CORS s'affiche comme une erreur CORS et le client ne voit jamais le vrai code) et <strong>après <code>UseAuthentication</code></strong> (sinon la partition n'a pas le claim d'instance et tout le monde tombe dans le même seau). <code>dotnet build</code> ✅, <code>dotnet test</code> <strong>203/203</strong>. ⚠️ <strong>Jamais exercé à l'exécution</strong> : le projet n'a aucune infrastructure de test HTTP (pas de <code>WebApplicationFactory</code>), et en monter une pour ce seul contrôle serait disproportionné. Vérification manuelle à faire une fois : une boucle de 130 appels sur <code>/api/AI/chat</code> doit basculer en 429 vers le 121<sup>e</sup>.</span>
       </div>
 
       <div class="done-item">
-        <strong>D3 — <code>audio/mpeg</code> reconnu à l'écriture des fichiers</strong>
-        <span>La table d'extensions ne mappait que <code>audio/mp3</code>, qui <strong>n'est pas un MIME standard</strong> : les MP3 servis correctement par le serveur atterrissaient en <code>.unknown</code> sur le device. Corrigé sans attendre le test §21 — c'était un défaut certain, lisible dans le code, pas une hypothèse à mesurer.</span>
+        <strong>D3 — <code>audio/mpeg</code> reconnu à l'écriture des fichiers</strong>
+        <span>La table d'extensions ne mappait que <code>audio/mp3</code>, qui <strong>n'est pas un MIME standard</strong> : les MP3 servis correctement par le serveur atterrissaient en <code>.unknown</code> sur le device. Corrigé sans attendre le test §21 — c'était un défaut certain, lisible dans le code, pas une hypothèse à mesurer.</span>
       </div>
 
       <div class="done-item">
-        <strong>D4 — purge des fichiers obsolètes réactivée</strong>
-        <span>La liste des ressources utilisées était calculée puis jetée : <code>deleteSync()</code> commenté, le stockage occupé sur le téléphone du visiteur ne diminuait jamais. Réactivé, borné au répertoire de la configuration. À confirmer au §21, seul juge de « elle ne supprime rien d'utile ».</span>
-        <span>⚠️ <strong>Deux prémisses du plan étaient fausses.</strong> « Les deux chemins de téléchargement divergent » (le motif <code>Create</code>/<code>Upload</code> de C1/C3) : <strong>il n'y a qu'un seul chemin vivant</strong> — les lignes 328-461 sont dans un bloc commenté, et <code>cleanLocalResources</code> n'est appelée nulle part. Et cette fonction <strong>reste désactivée délibérément</strong> : la table locale <code>resources</code> n'a pas de colonne <code>configurationId</code>, elle est globale à toutes les visites — l'activer sur les ids d'une seule aurait effacé les lignes des autres, pour rien, puisque le rendu retrouve le fichier en listant le répertoire.</span>
+        <strong>D4 — purge des fichiers obsolètes réactivée</strong>
+        <span>La liste des ressources utilisées était calculée puis jetée : <code>deleteSync()</code> commenté, le stockage occupé sur le téléphone du visiteur ne diminuait jamais. Réactivé, borné au répertoire de la configuration. À confirmer au §21, seul juge de « elle ne supprime rien d'utile ».</span>
+        <span>⚠️ <strong>Deux prémisses du plan étaient fausses.</strong> « Les deux chemins de téléchargement divergent » (le motif <code>Create</code>/<code>Upload</code> de C1/C3) : <strong>il n'y a qu'un seul chemin vivant</strong> — les lignes 328-461 sont dans un bloc commenté, et <code>cleanLocalResources</code> n'est appelée nulle part. Et cette fonction <strong>reste désactivée délibérément</strong> : la table locale <code>resources</code> n'a pas de colonne <code>configurationId</code>, elle est globale à toutes les visites — l'activer sur les ids d'une seule aurait effacé les lignes des autres, pour rien, puisque le rendu retrouve le fichier en listant le répertoire.</span>
       </div>
 
       <div class="done-item">
-        <strong>D2 — filtre de fraîcheur sur <code>dateUpdate</code>, de bout en bout</strong>
-        <span><code>dateUpdate</code> exposé dans <code>ResourceDTO</code> (<strong>champ DTO, pas une colonne</strong> — le gel du lot B tient), client <code>manager_api_new</code> édité à la main, colonne ajoutée à la base locale du device (<strong>v3 → v4</strong>), et le filtre passe de « le fichier est là » à une comparaison de dates. <code>dotnet test</code> <strong>205/205</strong> (2 tests ajoutés), <code>flutter build web</code> ✅, APK <code>dev</code> ✅, <code>tablet-app</code> ✅.</span>
-        <span>⚠️ <strong>La prémisse était fausse, et ça change ce que D2 répare.</strong> « Une image remplacée dans le CMS ne remonte jamais » : <strong>ce cas n'existe pas</strong> — <code>Upload</code> génère un nouvel id à chaque téléversement et le blob vit en <code>pictures/{instanceId}/{resourceId}</code>, donc remplacer une image donne un nouvel id et une nouvelle URL, que l'ancien filtre téléchargeait déjà. ✅ <strong>Le vrai cas de péremption est celui que D3 vient de créer</strong> : les MP3 déjà sur les devices y sont en <code>.unknown</code> et se déclaraient à jour. <strong>Sans D2, D3 ne réparait que les installations neuves.</strong></span>
-        <span>⚠️ <strong>Deux pièges tranchés en écrivant</strong> : la montée v4 laisse les dates existantes à <code>NULL</code> et les considère <strong>à jour</strong> (backfiller à zéro aurait fait re-télécharger toutes les visites de tous les visiteurs sur leur réseau mobile) ; et la boucle en masse héritée de D1 <strong>écrasait la date</strong> que la boucle de téléchargement venait d'écrire — <code>DatabaseHelper.insert</code> fait un UPDATE de la ligne entière quand l'id existe.</span>
+        <strong>D2 — filtre de fraîcheur sur <code>dateUpdate</code>, de bout en bout</strong>
+        <span><code>dateUpdate</code> exposé dans <code>ResourceDTO</code> (<strong>champ DTO, pas une colonne</strong> — le gel du lot B tient), client <code>manager_api_new</code> édité à la main, colonne ajoutée à la base locale du device (<strong>v3 → v4</strong>), et le filtre passe de « le fichier est là » à une comparaison de dates. <code>dotnet test</code> <strong>205/205</strong> (2 tests ajoutés), <code>flutter build web</code> ✅, APK <code>dev</code> ✅, <code>tablet-app</code> ✅.</span>
+        <span>⚠️ <strong>La prémisse était fausse, et ça change ce que D2 répare.</strong> « Une image remplacée dans le CMS ne remonte jamais » : <strong>ce cas n'existe pas</strong> — <code>Upload</code> génère un nouvel id à chaque téléversement et le blob vit en <code>pictures/{instanceId}/{resourceId}</code>, donc remplacer une image donne un nouvel id et une nouvelle URL, que l'ancien filtre téléchargeait déjà. ✅ <strong>Le vrai cas de péremption est celui que D3 vient de créer</strong> : les MP3 déjà sur les devices y sont en <code>.unknown</code> et se déclaraient à jour. <strong>Sans D2, D3 ne réparait que les installations neuves.</strong></span>
+        <span>⚠️ <strong>Deux pièges tranchés en écrivant</strong> : la montée v4 laisse les dates existantes à <code>NULL</code> et les considère <strong>à jour</strong> (backfiller à zéro aurait fait re-télécharger toutes les visites de tous les visiteurs sur leur réseau mobile) ; et la boucle en masse héritée de D1 <strong>écrasait la date</strong> que la boucle de téléchargement venait d'écrire — <code>DatabaseHelper.insert</code> fait un UPDATE de la ligne entière quand l'id existe.</span>
       </div>
 
       <div class="done-item">
-        <strong>Trois plans écrits, deux écrans maquettés</strong>
-        <span>Médias &amp; stockage, visite hors ligne, écran Guide IA, écran Statistiques. Le découpage V1/V2 est tranché : le RAG sur contenu CMS part en V1, l'ingestion documentaire en V2. <strong>Les deux écrans maquettés sont désormais implémentés.</strong></span>
+        <strong>Trois plans écrits, deux écrans maquettés</strong>
+        <span>Médias &amp; stockage, visite hors ligne, écran Guide IA, écran Statistiques. Le découpage V1/V2 est tranché : le RAG sur contenu CMS part en V1, l'ingestion documentaire en V2. <strong>Les deux écrans maquettés sont désormais implémentés.</strong></span>
       </div>
 
     </div>
   </section>
 
   <footer class="foot">
-    <span>Source de vérité : <code>DOCS/STATUS.md §1ter</code> · chantier Guide IA : <code>§1quater</code></span>
-    <span>Maquettes : <a href="https://claude.ai/code/artifact/c43fe02d-3283-48c2-992f-d687e18acdfa">Guide IA</a> · <a href="https://claude.ai/code/artifact/052fe8f3-0288-4847-b63f-4c7de06068ec">Statistiques</a></span>
-    <span>Règle de découpage : ce qui touche aux données écrites part avec la migration, ce qui est additif attend.</span>
+    <span>Source de vérité : <code>DOCS/STATUS.md §1ter</code> · chantier Guide IA : <code>§1quater</code></span>
+    <span>Maquettes : <a href="https://claude.ai/code/artifact/c43fe02d-3283-48c2-992f-d687e18acdfa">Guide IA</a> · <a href="https://claude.ai/code/artifact/052fe8f3-0288-4847-b63f-4c7de06068ec">Statistiques</a></span>
+    <span>Règle de découpage : ce qui touche aux données écrites part avec la migration, ce qui est additif attend.</span>
     <span>Rien ne part en prod avant que ce tableau soit vide.</span>
   </footer>
 
@@ -1185,7 +1185,7 @@
         }
       });
 
-      // « Fait récemment » n'a pas d'horizon : c'est du passé, pas du reste-à-faire.
+      // « Fait récemment » n'a pas d'horizon : c'est du passé, pas du reste-à-faire.
       if (done) { done.classList.toggle('hidden', horizon !== 'all'); }
       if (stats[5]) { stats[5].classList.toggle('hidden', horizon !== 'all'); }
       if (emptyMsg) { emptyMsg.classList.toggle('hidden', total !== 0); }
diff --git a/test-plan-manager-app.md b/test-plan-manager-app.md
new file mode 100644
index 0000000..2863d04
--- /dev/null
+++ b/test-plan-manager-app.md
@@ -0,0 +1,356 @@
+# Plan de test — manager-app (modifications du 2026-08-09 au 2026-08-12)
+
+Périmètre : les 8 commits livrés entre le 9 et le 12 août 2026 sur `manager-app`.
+Rien ici n'a été vérifié à l'œil dans un navigateur — c'est justement l'objet de ce document.
+
+Mode d'emploi : coche la case si le comportement attendu est constaté, laisse-la vide sinon
+et note l'écart sur la ligne. `→` = résultat attendu.
+
+Commits couverts :
+
+| Réf | Commit | Sujet |
+|---|---|---|
+| §1 | `eb8e849` | Socle visuel (constants.dart) |
+| §2 | `bb4d4fe` `eb8e849` | Guide IA — 2 onglets |
+| §3 | `bb4d4fe` | Statistiques refondues + export PDF |
+| §4 | `bb4d4fe` | Onboarding self-service (auth, abonnement, quota IA) |
+| §5 | `b39854a` | DB4 — éditeur de parcours unifié |
+| §6 | `bb4d4fe` | Mode de progression du parcours |
+| §7 | `5066b6c` | Lot E — PDF en média d'étape, QuestionType |
+| §8 | `762448c` | Lot F — écran Activité + compteur d'utilisateurs |
+| §9 | `608231f` | C4 — compression des images à l'upload |
+| §10 | `9d9f4bc` | Nettoyage du client généré |
+| §11 | — | i18n FR / EN / NL et non-régression |
+
+---
+
+## §0. Porte d'entrée
+
+- [ ] `flutter build web` passe sans erreur
+- [ ] `flutter analyze` ne remonte que les 3 problèmes connus de `test/widget_test.dart`
+- [ ] Connexion, sélection d'instance, chargement du menu latéral → aucun écran blanc
+
+---
+
+## §1. Socle visuel
+
+Le socle (11 rôles typo, 8 espacements, 5 rayons) n'est appliqué que sur les écrans neufs :
+Guide IA, Statistiques, Activité. Le reste de l'app garde son style d'origine — c'est voulu.
+
+- [ ] Les écrans Guide IA / Statistiques / Activité utilisent la même palette que le reste de l'app (pas de seconde identité visuelle)
+- [ ] Titres, sous-titres et cartes cohérents entre ces trois écrans
+- [ ] En 1280 px de large : pas de débordement horizontal, pas de texte tronqué
+- [ ] En ~900 px (fenêtre réduite) : les cartes passent en colonne au lieu de se compresser
+
+---
+
+## §2. Guide IA
+
+Menu conditionné à `isAssistant` (même drapeau que la garde d'`AiController`).
+
+### 2.1 Accès
+
+- [ ] Instance avec assistant activé → l'entrée « Guide IA » apparaît dans le menu
+- [ ] Instance sans assistant → l'entrée est absente
+
+### 2.2 Onglet « Configuration »
+
+- [ ] Les deux onglets sont visibles et basculent sans rechargement
+- [ ] Persona : saisie puis « Enregistrer » → message de succès, valeur retrouvée après F5
+- [ ] Réponses de repli : ajout, modification, suppression d'une ligne
+- [ ] Wakeword vocal affiché avec le nom configuré
+- [ ] Carte « Ce que connaît votre guide » (`GET /api/Ai/knowledge/{id}`) : le nombre de morceaux de contenu s'affiche
+- [ ] Une section désactivée puis réindexée → le compteur baisse (l'index vectoriel est la source, pas les tables de contenu)
+- [ ] Bouton de réindexation : lancement, retour visible, pas de double envoi si on reclique
+- [ ] Aperçu de conversation : une question envoyée reçoit une vraie réponse (`POST /api/AI/chat`, pas une simulation)
+- [ ] Aperçu avec des modifications non enregistrées → mention « non enregistré » affichée
+- [ ] Échec réseau sur l'enregistrement → snackbar rouge, la saisie n'est pas perdue
+
+### 2.3 Onglet « Ce que demandent vos visiteurs »
+
+Alimenté par `GET /api/Ai/insights/{id}`. **L'endpoint backend n'existe peut-être pas encore** :
+si c'est le cas, seul le premier point ci-dessous s'applique, le reste est à rejouer après livraison.
+
+- [ ] Aucune donnée / endpoint absent → état vide illustré (icône + texte), **pas** de cadre creux ni d'erreur
+- [ ] Avec des données : les 4 tuiles (questions, sans réponse, thèmes, langues) affichent les bons totaux
+- [ ] La tuile « sans réponse » est en ambre, les trois autres en encre normale
+- [ ] Bloc ambre « questions sans réponse » listé avec le compteur `n ×` à droite
+- [ ] Une carte dont la liste est vide (thèmes non encore regroupés) est **masquée**, pas affichée vide
+- [ ] Barres : la plus longue correspond bien à la valeur la plus haute, une seule teinte par carte
+- [ ] > 1100 px : les cartes sont côte à côte ; en dessous : empilées
+- [ ] Note de confidentialité affichée en bas
+
+---
+
+## §3. Statistiques — écran « Fréquentation »
+
+⚠️ Écran réécrit (+1832 lignes) et **jamais ouvert dans un navigateur** avant ce test.
+
+### 3.1 Chargement et filtres
+
+- [ ] Instance sans droit statistiques → message « indisponible » explicite (pas d'écran vide)
+- [ ] Erreur réseau → message d'erreur avec icône, pas de spinner infini
+- [ ] Instance sans aucune donnée → message « pas de données »
+- [ ] Sélecteur de période : 7 / 30 / 90 / 365 jours → la plage de dates affichée en sous-titre suit
+- [ ] Filtre canal : « Tous » + un bouton par canal (Mobile / Tablette / Web / VR / Voix)
+- [ ] Chaque bouton de canal affiche son volume
+- [ ] Un canal sans donnée sur la période est absent ou inactif
+- [ ] Filtre sur un canal unique → message « pas de données pour ce type » si le canal est vide
+- [ ] Retour à « Tous » → les valeurs redeviennent celles du total
+
+### 3.2 KPI et bandeau
+
+- [ ] 4 KPI affichés : visites, durée moyenne, contenus par visite, et part vocale **ou** vues totales
+- [ ] Chaque KPI porte sa variation vs période précédente (flèche + %)
+- [ ] Variation nulle → « stable » avec l'icône neutre, pas « 0 % »
+- [ ] Les variations sont cohérentes : passer de 30 à 7 jours change les chiffres ET les variations
+- [ ] Bandeau « à retenir » : phrases cohérentes avec les chiffres affichés au-dessus
+- [ ] Durée : `1 min 30 s` au-delà de 60 s, `45 s` en dessous
+
+### 3.3 Courbe et tableaux
+
+- [ ] Courbe en aire des visites par jour, un point par jour de la période
+- [ ] Bandes de week-end visibles et alignées sur les bons jours (vérifier un samedi précis)
+- [ ] Jour de pic annoté avec la bonne date et la bonne valeur
+- [ ] Barres horizontales : top contenus, canaux, langues
+- [ ] Tableaux détaillés : POI, agenda, quiz, jeux, articles, menu — un tableau vide est masqué
+- [ ] Les totaux des tableaux ne contredisent pas les KPI
+
+### 3.4 Export PDF
+
+- [ ] Bouton d'export → le PDF se télécharge
+- [ ] Nom du fichier : nom d'instance + intitulé + date
+- [ ] **Les chiffres du PDF sont identiques à ceux de l'écran** (KPI, pic, tops) — c'est le point critique
+- [ ] La plage de dates du PDF correspond au filtre actif
+- [ ] Export avec un filtre canal actif → le PDF reflète ce filtre
+- [ ] Le sommaire ne promet **pas** de données inexistantes (parcours terminés, questions au guide IA)
+- [ ] Échec de génération → snackbar rouge, l'écran reste utilisable
+- [ ] Export sur une période sans données → soit bouton désactivé, soit PDF cohérent (à noter selon le constat)
+
+---
+
+## §4. Onboarding self-service
+
+⚠️ Aucun parcours joué de bout en bout avant ce test.
+
+### 4.1 Mot de passe oublié
+
+- [ ] Lien « mot de passe oublié » accessible depuis l'écran de connexion
+- [ ] E-mail inconnu → message neutre (pas de fuite d'existence de compte)
+- [ ] E-mail connu → confirmation d'envoi
+- [ ] Le mail arrive et son lien ouvre l'écran de définition du mot de passe
+
+### 4.2 Définition du mot de passe
+
+- [ ] Lien valide → formulaire affiché
+- [ ] Lien expiré ou déjà consommé → message clair, pas d'erreur technique brute
+- [ ] Mot de passe trop court / confirmation différente → erreur de validation avant envoi
+- [ ] Définition réussie → redirection vers la connexion, connexion effective avec le nouveau mot de passe
+
+### 4.3 Écran Abonnement
+
+- [ ] Entrée « Abonnement » présente dans le menu
+- [ ] Période d'essai en cours → « essai actif » + date de fin correcte
+- [ ] Essai sans date de fin → texte de repli, pas de date vide ni de `null`
+- [ ] Plan payant actif → intitulé et description du plan
+- [ ] Liste « inclus dans votre plan » cohérente avec le plan réel de l'instance
+- [ ] Bouton de montée en gamme → ouvre bien la page cible dans un nouvel onglet
+- [ ] Section modules complémentaires → mention « bientôt disponible »
+
+### 4.4 Indicateur de quota IA
+
+- [ ] Sous le bouton « Traduire via IA » : `Quota IA : X / Y utilisés ce mois`
+- [ ] Plan sans plafond (quota = 0) → « Quota IA : illimité »
+- [ ] ≥ 80 % → texte orange + gras + mention « partagé avec l'assistant visiteur »
+- [ ] ≥ 95 % → texte rouge
+- [ ] Après une traduction, le compteur se met à jour (il ne se rafraîchit que si la clé change — à vérifier)
+- [ ] Endpoint quota en échec → **rien** ne s'affiche, la traduction reste possible
+
+---
+
+## §5. Éditeur de parcours unifié (DB4)
+
+Les trois anciennes fenêtres (`showNewOrUpdateGuidedPath` / `GuidedStep` / `QuizQuestion`) sont supprimées.
+Profondeur maximale attendue : 2 surfaces (l'éditeur, puis la traduction).
+
+### 5.1 Structure
+
+- [ ] Ouverture d'un parcours → une seule fenêtre : rail d'étapes à gauche, détail à droite
+- [ ] Ajouter une question → elle se déplie **sur place**, aucune fenêtre supplémentaire
+- [ ] Traduire un champ → la fenêtre de traduction est la seule surface superposée
+- [ ] Fenêtre large (≈ 1180 px max) et centrée, pas de barre de défilement horizontale
+
+### 5.2 Sauvegarde au fil de l'eau
+
+Il n'y a **plus** de bouton « Sauvegarder », et plus d'avertissement de perte de travail (garde-fou retiré volontairement).
+
+- [ ] Saisie dans un champ → écriture partie ~700 ms après la dernière frappe (vérifier dans l'onglet Réseau)
+- [ ] Frappe continue → une seule requête à la fin, pas une par caractère
+- [ ] Ajout / suppression / réordonnancement d'étape → écriture immédiate, sans attendre le débounce
+- [ ] Fermer la fenêtre juste après une frappe → la dernière saisie est bien enregistrée (purge à la fermeture)
+- [ ] F5 après édition → tout est retrouvé
+- [ ] Ouvrir une fenêtre neuve puis la refermer sans rien toucher → **aucun parcours créé en base**
+- [ ] Première modification sur une fenêtre neuve → le parcours est créé à ce moment-là
+
+### 5.3 Erreurs et fermeture
+
+- [ ] Backend coupé pendant l'édition → la fenêtre **refuse de se fermer**, un « Réessayer » apparaît en pied de page
+- [ ] Backend rétabli + « Réessayer » → l'écriture passe et la fermeture devient possible
+- [ ] Retour arrière du navigateur pendant l'édition → passe par la même fermeture (rien n'est perdu)
+- [ ] Suppression d'étape → demande de confirmation
+- [ ] Confirmation refusée → l'étape reste, aucune requête partie
+
+### 5.4 Pièges backend à vérifier en base
+
+- [ ] Ajouter deux étapes d'affilée → **pas de doublon** en base (les étapes sans id partent par `CreateGuidedStep`)
+- [ ] Créer une question, fermer, rouvrir → la question a le bon id et n'est pas dupliquée
+- [ ] Réordonner puis ajouter une question → la question reste rattachée à la bonne étape (récupération de l'id par `order`)
+- [ ] Supprimer une étape du milieu → les `order` des suivantes sont recalculés
+
+### 5.5 Les deux hébergements du parcours
+
+- [ ] Parcours sous une **SectionParcours** : création, édition, suppression
+- [ ] Parcours sous une **SectionMap** : mêmes opérations, même comportement
+- [ ] Aucun écart de comportement entre les deux
+
+---
+
+## §6. Mode de progression du parcours
+
+3 questions au lieu des 9 booléens précédents.
+
+- [ ] Trois modes proposés : Libre / Dans l'ordre / Étape par étape, chacun avec sa description
+- [ ] Un parcours existant s'ouvre sur le mode correspondant à ses booléens actuels
+- [ ] « Libre » → en base : `isLinear = false`, `requireSuccessToAdvance = false`, `hideNextStepsUntilComplete = false`
+- [ ] « Dans l'ordre » → `isLinear = true`, `requireSuccessToAdvance = false`
+- [ ] « Étape par étape » → `isLinear = true`, `requireSuccessToAdvance = true`
+- [ ] Aller-retour entre deux modes puis rechargement → le mode affiché est celui choisi
+- [ ] Le comportement côté visitapp correspond au mode choisi (test croisé, cf. `test-plan.md` §19.13)
+
+---
+
+## §7. Lot E — médias d'étape et types de question
+
+- [ ] Média d'une **étape de parcours** : le sélecteur propose Image, Vidéo, Audio **et PDF**
+- [ ] Média d'un **slider** : la liste est inchangée (pas de PDF)
+- [ ] PDF sélectionné sur une étape → enregistré, retrouvé après rechargement
+- [ ] Types de question : Simple / Choix multiple / Puzzle correctement libellés (plus de `number0/1/2`)
+- [ ] Changer le type d'une question existante → les champs affichés suivent le type
+- [ ] Une question Puzzle enregistrée se rouvre bien en Puzzle
+- [ ] Champ « fournisseur de carte » toujours présent, présenté comme réglage mobile/tablette (visitapp-web reste sur Leaflet)
+
+---
+
+## §8. Lot F — Activité et utilisateurs
+
+### 8.1 Accès à l'écran Activité
+
+- [ ] SuperAdmin → entrée « Activité » visible dans le menu (icône historique)
+- [ ] InstanceAdmin → entrée **absente**
+- [ ] Utilisateur standard → entrée absente
+- [ ] Passer de SuperAdmin à un autre rôle sans recharger → l'entrée disparaît
+
+### 8.2 Journal
+
+- [ ] Liste chargée avec colonnes : date, instance, entité, action, utilisateur, id d'entité
+- [ ] Actions traduites (Créer / Modifier / Supprimer), pas les valeurs brutes
+- [ ] Entités traduites (Section, Ressource, Configuration, Device, Utilisateur)
+- [ ] Ids d'instance et d'utilisateur résolus en **noms**
+- [ ] Un id qui ne correspond plus à rien (entité supprimée) reste affiché tel quel, sans casser la ligne
+- [ ] Clic sur une ligne → détail avant/après en **table**, pas de JSON brut
+- [ ] Une création (pas de valeur « avant ») s'affiche proprement
+- [ ] Journal vide → message dédié
+- [ ] Erreur backend → message d'erreur, pas de spinner infini
+
+### 8.3 Filtres et pagination
+
+- [ ] Filtre instance
+- [ ] Filtre type d'entité
+- [ ] Filtre utilisateur
+- [ ] Filtres de date « du » / « au »
+- [ ] Combinaison de plusieurs filtres → résultats cohérents
+- [ ] Tout changement de filtre ramène à la page 1
+- [ ] **« Réinitialiser les filtres » vide aussi l'affichage des listes déroulantes** (c'était le bug corrigé)
+- [ ] Pagination 50 : suivant / précédent, compteur « X–Y sur Z » exact
+- [ ] Bouton précédent inactif en page 1, suivant inactif en dernière page
+
+### 8.4 Compteur d'utilisateurs
+
+- [ ] Écran Utilisateurs : compteur « X / 5 » affiché
+- [ ] À 5 utilisateurs → bouton d'ajout désactivé
+- [ ] SuperAdmin → **pas** de compteur ni de blocage (sa liste couvre toutes les instances)
+- [ ] Création avec un e-mail déjà utilisé (409) → snackbar rouge avec le message serveur
+- [ ] Création avec un rôle refusé (403) → snackbar rouge
+- [ ] Création valide → utilisateur ajouté à la liste
+- [ ] InstanceAdmin → le rôle SuperAdmin n'est pas proposé dans la liste des rôles
+
+> Dettes serveur connues, hors périmètre de ce test : le plafond de 5 n'est pas appliqué par
+> `UserController` (un POST direct passe), et aucune section n'est journalisée dans l'audit.
+
+---
+
+## §9. C4 — compression des images à l'upload
+
+Règle : redimensionnement à 2560 px sur le côté long, JPEG q82 — sauf PNG à canal alpha qui reste PNG.
+
+- [ ] Upload d'un JPEG de 6000 px → l'image stockée fait 2560 px sur son côté long
+- [ ] Photo en **portrait** → c'est bien la hauteur qui est ramenée à 2560, pas la largeur
+- [ ] Le poids affiché dans la liste des ressources correspond au fichier **compressé**, pas à l'original
+- [ ] PNG **avec transparence** → reste un PNG, transparence intacte (pas de fond noir)
+- [ ] PNG **sans transparence** → ressort en JPEG, et le type MIME suit (vérifier le `Content-Type` servi par Firebase)
+- [ ] Petite image déjà bien encodée → l'original est conservé (pas de fichier plus lourd qu'avant)
+- [ ] Fichier image corrompu → l'upload passe quand même avec l'original, pas de blocage
+- [ ] Fichier non image (PDF, vidéo, audio) → aucun traitement, upload inchangé
+- [ ] **Les deux chemins d'upload** (création de ressource et ajout de fichier) compressent identiquement
+- [ ] Le quota de stockage augmente de la taille compressée, pas de la taille d'origine
+- [ ] Le second chemin d'upload renseigne désormais `sizeBytes` (avant : 0 octet au quota)
+- [ ] Upload multiple de plusieurs images → toutes compressées, aucune perdue
+
+> Les ressources créées avant ce commit par le second chemin comptent 0 octet au quota :
+> c'est l'existant, il attend le backfill C2 — ne pas le noter comme une régression.
+
+---
+
+## §10. Nettoyage du client généré
+
+- [ ] `flutter analyze manager_api_new` : 3 avertissements légitimes, plus les 67 d'avant
+- [ ] `lib/api/openApiTest.dart` a bien disparu (le déclencheur de génération est verrouillé)
+- [ ] Aucun écran ne casse à cause d'un modèle supprimé (statistiques, carte, utilisateurs surtout)
+- [ ] `tablet-app` compile toujours avec ce client
+- [ ] `mymuseum-visitapp` compile toujours avec ce client
+- [ ] Le mapping `isGood` → `isCorrect` des QCM est toujours en place
+
+---
+
+## §11. i18n et non-régression
+
+### 11.1 Langues
+
+- [ ] Sélecteur de langue dans le menu latéral : FR / EN / NL
+- [ ] Changement de langue → l'interface bascule immédiatement, sans rechargement
+- [ ] La langue est conservée après F5
+- [ ] Guide IA : aucune clé manquante en EN, aucune en NL
+- [ ] Statistiques : idem
+- [ ] Activité : idem (40 clés ajoutées au lot F)
+- [ ] Éditeur de parcours : idem (14 clés ajoutées, 3 retirées)
+- [ ] Aucun texte du type `guideIaXxx` ou `auditXxx` affiché brut à l'écran
+- [ ] En NL et EN, les libellés longs ne débordent pas des boutons et des cartes
+
+### 11.2 Écrans non touchés (contrôle rapide)
+
+- [ ] Configurations : ouverture, édition, enregistrement d'une section de chaque type
+- [ ] Ressources : liste, filtre, suppression
+- [ ] Applications / liaison configuration : aperçu bento toujours fonctionnel
+- [ ] Devices kiosk
+- [ ] Clés API
+- [ ] Notifications push
+- [ ] Déconnexion / reconnexion
+
+---
+
+## Écarts constatés
+
+| § | Ce qui a été observé | Gravité |
+|---|---|---|
+|  |  |  |
+|  |  |  |