Introduction
En mai 2026, Cloudflare a mis entre les mains de l'ensemble de ses employés une plateforme permettant de créer des applications internes, d'automatiser des processus et d'accéder aux systèmes de l'entreprise via des agents. Trois mois plus tard, la même plateforme a été publiée en open source sous le nom Cloudflare OS. Ce qui pourrait passer pour une annonce produit ordinaire cache une réponse architecturale à un problème que beaucoup d'équipes platform engineering connaissent bien : comment offrir un environnement d'exécution sécurisé et multi-tenant à des applications créées dynamiquement par des non-développeurs ?
Deux nouveaux primitifs pour l'isolation
La contrainte principale était simple à énoncer, difficile à résoudre : si chaque employé peut créer une application, chaque application doit s'exécuter dans un isolement strict, sans partager d'état ni de base de données avec ses voisines.
Cloudflare a développé deux briques absentes de son catalogue existant : les Dynamic Workers et les Durable Object Facets. Les premiers permettent de charger du code à la volée sans déploiement manuel — chaque application générée par un agent devient un Worker autonome, instancié à la demande. Les seconds résolvent le problème du stockage : chaque Worker dynamique reçoit sa propre instance de base de données SQLite, isolée du reste, sans configuration supplémentaire.
Le résultat : une application créée par un agent n'a aucun moyen structurel d'accéder aux données d'une autre. L'isolation est garantie par le runtime, pas par la convention ou la bonne volonté des développeurs.
La sécurité encodée dans des Workers
L'autre défi était le contrôle des accès. Un agent opérant au nom d'un employé ne devrait pas pouvoir lire l'intégralité d'un dépôt quand on lui demande de consulter une simple issue. Cloudflare OS introduit les Gatekeepers : des Workers spécialisés qui s'interposent entre l'agent et chaque système externe.
Chaque Gatekeeper définit des règles précises — accès en lecture seule à un chemin donné, masquage de certains champs, limites de débit, approbations requises pour les opérations sensibles. Par défaut, les agents démarrent sans aucun accès. La plateforme enregistre également chaque ressource observée par un agent : ce journal devient une donnée de sécurité active, consultée par les Gatekeepers lorsqu'un tiers tente d'accéder au workspace.
Cette approche relève du security-as-code : les règles d'accès sont des Workers versionnables, testables et déployables comme n'importe quel autre composant de l'infrastructure.
Open source après test en production
Cloudflare OS n'est pas un outil clé en main. Deux dépôts sont disponibles en open source : le cœur de la plateforme et un exemple de déploiement basé sur l'usage interne de Cloudflare. Des partenaires intégrateurs accompagnent la personnalisation des Gatekeepers et la configuration des contrôles de sécurité selon les systèmes de chaque organisation.
C'est précisément le modèle de publication qui mérite attention. Cloudflare a déployé Cloudflare OS pour des milliers de ses propres employés — couvrant toutes les fonctions de l'entreprise, pas uniquement les ingénieurs — avant d'ouvrir le code. Ce séquençage est rare : la plupart des plateformes sont publiées avant d'être véritablement éprouvées à l'échelle. Ici, les primitifs Dynamic Workers et Durable Object Facets ont été construits pour répondre à un besoin interne concret, puis affinés pendant plusieurs mois avant toute annonce.
Ce que les équipes DevOps peuvent en retenir
Pour les équipes platform engineering, l'intérêt de Cloudflare OS ne réside pas dans les fonctionnalités destinées aux utilisateurs finaux mais dans l'architecture sous-jacente. La combinaison Worker isolé plus base SQLite par instance résout un problème de multi-tenant que beaucoup d'Internal Developer Platforms contournent plutôt qu'ils ne le traitent vraiment. Le modèle Gatekeeper offre un schéma de référence pour contrôler l'accès des agents à des systèmes internes sans créer une surface d'attaque supplémentaire.
La base de code publiée en open source documente des choix techniques éprouvés par une organisation à l'échelle d'un grand éditeur cloud. Pour quiconque construit ou fait évoluer une plateforme interne, c'est un cas d'étude concret qui va bien au-delà de la documentation d'API.