Les démonstrations sont fascinantes. Une IA parcourt un processus de réservation complexe, passe d’une application à l’autre, remplit des formulaires administratifs et accomplit de manière autonome des tâches qui durent plusieurs heures. En 2024–2025, Anthropic Computer Use, OpenAI Operator, Google Project Mariner et une vague de jeunes entreprises ont présenté des agents capables d’utiliser des ordinateurs comme des humains.
En 2026, ces outils sont bien réels. Ils fonctionnent. Certaines entreprises les déploient avec succès en production. Mais ces déploiements ne ressemblent pas aux démonstrations : ils sont plus ciblés, plus contraints et entourés de garde-fous. Cet article présente les modèles qui distinguent la production d’une démonstration.
Nous avons abordé les principes de base dans un article de niveau intermédiaire. Celui-ci va plus loin : les modèles de production, les échecs récurrents, l’équation économique et la manière de déployer à grande échelle un système d’utilisation d’ordinateur réellement utile.
La réalité de la production
Voici quelques modèles observés dans les déploiements réels :
Modèle 1 : Les tâches restreintes dominent. Les déploiements en production réussissent pour des tâches précises et bien définies. Pas pour « faire n’importe quoi ». Pas pour « utiliser n’importe quel site web ». Ils concernent des processus précis sur des sites précis.
Modèle 2 : Un périmètre très encadré. Le périmètre des tâches est strictement limité. L’agent n’est autorisé à effectuer que certaines actions sur certains sites. Tout ce qui sort du périmètre provoque un arrêt, et non une improvisation.
Modèle 3 : Des processus enregistrés plutôt qu’une exploration autonome. De nombreux déploiements en production utilisent des processus enregistrés (des étapes définies une fois, puis rejouées avec des ajustements) plutôt que des agents entièrement autonomes. Ils sont plus fiables et plus faciles à maintenir.
Modèle 4 : Une intervention humaine pour les actions lourdes de conséquences. Toute action ayant des conséquences importantes (financières, juridiques ou visibles par un client) est soumise à un examen humain.
Modèle 5 : Une surveillance intensive. Chaque action est journalisée. Détection des anomalies. Boutons d’arrêt d’urgence. L’équipe d’exploitation surveille les tableaux de bord.
Modèle 6 : Une discipline des coûts. L’équation économique compte. De nombreux déploiements théoriques où « l’IA fait tout » ne sont pas rentables face aux solutions humaines ou aux solutions de RPA.
Modèle 7 : Spécialisé plutôt que généraliste. Les déploiements en production ont tendance à utiliser des modèles spécialisés (ou des configurations spécialisées) plutôt qu’un modèle généraliste d’utilisation d’ordinateur pour toutes les tâches.
Ces modèles correspondent à la réalité habituelle de l’IA en production : un périmètre plus restreint et des garde-fous plus solides que ne le laisse entendre le marketing.
Là où les agents d’utilisation d’ordinateur excellent en production
Voici les catégories de tâches pour lesquelles l’utilisation d’ordinateur est l’outil adapté :
1. Extraction de données de sites sans API
De nombreux outils d’entreprise, portails administratifs et petits services B2B ne proposent aucune API, ou une API très incomplète. Les agents d’utilisation d’ordinateur peuvent extraire des données en manipulant l’interface utilisateur.
Exemples en production :
- Récupérer des factures sur plus de 50 portails fournisseurs.
- Extraire des données de dossiers depuis les sites des systèmes judiciaires.
- Collecter les tarifs affichés sur les pages de concurrents.
- Agréger des données provenant de portails de déclaration de conformité.
Lorsque l’autre solution consiste à confier à un humain une succession fastidieuse de clics, l’utilisation d’ordinateur présente un avantage évident.
2. Remplissage de formulaires à grande échelle
Il s’agit de soumettre le même type de formulaire à de nombreux sites différents. Chaque site varie légèrement ; une API serait idéale, mais elle n’existe pas.
Exemples :
- Démarches administratives (chaque organisme possède son propre portail).
- Déclarations de conformité.
- Intégration de clients dans les systèmes de fournisseurs.
- Création de comptes pour des outils SaaS.
3. Test de l’interface utilisateur et assurance qualité
Les agents d’utilisation d’ordinateur sont de bons testeurs d’assurance qualité. Ils peuvent parcourir les applications, essayer des parcours utilisateur et signaler les problèmes.
Exemples :
- Tests de bout en bout des applications web.
- Tests de régression visuelle.
- Audits d’accessibilité.
- Validation des parcours utilisateur sur plusieurs appareils.
Cette approche est proche de la RPA, mais bénéficie de la souplesse de l’IA pour s’adapter aux changements d’interface.
4. Processus interapplications
Des tâches qui s’étendent à plusieurs applications sans point d’intégration unique.
Exemples :
- Extraire des données d’un CRM, les mettre en forme et les charger dans un outil d’analyse.
- Récupérer des tickets d’assistance client, créer des tâches dans un outil de gestion de projet et mettre à jour leur statut dans un CRM.
- Agréger des rapports provenant de plusieurs outils internes.
Lorsque vous ne pouvez pas ou ne souhaitez pas intégrer directement les applications, un agent offre une passerelle souple.
5. Processus répétitifs à plusieurs étapes
Des tâches que le même humain effectue régulièrement.
Exemples :
- Intégrer de nouveaux clients au moyen d’un processus en 30 étapes.
- Rapprocher chaque semaine les données de deux systèmes.
- Générer des rapports périodiques qui nécessitent d’extraire des données de plusieurs sources.
Si un processus est bien défini, se répète souvent et est actuellement exécuté par des humains qui cliquent dans une interface, il constitue un bon candidat.
Où ils échouent encore
À l’inverse, voici les tâches pour lesquelles les agents d’utilisation d’ordinateur ne sont pas encore prêts en production.
1. Tâches nécessitant un jugement
« Trouvez-moi un bon fournisseur. » Les agents peuvent naviguer sur les sites des fournisseurs ; ils ne peuvent pas juger lequel est bon pour vos besoins spécifiques.
2. Tâches présentant des interfaces inédites
Face à un site inédit, les agents peinent à comprendre des conventions d’interface inhabituelles. Ils fonctionnent mieux avec des modèles courants (formulaires, listes, menus de navigation) qu’avec des conceptions sur mesure.
3. Tâches confrontées à de puissantes mesures antibots
De nombreux sites détectent et bloquent activement l’automatisation. Les agents peuvent parfois contourner ces mesures (au prix d’efforts), mais c’est un jeu du chat et de la souris permanent. Cela n’en vaut souvent pas la peine.
4. Actions individuelles à haut risque
Effectuer un paiement, signer un document juridique ou publier du contenu au nom de quelqu’un. Le rayon d’impact d’une action erronée est important ; un examen humain est indispensable.
5. Tâches nécessitant un contexte du monde réel
L’agent ne voit que ce qui s’affiche à l’écran. Il ne connaît ni votre relation avec ce client, ni le contexte récent de votre équipe, ni la situation politique. Les tâches dépourvues de contexte échouent.
6. Exploration ouverte
« Trouvez la meilleure offre » ou « effectuez une recherche approfondie sur cette personne » : ces tâches ne comportent pas de critères d’achèvement clairs. Les agents tournent en rond ou s’arrêtent trop tôt.
L’architecture
Un système d’utilisation d’ordinateur en production comporte les couches suivantes :
┌─────────────────────────────────────┐
│ Orchestration │ Schedules, retries, escalations
├─────────────────────────────────────┤
│ Task definition + scope │ What the agent does and doesn't do
├─────────────────────────────────────┤
│ Agent runtime (Computer Use SDK) │ Anthropic / OpenAI / Browserbase
├─────────────────────────────────────┤
│ Browser / desktop environment │ Isolated, sandboxed
├─────────────────────────────────────┤
│ Authentication and session │ Credentials, cookies, MFA handling
├─────────────────────────────────────┤
│ Result handling │ Capture, validate, store
├─────────────────────────────────────┤
│ Monitoring + alerts │ Real-time observability
└─────────────────────────────────────┘
Examinons chacune d’elles.
Définition de la tâche
C’est l’étape la plus importante : définir précisément et de manière restrictive ce que fait l’agent.
Une bonne définition de la tâche inclut :
Déclencheur. Qu’est-ce qui déclenche la tâche ? (Planification, événement, manuel.)
Entrées. De quelles données l’agent dispose-t-il ? (Enregistrement précis, données de formulaire structurées.)
Portée. Quels sites, quelles actions, quels chemins à travers l’interface utilisateur.
Critères de réussite. Comment reconnaître que la tâche est terminée ?
Conditions d’arrêt. Qu’est-ce qui interrompt la tâche avant son terme ?
Sortie. Quelles données l’agent renvoie-t-il ?
Sémantique des erreurs. Comment les échecs sont-ils classés et signalés ?
Une tâche mal définie : « Soumettre notre rapport de conformité hebdomadaire. »
Une tâche bien définie :
Task: Submit weekly compliance report to portal X.
Trigger: Cron, every Monday at 9 AM.
Inputs:
- Report data file (CSV) from /reports/weekly.csv
- Submitter info from environment variables (name, ID).
- Credentials from secrets manager.
Scope:
- Site: https://portal.example.gov/submit (and subpaths)
- Allowed actions: navigate, click, type, upload, submit, screenshot.
- Forbidden: visit external sites, change account settings, navigate away from submission flow.
Success criteria:
- Receive confirmation page with submission ID.
- Capture submission ID.
Stop conditions:
- Confirmation received: success.
- CAPTCHA: escalate to human.
- Login failure: escalate to human.
- Form validation error: report and stop.
- Timeout 5 minutes: report and stop.
Output:
- Submission ID.
- Screenshot of confirmation page.
- Timestamp.
Errors:
- Validation: log, notify owner, do not retry.
- Auth: log, notify ops, do not retry.
- Network: retry once, then escalate.
Ce niveau de précision correspond à la réalité de la production. « Soumettre le rapport » correspond à une démonstration.
Application du périmètre
Le périmètre n’est pas une simple description ; il est imposé pendant l’exécution.
Liste d’autorisation d’URL. L’agent ne peut accéder qu’aux URL correspondant à un motif défini. Toute navigation en dehors de cette liste est bloquée.
Filtrage des actions. Seuls certains types d’actions sont autorisés. Le droit général d’« utiliser l’ordinateur » est remplacé par une liste précise d’actions permises.
Filtrage des éléments. Certaines pages comportent des éléments avec lesquels l’agent ne doit jamais interagir (paramètres, déconnexion, boutons dangereux). Ils peuvent être exclus de la couche de perception.
Limites de temps. Les tâches ont des durées maximales strictes. Si elles ne sont pas terminées au bout de N minutes, elles sont interrompues.
Limites d’étapes. Les tâches comportent un nombre maximal d’étapes. La logique est la même que pour les boucles d’agents.
La mise en œuvre varie selon la plateforme — Anthropic Computer Use, OpenAI Operator et Browserbase proposent des mécanismes différents. Le principe est universel : imposer le périmètre à l’exécution, et ne pas se contenter de le décrire dans le prompt.
Authentification
Un défi permanent. Les déploiements en production doivent authentifier la session de l’agent.
Sessions préauthentifiées. Un humain se connecte une fois ; les cookies et jetons de session sont capturés ; l’agent intervient ensuite dans cette session. Celle-ci est renouvelée lorsque cela est nécessaire.
Comptes de service. Des comptes sont réservés à l’agent (si le site les prend en charge). Autorisations limitées, journalisation des audits.
Injection d’identifiants. L’agent reçoit les identifiants à l’exécution, les utilise pour se connecter, puis les supprime. Leur stockage et leur traitement doivent être sécurisés.
Gestion de l’authentification multifacteur. C’est un véritable défi. Plusieurs options existent :
- Utiliser des secrets TOTP que l’agent peut calculer.
- Transmettre la demande d’authentification multifacteur à un humain pour approbation.
- Utiliser des comptes ou des sites qui acceptent des jetons d’API à la place de l’authentification multifacteur.
OAuth. Pour les sites modernes, les flux OAuth fonctionnent bien : l’agent obtient un jeton au moyen d’un flux approuvé une fois par un humain.
Le principe est le suivant : les agents ne doivent jamais disposer sur vos comptes d’un accès équivalent à celui d’un humain. Leurs identifiants doivent avoir un périmètre restreint, être auditables et pouvoir être révoqués.
Validation des résultats
Lorsque l’agent affirme avoir réussi, vérifiez son résultat.
Capture des artefacts. Captures d’écran, fichiers téléchargés, données de sortie. Ne vous fiez pas au rapport de l’agent ; examinez les preuves.
Vérification des conditions de réussite. Le formulaire a-t-il vraiment été soumis ? Y a-t-il une confirmation ? Les données étaient-elles correctes ?
Vérification croisée. Si vous pouvez confirmer la réussite par un autre canal (une API, un e-mail de confirmation, une vérification dans la base de données), faites-le.
Détection d’anomalies. Cette exécution a-t-elle été anormalement longue, courte ou coûteuse ? Analysez les valeurs aberrantes.
Le principe : partez du principe que l’agent peut se tromper. Prévoyez une vérification indépendante de son propre rapport.
Gestion des erreurs
Les tâches d’utilisation d’ordinateur peuvent échouer de nombreuses manières. Classez et traitez chacune d’elles :
Erreurs réseau. Site indisponible, expiration du délai. Réessayer avec un délai d’attente progressif.
Échecs d’authentification. Échec de la connexion, session expirée. Renouveler les identifiants ou transmettre le problème.
Modifications de l’interface utilisateur. Le site a changé ; l’élément attendu est introuvable. Arrêter l’exécution et alerter l’équipe de maintenance.
Erreurs de validation. Rejet de l’entrée du formulaire. Journaliser, informer, ne pas réessayer aveuglément.
Détection antibot. CAPTCHA, blocages. Transmettre le problème ; éventuellement placer le site sur une liste d’exclusion.
Confusion de l’agent. L’agent est bloqué, tourne en boucle ou s’écarte du scénario. L’arrêter, journaliser l’incident et l’analyser.
Quota ou limitation de débit. Le site a limité le débit de l’agent. Attendre progressivement avant de réessayer, ou replanifier l’exécution.
Chaque catégorie appelle une réponse différente. Mauvais modèle : « l’agent a échoué, réessayer ». Bon modèle : « l’agent a échoué dans la catégorie X, suivre la procédure X ».
Surveillance
Chaque action est journalisée, chaque exécution suivie et chaque anomalie signalée.
Journal par exécution :
- Horodatages de début et de fin.
- Toutes les actions entreprises.
- Toutes les captures d’écran.
- Résultat (réussite, échec ou transmission).
- Coût.
- Métriques de performance.
Tableau de bord par exécution : l’équipe d’exploitation peut consulter les exécutions actives, les échecs récents et la taille de la file d’attente.
Métriques agrégées :
- Taux de réussite par type de tâche.
- Distribution de la latence.
- Coût par exécution.
- Taux d’anomalie.
Alertes :
- Le taux de réussite tombe en dessous du seuil.
- Le coût par exécution augmente brusquement.
- Certains types d’échec augmentent.
- L’interface utilisateur du site a pu changer (plusieurs échecs récents sur la même étape).
Cette surveillance permet de détecter les problèmes avant qu’ils ne deviennent des incidents.
L’équation économique
La question directe : l’utilisation d’ordinateur coûte-t-elle moins cher que les autres solutions ?
Coûts :
- Coût par exécution : généralement 0,50 à 5 € selon la complexité de la tâche (les appels aux modèles de vision sont coûteux).
- Infrastructure : environnement d’exécution géré (Browserbase ou équivalent) ou autohébergé.
- Maintenance : les tâches cessent de fonctionner lorsque les sites changent. Un travail continu est nécessaire.
Alternatives :
- Humain à 30 €/heure : une tâche de 10 minutes coûte 5 €. Une tâche d’une minute coûte 0,50 €.
- Outils RPA : coût par exécution plus bas mais nécessitent une automatisation structurée.
- Intégration directe à une API : coût par appel bien inférieur, mais l’API doit exister.
- Externalisation à l’étranger : 5 à 10 €/heure, selon un calcul comparable à celui des employés internes.
L’équation économique favorise l’utilisation d’ordinateur lorsque :
- Le site n’a pas d’API.
- La tâche est suffisamment longue pour que l’automatisation amortisse les coûts fixes.
- Le volume est suffisamment élevé pour que le temps humain s’accumule.
- Le site est relativement stable (charge de maintenance faible).
L’équation économique ne favorise pas l’utilisation d’ordinateur lorsque :
- Une API existe (utilisez-la).
- La tâche est courte et peu fréquente.
- Le site change constamment.
- La tâche a trop de cas limites (maintenance élevée).
Exercice utile : estimez le coût par tâche avec un agent d’utilisation d’ordinateur, puis avec un humain. Multipliez par le volume et comparez.
Modèles de production efficaces
Quelques modèles de déploiements réussis :
Modèle 1 : L’approche « recette enregistrée »
Pour des tâches restreintes et à fort volume, enregistrez une fois le processus avec des étapes explicites, puis demandez à l’agent de le rejouer pour chaque entrée en apportant des ajustements mineurs.
Cette approche se rapproche de la RPA traditionnelle, tout en conservant la souplesse de l’IA face aux variations mineures (par exemple, un bouton légèrement déplacé ou une boîte de dialogue de confirmation supplémentaire).
Elle est bien plus fiable qu’un fonctionnement entièrement autonome.
Modèle 2 : La séparation entre extraction et soumission
De nombreux processus comportent deux phases :
- Extraire des données quelque part.
- Soumettre des données quelque part.
Séparer ces phases en plusieurs exécutions d’agents (ou procédures) est plus propre. Chaque phase possède des critères de réussite plus clairs. Les échecs de l’une ne s’ajoutent pas à ceux de l’autre.
Modèle 3 : Le point de contrôle humain
L’agent effectue le travail préparatoire de manière autonome, puis présente un état « prêt à agir » à un humain pour approbation. L’humain vérifie et approuve ; l’agent exécute.
Ce modèle est utilisé pour les paiements, les publications publiques et les soumissions sensibles. L’agent fait gagner du temps sur la préparation ; l’humain détecte les erreurs.
Modèle 4 : Le modèle « agent spécialiste »
Au lieu d’un agent généraliste, utilisez des agents spécialisés dans des tâches précises. Chacun est réglé, testé et maintenu pour son propre processus.
Un agent généraliste capable d’« utiliser n’importe quel site web » est difficile à maintenir. Un agent chargé de « soumettre notre rapport de conformité hebdomadaire » est simple.
Modèle 5 : Le retour à la RPA
Pour les tâches qui ne nécessitent pas réellement la souplesse de l’IA (site stable, processus fixe), revenez à la RPA traditionnelle (scripts Playwright ou Selenium). Dans ces cas, elle est moins coûteuse, plus rapide et plus fiable.
Réservez l’utilisation d’ordinateur aux situations où la souplesse de l’IA apporte une réelle valeur.
Modèle 6 : Le modèle « exécution par lots »
Ne lancez pas les agents à la demande pour les tâches à fort volume. Regroupez le travail et exécutez les agents en parallèle selon un calendrier.
Par exemple, au lieu du scénario « l’utilisateur envoie une demande ; l’agent s’exécute immédiatement », placez les demandes dans une file d’attente et lancez les agents par lots toutes les 15 minutes. Cela lisse la charge et simplifie l’architecture.
Ce qui peut mal tourner
Voici une courte liste des modes de défaillance courants :
Le site a changé. L’agent a parfaitement fonctionné pendant 6 mois. Une refonte du site casse tout. Sans surveillance, vous l’apprenez par des utilisateurs mécontents.
La détection antibot a rattrapé l’agent. Le site a mis en place une détection des robots. Les exécutions de l’agent échouent de plus en plus, puis le compte finit par être bloqué.
Spirale de coûts sur une tâche bloquée. L’agent tourne en boucle sur une page déroutante. Chaque cycle appelle un modèle de vision. Le coût atteint 100 € en une heure.
Mauvaise action. L’agent a cliqué sur le mauvais bouton. Il a annulé une commande au lieu de la confirmer, ou envoyé un message à la mauvaise personne.
Blocage sur l’authentification multifacteur. L’agent ne parvient pas à franchir cette étape. Les exécutions en production s’accumulent et la file d’attente s’allonge.
Compte bloqué. Le site a détecté une activité inhabituelle et suspendu le compte. Toutes les tâches similaires sont interrompues jusqu’au rétablissement du compte.
Fuite d’identifiants. L’agent a accidentellement exposé des identifiants dans un journal ou une capture d’écran. C’est un incident de sécurité.
Problème de confidentialité. L’agent a involontairement capturé des données à caractère personnel dans des captures d’écran qui ont ensuite été journalisées.
La plupart de ces problèmes peuvent être évités grâce aux modèles ci-dessus. Mais chacun s’est déjà produit dans des déploiements réels. Concevez les protections nécessaires en conséquence.
L’équation économique : un exemple chiffré
Il s’agit d’un scénario modélisé, et non d’un cas client ; nous le signalons délibérément. Un modèle de retour sur investissement que vous pouvez recalculer avec vos propres chiffres vaut mieux qu’un « cas anonymisé » invérifiable.
Tâche : soumettre des rapports de conformité récurrents sur les portails de 12 organismes différents. En Estonie, pensez aux portails qui exigent encore une saisie formulaire par formulaire : déclarations e-MTA, questionnaires de Statistics Estonia et soumissions au niveau de l’UE.
Référence manuelle : 12 portails × 90 minutes = 18 heures par semaine. À un coût complet de 30 €/heure, cela représente 540 € par semaine.
Automatisé :
- Exécutions des agents : 12 × environ 2 € (modèle de vision + infrastructure de navigation) = 24 € par semaine.
- Maintenance : environ 2 heures d’ingénieur par mois à 100 €/heure ≈ 46 € par semaine. Les portails changent ; prévoyez ce budget, faute de quoi l’automatisation cessera discrètement de fonctionner.
- Gestion des échecs : avec un taux de réussite autonome de 92 %, environ une exécution par semaine est transmise à un humain. Prévoyez 30 minutes d’examen : 15 € par semaine.
- Total : environ 85 € par semaine, soit une économie d’environ 455 € par semaine ou 23 500 € par an.
Deux chiffres déterminent si ce calcul se concrétise.
Le premier est le taux de réussite. En dessous d’environ 85 %, la surveillance humaine absorbe les économies. Mesurez ce taux pendant une période d’observation parallèle de deux semaines avant de vous y fier ; ne reprenez pas celui d’une diapositive commerciale.
Le second est la dérive de maintenance. Chaque refonte de portail provoque une rupture, et un parc de 12 portails en connaît plusieurs par an. Si vous ne pouvez pas désigner la personne chargée de les corriger sous un jour ouvré, le processus manuel était moins coûteux.
Liste de vérification de déploiement
Si vous déployez un système d’utilisation d’ordinateur en production :
- La tâche est restreinte et bien définie.
- Le périmètre est imposé à l’exécution, et pas seulement décrit.
- Des budgets d’étapes, de temps et de coût sont en place.
- Stratégie d’authentification avec des identifiants sécurisés.
- Mesures antibots prises en compte (utiliser des comptes légitimes ; respecter les limites de débit).
- Catégorisation et gestion des erreurs.
- Validation des résultats indépendante du compte rendu de l’agent.
- Surveillance et alertes.
- Interrupteurs de sécurité.
- Intervention humaine pour les actions lourdes de conséquences.
- Journalisation d’audit.
- Traitement de la confidentialité et des données à caractère personnel.
- Équation économique pertinente par rapport aux autres solutions.
- Plan de maintenance en cas de modification des sites.
Chacun de ces points est loin d’être trivial. En négliger un seul crée un risque.
Adapter la technologie à la tâche
En production, les agents d’utilisation d’ordinateur et de navigation ne ressemblent pas aux démonstrations virales. Tâches restreintes. Garde-fous solides. Surveillance intensive. Points de contrôle humains. Équation économique réaliste.
Pour les tâches adaptées, ils sont réellement utiles : extraction de données depuis des sites sans API, remplissage de formulaires à grande échelle, processus interapplications et opérations répétitives dans une interface. Les déploiements réels en production font réellement gagner du temps et de l’argent.
Pour les tâches inadaptées — jugement sans cadre précis, interfaces inédites, actions individuelles à fort enjeu — ils ne sont pas encore prêts. N’essayez pas de les y contraindre.
Tout l’art consiste à adapter la technologie à la tâche. Bien employés, les agents d’utilisation d’ordinateur constituent un outil utile dans la stack technologique de l’IA en production. Mal employés, ils représentent un moyen coûteux d’introduire de nouveaux modes de défaillance.
Choisissez des tâches restreintes. Construisez les garde-fous. Surveillez sans relâche. Assurez une maintenance régulière. C’est ainsi que les agents d’utilisation d’ordinateur gagnent leur place dans les systèmes de production.
