bige-ops Beta démo

Assistant IA (agent)

Un chat intégré qui manipule la configuration de votre simulation : lire le contexte, éditer project.yaml, lancer des commandes en lecture, préparer un Dockerfile. Il ne touche jamais à votre cloud : c’est vous qui faites plan et apply.

Votre clé, votre compte. Modèle utilisé aujourd’hui : Claude Sonnet 4.5 (Anthropic). Vous saisissez votre propre clé API dans Settings ; elle est stockée localement dans ~/.config/bige-ops/settings.json. Les appels partent du backend local de l’app (Tauri) vers l’API Anthropic — la clé ne transite pas par un backend bige-ops, et ce n’est pas une clé managée par nous. Mistral / stack souveraine : prévu, pas encore là. Voir clés & agent.

flowchart LR
  U[Vous — chat] --> A[Agent]
  A --> R[Lecture contexte et fichiers]
  A --> W[Ecriture project.yaml]
  W --> V[validate + generate]
  V --> P[Plan / Apply par vous]

L’agent s’arrête avant le cloud. La dernière étape reste manuelle.

Ce que l’agent peut faire

Lister les simulations du workspace et en créer une nouvelle.
Lire le contexte du projet : statut, project.yaml, estimation de coût.
Lister et lire les fichiers de la simulation.
Éditer project.yaml : mise à jour complète ou patch ciblé.
Retirer un composant, ajouter une stack.
Lancer des commandes CLI en lecture ou local : validate, generate, estimate --json, status, plan, diff config, inventory show…
Lire la documentation intégrée pour justifier ses choix.
Préparer un repo applicatif, lire et écrire un Dockerfile, et ouvrir une pull request dessus.

Ce que l’agent ne fait jamais

Bloqué	Pourquoi
`apply`, `deploy`, `redeploy`	Mutations réelles sur votre cloud ou vos workloads
`github push`	Le push du config-history reste une décision humaine
`auth login` / `auth logout`	Touche à vos credentials Outscale
`import selection`	Réécrit `project.yaml` depuis l’inventaire live
`init --force`	Peut effacer un projet existant

L’agent ne lit ni n’écrit les fichiers de secrets : credentials, coffre, .env, .pem, terraform.tfvars sont filtrés côté outils. Les actions sensibles restantes passent par une demande de confirmation explicite dans le chat — vous validez, ou non.

Dans vos repos applicatifs

Quand l’agent travaille sur un repo de code, l’écriture est volontairement étroite :

fichiers autorisés : Dockerfile, .dockerignore, .bige-ops/* ;
toujours sur une branche bige-ops/* ;
toujours via une pull request — jamais de commit sur main.

Le partage des rôles entre config-history, repos applicatifs et VMs est détaillé dans repos, VMs & Dockerfiles.

Comment bien s’en servir

Donnez une intention et une contrainte : « API + Postgres, budget sous X € HT/mois, région eu-west-2 ».
Faites-lui lire le contexte avant d’éditer, puis relancez validate et generate.
Relisez le diff de project.yaml — c’est la seule vérité.
Pour l’exposition réseau, vérifiez ses choix : ouvrir ou non.
Pour reprendre la main à la pince : config experte.

Limites honnêtes

L’agent peut se tromper. C’est un co-pilote sur la configuration, pas un opérateur cloud, pas un architecte, pas votre SRE. Il peut proposer un dimensionnement faux, une exposition réseau trop large ou un coût mal calibré. Relisez avant plan et apply. La fonctionnalité est encore WIP : outils et garde-fous bougent d’une version à l’autre. Enfin, la consommation de tokens est facturée sur votre compte Anthropic — pas sur le nôtre.