Le coût réel d’un système d’IA en production

Le coût réel d’un système d’IA en production est le coût annuel du service rendu, qui additionne inférence, recherche, relecture humaine, exploitation, réindexation et temps des utilisateurs, et pas seulement le prix des jetons. La facture d’API n’isole pas nécessairement tous ces postes, et ne couvre pas le temps humain interne.

On me demande : combien coûte une requête. La réponse tient en centimes, elle rassure, et elle ne sert à rien.

La question utile est : combien coûte le service rendu, une fois qu’il tourne, sur une année. Ce chiffre doit être reconstitué à partir des charges réellement supportées, sans lui appliquer un multiplicateur général, et sa structure explique pourquoi certains projets deviennent déraisonnables à mesure qu’ils réussissent.

Le coût total de possession d’un système d’IA se définit donc comme la somme de ce qu’il faut payer, en argent et en temps, pour que le service reste disponible, exact et utilisé pendant sa durée de vie.

Les six postes de coût d’un système d’IA sont l’inférence, l’infrastructure de recherche, la relecture humaine, l’exploitation, la réindexation et le temps des utilisateurs, et ils n’ont ni la même nature ni la même visibilité. Les distinguer est la première condition pour les piloter.

Ce tableau, mis à jour chaque mois depuis les journaux réels, est ce que je livre désormais avec le système. Il sert deux fois. Il permet à la direction de décider d’étendre ou non, sur des chiffres constatés. Et il rend visible la dérive : une hausse par requête appelle un diagnostic : contexte élargi, reprises supplémentaires ou demandes devenues plus complexes.

Pour comparer deux solutions, je fixe la même unité : dossier effectivement terminé, réponse validée ou opération exécutée. Les échecs, nouvelles tentatives et retours au traitement manuel restent dans le coût de cette unité. Le temps gagné ne se déduit qu’après avoir mesuré le temps initial et le travail résiduel. Une dépense moindre par appel peut ainsi coexister avec un coût supérieur par dossier ; c’est ce dernier que la direction doit arbitrer.

Sur un système d’IA dont les réponses doivent être vérifiées, la relecture humaine peut peser davantage que l’inférence, selon le volume et le temps de contrôle mesurés. Le calcul est simple et rarement fait.

Prenons un exemple purement illustratif : si le système traite mille dossiers par mois et que chaque réponse demande deux minutes de vérification, cela représente plus de trente heures mensuelles. Il faut valoriser ce temps avec le coût horaire interne, puis le comparer à la facture réelle d’inférence ; aucun tarif n’est présumé ici.

La conséquence pratique est contre-intuitive : investir pour réduire le temps de relecture peut être plus rentable qu’optimiser le prix des jetons. Trois dispositifs y contribuent directement : des citations précises, la mise en évidence des passages sources, et un refus explicite en cas de doute.

Réduire le contexte, réutiliser des résultats valides et adapter le modèle à la tâche peuvent réduire le coût, si la qualité et les permissions restent vérifiées.

• Router les tâches. Toutes n’exigent pas le meilleur modèle. Une classification simple traitée par un petit modèle, avec escalade sur les cas ambigus, peut réduire la facture, à condition de revalider les erreurs et le service rendu.
• Mettre en cache ce qui se répète. Mesurer les questions répétées et vérifier les droits d’accès avant de réutiliser une réponse.
• Réduire le contexte envoyé. Si vingt extraits de même taille sont remplacés par cinq, le volume de ces extraits est divisé par quatre ; la facture totale dépend aussi des autres entrées et sorties.

Pour réduire le coût d’un système d’IA, je recommande de mesurer les postes dominants, puis de tester contexte, cache et routage selon leur gain réel et leur risque. Cet ordre se décide sur les journaux.

1. Réduire le contexte inutile. Mesurer la part variable des entrées, puis rejouer les cas sensibles. Lecture complémentaire : réduire de moitié le contexte envoyé.
2. Mettre en cache lorsque c’est admissible. Prévoir expiration, permissions et invalidation après changement documentaire, selon la mise en cache du contexte.
3. Router les tâches. Comparer qualité et coût, en comptant les escalades et appels ratés ; l’article sur GPT-4o mini décrit un candidat disponible à cette date.

Diviser le contexte par deux réduit le coût de la partie d’entrée concernée, pas celui de la recherche, de la sortie ou de la relecture. La fenêtre disponible n’est pas un objectif de remplissage, comme l’explique GPT-4 Turbo.

Prévoir une réindexation demande d’identifier les événements qui la déclenchent, le volume réellement recalculé et les contrôles nécessaires, plutôt que de l’exclure du premier budget annuel.

La réindexation peut apparaître lors d’un changement de corpus, de découpage ou d’embeddings. Certaines modifications exigent un recalcul complet ; d’autres permettent une reprise incrémentale. Il faut budgéter la décision, la validation et le calcul, dès la première année si ces événements sont possibles.

Les appels au modèle ne constituent qu’une ligne du budget d’un système d’IA, dont le poids doit être comparé à celui du corpus, de l’intégration et de l’exploitation. Aucun classement universel ne remplace cette mesure.

Une équipe peut optimiser une ligne visible tout en ignorant une charge plus lourde faute de l’avoir chiffrée. Je demande donc une ventilation avec périmètre, fréquence et source de chaque montant. Lecture complémentaire : où part réellement un budget d’IA.

Étiqueter chaque appel au modèle par fonctionnalité transforme un total mensuel en arbitrage instruit, à condition de relier cet identifiant aux jetons, aux reprises et au résultat réellement rendu. Sans cette mesure, aucune décision d’optimisation n’est fondée.

La mesure permet de vérifier si une fonctionnalité peu utilisée concentre une dépense disproportionnée, sans le supposer avant d’avoir les données. Les coupables habituels sont un traitement de fond programmé trop fréquemment, une conversation qui conserve tout son historique, ou une synthèse qui envoie l’intégralité d’un dossier.

Le diagnostic dépend de cette ventilation. Lecture complémentaire : mesurer le coût par fonctionnalité. La même instrumentation sert à suivre la qualité dans le temps, comme le montre l’évaluation continue, le chaînon manquant.

Les heures passées par les utilisateurs à apprendre, à corriger et à contourner un système d’IA pendant les premiers mois constituent une ligne réelle qui n’apparaît nulle part. Son importance doit être estimée sur un échantillon d’utilisateurs, sans ratio universel avec le coût de construction.

Trois usages du temps se cumulent. L’apprentissage, qui est légitime et se réduit. La correction, quand la réponse est presque juste et qu’il faut la reprendre : son poids doit être mesuré avant de choisir une optimisation. Et le contournement, quand l’utilisateur préfère faire autrement, qui ne produit aucun signal.

Mesurez la correction sur un échantillon : proportion de réponses reprises et temps nécessaire, en documentant également l’apprentissage et les contournements. Ce taux est le meilleur indicateur de qualité perçue dont je dispose, bien meilleur qu’une enquête de satisfaction, Lecture complémentaire : mesurer l’adoption, pas la satisfaction.

L’erreur la plus coûteuse en budgétant un système d’IA consiste à présenter le coût de construction et le prix des jetons comme le coût total, sans ligne d’exploitation annuelle. Le dossier est alors arbitré sur un chiffre faux.

• Extrapoler le coût d’un prototype à la production, alors que le volume, le contexte et la relecture changent d’échelle.
• Oublier la réindexation, qui peut survenir dès la première année ou au changement de corpus, de découpage ou de modèle d’embedding.
• Optimiser les jetons en premier, avant d’avoir mesuré la relecture et l’exploitation.
• Ne pas étiqueter les appels, et se retrouver face à un total mensuel impossible à expliquer.
• Ignorer le temps des utilisateurs, en particulier celui de la correction.

Un audit IA permet de reconstituer ces six postes sur un système existant avant de décider de l’étendre.