Cloudflare unifie son observabilité et ouvre Traces sur tout le chemin de requête
Cloudflare regroupe journaux, traces, alertes et analytics dans une plateforme unique, et ouvre Traces en bêta pour suivre une requête de bout en bout. La tarification unifiée entre en vigueur le 1er décembre 2026, alors auditez vos volumes de journaux dès maintenant.
2 octobre 2026. Cloudflare ouvre Traces en bêta et dévoile huit mises à jour qui regroupent journaux, traces, alertes et analytics dans une plateforme d’observabilité unique. 2 octobre 2026. Le nouveau service génère automatiquement des spans sur tout le chemin de requête — règles de sécurité, transformations, décisions de cache, routage, exécution Workers, traitement à l’origine — sans instrumentation manuelle. 2 octobre 2026. La tarification unifiée des journaux et des traces s’appliquera à partir du 1er décembre 2026. Pourquoi c’est important : Cloudflare veut devenir « la partie la plus observable de votre pile », et le changement de modèle tarifaire impose de vérifier ses volumes de logs avant la fin d’année.
La fin du puzzle « quel produit détient ce signal »
Le constat de départ est simple, et il parle à tout SRE qui a déjà débogué une requête passant par Cloudflare. Les signaux d’une même requête sont éparpillés entre des produits distincts — les journaux Workers d’un côté, les événements de pare-feu de l’autre, les analytics de domaine encore ailleurs. Reconstruire ce qui s’est passé revient à interroger chaque silo avec sa propre requête, son propre langage et son propre modèle de facturation.
Cloudflare répond en changeant de logique. Au lieu de demander « quel produit détient ce signal », la plateforme pose désormais la question inverse : « que s’est-il passé sur ce chemin de requête, du bord à l’origine, en une seule vue ». C’est le sens des huit mises à jour annoncées le 2 octobre 2026 pendant la Birthday Week, et c’est un virage stratégique autant que technique : l’observabilité devient une capacité transverse, pas une somme de produits.
La première brique est la nouvelle page d’accueil des Logs, qui fusionne Workers Observability et Log Explorer. Un même jeu d’outils couvre désormais les jeux de données HTTP, pare-feu, Workers, Containers, R2 et AI Gateway. On peut partir d’une hausse de latence, regrouper par nom d’hôte ou par datacenter, puis basculer vers un autre jeu de données sans quitter l’écran. Le requêtage se fait en SQL brut ou via des filtres intégrés, et des visualisations peuvent être générées en langage naturel.
Traces : une requête, suivie de bout en bout
Traces est le cœur de l’annonce. Là où Workers Tracing — lancé l’an dernier — se limitait aux invocations Workers et à leurs appels sortants vers KV, R2, D1 ou Durable Objects, la nouvelle version étend le traçage à tout le reste du chemin. En une seule trace, on voit désormais quelles règles de sécurité ont été évaluées, comment une Transform Rule a réécrit l’URL, si la réponse venait du cache et où le temps s’est écoulé entre Cloudflare, la connexion à l’origine et l’application.
L’exemple que donne Cloudflare est parlant : un cache miss renvoyé à l’origine, où 527 ms sur les 539 ms totales ont été consommées par la remontée depuis le serveur d’application. C’est exactement le type d’information qui, jusqu’ici, exigeait de corréler manuellement des journaux séparés. Désormais, chaque étape est enregistrée comme un span avec son timing, son résultat et ses attributs, et l’on peut répondre directement à des questions opérationnelles : « pourquoi cette requête a-t-elle été bloquée, et quelle règle a agi ? » ou « quelle partie du chemin a ajouté les 500 ms manquantes ? »
Le déploiement est volontairement frugal. Aucun plugin ni instrumentation à écrire : une fois le traçage activé sur un domaine, les spans sont générés automatiquement. Un taux d’échantillonnage de base — par exemple 1 % du trafic — maintient un filet de visibilité continu sans collecter une trace pour chaque requête. Les Trace Rules, qui réutilisent le langage de règles de Cloudflare, permettent d’élever ce taux à 100 % pour une enquête ciblée : un nom d’hôte, une adresse IP, un en-tête de débogage temporaire. La propagation W3C traceparent accepte et transmet le contexte de trace, et l’export se fait en OpenTelemetry vers n’importe quel point d’entrée OTLP.
Une seule API SQL et un seul modèle de prix
L’autre brique structurante est l’API SQL unifiée, en bêta. Au lieu d’intégrer séparément les journaux Workers, les événements de sécurité des Containers, les requêtes HTTP et les données d’analytics, une personne — ou un agent IA — interroge tout avec un seul dialecte SQL, un seul modèle d’authentification et une seule API. L’agent peut passer par la nouvelle CLI cf ou par le serveur MCP d’observabilité de Cloudflare pour enquêter sur journaux, traces et analytics. La même surface SQL arrive directement dans Workers via un binding natif, pour météorer un usage client, construire des tableaux de bord ou automatiser l’investigation d’incident sans configurer un client d’API séparé.
Ce mouvement s’accompagne d’un changement qui, lui, aura un impact direct sur les factures. À partir du 1er décembre 2026, les journaux et traces ingérés et stockés basculent vers un abonnement d’observabilité unifié et une tarification au volume : 0,25 $ par Go ingéré et 0,10 $ par Go-mois stocké. Le palier gratuit inclut 0,5 Go d’ingestion par jour avec 7 jours de rétention ; les plans payants et Enterprise incluent 50 Go d’ingestion et 10 Go-mois de stockage par cycle, avec une rétention jusqu’à un an annoncée comme prochaine. Pour une équipe qui journalise beaucoup, le passage d’une facturation « par événement » à une facturation « au volume » peut déplacer la note dans un sens comme dans l’autre — d’où l’intérêt d’auditer ses volumes avant l’échéance.
Des alertes et des analytics enfin homogènes
La consolidation touche aussi les alertes. L’ancien module Notifications, rebaptisé Alerts, permet désormais de définir des conditions directement sur tout ce que l’API SQL unifiée sait interroger : journaux HTTP, événements Workers, jeux de données de l’Analytics Engine, traces et événements de sécurité. On choisit un jeu de données et une condition en SQL, un seuil, une anomalie ou un SLO, une fenêtre d’évaluation et une destination — et les webhooks sont désormais disponibles sur tous les plans, y compris pour router une alerte vers un agent qui commence l’investigation immédiatement.
Enfin, les analytics de domaine gagnent une rétention de 30 jours et une vue unifiée, ce qui clôt la promesse d’ensemble : ne plus avoir à reconstituer l’état d’un domaine à partir de métriques dispersées. Prises une à une, ces huit évolutions sont des améliorations incrémentales. Mises bout à bout, elles dessinent une plateforme où la trace devient l’unité de base de l’investigation, et où le SQL devient la langue commune de l’observabilité.
Verdict
Si vous êtes déjà chez Cloudflare et que vous déboguez des piles multi-sauts — WAF, transformations, Workers, origine —, activez Traces dès la bêta et branchez l’API SQL unifiée : elles suppriment la friction principale, qui est de reconstituer une requête à partir de journaux éclatés. Avant le 1er décembre 2026, modélisez votre volume de logs et de traces au nouveau barème (0,25 $/Go ingéré, 0,10 $/Go-mois) pour éviter une surprise de facturation — surtout si vous journalisez massivement. Si vous êtes sur un autre CDN, ce virage est un argument de plus en faveur de la gravité d’observabilité de Cloudflare : la plateforme où vos requêtes passent devient celle qui vous montre le mieux ce qu’elles ont fait.