INTRODUCTION
Une facture de modèle plus légère ne termine pas le travail
Un modèle moins cher peut rendre une fonctionnalité utile économiquement viable. Il peut aussi permettre à une fonctionnalité peu utile de donner davantage de travail à tout le monde. La décision produit consiste à savoir si la baisse du coût de génération améliore réellement le résultat attendu, une fois la vérification, les corrections et le support pris en compte.
Anthropic a lancé Claude Haiku 5.5 le 7 octobre 2026, en le destinant aux tâches bien délimitées et répétées à grande échelle, tout en réservant une place aux modèles plus puissants pour les tâches difficiles. Une raison de réexaminer les usages d'un produit, plutôt que de remplacer automatiquement son modèle partout.
Lire le tarif, puis changer d'unité
Vérification du 9 octobre : Claude Platform affiche pour Haiku 5.5 des tarifs entrée/sortie de 0,10/0,50 dollar par million de tokens jusqu’à 100 000 tokens de prompt, puis 0,50/2,50 dollars au-delà. Ces tarifs API ne représentent pas une tâche terminée. Comptabiliser séparément le cache, les outils et les autres frais applicables.
Une équipe produit a besoin d'une autre unité : le coût par résultat accepté. Un résumé qu'un conseiller doit réécrire ne vaut pas un résumé directement exploitable. Une étiquette documentaire qui envoie discrètement un dossier au mauvais endroit n'est pas une bonne affaire sous prétexte que sa génération coûte peu.
Une méthode concrète consiste à diviser les coûts du modèle, des outils, de la vérification et des corrections par le nombre de résultats satisfaisant un critère d'acceptation défini à l'avance. Le délai et les erreurs graves doivent être suivis séparément. Une moyenne basse ne doit pas masquer un échec rare aux conséquences inacceptables.
La file de vérification peut absorber toute l'économie
Prenons un outil interne de synthèse hypothétique, sans lien avec un résultat client de Blanche ni avec un benchmark. Il traite 1 000 documents. L'équipe prévoit 20 dollars de génération et 100 minutes de vérification, valorisées en interne à 30 dollars de l'heure. Le coût cumulé atteint 70 dollars.
Supposons qu'une autre configuration ramène la génération à 5 dollars, mais double la vérification à 200 minutes. Le total devient 105 dollars. Cet exemple ne prédit les performances d'aucun modèle. Il montre simplement qu'une facture API plus faible ne suffit pas à prouver qu'un processus coûte moins cher. L'hébergement, les taxes, le support et l'intégration sont exclus de ces totaux illustratifs.
Le design compte autant que le choix du modèle. Afficher les passages sources à côté du résumé. Faciliter l'examen des champs incertains. Permettre de corriger un élément sans relancer toute la tâche. Vérifier que ces changements réduisent le temps de contrôle avant d'augmenter le volume produit.
Confier une tâche plus petite au petit modèle
Un premier essai raisonnable porte sur une étape délimitée dont on peut vérifier la réponse : classer une demande entrante, extraire un champ précis ou préparer un résumé court à relire. L'entrée, la sortie autorisée et le traitement des échecs doivent être explicites.
Cela n'impose pas une architecture compliquée d'agents. Dans un produit hypothétique de service client, une première version pourrait répartir les demandes entre quelques files existantes et transmettre les cas ambigus à une personne. Elle ne devrait pas se mettre discrètement à autoriser des remboursements parce que le même modèle sait rédiger une réponse plausible.
Produire davantage ne crée pas automatiquement plus de valeur. Si une équipe ne peut examiner que dix propositions, en générer cent risque de créer un nouveau stock de travail. L'économie pourrait être mieux employée à accélérer le retour, à ajouter un contrôle sur les cas risqués ou à proposer une fonctionnalité auparavant trop coûteuse.
Le modèle plus puissant est parfois le choix le plus simple
Répartir le travail entre plusieurs modèles ajoute de la maintenance, des évaluations et un endroit supplémentaire où les erreurs peuvent se cacher. Pour un produit à faible volume ou une tâche demandant un raisonnement prolongé, un seul modèle plus puissant peut coûter moins cher au total. L'option économique doit démontrer son intérêt dans les résultats observés, pas seulement dans un tableau tarifaire.
C'est aussi pourquoi une démonstration soignée ne suffit pas. Tester les cas ordinaires, les entrées ambiguës et les échecs connus avec les mêmes critères. Compter les escalades et les nouvelles tentatives. Examiner les erreurs elles-mêmes, pas seulement un taux de réussite global. Garder un retour possible à la configuration précédente pendant un déploiement limité.
Avant de changer le modèle par défaut
- Nommer le résultat attendu par le client et définir ce qui rend un résultat acceptable.
- Établir une référence pour les coûts, l'attente, l'effort de vérification et la gravité des erreurs.
- Comparer les mêmes tâches représentatives, y compris les cas difficiles.
- Intégrer les appels d'outils, nouvelles tentatives, corrections et maintenance dans la décision.
- Étendre l'usage seulement si le processus complet s'améliore sans échecs inacceptables.
La baisse du prix de l'inférence ouvre des possibilités pour mieux concevoir les produits. La question utile est ce qu'on en fait. Pour choisir la prochaine fonctionnalité, partir du produit et de ses utilisateurs, puis retenir le modèle qui permet à l'ensemble de l'expérience de fonctionner.