Cloudflare vient de rendre open source un projet qui ressemble, sur le papier, à un énième “espace de travail IA d’entreprise”. Sauf qu’en creusant, on tombe sur l’histoire d’un type qui a vu son ancienne startup échouer commercialement il y a dix ans, et qui vient de la ressusciter avec les honneurs d’un lancement à 3900 étoiles GitHub en une journée. La vraie question n’est pas “qu’est-ce que ça fait”, elle est plutôt : pourquoi une idée morte en 2017 devient soudain une évidence en 2026.

À retenir

Cloudflare OS n’est pas un chatbot d’entreprise de plus, c’est la resucée assumée de Sandstorm, un projet enterré en 2017 dont l’équipe travaille aujourd’hui chez Cloudflare et vient de retenter le coup avec une infrastructure dix ans plus mature. Le cœur technique tient en trois choix précis : isolats V8 légers plutôt que conteneurs pour éviter les démarrages à froid, RPC typé via Cap’n Web pour que chaque application créée par un utilisateur devienne automatiquement pilotable par un agent, et un modèle de permissions “capability-based” où personne, ni humain ni IA, ne part avec un accès par défaut. Le vrai coup de génie s’appelle l’approbation asynchrone : au lieu de bloquer l’agent en attendant une validation humaine, les Gatekeepers simulent le résultat de l’action pour que le travail continue, quitte à faire signer l’humain plus tard, en lot. Et la limite qu’on oublie de mentionner partout ailleurs, c’est que ce système reporte une partie de la dette de gouvernance sur des équipes qui, en 2026, n’ont toujours pas fini de cataloguer leurs accès Google Workspace.

Un fantôme qui revient chercher sa revanche

Il faut d’abord régler un malentendu. Kenton Varda, le tech lead qui a porté le projet, l’a dit lui-même sur X le jour du lancement, sans filtre marketing : “Aujourd’hui on sort Cloudflare OS, un chatbot avec des connecteurs, comme le fait toute autre entreprise tech. Sauf qu’en réalité, c’est différent. C’est un remake de Sandstorm.io, ma startup d’il y a dix ans, sauf que cette fois construit sur Cloudflare Workers”. Sandstorm, en 2014, proposait déjà l’idée que chaque utilisateur fasse tourner sa propre instance privée d’une application, avec une sécurité fondée sur les capacités plutôt que sur des listes de permissions. Ça n’a jamais décollé. Trop tôt, trop lourd en ressources serveur, et surtout, modifier le code demandait encore un développeur.

Dix ans plus tard, l’obstacle a disparu. Si n’importe qui peut demander à un agent d’ajouter une fonctionnalité à son application privée, le logiciel personnel cesse d’être une curiosité de hacker et devient une hypothèse économique sérieuse. C’est ce pari-là que Cloudflare relance, avec un timing et une infrastructure qui, cette fois, tiennent la route.

Ce qui m’amène à une intuition qui va sûrement déranger certains lecteurs pressés d’adopter le truc.

Le mensonge utile de la simulation

On m’a vendu, pendant des années, le “human in the loop” comme LA solution miracle contre les dérapages des agents IA. Sauf que dans la pratique, ça casse tout le flux de travail : l’agent s’arrête, l’utilisateur doit revenir, le contexte se perd, et au bout de trois interruptions par heure, l’équipe finit par activer l’auto-approbation. Le fameux bouton qui saute la sécurité pour aller plus vite. Tout le monde le fait, personne ne l’admet.

Les Gatekeepers de Cloudflare OS contournent le problème d’une façon élégante : quand l’agent demande une action sensible, le Gatekeeper simule localement le résultat, laisse l’agent croire que c’est fait, et empile les validations pour plus tard. En apparence, tout le monde gagne. En réalité, on vient de refiler à l’agent une dette cognitive. S’il construit dix étapes de raisonnement sur une action qui n’a jamais vraiment eu lieu, et que l’humain rejette cette action au moment de valider, c’est toute la chaîne de décisions suivante qui repose sur une prémisse fausse. Personne ne parle de ce risque en ce moment. Je pense qu’on en reparlera dans six mois, au premier incident public.

Et pendant qu’on y est, petite anecdote qui me revient direct en tête.

La clé API qui traînait dans un Google Sheet

Il y a quelques années, sur un des sites que je gérais, j’avais confié à un pigiste un accès Zapier connecté à l’API WordPress pour automatiser la publication d’articles sur trois sites en même temps. Par flemme, ou par manque de temps, j’avais donné une clé avec des droits beaucoup trop larges, capable de publier, modifier et supprimer n’importe quel contenu. Cette clé a fini copiée dans un Google Sheet partagé “juste pour deux jours”, devenu accessible à toute une liste de diffusion trois semaines plus tard. Rien de catastrophique n’est arrivé, on a eu de la chance, mais j’ai passé une soirée entière à révoquer et recréer des accès en panique.

La leçon a été brutale et simple : une clé API, c’est un passe-partout, pas une permission. C’est exactement le problème que le modèle “capability-based” de Cloudflare OS règle à la racine. Un agent n’a jamais la clé, il reçoit une fonctionnalité typée, limitée à une ressource précise, révocable sans toucher au reste. Sur le papier, ça ressemble à du jargon d’architecte système. Dans la vraie vie, ça évite exactement le genre de soirée que j’ai décrite plus haut.cloudflare

Reste une question que peu de gens posent quand ils s’extasient devant les 3900 étoiles GitHub du premier jour.

Pourquoi des isolats V8 et pas des conteneurs

Sandstorm avait choisi les conteneurs en 2014, et s’était pris les pieds dans le tapis des démarrages à froid et de la consommation mémoire. Douze ans après, Cloudflare fait le choix inverse : chaque Gadget tourne dans un Dynamic Worker Facet, un isolat V8 léger avec sa propre base SQLite, sans conteneur ni serveur dédié en attente. Le calcul est simple à comprendre une fois qu’on connaît le contexte : une entreprise qui génère des milliers de mini-applications par mois ne peut pas se permettre le coût de milliers de conteneurs qui tournent en permanence. Un isolat démarre en quelques millisecondes, un conteneur en prend plusieurs secondes. À l’échelle d’une suite bureautique où chaque document devient potentiellement une application, cette différence de latence change tout l’usage perçu.

Le choix du RPC via Cap’n Web plutôt qu’un serveur MCP classique par application obéit à la même logique de radicalité assumée. Là où le standard du marché imposerait d’écrire un serveur MCP pour chaque outil interne, ici l’interface typée existe déjà par construction : n’importe quelle application créée devient automatiquement pilotable par un agent, sans ligne de code supplémentaire. C’est moins consensuel que MCP partout, mais ça évite une explosion de maintenance que personne, sur le terrain, n’a envie de gérer.

Petite mise en abîme au passage : un utilisateur a raconté avoir couplé Cloudflare OS à un modèle DeepSeek auto-hébergé, tournant sur son propre matériel, façon “compagnon de travail privé” complètement souverain. C’est probablement l’usage le plus honnête de la promesse open source du projet, loin du discours corporate sur la productivité.

Le deuxième échec qui m’a servi de leçon

Autre histoire, sur un projet différent. J’avais poussé en production un outil headless en version “early access” quelques jours avant la sortie d’un jeu attendu par toute une communauté, persuadé que la documentation suffisait à couvrir les cas limites. Le trafic a explosé le jour J, l’intégration n’a pas tenu, et on a dû revenir en arrière en urgence pendant les heures les plus chaudes du pic d’audience. La leçon, cette fois, ne portait pas sur la sécurité mais sur l’arrogance : “early access” veut dire early access, pas presque fini.

C’est exactement l’avertissement que les mainteneurs de Cloudflare OS formulent eux-mêmes, sans détour : la version deux, publiée le 5 août 2026, comporte des angles bruts assumés, et pour l’instant seules les contributions triviales sont acceptées, le temps que le socle se stabilise. Ceux qui vont déployer ça en production cette semaine sur un système critique reproduisent, presque au mot près, mon erreur d’il y a deux ans.

Alors, une question à se poser franchement avant de foncer.

Ce que personne ne demande

Combien de temps avant que votre équipe sécurité découvre qu’elle doit désormais auditer non plus dix applications SaaS, mais potentiellement quatre mille instances privées de Gadgets, chacune avec sa propre base SQLite et ses propres capacités accordées à la volée ? Le modèle “une app privée par utilisateur” résout le problème classique du multi-tenant qui fuit entre comptes, c’est vrai et c’est même plutôt élégant. Mais il déplace le problème de gouvernance ailleurs : de la fuite entre utilisateurs vers la prolifération incontrôlée d’artefacts logiciels, chacun avec sa surface d’attaque propre. Le repository fournit quinze Gatekeepers prêts à l’emploi, GitHub, Google, Slack, Notion, Confluence, Linear, Supabase, Home Assistant et quelques autres, mais un Gatekeeper bien configuré ne remplace pas une politique de cycle de vie pour des milliers d’applications jetables.

Est-ce que votre entreprise a vraiment envie de gérer ça, ou est-ce qu’elle a simplement envie du mot “IA” sur sa feuille de route ?

Et après

Ce qui me frappe, au final, ce n’est pas l’appareillage technique, aussi soigné soit-il. C’est que Cloudflare vient de documenter, noir sur blanc dans son propre billet, le moment précis où le SaaS multi-tenant classique commence à sembler dépassé pour une partie des usages internes d’entreprise. Pas remplacé demain, pas partout, mais fissuré dans son évidence. Les partenaires Presidio et Happy Cog vont sans doute vendre ça comme la nouvelle norme d’intégration IA aux comités de direction dans les mois qui viennent. Reste à savoir si les équipes qui devront maintenir des milliers d’applications privées auront, elles, été consultées avant la signature du contrat.