J'ai vibe codé une CLI (1/3) : Du problème à la solution

Photo de Roman Synkevych sur Unsplash

Résumé

Appliquer le zéro trust sur un cluster Kubernetes n’est pas une tâche aisée : Il faut mettre en place différents outils pour l’authentification, la sécurité des flux réseaux, l’auditabilité et l’observabilité.

Concernant la sécurisation des flux réseaux, c’est définir ce qui est autorisé ou non entre les différents composants déployés sur un cluster. En pratique : près de cent vingtrègles à créer manuellement à partir d’une matrice de flux pour un seul cluster Kubernetes.

C’est une tâche fastidieuse et source d’erreurs. Face à ce défi, j’ai décidé de créer une CLI pour automatiser cette conversion… en utilisant un assistant de code IA.

Ce qui devait être un simple outil interne est devenu un terrain de jeu pour expérimenter le “vibe coding” avec Claude Code.

Dans cette série d’articles, je partage mon retour d’expérience sur un mois de développement assisté par IA en environnement de production : ce qui a marché, ce qui a échoué, et les leçons apprises.

Dans ce premier article (partie 1/3) : Je vous présente le contexte qui m’a amené à créer cette CLI, le défi technique posé par les network policies, et pourquoi j’ai choisi d’utiliser un assistant de code pour son implémentation.

Le contexte : SRE dans une plateforme Kubernetes

Dans ma mission actuelle, je travaille en tant que SRE sénior dans une équipe qui propose une plateforme pour l’hébergement d’applications développées en interne. Cette plateforme se base sur des clusters Kubernetes créés par Cluster API (entres autres, mais ça c’est une autre histoire).

Un jour, mon PO exprime le besoin d’ajouter une couche de sécurité au niveau réseau pour isoler les différents composants d’une application. Normal me direz-vous mais ayant tout à construire ces aspects avaient été mis au fond du backlog. Enfin bon, je m’attaque à l’Epic : ajouter des règles pour sécuriser les applications.

Le défi : la matrice de flux

En ouvrant le ticket, je commence à lire la matrice de flux : Dans ce fichier y sont décrits pour chaque namespace de chaque cluster, les flux entrants et sortants pour les composants du namespace. A titre d’exemple, pour un cluster, il peut y avoir une quinzaine de namespaces comportant entre cinq et dix composants sans compter les composants permettant l’observabilité, le déploiement ou autres joyeusetés.

Cette matrice de flux était incomplète car il n’y avait que les flux applicatifs qui y étaient décrits. Cette simple tâche devient une tâche complexe pour avoir un ensemble exhaustif et cohérent. Heureusement, Cilium propose des outils d’observabilité qui permettent de facilement comprendre l’ensemble des flux réseaux d’un namespace.

Une fois la matrice de flux complétée, je commence alors à me dire que ce sera une charge importante pour la transformer en un ensemble de polices cohérentes (et qui ne ferme pas TOUS les flux par accident).

Pourquoi c’est complexe ?

Créer manuellement des Network Policies à partir d’une matrice de flux présente plusieurs difficultés et peuvent être des sources d’erreurs :

1. Volume important : Une dizaine de namespaces avec plusieurs flux chacun = dizaines de policies à écrire
2. Complexité du format : Le format YAML des CiliumNetworkPolicy est verbeux et technique. Il existe différents moyens de décrire la même autorisation ou refus.
3. Risque d’erreur : Une erreur de syntaxe ou de logique peut couper des flux critiques
4. Maintenance : À chaque nouveau flux, il faut mettre à jour ou créer de nouvelles policies
5. Cohérence : S’assurer que toutes les policies suivent les mêmes conventions de nommage, labels, etc.

Exemple simplifié d’une ligne de matrice de flux dans le fichier CSV que j’ai défini:

source_namespace,source_labels,destination_namespace,destination_labels,port,protocol,cluster
frontend,app: frontend,backend, app: backend,8080,tcp,same-cluster

Et la Network Policy Cilium qui doit être obtenue:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: frontend
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
  - toEndpoints:
    - matchLabels:
        app: backend
        k8s:io.kubernetes.pod.namespace: backend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

Et ceci multiplié par le nombre de cluster (en général trois par environnement), le nombre de namespaces (entre dix et vingt par cluster) et le nombre d’applications déployées par namespace…

L’idée : automatiser avec une CLI

En bon SRE, je me dis qu’il est temps pour moi d’automatiser. Et si c’était pour moi l’occasion de proposer une CLI aux équipes de développement pour leur faciliter la création de ces objets Kubernetes ?

Pourquoi une CLI plutôt qu’un script ?

J’aurais pu créer un simple script Python ou Bash, mais j’ai choisi de développer une CLI complète en Golang pour plusieurs raisons :

1. Outillage : Le Golang est le langage utilisé chez mon client, il y a déjà des bonnes pratiques de développement, des pipelines CICD mis en place, et la connaissance des équipes de développement pour reprendre en main l’outil.
2. Réutilisabilité : Une CLI bien conçue peut être utilisée par toutes les équipes applicatives sans difficulté. Le cœur de la CLI est une librairie qui pourra être aisément intégrée dans d’autres outils de l’équipe
3. Expérience utilisateur : Commandes claires, aide intégrée, messages d’erreur explicites ce qui facilitera l’onboarding des équipes applicatives
4. Évolutivité : Plus facile d’ajouter de nouvelles fonctionnalités (validation, preview, différents formats de sortie) que d’un script bash
5. Distribution : Facile à installer et à maintenir

Vision de l’architecture

  flowchart TB
CSV["Matrice de flux
(CSV)
━━━━━━━━━━━━━━━━━
frontend,app:frontend,backend,app:backend,8080,tcp"]

subgraph CLI["🛠️ CLI - np-converter"]
  direction TB
  Parse["1️⃣ Parser
Lecture & validation CSV"]
  Model["2️⃣ Modélisation
Création objets métier"]
  Generate["3️⃣ Générateur
Conversion en CiliumNetworkPolicy"]
end

YAML["Network Policy (YAML)
━━━━━━━━━━━━━━━━━
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: frontend-to-backend
..."]


CSV --> Parse
Parse --> Model
Model --> Generate
Generate --> YAML

style CSV fill:#e1f5ff,stroke:#0288d1,stroke-width:2px
style CLI fill:#fff3e0,stroke:#f57c00,stroke-width:2px
style Parse fill:#ffe0b2,stroke:#f57c00
style Model fill:#ffe0b2,stroke:#f57c00
style Generate fill:#ffe0b2,stroke:#f57c00
style YAML fill:#e8f5e9,stroke:#388e3c,stroke-width:2px

Cette architecture en trois étapes — parsing, modélisation, génération — constitue le cœur de la CLI — J’avais une idée claire de l’architecture logicielle que je voulais mettre en place. La couche métier doit être réutilisable sous forme d’une librairie. J’avais donc en tête de faire cette CLI sous forme d’architecture hexagonale pour être facilement étendue — peut-être overkill vous me direz mais qui a fait ses preuves.

Je voulais pouvoir aisément prendre en charge :

• Différents types de fichiers en entrée : CSV, YAML, JSON
• Différents types de sorties : Cilium, Kubernetes standard, ou autres CNI
• Plusieurs commandes : validate, preview, generate et qui serait facilement extensible ultérieurement.
• Mode verbose : Pour faciliter le diagnostic et le debug

Et si je me faisais aider d’une IA ?

Cette architecture hexagonale bien pensée, ces multiples adaptateurs, ces commandes extensibles… J’avais le design en tête, mais l’implémenter proprement prendrait du temps : facilement 2 à 3 semaines pour développer la CLI avec ses différents adaptateurs (CSV, YAML, JSON), ses générateurs (Cilium, Kubernetes standard), et tous les tests qui vont avec.

Du temps que je n’avais pas vraiment, entre mes autres responsabilités de SRE dans l’équipe, pour un outil qui ne servirait au final que quelques fois par an lors de la configuration initiale des network policies.

C’est là qu’une idée s’est imposée : et si c’était justement l’occasion parfaite de tester en conditions réelles les assistants de code dont on parlait tant ? Un vrai projet avec de la valeur métier, une architecture claire, mais un budget temps limité.

Depuis un an, j’anime avec un collègue un groupe de travail à propos de l’IA générative au sein de ma société. Nous faisons de la veille, nous créons des prototypes pour monter en compétences ou faisons des présentations en interne pour vulgariser les concepts.

Je me suis alors dit que c’était l’occasion de m’aider d’un assistant de code pour créer cette CLI.

C’est cette réflexion qui a lancé mon aventure dans le “vibe coding”.

Les questions qui se posent alors

Avant de me lancer, plusieurs questions me viennent à l’esprit :

• Est-ce que ça va vraiment marcher ? Est-ce qu’une CLI générée par un assistant de code sera de qualité professionnelle et maintenable ?
• Combien de temps ça va prendre ? Plus ou moins qu’un développement classique ?
• Quelle sera la qualité du code ? Est-ce que l’assistant de code respectera l’architecture logicielle définie ? Est-ce que le code sera facilement testable ?
• Quelle sera ma vraie valeur ajoutée ? Qu’est-ce que je fais en tant que senior, qu’est-ce que l’IA fait ?

Autant de questions auxquelles je vais pouvoir répondre en expérimentant concrètement.

Dans le prochain article

Maintenant que le contexte est posé, il est temps de choisir l’outil qui va m’accompagner dans cette aventure. Dans le prochain article, je vous explique :

• Pourquoi j’ai choisi Claude Code parmi tous les assistants de code disponibles
• Mon expérience d’animation de la communauté IA chez WeScale
• Le processus d’évaluation que nous avons mis en place
• Les forces spécifiques de Claude Code pour ce type de projet

👉 Lire la partie 2 : Pourquoi Claude Code ?