Aller au contenu principal
Coucou IA

coulisses10 septembre 20267 min de lecture

IA facturée à l’usage : le jour où mon compteur a failli débiter deux fois

Chez Livia, le produit que je construis, un lot de crédits a failli se compter deux fois. La clé censée l’en empêcher était posée au mauvais endroit, et personne ne l’avait remarqué.

À retenir

  • Une IA facturée à l’usage décompte un quota mensuel de crédits à partir d’un journal de consommation écrit par le prestataire lui-même.
  • Une clé d’idempotence est l’identifiant attaché à un lot d’écritures dès son ouverture, qui permet à un système de reconnaître ce lot s’il repart et de l’ignorer plutôt que de l’enregistrer une seconde fois.
  • Chez Livia, le produit que je construis, un défaut générait la clé d’idempotence à la fermeture du lot au lieu de son ouverture : un même lot repartait avec une clé différente à chaque tentative et pouvait doubler un débit. Ce défaut a été trouvé et corrigé avant qu’aucun client ne soit facturé deux fois.
  • Écrire chaque lot dans un fichier temporaire puis le renommer de façon atomique à son emplacement définitif fige la clé d’idempotence dès l’ouverture du lot, si bien qu’un lot reparti retombe sur la même clé et se fait ignorer.

Le lot qui pouvait repartir deux fois

En relisant le code qui écrit la consommation de Livia, le produit que je construis, je suis tombé sur une ligne au mauvais endroit. La clé censée empêcher un même travail d’être compté deux fois se fabriquait à la fin du lot d’écritures, une fois le travail terminé.

Un lot reparti obtenait donc une clé neuve, comme s’il s’agissait d’un travail nouveau. Un incident réel produit ce scénario sans prévenir : une reprise après une panne serveur, un envoi qui échoue et qu’on relance. Sur l’offre où le quota tourne autour de 1 100 crédits par mois, un lot reparti et mal reconnu double un débit qui n’a eu lieu qu’une fois.

Aucun client n’a été facturé deux fois. J’ai corrigé le défaut avant qu’il touche une seule organisation.

Ce que compte vraiment un compteur d’usage

Facturer une IA à l’usage veut dire compter ce qu’elle fait. Chaque organisation cliente reçoit un quota de crédits pour le mois. Chaque action de l’agent, une lecture, une comparaison, une rédaction, coûte un nombre de crédits fixé à l’avance. Cette consommation s’écrit dans un journal, par lots, avant d’être décomptée du quota. Ce journal, c’est le prestataire qui l’écrit.

Le client voit un solde qui baisse. Le détail de chaque écriture reste dans le journal du prestataire.

Je détaille ailleurs ce qui compose la facture d’un assistant IA branché sur un logiciel métier : les mêmes réglages, cache, plafonds, boucles d’outils, jouent aussi sur le nombre de crédits qu’une action consomme. Le compteur, lui, décide si cette consommation s’écrit une fois ou deux.

Un devis chiffre la construction de l’agent, une fois. Le compteur chiffre chaque mois qui suit. Une écriture doublée ne laisse aucune trace visible sur la facture : le solde baisse plus vite, et rien n’explique pourquoi. Les autres postes qui composent la facture d’un projet IA se lisent sur un devis. Le compteur, lui, se lit sur un solde.

La clé posée au mauvais moment

Chaque lot d’écritures part avec une clé d’idempotence : un identifiant qui permet au système de reconnaître un lot déjà enregistré, et de l’ignorer s’il repasse. C’est le principe du numéro de suivi collé sur un colis au moment où on le scelle : il désigne ce colis précis, et s’il repasse par l’entrepôt, il dit qu’il est déjà parti.

Dans Livia, cette clé se générait au moment du vidage du lot, c’est-à-dire à la fin, quand les écritures partaient vers le journal. Un lot reparti, après une reprise ou un envoi relancé, générait alors une clé différente à chaque tentative. Le système ne pouvait plus reconnaître qu’il s’agissait du même travail : chaque tentative avait l’air d’être la première.

Un rejeu, c’est ça : le même lot qui repart une seconde fois, volontairement ou après un incident. Pour un agent IA qui traite des dossiers toute la journée, les rejeux sont courants et sans danger, tant que le système sait les reconnaître. La clé posée au mauvais moment retirait cette capacité.

Ce qu’un double débit coûte au client

Illustration chiffrée. Une PME de 30 salariés, sur le quota de 1 100 crédits par mois. Un lot de 180 crédits part en milieu de mois, un incident le fait repartir, et la clé mal posée le laisse s’écrire deux fois.

PME de 30 salariés, quota de 1 100 crédits par mois360 crédits débités pour 180 consommés

Illustration : un lot rejoué en milieu de mois double son propre débit. Le quota tombe à zéro plusieurs jours avant la fin du mois.

Un quota épuisé en avance arrête l’agent pour toute l’équipe. Les collègues qui n’ont rien lancé perdent l’accès en même temps que l’utilisateur du lot reparti. Les dossiers en cours restent sans réponse jusqu’au mois suivant, ou jusqu’à un geste commercial du prestataire.

La vraie question suit le premier incident : si le compteur s’est trompé une fois, sur quoi d’autre se trompe-t-il ? Un prestataire sérieux y répond avant qu’on la lui pose.

Écrire à côté, puis renommer

La correction tient en un changement d’ordre. Le lot s’écrit d’abord dans un fichier temporaire, à côté, pendant que le travail se fait. Une fois le lot complet, ce fichier temporaire est renommé à l’emplacement définitif du journal.

Ce renommage est une opération atomique : il réussit entièrement, ou pas du tout, jamais à moitié. La clé d’idempotence se génère à l’ouverture du lot, avant la moindre écriture, et elle suit le fichier jusqu’au renommage. Un lot reparti reconstruit le même fichier, avec la même clé, et retombe sur une écriture déjà connue : le système l’ignore.

La correction se vérifie sans ouvrir le code : rejouez un lot, regardez le solde. S’il ne bouge pas à la seconde tentative, la clé tient. C’est le réflexe que je décris aussi pour les agents IA en production : une reprise propre s’observe sur un système qui tourne, avec les chiffres devant soi.

Le test à demander avant de signer

Demandez au prestataire de rejouer volontairement une écriture devant vous, et de vous montrer le solde avant et après. S’il refuse, ou s’il ne sait pas comment faire ce test, le compteur n’a probablement jamais été vérifié de cette façon.

Les questions à poser sur le compteur

Avant de signer un contrat d’IA facturée à l’usage, quatre questions suffisent à savoir si le compteur mérite confiance.

  1. Qui écrit le compteur : le prestataire, ou un système de facturation indépendant qu’il ne contrôle pas ?
  2. Que se passe-t-il si une écriture est rejouée après un incident ou une reprise ?
  3. Où le client lit-il sa consommation en temps réel, et à quelle fréquence ce chiffre se met-il à jour ?
  4. Que se passe-t-il quand le quota est atteint : l’agent s’arrête net, ou continue sur un dépassement facturé ?

Le compteur fait partie du contrat, au même titre que le prix ou le périmètre. La grille par où commencer aide à poser ces questions avant même de demander un devis.

Questions fréquentes

Comment une IA facturée à l’usage compte-t-elle ce que je consomme ?
Chaque action de l’IA, une lecture, une comparaison, une rédaction, consomme un nombre de crédits fixé à l’avance. Ces consommations s’écrivent par lots dans un journal tenu par le prestataire, puis se décomptent d’un quota mensuel de crédits attribué à votre organisation. Le solde affiché évolue à chaque lot traité, sans attendre la fin du mois.
Qu’est-ce qu’une clé d’idempotence ?
C’est l’identifiant unique attaché à un lot d’écritures au moment où il commence. Il permet au système de reconnaître ce lot précis s’il revient, par exemple après une reprise sur incident, et de l’ignorer plutôt que de l’enregistrer une seconde fois. Posée au mauvais moment, une clé d’idempotence perd cette capacité et laisse un même travail s’écrire deux fois.
Comment vérifier qu’un prestataire ne facture pas deux fois la même consommation d’IA ?
Demandez-lui de rejouer volontairement une écriture devant vous et de montrer le solde avant et après la tentative : s’il ne bouge pas à la seconde fois, le compteur reconnaît le rejeu. Demandez aussi comment la clé qui protège contre les doublons est générée, et à quel moment du traitement. Un prestataire qui répond avec précision aux deux a déjà testé son propre compteur.

Envie d’en parler pour votre entreprise ?

Trente minutes, gratuites, sans engagement. On regarde vos tâches répétitives et je vous dis franchement ce qui vaut le coup, et ce qui ne le vaut pas.

Trouver mon point de départ
Trouver mon point de départ