Surveillez les charges de travail liées à l’IA sur WordPress grâce à Kinsta APM et aux journaux de serveur MyKinsta

Avec l’introduction de l’API Abilities et de l’IA Client, WordPress est devenu un véritable moteur d’exécution, faisant le lien entre vos applications et les modèles d’IA de votre choix.

Cette évolution majeure transforme la nature même du CMS. Cependant, elle ajoute également une couche de complexité à l’écosystème global, rendant l’observabilité des processus et la surveillance des performances de plus en plus essentielles à la gestion d’un site web moderne.

Aujourd’hui, nous ne sommes pas seulement ici pour vous expliquer à quel point il est important de surveiller le comportement de votre site alors que les machines sont de plus en plus présentes (voire intrusives) dans vos journaux d’accès. Nous souhaitons plutôt vous apporter des preuves claires et concrètes de l’impact direct de ces nouvelles fonctionnalités d’IA sur les ressources de votre site.

Pour cela, nous allons utiliser deux outils MyKinsta : Kinsta APM — notre outil de surveillance des performances des applications — et les journaux d’accès aux serveurs. Ces deux fonctionnalités sont accessibles à tous les clients Kinsta sans frais supplémentaires.

Vous êtes curieux de savoir dans quelle mesure l’IA affecte réellement votre site WordPress ? Plongeons-nous dans le vif du sujet !

Comment surveiller les charges de travail liées à l’IA dans WordPress

Votre site interagit avec l’IA de plusieurs façons. Cela va des analyses effectuées par des robots et des robots d’exploration IA aux opérations réalisées en interne par des plugins via l’IA Client, en passant par les requêtes émanant d’applications externes et d’agents IA interrogeant votre site via l’API Abilities.

Pensez au temps nécessaire pour générer une image ou transcrire un fichier audio. Ces opérations d’IA prennent souvent plusieurs secondes. Pendant ce temps, un worker/thread PHP n’est pas disponible pour d’autres opérations, qu’elles soient déclenchées par un utilisateur humain ou par une machine.

Bien que cela ne constitue pas nécessairement un problème pour tous les sites, cela devient un facteur critique à surveiller attentivement pour les sites professionnels à fort trafic et les boutiques en ligne proposant des centaines, voire des milliers de produits.

Un outil de surveillance des performances des applications (APM) vous aide à mesurer avec précision l’impact de l’IA sur votre site WordPress.

Vous pouvez utiliser un outil tel que New Relic pour suivre les transactions WordPress, les hooks, les extensions, les thèmes, les requêtes de base de données, les requêtes externes et tout ce qui vous aide à identifier les problèmes de performances.

Les utilisateurs de Kinsta ont accès à un outil gratuit de surveillance des performances des applications, directement disponible dans le tableau de bord MyKinsta.

Pour activer l’APM de Kinsta, rendez-vous dans Sites > nom-du-site > APM, puis cliquez sur Activer. Sélectionnez l’intervalle souhaité et laissez l’outil enregistrer l’activité de votre site.

Une fois la surveillance terminée, vous recevrez un e-mail automatique contenant un lien vers la page des résultats, où vous pourrez consulter des graphiques détaillés portant sur les transactions, les extensions, les thèmes, les hooks, les requêtes de base de données lentes et les requêtes externes.

Les journaux d’accès et d’erreurs constituent une autre mine d’informations précieuses sur ce qui se passe en coulisses. En règle générale, vous pouvez accéder aux journaux du serveur via votre panneau de contrôle d’hébergement ou au sein du système de fichiers de votre serveur via FTP ou SSH.

Ces journaux fournissent des données complètes pour résoudre les erreurs, identifier les goulots d’étranglement en matière de performances et localiser vos principales sources de trafic.

Les utilisateurs de Kinsta peuvent télécharger les fichiers de journaux directement depuis le serveur via SFTP ou SSH, ou via le gestionnaire de fichiers MyKinsta. Vous pouvez également consulter les journaux d’erreurs, de cache et d’accès directement à l’aide de la visionneuse de journaux MyKinsta.

Dans les sections suivantes, nous analyserons une opération d’IA afin de vous aider à comprendre comment mesurer l’impact de l’utilisation de l’IA sur votre site web et pourquoi celle-ci nécessite une infrastructure robuste et une surveillance adéquate.

Examinons un exemple concret en demandant à un modèle d’IA de générer une image mise en avant pour un article de blog.

Génération d’images par IA dans WordPress

Pour nos tests, nous avons demandé à l’IA de générer une image mise en avant pour un article de blog WordPress à l’aide d’une extension IA officielle de WordPress.org. Pour effectuer les mêmes tests, veuillez suivre les étapes suivantes :

1. Configurer un connecteur dans l’écran « Connecteurs » de l’interface d’administration de WordPress
2. Installer et activer l’extension IA officielle de WordPress.org
3. Activer Kinsta APM et surveillez les journaux d’accès dans MyKinsta
4. Créez un nouvel article et générez une nouvelle image mise en avant à l’aide de la fonctionnalité d’IA

C’est parti.

Étape 1 : Configurer un connecteur dans l’écran « Connecteurs »

Pour commencer, vous aurez besoin d’une clé API fournie par votre fournisseur d’IA. Nous n’aborderons pas cette étape ici, mais vous pouvez consulter la documentation de votre fournisseur pour plus de détails.

Une fois que vous disposez de votre clé API, ouvrez l’administration de votre site et accédez à Réglages > Connecteurs. Cliquez sur le bouton Activer correspondant à votre fournisseur d’IA et saisissez votre clé API.

Étape 2 : Installer et activer l’extension IA officielle de WordPress.org

WordPress fournit d’emblée les API et les abstractions nécessaires. Pour doter votre site d’une fonctionnalité de génération d’images par IA, vous devrez installer un plugin qui exploite l’infrastructure centrale d’IA, tel que l’extension IA officielle fournie par WordPress.org.

Cette extension ajoute plusieurs capacités que vous pouvez consulter dans l’écran Abilities Explorer, sous Outils > Abilities Explorer.

Parmi les capacités répertoriées, notez notamment Génération et édition d’images. Cette capacité vous permet de générer une image mise en avant à partir du contenu d’un article ou d’une consigne personnalisée lorsque vous l’invoquez depuis la médiathèque.

Étape 3 : Activer Kinsta APM et surveiller les journaux d’accès dans MyKinsta

Dans MyKinsta, accédez à Sites > nom-du-site > APM et activez Kinsta APM. Définissez une durée de surveillance de 2 heures, puis cliquez sur Activer la surveillance.

Pendant que l’outil APM suit les performances en arrière-plan, accédez à Sites > nom-du-site > Journaux et sélectionnez l’onglet access.log. Vous pouvez conserver les réglages par défaut.

Étape 4 : Créer un nouvel article et générer une nouvelle image mise en avant à l’aide de l’IA

De retour dans votre tableau de bord d’administration WordPress, créez un nouvel article, saisissez un titre et du contenu, puis cliquez sur le bouton Générer une image mise en avant situé à droite.

Au bout de quelques instants, une image mise en avant générée par l’IA s’affiche dans la colonne latérale des réglages de l’article.

L’opération que nous souhaitons surveiller est désormais terminée. Nous pouvons passer à l’analyse des données.

Mesurer la consommation de ressources liée à la génération d’images par IA

Mesurons à présent l’impact d’une requête de génération d’image via l’API WordPress Abilities. Les résultats de ce test ne sont pas figés, car ils dépendent en grande partie des temps de traitement et de réponse de l’API du fournisseur, ainsi que des opérations spécifiques effectuées par le plugin lors de l’envoi de la requête.

Notre objectif ici est de vous fournir un cadre et une méthodologie que vous pourrez facilement reproduire dans vos propres environnements de staging afin de mesurer la consommation de ressources et les temps d’exécution des opérations d’IA.

L’analyse que nous proposons examine les deux facettes du problème. Côté serveur, nous analyserons les transactions à l’aide de Kinsta APM et surveillerons les requêtes HTTP via la visionneuse de journaux MyKinsta. Côté client, nous surveillerons ce qui se passe en arrière-plan à l’aide des outils de développement du navigateur.

C’est parti !

Analyse détaillée de Kinsta APM

Une fois que vous disposez de l’image mise en avant générée par l’IA pour votre article, patientez quelques minutes, puis revenez à la page Kinsta APM dans MyKinsta et commencez à explorer chaque onglet.

L’onglet Transactions affiche un graphique représentant la durée globale des transactions ainsi qu’un tableau des transactions les plus lentes, où une transaction correspond à une activité en arrière-plan qui a lieu pour répondre à une requête adressée à votre site WordPress (voir la documentation).

L’image ci-dessous illustre le temps de transaction global sur une période de deux minutes, durant laquelle l’exécution PHP a pris environ 27 secondes, MySQL 271 ms, et les transactions externes ont représenté plus de 19 secondes.

Le tableau ci-dessous répertorie les transactions les plus lentes. Comme vous pouvez le constater, les requêtes ciblant le point de terminaison /wp-json ont représenté la plus grande partie du temps de transaction.

L’onglet WordPress présente les tableaux des extensions WordPress les plus lentes et des hooks WordPress les plus lents. Comme on pouvait s’y attendre, les extensions les plus lentes étaient ai-provider-for-google et ai, qui représentaient à eux deux près de 90 % de la durée totale.

L’onglet Externe affiche les requêtes externes les plus lentes, triées par durée totale.

Analysons ces données :

• Durée totale (%) : il s’agit du pourcentage de temps consommé par l’ensemble des requêtes adressées à un point de terminaison de transaction au cours de la période sélectionnée. Veuillez noter que cette valeur correspond à la somme des durées de toutes les requêtes adressées à un point de terminaison, et non à celle d’un échantillon de transaction individuel. Dans notre exemple, les requêtes POST adressées au point de terminaison generativelanguage.googleapis.com représentaient 95,51 % de l’ensemble des transactions externes, tandis que les requêtes GET adressées au même point de terminaison représentaient 3,94 %.
• Durée totale : il s’agit de la durée absolue qu’un point de terminaison de transaction consomme au cours de la période sélectionnée. Là encore, cette valeur représente la somme des durées de toutes les requêtes adressées à un point de terminaison particulier. Dans notre exemple, les requêtes POST adressées à generativelanguage.googleapis.com ont eu une durée cumulée de plus de 18 secondes.
• Durée maximale : la durée la plus longue parmi les échantillons de transactions de la période sélectionnée.
• Durée moyenne : la moyenne de toutes les durées d’échantillons de transaction pour la période sélectionnée.
• Fréquence par minute : le nombre moyen d’exécutions d’une transaction par minute.

Lorsque vous cliquez sur une requête spécifique, une fenêtre modale Échantillons de transaction s’affiche et présente les échantillons au cours desquels la requête POST sélectionnée s’est exécutée.

Cliquez sur l’échantillon de transaction le plus lent pour afficher le tableau de la chronologie de la trace de transaction. Vous y trouverez une présentation étape par étape des segments (processus PHP, requêtes de base de données MySQL et appels externes) pour un échantillon de transaction spécifique (voir la documentation).

Si vous cliquez sur un « span » dans la chronologie de la trace de transaction, vous verrez un aperçu détaillé et une trace de pile complète.

La trace de pile détaille le code PHP exact qui a été exécuté, jusqu’au fichier et au numéro de ligne spécifiques (voir la documentation).

L’image suivante montre la trace de pile complète de la transaction qui a géré la génération de l’image :

Voici le détail des étapes :

Étape 1 : Initialisation de la requête

WordPress reçoit la requête HTTP, lance le système central via wp-blog-header.php et la transmet via le contrôleur de l’API REST (WP_REST_Server) afin de traiter la requête entrante de manière synchrone.

Étape 2 : Déclenchement de la fonctionnalité

Le fichier Generate_Image.php appelle la capacité  generate_image au sein de l’espace de noms WordPress\AI\Abilities\Image afin de générer l’image de l’article.

Étape 3 : Transfert vers le client

Le fichier class-wp-ability.php exécute la fonction de rappel, en déléguant l’exécution au module WP_AI_Client.

Étape 4 : Création de la consigne

PromptBuilder.php construit la prompt, et GoogleTextGenerationModel.php convertit les instructions en un format de requête compatible avec les API Gemini.

Étape 5 : Transfert vers la couche de transport HTTP

HttpTransporter.php transfère l’exécution à l’API HTTP de WordPress (http.php -> WP_Http->request).

Étape 6 : Ouverture d’une connexion HTTP

WP_Http ouvre une connexion synchrone, bloquant le worker PHP jusqu’à ce que Google renvoie une réponse (voir la documentation officielle).

Conclusion

Le point essentiel à retenir ici est que la tâche de génération d’image que nous avons mesurée est une opération synchrone et bloquante.

L’appel passe de WP_REST_Server à WP_Http->request au cours du même cycle de vie de la requête HTTP. Par conséquent, le thread PHP reste en attente pendant la génération et le renvoi de l’image.

Dans cet exemple, le thread PHP traitant la requête est resté occupé pendant 8 secondes. D’autres threads disponibles pouvaient tout de même traiter d’autres requêtes. Cependant, les opérations d’IA simultanées peuvent épuiser le pool de mémoire PHP et accroitre les files d’attente, la latence et le risque de dépassement de délai (découvrez comment Kinsta vous aide à gérer les threads PHP et l’utilisation de la mémoire).

Analyse des journaux du serveur

Alors qu’une trace de pile enregistre la séquence exacte des fonctions PHP, des méthodes, des fichiers et des lignes de code parcourus par le serveur pour traiter une requête spécifique, les journaux d’accès enregistrent les requêtes HTTP au niveau du serveur web.

Un journal d’accès indique qui a effectué la requête (adresse IP et agent utilisateur), ce qui a été demandé (URL ou point de terminaison API), le code d’état de la réponse et la durée totale d’exécution de la requête.

En résumé, l’analyse des journaux vous offre une vue complète et non filtrée de ce qui se passe sur votre serveur lors d’une opération d’IA, telle que la génération de l’image mise en avant dans notre exemple.

Pour générer cette seule image, WordPress a exécuté quatre appels consécutifs à l’API Abilities.

Voici les journaux retraçant l’interaction avec l’API Google :

1. Génération du prompt

POST "/wp-json/wp-abilities/v1/abilities/ai/image-prompt-generation/run?_locale=user" HTTP/2.0 200
PHP execution time: 5.432s

• Ce que ce journal vous indique : le plugin utilise la fonctionnalité image-prompt-generationpour envoyer le contenu de l’article à Gemini afin de générer une consigne descriptive pour l’image (par exemple : « Une personne serrant la main d’un robot futuriste aux lignes épurées… »).
• Latence : 5,43 secondes consacrées à la communication avec l’API Google.

2. Génération d’images

POST "/wp-json/wp-abilities/v1/abilities/ai/image-generation/run?_locale=user" HTTP/2.0 200
PHP execution time: 9.795s

• Ce que ce journal vous indique : cette entrée de journal correspond directement à l’exemple de transaction et à la trace de pile que nous avons analysés dans la section APM de Kinsta. L’extension envoie la requête générée au modèle de génération d’images de Google (Imagen) via la fonctionnalité image-generation.
• Temps d’exécution PHP : 9,79 secondes passées à attendre la charge utile binaire/base64 de l’image.

3. Génération du texte alternatif

POST "/wp-json/wp-abilities/v1/abilities/ai/alt-text-generation/run?_locale=user" HTTP/2.0 200
PHP execution time: 11.305s

• Ce que ce journal vous indique : immédiatement après la création de l’image, le système déclenche un autre appel automatique à l’API Abilities afin de générer le texte alternatif. La fonctionnalité fait alors appel à Gemini pour analyser et décrire l’image nouvellement générée.
• Temps d’exécution PHP : 11,30 secondes au total.

L’image a été générée. L’étape suivante consiste à l’enregistrer dans la médiathèque WordPress.

4. Intégration des médias

POST "/wp-json/wp-abilities/v1/abilities/ai/image-import/run?_locale=user" HTTP/2.0 200
PHP execution time: 0.839

• Ce que ce journal vous indique : WordPress télécharge le contenu du fichier depuis l’API externe via la fonctionnalité image-import et l’enregistre dans la médiathèque.
• Temps d’exécution PHP : 0,839 seconde.

5. Télécharger l’image

GET "/wp-content/uploads/2026/09/a-person-shaking-hands-with-a-sleek-futuristic-robot-inside-a-glass-dome-1024x559.jpg" HTTP/2.0 200
PHP execution time: 0.000

• Ce que ce journal vous indique : l’éditeur de blocs récupère le fichier image importé directement depuis le répertoire uploads afin de l’afficher dans l’interface utilisateur. Il s’agit d’une ressource statique fournie directement par le serveur web, et aucun traitement PHP n’est nécessaire.
• Temps d’exécution PHP : 0,000 seconde.

Ce que révèlent les journaux d’accès

Si vous additionnez les temps d’exécution sur l’ensemble du flux de travail pour la génération d’une seule image, vous obtenez le temps d’exécution global de l’opération complète — y compris la génération de lu prompt, la génération de l’image, la génération du texte alternatif et l’importation de l’image dans WordPress.

Dans notre exemple, les journaux ont fourni les temps d’exécution suivants :

• Génération de la consigne d’image : 5,43 s
• Génération-de-l’image : 9,79 s
• Génération-du-texte-alternatif : 11,30 s
• Importation-de-l’image : 0,84 s

Total : environ 27,36 secondes cumulées de temps de traitement des threads PHP !

Cela confirme notre hypothèse initiale : sur une configuration d’hébergement traditionnelle aux ressources limitées, si deux ou trois tâches basées sur l’IA s’exécutent simultanément, le serveur atteindra rapidement la saturation des threads PHP et cessera de répondre aux autres visiteurs du site pendant plusieurs secondes.

Si votre site intègre plusieurs fonctionnalités d’IA, votre infrastructure d’hébergement revêt une importance encore plus cruciale. De plus, les outils de surveillance tels que Kinsta APM et les journaux d’accès MyKinsta constituent d’excellents moyens de mesurer l’impact des charges de travail liées à l’IA, d’identifier les goulots d’étranglement en matière de performances et de mettre en œuvre les optimisations appropriées.

Répartition des requêtes HTTP côté client

Alors que Kinsta APM et les journaux d’accès au serveur vous aident à comprendre l’impact de l’IA sur l’infrastructure de votre site, les outils de développement du navigateur vous permettent d’analyser le flux de travail du point de vue du client.

Pour analyser les appels réseau, veuillez suivre les étapes suivantes :

1. Ouvrez votre interface d’administration WordPress et créez un nouvel article.
2. Ouvrez les outils de développement de votre navigateur préféré en appuyant sur F12 (ou en cliquant avec le bouton droit > Inspecter / Cmd Option I sur Mac).
3. Sélectionnez l’onglet Réseau et filtrez par Fetch/XHR pour n’afficher que les appels asynchrones ou vers l’API REST.
4. Lorsque vous êtes prêt, cliquez sur le bouton Générer une image mise en avant dans l’éditeur de blocs.

Les requêtes adressées aux points de terminaison de l’API Abilities commencent à s’afficher dans le panneau Réseau. Dans les outils de développement de Firefox, elles seront signalées par une icône en forme de tortue, indiquant des requêtes lentes.

Cliquez sur chacune de ces requêtes, l’une après l’autre, et observez les onglets Requête, Réponse et Temps pour chaque requête.

1. Génération du prompt

Le premier appel à l’API Google AI génère la consigne. Pour cette opération, la charge utile de la requête comprend le titre et le contenu de l’article.

La réponse correspond à la consigne envoyée au modèle Imagen.

Passez ensuite à l’onglet Timings pour vérifier les temps d’exécution. La génération du prompt pour cette dernière image a pris 5,52 secondes.

2. Génération de l’image

Vient ensuite la requête de génération d’image. La charge utile de la requête correspond à la consigne reçue lors de la requête précédente.

La réponse de l’API Google correspondra à la charge utile de l’image au format base64.

L’onglet Timings indique la durée totale d’exécution de la génération d’image. La requête a été en attente pendant 9,92 secondes.

3. Génération du texte alternatif

Lors du troisième appel, l’API Abilities demande à l’API Google de générer le texte alternatif de l’image. La requête inclut la charge utile de l’image au format base64.

La réponse de l’API contient le texte alternatif de l’image.

Malgré un résultat concis, le décodage de l’image et la génération du texte ont été particulièrement lents : 7,32 s.

4. Téléchargement de l’image

La quatrième requête de l’API Abilities traite la charge utile binaire, télécharge le fichier image, génère des recadrages de l’image et enregistre celle-ci dans la médiathèque WordPress. Le temps d’attente pour cette dernière requête était de 1,79 s.

Résumons à présent les temps d’attente des quatre requêtes exécutées par l’API Abilities pour générer l’image mise en avant :

• Génération du prompt : 5,52 s
• Génération de l’image : 9,92 s
• Génération du texte alternatif : 7,32 s
• Téléchargement et enregistrement de l’image : 1,79 s

Le temps d’attente total s’élevait à pas moins de 24,55 secondes.

L’impact de l’IA sur l’infrastructure du site

Que vous utilisiez des extensions tierces ou du code personnalisé pour ajouter des fonctionnalités d’IA à votre site, il est essentiel de comprendre leur impact sur les performances du serveur et la consommation de ressources.

Une gestion inefficace des ressources ou une architecture de code médiocre peut rapidement surcharger votre serveur, entrainant une saturation des ressources PHP, des délais d’attente du serveur, une utilisation excessive de la bande passante, des erreurs HTTP 5xx ou même une indisponibilité totale.

Un hébergeur cloud hautement performant, reposant sur une infrastructure conteneurisée, une mise en cache à plusieurs niveaux, une optimisation automatique des bases de données et des workers PHP évolutifs, ne peut pas éliminer comme par magie la charge de traitement liée à l’IA. Cependant, il offre à votre site la marge de manœuvre nécessaire pour prévenir les goulots d’étranglement et résoudre les pics de performance avant qu’ils n’affectent vos visiteurs.

Personne ne souhaite un site lent lors des pics de trafic tels que le Black Friday, et les entreprises ne peuvent se permettre de délais d’expiration du serveur lorsque la disponibilité a un impact direct sur leur chiffre d’affaires. À mesure que les machines jouent un rôle de plus en plus important dans le fonctionnement des sites web, le choix d’un hébergeur performant et évolutif n’est plus une option.

Kinsta offre les performances, la sécurité et l’observabilité dont les sites WordPress modernes ont besoin pour prospérer à l’ère de l’IA. Vous souhaitez constater la différence par vous-même ? Découvrez nos plans ici.