Déployer des agents IA en entreprise soulève un dilemme récurrent : comment automatiser les tâches quotidiennes sans risquer des fuites de données ou perdre le contrôle des accès ? Initialement conçu pour les équipes internes de Cloudflare, de l’ingénierie aux ventes, Cloudflare OS apporte une réponse technique originale. Ce système transforme les interactions avec l’IA en micro-applications privées et sécurisées.
Voici 7 caractéristiques fondamentales à connaître sur ce projet open source, son architecture technique et ses méthodes de déploiement.
1. Une plateforme interne pensée pour devenir le système d’exploitation de votre entreprise
Cloudflare OS ne se présente pas comme un système d’exploitation d’ordinateur conventionnel. L’éditeur emploie le terme « operating system » selon deux axes précis :
- Un cadre de productivité d’entreprise : offrir un environnement où les collaborateurs utilisent l’IA en toute sécurité, sans inquiéter les équipes chargées de la sécurité informatique.
- Un gestionnaire de charges de travail IA : administrer les calculs et les contextes d’agents, de la même manière qu’un système traditionnel orchestre les processus système.
L’interface met à disposition un espace de dialogue avec des agents préchargés avec les connaissances opérationnelles de l’organisation. L’objectif avoué du passage en open source n’est pas d’imposer les méthodes de Cloudflare, mais de permettre à chaque structure de concevoir son propre environnement adapté.
2. Les « Gadgets » : l’abandon du modèle SaaS centralisé
Au lieu de s’en remettre à des applications tierces en ligne, Cloudflare OS repose sur des micro-applications personnelles appelées Gadgets. Lorsqu’un utilisateur demande par exemple la génération d’un diaporama, le système ne se connecte pas à un logiciel cloud partagé : il instancie une copie privée de l’application dédiée à cette tâche.
Cette approche bouleverse l’architecture cloud standard observée depuis 25 ans :
- Isolation totale : chaque instance fonctionne dans un bac à sable hermétique. Une faille de sécurité interne à l’application ne peut pas exposer les données à un tiers.
- Modification du code à la volée : si une fonctionnalité manque, l’utilisateur demande directement à l’agent de modifier le code de son instance. L’opération s’exécute sans danger pour les autres utilisateurs.
À l’image des fichiers d’une suite bureautique classique, chacun peut accumuler des milliers de gadgets, les créer instantanément et les conserver privés par défaut.
3. Les « Gatekeepers » : une sécurité par capacités avec simulation d’approbation
Pour relier un agent ou un gadget à un service externe (comme GitHub, Google, Slack ou Notion), le système déploie un composant dédié appelé Gatekeeper. Conçu comme une version avancée des serveurs MCP, chaque Gatekeeper enveloppe l’API cible via le protocole Cap’n Web, gère l’authentification OAuth, restreint l’accès aux seules ressources autorisées et enregistre l’ensemble des actions exécutées.
Ce mécanisme résout le principal défaut des architectures avec validation humaine synchrone :
Les systèmes traditionnels obligent l’agent à s’interrompre dans l’attente d’une validation humaine. Pour éviter ces blocages, les utilisateurs finissent souvent par activer des options dangereuses comme
--dangerously-skip-permissions.
Les Gatekeepers adoptent un fonctionnement asynchrone : lorsqu’une action requiert une autorisation, le Gatekeeper simule localement le résultat. L’agent reçoit une réponse fictive cohérente et poursuit sa chaîne de tâches. L’utilisateur peut ainsi vaquer à ses occupations, puis examiner et valider l’ensemble des actions en bloc ou individuellement au moment voulu.
4. Une analogie directe avec les composants d’un OS traditionnel
L’appellation Cloudflare OS ne relève pas d’une simple formule marketing : l’architecture technique reproduit point par point les strates d’un système informatique classique, tout en attribuant un statut inédit aux agents autonomes.
| Système d’exploitation standard | Cloudflare OS |
|---|---|
| Noyau (kernel) | packages/workshop-backend |
| Pilotes de périphériques | packages/gatekeeper-* |
| Interface / Shell | packages/workshop-frontend |
| Processus | Gadgets |
| Exécutables | Blueprints |
| Utilisateurs | Utilisateurs |
| Listes de contrôle d’accès (ACL) | Permissions partagées |
| Élément non géré nativement | Agents |
Dans ce schéma, les agents IA ne sont pas traités comme de simples utilisateurs humains. Responsables devant l’utilisateur qui les pilote, ils génèrent et exécutent des fragments de code en temps réel grâce à une sécurité régie par des capacités ciblées plutôt que par des listes de contrôle d’accès globales.
5. Des « Blueprints » réutilisables et une collaboration multijoueur native
Lorsqu’un gadget s’avère pertinent pour d’autres membres de l’équipe, son créateur peut publier un Blueprint. Ce modèle ne contient pas uniquement des données, mais l’intégralité du code applicatif. Les destinataires créent alors leur propre copie autonome, qu’ils peuvent adapter à leurs exigences sans solliciter le développeur initial.
Cette dynamique collaborative intègre deux briques essentielles :
- Le multijoueur en temps réel : chaque gadget repose sur un Durable Object, ce qui permet à plusieurs collaborateurs d’interagir simultanément sur un même document avec synchronisation instantanée. L’agent de codage génère cette logique par défaut.
- Des applications pilotables par l’IA : l’échange entre le client et le serveur d’un gadget s’effectue via des appels distants Cap’n Web RPC. Cette structure expose naturellement une interface directe que l’agent manipule en mode « Code Mode », lui permettant de travailler au sein même de l’application aux côtés de l’utilisateur.
L’agent polyvalent intégré prend en charge de multiples modèles de langage du marché ainsi que des modèles auto-hébergés, avec une consommation de jetons souvent réduite grâce à l’intégration directe de la plateforme.
6. Un confinement strict et un contrôle d’accès par présentations explicites
Le modèle de sécurité applique un principe de moindre privilège absolu. Contrairement aux configurations où les serveurs d’outils restent accessibles en permanence en arrière-plan, les gadgets et les agents démarrent sans aucun droit d’accès.
L’isolation repose sur une double barrière technique :
- Au niveau serveur : le code tourne dans un Dynamic Worker dont les accès directs à Internet sont coupés. Il ne peut dialoguer qu’avec des ressources explicitement attribuées par des liaisons déclarées (Workers Bindings).
- Au niveau client : l’interface s’exécute dans une iframe protégée par une politique de sécurité de contenu (CSP) stricte et les restrictions sandbox du navigateur. Ses communications avec le serveur transitent exclusivement via
postMessage().
Pour connecter un agent à un compte externe ou à un dépôt distant, l’utilisateur doit procéder à une « introduction » volontaire, par exemple en collant un lien ou en sélectionnant manuellement la ressource dans l’interface.
7. Une version 2 en accès anticipé et plusieurs options de déploiement
Le projet correspond actuellement à une réécriture intégrale (version 2) tirant les enseignements de la première mouture. Publiée en août 2026 sous forme d’accès anticipé (« early access »), la plateforme demeure fonctionnelle mais comporte des aspects encore en cours de stabilisation.
Plusieurs options permettent de tester et déployer l’environnement :
- En local : après avoir configuré pnpm, la commande
pnpm run-locallance l’ensemble des services surhttp://localhost:8787via Wrangler et le moteur d’exécution local. Les données sont conservées dans le dossier.wrangler(cet usage est réservé aux tests). Pour le développement actif, lancezpnpm dev-serveretpnpm dev-clientpour ouvrir l’interface surhttp://localhost:3000. - Déploiement managé : une procédure d’installation directe est accessible pour déployer l’environnement sur votre compte Cloudflare, complétée par un modèle de référence sur le dépôt de démarrage cloudflare-os-starter.
- Sur vos propres serveurs : l’hébergement autonome reposera sur le moteur open source workerd, dont la documentation et les outils d’installation dédiés sont en cours de finalisation.
À noter que la configuration des Gatekeepers pour les services tiers (Google, GitHub, Supabase, Confluence, Slack, Home Assistant ou ZoomInfo) nécessite d’enregistrer manuellement des identifiants OAuth auprès de chaque fournisseur, ce qui constitue une étape technique préalable indispensable.