Suivre et maîtriser le coût des appels IA dans vos workflows n8n

Un workflow n8n qui trie des emails ou répond à des questions via un LLM n’affiche jamais de compteur de coût en temps réel. Tant que le volume reste faible, personne ne regarde. Puis la facture OpenAI ou Anthropic du mois arrive, et il devient impossible de savoir quel workflow, quel node ou quel modèle a consommé quoi — sans même parler d’anticiper une dérive avant qu’elle ne coûte cher. Le problème n’est pas seulement organisationnel : n8n rend le suivi des tokens plus difficile qu’il n’y paraît, pour une raison technique précise.

Le piège du node AI Agent

Le node AI Agent (@n8n/n8n-nodes-langchain.agent), utilisé dans la plupart des workflows IA — y compris ceux du Pack Inbox IA et du Pack Assistant RAG — calcule bien un objet tokenUsage à chaque appel du modèle. Ce détail est visible dans le panneau d’exécution du sous-node Chat Model (lmChatOpenAi, lmChatAnthropic) lui-même. Le problème : cette donnée n’est jamais propagée jusqu’à la sortie du node Agent parent. Seuls les tokens consommés par d’éventuels appels d’outils remontent dans intermediateSteps — pas ceux de l’appel principal au modèle, qui représente pourtant l’essentiel du coût. C’est une limitation documentée et régulièrement remontée par la communauté n8n, non résolue à ce jour : impossible de brancher un node suivant sur {{ $json.tokenUsage }} en sortie d’un Agent et d’obtenir quoi que ce soit d’exploitable.

Concrètement, cela signifie qu’un monitoring de coût « propre » ne peut pas se contenter d’ajouter un node après l’AI Agent : il faut changer d’approche selon ce que fait réellement le workflow.

Deux façons de récupérer l’usage réel

Pour les workflows qui n’ont pas besoin du function calling multi-outils — une classification d’email comme dans le workflow de tri du Pack Inbox IA, un résumé, une extraction de champs — remplacez le node AI Agent par un node LLM Chain (chainLlm, souvent combiné à un Structured Output Parser pour forcer une sortie JSON). Ce node expose l’objet tokenUsage directement dans sa sortie, sans détour.

Pour les workflows qui ont réellement besoin de l’AI Agent — un chatbot RAG comme celui du Pack Assistant RAG qui doit interroger un outil de recherche vectorielle avant de répondre — la solution consiste à appeler l’API du fournisseur directement via un node HTTP Request plutôt que par le node Chat Model natif, au moins sur le chemin où le coût compte. La réponse brute de l’API OpenAI (/v1/chat/completions) contient un champ usage avec prompt_tokens et completion_tokens ; l’API Anthropic (/v1/messages) renvoie de son côté usage.input_tokens et usage.output_tokens. C’est plus de configuration qu’un node préconstruit, mais c’est le seul moyen d’obtenir un chiffre fiable sans attendre que n8n corrige ce comportement.

Construire un journal de coûts dans Supabase

Une fois l’usage récupéré, direction une table de journalisation — la même logique que celle décrite dans notre guide sur la piste d’audit RGPD, appliquée cette fois au coût plutôt qu’à la conformité :

create table ai_usage_log (
  id uuid primary key default gen_random_uuid(),
  created_at timestamptz default now(),
  workflow_name text not null,
  node_name text,
  model text not null,
  input_tokens integer not null,
  output_tokens integer not null,
  estimated_cost_usd numeric(10,6) not null
);

Un Code node, placé juste après la récupération de l’usage, calcule le coût à partir d’une table de prix par modèle maintenue à la main (les tarifs des fournisseurs évoluent régulièrement, ce Code node est le seul endroit à mettre à jour) :

const pricing = {
  "gpt-4o-mini": { input: 0.15, output: 0.60 },
  "gpt-4o": { input: 2.50, output: 10.00 },
  "claude-haiku": { input: 0.80, output: 4.00 },
};

const { model, prompt_tokens, completion_tokens } = $input.item.json;
const rate = pricing[model];
const cost =
  (prompt_tokens / 1_000_000) * rate.input +
  (completion_tokens / 1_000_000) * rate.output;

return { json: { model, input_tokens: prompt_tokens, output_tokens: completion_tokens, estimated_cost_usd: cost } };

(Prix indicatifs par million de tokens, à titre d’exemple — vérifiez toujours la grille tarifaire en vigueur sur la console de votre fournisseur avant de vous y fier pour un budget réel.)

Un node Supabase en insertion, exécuté en parallèle de la suite du workflow plutôt qu’en bloquant le chemin critique, écrit la ligne dans ai_usage_log. En quelques jours, une simple requête SQL groupée par workflow_name ou par model répond à la question que la facture mensuelle du fournisseur ne détaille jamais : quel workflow précis coûte quoi.

Alerter avant la dérive, pas après la facture

Journaliser ne suffit pas si personne ne regarde la table avant la fin du mois. Un second workflow, déclenché par un Cron quotidien, additionne les coûts de la journée ou du mois glissant et compare le total à un seuil défini. Au-delà, il envoie une alerte Slack — le même mécanisme que celui détaillé dans notre guide sur la gestion des erreurs et alertes n8n, appliqué ici à un seuil budgétaire plutôt qu’à un échec technique :

SELECT model, SUM(estimated_cost_usd) as total
FROM ai_usage_log
WHERE created_at > now() - interval '1 day'
GROUP BY model;

Ce garde-fou change concrètement la dynamique : au lieu de découvrir en fin de mois qu’un digest quotidien mal calibré a envoyé dix fois plus d’appels que prévu, l’alerte tombe le jour même, avec le modèle et le workflow responsables déjà identifiés.

Le choix du modèle reste le premier levier

Le suivi ne remplace pas l’optimisation en amont. Les workflows du Pack Inbox IA sont réglés par défaut sur gpt-4o-mini, précisément parce qu’une tâche de classification ou de scoring d’urgence n’a pas besoin de la puissance — ni du tarif — d’un modèle plus large : pour une boîte de 100 emails par jour, la facture reste de l’ordre de quelques centimes à 1-2 € par mois. À l’inverse, un chatbot RAG comme celui du Pack Assistant RAG, où la qualité de réponse compte directement pour l’utilisateur final, justifie plus souvent un modèle intermédiaire — c’est un arbitrage à faire consciemment, modèle par modèle, plutôt qu’à garder le réglage par défaut partout. Notre guide pour connecter Claude ou GPT à n8n détaille comment basculer un workflow d’un fournisseur ou d’un modèle à l’autre sans réécrire la logique métier — un changement que le journal de coûts permet justement de valider objectivement, avant/après, plutôt qu’à l’impression.

Pièges fréquents

• Se fier à l’estimation de tokens du node Chat Model sans vérifier l’usage réel : certains sous-nodes affichent une estimation approximative plutôt que le compte exact renvoyé par l’API ; en cas de doute, l’appel direct via HTTP Request reste la source la plus fiable.
• Journaliser sans jamais interroger la table : un ai_usage_log qui grossit sans dashboard ni alerte a le même défaut qu’un log d’erreurs jamais relu — la donnée existe, mais personne n’agit dessus à temps.
• Oublier le coût des embeddings : dans un pipeline RAG comme celui du Pack Assistant RAG, l’ingestion de documents volumineux génère elle aussi des appels facturés (embeddings), distincts des appels de génération de réponse — à journaliser séparément si le volume d’ingestion est important.
• Ne pas mettre à jour la table de prix : les tarifs des fournisseurs IA changent plus souvent qu’on ne l’imagine ; un coût estimé sur d’anciens tarifs fausse silencieusement toutes les alertes en aval.

Pour aller plus loin

Suivre le coût réel de vos appels IA devient particulièrement utile dès que plusieurs workflows tournent en parallèle sur des modèles différents — exactement la situation du Bundle FlowKit Complet, qui réunit tri d’emails, assistant RAG et rapports de conformité générés par IA. Un seul journal ai_usage_log, alimenté par les trois packs, suffit à répondre en une requête SQL à la question que la facture mensuelle du fournisseur ne détaille jamais.