On ne gère pas un employé en lui donnant des instructions une par une. On lui donne un contrat, une période d'essai et un moyen de mesurer s'il vaut encore son salaire. Fable 5 mérite le même traitement.
Voici le problème. Fable 5 peut fonctionner pendant des heures sans vous, créer ses propres sous-agents et terminer une semaine de travail en une nuit. Il coûte aussi de l'argent réel par token, il sur-livre dès que vous laissez le champ libre, et il défendra une mauvaise réponse mieux que la plupart des humains ne défendent une bonne.
Laissé sans gestion, c'est un moyen coûteux de produire des absurdités avec assurance. Mis sous contrat, c'est ce qui se rapproche le plus d'un employé à temps plein que vous pouvez faire tourner pour quelques dollars par jour.
Voici ce contrat. Pas la théorie. Les fichiers réels, dans l'ordre où vous les écrivez, construits autour d'un déploiement concret : les bots de surveillance que je fais déjà tourner sur un VPS à Paris via pm2. Les flux d'authentification et les tables de facturation ne sont pas ma surface d'attaque. Les clés RPC, les adresses de portefeuille et les transactions blockchain en direct le sont. Le système ci-dessous est conçu pour cela, pas pour un dépôt SaaS générique.
Cinq sections. Chacune livre un fichier. Temps total de configuration : moins de deux heures.
La configuration
1CLI Claude (Claude Code) avec accès à Fable 5 # crédits d'utilisation, plafonné2CLI llm + clé OpenRouter # pour les modèles bon marché3jq, git, pm2, cron4un VPS avec les bots déjà en cours d'exécution
Ce que vous obtenez au final :
1agent-contract/2 CONTRACT.md # Section 1 : les conditions d'emploi3 ops/4 shift.sh # Section 3 : le shift quotidien5 dispatcher.md # prompt de routage, Fable uniquement6 intake.md # lecteur bon marché, lit les logs en premier7 worker.md # modèle bon marché, effectue la frappe8 reviewer.md # nouveau Fable, vérifie le travail9 boundaries.md # Section 2 : ce qu'il peut et ne peut pas toucher10 guardrails/signoff.sh # Section 2 : le oui/non déterministe11 personnel/12 trust.tsv # Section 4 : qui a gagné son autonomie13 standing-checks/ # Section 4 : les choses qui doivent rester vraies14 incidents/15 log.tsv # Section 5 : ce qui a cassé et quand16 runbook.md # Section 5 : quoi faire à ce sujet17 Makefile
Une règle à citer avant de commencer, car elle donne le ton pour tout le reste :
Un agent qui note ses propres devoirs est un agent qui s'augmente tout seul.
Rien dans ce système ne vérifie son propre travail. Pas une seule fois.
Section 1 : Le contrat (CONTRACT.md)
Un contrat de travail n'est pas une liste de suggestions. Ce sont des chiffres, des limites strictes et des clauses qui sont appliquées, que l'employé soit d'accord ou non. Écrivez ce fichier de la même façon. Pas de « s'il vous plaît » ni d'« essayez de ». Un modèle optimise autour d'un langage vague comme un stagiaire optimise autour d'un manager qui ne vérifie jamais.
1# CONTRACT.md23## ARRÊTS STRICTS (aucune exception, pas de demande itérée)4- Ne touchez jamais aux clés de portefeuille, aux fichiers .env ou aux identifiants RPC sans approbation.5- Ne poussez jamais une modification vers un processus bot en direct (pm2 restart) sans un signoff réussi.6- Ne dépassez jamais 150 lignes modifiées dans un seul commit sans demander d'abord.7- Ne prétendez jamais qu'une tâche est terminée en vous basant sur votre propre lecture du résultat.8 Terminé signifie que le script de signoff a retourné 0. Rien d'autre ne compte.9- N'inventez jamais de point d'API, d'adresse de contrat ou de valeur de configuration.10 Si ce n'est pas dans le dépôt, arrêtez-vous et demandez.11- N'ajoutez jamais une nouvelle dépendance. Écrivez-la dans ops/shift-log.md et arrêtez-vous là.12- Ne modifiez ni ne supprimez jamais un test, un seuil d'alerte ou une condition de surveillance pour faire13 passer quelque chose. Ce n'est pas un correctif. C'est une fraude.14- Ne travaillez jamais à un effort supérieur à « élevé » à l'intérieur d'un shift. « xhigh » est réservé aux révisions15 ponctuelles que vous déclenchez manuellement, jamais pour la boucle automatisée.16- Ne racontez ni n'expliquez jamais votre raisonnement interne dans une réponse. Cela semble17 utile. Sur Fable 5, cela peut déclencher un classificateur de refus à la place.1819## ROUTAGE DES TÂCHES (qui fait quoi, le moins cher capable gagne)20| modèle | coût par tâche | ambition | jugement | goût |21|-------------------|----------------|----------|----------|------|22| claude-fable-5 | élevé | faible | 10 | 10 |23| claude-opus-4-8 | moyen | moyen | 8 | 9 |24| claude-sonnet-5 | faible | élevé | 7 | 7 |25| worker OSS bon marché | le plus faible | le plus élevé | 5 | 4 |26271. Décider quoi faire ensuite, réviser un diff, départager une situation -> Fable 5,28 lecture seule, effort élevé.292. Lire des logs bruts, des vidages ou tout ce qui dépasse 50k tokens -> le worker bon marché.30 Jamais Fable. C'est payer un directeur pour lire un tableur.313. Tout ce avec quoi un utilisateur ou une chaîne interagit directement -> nécessite un score de goût32 de 8 ou plus avant d'être livré.334. Tout le reste -> sonnet-5, effort moyen, remonter d'un niveau en cas d'échec.3435## DÉFINITIONS36- « jugement » = peut-il gérer la chose la plus difficile sur le bureau sans supervision37- « terminé » = le script de signoff est sorti avec 0, point final38- « petit » = moins de 50 lignes modifiées39- « nettoyage » = le comportement est identique bit par bit, signoff vert avant et après4041## LA SEULE DÉFINITION DE « TERMINÉ » QUI COMPTE42- Chaque tâche reçoit une ligne d'arrivée vérifiable par machine avant que le travail ne commence.43- Un relecteur qui n'a vu ni le plan ni le brouillon le vérifie.44- guardrails/signoff.sh a le dernier mot. Pas le relecteur. Le script.45- Si le worker et le relecteur sont en désaccord deux fois de suite, ça va à un humain.46 Pas de troisième avis, pas de modèle départiteur.
Adaptez avec vos propres chiffres. Tout ce que vous laisseriez passer 80% du temps en appelant ça « terminé » a besoin d'un chiffre ou d'un « jamais » attaché, ou supprimez-le.
Section 2 : Les limites et le signoff
Un contrat de travail ne signifie rien sans une vérification des antécédents sur ce qu'il est autorisé à toucher, et un manager qui signe avant que quoi que ce soit ne soit livré. Deux fichiers.
ops/boundaries.md :
1## travaille seul2rédiger des correctifs sur une branche ; mettre à jour shift-log.md ; redémarrer une instance de test3*non productive* ; signaler des flux de données obsolètes45## a besoin de ma signature6tout ce qui se trouve sous wallets/, .env*, config/rpc.json ; tout diff de plus de 300 lignes ;7toute modification d'un processus pm2 en direct ; tout ce qui envoie une transaction89## me réveille immédiatement10le relecteur échoue deux fois le même correctif ; le routeur a servi un modèle différent11de celui demandé ; les dépenses quotidiennes ont dépassé la ligne ; un contrôle permanent passe au rouge ;12quoi que ce soit demande une clé privée
ops/guardrails/signoff.sh (modifiez les commandes pour correspondre à vos bots) :
1#!/usr/bin/env bash2set -e3npm run typecheck --if-present4npm test --if-present5pm2 describe "$BOT_NAME" | grep -q "status.*online" || exit 1
Exécutez-le une fois manuellement avant que quoi que ce soit d'autre dans ce système ne soit mis en service. S'il ne passe pas proprement sur votre configuration actuelle, c'est la première tâche réelle. Tout le reste en aval suppose que ce script dit la vérité.
Section 3 : Le shift
Voici le calcul qui fait ou défait le système. Une session complète avec Fable 5 qui tape le travail coûte vite cher, quatre chiffres si vous le laissez écrire pendant des heures. Fable 5 qui prend les décisions pendant qu'un modèle bon marché tape le travail est une facture complètement différente, environ 15 à 20 % des tokens pour 100 % des décisions.
Donc le shift a quatre employés, pas un :
- Un modèle quasi gratuit lit les logs de la nuit et la sortie pm2. Il dit « calme » ou « actionnable ». C'est tout.
- Fable 5, en lecture seule, décide de la seule chose à plus haute valeur et rédige un ordre de travail. Il ne touche pas au code.
- Un modèle worker bon marché exécute l'ordre de travail sur une branche isolée.
- Une nouvelle instance de Fable 5, ne voyant que le cahier des charges et le diff, vote réussi ou échoué.
Le script déterministe de la section 2 départage. À chaque fois.
ops/shift.sh :
1#!/usr/bin/env bash2set -euo pipefail3cd "$(dirname "$0")"4DAILY_BUDGET="${DAILY_BUDGET_USD:-5}"5INTAKE_MODEL="${INTAKE_MODEL:-openrouter/deepseek/deepseek-v4-flash}"6WORKER_MODEL="${WORKER_MODEL:-openrouter/moonshotai/kimi-k2.6}"78# 1. PRISE EN CHARGE, quelques centimes9pm2 logs --lines 100 --nostream | llm -m "$INTAKE_MODEL" -s "$(cat intake.md)" \10 >> shift-log.md11grep -q "status: actionable" shift-log.md || { echo "shift calme"; exit 0; }1213# 2. ORDONNANCEMENT, Fable, xhigh, lecture seule, décide et s'arrête14claude -p "$(cat dispatcher.md)15LOG: $(cat shift-log.md)16TRUST: $(cat personnel/trust.tsv)17BOUNDARIES: $(cat boundaries.md)" \18 --model claude-fable-5 --effort xhigh --allowedTools "Read" \19 --output-format json > /tmp/order.json2021SERVED=$(jq -r '.modelUsage | keys[0] // "claude-fable-5"' /tmp/order.json)22[[ "$SERVED" != *fable* ]] && { echo "redirigé, abandonner cette exécution" >> shift-log.md; exit 2; }2324jq -r '.result' /tmp/order.json > work-order.json25ACTION=$(jq -r .action work-order.json)26[[ "$ACTION" == "stop" ]] && exit 027[[ "$ACTION" == "queue" ]] && { echo "mis en file d'attente pour signature" >> shift-log.md; exit 0; }2829# 3. EXÉCUTION, worker bon marché, branche isolée30BR="shift-$(date +%s)"31git worktree add "../$BR" -b "$BR" >/dev/null32( cd "../$BR" && llm -m "$WORKER_MODEL" -s "$(cat "$OLDPWD/worker.md")" \33 "$(cat "$OLDPWD/work-order.json")" > shift-notes.md )3435# 4. RÉVISION, nouveau Fable, cahier des charges et diff uniquement, rien d'autre36VERDICT=$(claude -p "$(cat reviewer.md)37SPEC: $(jq -r .spec work-order.json)38DIFF: $(cd "../$BR" && git diff)" \39 --model claude-fable-5 --effort high --allowedTools "" \40 --output-format json | jq -r .result)4142# 5. LE SEUL VOTE QUI LIVRE QUOI QUE CE SOIT43if [[ "$VERDICT" == PASS* ]] && ( cd "../$BR" && "$OLDPWD/guardrails/signoff.sh" ); then44 echo "RÉUSSI, livré ou mis en file selon le niveau de confiance" >> shift-log.md45else46 echo "ÉCHOUÉ : $BR mis en attente pour révision" >> shift-log.md47fi
Une décision prise par Fable et une ligne de code tapée par Fable sont deux prix différents. Ne payez le plus élevé que pour la décision.
Section 4 : Le dossier personnel
La confiance n'est pas un paramètre à l'échelle de l'entreprise. Elle se gagne tâche par tâche, de la même manière que vous ne donneriez pas les clés de production à un nouveau venu dès le premier jour, quel que soit son portfolio.
personnel/trust.tsv suit chaque tâche récurrente par nom : exécutions, réussites, niveau actuel.
- surveillance : moins de 10 exécutions, ou taux de réussite inférieur à 90 %. Brouillons uniquement, pas d'exception.
- période d'essai : 10 à 19 exécutions à 90 % ou plus. Mis en file d'attente pour votre signature, à chaque fois.
- approuvé : 20 exécutions ou plus à 95 % ou plus. Livré sans vous.
Un échec sur une tâche approuvée ne reçoit pas d'avertissement. Elle redescend directement en période d'essai et s'affiche sur stderr, que votre cron vous envoie par mail. La rétrogradation automatique est la seule qui tienne vraiment.
La seconde moitié du dossier personnel est personnel/standing-checks/. Chaque tâche terminée obtient son diplôme ici sous forme de commande qui doit continuer à retourner vrai, pour toujours, vérifiée une fois par jour :
1# personnel/standing-checks/bankr-claim-monitor.md2prédicat : pm2 describe bankr-claim-monitor | grep -q "status.*online" && \3 sqlite3 claims.db "select count(*) from claims where ts > strftime('%s','now','-1 day')" | grep -qv "^0$"4dernière-vérification : 2026-07-085en-cas-de-violation : réveillez-moi, ne redémarrez pas à l'aveugle
Une tâche que vous n'avez vérifiée qu'une fois n'est pas terminée. C'est une hypothèse avec un horodatage.
Exécutez la vérification quotidiennement via cron. Un prédicat qui échoue signifie que quelque chose qui était vrai a cessé de l'être, silencieusement, et personne ne l'aurait remarqué sans ce fichier.
Section 5 : Le rapport d'incident
C'est la section que les playbooks originaux ignorent, et c'est celle qui compte vraiment une fois que le système est en production sur une infrastructure qui manipule de l'argent réel. Tout système agentique finit par faire quelque chose que vous ne vouliez pas. La question est de savoir si vous l'apprenez d'un log propre ou d'un portefeuille vidé.
ops/incidents/runbook.md :
1| signal | signification | action2|---------------------------------|------------------------------------------|-------3| exit 2 (redirigé) | un modèle différent a servi la requête | jetez la sortie, ne construisez jamais dessus, réessayez demain4| stop_reason: refusal | le classificateur de sécurité a refusé, HTTP 200 | pas une erreur, vérifiez le log ; si une tâche refuse à plusieurs reprises, c'est qu'elle touche probablement quelque chose qu'elle ne devrait pas5| le signoff échoue deux fois, même correctif | le worker et le relecteur ne convergent pas | passez-le en révision humaine, ne réessayez pas une troisième fois automatiquement6| un contrôle permanent passe au rouge | quelque chose de terminé a cessé d'être vrai | vérifiez la date de dernière vérification, différenciez ce qui a été livré depuis, ne faites pas de revert automatique7| les dépenses quotidiennes dépassent la ligne | budget dépassé | arrêtez le shift, lisez shift-log.md, trouvez quelle étape a gonflé8| une tâche touche wallets/.env/rpc | tentative de violation des limites | arrêt strict, cela ne devrait jamais se produire si boundaries.md est respecté, traitez toute occurrence comme un bug dans le système lui-même
Enregistrez chacun de ces incidents dans incidents/log.tsv avec un horodatage, que vous ayez agi ou non. L'objectif n'est pas zéro incident. C'est zéro incident dont vous apprenez trop tard.
Une fois par semaine, faites un passage de compost : lisez le journal des incidents, les rétrogradations du fichier de confiance, et tout ce qui est resté en file d'attente et non signé pendant plus de 3 jours. Extrayez au maximum trois propositions : un nouvel arrêt strict pour CONTRACT.md, un correctif à une description de poste, ou un contrôle permanent qui vous manquait. Vous signez les trois à la main. Le système peut proposer sa propre règle suivante. Il n'a jamais le droit d'en écrire une.
Calendrier de probation
Trois points de contrôle, pas trente jours de surveillance :
Point de contrôle 1. Exécutez le shift manuellement chaque jour pendant une semaine. Lisez chaque ligne. Diplômé lorsque trois shifts de suite routent exactement comme vous l'auriez fait.
Point de contrôle 2. Cron prend le shift. Vous révisez la file d'attente avec un café au lieu de l'exécuter vous-même. Diplômé lorsque deux tâches récurrentes dépassent 20 exécutions enregistrées.
Point de contrôle 3. Votre tâche la plus performante est livrée sans surveillance. Diplômé lorsqu'elle fonctionne une semaine entière sans aucune intervention de votre part.
Les règles, condensées
- Un contrat est un chiffre ou un « jamais ». Tout ce qui est plus flou sera optimisé.
- L'ordonnanceur décide. Le worker tape. Aucun des deux ne vérifie son propre travail.
- Le jugement de Fable vaut le prix. La frappe de Fable, généralement pas.
- La confiance est par tâche, pas à l'échelle de l'entreprise, et la rétrogradation est automatique et bruyante.
- Une tâche terminée qui n'est pas revérifiée n'est pas terminée, c'est une supposition avec une date.
- Les limites se trouvent dans un fichier que vous pouvez lire en dix secondes, pas dans votre mémoire.
- Le journal des incidents existe pour que vous trouviez les problèmes dans un rapport, pas dans un solde.
- Ne construisez jamais sur la sortie d'un modèle que vous n'avez pas demandé.
- Une fois par semaine, le système peut proposer une nouvelle règle. C'est toujours vous qui la signez.
Le modèle n'a jamais été la partie difficile. Construire quelque chose autour de lui qui reste honnête quand personne ne regarde, c'est le vrai travail. Voici à quoi ça ressemble pour une flotte de bots plutôt que pour une base de code.
Commencez par guardrails/signoff.sh. Exécutez un shift manuellement. Écrivez un contrôle permanent pour le dernier bot que vous avez livré. La première fois qu'il attrape quelque chose dont vous étiez sûr que c'était bon, le reste cesse d'être optionnel.
Suivez @GipArcAI pour plus d'analyses de ce type, et retrouvez-moi sur X à https://x.com/gippp69.
