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

Dix secondes : échec. Quarante-cinq secondes : échec identique. La cible n’est pas lente — elle ne sera jamais terminée, et aucun délai n’y changera rien.

Le symptôme. TimeoutError sur la navigation initiale. Vous passez --timeout de 10 s à 45 s. Nouvel échec, exactement le même.

C’est ce même échec qui fait le diagnostic : ce n’est pas un problème de durée.

Ce que Diwall attend

Par défaut, la navigation se termine sur networkidle — 500 ms de silence réseau. C’est un bon défaut : il signifie que la page s’est vraiment stabilisée, que les scripts ont tourné, que le contenu est arrivé.

Certaines cibles ne se taisent jamais. Un tableau de bord qui rafraîchit des compteurs, un panneau de statistiques en direct, l’interface d’administration d’un routeur qui interroge son propre état — ils parlent au réseau en permanence, par construction. Il n’y a aucun moment de calme à attendre : Diwall attend donc jusqu’au délai, à chaque fois, quelle que soit sa durée.

Changer la condition, pas la durée

diwall-shot --url http://target.local/ --wait-until load --som --a11y \
  --guide-version 1.3

--wait-until load se termine quand l’événement de chargement de la page se déclenche, sans exiger de silence réseau. La même option existe sur diwall-rpa, qui la transmet.

Un scénario peut la porter comme propriété de premier niveau, pour rester autonome — celui qui réutilise votre scénario n’a pas à connaître la manie 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 cumulent, celle-ci porte une valeur — et deux valeurs ne s’additionnent pas. Si les deux sont renseignées, c’est l’option de la ligne de commande qui décide.

Quelle valeur choisir

Valeur	Se termine sur	À utiliser quand
`networkidle`	500 ms de silence réseau	c’est le défaut — gardez-le tant qu’il marche
`load`	l’événement de chargement de la page	la cible interroge le réseau en continu
`domcontentloaded`	HTML analysé, sous-ressources en attente	il vous faut la vue la plus précoce possible

N’allez pas chercher load par précaution. Le défaut vous donne une page qui a fini d’arriver ; en changer revient à accepter qu’une partie du contenu soit encore en route au moment de la capture. Changez-le quand le défaut échoue, pas avant.

La distinguer d’une page simplement lente

Une page lente finit par réussir si l’on attend assez — relever le délai change le résultat. Une page qui ne se tait jamais échoue à l’identique, quelle que soit la durée.

Le test ne coûte donc presque rien : lancez deux fois, une fois avec le délai par défaut, 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 ordinairement lente, et c’est bien le délai qu’il faut régler.

En bref

Échec identique à 10 s et à 45 s = mauvaise condition, pas mauvaise durée.
--wait-until load pour les cibles qui interrogent le réseau en continu.
Mettez-le dans le scénario, pour qu’il voyage avec la cible.
Gardez networkidle partout ailleurs.