Cloudflare a publié le Cloudflare OS en open source, une plateforme que la société définit comme un « système d’exploitation » pour la productivité avec intelligence artificielle. Le nom peut prêter à confusion : il ne s’agit pas de concurrencer Linux, Windows ou macOS. Son objectif est de fournir un environnement où les employés et agents IA peuvent créer des applications, consulter des ressources d’entreprise et exécuter des actions sous un modèle d’isolation, avec des permissions spécifiques et une validation humaine. Cloudflare affirme que de nombreux membres de son équipe utilisent déjà cette technologie en interne.

Les points clés de Cloudflare OS en 20 secondes

• Cloudflare a publié le code d’une plateforme IA initialement conçue pour un usage interne.
• Les utilisateurs peuvent demander à des agents de créer de petites applications, appelées Gadgets.
• Les Gatekeepers limitent les ressources externes auxquelles chaque application ou agent peut accéder.
• Les actions sensibles peuvent nécessiter une validation humaine préalable.
• Cloudflare OS v2 reste en early access, avec certaines parties de son déploiement autonome encore non documentées.

Ce concept est particulièrement intéressant car il aborde un problème clé : celui des agents IA qui dépassent la simple réponse à des questions. Un chatbot générant du texte présente un risque contrôlable. En revanche, un agent capable de lire des dépôts, de modifier des documents, de consulter des applications internes ou d’exécuter des actions requiert un système de permissions beaucoup plus précis.

Cloudflare OS construit cet environnement autour de trois composants principaux : Agent Workspaces, Gadgets et Gatekeepers. La ressemblance avec un système d’exploitation vient précisément de cette séparation entre utilisateurs, applications, ressources et permissions.

Gadgets : petites applications que l’IA peut créer et modifier

L’un des concepts les plus particuliers de Cloudflare OS est celui des Gadgets.

Ce modèle s’éloigne du paradigme traditionnel du logiciel en tant que service (SaaS), où une application centralisée est utilisée par des milliers d’utilisateurs simultanément.

Dans Cloudflare OS, chaque utilisateur peut disposer de sa propre instance d’une application.

Par exemple, quelqu’un peut demander :

Create a collaborative whiteboard app.

L’agent génère alors le Gadget correspondant, et cette application s’exécute dans son propre environnement isolé.

Il est également possible de demander :

Make slides for my upcoming meeting with a customer.

Dans ce cas, Cloudflare OS utilise l’un de ses Blueprints, des modèles qui contiennent non seulement des informations mais aussi le code complet d’une application.

La différence apparaît quand l’utilisateur souhaite quelque chose que l’application ne réalise pas encore. Plutôt que de contacter un développeur, il peut demander à l’agent de modifier son propre code.

Cloudflare considère que l’IA peut rendre viable un modèle où chaque employé dispose de versions personnalisées d’outils relativement légers.

L’architecture vise à éviter que cette liberté devienne un problème de sécurité.

Chaque Gadget s’exécute dans un sandbox indépendant. Le code serveur fonctionne via un Dynamic Worker sans accès direct et général à Internet. Pour accéder à des services externes, il faut explicitement des ressources autorisées.

Le client s’exécute également dans un iframe isolé, avec des restrictions via Content Security Policy et les capacités de sandbox du navigateur.

Le concept repose sur une règle simple : une application créée récemment n’a pas automatiquement accès aux systèmes de l’entreprise.

Ce comportement est particulièrement pertinent si le code a été généré automatiquement par un modèle.

Gatekeepers : permissions spécifiques pour agents et applications

La deuxième pièce est constituée des Gatekeepers.

Cloudflare les compare à des serveurs Model Context Protocol (MCP) plus contrôlés. Leur rôle est de faire le lien entre l’agent ou le Gadget et les services externes.

Lorsque l’utilisateur souhaite autoriser un agent à travailler, par exemple sur un dépôt précis, l’accès se fait via un Gatekeeper.

Ce composant assure plusieurs fonctions :

• authentification et autorisation, y compris OAuth le cas échéant ;
• limitation de l’accès à la ressource spécifique autorisée par l’utilisateur ;
• enregistrement des opérations effectuées ;
• fourniture d’une API à l’agent ;
• demande d’approbation humaine pour des actions ayant des effets externes.

Ce dernier point est l’un des aspects les plus innovants du projet d’un point de vue technique.

Les systèmes d’agents rencontrent souvent le problème de l’attente d’une validation humaine. Si l’agent tente d’exécuter une opération sensible, il peut rester bloqué en attendant que quelqu’un clique sur « approuver ».

Cela fonctionne lorsque l’utilisateur est devant l’écran. Mais devient problématique si l’on souhaite laisser l’agent travailler pendant plusieurs minutes.

Cloudflare propose une approche différente :

Le Gatekeeper peut simuler localement le résultat d’une action en attente d’autorisation. L’agent reçoit une réponse simulée et peut continuer à travailler en se basant sur cette hypothèse.

Si, par la suite, il doit vérifier le résultat, il reçoit à nouveau une réponse simulée.

Une fois le travail terminé, l’utilisateur peut réviser les opérations en attente et les approuver ou les rejeter individuellement ou en bloc.

Cela permet de distinguer deux étapes habituellement liées : la réflexion de l’agent et l’exécution effective des actions ayant des effets externes.

Cette approche ne supprime pas totalement le risque : si l’utilisateur accepte tous les opérations sans distinction, le contrôle perd une grande partie de son utilité. Mais elle évite qu’il soit nécessaire d’accorder des permissions permanentes ou de recourir à des options équivalentes à passer outre les validations.

Les agents ne devraient pas disposer de toutes les permissions de l’utilisateur

Cloudflare OS adopte également un modèle de sécurité basé sur les capacités.

Chaque agent et chaque Gadget commence sans accès aux ressources externes.

Même si l’organisation a configuré des intégrations d’entreprise, ces identifiants ne sont pas automatiquement disponibles pour toutes les conversations.

L’utilisateur doit « présenter » explicitement la ressource à l’agent.

Par exemple, en fournissant le lien vers un dépôt précis. L’agent reçoit alors cet accès via le Gatekeeper correspondant, au lieu d’hériter de permissions globales sur tous les dépôts accessibles à l’utilisateur.

Ce modèle s’efforce d’appliquer le principe du moindre privilège.

La différence est significative comparée à des configurations où un serveur MCP est ajouté globalement à l’environnement et où tous les outils sont disponibles lors de n’importe quelle session.

Cloudflare souligne qu’un agent ne doit pas être considéré simplement comme un autre utilisateur. Il doit agir sous la responsabilité d’une personne, mais avec ses permissions limitées.

Pour illustrer cette analogie avec un système d’exploitation classique, voici la correspondance proposée :

Bien que cette comparaison ait ses limites, elle permet de saisir pourquoi Cloudflare a choisi de parler d’OS.

Il ne s’agit pas de gérer la CPU, la mémoire ou les périphériques comme le fait Linux. Il s’agit de créer une couche qui relie personnes, agents, applications et ressources d’entreprise, en maintenant des frontières de sécurité entre eux.

Basé sur Workers, Durable Objects et workerd

Cloudflare OS exploite largement les technologies déjà présentes dans sa plateforme d’exécution.

Chaque espace de travail fonctionne comme un Durable Object. Les Gadgets utilisent des Dynamic Worker Facets, et les Gatekeepers s’intègrent également au workspace pour gérer l’accès aux ressources distantes.

Le projet utilise également Cap’n Web RPC pour la communication entre le client et le serveur des Gadgets.

Ce choix a une autre conséquence : les applications créées disposent d’une interface que les agents peuvent utiliser directement.

Un utilisateur peut commencer par demander :

Create an issue dashboard for this repository.

puis demander à l’agent de travailler avec l’application générée, sans devoir construire un serveur MCP spécifique.

Cloudflare appelle cette approche Code Mode. Elle consiste à générer de petits morceaux de code que l’agent exécute pour effectuer des tâches.

La plateforme n’est pas limitée à un seul fournisseur de modèles. Elle peut utiliser différents grands modèles de langage (LLM), y compris des modèles auto-hébergés, selon la configuration spécifique.

Déployable localement

Cloudflare a publié le projet avec ses instructions pour l’exécuter localement.

Après installation de pnpm, la procédure de base est :

pnpm run-local

L’interface est accessible par défaut à l’adresse :

http://localhost:8787

Ce mode utilise wrangler et workerd et vise principalement à tester le projet, pas à une installation de production. Les données locales sont stockées dans le répertoire .wrangler.

Il existe aussi une procédure pour déployer Cloudflare OS dans un compte Cloudflare.

Une nuance importante concerne l’indépendance de la plateforme.

Cloudflare explique que le fait d’être construit sur Workers ne signifie pas que Cloudflare OS doit obligatoirement fonctionner sur leur infrastructure. workerd, l’environnement d’exécution de Workers, est également open source et peut fonctionner sur des serveurs privés.

Cependant, au moment de la publication en août 2026, la documentation et les outils pour déployer Cloudflare OS avec workerd sur des serveurs personnels sont encore en développement, marqués comme « Coming Soon ».

Ainsi, cette option fait partie de l’architecture du projet, mais elle n’est pas encore aussi documentée que le déploiement via un compte Cloudflare.

Un projet ouvert, mais encore en early access

Cloudflare ne présente pas la version actuelle comme un produit fini.

La société parle de la version de août 2026 comme Cloudflare OS v2, une réécriture complète basée sur l’expérience de la première version.

Le dépôt la considère comme suffisamment fonctionnelle pour l’expérimenter, mais admet qu’elle comporte encore de nombreux points à améliorer, en utilisant explicitement le terme early access.

L’approche concernant les contributions externes est également intéressante :

Bien que le code soit open source, Cloudflare n’encourage pas actuellement les contributions massives extérieures. La société explique que l’IA a réduit le coût d’écriture du code, mais que la revue, la maintenance de la qualité et la cohérence du produit continuent d’exiger un travail humain.

Elle accepte toutefois les corrections mineures et facilement vérifiables, en recommandant d’utiliser les discussions du dépôt pour des propositions plus ambitieuses.

Au-delà du nom, la partie la plus intéressante de Cloudflare OS réside probablement dans le problème qu’il tente de résoudre.

Les entreprises passent progressivement de collaborateurs qui consultent des chatbots à des agents capables d’exécuter du code et d’intervenir sur les systèmes d’entreprise. Dans ce contexte, il ne suffit pas simplement de connecter un modèle à toutes les outils disponibles.

Il faut définir quels agents peuvent accéder à quels ressources, isoler le code généré, enregistrer leurs actions et déterminer quand une intervention humaine est nécessaire.

Cloudflare OS propose une architecture pour organiser ces relations. Bien qu’elle soit encore en développement et que plusieurs éléments continuent d’évoluer, ses Gadgets, Gatekeepers et le modèle de permissions offrent une orientation intéressante pour répondre à cette question cruciale : comment permettre aux agents d’effectuer un travail réel sans leur donner un contrôle total sur l’infrastructure.

Questions fréquemment posées

Qu’est-ce que Cloudflare OS ?

Cloudflare OS est un environnement open source destiné à travailler avec des agents IA, à créer de petites applications et à les connecter de manière contrôlée à des ressources d’entreprise. Malgré son nom, ce n’est pas un système d’exploitation traditionnel comme Linux ou Windows.

Que sont les Gadgets dans Cloudflare OS ?

Les Gadgets sont des applications individuelles que l’IA peut créer et modifier. Chaque instance s’exécute dans un environnement isolé et n’a pas d’accès général à Internet ou aux ressources de l’entreprise par défaut.

À quoi servent les Gatekeepers ?

Les Gatekeepers contrôlent la connexion entre les agents ou Gadgets et les services externes. Ils gèrent l’autorisation, limitent l’accès aux ressources, enregistrent les opérations et peuvent demander une validation humaine pour des actions avec des effets extérieurs.

Peut-on déployer Cloudflare OS sur ses propres serveurs ?

L’architecture permet d’utiliser workerd, l’environnement d’exécution open source de Workers, et le projet peut être testé localement. Cependant, au moment de la publication en août 2026, la documentation et les outils pour un déploiement en production sur ses propres serveurs restent en développement, et sont encore marqués comme « Coming Soon ».