Combien coûte un agent IA ?

On me pose la question à presque chaque premier échange : combien coûte un agent IA ? La réponse honnête n'est pas un chiffre, et je me méfie de quiconque en sort un avant d'avoir vu le cas. Voici ce qui fait vraiment le prix, pour que vous puissiez lire un devis au lieu de le subir.

Pourquoi il n'y a pas de prix catalogue

Un agent à 19 euros par mois existe : c'est un logiciel déjà construit, partagé entre des milliers de clients, que vous configurez à la marge. Utile, parfois suffisant. Un agent sur mesure, c'est autre chose : il parle à vos outils, suit vos règles, agit dans vos systèmes. Personne ne l'a construit avant vous, donc personne ne peut vous le vendre au prix d'un abonnement. Le prix catalogue n'existe pas parce que le produit, lui, n'existe pas encore. Quand un devis sur mesure ressemble à un tarif d'abonnement, ce n'est pas une bonne affaire : c'est souvent que le périmètre est flou, ou que la maintenance a disparu du calcul.

Les deux budgets à ne pas confondre : le build et le run

• Le build, une fois : cadrage, connexion à vos outils, règles métier, tests, mise en production. Une dépense ponctuelle, et plus l'agent touche à de vrais systèmes, plus elle pèse.
• Le run, chaque mois : les tokens consommés, l'hébergement, la surveillance, les correctifs. C'est le budget qu'on oublie de chiffrer, et c'est lui qui décide si l'agent reste rentable dans la durée.

Ce qui fait vraiment monter la facture

• Le nombre d'outils branchés. Un agent qui lit une base, c'est simple. Un agent qui orchestre plusieurs outils et plusieurs étapes, c'est un autre métier, et un autre budget.
• La profondeur des intégrations. Lire une donnée est facile. Écrire dans un système de production (créer une commande, modifier une fiche client) demande des garde-fous, donc du temps.
• Le niveau de fiabilité exigé. Un agent qui se trompe une fois sur dix se construit vite. Un agent à qui vous confiez des clients ou de l'argent doit être testé, encadré, supervisé. C'est là que part l'essentiel du budget.

Le coût des tokens : pourquoi il est imprévisible

Chaque fois que l'agent réfléchit ou répond, il consomme des tokens, l'unité que facture le modèle. Le problème : cette consommation dépend de l'usage réel, pas d'un forfait. Un agent qui traite dix demandes par jour et le même agent qui en traite dix mille n'ont pas la même facture. C'est pour ça qu'un prix de run annoncé à la louche, sans hypothèse de volume, ne veut rien dire. La bonne nouvelle : ça se borne, à condition de le décider dès la conception. Choisir le bon modèle pour chaque étape (un petit pour le tri, un gros seulement quand il le faut), mettre en cache ce qui se répète, plafonner les volumes. Sur une facture déjà en production, un audit dégage souvent 30 à 70% d'économies sur une facture LLM auditée, à qualité égale. Demandez à votre prestataire comment il compte réduire la facture LLM plutôt que de la subir.

La maintenance, le poste que tout le monde oublie

Un agent n'est pas un meuble, c'est un logiciel vivant, branché sur des modèles et des outils qui bougent sans vous prévenir. Un modèle est déprécié, une API change, un cas non prévu arrive : sans entretien, l'agent se dégrade en silence. La maintenance n'est pas une option qu'on ajoute si ça casse, c'est une ligne de budget dès le premier jour. Un agent livré puis abandonné coûte deux fois : une fois pour le construire, une fois pour réparer les dégâts.

Un agent sans budget de maintenance n'est pas moins cher. Il est juste plus cher, plus tard.

Des fourchettes réalistes, en logique plutôt qu'en chiffres

Je ne vous donnerai pas de prix au hasard : ce serait malhonnête sans voir votre cas. La logique, elle, est claire. Partez du type d'agent le plus simple comme unité de base, et regardez ce que chaque capacité vient ajouter.

• Agent en lecture seule, qui répond à partir de vos documents sans rien modifier : le plancher. C'est le terrain d'une réponse sourcée en 2 secondes, avec 70% de recherche en moins pour vos équipes.
• Agent qui agit dans un système, crée un ticket ou met à jour une fiche : au-dessus, parce qu'il faut gérer les erreurs et les cas limites.
• Agent multi-outils à haute fiabilité, un support 24h/24 qui manipule des actions sensibles : souvent un ordre de grandeur au-dessus du premier en build, avec un run mensuel qui ne s'arrête jamais. C'est le prix d'un support 24h/24 qui escalade 50% de tickets en moins.
• La règle : chaque capacité ajoutée (écrire, brancher un outil de plus, exiger plus de fiabilité) fait monter le build et le run en même temps. Le prix ne suit pas le discours de l'agent, il suit ce qu'il a le droit de faire.

Les 5 questions à poser avant de signer

• Ce budget, c'est le build ou le run ? Si les deux ne sont pas séparés, le devis est incomplet.
• Qui paie les tokens, et sur quelle hypothèse de volume ? Que se passe-t-il en cas de dépassement ?
• Que devient l'agent quand le modèle change ou est déprécié ? La maintenance est-elle incluse, ou facturée à part ?
• Quelles actions passent par une validation humaine avant de partir ? (Envoyer, payer, supprimer, écrire à un client.)
• Est-ce du sur mesure que je possède, ou un SaaS repackagé ? Si on se quitte, qu'est-ce qui me reste ? Un agent bâti sur un standard ouvert comme MCP (adopté par Anthropic, OpenAI, Google et Microsoft, confié à la Linux Foundation fin 2025) ne vous enferme pas chez un prestataire.

Quand un agent ne vaut pas son coût

Le meilleur conseil que je peux donner sur le prix d'un agent, c'est parfois de ne pas en construire. Si votre besoin se résume à « quand X arrive, faire Y », sans jugement à porter ni langage à interpréter, un agent est trop cher et trop fragile pour la tâche. Un simple workflow d'automatisation fait le travail, coûte bien moins et tombe moins souvent en panne. Gardez l'agent pour ce qui demande vraiment de comprendre, de décider, de rédiger. Payer un agent pour ce qu'une règle « si ceci, alors cela » fait très bien, c'est jeter de l'argent.

Si vous avez un devis d'agent sous les yeux et que vous ne savez pas ce que vous payez, c'est exactement là que j'interviens : cadrer le périmètre, séparer le build du run, et chiffrer le coût réel avant de construire. Un premier échange suffit souvent à y voir clair, sans engagement : parlons-en.