Computer use en PME : le bon usage commence là où l’API s’arrête

Un agent de « computer use » peut lire un écran, cliquer, saisir des informations et naviguer dans un logiciel comme le ferait un utilisateur. Pour une PME, son intérêt n’est pas de remplacer toutes les intégrations existantes. Il est de débloquer les tâches encore prisonnières d’un portail, d’un ancien logiciel ou d’une interface sans API exploitable.

La méthode solide tient en trois décisions : connecter directement ce qui peut l’être, réserver l’agent aux étapes vraiment fermées, puis conserver une preuve exploitable de chaque exécution. Autrement, l’entreprise transforme une corvée manuelle visible en automatisation fragile et difficile à diagnostiquer.

Ce qui change avec les agents capables d’utiliser un écran

Le 16 juillet 2026, L’Usine Digitale a présenté le lancement par H Company d’une API et d’une plateforme en libre-service. Elles visent les développeurs qui veulent intégrer des agents de computer use dans leurs applications ou leurs workflows, sur un navigateur fourni par H ou sur leur propre ordinateur.

L’annonce est intéressante pour les petites structures parce qu’elle abaisse le seuil technique d’accès. Jusqu’ici, ce type de dispositif évoquait surtout un projet réservé à une grande entreprise. Il devient désormais possible de tester un agent dans une automatisation plus modeste, sans construire soi-même toute la couche de perception visuelle et de pilotage de l’ordinateur.

La documentation officielle de H Company sur HoloDesktop CLI montre aussi comment ce type d’agent peut s’insérer dans un environnement existant. Le client open source pilote la souris et le clavier, fonctionne sur la machine, et expose plusieurs modes d’intégration, dont CLI, MCP, ACP et A2A. H illustre notamment deux usages : tester visuellement une application après une modification et reporter des informations issues de justificatifs dans un formulaire.

Ce progrès ne rend pas les interfaces graphiques aussi stables qu’une API. Il rend leur automatisation plus accessible.

Une API et un écran ne rendent pas le même service

Une API fournit des données et des actions prévues pour être appelées par un logiciel. Les champs sont structurés. Les erreurs peuvent être interprétées. Les échanges sont généralement plus faciles à répéter, surveiller et tester.

Un agent de computer use travaille à partir de ce qu’il voit. Il peut donc agir là où aucun connecteur n’existe, mais il dépend de l’état de l’interface : une fenêtre inattendue, un bouton déplacé, une session expirée ou une information ambiguë peuvent modifier son parcours.

La règle de conception est simple.

Utiliser une API lorsque l’action est structurée et répétitive

Une synchronisation de commandes, une création de fiche client, une mise à jour de stock ou l’envoi d’un statut doivent passer par une API fiable lorsqu’elle existe. C’est particulièrement vrai si le volume est élevé, si l’action touche une donnée financière ou si une erreur déclenche d’autres traitements.

Le computer use ne doit pas servir à cliquer cent fois sur un bouton qu’un appel logiciel peut remplacer proprement.

Utiliser le computer use pour franchir une interface fermée

Le bon candidat est une étape précise qui bloque le reste du flux : récupérer un document sur un portail fournisseur sans connecteur, saisir une demande dans un extranet ancien, vérifier un parcours client dans un navigateur ou collecter une information visible uniquement après navigation.

L’agent joue alors le rôle d’adaptateur. Il ne devient pas toute l’architecture.

Garder une validation humaine pour l’irréversible

Un remboursement, une modification contractuelle, une suppression ou un envoi engageant l’entreprise ne devraient pas être validés uniquement parce que l’agent a trouvé le bon bouton. L’automatisation peut préparer l’action, rassembler les éléments et signaler l’écart. La décision finale reste séparée lorsque le coût d’une erreur est élevé.

L’architecture utile pour une TPE ou une PME

Un pilote sérieux peut rester simple. Il doit toutefois distinguer trois couches.

1. Le workflow porte la règle métier

Le scénario principal, par exemple dans n8n ou dans une application possédée par l’entreprise, décide quand la tâche démarre, quelles données elle reçoit et ce qui doit se produire ensuite. La règle métier ne doit pas être cachée uniquement dans une longue instruction envoyée à l’agent.

Exemple : chaque matin, le workflow identifie les dossiers incomplets. Il appelle l’agent seulement pour télécharger les pièces depuis un portail sans API. Il reprend ensuite la main pour classer les fichiers et notifier la bonne personne.

2. L’agent ne reçoit qu’une mission bornée

La mission décrit un objectif observable : ouvrir le portail, rechercher le dossier correspondant à une référence, télécharger le document attendu, puis s’arrêter. Elle précise aussi les situations qui imposent un arrêt : référence absente, double résultat, demande d’authentification inhabituelle ou changement de page.

Un agent qui peut naviguer partout avec un compte trop large crée plus de surface d’erreur qu’il n’en retire. Un compte dédié et des permissions limitées rendent le test plus lisible.

3. Chaque exécution laisse une trace

Le workflow doit conserver au minimum l’identifiant du dossier, l’heure, le résultat, le fichier obtenu ou l’action réalisée, ainsi que la raison d’un éventuel arrêt. Une capture ciblée peut être utile pour une étape visuelle, à condition de ne pas accumuler inutilement des données sensibles.

Cette trace sert à répondre à une question concrète : que s’est-il passé lorsque le résultat attendu n’est pas arrivé ? Sans réponse, l’automatisation reste une boîte noire.

Trois cas d’usage qui méritent un test

Tester un site ou une application après une modification

Un build réussi ne prouve pas qu’un bouton est accessible, qu’un filtre fonctionne ou qu’un parcours se termine correctement. H Company montre un agent qui ouvre une application, se connecte et vérifie visuellement un parcours après une modification de code. Pour une PME qui possède son site ou son outil métier, ce contrôle peut compléter les tests techniques avant publication.

Le scénario doit rester précis : trois à cinq parcours critiques, un résultat attendu par étape et un rapport qui distingue réussite, échec et blocage.

Récupérer des documents sur plusieurs portails

Beaucoup d’entreprises perdent du temps à se connecter à des extranets pour télécharger factures, confirmations ou états de dossier. Si aucun export ni API n’existe, un agent peut prendre en charge la navigation et remettre le document au workflow de classement.

Le gain ne vient pas du clic automatique seul. Il vient de la chaîne complète : nommage cohérent, rangement dans l’espace de l’entreprise, détection des pièces manquantes et alerte en cas d’exception.

Compléter un formulaire à partir d’une donnée déjà vérifiée

L’agent peut reporter une information dans une interface qui n’accepte aucune intégration. La donnée doit toutefois être validée avant la saisie, puis relue après. Pour un premier pilote, mieux vaut choisir un formulaire interne ou réversible plutôt qu’une déclaration sensible.

Comment décider si le pilote mérite une mise en production

Ne mesurez pas seulement le temps d’une démonstration réussie. Observez une série d’exécutions réelles et notez :

• la part des tâches terminées sans intervention ;
• les causes de blocage et leur fréquence ;
• le temps humain encore nécessaire ;
• le coût d’exécution par dossier ;
• la gravité d’une erreur possible ;
• la facilité de reprise après un échec.

Si l’interface change souvent, si les exceptions sont nombreuses ou si chaque erreur exige une enquête longue, le cas d’usage n’est peut-être pas mûr. Il peut aussi révéler qu’une petite application ou une intégration API serait plus rentable qu’un agent visuel permanent.

Ce que l’entreprise doit posséder

Le fournisseur du modèle peut changer. Le portail tiers peut évoluer. Le workflow métier, lui, doit rester documenté et récupérable par l’entreprise.

Cela implique de conserver dans ses propres espaces les scénarios, les règles d’arrêt, les journaux utiles, les comptes techniques, la documentation et les données produites. Le computer use devient alors une brique remplaçable dans une automatisation maîtrisée, pas un nouveau silo.

L’arrivée d’API en libre-service rend le computer use plus facile à expérimenter. Pour une PME, le meilleur projet ne sera pas celui qui fait le plus de clics tout seul. Ce sera celui qui supprime une rupture concrète entre deux outils, avec un résultat vérifiable et une reprise prévue dès le départ.