LegalOn réduit de 65% ses dépenses quotidiennes sur Codex sans perdre en vitesse

LegalOn a réduit de 65% ses dépenses quotidiennes estimées sur Codex, sans perdre en vitesse de développement. L'information provient du blog d'OpenAI. Le titre de l'article évoque une réduction de moitié, mais le chiffre réel est plus élevé : si les dépenses ont baissé de 65%, l'entreprise paie environ 35% de son ancienne facture, soit environ 2,9 fois moins.

Ce qui a été fait

Le court descriptif publié mentionne deux leviers. Premier levier : LegalOn a associé ses tâches aux options Astra, Sol et Luna. Second levier : l'entreprise a piloté ses budgets de manière stratégique. Le fragment disponible ne précise pas ce que recouvrent les noms Astra, Sol et Luna (modèles distincts, modes ou configurations), ni comment ils se distinguent par leur prix et leurs capacités. Nous n'extrapolerons donc pas.

La logique, elle, est claire et familière à quiconque paie des tokens. Inutile de faire passer le travail de routine par l'option la plus chère. Les corrections simples, la génération de code standard et les petits refactorings peuvent aller vers un niveau moins coûteux. Les décisions d'architecture complexes et les contextes de débogage embrouillés restent réservés à l'option plus chère et plus puissante.

Chiffres et faits clés

• Baisse des dépenses quotidiennes estimées sur Codex : 65%.
• Vitesse de développement : maintenue, mais la source ne fournit aucune donnée chiffrée.
• Trois options utilisées : Astra, Sol et Luna.
• Approche : choix de l'option selon le type de tâche, plus pilotage des budgets.
• Type de métrique : des dépenses quotidiennes estimées, et non des factures confirmées sur une période.

Pourquoi ce chiffre appelle à la prudence

Le mot « estimées » compte ici. Il s'agit d'un calcul, pas d'un résultat issu de la comptabilité, et le résultat dépend beaucoup de la base de comparaison retenue. Si toutes les requêtes passaient auparavant par l'option la plus chère, 65% d'économies paraissent réalistes, voire modestes. Si la base était déjà un schéma en partie optimisé, le résultat est plus marquant.

La seconde question concerne la vitesse. « Vitesse de développement préservée » peut désigner le délai entre la tâche et le merge, le nombre de tickets clos ou une appréciation subjective de l'équipe. Sans métrique ni période de mesure, l'affirmation reste une déclaration, pas une preuve. Pour l'instant, la source ne montre ni le nombre d'itérations de revue, ni la part des tâches qu'il a fallu refaire avec une option plus puissante. Or ce sont précisément ces reprises qui rognent les économies.

Enfin, l'échelle est inconnue : 65% d'une petite somme et 65% d'un gros budget n'ont pas le même poids pour une équipe.

Ce que vous pouvez en retenir

Cette expérience est applicable même sans accès aux détails de LegalOn.

• Classez les tâches par complexité. Commencez par trois catégories : correction mécanique, fonctionnalité standard, problème atypique. Pour chacune, choisissez l'option minimale suffisante.
• Comptez le coût d'une tâche, pas celui d'une requête. Un modèle bon marché qui exige trois tentatives peut coûter plus cher qu'une seule tentative avec un modèle puissant.
• Fixez des budgets par équipe ou par flux de travail et suivez-les chaque jour. La granularité quotidienne dont parle LegalOn permet de repérer un dépassement avant la fin du mois.
• Mesurez la vitesse avant d'optimiser. Sans base de référence, impossible de vérifier qu'elle est restée la même.
• Suivez la part des escalades du niveau économique vers le niveau coûteux. Si elle augmente, le routage est mal réglé.

Le cas LegalOn montre que les dépenses de codage assisté par IA se pilotent aussi bien que des factures cloud. On pourra juger du tableau complet quand les détails seront connus : ce que sont Astra, Sol et Luna, et comment la vitesse a été mesurée.