Un client avait mis en place une fonctionnalité de reformulation de commentaires par IA sur son site à fort trafic, sans plafond de sécurité. Un pic de visites inhabituel, provoqué par un article partagé sur les réseaux sociaux, a suffi pour dépasser en quelques heures le quota mensuel prévu avec son fournisseur d’API, coupant net la fonctionnalité pour le reste du mois.
Pour éviter que cela ne se reproduise, nous avons ajouté un compteur de requêtes quotidien directement dans le code de l’extension, avec une dégradation progressive du service plutôt qu’une coupure brutale et incomprise par les visiteurs.
Le compteur basé sur les transients
Les transients WordPress, avec leur expiration automatique intégrée, conviennent parfaitement à ce type de compteur glissant sur 24 heures. On incrémente une valeur à chaque appel réussi vers l’API, et on vérifie ce compteur avant chaque nouvel appel.
function ia_quota_atteint() {
$compteur = get_transient( 'ia_requetes_du_jour' );
return false !== $compteur && (int) $compteur >= 500;
}
function ia_incrementer_compteur() {
$compteur = get_transient( 'ia_requetes_du_jour' );
if ( false === $compteur ) {
set_transient( 'ia_requetes_du_jour', 1, DAY_IN_SECONDS );
return;
}
set_transient( 'ia_requetes_du_jour', (int) $compteur + 1, DAY_IN_SECONDS );
}
Le seuil de 500 requêtes par jour a été fixé après discussion avec le client, en fonction du quota mensuel réellement souscrit auprès du fournisseur, avec une marge de sécurité volontaire d’environ 20 % pour absorber les imprévus.
La dégradation gracieuse côté visiteur
Plutôt que d’afficher une erreur technique brute une fois le quota atteint, la fonctionnalité bascule sur un message clair et un comportement de repli acceptable : le formulaire de reformulation se désactive temporairement, avec un texte expliquant que le service reprendra le lendemain.
if ( ia_quota_atteint() ) {
return new WP_Error(
'quota_ia_atteint',
__( 'La reformulation assistée est momentanément indisponible, réessayez demain.', 'mon-plugin' )
);
}
Répartir le quota entre plusieurs fonctionnalités
Sur ce même site, deux fonctionnalités distinctes utilisaient la même clé API, la reformulation de commentaires et un outil interne de suggestion de titres pour l’équipe éditoriale. Sans distinction, un pic sur l’une pouvait épuiser le quota de l’autre. Nous avons donc segmenté le compteur par fonctionnalité, avec une clé de transient différente pour chacune.
ia_requetes_du_jour_commentairespour la reformulation publique, plafonnée à 400 par jouria_requetes_du_jour_editorialpour l’outil interne, plafonné à 100 par jour- chaque compteur expire indépendamment au bout de 24 heures
Cette segmentation garantit que l’équipe éditoriale garde accès à son outil même lors d’un pic de trafic public inattendu, et inversement.
Ce qu’un simple compteur ne couvre pas
Ce mécanisme protège contre un dépassement de volume, mais ne protège pas contre un pic de coût soudain si le fournisseur facture différemment selon la longueur des réponses. Pour un contrôle plus fin, il faudrait comptabiliser les tokens réellement consommés plutôt que le simple nombre d’appels, ce qui dépasse le périmètre de cette recette centrée sur la fréquence des requêtes.
Un plafond de requêtes qui se contente de couper le service au dépassement du seuil vaut toujours mieux qu’aucun plafond du tout, mais il ne remplace pas un vrai suivi de consommation.
Le choix du seuil, une décision à revoir régulièrement
Le seuil de 500 requêtes par jour retenu au départ n’a rien d’une valeur universelle, il découle directement du quota mensuel négocié avec le fournisseur et du nombre de jours ouvrés du mois. Trois mois après la mise en place, le client a renégocié un forfait plus large auprès de son fournisseur d’API, ce qui nous a conduits à relever le seuil en conséquence dans le code de l’extension. Un tel plafond mérite d’être revu à chaque changement de contrat, plutôt que d’être figé une fois pour toutes lors du développement initial.
En résumé
Un compteur de requêtes basé sur les transients WordPress, associé à un message de repli clair pour le visiteur, protège efficacement un site à trafic imprévisible contre un dépassement brutal de quota. La segmentation par fonctionnalité évite qu’un usage public à fort volume ne prive l’équipe interne de son propre accès à l’API le même jour, à condition de revoir le seuil retenu à chaque évolution du contrat souscrit auprès du fournisseur.
