Un prix universel pour une « application IA » n'est pas utile sans définition du logiciel. Une aide à la rédaction intégrée et un nouveau produit multi-utilisateur représentent des travaux différents, même avec le même modèle.
Un budget utile distingue réalisation, exploitation et incertitude.
Réalisation : chiffrer les livrables
Décomposer le projet : cadrage, design, frontend, backend, préparation des données, intégrations, comportement IA, évaluation, déploiement et transfert. Identifier ce qui existe et ce qui reste à créer.
Préciser ensuite chaque poste. Une intégration peut signifier une route API documentée ou plusieurs systèmes sans environnement de test complet. Le traitement documentaire peut viser un seul modèle de document ou plusieurs langues, mises en page et qualités de sources.
L'estimation conserve ces hypothèses. Sans elles, la comparaison de deux totaux renseigne peu sur les livrables.
Exploitation : séparer fixe et variable
Les appels aux modèles ne constituent qu'un poste. Inclure, selon le cas, hébergement, stockage, recherche, traitement documentaire, supervision, abonnements, support et revue humaine.
L'estimation d'usage suit le processus réel. Une action utilisateur peut déclencher plusieurs étapes ou relances. Un budget fondé uniquement sur une réponse de modèle réussie peut oublier ces situations.
Exemple de calcul, et non tarif inAi
Supposons un processus fictif de 2 000 dossiers mensuels. Retenons, uniquement pour l'exemple, 0,12 € de traitement variable par dossier, 180 € mensuels d'hébergement et d'outils, et une minute de revue par dossier à un coût interne supposé de 30 € par heure.
Le traitement représente 2 000 × 0,12 € = 240 €. La revue représente 2 000 ÷ 60 × 30 € = 1 000 €. Avec le fixe, le total est de 1 420 € par mois, hors maintenance, réalisation, taxes et postes non inclus.
Ces entrées sont hypothétiques : ni prix de marché, ni coûts mesurés chez inAi, ni devis. Le calcul illustre la structure : ici, la revue coûte davantage que le traitement. Une estimation réelle remplace chaque hypothèse par des éléments propres au projet.
Rendre l'incertitude visible
Lorsque les données ou les accès sont mal connus, un cadrage ou un pilote peut réduire l'incertitude avant un engagement plus large. Cette étape possède son propre livrable et ses critères de décision.
Ne pas ajouter une réserve inexpliquée à chaque poste en présentant le résultat comme précis. Expliquer quelles hypothèses peuvent modifier le budget et comment les vérifier.
Comparer un périmètre équivalent
Demander à chaque prestataire les exclusions, les frais tiers, la propriété, le transfert, les tests d'acceptation et les responsabilités après lancement. Vérifier si le prix suppose une infrastructure, une préparation des données ou du temps de revue fournis par le client.
La réalisation et le support ne doivent pas se chevaucher de façon ambiguë. Préciser les défauts couverts, les demandes considérées comme évolutions et leur facturation.
Faire du budget un outil de décision
La bonne première version n'est pas nécessairement le prototype le moins cher ou le produit le plus large. C'est le périmètre minimal qui répond à la question métier tout en laissant un chemin crédible vers l'exploitation.