Claude Code dans mon terminal : comment j’administre heighliner avec une IA à côté

Il y a quelques mois, j’ai commencé à utiliser Claude Code – le CLI d’Anthropic – dans mes sessions d’administration serveur. Pas comme oracle, pas comme remplaçant de la documentation, mais comme un collègue de terminal. Quelqu’un à qui je peux dire « regarde cette crontab, est-ce qu’il y a quelque chose qui cloche ? » et qui donne une réponse exploitable.

Le résultat m’a surpris, dans les deux sens. Il y a des cas où Claude Code a trouvé des bugs que j’aurais mis des heures à trouver seul. Et il y a des cas où j’ai failli appliquer ce qu’il m’avait suggéré et heureusement que j’ai revérifié avant.

Voilà mon workflow réel, avec les exemples concrets, les limites honnêtes, et quelques tips de prompt engineering pour le contexte infra.

Ce qu’est Claude Code (et ce que ce n’est pas)

claude est un CLI. On l’installe avec npm (npm install -g @anthropic-ai/claude-code), on l’exécute dans un terminal, et il peut – avec permission – lire des fichiers dans le répertoire courant, exécuter des commandes shell, et naviguer dans la structure de fichiers.

Ce n’est pas un agent autonome qui va aller modifier vos configs à votre insu. Chaque action qu’il propose de faire (écrire un fichier, exécuter une commande) passe par une confirmation. En mode interactif, il explique ce qu’il fait avant de le faire.

Pour l’administration serveur, j’utilise deux modes :

Mode conversationnel : claude sans argument, session interactive. Je décris un problème, il analyse, on échange. Utile pour débugger, comprendre un comportement, revue de config.

Mode one-shot : claude -p "..." avec un prompt direct. Utile pour générer rapidement un script ou une commande que j’adapte ensuite.

Le premier cas qui m’a convaincu : la crontab cassée depuis 6 mois

C’est l’histoire qui m’a fait prendre Claude Code au sérieux pour l’administration système.

J’avais un script de rotation de logs Proxmox qui était censé archiver les logs journalctl des services PVE une fois par semaine. Il était dans ma crontab depuis juin 2025. Je pensais qu’il fonctionnait. Je ne l’avais jamais vraiment vérifié.

Un jour, je cherchais des logs anciens et j’ai réalisé qu’il n’y avait rien. Pas d’archives. Le script tournait (je le voyais dans journalctl avec des timestamps réguliers), mais il ne produisait rien.

J’ai ouvert une session Claude Code dans le répertoire /opt/homelab-scripts/ et j’ai demandé :

Regarde le script log-rotation.sh et ma crontab (je vais te coller le contenu).
Est-ce qu'il y a quelque chose qui pourrait expliquer que le script s'exécute
mais ne produit aucune archive ?

J’ai collé le contenu du script et de la crontab. Claude Code a répondu en moins de 30 secondes :

« Le problème est probablement dans la ligne 14 de log-rotation.sh. La variable $OUTPUT_DIR est définie dans le script, mais la crontab l’exécute comme bash /opt/homelab-scripts/log-rotation.sh sans charger l’environnement utilisateur. Résultat : $OUTPUT_DIR est vide, journalctl ... > /dev/null en pratique, et aucune archive n’est créée. Aucune erreur visible parce que bash crée un fichier avec un nom vide plutôt que d’échouer.

Solution : soit exporter OUTPUT_DIR dans /etc/environment, soit la définir directement dans le script plutôt que de la lire depuis l’environnement. »

J’ai vérifié. C’était exactement ça. Six mois de script silencieusement cassé, trouvé en 30 secondes.

Ce que Claude Code a fait là n’est pas magique – c’est ce que n’importe quel sysadmin expérimenté aurait repéré en lisant attentivement le script. Mais moi, je lisais le script depuis des mois sans voir le problème parce que je le lisais avec mes a priori. L’IA n’a pas d’a priori.

Écrire des scripts Proxmox : le workflow

Voilà comment je travaille maintenant pour un script nouveau.

1. Décrire le besoin avec le contexte technique.

La précision du contexte fait 80 % de la qualité du résultat. « Écris-moi un script bash pour Proxmox » donne quelque chose de générique. « Écris-moi un script bash pour heighliner (Proxmox VE 8.4, nœud unique, pas de cluster) qui… » donne quelque chose d’utilisable.

Exemple de prompt que j’ai utilisé :

J'ai un nœud Proxmox VE 8.4 (heighliner, MS01 Mini PC, 32 GB RAM).
J'ai besoin d'un script bash qui :
1. Liste toutes les VMs et LXC avec leur état (running/stopped)
2. Pour les VMs qui sont stopped depuis plus de 7 jours (selon le log
   de Proxmox), les archive dans un fichier JSON horodaté
3. Envoie le résultat par curl sur mon webhook Telegram

Les outils disponibles : pvesh, qm, pct, jq. Pas de Python sur ce nœud.

2. Réviser le script généré avant de l’exécuter.

Claude Code produit du bash syntaxiquement correct, mais il ne connaît pas votre environnement précis. Dans le script généré ci-dessus, il utilisait pvesh get /nodes/localhost/... – correct en général, mais mon nœud s’appelle heighliner dans Proxmox, pas localhost. Ce genre de détail doit être vérifié.

# Ce que Claude a généré (générique)
pvesh get /nodes/localhost/qemu --output-format json

# Ce qui fonctionne chez moi
pvesh get /nodes/heighliner/qemu --output-format json

3. Demander une revue du script corrigé.

Après avoir adapté le script, je le repasse à Claude Code pour une deuxième lecture :

Voilà le script corrigé. Regarde-le d'un oeil de sécurité :
est-ce qu'il y a des edge cases non gérés, des risques si une
commande échoue, des problèmes de permissions à prévoir ?

Cette deuxième passe trouve souvent des set -euo pipefail manquants, des || true là où on devrait propager l’erreur, des commandes qui ne gèrent pas le cas « résultat vide ».

Débugger des playbooks Ansible

Je maintiens quelques playbooks Ansible pour heighliner – la configuration de base, les packages, les paramètres réseau. Ce n’est pas une infrastructure massive, mais Ansible a ses pièges.

Un exemple concret : j’avais un playbook qui échouait silencieusement sur une tâche blockinfile. Le play finissait avec « changed: [heighliner] » mais la config cible n’était pas modifiée. Erreur classique dans Ansible, mais difficile à diagnostiquer quand on est fatigué.

J’ai demandé à Claude Code :

Ce playbook Ansible s'exécute sans erreur mais ne produit pas le résultat
attendu. La tâche blockinfile est censée ajouter un bloc dans /etc/sysctl.conf
mais le fichier n'est pas modifié. Voilà le playbook et le contenu actuel
du fichier.

Il a repéré que le marker que j’utilisais dans blockinfile contenait des caractères spéciaux qui n’échappaient pas correctement dans le YAML. Le bloc était « inséré » puis immédiatement supprimé parce que le marker de fin ne matchait pas. Quarante minutes de debug économisées.

Revue de configuration : ce que ça vaut (et ce que ça ne vaut pas)

J’utilise Claude Code pour passer en revue des configs avant de les appliquer. Typiquement : les fichiers de configuration Proxmox, les règles iptables, les configs Nginx pour les reverse proxies de hubble (mon VPS OVH de monitoring).

La règle d’or que j’ai apprise : donner le contexte de ce que le fichier est censé faire, pas juste le fichier.

Sans contexte :

Regarde cette config iptables, est-ce qu'elle est correcte ?

Résultat : Claude commente chaque règle de façon générique. Pas inutile, mais pas très utile non plus.

Avec contexte :

Cette config iptables est sur heighliner (Proxmox, nœud homelab, pas en prod).
L'objectif : accepter SSH depuis mon réseau local (192.168.1.0/24) seulement,
exposer Proxmox UI (port 8006) uniquement depuis ce même réseau, et bloquer
tout le reste en entrée. Le nœud est derrière un routeur qui fait du NAT.
Vérifie que les règles correspondent à cet objectif et signale ce qui pourrait
poser problème.

Avec ce contexte, la réponse est ciblée. Dans mon cas, il a signalé que je n’avais pas de règle pour le trafic établi/associé (-m state --state ESTABLISHED,RELATED -j ACCEPT) – la règle d’acceptation des connexions établies. Sans elle, les réponses à mes connexions sortantes auraient été bloquées. Bug réel.

Ce que Claude Code ne fait pas bien en contexte sysadmin

Honnêteté totale sur les limites.

Il ne connaît pas votre setup précis. Claude Code n’a pas accès à votre Proxmox, votre réseau, vos VMs. Il raisonne sur le texte que vous lui fournissez. Si vous lui donnez une config incomplète ou si votre setup dévie de la norme documentée (versions particulières, patches, comportements locaux), il peut raisonner correctement sur des données fausses.

Les versions comptent. Proxmox 8.4 n’est pas Proxmox 7.4. Les commandes pvesh, les options pct et qm, les paths de configuration changent entre versions. Claude a une date de coupure de connaissance, et les versions très récentes (ou les patches très récents) peuvent le faire dériver vers des syntaxes obsolètes. Vérifiez toujours contre man et la documentation officielle.

Il peut être trop optimiste. Sur des questions de sécurité, Claude Code a tendance à lister les bonnes pratiques générales même quand elles ne s’appliquent pas à votre cas. « Vous devriez activer SELinux » dans un contexte homelab Debian où SELinux n’est pas installé et où AppArmor fait le travail – c’est techniquement correct mais inutile. Apprenez à filtrer les recommandations génériques des observations spécifiques à votre situation.

Il ne testera pas le script pour vous. Il peut écrire un script bash parfait syntaxiquement qui fait quelque chose de légèrement différent de ce que vous voulez. La vérification reste de votre côté. Pour tout ce qui touche à la configuration réseau ou à la gestion de VMs, je teste toujours d’abord sur une VM de test ou avec un --dry-run si disponible.

Tips de prompt engineering pour l’infra

Quelques patterns que j’ai affinés au fil des semaines :

Pattern 1 : « Sans contexte, avec contexte »

Pour les scripts, toujours commencer par poser le contexte technique avant la demande. OS, version, contraintes, outils disponibles.

Environnement : Debian 12, Proxmox VE 8.4, pas de cluster.
Outils disponibles : bash, jq, curl, pvesh, qm, pct.
Python non disponible sur ce nœud.
Objectif : [votre demande]

Pattern 2 : Séparer la génération de la revue

Ne demandez pas à Claude de générer ET de vérifier en même temps. Générez d’abord, puis dans un deuxième prompt, demandez la revue. Les deux opérations activent des modes de raisonnement différents.

Pattern 3 : La question de l’edge case

Après chaque script généré, demandez systématiquement :

Qu'est-ce qui se passe si [commande X] échoue ou retourne vide ?
Est-ce que le script gère ce cas ou est-ce qu'il continue silencieusement ?

Cette question trouve presque toujours quelque chose dans les scripts bash qui gèrent du JSON ou des outputs de commandes système.

Pattern 4 : Demander l’explication, pas juste la solution

Avant de me donner le fix, explique-moi pourquoi ça ne fonctionne pas.

Cette formulation force Claude à articuler son diagnostic, ce qui me permet de valider que son raisonnement est correct avant d’appliquer le fix. Si l’explication ne tient pas la route, le fix ne le tiendra probablement pas non plus.

Le workflow au quotidien

En pratique, voilà à quoi ressemble une session type. Je suis connecté en SSH sur hubble, je veux modifier la configuration Nginx d’un reverse proxy.

# Sur hubble, dans le répertoire des configs
cd /etc/nginx/sites-available/

# Je lance Claude Code avec le fichier ouvert comme contexte
claude

# Dans la session interactive :
# "Regarde le fichier grafana.conf dans ce répertoire.
#  Je veux ajouter un header X-Frame-Options SAMEORIGIN
#  sans casser les iframes Grafana qui s'embarquent
#  dans mon dashboard interne. Est-ce que c'est possible
#  et comment ?"

Claude Code lit le fichier, explique le compromis (SAMEORIGIN bloquera les iframes depuis d’autres origines, ALLOW-FROM est déprécié, la vraie solution moderne est Content-Security-Policy avec frame-ancestors), me propose la modification exacte à faire dans le fichier. Je la lis, je comprends le pourquoi, j’applique ou j’adapte.

Ce n’est pas de la magie. C’est de la documentation interactive avec contexte.

Est-ce que ça change vraiment quelque chose ?

Trois mois de pratique, verdict honnête : oui, mais pas de la façon spectaculaire qu’on pourrait imaginer.

Le gain principal est sur les tâches que je maîtrise partiellement. Pour les trucs que je fais tous les jours, Claude Code n’apporte pas grand-chose – je suis plus rapide sans lui. Pour les trucs que je fais rarement (configurer un service obscur, écrire du bash dans un domaine où je suis moins à l’aise, débugger un comportement que je n’ai jamais vu), il est précieux.

Le deuxième gain est sur la relecture. Les bugs que j’ai dans mes propres scripts, je ne les vois plus parce que je relis avec mes présuppositions. Claude Code relit sans présuppositions. C’est ce qui a trouvé la crontab cassée.

Ce que ça ne remplace pas : la compréhension profonde du système. Si je n’avais pas compris pourquoi les variables d’environnement ne se propagent pas dans cron, je n’aurais pas su évaluer si l’explication de Claude était correcte. L’IA est un amplificateur de compétence, pas un substitut.

Article connexe : Briefing ops quotidien avec l’API Claude et Prometheus →