Arrêtez de brûler des tokens : la boucle de développement Claude Code + OpenClaw

Une session de développement sérieuse dans OpenClaw — construire un service backend, déboguer des intégrations, itérer sur une API — peut brûler entre 50 € et 100 €+ en tokens Sonnet avant même d'être à mi-chemin. Non pas parce que quelque chose dysfonctionne. OpenClaw maintient l'état du workspace, charge le contexte de manière agressive, exécute des boucles de raisonnement et lance des appels d'outils à chaque étape. C'est ce qui fait fonctionner l'orchestration. C'est aussi ce qui rend l'écriture d'endpoints CRUD absurdement coûteuse.

La cause profonde : OpenClaw est conçu pour le raisonnement au niveau système. L'utiliser pour écrire des tests unitaires, c'est comme utiliser une clé dynamométrique pour planter des clous.

Séparer l'orchestration du code

Répartissez le travail entre deux outils :

Claude Code fonctionne sur un abonnement fixe — environ 17 €/mois. Le gros du code reste dans ce coût fixe. OpenClaw n'intervient sur le projet que lorsque vous avez besoin de raisonnement système : concevoir l'architecture, valider les intégrations, identifier les cas limites entre composants.

Nous avons constaté des réductions de coûts approchant 80 % sur des projets qui auraient autrement été des sessions pures Sonnet.

Git comme interface entre agents

Git devient le contrat entre les deux environnements. OpenClaw commite les décisions d'architecture. Claude Code commite l'implémentation. Aucun des deux n'a besoin de savoir ce que l'autre a fait en interne — ils lisent l'état actuel du dépôt et travaillent à partir de là.

Une structure de dépôt propre est essentielle :

repo/
 ├─ src/
 ├─ tests/
 ├─ docs/
 ├─ requirements.md
 ├─ architecture.md
 └─ README.md

Le fichier requirements.md est la source unique de vérité — la spécification que Claude Code lit pour comprendre quoi construire, et qu'OpenClaw met à jour quand le périmètre change. Traitez-le comme un contrat, pas comme un brouillon.

Commitez à chaque passage de relais. Cela vous donne un historique reproductible et des rollbacks faciles si une passe de raisonnement déraille.

OpenClaw conçoit le cadre

Commencez dans OpenClaw, mais utilisez un modèle de raisonnement économique comme DeepSeek Chat pour cette phase. Vous n'avez pas besoin de Sonnet pour esquisser une architecture.

L'objectif est de produire des artefacts, pas du code :

• requirements.md — ce que le système doit faire
• architecture.md — comment il est structuré, quels composants existent
• Structure de fichiers initiale — fichiers vides ou stubs montrant la structure prévue
• Contrats d'API — signatures des endpoints, formats requête/réponse, codes d'erreur
• Liste de tâches — travail d'implémentation ordonné

Réduisez le code au minimum. OpenClaw doit définir le squelette, pas le remplir. Quelques lignes de boilerplate par fichier, c'est acceptable. Des implémentations complètes, non.

Une fois le squelette en place :

git init
git add .
git commit -m "Initial architecture and requirements"
git push

Ce push est le passage de relais.

Claude Code implémente le projet

Claude Code clone le dépôt, lit requirements.md et architecture.md, et commence à construire.

C'est ici qu'il rentabilise le coût de l'abonnement. Il est véritablement excellent pour :

• Implémenter des fonctionnalités complètes à partir d'une spécification
• Écrire du code propre et idiomatique
• Construire des suites de tests avec une couverture significative
• Exécuter les tests localement et corriger les échecs
• Rédiger la documentation inline et les sections README
• Effectuer un premier refactoring une fois les fonctionnalités opérationnelles

Une session typique pour un service backend :

→ Implémenter le module d'authentification selon architecture.md
→ Écrire les tests unitaires du module auth
→ Implémenter les endpoints CRUD utilisateur
→ Écrire les tests d'intégration ciblant les endpoints
→ Corriger trois tests en échec
→ Mettre à jour le README avec les instructions d'installation
→ Lancer black + isort

Tout cela dans le cadre de l'abonnement. Aucun coût par token. À la fin de la session :

git add .
git commit -m "Implement auth module and user endpoints with tests"
git push

OpenClaw valide l'intégration

Récupérez le dépôt dans OpenClaw. Utilisez-le maintenant pour ce à quoi il excelle réellement.

git pull

Le rôle d'OpenClaw à cette étape :

• Le code implémenté correspond-il à la spécification d'architecture ?
• Existe-t-il des bugs d'interaction entre composants que les tests unitaires ne détecteraient pas ?
• Des cas limites manquants dans les contrats d'API ?
• La gestion des erreurs tient-elle sur l'ensemble du cycle de vie d'une requête ?

OpenClaw trouvera des choses que Claude Code a manquées — non pas parce que Claude Code est moins bon en code, mais parce que le raisonnement au niveau intégration nécessite de maintenir l'ensemble du système en contexte simultanément. C'est exactement ce pour quoi la gestion de contexte d'OpenClaw est conçue.

Le résultat est une liste de problèmes, pas de correctifs :

## Problèmes d'intégration identifiés

1. L'expiration du token d'auth n'est pas propagée aux services en aval
2. L'endpoint de suppression utilisateur ne cascade pas vers les ressources liées
3. Le rate limiting est appliqué avant la vérification d'auth — l'ordre doit être inversé
4. Réponse d'erreur manquante pour un body JSON malformé

Commitez cela sous forme de fichier de requirements mis à jour, poussez, et repassez la main à Claude Code.

La boucle d'itération

Le développement devient un cycle serré :

OpenClaw → architecture / retours d'intégration / identification des problèmes
    ↓
Claude Code → implémentation / tests / correctifs / refactoring
    ↓
git commit → git push → git pull
    ↓
répéter

Chaque outil opère à son niveau naturel. Claude Code ne raisonne jamais sur l'architecture système. OpenClaw n'écrit jamais une boucle for. Git les maintient proprement séparés.

Un service backend qui prendrait une journée entière en sessions pures OpenClaw peut passer par l'architecture, l'implémentation et la validation en quelques heures — pour une fraction du coût.

La passe de refactoring finale

Une fois le projet stabilisé — les tests passent, les problèmes d'intégration sont résolus, la spécification est entièrement implémentée — confiez le dépôt à Claude Code une dernière fois.

• Unifier le style de code entre les modules écrits lors de sessions différentes
• Simplifier l'architecture qui s'est complexifiée pendant l'itération
• Enrichir les docstrings et la documentation
• Supprimer le code mort et les imports inutilisés
• Finaliser la couverture de tests et ajouter les cas limites manquants

Cette passe est économique. Du travail de code pur, sans ambiguïté architecturale.

Quand ça fonctionne et quand ça ne fonctionne pas

Cette approche est idéale pour les services backend, les API, les outils d'automatisation, les outils CLI, le code d'infrastructure — tout ce qui finira par s'intégrer dans un workflow OpenClaw.

Moins utile pour les scripts très courts (le surcoût organisationnel n'en vaut pas la peine), le prototypage exploratoire (vous n'avez pas de spécification à transmettre), ou les tâches ponctuelles où le temps total de codage est inférieur à une heure.

Conseils pratiques

Gardez les prompts OpenClaw courts. Vous payez pour le raisonnement, pas pour le contexte. Ne collez pas des bases de code entières quand vous voulez un avis architectural — décrivez la structure et laissez-le raisonner à partir de là.

Commitez à chaque passage de relais. Ne transmettez pas un répertoire de travail non commité entre les outils. Chaque passage de relais est un commit.

Traitez requirements.md comme immuable pendant l'implémentation. Les changements de requirements passent par OpenClaw, sont commités, puis Claude Code les récupère. Ne laissez pas Claude Code modifier la spécification.

Laissez Claude Code gérer les tests. OpenClaw identifie ce qui doit être testé au niveau intégration. Claude Code écrit le code de test effectif.

Évitez d'écrire du code dans OpenClaw, sauf s'il s'agit de logique de liaison. Dès que vous implémentez de la logique métier dans une session OpenClaw, vous brûlez des tokens coûteux pour du travail bon marché.

Le principe

OpenClaw est excellent dans ce pour quoi il est conçu. L'erreur est de l'utiliser pour tout.

Implémentation, tests, refactoring, documentation — tout cela appartient à Claude Code au coût fixe d'un abonnement. Architecture, validation d'intégration, raisonnement système — tout cela appartient à OpenClaw, où la gestion de contexte justifie la dépense en tokens.

Git est la poignée de main. Chaque commit est un passage de relais propre. Chaque pull est un chargement de contexte frais. Les agents n'ont jamais besoin de se connaître — seulement l'état actuel du dépôt.

Vous pouvez coller l'URL de cet article dans Claude Code ou l'assistant IA de votre choix comme contexte lors de la mise en place de ce workflow.

Où exécuter tout cela

Vous avez besoin d'un VPS capable de faire tourner OpenClaw de manière fiable. Hetzner vous offre 10 € de crédit à l'inscription — un CX22 à 4,85 €/mois gère OpenClaw et vos dépôts Git sans difficulté. C'est ce sur quoi tourne ce blog.

Si vous préférez éviter complètement le self-hosting, xCloud propose un hébergement managé d'OpenClaw. Pointer, cliquer, déployer — vous conservez le même workflow hybride, sans avoir à maintenir le serveur vous-même.

Pour les équipes qui veulent la couche d'orchestration sans le travail d'infrastructure, ClawTrust est une plateforme d'automatisation IA qui gère le volet OpenClaw de cette boucle en tant que service managé.

(Liens affiliés — nous percevons une petite commission si vous vous inscrivez, sans aucun coût pour vous.)