L'expérience d'un développeur indépendant avec trois modèles Claude a permis de réduire les coûts mensuels d'API de 35 % et de faire passer la latence médiane des tâches de 42 à 27 secondes. En routant les tâches simples et peu ambiguës vers le modèle économique Haiku, le travail de routine vers Sonnet, et en réservant le puissant Opus pour les problèmes à enjeux élevés, l'auteur a prouvé que le « meilleur modèle pour tout » est une habitude coûteuse.

Pourquoi le routage était important

L'auteur utilise un agent de codage autonome qui reçoit un flux constant de tâches de développement — corrections de lint, ajouts de fonctionnalités, revues de sécurité et sessions de débogage approfondies. Pendant des mois, l'agent a envoyé chaque requête à Opus, le modèle Claude le plus performant, supposant qu'une qualité supérieure l'emporterait toujours sur le prix. Opus impose un prix premium par token, la facture a donc augmenté sans contrôle.

Lorsque l'auteur a introduit un schéma de routage par paliers, les dépenses sont tombées à 65 % de leur niveau initial et l'utilisation d'Opus est descendue à 11 % du total des tâches.

Comment fonctionne le système à trois niveaux

La logique de routage repose sur l'ambiguïté, et non sur le nombre de lignes de code qu'une tâche touche. L'auteur a défini trois catégories :

  • Haiku – tâches déterministes à faible ambiguïté. Exemples : correction d'avertissements de lint, renommage de variables, résumé de fichiers journaux (logs). La réponse correcte est généralement une seule ligne de code ou de texte.
  • Sonnet – le bourreau de travail par défaut. Gère l'implémentation de fonctionnalités, les corrections de bugs de routine et les refactorisations standards où le problème est clair mais la solution peut nécessiter plusieurs étapes.
  • Opus – travail à enjeux élevés et à forte ambiguïté. Décisions d'architecture, audits de sécurité, sessions de débogage complexes, ou toute tâche où le chemin correct est incertain et où une erreur pourrait briser le pipeline.

Une table de correspondance statique associe chaque requête entrante au modèle approprié en fonction de ces règles. L'auteur a testé un modèle « intelligent » qui déciderait du palier à la volée, mais la consommation supplémentaire de tokens a annulé toute économie. Des règles statiques simples ont couvert environ 80 % de la charge de travail tout en maintenant le système économique et prévisible.

Le filet de sécurité par escalade

Les modèles économiques font tout de même des erreurs. Pour éviter qu'une réponse erronée de Haiku ou Sonnet ne fasse dérailler le build, le système escalade une requête après deux échecs, la faisant passer au niveau supérieur. Ce filet de sécurité détecte les erreurs précocement et permet au pipeline de fonctionner sans interruption et sans intervention manuelle.

Des chiffres qui parlent d'eux-mêmes

Après quatre semaines d'utilisation du routeur par paliers, l'auteur a constaté les changements suivants :

  • Dépenses d'API : tombées à 65 % du coût initial (une réduction de 35 %).
  • Temps de traitement médian : passé de 42 secondes à 27 secondes.
  • Utilisation d'Opus : réduite de la gestion de chaque requête à seulement 11 % du total des tâches.

Ces chiffres montrent que la majeure partie du travail de développement peut être déléguée à des modèles moins coûteux sans baisse notable de la qualité, tandis que les problèmes les plus difficiles bénéficient toujours de la fenêtre de contexte plus large d'Opus.

Leçons pour les autres développeurs

  1. Commencez bas, pas haut. La plupart des tâches de codage quotidiennes n'ont pas besoin du modèle le plus puissant. Faire de Sonnet le modèle par défaut pour les tâches ambiguës a permis de réaliser plus d'économies que de tout envoyer vers Haiku.
  2. Mesurez la difficulté, pas la taille. La correction d'une condition de concurrence (race condition) sur une seule ligne peut être plus difficile que la refactorisation d'un fichier entier. Routez en fonction de l'ambiguïté de la solution, et non du nombre de lignes modifiées.
  3. Surveillez le taux d'escalade. Une augmentation du nombre d'escalades signale que les règles statiques ne correspondent plus à la charge de travail. Ajustez les catégories avant que les modèles économiques ne commencent à provoquer davantage d'échecs dans le pipeline.

Réserver le modèle le plus coûteux aux problèmes les plus difficiles et laisser les modèles moins chers s'occuper du reste permet de maintenir un développement assisté par l'IA rapide et abordable. Le véritable avantage réside dans une stratégie de routage disciplinée qui associe le bon outil à la bonne tâche.