26 October 2026 · 8 min de lecture

Le playbook, au niveau d’exigence d’un CFO, pour éviter le choc de COGS des agents

Renégociez les contrats, repensez les workflows et mesurez l’usage des agents avant que les « AI add-ons » ne deviennent une fuite de marge sans plafond.

Sketchnote-style path showing a leader moving from surprise AI agent bills to caps, a usage ledger, and controlled scaling.

Le coût d’IA le plus dangereux est celui qui paraît marginal à l’achat et devient non linéaire une fois en production.

Vous ajoutez « quelques seats d’agents » ou « quelques crédits ». Les équipes s’enthousiasment. Les automatisations se propagent. Un trimestre plus tard, la facture tombe et personne ne sait expliquer quels workflows l’ont générée, quels clients en ont profité, ni si cela a remplacé un coût réel. C’est arrivé, c’est tout.

C’est le choc de COGS des agents : non pas parce que l’IA coûte forcément cher, mais parce que nous importons un nouveau compteur dans de vieux réflexes d’achats. Les éditeurs l’ont bien compris. Beaucoup de produits SaaS « pré-IA » augmentent désormais leurs prix pour l’accès aux agents, avec des compteurs hétérogènes — crédits, tarification par « resolution », ou metering sur agents sur mesure — comme l’explique la note de SaaStr sur la hausse des prix de l’accès aux agents.

Si vous traitez cela comme un simple sujet d’achat, vous perdrez. La réponse, c’est de repenser ensemble les contrats, les workflows et l’instrumentation. Vous devez pouvoir dire, sans détour : « on peut doubler l’usage sans doubler le coût » ou « si le coût double, la marge brute ne bouge pas ».

Ce qui rend la dépense agentique différente (et pourquoi les budgets se font surprendre)

Le SaaS traditionnel a des angles morts connus : shelfware, trop de seats, outils redondants. On corrige souvent avec un nettoyage de licences et des validations plus strictes.

Le SaaS agentique fait sauter ces garde-fous parce que l’unité de consommation n’est plus une personne. C’est une activité. Et l’activité peut exploser en silence.

  • Une seule personne peut déclencher des milliers d’appels. Un changement de workflow peut se démultiplier en tâches en arrière-plan, retries et longues fenêtres de contexte.
  • Les coûts naissent loin de l’acheteur. La personne qui signe le renouvellement n’est pas celle qui prompte l’agent dans une macro de ticketing à 2 heures du matin.
  • La valeur est difficile à attribuer. « Un meilleur support » n’est pas une métrique. « Moins d’escalades pour 1 000 tickets », si.
  • Les éditeurs ont tout intérêt à facturer là où vous ne pouvez pas auditer. Crédits, « resolutions », « agent actions », « enrichments », « copilot runs ». Si vous ne pouvez pas rapprocher ces métriques de vos propres logs, vous achetez une boîte noire.

Conséquence opérationnelle : vous ne piloterez pas la dépense agentique avec un budget annuel et un calendrier de renewals. Il faut la gérer comme une ligne de coût variable : mesurée, prévue, plafonnée et revue régulièrement.

Les leviers contractuels : renégocier avant que le renewal ne devienne une prise d’otage

Les équipes achats négocient souvent un prix par unité. Avec la tarification des agents, la bataille porte d’abord sur l’unité elle-même. Commencez par là.

1) Exiger une nomenclature claire de l’« usage agent »

Demandez un mapping écrit de chaque événement facturable. Pas du langage marketing. Une liste.

  • Qu’est-ce qui compte comme une « resolution » ou une « agent action » ?
  • Qu’est-ce qui déclenche un événement : clic UI, appel API, webhook, background job ?
  • Les retries sont-ils facturés ?
  • Les exécutions en échec sont-elles facturées ?
  • La longueur du contexte change-t-elle le prix ?

S’ils ne peuvent pas l’expliquer sans ambiguïté, vous ne pourrez pas gouverner. Ce n’est pas un « détail technique ». C’est le produit que vous achetez.

2) Négocier des plafonds et des amortisseurs de choc, pas seulement des remises

Les remises rassurent et ne règlent rien. Vous avez besoin de protections structurelles.

  • Des plafonds mensuels stricts avec dégradation progressive. Au plafond, l’agent passe en mode moins cher, met en file d’attente ou exige une confirmation humaine.
  • Des throttles basés sur le budget, configurables par vous. Pas via un ticket support.
  • Une tarification par paliers où le coût marginal baisse après un seuil. Si l’usage croît avec votre succès, vos unit economics doivent s’améliorer — pas se dégrader.
  • Pas de facturation des échecs (timeouts, erreurs de modèle, indisponibilités côté éditeur).

Si l’éditeur refuse les plafonds, c’est un signal. Soit il ne maîtrise pas ses propres COGS, soit il parie que vous ne verrez rien avant qu’il soit trop tard.

3) Exiger l’auditabilité et une télémétrie exportable

« Faites confiance à notre dashboard » n’est pas de la gouvernance. Rendez contractuels les éléments suivants :

  • Export d’usage via API (granularité quotidienne a minima).
  • Logs au niveau événement, avec des IDs de corrélation que vous pouvez relier à vos systèmes.
  • Définitions claires, non modifiables unilatéralement en cours de période.

J’ai vu un cutover ERP consommer un an parce que les définitions de reporting n’avaient jamais été stabilisées. Le metering des agents relève du même risque — en plus rapide.

4) Obtenir une période de « meter freeze » pendant les migrations

Si un éditeur change de modèle de prix (crédits vers per-resolution, ou ajout de metering sur des agents custom), il vous faut du temps pour recâbler les workflows. Demandez une période de transition où vous pouvez mesurer en double mode sans payer deux fois. L’objectif n’est pas la générosité : c’est d’éviter le chaos en production.

Le redesign des workflows : arrêter de laisser les agents tourner « en roue libre » dans l’entreprise

La plupart des dérapages de coûts ne viennent pas d’un cas d’usage massif. Ils viennent de dizaines de petites automatisations que personne ne « possède ». La correction relève du design, pas de la police.

1) Classer le travail des agents en trois couloirs

  • Couloir A : assistance déterministe. Résumés, rédaction, mise en forme, recherche. Cela doit rester bon marché et borné.
  • Couloir B : aide à la décision. Recommandations, triage, priorisation. Il faut de la traçabilité et des revues par échantillonnage.
  • Couloir C : action autonome. Envoi d’e-mails, modification d’enregistrements, remboursements, push de code. Il faut des gates explicites.

Beaucoup d’équipes passent par accident du couloir A au couloir C parce que « ça marche en démo ». N’attendez pas une surprise tarifaire pour découvrir qu’un bot peut créer 500 mises à jour CRM en une nuit.

2) Remplacer le « toujours actif » par des triggers et des points de contrôle

  • Déclenchez sur des changements d’état pertinents, pas à chaque frappe.
  • Ajoutez une étape de confirmation avant les exécutions coûteuses (contexte long, tool use, plans multi-étapes).
  • Mettez en cache et réutilisez les résultats (résumés, enrichment) avec des TTL.
  • Regroupez les tâches non urgentes dans des fenêtres planifiées.

C’est là que vous protégez la marge brute. Pas dans un call de négociation.

3) Construire le kill switch avant d’en avoir besoin

Vous devez disposer d’un mécanisme simple pour arrêter l’activité des agents par workspace, par workflow, ou par segment client. Non pas parce que vous attendez une catastrophe tous les jours, mais parce que vous voulez l’autorisation de scaler. Si vous ne pouvez pas arrêter la dépense en quelques minutes, vous hésiterez à déployer le prochain cas d’usage.

Si c’est déjà un sujet actif chez vous, voyez AI sprawl as an ownership problem. Le schéma est identique : personne n’est accountable de la facture complète et de l’ensemble de la surface de risque.

Le système de metering : gérer les agents comme une ligne de produits à coût variable

Le changement est là : vous n’« achetez » pas de l’IA. Vous opérez une consommation d’IA.

1) Créer un ledger d’usage que vous possédez

Ne vous contentez pas des totaux éditeur. Construisez un ledger interne qui enregistre, a minima :

  • Nom du workflow
  • Système à l’origine de l’appel (CRM, support, IDE, outil interne)
  • Tag client ou segment (quand c’est pertinent)
  • Unités de coût estimées (crédits, appels, « resolutions » mappées vers votre unité interne)
  • Tag de résultat (temps gagné, escalation évitée, assistance à la conversion, non résolu)

Quand la finance demande « qu’est-ce qui a tiré ce mois-ci », vous répondez en trois lignes, pas en trois semaines.

2) Définir deux limites : technique et financière

  • Limite technique : rate limits, limites de concurrence, limites de tool use.
  • Limite financière : budget mensuel par owner de workflow, avec alertes à 50 %, 80 %, 95 %.

Rendez le budget visible pour ceux qui peuvent modifier le workflow. Si seule la finance le voit, rien ne change.

3) Tarifer l’usage en interne, même si personne ne paie en cash

Le chargeback est optionnel. La logique d’unit economics ne l’est pas.

  • Attribuez un « cost per run » interne à chaque workflow d’agent.
  • Exigez une justification simple pour tout workflow sans résultat mesurable.

C’est la même discipline que pour la dépense cloud, sauf qu’ici la demande peut naître d’un simple ajustement de template de prompt.

Le rythme trimestriel : une boucle de gouvernance simple pour préserver la marge

Ne montez pas un comité. Installez une cadence.

  1. Inventaire (semaine 1) : lister les workflows « agent-enabled » par système et par owner. Supprimer ceux qui sont morts.
  2. Mapping du meter (semaine 2) : rapprocher les charges éditeur des catégories du ledger interne. Identifier l’usage « inconnu » et le couper tant qu’il n’est pas expliqué.
  3. Top 5 des drivers de coût (semaine 3) : repenser les pires contributeurs. Ajouter des gates, du caching, du batching, ou downgrader les modèles.
  4. Posture contractuelle (semaine 4) : décider quels éditeurs renégocier, lesquels mettre en exploration de remplacement, et lesquels soumettre à des throttles plus stricts.

Si vous cherchez un pattern de déploiement plus large qui fait composer l’IA plutôt que la laisser dériver, build on the stack you have. L’enjeu est de concentrer l’usage dans des workflows que vous pouvez observer et améliorer.

Mon point de vue : les caps ne sont pas du pessimisme, ce sont l’autorisation de scaler

La tarification des agents n’est pas une mode passagère. Les éditeurs alignent leurs revenus sur leurs propres coûts variables, et sur la valeur qu’ils pensent que vous captez. Le risque, c’est de l’adopter avec des habitudes d’achats conçues pour des licences par seat.

Les entreprises qui gagneront traiteront la dépense agentique comme n’importe quel cost of goods : conçue, mesurée et bornée. Renégociez l’unité. Repensez le workflow. Possédez le ledger. Installez un kill switch. Puis scalez avec confiance.

Sinon, dans un an, vous vous réveillerez avec d’excellentes démos, des factures plus élevées, et une histoire de marge brute que vous ne pourrez pas défendre.

Newsletter

Des notes de terrain, directement dans votre boîte.

Des notes occasionnelles et sans bruit, prises de l'intérieur du travail : ce qui a été livré, ce qui a cassé, et ce que je ferais différemment.