Projet IA sur mesure : comment construire un budget réaliste avant de demander des devis

Les fournisseurs d’IA facturent généralement l’usage de leurs modèles selon les volumes traités et les fonctionnalités mobilisées. Ces tarifs sont publics et évolutifs. Ils permettent d’estimer la consommation, mais pas le coût du système complet.

Une application IA peut également nécessiter :

• une interface pour les utilisateurs ;

• des connexions au CRM, à l’ERP, à la messagerie ou aux bases documentaires ;

• une gestion des identités et des droits ;

• un environnement d’hébergement ;

• des journaux, alertes et tableaux de suivi ;

• un jeu de tests représentatif ;

• des validations humaines ;

• une maintenance lorsque les données, les modèles ou les processus changent.

AWS distingue explicitement le prototype de la préproduction : une application destinée à fonctionner dans l’entreprise doit ajouter versioning, tests, sécurité, observabilité et contrôle des régressions. C’est souvent cette transformation, invisible dans une démonstration, qui explique l’écart entre le coût d’un POC et celui d’un système en production.

Ce tableau sert à rendre les offres comparables. Il ne remplace pas un cahier des charges exhaustif : il force surtout l’entreprise et le prestataire à expliciter ce qui est acheté.

Un budget devient exploitable lorsque le périmètre tient en une phrase vérifiable.

Formulation trop vague :

Mettre de l’IA dans le service client.

Formulation exploitable :

Préparer une proposition de réponse pour les demandes de niveau 1 reçues par email, à partir de la base d’aide validée, puis soumettre chaque réponse à un conseiller avant envoi.

La seconde formulation précise l’entrée, la source de connaissance, l’action et le contrôle humain. Elle permet de compter les volumes, d’identifier les intégrations et de construire un jeu de tests.

Avant toute consultation, consignez :

1. le processus actuel ;

1. les utilisateurs concernés ;

1. le volume mensuel ;

1. le résultat attendu ;

1. les erreurs inacceptables ;

1. les données nécessaires ;

1. les outils à connecter ;

1. le responsable métier de la décision.

Si ces éléments restent inconnus, la première ligne budgétaire doit financer le cadrage, pas la construction.

Tous les projets ne nécessitent pas un agent autonome. Google Cloud recommande d’évaluer la complexité de la tâche, la latence, le budget et le besoin de validation humaine avant de choisir une architecture agentique. Pour un travail prévisible ou très structuré, une solution non agentique peut être plus économique.

Une grille simple aide à éviter le suréquipement :

La position d’Atalas est qu’une architecture impressionnante n’est pas une valeur en soi. Le bon système est le plus simple qui atteint le résultat attendu avec un niveau de contrôle acceptable.

Un devis unique intitulé « développement de la solution » masque souvent trois décisions différentes.

Prototype

Le prototype vérifie que l’approche peut fonctionner sur des cas représentatifs. Il peut accepter des manipulations manuelles et une interface rudimentaire. Son budget doit préciser :

• le nombre de cas testés ;

• les données utilisées ;

• la mesure de qualité ;

• la décision attendue à la fin.

Préproduction

La préproduction transforme une démonstration en système testable dans les conditions réelles. Elle ajoute notamment la sécurité, les droits, les journaux, les tests de régression et l’intégration à un environnement stable.

Exploitation

L’exploitation couvre le fonctionnement après le lancement : consommation, hébergement, surveillance, incidents, mises à jour et évolution du périmètre. Elle doit être chiffrée séparément, avec un responsable et une fréquence de revue.

Le dirigeant peut ainsi arrêter le projet après le prototype si la valeur n’est pas démontrée, sans avoir implicitement engagé tout le budget de production.

Utilisez cette formule :

Coût complet sur douze mois = cadrage + construction + données + intégrations + mise en production + consommation + hébergement + maintenance + temps interne.

Ajoutez ensuite une réserve identifiée pour les inconnues, sans la confondre avec une enveloppe libre. Chaque incertitude doit être nommée : qualité des données, limites d’une API, nombre d’exceptions, sécurité ou volume réel.

Pour la consommation des modèles, le calcul doit partir de mesures :

Coût mensuel estimé = nombre d’exécutions × consommation moyenne par exécution × tarif du modèle, auxquels s’ajoutent les outils et l’infrastructure.

Les pages tarifaires d’OpenAI et d’Anthropic, consultées le 4 novembre 2026, confirment que les prix varient selon les modèles, les entrées, les sorties et certaines fonctionnalités. Le devis doit donc conserver le modèle retenu, la date du tarif et l’hypothèse de volume. Une estimation sans ces trois éléments n’est pas vérifiable.

AWS recommande également de modéliser les volumes, les tokens moyens, le coût du modèle, l’infrastructure, le stockage et les garde-fous. Ce modèle doit vivre pendant les tests : la consommation mesurée remplace progressivement l’hypothèse.

Avant de choisir, exigez une réponse écrite aux douze questions suivantes :

1. Quel résultat métier précis est inclus ?

1. Quelles situations sont explicitement exclues ?

1. Quelles données devons-nous préparer ?

1. Quelles intégrations sont incluses ?

1. Quelle architecture est proposée et pourquoi est-elle proportionnée ?

1. Comment la qualité sera-t-elle testée ?

1. Quelles validations humaines restent nécessaires ?

1. Que contient exactement la mise en production ?

1. Qui possède le code, les configurations et la documentation ?

1. Quels coûts tiers et coûts d’usage resteront à notre charge ?

1. Qui assure la maintenance et les incidents ?

1. À quelle étape pouvons-nous arrêter, étendre ou réviser le projet ?

Deux montants ne sont comparables que si ces réponses couvrent le même périmètre. Le devis le moins cher peut simplement déplacer vers le client les données, les tests, l’intégration ou l’exploitation.

Une PME veut préparer ses devis à partir des emails clients, de son catalogue et de règles tarifaires internes.

Un chiffrage incomplet peut couvrir uniquement une démonstration qui lit quelques emails et génère un document. Le budget complet doit aussi examiner :

• la qualité et l’actualisation du catalogue ;

• les exceptions commerciales ;

• la connexion au CRM ;

• les droits d’accès aux tarifs ;

• la validation par un commercial ;

• la traçabilité des modifications ;

• la gestion d’un modèle ou d’un fournisseur indisponible ;

• l’exploitation après la livraison.

Cet exemple est fictif. Il montre pourquoi le même intitulé de projet peut désigner un prototype rapide ou une application métier durable.

Sous-estimer la production : le prototype fonctionne, mais aucune enveloppe ne couvre l’authentification, les tests, la surveillance ou la reprise après erreur.

Surconcevoir : l’entreprise finance un agent complexe alors qu’un workflow déterministe avec une étape IA aurait suffi.

Oublier l’usage : la solution est livrée sans responsable métier, formation ni règle d’adoption.

Créer une dépendance : le code, les prompts, les évaluations ou la documentation ne sont pas transférables.

Confondre forfait et certitude : un prix fixe construit sur des données inconnues reporte souvent les exclusions dans les petites lignes.

Avant de demander trois devis, produisez une fiche de cadrage de deux pages avec le résultat métier, dix cas représentatifs, les données, les intégrations, les critères d’acceptation et le volume prévu. Demandez ensuite à chaque prestataire de chiffrer séparément le prototype, la préproduction et douze mois d’exploitation.

Le Studio IA d’Atalas accompagne précisément ce passage : cadrer le besoin métier, choisir une architecture proportionnée, construire un prototype vérifiable puis organiser la mise en production. L’objectif n’est pas de vendre le système le plus complexe, mais de donner à l’entreprise un périmètre, un budget et des responsabilités qu’elle peut réellement piloter.

Peut-on obtenir un prix ferme avant le cadrage ?

Un prix ferme est possible seulement sur un périmètre suffisamment défini. Si les données, les intégrations ou les critères de qualité sont inconnus, mieux vaut chiffrer d’abord une phase de cadrage bornée, puis décider de la construction.

Faut-il budgéter un POC séparément ?

Oui, lorsqu’il répond à une décision précise : poursuivre, modifier ou arrêter. Un POC sans cas représentatifs ni seuil d’acceptation produit une démonstration, pas une décision d’investissement.

Les tokens représentent-ils une part importante du budget ?

Cela dépend du volume, du modèle et de l’architecture. Pour certains projets, l’intégration et l’exploitation dominent largement. Pour d’autres, une consommation élevée ou plusieurs appels par dossier rendent le coût variable déterminant. Il faut mesurer sur les cas réels.

Comment éviter la dépendance au prestataire ?

Prévoyez contractuellement l’accès au code, aux configurations, aux évaluations, à la documentation et aux comptes techniques appropriés. Définissez aussi les conditions de maintenance, de transfert et de sortie.

Quel budget réserver à la maintenance ?

Il n’existe pas de pourcentage universel. Demandez un chiffrage fondé sur les responsabilités réelles : surveillance, incidents, mises à jour des intégrations, changements de modèles, évolution des données et fréquence des améliorations.

• Agents IA : le prix au token masque le vrai coût du travail

• Portefeuille IA : quels processus méritent le passage en production ?