J’utilise Claude Code tous les jours depuis presque un an. Avec le temps, j’ai compris que la vraie économie ne vient ni du modèle choisi, ni d’un prompt parfait : elle vient de la façon dont on répartit le travail entre les scripts Bash et les skills.
Le piège du « tout confier à l’agent »
Quand on découvre un agent de code (coding agent) comme Claude Code, le réflexe est de tout lui déléguer. Y compris les tâches les plus mécaniques : découvrir le contexte d’un projet, poser trois questions de cadrage, créer une arborescence de dossiers, deviner où ranger un fichier.
Le problème, c’est que chacune de ces actions est facturée en jetons (tokens) et consomme du temps de raisonnement pour un résultat qui n’en demande aucun. Plus la tâche est répétitive, plus le déséquilibre se creuse :
- Plus lent : l’agent explore au lieu d’exécuter.
- Plus cher : chaque jeton dépensé à redécouvrir le contexte est facturé.
- Plus d’erreurs : l’agent réinvente à chaque fois ce qui devrait être figé.
Confier une tâche déterministe à un système probabiliste, c’est payer le prix fort pour introduire de l’incertitude là où il n’en faut pas.
Bash pour le mécanique, le skill pour le raisonnement
La solution que j’applique repose sur une division claire du travail. Bash gère tout ce qui est mécanique et déterministe. Les skills gèrent ce qui demande du raisonnement : interprétation, rédaction, décisions contextuelles.
Concrètement, j’utilise deux types de scripts qui correspondent à deux moments différents du flux de travail.
Cas 1 : préparer le contexte avant de lancer Claude
Le premier type, ce sont des scripts Bash interactifs qui préparent le terrain en amont.
Le script pose lui-même les questions, collecte les variables métier, génère l’arborescence du projet et écrit un fichier CLAUDE.md déjà rempli. Quand Claude démarre, tout est en place : il n’a rien à découvrir, rien à deviner. Il commence directement à raisonner sur une base solide.
L’économie est double : aucun jeton dépensé en exploration, et un contexte identique à chaque lancement. La reproductibilité d’un script remplace l’improvisation d’un agent.
Cas 2 : déléguer une tâche lourde depuis un skill
Le second type intervient pendant l’exécution. Un skill peut déléguer une tâche coûteuse à un script Bash, attendre sa fin, puis reprendre la main.
Un exemple concret tiré de mon propre flux de travail : un pipeline qui transcrit de l’audio en texte avec Whisper, range les fichiers transcrits dans les bons dossiers, puis envoie une notification Telegram. Le skill orchestre, mais ce sont les scripts qui font le travail lourd.
Le mécanisme du passage de relais
Le point technique qui rend tout cela fluide est simple : le script Bash émet un marqueur sur sa sortie standard (stdout) en fin d’exécution, par exemple TRANSCRIPTION_DONE: 3 files generated.
#!/usr/bin/env bash
set -euo pipefail
INPUT_DIR="${1:?Usage : transcribe.sh <dossier>}"
count=0
for file in "$INPUT_DIR"/*.m4a; do
[ -e "$file" ] || continue
# ... transcription réelle ici ...
count=$((count + 1))
done
# Marqueur de fin lu par le skill
echo "TRANSCRIPTION_DONE: ${count} files generated"
La dernière ligne est un contrat : le préfixe TRANSCRIPTION_DONE: est un marqueur que l’on choisit une fois et que le skill reconnaît. On peut y placer un compteur, un chemin ou un statut — tout ce dont l’agent a besoin pour décider de la suite.
Le skill lit ce marqueur dans le résultat du script et enchaîne automatiquement les étapes suivantes, sans demander de confirmation. Le relais se passe sans intervention humaine, et surtout sans que l’agent ait dépensé le moindre jeton à superviser une tâche purement mécanique.
Pour l’adapter à un autre usage, il suffit de remplacer le contenu du script par sa propre tâche — construction (build), export, conversion — en conservant le marqueur de fin. Le skill, lui, ne change pas.
Ce n’est pas un hasard
Cette complémentarité n’a rien d’anecdotique. Boris Cherny, le créateur de Claude Code, rappelle que Bash a été le tout premier langage rendu accessible à un agent de code. Ce choix de conception dit quelque chose d’essentiel : un agent puissant a besoin d’un socle déterministe sur lequel s’appuyer.
Le résultat de cette approche est net : l’agent démarre sur une base déjà construite, le déterministe reste déterministe sans risque d’hallucination, et la facture de jetons fond.
Et vous, où placez-vous la frontière ?
La question que je me pose désormais à chaque tâche est toujours la même : est-ce que cela demande du raisonnement, ou juste de l’exécution ? Cette frontière, simple à formuler, change radicalement le coût et la fiabilité d’un flux de travail piloté par l’IA.
Si vous voulez structurer vos propres workflows Claude Code ou MCP — décider où placer le déterministe et où placer l’agent, réduire vos coûts et votre latence — je peux vous accompagner sur l’architecture comme sur l’implémentation. Parlons-en via ma page de contact.
Article publié initialement sur LinkedIn
