Agents IA et développement : les promesses, les limites et la discipline du token

Ce que les agents changent vraiment au développement

Pendant des années, l’IA dans le code s’est résumée à de l’autocomplétion glorifiée. Un mot, une suggestion, un Tab. Utile, mais fondamentalement passif.

Les agents changent la donne sur le plan architectural. Un agent n’attend pas votre approbation à chaque ligne : il planifie, exécute, observe le résultat, se corrige. Il peut lire un fichier, lancer des tests, interpréter une sortie d’erreur et relancer une correction, tout seul, en boucle. C’est un changement de paradigme : l’IA passe de copilote à sous-traitant.

Les architectures multi-agents poussent cette logique encore plus loin. On peut aujourd’hui configurer un agent “développeur” qui produit du code, et un agent “QA” qui le teste de façon indépendante, les deux coordonnés par un orchestrateur. L’un génère, l’autre critique. Ce modèle reproduit en accéléré ce que font deux développeurs en pair programming, mais à l’échelle d’une pipeline automatisée.

Dans un contexte .NET avec Azure DevOps, ça peut ressembler à ceci : un agent déclenché en CI génère une correction de bug à partir du diff d’un ticket, un second agent valide que les tests unitaires passent, un troisième vérifie la conformité aux conventions de nommage du projet. Chaque agent a un rôle circonscrit, un contexte minimal, et une responsabilité claire.

Le mur des quotas : une réalité architecturale

La promesse est séduisante. La réalité opérationnelle l’est beaucoup moins dès qu’on commence à mesurer.

Les modèles LLM facturent à la consommation de tokens, en entrée comme en sortie. Un agent qui travaille sur une codebase réelle ne lit pas un fichier, il lit un contexte : l’historique de la conversation, les fichiers pertinents, les instructions système, les résultats des commandes précédentes. Tout s’accumule dans la fenêtre de contexte, et tout est facturé.

Sur une session de 30 minutes avec Claude Code, une commande banale comme git status envoie environ 2 000 tokens bruts au modèle. Un cargo test qui échoue peut en envoyer 25 000. Multipliez par la fréquence d’utilisation d’une équipe de cinq développeurs travaillant en parallèle, et vous obtenez une ligne budgétaire qui mérite d’être pilotée.

Les plans d’abonnement comme Claude Pro introduisent une autre contrainte : les quotas de messages. Contrairement à une facturation pure à la consommation, ils imposent un plafond d’interactions dans une fenêtre de temps. Un agent qui boucle sur une tâche complexe peut consommer en quelques heures ce qu’un développeur utiliserait en une journée d’usage normal. C’est un risque de blocage en milieu de journée, particulièrement pénalisant si l’agent est intégré dans un pipeline critique.

La discipline du bon modèle pour la bonne tâche

La première ligne de défense contre la consommation excessive est architecturale : ne pas utiliser un modèle Opus là où un Haiku suffit.

Les modèles de la même famille ne sont pas interchangeables par performance, mais par pertinence. Un modèle de petite taille comme Claude Haiku gère très bien des tâches de classification, de reformatage, d’extraction simple ou de validation de syntaxe. Son coût par token est radicalement inférieur à celui d’un Opus. Utiliser Opus pour vérifier qu’une variable respecte une convention de nommage, c’est prendre un avion pour aller chercher du pain.

Une stratégie d’orchestration mature ressemble à ceci : l’agent principal, chargé de raisonner sur une architecture ou de comprendre un contexte métier ambigu, utilise le modèle le plus capable. Les sous-agents délégués à des tâches répétitives et bien définies utilisent le modèle le moins cher capable de les exécuter correctement. Ce routing par complexité est l’équivalent, en gestion de ressources, de ce qu’on fait déjà avec les tiers de stockage Azure ou la gestion des queues de priorité.

Concrètement, cela implique de traiter le choix du modèle comme un paramètre de configuration, pas comme une décision figée. Chaque agent dans votre orchestration devrait exposer son niveau de modèle requis, et cela devrait pouvoir être ajusté sans toucher à la logique métier.

Réduire le bruit avant qu’il n’atteigne le contexte

Une autre source massive de gaspillage est la verbosité des outils que l’agent utilise. Quand un LLM appelle git log, il reçoit l’intégralité du log formaté avec les métadonnées de chaque commit. Quand il appelle docker ps, il récupère un tableau ASCII complet avec des colonnes dont la moitié ne servent à rien dans le contexte de la tâche.

Ce bruit est facturé. Il dilue aussi la qualité du raisonnement : un contexte encombré de données non pertinentes augmente la probabilité que le modèle s’égare ou hallucine.

C’est précisément le problème que résout rtk (Rust Token Killer). Il s’agit d’un proxy CLI écrit en Rust qui s’intercale entre l’agent et le shell, et compresse la sortie des commandes avant qu’elle n’atteigne le contexte du LLM. Concrètement, un git status qui produit habituellement environ 2 000 tokens en sort à 400. Un cargo test échoué passe de 25 000 tokens à 2 500 en ne conservant que les échecs et les lignes d’erreur pertinentes. Sur une session type, rtk annonce des économies de l’ordre de 80% sur la consommation totale.

L’outil applique quatre stratégies selon le type de commande : filtrage du bruit (commentaires, espaces, boilerplate), regroupement des éléments similaires, troncature avec conservation du contexte utile, et déduplication des lignes répétées avec comptage. Son mode de fonctionnement le plus efficace est le hook automatique, qui réécrit transparentement les commandes shell avant leur exécution. L’agent ne voit jamais la réécriture : il envoie git status, il reçoit une sortie compressée.

Pour une équipe qui opère des agents en CI/CD, rtk peut se configurer en mode non interactif (--auto-patch) et s’intégrer directement dans les images de build.

Penser les agents comme une ressource, pas comme un outil

Il y a une dernière dimension que les équipes tardent souvent à intégrer : la gouvernance.

Déployer des agents sans politique de consommation revient à ouvrir un accès root sans monitoring. Les agents autonomes, par nature, sont prolixes. Ils explorent, ils vérifient, ils repassent sur leur travail. Sans guardrails, ils consomment tout ce qu’on leur donne.

Une approche mature consiste à définir des budgets token par type de tâche et par environnement. Un agent de revue de code en pre-commit peut avoir un budget serré et un modèle économique. Un agent d’analyse d’architecture ou de refactoring profond justifie un modèle plus puissant et un budget plus large, mais avec approbation explicite. Cette granularité se pilote aujourd’hui via les paramètres max_tokens des appels API, combinés à une instrumentation des coûts par pipeline.

La supervision n’est pas optionnelle. Un agent qui boucle en silence, incapable de terminer une tâche, peut consommer des heures de quota sans produire de valeur. Les patterns de circuit breaker, déjà bien connus en architecture de microservices, s’appliquent directement ici : un agent qui échoue trois fois sur la même tâche doit s’arrêter et escalader plutôt que de continuer à brûler du contexte.

Les agents IA pour le code ne sont ni une silver bullet ni une mode passagère. Ils redistribuent effectivement les tâches cognitives de faible valeur vers des systèmes automatisés, libérant les architectes et les développeurs seniors pour des décisions de plus haut niveau. Mais cette redistribution a un coût qui se mesure en tokens, et ce coût mérite d’être piloté avec la même rigueur qu’on applique à l’infrastructure cloud. Choisir le bon modèle, compresser les sorties, définir des budgets : ce sont les premières règles d’une ingénierie IA responsable.