Le coût réel d'un système IA : Après le développement, quels sont les frais de fonctionnement ?
Frais de modèle, entretien, révision humaine et dérive qualitative silencieuse — une manière pratique de budgétiser les douze mois suivant le lancement de votre système d'IA.

La facturation de l'IA : au-delà des coûts apparents
La plupart des budgets alloués à l'IA s'arrêtent à la phase de lancement. La proposition couvre la phase de découverte, de développement, d'intégration et une date de mise en service. Ensuite, le système fonctionne pendant deux ans, mais les coûts associés restent souvent non documentés. Voici ce qui figure réellement sur les factures.
Le coût prévisible : les frais du modèle
Les frais du modèle sont calculés par jeton, approximativement par mot entrant et sortant. Cela les rend prévisibles si vous effectuez le calcul une fois.
Prenons l'exemple d'un assistant interne gérant 8 000 conversations par mois, avec six tours de conversation en moyenne. Cela représente 48 000 appels au modèle. Chaque appel inclut vos instructions, les documents récupérés et la conversation jusqu'à présent, soit environ 5 000 jetons en entrée, et génère environ 400 jetons en sortie. Vous achetez ainsi 240 millions de jetons d'entrée et 19 millions de jetons de sortie par mois. À des prix moyens du modèle, cela représente environ 1 000 dollars par mois, et le stockage des prompts peut réduire significativement ce coût.
Deux aspects surprennent souvent les utilisateurs : tout d'abord, l'entrée domine largement les coûts ; vous payez pour tout ce que vous envoyez, à chaque tour, et la longueur du contexte est le principal levier de contrôle sur les dépenses. Ensuite, les retents, les évaluations et les tests internes ajoutent 15 à 30 % aux coûts de production. Budgettez le montant brut, pas le net.
Les prix des modèles par jeton ont constamment diminué. Les dépenses totales augmentent généralement malgré tout, car l'utilisation croît et que de nouveaux modèles sont utilisés pour des tâches plus complexes. Préparez-vous en fonction du volume, pas des tarifs.
Les coûts cachés : ce qui n'est pas inclus dans la proposition
Les frais du modèle ne représentent généralement pas la ligne budgétaire la plus importante. Le reste des coûts de fonctionnement est lié aux tâches nécessaires au bon fonctionnement des systèmes d'IA :
- Révision humaine : une personne lit un échantillon des sorties réelles chaque semaine pour évaluer la qualité. Pour un système client, prévoyez quelques heures par semaine, en permanence.
- Infrastructure autour du modèle : index de recherche, magasins de vecteurs, journalisation et pipeline pour maintenir à jour vos documents. Modeste individuellement, mais constant dans l'ensemble.
- Travail d'adaptation : nouveaux produits, nouvelles politiques, nouveaux cas limites que le système gère mal. Attendez un petit flux continu d'ajustements plutôt que des mises à jour majeures occasionnelles.
- Changements de fournisseur : les modèles deviennent obsolètes selon des calendriers publiés. La migration vers un successeur implique de rétester tout ce que l'ancien modèle faisait bien, généralement une fois par an.
- Conformité et archives : conservation, contrôle d'accès et audit du parcours du système avec un client en mars.
L'élément surprenant : la dérive
Les logiciels échouent bruyamment. Les systèmes d'IA se dégradent silencieusement et restent confiants tout au long du processus.
Votre entreprise dérive en premier. Les prix changent, un produit est retiré, une politique est réécrite. Le système continue de répondre avec la version qui lui a été donnée, fluemment et incorrectement, jusqu'à ce que quelqu'un s'en aperçoive.
Vos utilisateurs dérivent ensuite. Une fois qu'ils ont compris ce que le système gère, ils poussent dans des domaines adjacents non prévus à l'origine. Un trafic qui ressemblait à une réponse aux FAQ devient une interprétation de contrat, et la précision mesurée au lancement ne décrit plus les faits.
Votre contenu dérive également. La récupération sur 400 documents se dégrade sur 4 000, car des correspondances plus proches étouffent la bonne réponse dans les résultats.
Rien de tout cela déclenche d'alerte. Cela apparaît des mois plus tard sous forme d'escalades croissantes, d'utilisation décroissante ou d'une plainte d'un client qui a agi sur une information fournie par le système. À ce moment-là, la réparation coûte plus cher que la surveillance aurait coûté.
La défense est peu glamour et bon marché : échantillonnez 50 à 100 interactions réelles par mois, notez-les par rapport à ce qu'un bon employé dirait, et suivez le score dans le temps. Une seule personne, demi-journée par mois. Cette simple habitude détecte presque tous les modes d'échec ci-dessus lorsqu'ils sont encore petits.
Un budget résistant à la réalité
Prévoir un coût annuel de fonctionnement entre 30 et 50 % du coût de développement pour les deux premières années. En dessous de 20 %, le système est négligé, et la courbe de qualité le reflétera. Au-dessus de 60 %, soit le développement a laissé trop de travail inachevé, soit l'utilisation de cas est plus volatile qu'elle n'y paraissait.
Divisez ce montant en trois catégories : utilisation (frais du modèle et infrastructure, évolutivité avec le volume), garde (révision, surveillance, archives - approximativement fixe) et changement (adaptation à votre entreprise et au plan de route de votre fournisseur). Les tranches se comportent différemment, donc un chiffre global unique vous induira en erreur la première fois que le volume double.
Désignez ensuite un propriétaire. Un système d'IA sans propriétaire nommé ni ligne budgétaire dédiée ne sera pas entretenu ; il sera toléré jusqu'à ce qu'il soit abandonné discrètement. C'est le véritable coût de l'omission de cette étape - pas le dépassement du budget, mais le paiement du développement deux fois.
Faites le calcul du taux d'utilisation avant la phase de développement, et non après. Le chiffre change souvent ce que vous décidez de développer, c'est exactement son but. C'est la première calculation que nous faisons avec un client, et parfois, elle est la raison pour laquelle nous recommandons un système plus petit que celui qu'ils ont initialement demandé.