Cloudflare facilite le retour d’une erreur au code d’origine

Un formulaire web peut s’appuyer sur un petit programme exécuté à distance pour traiter une demande. Cloudflare Workers fournit ce type d’exécution. Lorsqu’une erreur survient, l’équipe technique cherche le fichier et la ligne à examiner. Or le code envoyé en production a souvent été regroupé et compacté : les repères visibles dans l’erreur peuvent devenir difficiles à rapprocher du travail d’origine.

Une source map est une table de correspondance entre le code transformé et le code source. Elle aide à restituer des repères lisibles dans la trace d’erreur, c’est-à-dire la suite des appels qui ont conduit au problème. La documentation Cloudflare sur les source maps décrit ce rôle. Le fichier sert à retrouver un emplacement ; la recherche de la cause et sa correction restent un travail à effectuer.

Ce qui devient automatique le 20 octobre

Cloudflare annonce que Wrangler 4.150.0 génère et envoie ces fichiers par défaut lors du déploiement, de l’envoi d’une version ou d’un aperçu. Wrangler est l’outil utilisé par les développeurs pour ces opérations. L’annonce concerne aussi le déploiement avec cf ; avec le plugin Cloudflare Vite, la génération par défaut demande la version 1.64.0 ou ultérieure. Ces conditions figurent dans la note du 20 octobre 2026. Un projet utilisant une ancienne chaîne de construction doit donc être examiné avant de supposer ce comportement acquis.

Les traces ainsi réinterprétées sont disponibles dans plusieurs outils de journaux et de suivi d’erreurs de Workers. Cloudflare précise que l’application des correspondances intervient après l’exécution et ne modifie ni le temps processeur, ni la taille du programme, ni son démarrage à froid. La même note de version distingue donc l’amélioration du diagnostic d’une amélioration des performances. Le responsable du site peut demander un diagnostic plus exploitable sans en déduire une accélération pour ses visiteurs.

Une preuve utile avant le prochain incident

Voici un contrôle à faire réaliser sur un environnement d’essai, avec des données fictives. Le développeur provoque une erreur connue dans une version identifiée, puis vérifie que la trace renvoie au fichier attendu et à la bonne ligne. Il conserve le numéro de version déployée et le résultat du contrôle. Ce rapprochement compte davantage qu’une simple présence de fichiers : une correspondance associée au mauvais code orienterait la recherche vers une mauvaise piste.

Le comportement par défaut a une limite importante : Wrangler peut ignorer les correspondances qu’il ne parvient pas à résoudre et poursuivre l’envoi. La documentation technique prévoit un réglage explicite pour faire échouer l’envoi dans ce cas. Le choix dépend du projet : si le diagnostic est indispensable à son exploitation, l’équipe peut préférer détecter ce manque avant la mise en ligne. Il faut aussi vérifier les droits d’accès aux outils où les traces sont consultées et les informations qu’ils contiennent.

Préparer une maintenance capable d’expliquer

L’amélioration devient utile lorsque l’on sait quelle version tourne, où lire l’erreur et qui doit l’examiner. Dans un projet de site, ces questions gagnent à être posées avant la livraison. Les offres de création de sites Gaia permettent de cadrer les fonctions attendues, tandis que les offres de maintenance précisent les niveaux de suivi. Une application Workers et sa chaîne de déploiement demandent un périmètre technique explicite ; la présence de source maps ne suffit pas à définir ce service.