L’automatisation par computer use peut piloter une application métier via son interface lorsqu’aucune API adaptée n’est disponible. Cela peut rendre un processus ancien accessible, mais l’écran devient une frontière d’intégration avec ses incertitudes. Un clic ne prouve pas que le dossier visé a changé.
Choisissez le computer use lorsqu’une API prise en charge, un export ou une intégration classique ne peut satisfaire économiquement la tâche dans ses contraintes opérationnelles. Délimitez le périmètre, vérifiez l’état de l’écran et du destinataire, et définissez la récupération après interruption. Gardez un contrôle humain sur les dossiers ambigus et les engagements importants.
Imaginez des salariés recopiant des commandes approuvées dans un ancien portail fournisseur. Le portail n’a pas d’interface d’écriture adaptée ; une automatisation visuelle pourrait préparer la commande. Avant d’accepter cette conception, déterminez comment elle identifie le bon client, détecte une page modifiée et établit si l’envoi a déjà eu lieu après un dépassement de délai.
Ce guide compare des approches d’implémentation. Il ne prétend pas que toute application ancienne autorise l’automatisation ni qu’un opérateur d’interface piloté par modèle est toujours préférable à une automatisation déterministe du navigateur.
Décider si l’automatisation par computer use convient
Inventoriez d’abord les possibilités d’intégration prises en charge. Demandez les API, imports en masse, exports et connecteurs du fournisseur. Une voie apparemment absente de l’interface peut exister dans une intégration documentée. Inversement, une API disponible peut manquer de l’opération ou de l’autorité précise nécessaire.
Expliquez pourquoi le parcours visuel est nécessaire et ce que ses limites impliquent. Si l’application change souvent, manque de références de dossiers stables ou exige des décisions humaines non résolues, adaptez le périmètre à ces contraintes. N’achetez pas un agent autonome général avant de prouver une tâche complète.
| Voie | Usage raisonnable | Preuve principale à demander |
|---|---|---|
| API prise en charge | Opérations et permissions nécessaires disponibles | Contrats documentés et résultats destinataires |
| Import ou export | Traitement sûr par lots | Correspondance d’identité et rapprochement |
| Automatisation visuelle déterministe | Interface stable et séquence connue | Ciblage fiable des éléments et tests d’interruption |
| Computer use assisté par modèle | Variation nécessitant une interprétation délimitée | Décisions contrôlées et vérification d’état |
| Continuation manuelle | Ambiguïté ou engagement exigeant une personne | Relais attribué avec contexte conservé |
Vérifiez les conditions actuelles d’accès et d’usage avec le propriétaire de l’application avant l’achat. Ce guide n’accorde aucun droit général d’automatiser un produit tiers. La proposition doit identifier le mode d’exploitation pris en charge et les contraintes affectant la livraison.
Décrire la tâche en états observables
Partez d’un enregistrement source et d’un état destinataire accepté. Pour le portail fournisseur, la source peut être une demande d’achat approuvée et la destination un brouillon enregistré avec une référence correspondante. Préparer un brouillon peut constituer un premier périmètre utile sans envoyer une commande commerciale.
Identifiez les contrôles d’un opérateur humain : bon compte, bon client, article correspondant, totaux vérifiés et sauvegarde confirmée. Traduisez-les en preuves explicites d’acceptation. Une suite de coordonnées n’est pas une définition métier de l’achèvement.
Les indications Microsoft sur l’automatisation du navigateur décrivent des actions utilisant des instances de navigateur et des éléments de page capturés. Elles illustrent une distinction essentielle : l’interaction exige une cible identifiée et un état pertinent. Un contrôle de bureau et un élément web ne sont pas interchangeables.
Traitez explicitement les états incertains. Si une fenêtre ou une nouvelle disposition empêche la vérification, le système doit s’arrêter avec une explication utile et une référence source. Continuer parce que le prochain clic semble correct peut transformer un désagrément d’interface en action métier erronée.
Séparer interprétation et engagement
Un modèle peut interpréter un libellé inconnu ou trouver des informations pertinentes, mais la tâche autorisée doit rester explicite. Définissez les champs remplissables, les dossiers sélectionnables et les actions exigeant une approbation. Ne donnez pas d’autorité générale à l’opérateur simplement parce qu’il voit toute l’application.
Les recommandations OWASP sur l’autorisation conseillent le moindre privilège. Utilisez un compte dont les pouvoirs correspondent à l’automatisation lorsque le produit le permet. Un prompt interdisant les actions administratives n’équivaut pas à restreindre le compte.
| Action | Traitement initial proposé | Preuve avant continuation |
|---|---|---|
| Lire un dossier autorisé | Permettre dans le périmètre du compte convenu | Bon dossier et référence source |
| Remplir un brouillon | Permettre les champs vérifiés | Valeurs conformes à la demande approuvée |
| Choisir un résultat ambigu | Envoyer en validation | Confirmation humaine du dossier voulu |
| Envoyer une commande commerciale | Exiger l’approbation convenue | Destination concrète, valeurs et brouillon actuel |
| Modifier les droits du compte | Exclure sauf cadrage séparé | Processus d’exploitation explicitement autorisé |
Liez l’approbation à la version visible au moment de l’engagement. Si l’interface recalcule un total ou remplace un article après validation, l’approbation précédente ne décrit peut-être plus l’action. Définissez la règle d’arrêt et de nouvelle approbation.
Attribuer la responsabilité des sessions et environnements
Documentez où fonctionne l’automatisation, qui possède le compte et comment les opérateurs autorisés récupèrent une session. Incluez dépendances navigateur ou bureau, accès applicatif et authentification prise en charge. Ne stockez pas les identifiants dans des fichiers sources généraux et ne les exposez pas dans les captures.
Prévoyez une voie humaine pour les demandes d’authentification. Atteindre un écran de connexion n’indique pas forcément un défaut de l’application. La procédure doit expliquer qui rétablit l’accès autorisé sans contourner les protections ni élargir les droits du compte.
Séparez les tests contrôlés du travail réel. Confirmez compte et environnement avant une écriture. Un jeu de test chargé dans un vrai portail peut créer une commande réelle si la destination n’est pas délibérément contrôlée.
Décidez comment gérer les utilisateurs simultanés. Une autre personne modifiant le brouillon ou changeant l’organisation de la session peut invalider les observations. La conception doit détecter les changements pertinents et coordonner l’accès plutôt que supposer une interface fixe entre les étapes.
Récupérer après interruption sans reprise aveugle
L’interruption critique survient souvent après l’envoi mais avant l’accusé de réception. Inspectez la destination avec la référence source ou d’opération avant de répéter. La dernière capture peut montrer un chargement alors que le serveur a accepté la demande.
Conservez un journal de tâche avec des étapes significatives. Enregistrez référence source, destination choisie, brouillon vérifié et confirmation observée. Limitez les contenus sensibles à la finalité d’enquête. Le journal doit aider à reprendre ou rapprocher, pas seulement rejouer des frappes.
Notre guide d’intégration des portails fournisseurs aborde la décision d’intégration globale. Pour un parcours visuel, l’acceptation doit inclure une interruption volontaire et la preuve que la récupération ne crée pas de seconde commande ni n’écrase le travail d’un autre opérateur.
Définissez une continuation manuelle. La personne qui reprend doit savoir ce qui a été observé, ce qui a pu déjà arriver et quelles actions restent non confirmées. Un relais disant seulement « automatisation échouée » peut conduire à reproduire la même incertitude.
Tester les changements d’interface et variations légitimes
Utilisez des dossiers représentatifs avec noms longs, champs facultatifs et erreurs de validation réalistes. Testez résultats vides, correspondances multiples, sessions expirées et pages modifiées. Le système doit distinguer une variation prise en charge d’un état qu’il ne sait pas interpréter sans risque.
La discussion d’Anthropic sur l’évaluation des agents comprend les systèmes de computer use et la vérification de leurs résultats dans un environnement. Appliquez cette distinction quel que soit le fournisseur ou outil choisi. Exécuter une séquence d’actions visuelles n’équivaut pas à accomplir la tâche voulue.
Conserver les preuves des refus et relais
Un arrêt correct doit compter comme résultat accepté si la tâche est ambiguë ou non autorisée. Testez la réception d’une référence utile par l’opérateur et l’absence de modification non prise en charge. Sinon, l’évaluation peut récompenser une fin risquée plutôt qu’un parcours manuel fiable.
Relancez les cas pertinents après modification de l’application cible, de l’environnement d’automatisation ou du composant d’interprétation. Ajoutez un contrôle simple détectant qu’une page connue n’a plus la structure prévue. Le responsable d’exploitation doit savoir quand le périmètre pris en charge change.
Comparer le coût complet du parcours visuel
Demandez des devis en GBP séparant étude, automatisation, acceptation contrôlée, récupération et maintenance. Incluez assistance aux sessions, exploitation de l’environnement et changements d’interface. Une démonstration recopiant des champs une fois ne vaut pas un processus de production pris en charge.
| Lot de travail | Livrable | Hypothèse de coût à expliciter |
|---|---|---|
| Évaluation des voies | Comparaison API, import et interface | Opérations destinataires prises en charge |
| Conception des interactions | États délimités et correspondance des champs | Stabilité de l’interface et ambiguïté |
| Vérification | Contrôles destinataires et interruptions | Disponibilité de comptes contrôlés |
| Exploitation | Récupération de session et relais manuel | Couverture d’assistance et fréquence des changements |
| Sortie | Transfert des sources, configuration et responsabilité | Dépendance à un opérateur ou fournisseur |
Demandez-vous si le processus doit être simplifié avant automatisation. Supprimer une étape redondante ou obtenir un export pris en charge peut être un meilleur investissement que maintenir un opérateur d’écran complexe. Le choix doit suivre le résultat métier accepté.
Notre service de développement logiciel peut partir de la tâche et des voies d’intégration. Envoyez-nous l’application, le processus approuvé et le relais difficile pour discuter d’un parcours délimité avec vérification, permissions et responsabilité de récupération claires.
Questions fréquentes
Qu’est-ce que l’automatisation par computer use ? Elle pilote des logiciels par leur interface graphique : lire les écrans, sélectionner des contrôles et saisir des valeurs. Une implémentation métier exige des contrôles d’état, des pouvoirs de compte adaptés et des preuves de récupération autour de ces interactions.
Faut-il l’utiliser plutôt qu’une API ? Comparez d’abord les voies prises en charge. Une API ou un import peut fournir des contrats plus clairs s’il satisfait la tâche. Le parcours visuel peut servir si l’opération nécessaire n’est disponible que dans l’interface applicative.
Faut-il un modèle IA ? Pas toujours. Des séquences stables peuvent convenir à une automatisation visuelle déterministe. Un modèle peut aider à interpréter dans un périmètre limité, mais son rôle doit être justifié par la tâche et testé sur les résultats acceptés.
Peut-elle envoyer des commandes sans validation humaine ? Cela dépend du périmètre d’exploitation explicitement autorisé et des contrôles. Commencez par préparer des brouillons si approprié et liez l’engagement commercial à une action concrète validée. Ne supposez pas une autorité générale grâce à l’accès à l’écran.
Que se passe-t-il si la connexion échoue après l’envoi ? Considérez le résultat comme incertain jusqu’à inspection. Utilisez référence source et preuves destinataires pour établir si l’action a abouti avant de décider de réessayer. Une reprise aveugle peut dupliquer les effets métier.
Comment gère-t-elle les demandes de connexion ? Prévoyez un processus humain autorisé de récupération et documentez le propriétaire du compte. Le flux doit s’arrêter quand l’accès exige une intervention, sans contourner l’authentification ni changer discrètement les identifiants.
Quelle maintenance prévoir ? Budgétez changements d’interface, mises à jour d’environnement, assistance aux sessions et tests de régression. La proposition doit préciser qui détecte les pages non prises en charge et comment le travail continue pendant la réparation.
Que doit démontrer un pilote ? Une tâche complète délimitée, un refus ou relais correct, et la récupération après une interruption significative. Vérifiez l’état final destinataire plutôt que compter uniquement sur des captures montrant les clics.