Le coût d’un assistant ne vient pas seulement des tokens du dernier appel. Un RAG génère des embeddings, recherche, reranke, appelle parfois plusieurs modèles et utilise des outils. Un agent peut répéter, attendre et demander une validation humaine. L’infrastructure, les logs et le support complètent le coût.
Optimiser exige de mesurer une tâche complète et sa réussite. Une requête bon marché qui produit une mauvaise réponse et une reprise manuelle est une fausse économie.
Construire une unité économique
Choisir une unité liée au métier : dossier qualifié, document traité, réponse utile, commande préparée ou incident résolu. Pour chaque unité, compter :
- appels ;
- tokens ;
- embeddings ;
- reranking ;
- outils ;
- stockage ;
- retries ;
- validation ;
- erreurs ;
- infrastructure ;
- support.
Cette unité permet de comparer une architecture, un modèle et le processus actuel.
Calculer le coût par tâche réussie
Une formule simplifiée est :
(coûts variables + coûts fixes affectés + validation + reprises) / tâches réussies
Le taux de réussite doit respecter une définition. Une réponse affichée n’est pas une tâche réussie si l’utilisateur doit tout refaire.
Les scénarios intègrent volume moyen, pic, croissance et saisonnalité. Les tarifs sont datés et vérifiés, car ils évoluent.
Outil local de cadrage
Atelier de cadrage
Structurez les décisions principales avant de lancer un atelier métier. Les réponses restent dans votre navigateur.
Décomposition du coût d’une tâche IA entre contexte, recherche, modèle, outils, reprises, validation et exploitation.
Éviter l’appel au modèle
Le levier le plus efficace est de ne pas appeler un LLM lorsque :
- une règle suffit ;
- une réponse existe en cache ;
- la requête est invalide ;
- les données manquent ;
- l’utilisateur n’a pas le droit ;
- une recherche classique répond ;
- une opération peut être regroupée.
La classification initiale peut être déterministe ou utiliser un petit modèle. Les parcours fréquents sont optimisés en priorité.
Router selon la difficulté
Toutes les tâches ne nécessitent pas le modèle le plus capable. Un routeur peut choisir :
- règle ;
- modèle léger ;
- modèle spécialisé ;
- modèle général plus puissant ;
- traitement humain.
Le routage utilise intention, longueur, risque, langue et confiance. Il est évalué : une erreur d’orientation peut coûter plus que l’économie.
Pour les tâches sensibles, la politique et la donnée peuvent imposer un environnement indépendamment du coût.
Réduire le contexte
Les prompts accumulent parfois historique, documents et instructions. Un contexte plus long augmente coût et latence, et peut réduire la précision.
Les leviers sont :
- récupération plus précise ;
- déduplication ;
- filtres ;
- compression avec provenance ;
- mémoire structurée ;
- résumé des échanges anciens ;
- contexte différent selon l’étape ;
- suppression des exemples inutiles.
Le gain doit être validé par les évaluations.
Optimiser le RAG
Une mauvaise recherche pousse à envoyer trop de passages. Améliorer métadonnées, hybride et reranking peut réduire le contexte final.
Les embeddings sont calculés uniquement pour les contenus changés. Les lots, dimensions et modèles sont choisis selon le corpus. Un changement d’embedding nécessite une comparaison avant réindexation complète.
Le reranking est réservé aux requêtes où il apporte un gain. Un petit nombre de candidats réduit le coût.
Cache
Plusieurs niveaux existent :
- réponse exacte ;
- résultat de recherche ;
- embeddings de requête ;
- préfixe de prompt ;
- sortie d’outil ;
- sous-tâche agentique.
La clé doit inclure version, droits, langue et fraîcheur. Un cache partagé entre utilisateurs ne doit pas exposer des données privées. L’invalidation suit les sources et politiques.
Les fournisseurs peuvent proposer des mécanismes de cache de contexte ; leurs conditions et économies sont vérifiées.
Batch et asynchrone
Les tâches non interactives peuvent être regroupées et traitées avec une capacité moins coûteuse ou à un horaire adapté. Les API batch éventuelles ont des délais et tarifs spécifiques.
L’architecture sépare les besoins temps réel des traitements de fond. Un utilisateur reçoit un état et une notification plutôt qu’une connexion maintenue inutilement.
Limiter les retries et les boucles
Un timeout ne signifie pas toujours échec. L’idempotence et la vérification évitent de répéter une opération. Les retries utilisent un nombre maximal, un backoff et une distinction entre erreurs temporaires et permanentes.
Les agents ont un budget d’étapes, de durée et de coût. Ils s’arrêtent lorsqu’aucune nouvelle preuve n’apparaît.
Sorties structurées
Un format clair réduit les appels de correction. Le schéma est validé et les erreurs déterministes sont renvoyées au modèle avec un nombre limité de tentatives.
Pour une extraction, un modèle spécialisé ou une règle de post-traitement peut être plus économique qu’une conversation générale.
Modèles ouverts et capacité privée
Une infrastructure privée peut réduire le coût variable à volume stable, mais ajoute investissement et exploitation. Il faut calculer le taux d’utilisation, la capacité de pic, l’énergie, le support et le renouvellement.
Une architecture hybride route le volume prévisible vers une capacité réservée et les pics ou tâches complexes vers une API. La qualité et la souveraineté restent des contraintes.
Négocier et réserver
À volume élevé, les fournisseurs peuvent proposer capacités, engagements ou tarifs adaptés. Une réservation n’est rentable que si l’usage est stable et que la dépendance est acceptée.
Le contrat doit traiter versions, disponibilité, région, réversibilité et évolution des prix. La négociation ne remplace pas l’optimisation technique.
Réduire les coûts de validation
L’interface montre sources, différences et zones incertaines pour accélérer la revue. Les contrôles déterministes filtrent les erreurs avant l’humain. L’échantillonnage est adapté au risque et à la qualité démontrée.
Le temps humain est suivi dans le coût par tâche.
FinOps pour l’IA
Une pratique FinOps associe visibilité, ownership et optimisation. Chaque équipe connaît :
- usage ;
- budget ;
- coût unitaire ;
- modèle ;
- qualité ;
- anomalies ;
- prévision.
Des tags et identifiants attribuent les appels au cas d’usage. Les alertes détectent pics, boucles, changement de contexte et dérive de taux de réussite.
Budgets et garde-fous
Les limites existent par utilisateur, équipe, tâche et période. Lorsqu’un budget approche, le système peut :
- utiliser un modèle plus léger ;
- réduire les étapes ;
- passer en asynchrone ;
- demander une validation ;
- refuser une tâche non prioritaire.
Les décisions à risque ne doivent pas être dégradées silencieusement pour économiser.
Mesurer qualité et coût ensemble
Un tableau compare les versions sur :
- succès ;
- erreurs critiques ;
- latence ;
- coût ;
- validation ;
- satisfaction.
La frontière de Pareto montre les options qui améliorent une dimension sans dégrader excessivement les autres. Le choix est fait par cas d’usage.
Une démarche continue
Commencer par instrumenter, identifier les trois postes majeurs, tester un levier et vérifier la qualité. Les économies durables viennent souvent du processus : meilleur routage, moins de contexte, moins de reprises et moins d’appels inutiles.
Partitech peut instrumenter les coûts, construire le routeur, optimiser RAG et agents et comparer les scénarios d’hébergement. L’objectif est un coût par tâche maîtrisé avec une qualité et une sécurité prouvées.
Parlons de votre projet
Auditer et optimiser le coût de votre plateforme IA avec Partitech. Contactez Partitech.