Ajouter comme source préférée sur Google
Mettons les choses en perspective. Votre nouveau chatbot WooCommerce réussit tous les tests. Il répond aux questions sur les produits, aide les acheteurs à comparer les options et réagit suffisamment vite pour que personne ne s’interroge sur ses performances.
Le problème n’apparaît qu’au moment où la boutique connaît un après-midi de forte affluence. Le processus de commande commence à prendre un peu plus de temps et les temps de réponse s’allongent à mesure que les threads PHP atteignent leur capacité maximale. Au premier abord, ce ralentissement semble résulter d’un pic de trafic, mais le nombre de visiteurs est à peu près identique à celui de la semaine précédente. Ce qui a changé, c’est la charge de travail que le serveur doit gérer lors de chaque visite.
Chaque échange avec le chatbot peut déclencher un appel d’API en temps réel qui transite par WordPress, contourne le cache de la page et occupe un thread PHP pendant que le fournisseur du modèle génère sa réponse. Il peut également interroger la base de données pour obtenir des détails sur les produits, l’historique des conversations ou d’autres éléments de contexte. Le client voit la réponse s’afficher en deux secondes. Le serveur, quant à lui, voit un thread qu’il ne peut utiliser à aucune autre fin pendant ce laps de temps.
Cette question d’infrastructure devient de plus en plus difficile à éluder. WordPress 7.0 a intégré l’IA au cœur du système via un client IA indépendant du fournisseur, ainsi que l’API Abilities et un hub central « Connectors ».
La même pression peut provenir de fonctionnalités qui semblent très différentes à première vue. La recherche par IA, les recommandations de produits, le contenu personnalisé, les outils éditoriaux et les intégrations d’agents interagissent chacun avec WordPress à leur manière. Savoir si elles s’exécutent dans le tableau de bord, sur l’interface utilisateur ou via une API (et si leurs requêtes peuvent être mises en cache) vous aide à prévoir les ressources serveur dont elles auront besoin.
À quoi ressemble réellement l’IA WordPress sur un site en production ?
L’IA sur WordPress ne constitue pas une charge de travail unique. L’endroit où la fonctionnalité s’exécute, le moment où elle s’exécute et le fait qu’un visiteur la déclenche ou non ont tous une incidence sur le profil de l’infrastructure.
Chatbots IA et assistants de support
Il s’agit de la catégorie la plus visible. Des extensions telles que AI Engine (qui compte plus de 100.000 installations actives), MxChat et Tidio intègrent des interfaces conversationnelles à l’interface utilisateur.
Chaque message peut déclencher une requête dynamique, récupérer le contexte, appeler un modèle externe et stocker les données de conversation. Contrairement à l’envoi d’un formulaire de contact, une seule conversation peut générer plusieurs de ces requêtes en succession rapide.
Personnalisation, recommandations et recherche basées sur l’IA
La personnalisation, les recommandations et la recherche par IA s’exécutent généralement côté client. Sur une boutique WooCommerce, cela peut impliquer d’adapter les suggestions de produits en fonction de ce qu’un client a déjà consulté ou d’interpréter une requête de recherche plutôt que de se contenter de faire correspondre sa formulation exacte. Le reste de la page peut souvent provenir du cache, mais ces résultats doivent tout de même être générés pour chaque requête individuelle.
Génération de contenu par IA et outils éditoriaux
Pensez à des outils tels que Jetpack AI, Rank Math Content AI, Divi AI et GetGenie. Ils fonctionnent principalement au sein du tableau de bord WordPress.
Comme ces outils s’exécutent principalement dans le tableau de bord WordPress, ils ne ralentissent généralement pas le chargement des pages côté client. Ils peuvent toutefois exercer une pression notable sur le serveur lorsque plusieurs éditeurs les utilisent simultanément.
Agents IA et intégrations MCP
Les intégrations MCP n’attendent pas qu’un visiteur accède au site. La prise en charge MCP d’AI Engine et l’adaptateur MCP officiel de WordPress permettent à un outil externe de se connecter à WordPress et d’effectuer des tâches autorisées, telles que la lecture des données du site ou la mise à jour d’un article. Chaque tâche s’effectue sous la forme d’une requête API authentifiée, ce qui ajoute une source supplémentaire d’activité serveur à prendre en compte.
Deux sites peuvent tous deux utiliser l’IA tout en nécessitant des niveaux de ressources d’hébergement très différents. L’un peut l’utiliser occasionnellement dans l’éditeur pour suggérer des titres, tandis que l’autre génère des recommandations de produits pour chaque client. Pour estimer l’impact, examinez où la fonctionnalité s’exécute et à quelle fréquence elle déclenche une requête WordPress.
L’impact réel des fonctionnalités d’IA sur votre serveur
Le coût d’une fonctionnalité d’IA provient du travail lié à la réponse du modèle. WordPress doit toujours recevoir la requête, exécuter le code de l’extension, récupérer les données nécessaires, contacter le fournisseur externe et renvoyer le résultat. Quatre étapes de ce processus ont le plus grand impact sur les performances.
Les threads PHP restent occupés plus longtemps
Le contenu mis en cache peut être servi sans utiliser de thread PHP. Une requête IA dynamique doit être traitée par un thread, et chaque thread ne gère qu’une seule requête à la fois. Si un chatbot attend deux secondes la réponse d’un fournisseur externe, le thread PHP gérant cet échange peut rester occupé pendant ces deux secondes. Lorsque des conversations simultanées utilisent tous les threads disponibles, les autres requêtes non mises en cache sont placées en file d’attente.
Ce phénomène est structurellement similaire aux modèles de trafic des robots documentés dans le rapport de Kinsta sur le trafic IA et des robots. Les robots accédant aux points de terminaison de recherche, de panier et autres points de terminaison dynamiques réservent des threads PHP et imposent un traitement à la source. Les fonctionnalités d’IA font la même chose de manière intentionnelle et, idéalement, de manière productive. Le coût d’infrastructure de chaque requête reste comparable.
Davantage de requêtes contournent le cache
De nombreuses réponses générées par l’IA sont spécifiques à la personne à l’origine de la requête ; elles ne peuvent donc pas être simplement réutilisées pour le visiteur suivant. La page principale du produit peut toujours se charger à partir du cache, mais un panneau de recommandations ou un résultat de recherche généré par l’IA doit être généré séparément. Plus cela se produit fréquemment au cours d’une visite, plus le serveur d’origine doit traiter de requêtes.
L’activité de la base de données se complexifie
Avant d’envoyer une invite, une extension peut avoir besoin d’extraire de WordPress les détails d’un produit, les messages précédents ou des informations sur l’utilisateur. Comme les données varient d’une requête à l’autre, il est plus difficile de les mettre en cache que pour une requête de page classique. Si un grand nombre de ces requêtes arrivent simultanément, elles alourdissent l’activité de la base de données au moment même où les pages de commande et de compte tentent d’effectuer leurs propres opérations.
La latence des API externes influe désormais sur les performances du site
Les extensions d’IA doivent souvent attendre la réponse d’un service tiers avant de pouvoir mener à bien une requête. Si OpenAI met trois secondes à répondre, WordPress attend lui aussi — et, dans le cas d’un appel synchrone, le thread PHP qui le gère attend également. L’extension doit disposer d’un délai d’expiration afin qu’un appel bloqué ne reste pas ouvert indéfiniment. Certaines charges de travail peuvent également être mises en file d’attente ou mises en cache, bien qu’un chatbot en direct doive généralement attendre le fournisseur.
WordPress 7.0 lui-même en offre un exemple utile. L’équipe du cœur du logiciel a retiré la fonctionnalité de collaboration en temps réel de cette version après que des tests ont soulevé des inquiétudes concernant la charge du serveur, l’utilisation de la mémoire et les conditions de concurrence. La fonctionnalité présentait toujours un intérêt, mais elle n’était pas prête à être déployée dans le respect des limites de performances que le cœur de WordPress devait respecter.
Les trois caractéristiques d’hébergement les plus importantes pour un WordPress doté d’IA
Les charges de travail liées à l’IA sont dynamiques, par intermittence et dépendent souvent de services extérieurs à votre environnement d’hébergement. Trois caractéristiques d’hébergement déterminent si ces requêtes restent circonscrites et identifiables ou si elles commencent à affecter le reste du site.
1. Architecture de conteneurs isolés
Cela peut poser problème sur un hébergement mutualisé, où votre site n’est pas le seul à utiliser le serveur. Si l’activité IA augmente soudainement, elle peut grignoter les ressources CPU, mémoire et base de données disponibles pour les autres sites hébergés sur la même machine.
Kinsta exécute chaque site WordPress dans son propre conteneur Linux isolé, doté d’une pile logicielle dédiée comprenant Nginx, PHP et MySQL. Chaque site bénéficie également de son propre thread PHP et de sa propre allocation de mémoire. Si un chatbot IA gère soudainement des dizaines de conversations simultanées, sa charge de travail reste confinée au conteneur de ce site, sans utiliser les ressources attribuées à un autre site.
Cette isolation est particulièrement précieuse pour les agences. Une extension d’IA mal configurée sur le site d’un client peut certes nuire à ce site, mais le problème ne se répercute pas sur le reste du portefeuille.
2. Une version PHP à jour et une configuration adaptée
PHP 7.4 permet d’exécuter WordPress 7.0, mais ce n’est pas la version que vous choisiriez pour optimiser les performances. PHP 8.x traite le code WordPress plus rapidement ; ainsi, le traitement d’une requête IA prend moins de temps et le thread PHP redevient disponible plus tôt.
Une version plus récente de PHP ne peut pas accélérer la réponse d’OpenAI ou d’Anthropic, mais elle peut réduire le travail effectué par WordPress avant et après cet appel externe. Kinsta prend en charge les versions de PHP jusqu’à la 8.5 et vous permet de modifier les versions pour chaque environnement de production ou de staging depuis MyKinsta. Tester d’abord la modification sur l’environnement de staging permet de détecter les conflits de compatibilité au niveau du plugin d’IA, du thème ou du code personnalisé.
3. Visibilité sur l’ensemble de la requête
Les problèmes de performances liés à l’IA peuvent provenir de plusieurs sources : le code PHP du plugin, une requête de base de données, le fournisseur de modèles externe ou une capacité de thread insuffisante. Sans données au niveau de la requête, ces quatre causes peuvent toutes être confondues avec un ralentissement général de l’hébergement.
L’outil APM de Kinsta sépare ces composants.
Une analyse pratique pourrait se présenter comme ceci :
- Consultez la rubrique Analyses > Performance pour vérifier à quel moment les temps de réponse ont augmenté.
- Ouvrez APM > Transactions pour identifier les points de terminaison et les requêtes les plus lents.
- Consultez la section APM > Externe pour mesurer les appels vers OpenAI, Anthropic ou un autre fournisseur.
- Consultez la section APM > Base de données pour repérer les requêtes de personnalisation lentes ou répétées.
- Passez en revue les principaux contournements du cache serveur pour voir quels chemins pilotés par l’IA atteignent l’origine.
Une fois que vous avez identifié où le temps s’est écoulé, vous disposez d’un point de départ utile. Une transaction WordPress lente nécessite une solution différente de celle d’une base de données saturée ou d’une API de modèle qui met plusieurs secondes à répondre.
Les fonctionnalités d’IA modifient également le profil de votre trafic
L’IA peut accroître la demande en infrastructure dans les deux sens. Votre site WordPress envoie davantage de requêtes aux fournisseurs de modèles, tandis que les systèmes automatisés envoient davantage de requêtes à votre site.
La publication assistée par l’IA peut rapidement élargir la surface d’exploration d’un site. Si une équipe éditoriale passe de cinq articles par semaine à vingt, le site ajoute davantage d’URL, de liens internes, d’archives et de pagination que les robots d’exploration devront parcourir. Les robots d’indexation ne savent pas nécessairement, ni ne s’en soucient, que l’IA a contribué à la production du contenu. Ils perçoivent simplement une bibliothèque plus vaste et mise à jour plus fréquemment, et reviennent l’explorer.
Un million de requêtes vers des pages mises en cache impose une charge très différente à un serveur par rapport à un million de requêtes vers des URL dynamiques. L’analyse réalisée par Kinsta sur plus de 10 milliards de requêtes montre que les robots d’indexation accèdent de manière répétée aux résultats de recherche, aux pages de produits filtrées, aux liens « Ajouter au panier » et à des points de terminaison similaires. Chaque requête peut contourner le cache et générer une charge de travail pour PHP et la base de données.
Cela met le trafic automatisé en concurrence avec les propres fonctionnalités d’IA de votre site. Une requête de chatbot et un robot d’indexation accédant à un filtre de produit dynamique peuvent avoir des objectifs totalement différents, mais tous deux peuvent occuper des threads PHP. Si les robots d’indexation consomment une part considérable de la capacité disponible du site, les requêtes légitimes provenant des chatbots, des recherches et des recommandations disposent de moins de ressources pour s’exécuter.
Un site doté d’IA a besoin d’une marge suffisante pour les requêtes que ses visiteurs effectuent réellement. Les contrôles des robots permettent de préserver cette marge. Googlebot a toujours besoin d’accéder aux pages que vous souhaitez indexer, et vous pouvez décider que certains robots d’exploration d’IA méritent d’être autorisés. Le trafic à réduire correspond aux activités répétitives sur des points de terminaison dynamiques qui n’apportent aucune valeur ajoutée mais mobilisent néanmoins des threads PHP.
La protection anti-robots de Kinsta offre des contrôles au niveau de l’environnement pour autoriser, vérifier ou bloquer le trafic automatisé, y compris une option distincte pour les robots d’exploration basés sur l’IA. Ses analyses montrent comment les requêtes sont classées et traitées.
Les analyses relatives aux robots ne constituent qu’une partie du tableau. Comparez-les aux traces APM, aux rapports de contournement du cache et aux principales adresses IP des clients dans MyKinsta. Cela vous permettra de déterminer plus facilement si la charge provient de vos propres fonctionnalités d’IA ou de robots d’indexation externes, et si ces requêtes de robots justifient les ressources qu’elles consomment.
Ce qu’il faut vérifier avant d’ajouter une fonctionnalité d’IA à un site WordPress
Avant de mettre en production une fonctionnalité d’IA, testez son comportement sur votre infrastructure existante. Commencez par vous poser ces cinq questions.
1. À quel moment du cycle de requête ce plugin s’exécute-t-il ?
Le chemin de la requête est ici déterminant. Les outils de rédaction et d’édition effectuent généralement leur travail au sein de wp-admin. Les outils destinés aux clients partagent la capacité PHP avec le reste du frontend, y compris les pages de commande et de compte. Un agent peut contourner ces deux chemins et accéder au système via l’API. Vérifiez le flux de requêtes de l’extension avant d’estimer la capacité dont elle a besoin.
2. Que peut mettre en cache le plugin ?
Déterminez précisément ce que l’extension exclut de la mise en cache. La réponse elle-même devra peut-être rester dynamique, car elle varie en fonction de la demande ou de l’utilisateur, mais les données associées, telles que l’état de la conversation, les résultats de recherche ou les recommandations, peuvent être réutilisables pendant un court laps de temps. Un point de terminaison API dédié et non mis en cache est bien moins coûteux qu’une extension qui rend l’intégralité de la page produit dynamique.
3. Que se passe-t-il lorsque l’API externe est lente ?
Testez également un appel ayant échoué, et pas seulement un appel lent. Interrompez temporairement la connexion en environnement de staging et observez à quel moment la requête prend fin. Certaines extensions effectuent immédiatement une nouvelle tentative ; d’autres restent ouverts jusqu’à ce que PHP les interrompe. Si plusieurs requêtes du chatbot agissent ainsi simultanément, les requêtes de commande et de compte pourraient devoir attendre qu’un thread PHP se libère.
4. Testez d’abord en environnement de staging avec l’outil APM activé
Installez l’extension sur un environnement de staging et activez l’outil APM de Kinsta pendant les tests. Reproduisez des conversations, des recherches ou des workflows de génération de contenu typiques, y compris des activités simultanées le cas échéant. Consultez les onglets Transactions, Externe et Base de données pour déterminer la durée des requêtes et où ce temps est consacré.
5. PHP est-il prêt à supporter cette charge de travail supplémentaire ?
Enregistrez le comportement du site de staging avant de modifier la version de PHP. MyKinsta indique si la limite de threads PHP est déjà atteinte, ainsi que les données relatives au temps de réponse et à l’utilisation de la mémoire. Passez le site de staging à une version actuelle de PHP 8.x, répétez les mêmes workflows et vérifiez que l’extension fonctionne toujours avant d’effectuer la modification en production.
L’environnement de staging ne reproduira pas parfaitement les conditions de production. Il peut néanmoins révéler si l’extension génère trop de requêtes contournant le cache, attend trop longtemps une API externe, exécute des requêtes coûteuses ou laisse trop peu de ressources PHP disponibles pour le reste du site.
Considérez chaque déploiement d’IA comme un changement d’infrastructure
WordPress 7.0 offre aux développeurs un moyen standard de s’intégrer aux fournisseurs d’IA et d’appeler des modèles depuis WordPress. Le serveur doit toutefois toujours traiter ces requêtes une fois la fonctionnalité mise en ligne.
Avant de modifier la configuration de l’hébergement, ouvrez quelques traces APM. La liste des extensions ne vous indiquera pas la charge de travail du site, et le nombre de threads PHP n’expliquera pas pourquoi une requête est lente. Une trace indique si la requête a contourné le cache, le temps de traitement passé par PHP, et si le retard provient de la base de données ou de l’API du modèle. À partir de là, vous pouvez déterminer si l’extension doit être améliorée ou si le site a besoin de plus de capacité.
Une extension IA peut fonctionner parfaitement tout en étant mal adaptée à la capacité actuelle du site. Avant de le déployer sur le site d’un client, exécutez l’APM en environnement de staging et vérifiez la durée des appels API externes, quelles requêtes ne sont pas mises en cache et quelle version de PHP l’environnement utilise. Vérifiez à nouveau ces chiffres après le lancement, une fois que le trafic réel est pris en compte.
Ces quelques vérifications permettent de détecter la pression sur les threads, les dépendances lentes et les comportements de requêtes coûteuses avant qu’ils ne se traduisent par un site lent — ou une discussion difficile avec le client.
Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.
