Chrome peut désormais renvoyer n'importe quelle requête. Ce que cela vous dit et ce que cela ne vous dit pas

Les notes DevTools de Chrome 152 sont parues le 25 août 2026, et une ligne y compte davantage que sa taille ne le laisse croire. L’ancienne entrée de menu Replay XHR du panneau Network est devenue simplement Resend, et la description que Chrome donne lui-même du changement est exacte :

Il prend désormais en charge toutes les requêtes réseau récupérables, convertissant les requêtes standard en appels fetch() tout en préservant une fidélité de rejeu complète, aux côtés de XHR.

Replay XHR figurait dans ce menu depuis des années, utile seulement pour le type de requête précis qu’il nommait. Toute autre requête en échec - un envoi de formulaire, la récupération d’un document, un téléversement - devait être reconstruite à la main sous forme de commande curl ou dans un client. Maintenant, vous faites un clic droit dessus et vous la renvoyez.

La même version donne à l’onglet Payload des options de décodage - Base64, Hex et UTF-8 - pour les corps de requête binaires et compressés, reprenant ce que l’onglet Response offrait déjà. Quiconque a déjà regardé un téléversement de fichier en échec ou un corps compressé sans rien y voir d’exploitable dispose maintenant de trois façons de le lire.

Pourquoi cela compte quand la requête n’était pas la vôtre

Les deux changements portent sur la même activité : comprendre ce qui s’est passé à partir d’une requête que vous n’avez pas faite.

C’est le cas de la plupart des rapports de bogue. Quelqu’un a rencontré une panne, la requête en échec est devant vous, et la question est de savoir si vous pouvez remonter d’elle à une cause. Pouvoir la renvoyer en un clic, et lire un corps qui était jusqu’ici opaque, retire deux corvées de ce travail.

Ce sur quoi il faut être prudent

Un renvoi n’est pas la requête qui a échoué. C’est une nouvelle requête qui lui ressemble.

Elle part de votre navigateur, avec vos cookies, votre session, vos extensions et votre adresse IP, à un moment qui n’est pas celui de l’échec d’origine. Cela fait quatre différences avant même que vous ayez changé quoi que ce soit, et chacune peut renverser le résultat :

Ce à quoi un renvoi répond

Est-ce que cette forme de requête échoue pour moi, depuis ici, maintenant ?

Ce à quoi le rapport doit répondre

Pourquoi cette requête a-t-elle échoué pour cette personne-là, sur sa session, à ce moment-là ?

Un 403 qui revient en 200 signifie en général que la différence était dans la session plutôt que dans la requête. Un 500 qui revient en 500 est un cadeau, parce que vous tenez une reproduction que vous contrôlez. Un délai d’attente dépassé qui revient instantanément vous dit que l’état qui l’a provoqué est passé, ce qui est exactement le cas du 504.

Rien de tout cela ne rend Resend moins utile. Cela en fait une première question plutôt qu’une réponse, et savoir laquelle des deux vous tenez, c’est tout le métier.

Ce que le rapport doit porter pour que tout cela fonctionne

Vous ne pouvez pas renvoyer une requête que vous n’avez pas. Ce qui rend cette nouvelle possibilité accessible tout court, c’est de savoir si la requête en échec a survécu au trajet entre la personne qui l’a vue et celle qui la corrige, avec sa méthode, son URL, ses en-têtes et son corps intacts.

C’est à cela que sert un journal réseau dans un rapport de bogue, et c’est pour cela que les fichiers HAR existent en tant que format.

Une limite honnête de notre côté : nous masquons par défaut les en-têtes et les valeurs d’identification, et sur un domaine qui n’a rien demandé d’autre, nous les masquons partout. Une requête rejouée à partir d’un rapport que nous avons capturé demandera donc en général que son autorisation soit fournie par la personne qui la rejoue. C’est l’arbitrage que nous avons choisi - un rapport est un lien que quelqu’un peut ouvrir, donc tout ce qui est capturé est de fait partagé - et il vaut mieux le savoir avant de se demander pourquoi le renvoi est revenu non autorisé.

Le reste de la version, en bref

Trois autres choses dans les mêmes notes valent la minute d’un développeur.

Copy as preload element. Faites un clic droit sur une requête et vous obtenez une balise <link rel="preload"> prête à coller, ce qui transforme une observation de performance en une modification sans l’étape intermédiaire de la recherche de syntaxe.

L’export structuré des tableaux dans la console, pour qu’un tableau que vous avez journalisé puisse quitter la console sous forme de données plutôt que de capture d’écran de données.

Le passage de l’arbre DOM à l’arbre d’accessibilité depuis le menu contextuel d’Elements, avec “scroll into view” pour les nœuds d’accessibilité. Petit, et cela abaisse le coût de la vérification que la plupart des équipes font le moins.

Ce qu’il faut en retenir

Une note de version de navigateur ne mérite en général pas d’être lue deux fois, et celle-ci le mérite, pour une raison qui n’a rien à voir avec la taille des fonctionnalités : elle améliore l’outillage autour des preuves rassemblées par quelqu’un d’autre. C’est une catégorie dans laquelle la plupart des outils de débogage ont historiquement été mauvais, parce qu’ils supposent que la personne qui tient le navigateur est celle qui a trouvé le bogue.

Ce n’est en général pas la même personne. Tout ce qui raccourcit la distance entre les deux vaut plus que ce que sa note de version laisse croire.

Les notes de Chrome sont l’endroit où lire la liste complète : What’s new in DevTools (Chrome 152).