# Reprendre le pilotage de la recette — depuis n'importe quelle conversation

Écrit le 20/08/2026. Une conversation n'est PAS un support d'état : elle se
compacte, elle se ferme. Ce document liste ce qu'une nouvelle session doit lire,
et les **quatre choses qu'elle ne peut PAS deviner** et qu'il faut lui redonner.

## 1. Ce qui se lit tout seul (aucune perte)

| Quoi | Où |
|---|---|
| Les attendus de chaque étape + le registre des écarts connus | `docs/design/refonte-2026-08/CAHIER_RECETTE.md` |
| L'état de chaque écart, avec les décisions en commentaire | les **issues** des deux dépôts (BACK et FRONT) |
| Les arbitrages produit tranchés et en attente | `docs/roadmap/ARBITRAGES_EN_ATTENTE.md` |
| Les principes cibles des habilitations | `docs/roadmap/23_CARTOGRAPHIE_HABILITATIONS.md` §8 |
| Comment on traite un défaut | `docs/process/TRAITEMENT_DES_BUGS.md` |
| Comment on déploie | `docs/process/DEPLOIEMENT_STAGING.md` |
| Comment on pilote un fil | `docs/process/FIL_DE_CHANTIER.md` |
| L'avancement + le journal des correctifs | `docs/recette/tableau-de-bord.html` (source) — publication : §4 |

La méthode elle-même est transverse, hors dépôt : skills `pilotage-recette`,
`socle-livraison`, `chef-orchestre`, `cadrage-orchestration`, `rex-session`.

## 2. Ce qu'une nouvelle session NE PEUT PAS deviner — à lui redonner

1. **Le jeton Sentry de lecture.** Vit en variable d'environnement, jamais au
   dépôt. Sans lui, aucune collecte de signalements.
2. **Le mot de passe des comptes de recette.** Idem : variable d'environnement
   `RECETTE_PASSWORD`, jamais dans un formulaire ni au dépôt.
3. **La tâche planifiée de screening** : elle ne vit que dans la session qui
   l'a créée. À recréer — et à VÉRIFIER qu'aucune ancienne ne subsiste, un
   doublon produit des screenings en double. La cadence est décidée par
   Enguerran (30 min au lancement ; **horaire depuis le 25/08 14h50**).
5. **Le canal vers la conversation CHAPEAU.** Les points de pilotage remontent
   à la conversation « CHAPEAU LMS — trajectoire 4 sujets » par la
   **messagerie de sessions du poste** (`mcp__ccd_session_mgmt__send_message`,
   session retrouvée PAR SON TITRE via `list_sessions` — l'id change si la
   chapeau est recréée). ⚠️ Le canal inter-agents (`SendMessage`) ne la joint
   PAS (4 échecs vérifiés le 24/08) : ne pas y perdre de tentatives. Régime des
   points (mandat Enguerran 25/08) : un point à chaque screening PORTEUR,
   synthèse midi et soir même à vide, VITAL immédiat (chapeau ET Enguerran),
   rythme du testeur signalé (reprise, pause > 1 h, fin de session).
4. ~~L'adresse du tableau de bord publié~~ — plus rien à redonner depuis le
   24/08 : l'adresse ET la commande de publication sont écrites au §4.
   ⚠️ L'ancienne version de ce point disait « republier depuis la source du
   dépôt » : c'était FAUX le 24/08 — la source avait quatre jours de retard sur
   la page publiée. La règle vraie est au §4 : en cas de divergence, la page
   PUBLIÉE fait foi, jamais la source.

## 3. Le geste de reprise

1. Lire le cahier + le registre, puis les issues ouvertes des DEUX dépôts.
2. Recevoir le jeton Sentry et le mot de passe de recette.
3. Recréer la tâche de screening (après avoir vérifié qu'il n'y en a pas déjà).
4. Balayer la journée entière, trier, reporter au tableau de bord — puis
   **republier** (commit d'abord, le script du §4 refuse une source non commitée).

## 4. La page des testeurs — adresse et publication (la commande exacte)

La feuille de suivi que consulte le testeur est servie par staging, à une
adresse stable non devinable :

```
https://staging.efektiv-academie-dev.com/_recette/recette-0ts4w5xbdmin4v/
```

Côté serveur : `/var/www/staging.efektiv-academie-dev.com/_recette/recette-0ts4w5xbdmin4v/`
— `index.html` (la feuille, source : `docs/recette/tableau-de-bord.html`),
`cahier.html` (le cahier rendu, source de vérité : `CAHIER_RECETTE.md` ; le
rendu HTML versionné est un instantané, aucun générateur n'est versionné à ce
jour), et un `.htaccess` `RewriteEngine Off` qui n'est PAS au dépôt et ne doit
JAMAIS être écrasé. Le dossier est exclu du déploiement front
(`--exclude=/_recette/` dans les deux rsync de `deploy-staging.yml` du FRONT).

**Publier = trois gestes, dans cet ordre :**

1. éditer `docs/recette/tableau-de-bord.html` (et `docs/recette/cahier.html`
   si le cahier a changé) ;
2. **committer** — le script refuse une source non commitée ;
3. lancer `docs/recette/publier-recette.sh` — scp vers `/tmp` du serveur,
   `sudo install` en `www-data`, relecture `curl` de contrôle.

**La règle née de l'incident du 20→23/08** : la page a été tenue à jour
directement sur le serveur pendant quatre jours, SANS commit — la source du
dépôt affichait 27 KO quand la page réelle en affichait 16, et la session qui
savait publier s'est close. **Si la page publiée et la source divergent, la
page publiée fait foi** (c'est ce que le testeur a vu) : la rapatrier
(`curl -s <URL> > docs/recette/tableau-de-bord.html`), committer, puis
seulement republier. Ne JAMAIS republier une source dont on n'a pas vérifié
qu'elle est au moins aussi récente que la page en ligne.

## 4bis. La collecte des signalements — la commande exacte

Reconstituée le 24/08 (elle non plus n'était écrite nulle part). Les
signalements de recette sont du **user feedback Sentry** — organisation
`voltaire-digital`, projet `e-learning` (id `4510312056946768`). Le jeton :
`SENTRY_READ_TOKEN` dans le `.env` du clone principal BACK (jamais affiché,
jamais copié ailleurs ; scopes utiles : `event:read`, `project:read`,
`org:read`).

```bash
TOK=$(sed -n 's/^SENTRY_READ_TOKEN=//p' <clone BACK>/.env)
curl -s -H "Authorization: Bearer $TOK" \
  "https://sentry.io/api/0/organizations/voltaire-digital/issues/?query=issue.category%3Afeedback&statsPeriod=24h&project=4510312056946768&limit=100"
```

Chaque entrée porte `shortId` (le ticket `E-LEARNING-…` de la feuille de
suivi), `lastSeen`, et le message dans `metadata.message` (préfixé `Px.y
OK/KO/BUG` par convention ; les réponses aux questions arrivent préfixées
`REPONSE Qn`). ⚠️ Balayer la **journée entière** (`statsPeriod=24h` ou plus),
jamais une fenêtre courte ; contrôler la **release** de l'événement avant de
trier un KO. L'ancien endpoint `/projects/…/user-feedback/` renvoie zéro :
c'est la catégorie d'issue `feedback` qui fait foi.

⚠️ Piège vécu (24/08) : en replaçant les secrets dans le `.env`, les chevrons
du modèle (`SENTRY_READ_TOKEN=<sntryu_…>`) étaient restés autour des valeurs —
l'API répond alors « Authentication credentials were not provided ». La valeur
se colle NUE, sans `<>`, sans guillemets, sans espace.

## 4ter. La recette connectée — la commande exacte

Reconstituée le 25/08 (le 404 sur `/api/...` a coûté trois essais). La base API
de staging N'EST PAS `/api` à la racine : elle se lit dans `VITE_APP_API` du
`.env` du clone FRONT —
`https://api-staging.efektiv-academie-dev.com/e-learning-api/public/api`.

```bash
# connexion (POST /session/login) — le mot de passe vient du .env, jamais affiché
curl -X POST "$BASE/session/login" -H "Content-Type: application/json" \
  -d '{"email":"recette-claude-managerrh@yopmail.com","password":"<RECETTE_PASSWORD>"}'
# → jeton Bearer pour les routes authentifiées (ex. GET $BASE/manager/pilotage/dashboard)
```

Comptes : `recette-<personne>-<suffixe>@yopmail.com` — le schéma exact (personnes,
suffixes, correspondance suffixe→rôle, ET le piège managerrh/manager) vit dans
`app/Support/Recette/ComptesDeRecette.php`. **Le jeu `claude` est celui du
pilote** ; `david`, `eng`, `lilian` appartiennent aux humains. Connexions
espacées de ~20 s ; le jeton API s'efface en fin de passe.

## 4quater. Le régime de tri en vigueur (état au 25/08)

- **Jalon obligatoire à la création d'issue** (règle Enguerran 25/08 15h) :
  **« Avant bascule »** (le cas normal d'un bug de recette) ou
  **« Post-bascule »** (n'empêche pas la mise en production). Jamais L4.8 pour
  une issue neuve ; pas de rétro-correction des issues existantes (lotissement).
  ⚠️ Les jalons ont été renommés le 25/08 (« V1 · L5 » → « Avant bascule »,
  « V2 » → « Post-bascule ») : vérifier les titres à l'instant T.
- **Fermeture = règle des deux volets** : re-passe humaine sur le visible +
  mesure serveur datée sur l'invisible, les deux tracées dans l'issue —
  codifiée dans `TRAITEMENT_DES_BUGS.md` (PR #661).
- **Chantiers parallèles** : relire l'état d'une issue à l'instant T avant d'y
  toucher ; un correctif déployé sur staging hors journal des correctifs de la
  feuille = **incident à remonter à la chapeau**, pas à absorber.
- **Coordination infra** : toute communication aux testeurs sur l'infrastructure
  ou les environnements passe par la chapeau, jamais par le pilote directement ;
  le pilote lui signale le rythme du testeur (fenêtres calmes).
- **Mises à jour de la feuille** : chaque lot d'éditions part d'une branche
  fraîche depuis `origin/development` (ou continue une PR ENCORE OUVERTE —
  vérifier avant chaque commit : un commit poussé sur une branche dont la PR
  est fusionnée est orphelin, vécu le 25/08 avec le correctif charset, rattrapé
  par cherry-pick en PR #660).

## 5. La règle qui a produit ce document

Deux pertes réelles le 19/08 : la **procédure de déploiement**, qui ne vivait
que dans la tête du pilote et a disparu à une compaction de contexte ; et deux
**specs produit** déclarées « non tracées » alors qu'elles existaient dans
l'autre dépôt depuis la veille.

**Ce qui n'est pas écrit dans le dépôt n'existe pas — et ce qui n'est cherché
que dans un seul dépôt est réputé inexistant à tort.**