Trois agents entrent dans un bar : mon expérience pour coder davantage sans exploser le budget

Il y a un moment dans la vie de tout développeur équipé de copilotes où vous regardez la facture mensuelle et vous pensez : “C’est bien, mais ça ressemble plus à une liste d’abonnements qu’à mon ancien fitness du quartier.”

Ce moment m’est arrivé avec une combinaison assez sérieuse : Claude Max 5, Codex Plus, et la tentation d’ajouter Z.AI avec OpenCode pour les petits jobs. L’idée avait l’air solide. Mais voilà le problème : si vous intégrez trois agents dans votre flux sans structure, vous finissez par ressembler à un chef de chantier où tout le monde est occupé à tourner en rond, mais personne ne tient les plans.

Ma conclusion initiale est très simple : avant de vouloir automatiser le routing, mieux vaut faire un test manuel. Pendant deux semaines. Avec des règles un peu basiques, mais claires.

Le problème n’est pas le prix, mais la coordination

Payer 23 francs, 90 euros ou 10 dollars séparément ne semble pas insurmontable.

Mais la vraie galère commence lorsque chaque outil commence à empiéter sur l’autre. Vous demandez à l’un de réfléchir, à un autre d’implémenter, vous revenez au premier pour réviser, et terminez avec un troisième pour une tâche machinale. Et au bout de vingt minutes, vous commencez à douter : économisez-vous de l’argent, de la qualité, ou juste en train de vous amuser à jongler entre les fenêtres ?

Pour le dire clairement : le vrai coût n’est pas seulement l’abonnement. C’est aussi le perpétuel changement de contexte.

C’est un peu comme avoir une cuisine avec un couteau japonais, un Thermomix et une friteuse à air chaud. Les trois sont utiles. Les trois font des choses différentes. Mais si vous essayez de faire frire des frites avec le Thermomix, ça ne marchera pas.

Ma hypothèse : réfléchir, exécuter, nettoyer

Voici la politique que je veux tester, très simplement :

• Claude pour réfléchir
• Codex pour exécuter
• GLM/Z.AI pour nettoyer

Ce n’est pas une théorie académique, mais une règle de base.

Quand une tâche est mal définie, touche à l’architecture, comporte des risques, ou nécessite du discernement, c’est logique de la confier à l’agent le plus compétent en raisonnement dans mon arsenal : Claude.

Quand il est clair que la tâche consiste à coder, modifier des fichiers, exécuter des tests ou résoudre des bugs, c’est à ce stade que j’appelle Codex au travail.

Et enfin, pour ces petits boulots mécaniques que personne ne veut vraiment faire mais qui sont nécessaires (tests simples, documentation, scripts basiques, renommage, refactorisations mécaniques), je veux voir comment GLM avec OpenCode peut gérer ça.

Ce que je ne veux PAS faire pour l’instant

Je ne veux pas mettre en place un routeur automatique.

Je ne veux pas d’un système magique qui analyse le prompt, classe les tâches, choisit le fournisseur, change de modèle en fonction de l’heure, et me génère un joli graphique pour justifier la complexité.

C’est probablement passionnant à concevoir. Mais cela ressemblerait surtout à un beau bazar fait trop vite.

Voici l’erreur classique : construire une tour de contrôle avant même de savoir si vous avez réellement du trafic aérien. Il faut commencer par observer. Puis réfléchir si le montage d’un sémaphore est vraiment nécessaire.

La politique manuelle pour deux semaines

L’expérience que je vais mener est bien moins glamour, mais probablement plus utile.

1. Claude pour les tâches complexes

Je commence par Claude si l’une des conditions suivantes se présente :

• je n’ai pas d’approche claire
• il y a des décisions de design
• un risque de casser quelque chose d’important
• besoin de vérifier des arguments, pas seulement du code

En termes simples : si la tâche exige du discernement, je ne lésine pas.

2. Codex pour le travail principal dans le repo

J’utilise Codex lorsqu’une tâche est bien définie :

• implémenter des changements concrets
• corriger des tests
• refactoriser avec validation
• itérer jusqu’à remise en l’état fonctionnel de l’ensemble

C’est là que le concept d’un “agent d’exécution performant” prend tout son sens. Non pas en raison du modèle lui-même, mais du processus efficace qu’il permet.

3. Z.AI pour les travaux basiques et remplaçables

La règle pour Z.AI, c’est la suivante :

• boilerplate
• brouillons
• documentation
• tests simples
• scripts légers
• renommage
• modifications mécaniques simples à vérifier

S’il échoue, ce n’est pas grave. On peut jeter et recommencer ailleurs.

C’est l’idée centrale. Je ne cherche pas les finitions précises avec GLM. Je veux juste qu’il fasse le travail de base.

La règle d’or : en cas d’échec, on escalade

Voici l’aspect le plus important du processus, celui que beaucoup oublient.

Quand un outil bon marché échoue, la tentation c’est de insister. “Encore une itération.” “Je vais ajuster le prompt.” “Je vais lui donner plus de contexte.” Et 30 minutes plus tard, vous vous retrouvez à négocier avec le modèle comme s’il s’agissait d’une imprimante capricieuse.

Ma règle pour cet essai est la suivante :

• Si Z.AI échoue en 1-2 tentatives, on escalade immédiatement.
• Si c’est un problème d’exécution, ça passe à Codex.
• Si c’est un problème de conception ou de compréhension, ça passe à Claude.

Ce qui est bon marché cesse de l’être dès qu’il vous vole des heures.

Ce que je veux vraiment mesurer

Je ne suis pas là pour du benchmark theatre.

Je ne vais pas créer un tableau avec des données comme tokens par seconde, latence moyenne, et autres métriques qui paraissent très sérieuses, mais qui vous éloignent de votre vrai problème : renommer quarante symboles sans y passer la journée.

Ce que je veux vraiment mesurer en deux semaines, c’est ceci :

Si l’expérience est concluante, tant mieux.

Si ça échoue, autant le savoir rapidement avec un abonnement à 10 francs, plutôt que trop tard après avoir dépensé une fortune à construire une mini-tour de contrôle.

Des outils existants, pas imaginaires

L’outil bon marché de mon test ne sort pas de nulle part. OpenCode existe et est conçu justement pour intégrer fournisseurs et agents depuis un terminal. Z.AI fournit la documentation de son coding plan et l’assistance au travers des modèles GLM adaptés au codage.

Cela ne signifie pas que je vais remplacer Codex ou Claude indiscriminément. Mais il y a assez de matière pour tester, sans inventer des histoires.

Les références officielles que j’ai consultées pour éviter de raconter n’importe quoi :

• OpenCode : https://opencode.ai/docs
• Z.AI DevPack : https://docs.z.ai/devpack/overview

Mon pari aujourd’hui

À ce jour, mon pari est plutôt modeste :

• conserver Claude Max 5
• conserver Codex Plus
• tester Z.AI Lite pour les tâches basiques
• ne pas encore automatiser le routing
• revoir dans deux semaines si cela réduit réellement les coûts ou si cela ajoute simplement des frictions.

La politique mentale tient sur un post-it :

En cas de doute, Claude.  
Si ça construit, Codex.  
Si ça nettoie, GLM.  
Si GLM échoue deux fois, fin de la blague.

Ce n’est pas sophistiqué. Ça ne nécessite pas de YAML. Pas de MCP. Pas de tableau de bord avec des graphes complexes. Et c’est précisément pour cette raison que je pense que ça peut marcher.

Parce que parfois, la vraie différence entre un système fonctionnel et un gadget inutilisable, ce n’est pas d’ajouter plus d’intelligence.