Le coût réel d’une fonctionnalité IA en production

Le coût réel d’une fonctionnalité IA en production ne se limite pas à l’API

Réponse directe : le coût réel d’une fonctionnalité IA en production est la somme de quatre postes rarement budgétés ensemble : la préparation des données, l’appel au modèle, les garde-fous et la supervision, la maintenance de la dérive. L’appel au modèle, celui qu’on regarde en premier sur une grille tarifaire, représente souvent moins de la moitié de la facture totale sur trois ans. Le reste de cet article détaille ces quatre postes, donne un ordre de grandeur par type de fonctionnalité, et explique dans quels cas il vaut mieux ne rien construire.

Une PME romande qui veut ajouter un assistant de support, un module d’extraction de documents ou un moteur de scoring reçoit en général un chiffre unique : le prix au token du modèle choisi. Ce chiffre rassure, parce qu’il est précis. Il est aussi presque toujours incomplet. La facture d’exploitation d’une fonctionnalité IA en production suit un tout autre schéma que celle d’un module logiciel classique, parce qu’elle continue de coûter de l’argent après la mise en service, à un rythme qui dépend du comportement réel des utilisateurs et non du cahier des charges initial.

Les quatre postes qui composent la facture

Chaque poste apparaît à un moment différent du cycle de vie de la fonctionnalité. Les confondre conduit systématiquement à sous-estimer le budget annuel de 30 à 50 pour cent, selon les retours d’expérience publiés sur des projets de taille comparable.

1. La préparation des données

Avant le premier appel au modèle, il faut nettoyer, structurer et découper les documents ou les enregistrements sur lesquels la fonctionnalité va s’appuyer. Pour un système de type RAG (recherche augmentée par récupération de contexte), ce poste inclut l’indexation, le choix de la taille des fragments et la mise à jour continue de la base documentaire. C’est le poste le plus sous-estimé, parce qu’il ressemble à du travail d’intégration ordinaire et qu’aucun fournisseur de modèle ne le facture séparément sur sa grille tarifaire.

2. L’appel au modèle

C’est le poste visible : un prix par million de tokens en entrée, un autre en sortie. Le calcul se complique dès qu’un agent enchaîne plusieurs appels pour une seule tâche (classification de l’intention, planification, sélection d’un outil, exécution, vérification), ou dès qu’un historique de conversation s’accumule dans le contexte envoyé à chaque requête. Un agent qui exécute cinq étapes internes pour répondre à une seule question de l’utilisateur peut multiplier par cinq le coût apparent d’une simple réponse directe.

3. Les garde-fous et la supervision

Détection des réponses hors sujet, filtrage des données sensibles, journalisation par fonctionnalité et par utilisateur, alerte de dépassement de budget : ce poste ne produit aucune valeur visible pour l’utilisateur final, mais son absence transforme un incident mineur en facture à cinq chiffres. Un bouclage d’agent qui relance indéfiniment le même appel, ou une fuite de contexte qui gonfle chaque requête, peut faire basculer une facture mensuelle prévue à quelques centaines de francs à plusieurs milliers en quelques jours, sans qu’aucune alerte ne se déclenche si rien n’a été mis en place pour la détecter.

4. La maintenance et la dérive

Un modèle change de version, un fournisseur ajuste ses prix, le comportement des utilisateurs évolue et les cas limites se multiplient. La fonctionnalité qui fonctionnait à 95 pour cent de fiabilité au lancement dérive si personne ne réévalue régulièrement les réponses produites en conditions réelles. Ce poste inclut aussi les mises à jour de prompts, les tests de régression sur les cas déjà résolus, et l’ajustement du choix de modèle quand un concurrent moins cher atteint une qualité suffisante pour la tâche.

Un ordre de grandeur, pas un devis

Les chiffres ci-dessous viennent d’observations publiées sur des projets nord-américains, à échelle plus grande que la plupart des PME romandes. Ils servent de repère de proportion entre les postes, pas de grille tarifaire à appliquer tel quel : une fonctionnalité unique ajoutée à un produit existant coûte nettement moins qu’une plateforme construite depuis zéro.

La conséquence pratique : négocier uniquement le prix au token d’un fournisseur agit sur un seul poste parmi quatre, souvent celui qui pèse le moins sur trois ans une fois la fonctionnalité en production.

Un exemple chiffré, à titre d’illustration

Prenons un assistant de support qui répond aux questions de premier niveau pour une PME de taille moyenne : 200 conversations par jour, trois échanges en moyenne par conversation, un contexte moyen de 2 000 tokens par appel une fois l’historique et les documents récupérés inclus. Cela représente environ 1,2 million de tokens d’entrée par jour, un volume qui reste largement dans les grilles tarifaires standard des fournisseurs de modèles actuels et qui, sur ce seul poste, coûte en général quelques centaines de francs par mois, pas plus.

Le calcul change de nature dès qu’on ajoute les trois autres postes. La préparation initiale de la base de connaissances (indexation des documents produit, des conditions générales, de l’historique des tickets résolus) demande un travail d’intégration ponctuel, suivi d’une mise à jour continue à chaque nouveau document. Les garde-fous demandent une détection des questions hors périmètre (juridique, facturation sensible) et un renvoi vers un humain plutôt qu’une réponse inventée. La maintenance demande une relecture régulière d’un échantillon de conversations réelles, pour vérifier que les réponses restent correctes quand le catalogue produit change. Additionnés, ces trois postes dépassent presque toujours le coût des appels au modèle sur la durée, même pour un volume aussi modeste que celui de cet exemple.

Ce n’est pas une règle universelle : un cas d’usage à très fort volume et à contexte court (classification d’un champ de formulaire, par exemple) déplace le rapport de force vers l’inférence. La méthode reste la même : chiffrer les quatre postes séparément avant de comparer des offres.

Comment estimer le coût avant de commencer

Une estimation utile se construit avant d’écrire la moindre ligne de prompt, avec des données mesurables plutôt que des hypothèses.

1. Compter les requêtes réelles attendues par jour, pas un volume théorique : nombre d’utilisateurs actifs multiplié par le nombre d’interactions par utilisateur.
2. Estimer la longueur moyenne du contexte envoyé à chaque appel, historique de conversation et documents récupérés inclus, pas seulement le message de l’utilisateur.
3. Compter les appels par tâche si un agent orchestre plusieurs étapes, pas un seul appel par interaction visible.
4. Ajouter un taux de nouvelle tentative réaliste (10 à 20 pour cent est un point de départ courant sur les intégrations avec des systèmes tiers instables).
5. Chiffrer séparément l’intégration aux systèmes existants : CRM, ERP, base de tickets. C’est souvent le poste le plus long à livrer, pas le plus visible sur une facture d’API.
6. Prévoir une réserve de 15 à 25 pour cent sur le total, pour les garde-fous et la dérive qui apparaissent seulement après quelques semaines d’usage réel.

Quand une fonctionnalité IA maison n’est pas le bon choix

Ce n’est pas toujours la bonne réponse, et le dire clairement évite des mois de développement inutiles.

Si le volume de requêtes attendu reste faible (quelques dizaines par jour) et que la tâche est bien définie, un outil existant (agent de support packagé, extension d’un CRM déjà en place, automatisation sans code) couvre souvent le besoin pour une fraction du budget d’un développement maison, sans les postes 3 et 4 détaillés plus haut. Construire une fonctionnalité sur mesure a du sens quand la tâche touche une donnée propriétaire, un flux métier spécifique à l’entreprise, ou un volume qui justifie l’investissement en supervision. Si aucune de ces conditions n’est réunie, le retour sur investissement d’un développement maison est rarement au rendez-vous avant douze à dix-huit mois, et le poste maintenance continue de courir même quand l’usage réel reste marginal.

Autre cas fréquent : une entreprise qui n’a pas encore de processus de mesure de la qualité des réponses produites. Ajouter une fonctionnalité IA avant de savoir comment on va évaluer si elle fonctionne revient à construire sans plan de contrôle. Mieux vaut d’abord définir un jeu de cas de test représentatifs, même modeste, que de lancer une fonctionnalité dont personne ne pourra dire six mois plus tard si elle a dérivé.

Ce que change une approche Forward Deployed Engineer sur ce calcul

Une part importante du dépassement de budget vient d’un choix fait trop tôt : construire l’architecture complète avant d’avoir observé le comportement réel des utilisateurs sur les premières semaines. L’approche que nous suivons en mission, proche de ce que recouvre le forward deployed engineering, consiste à livrer un périmètre restreint sur des données réelles dès les premières semaines, puis à ajuster les postes 3 et 4 en fonction de ce qui casse effectivement, plutôt que de les provisionner sur hypothèse. Nous avons suivi cette logique sur une plateforme de gestion de patrimoine où l’intégration aux systèmes existants représentait la majorité du travail, loin devant l’appel au modèle lui-même : le code de cette plateforme, développée sur une base d’environ 106 000 lignes, a grandi par itérations mesurées plutôt que par un plan figé au démarrage.

C’est aussi ce qui explique pourquoi les points de rupture d’un agent en production touchent rarement le modèle en premier : nous détaillons ces points de rupture dans un article dédié à ce qui casse en premier quand un agent IA passe en production. Pour une PME qui hésite entre un module packagé et un développement sur mesure, ce sont les mêmes questions qui permettent de trancher : volume réel, sensibilité des données, capacité à mesurer la qualité dans le temps. Ce sont aussi les questions que nous posons systématiquement avant de chiffrer une mission au forfait ou en régie, et que présente ce que fait le studio au quotidien sur ce type de projet.