J’avais ma console, elle marchait bien. Mais un soir, en déployant un énième Grafana à coup de YAML, j’ai eu une idée.

Et si je pouvais juste dire “déploie un Grafana” et que ça se fasse ?

L’idée

Les LLMs comme GPT ou Claude sont bons pour comprendre le langage naturel et générer du code. Et si j’en faisais un assistant pour mon cluster ?

Pas un chatbot qui te donne des conseils. Un agent qui exécute vraiment des actions.

Moi: "Déploie un Grafana"

Agent: 
✅ Namespace créé
✅ Deployment créé  
✅ Service créé
✅ HTTPS configuré
Voilà l'URL: https://grafana-xxx.sortium.fr

Pourquoi Claude ?

J’ai testé GPT-4 et Claude. Les deux marchent bien, mais Claude avait un truc en plus : le “tool calling” natif.

Avec le tool calling, tu définis des fonctions que l’IA peut appeler :

{
  "name": "deploy_app",
  "description": "Déploie une application sur Kubernetes",
  "parameters": {
    "app_name": "string",
    "namespace": "string"
  }
}

Claude décide quand appeler quelle fonction, avec quels paramètres. Tu reçois l’appel, tu l’exécutes, tu renvoies le résultat.

Le premier prototype

J’ai commencé simple. Un seul tool : kubectl_get.

type Tool struct {
    Name        string
    Description string
    Execute     func(input map[string]interface{}) string
}

tools := []Tool{
    {
        Name:        "kubectl_get",
        Description: "Liste des ressources Kubernetes",
        Execute:     func(input) {
            resource := input["resource"].(string)
            namespace := input["namespace"].(string)
            return runKubectl("get", resource, "-n", namespace)
        },
    },
}

Puis j’ai envoyé une requête à Claude avec le tool disponible :

User: "Liste mes pods dans le namespace default"

Et Claude a répondu :

{
  "type": "tool_use",
  "name": "kubectl_get",
  "input": {"resource": "pods", "namespace": "default"}
}

Il avait compris ! Il a choisi le bon tool avec les bons paramètres.

Les premiers succès

J’ai ajouté d’autres tools :

• deploy_app : Déployer une application
• delete_pod : Supprimer un pod
• get_logs : Récupérer les logs

Et ça marchait. Je disais “supprime le pod nginx-xxx” et il le faisait.

Le moment où j’ai dit “déploie un MySQL” et que j’ai eu une base de données fonctionnelle 30 secondes plus tard, j’ai su que je tenais un truc.

Les premiers échecs

Mais c’était pas parfait.

1. Il inventait des trucs

Parfois Claude inventait des noms de pods ou de namespaces. Hallucination classique des LLMs.

Solution : Lui demander de toujours vérifier avec kubectl_get avant d’agir.

2. Il était trop bavard

Il expliquait tout ce qu’il allait faire au lieu de le faire.

Solution : Ajuster le system prompt pour lui dire d’être concis et d’agir.

3. Il oubliait le contexte

Sur des conversations longues, il perdait le fil.

Solution : Résumer le contexte à chaque échange.

Le system prompt

Le truc qui a tout changé, c’est le system prompt. J’ai passé des heures à l’affiner :

Tu es un agent IA autonome pour Kubernetes.
Tu as accès à des tools pour interagir avec le cluster.
Quand on te demande quelque chose, FAIS-LE. Ne demande pas de confirmation.
Sois concis. Donne les infos importantes (URLs, credentials).
En cas d'erreur, diagnostique et corrige.

Avec un bon prompt, l’agent est passé de “assistant qui bavarde” à “agent qui agit”.

Le moment eureka

Un jour, j’ai déployé une app et elle crashait. Au lieu de debugger moi-même, j’ai dit :

“Le pod nginx crash, pourquoi ?”

L’agent a :

1. Récupéré le status du pod
2. Lu les logs
3. Identifié l’erreur (permission denied sur un volume)
4. Suggéré la correction

J’ai dit “corrige” et il l’a fait. Le pod marchait.

C’était plus qu’un déploiement automatique. C’était un agent qui comprend et résout les problèmes.

---

Prochain article : 45 tools plus tard - comment l’agent est devenu vraiment autonome.