Partie 1 — Pourquoi j’ai eu besoin d’un agent de développement

L’IA m’a rendu plus rapide, et pourtant

Depuis un peu plus d’un an, j’utilise Cursor intensivement pour mes développements. L’outil est devenu central dans ma façon de travailler : aujourd’hui, je travaille à 95 % assisté par des IA.

Au début, les résultats étaient inégaux. Une fois sur deux, le code produit ne compilait même pas. Mais les progrès ont été fulgurants. Les modèles de langage ont atteint un niveau où ils livrent du code de qualité correcte de manière régulière, y compris sur des tâches complexes.

Et c’est là qu’est apparu un nouveau problème.

Plus l’IA est capable, plus je lui confie de travail. Et plus je lui confie de travail, plus je me retrouve à… attendre. J’essayais de jongler entre plusieurs projets ou plusieurs features en parallèle pour rester productif pendant qu’elle travaillait. Mais ce n’est pas très efficace : chaque changement de contexte a un coût cognitif. Et sur les tâches simples, je perdais clairement du temps à rester impliqué dans des cycles qui pourraient se dérouler sans moi.

Le constat : certaines tâches n’ont pas besoin de moi

Il y a des tickets où le travail est clair, balisé, sans ambiguïté. Un correctif de bug documenté. Une nouvelle page qui suit un pattern existant. Une intégration d’API bien spécifiée. Ce type de tâche ne demande pas de décision architecturale, pas de négociation avec le client, pas d’arbitrage technique. Il demande juste de l’exécution.

C’est exactement là que je perdais du temps : à rester dans la boucle pour des choses qui n’ont pas besoin que je sois dans la boucle.

Ma conclusion : il me fallait un agent capable de prendre en charge ces tickets de bout en bout — de la récupération du ticket jusqu’au pull request — sans que j’aie à intervenir.

Partie 2 — Ce qui n’a pas marché

Les échecs, ça forme aussi

Si tout avait marché du premier coup, cet article serait beaucoup moins intéressant à écrire — et probablement aussi à lire. Je trouve qu’on apprend autant de ses réussites que de ses échecs. C’est pour ça que je tiens à partager ce qui n’a pas fonctionné pour moi avant d’arriver à BB-DEV. Spoiler : ça a pris plusieurs détours.

OpenClaw

Premier essai : OpenClaw, sur un vieux PC Ubuntu que j’avais sous la main. Installation complexe, plusieurs heures à batailler, et au bout du compte des instabilités qui refusaient de disparaître. J’ai fini par lâcher l’affaire. Parfois, le bon réflexe, c’est de savoir s’arrêter avant d’y laisser sa soirée.

Hermes Agent

Deuxième tentative : Hermes Agent, cette fois sur un VPS chez Hostinger. L’installation est plus simple — Hostinger propose une image “toute prête” — mais même avec ça, j’ai eu droit à des instabilités entre le front et la gateway. Mon Claude Code m’a bien aidé à creuser les problèmes (oui, j’utilise déjà l’IA pour configurer mes IA, on n’arrête pas le progrès), mais la gateway de Hermes continuait de redémarrer toute seule. Je ne suis pas administrateur système, mais disons que c’était quand même bien technique pour ce que je voulais en faire.

Une fois le système stabilisé, j’ai commencé à utiliser Hermes pour configurer un premier agent. J’ai acheté pour 10 € de tokens chez Anthropic. Résultat : une dizaine de prompts plus tard — pour configurer l’agent, créer une première skill et connecter un MCP — les 10 € étaient déjà cramés. Autant dire que ça ne m’a pas franchement rassuré sur l’efficience de la consommation de tokens.

Google ADK et OpenHands

J’ai aussi creusé du côté de Google Agent Development Kit (ADK) : très puissant, mais largement surdimensionné pour mon besoin. Et OpenHands, qui m’a semblé être une très bonne solution sur le papier — mais qui, comme Hermes, fait également tourner la note en consommant des tokens d’API.

La conclusion qui s’est imposée

Tous ces essais m’ont amené à la même conclusion : il me fallait un petit script maison, capable de s’appuyer sur les abonnements que je paie déjà — Claude Code et Cursor — plutôt que de cramer des tokens d’API à chaque interaction. C’est cette idée toute simple qui a posé les bases de ce qui allait devenir BB-DEV.

Partie 3 — Architecture de l’agent BB-DEV

Les composants du système

L’agent BB-DEV repose sur un ensemble de briques simples, délibérément légères :

ComposantRôle
VPS HostingerEnvironnement d’exécution stable et toujours disponible
Liste de projets GitHub + tokensPérimètre d’action défini manuellement
Script Python de récupération des ticketsFiltre et sélectionne les tâches éligibles
Claude Code en mode CLIExécute le développement de manière autonome
Les skills du projetsIndiquent à Claude comment travailler sur ce projet
Le MCP GitHubPermet d’interagir avec le repo et les issues
Cron toutes les heuresOrchestre le cycle complet

Pourquoi un script Python pour la collecte, pas une IA ?

C’est un choix délibéré. La collecte des tickets GitHub est une opération simple et déterministe : appeler l’API GitHub, filtrer sur un tag spécifique (BB-DEV), retourner la liste. Faire passer cette étape par une IA aurait consommé des tokens inutilement sur une opération qui n’a pas besoin d’intelligence.

La règle que j’applique : l’IA intervient là où l’intelligence est nécessaire, pas là où la logique suffit.

Le filtre BB-DEV : comment je décide ce que l’agent peut traiter

Je ne confie pas tous les tickets à l’agent. Seulement ceux que j’ai volontairement tagués BB-DEV. C’est moi qui fais l’aiguillage. Ce tag signifie : “j’ai évalué ce ticket, le développement est suffisamment clair et borné pour que l’agent s’en charge sans mon intervention.”

Ce mécanisme me donne deux garanties :

  • L’agent ne travaille jamais sur quelque chose d’ambigu ou de risqué sans que je l’aie décidé.
  • Je garde la main sur la stratégie et les arbitrages techniques.

Claude Code en mode CLI : le cœur de l’exécution

Pour l’exécution du développement, j’utilise Claude Code en mode CLI avec le mode autonome activé. Cela me permet d’utiliser mon forfait Claude directement — pas besoin de tokens API supplémentaires.

Le modèle utilisé est Claude Sonnet. C’est un bon équilibre entre performance et coût pour des tâches de développement courantes.

Un point important : toute la configuration du projet — contexte, skills, MCPs — est versionnée dans le dépôt. Claude Code la charge automatiquement quand il démarre sur un projet. Il n’y a donc aucune configuration supplémentaire à faire côté agent : le comportement attendu de l’IA est décrit dans le projet lui-même.

Partie 4 — Le cycle de vie d’un ticket

De l’issue GitHub au pull request

Voici ce qui se passe à chaque exécution du cron :

1. Le script Python interroge l'API GitHub
   └── pour chaque projet dans la liste
       └── récupère les tickets ouverts avec le tag "BB-DEV"

2. Pour chaque ticket éligible
   └── Lance Claude Code en mode autonome
       ├── avec le contexte du ticket
       ├── dans le dossier du projet concerné
       └── avec les instructions pour créer une branche, développer, committer et ouvrir un PR

3. Claude Code exécute le développement
   ├── analyse le code existant
   ├── implémente les modifications
   ├── teste ce qui peut l'être
   └── crée le pull request

4. Le ticket est mis à jour sur GitHub

Ce que l’agent fait seul

Depuis un mois que le système tourne, l’agent a traité 25 tickets sans intervention de ma part. Ce sont principalement :

  • Des petits correctifs de bugs avec une cause identifiée
  • Des ajouts de features simples qui suivent des patterns existants
  • Des mises à jour de contenu ou de configuration
  • Un ticket par jour, pas si mal

Ce que je continue de faire moi-même

L’agent ne remplace pas le jugement. Je continue de traiter :

  • Les tickets qui nécessitent un échange avec le client
  • Les choix d’architecture ou de modèle de données
  • Les features nouvelles sans pattern existant dans le projet
  • Tout ce qui touche à la sécurité ou aux données sensibles

La ligne de partage est claire : exécution déléguée, décision gardée.

Partie 5 — Ce que ça change concrètement

La fin du coût de réentrée sur les petites tâches

Avant, même pour un ticket simple, je devais ouvrir le projet, retrouver le contexte, lancer l’IA, relire le code produit, committer. Sur un ticket qui prend 20 minutes d’exécution, le coût de ma présence était réel.

Maintenant, ces tickets se traitent sans moi, dans la journée, au fil du cron. Quand je reviens sur le projet, le PR est là, je le relis, je le merge ou je demande une correction.

Un rythme de développement en arrière-plan

Le système s’étale dans la journée : maximum un ticket par heure par le cron. Cela crée un flux régulier de small PRs qui avancent les projets de manière continue, sans que je sois présent.

Je n’ai pas encore eu de saturation du forfait Claude, même en travaillant en parallèle sur plusieurs projets.

Ce que je veux faire évoluer

Le système actuel est volontairement simple. Pour la suite, j’explore l’idée de remplacer mes scripts maison par un SDK dédié comme OpenHands, qui offre une abstraction plus robuste pour ce type d’orchestration multi-agents.

Je vais également essayer Hermes Agent avec un compte Open AI qui me permettra d’utiliser le forfait fourni par Open AI, mais sous la forme d’API, ce que ne permet plus Claude.

Enfin et surtout, je vais continuer de créer de nouveaux agents. BB-DEV a besoin d’être bien entouré pour constuire une équipe de choc. Je vous tiens au courant dans les prochaines semaines.

Chez Citios, j’accompagne les équipes tech et les fondateurs dans l’automatisation de leurs workflows de développement. Définir le périmètre d’action, choisir les outils, sécuriser le processus : c’est le genre de cadrage qui évite de partir dans une mauvaise direction.