5 min de lecture
Celui qui a déjà développé sur Cloudflare Workers connaît le mur : dès que le code nécessite plus de 128 Mo de RAM ou une véritable chaîne d’outils Linux, le déploiement devient compliqué. Avec la disponibilité générale (GA) de Containers depuis le 13 avril 2026, Cloudflare repousse ce mur. Les développeurs web qui jusqu’ici migraient vers EC2, Fly.io ou Render obtiennent désormais une couche Edge intermédiaire, sans cluster Kubernetes ni contrat de datacenter.
10.05.2026
Les points clés en bref
- Tarification Active-CPU, un véritable levier : les conteneurs ne sont facturés que lorsque le processeur consomme réellement des cycles. Les conteneurs inactifs ne coûtent que la mémoire et le stockage, pas la puissance de calcul. Pour les charges en rafale, cela change complètement la donne par rapport à AWS Fargate ou Fly.io.
- Noms d’hôte, Docker Hub, SSH : les Workers accèdent aux conteneurs via des liaisons de service, les images proviennent de Docker Hub ou d’une registry, et le SSH est disponible pour le débogage en direct. L’ensemble ressemble à un environnement Linux classique, pas à une sandbox Edge.
- Combler le fossé entre Workers et EC2 : pour les navigateurs sans interface, ffmpeg, Pandoc ou de petits endpoints d’inférence, Workers était jusqu’ici trop limité, et EC2 trop lourd. Containers comble précisément ce niveau intermédiaire et réduit le saut technologique à un seul fournisseur.
En lien :Les mini-PCs remplacent les serveurs 1HE : Edge dans le datacenter en 2026 / Documentation Cloudflare Containers
Ce que Containers GA apporte réellement
Qu’est-ce qu’un Cloudflare Container ? Un Cloudflare Container est un conteneur Linux éphémère, exécuté dans le réseau Edge de Cloudflare et accessible depuis un Worker via des liaisons de service. Il se situe fonctionnellement entre une fonction Workers et une machine virtuelle cloud classique, et prend en charge les charges nécessitant plus de temps d’exécution, plus de mémoire ou une chaîne d’outils Linux complète.
La version GA apporte trois améliorations majeures par rapport à la version bêta publique. La tarification Active-CPU ne facture que les cycles processeur réellement consommés, et non le temps réel écoulé. Les limites autorisent des milliers de conteneurs exécutés en parallèle par compte. Les liaisons de service permettent d’adresser les conteneurs via un nom d’hôte plutôt qu’une adresse IP, supprimant ainsi la logique DNS et le code de découverte du Worker.
S’ajoutent le support de Docker Hub pour les pulls d’images directs, le SSH pour le débogage en direct, et les Sandboxes, un produit complémentaire dédié aux charges de travail d’agents IA avec des sessions de système de fichiers persistantes. Celui qui possède un Worker nécessitant un navigateur sans interface pour des captures d’écran ou un pipeline Pandoc pour générer des PDF peut désormais appeler un conteneur via une liaison de service, sans passer par un fournisseur d’API externe.
Où l’avantage Edge s’applique, où pas
Les conteneurs ne fonctionnent pas dans chaque emplacement Edge, mais sont lancés à la demande dans la région disponible la plus proche. Pour les applications Web interactives avec des utilisateurs DACH, cela signifie généralement Francfort ou Düsseldorf. Les latences entre le worker et le conteneur sont ainsi dans la plage des millisecondes, le saut vers un backend classique à Francfort ou Dublin est éliminé. La documentation officielle de la plateforme liste explicitement les régions et les limites prises en charge.
Où cela vraiment mord, c’est le traitement d’images et de PDF. Un worker qui appelle un conteneur avec ImageMagick économise un saut vers un Lambda ou un service de rendu plus son démarrage à froid. De même pour les charges de travail de navigateur sans tête : Playwright dans un conteneur à côté du worker fournit des captures d’écran en 700 à 1 200 ms de latence totale, là où le détour par un point de terminaison Browserless externe prend souvent le double.
Ce que les conteneurs ne remplacent pas, ce sont les services à longue durée de vie avec leur propre état. Une instance Postgres appartient toujours à une plateforme de base de données, un courtier Kafka sur une machine virtuelle. Les conteneurs sont éphémères, sont arrêtés en cas d’inactivité et redémarrent à froid. Qui n’a pas cela en tête construit des architectures qui surprennent sur la facture de fin de mois.
Workers, conteneurs, EC2 : quoi, quand
Quand les conteneurs sont adaptés
- Navigateurs sans tête, Pandoc, ffmpeg, Tesseract à côté d’un worker
- Petits points de terminaison d’inférence qui ne rentrent pas dans une fonction AI de worker
- Outils CLI qui ont besoin d’un Linux complet
- Charges de travail en rafale avec de longues phases d’inactivité, grâce à la tarification Active-CPU
Quand pas
- Bases de données ou autres services à longue durée de vie avec état local
- Charges de travail qui ont besoin de garanties de région fixe (conformité)
- Inférence GPU pour les grands modèles, ici restent les travailleurs AI ou un hyperscaler
- Stacks existants qui fonctionnent déjà sur Kubernetes et sont consolidés
Un plan de 60 jours pour les équipes DACH
Pour examiner sérieusement la pile technologique, il ne faut pas commencer par une migration, mais plutôt par une charge de travail spécifique qui cause des problèmes aujourd’hui.
Foire aux questions
Ai-je besoin d'un plan Cloudflare payant pour les conteneurs ?
Oui, les conteneurs fonctionnent sur le plan Workers Paid, qui démarre à 5 $ par mois. La tarification Active-CPU s'ajoute à cela, facturée avec précision à la seconde. Pour de simples tests, le plan Paid suffit, mais pour des configurations productives avec une charge élevée, Workers Enterprise est plus intéressant en raison de meilleures limites et de garanties de support.
Puis-je utiliser directement mes images Docker existantes ?
Dans la plupart des cas, oui. Cloudflare prend en charge les pulls Docker Hub et les registres privés, des tailles d'images allant jusqu'à plusieurs gigaoctets sont possibles. Ce qui ne fonctionne pas sont les images qui reposent sur le mode privilégié ou sur des modules de noyau spécifiques et les charges de travail avec des exigences GPU au-delà de ce que les conteneurs Cloudflare offrent aujourd'hui.
Quel est le comportement de la pile en termes de RGPD et de résidence des données ?
Cloudflare propose des options de régionalité, permettant d'héberger les conteneurs dans des sites de l'UE. Pour ceux qui ont besoin d'une résidence de données stricte (secteur public, banques), il est recommandé de vérifier la configuration Enterprise et d'obtenir une confirmation écrite. Les configurations standard sont généralement hébergées à Francfort ou à Amsterdam, ce qui suffit pour la plupart des charges de travail DACH.
À propos de l'auteur
Adrian Garcia-Kunz est développeur Web chez Evernine. Il vient de la pile Frontend, mais connaît le moment où un worker ou une Lambda ne suffit plus. Il est sceptique envers les modes et apprécie les outils qui seront encore fonctionnels dans six mois.
Plus de contenu du réseau MBF Media
Source de l'image de titre : Générée par IA avec Google Imagen 4 Fast, vérifiée SynthID
