Un client éditeur d’un magazine en ligne a vu sa facture mensuelle d’API de génération de contenu grimper de 2,3 fois entre janvier et février, sans que le volume d’articles réellement publiés n’ait augmenté de façon comparable sur la même période. L’alerte est venue directement du service de facturation du fournisseur d’API, avant même que quiconque du côté du client ne remarque quoi que ce soit d’anormal sur le site.
Nous avons été sollicités pour comprendre l’origine de cette explosion de coût, avec l’obligation de trouver une réponse rapide tant la trajectoire de facturation, si elle se poursuivait, menaçait de dépasser largement le budget alloué à cette fonctionnalité.
Le symptôme : un nombre d’appels sans rapport avec les publications
La fonctionnalité en cause, un résumé automatique généré en tête de chaque article via l’API GPT-4, semblait à première vue raisonnable, un seul appel par article publié. Le journal des appels API, une fois exporté et confronté au nombre réel d’articles publiés dans le mois, racontait une tout autre histoire : plus de 1 800 appels API facturés pour seulement 95 articles publiés, soit environ 19 appels par article en moyenne.
Le diagnostic : la prévisualisation regénérait le résumé à chaque fois
En reprenant le code de l’extension, la cause est apparue clairement : le résumé était généré à chaque chargement de l’écran d’édition en mode prévisualisation, via un appel direct dans le rendu du bloc Gutenberg concerné, sans aucune mise en cache du résultat. Or l’équipe éditoriale de ce magazine avait pour habitude de prévisualiser un article de nombreuses fois avant sa publication finale, pour ajuster la mise en forme, vérifier les images, ou simplement se relire.
// Code fautif : un appel API à chaque rendu de prévisualisation
function render_resume_bloc( $attributes, $content ) {
$resume = appeler_api_resume( get_the_content() ); // aucun cache !
return '<p class="resume-ia">' . esc_html( $resume ) . '</p>';
}
Le correctif : mettre en cache le résumé par version de contenu
Le correctif consiste à ne régénérer le résumé que si le contenu de l’article a réellement changé depuis la dernière génération, en comparant un hachage du texte source à celui stocké lors du dernier appel.
function render_resume_bloc( $attributes, $content ) {
$post_id = get_the_ID();
$contenu = get_the_content();
$hash_actuel = md5( $contenu );
$hash_stocke = get_post_meta( $post_id, '_resume_ia_hash', true );
$resume_stocke = get_post_meta( $post_id, '_resume_ia_texte', true );
if ( $hash_actuel === $hash_stocke && ! empty( $resume_stocke ) ) {
return '<p class="resume-ia">' . esc_html( $resume_stocke ) . '</p>';
}
$resume = appeler_api_resume( $contenu );
update_post_meta( $post_id, '_resume_ia_hash', $hash_actuel );
update_post_meta( $post_id, '_resume_ia_texte', $resume );
return '<p class="resume-ia">' . esc_html( $resume ) . '</p>';
}
Le résultat après correctif
Le mois suivant le déploiement du correctif, le nombre d’appels API est retombé à 112 pour 98 articles publiés, un ratio proche de un appel par article, cohérent avec l’usage réellement attendu. La facture est revenue à un niveau proche de celui observé avant l’explosion, avec une marge de sécurité conservée grâce au plafond de requêtes ajouté par la même occasion.
| Période | Appels API | Articles publiés | Appels par article |
|---|---|---|---|
| Avant correctif | 1 800 | 95 | ~19 |
| Après correctif | 112 | 98 | ~1,1 |
Un appel API déclenché à chaque rendu d’écran, plutôt qu’à chaque changement réel de contenu, finit toujours par se voir sur une facture, même quand personne ne l’a remarqué avant.
En résumé
Une fonctionnalité de génération IA branchée directement sur un rendu d’écran, sans mise en cache liée au contenu réel, peut multiplier silencieusement le nombre d’appels facturés bien au-delà de l’usage apparent. Comparer systématiquement le volume d’appels API au volume réel de publications, dès la mise en production d’une extension IA, aurait permis de détecter ce problème avant qu’il n’atteigne le service de facturation du fournisseur.
