Partager une application active et partager le code qui permet d’en créer une autre sont deux opérations différentes. Elles ne doivent pas donner accès aux mêmes données.
Un espace de travail fondé sur les autorisations
Cloudflare décrit des Dynamic Workers isolés, un état SQLite par application dans des Durable Object Facets et des Gatekeepers pour encadrer les ressources. Un gadget actif peut partager son état ; un blueprint copie le code sans base, historique ni ressources connectées d’origine.
Le dépôt présente la version 2 en accès précoce. Son démarrage local sert à essayer le produit ; documentation et outils d’auto-hébergement en production avec workerd restent annoncés. La licence Apache 2.0 du code ne fournit ni identifiants, ni support opérationnel, ni audit des intégrations.
Deux vérifications de partage distinctes
Le schéma prend une application fictive de notes de frais. Alice et Bob collaborant sur une même instance doivent voir les mêmes enregistrements autorisés. Charlie créant une instance à partir du blueprint doit recevoir la logique avec un état neuf, sans les dépenses d’Alice. Ce sont deux tests d’acceptation différents.
Ajoutez une personne sans accès à la source sous-jacente. Vérifiez si elle peut ouvrir un rapport dérivé, recevoir un export ou suivre un lien partagé. Une connexion réussie à l’espace de travail indique son identité ; elle ne dit pas quelles informations cette personne peut recevoir.
Définir la frontière avant les vraies données
Pour le premier essai, utilisez des données synthétiques faciles à reconnaître. Accordez une ressource à un espace de travail. Essayez une lecture permise, une lecture refusée et une écriture soumise à approbation. Retirez ensuite l’accès et recommencez. Conservez l’état réel du service distant en plus de ce que raconte l’agent.
Ce dernier contrôle compte pour tout système qui prépare ou simule des actions : « terminé » dans une conversation ne doit pas être votre seule preuve d’une modification extérieure. Réciproquement, une action refusée doit laisser le service intact.
L’architecture constitue une référence intéressante pour encadrer des applications générées. Un déploiement utile exige néanmoins des preuves propres à chaque intégration. Gardez ensemble la révision testée, les règles d’identité, les autorisations de ressources et le comportement des exports pour pouvoir expliquer et exploiter le système.
Revue du 8 septembre : gadget partagé distingué du blueprint, limites de maturité et d’auto-hébergement vérifiées, garanties absolues remplacées par des contrôles concrets.