Sergey - stock.adobe.com
Développement agentique : Cloudflare muscle sa panoplie d’outils
Face à l’émergence de l’IA agentique, Cloudflare adapte son offre cloud en s’appuyant sur ses primitifs existants, notamment les Workers. Reste à voir s’il ne sera pas pris de court par AWS, GCP, Anthropic et les autres.
Le spécialiste du CDN alimente son offre de services managés serverless et agentiques rassemblés sous la marque ombrelle Cloudflare Agent Cloud.
Il a commencé il y a deux semaines, en présentant les évolutions des Workers. Lancés il y a huit ans, les Workers sont des « isolats » du moteur JavaScript V8 (celui qui propulse Google Chrome). En clair, les Workers sont des instances V8 isolées. Cloudflare avait opté en faveur de ce moteur pour sa rapidité d’exécution et de démarrage par rapport aux conteneurs. Dans ce mode, le fournisseur maintient le serveur, l’OS, les runtime JavaScript, WebAssembly et Python ainsi que les packages. Les développeurs n’ont qu’à y déployer leur code applicatif.
Persister le code ou ne pas le persister, telle est la question
C’est sur ce primitif que s’appuient les Dynamic Workers. Ceux-là permettent d’exécuter en parallèle des environnements isolés contenant des portions de code générées par des agents IA. Il s’agit là de remplacer les appels aux outils par les LLM ou de multiplier les tests de Vibe Coding.
« L’exécution de chaque agent dans son propre conteneur est suffisamment coûteuse pour que les outils basés sur les agents se limitent aujourd’hui principalement aux assistants de programmation destinés aux ingénieurs capables d’en justifier le coût », prétendent les porte-parole de Cloudflare. « Les isolats, dont l’efficacité s’avère bien supérieure, permettent de rendre la rentabilité unitaire viable à l’échelle requise par les agents IA ».
Toutefois, ici, « le code est à usage unique : il est conçu pour effectuer une seule tâche une seule fois, puis est supprimé immédiatement après son exécution », précisent les ingénieurs de Cloudflare.
Justement, cela ne pourrait convenir à tous les besoins. Cette semaine, le fournisseur a présenté en bêta publique les « Durable Objects Facets ».
« Un objet durable est un type particulier de Worker doté d’un nom unique, avec une seule instance par nom à l’échelle du système », décrit-il. « Cette instance est associée à une base de données SQLite, qui réside sur le disque local de la machine sur laquelle l’objet durable s’exécute ». De ce fait, la latence d’accès au stockage est quasi nulle.
Or les objets durables n’ont pas été conçus pour l’avènement des Dynamic Workers. Ils sont provisionnés à travers une API et doivent pointer vers une classe d’implémentation. Autrement dit, ils sont figés dès leur création et ne peuvent pas charger de code à la volée. S’ils pointaient vers des Dynamic Workers, il n’y a pas par défaut de moyens de contrôle d’accès et de volume de stockage.
Les facettes doivent résoudre ce problème en s’appuyant sur une architecture à deux niveaux. Pour ce faire, il convient de configurer un objet durable « classique » qui joue le rôle de superviseur. Il peut charger et instancier une classe Durable Object définie dans un Dynamic Worker. Une fois cela fait, le code dynamique devient une facette, un enfant de la classe Durable Object de supervision.
« La facette dispose de sa propre base de données SQLite, qu’elle peut utiliser via les API de stockage normales de Durable Object. Cette base de données est distincte de celle du superviseur, mais les deux sont stockées ensemble dans le cadre du même Durable Object global », précise Kenton Varda, ingénieur principal chez Cloudflare.
Il s’agit d’assurer un contrôle strict de ce que peut « faire » le code généré et exécuté de manière dynamique, selon le fournisseur. Chaque application agentique a, dès lors, sa propre base de données.
La sandbox conteneurisée n’a pas dit son dernier mot
Cloudflare annonce également la disponibilité générale de ses sandbox. Là encore, il s’agit d’exécuter du code dans des environnements isolés, mais cette fois-ci en s’appuyant sur Docker et Linux. « Une sandbox se présente sous la forme d’un environnement Linux persistant et isolé disposant d’un shell, d’un système de fichiers et de processus en arrière-plan », indique le communiqué de presse de Cloudflare. « Un agent peut y cloner un référentiel, installer des packages Python, lancer des versions exécutables et itérer en s’appuyant sur la même boucle de rétroaction que celle qu’un développeur humain utilise ».
En clair, ces bacs à sable sont plus adaptés au bout de code non JavaScript. Si les workers peuvent exécuter des éléments de Python et de WebAssembly, ils ne prennent pas en charge des notebooks entiers ou des portions d’applications WASM. De plus, Cloudflare gère l’authentification au niveau du réseau pour éviter l’exposition des secrets et mots de passe aux agents IA.
Les sandbox s’exécutent dans des conteneurs Cloudflare et sont facturées à la consommation de mémoire, de CPU et d’espace disque, mesurée toutes les 10 millisecondes. Pour l’instant, il y a une limite de 40 Go et 40 vCPU. Mais les clients du fournisseur réclameraient de faire sauter cette limite. Difficile de savoir si les prix présentés sont intéressants ou non. Le fournisseur ne s’attarde pas sur les charges de travail typiques. En novembre 2025, Cloudflare a changé son modèle économique des ressources CPU dédiées aux conteneurs et aux sandbox. Au lieu de facturer la capacité allouée, il facture l’usage actif. Cela ferait chuter le coût de calcul, mais la mémoire et le stockage sont encore soumis au précédent régime.
Artifacts : une réponse aux limites des gestionnaires de dépôts de code
Cloudflare a également dévoilé Artifacts, une « primitive de stockage compatible Git ». Il s’agit de dupliquer des dépôts de code issu de n’importe quel client Git standard (dont GitHub et GitLab), afin d’en confier l’accès aux agents IA. Le fournisseur n’a pas précisé l’architecture technique d’Artifacts ni son modèle économique.
Si Cloudflare se contente d’annoncer cette couche de stockage, il s’agit sans aucun doute d’une réponse aux récentes pannes de GitHub. La filiale de Microsoft, en pleine migration vers Azure, doit maintenant faire face à des pics de charge provoqués par la création de dépôts par et pour les agents IA. GitHub a évoqué quatre incidents majeurs en mars. Reste à voir quelle forme prendra cette couche de stockage, à quel prix elle sera proposée et si les éditeurs de systèmes de contrôle de version logiciel proposeront leurs propres solutions d’intermédiation.
En attendant, Cloudflare s’attend à une cohabitation durable de l’ancien et du Nouveau Monde. « Les agents de programmation ont vraiment besoin d’environnements : un système de fichiers, Git, Bash, la possibilité d’exécuter des binaires. Cela ne changera pas ».
Un framework agentique qui doit encore se distinguer
Il promeut aussi son kit de développement agentique TypeScript/JavaScript (nommé « Agents SDK ») et sa fonctionnalité Think. Celle-ci permet d’appeler des modèles OpenAI, Google ou Anthropic à travers les protocoles Websockets et SSE pour exécuter des tâches durant plusieurs heures. Il s’agit par ailleurs d’intégrer des options de persistance pour les agents IA. AWS a également intégré une fonctionnalité similaire à travers son framework Agentcore. Les autres fournisseurs cloud (GCP, Oracle, Azure), ainsi que les entraîneurs de LLM (Anthropic, OpenAI, MistralAI) s’y intéressent également. Il faut aussi compter sur les frameworks open source – LangChain, CrewAI, etc. –, déjà populaires au sein des grands groupes.
Enfin, Cloudflare rappelle qu’il a acquis Replicate en novembre dernier, le porteur d’un catalogue d’environ 50 000 LLM, et de modèles de diffusion. Il s’agit d’appeler non seulement les API des grands fournisseurs OpenAI, Anthropic et Google, mais également d’étendre les déploiements aux modèles open weight. Y compris ceux fine-tunés par les entreprises.
