La session n'est pas conservée entre deux appels

Le symptôme. Vous découpez un travail en deux appels. Le premier s’authentifie et enregistre la session ; le second la réutilise. Soit le second appel retombe sur la page de connexion, soit — et c’est pire — il renvoie succes: true en une seconde environ et ne change rien sur la cible.

Ce qui se passe réellement

Une session enregistrée est un storage_state de Playwright : les cookies et le localStorage, rien d’autre. Deux choses n’y sont pas, et ce sont justement celles qui vous font tomber.

L’état du DOM n’y est pas. Une case que vous avez cochée, un <select> que vous avez réglé, une boîte de dialogue ouverte — tout disparaît à la reprise. La page revient vierge. Vos actions numérotées s’exécutent alors sur une page neuve, touchent l’élément qui porte désormais ce numéro, et annoncent un succès. Aucune erreur, parce que rien n’a mal tourné du point de vue de Diwall : il a cliqué sur l’élément 7, et l’élément 7 existait.

La session côté serveur n’y est pas non plus. Beaucoup d’applications appellent un équivalent de session_regenerate_id() juste après la connexion. Le cookie que vous avez enregistré est celui d’avant la régénération. L’instantané côté client est parfaitement valide, et parfaitement inutile.

La règle

Ne découpez jamais un travail avec état. Connexion, action et confirmation en un seul appel, même s’il faut se reconnecter.

Mesuré sur une cible réelle : la version en un seul appel a pris 7,5 secondes et a marché ; la version découpée a pris 1,1 seconde et n’a rien fait, sans rien dire. La rapide est celle qui a échoué.

Un seul appel prend un tableau d’actions — c’est toute la raison d’être du tableau :

diwall-shot --url https://target.local/login --som --guide-version 1.3 \
  --actions '[
    {"type": "remplir_som", "id": 4, "valeur": "depuis_secrets", "secret_cle": "username"},
    {"type": "remplir_som", "id": 5, "valeur": "depuis_secrets", "secret_cle": "password"},
    {"type": "cliquer_som", "id": 7},
    {"type": "attendre_selecteur_present", "selecteur": ".user-menu"},
    {"type": "cliquer_som", "id": 12}
  ]'

Un lancement de navigateur, une capture finale. La version découpée coûte un démarrage de Playwright, un rechargement du stockage et un nouveau calcul complet de Set-of-Mark à chaque appel — elle est plus lente à chaque étape, et elle perd votre état entre les deux.

Quand la persistance est le bon outil

La persistance de session n’est pas un piège, c’est un outil à l’usage étroit : lire plusieurs pages authentifiées qui ne dépendent pas les unes des autres. Un tableau de bord, puis une page de réglages, puis un rapport — chacun autonome.

# S'authentifier une fois
diwall-shot --url https://target.local/login --som --guide-version 1.3 \
  --actions login.json --sauver-session ~/session.json

# Lire autant de pages indépendantes que vous voulez
diwall-shot --url https://target.local/dashboard --som --guide-version 1.3 \
  --reprendre-session ~/session.json

Depuis la 1.11.1, le fichier de session n’est plus supprimé en fin d’exécution : les appels enchaînés sont sûrs. Ne remettez --sauver-session que pour rafraîchir volontairement l’état enregistré.

La ligne à tenir : la persistance transporte qui vous êtes, pas ce que vous étiez en train de faire.

Lire la réponse, pas seulement le verdict

Chaque appel après --reprendre-session vous dit si la session a tenu :

"boussole": {
  "session_derive": true,
  "url_courante": "https://target.local/login",
  "dernier_code_http": 302
}

session_derive: true veut dire que vous n’êtes plus là où vous le croyiez. Relancez la connexion complète, sans --reprendre-session.

Lisez ensuite dernier_code_http, car deux pannes très différentes se ressemblent trait pour trait. Une session réellement expirée et une erreur applicative masquée par display_errors=0 vous déposent toutes deux sur la page de connexion avec session_derive: true. Un 302 ou un 200 désigne une vraie expiration — reconnectez-vous. Un 500 ou un 4xx signifie que l’application a cassé et que votre session n’a jamais été en cause ; vous reconnecter ne fera que vous faire perdre du temps.

Une nuance : sur une exécution comportant plusieurs actions naviguer, ce champ ne reflète que la dernière navigation, qui n’est pas forcément celle qui explique la dérive.

En bref

• Avec état — connexion, action, confirmation : un appel, un tableau d’actions.
• Sans état — lecture de pages authentifiées indépendantes : la persistance convient.
• Après chaque reprise : regardez session_derive, puis dernier_code_http.
• Un succes: true rapide sur un travail que vous attendiez lent est un avertissement, pas un résultat.