Projet perso avec Claude Fable 5 : de l'idée au déploiement, que fait vraiment l'IA ?

Conclusion d'abord : avec Claude Fable 5 nous avons livré pulsecheck, un CLI qui vérifie en lot si une liste d'URL/API répond encore et écrit un rapport JSON prêt pour cron ou alertes. L'article se lit en deux temps : d'abord à quoi sert l'outil et à quoi ressemble le résultat (capture ci-dessous) ; ensuite les sept étapes où l'IA a écrit du code et où un humain doit trancher dans Claude Code. Pour juger l'utilité, la capture suffit ; pour reproduire, commencez à l'étape 1.

Trois scénarios concrets

Oubliez Go et YAML une seconde : le problème, c'est « comment savoir si ces services répondent encore ». Trois situations où pulsecheck se justifie :

• Patrouille planifiée — Vous avez 5 à 20 URLs de health check (webhooks paiement, API publiques, passerelle interne). Un script shell for url in …; do curl … devient vite ingérable. pulsecheck lit un fichier, sort un JSON structuré, cron fait le reste.
• Avant release ou astreinte — Une commande : ./pulsecheck -config prod.yaml -o /tmp/pre-deploy.json. Code 0 : vous déployez ; code 1 : vous stoppez.
• Sonde pour alertes existantes — Sans Prometheus complet, le code de sortie déclenche votre Webhook ou mail ; le JSON sert à l'analyse après coup.

Hors périmètre : tendances historiques, SMS, console multi-tenant — là, un vrai observability stack. pulsecheck ne répond qu'à maintenant, cette liste est-elle OK ?

Capture du produit fini

Voici pulsecheck une fois terminé dans un terminal Mac : lecture config, sondes, JSON écrit ; un site renvoie 503 donc le code de sortie est 1.

Trois commandes pour reproduire chez vous :

./pulsecheck -config config.example.yaml -o report.json
echo $?          # 1 = au moins une cible KO
cat report.json   # lire le rapport

Entrées, sorties, stack

Techniquement, voyez curl en rafale + rapport unique, compilé en binaire pour cron.

Vous ne maintenez qu'un YAML ; le reste est automatique :

targets:
  - https://api.example.com/health
  - https://status.example.com/ping

Dépôt final ~400 lignes Go :

pulsecheck/
├── cmd/pulsecheck/main.go      # -config -o
├── internal/checker/checker.go # HTTP + latence
├── internal/config/config.go   # parse YAML
├── config.example.yaml
├── Makefile · README.md
└── .github/workflows/ci.yml

Ce que l'IA écrit dans les 7 étapes

Vous savez ce qu'est pulsecheck ; place au processus : Claude Fable 5 + Claude Code, dossier vide jusqu'au tag v0.1.0.

Règle simple : l'IA code et teste ; l'humain cadre, review et signe la release. Chaque étape a un prompt copiable ; Fable 5 suffit pour la boucle agent (pas besoin d'Opus — voir comparatif des tiers).

Prérequis

• Go 1.22+ — go version
• Claude Code CLI — modèle Claude Fable 5 (choix de tier)
• Dossier vide — mkdir pulsecheck && cd pulsecheck && git init
• GitHub (optionnel) — pour l'étape 6 CI distante

Étape 1 : dépôt et besoin

Vous : trois phrases de douleur → SPEC.md. L'IA peut développer, mais vous coupez le hors périmètre (sinon UI web et base de données arrivent tout seuls).

Lis le besoin ci-dessous et génère SPEC.md sans ajouter de fonctionnalité :

- Outil pulsecheck, CLI Go 1.22
- Lire une liste d'URL YAML, HTTP GET concurrent
- Rapport JSON vers -o
- Champs : url, status_code, latency_ms, ok
- Timeout 5 s par défaut, PULSECHECK_TIMEOUT pour override
- Codes : 0 tout vert, 1 échec, 2 erreur config
- Hors périmètre : GUI, DB, Docker, push alertes

IA : SPEC.md. Vous : pas de feature en trop ; commande de validation go test ./... mentionnée.

Validation : cat SPEC.md — sections must / non-objectifs / codes présentes.

Étape 2 : squelette

Vous : demander structure seule, pas de métier. Fable 5 gère presque tout.

Lis SPEC.md, init module github.com/you/pulsecheck.
Squelette uniquement, logique stub :
- cmd/pulsecheck/main.go parse -config et -o
- internal/config lit YAML
- internal/checker vide
- Makefile : test, lint, build
- .github/workflows/ci.yml placeholder
go build ./... doit passer, pas de vraie HTTP.

IA : ~8 fichiers. Durée observée : ~6 minutes.

Validation :

go build ./...
./pulsecheck -h   # aide affichée

Étape 3 : sondes et tests

Vous : imposer tests d'abord, code ensuite. L'agent lance go test, corrige, reboucle — l'étape la plus « vraie projet ».

Dans internal/checker :
1. checker_test.go avec httptest : 200, 500, timeout
2. checker.go : GET, status_code, latency_ms
3. Boucler go test ./... jusqu'au vert
4. main.go : config → checker → JSON vers -o

Extrait typique généré par l'IA :

func CheckURL(ctx context.Context, client *http.Client, url string) Result {
    start := time.Now()
    req, _ := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    resp, err := client.Do(req)
    if err != nil {
        return Result{URL: url, OK: false, LatencyMs: time.Since(start).Milliseconds()}
    }
    defer resp.Body.Close()
    ok := resp.StatusCode >= 200 && resp.StatusCode < 300
    return Result{
        URL: url, StatusCode: resp.StatusCode,
        LatencyMs: time.Since(start).Milliseconds(), OK: ok,
    }
}

En test, Fable 5 a enchaîné 3 tours de go test et a corrigé seul le timeout HTTP non propagé.

Validation : go test ./... -v — 12 cas table-driven verts.

Étape 4 : review

Vous : jouer le reviewer — liste de retours, pas de patch manuel (sinon vous ne testez pas la capacité d'itération de l'agent).

Applique ces retours, go test ./... doit rester vert :
1. Champ JSON latency → latency_ms (SPEC)
2. Worker pool pour URLs, max 10 concurrent par défaut
3. stdout : seulement chemin du rapport ; warns sur stderr

IA : pool, renommage, logs. Vous : décider si ces trois points méritent d'être faits — jugement non déléguable.

Validation : tests verts ; JSON manuel sur une URL réelle.

Étape 5 : config et README

Vous : documentation exploitable par un ops qui copie-colle.

Génère config.example.yaml et README.md :
- Install : go install ou go build
- Exemples, table codes 0/1/2
- Exemple cron 5 min avec log
- Pas de sous-commandes inventées

Validation : URLs réelles dans l'exemple, commandes de la section capture exécutées, champs JSON complets.

Étape 6 : GitHub Actions

Vous : pousser sur GitHub ; l'IA complète le workflow et lit les logs d'échec.

Complète .github/workflows/ci.yml :
- go test -race ./...
- golangci-lint run
- go 1.22
Si lint échoue, lis le log, corrige, recommit.

Premier lint : import inutilisé — Fable 5 a lu le log CI et supprimé. Sur Mac 16 Go, -race peut swapper : déporter vers un runner GitHub ou un nœud Cloud Mac — même logique que le choix d'environnement d'exécution Claude Code.

Validation : CI verte sur GitHub.

Étape 7 : validation et tag

Vous seul : smoke test et tag. L'IA peut brouillonner le CHANGELOG ; la signature release reste humaine.

go test ./...
make build
./pulsecheck -config config.example.yaml -o /tmp/report.json
cat /tmp/report.json | jq .
git add -A && git commit -m "feat: pulsecheck v0.1.0"
git tag -a v0.1.0 -m "first release: YAML-driven HTTP health probe"
git push && git push --tags

pulsecheck est livré : CLI cronable, ~52 minutes de bout en bout.

Répartition IA / humain

Environ 78 % du code livrable vient de l'IA ; cadrage, review et tag restent humains quel que soit le modèle.

Matrice de choix

Combinaisons recommandées

• Solo — Fable 5 sur étapes 2–6 ; Cursor Tab pour micro-ajustements ; Opus seulement sur surfaces exposées.
• Petite équipe — Template dépôt avec checklist sept phases ; process dupliqué ; agent sur workflow Claude Code prod.
• Budget tokens — SPEC et CHANGELOG via Gemini Flash ; boucle code Fable 5 ; routing OpenRouter.

Avec MCP : l'agent tire Issues et contexte monitoring, Fable 5 modifie le repo — étape 7 release : signature humaine recommandée.

Pièges fréquents

• Discuter sans objectif projet — l'IA vague ; fixez « pulsecheck en une phrase » d'abord.
• Métier dès l'étape 2 — squelette et implémentation mélangés, tests difficiles.
• Sauter l'étape 4 — noms JSON, pollution stdout passent en prod.
• Tag sans étape 7 — pas de smoke, pas de release.
• race + agent sur 16 Go — lenteur RAM, pas modèle ; CI sur runner distant.

FAQ

Quel problème pulsecheck résout-il ?

« Cette liste d'URL répond-elle maintenant ? » — sans shell artisanal ni plateforme lourde. Idéal petit équipe ou pré-release.

Différence avec UptimeRobot ou Prometheus ?

pulsecheck est un CLI sur votre machine, config locale, zéro SaaS ; les autres sont des stacks complètes. Ici : suffisant et modifiable.

Un dépôt public à cloner ?

Article retour d'expérience + tutoriel reproductible ; les sept prompts suffisent, pas besoin d'un diff identique.

Étape la plus « IA » ?

3 (tests + code) et 2 (squelette) ; 1 et 7 surtout humaines.

Vs complétion Cursor Tab ?

Tab = fichier unique ; projet entier = Claude Code multi-fichiers + tests. Voir Copilot vs Cursor.

Conclusion

Produit : pulsecheck — YAML, sondes, report.json (capture plus haut). Process : sept étapes Fable 5, ~78 % du Go par l'IA, humain sur périmètre, review et tag. Pour évaluer « l'IA peut-elle livrer un petit outil ? », la capture et le tableau suffisent ; pour le faire vous-même, copiez l'étape 1.