Automatiser une tâche web : agent, script ou RPA ?

Vous voulez automatiser une tâche web sans construire une usine à gaz ? Commencez par un script lorsque le parcours est prévisible. Passez à un agent si l’interface doit être interprétée, et réservez la RPA aux processus qui traversent plusieurs applications. Dans la plupart des cas complexes, la meilleure réponse combine ces approches plutôt que d’en imposer une partout.

Toutes les tâches répétitives ne méritent pas un navigateur#

La répétition ne suffit pas. Une tâche vaut la peine d’être automatisée si son entrée est identifiable, son résultat vérifiable et son échec récupérable. Extraire un catalogue, télécharger des factures, contrôler une mention réglementaire ou rejouer un parcours fonctionnel répond à ces critères.

Le navigateur devient en revanche un mauvais investissement pour une opération rare et très courte. Même réserve lorsque chaque cas exige une décision métier difficile à formaliser : le temps économisé à l’exécution réapparaît alors dans la supervision.

Les cas solides dépassent largement la veille tarifaire :

• Extraction : prix, stocks, documents, statuts ou données d’annuaire.
• Vérification : conformité d’une page, cohérence d’un compte, présence d’une information.
• Exécution : saisie, dépôt de fichier, création ou mise à jour d’un enregistrement.
• Test et relevé : parcours fonctionnel, capture de preuve, mesure ou comparaison périodique.

Une collecte de prix relève du même choix d’architecture. Elle ajoute ensuite des contraintes propres aux données, détaillées dans ce guide sur le scraping des prix concurrents. La fréquence des relevés et le traitement des écarts sont abordés dans ce guide pour surveiller les prix des concurrents.

Automatiser une tâche web sans surdimensionner l’architecture#

Le premier réflexe devrait être de chercher un contrat plus stable que l’interface. Une API officielle, un export ou un flux structuré réduit le nombre d’états intermédiaires, facilite les contrôles et coûte moins cher à exécuter. Le navigateur reste pertinent lorsque ces voies n’existent pas ou ne couvrent pas l’action attendue.

Pour le reste, l’ordre de choix doit être tranché :

1. Script déterministe si le parcours et le résultat peuvent être décrits précisément.
2. RPA si le processus traverse le navigateur, le poste de travail et plusieurs applications métier.
3. Agent navigateur si l’action dépend du sens de la page ou d’un chemin variable.
4. Architecture hybride si seules certaines étapes exigent cette interprétation.

L’hybride n’est pas un compromis tiède. C’est souvent le bon découpage. Un ordonnanceur prépare les entrées, le script exécute les étapes stables, l’agent traite une bifurcation, puis des règles contrôlent la sortie. Confier l’ouverture d’une URL connue ou un téléchargement prévisible à un agent ajoute du coût et de l’incertitude sans gagner de robustesse.

Matrice pour choisir entre script, agent navigateur et RPA#

Cette matrice donne un point de départ. Elle évite surtout de choisir selon la démonstration la plus séduisante plutôt que selon les contraintes d’exploitation.

Choisissez le script pour une extraction nocturne volumineuse sur un DOM prévisible. Playwright attend notamment qu’un élément soit visible, stable, activé et capable de recevoir l’événement avant certains clics, selon sa documentation sur l’actionnabilité¹. Ces contrôles éliminent une partie des erreurs de synchronisation. Ils ne détectent pas un bouton dont l’apparence reste identique alors que la fonction change.

Choisissez l’agent pour retrouver un document dont le libellé, l’emplacement ou le chemin diffère selon les comptes. Il peut interpréter le texte, la structure et la présentation. En revanche, ne lui déléguez pas seul une publication, une suppression, une commande ou une modification financière.

Choisissez la RPA pour un flux qui lit une pièce jointe, ouvre un portail, met à jour un logiciel Windows puis produit un compte rendu dans Excel. Sa valeur vient de l’orchestration transverse, des coffres de secrets, des files de travail et de l’administration centralisée. Pour un parcours purement web maintenu par des développeurs, cette couche devient souvent une taxe.

Chiffrer la fragilité plutôt que le coût du premier développement#

Le devis initial mesure mal l’arbitrage. Le coût annuel pertinent inclut la construction, les exécutions, la supervision, la maintenance et les erreurs :

coût total = construction + exécutions + supervision + maintenance + coût attendu des erreurs

Le dernier terme s’estime ainsi :

probabilité d’erreur × nombre d’exécutions × impact moyen

Prenons une hypothèse de dimensionnement : 20 000 actions mensuelles, 0,5 % de résultats incorrects et 8 € de traitement par anomalie. La reprise atteint alors 800 € par mois. Ces valeurs ne constituent pas une référence de marché ; elles montrent pourquoi un faible taux d’erreur peut dominer le coût total.

L’impact compte davantage que le taux moyen. Si une mauvaise action peut engager une commande de 10 000 €, selon une hypothèse propre au processus, une validation humaine devient rationnelle même lorsque les erreurs sont rares. Un taux de réussite global ne suffit donc jamais à qualifier une automatisation sensible.

Grille de départ pour noter la fragilité#

Attribuez de 0 à 2 points à chacun des axes suivants. Cette échelle est une grille de cadrage, à recalibrer après le pilote :

• variation du DOM ou de la mise en page ;
• diversité des comptes, pays, langues ou rôles ;
• authentification, MFA et expiration des sessions ;
• dépendance à un état antérieur du parcours ;
• fréquence des changements imposés par l’éditeur.

Un score de 0 à 3 oriente vers un script classique. Entre 4 et 7, isolez les zones instables ou introduisez une capacité agentique ciblée. Entre 8 et 10, partez du principe qu’une supervision sera nécessaire tant qu’un échantillon représentatif n’aura pas prouvé le contraire.

Le volume accentue les conséquences du choix. Il rentabilise le développement déterministe, mais multiplie les erreurs silencieuses. À faible fréquence, une exécution assistée peut coûter moins cher qu’un système autonome maintenu toute l’année.

La preuve du résultat compte davantage que le clic#

Une automatisation n’est pas terminée lorsqu’elle atteint la dernière page. Elle l’est lorsque le système peut établir que le résultat attendu existe. Chaque étape décisive doit associer action, assertion et preuve.

Après un téléchargement, contrôlez le nom, le type, une taille minimale adaptée au fichier et, si possible, son contenu. Après une saisie, relisez la valeur affichée ou enregistrée. Après une publication, recherchez l’identifiant créé. Une notification verte peut confirmer la réception de la demande sans prouver son traitement.

Pour chaque exécution, conservez les éléments nécessaires au diagnostic :

• l’identifiant du run et la version du scénario ;
• les entrées utiles, sans secrets ;
• l’heure et l’URL des étapes décisives ;
• les sorties structurées et le résultat des assertions ;
• une capture ou une trace lors d’un écart ;
• la décision de l’agent et son niveau de confiance lorsqu’il intervient.

Une trace exhaustive de chaque succès coûte cher et augmente l’exposition de données sensibles. Conservez les résultats structurés pour tous les runs, puis les traces détaillées pour les échecs et un échantillon défini des succès. Le Trace Viewer de Playwright² permet notamment d’inspecter actions, journaux, requêtes réseau, captures et instantanés du DOM.

La bonne question n’est pas « que pouvons-nous enregistrer ? », mais quelle preuve autorise l’étape suivante ? Sans réponse explicite, l’observabilité produit des archives, pas une décision exploitable.

1. 01Déclencher la tâche
2. 02Observer l’état réel
3. 03Exécuter l’action
4. 04Vérifier le résultat
5. 05Conserver la preuve
6. 06Reprendre ou alerter

La reprise doit précéder le cas nominal#

Relancer tout un parcours après un échec peut dupliquer une commande, un message ou un dossier. Découpez le travail en étapes idempotentes et conservez leur état : à faire, commencé, confirmé ou en anomalie.

Un retry convient à une attente réseau ou à un composant temporairement indisponible. Il ne corrige ni une session expirée, ni un parcours modifié, ni une décision ambiguë. Comme seuil de départ, après deux tentatives identiques, changez de stratégie ou ouvrez une reprise humaine. Ajustez ensuite ce seuil selon la télémétrie du processus.

L’autoréparation des sélecteurs exige la même discipline. Microsoft indique que le mécanisme de self-healing de Power Automate³ peut identifier un élément non souhaité. Retrouver un élément visuellement ou structurellement proche ne prouve pas que l’action conserve son sens métier.

Prévoyez des issues distinctes :

• succès confirmé, accompagné de la preuve attendue ;
• échec technique, relançable depuis un état connu ;
• ambiguïté métier, transmise à un opérateur avec le contexte déjà collecté.

Cette séparation évite de transformer chaque doute en échec technique ou, pire, chaque absence d’erreur en succès.

Checklist de mise en production#

Cadrage#

• Le résultat possède-t-il une assertion indépendante du clic final ?
• Une API, un export ou un flux structuré peut-il éviter une partie du navigateur ?
• Le volume, la fréquence et le temps manuel sont-ils mesurés ?
• Le coût maximal d’une mauvaise action est-il documenté ?
• Les conditions d’utilisation du site autorisent-elles l’exécution prévue ?

Architecture#

• Les étapes stables restent-elles déterministes ?
• L’agent intervient-il uniquement sur des décisions ambiguës ?
• Les écritures sensibles passent-elles par une validation ou un plafond ?
• Chaque étape peut-elle être rejouée sans doublon ?
• Les identifiants métier remplacent-ils les positions visuelles lorsqu’ils existent ?

Exploitation#

• Les secrets restent-ils hors des journaux et des instructions transmises à l’agent ?
• Le scénario traite-t-il MFA, session expirée, fenêtre parasite et changement de langue ?
• Les assertions détectent-elles un résultat plausible mais faux ?
• Chaque anomalie possède-t-elle un responsable et un délai de traitement ?
• Les traces permettent-elles de reconstruire la décision sans exposer de données inutiles ?
• Une alerte signale-t-elle une dérive du taux de succès, de la durée ou du volume traité ?

Le pilote doit utiliser des cas représentatifs et les contrôles prévus pour la production. Mesurez séparément le succès technique, la justesse métier et l’intervention humaine. Un run qui atteint la dernière page tout en enregistrant la mauvaise donnée doit apparaître comme un échec, pas comme une exécution réussie.