« Charge créée avec succès » : ce message, journalisé sans le moindre avertissement, s’est répété 34 fois en moins d’une heure sur l’un des sites gérés par une agence spécialisée dans les plateformes SaaS de formation en ligne, à l’occasion d’un audit de sécurité mené sur l’ensemble de son parc de douze clients utilisant des agents IA connectés à Stripe pour gérer les changements d’abonnement.
L’audit portait spécifiquement sur les agents chargés d’accompagner les utilisateurs dans un changement de formule d’abonnement, avec création d’un paiement ponctuel pour la différence de tarif au prorata. Sur sept des douze sites audités, un plafond de montant existait bien pour chaque appel individuel à l’outil Stripe, mais rien n’empêchait un agent d’enchaîner plusieurs appels successifs dans la même session, sans limite cumulée.
Le trou dans la raquette
Le plafond par appel, généralement fixé autour de 200 euros sur ces sites, protégeait bien contre une charge unique disproportionnée. Il ne protégeait en revanche pas contre un scénario où l’agent, coincé dans un raisonnement erroné après une réponse ambiguë de l’utilisateur, réémettait plusieurs petites charges successives en pensant corriger une erreur précédente, chacune sous le seuil autorisé mais dont le cumul dépassait largement ce que la situation justifiait.
Le correctif : un compteur de session, pas seulement un plafond d’appel
La correction introduit un second niveau de contrôle, complémentaire du plafond par appel existant : un compteur de dépense cumulée par session d’agent, stocké en base et vérifié avant chaque nouvelle tentative de création de paiement.
function wpm_verifier_plafond_session( string $session_id, float $montant ): bool {
global $wpdb;
$cumul = (float) $wpdb->get_var(
$wpdb->prepare(
"SELECT COALESCE(SUM(montant), 0) FROM {$wpdb->prefix}agent_paiements
WHERE session_id = %s AND DATE(cree_le) = CURDATE()",
$session_id
)
);
$plafond_session = 300.00; // en euros, ajustable par site
if ( ( $cumul + $montant ) > $plafond_session ) {
return false; // rejet, passage en validation humaine requis
}
return true;
}
Chaque tentative de création de paiement enregistre désormais son montant dans une table dédiée, avec la session de l’agent associée, ce qui permet de calculer un cumul quotidien avant d’autoriser une nouvelle opération. Le plafond de session a été fixé à 300 euros sur la majorité des sites concernés, remis à zéro chaque jour.
Pourquoi un plafond quotidien plutôt que par conversation
Un plafond réinitialisé à chaque nouvelle conversation aurait pu être contourné simplement en ouvrant plusieurs conversations successives avec le même agent. Le choix d’un cumul à l’échelle de la journée, indépendant du découpage en conversations, ferme cette voie de contournement, au prix d’une légère rigidité pour les cas légitimes de changements multiples le même jour, qui basculent alors en validation humaine.
Le déploiement sur les sept sites concernés
- Ajout de la table de suivi des paiements par session sur chaque site concerné
- Plafond de session fixé en concertation avec chaque client, entre 200 et 500 euros selon le volume habituel
- Aucune régression constatée sur les changements d’abonnement légitimes après trois semaines de suivi
Un plafond par appel protège contre l’erreur ponctuelle ; un plafond de session protège contre l’erreur qui se répète sans qu’on s’en aperçoive.
En résumé
Cet audit rappelle qu’un plafond de montant par appel, aussi bien conçu soit-il, ne suffit pas à encadrer un agent capable d’enchaîner plusieurs opérations dans une même session. La performance de ces intégrations Stripe, elle, n’a fait l’objet d’aucune mesure particulière dans le cadre de cet audit, qui s’est volontairement concentré sur la question du plafonnement des montants.
