OpenAI vient de brancher Codex sur le protocole Chrome DevTools (l’interface bas niveau qui pilote le navigateur Chrome). La couverture médiatique y voit une fonction de navigation de plus. Mais ce n’est pas une fonction de navigation : c’est un agent à qui l’on donne des mains sur le web.
Ce que le commentaire ambiant a déjà rangé dans la case « gadget »
La lecture immédiate tient en une ligne : Codex sait maintenant ouvrir une page et cliquer. On l’a déjà entendue pour chaque assistant qui s’est mis à « surfer ». L’histoire semble écrite d’avance : encore une démo, encore un agent qui remplit un formulaire à votre place.
Cette lecture passe à côté de l’essentiel. La nouveauté n’est pas que Codex visite des sites. C’est par où il les visite. Le protocole Chrome DevTools n’est pas une fenêtre que l’on regarde : c’est le poste de pilotage que les développeurs utilisent pour inspecter le DOM (la structure interne de la page), lire le réseau, exécuter du JavaScript, modifier une page en direct. Donner cet accès à un agent, ce n’est pas lui offrir des yeux. C’est lui donner des mains.
Inspecter et modifier : la différence qui change tout
Un agent qui « lit » une page reste un lecteur passif : il interprète des pixels ou du texte, puis tente de deviner où cliquer. Un agent connecté au protocole DevTools, lui, parle au navigateur dans sa propre langue. Il ne devine plus la structure d’un site : il la lit. Il ne simule plus un clic à l’aveugle : il cible l’élément exact. C’est ce qui le sépare des agents qui ont dominé jusqu’ici : du Computer Use de Claude à l’Operator d’OpenAI, ils pilotent le navigateur en interprétant des captures d’écran, là où le protocole DevTools s’adresse directement au moteur de la page.
La conséquence est concrète pour quiconque orchestre l’IA au quotidien :
- déboguer un site en décrivant le symptôme, et laisser l’agent ouvrir la console, lire l’erreur réseau et proposer le correctif ;
- extraire des données d’une interface qui n’expose aucune API (interface de programmation), en s’appuyant sur le DOM réel plutôt que sur un scraping fragile ;
- tester un parcours utilisateur de bout en bout, en pilotant le navigateur comme le ferait un humain, mais sans intervention manuelle ;
- modifier l’affichage d’une page à la volée pour vérifier une hypothèse avant même de toucher au code source.
OpenAI le présente comme une implémentation encore très précoce. C’est honnête, et c’est aussi le point clé. On ne juge pas une fondation à sa finition : on la juge à ce qu’elle rend possible ensuite.
Pourquoi le navigateur devient le vrai terrain de jeu des agents
Les agents savent déjà manier un terminal, lire des fichiers, appeler des API. Le web restait leur angle mort : un territoire pensé pour des humains, plein de boutons, de pop-ups et de pages qui n’exposent rien de structuré. Le protocole DevTools rebat cette carte. Il transforme le navigateur, l’application la plus universelle qui soit, en runtime (environnement d’exécution) d’agent.
Et il y a une raison de fond pour que cela compte. La majorité des logiciels que nous utilisons n’a pas d’API publique : un intranet d’entreprise, un back-office, un outil métier interne, un site administratif. Pour un agent, ces zones étaient inatteignables autrement qu’en bricolant. Avec un accès navigateur natif, elles redeviennent pilotables. Le web cesse d’être une vitrine que l’IA contemple pour devenir une surface qu’elle manipule.
C’est là que la trajectoire se dessine. Aujourd’hui, c’est une option pour Codex. Demain, capter, lire et agir sur une page sera une brique par défaut de tout agent sérieux, au même titre que lire un fichier l’est devenu. La bascule n’est pas dans l’annonce : elle est dans le fait que cette capacité va se généraliser, silencieusement, jusqu’à paraître évidente.
La puissance a un revers, et il faut le nommer
Un agent capable de modifier n’importe quel site est aussi un agent capable de se tromper sur n’importe quel site. Le protocole DevTools ne fait pas de distinction morale : il exécute. Remplir un formulaire bancaire, valider un paiement, supprimer une ressource en production : ce sont les mêmes gestes techniques qu’inspecter une page anodine.
Se posent alors des questions que la démonstration enthousiaste laisse de côté. Qui valide l’action avant qu’elle ne parte ? Comment trace-t-on ce qu’un agent a réellement modifié dans une session ? Quelles barrières empêchent un site malveillant de détourner les commandes envoyées au navigateur ? Donner des mains à une IA suppose d’inventer, en parallèle, les garde-fous qui encadrent ce qu’elle a le droit de toucher.
Ces risques ne sont pourtant pas un argument pour rejeter la fonction. Ils sont la preuve qu’elle est sérieuse. On ne réfléchit aux freins que pour ce qui avance vraiment.
Un cap, pas une fonctionnalité
Réduire cette annonce à « Codex sait naviguer » revient à confondre l’outil et le geste. Le geste, ici, c’est l’autonomie d’action sur le web, standardisée par un protocole que des millions de développeurs connaissent déjà. C’est précisément ce qui le rend solide : OpenAI ne réinvente pas le pilotage du navigateur, l’éditeur s’appuie sur la plomberie existante de Chrome.
Pour qui orchestre des agents, la leçon est pratique : il ne s’agit plus de se demander si une IA peut accéder à un service, mais de décider ce qu’on l’autorise à y faire. La question n’est pas de savoir si les agents auront un navigateur par défaut, mais comment nous encadrerons les mains qu’on vient de leur donner.
