La page ne finit jamais de se charger, quel que soit le délai que vous définissez

Dix secondes, échec. Quarante-cinq secondes, échec identique. La cible n'est pas lente ; elle ne sera jamais terminée, et aucun délai d'attente ne changera cela.

Le symptôme. TimeoutError lors de la navigation initiale. Vous augmentez --timeout de 10 secondes à 45 secondes. Le problème se reproduit, exactement de la même manière.

La même panne se produit à chaque fois : il ne s’agit pas d’un problème de durée.

Ce que Dinoer attend

Par défaut, la navigation se termine sur networkidle — 500 ms de silence réseau. C’est un bon paramètre par défaut : cela signifie que la page s’est réellement chargée, les scripts ont été exécutés et le contenu est arrivé.

Certains équipements ne cessent jamais de communiquer. Un tableau de bord actualisant des compteurs, un panneau d’affichage statistique en direct, une interface d’administration de routeur interrogeant son propre état — ils continuent de communiquer avec le réseau par conception. Il n’y a aucun moment de silence à attendre, donc Dinoer attend jusqu’à la fin du délai imparti, à chaque fois, quelle que soit sa durée.

Modifiez 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 déclenche lorsque l’événement de chargement de la page est activé, sans nécessiter une absence de trafic réseau. Le même indicateur existe sur rpa.py et est propagé aux escalades déclenchées par les campagnes.

Un scénario peut l’inclure comme propriété racine, ce qui le rend autonome : la personne qui réutilise votre scénario n’a pas besoin de connaître les particularités de la cible :

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

La ligne de commande l’emporte sur le scénario. Contrairement aux options booléennes qui se combinent, celle-ci transporte une valeur, et deux valeurs ne s’additionnent pas. Si les deux sont définies, c’est le paramètre qui décide.

Quelle valeur utiliser ?

Valeur	Complétion	Utilisez-la lorsque
`networkidle`	500 ms de silence réseau	par défaut - conservez cette valeur sauf en cas d’échec
`load`	événement de chargement de la page	le composant interroge continuellement
`domcontentloaded`	HTML analysé, ressources secondaires en attente	vous avez besoin de l’affichage le plus rapide possible

Ne recourez pas à load par précaution. La valeur par défaut vous donne une page qui a fini d’arriver ; la changer revient à accepter qu’un contenu puisse encore être en transit au moment où la réponse est produite. Changez-la quand la valeur par défaut échoue, pas avant.

Comment distinguer cela d’une page qui se charge lentement ?

Une page qui se charge lentement réussit si vous attendez suffisamment longtemps ; augmenter le délai d’attente modifie le résultat. Une page qui ne reste jamais inactive échoue de la même manière, quelle que soit la durée.

Le test est donc peu coûteux : exécutez-le deux fois, une fois avec les paramètres par défaut et une fois avec un délai d’attente beaucoup plus long. Même échec, même vitesse ? Modifiez la condition. Comportement différent ? Vous avez un simple système lent, et le délai d’attente est le paramètre à ajuster.

En bref

Échec identique à 10 secondes et à 45 secondes = problème de condition, pas de durée.
--wait-until load pour les cibles qui interrogent en continu.
Placez-le dans le scénario afin qu’il voyage avec la cible.
Conservez networkidle partout ailleurs.