Codex Computer Use et le navigateur intégré en pratique : laisser l’agent voir les pages, manipuler les apps et itérer sur le frontend

Quand vous terminez une modification frontend et que la capture d’écran ne suffit toujours pas à montrer à l’agent le vrai rendu de la page, la boucle devient vite pénible. Et si l’agent pouvait ouvrir le navigateur lui-même, voir la page, commenter directement dessus, puis continuer ?

Sur macOS, l’agent peut piloter plusieurs apps en arrière-plan pendant que vous continuez à écrire du code. Sur Windows, il prend le curseur en main, donc vous devez mettre le reste en pause. Pour l’itération frontend, cela donne une boucle très simple : modifier le code, laisser l’agent ouvrir le navigateur, commenter sur la page, puis recommencer. C’est là que Computer Use et le navigateur intégré deviennent vraiment utiles. Les différences de plateforme définissent le workflow, et les limites de sécurité définissent les autorisations.

1. Bases de Computer Use : utiliser le curseur pour voir, cliquer et saisir dans les applications

1.1 Ce n’est pas une prise de contrôle totale, mais “vous donnez l’objectif, il pilote l’interface graphique”

Computer Use permet à Codex de voir, cliquer et saisir avec son propre curseur sur les applications de votre ordinateur, y compris des outils de bureau sans API publique. Vous décrivez l’objectif, par exemple “convertir ce PDF en Word”, et Codex déplace le focus, clique les fenêtres, saisit le texte et termine le flux GUI.

C’est différent d’un script en arrière-plan. Sur Windows, Codex prend le curseur en main au premier plan. Sur macOS, il travaille en parallèle en arrière-plan, donc vous pouvez continuer à travailler dans d’autres apps.

Il résout surtout deux types de tâches :

1. Piloter des outils sans API : logiciels de design, réglages système et apps de bureau, tant que la tâche peut être terminée dans une interface graphique.
2. Les tâches qui doivent voir la vraie interface : débogage GUI, reproduction de maquettes de design et tests d’interaction desktop.

1.2 macOS vs Windows : parallèle en arrière-plan vs prise en main au premier plan

La grande différence avec Computer Use est de savoir si vous pouvez travailler en parallèle.

Si vous êtes sur macOS, Computer Use fonctionne très bien comme “assistant parallèle” : vous laissez un agent piloter une app de design pendant que vous continuez à coder dans l’éditeur. Sur Windows, il vaut mieux prévoir un créneau de concentration : Codex prend le curseur, vous mettez le reste en pause et vous attendez qu’il termine.

2. Le navigateur intégré : modifier le frontend -> ouvrir la page -> commenter dessus -> continuer

2.1 La boucle d’itération frontend en 4 étapes

Le problème principal que résout le navigateur intégré est simple : l’agent modifie le code frontend, mais il ne voit pas le rendu réel. Sans navigateur, il faut se contenter de captures d’écran.

La boucle ressemble à ceci :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

1. Modifier le frontend : ajuster le style, la mise en page ou la logique d’interaction.
2. Ouvrir le navigateur : demander à Codex d’ouvrir localhost ou une app web locale.
3. Commenter sur la page : cliquer, annoter et commenter directement dans le navigateur pour donner des instructions précises à l’agent.
4. Continuer l’itération : l’agent utilise ce retour, ajuste à nouveau et vérifie le rendu suivant.

On passe ainsi de “modifier le code -> envoyer une capture -> recevoir un retour -> modifier le code” à “modifier le code -> voir la page -> commenter -> modifier le code”. L’agent voit le rendu directement, donc vous n’avez pas besoin d’envoyer des captures sans arrêt.

2.2 Pour l’instant, surtout utile pour le frontend et le jeu

Le positionnement actuel d’OpenAI est clair : le navigateur intégré sert surtout aux apps web localhost, au développement frontend et au développement de jeux.

L’ouverture vers un contrôle de navigateur plus complet progresse encore. Si vous voulez que Codex pilote des sites externes, par exemple pour un debug en production ou des tests sur un site tiers, c’est encore limité aujourd’hui et cela dépend des futurs déploiements.

2.3 Developer mode : donner à Codex un accès contrôlé à Chrome DevTools Protocol

Developer mode a été publié le 2026-06-11 dans la version 6.609 et donne à Codex un accès contrôlé à Chrome DevTools Protocol.

Il permet notamment :

• Analyse de performance : profiler JavaScript et mesurer les temps de rendu.
• Débogage réseau : inspecter requêtes, réponses et timings.
• Sortie Console : lire les erreurs d’exécution et console.log.
• Inspection de l’état de page : examiner le DOM et les styles appliqués.

Au-delà de ces capacités, CDP accélère aussi l’itération. Les snapshots DOM réduisent les rendus répétés et les transferts de captures. Sur certaines pages complexes, l’itération peut être jusqu’à 2x plus rapide, parce que l’agent n’a pas besoin de recharger toute la page à chaque fois et peut repartir du snapshot.

Le chemin d’activation est Settings > Browser > Enable full CDP access. Si votre organisation a désactivé Developer mode, vous ne pouvez pas l’activer localement. C’est une politique d’organisation, pas un réglage de compte personnel.

3. Appshots : double-cliquer sur Command sur macOS et envoyer l’app à Codex en un geste

3.1 Pas une simple capture, mais “capture + texte caché”

Appshots, publié le 2026-05-21, règle un point précis des captures d’écran : le contenu hors zone de défilement est difficile à voir.

Double-cliquez sur la touche Command, et Codex capture la fenêtre de l’app au premier plan avec le texte disponible, y compris le texte caché hors de la zone visible. Par exemple, si une pile d’erreur web se trouve sous la zone visible, une capture normale ne la montre pas, mais Appshots peut extraire tout le texte de la page.

3.2 Cas d’usage

Cas d’usage typiques d’Appshots :

• Déboguer une erreur web : envoyer à Codex toute la fenêtre du navigateur, y compris la pile d’erreur hors écran.
• Reproduire une maquette de design : envoyer la fenêtre d’un logiciel de design à l’agent pour qu’il analyse la mise en page.
• Extraire le texte non sélectionnable d’un PDF : lire directement le contenu de la fenêtre PDF.

C’est plus efficace qu’un simple screenshot, car l’agent voit à la fois le visuel et le texte.

3.3 Flux Appshots

1. Ouvrez la fenêtre de l’app cible et cliquez dedans pour lui donner le focus.
2. Double-cliquez sur la touche Command, puis relâchez.
3. Une icône Codex apparaît en bas à droite pendant environ 1,2 seconde, ce qui signifie que la capture a réussi.
4. La capture est automatiquement attachée au fil de conversation actif des 60 dernières secondes.

Attention : Appshots fonctionne uniquement sur macOS, et la langue système doit être l’anglais ou le chinois simplifié. Les environnements japonais et coréens ont des limites connues. Dans ces deux langues, le texte hors de la zone de défilement peut être incomplet, et certains textes non sélectionnables peuvent ne pas être capturés correctement. Si vous utilisez un système japonais ou coréen, testez d’abord la fonction en anglais ou en chinois simplifié.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

4. Limites de sécurité : quand ne pas donner l’accès complet

4.1 Sandbox par défaut + accès à la demande

Codex fonctionne par défaut en sandbox, l’agent étant limité au dossier de travail et à la branche. Les actions à plus haute privilège nécessitent votre validation. Computer Use et le navigateur intégré sont des capacités à privilèges plus élevés, donc il faut les autoriser avec prudence.

Les utilisateurs Windows disposent d’un contrôle supplémentaire : Settings > Computer Use > Configure per-app access control permet de limiter Codex à des applications précises.

4.2 Quand ne pas donner l’accès complet

Il faut être très strict avec les permissions de Computer Use. Ne l’autorisez pas dans ces cas :

• Codebases tierces non fiables, où l’agent pourrait accéder à des fichiers sensibles.
• Bases de données de production, où l’agent pourrait faire une mauvaise modification.
• Réglages système à privilèges élevés, où le contrôle par app sous Windows est important.

La règle de base est simple :

• Restez en sandbox par défaut, et n’autorisez que lorsque la tâche l’exige clairement.
• Sous Windows, utilisez per-app access control pour réduire le périmètre.

5. Arbitrage : quand utiliser Computer Use et quand le codage classique reste moins cher

5.1 Matrice de scénarios

Computer Use n’est pas un outil universel. Décidez selon le type de tâche.

La règle centrale est simple : si le codage classique suffit, n’activez pas Computer Use. Sa valeur se trouve dans le pilotage des outils sans API et dans les situations où il faut voir l’interface réelle.

5.2 Coût : Computer Use et le navigateur sont plus chers

Computer Use et le navigateur intégré coûtent plus cher que le codage classique :

• Computer Use consomme plus de tokens à cause des captures et des interactions.
• L’itération dans le navigateur déclenche un appel à chaque tour.

Utilisez le codage classique pour les tâches simples, et gardez Computer Use pour les travaux GUI complexes.

6. FAQ : questions courantes

Q1 : Qu’est-ce que Computer Use, et jusqu’où va-t-il ?

Computer Use permet à Codex de voir, cliquer et taper avec son propre curseur pour piloter toutes les applications sur votre ordinateur, y compris les outils de bureau sans API publique. Ce n’est pas une prise de contrôle totale. Vous donnez l’objectif, et Codex pilote l’interface graphique au premier plan sur Windows ou en arrière-plan sur macOS.

Q2 : Quelle est la différence entre macOS et Windows ?

macOS prend en charge le travail parallèle en arrière-plan, donc plusieurs agents peuvent piloter différentes apps sans gêner le reste de votre travail. Windows fonctionne actuellement seulement au premier plan, l’agent prend le curseur, et vous devez donc mettre les autres tâches en pause. Les deux peuvent piloter toutes les apps ; le choix dépend du workflow.

Q3 : Comment utiliser le navigateur intégré pour itérer sur le frontend ?

Modifiez le frontend, ouvrez la page localhost dans le navigateur intégré, commentez directement sur la page, laissez l’agent poursuivre les changements, puis rouvrez le navigateur pour vérifier le résultat. Cela crée une boucle modifier-voir-commenter-modifier. Il sert surtout aux itérations frontend et jeu pour l’instant.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Q4 : Est-ce sûr, et faut-il donner l’accès complet ?

Par défaut, Codex est en sandbox et l’agent est limité au dossier de travail et à la branche. Les privilèges plus élevés nécessitent une validation. Computer Use et le navigateur sont des capacités à privilèges plus élevés, donc accordez-les seulement si nécessaire. Sous Windows, vous pouvez aussi restreindre l’accès par application, et les contextes non fiables ne doivent jamais recevoir un accès complet.

Q5 : Quand Computer Use vaut-il le coup ?

Il vaut le coup pour les outils desktop sans API, comme les logiciels de design ou les réglages système, et pour les tâches où l’agent doit voir la vraie interface, comme le débogage GUI ou la reproduction de maquettes. La génération de code simple reste moins chère avec le codage classique.

Q6 : Que peut faire le navigateur Developer mode ?

Il donne à Codex un accès contrôlé à Chrome DevTools Protocol pour l’analyse des performances, le débogage réseau, la sortie Console et l’inspection du DOM et des styles. Cette fonction a été ajoutée le 2026-06-11. Dans certains cas, le DOM snapshotting peut améliorer l’itération jusqu’à 2x.

7. Étapes suivantes et ressources utiles

Articles liés

• En amont : sandbox de sécurité Codex et limites de permission : quand ne pas donner l’accès complet (à publier)
• En aval : workflow Codex Cloud Agent : pilotage et supervision d’appareils distants (à publier)
• En aval : coût de Codex en pratique : contrôler le budget de Computer Use, du navigateur et des tâches longues (à publier)

Ressources officielles

• Documentation officielle de Codex
• Changelog Codex
• Codex for (almost) everything, la grande mise à jour du 2026-04-16

Conclusion

Computer Use et le navigateur intégré résolvent le même problème central : l’IA doit voir l’interface réelle pour terminer la tâche. Le travail frontend a besoin du rendu réel, et les outils sans API ont besoin d’une GUI.

La différence de plateforme définit le workflow. Sur macOS, vous pouvez laisser l’agent piloter une app en arrière-plan pendant que vous continuez à coder. Sur Windows, il faut prévoir un bloc de concentration et laisser l’agent prendre le curseur.

La sécurité demande aussi de la retenue. Restez en sandbox par défaut, n’accordez l’accès que lorsque la tâche l’exige, et utilisez per-app access control sur Windows pour réduire le périmètre.

L’arbitrage de coût est également clair : le codage classique est moins cher pour les tâches simples, tandis que Computer Use prend tout son sens pour les travaux GUI complexes.

Étapes recommandées ensuite :

• Si vous utilisez macOS, essayez de faire tourner une app de design en arrière-plan pendant que vous continuez à coder.
• Si vous devez itérer sur le frontend, construisez la boucle modifier-voir-commenter-modifier avec le navigateur intégré.
• Si vous avez encore des doutes sur les limites de sécurité, lisez d’abord la sandbox de sécurité Codex et les limites de permission avant d’accorder l’accès complet.