Avant de laisser un AI Agent agir sur des sites web, vérifiez la chaîne entre environnement et Agent selon quatre niveaux : test fumée en une étape, tâches multi-étapes, charge concurrente et injection de pannes, avec des métriques dédiées.
Réussir une fois dans un environnement de démonstration ne signifie pas que la même chaîne est fiable au quotidien.
Pour l’évaluer, il faut séparer les tests : valider l’environnement à son niveau, valider l’Agent au sien, puis vérifier si l’ensemble reste stable une fois connecté.
Test fumée en une étape : quatre actions séparées
Le test fumée ne fait que quatre choses, chacune séparément et sans les enchaîner : ouvrir une page précise ; localiser un élément ; cliquer dessus ; récupérer le texte de cet élément. Si les quatre réussissent, les bases de connexion, de session et d’accès aux éléments fonctionnent.
Limiter le test à quatre actions réduit fortement la surface de panne. Si la page ne s’ouvre pas, le problème vient souvent de la sortie réseau ou des droits d’accès. Si elle s’ouvre mais que l’élément reste introuvable, la page n’était peut-être pas entièrement chargée ou la méthode de localisation dépend trop de la mise en page actuelle. Si l’élément est localisé mais impossible à cliquer, vérifiez s’il est masqué ou placé dans un iframe. Si le texte renvoyé est vide, confirmez d’abord que vous lisez le contenu rendu et non le HTML initial.
Trois chiffres sont à suivre : taux de réussite par étape, durée par étape et répartition des types d’erreur. Ils doivent déjà être stables au stade du test fumée. Si le taux de réussite d’une étape oscille seulement autour de 80 à 90 %, les tests suivants n’ont guère de valeur.
Tâches multi-étapes : les branches comptent plus que le nombre d’étapes
Enchaînez les quatre actions dans une tâche réelle, par exemple remplir un formulaire, parcourir plusieurs pages, filtrer selon des conditions et réécrire le résultat en local. Ajouter des étapes n’est qu’un changement de volume ; la vraie difficulté vient des branches : apparition d’un message, disparition de l’élément cible, redirection automatique de la page ou étape de vérification nécessitant une confirmation humaine.
Ici, on regarde le taux d’achèvement de la tâche, pas le taux de réussite des étapes. Après un échec, la capacité de l’Agent à ajuster son parcours et à savoir quand s’arrêter pour signaler clairement le problème est plus importante que le simple fait d’aller jusqu’au bout.
Un autre chiffre souvent négligé est le nombre d’interventions humaines. Si la même tâche est exécutée vingt fois, le nombre d’interventions et l’étape où chaque blocage survient renseignent mieux sur la maturité de la chaîne que le taux global d’achèvement.
Concurrence et injection de pannes
Une fois une chaîne unique stable, ajoutez de la concurrence. Lancez plusieurs environnements simultanément sur le même type de tâche et observez s’ils se perturbent mutuellement et si le taux d’échec se dégrade à mesure que la concurrence augmente. À ce stade, les échecs proviennent souvent d’une saturation des ressources ou des sessions, plutôt que d’une erreur de logique de l’Agent.
L’injection de pannes est l’un des tests les plus souvent sautés et pourtant l’un des plus nécessaires. Provoquez volontairement des timeouts, la disparition d’éléments, l’expiration de sessions et l’apparition de CAPTCHAs, puis observez la réaction : après un timeout, une nouvelle tentative réussit-elle ou le processus reste-t-il bloqué ; après expiration de la session, la chaîne signale-t-elle clairement l’erreur ou continue-t-elle avec des identifiants invalides ?
Suivez trois métriques : courbe du taux d’échec sous concurrence, taux de récupération après anomalie et temps supplémentaire causé par une anomalie. Un faible taux de récupération signifie que la chaîne ne fonctionne que lorsque les conditions sont favorables.
Valider séparément la couche environnement
Les tests précédents se déroulent dans un seul environnement, mais plusieurs environnements utilisés ensemble exigent une validation supplémentaire : chacun doit pouvoir démarrer indépendamment, conserver sa propre session et son propre cache, et être lié à sa propre IP de sortie.
Les équipes qui exploitent plusieurs comptes gèrent généralement un environnement par compte. Des outils comme PurpleMark fournissent une isolation des environnements afin d’offrir à chaque compte un espace d’exécution indépendant. Pour tester, lancez plusieurs environnements en parallèle et vérifiez que Cookies, caches et sorties ne se mélangent pas.
Trois chiffres sont à observer : taux de réussite du démarrage des environnements, interférence de données entre environnements (normalement zéro) et continuité de la session après reconstruction d’un environnement.
Comment attribuer un échec
Lorsqu’un problème survient dans la chaîne, une erreur fréquente consiste à modifier immédiatement le script de l’Agent. Un ordre plus rationnel est de vérifier d’abord que l’environnement démarre et que la session n’a pas expiré, puis de contrôler la sortie réseau et les nœuds, et seulement ensuite de suspecter la localisation des éléments et la planification des tâches par l’Agent. Inverser cet ordre conduit à modifier sans cesse la mauvaise partie.
Les quatre actions du test fumée servent aussi d’outil d’attribution. Après chaque échec, relancez-les séparément et observez quel maillon casse en premier. La réponse apparaît le plus souvent à cette étape.
