Cloudflare a ouvert une nouvelle ligne de front dans la course à l’infrastructure pour agents IA. Le 3 août 2026, l’entreprise a publié en avant-première @cloudflare/computer, un runtime open source qui donne à chaque agent son propre « ordinateur » : un système de fichiers persistant couplé à plusieurs environnements d’exécution interchangeables. L’annonce est tombée en pleine Agents Week, la deuxième organisée par Cloudflare en quatre mois, et elle rebat les cartes d’un marché où AWS, Microsoft et Google misent depuis des mois sur des architectures à base de conteneurs.
Derrière ce nom presque anodin se cache un pari technique clair : les conteneurs, jugés trop lents et trop coûteux à instancier pour chaque tâche d’un agent, ne seraient pas la bonne brique de base pour l’informatique agentique. Cloudflare mise à la place sur ses isolates V8, la technologie qui fait tourner Cloudflare Workers depuis 2018, combinés ponctuellement à des conteneurs Linux complets quand la tâche l’exige. Le résultat, encore en préversion et explicitement non prêt pour la production, ouvre déjà un débat dans la communauté développeurs sur l’avenir du calcul serverless face à la déferlante des agents autonomes.
Qu’est-ce que Cloudflare Computer concrètement ?
Cloudflare Computer répond à un problème précis : un agent IA qui exécute des tâches successives (lire un fichier, lancer un script, installer une dépendance, relire le résultat) a besoin d’un état persistant. Avec une fonction serverless classique, chaque invocation démarre de zéro. Cloudflare a donc construit un système de fichiers virtuel unique, sauvegardé dans une base SQLite, qui vit à l’intérieur d’un Durable Object, la brique de stockage à état de Cloudflare Workers. Ce système de fichiers reste accessible quel que soit le backend d’exécution choisi pour la commande en cours.
Le changelog officiel de Cloudflare décrit un runtime qui orchestre dynamiquement entre isolates rapides et conteneurs Linux complets, afin que l’agent tourne toujours sur la bonne primitive de calcul pour la tâche à accomplir. Concrètement, un agent peut lancer une commande shell légère dans un isolate en quelques millisecondes, puis basculer vers un conteneur complet pour une opération plus lourde, sans perdre l’accès aux fichiers déjà créés. C’est cette bascule à la demande, plutôt qu’un choix figé entre isolate ou conteneur, qui constitue l’argument central de Cloudflare.
Trois backends d’exécution pour un seul agent
Au lancement, le 3 août, Cloudflare Computer proposait deux backends : un backend conteneur, qui monte le système de fichiers virtuel via FUSE dans un environnement Linux complet, et un backend isolate shell, capable d’exécuter des commandes shell (via un outil interne baptisé just-bash) directement dans un isolate V8. Quatre jours plus tard, le 7 août, un troisième backend a rejoint le dépôt public : un isolate JavaScript qui exécute des modules ECMAScript directement dans un Dynamic Worker, aux côtés des deux premiers.
Cette architecture à trois vitesses illustre la logique de Cloudflare : ne pas forcer l’agent à choisir un seul mode d’exécution en amont, mais laisser le modèle ou la plateforme décider, commande par commande, quel backend traiter. Un développeur installe le runtime via npm install @cloudflare/computer, l’intègre à une application Node.js, un Worker Cloudflare ou tout environnement serverless compatible, et laisse le contrôleur orchestrer la répartition des tâches.
npm install @cloudflare/computer
// L'agent choisit le backend par commande :
// isolate JS pour un script rapide, conteneur Linux
// pour une operation lourde, meme systeme de fichiers
const computer = new Computer({ durableObjectNamespace });
await computer.run("npm test", { backend: "container" });
await computer.run("format-output.js", { backend: "isolate" });Le projet est publié dans un monorepo public regroupant plusieurs paquets, dont @cloudflare/computer, @cloudflare/dofs (le système de fichiers sur Durable Object) et @cloudflare/computerd. Cloudflare a toutefois posé des garde-fous clairs : la politique de contribution refuse pour l’instant les pull requests non sollicitées, et les API sont explicitement qualifiées d’instables. Autrement dit, l’entreprise invite à expérimenter, pas à déployer en production.
Cloudflare OS, le banc d’essai grandeur nature
Ce qui distingue cette annonce d’un simple prototype de recherche, c’est son usage interne. Deux jours après la publication du runtime, le 5 août, Cloudflare a ouvert le code source de Cloudflare OS, son espace de travail IA interne, sous licence Apache 2.0. Cette version 2, réécrite entièrement sur Workers et Durable Objects, succède à une première mouture déployée en interne dès mai 2026. Selon Cloudflare, ce banc d’essai fait déjà tourner le runtime Cloudflare Computer en production pour des milliers d’employés de l’entreprise, bien avant que la version publique ne quitte le statut de préversion.
Cloudflare OS s’appuie sur une couche de contrôle d’accès par capacités baptisée Gatekeepers, conçue pour qu’un agent n’obtienne jamais de clé d’API permanente. C’est un choix de conception qui répond directement à l’une des critiques les plus fréquentes adressées aux agents autonomes : le risque qu’un identifiant volé ou détourné donne un accès large et durable aux systèmes de l’entreprise. Cloudflare affirme que ses employés interagissent avec des agents sans jamais leur confier de secrets à longue durée de vie.
Dynamic Workers et l’extension de l’Agent Cloud
Cloudflare Computer ne sort pas seul. L’entreprise l’a présenté comme une pièce d’un ensemble plus large qu’elle appelle son « Agent Cloud ». Dans un communiqué distinct, Cloudflare a détaillé Dynamic Workers, un runtime à base d’isolates conçu pour exécuter du code généré par une IA dans un environnement isolé, plus rapide et moins coûteux qu’un conteneur classique selon l’entreprise. Trois jours plus tôt, le 6 août, Cloudflare avait aussi lancé Kitesurf, un runtime de navigateur sans état pour agents IA, tournant lui aussi entièrement dans des isolates V8 sur Workers.
La cadence de ces annonces est en soi un signal. Cloudflare a organisé sa première Agents Week de l’année en avril 2026 et la seconde début août, soit un intervalle d’environ trois mois et demi entre les deux. Un tel rythme d’itération sur une seule et même couche technique, l’exécution d’agents, traduit une pression concurrentielle que l’entreprise ne cache pas : elle veut s’imposer comme la référence de l’exécution agentique avant que les hyperscalers ne verrouillent le marché avec leurs propres offres.
Le pari contre les conteneurs
Pour comprendre ce choix, il faut remonter à l’ADN de Cloudflare Workers. Contrairement à la quasi-totalité des plateformes cloud, Workers n’a jamais reposé sur des machines virtuelles ou des conteneurs pour isoler le code des clients. Depuis son lancement, la plateforme utilise des isolates V8, les mêmes mécanismes d’isolation qu’un navigateur utilise pour séparer les onglets, pour démarrer du code en quelques millisecondes plutôt qu’en centaines de millisecondes ou en secondes. Cloudflare a construit toute son activité serverless sur cette différence d’échelle.
L’analyse technique publiée par nerdleveltech.com autour de cette annonce résume la position de Cloudflare en une phrase : donner un conteneur dédié à chaque agent ne tiendra pas la charge. L’argument est arithmétique autant que technique. Si un agent multiplie les appels, les allers-retours et les tâches parallèles, chaque conteneur instancié ajoute un coût fixe de démarrage et de mémoire. Un isolate, lui, coûte une fraction de cette empreinte, et Cloudflare parie que la majorité des tâches d’un agent peuvent y tourner sans jamais toucher à un conteneur.
Face à AWS, Azure et Google : quatre approches de l’agent cloud
Cloudflare Computer n’arrive pas en terrain vierge. Amazon a été le premier grand fournisseur à livrer une plateforme dédiée à l’exécution d’agents en production : Amazon Bedrock AgentCore a atteint la disponibilité générale le 13 octobre 2025. Il couvre tout le cycle de vie d’un agent (environnement d’exécution, isolation par session, mémoire, connexion à des outils, gestion des identités) via des micro-VM facturées à la consommation, avec un tarif de 0,0895 dollar par heure de vCPU et 0,00945 dollar par heure de Go de mémoire selon la page tarifaire officielle d’AWS.
Microsoft propose de son côté Azure AI Foundry, qui intègre des capacités d’orchestration d’agents adossées à Azure OpenAI Service et aux outils de recherche vectorielle du cloud Azure. Google avance avec Vertex AI Agent Builder, qui connecte les agents à BigQuery, à Google Search et aux capacités multimodales de Gemini. Dans les trois cas, la brique d’exécution reste construite sur des conteneurs ou des machines virtuelles gérées par le fournisseur, avec une facturation propriétaire et aucune option d’auto-hébergement comparable à ce que propose Cloudflare.
C’est là que se joue la vraie différence. AWS, Azure et Google vendent des services d’agents managés, fermés, avec une tarification détaillée par composant. Cloudflare, lui, publie un runtime open source que n’importe quelle organisation peut inspecter, modifier et faire tourner sur sa propre infrastructure Cloudflare, sans devoir souscrire à un produit d’agent dédié. La facturation reste indirecte : ce sont les briques sous-jacentes, Workers, Durable Objects et AI Gateway, qui sont facturées, pas le runtime d’agent lui-même.
Tableau comparatif des runtimes d’agents IA cloud
| Fournisseur | Primitive d’isolation | Modèle économique | Persistance d’état | Statut (septembre 2026) |
|---|---|---|---|---|
| Cloudflare Computer | Isolates V8 + conteneurs Linux (choix par commande) | Open source, facturation via l’infra Cloudflare sous-jacente | Système de fichiers SQLite dans un Durable Object | Préversion, non prêt pour la production |
| AWS Bedrock AgentCore | Micro-VM managées | Consommation : 0,0895 $/vCPU-h, 0,00945 $/Go-h | Mémoire courte et longue durée intégrée | Disponible en production depuis le 13/10/2025 |
| Azure AI Foundry Agent Service | Conteneurs / VM managés Azure | Propriétaire, lié à Azure OpenAI Service | Stockage Azure externe | Disponible, intégré à l’écosystème Azure |
| Google Vertex AI Agent Builder | Conteneurs / infrastructure Vertex AI | Propriétaire, lié à Vertex AI et BigQuery | Stockage Google Cloud externe | Disponible, intégré à l’écosystème Google Cloud |
Cloudflare en Bourse : la croissance portée par l’« internet agentique »
Ces annonces techniques arrivent trois jours avant un rendez-vous financier qui leur donne un tout autre relief. Le 6 août 2026, Cloudflare a publié ses résultats du deuxième trimestre : un chiffre d’affaires de 696,1 millions de dollars, en hausse de 36 % sur un an, contre 512,3 millions de dollars un an plus tôt. Le titre coté à New York sous le symbole NET a bondi d’environ 15 % dans la foulée de la publication, les analystes saluant une croissance supérieure aux attentes du marché. Les documents de présentation du trimestre attribuent explicitement une partie de cette dynamique à ce que l’entreprise appelle l’« internet agentique », la multiplication des applications et des agents automatisés qui consomment de la bande passante et du calcul sur le réseau Cloudflare.
Le calendrier n’est probablement pas un hasard. En lançant Cloudflare Computer, Dynamic Workers et Kitesurf la même semaine que ses résultats trimestriels, Cloudflare a construit un récit cohérent auprès des investisseurs : la demande liée aux agents IA n’est plus une hypothèse, elle se traduit déjà dans les chiffres. Reste que rien, dans les documents financiers publiés, ne permet d’isoler la part de croissance directement imputable à Cloudflare Computer, qui n’existait pas encore au moment de la clôture du trimestre concerné.
Un marché du serverless qui pèse déjà des dizaines de milliards
La bataille des runtimes d’agents s’inscrit dans un marché du calcul serverless déjà conséquent. Plusieurs cabinets d’études convergent sur un ordre de grandeur pour 2026, avec des écarts qui tiennent surtout au périmètre retenu. Ces chiffres restent des estimations de marché, à prendre comme des ordres de grandeur plutôt que des valeurs figées, mais leur convergence donne une idée du terrain sur lequel Cloudflare, AWS, Azure et Google se disputent des parts.
| Cabinet d’études | Taille du marché serverless en 2026 | Projection à long terme |
|---|---|---|
| Mordor Intelligence | 32,59 milliards de dollars | 91,56 milliards de dollars d’ici 2031 (CAGR 22,94 %) |
| Fact.MR | 31,56 milliards de dollars | 104,31 milliards de dollars d’ici 2036 (CAGR 12,7 %) |
| VyanS Intelligence | 29,61 milliards de dollars | Base 2025 : 24,7 milliards de dollars |
| Coherent Market Insights | 28,30 milliards de dollars | 67,41 milliards de dollars d’ici 2033 (CAGR 13,2 %) |
Ce socle de plusieurs dizaines de milliards de dollars explique pourquoi aucun grand fournisseur ne peut se permettre de laisser Cloudflare définir seul la couche d’exécution des agents. Chaque euro dépensé dans un runtime d’agent, qu’il s’agisse d’un conteneur AWS ou d’un isolate Cloudflare, alimente une portion de ce marché du serverless au sens large, désormais tiré autant par les applications web classiques que par les charges de travail agentiques.
Open source, mais loin d’être prêt pour la production
La prudence affichée par Cloudflare mérite d’être prise au sérieux. Le runtime porte l’étiquette « early preview » à chaque page de documentation, les API changent sans garantie de compatibilité ascendante, et l’équipe a explicitement fermé la porte aux contributions externes non sollicitées le temps de stabiliser l’architecture. Pour une entreprise qui gère une part significative du trafic web mondial, ce choix traduit une volonté de ne pas répéter les erreurs classiques d’un lancement précipité sur une brique aussi sensible que l’exécution de code pour des agents autonomes.
Cette prudence contraste avec l’usage interne massif du même runtime chez Cloudflare, où il fait tourner Cloudflare OS pour des milliers d’employés. L’écart entre le statut affiché en externe et l’ampleur de l’usage en interne est révélateur d’une stratégie assez commune dans la tech : valider une architecture à grande échelle en conditions réelles avant d’en ouvrir l’accès public sans filet.
Sécurité et gouvernance : le vrai enjeu des agents persistants
Donner à un agent un système de fichiers permanent change la donne en matière de sécurité. Une fonction serverless classique disparaît après son exécution, ce qui limite mécaniquement la fenêtre d’exposition en cas de compromission. Un agent doté d’un « ordinateur » persistant conserve, lui, un état entre les sessions : des fichiers, des scripts, potentiellement des traces d’informations sensibles manipulées lors d’une tâche précédente.
La réponse de Cloudflare passe par la couche Gatekeepers déployée dans Cloudflare OS et par le choix de ne jamais distribuer de clés d’API à durée de vie longue aux agents. Dynamic Workers ajoute une couche supplémentaire en exécutant le code généré par un modèle dans un environnement isolé plutôt que directement dans le contexte de l’agent principal. Ces mécanismes répondent à une préoccupation croissante des équipes de sécurité en Europe, où le RGPD impose une traçabilité stricte des accès aux données personnelles, y compris lorsque ces accès sont initiés par un agent logiciel plutôt que par un humain.
Ce que ça change pour les développeurs et les entreprises européennes
Pour une PME ou une ETI française qui expérimente des agents IA internes, l’intérêt de Cloudflare Computer tient moins à la préversion elle-même qu’à la trajectoire qu’elle dessine. La possibilité d’auto-héberger un runtime d’agent complet, sans dépendre d’un service managé propriétaire facturé à la ligne, correspond à une préoccupation régulièrement exprimée par les directions informatiques européennes soucieuses de maîtriser où et comment tourne leur code, alors même que le débat sur la souveraineté cloud continue d’agiter Bruxelles.
Cloudflare opère des centres de données dans plusieurs pays européens, ce qui permet en théorie d’exécuter Cloudflare Computer avec des données qui ne quittent jamais l’Union européenne, à condition de configurer correctement le placement des Durable Objects. Reste que le statut de préversion interdit pour l’instant tout déploiement en production, ce qui laisse aux équipes techniques une fenêtre pour expérimenter et remonter des retours plutôt que pour bâtir des services critiques.
Prédictions : où va la course aux runtimes d’agents d’ici 2027
Plusieurs trajectoires se dessinent à partir des éléments connus aujourd’hui, sans certitude sur leur calendrier exact.
- Une sortie de préversion vers une disponibilité générale de Cloudflare Computer prendra probablement plusieurs trimestres, si l’on se fie au rythme observé sur d’autres briques Workers passées de la préversion à la production.
- AWS, Microsoft et Google devraient répondre par des offres hybrides mêlant isolates légers et conteneurs, plutôt que de miser uniquement sur l’un ou l’autre modèle, pour ne pas céder l’argument de la latence à Cloudflare.
- L’absence de tarification dédiée pour Cloudflare Computer restera un frein à l’adoption en entreprise tant que les équipes financières ne pourront pas estimer précisément un coût par agent, contrairement à la grille détaillée déjà publiée par AWS pour AgentCore.
- Le rythme de deux Agents Week en quatre mois laisse présager une cadence d’itération proche du trimestre pour les prochaines briques de l’Agent Cloud de Cloudflare, plutôt qu’un rythme annuel classique.
- La question de la gouvernance des agents persistants, aujourd’hui traitée via Gatekeepers chez Cloudflare, devrait devenir un critère de sélection à part entière pour les entreprises européennes, au même titre que le prix ou la latence.
Foire aux questions
Qu’est-ce que Cloudflare Computer exactement ?
C’est un runtime open source publié en préversion par Cloudflare le 3 août 2026, qui donne à chaque agent IA un système de fichiers persistant et plusieurs environnements d’exécution interchangeables (isolates V8 et conteneurs Linux), plutôt qu’une fonction serverless éphémère et sans état.
Cloudflare Computer est-il déjà utilisable en production ?
Non. Cloudflare qualifie le projet d’« early preview », avec des API instables et une politique de contribution restreinte. L’entreprise déconseille explicitement tout déploiement en production à ce stade.
Combien coûte Cloudflare Computer ?
Le runtime lui-même est open source et gratuit à installer. Il n’existe pas de tarification dédiée publiée à ce jour : le coût réel dépend de la consommation des briques Cloudflare sous-jacentes utilisées (Workers, Durable Objects, AI Gateway).
En quoi Cloudflare Computer diffère-t-il d’AWS Lambda ?
AWS Lambda exécute des invocations sans état, initialisées à chaque appel, avec une persistance gérée séparément via des services comme DynamoDB ou S3. Cloudflare Computer intègre au contraire un système de fichiers persistant directement dans le runtime, partagé entre tous les backends d’exécution d’un même agent.
Cloudflare Computer est-il réellement open source ?
Oui. Le code est publié dans un monorepo public incluant les paquets @cloudflare/computer, @cloudflare/dofs et @cloudflare/computerd, installables via npm. La politique de contribution reste toutefois fermée aux pull requests non sollicitées pendant la phase de préversion.
Quel est le lien entre Cloudflare Computer et Cloudflare OS ?
Cloudflare OS est l’espace de travail IA interne de Cloudflare, ouvert en open source le 5 août 2026. Il utilise Cloudflare Computer comme runtime d’exécution pour les agents utilisés en interne par les employés de l’entreprise, ce qui en fait le principal déploiement à grande échelle du runtime à ce jour.
Les entreprises françaises peuvent-elles utiliser Cloudflare Computer dès maintenant ?
Techniquement, oui, pour de l’expérimentation, puisque le runtime est public et installable via npm. Le statut de préversion et l’absence de garanties de stabilité déconseillent en revanche tout usage en production tant que Cloudflare n’aura pas annoncé de disponibilité générale.
Quels risques de sécurité pose un agent IA doté d’une mémoire persistante ?
Le principal risque tient à l’élargissement de la fenêtre d’exposition : un agent qui conserve un état entre les sessions peut aussi conserver des données sensibles plus longtemps qu’une fonction serverless classique. Cloudflare répond à cette préoccupation avec sa couche de contrôle d’accès Gatekeepers et l’absence de clés d’API à longue durée de vie distribuées aux agents.
