bkit — Bien utiliser Claude Code grâce au Context Engineering
En décembre 2025, j’ai lancé un service appelé bkamp.ai.
- 11 microservices
- Un portail basé sur Next.js
- AWS EKS + GitOps (ArgoCD)
- Une infrastructure Terraform
Et j’ai mis l’ensemble en production en seulement 9 jours.
J’étais l’unique développeur,
et j’ai utilisé Claude Code pour l’IA.
Cet article ne parle pas simplement de “faire vite”
Beaucoup de retours d’expérience sur le développement avec l’IA sont présentés ainsi :
- « Je l’ai fait avec l’IA en N jours »
- « Il suffit de bien écrire les prompts »
Mais ce que j’ai ressenti en développant pendant ces 9 jours était complètement différent.
L’IA sait effectivement bien écrire du code.
Mais elle ne décide pas de ce qu’il faut écrire.
Ce qui le décide, au final, c’est :
- la conception
- les règles
- les unités de travail
- la méthode de validation
C’est ce que j’ai défini comme du Context Engineering.
Qu’est-ce que le Context Engineering ?
Pour le dire simplement :
il ne s’agit pas de bien écrire un prompt,
mais de concevoir l’environnement même dans lequel l’IA travaille
Par exemple :
- créer d’abord des documents de conception
- découper les unités de travail à partir de ces documents
- définir des règles pour valider les résultats
- mettre en place un cycle reproductible
Autrement dit,
l’IA ne devient pas un « auteur »,
mais un moteur qui rend un contexte prédéfini
La méthode réellement utilisée sur bkamp
1. Day 0 — définir les règles avant d’écrire du code
Le premier commit ne contenait pas de code.
À la place, j’ai créé :
.claude/CLAUDE.md(environ 150 lignes)- un document d’exigences
- un document de stratégie
On y définit notamment :
- le cycle PDCA (Plan → Do → Check → Act)
- tous les résultats sont validés par un humain
- conception en coréen, code en anglais, commits en coréen
- les unités de travail et la manière d’avancer
Ces une centaine de lignes de règles ont ensuite déterminé tout le développement.
2. L’unité de travail n’est pas une “fonctionnalité”, mais un “document”
En général, on demande quelque chose comme :
- « Crée-moi une fonction de chat »
Mais en pratique, j’ai travaillé ainsi :
- « Implémente la section 3.2 du document 7 »
La différence est énorme.
Du point de vue de l’IA :
- fonctionnalité → nécessite une interprétation (incertitude)
- document → implémentation telle quelle (déterministe)
Au final :
la variabilité des sorties disparaît presque complètement
3. Une journée = un cycle PDCA
Le développement avance de cette manière :
- Plan (conception)
- Do (implémentation)
- Check (analyse des écarts)
- Act (correction)
Et ce cycle est répété à l’échelle d’une journée.
Les avantages de cette approche :
- le contexte reste toujours à jour
- le périmètre de travail est clair
- l’IA sait précisément « ce qu’elle doit faire maintenant »
4. Poser des checkpoints et refondre sans hésiter
Le 4e jour, j’ai entièrement réorganisé le frontend.
Mais avant cela, je fais toujours une chose :
- créer un checkpoint permettant le rollback
De cette manière :
même en cas d’échec, on reste en sécurité
→ ce qui permet des changements structurels audacieux
5. Raccorder l’infrastructure d’un seul coup à la fin
Le 8e jour, en une seule journée, j’ai raccordé :
- Terraform
- Kubernetes
- CI/CD
- ArgoCD
Le fait que cela soit possible s’explique simplement :
toute la structure était déjà alignée en amont
Les motifs clés tirés de cette expérience
Voici le schéma qui s’est répété durant ces 9 jours :
- définir les règles d’abord
- concevoir d’abord
- travailler à partir des documents
- itérer avec le cycle PDCA
- créer des checkpoints
- résoudre les divergences dans les documents
- le code vient en dernier
Mais peut-on maintenir cela dans la durée ?
C’est là qu’un problème apparaît.
Cette méthode est puissante, mais :
elle est trop exigeante pour être maintenue durablement par un humain seul
- il faut se souvenir en permanence des règles
- il faut constamment réaligner les documents
- il faut respecter le PDCA à chaque fois
C’est pour cela que j’ai créé bkit.
Qu’est-ce que bkit ?
bkit est un plugin Claude Code.
Mais ce n’est pas un simple outil.
C’est la mise en système, telle quelle, de la méthode de travail utilisée pour bkamp
Le concept le plus important : PDCA = machine à états
Dans bkit, le PDCA est implémenté ainsi :
- états : plan, design, do, check, act, etc.
- transitions : règles de passage d’un état à l’autre
- gardes : vérification des conditions
Par exemple :
- taux de correspondance entre conception et implémentation supérieur ou égal à 90 % → validation
- sinon → lancement automatique d’une boucle de correction
Autrement dit,
« revue → correction » se répète automatiquement
Une architecture qui transforme le Context Engineering en système
bkit se compose des éléments suivants :
- Skills (connaissance métier)
- Agents (comportements basés sur les rôles)
- machine à états PDCA
- système d’injection de contexte
- Quality Gate (validation)
- Audit Log (journalisation)
- Feedback Loop (itération automatique)
En une phrase :
il ne s’agit pas d’utiliser l’IA,
mais de construire le système dans lequel l’IA travaille
Résultats
Voici les résultats obtenus avec cette approche :
- compatibilité continue sur 79 versions de Claude Code
- 4 000+ tests, 0 échec
- 200+ règles de validation CI
- synchronisation complète entre Docs et Code
Conclusion
Ce n’est pas l’histoire d’une IA devenue plus intelligente.
C’est l’histoire d’un travail humain déplacé en amont
- conception d’abord
- règles d’abord
- validation d’abord
Ensuite :
- l’IA exécute
- le système valide
- l’humain approuve
TL;DR
- les prompts seuls ont leurs limites
- le Context Engineering est la clé
- l’IA n’est pas un auteur mais un moteur de rendu
- le workflow compte plus que le modèle
Liens
- bkit: https://github.com/popup-studio-ai/bkit-claude-code
- cas d’usage : https://bkamp.ai
Si vous avez des avis ou des retours sur cette approche, ils sont vraiment les bienvenus.
Aucun commentaire pour le moment.