Quand le paiement ne passe plus, que fait votre agent IA ?

Le prélèvement qui ne passe pas

Un mardi soir, un mail arrive : le prélèvement de l’abonnement IA a échoué. La question suit dans la seconde : est-ce que l’agent tourne encore cette nuit, et qui paie ce qu’il consomme d’ici la régularisation ?

Un agent IA facturé à l’usage doit cesser de dépenser dès que le paiement ne passe plus, et repartir seul dès qu’il repasse. Ce comportement se vérifie avant de signer, par un test précis pendant la démonstration.

Un logiciel qui dépense à chaque action

Un logiciel de gestion classique continue de tourner après un impayé sans coûter grand-chose de plus à son éditeur. Le code tourne, la base de données répond, l’infrastructure ne consomme pas davantage parce qu’un client ouvre l’outil ce jour-là.

Un agent IA dépense à chaque action. Chaque lecture, chaque rédaction, chaque appel à un outil consomme des crédits, décomptés d’un quota comme je le décris dans le fonctionnement d’un compteur de facturation à l’usage. Un compte resté actif après un impayé continue de consommer ce quota, ligne après ligne.

D’où deux peurs chez le dirigeant. L’agent continue de tourner et la note se creuse pendant que le paiement traîne. Ou l’agent s’arrête net, et le travail s’arrête avec lui, dossiers en cours compris.

Le blocage à deux couches

Chez Livia, le produit que je construis, le blocage de dépense se pose à deux couches. Une première vérification a lieu à l’entrée, avant qu’une action coûteuse ne parte : lecture d’un dossier, appel à un outil, rédaction d’une réponse. Une seconde vérification a lieu au moment de débiter les crédits, juste avant l’écriture dans le journal de consommation.

Le premier contrôle arrête une action avant qu’elle ne commence à consommer. Le second empêche qu’une action déjà lancée ne s’écrive quand même au débit, si le paiement a basculé entre les deux.

Les deux couches lisent le même état de paiement. Aucune des deux n’écrit de drapeau « suspendu » sur le compte client. L’état se recalcule à chaque passage, à partir du paiement lui-même.

Un drapeau posé en base ressemble à une étiquette collée sur un dossier physique. Une fois posée, quelqu’un doit penser à la retirer. Un incident de paiement en pleine nuit, un week-end, une régularisation traitée par un tiers : l’étiquette reste, même quand la situation qui l’a justifiée a disparu. Le client régularisé se retrouve bloqué, pour une raison qui n’existe plus.

Lire l’état du paiement à chaque passage évite ce risque. Rien n’est écrit qui doive être défait plus tard.

Repartir seul en 60 secondes

La régularisation change l’état du paiement. À la vérification suivante, l’agent lit ce nouvel état et reprend. Chez Livia, le produit que je construis, ce délai ne dépasse jamais 60 secondes. Le compte redémarre de lui-même, sans que personne ait à intervenir.

Un service qui exige un appel au support pour redémarrer après une régularisation a posé un drapeau quelque part, et quelqu’un doit se souvenir d’aller le retirer, un samedi matin s’il le faut. C’est le même réflexe que je décris pour un agent IA qui tient en production : une reprise propre s’observe sur un système qui tourne, chiffres devant soi.

Les 23 heures que votre carte peut coûter

La coupure n’est jamais instantanée, et le délai dépend du moyen de paiement. Une carte bancaire en attente de validation 3DS, la double authentification du paiement, peut laisser l’agent actif jusqu’à 23 heures. Un prélèvement SEPA peut prendre plusieurs jours avant d’être confirmé ou rejeté.

Le moyen de paiement fixe donc la durée de la fenêtre. Une carte se décide en heures, un prélèvement SEPA en jours. Pendant toute cette fenêtre, l’agent travaille, et chaque action qu’il lance consomme des crédits.

C’est une décision assumée. Couper la dépense au premier signal d’échec arrêterait aussi les clients dont la carte finit par être validée quelques heures plus tard. Attendre la confirmation de la banque coûte quelques heures de dépense en plus.

Illustration chiffrée. Une PME dont l’agent traite environ 400 dossiers par mois, soit environ 13 par jour, voit son prélèvement échouer un mardi soir. Pendant la fenêtre d’attente de validation 3DS, l’agent continue de traiter les dossiers du mercredi, comme n’importe quel autre jour.

La banque confirme ou rejette la carte à son rythme, sans que le prestataire ait la main sur ce délai. Si la carte finit par passer, l’agent n’a jamais interrompu personne. Si elle est rejetée, la coupure s’applique à la vérification suivante, dans la même journée.

Ce que le contrat doit dire de l’impayé

Avant de signer, quelques questions suffisent à savoir si un prestataire a pensé l’impayé ou le découvre en même temps que vous.

1. À quels moments le blocage de dépense vérifie-t-il le paiement au cours d’une action ?
2. Le système pose-t-il un drapeau « suspendu » en base, ou recalcule-t-il l’état du paiement à chaque passage ?
3. Combien de temps s’écoule entre la régularisation d’un paiement et la reprise de l’agent ?
4. La reprise est-elle automatique, ou exige-t-elle un appel au support ?
5. Quel délai sépare un échec de paiement de la coupure effective, selon le moyen de paiement utilisé ?

Posez ces questions en même temps que celles sur le prix et le périmètre. La grille par où commencer aide à les poser avant même de demander un devis, et les postes qui composent la facture d’un projet IA se lisent utilement à côté de la clause d’impayé.