L'onglet de Schrödinger de Claude in Chrome : il ne travaille que si vous le regardez

Pourquoi les agents IA qui travaillent dans les onglets en arrière-plan de Chrome ralentissent, s'endorment, et peuvent même faire couper une discussion avec le service client.

J'ai l'habitude de mener plusieurs choses de front. Un après-midi de la mi-juillet, j'ai confié trois tâches en même temps à Claude in Chrome. Dans le premier onglet, il vérifiait la détection des fenêtres contextuelles de notre navigateur ; dans le deuxième, il cherchait une musique de fond qui colle à une vidéo ; dans le troisième, il rédigeait une réclamation pour le service client d'Origin Energy, parce qu'ils s'étaient trompés sur une de mes factures d'électricité. Une fois les trois lancées, j'ai laissé le navigateur en arrière-plan et je suis retourné dans le terminal, où j'utilise Claude Code pour faire tourner mon équipe de développement IA. C'est tout l'intérêt des agents pour moi : plusieurs d'entre eux travaillent seuls, et je n'ai pas à surveiller chacun.

Quand je suis revenu au navigateur un peu plus tard, une seule des trois tâches avait avancé. Les deux autres avaient l'air de s'être assoupies, et elles le sont restées alors que j'ai attendu encore un peu et cliqué plusieurs fois d'un onglet à l'autre.

La plupart des gens penseraient d'abord à un réseau lent, ou à un modèle lent ce jour-là. Mais si le réseau ou le modèle étaient en cause, les trois tâches auraient ralenti ensemble, et là, une seule bougeait. Je travaille sur les navigateurs depuis de longues années, et une autre explication m'est venue tout de suite : Chrome bridait les onglets en arrière-plan.

Ce n'est pas vraiment un défaut de Chrome. Un navigateur est censé faire ça. Une page que vous ne regardez pas n'a aucune raison de tourner à pleine vitesse, et les gens gardent des dizaines d'onglets ouverts ; si chacun tournait à fond, qu'il soit devant ou pas, la batterie d'un portable serait vide en une demi-journée. Le problème, c'est que les pages d'un navigateur ne sont plus seulement là pour être regardées par des personnes. Des agents IA y travaillent aussi. Pour une personne, un onglet en arrière-plan, c'est quelque chose dont elle n'a pas besoin pour l'instant. Pour un agent, ce même onglet attend peut-être un téléchargement, fait passer un remboursement ou tient une discussion avec le service client qui ne doit pas être coupée. Un onglet que personne ne regarde peut très bien avoir du travail à faire.

Les règles des navigateurs ont été écrites pour des personnes, et elles conviennent mal aux agents.

Le 16 juillet, j'ai testé à la main et confirmé que le problème venait bien de là. C'est aussi ce jour-là que nous avons décidé d'ajouter à Embiody, le navigateur que nous construisons pour les agents IA, une fonctionnalité appelée « onglets IA ». Récemment, j'ai refait ces tests proprement, pour répondre à trois questions : jusqu'où Chrome ralentit un onglet en arrière-plan ; quand Chrome gèle complètement une page ; et la plus vicieuse, est-ce qu'un agent peut lire quelque chose de faux sur une page pourtant toujours ouverte. Les résultats ont été pires que ce que j'imaginais.

1. Huit minutes passent, la page croit qu'il s'en est écoulé une et demie#

J'ai commencé par la page de compte à rebours la plus ordinaire, qui avance d'un cran par seconde, écrite de la même façon que les comptes à rebours des pages de commande et de paiement. À chaque cran, la page signale où elle en est à un petit serveur sur la même machine ; ainsi, même si le navigateur gèle la page, le serveur garde une trace de ce qui s'est réellement passé.

J'ai ouvert deux exemplaires de cette page, l'un ouvert par Claude in Chrome et l'autre ouvert par moi pour comparer, puis je les ai gardés hors de vue tous les deux pendant 8 minutes. J'ai essayé trois façons de les cacher : passer à un autre onglet, recouvrir entièrement la fenêtre par une autre, et réduire la fenêtre. Les trois ont donné presque exactement le même résultat.

Pendant la première minute après que la page a disparu de la vue, rien n'a changé, et le compte à rebours avançait toujours d'un cran par seconde. Au bout d'environ une minute, il est tombé à un cran par minute. Au bout de 8 minutes, 480 secondes s'étaient écoulées dans le monde réel, mais la page croyait qu'il ne s'en était écoulé qu'environ 90 ; elle avait donc 390 secondes de retard. C'est comme sortir prendre un petit-déjeuner de 8 minutes et retrouver en rentrant une horloge qui n'a avancé que d'une minute et demie. Et quand j'ai ramené la fenêtre devant moi, le compte à rebours est bien reparti à un cran par seconde, mais les minutes perdues n'ont jamais été rattrapées.

Plus important encore, la page ouverte par Claude in Chrome s'est comportée exactement comme celle que j'avais ouverte à la main : 387 à 391 secondes de retard pour celle de Claude, 392 pour la mienne. Ça n'a donc rien à voir avec Claude. N'importe quelle page ouverte dans Chrome que personne ne regarde finit comme ça, ce qui veut dire que quiconque fait tourner un agent dans Chrome va tomber dessus.

(Windows 11, Chrome 157.0.8103.39, extension Claude 1.0.106, 11 novembre 2026, une seule machine, 1 à 2 essais par cas.)

D'où une question évidente. Les onglets de Claude in Chrome restent presque tout le temps en arrière-plan. Si un onglet en arrière-plan n'avance qu'une fois par minute, comment arrive-t-il à faire quoi que ce soit ? Pourtant, il finit bel et bien son travail.

2. Seul l'onglet que l'agent touche reste éveillé#

Pour le savoir, j'ai construit une page de test plus proche d'une vraie tâche, avec les deux types d'attente qu'on voit le plus souvent sur les sites. Le premier est un téléchargement : la page affiche « Votre téléchargement commencera dans 90 secondes », et le bouton de téléchargement ne devient cliquable que lorsque le compte à rebours atteint 0. Le second est un export : la page affiche « Export en cours », demande au serveur toutes les 2 secondes si c'est prêt, et le serveur répond oui au bout de 90 secondes.

Ensuite, j'ai demandé à Claude in Chrome de faire deux de ces tâches à la fois, une dans l'onglet A et une dans l'onglet B. Il s'est d'abord occupé de A, et B est resté en arrière-plan sans que personne n'y touche. Voici ce qui s'est passé :

Voici B lors du second essai, au moment où j'ai ramené la fenêtre devant moi. Regardez combien de temps la page dit avoir attendu :

La page avait attendu 378 secondes de temps réel et il lui restait encore 6 secondes. Une attente de 90 secondes était devenue six ou sept minutes, et c'est exactement ce qui m'était arrivé cet après-midi de juillet. L'agent travaillait sans arrêt, mais toujours dans A, pendant que B se traînait en arrière-plan à un cran par minute. Quand il a enfin regardé B, un compte à rebours qui aurait dû être fini depuis longtemps tournait encore. Et c'était le cas favorable. Si l'agent n'était jamais revenu sur B, à un cran par minute, ce compte à rebours de 90 secondes aurait pris à peu près une demi-heure.

Le plus étrange, c'est que l'export n'a presque pas été touché. Le serveur a dit que c'était prêt à 90 secondes, et l'agent s'en est aperçu seulement 3 secondes plus tard.

Les deux étaient des attentes dans un onglet en arrière-plan, alors pourquoi Chrome a-t-il ralenti le compte à rebours du téléchargement et laissé l'export tranquille ?

La différence tient à la façon dont les deux attentes sont écrites. Le compte à rebours règle son propre réveil : quand le réveil de cette seconde sonne, il règle le suivant, et quand celui-là sonne, il règle celui d'après, chaque réveil accroché au précédent. L'export, lui, attend qu'on le rappelle : il pose la question au serveur, et ce n'est qu'une fois la réponse reçue qu'il programme la question suivante, si bien que chaque tour repart de zéro à partir de la réponse de quelqu'un d'autre. Chrome a une règle qui vise précisément les réveils accrochés les uns aux autres. Une fois qu'une page est hors de vue depuis un moment, ces réveils n'ont le droit de sonner qu'une fois par minute. Voilà pourquoi le compte à rebours a ralenti, alors que l'export, qui attend qu'on le rappelle, n'est pas concerné par la règle.

Le bridage en arrière-plan ne ralentit donc pas toute une page de façon uniforme. C'est la manière dont la page est écrite qui décide si elle ralentit. Mais ce n'est pas le pire.

3. Au bout de 20 secondes, la page s'arrête net#

Le ralentissement ci-dessus finit au moins par arriver au bout. Le suivant m'a vraiment fait sursauter. Par défaut, Claude in Chrome ouvre les nouveaux onglets en arrière-plan, derrière l'onglet que vous regardez. Je lui ai fait ouvrir un onglet de test, puis je l'ai laissé tranquille, et au bout de seulement 20 secondes la page s'est arrêtée complètement. Le compte à rebours n'avançait plus d'un cran par minute, il n'avançait plus du tout, jusqu'à ce que l'agent revienne faire quelque chose dedans. Je l'ai vu quatre fois, toujours vers 20 secondes, et pendant tout ce temps la fenêtre du navigateur était là, à l'écran, ni recouverte ni réduite.

La fenêtre est bien en vue, alors pourquoi une page à l'intérieur se figerait-elle d'un coup ?

Pour comparer, j'ai ouvert la même page dans un onglet en arrière-plan de la manière habituelle. Au bout de 3 minutes, elle tournait toujours, simplement tombée à un cran par minute ; les 20 secondes avaient donc forcément un rapport avec Claude in Chrome. J'ai observé la barre d'onglets un moment et j'ai fini par le voir : environ 20 secondes après la dernière commande de l'agent, le groupe d'onglets de Claude se réduisait tout seul, et dès qu'un groupe d'onglets est réduit, Chrome gèle les onglets qu'il contient et qui n'ont jamais été affichés. Gardez un œil sur la barre d'onglets dans ce clip :

Prise à part, chacune de ces deux choses se tient. Claude in Chrome ne veut pas que sa pile d'onglets envahisse votre barre d'onglets, alors il range le groupe quand il n'a rien à faire. Chrome traite un groupe réduit comme des affaires rangées dans un tiroir dont vous n'aurez pas besoin avant un moment, alors il coupe le courant pour économiser la mémoire. Mettez ces deux règles raisonnables ensemble, pourtant, et chaque onglet que l'agent a ouvert en arrière-plan s'endort dès que l'agent fait une pause.

L'onglet dans lequel l'agent travaille vraiment, lui, est forcément à l'abri ? J'ai fait surveiller deux onglets à l'agent, A et B, en lui faisant lire A toutes les 30 secondes pendant les 3 premières minutes. A a tourné normalement tout du long, tandis que B, auquel personne ne touchait, était pratiquement arrêté à partir de la deuxième minute. Puis je lui ai fait lire B à la place. B s'est réveillé aussitôt, mais environ 30 secondes plus tard, A, qu'on venait de laisser seul, était gelé à son tour.

Quand un agent touche un onglet, cet onglet ne reste donc éveillé que vingt ou trente secondes. Dès que l'agent passe à autre chose, ou s'arrête simplement pour réfléchir un peu plus longtemps, le groupe se réduit et l'onglet s'endort avec lui. Pour une personne, c'est juste le navigateur qui économise un peu de mémoire. Pour un agent, c'est bien plus grave, parce qu'il n'a aucune idée que la page qu'il vient de quitter a cessé de fonctionner.

4. Le service client n'a jamais reçu le YES#

Un compte à rebours gelé, ça veut juste dire que quelque chose finit en retard. Une discussion avec le service client gelée, ça veut dire que la tâche échoue. Le chat en direct avec un service client, la banque en ligne, les pages d'examen et les files d'attente de billetterie attendent tous que vous restiez présent, et toutes les quelques secondes ils disent discrètement au serveur « toujours là ». Mettez-vous un instant du côté du service client. Si en face personne n'a donné signe de vie depuis 45 secondes, qu'est-ce que vous en concluez ? Que la personne est partie, et vous fermez la session. Ma réclamation à Origin Energy en juillet passait justement par ce genre de chat.

J'ai construit une page de service client de ce type. Elle se signale au serveur toutes les 10 secondes, et le serveur met fin à la discussion s'il n'entend rien pendant 45 secondes. Une minute après le début de la discussion, le service client envoie : « Reply YES and I will refund it today. » (Répondez YES et je vous rembourse aujourd'hui.)

Là encore, j'ai fait surveiller deux onglets à Claude. Il a d'abord terminé une autre tâche dans A, ce qui a pris une minute et demie. Puis, comme il le fait quand il part exécuter des commandes dans le terminal, il a laissé le navigateur tranquille pendant une minute et demie. Enfin, il est retourné sur la page du service client dans B pour répondre YES. La fenêtre est restée à l'écran tout du long, mon propre onglet était devant, et le groupe d'onglets de Claude derrière. C'est comme ça qu'il fonctionne d'habitude, rien d'inhabituel.

Vingt secondes après que l'agent s'est arrêté, le groupe d'onglets de Claude s'est réduit, la page du service client dans B a été gelée, et les signalements se sont arrêtés. Quand l'agent est revenu sur B environ une minute plus tard, il est tombé sur ceci :

Chat ended: no check-in from this page for 83 s. Please sign in again to start a new chat.

(Discussion terminée : aucun signalement de cette page depuis 83 s. Veuillez vous reconnecter pour démarrer une nouvelle discussion.)

Notez que le serveur regarde depuis combien de temps la page est silencieuse, pas depuis combien de temps la discussion est ouverte. Tant que la page continue de se signaler, elle peut rester là aussi longtemps que vous voulez. B a été coupé parce qu'une fois gelé, il n'a rien dit pendant 83 secondes.

Le champ de saisie et le bouton d'envoi étaient déjà grisés. Le YES ne pouvait plus partir, le service client avait raccroché, et le remboursement est tombé à l'eau. L'agent ne peut pas non plus se reconnecter à votre place, donc tout attend que vous reveniez faire la queue depuis le début. J'ai lancé la même tâche dans Embiody, avec l'agent absent pendant la même minute et demie. Là, la page du service client a continué à se signaler toutes les 10 secondes et a affiché Connected (connecté) tout du long, le YES est passé, et le service client a répondu « Done, the refund is on its way. » (C'est fait, le remboursement est en route.) Voici les deux côte à côte, Chrome à gauche, Embiody à droite :

Vous pourriez objecter que j'ai dit plus haut qu'attendre la réponse du serveur protège du ralentissement, que le signalement au service client fonctionne exactement comme ça, alors comment a-t-il pu être coupé ? Justement : avec le bridage seul, la page du service client se serait encore signalée toutes les 10 secondes. Ce qui l'a cassée, c'est le gel. Le bridage fait seulement sonner une fois par minute les réveils qu'une page règle elle-même. Le gel coupe le courant à toute la page. Tout s'arrête à l'intérieur, les réveils réglés par la page comme les attentes de rappel, donc évidemment les signalements s'arrêtent aussi.

Alors pourquoi ne pas simplement faire en sorte que l'extension arrête de réduire le groupe ? En fait, elle ne le réduit que dans un seul cas : quand l'onglet affiché au premier plan de la fenêtre est l'un des vôtres. J'ai essayé de déplacer le groupe d'onglets de Claude dans une fenêtre à part, pour que l'onglet au premier plan soit un des siens. L'extension n'a alors pas réduit le groupe, la page du service client a seulement été bridée, et elle est restée connectée 11 minutes d'affilée. Mais qui ouvre une fenêtre séparée juste pour ça ? Son groupe d'onglets vit dans la fenêtre que vous utilisez.

Vu du côté de Claude in Chrome, c'est une impasse. Il partage un navigateur et une fenêtre avec vous. S'il ne réduit pas le groupe, ses onglets restent étalés sur votre barre d'onglets et vous gênent. S'il le réduit, Chrome les gèle selon ses propres règles. Réduire le groupe est une décision produit de l'extension, le gel est une règle de Chrome, et l'extension ne peut changer que la première. Même si elle ne réduisait jamais le groupe, ses onglets resteraient derrière les vôtres, toujours hors de vue, toujours bridés.

Tant que les agents seront des locataires dans un navigateur conçu pour des personnes, il n'y aura pas d'issue. Et les agents ne peuvent pas se passer du navigateur, parce que le web a été construit pour des personnes, et que des personnes et des agents qui travaillent côte à côte, dans le même navigateur et sur les mêmes sites, c'est clairement la direction que prennent les choses.

(12 novembre 2026, Chrome 157.0.8103.51, extension 1.0.106, un essai pour chaque.)

5. La page croit qu'on la regarde, mais rien n'est dessiné#

Si c'était tout, ce serait déjà un gros problème. Mais j'en ai trouvé un plus sournois. Cette fois, la page n'était pas gelée, les minuteurs étaient exacts, et la page se considérait même comme visible, pourtant son image bougeait à peine.

J'ai fait une page avec deux barres de progression. La verte avance avec le temps, d'un cran par seconde. La rouge avance avec les images que le navigateur dessine réellement, un peu à chaque image. J'ai fait travailler Claude sur cette page dans un onglet en arrière-plan pendant deux minutes : un clic pour lancer de la musique, puis faire défiler une liste et lire la page toutes les 10 secondes. À la fin, j'ai ramené l'onglet au premier plan.

Au moment où il est arrivé devant, la barre verte était pleine et la rouge avait à peine démarré. Le minuteur indiquait que 184 secondes s'étaient écoulées, mais seulement 620 images environ avaient été dessinées, alors qu'à 60 images par seconde, le rythme normal, il aurait dû y en avoir autour de 11 000. Pendant les 100 premières secondes, la page n'en a dessiné que 387, moins de 4 par seconde en moyenne, ce qui pour une personne ressemble à un diaporama. La page croyait qu'on la regardait, mais le moteur de rendu ne la dessinait pas vraiment.

L'image est donc dessinée lentement. Est-ce que c'est grave ? Beaucoup de sites aiment afficher des chiffres avec une animation. Pensez aux « 98 765 entreprises clientes » sur la page d'accueil d'une société, qui comptent à partir de 0 quand la page s'ouvre et se posent sur le chiffre final deux ou trois secondes plus tard. Si un agent ouvre une page comme ça en arrière-plan, là où rien n'est dessiné, le chiffre peut rester bloqué en route.

J'ai construit une page qui compte de 0 à 98 765 en 3 secondes, j'ai demandé à Claude de l'ouvrir dans un nouvel onglet en arrière-plan, de faire autre chose, puis de revenir 10 secondes plus tard lire le chiffre. Les résultats :

Ce clip montre ce que faisaient les deux onglets en arrière-plan pendant que l'agent était occupé ailleurs :

Chrome a donné trois chiffres différents en trois essais parce que la page est restée cachée en arrière-plan sans dessiner une seule image, si bien que le chiffre restait à 0. Au moment où l'agent est venu le lire, l'extension a rendu la page « visible », le chiffre n'a commencé à monter qu'à ce moment-là, et l'agent n'a pas attendu qu'il finisse ; il a donc lu là où le compteur en était arrivé. C'est comme photographier quelqu'un en pleine course : quel que soit le moment où vous déclenchez, vous l'attrapez au milieu de la piste.

Le pire, c'est que l'agent ne vous dira pas que le chiffre est peut-être faux. Il n'y a aucune erreur, et il n'a aucun moyen de savoir qu'il a vu une animation qui n'était pas terminée. De là où il est, la page s'est ouverte, le chiffre a été lu, tout va bien. S'il ne lit qu'une fois, il vous rend le mauvais chiffre comme un fait. Et ce n'est que ma propre page de test. Imaginez un agent dans un onglet en arrière-plan qui essaie de vous décrocher des places de concert ou un article en vente flash.

(12 novembre 2026, Chrome 157.0.8103.51, extension 1.0.106.)

6. L'onglet de Schrödinger#

Tout ça m'a fait penser au chat de Schrödinger. Dans cette célèbre expérience de pensée, tant que la boîte n'est pas ouverte, personne ne peut dire si le chat est vivant ou mort. L'onglet d'un agent dans Chrome, c'est à peu près pareil. Quand vous le regardez, il fonctionne correctement. Quand vous ne le regardez pas, il avance peut-être une fois par minute, ou il est peut-être déjà gelé. Quand l'agent agit sur l'onglet, c'est comme ouvrir la boîte pour jeter un œil, et l'onglet se réveille un moment. Quand l'agent s'en va, la boîte se referme, et cette fois on peut même voir la boîte : c'est le groupe d'onglets qui se replie tout seul.

Quand un agent mène plusieurs tâches à la fois, il ne peut agir que sur un onglet à la fois, et les autres sont enfermés dans des boîtes. Certains sont seulement ralentis, d'autres déjà gelés, d'autres encore ont l'air normaux mais ne sont même pas dessinés, et l'agent lui-même n'a aucune idée de l'état de chacun. Il ne s'agit donc pas seulement d'aller un peu plus vite ou un peu plus lentement. C'est ce qui décide si vous pouvez faire confiance à ce que l'agent vous rapporte.

Pour comprendre ce qu'il y avait derrière, j'ai parcouru le code source de Chromium 156 (il se comporte comme la version 157 que j'ai testée) en parallèle du code de l'extension Claude in Chrome 1.0.106, et j'ai trouvé sept règles empilées les unes sur les autres.

7. Ce que disent vraiment les sept règles#

Cette section reprend une par une, en regard du code source de Chromium, les sept règles rencontrées dans l'histoire ci-dessus. Elle s'adresse aux lecteurs qui veulent aller au fond des choses ou vérifier le code eux-mêmes. Si seul le comportement vous intéresse, « les onglets en arrière-plan sont bridés, gelés et pas dessinés » suffit, et vous pouvez passer directement à la section 8, « On ne peut pas simplement désactiver les limites de Chrome ? », sans rien manquer de la suite.

1. Dans une page cachée, après un délai de grâce, les minuteurs enchaînés ne peuvent se réveiller qu'une fois par minute. Le code de Chrome appelle ça intensive wake-up throttling (bridage intensif des réveils). Qu'est-ce que ça veut dire ? C'est le réveil que la page règle elle-même, dont on a parlé plus haut : un minuteur se déclenche, et sa fonction de rappel règle le minuteur suivant. Chrome compte la profondeur de la chaîne, et à partir du 7e niveau, une fois que la page est cachée depuis un moment, ces minuteurs ne peuvent se déclencher qu'une fois par minute. Le compte à rebours est écrit exactement comme ça, donc il se fait prendre. Un minuteur réglé après la réponse du serveur recommence à compter au niveau 1, donc l'export et les signalements au service client ne sont pas touchés. Le délai de grâce après qu'une page est cachée est en général de 60 secondes, et un onglet que l'agent a ouvert en arrière-plan sans qu'il ait jamais été affiché a lui aussi droit à 60 secondes. Passer à un autre onglet, avoir la fenêtre entièrement recouverte ou réduire la fenêtre, tout cela compte comme caché. Il existe aussi deux limites plus douces : aucun minuteur ne se réveille plus d'une fois par seconde, et au bout de 10 secondes de page cachée, l'ensemble des fonctions de rappel des minuteurs ne peut utiliser que 1 % du processeur, ce qui ne compte que pour les pages qui font de gros calculs dans leurs rappels. (third_party/blink/renderer/platform/scheduler/main_thread/page_scheduler_impl.cc ; niveau d'imbrication dans third_party/blink/renderer/core/scheduler/dom_timer.cc)

2. Quand un groupe d'onglets est réduit, les onglets qu'il contient sont gelés. Dès qu'un groupe est réduit, Chrome émet un vote « geler » pour chaque onglet du groupe. Les onglets affichés au cours des 5 dernières minutes sont protégés, et ceux qui n'ont jamais été affichés sont gelés sur-le-champ. Gelé veut dire que tout le code de la page s'arrête. Elle ne ralentit pas, elle ne bouge plus du tout, comme si on coupait le courant à ce tiroir. (chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc émet le vote ; components/performance_manager/freezing/freezing_policy.cc décide)

3. Après environ 20 secondes d'inactivité, Claude in Chrome réduit son propre groupe d'onglets. Cela n'arrive que lorsque l'onglet au premier plan de la fenêtre n'est pas l'un des siens, et la prochaine fois qu'elle a du travail, l'extension commence par développer le groupe. La règle 3 plus la règle 2, c'est le « mort au bout de 20 secondes » vu plus haut : l'extension réduit le groupe, et Chrome gèle les onglets qu'il contient.

4. L'extension fait croire à l'onglet sur lequel elle travaille que « quelqu'un le regarde ». Avant chaque action, l'extension utilise le protocole de débogage pour activer un interrupteur appelé émulation du focus (Emulation.setFocusEmulationEnabled). À quoi ça sert ? Ça dit à Chrome « cet onglet est en train d'être regardé », si bien que le visibilityState de la page passe à visible et que ses minuteurs ne sont plus bridés comme ceux des pages cachées, même si toute la fenêtre est réduite. Environ 20 secondes après l'action, l'extension désactive l'interrupteur.

Les règles 3 et 4 réunies expliquent aussi une bizarrerie : pourquoi l'onglet sur lequel l'agent a travaillé en dernier n'est parfois pas gelé quand le groupe se réduit. Je pensais que l'extension le protégeait volontairement, mais le code a montré que c'est une pure coïncidence. Quand le groupe se réduit, Chrome envoie un ordre de gel à chaque onglet du groupe. L'onglet que l'agent a touché en dernier a encore l'émulation du focus activée à ce moment-là, se croit regardé, et refuse l'ordre. Mais du côté de Chrome, personne ne remarque le refus : l'onglet est quand même noté comme « gelé », et l'ordre n'est jamais renvoyé. Quand l'émulation du focus se désactive et que l'onglet est vraiment hors de vue, plus personne ne revient le geler.

Pour le dire autrement : le surveillant de l'internat fait sa ronde d'extinction des feux, vous criez « il y a encore quelqu'un ici », le surveillant note « lumière éteinte » dans son cahier et passe son chemin, sans jamais revenir, et une fois que vous êtes endormi, la lumière reste allumée toute la nuit. Cet onglet ne reste éveillé que parce que « le groupe se réduit » et « l'émulation du focus se désactive » se produisent dans cet ordre-là, et ni l'extension ni Chrome ne l'ont conçu ainsi. Plus haut, quand l'agent est passé de A à B, A est tombé sur l'ordre inverse : son émulation du focus s'est désactivée d'abord, donc quand le groupe s'est réduit, A était déjà hors de vue, et le gel a pris effet dès qu'il est arrivé.

5. Une page qui n'est pas réellement dessinée à l'écran voit ses images réduites à une par seconde. L'émulation du focus peut faire croire à la page qu'on la regarde, mais elle ne peut pas tromper la partie qui dessine l'image. Chrome a un service de composition appelé viz qui envoie à chaque onglet un signal « commence à dessiner l'image suivante » (BeginFrame) au rythme de l'écran. Si 3 images d'affilée d'un onglet n'ont réellement été dessinées à l'écran par aucune fenêtre, ce signal tombe à une fois par seconde, et le commentaire du code le dit franchement : « we throttle BeginFrames to 1 per second » (components/viz/service/frame_sinks/compositor_frame_sink_support.h, kUndrawnFrameLimit = 3). Les onglets placés derrière d'autres ou dans une fenêtre réduite ne peuvent donc exécuter requestAnimationFrame (la fonction que les pages web utilisent pour dessiner les animations) qu'une ou deux fois par seconde, même avec des minuteurs qui tournent normalement. C'est comme une caméra braquée sur une scène : les acteurs continuent de jouer, mais la caméra remarque que personne ne regarde la retransmission et passe à une prise de vue par seconde. Sur les moins de 4 images par seconde que j'ai mesurées, les deux ou trois en plus sont probablement dessinées en passant, lors des captures d'écran de l'extension.

6. Une fenêtre recouverte ou réduite compte aussi comme hors de vue. Sous Windows, Chrome calcule lui-même si une fenêtre est entièrement recouverte par d'autres fenêtres, et si c'est le cas, il traite ses onglets comme cachés (ui/aura/native_window_occlusion_tracker_win.cc, activé par défaut). Quand une fenêtre est réduite, toute sa zone de composition passe à 0×0 (desktop_window_tree_host_win.cc).

7. Les processus de rendu en arrière-plan sont aussi rétrogradés. Si un processus de rendu n'a aucun onglet visible, Chrome le fait passer à la priorité la plus basse et demande à Windows l'EcoQoS, c'est-à-dire de le faire tourner à la fréquence la plus économe du processeur et de placer son travail sur les cœurs à haute efficacité énergétique, au prix de la vitesse (base/process/process_win.cc, kUseEcoQoSForBackgroundProcess activé par défaut). Cette règle regarde si la fenêtre est réellement visible, donc l'émulation du focus ne peut pas la tromper.

Chacune de ces sept règles est raisonnable prise seule, mais empilées, elles mettent l'onglet d'un agent dans une position bancale. La page se croit visible, et pourtant ses minuteurs peuvent être bridés. L'agent vient de travailler dedans, et pourtant un peu plus tard elle peut être gelée. Elle n'est pas gelée, et pourtant son image bouge à peine. Quels onglets sont éveillés et lesquels dorment, même les gens qui ont écrit l'extension ne sauraient peut-être pas le dire. Au bout du compte, on en revient toujours au même point : les règles des navigateurs ont été écrites pour des personnes.

8. On ne peut pas simplement désactiver les limites de Chrome ?#

Vous vous dites peut-être que puisque ce sont les règles de Chrome qui sont en cause, on pourrait les désactiver avec des options de lancement. En partie, oui. --disable-background-timer-throttling, --intensive-wake-up-throttling-policy=0, --disable-renderer-backgrounding et --disable-backgrounding-occluded-windows désactivent le bridage des minuteurs et la rétrogradation des processus. Mais la règle sur les images, elle, ne se désactive pas. Un onglet qui n'est pas dessiné à l'écran ne récupère pas ses images normales parce que vous avez désactivé le bridage des minuteurs, et l'agent peut donc toujours lire un compteur pas encore arrivé au bout.

9. Les mêmes tests dans Embiody#

Nous construisons Embiody, un navigateur Windows conçu pour les agents IA. Les agents y travaillent via BrowserDo, un serveur MCP fait pour lui. Claude Code et Codex se branchent avec une seule commande, Cursor et Claude Desktop avec quelques lignes de configuration. La fonctionnalité des onglets IA est née de cet après-midi de juillet : je voulais que les agents fassent plusieurs choses à la fois pendant que je poursuivais mon propre travail.

J'ai donc refait tous les tests ci-dessus dans Embiody dans les mêmes conditions, en changeant seulement le navigateur pour Embiody et l'outil pour BrowserDo. Les résultats :

Dans Embiody, la tâche B se termine à l'heure même quand elle est derrière d'autres onglets, sans que personne n'y touche, dans une fenêtre réduite. La page sur laquelle l'agent travaille en arrière-plan continue d'être dessinée, le chiffre des statistiques est bien lu du premier coup, et la discussion avec le service client reste connectée. Cela ne vaut toutefois que pour les onglets que l'agent utilise. Les onglets que vous ouvrez vous-même sont toujours bridés en arrière-plan selon les règles d'économie d'énergie habituelles, donc avoir un agent dans le navigateur ne fait pas consommer plus à vos propres onglets. Le chat dans la boîte reste éveillé. Pour être honnête, il s'agissait d'une seule machine Windows et de 1 à 2 essais par test pour Embiody, rien à voir avec un test à grande échelle, mais dans ces scénarios au moins, la différence est nette.

Encore une chose à préciser : ces problèmes ne sont pas propres à Claude in Chrome. Quels que soient l'extension ou l'outil d'automatisation que vous utilisez, un agent qui travaille dans Chrome doit vivre selon les règles de Chrome. Dans le test du compte à rebours du début, l'onglet que j'avais ouvert à la main a pris plus de 390 secondes de retard en 8 minutes, exactement comme celui de Claude. Il y a aussi deux règles que je n'ai pas rencontrées cette fois. Quand l'ordinateur manque de mémoire, Chrome décharge l'onglet en arrière-plan qui n'a pas été regardé depuis le plus longtemps, et il se recharge quand vous y revenez. Et quand un portable est débranché avec une batterie sous les 20 %, les onglets en arrière-plan qui utilisent pas mal de processeur sont gelés. Une personne qui s'absente et tombe sur l'une de ces règles n'a qu'à actualiser la page en revenant. Un agent qui tourne tout l'après-midi en s'occupant de plusieurs pages à la fois finira tôt ou tard par tomber dessus.

10. L'IA a besoin de son propre navigateur#

Après quelques années à faire travailler l'IA, j'en suis de plus en plus convaincu : l'IA a besoin de son propre navigateur, et se débrouiller avec Chrome n'est qu'une solution de fortune.

Je ne dis pas que Chrome fait mal son travail. Ces règles ont été affinées pendant des années pour que la personne assise devant l'écran soit mieux servie : les onglets que vous ne voyez pas doivent consommer moins, les animations que personne ne voit n'ont pas besoin d'être dessinées, et les pages inutilisées depuis longtemps doivent être gelées, voire déchargées. Tout ce qu'une extension peut faire, c'est ajouter une couche par-dessus ces règles, par exemple utiliser l'émulation du focus pour faire croire à une page que quelqu'un la regarde, ou réduire son groupe d'onglets pour que les onglets de l'agent ne vous gênent pas. Mais les règles sont celles de Chrome, et l'architecture de Chrome a été conçue pour des personnes. Sans la changer en profondeur, une extension ne peut que rafistoler.

L'onglet de tout à l'heure, celui pour lequel le surveillant a noté « lumière éteinte », c'est ce que donne le rafistolage. Il ne reste éveillé que parce que deux choses se sont produites par hasard dans un certain ordre. N'importe quelle nouvelle version de Chrome peut changer cet ordre, et ce genre de coïncidence ne s'évite pas et ne se prévoit pas, parce que Chrome n'a jamais été conçu pour les agents.

Pour ne plus dépendre du hasard, il faut que les règles du navigateur elles-mêmes tiennent compte des agents. Pour une personne, qu'un onglet soit visible ou non décide s'il doit continuer à consommer des ressources. Pour un agent, un onglet que personne ne regarde est peut-être en train de faire pour vous quelque chose qui ne peut pas être mis en pause, et il doit continuer à travailler, qu'il y ait quelqu'un devant l'écran ou non. Cela ne peut se régler que dans le moteur du navigateur lui-même, et c'est le principe sur lequel sont construits les onglets IA d'Embiody.

(Embiody : 1 à 2 essais par test, 11 et 12 novembre 2026, même machine.)

Ce que je n'ai pas testé#

• Une seule machine Windows et une seule version de Chrome. Quand j'ai testé à la main en juillet, j'ai le souvenir que le ralentissement ne devenait net qu'au bout de 5 minutes ; cette fois (Chrome 157), c'était environ 1 minute. Je ne sais pas si Chrome a changé ou si ma mémoire me joue des tours.
• Pas de Mac ni de Linux, et rien avec l'économiseur de mémoire activé.
• Le déchargement d'onglets quand la mémoire manque et le gel d'onglets quand la batterie est faible viennent uniquement de la lecture du code source, pas de mesures.

Essayez vous-même en deux minutes#

Ouvrez https://embiody.com/lab/background-tab/. La page lance un compte à rebours de 15 minutes. Passez à un autre onglet (recouvrir ou réduire la fenêtre marche aussi), revenez au bout de deux minutes et regardez « Behind by » (retard) : c'est le nombre de secondes que le compte à rebours a perdues pendant votre absence. 0 s voudrait dire que la page a continué à tourner à l'heure. La page de test est en anglais.

Pour finir#

Je ne sais pas si Chrome changera un jour ces règles pour les agents. Ses raisons sont bonnes : économiser l'énergie, économiser la mémoire et garder le premier plan fluide, c'est exactement ce qu'un navigateur doit faire. Simplement, le navigateur partait du principe qu'il y avait une personne devant l'écran, qui regarde un onglet à la fois, et aujourd'hui il n'y a peut-être plus personne devant l'écran, mais un agent derrière les onglets qui s'occupe de plusieurs pages à la fois.

Si vous ne le regardez pas, il ne travaille pas. Mais le travail d'un agent, c'est justement celui qui se fait pendant que vous ne regardez pas.