La page n'en finit pas de charger, quel que soit le délai

Dix secondes échouent. Quarante-cinq secondes échouent de la même façon. La cible n'est pas lente : elle ne finit jamais, et aucun délai n'y changera rien.

Le symptôme. Un TimeoutError sur la première navigation. Vous passez --timeout de 10 s à 45 s, et l’échec se reproduit, exactement de la même façon.

Cet échec identique est le diagnostic : le problème n’est pas la durée.

Ce qu’attend Dinoer

Par défaut, la première navigation se termine sur networkidle : 500 ms sans trafic réseau. C’est un bon réglage, car il signifie que la page s’est vraiment stabilisée : les scripts ont tourné, le contenu est arrivé.

Certaines cibles ne se calment jamais. Un tableau de bord qui rafraîchit ses compteurs, un panneau de statistiques en direct, la page d’administration d’un routeur qui interroge son propre état : elles utilisent le réseau en permanence, par construction. Il n’y a pas de moment de calme à attendre ; Dinoer attend donc jusqu’à l’expiration du délai, à chaque fois, quelle qu’en soit la durée.

Changer la condition, pas la durée

/opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url http://target.local/ --wait-until load --a11y \
  --guide-version 1.6

--wait-until load se termine quand l’événement load de la page se déclenche, sans exiger de silence réseau. La même option existe sur rpa.py. Elle ne porte que sur la première navigation, pas sur les actions naviguer, et les escalades lancées par campagne.py gardent le réglage par défaut.

Un scénario peut la porter comme propriété racine, pour que celui qui le réutilise n’ait pas à connaître la particularité de la cible :

{"url": "http://target.local/", "wait_until": "load", "actions": [...]}

La ligne de commande l’emporte sur le scénario Cette option porte une valeur, et deux valeurs ne se combinent pas. Si les deux sont définies, c’est l’option de la ligne de commande qui décide.

Quelle valeur choisir

Valeur	Se termine sur	À utiliser quand
`networkidle`	500 ms sans trafic réseau	par défaut : gardez-la sauf si elle échoue
`load`	l’événement `load` de la page	la cible interroge le serveur en continu
`domcontentloaded`	le HTML analysé, les autres ressources encore en chargement	vous voulez la vue la plus précoce possible

Ne passez pas à load par anticipation. Le réglage par défaut vous donne une page entièrement arrivée ; le changer, c’est accepter qu’une partie du contenu soit encore en chargement au moment de la réponse. Changez-le quand le réglage par défaut échoue.

La distinguer d’une page lente

Une page lente réussit si l’on attend assez : relever le délai change l’issue. Une page qui ne se calme jamais échoue de la même façon quelle que soit la durée.

Le test ne coûte presque rien : lancez-la une fois avec le délai par défaut et une fois avec un délai bien plus long. Même échec, même vitesse ? Changez la condition. Comportement différent ? Vous avez une cible simplement lente, et le délai est le bon réglage.

En bref

Le même échec à 10 s et à 45 s signale une mauvaise condition, pas une mauvaise durée.
--wait-until load pour les cibles qui interrogent le serveur en continu.
Mettez-la dans le scénario pour qu’elle accompagne la cible.
Gardez networkidle partout ailleurs.