Bonjour à tous,
Cela fait quelques mois que j’utilise Claude (surtout Claude Code) au quotidien, au boulot comme à la maison, et on me demande assez souvent comment je m’en sers concrètement.
Je vous fais donc un petit retour sur ma façon de l’utiliser, les garde-fous que j’ai mis en place et les quelques projets où il m’a vraiment fait gagner du temps.
Le but de cet article n’est pas de vous vendre de l’IA à toutes les sauces, mais de vous montrer ce qui marche (et ce qui ne marche pas) pour mon usage (pour ce que j’en ai fait jusqu’à maintenant).
Pourquoi Claude Code
J’ai testé pas mal de choses, y compris des modèles en local (je vous en parlais ici : faire tourner ses modèles d’IA en local avec Ollama et Open WebUI), mais ce qui m’intéresse vraiment, ce n’est pas de la génération de code (pas que).
Claude Code tourne directement sur mon poste, il lit les logs, les exports de config et les scripts que je lui donne, et il travaille avec. Pour du diagnostic ou de la doc, c’est là que ça devient intéressant.
Et surtout, les petits outils deviennent enfin rentables : le script qui fait gagner 10 minutes par semaine, je ne l’aurais jamais pris une demi-journée pour l’écrire, maintenant ça prend une demi-heure.
Les règles du jeu
Je ne lâche pas un assistant IA sur des infras clients sans cadre, donc voilà comment je fonctionne.
Chaque projet a son dossier, synchronisé sur mon Nextcloud, avec un fichier CLAUDE.md dedans qui explique le contexte, les conventions et les pièges déjà rencontrés, de cette façon, chaque nouvelle session repart avec la mémoire du projet au lieu de tout redécouvrir.
J’ai aussi un fichier de règles globales dans %USERPROFILE%\.claude\CLAUDE.md qui s’applique partout. En voici un bout :
# Global rules - Never add attribution, watermarks, or "generated by Claude/AI" notes to any output: commits, PRs, issues, code comments, docs, files, emails, or messages. - No Co-Authored-By: Claude trailers. ## Délégation du développement aux modèles locaux / Ollama 1. Ollama Cloud (gpt-oss:120b-cloud) tant qu'il reste du quota. 2. Serveur Ollama réseau (qwen3-coder:30b). 3. Ollama local uniquement si un GPU NVIDIA est présent.
Pour le reste, c’est du bon sens : pas de mention d’IA dans ce que je livre (c’est mon travail, je l’ai relu et j’en suis responsable).
Les plugins : Caveman et Ponytail
Par défaut, Claude est bavard. Très bavard. Les pavés de trois pages pour une question simple, très peu pour moi, et en plus chaque mot se paie en tokens.
J’utilise donc deux plugins de la communauté :
- Caveman (https://github.com/JuliusBrussee/caveman) : il force des réponses courtes, la réponse d’abord, sans politesses ni récap. Les commandes, chemins et messages d’erreur restent exacts, seul le blabla disparaît.
- Ponytail (https://github.com/DietrichGebert/ponytail) : c’est le « dev senior fainéant ». Avant d’écrire du code, il se demande si ça doit exister, si ça existe déjà dans le projet, si la lib standard le fait déjà… Bref, la solution la plus simple qui marche, au lieu de trois couches d’abstraction pour un script de 20 lignes.
Ils s’installent depuis leur marketplace GitHub dans Claude Code :
/plugin marketplace add JuliusBrussee/caveman /plugin install caveman@caveman /plugin marketplace add DietrichGebert/ponytail /plugin install ponytail@ponytail
J’ai aussi une petite status line qui affiche le mode actif des deux plugins en bas de Claude Code, pour savoir où j’en suis.
Faire coder Ollama, faire relire Claude
C’est la deuxième partie de mes règles globales : Claude n’écrit pas le code lui-même (sauf quand je suis pressé).
Il prépare une tâche précise (le fichier, les changements exacts, « ne modifie rien d’autre » et comment savoir que c’est fini), et c’est un modèle open source via Ollama qui écrit le code. Ensuite Claude relit le diff, lance les tests et merge. Si le diff est faux, il renvoie une consigne de correction au modèle au lieu de corriger lui-même.
Pour ça, j’ai écrit un petit script PowerShell, local-worker.ps1, qui fait tout le travail :
- Il choisit le modèle : Ollama Cloud (gpt-oss:120b-cloud, gratuit dans la limite du quota), et si le quota est épuisé, un serveur Ollama sur mon réseau (qwen3-coder:30b), et en dernier recours l’Ollama local, mais uniquement s’il y a un GPU NVIDIA (un modèle de 20 Go sur CPU, ce n’est pas la peine).
- Il crée une branche local/<nom> dans un worktree git séparé, pour ne jamais toucher à la branche de travail.
- Il lance aider avec le modèle sur les fichiers indiqués, puis commite le résultat.
Le cycle complet, avec la boucle de correction :
Concrètement, ça donne ça :
local-worker.ps1 -e aider fix-encoding "In md2docx.py, replace the Unicode characters in every print() with ASCII equivalents. Change nothing else." md2docx.py git diff main...local/fix-encoding git merge --no-ff local/fix-encoding
J’ai testé Claude Code en mode headless branché sur gpt-oss comme moteur, mais il avait la fâcheuse tendance à se relancer lui-même dans des sous-worktrees et à poser des questions au lieu de modifier, donc aider est bien plus fiable pour ça.
Résultat : ça coûte beaucoup moins cher, et chaque changement arrive dans une branche à part avec un commit, donc rien n’arrive sur main sans relecture.
Et pour les projets où je veux que Claude code directement, je mets simplement une exception dans le CLAUDE.md du projet.
Le script et la doc pour l’installer sont dispo ici : https://github.com/stylersnico/claude-ollama-worker
Les données clients ne passent pas par Claude
C’est le point le plus important, donc je le mets à part.
Quand je dois traiter des données réelles (exports de config, logs, inventaires…), je ne les donne pas à Claude. Je lui fournis des données d’exemple avec exactement la même structure (un export anonymisé ou carrément fabriqué), il m’aide à écrire les scripts à partir de ça, et ensuite ce sont ces scripts qui tournent sur les vraies données, en local, sur ma machine.
Bonus : on se retrouve avec des scripts réutilisables, au lieu d’une conversation qu’on ne retrouvera jamais.
La doc d’infra et de sauvegarde qui s’écrit toute seule
C’est probablement le projet qui m’a fait gagner le plus de temps au boulot.
Une doc d’infra écrite à la main, ça prend des jours et c’est déjà faux le jour où on la livre. Du coup j’ai monté une chaîne en trois étapes.
D’abord la collecte : des scripts PowerShell en lecture seule exportent la configuration réelle en JSON. Hôtes Hyper-V et VM, rôles et logiciels des serveurs, Active Directory, Microsoft 365, supervision PRTG, DNS public, switches…
Aucun mot de passe n’est demandé ni enregistré, et tout ce qui ressemble à un secret est filtré à l’export.
Ensuite la sauvegarde, qui a droit à son propre traitement parce que c’est rarement un seul logiciel chez un client. Ça peut être un mélange de Veeam Backup & Replication, Veeam Backup for Microsoft 365, Iperius Backup, Synology Hyper Backup, et même le cron qui fait un dump SQL avant que tout ça passe.
Pour Veeam, l’export sort tout : infra, jobs, rétentions, GFS, immuabilité, bandes, notifications. Pour les autres, je pars du rapport de config Iperius en PDF ou de captures d’écran des tâches Hyper Backup.
À partir de là, on génère un schéma Visio avec les stencils officiels Veeam, avec les flux numérotés de bout en bout (le dump SQL de 7h30, récupéré par Iperius à 8h, dans une VM sauvegardée par Veeam…), plus les tableaux des jobs et des rétentions.
Deux règles :
- On documente la configuration, pas l’état. Le dernier succès d’un job ou la taille d’un backup, ça change tous les jours, ça n’a rien à faire dans une doc.
- Une info introuvable s’écrit « Non documenté » et devient un point d’attention à vérifier. Jamais de valeur inventée (l’IA a une fâcheuse tendance à combler les trous si on ne lui dit pas).
Et pour finir l’assemblage : un générateur Python prend tous les JSON et le schéma de sauvegarde, et sort un seul document Word et PDF aux couleurs de la boîte.
Pour résumer tout ça en un schéma :
Un audit d’infra qui me prenait plusieurs jours se fait maintenant en quelques heures, il se régénère quand quelque chose change, et le schéma de sauvegarde sert directement de base pour les tests de restauration annuels.
La réponse à incident
Même logique que pour la doc : les vrais journaux ne partent pas chez Claude.
Pour SentinelOne, on a écrit des scripts qui prennent les exports de la console (kill report, recherches Deep Visibility en CSV) et qui sortent un résumé de l’incident : la chaîne de processus, les fichiers touchés, les horaires. Pour Office 365, même principe avec les journaux de connexion Entra ID et l’audit unifié : qui s’est connecté d’où, avec quelle méthode d’authentification, et ce qui a été fait derrière.
Tout ça tourne en local, et le résultat part dans mes propres modèles de note d’incident en Word et PDF. Claude n’a vu que des exemples pour écrire les scripts, jamais les données du client.
Il ne décide rien à ma place, mais il mâche tout le travail de lecture, et un faux positif est repéré en quelques minutes au lieu d’une heure à éplucher des CSV.
Naxsi et CrowdSec sur mon reverse proxy perso
C’est la suite de mon article sur le reverse proxy FreeBSD : avec Claude, j’ai durci le nginx qui est devant toutes mes applis auto-hébergées.
En gros, Naxsi fait office de WAF requête par requête, et CrowdSec passe par-dessus pour bannir les IP qui ont un comportement louche, directement dans PF (et pas via le module LUA de nginx). Il y a aussi du rate limiting par vhost et des en-têtes de sécurité globaux qui passent toujours devant ceux du backend.
Le plus long, et de loin, ça a été les whitelists Naxsi. À part WordPress, il n’existe aucun jeu de règles communautaire pour mes applis, donc tout a été écrit à partir du trafic réel. Et sur certaines applis (CheckMK pour ne pas le citer), ça devenait tellement sans fin que je suis passé en mode « login uniquement » : Naxsi ne protège que la page de connexion et laisse tranquille tout le reste.
C’est typiquement là que Claude aide énormément : il lit les naxsi_error.log et propose la règle qui va bien.
Tout est dispo ici : https://github.com/stylersnico/Custom-Naxsi-Crowdsec-Configs
Je ne rentre pas plus dans le détail, ça fera l’objet d’un article dédié 🙂
LetsCheck pour Checkmk 3
Suite à mon passage chez CheckMK, je voulais une app mobile. LetsCheck existait, mais elle ne fonctionnait plus avec les versions récentes de Checkmk.
J’ai donc repris l’app Flutter et son SDK pour l’API REST de Checkmk 2.5 et 3 : https://github.com/stylersnico/LetsCheck-Checkmk-2.5-3
Je n’avais jamais touché à Flutter de ma vie, donc clairement sans Claude ce projet ne serait jamais sorti. Le but maintenant, c’est de reverser tout ça au projet d’origine quand j’aurai fini mes tests.
Mon infra perso documentée sur le wiki
Le générateur de doc du boulot a aussi servi à la maison : il y a une variante qui, au lieu d’un Word, sort des pages Markdown pour Wiki.js.
Le résultat est en ligne ici : https://wiki.abyssproject.net/fr/infra/infrastructure
On y trouve tout : le pare-feu OPNsense avec ses deux fibres en répartition de charge et Starlink en secours, les listes de blocage, le reverse proxy, l’hyperviseur Hyper-V, les sauvegardes Veeam vers Backblaze B2, la supervision Checkmk et l’automatisation avec Ansible et Semaphore. Les schémas sont en Mermaid, directement rendus par Wiki.js.
Comme c’est public, les règles sont encore plus strictes que pour un client : aucune adresse IP, aucun nom de domaine, aucun numéro de série ni compte. Et les points faibles que Claude a relevés pendant la rédaction, je les ai eus en conversation, mais ils ne sont évidemment pas publiés 🙂
Le réglage de ma pompe à chaleur
Celui-là est un peu hors sujet, mais ça vaut le coup aussi.
J’ai une PAC Atlantic Alfea Extensa Duo avec des radiateurs à eau, un thermostat d’ambiance radio et un ballon d’eau chaude intégré. Les réglages d’origine de l’installateur, disons qu’ils étaient… perfectibles : l’appoint électrique se déclenchait trop vite, l’eau chaude chauffait à n’importe quelle heure et les consignes ne correspondaient pas à notre rythme.
J’ai donné à Claude la notice d’installation complète (avec le menu installateur, qu’on ouvre en maintenant MENU et en tournant la molette d’un quart de tour), et mes contraintes : 21°C dans la pièce de vie, pas d’heures creuses sur le contrat et 2 kWc de panneaux solaires (https://www.abyssproject.net/2024/06/suite-et-fin-de-mon-installation-solaire/).
Ce qu’on a changé :
- Régulation 100 % sur la sonde d’ambiance au lieu d’une loi d’eau, avec les têtes thermostatiques de la pièce de la sonde ouvertes à fond pour qu’elles ne se battent pas avec le thermostat.
- L’eau chaude entre 13h et 18h, quand les panneaux produisent, avec un différentiel de commutation réduit de 7 à 5°C, une consigne confort à 55°C, ECO à 40°C et l’anti-légionelle le lundi à 13h.
- L’appoint électrique : le réglage de commutation passe de 100 à 300°C.min, pour que la résistance ne s’allume plus au premier coup de froid, et il reste autorisé seulement sous 2°C extérieur.
- La nuit, le compresseur est limité à 50 % entre 22h et 7h, et les plages de chauffage suivent les jours où on est à la maison ou au boulot.
Le plus utile, honnêtement, ça a été la liste de ce qu’il ne fallait pas toucher : temporisations du compresseur, anticipation, température de départ… Sur une PAC, c’est facile de tout casser en voulant bien faire.
Prochaine étape en janvier : si les 21°C tiennent par grand froid, baisser la température de départ maxi de 55 à 50°C, en suivant les kWh dans le menu de consommation d’énergie et l’icône d’appoint le matin.
Claude n’a rien réglé lui-même évidemment, il a lu la notice et m’a dit quoi changer et pourquoi, j’ai appliqué menu par menu.
L’optimisation de ma TV Philips Android
Toujours à la maison, mais cette fois Claude a mis les mains dedans.
J’ai une TV Philips sous Android 12 avec 2 Go de RAM, et elle ramait sérieusement. Au final, je n’utilise que SmartTube, Jellyfin et Prime Video, avec le Chromecast, la recherche vocale et Ambilight/Hue. Tout le reste, c’est des applis préinstallées, des recommandations, de la pub et du suivi d’usage.
Côté TV, il suffit d’activer les options pour les développeurs (7 appuis sur Build dans Paramètres > Système > À propos) puis le débogage USB. Sur les Philips il n’y a souvent pas d’option « débogage réseau », mais ADB écoute quand même sur le port 5555 :
adb connect 192.168.1.50:5555 adb devices
À la première connexion, adb devices affiche « unauthorized » : il faut accepter la fenêtre sur la TV en cochant « Toujours autoriser ».
Ensuite, je lui ai donné la consigne suivante :
Connecte-toi en ADB à ma TV Philips Android et optimise-la au max. Je n'utilise que SmartTube, Jellyfin et Prime Video. Je veux garder Chromecast, la recherche vocale et Ambilight/Hue. Avant de désactiver quoi que ce soit, liste les paquets et montre-moi ce que tu comptes désactiver. Utilise uniquement des méthodes réversibles et note tout dans un fichier disabled-packages.txt.
Il a listé les paquets, m’a proposé une liste, et une fois validée il a désactivé une bonne trentaine de paquets : Netflix, YouTube, Apple TV, Alexa, le navigateur et le store Philips, les recommandations Google et Philips, les loggers d’usage, l’écran de veille, PlayFi… Et il a gardé exprès le Chromecast (com.google.android.apps.mediashell), la recherche vocale (com.google.android.katniss), tout ce qui touche à Ambilight/Hue et les briques TV de base.
Rien n’est supprimé du système, tout passe par :
adb shell pm disable-user --user 0 <paquet> adb shell pm uninstall -k --user 0 <paquet>
Quelques réglages en plus, pour les animations, les scans en arrière-plan et les caches :
adb shell settings put global window_animation_scale 0.3 adb shell settings put global transition_animation_scale 0.3 adb shell settings put global animator_duration_scale 0.3 adb shell settings put global wifi_scan_always_enabled 0 adb shell settings put global ble_scan_always_enabled 0 adb shell settings put secure screensaver_enabled 0 adb shell pm trim-caches 999G adb shell cmd package bg-dexopt-job
Et pour finir, l’accueil Google TV a été remplacé par Projectivy Launcher, qui n’affiche que mes trois applis :
adb shell cmd package set-home-activity com.spocky.projengmenu/.ui.home.MainActivity adb shell pm uninstall -k --user 0 com.google.android.tvlauncher
Le plus marrant, c’est le rangement de l’accueil : Claude prend une capture de l’écran de la TV (adb exec-out screencap -p), la lit, et navigue avec la télécommande virtuelle (adb shell input keyevent DPAD_DOWN…) pour masquer les tuiles et les rangées inutiles. Il vérifie sur une capture avant chaque validation, parce que le nombre d’entrées du menu change selon l’appli.
Quelques pièges rencontrés en route :
- Certains paquets se réactivent au redémarrage, en particulier le launcher Google et PlayFi. Pour ceux-là, seul pm uninstall -k –user 0 tient.
- dumpsys meminfo expire sur ces TV, donc on regarde la mémoire avec ps -A -o RSS,NAME | sort -rn | head -30.
- Bloquer une appli en arrière-plan ne l’empêche pas forcément de se lancer au démarrage (coucou TuneIn).
- Ne surtout pas bloquer le Play Store en arrière-plan, sinon les mises à jour automatiques cassent.
Résultat : la mémoire libre est passée d’environ 420 Mo à environ 700 Mo, et la TV est enfin réactive.
Et comme tout est noté dans disabled-packages.txt, on peut tout annuler en deux commandes par paquet :
adb shell pm enable <paquet> adb shell cmd package install-existing <paquet>
Les limites
Parce qu’il y en a, évidemment.
Il se trompe, et il se trompe avec beaucoup d’aplomb. Tout est relu, et rien ne part en production sans avoir été testé.
Le gain est énorme sur ce que je connais déjà, parce que je vois tout de suite quand la réponse est fausse. Sur un sujet que je ne maîtrise pas, je dois d’abord apprendre, sinon je suis incapable de juger ce qu’il me raconte.
Et pour les données clients, je le répète : anonymisation, comptes en lecture seule, pas de secrets dans les prompts, et les vraies données restent en local.
Pour résumer, Claude ne remplace pas l’ingénieur systèmes, il enlève tout ce qui traîne : la doc, les scripts « on verra plus tard », la lecture de logs à rallonge. Le temps gagné, je le mets dans ce qui m’intéresse vraiment.
Tous mes outils publics sont sur mon Github : https://github.com/stylersnico 🙂
