Combien coûte un projet IA, du POC à la production ?

Un projet d’intelligence artificielle coûte rarement là où on l’attend. La question qui revient en rendez-vous porte presque toujours sur le prix du modèle, alors que c’est le poste le plus faible et le plus facile à piloter. Les trois budgets qui décident du coût réel sont ailleurs : le cadrage, la préparation des données et de l’intégration, et l’exploitation dans la durée.

Cet article donne les ordres de grandeur vérifiables, la méthode pour calculer votre propre seuil de bascule entre une API et un serveur dédié, et les cinq mécanismes qui font déraper un budget. L’objectif n’est pas de vous donner un prix, qui ne voudrait rien dire sans votre cas d’usage, mais de vous permettre de challenger n’importe quel devis.

Le prix au jeton, et pourquoi ce n’est presque jamais le problème

Commençons par le chiffre que tout le monde regarde. Les modèles se facturent au million de jetons, séparément en entrée et en sortie, la sortie coûtant systématiquement plus cher. Sur la grille publique d’OpenAI, un modèle léger comme GPT-4o-mini est à 0,15 dollar le million de jetons en entrée et 0,60 en sortie, tandis qu’un modèle haut de gamme monte à 10 dollars en entrée et 50 en sortie. Chez Mistral, Mistral Large est annoncé à 0,50 dollar en entrée et 1,50 en sortie.

Le rapport entre les deux extrémités de cette grille dépasse un facteur soixante en entrée et quatre-vingts en sortie. Autrement dit, le choix du modèle pèse davantage sur votre facture que tout ce que vous pourrez optimiser ensuite. Classer un e-mail, extraire une date ou reformuler un paragraphe ne demandent pas le modèle le plus capable du marché. Réserver celui-ci aux tâches qui l’exigent vraiment divise la note sans dégrader le résultat.

Deux mécanismes complètent le tableau et sont largement sous-utilisés. La mise en cache du contexte fait tomber le prix des jetons d’entrée déjà vus à un dixième du tarif chez OpenAI, ce qui change tout dès qu’un système renvoie les mêmes instructions ou les mêmes documents à chaque appel. Et le traitement par lot, pour tout ce qui n’a pas besoin d’une réponse immédiate, applique une remise de moitié. Un projet qui traite des documents la nuit paie donc la moitié du prix affiché.

Le second levier est la taille du contexte. Beaucoup d’implémentations renvoient à chaque appel un prompt système de plusieurs milliers de mots et des documents recopiés sans nécessité. C’est ce volume, multiplié par le nombre d’appels, qui construit la facture, pas le tarif unitaire.

Les trois phases, et ce que chacune coûte vraiment

Le cadrage et la preuve de concept

C’est la phase la plus rentable et celle qu’on saute le plus souvent. Son objet n’est pas de construire, c’est de répondre à trois questions : le cas d’usage a-t-il une valeur mesurable, les données nécessaires existent-elles dans un état exploitable, et un modèle sait-il faire la tâche à un niveau acceptable.

La confusion entre preuve de concept, prototype et produit minimum viable coûte des mois. Nous l’avons détaillée dans notre article sur ce qu’il faut construire en premier. Retenez la distinction utile : une preuve de concept a le droit d’être moche, lente et manuelle, mais elle doit trancher une incertitude. Si elle ne tranche rien, elle ne sert à rien, quel que soit son coût.

Le budget de cette phase se compte en jours de cadrage, pas en licences. Et c’est le seul moment où l’on peut encore décider de ne pas faire le projet, ce qui est souvent la décision la plus rentable de l’année.

La mise en production

C’est ici que se concentre l’essentiel du coût, et l’essentiel de la surprise. Le modèle est un composant parmi d’autres. Autour de lui, il faut construire la récupération des données, leur découpage, leur indexation, la gestion des accès, la journalisation, l’interface, et le traitement des cas où le système ne sait pas répondre.

Sur un assistant branché sur vos documents internes, la qualité dépend beaucoup plus de cette architecture que du modèle choisi. C’est le sujet de notre article sur l’architecture RAG sur des documents internes, et c’est aussi pourquoi la question du choix entre RAG et fine-tuning se pose au cadrage et pas après.

Un repère de proportion, tiré de nos projets : sur un assistant documentaire d’entreprise, le coût d’appel au modèle représente rarement plus d’un dixième du budget de la première année. Le reste est du développement, de l’intégration et de la préparation de données.

L’exploitation

Le poste oublié. Un système d’IA en production demande une supervision, parce qu’il échoue autrement qu’un logiciel classique : il ne plante pas, il répond mal. Cela suppose de journaliser les échanges, de surveiller les coûts, de poser des plafonds de dépense, et de traiter les retours des utilisateurs.

S’y ajoute une charge que personne n’anticipe : les modèles évoluent. Un fournisseur déprécie une version, en publie une meilleure et moins chère, ajuste ses tarifs. Ce qui marchait il y a six mois doit être revérifié. Budgéter zéro pour cette maintenance revient à laisser la qualité se dégrader silencieusement.

Le poste que personne ne budgète : l’évaluation

C’est la ligne qui distingue un projet qui tient d’un projet qui impressionne en démonstration puis déçoit. Sans évaluation, vous n’avez aucun moyen de savoir si un changement de modèle, de prompt ou de découpage améliore ou dégrade le système. Vous naviguez à l’impression.

La bonne nouvelle est que cela coûte moins cher qu’on ne le croit. Cinquante à cent exemples représentatifs, annotés à la main avec la réponse attendue, suffisent à comparer deux configurations de façon fiable. Deux mesures suffisent à piloter : le rappel, qui indique si la bonne information figure dans ce qui a été retrouvé, et la fidélité, qui mesure la part d’affirmations non appuyées par les sources fournies.

Sur cette seconde mesure, le classement public de Vectara donne un repère utile : même les meilleurs modèles restent à quelques pour cent d’hallucination sur une tâche de résumé fidèle à un document fourni. Ce n’est pas zéro, et c’est exactement pourquoi il faut mesurer sur vos propres documents plutôt que se fier à un score général.

Comptez une à deux journées pour construire ce jeu d’évaluation. C’est l’investissement au meilleur rendement de tout le projet, parce qu’il rend toutes les décisions suivantes vérifiables.

API ou serveur dédié : le seuil se calcule

La question revient systématiquement, souvent motivée par la souveraineté autant que par le coût. Elle mérite un calcul plutôt qu’une intuition, et le calcul est simple : divisez le coût mensuel de votre serveur par le prix au million de jetons de l’API que vous remplaceriez.

Un ordre de grandeur pour ancrer le raisonnement. Chez Scaleway, une instance équipée d’un GPU L4 est facturée 0,79 euro de l’heure, soit environ 575 euros par mois en fonctionnement continu. Face à un modèle léger facturé quelques dizaines de centimes le million de jetons, il faut consommer plusieurs milliards de jetons mensuels avant que le serveur devienne le choix économique. Face à un modèle haut de gamme, le seuil descend à quelques centaines de millions. Dans les deux cas, c’est un volume que la plupart des projets n’atteignent jamais.

Deux nuances complètent ce calcul. D’abord, la taille du modèle doit tenir dans la mémoire du GPU, ce qui disqualifie les cartes d’entrée de gamme pour les grands modèles. Ensuite, le moteur d’inférence compte autant que la carte : un moteur optimisé pour le débit comme vLLM sert bien plus de requêtes par seconde qu’une exécution séquentielle, ce que nous détaillons dans notre article sur l’hébergement d’un LLM open source.

Enfin, le coût n’est pas toujours le vrai motif. Quand la contrainte est la confidentialité, le raisonnement change de nature. Il vaut alors la peine de vérifier ce que dit réellement le fournisseur : OpenAI indique dans sa documentation sur les données de l’API que les données envoyées ne servent pas à entraîner ses modèles, mais qu’elles transitent par des journaux de surveillance des abus conservés jusqu’à trente jours. C’est l’arbitrage que nous détaillons dans notre comparaison Mistral face à OpenAI.

Les cinq mécanismes qui font déraper un budget

• Un périmètre qui n’a jamais été fermé. Un assistant censé répondre à tout n’a pas de critère de réussite, donc pas de fin. Le premier travail de cadrage consiste à écrire ce que le système ne fera pas.
• Des données qu’on découvre en route. Documents dispersés, formats hétérogènes, versions contradictoires, droits d’accès flous. C’est le poste qui explose le plus souvent, et il se mesure avant de commencer, pas pendant.
• Aucune évaluation. Sans jeu de test, chaque modification se juge à l’impression, les allers-retours se multiplient et le budget de développement double sans que la qualité progresse.
• Un agent avec trop de droits. Dès qu’un système peut agir, l’injection de requête devient un risque réel, classé premier des risques du Top 10 OWASP pour les applications à modèles de langage. Restreindre les outils et exiger une validation humaine sur les actions irréversibles coûte moins cher que l’incident.
• Pas de plafond de dépense. Une boucle mal fermée ou un contexte qui grossit peuvent multiplier la consommation en une nuit. Un plafond par clé et une alerte évitent la mauvaise surprise en fin de mois.

Trois repères pour lire un devis

Quand vous recevez une proposition, trois éléments disent immédiatement si elle a été construite ou improvisée. Le premier est la présence d’une ligne d’évaluation. Un devis qui ne prévoit ni jeu de test ni critère de réussite chiffré vend une démonstration, pas un système en production.

Le deuxième est le traitement des données. Si la préparation des sources apparaît comme une ligne forfaitaire sans avoir été regardée, elle sera soit largement sous-estimée, soit facturée en avenant. Un prestataire sérieux demande à voir un échantillon réel avant de chiffrer, et refuse de s’engager sur un corpus qu’il n’a pas ouvert.

Le troisième est le coût de fonctionnement, distinct du coût de construction. Une proposition qui ne dit rien du budget mensuel d’appels, de l’hébergement, de la supervision et de la maintenance des modèles laisse le poste le plus durable hors du champ. C’est précisément celui qui se découvre trois mois après la mise en ligne. Nous abordons cette même logique dans notre article sur la transformation IA en entreprise.

Comment chiffrer avant de s’engager

La méthode que nous appliquons tient en quatre questions, et elle se répond en atelier plutôt qu’en devis. Quelle décision ou quelle tâche le système remplace-t-il, et combien de temps humain cela représente-t-il aujourd’hui ? Quelles données faut-il, où sont-elles, et dans quel état ? À quoi ressemble une bonne réponse, formulée assez précisément pour être annotée sur cinquante exemples ? Et que se passe-t-il quand le système se trompe, qui le voit et qui corrige ?

Une fois ces quatre réponses écrites, le chiffrage devient mécanique, et surtout comparable entre prestataires. Sans elles, tout devis est une estimation au doigt mouillé, y compris le nôtre. C’est d’ailleurs la même logique que celle qui prévaut pour le coût de développement d’un SaaS : ce n’est pas la technologie qui fait le prix, c’est la précision du périmètre.

Un dernier repère, contre-intuitif mais constant : les projets d’IA les moins chers sont ceux qui commencent par le cas d’usage le plus étroit. Un assistant qui répond bien à une seule famille de questions se livre en quelques semaines, produit un résultat mesurable, et sert de base à l’extension suivante. Un assistant qui doit tout savoir dès le premier jour ne se livre jamais.

Ce que nous en retenons

Le coût d’un projet IA se pilote par le cadrage, pas par le choix du modèle. Le prix au jeton est réel mais marginal, la mise en production concentre l’essentiel de la dépense, et l’évaluation est le seul investissement qui rend les suivants vérifiables. Quant au serveur dédié, il se justifie par la confidentialité bien plus souvent que par l’économie.

Si vous avez un projet d’assistant, d’agent ou d’automatisation intelligente et que vous cherchez à le chiffrer sérieusement, c’est exactement l’objet de notre cadrage IA. Nous en sortons un périmètre écrit, un jeu d’évaluation et une estimation défendable. Parlons-en.