Fluid - Claude Code pour l’infrastructure

 (fluid.sh)
5 points par GN⁺ 2026-02-06 | 1 commentaires | Partager sur WhatsApp
  • Un outil en ligne de commande qui crée un environnement sandbox répliqué afin que des agents IA puissent manipuler une infrastructure réelle en toute sécurité
  • Exécute des commandes, modifie des fichiers et teste des connexions dans une VM répliquée ou un cluster Kubernetes, puis génère automatiquement le résultat sous forme d’Ansible Playbook
  • Contrairement à une approche où le LLM se contente de générer du code, il réplique l’environnement réel pour produire de l’IaC (Infra-as-Code) testée et validée
  • Utilise des certificats SSH éphémères pour exécuter les commandes en sécurité, avec une validation humaine requise pour les hôtes à faibles ressources ou les accès à Internet
  • Toutes les commandes et modifications sont suivies dans un journal d’audit, ce qui permet aux développeurs d’expérimenter l’infrastructure en local et de créer des configurations reproductibles

Présentation de Fluid

  • Fluid est un agent terminal qui permet à une IA de travailler dans une sandbox répliquant une infrastructure de production (ex. : VM, cluster K8s)
    • L’agent IA peut exécuter des commandes, tester des connexions et modifier des fichiers
    • Les résultats peuvent ensuite être convertis en Ansible Playbook afin d’être appliqués à l’environnement de production
  • Cette approche permet à l’IA de tester directement dans un environnement répliqué, au lieu de devoir deviner la structure réelle du système

Différences avec la génération d’IaC basée sur les LLM

  • Les LLM génèrent bien du code pour Terraform, OpenTofu, Ansible, etc., mais ne comprennent pas précisément le comportement d’un environnement de production réel
  • Fluid commence par exécuter des commandes et effectuer des tests via l’accès à une infrastructure répliquée, puis rédige l’IaC à partir des résultats obtenus
  • Cette approche rend possibles la validation et l’expérimentation avant déploiement

Différences avec Claude Code et conception de la sécurité

  • Fluid est conçu pour que Claude Code ne se connecte pas directement en SSH aux serveurs de production depuis l’environnement local
  • Toutes les opérations sont exécutées uniquement dans la sandbox, sous le contrôle de Fluid
  • Il utilise des certificats SSH éphémères et affiche en temps réel les résultats de l’exécution des commandes
  • Les hôtes à faible mémoire ou faible CPU, l’accès à Internet, l’installation de paquets, etc. nécessitent une validation humaine

Fonctionnalités principales

  • Sandbox Isolation : réplique instantanément une VM pour tester des modifications sans impacter la production
  • Context-Aware : explore l’OS, les paquets et les outils CLI de l’hôte pour s’adapter à l’environnement
  • Full Audit Trail : enregistre toutes les commandes et modifications pour permettre audit et revue
  • Génération automatique d’Ansible Playbook : crée du code d’infrastructure reproductible à partir des opérations effectuées dans la sandbox

Exemple d’utilisation

  • Fluid crée une sandbox avec la commande v create_sandbox et affiche son IP ainsi que son état
  • v run_command exécute des commandes ; dans l’exemple, il installe et lance Apache HTTP Server sur un environnement Ubuntu 22.04
  • curl localhost permet de vérifier le bon fonctionnement du serveur web
  • Ensuite, v create_playbook génère le playbook httpd-setup
    • Il contient 4 tâches : mise à jour du cache apt, installation d’Apache, création de index.html, démarrage et activation du service Apache
  • Le playbook généré permet de reproduire la même configuration sur d’autres serveurs Ubuntu

Installation et exécution

  • Il se présente sous la forme d’un agent terminal à installer sur le poste de travail local
  • Après l’installation, il est possible de créer immédiatement une sandbox et d’effectuer des tests depuis l’environnement local

Résumé

  • Fluid est un outil qui combine automatisation d’infrastructure par IA et isolation sécurisée
  • Grâce à l’exécution de commandes en temps réel, à la traçabilité d’audit et à la génération de code Ansible, il prend en charge une gestion d’infrastructure sûre et reproductible
  • Une sorte de version infrastructure de Claude Code, offrant aux développeurs et aux équipes d’exploitation une nouvelle manière d’expérimenter en reproduisant l’environnement de production

À lire aussi

1 commentaires

 
GN⁺ 2026-02-06
Commentaires Hacker News

  • En ce moment, on a l’impression qu’il y a une surabondance d’outils pour construire, mais rien de vraiment clair à construire au final
    Comme si tous les produits n’étaient qu’une partie d’une pyramide au service d’un autre build tool
    Ce n’est pas une critique de fluid.sh, c’est juste que moi aussi je me demande quoi construire

    • Je bossais dans une startup pendant le boom des apps Facebook en 2007, et toutes les boîtes d’apps avaient en fait un modèle où elles vendaient de la pub pour d’autres apps
      L’écosystème des apps tournait complètement en vase clos, sans vraie valeur utilisateur ni vraie source de revenus. Ça n’a évidemment pas duré
    • Le problème, c’est que beaucoup de développeurs approfondissent surtout les compétences logicielles sans connaissance métier
    • Moi aussi, ça fait un an que je travaille dans un secteur non tech, et grâce à mes compétences en code, mes collègues me prennent pour un magicien
      En résolvant de vrais problèmes, la base de code évolue peu à peu vers des fonctions réutilisables
      J’essaie maintenant de faire du conseil à partir de cette expérience, et je finirai peut-être par trouver quelque chose qu’on pourra appeler un « produit »
    • D’un point de vue macroéconomique, quand la technologie avance trop vite, il peut y avoir une phase où la production diminue au lieu d’augmenter
      Le boom actuel des outils IA ressemble un peu à ça. Tout le monde réapprend en permanence dans un contexte de changements trop rapides
      Au fond, on est en train de bâtir sur du sable mouvant
    • Je me posais la même question, mais récemment j’ai commencé à utiliser ces outils pour du reverse engineering
      Par exemple, je n’étais pas satisfait de la qualité d’impression sous Linux de mon imprimeuse d’étiquettes chinoise, alors j’ai écrit un script Go qui imprime directement via BLE
      Au lieu de décompiler l’app Android, j’ai laissé faire une Agentic AI, et maintenant j’ai même une version navigateur et une version ESP32
      J’ai résumé ça ici : Making a label printer work under Linux using Agentic AI

  • La raison pour laquelle le curl -fsSL https://fluid.sh/install.sh | bash m’a fait rire,
    c’est l’ironie de vouloir à l’origine bloquer l’accès SSH pour des raisons de sécurité, pour finalement faire exécuter un script d’installation encore plus risqué
    Le tweet lié est visible ici

    • On vit maintenant dans un monde où l’on empoisonne Internet pour que les LLM recommandent des URL malveillantes. Quelle époque incroyable

  • Moi, c’est Collin, et je construis fluid.sh
    On peut voir ça comme la version infrastructure de Claude Code.
    Fluid crée des copies sandboxées d’une infrastructure de production (VM, K8s, etc.), pour permettre à un agent IA d’exécuter des commandes, modifier des fichiers et lancer des tests,
    puis de générer de l’IaC comme des playbooks Ansible
    L’idée clé, c’est qu’au lieu de simplement faire générer du Terraform par un LLM, on lui permet d’explorer l’environnement réel et d’en comprendre le contexte
    Pour des raisons de sécurité, Claude Code n’est pas conçu pour se connecter directement en SSH à la production,
    et on utilise des certificats SSH éphémères pour assurer la traçabilité de l’exécution des commandes
    Une approbation humaine est requise pour les hôtes aux ressources limitées ou quand il faut accéder à des réseaux externes
    Tous les retours sont les bienvenus !

    • Je me demande pourquoi cette explication n’apparaît pas sur la page d’accueil.
      En l’état, le site se contente de dire quelque chose comme « Claude Code for infrastructure »,
      ce qui reste beaucoup trop vague pour qu’un ingénieur infra lance un bash en une ligne en toute confiance
    • Lancer plusieurs copies d’infrastructure pour y faire circuler des agents, ça ressemble surtout à du gaspillage de coûts
      D’un point de vue DevOps, ça paraît inefficace
    • Faire de la configuration manuelle dans un sandbox distant va à l’encontre de la philosophie Infrastructure as Code
      De mon côté, j’automatise déjà très bien avec Pulumi, Tilt et Kubernetes
      Claude fonctionne aussi très bien dans cet environnement. Pas besoin d’aller bricoler directement en SSH
    • Dans ce cas, je ne vois pas bien en quoi c’est différent du fait de déployer Claude Code sur une VM existante pour l’y faire tourner
      Il existe déjà plusieurs approches de sandboxing. Je me demande quelle est la différence réelle
    • On peut déjà répliquer une infrastructure existante avec Terraformer,
      donc si cette automatisation IaC de base n’est pas en place, c’est surtout un problème de l’équipe DevOps
    • Je fais déjà ce genre de choses en demandant à Claude Code d’exécuter des commandes kubectl pour modifier des charts Helm
      Ça fonctionne déjà très bien avec un simple CLI
      • Une bonne partie des outils à base de LLM aujourd’hui ne sont qu’à ce niveau de wrapper de prompt. Il n’y a pas de différence fondamentale
      • J’ai un peu la même impression, mais ce projet vise surtout à sécuriser les environnements à grande échelle
        Quand on opère des centaines de VM, une simple supervision ne suffit pas
      • Je fais aussi tourner Claude avec un compte en lecture seule, et ça s’intègre très bien avec Terraform ou l’AWS CLI
        Je n’ai pas vraiment besoin d’un nouvel outil
      • Moi aussi, je le limite avec un kubeconfig en lecture seule, et avec un SKILL.md bien rédigé, ça reste suffisamment sûr
      • Même en lecture seule, je n’ai pas rencontré de gros problèmes.
        Cela dit, ce projet semble mettre davantage l’accent sur la reproductibilité et la sécurité
    • Répliquer la production n’a rien de simple. Les connexions aux bases de données ou la duplication d’une stack complète sont difficiles à réaliser en pratique
      Je pense qu’il vaut mieux laisser l’IA comprendre la structure de la production et faire directement les changements
      Les modèles sont déjà largement capables d’écrire de l’IaC
    • L’idée est intéressante. En ce moment, tout ce qui touche à l’exploitation et à l’observabilité (Observability) est en plein essor
      Moi aussi, en exploitation Kubernetes, je donne à Claude l’accès à Grafana pour l’aider à debugger,
      et ça m’a déjà fait gagner des dizaines d’heures.
      L’approche consistant à générer automatiquement des playbooks Ansible est aussi excellente du point de vue de la traçabilité d’audit
      • Mais si ce type d’automatisation se généralise, cela risque d’accentuer la précarité des équipes d’exploitation
        On voit déjà des cas où des ingénieurs expérimentés perdent leur emploi
      • Ravi d’apprendre qu’un support Kubernetes est prévu. J’aime bien l’idée
    • Honnêtement, j’ai l’impression que c’est déjà un problème résolu
      Dans la plupart des cas, l’infrastructure est mise en place en IaC dès le départ, et si besoin on peut la reconstituer dans l’autre sens
      Il suffit de faire tourner Claude dans un compte sandbox avec un rôle IAM
    • Je ne suis pas d’accord avec l’idée que les LLM ne peuvent pas bien inférer l’état d’un système de production
      Avec l’IaC, on peut interroger l’infrastructure via des API, et les avantages sont la réutilisabilité et le versioning
      • Je suis d’accord sur le fait que les environnements DevOps varient d’une entreprise à l’autre et sont difficiles à généraliser
        La plupart des startups peinent encore avec du HCL ou du YAML
    • Le message du type « pour rester en sécurité, exécutez ce script curl » paraît ironiquement contradictoire
    • Est-ce que ça consiste à piloter KVM via libvirt et à émettre des clés SSH pour que le LLM accède aux VM ?
      Est-ce que les playbooks Ansible sont générés à partir des changements effectués dans la VM, ou bien tout passe-t-il uniquement par Ansible ?
      J’aimerais comprendre quelle est la fonction différenciante par rapport à de simples exécutions répétées d’Ansible