La mise à jour d'avril du SDK Agents d'OpenAI introduit deux nouvelles briques qui manquaient pour passer de l'agent-jouet au déploiement réel. Le sandboxing natif permet de confiner un agent dans un espace de travail isolé, avec accès limité aux fichiers et outils d'un périmètre défini. Et le nouveau harness d'exécution sépare proprement le plan de contrôle (boucle agent, appels modèle, routing d'outils, approbations, tracing, récupération d'erreurs) du plan de calcul (sandbox où l'agent lit, écrit, exécute du code, installe des dépendances, snapshot son état).

L'architecture est pensée pour les agents "long-horizon", ceux qui travaillent sur des tâches complexes en plusieurs étapes, sur des durées longues, avec un besoin de persistance d'état entre les étapes. Le harness gère la coordination, le développeur apporte son propre compute et stockage. C'est une séparation qui permet de brancher le SDK sur n'importe quelle infrastructure, que ce soit Cloudflare, Vercel, Blaxel ou un cluster interne.

Le SDK introduit aussi une abstraction "Manifest" pour décrire un workspace de manière portable. En clair, vous décrivez les outils, les fichiers et les permissions disponibles dans un format standardisé, et le harness sait reconstituer l'environnement ailleurs. C'est utile pour le test, pour la reproductibilité, et pour déployer le même agent dans des environnements différents sans reconfigurer à la main.

Le lancement est Python d'abord, TypeScript prévu après. Classique. Ça peut agacer les équipes full-stack qui bossent en TypeScript, mais c'est quand même très cohérent avec le fait que la majorité des workloads agents en prod tournent encore en Python, surtout côté data et sécurité.

Ce qui est intéressant, c'est le sous-texte. OpenAI pousse un modèle où son SDK est le harness, et le compute est chez le client ou chez un partenaire cloud. C'est un positionnement de plateforme d'orchestration, pas de fournisseur d'infra. Anthropic et Google proposent des approches comparables avec leurs propres SDKs, mais OpenAI a l'avantage du premier écosystème de plugins et d'outils tiers déjà en place.

Bref, pour les devs qui construisent des agents en prod, cette release comble de vrais trous. Sandboxing et harness, c'étaient les deux pièces manquantes.

Source : Techcrunch

Figurez-vous que les agents IA sont désormais les premiers consommateurs des APIs Cloudflare, bien devant les développeurs humains. C'est en tous cas ce que l'éditeur déclare publiquement pour justifier une refonte importante de son outil en ligne de commande, Wrangler, et la sortie d'un nouveau CLI unifié baptisé sobrement "cf".

Le raisonnement est froid mais a du sens. Si les agents IA pilotent la plateforme, autant qu'ils aient un CLI qui ne les plante pas.

Concrètement, Cloudflare a refait toute sa pipeline de génération de code autour d'un schéma TypeScript unique. Ce schéma décrit le périmètre complet des APIs, des commandes CLI, des arguments et du contexte nécessaire pour générer n'importe quelle interface.

Quand un nouveau produit Cloudflare arrive, il tombe automatiquement dans le CLI. Avec près de 3 000 opérations d'API au catalogue, c'était effectivement le bon moment pour industrialiser la chose.

Le point qui dit beaucoup sur l'état de l'industrie, c'est celui-ci. Cloudflare force désormais des commandes CLI par défaut au niveau du schéma, pour éviter que les agents se plantent sur des variantes moins standards qu'ils ne connaissent pas.

En clair, le design du CLI est partiellement contraint par ce que les LLM savent deviner. C'est nouveau, et pas anodin.

À côté du nouveau CLI cf, Cloudflare lance Local Explorer en bêta ouverte, intégré à Wrangler et au plugin Cloudflare pour Vite. L'outil permet d'inspecter les Workers en local, de voir quels bindings leur sont attachés et quelles données y sont stockées.

Pratique pour déboguer sans passer par le dashboard web, surtout quand on jongle entre plusieurs environnements.

Pour les développeurs humains, la promesse est double. D'abord, un CLI plus cohérent, moins de surprises d'un produit à l'autre. Ensuite, un outil de debug local qui évite l'allée-retour constant avec l'interface web Cloudflare. Pour les agents IA, la promesse est plus prosaïque, appeler Cloudflare sans générer d'erreurs de syntaxe toutes les trois commandes.

C'est en fait assez symptomatique d'une tendance qu'on voit chez plusieurs plateformes cloud en ce moment, où l'ergonomie CLI est pensée pour les LLM autant que pour les humains. Pas sûr que tous les acteurs l'assument aussi frontalement, mais Cloudflare, fidèle à son style, le dit.

Bref vous l'avez compris, cf et Local Explorer valent le détour. Et si vous laissez un agent piloter l'infra, au moins il aura des rails pour que ça ne parte pas dans tous les sens.

Source : The Register

Si vous bossez avec le CI/CD de GitLab, y'a un angle mort que vous n'avez probablement jamais vérifié : La config de votre pipeline elle-même. Celle qui décide quelles images faire tourner et quels secrets exposer sans oublier les jobs à lancer. Et ça personne ne la scanne !

C'est d'ailleurs exactement cet angle d'attaque qu'ont choisi les pirates derrière l'attaque tj-actions en mars 2025, qui a touché plus de 23 000 organisations en modifiant simplement des tags de version. Ou encore l'attaque sur Trivy , où un scanner de sécurité s'est retrouvé lui-même vérolé. Le schéma est toujours le même : on s'infiltre comme Mario, par la tuyauterie et pas par la porte d'entrée.

Plumber que je vous présente aujourd'hui, est un outil open source en Go qui scanne votre .gitlab-ci.yml et les réglages de votre repo pour détecter les failles de configuration. Vous l'installez via Homebrew (brew tap getplumber/plumber && brew install plumber), vous lancez plumber analyze à la racine de votre projet, et il vous sort un rapport de conformité. 2 minutes chrono, même pas besoin de toucher à votre CI.

Plumber embarque 14 contrôles de sécurité qui couvrent les erreurs de configuration les plus courantes. Ça détecte les images Docker taguées latest (le classique qui traîne dans 80% des projets), les branches pas protégées, les curl | bash sans vérification, et même les jobs de sécurité qu'on a désactivés en douce avec un petit allow_failure: true. Vous savez, le réglage foireux qui fait que votre pipeline affiche tout vert... alors qu'il ne scanne plus rien du tout !

Côté output, Plumber génère une sorte de liste d'ingrédients de votre pipeline, un peu comme l'étiquette sur un paquet de bouffe mais pour votre chaîne de déploiement. Ça vous dit exactement quelles images, quels scripts et quelles dépendances tournent dans vos jobs. Le tout dans un format standard que d'autres outils de sécu peuvent digérer.

Pour l'intégrer directement dans votre pipeline GitLab, c'est 2 lignes :

include:
 - component: gitlab.com/getplumber/plumber/plumber@v0.1.30

Si vous avez déjà installé Nextcloud sur un serveur, vous savez que c'est pas une partie de plaisir ! La stack PHP + MySQL, les mises à jour qui cassent tout, les performances qui s'effondrent dès que vous dépassez 50 utilisateurs... Relouuu.

Mais c'est là qu' OpenCloud débarque avec une approche radicalement différente puisque tout est écrit en Go, y'a zéro base de données, et l'installation se fait en deux commandes sur n'importe quel serveur à 5 balles par mois.

OpenCloud, en fait, c'est un fork d'ownCloud Infinite Scale (OCIS). Les développeurs du projet original chez Heinlein Group ont quitté ownCloud, forké le code, et relancé le tout sous licence Apache 2.0. Du coup, c'est pas un projet qui part de zéro mais une réécriture déjà très mature qui tourne en prod.

Là où Nextcloud utilise une base MySQL ou PostgreSQL pour stocker les métadonnées, OpenCloud balance donc tout dans le système de fichiers. Pas de SGBD ce qui veut dire pas de migration de base à gérer ni de tables corrompues après un crash. Tout atterrit dans le dossier $HOME/.opencloud/ et c'est réglé. Donc si vous savez faire un rsync, vous savez aussi faire une sauvegarde complète de votre instance. Oui la vie est belle !

Côté fonctionnalités, on retrouve donc le partage de fichiers, la collaboration en temps réel avec une suite bureautique intégrée, le chiffrement, le versioning (pratique contre les ransomwares), l'authentification via OpenID Connect... bref tout le classique d'un cloud privé correct.

Maintenant, le problème je trouve, c'est que l'écosystème d'apps est pas forcément au niveau de Nextcloud. Le CalDAV/CardDAV passe par Radicale en conteneur séparé (pas intégré au core), y'a pas d'app Notes ni de client mail intégré. Donc si vous avez besoin de tout ça, Nextcloud reste le bon choix. Mais bon, pour du stockage et de la collaboration pure, c'est clairement plus léger (genre 200 Mo de RAM au lieu de 2 Go pour Nextcloud) et surtout plus rapide.

D'ailleurs, l'architecture microservices en Go fait que ça scale nettement mieux.

Maintenant, pour installer ça, le plus simple c'est Docker Compose. Le repo opencloud-compose vous propose même des configs prêtes à l'emploi. À vrai dire, si vous êtes du genre à auto-héberger vos services , c'est un candidat sérieux pour remplacer votre Nextcloud donc si vous avez surtout besoin de fichiers et de collaboration, ça vaut le test. D'ailleurs, comme OpenCloud utilise OIDC pour l'auth, Pocket ID s'intègre pile poil avec pour du SSO sans mot de passe. Je dis ça, je dis rien ^^.

Bref, si Nextcloud vous gonfle avec sa lourdeur PHP et ses 47 tables MySQL, OpenCloud mérite un bon petit coup d'oeil !

Merci à fredix pour le lien !