Administrer une interface web de bout en bout
Configurer un tableau de bord, faire tourner une billetterie par sa propre interface d’administration. Un travail en plusieurs étapes, authentifié — frictions rencontrées en chemin comprises.
Le plus lourd des cas de démonstration, et celui qui en dit le plus sur ce qu’un agent peut réellement porter : piloter une interface d’administration comme le ferait une personne, en plusieurs étapes, derrière une connexion.
Et non éditer à la main des fichiers de configuration pour des étapes que l’interface existe justement pour prendre en charge.
Mettre en place un tableau de bord auto-hébergé
Un opérateur qui installe un tableau de bord de supervision ou de mesure d’audience derrière un proxy inverse : créer un tableau de bord, brancher une source de données, régler une règle d’alerte. Le tout par l’interface, piloté par l’agent.
Cela vaut aussi pour les cibles placées derrière une authentification HTTP Basic au niveau du réseau — celle qu’un proxy inverse ajoute devant tout :
{"http_credentials": true, "url": "https://target.local/admin", "actions": [...]}
Confirmé sur une vraie interface protégée par un proxy, et non sur une page de
test synthétique : les identifiants résolus depuis le répertoire chiffré ont
répondu à la demande dès la première tentative. Le scénario ne nomme toujours
aucun secret — http_credentials dit à Diwall de les lire dans ce répertoire,
pour cette seule origine.
Faire tourner une billetterie
Sur plusieurs sessions : création de l’événement, catégories de billets, un domaine personnalisé, et l’outil de contrôle des entrées utilisé le jour même. Un vrai travail de configuration, par la même interface web qu’utiliserait un administrateur humain.
Ce n’était pas une réussite sans accroc, et c’est justement ce qui la rend bonne à raconter.
La gestion de session a dû être mise au point. Une liste déroulante s’est comportée de façon inattendue. Une demande d’autorisation a bloqué une étape sans surveillance et a dû être traitée explicitement.
Aucun de ces problèmes ne venait de Diwall. C’étaient des obstacles ordinaires de l’automatisation web — ceux que rencontrerait toute personne qui automatise cette interface. Une démonstration qui les cache n’apprend rien sur ce que le travail coûte vraiment.
Chacun a désormais sa recette :
Ce qui fait marcher ce cas
Un seul appel pour tout ce qui a un état. Connexion, action, confirmation — en une seule invocation. Découper en plusieurs appels perd l’état du DOM, sans rien dire.
Une vérification en tête. Si la page n’est pas celle attendue, on s’arrête avant de taper quoi que ce soit où que ce soit.
Le répertoire chiffré pour chaque identifiant. Le scénario reste versionnable parce qu’il nomme des clés, jamais des valeurs.
Des signaux lus, pas seulement le verdict. Après chaque étape : où suis-je vraiment, qu’a répondu le serveur, la session a-t-elle tenu.
Où cela s’arrête
Les opérations de plusieurs minutes s’y prêtent mal — on voit la fin, pas le milieu, et un délai dépassé ne veut pas dire un échec. Les modifications en masse passent mieux par une API quand il en existe une. Et rien ici ne peut être annulé : Diwall exécute la liste que vous avez écrite.
Pourquoi aucun scénario n’est livré pour ce cas. La disposition d’un tableau de bord, les noms des sources de données, la configuration d’une billetterie — tout cela est propre à l’infrastructure d’un opérateur. En inventer un équivalent synthétique ne montrerait rien que le cas local exécutable ne couvre déjà.