45 tools plus tard

Le prototype marchait. Mais avec 3-4 tools, c’était limité. J’ai passé les semaines suivantes à construire un vrai arsenal.

Les catégories de tools

1. Recherche et Discovery

L’agent doit pouvoir découvrir des apps qu’il connaît pas.

  • web_search : Chercher sur internet
  • search_docker_image : Chercher sur Docker Hub
  • inspect_docker_image : Analyser une image (ports, env vars, volumes)

Maintenant quand tu dis “déploie Coolify”, l’agent cherche ce que c’est, trouve l’image Docker, l’inspecte pour comprendre comment la déployer.

2. Déploiement

Le cœur du truc.

  • deploy_app_template : Déployer une app connue (45 templates)
  • deploy_custom_app : Déployer n’importe quelle app
  • deploy_helm_chart : Installer via Helm
  • deploy_docker_compose : Convertir un docker-compose en K8s

3. VMs

Parce que KubeVirt.

  • deploy_vm : Créer une VM
  • start_vm, stop_vm, restart_vm
  • get_vm_access : Récupérer les infos SSH/VNC

4. Kubernetes natif

Les classiques.

  • kubectl_get, kubectl_exec, kubectl_delete
  • list_pods, list_deployments, list_services
  • get_pod_logs, describe_resource

5. Troubleshooting

Le game changer.

  • analyze_pod_failure : Diagnostiquer pourquoi un pod crash
  • apply_fix : Appliquer une correction automatique

Les templates d’apps

J’ai pré-configuré 45 applications courantes :

var AppTemplates = map[string]AppTemplate{
    "grafana": {
        Image:        "grafana/grafana:latest",
        Ports:        []int{3000},
        DefaultUser:  "admin",
        DefaultPass:  "admin",
        SecurityContext: &SecurityContext{
            FSGroup: 472,
        },
    },
    "mysql": { ... },
    "postgres": { ... },
    "redis": { ... },
    // ... 45 templates
}

Chaque template a les bonnes configs : ports, users, security context, health checks…

Quand tu dis “déploie un Grafana”, l’agent utilise le template. Pas besoin de chercher comment configurer.

L’auto-healing

Le truc dont je suis le plus fier.

Quand un pod crash, analyze_pod_failure fait :

  1. Récupère le status du pod
  2. Lit les events Kubernetes
  3. Lit les logs (current + previous)
  4. Analyse l’erreur
  5. Suggère un fix

Et apply_fix peut appliquer des corrections :

  • Ajouter un security context
  • Corriger les permissions d’un volume
  • Augmenter les resources (CPU/RAM)
  • Modifier une variable d’environnement

En pratique :

Moi: "Grafana crash"

Agent:
🔍 Analyse en cours...

Problème identifié: Permission denied sur /var/lib/grafana
Cause: Le container tourne en UID 472 mais le volume est monté en root

Correction: Ajouter fsGroup: 472 au securityContext

✅ Fix appliqué
✅ Pod redémarré
✅ Grafana fonctionne

URL: https://grafana-xxx.sortium.fr

30 secondes au lieu de 30 minutes de debug.

Le workflow Discovery

Pour les apps pas dans les templates :

Moi: "Déploie Coolify"

Agent:
🔍 Je connais pas Coolify, je cherche...

→ web_search("coolify kubernetes")
→ search_docker_image("coolify")
→ inspect_docker_image("ghcr.io/coollabsio/coolify:latest")

💡 Coolify a besoin de PostgreSQL et Redis

→ deploy_app_template("postgresql")
→ deploy_app_template("redis")
→ deploy_custom_app("coolify", image: "...", env: {...})

✅ Stack déployée!
URL: https://coolify-xxx.sortium.fr

Il découvre, il apprend, il déploie.

Les règles d’or

Dans le system prompt, j’ai des règles :

  1. Toujours vérifier avant d’agir. Pas d’hallucination sur les noms de resources.
  2. Donner les infos d’accès. URL, username, password.
  3. En cas d’erreur, diagnostiquer automatiquement.
  4. Demander confirmation pour les actions destructives (delete namespace).

Le coût

Claude c’est pas gratuit. Avec un system prompt de 290 lignes + 45 tools, chaque requête coûtait cher.

Solution : Anthropic Prompt Caching. Le system prompt est mis en cache côté serveur. Réduction de 90% sur les tokens d’input.

De ~50$/mois à ~10$/mois pour un usage normal.

Ce que ça change

Avant l’agent :

  • “Je vais déployer un Grafana” → 15-20 min de YAML
  • “Ça crash” → 30 min de debug

Après l’agent :

  • “Déploie un Grafana” → 30 secondes
  • “Ça crash, répare” → 30 secondes

C’est pas juste du gain de temps. C’est un changement de paradigme. Tu parles à ton cluster.

Prochain article : Le formulaire dynamique - créer n’importe quelle ressource Kubernetes sans écrire de YAML.