Beaucoup de PME ont un logiciel métier qui n'a ni API, ni ligne de commande, ni connecteur : un outil de facturation ancien, un portail fournisseur, une application installée sur un seul poste. Automatiser ce qui s'y fait chaque jour semblait réservé à la saisie manuelle ou à des robots fragiles. Le 1er octobre 2026, GitHub a ouvert en préversion publique une fonction qui change la question : Copilot peut désormais piloter des applications de bureau comme le ferait un utilisateur.
Cet article explique ce que GitHub a annoncé, ce que cela change pour automatiser un logiciel sans API, et pourquoi la bonne réponse reste, pour un processus récurrent, rarement « laisser un agent cliquer ». Les informations sur le produit viennent de l'annonce officielle de GitHub ; la fonction étant en préversion, vérifiez sa disponibilité et ses conditions avant tout projet.
Ce que GitHub a annoncé
D'après l'annonce, Copilot peut lire le contenu d'une application, cliquer sur des contrôles, saisir du texte, appuyer sur des touches, faire défiler, glisser-déposer et enchaîner les étapes d'un parcours. La fonction est disponible en préversion publique dans Copilot CLI et dans l'application Copilot, sur macOS et sur Windows.
GitHub précise qu'elle s'adresse notamment aux logiciels anciens ou à interface graphique uniquement, qui n'ont ni API, ni ligne de commande, ni intégration MCP. L'annonce cite comme exemples le résumé de notifications dans un navigateur, la mise à jour d'une présentation ou le traitement de workflows dans une application de bureau.
Côté contrôle, GitHub indique que Copilot demande une approbation avant de piloter une application, que l'utilisateur peut revoir ou réinitialiser les applications qu'il a choisi d'autoriser en permanence, et que des paramètres gérés par l'organisation peuvent désactiver la fonction. Sur macOS, des autorisations d'accessibilité et d'enregistrement d'écran sont nécessaires. L'annonce ne précise pas les formules d'abonnement concernées : consultez la documentation GitHub avant de chiffrer quoi que ce soit.
Pourquoi c'est un vrai changement pour une PME
Jusqu'ici, un agent IA ne pouvait agir que là où une porte d'entrée existait : une API, un connecteur, un fichier à déposer. Un logiciel fermé restait en dehors du périmètre. Le pilotage par l'interface graphique sert de couche d'intégration de dernier recours : si un humain peut faire l'action avec la souris et le clavier, un agent peut en principe tenter de la faire aussi.
Pour une PME, cela ouvre trois cas qui bloquaient :
- un logiciel métier ancien dont l'éditeur ne propose aucune interface de programmation ;
- un portail web tiers sans export ni API, utilisé tous les jours pour une saisie répétitive ;
- une application interne développée il y a longtemps, que personne ne veut ou ne peut plus modifier.
Ce que cela ne change pas
Une interface graphique n'est pas un contrat. Une API garantit un format, des erreurs explicites et une version ; un écran peut changer de place un bouton après une mise à jour, afficher une fenêtre inattendue ou ralentir un jour de forte charge. Un agent qui clique doit interpréter ce qu'il voit, ce qui introduit de la variabilité là où un processus récurrent a besoin de régularité.
Cette lecture est la nôtre, pas celle de GitHub : l'annonce ne publie aucune mesure de fiabilité, de vitesse ou de coût pour ce mode, et le produit est en préversion. Il faut donc le traiter comme une option à tester, pas comme une fondation.
Il y a aussi un risque propre à ce mode : l'agent agit avec les droits de la session ouverte. S'il se trompe de bouton dans un logiciel de comptabilité ou de paie, l'action est réelle. C'est pourquoi la question des permissions et des confirmations passe avant la question de la productivité.
Computer use, API, workflow : quel outil pour quel cas ?
Le choix dépend de la répétition du processus, du risque de l'action et de l'existence d'une porte d'entrée propre. Le tableau ci-dessous résume une grille de décision à adapter ; c'est une proposition de méthode, pas une règle universelle.
| Situation | Approche à privilégier | Pourquoi |
|---|---|---|
| Processus quotidien, volume régulier, une API existe | Workflow déterministe sur l'API | Résultat reproductible, erreurs explicites, facile à surveiller |
| Processus régulier, logiciel sans API, action à faible risque | Essai de computer use avec approbation à chaque étape | Permet de tester sans développer d'intégration |
| Action irréversible ou sensible (paiement, suppression, envoi client) | Validation humaine obligatoire, ou ne pas déléguer | Une erreur de clic a un coût réel |
| Tâche occasionnelle, une fois par mois | Rester manuel ou assisté ponctuellement | L'automatisation ne se rentabilise pas |
| Processus critique sur un logiciel sans API | Chercher d'abord une porte d'entrée : export, base de données, connecteur éditeur | Plus stable que de simuler une personne devant un écran |
Sur les rôles respectifs d'un agent et de workflows déterministes, notre article sur n8n Agents détaille un partage qui reste valable ici : l'agent décide, les étapes sensibles sont exécutées par un mécanisme maîtrisé.
Cinq garde-fous avant d'essayer
Si vous décidez d'expérimenter, posez ces règles avant le premier essai. Elles s'appuient sur les contrôles décrits par GitHub et sur de bonnes pratiques d'exploitation.
- Un périmètre écrit. Quelle application, quelle tâche, quel résultat attendu. GitHub recommande lui-même de décrire le résultat voulu, les applications concernées et les contraintes importantes.
- Un environnement de test. Une copie du logiciel ou un compte sans données réelles pour les premiers essais, jamais la base de production.
- Des droits minimaux. Un compte utilisateur dédié, limité aux écrans nécessaires, plutôt que la session d'un administrateur.
- L'approbation conservée. Ne pas autoriser « toujours » une application tant que la fiabilité n'est pas observée, et revoir régulièrement la liste des applications autorisées.
- Une trace et un contrôle du résultat. Comparer ce que l'agent a fait à ce qui était attendu, sur un échantillon, avant d'étendre.
Ces points rejoignent la méthode décrite dans notre guide pour cadrer un premier agent IA : périmètre écrit, validation humaine, jeu d'essai et déploiement par paliers.
Données personnelles : ne pas oublier le cadre
Un agent qui lit l'écran voit tout ce qui s'y affiche, y compris des données de clients ou de salariés. Avant d'essayer, vérifiez quelles données apparaissent dans les écrans concernés, où est traité ce qui est capturé et ce que prévoient les conditions du service utilisé. Cette vérification relève du RGPD et de votre politique interne ; en cas de doute, faites-la valider par la personne qui en est responsable dans votre structure.
Une démarche réaliste en quatre étapes
- Lister les tâches répétitives qui passent par un logiciel sans API, avec leur fréquence et leur risque.
- Chercher d'abord une porte d'entrée stable : export de fichier, connecteur de l'éditeur, accès à la base, outil de type n8n, Make ou Zapier.
- Tester le computer use sur une tâche à faible risque, avec approbation à chaque étape, dans un environnement de test.
- Décider sur preuves : taux d'erreurs constaté, temps réellement gagné, effort de supervision. Si le gain n'est pas net, revenir à une intégration plus classique.
Si vous hésitez sur le bon niveau d'automatisation pour votre situation, notre approche part toujours d'un processus précis et de ses risques, et nos offres détaillent les formats d'accompagnement.
FAQ
Le computer use de GitHub Copilot est-il disponible pour tout le monde ?
D'après l'annonce du 1er octobre 2026, la fonction est en préversion publique dans Copilot CLI et dans l'application Copilot, sur macOS et Windows. L'annonce ne précise pas les formules d'abonnement concernées et indique que les paramètres gérés par l'organisation peuvent la désactiver. Vérifiez la documentation de GitHub avant tout projet.
Peut-on automatiser un logiciel sans API de façon fiable avec un agent ?
Rien dans l'annonce ne permet de l'affirmer : GitHub ne publie pas de mesure de fiabilité pour ce mode, encore en préversion. Pour un processus récurrent et critique, une intégration par export, base de données ou connecteur reste plus stable. Le pilotage de l'écran est surtout une option à tester sur des tâches à faible risque.
L'agent peut-il agir sans que personne ne valide ?
GitHub indique que Copilot demande une approbation avant de piloter une application, et que l'utilisateur peut choisir d'autoriser certaines applications de façon permanente. Conserver l'approbation, au moins le temps d'observer la fiabilité, est une précaution raisonnable.
Quels types de tâches éviter de confier à un agent qui clique ?
Les actions irréversibles ou sensibles : paiements, suppressions, envois à des clients, modifications de paie ou de comptabilité. Pour celles-là, gardez une validation humaine explicite, ou ne les déléguez pas.
Faut-il remplacer ses automatisations existantes par du computer use ?
Non. Si une API ou un connecteur existe, un workflow déterministe est en général plus prévisible, plus facile à surveiller et moins sensible aux changements d'interface. Le pilotage de l'écran sert de solution de dernier recours.
Pour aller plus loin
Vous avez un logiciel sans API au cœur d'un processus répétitif et vous voulez savoir s'il vaut la peine de l'automatiser, et par quelle voie ? Décrivez-nous le processus : nous regardons ensemble la porte d'entrée la plus stable et le niveau de contrôle à prévoir.