Ce post fait partie de ma démarche build-in-public. Réflexion en cours, les choix décrits ici peuvent évoluer.
J’arrête d’appeler Claude “Junior”. Ce n’est pas le bon mot.
Il oublie des étapes, oui. Il optimise pour la vitesse. Il contourne si on ne l’en empêche pas. Mais si on lui demande correctement, c’est bien plus qu’un junior.
La promesse de “~1h par feature” est vraie. Mais elle est incomplète, car elle demande beaucoup de préparation. Ce qu’on ne dit pas assez : pour arriver à ~1h par feature sans dette cachée, la vraie difficulté ne vient plus du code. Elle vient du produit.
Le vrai effort : le produit, pas le code
Définir précisément ce qu’on veut. Écrire une user story claire, pas une intention floue. Poser le cadre avant de se lancer. Comprendre ce qu’on construit avant de demander à l’IA de le construire.
Si ce travail n’est pas fait, l’IA va vite. Dans la mauvaise direction.
C’est le piège structurel du vibe coding : on prompt, ça compile, on commit. Productivité immédiate, friction quasi-nulle. Et puis trois semaines plus tard : le CHANGELOG est vide depuis six features. Les tests passent, mais l’un d’eux est commenté parce que Claude avait besoin de faire passer le build. Une décision d’architecture a été prise dans l’élan d’un prompt, sans validation humaine.
La dette invisible s’accumule silencieusement. Le build tient. Le produit dérive.
Les moments où il faut surveiller Claude
Claude est enthousiaste. Parfois trop.
Il bypass les étapes qu’on n’impose pas explicitement. La code review 24 points ? Sans point de blocage dans le workflow, Claude la saute pour “avancer”. Le CHANGELOG ? Idem. Il faut que le workflow dise “si vide, stop” pour que l’étape soit respectée.
Il résout les build errors par le chemin de moindre résistance. Un test qui échoue à cause d’un vrai bug ? Claude peut commenter le test. Build passe. Problème reporté.
Il optimise pour la satisfaction immédiate. “Ça compile” n’est pas “ça tient”. “Les tests passent” n’est pas “le design est bon”.
Il peut pousser directement sur main si rien ne l’en empêche. C’est arrivé. Un commit direct sur main, sans PR, sans review. Parce que le workflow ne l’interdisait pas explicitement à ce moment et qu’il faut aussi configurer strictement sa CI/CD. Dans mon contexte d’apprentissage, rien n’est en production, le risque était contenu.
Et encore, je joue tout seul. Avec une équipe de quelques personnes et du code en production complexe… stress.
La surveillance n’est pas une question de méfiance. C’est une question de complémentarité : Claude est excellent pour exécuter vite et précisément dans un cadre défini. Définir et maintenir ce cadre, c’est le rôle de l’humain.
La méthode Cherny : les principes de base
Boris Cherny, le créateur de Claude Code chez Anthropic, a documenté sa façon de travailler. Sept principes :
- CLAUDE.md comme base de connaissance permanente
- Plan Mode avant exécution — Claude critique son propre plan avant de coder
- Exécution parallèle — plusieurs instances simultanées sur des checkouts indépendants
- Boucle de vérification automatisée — un sous-agent vérifie avant toute revue humaine
- Commandes et hooks personnalisés — slash commands et PostToolUse hooks
- Fleet vs tool — Claude comme plusieurs workers schedulés, pas un chatbot unique
- Flywheel auto-améliorant — chaque cycle alimente CLAUDE.md, avantage cumulatif
Deux sont au coeur de ma stack.
Le premier : CLAUDE.md comme base de connaissance permanente. Chaque erreur de Claude ajoutée au fichier. Chaque règle qui survit à plusieurs User Stories. Le spécifique reste dans la fiche US. Le durable migre vers CLAUDE.md. Résultat : à chaque nouvelle session, Claude repart avec un contexte compact et pertinent. Pas 500 lignes qui noient l’essentiel dans le bruit.
Le quatrième : une boucle de vérification automatisée. Un sous-agent dédié teste le code. La tâche reste incomplète jusqu’à ce que la vérification passe. Rien n’atteint la revue humaine si ça n’a pas été vérifié avant.
C’est sur ces deux principes que j’ai construit ma stack. Et c’est le quatrième que j’ai étendu.
La stack complète
La fondation repose sur trois éléments concrets.
Le dossier .claude/commands/ contient le playbook : des commandes qui correspondent chacune à une phase du cycle de vie d’une User Story. /new-us pour cadrer, /implement-us pour planifier et exécuter, /simplify pour revoir la qualité, /review-us pour les 24 points de conformité, /commit-push-pr pour structurer le commit et la PR. Claude n’improvise pas, il suit un rôle défini selon la phase.
Les hooks s’exécutent automatiquement avant ou après chaque action. Un branch-guard en PreToolUse bloque toute modification de fichier hors de la branche courante. Le format automatique en PostToolUse applique Prettier ou dotnet format après chaque fichier modifié, sans y penser.
GitHub Projects tourne comme s’il y avait une équipe. Chaque User Story a son issue, sa branche dédiée, sa Pull Request avec description. Backlog → Draft → Frozen → InProgress → Review → Done. Les commit messages sont structurés. Le CHANGELOG existe et est maintenu.
Pas pour faire joli. Pour que quelqu’un puisse rejoindre le projet sans que tout s’écroule. Et parce que la rigueur visible est une preuve que le travail est sérieux, pour un hiring manager qui regarde l’historique git autant que pour soi-même.
Ce que j’ai ajouté : /deliver-us
Cherny formalise une boucle de vérification. J’ai étendu ce principe à 14 étapes, avec des points de confirmation humaine obligatoires aux moments où Claude prend le plus de liberté.
deliver-us est le wrapper qui referme ça. Il n’est pas dans la stack de base, il l’enrobe. Un orchestrateur en 14 étapes, de la user story au merge :
| Étape | Action |
|---|---|
| 1 | /new-us — créer et enrichir la User Story |
| 2 | Validation PO — scope confirmé par l’humain |
| 3 | /freeze-us — scope gelé, plus de changement |
| 4 | /implement-us — plan présenté, validé, puis exécuté |
| 5 | Exécution — code implémenté selon le plan |
| 6 | Format automatique — Prettier ou dotnet format |
| 7 | /simplify — revue qualité, réutilisation, perf |
| 8 | /verify-build — build 0 warning, tests verts |
| 9 | /review-us — 24 points, bloquant sur les critiques |
| 10 | Documentation — lessons learned + CHANGELOG |
| 11 | Alléger CLAUDE.md — méthode Cherny appliquée |
| 12 | /commit-push-pr — commit structuré + PR |
| 13 | Review humaine — PR approuvée |
| 14 | Merge — mergé dans develop |
Le protocole est strict : les étapes 1 à 3 demandent une confirmation explicite. Les étapes 4 à 11 s’enchaînent de façon autonome, avec arrêt uniquement sur blocage technique. L’étape 12 est une pause obligatoire avant tout push. Les étapes 13 et 14 sont des actions humaines, Claude attend.
Ce n’est pas de la bureaucratie. C’est ce qu’une équipe ferait naturellement, formalisé pour qu’un développeur solo ne puisse pas se mentir à lui-même.
Ce que ça change pour tout le monde
L’IA ne rend pas chaque étape plus simple. Elle oblige à bien comprendre tous les processus. Un dev produit le code. Une personne produit le workflow et les concepts.
L’ère de l’IA redistribue les cartes. Les managers qui comprennent ce qui se passe vont avoir une longueur d’avance considérable sur ceux qui délèguent sans comprendre.
Pour être bon avec l’IA, il faut être meilleur qu’hier.
La vraie question
Ce setup (CLAUDE.md, commandes, agents, hooks, workflow 14 étapes) m’a pris du temps à construire. Il évolue à chaque US livrée. Il a ses angles morts.
Mais il tient. Et c’est ça qui compte dans le build longue durée.
Est-ce que des gens veulent que je le partage complètement ? Le CLAUDE.md, les commandes, les agents. Pas comme template générique à copier-coller, mais comme point de départ à adapter selon votre domaine et votre stack ?
La question est sincère. Si l’intérêt est là, je peux documenter ça proprement.
OGPS est un projet personnel développé avec Claude Code pour apprendre à créer des produits avec l’IA dans la santé suisse.