veilletech.frCe qui se passe
Le 12 août 2026, Cloudflare a déplacé son blog vers EmDash, un système de gestion de contenu conçu pour Astro et pour tourner sur leur propre infrastructure. La refonte visuelle visible — mode sombre compris — n'était que la partie émergée d'un changement de plateforme.
L'intérêt du billet n'est pas l'annonce produit : c'est le compte rendu de migration, avec les scénarios de charge, les seuils, et les trous découverts en route.
La méthode : décider avant de mesurer
Le trafic du blog est très irrégulier. La charge courante tourne autour de 75 requêtes par seconde, avec des pointes au-delà de 5 000 — parfois à la publication d'un article devenu viral, parfois en pleine nuit sans raison apparente.
L'équipe a donc rejoué ce profil avec k6, en trois scénarios :
- Montée progressive jusqu'à trois fois la charge de production, puis retour au calme.
- Point de rupture : montée de 0 à 100 requêtes par seconde en dix minutes, arrêt dès que quelque chose casse.
- Rafale : 7 000 requêtes par seconde d'un coup, pendant une minute.
Le point important est ailleurs : les critères d'échec étaient écrits avant de lancer les tests.
- Disponibilité : échec au-delà de 0,01 % de réponses en erreur serveur.
- Latence p95 : échec si plus de 5 % des réponses dépassent 500 ms.
- Latence p99 : échec si plus de 1 % des réponses dépassent 1 000 ms.
C'est ce qui distingue un test de charge d'une démonstration : sans seuil défini d'avance, un graphique se lit toujours dans le sens de la décision déjà prise.
L'architecture retenue
Le résultat empile les niveaux de cache, du plus proche de l'utilisateur au plus profond :
- EmDash exécuté sur un Worker.
- Derrière le nouveau Workers Cache — Cloudflare se présente comme le premier site majeur à l'utiliser.
- Un cache d'objets bâti sur Workers KV, développé spécifiquement pour ce cas d'usage.
- Une connexion Hyperdrive de première partie vers PlanetScale.
Cette superposition explique la résistance aux rafales : l'origine n'est sollicitée que pour ce qui n'est ni en cache de bord, ni en cache d'objets.
Ce que le test d'usage a rattrapé
L'équipe a aussi mené des tests d'utilisation sur l'interface d'édition, et les manques trouvés sont instructifs parce qu'ils sont typiques d'une migration de CMS :
- l'échelle du site — médiathèque, recherche d'entités, signatures d'auteurs ;
- les sujets connexes que personne ne teste : localisation, référencement, politique de sécurité du contenu ;
- l'ergonomie de rédaction qui retarde une publication — blocs HTML difficiles à retrouver, barre d'outils qui disparaît sur les longs articles.
Le trou le plus sérieux : la publication programmée ne fonctionnait pas avant la version 0.19.0 d'EmDash. Découvrir cela à l'heure prévue d'une publication aurait coûté bien plus cher que le test.
À retenir
Trois réflexes réutilisables, quelle que soit la pile : rejouer son propre profil de trafic plutôt qu'un profil théorique ; fixer les seuils d'échec avant de lancer les tests ; et tester le parcours de publication, pas seulement le rendu public — c'est là que les migrations font mal.
Source : Cloudflare