Comment Devin utilise un environnement de bureau complet pour interagir avec des interfaces graphiques, tester des applications et vérifier visuellement les modifications
Devin a accès à un environnement de bureau complet — pas seulement un navigateur. Il peut déplacer la souris, cliquer sur des éléments de l’interface, taper au clavier, prendre des captures d’écran et interagir avec n’importe quelle application qui s’exécute sur le bureau. Cette capacité s’appelle Computer Use, et elle permet à Devin de tester et d’interagir avec votre logiciel de la même manière qu’un humain le ferait.Computer Use fonctionne sur les sessions Linux (la plateforme de session par défaut) et Windows, ainsi que sur les machines Outposts — y compris macOS — qui disposent d’un bureau graphique. Consultez Plateformes prises en charge pour plus de détails.
Computer Use donne à Devin un accès direct à un environnement de bureau graphique avec souris et clavier. Cela va au-delà de l’automatisation du navigateur : Devin peut interagir avec n’importe quelle application qui s’affiche à l’écran, y compris :
Les applications web dans Chrome (cliquer sur des boutons, remplir des formulaires, naviguer entre les pages)
Les applications de bureau qui s’exécutent sur la plateforme de la session (Linux ou Windows), y compris les applications Electron, les IDE et les interfaces graphiques natives de la plateforme
Les interfaces basées sur le terminal (programmes TUI, CLI interactives)
Toute interface visuelle qui peut être affichée sur le bureau
Devin voit l’écran comme un écran de 1024×768 pixels et peut effectuer des actions comme cliquer, taper, faire défiler, faire glisser et prendre des captures d’écran — comme un humain assis devant l’ordinateur.
Pris en charge — les sessions s’exécutent dans un environnement de bureau Linux complet
Windows
Pris en charge — les sessions sur les environnements Windows s’exécutent dans un environnement de bureau Windows complet
Outposts (Linux)
Pris en charge lorsque la machine dispose d’une session X active (DISPLAY défini pour le worker, par exemple une session de bureau ou Xvfb). Les machines sans interface graphique reçoivent à la place une erreur explicite. Consultez Computer Use sur Outposts.
Outposts (macOS)
Pris en charge — Devin utilise la session de bureau existante de la machine. Les captures d’écran nécessitent l’autorisation Enregistrement de l’écran ; les actions de souris et de clavier nécessitent en outre l’autorisation Accessibilité. Consultez Computer Use sur Outposts.
macOS (Devin Cloud)
Non disponible — les sessions macOS s’exécutent uniquement sur Outposts
L’expérience Computer Use est la même sur toutes les plateformes : Devin utilise la souris et le clavier, prend des captures d’écran, exécute Chrome pour les applications web et peut enregistrer ses sessions de test. Sous Windows, Devin peut également tester des applications de bureau natives de Windows (p. ex. WPF, WinForms et d’autres applications qui ne s’exécutent que sous Windows). Pour exécuter des sessions sous Windows, configurez un blueprint Windows comme indiqué dans la documentation sur la prise en charge de Windows.
Quand Devin crée une PR, il propose un bouton Tester l’app. En cliquant sur ce bouton, vous déclenchez le workflow de test complet : Devin démarre votre application, utilise Computer Use pour interagir avec le bureau, teste les modifications et vous envoie un enregistrement.
Vous pouvez demander à Devin d’exécuter des tests à tout moment pendant une session — aucune syntaxe particulière n’est nécessaire, utilisez simplement le langage naturel. Par exemple :
« Testez les modifications que vous venez d’effectuer et envoyez-moi un enregistrement »
« Ouvrez l’application dans le navigateur et vérifiez que la page de connexion fonctionne »
« Lancez l’application de bureau et vérifiez que le nouvel élément de menu apparaît »
Devin décide de lui-même quand l’interaction avec le bureau est l’outil le plus adapté à la tâche. Si une tâche implique de cliquer sur des éléments d’interface, de naviguer dans une application, de remplir des formulaires ou de vérifier visuellement quelque chose, Devin utilisera Computer Use sans qu’on le lui demande explicitement. Vous n’avez pas besoin d’expliquer à Devin comment interagir avec l’écran — indiquez-lui simplement ce qu’il doit accomplir.
Devin peut démarrer votre application en local, l’ouvrir dans Chrome et parcourir des parcours utilisateur complets — connexion, navigation, saisie de formulaires, finalisation de commande — en vérifiant que tout fonctionne comme prévu.
Toute application qui s’exécute sur la plateforme de sessions de Devin peut être testée. Dans les sessions Linux, cela inclut les applications Electron, les applications Java Swing/AWT, les applications GTK/Qt, et bien d’autres. Dans les sessions Windows, Devin peut également tester des applications propres à Windows, telles que les applications WPF et WinForms. Devin lance l’application, interagit avec son interface graphique et vérifie son comportement.
Devin peut prendre des captures d’écran à des moments précis pendant les tests pour vérifier que la mise en page, le style et les éléments d’interface utilisateur s’affichent correctement. Il peut comparer ce qu’il voit à l’écran par rapport au comportement attendu et signaler les problèmes visuels.
Interagir avec des flux d’interface utilisateur complexes
Certains scénarios de test nécessitent des interactions avec l’interface graphique en plusieurs étapes qui vont au-delà de simples appels d’API ou de l’automatisation du navigateur — des actions comme le glisser-déposer, les menus contextuels, les raccourcis clavier ou la navigation entre plusieurs fenêtres. Computer Use prend tout cela en charge.
Devin peut enregistrer son écran au cours des tests et annoter les moments clés dans la vidéo. L’enregistrement est ensuite traité et envoyé afin que vous puissiez regarder Devin interagir avec votre application et confirmer que les modifications fonctionnent. Consultez Tests et enregistrements vidéo pour plus de détails sur le processus d’enregistrement.
Lorsque Devin utilise Computer Use pendant une session, il suit ce processus :
Prend une capture d’écran de l’écran actuel pour comprendre ce qui est visible
Identifie les éléments interactifs — boutons, champs de texte, menus, liens — et décide avec lesquels interagir
Effectue une action — clique, tape, fait défiler ou utilise des raccourcis clavier
Attend et observe — prend une autre capture d’écran pour voir le résultat de l’action
Répète jusqu’à ce que la tâche soit terminée
Cette boucle capture d’écran–action permet à Devin de s’adapter à tout ce qui s’affiche à l’écran, en gérant le contenu dynamique, les états de chargement, les fenêtres contextuelles (pop-ups) et les boîtes de dialogue inattendues comme le ferait un humain.
Computer Use est au cœur du flux de travail de tests et enregistrements de Devin. Lorsque Devin teste votre application après avoir créé une PR :
Configuration — Devin installe les dépendances, lance votre application et prépare l’environnement
Planification des tests — Devin lit le diff et crée un plan de tests ciblé
Exécution via Computer Use — Devin utilise son bureau pour interagir avec votre application, en suivant le plan de tests étape par étape
Enregistrement — Le processus complet est capturé en vidéo avec des annotations, puis vous est envoyé pour relecture
La principale différence entre Computer Use et le workflow Testing & Recordings est la portée : Computer Use est la fonctionnalité sous-jacente (interaction avec le bureau), tandis que Testing & Recordings est le flux de travail structuré qui utilise Computer Use pour tester vos PR et fournir une preuve sous forme de vidéo.
Sur Outposts, les sessions s’exécutent sur les machines que vous gérez. Devin utilise donc l’environnement de bureau déjà présent sur la machine au lieu de provisionner le sien. L’outil computer est disponible dans chaque session en mode bureau ; si la machine ne prend pas en charge une action, celle-ci échoue avec un message d’erreur clair indiquant comment y remédier, plutôt que l’outil soit silencieusement indisponible.
Linux : le worker doit s’exécuter avec accès à une session graphique — DISPLAY doit être défini dans l’environnement du worker et pointer vers un serveur X en cours d’exécution. Sur une machine sans interface graphique, vous pouvez en démarrer un vous-même (par ex. Xvfb :0 avec un gestionnaire de fenêtres) et exporter DISPLAY avant de démarrer le worker. Sans affichage, les actions sur l’ordinateur renvoient une erreur indiquant qu’aucun bureau graphique n’est disponible et expliquant comment en fournir un.macOS : Devin réutilise la session de bureau existante de la machine. Deux autorisations macOS distinctes (TCC) s’appliquent au processus qui exécute le worker Devin :
Enregistrement de l’écran — requis pour les captures d’écran.
Accessibilité — requise pour les entrées synthétiques de la souris et du clavier.
Accordez ces deux autorisations au processus qui lance le worker dans Réglages Système > Confidentialité et sécurité, ou préautorisez-les à l’aide d’un profil PPPC MDM sur les parcs gérés, puis redémarrez le worker.Windows : Devin utilise la session de bureau interactive existante de la machine. Contrairement aux environnements Windows gérés par Devin — où le worker démarre et configure sa propre instance de Chrome — sur un Outpost Windows, le worker vous laisse gérer Chrome : installez Chrome comme décrit dans les dépendances de la machine pour utiliser les fonctionnalités du navigateur, et Devin interagit avec le bureau tel quel.
Une disponibilité partielle des capacités est prévue
Les capacités sont vérifiées indépendamment, ce qui permet à Devin de continuer à fonctionner de manière dégradée plutôt que de perdre l’ensemble de l’outil :
Si l’enregistrement d’écran est accordé, mais pas l’accessibilité (cas fréquent par défaut), les captures d’écran fonctionnent, tandis que les actions de clic, de saisie et de défilement renvoient une erreur indiquant précisément quelle autorisation accorder.
Si aucun écran n’est disponible, chaque action sur l’ordinateur indique la raison (par ex. DISPLAY non défini) et ce qu’il faut modifier.
L’enregistrement d’écran des sessions de test nécessite également ffmpeg sur la machine ; consultez les dépendances de la machine.
Si votre application nécessite une authentification, configurez les secrets à l’avance afin que Devin puisse se connecter sans vous solliciter pendant la session. Effectuez la configuration de l’environnement pour garantir que Devin puisse installer les dépendances et lancer votre application sans problème.
Pour les applications que vous testez fréquemment, créez un Skill qui indique à Devin exactement comment configurer et tester votre application. Cela vous fait gagner du temps lors de sessions répétées et garantit la cohérence des tests. Consultez Tests et enregistrements vidéo — suggestions de skills pour des exemples.
Le navigateur Chrome de Devin expose un endpoint Chrome DevTools Protocol (CDP) auquel Playwright peut se connecter. Devin peut écrire et exécuter des scripts Playwright pour automatiser des interactions dans le navigateur — comme des parcours de connexion ou la saisie systématique de données — sur sa propre instance de navigateur en cours d’exécution. Vous pouvez également écrire ces scripts vous-même et les versionner dans votre dépôt. Pour la plupart des autres actions dans le navigateur, il est recommandé d’utiliser Computer Use ou les outils de navigateur natifs de Devin.
L’instance Chrome de Devin écoute les connexions CDP sur le port 29229. Un script Playwright peut se connecter à ce navigateur, effectuer des actions (remplir des formulaires, cliquer sur des boutons, gérer les redirections), puis se déconnecter. Comme le script se connecte au navigateur existant au lieu d’en lancer un nouveau, tous les changements d’état — cookies, localStorage, jetons d’authentification — sont conservés après la fin du script.Cela signifie que Devin peut immédiatement utiliser la session authentifiée : actualiser les pages, naviguer et interagir normalement avec l’application.
Automatisez les parcours de connexion en plusieurs étapes (p. ex., Okta, Auth0, Google SSO) qu’il serait fastidieux d’effectuer manuellement à chaque session.
Authentification lors de la configuration de l’environnement
Incluez un script de connexion dans votre configuration de l’environnement afin que Devin démarre chaque session en étant déjà authentifié.
Automatisation basée sur les Skills
Stockez des scripts de connexion ou de saisie de données dans une Skill afin que Devin puisse les exécuter automatiquement lorsque nécessaire.
Saisie de données systématique
Créez des scripts pour des envois répétitifs de formulaires ou des saisies de données en masse, qui seraient lents et sources d’erreurs en pointant-cliquant.
Si Devin ne parvient pas à trouver un bouton ou un élément à l’écran, essayez d’être plus précis dans vos instructions — décrivez l’emplacement de l’élément, son libellé ou le contexte autour de lui. Par exemple, « cliquez sur le bouton Save bleu en bas à droite de la fenêtre modale » est mieux que « cliquez sur Save ».
L’application ne s’affiche pas sur le bureau de Devin
Par défaut, Devin s’exécute dans un environnement Linux. Si votre application ne fonctionne que sous Windows, exécutez vos sessions dans un environnement Windows afin que Devin puisse l’y tester. Les applications uniquement compatibles avec macOS nécessitent une machine Outpost macOS avec une session de bureau. Les applications web fonctionnent quel que soit le système, puisqu’elles s’exécutent dans Chrome. Pour les applications de bureau, assurez-vous qu’elles disposent d’un build pour la plateforme sur laquelle vos sessions s’exécutent.
Si Devin interagit mal avec votre interface, ajoutez une entrée Skill ou Knowledge avec des instructions de navigation précises pour votre application. Décrire les étapes exactes (« cliquez sur le menu hamburger en haut à gauche, puis cliquez sur Settings dans le menu déroulant ») réduit les ambiguïtés.
⌘I
Assistant
Responses are generated using AI and may contain mistakes.
