Cloudflare OS : un énième environnement de travail agentique ?

Chose promise, chose due : Cloudflare OS est désormais open source.

Cette plate-forme fusionne plusieurs projets internes. Ayant pour principal substrat le service Cloudflare Workers (fonctions sans serveur), elle est présentée comme un « successeur spirituel » de Sandstorm.

De Sandstorm à Cloudflare OS, plus qu’un air de famille

Sandstorm avait émergé en 2014. Il s’agissait d’un serveur d’hébergement d’applications web. Le projet se distinguait par son niveau de granularité : chaque document avait son conteneur. Il s’est cependant heurté aux limites techniques des infrastructures d’alors (démarrage à froid, consommation de mémoire…). La start-up qui le portait n’a, plus globalement, pas réussi à développer son modèle économique, fondé sur la fourniture de fonctionnalités d’entreprise. Début 2017, elle avait transmis Sandstorm à la communauté. Son équipe avait ensuite rejoint Cloudflare. Et s’était mise à travailler sur ce qui deviendrait Cloudflare Workers.

Les unités fonctionnelles de Sandstorm étaient appelées « Grains ». Avec Cloudflare OS, elles deviennent « Gadgets »... et abandonnent les conteneurs à la faveur d'un mécanisme d'isolation plus léger basé sur le moteur JavaScript V8.

Kenton Varda, cofondateur de Sandstorm et aujourd'hui tech lead de Cloudflare Workers, en avait fait une démonstration fin juin à l'AI Engineer World's Fair. L'initiative ne s'appelait pas encore officiellement Cloudflare OS. Mais elle était, selon lui, devenue « suffisamment sérieuse » en interne pour ne pas la verser immédiatement en open source - alors qu'il l'avait promis au moment de proposer son talk.

L'angle « indie » : permettre à chacun de modifier ses applications

« Cet environnement, il faut le voir comme une suite bureautique », avait expliqué Kenton Varda. Sauf qu'au lieu des documents, il y a des applications : les fameux Gadgets. La logique de partage de ces apps - et de contrôle des accès - est implémentée au niveau de la plate-forme. Pour chacune, le code client tourne dans un iframe qui n'a qu'un canal de communication : du POST vers le cadre parent. La liaison avec le code serveur - instancié sous forme d'objet durable avec sa base SQLite - se fait via une session RPC basée sur le système Cap'n Web, autre brique open source de Cloudflare.

Le runtime workerd sous-jacent étant lui aussi ouvert, il est possible d'exploiter l'ensemble en local, avait affirmé Kenton Varda. L'intéressé avait aussi abordé les possibilités que le modèle de sécurité offrait en matière de vibe coding. Ou plus précisément de personnalisation des applications directement par les utilisateurs, chacun exécutant sa propre copie de l'application. Il en avait donné une illustration en ajoutant, grâce à Claude, la gestion des diagrammes SVG arbitraires et du centrage de texte dans un outil de génération de diapositives.

L'angle B2B : codifier les workflows dans un système agentique

Kenton Varda n'avait pas abordé en long un autre aspect : la connexion de ces applications à des services externes. Cloudflare le fait, désormais qu'il a ouvert la plate-forme. C'en est, en quelque sorte, une v2. La première mouture avait été lancée en interne au mois de mai. Elle permettait d'exécuter, via une UI web, des workflows codifiés sous forme de skills. Ces dernières avaient été développées au préalable, sur la base d'une cartographie des tâches que les employés souhaitaient automatiser. Les résultats s'affichaient dans un panneau latéral au sein du navigateur, sans interaction avec le reste de l'environnement local.

Cloudflare a, dans un deuxième temps, entrepris la connexion à ses autres systèmes. Pour la plupart, il a construit sa propre implémentation de serveur MCP. Il a ainsi pu ajouter des couches de contrôle, comme une limitation du débit par rôle et par région. Une grande partie des flux de travail étant déterministes, il a fini par mettre en place un mécanisme d'inférence à la demande (basé sur son AI Gateway) évitant de réexécuter une skill à chaque session.

Vers une « usine à connecteurs » pour Cloudflare OS

Dans la terminologie de Cloudflare OS, ces serveurs MCP ad hoc sont des « contrôleurs d'accès » (Gatekeepers). Ils comprennent la logique de chaque service et assurent la mise en œuvre des politiques de sécurité lorsque des ressources sont partagées. Il peut s'agir des applications elles-mêmes (avec base de données, historique de conversation, authentifiants, etc.) ou de blueprints (code uniquement).

Les Gatekeepers sont capables de « simuler » le résultat d'actions. On peut ainsi les valider par lots en bout de chaîne, sans que l'agent interrompe son travail à chaque étape.

Cloudflare travaille sur une forme d'« usine logicielle » qui produira des Gatekeepers à partir de documentations API. Il en existe actuellement pour, entre autres, Confluence, GitHub, Google (Gmail, Docs, Sheets, Agenda, BigQuery), Home Assistant, Linear, Notion, Slack, Spotify, Supabase et ZoomInfo. Cloudflare y ajoute un modèle d'implémentation « prêt à l'emploi ». Il permet d'exploiter une version épinglée sans modifier le code source, mais en ayant la main sur les identités, le routage, les intégrations, l'inférence, l'observabilité et le branding.

I paired Cloudflare OS with self hosted deepseek-v4-flash and the result is freakin amazing

Imagine running this setup inside DGX spark, you get fully private work companion solving all your work stuff

The thing about this type of software is it already have a good harness and… https://t.co/gvYHGQnlFe pic.twitter.com/ujcFVAbdbX

— Farhan Helmy (@farhanhelmycode) August 5, 2026

Illustration principale générée par IA