bige-ops Gratuit

Assistant IA (agent)

Un chat intégré qui travaille sur la configuration de ta simulation : lire le contexte, éditer project.yaml, lancer des commandes en lecture, préparer un Dockerfile. Il ne touche jamais à ton cloud : c’est toi qui fais plan et apply. En option, un agent d’audit relit aussi les failles de ton code (audit approfondi).

Ta clé, ton fournisseur. Modèle par défaut : Claude Sonnet 4.5 (Anthropic). Tu peux aussi choisir un modèle OpenAI, Gemini ou Mistral. Tu saisis ta propre clé API dans Settings ; elle est stockée localement dans ~/.config/bige-ops/settings.json. Les appels partent de l’app, sur ton poste, directement vers l’API du fournisseur choisi : aucun backend bige-ops au milieu, aucune clé gérée par nous. Voir la FAQ.

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

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

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 en 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 ton cloud ou tes workloads
`github push`	Le push du config-history reste une décision humaine
`auth login` / `auth logout`	Touche à tes 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 : tu valides, ou non.

Dans tes 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.

L’audit approfondi des failles (en option)

Sans clé ni IA, bige-ops repère déjà les failles de tes dépôts, sur ton poste : pages ou API accessibles sans être connecté, erreurs classiques dans le code, bibliothèques qui ont une faille connue (la méthode). Avec bige-ops advanced et ta propre clé d’IA, un agent d’audit va plus loin :

il relit les pistes déjà repérées : pages ou API accessibles sans être connecté, passages de code à risque, pièges connus de ton framework ;
il confirme les vraies failles et écarte les fausses alertes ;
il classe chaque faille par type, selon le catalogue de référence (CWE), avec son urgence (de P0, la plus urgente, à P3) et son exposition ;
chaque faille peut devenir un ticket GitHub (issue) prêt à ouvrir : c’est toi qui l’ouvres, rien n’est corrigé à ta place.

Seuls des extraits ciblés de ton code partent, avec ta clé, chez le fournisseur d’IA choisi ; la consommation est facturée sur ton compte chez lui. Comme le chat, l’agent d’audit n’applique rien et ne lit pas tes secrets.

MCP local (Cursor / Claude Code)

Même moteur que le chat : bige-ops mcp en stdio (binaire embarqué, rien à installer). Settings → Agents / MCP → copier le snippet. Apply, deploy et auth restent refusés. Visual se rafraîchit après chaque écriture.

Traces

Chaque tour de l’agent est journalisé en JSONL sous chats/traces/ (hors repo). Utile pour l’audit et le debug.

Exposition HTTPS

Pour le HTTPS, l’agent écrit dans project.yaml l’ORN du certificat serveur EIM que tu lui donnes : sur un listener LBU, ou dans expose.tls pour OKS. Le certificat se charge d’abord dans EIM. Voir OKS et LBU.

Comment bien s’en servir

Donne une intention et une contrainte : « API + Postgres, budget sous X € HT/mois, Région eu-west-2 ».
Fais-lui lire le contexte avant d’éditer, puis relance validate et generate.
Relis le diff de project.yaml : c’est la référence.
Pour l’exposition réseau, vérifie ses choix : ouvrir ou non.
Pour reprendre la main à la pince : mode expert.

Bon usage

Un co-pilote de configuration. L’agent propose ; tu décides. Un dimensionnement, une règle réseau ou un coût se relisent avant plan et apply. Ses outils et garde-fous s’enrichissent d’une version à l’autre. La consommation de tokens est facturée sur ton compte chez le fournisseur choisi.