Open Interface : piloter un ordinateur de bureau par LLM, avec pyautogui comme seule interface
Control Any Computer Using LLMs.
En bref
- De quoi s’agit-il ?
- Open Interface transforme une demande en langage naturel en une suite de frappes clavier et de mouvements de souris, en s'appuyant sur GPT-4o ou Gemini et sur des captures d'écran successives. Le projet est multiplateforme, sous GPL-3.0, et sa dernière version publiée remonte à mars 2025.
- À qui s’adresse-t-il ?
- Open Interface convient à un développeur qui veut expérimenter le contrôle d'un bureau par un modèle de vision sur une machine dédiée, pas à une équipe qui cherche un exécuteur fiable en production. Avant toute adoption, vérifiez la date du dernier commit sur la branche main et lisez la sortie du modèle avant de laisser le programme agir, car aucune validation intermédiaire n'est décrite dans la documentation.
- Puis-je l’utiliser commercialement ?
- Oui, sous conditions. GPL-3.0 est une licence copyleft : si vous distribuez un logiciel qui l’inclut, vous devez publier le code source de ce logiciel sous la même licence. Un usage interne, sans distribution, ne déclenche pas cette obligation.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 61 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un problème d'automatisation que les API ne couvrent pas
La plupart des automatisations reposent sur une API ou un script déterministe. Dès qu'une tâche traverse une interface graphique sans API (un logiciel interne, un panneau d'administration, un jeu), il faut écrire du pyautogui à la main, avec des coordonnées codées en dur. Open Interface attaque ce cas précis : l'utilisateur formule une demande en langage naturel, et le programme déduit lui-même la séquence d'actions.
La cible est donc étroite. Il faut accepter qu'un modèle de vision regarde l'écran, qu'il se trompe, et que la correction passe par une nouvelle capture. Le README illustre l'usage avec des démonstrations comme « Solve Today's Wordle » ou « Make me a meal plan in Google Docs ». Ce sont des tâches à état visible, où l'erreur se détecte à l'écran. Une opération de base de données sans retour visuel ne relève pas de cet outil.
La boucle capture, décision, frappe
Le mécanisme tient en trois temps, décrits dans le README : la demande part vers un backend LLM qui détermine les étapes nécessaires, le programme exécute ces étapes en simulant clavier et souris, puis il renvoie au modèle des captures d'écran mises à jour pour se recaler. Le README parle de « course-corrects » : la correction n'est pas planifiée à l'avance, elle émerge de la comparaison entre l'état attendu et l'état observé.
Cette architecture a une conséquence directe sur le coût. Chaque cycle de correction est un appel au modèle avec une image en entrée, et les modèles de vision facturent l'image. Une tâche qui demande vingt captures consomme vingt appels multimodaux. Le projet ne publie aucun chiffre sur ce point, donc la seule façon de connaître la facture est de compter les appels lors d'un essai.
Le choix de pyautogui comme unique canal d'action est cohérent avec la promesse multiplateforme, mais il plafonne la précision. Le modèle raisonne sur une capture, pas sur l'arbre d'accessibilité des widgets. Il ne sait pas qu'un bouton porte un identifiant ; il voit des pixels.
Installer : binaire par plateforme ou script Python
Le README documente deux voies. La première passe par les binaires de la dernière release. Sous macOS, il faut décompresser l'archive, déplacer Open Interface dans le dossier Applications, puis accorder deux autorisations dans Réglages Système, Confidentialité et sécurité : Accessibilité, pour piloter clavier et souris, et Enregistrement de l'écran, pour les captures. Sur les Mac Intel, le README signale l'erreur classique de développeur non vérifié et indique la marche à suivre : cliquer sur Annuler, puis ouvrir Réglages Système, Confidentialité et sécurité, et choisir Ouvrir quand même.
Sous Linux, le binaire n'a été testé que sur Ubuntu 20.04 selon le README. Sous Windows, il a été testé sur Windows 10. Ces deux mentions limitent la portée du support : une distribution récente ou un Windows 11 ne sont pas couverts par la documentation.
La seconde voie est l'exécution comme script, avec Python 3.12 ou plus récent, après un git clone du dépôt. Le README renvoie ensuite à sa section Setup pour connecter Open Interface à un backend LLM, en citant OpenAI GPT-4V. Les clés d'API et les noms de fournisseurs exacts ne figurent pas dans l'extrait disponible, donc je ne peux pas les citer ici : consultez la section Setup du dépôt avant de configurer quoi que ce soit.
Deux permissions système qui définissent le périmètre de risque
L'Accessibilité et l'Enregistrement de l'écran ne sont pas des détails d'installation. Elles accordent au programme exactement ce dont un LLM a besoin pour agir sur la machine : voir tout ce qui s'affiche et produire n'importe quelle frappe. Une fois ces deux droits donnés, la seule barrière entre une instruction mal interprétée et une action réelle est la qualité du raisonnement du modèle.
Le README ne décrit ni confirmation avant exécution, ni liste blanche d'applications, ni journal d'audit. C'est le point que je vérifierais en premier dans le code, parce qu'il détermine si l'outil est utilisable sur une machine de travail ou seulement dans une machine virtuelle jetable. La documentation ne tranche pas cette question.
Là où l'outil devient le mauvais choix
La limite principale est la détection d'échec. Si le modèle clique au mauvais endroit et que l'écran résultant ressemble à ce qu'il attendait, la boucle de correction n'a rien à corriger. Le programme continue sur une trajectoire fausse. Ce mode de défaillance est silencieux, et c'est précisément ce qui le rend dangereux sur une tâche destructive.
Deuxièmement, la latence. Chaque étape suppose un aller-retour réseau plus une inférence multimodale. Pour une tâche de bureau ordinaire, c'est plus lent qu'un script pyautogui écrit à la main, et le résultat est moins prévisible. Troisièmement, la reproductibilité : le même prompt sur la même machine peut produire des séquences différentes, ce qui exclut l'usage en intégration continue.
Enfin, le README ne mentionne pas de mode sans interface graphique. Un serveur headless n'a pas d'écran à capturer, donc l'outil ne s'y applique pas.
Face à un agent qui lit l'arbre d'accessibilité
L'alternative la plus directe n'est pas un autre projet de pilotage par LLM, mais les API d'accessibilité du système d'exploitation : UIAutomation sous Windows, AXUIElement sous macOS, AT-SPI sous Linux. Ces interfaces exposent la structure des fenêtres, les rôles des contrôles et leurs libellés. Un agent construit dessus cible un bouton par son nom plutôt que par ses coordonnées, et il sait qu'un clic a échoué parce que l'état du contrôle n'a pas changé.
La différence d'approche est nette. Open Interface traite l'écran comme une image et demande au modèle de vision de deviner où cliquer. Une approche par accessibilité traite l'interface comme un graphe d'objets et réduit le rôle du modèle à la sélection de l'élément suivant. La première fonctionne sur n'importe quelle application, y compris celles qui dessinent leurs propres contrôles. La seconde est plus fiable mais aveugle sur les applications qui n'exposent rien. Le choix dépend donc de la nature des logiciels visés, pas de la préférence pour un modèle.
Licence, maintenance et coût de mise à jour
Open Interface est publié sous GPL-3.0. Concrètement, si vous redistribuez une version modifiée du programme, vous devez fournir le code source correspondant sous la même licence. Un usage interne ne déclenche pas cette obligation de la même manière qu'une distribution, mais je ne donne pas d'avis juridique : faites relire votre cas si vous intégrez le code dans un produit livré à des tiers. La licence est compatible avec un usage commercial du logiciel, à condition de respecter ses termes.
Sur la maintenance, les faits disponibles sont limités. La dernière release listée est v0.9.0, datée du 16 mars 2025, précédée de v0.8.0 en janvier 2025 et de 0.7.0 en décembre 2024. Le dépôt n'est pas archivé. La branche main a reçu un push le 17 juillet 2026 selon les métadonnées du dépôt, soit après la dernière release publiée. Cet écart entre commits et releases signifie qu'une partie du travail récent n'est peut-être pas empaquetée dans un binaire téléchargeable. Si vous dépendez des binaires, vous suivez le rythme des releases ; si vous clonez le dépôt, vous suivez la branche main, avec ce que cela implique d'instabilité.
Le coût récurrent réel n'est pas la maintenance du code mais les appels au modèle. Il évolue avec les tarifs du fournisseur choisi, pas avec les versions d'Open Interface.
Conclusion éditoriale
Open Interface convient à un développeur qui veut expérimenter le contrôle d'un bureau par un modèle de vision sur une machine dédiée, pas à une équipe qui cherche un exécuteur fiable en production. Avant toute adoption, vérifiez la date du dernier commit sur la branche main et lisez la sortie du modèle avant de laisser le programme agir, car aucune validation intermédiaire n'est décrite dans la documentation.
Notes de la communauté