On me demande de plus en plus souvent de faire piloter un back-office par un agent, dans un navigateur, parce que l'outil en question n'expose rien : pas d'API sur l'abonnement en cours, pas de connecteur, pas de webhook. C'est faisable, j'en fais tourner. Mais une chaîne qui passe par une interface n'a pas les mêmes propriétés qu'une chaîne qui passe par une API, et traiter les deux de la même façon est ce qui coûte le plus cher.
Trois niveaux de fiabilité, pas un
Avant d'écrire quoi que ce soit, je classe la tâche dans l'un de ces trois paniers.
Lire. Récupérer un état, une liste, un chiffre, un historique. C'est le cas le plus solide : si la lecture échoue, elle échoue visiblement et il ne s'est rien passé. Tu peux relancer dix fois sans conséquence.
Écrire dans un formulaire stable. Remplir toujours les mêmes champs, enregistrer, recommencer. Ça tient, à condition d'accepter une supervision et de vérifier chaque enregistrement après coup plutôt que de faire confiance au clic.
Écrire dans un flux à état. Tout ce qui déclenche une validation côté plateforme, une publication, une modération, un envoi. C'est là que les choses dérapent, parce que ton agent voit l'interface mais pas la décision prise derrière. Il croit avoir terminé ; en réalité quelque chose est en attente, ou a été refusé silencieusement.
La règle que j'applique : plus on descend dans cette liste, plus il faut un humain dans la boucle et une vérification explicite de l'état final.
Ce qui casse, ce n'est pas ton script
Quand une automatisation d'interface échoue, le réflexe est de croire qu'on a mal cliqué. Presque jamais. Ce qui casse, c'est le rendu de la page, et c'est un terrain beaucoup moins stable qu'un endpoint.
Les cas que je rencontre, dans tous les outils, sans exception :
- Une modale met quinze à trente secondes à s'afficher, et le clic parti pendant ce temps-là est perdu.
- Un champ ne se rend qu'au deuxième passage, alors que rien ne distingue le premier du second.
- Une liste ne défile ni à la molette ni à l'ascenseur, et seul le clavier permet d'atteindre ce qui est sous la ligne de flottaison.
- Un panneau entier est invisible pour la lecture du texte de la page, alors qu'il s'affiche parfaitement à l'écran.
- La position d'un bouton change selon la longueur du contenu au-dessus de lui.
Trois conséquences pratiques. Ne jamais traiter le nombre de clics ou de tabulations comme une constante : c'est vrai le jour où tu le mesures, pas le lendemain. Attendre un élément identifiable, jamais un délai fixe. Et se repérer à un texte visible à l'écran — un intitulé, un libellé de bouton — plutôt qu'à une position dans la page.
Une chaîne qui vit dans ton navigateur ne se programme pas
C'est le point le plus contre-intuitif, et celui que je défends le plus souvent.
Une automatisation d'interface s'exécute dans une session ouverte, sur une machine allumée. Si tu la programmes à sept heures du matin et que ton ordinateur est fermé, elle n'échoue pas proprement : elle ne tourne pas, et tu l'apprends la fois où tu vas vérifier. Tu as construit une dépendance invisible entre une tâche planifiée et l'état physique d'un poste de travail.
J'ai fini par trancher pour mes propres chaînes : tout ce qui passe par mon navigateur se déclenche à la main, quand je suis là. Ce n'est pas une version dégradée de l'automatisation, c'est son mode de fonctionnement correct. Le gain reste entier — l'agent fait en quelques minutes ce que je ferais en une heure — et la planification reste réservée à ce qui tourne côté serveur, où personne n'a besoin d'être réveillé.
Si une tâche doit absolument partir toute seule à heure fixe, c'est le signal qu'elle ne doit pas passer par une interface. Il faut aller négocier l'accès API, ou changer de brique.
Le seuil d'autonomie se fixe sur le coût de l'erreur
Dernière décision, et c'est une décision de cadrage, pas de technique : qu'est-ce que l'agent a le droit de faire seul.
Le critère n'est pas le volume ni la difficulté, c'est ce que coûte une erreur publiée sous ton nom. Pour une chaîne qui écrit à l'extérieur, je découpe comme ça :
- Il agit seul sur les cas franchement positifs, répétitifs, réversibles, où une maladresse se corrige en deux minutes.
- Il s'arrête et me remonte le cas dès qu'il y a une critique, une demande, un interlocuteur qu'il n'identifie pas, ou simplement un doute.
Un agent utile n'est pas celui qui traite tout. C'est celui qui sait reconnaître ce qu'il ne doit pas traiter. Cette ligne se décide avant la première exécution, pas après le premier dérapage.
Et il y a ce que je ne fais jamais passer par une interface, quelles que soient les circonstances : la saisie d'identifiants, les paiements, les suppressions et toute action irréversible. Si le résultat n'est pas rattrapable à la main en quelques minutes, ça ne va pas dans un navigateur piloté.
Avant de lancer la première chaîne
Trois questions, dans l'ordre.
Est-ce que je peux vérifier, après coup et par un autre chemin, que l'action a bien été enregistrée ?
Si la réponse est non, l'automatisation est aveugle et tu ne sauras pas qu'elle a dérivé.
Puis : est-ce que quelqu'un sera devant l'écran au moment où elle tourne ? Et enfin : quelle est la pire chose qu'elle puisse publier à ma place ? Cette dernière réponse te donne ton seuil d'autonomie, bien mieux qu'une estimation de fiabilité.
L'automatisation par l'interface est un outil de contournement, pas un socle. Elle fait gagner un temps réel sur des outils qu'on ne peut pas quitter — et le jour où tu te surprends à la consolider, à la planifier, à la laisser tourner sans regarder, c'est qu'il est temps d'aller chercher une vraie porte d'entrée.