Claude Code dans un terminal vs copier-coller dans un chatbot web : ce qui change vraiment pour l’admin système

Avant d’installer Claude Code, j’utilisais Claude.ai dans un onglet du navigateur, à côté de mon terminal SSH sur heighliner. Copier une config, la coller dans le chat, lire la réponse, copier le résultat, le coller dans le terminal. Ça a fonctionné pendant des mois. Puis j’ai testé Claude Code, et je n’ai quasiment plus rouvert l’onglet.

Ce n’est pas parce que le modèle est différent – c’est le même. C’est le workflow autour qui change tout, et je pense que beaucoup de gens sous-estiment à quel point.

Le vrai problème du copier-coller : le contexte s’effondre

Dans le navigateur, chaque échange demande de re-fournir le contexte manuellement. Je veux que Claude regarde ma config nginx et mes logs d’erreur et ma crontab pour comprendre pourquoi un reverse proxy timeout de façon intermittente ? Trois copier-coller, dans le bon ordre, en espérant ne rien oublier.

Avec Claude Code dans le répertoire /etc/nginx/, la demande devient :

Regarde grafana.conf, et croise avec les 200 dernières lignes de
error.log. Il y a des timeouts intermittents sur /api/, je veux
comprendre le pattern.

Il lit les fichiers lui-même. Pas de copier-coller, pas de risque d’oublier une ligne de log pertinente parce que je l’ai tronquée en collant.

Ça a l’air d’un détail de confort. Ce n’en est pas un : la qualité de la réponse dépend directement de la qualité du contexte fourni, et un humain fatigué un vendredi soir fournit un contexte moins bon en copier-collant à la main qu’un outil qui lit le fichier entier automatiquement.

Ce que ça change pour la vérification

Contre-intuitivement, le CLI m’a rendu plus rigoureux sur la vérification, pas moins. Dans le navigateur, je copiais souvent la réponse et l’exécutais directement – une friction en moins signifie une vérification en moins aussi.

Avec Claude Code, chaque commande ou modification de fichier proposée passe par une confirmation explicite avant exécution. Je vois la commande exacte, je peux dire non, je peux demander « pourquoi cette commande précisément » avant d’accepter. Ce point de friction supplémentaire – contre-intuitivement positif – m’a évité au moins une commande destructive que j’aurais probablement exécutée sans réfléchir dans l’ancien workflow copier-coller.

Là où le chatbot web reste suffisant, honnêtement

Je ne vais pas prétendre que le CLI est strictement supérieur pour tout. Trois cas où je rouvre encore l’onglet navigateur :

Réfléchir à une architecture avant d’avoir du code. Si je veux discuter d’une approche – « est-ce que je segmente mon réseau IoT différemment ? » – sans fichiers concrets à analyser, le chat web fait exactement le même travail, sans qu’un accès au système de fichiers apporte quoi que ce soit.

Sur mobile, en déplacement. Claude Code est un outil de terminal. Pour une question rapide depuis mon téléphone dans le train, l’appli ou le site web est simplement plus pratique – je ne vais pas ouvrir une session SSH sur mon téléphone pour une question théorique.

Générer du texte qui n’a rien à voir avec du code ou de l’infra. Rédiger l’intro de cet article, par exemple. Le CLI n’apporte rien de plus qu’un chat classique pour ce genre de tâche.

Le vrai gain : moins de perte d’information entre les étapes

Après plusieurs mois, ce que je retiens surtout, ce n’est pas la vitesse – le CLI n’est pas nécessairement plus rapide qu’un copier-coller bien exécuté. C’est la réduction du nombre d’endroits où l’information peut se perdre ou se corrompre : un log tronqué en collant, un fichier oublié dans le contexte, une commande copiée avec une coquille de ma part en la retapant.

Chaque étape manuelle entre « voir le problème » et « appliquer la solution » est une occasion d’introduire une erreur. Le CLI n’élimine pas ces étapes – il les automatise, ce qui n’est pas la même chose que les rendre infaillibles, mais qui réduit clairement leur nombre.

Ce qui m’a fait douter au début

Honnêteté totale : donner à un outil la capacité d’exécuter des commandes sur heighliner, même avec confirmation à chaque étape, m’a mis mal à l’aise les deux premières semaines. J’ai commencé sur un LXC de test sans rien de critique dessus, pas directement sur les services en production chez moi.

Ce test préalable n’était pas superflu. J’ai vu, sur ce LXC jetable, une commande proposée qui aurait supprimé un répertoire entier plutôt qu’un seul fichier – une ambiguïté dans ma propre demande, pas une erreur du modèle, mais qui m’a confirmé que la vérification à chaque étape n’est pas une formalité. Après ça, je me suis senti plus à l’aise pour l’utiliser sur des services réels, toujours avec la même vigilance.

Verdict, sans détour

Pour tout ce qui touche à des fichiers réels sur heighliner ou hubble – configs, logs, scripts – le CLI a remplacé le chatbot web chez moi, largement. Pour tout le reste – réflexion, questions générales, mobile – le chatbot web reste ce qu’il a toujours été : suffisant, et parfois plus pratique.

Ce n’est pas un outil qui remplace l’autre. C’est un outil de plus dans la boîte, à sortir quand le problème implique des fichiers réels plutôt que des idées abstraites.