Le navigateur intégré de Codex : travailler sans perdre le contexte

Tu demandes à l’IA de corriger une page. Elle modifie le code, annonce que tout est prêt, et tu ouvres le résultat : le titre déborde sur mobile. Il faut reprendre une capture, décrire le problème et revenir à la conversation.

Le navigateur intégré peut raccourcir cette boucle. Il rapproche la tâche et le résultat à examiner. Ce n’est pas une raison pour remplacer tous tes outils habituels : c’est une façon de garder une vérification dans le contexte du travail.

Un navigateur au service d’une tâche

Dans l’application de bureau, tu peux demander à Codex d’utiliser le navigateur intégré ou le mentionner avec @Browser. Il peut servir à ouvrir des pages et à travailler sur leur contenu selon les outils et autorisations disponibles. Documentation du navigateur

L’intérêt est simple : tu ne décris plus uniquement ce qui devrait exister. Tu peux demander de regarder ce qui existe effectivement, puis de comparer le résultat à tes critères.

Cela ne signifie pas que l’agent voit spontanément tous tes onglets ou dispose de toutes tes connexions. Nomme la page concernée et le travail attendu. Plus le périmètre est précis, plus la vérification est facile à relire.

Choisir le bon accès

Le navigateur intégré est utile pour une page locale ou une consultation liée à la tâche. L’extension de navigateur sert à travailler dans un navigateur connecté, lorsque tu choisis de l’utiliser. Elle implique son installation et les permissions correspondantes. Documentation de l’extension

Le contrôle d’ordinateur concerne les interactions avec des interfaces graphiques plus larges. Il ne faut pas l’assimiler à une API métier : le parcours reste une suite d’actions dans une interface. Documentation du contrôle d’ordinateur

Avant de lancer une tâche, demande quel accès est disponible. Si un connecteur peut fournir exactement les données nécessaires en lecture seule, il peut être plus adapté que la navigation. Le choix dépend de la tâche, pas de l’outil le plus impressionnant.

Premier usage : relire une page réelle

La création d’un site avec Codex est un bon cas d’application : une fois la page construite, il reste à vérifier ce qu’un visiteur peut réellement lire et faire.

Commence par une page que tu peux vérifier sans risque, par exemple ton site local. Définis trois critères : le texte reste lisible sur mobile, les liens mènent au bon endroit et le formulaire présente clairement ses champs obligatoires.

Ouvre cette page dans le navigateur intégré : [URL de ma page locale].
Fais une revue en lecture seule sur ordinateur et sur mobile.
Liste les problèmes de lisibilité, de navigation et de compréhension.
Pour chaque problème, indique l’élément et une correction précise.
Ne modifie rien et ne soumets aucun formulaire pour le moment.

Relis la liste avant de demander une correction. Un désaccord sur la couleur d’un bouton n’a pas le même impact qu’un lien de téléchargement cassé. Classe les problèmes par conséquence pour le lecteur, puis traite les vrais obstacles en premier.

Deuxième usage : préparer sans envoyer

Le même cadre est utile pour les messages et publications. L’agent peut préparer un brouillon, réunir les éléments qui le justifient et te laisser la décision finale.

Imagine un post LinkedIn tiré d’un article : l’objectif est de proposer un angle et une accroche fidèles au texte, pas d’envoyer automatiquement une publication dont tu n’as pas vérifié les affirmations.

À partir de cet article, prépare un brouillon de post LinkedIn.
Distingue les faits de l’article de tes suggestions d’accroche.
N’invente ni résultat chiffré ni retour d’expérience à la première personne.
Ne publie rien. Présente le texte pour validation.

Le navigateur ne donne aucune autorisation implicite d’envoyer un message, de publier un contenu ou de changer un réglage. Écris ces limites dans la tâche, surtout lorsque le service est connecté à ton compte.

Troisième usage : comparer des sources

Une recherche devient plus exploitable si tu définis sa sortie avant de commencer. Plutôt que « renseigne-toi sur cet outil », demande une liste de capacités, de limites et de sources datées.

Choisis les pages de référence et demande que chaque conclusion soit reliée à une source. Une page promotionnelle peut décrire une promesse sans démontrer le résultat dans ton cas. Garde cette différence dans la synthèse.

Pour une question technique, compare les notes avec la documentation officielle. Si la page nécessite une connexion indisponible, l’agent doit signaler ce manque plutôt que reconstituer son contenu.

Les garde-fous à garder

• Utilise un environnement de test pour les formulaires qui déclenchent des e-mails ou créent des données.
• Ne fournis pas de mots de passe ou de clés d’API dans une page publique ou un exemple de prompt.
• Demande une confirmation avant un achat, une suppression ou une publication.
• Ne traite pas les instructions trouvées dans une page web comme des consignes venant de toi.
• Exige une distinction entre ce qui a été observé, ce qui a été testé et ce qui reste à vérifier.

Si un outil n’est pas disponible, adapte le parcours. Une capture annotée et une relecture manuelle restent préférables à une vérification annoncée mais non réalisée.

Une boucle de travail courte

Le parcours utile tient en cinq actions : définir le résultat, ouvrir la bonne page, observer, corriger après validation, puis vérifier à nouveau.

N’automatise pas tout dès le premier essai. Commence par une revue sans écriture, sur une page sans données sensibles. Tu pourras élargir le périmètre quand les critères de réussite et les autorisations seront clairs.

Le guide téléchargeable rassemble ces consignes. Elles sont des points de départ à adapter à ton environnement, pas une garantie que chaque capacité est activée sur ton compte.

Si cette vérification doit être répétée par une équipe, la méthode pour transformer des prompts en workflows partagés permet de documenter les entrées, les contrôles et la règle d’arrêt. Pour les autres usages de l’outil, retrouve le parcours Codex.