Combien coûte un projet IA pour une entreprise ?

Ce n'est presque jamais le build qui surprend un DAF. La surprise arrive six mois plus tard, avec la facture du fournisseur de modèles, que personne n'avait budgétée.

Ou elle arrive plus tôt, quand deux devis pour le même projet sont posés sur votre bureau, l'un trois fois plus cher que l'autre, et que rien dedans n'explique pourquoi.

Un projet IA a cinq lignes de coût. Deux se paient une fois. Trois se paient tous les mois, tant que le système tourne.

Les cinq lignes de la facture

Cadrage. Quelqu'un doit décider ce qu'on construit, avec quelles données, et ce que « ça marche » veut dire. C'est la plus petite ligne de la facture, et celle qui fait bouger toutes les autres. Les projets qui s'en passent sont cadrés quand même, en plein build, au tarif du build.

Build. Le produit lui-même : l'agent ou l'assistant, les écrans autour, les connexions à votre CRM, votre ERP ou votre outil de support. Dans la plupart des projets, la partie IA pèse le moins. Ce sont les intégrations et l'interface qui prennent le temps.

Hébergement. Serveurs, bases de données, stockage, logs. Pour un outil interne classique, c'est une ligne mensuelle modeste. Elle grossit quand vos données doivent rester dans un pays donné ou chez vous.

Héberger votre propre modèle est rarement rentable à faible volume : les serveurs coûtent la même chose, qu'on leur pose une question ou aucune.

Coût par requête. Chaque appel à un modèle de langage se paie, selon le volume de texte envoyé et reçu. L'estimation tient en une multiplication : requêtes par mois × texte moyen par requête × prix du fournisseur par volume de texte, publié sur sa page tarifs (Anthropic, OpenAI). Ce qui fait grossir cette ligne, ce n'est pas le nombre d'utilisateurs, ce sont les longs documents envoyés à chaque requête.

Exemple : un assistant qui répond à 500 questions par jour, en envoyant chaque fois un document de 10 pages, fait environ 15 000 requêtes par mois. Multipliez par le texte de chaque requête et par le prix actuel du fournisseur, et vous avez la ligne mensuelle. Envoyez un résumé plutôt que le document entier, et la ligne baisse avec le volume de texte envoyé.

Maintenance. Votre fournisseur retire un modèle, votre CRM change son API, votre équipe change de process. Quelqu'un surveille le système, répare ce qui casse et améliore ce qui marche. Cela coûte moins cher quand l'équipe qui a construit le système le fait aussi tourner : personne n'a à réapprendre le code avant de le corriger.

Ce qui fait bouger la facture

Deux projets qui portent le même nom, « un agent IA pour le support client », peuvent varier du simple au triple, voire plus. L'écart ne vient presque jamais du modèle. Il vient de tout ce qu'il y a autour.

Les facteurs que nous voyons le plus souvent :

• L'état de vos données. Des données éparpillées entre des PDF, des boîtes mail et trois versions d'un tableur doivent d'abord être rassemblées et nettoyées, et ce travail se paie.
• Le nombre de systèmes à connecter. Un vieil ERP sans API, ou un éditeur qui fait payer l'accès, peut prendre plus de temps que l'IA elle-même.
• Le coût d'une mauvaise réponse. Un assistant qui rédige des mails internes peut se tromper de temps en temps. Celui qui donne des prix à vos clients ou lit des documents médicaux a besoin d'étapes de relecture, de tests et de contrôles humains. Chacun de ces points, c'est du temps de build.
• Le volume. Dix utilisateurs par jour et dix mille clients par jour n'appellent pas la même architecture, ni la même facture mensuelle.
• L'endroit où doivent vivre les données. L'API d'un cloud public est l'option la moins chère. L'hébergement en Europe, dans votre propre cloud ou sur site est possible, et coûte plus cher à mettre en place et à faire tourner.

Ce qui fait monter le budget, par type de projet

Le tableau couvre une première version en production, pas un prototype.

Nous ne publions pas de fourchettes que nous ne pouvons pas tenir pour votre cas. Les quatre réponses plus bas sont ce qu'il faut pour en obtenir une.

Sur les délais, nous pouvons être plus précis. Avec nous, une première version arrive en général en production en 3 à 6 semaines après le lancement, puis s'améliore par itérations.

Les coûts de fonctionnement que la plupart des devis oublient

Un devis de projet IA s'arrête souvent au lancement. Le produit, lui, continue.

L'usage du modèle au vrai volume. La démo tournait sur cinquante questions de test. Les vrais utilisateurs envoient des messages plus longs, joignent des fichiers et posent trois fois la même question. Estimez l'usage sur le volume attendu, puis suivez-le pendant les premières semaines.

L'évaluation. Il vous faut un moyen de savoir que le système répond toujours bien après une modification. Concrètement, un jeu de cas de test, relancé à chaque mise à jour.

Les changements de modèle. Les fournisseurs retirent des modèles et en sortent de nouveaux. Un changement peut améliorer la qualité, baisser le coût, ou casser sans bruit un prompt qui marchait. Quelqu'un doit tester et basculer.

La relecture humaine. Si une personne vérifie une partie des réponses, son temps fait partie du coût du système. Il a sa place dans le budget dès le premier jour.

L'itération suivante. Une fois la première version en route, vos équipes en voudront plus. Prévoyez la ligne de budget maintenant, pas quand la première demande arrive.

Une règle raisonnable : prévoyez un budget mensuel pour faire tourner et améliorer le produit, pas seulement pour l'héberger.

Cinq signes qu'un devis est incomplet

Envoyez cette liste à la personne qui lit le PDF du prestataire avec vous.

• Aucune ligne mensuelle après le lancement.
• L'usage du modèle chiffré sur la démo, pas sur votre volume.
• Pas de jeu de test, donc personne ne peut dire si une mise à jour a dégradé les résultats.
• Rien sur qui change de modèle quand le fournisseur en retire un.
• Un planning sans première version en production avant le sixième mois : rien ne vous dit quand vous verrez un résultat.

Comment budgéter avant le premier appel

Pas besoin d'un chiffre précis pour commencer. Il vous faut quatre réponses, et la plupart des entreprises les ont déjà.

1. La tâche. Quel travail le système prend en charge ou accélère, et combien d'heures il demande aujourd'hui.
2. Le volume. Combien de requêtes, de documents ou d'utilisateurs par jour, aujourd'hui et dans un an.
3. Les données. Où elles se trouvent, à qui elles appartiennent, et quelles règles s'y appliquent.
4. Le coût d'une erreur. Ce qui se passe quand le système se trompe, et qui s'en rend compte.

Avec ces quatre réponses, n'importe quel interlocuteur sérieux peut vous donner une fourchette pour le build et pour le fonctionnement. Sans elles, tout chiffre que vous recevez est une supposition, le nôtre compris.

Les heures gagnées vous donnent le plafond. Si une tâche prend deux jours par semaine à une personne, cela fait environ 90 jours travaillés par an : multipliez par ce que vous coûte une journée de cette personne, salaire et charges compris. Le build plus un an de fonctionnement doit passer sous ce chiffre, ou apporter quelque chose que ces jours n'apportent pas.

Certains projets ne passent pas ce test. Nous le disons pendant l'audit. Ne pas construire est aussi un résultat, et c'est le moins cher.

Commencez par les quatre réponses

L'audit gratuit, c'est une heure sur votre activité, puis un document court : ce qui vaut la peine d'être construit, et ce qui ne l'est pas. Réservez un audit gratuit et venez avec les quatre réponses ci-dessus. Si vous n'en avez que deux, venez quand même : c'est pendant l'appel qu'on trouve les deux autres.