Cloudflare a achevé le 12 août la migration de son blog vers EmDash, un système de gestion de contenu conçu pour fonctionner avec Astro et Cloudflare, dans le cadre d’un projet qui ne s’est pas limité à une refonte de l’interface. L’entreprise a utilisé son blog comme « client zéro » pour tester la nouvelle plateforme sur du trafic de production réel, en mettant l’accent sur l’évolutivité, la rapidité de réponse et la sûreté de la transition depuis l’ancien système.
Cloudflare affirme que le processus de migration a révélé des besoins liés à la taille et à la complexité du blog, et a permis à l’équipe d’améliorer EmDash avant son déploiement à plus grande échelle. Comme les résultats et les mesures proviennent de l’entreprise elle-même, ils représentent une expérience opérationnelle publiée par une seule partie et non un test indépendant de la plateforme.
Tester la plateforme avant les performances
L’équipe a commencé par une question pratique : EmDash répond-il réellement aux besoins de Cloudflare ? Elle a donc testé des parcours essentiels, comme la création, la publication, la dépublication et la planification des articles, ainsi que l’ajout de médias, la recherche dans les entités de contenu et la gestion des noms d’auteurs.
Les lacunes les plus importantes concernaient la gestion du grand volume de médias et de contenu, ainsi que les détails liés à la traduction, à l’optimisation pour les moteurs de recherche et aux politiques de sécurité du contenu (CSP). L’éditeur d’administration nécessitait également des améliorations pour trouver les blocs HTML personnalisés, gérer les erreurs dans l’éditeur de contenu et maintenir la barre de mise en forme visible lors de la modification d’articles longs.
Les articles planifiés ont constitué le principal problème découvert : ils ne fonctionnaient pas encore dans EmDash 0.19.0. Ce point illustre la valeur du test de parcours opérationnels complets avant d’adopter un nouveau système, car le dysfonctionnement n’aurait pas nécessairement été détecté lors d’un test de création ou de publication immédiate de contenu.
Des tests de charge simulant un trafic fluctuant
Le trafic habituel du Cloudflare Blog se situait autour de 75 requêtes par seconde, mais pouvait dépasser 5 000 requêtes par seconde, soit lors de la diffusion d’un nouvel article, soit en raison de pics indépendants de l’heure de publication. L’équipe a donc conçu des tests avec l’outil open source k6, comprenant une augmentation progressive de la charge jusqu’à trois fois la référence, un test partant de zéro et atteignant 100 requêtes par seconde en dix minutes, ainsi qu’un test d’explosion immédiate à 7 000 requêtes par seconde pendant une minute.
Les critères d’échec reposaient sur trois indicateurs : les erreurs HTTP de classe 5xx ne devaient pas dépasser 0,01 %, le temps de réponse de 95 % des requêtes ne devait pas dépasser 500 millisecondes et celui de 99 % des requêtes ne devait pas dépasser une seconde. Ces limites ont transformé la question « la plateforme est-elle rapide ? » en conditions opérationnelles mesurables.
Une architecture multicouche et une voie de retour claire
Cloudflare a choisi d’exécuter EmDash sur un Cloudflare Worker derrière Workers Cache, en utilisant le nouveau stockage d’objets d’EmDash fondé sur Workers KV, ainsi que l’intégration d’Hyperdrive avec PlanetScale. Les couches de mise en cache ont permis de servir 99,5 % des fichiers statiques depuis le cache, et environ 70 % de l’ensemble des requêtes, selon les données de l’entreprise, ce qui a réduit la pression sur la base de données.
Pour éviter une interruption du service pendant la transition, l’équipe a créé un Proxy Worker qui répartissait les requêtes entre l’ancien blog et le nouveau site. Il déterminait la version expérimentale à l’aide d’un cookie, avec la possibilité de renvoyer les requêtes vers l’ancien système en cas d’erreurs 500 sur le nouveau site. Elle a également utilisé une connexion directe entre Workers via la liaison de service NEW_BLOG afin d’éviter de passer par un nom de domaine public, des opérations DNS et TLS et une connexion HTTP externe.
Le déploiement progressif a commencé avec 1 % du trafic, puis est passé à 5 % et 15 %, avant d’atteindre 100 % à la fin de la journée. Cette méthode a permis de surveiller la charge réelle et de détecter les cas limites sans exposer la majorité des lecteurs à une modification instable.
Qu’est-ce qui a changé concrètement ?
Cloudflare affirme que la nouvelle architecture a maintenu un temps de réponse plus stable que la plateforme précédente, avec des gains de performance et un nombre limité d’erreurs lors du traitement de jusqu’à 850 requêtes par seconde. Pendant Agents Week, 18 articles ont été publiés en neuf jours et ont enregistré près de 3 millions de vues ; le nouveau Worker a traité jusqu’à 450 requêtes par seconde sans problème notable. La protection DDoS intégrée a également absorbé une attaque atteignant 28 000 requêtes par seconde le 10 août, selon l’entreprise.
Le changement a également concerné l’interface, reconstruite selon les modèles du système de design Kumo, avec une prise en charge native des modes clair et sombre fondée sur les préférences du système et un bouton de basculement manuel. L’invitation à s’abonner par e-mail a été déplacée à la fin de l’article, et une table des matières « Sur cette page » ainsi qu’une option « Discuter en ligne » ont été ajoutées afin d’améliorer la navigation et le partage.
Les nouvelles interfaces d’EmDash et les points de recherche en intelligence artificielle ont permis de créer en quelques heures un serveur MCP pour le blog de Cloudflare, avec des outils permettant de rechercher, de répertorier et de récupérer les articles, ainsi que de répertorier les balises. Le serveur MCP d’EmDash permet également aux auteurs de parcourir, créer, modifier, publier et planifier du contenu, ainsi que de supprimer des fichiers sans coût supplémentaire, selon la source.
L’expérience d’édition elle-même reste incomplète : Cloudflare continue d’enregistrer de petits problèmes et des erreurs liées aux articles planifiés, et indique les avoir transmis à l’équipe d’EmDash, qui devrait les corriger avant Birthday Week. Ce cas ne prouve donc pas que la plateforme est dépourvue de limites, mais il illustre une pratique applicable : tester les parcours de contenu avant les performances, définir des seuils d’échec explicites, construire une voie de retour, puis élargir progressivement le déploiement plutôt que d’effectuer une transition globale en une seule fois.