Face à la hausse des dépenses liées à l’IA, la réponse la plus courante consiste à limiter l’usage : plafonds de consommation, nombre de sièges et validations avant le lancement d’agents. Ces restrictions indifférenciées peuvent toutefois freiner des usages utiles et mesurer le mauvais indicateur, selon l’analyse.
- Il faut mesurer le logiciel livré plutôt que les tokens consommés.
- Le coût par demande de fusion acceptée reflète mieux la valeur produite.
- Le modèle le plus puissant doit être réservé aux tâches complexes.
- Les modèles à poids ouverts peuvent traiter les tâches simples, après évaluation sur le code de l’entreprise.
Le coût par token (unité de texte traitée par un modèle de langage) mesure la consommation, pas les résultats. Une partie des dépenses correspond à du gaspillage, comme les relances de requêtes ou les boucles incontrôlées, tandis qu’une autre représente le travail réel de livraison d’un logiciel. Un compteur ne permet pas de les distinguer, pas plus qu’un plafond de dépenses.
Mesurer le logiciel livré
Un indicateur plus pertinent serait le coût par demande de fusion acceptée, c’est-à-dire le coût total du développement assisté par IA divisé par le nombre de modifications qui passent la revue et sont intégrées au code, appelées « pull requests » dans le jargon. Il faut suivre en parallèle les retouches et les défauts, afin que des modifications moins coûteuses ne masquent pas une baisse de qualité.
Si ce coût baisse alors que l’usage augmente, sans dégradation de la qualité, les développeurs transforment davantage de consommation en logiciel utile. La question n’est donc pas le nombre de tokens utilisés, mais la quantité de travail achevé que produit l’investissement. Pour améliorer cet équilibre, deux leviers sont avancés : réserver l’inférence coûteuse aux tâches qui en ont besoin, et réduire le coût du travail courant.
Adapter le modèle à la tâche
Le développement agentique, dans lequel un agent écrit et modifie du code de manière autonome, n’exige pas le modèle le plus puissant à chaque étape. Un modèle de pointe, ou un modèle phare hébergé sur site lorsque la politique de l’entreprise l’impose, peut être réservé à la planification complexe et au raisonnement inédit. Les tâches plus simples, comme la génération de code, la création de tests ou les refactorisations répétées, peuvent être confiées à des modèles à poids ouverts (« open-weight »), exploités directement par l’entreprise.
Une passerelle, ou « gateway », peut orienter chaque requête selon sa complexité, la sensibilité des données, son coût et sa latence. Le premier modèle est ainsi employé uniquement lorsque la situation le justifie. Comme le résume l’auteur, « Meter the exception, not the workload », soit : mesurer l’exception, et non la charge de travail.
Les modèles à poids ouverts rendent cette répartition de plus en plus praticable. Selon les benchmarks d’ingénierie logicielle cités, les meilleurs d’entre eux peuvent approcher les performances de pointe sur certaines tâches. Ce constat ne garantit pas l’équivalence sur tous les dépôts de code ni sur tous les workflows. Il est donc recommandé d’évaluer les candidats sur son propre code, ses propres tests et ses critères d’acceptation avant de leur confier du travail en production.
Changer l’économie des usages répétés
Reste à déterminer qui possède la capacité de calcul. Avec une inférence louée, chaque appel s’ajoute à la facture. Avec une capacité possédée, l’essentiel du coût est engagé dès le départ, si bien que chaque appel supplémentaire devient moins cher à mesure que l’usage augmente.
