Bytebot

Une phrase pour présenter

Bytebot est un agent intelligent de bureau open source et auto-hébergé pour l’IA, qui fournit aux modèles un environnement virtuel Linux indépendant leur permettant de regarder l’écran, de déplacer la souris, de saisir du texte, de manipuler des fichiers et d’effectuer des tâches en langage naturel entre différentes applications.

Qu’est-ce que Bytebot ?

Bytebot n’est pas simplement un proxy navigateur qui fonctionne dans le DOM d’une page web, mais il assemble le bureau Ubuntu, des services pour les tâches d’IA, une interface de gestion Web et des bases de données en un environnement automatisé containerisé. Les agents peuvent utiliser Firefox, VS Code, la terminal, des clients de messagerie ainsi que des applications installées par l’utilisateur lui-même.

Le projet a été développé par Tantl Labs et la communauté open source, et son code est soumis à la licence Apache 2.0. Il convient de noter que le répertoire officiel GitHub a été archivé en mode lecture seule le 7 mars 2026 ; bien que le site web et les documents restent accessibles, la maintenance par les développeurs principaux, la correction des vulnérabilités et les mises à jour fonctionnelles ne peuvent plus s’effectuer comme pour un projet actif.

État actuel du projet

Architecture du système

Fonction principale

• Tâche en langage naturel : décrire l’objectif en langue commune, puis le robot planifie et exécute des opérations sur le bureau.
• Environnement de bureau complet : il est possible d’utiliser un navigateur, un éditeur, une terminal, un client de messagerie et d’autres applications de bureau Linux.
• Traitement de fichiers : téléchargement, téléchargement, lecture, organisation et génération de PDF, de tableaux, de documents et d’autres fichiers.
• Flux de travail inter-applications : transmission d’informations entre sites web, systèmes de fichiers, terminaux et programmes de bureau.
• Opérations informatiques visuelles : comprendre l’interface à l’aide de captures d’écran, puis effectuer des clics, des défilements, des pressions de touches et des saisies de texte.
• Gestion de l’état des tâches : enregistrement de la priorité, de l’état d’exécution, des messages, des opérations et des résultats historiques.
• Voir l’écran en temps réel : observer les actions de l’agent et l’état actuel de l’écran depuis la page des tâches.
• Prise en main manuelle : Lorsque l’agent rencontre des problèmes de connexion, des anomalies ou des difficultés de jugement, l’utilisateur peut accéder au bureau pour effectuer les étapes clés.
• Environnement persistant : le logiciel installé et les paramètres peuvent être réutilisés dans des tâches ultérieures.
• Soutien aux gestionnaires de mots de passe : 1Password ou Bitwarden peuvent être installés sur le bureau pour gérer les connexions et la double authentification.
• Contrôle programmé : API de tâches, API de contrôle de bureau de bas niveau et points d’entrée MCP.
• Accès à plusieurs modèles : il est possible de configurer directement les clés d’Anthropic, OpenAI et Google, ou de se connecter à d’autres fournisseurs via LiteLLM.

Comment Bytebot fonctionne

1. L’utilisateur soumet des objectifs en langage naturel depuis l’interface de tâche ou l’API de tâche, et peut joindre les fichiers à traiter.
2. L’agent d’IA lit la tâche et le contexte historique, puis décompose l’objectif en actions de navigation, de clic, de saisie, de fichier ou de script.
3. Le conteneur Desktop fournit l’écran actuel et une interface d’exécution, permettant au modèle de choisir la prochaine étape en fonction des résultats visuels.
4. Après chaque opération, le système retourne à un nouvel état d’écran, et l’agent continue d’évaluer, de corriger les erreurs ou de demander de l’aide à l’utilisateur.
5. Une fois la tâche terminée, enregistrez les messages, les captures d’écran et les fichiers de résultats ; l’utilisateur peut examiner l’ensemble du processus et décider s’il souhaite utiliser le résultat.

Deux modes d'utilisation

Tutoriel de déploiement auto-hébergé

Préparatifs avant le déploiement

• Installez un environnement Linux, macOS ou Windows prenant en charge les conteneurs ; privilégiez les serveurs isolés pour l’environnement de production.
• La version Docker doit être au moins 20.10, et Docker Compose doit être installé.
• Prévoyez au moins 4 Go de mémoire disponible ; les bureaux complexes et les tâches parallèles nécessitent plus de CPU, de mémoire et d’espace disque.
• Préparez les clés API pour des modèles compatibles avec Claude, GPT, Gemini ou LiteLLM.
• Comme le dépôt officiel a été archivé, vérifiez d’abord l’état de maintenance, les vulnérabilités et les branches communautaires avant de décider de la version à déployer.

Processus d’installation de Docker Compose

1. Obtenez le code depuis les archives officielles et l’incorporez à des dépôts ayant été examinés en interne, sans suivre directement des images marginales incertaines.
2. Copiez le fichier de configuration de l’environnement, remplissez uniquement la clé du fournisseur de modèles sélectionné, et restreignez les droits de lecture du fichier.
3. Vérifiez les ports, le mot de passe de la base de données, le mode privilégié et l’étiquette de l’image dans la configuration de Compose, afin de renforcer d’abord la sécurité.
4. Créer et démarrer les quatre services : Desktop, Agent, UI et PostgreSQL.
5. Ouvrez uniquement l’interface de tâche depuis un réseau fiable, et créez une tâche de test sans droits sensibles.
6. Vérifiez que le bureau, les fichiers, les journaux et la prise en main manuelle fonctionnent correctement, avant d’intégrer progressivement l’application réelle.

Configuration après déploiement

1. Installez uniquement les applications vraiment nécessaires sur le bureau virtuel, supprimez les outils inutiles et maintenez des droits d’accès minimaux.
2. Configurer un gestionnaire de mots de passe pour le compte de test, afin d’éviter d’enregistrer des mots de passe en clair dans les prompts ou les fichiers d’environnement.
3. Créer une liste blanche du réseau pour restreindre l’accès des appareils intelligents au réseau interne, à la console cloud et aux systèmes de gestion.
4. Configurer les journaux des tâches, la conservation des captures d’écran, le renouvellement des clés, le chiffrement du disque et les alertes en cas d’anomalie.
5. Laissez d’abord l’approbation manuelle pour les actions à haut risque telles que l’envoi d’e-mails, les paiements, la suppression de fichiers et l’écriture dans le système de production.
6. Après avoir terminé les tests de sécurité et l’acceptation par le service, ajoutez des bureaux simultanés ou des tâches planifiées.

Modèles pris en charge

Les modèles ne sont pas fournis gratuitement avec les projets open source ; les utilisateurs doivent assumer eux-mêmes les coûts de traitement et se conformer aux conditions d’utilisation. L’utilisation de modèles locaux permet de réduire le transfert de données externes, mais les capacités en matière de vision desktop, de planification de tâches longues et d’appel d’outils peuvent présenter des différences significatives par rapport aux modèles cloud.

À qui s’adresse-t-il

• Ingénieur en automatisation : Il est nécessaire de permettre à l’IA de contrôler l’ensemble du bureau, et non seulement d’appeler des interfaces web.
• Équipe de développement et de test : reconstitution automatique des problèmes d’interface, exécution de processus bout en bout et collecte d’écrans comme preuves.
• Équipe IT d’entreprise : mise en place d’essais d’automatisation d’interfaces isolées pour les systèmes anciens sans API.
• Équipe de traitement de documents : lecture, organisation et saisie entre fichiers, navigateurs et applications de bureau.
• Chercheurs en IA : recherche sur l'utilisation des ordinateurs, les agents de bureau, la prise de contrôle artificielle et les performances multi-modèles.
• Développeurs open source : créer leurs propres branches de maintenance ou des agents desktop personnalisés à partir du code Apache 2.0.

Scénarios d'utilisation typiques

• Traitement des factures fournisseurs : se connecter à plusieurs portails pour télécharger des fichiers, organiser les dossiers et générer un résumé.
• Saisie de données inter-systèmes : lecture des enregistrements depuis des tableaux, puis écriture dans les interfaces CRM ou ERP qui ne disposent pas d’une API ouverte.
• Recherche technique : consultation de documents, téléchargement de PDF, lecture du contenu et création de documents de comparaison dans un éditeur.
• Test logiciel : ouvrir l’application, reproduire les étapes de l’utilisateur, capturer les écrans d’erreur et créer un rapport de test.
• Développement et validation : exécuter des commandes, modifier les fichiers d’exemple, lancer le service, puis vérifier les résultats avec un navigateur.
• Collecte de documents de conformité : consultation des pages des organismes publics, téléchargement de fichiers et mise à jour des tableaux de suivi internes.
• Processus de messagerie et de fichiers : lecture des pièces jointes des e-mails spécifiés, stockage classé et génération des résultats à examiner.

Avantages du produit

• Fournit un bureau Linux complet, couvrant les navigateurs, le système de fichiers, la console et les applications natives.
• L’utilisation d’objectifs en langage naturel convient aux tâches où l’interface change fréquemment et qui sont difficiles à planifier entièrement à l’avance.
• L’architecture auto-hébergée permet aux entreprises de contrôler le réseau, les fichiers, les images d’écran et la conservation des données.
• Prend en charge la prise de contrôle manuelle ; permet de suspendre l’automatisation en cas de connexion, d’anomalie ou de décision cruciale.
• Les APIs de tâches, l’API d’utilisation du ordinateur et MCP facilitent l’intégration avec des proxies et des systèmes de planification personnalisés.
• La licence Apache 2.0 permet aux organisations de modifier, de déployer et de distribuer leurs propres versions.
• Il est possible de se connecter à plusieurs modèles cloud ou locaux, sans être obligé d’utiliser un seul fournisseur d’inférence.
• Chaque bureau est isolé par un conteneur, ce qui facilite la création d’environnements de travail avec des configurations d’applications et de permissions différentes.

Limites importantes

• Le dépôt officiel a été archivé, le projet original ne fait plus l’objet d’une maintenance normale, et les documents de dépendances, d’images et de déploiement deviendront progressivement obsolètes.
• Les opérations sur le bureau visuel sont plus lentes que les API déterministes et les scripts, et elles sont également plus sensibles aux fenêtres contextuelles, aux résolutions et aux changements d’interface.
• Le modèle peut mal interpréter l’écran, cliquer au mauvais endroit, écraser des fichiers ou soumettre un formulaire incorrect ; il ne doit pas effectuer d’opérations à haut risque sans vérification.
• L’isolation des conteneurs ne signifie pas automatiquement sécurité ; les modes privilégiés, les répertoires montés, les permissions réseau et les clés peuvent élargir l’étendue des impacts.
• Le logiciel auto-hébergé ne comporte pas de limite de consommation, mais l’API des modèles, les serveurs cloud, le stockage, la bande passante et la maintenance entraînent des frais.
• L’interface par défaut locale ne dispose d’aucune authentification ; son exposition directe à Internet ou à un réseau local non fiable comporte un risque grave de prise de contrôle.
• Les gestionnaires de mots de passe peuvent réduire l’exposition des clés en texte brut, mais le contenu de l’écran et les résultats des opérations visibles par l’IA peuvent encore contenir des informations sensibles.
• Le projet ne dispose pas actuellement de prix ni d’engagements de service pour le cloud hébergé, et les liens d’essai présents sur les anciennes pages ne doivent pas être considérés comme des forfaits commerciaux disponibles.

Risques de sécurité et recommandations de renforcement

Par défaut, la configuration Compose de Bytebot mappera les ports du bureau, des tâches, de l’interface et de la base de données, où le conteneur du bureau utilise un mode privilégié, et la base de données d’exemple emploie également un mot de passe par défaut. La documentation officielle de l’API indique que l’accès local ne nécessite pas de authentification par défaut ; ces configurations ne conviennent qu’à des environnements de développement contrôlés.

Le CVE-2026-30631, rendu public en juillet 2026, indique que le chemin d’écriture des fichiers dans les dépôts affectés peut déclencher une injection de commandes, et l’évaluation publique lui attribue un niveau de gravité de 9,8. Comme le répertoire a été archivé, les déploieurs ne peuvent pas supposer que des correctifs ultérieurs seront fournis par les développeurs officiels.

• Ne mappez pas directement les API de bureau, les API de tâches, la base de données et VNC sur Internet.
• Intégrer une authentification forte, TLS, une liste blanche d’IP et des journaux de requêtes dans un proxy inversé ou un réseau de services.
• Remplacez les identifiants de la base de données d’exemple et interdisez l’ouverture des ports de la base de données aux réseaux non essentiels.
• Évaluer la possibilité de supprimer le mode privilégié et de limiter les capacités du conteneur, les répertoires montés et l’accès hôte.
• Vérifiez l’impact du CVE, utilisez des correctifs audités ou des branches de maintenance ; en cas d’incertitude, ne réalisez pas de tâches sensibles.
• Stockez la clé API du modèle dans un système de gestion des clés, et interdisez son inclusion dans le code, les images ou la description des tâches.
• Attribuer un compte dédié à faibles privilèges pour l’ordinateur de bureau, sans se connecter avec le compte principal personnel ou le compte d’administrateur de production.
• Restreindre les routages réseau sortants et internes afin d’empêcher les agents d’accéder à des systèmes hors du champ de la tâche.
• Autorisation manuelle pour les paiements, la suppression, l’envoi de messages, la modification des permissions et le déploiement du code.
• Vider régulièrement les captures d’écran, les fichiers téléchargés, l’historique des conversations et les volumes persistants, et vérifier la stratégie de suppression des sauvegardes.

API REST et MCP

L’API Agent est conçue pour la gestion de tâches de haut niveau, tandis que l’API Desktop sert au contrôle de bas niveau du curseur, du clavier et de l’écran. L’orchestration en production doit privilégier les interfaces au niveau des tâches, et n’appeler l’API Desktop que lorsque la détermination d’actions de contrôle est nécessaire.

Processus d’intégration pour les développeurs

1. Démarrer la version auditée de Bytebot dans un environnement isolé, et vérifier que les services de tâches, du bureau et de la base de données sont opérationnels.
2. Créez d’abord une tâche de test lisible ou sans effets secondaires via l’interface de tâches, et enregistrez l’identifiant de la tâche ainsi que les changements d’état.
3. Poller des tâches ou s’abonner à des mises à jour en temps réel pour gérer les états de fin de traitement, d’échec, d’annulation et de besoin d’aide.
4. Lorsqu’une contrôle précis est nécessaire, appeler l’action uniforme Computer Use et vérifier l’écran de retour après chaque action.
5. Ajouter une authentification, des droits minimaux, des limites de vitesse, des délais d’expiration et un contrôle d’identité pour les appels à distance.
6. Considérer les captures d’écran, les fichiers et les journaux comme des données sensibles, et les chiffrer, masquer et nettoyer selon les exigences métier.
7. Exécuter des tests de régression et de sécurité avant de mettre à jour un modèle, une image ou une branche communautaire.

Prix et coût réel

Le code source de Bytebot peut être utilisé gratuitement sous la licence Apache 2.0, sans frais de abonnement pour un logiciel open source officiel. Le site officiel ne fournit pas de prix pour les forfaits de hébergement cloud valables à la date de vérification, il est donc impossible d’indiquer un tarif mensuel fixe ou un service cloud gratuit à vie.

Licences open source et état de maintenance

Apache 2.0 autorise la copie, la modification, la distribution et l’utilisation commerciale du code source, et comprend également des licences de brevet correspondantes. Lors de la distribution de versions modifiées, il est nécessaire de conserver la licence et la déclaration de propriété, ainsi que d’indiquer clairement les modifications apportées aux fichiers ; les marques commerciales du projet ne sont pas automatiquement autorisées par cela.

La licence open source reste valide à long terme, mais l’archivage du dépôt signifie que la maintenance officielle a été interrompue ou suspendue. Si une entreprise souhaite continuer à l’utiliser, elle doit créer ses propres branches, mettre à jour les dépendances, gérer les réponses en matière de sécurité et suivre des processus de publication, ou choisir une branche communautaire bénéficiant d’une maintenance continue.

Confidentialité et traitement des données

L’hébergement auto-géré permet de conserver les tâches, les bases de données, les captures d’écran et les fichiers au sein de sa propre infrastructure, mais le modèle cloud choisi peut néanmoins recevoir des notifications, des captures d’écran ou du contenu de fichiers. La portée précise des transferts dépend de la version de Bytebot, du mode de connexion au modèle et de la mise en œuvre de la tâche.

L’utilisation de modèles locaux permet de réduire les envois vers l’extérieur, mais elle ne peut pas éliminer les risques liés aux droits d’accès au poste de travail, aux journaux, aux sauvegardes et aux accès internes. Avant le déploiement, il convient de cartographier les flux de données, de vérifier les politiques du fournisseur de modèles et de contrôler les captures d’écran, les clés et les fichiers sensibles selon le principe de minimisation.

Informations de base

Indice de recommandation

Le score de recommandation est de 3,2 sur 5. L’interface desktop complète de Bytebot, son code open source, les options de modèles et son API à deux niveaux conservent une valeur pour l’apprentissage, la recherche et le développement secondaire, étant particulièrement adaptés à la compréhension de l’architecture des agents desktop.

Les points déduits proviennent principalement de l’archivage dans des entrepôts officiels, d’un manque de maintenance continue en amont, d’une portée de déploiement par défaut importante, ainsi que de vulnérabilités graves déjà divulguées. À ce stade, il n’est pas recommandé de l’utiliser directement pour des activités sensibles en production, sauf si l’équipe est capable de mener une audit du code, de corriger les problèmes, d’isoler les composants concernés et d’en assurer la maintenance à long terme.

Questions fréquentes

Bytebot est-il gratuit ?

Le code source peut être utilisé gratuitement sous la licence Apache 2.0. L’API des modèles, les serveurs cloud, le matériel local, le stockage ainsi que l’exploitation sécurisée doivent encore être payés séparément ; à l’heure actuelle, il n’existe pas de prix officiel confirmé pour les forfaits cloud.

Bytebot est-il encore maintenu ?

Le dépôt GitHub officiel a été archivé en mode lecture seule le 7 mars 2026 et ne peut donc pas être considéré comme étant maintenu activement. Le fait que le site web et la documentation soient en ligne ne signifie pas pour autant qu’il y ait des mises à jour continues ou une réponse en cas de problème de sécurité.

Peut-on l’utiliser sous Windows ou macOS ?

L’agent central fonctionne dans un environnement de bureau Ubuntu containerisé, tandis que Windows et macOS peuvent servir d’hôte Docker ou d’interface d’accès. Ce n’est pas un assistant personnel natif qui contrôle directement le bureau actuel de Windows ou de macOS.

Est-ce que les modèles locaux sont pris en charge ?

Le document liste, via l’intégration LiteLLM, les solutions de modèles locaux tels qu’Ollama. Les performances en matière de vision desktop réelle et de processus longs dépendent des capacités du modèle, du contexte et du matériel, et doivent être évaluées séparément.

Une API est-elle disponible ?

Fourni. L’API Agent est utilisée pour la gestion des tâches, tandis que l’API Desktop sert au contrôle de niveau bas des écrans, de la souris, du clavier et des fichiers ; par défaut, l’interface locale n’est pas authentifiée.

Est-ce que MCP est pris en charge ?

Le service Desktop fournit des endpoints MCP qui permettent d’exposer des outils de contrôle de bureau aux clients compatibles. La documentation utilise une méthode de connexion SSE plus ancienne ; il convient de vérifier la compatibilité du protocole avant de se connecter à de nouveaux clients.

Bytebot est-il sécurisé ?

Il n’est pas possible de tirer directement des conclusions sur la sécurité. Par défaut, les interfaces non authentifiées, les conteneurs privilégiés, les mots de passe de bases de données d’exemple ainsi que les vulnérabilités graves d’injection de commandes divulguées exigent que le déploiteur renforce et corrige lui-même ces éléments.

Les données quitteront-elles mon serveur ?

Les tâches et les bureaux peuvent être gérés de manière autonome, mais lorsque des modèles cloud sont utilisés, des indications pertinentes, des captures d’écran ou le contenu des fichiers peuvent être envoyés au fournisseur du modèle. Ce n’est qu’en combinant du code, des paramètres de configuration et les politiques relatives aux modèles que l’on peut déterminer le flux de données réel.

Peut-il être utilisé pour gérer les banques et les systèmes de paiement ?

Techniquement, il est possible de contrôler le navigateur et le gestionnaire de mots de passe, mais aucune opération financière ne devrait être exécutée sans surveillance dans la version archivée actuelle. Il est nécessaire au minimum un compte à faibles privilèges, une confirmation manuelle, un réseau isolé, des limites de transaction et un audit complet.

L’SDK officiel est-il open source ?

Aucun SDK officiel distinct n’a été trouvé ; le code source du projet lui-même ainsi que des exemples d’appels aux interfaces sont disponibles. Le fait que le produit soit open source et l’existence d’un SDK sont deux choses différentes.

Peut-on encore l’utiliser à des fins commerciales une fois archivé ?

La licence autorise toujours une utilisation commerciale conforme, mais l’équipe doit assumer elle-même les responsabilités en matière de maintenance, de sécurité, de marques déposées et de dépendances vis-à-vis de tiers. Avant de fournir des services à l’extérieur, il est également nécessaire de vérifier les autorisations respectives des modèles, des applications et du contenu.

Résumé

Bytebot montre comment combiner un bureau Linux complet, une planification par IA, une interface de tâches, une base de données et une interface d’utilisation du ordinateur pour créer un agent intelligent de bureau auto-hébergé. Il reste une référence open source précieuse, pouvant également servir de point de départ pour des développements ultérieurs.

Mais le fait le plus important à l’heure actuelle est que le dépôt a été archivé et qu’il existe des risques de sécurité qui doivent être traités avec sérieux. Il est recommandé de l’utiliser pour l’isolation de la recherche et les prototypes contrôlés ; si son utilisation en production est envisagée, il convient d’abord d’adopter une branche de maintenance auditée, ainsi que d’établir des systèmes d’authentification, de correctifs, de permissions, de réseau et d’approbation manuelle.