Le problème est rarement le modèle.
Si ton agent de code produit tantôt du très bon, tantôt du code à jeter, c'est presque toujours ce qu'il reçoit qui varie. Ce kit te donne un système reproductible : un socle projet, quatre rôles d'agents, une vérification systématique et des mesures.
Le workflow du kit, de la user story à la merge request. Touche une étape.
Trois symptômes que tu reconnais peut-être
Tu réexpliques le projet à chaque session.Et le résultat dépend de ce que tu as pensé à dire ce jour-là.
L'agent affirme que les tests passent.Tu découvres en revue qu'ils n'ont jamais été lancés.
Tu ne sais pas si ça s'améliore.Tu juges ton outillage à l'impression laissée par la dernière session.
Huit modules courts, un fichier à poser à chaque étape
Chaque module : une lecture d'une dizaine de minutes, un fichier à copier dans ton dépôt, une vérification pour savoir si c'est en place. Après le module 03, tu as déjà un système utilisable.
- 00Commencer iciLe résultat attendu et comment parcourir le kit.
- 01Comprendre le systèmeModèle, agent, harness, contexte, outils, résultat. Diagnostiquer un mauvais résultat.
- 02Construire son socle projetCLAUDE.md, ARCHITECTURE.md, DECISIONS.md, règles qualité, permissions.
- 03Faire passer une vraie USLe workflow complet sur un exemple Java/Spring, de l'énoncé au verdict.
- 04Agents et contratsCe qu'un agent reçoit, ce qu'il rend, quand il s'arrête.
- 05Vérifier au lieu de croireRelire un diff d'agent, les dérives récurrentes, les preuves.
- 06MesurerRéussite, interventions humaines, relances, coût. Un événement par étape.
- 07Faire évoluer le harnessMaintenir les contextes, rester portable, revue trimestrielle.
Ce que tu copies dans ton dépôt
starter-kit/
├── CLAUDE.md
├── DECISIONS.md
├── agents/
│ ├── analyst.md
│ ├── architect.md
│ ├── developer.md
│ └── verifier.md
├── workflows/
│ └── us-to-mr.md
├── metrics/
│ ├── metrics.md
│ └── event-example.jsonl
├── checklists/
│ ├── project-bootstrap.md
│ └── verification.md
└── examples/
└── java-spring/
Le module 01, en entier et sans inscription
Pour juger sur pièce avant d'acheter.
01. Comprendre le système
La chaîne
Quand un agent produit un changement dans ton projet, six éléments interviennent, dans cet ordre.
- Le modèle. Il prédit la suite la plus probable compte tenu de ce qu'il voit. Tu ne le modifies pas : tu le choisis.
- L'agent. La boucle qui permet au modèle d'agir : lire un fichier, exécuter une commande, observer le résultat, recommencer.
- Le harness. Tout ce qui encadre cette boucle : instructions permanentes, rôles, permissions, étapes imposées, vérifications. C'est la partie que tu construis.
- Le contexte. Ce que le modèle a sous les yeux au moment de décider.
- Les outils. Ce que l'agent peut faire concrètement : lire, écrire, exécuter, chercher.
- Le résultat. Un diff, des tests, un rapport.
Ce qui dépend de toi
Le modèle ne dépend pas de toi. Le harness et le contexte dépendent entièrement de toi. Les outils, en partie, à travers les permissions que tu accordes.
Quand un résultat est mauvais, le réflexe est d'accuser le modèle ou de reformuler la demande. Le plus souvent, le problème se situe plus haut : l'agent n'avait pas l'information, n'avait pas de règle, ou personne n'a vérifié ce qu'il a produit.
Pourquoi le même modèle donne des résultats différents
Un modèle ne connaît pas ton projet. Sans contexte, il écrit le code le plus plausible en général, pas le code juste pour ton projet. Il crée une classe utilitaire qui existe déjà, choisit une convention de nommage qui n'est pas la tienne, gère une erreur d'une manière que ton architecture exclut.
Aucune de ces erreurs n'est une faute de raisonnement. Ce sont des absences d'information.
Le piège du plausible
Le texte produit par un modèle a toujours l'air juste : fluide, structuré, assuré. C'est précisément pour cela qu'il doit être vérifié. Un agent peut annoncer que les tests passent sans les avoir lancés, citer une méthode qui n'existe pas, ou résumer un fichier qu'il n'a pas lu en entier.
Diagnostiquer un mauvais résultat
- L'agent avait-il l'information nécessaire ? Si non : contexte.
- Avait-il une règle qui lui disait quoi faire ? Si non : harness.
- Pouvait-il faire ce qu'il fallait ? Si non : outils ou permissions.
- Quelque chose a-t-il vérifié le résultat ? Si non : vérification.
- Seulement ensuite : le modèle est-il en cause ?
À faire
Reprends le dernier résultat d'agent que tu as dû jeter ou reprendre. Passe-le aux cinq questions. La première réponse négative te dit par quel module commencer.
Deux fichiers du kit, gratuitement
Le modèle de CLAUDE.md et la checklist de vérification, par e-mail. Tu peux les poser dans ton dépôt dès aujourd'hui.
Pour toi si
- tu utilises déjà Claude Code ou un agent équivalent ;
- tes sessions donnent des résultats inégaux ;
- tu veux un fonctionnement reproductible d'une tâche et d'un projet à l'autre.
Pas pour toi si
- tu découvres les agents de code : la documentation officielle couvre les bases ;
- tu cherches une automatisation complète sans relecture humaine ;
- tu veux une formation vidéo : ici, ce sont des textes courts et des fichiers.
Le kit complet
- les huit modules en ligne ;
- l'archive des fichiers prêts à copier ;
- l'exemple complet sur un projet Java/Spring fictif ;
- les mises à jour de la version 1.
Questions
Le kit fonctionne-t-il seulement avec Claude Code ?
Les fichiers sont fournis au format Claude Code. Les principes, les rôles et le workflow sont décrits en Markdown neutre et s'adaptent à d'autres agents.
Je débute avec les agents de code, est-ce pour moi ?
Non. Le kit suppose que tu utilises déjà un agent au quotidien. Commence par la documentation officielle, puis reviens.
Quelle stack faut-il ?
L'exemple complet est en Java et Spring Boot. Les principes ne dépendent pas du langage : seules les commandes et les conventions changent.
Comment j'accède au kit après l'achat ?
Tu reçois un lien d'accès par e-mail juste après le paiement : le parcours en ligne et l'archive des fichiers.
Qui est derrière le kit ?
Un développeur backend en activité, qui utilise ce système au quotidien sur des projets réels. Le kit est publié sous le nom Sabel.
Les exemples viennent-ils de vrais projets clients ?
Non. Tous les exemples sont fictifs et écrits pour le kit. Aucun code ni aucune règle ne provient d'un projet client.