wp_remote_post() qui retourne un WP_Error silencieux : voilà le point de départ de ce chantier. Depuis l’ouverture d’Elementor AI en marge de l’éditeur, plusieurs rédacteurs signalaient des générations de texte qui « ne se passaient rien », sans message d’erreur exploitable côté interface. Impossible de savoir, sans capture technique, si le problème venait d’un quota atteint, d’un timeout réseau ou d’une réponse malformée de l’API.
Le suivi qualitatif des textes générés n’est pas le sujet ici : d’autres personnes de l’équipe éditoriale s’en chargent. Ce qui manquait, c’était une remontée fiable des échecs techniques, avec assez de contexte pour qu’un développeur puisse reproduire le problème sans devoir demander à l’utilisateur de tout réexpliquer.
Où s’accrocher dans le flux d’Elementor AI
Les appels à l’API d’Elementor AI transitent, côté serveur, par des points d’entrée AJAX propres au plugin Elementor Pro. Plutôt que de modifier le cœur du plugin, ce qui casserait à la moindre mise à jour, nous avons ciblé les hooks génériques disponibles autour du traitement des requêtes AJAX de WordPress, en filtrant sur l’action concernée.
Le principe retenu : intercepter la réponse juste après l’appel réseau, vérifier si elle correspond à un cas d’erreur (code HTTP hors 200, corps JSON invalide, champ d’erreur explicite), puis transmettre l’incident à Sentry avec un contexte structuré plutôt qu’un simple message texte.
Mise en place du SDK Sentry côté serveur
Le SDK PHP officiel de Sentry s’installe via Composer dans un plugin maison dédié à l’observabilité, séparé du thème et d’Elementor pour survivre aux mises à jour.
\Sentry\init([
'dsn' => getenv('SENTRY_DSN'),
'environment' => wp_get_environment_type(),
'traces_sample_rate' => 0.0,
]);
add_action('elementor_ai/request/after', function ($response, $context) {
if (is_wp_error($response) || empty($response['success'])) {
\Sentry\withScope(function ($scope) use ($context) {
$scope->setTag('component', 'elementor-ai');
$scope->setContext('elementor_ai', [
'widget_id' => $context['widget_id'] ?? 'inconnu',
'user_id' => get_current_user_id(),
'prompt_len' => strlen($context['prompt'] ?? ''),
]);
\Sentry\captureMessage('Échec appel Elementor AI');
});
}
}, 10, 2);
Un hook maison plutôt qu’un hook natif
Le nom elementor_ai/request/after ci-dessus n’est pas un hook natif d’Elementor : il faut le créer soi-même en interceptant la requête AJAX correspondante via add_action('wp_ajax_elementor_ajax', ...) et en isolant l’action précise dans le tableau de données transmis, avant de déclencher le do_action maison avec les informations utiles. C’est un point important à ne pas confondre lors de la mise en œuvre.
Filtrer les faux positifs
Sans filtrage, la première semaine de capture a rempli le projet Sentry d’alertes redondantes liées à un quota d’utilisation temporairement dépassé sur le compte Elementor AI. Une règle de regroupement par empreinte (fingerprint) a permis de distinguer trois familles distinctes :
- Quota API dépassé (code retour spécifique, non bloquant côté rédacteur)
- Timeout réseau au-delà de 15 secondes
- Réponse JSON tronquée côté fournisseur
Ce que cette mise en place n’ambitionne pas
Ce dispositif ne juge à aucun moment la qualité du contenu généré : un texte de mauvaise qualité mais correctement retourné par l’API n’est pas capturé, et ce n’est pas son rôle. La configuration initiale d’Elementor AI (activation, quotas, choix des modèles disponibles) reste également hors du périmètre de cet article, déjà documentée par ailleurs.
Un incident silencieux côté interface reste un incident : sans capture technique dédiée, l’équipe de support découvre le problème par les tickets utilisateurs, toujours en retard d’une journée.
Pour aller plus loin
Avec trois semaines de recul, la répartition des erreurs remontées a permis de dimensionner le quota Elementor AI de l’équipe et d’ajouter un message d’attente explicite côté éditeur au-delà de 8 secondes de traitement. La prochaine étape consistera à croiser ces événements avec les métriques d’usage côté rédaction, pour distinguer les pics d’échec liés à la charge des pics liés à un incident du fournisseur.
