Un client ne voit qu’une seule page de commande. En coulisses, votre site WordPress peut contacter plusieurs services pour traiter le paiement, vérifier les stocks, calculer les frais de livraison et mettre à jour votre CRM. Les extensions facilitent la mise en place de ces connexions. Cependant, elles ne permettent pas toujours de comprendre clairement ce qui se passe lorsqu’un service ralentit ou cesse de répondre.

À mesure que vous ajoutez des intégrations et des fonctionnalités d’IA, une part croissante du fonctionnement quotidien de votre site repose sur les API. Ces connexions font donc partie intégrante de vos exigences en matière d’hébergement, même si vous considérez votre site comme « simplement WordPress ».

Dans cet article, nous examinerons comment WordPress utilise les API, pourquoi l’hébergement influe sur les performances des intégrations, et comment empêcher une requête lente ou ayant échoué de perturber le reste de votre site. Nous aborderons également les éléments à surveiller et ce que les agences doivent vérifier avant d’ajouter une nouvelle dépendance.

Que signifie utiliser des API pour un site web ?

Lorsqu’un site demande des informations à un autre système ou lui demande d’effectuer une action via son API, il agit alors en tant qu’utilisateur d’API. Cela peut par exemple consister à obtenir un devis de livraison auprès d’un prestataire logistique ou à demander à un service de messagerie électronique d’envoyer une confirmation de commande.

Vous utilisez probablement déjà des API avec l’API REST de WordPress, car celle-ci permet à d’autres programmes de récupérer du contenu ou d’effectuer des actions autorisées sur votre site. L’utilisation d’une API fonctionne dans l’autre sens : WordPress envoie la requête, et un autre service fournit la réponse. Un site web peut effectuer ces deux opérations.

De nombreuses fonctionnalités courantes d’un site web impliquent l’utilisation d’API externes :

  • Paiements : soumettre une transaction à un prestataire de paiement.
  • Stock : vérifier les niveaux de stock dans un système d’entrepôt.
  • Expédition et taxes : récupérer les tarifs en fonction de la localisation du client.
  • Capture de prospects : envoyer les informations issues des formulaires remplis par les utilisateurs vers un CRM.
  • E-mail : demander un e-mail de réinitialisation de mot de passe ou de confirmation d’achat.
  • Recherche et IA : récupérer des résultats de recherche, générer du texte ou analyser du contenu.

Le moment et le lieu où ces requêtes ont lieu ont leur importance. Un devis d’expédition doit parfois être reçu avant qu’un client puisse finaliser sa commande. Une mise à jour du CRM peut souvent attendre que le site ait confirmé l’envoi du formulaire.

Certains appels s’exécutent directement dans le navigateur du visiteur. D’autres s’exécutent via WordPress sur votre serveur, soit lors de la requête d’un visiteur, soit via une tâche planifiée en arrière-plan. Des services externes peuvent également envoyer des webhooks pour notifier votre site d’un évènement, tel qu’un paiement effectué, ce qui peut déclencher d’autres appels d’API.

WordPress coordonne les services dont dépend votre site

Lorsque vous effectuez la majeure partie de votre travail dans le tableau de bord WordPress, il est facile de penser que l’ensemble du site s’y exécute. Or, une extension peut vérifier les détails de paiement auprès d’un service et l’état d’un abonnement auprès d’un autre avant d’autoriser une connexion. Vous gérez ces fonctionnalités dans WordPress, même lorsque des services externes prennent en charge une partie du travail.

WordPress coordonne ce travail. Il collecte les informations, les transmet au service approprié et utilise la réponse pour décider de la suite des opérations. Observez vers où le site envoie ses requêtes, et vous découvrirez souvent des liens avec l’ensemble des activités du client :

  • Commerce : encaissement des paiements, renouvèlement des abonnements, obtention de devis d’expédition et vérification des stocks.
  • Marketing : ajout de contacts à des listes de diffusion, transmission de prospects au CRM, suivi des visites et saisie des informations relatives aux prospects.
  • Contenu : votre site peut utiliser un service de recherche distinct, envoyer des pages en traduction ou s’appuyer sur une autre plateforme pour redimensionner les images et héberger des vidéos.
  • Identité : un visiteur se connecte avec un compte provenant d’un autre service, ou WordPress vérifie un système d’adhésion externe avant d’accorder l’accès.
  • IA : un chatbot fait appel à un modèle pour répondre à une question. D’autres outils suggèrent des produits, signalent les soumissions inappropriées ou rédigent des ébauches de contenu.

Sur un site d’adhésion, WordPress peut gérer les comptes tandis qu’un service de facturation distinct encaisse les paiements d’abonnement. Les deux doivent toutefois rester en contact. Lorsqu’un paiement est validé ou échoue, WordPress doit savoir si le visiteur doit conserver son accès. Il est important de noter que cet échange a lieu tout au long de la durée de l’abonnement et pas seulement lors de l’inscription.

Pour une agence, cela modifie la définition même d’un « site fonctionnel ». Les pages peuvent toujours se charger rapidement, mais une synchronisation défaillante peut priver les utilisateurs d’accès ou transmettre des informations obsolètes sur les stocks à la boutique en ligne. Malheureusement, vérifier que WordPress fonctionne correctement ne reflète qu’une partie de la réalité.

Vous devez également savoir sur quels services le site s’appuie, quel est le rôle de chaque connexion et ce qui se passe lorsque la réponse attendue ne parvient jamais.

L’IA ajoute une couche supplémentaire d’activité API

L’ajout d’une fonctionnalité d’IA implique souvent de connecter votre site à un autre service externe. Un assistant d’assistance envoie des questions à une API de modèle. Un outil de traduction soumet du contenu et récupère la version traduite. Une fonctionnalité de recherche par IA peut contacter à la fois un service de recherche et un modèle avant de renvoyer une réponse.

WordPress gère déjà des connexions externes pour de nombreuses tâches quotidiennes. Mais l’IA ajoute des fonctionnalités qui se comportent différemment. Générer une réponse peut prendre plus de temps que de récupérer un tarif d’expédition, et une seule question peut déclencher plusieurs requêtes. Un assistant de support, par exemple, peut récupérer une commande, consulter une politique de retour et transmettre ces informations à un modèle afin qu’il prépare sa réponse.

Les flux de travail automatisés peuvent également générer des pics d’activité. Si un outil traite des dizaines de descriptions d’articles à la fois, le site peut effectuer bien plus de requêtes simultanées que lors d’une navigation courante. Chaque fournisseur a ses propres limites quant au volume de travail qu’il accepte.

Cela illustre en réalité la tendance plus large vers un développement basé sur les API, qui s’opère déjà discrètement. Le rapport « State of the API 2025 » de Postman, établi à partir de plus de 5700 répondants, a révélé que 82 % des organisations avaient adopté, à un certain niveau, une approche de développement « API-first ».

Pour votre site, la question pratique est donc la suivante : que se passe-t-il pendant l’exécution de ces appels ? WordPress attend-il chaque réponse ? Le site peut-il continuer à fonctionner en arrière-plan ? Les tâches quotidiennes du site, telles que le paiement ou la connexion, peuvent-elles toujours s’effectuer pendant que la fonctionnalité d’IA est occupée ?

Pourquoi l’hébergement a une incidence sur les intégrations

Une API peut s’exécuter sur l’infrastructure d’un tiers, mais votre site doit tout de même communiquer avec elle. WordPress prépare la requête, l’envoie, traite la réponse et peut enregistrer le résultat dans votre base de données. Et tout au long de ce processus, votre environnement d’hébergement prend en charge ces opérations.

Prenons l’exemple d’un formulaire qui envoie un prospect vers un CRM avant d’afficher un message de confirmation :

  1. Un visiteur envoie le formulaire, et le serveur attribue la requête à un thread PHP.
  2. L’extension du formulaire vérifie les informations envoyées et envoie une requête API au CRM.
  3. Si l’appel est synchrone, le thread PHP attend la réponse du CRM.
  4. L’extension traite le résultat, puis WordPress renvoie un message de validation ou d’erreur.

Si le CRM met plusieurs secondes à répondre, ce thread PHP reste occupé. Il n’utilise pas nécessairement beaucoup de ressources CPU pendant l’attente, mais il ne peut pas traiter une autre requête.

Comme l’explique la documentation PHP de Kinsta, chaque thread PHP traite une requête à la fois. Lorsque tous les threads disponibles sont occupés, les requêtes supplémentaires nécessitant PHP doivent patienter. Plusieurs appels CRM lents peuvent donc affecter des activités sans rapport, telles que la création de comptes par les clients ou l’envoi des informations de paiement.

C’est l’une des raisons pour lesquelles le nombre de visiteurs mensuels ne reflète pas entièrement les besoins d’hébergement d’un site. Mais les threads PHP ne constituent qu’une partie du tableau. La configuration de votre hébergement influe également sur la manière dont le site prépare les requêtes, exécute les tâches planifiées et identifie les problèmes :

  • Processeur et mémoire : WordPress a besoin de ces deux ressources pour assembler les données qu’il envoie, lire la réponse et mettre à jour vos enregistrements.
  • Planification : une planification côté serveur vous permet d’exécuter des intégrations à des heures définies, même lorsque personne ne visite le site.
  • Journaux et surveillance : lorsqu’un formulaire met dix secondes à être envoyé, ces outils vous aident à déterminer si un appel externe est à l’origine de ce délai.
  • Capacité de traitement pendant les pics d’activité : plusieurs intégrations peuvent s’exécuter simultanément avec le processus de paiement, la connexion et d’autres activités. Les ressources disponibles déterminent la charge de travail que le site peut gérer en même temps.

En exécutant une mise à jour du CRM en arrière-plan, vous évitez de gêner le visiteur. La mise à jour doit toutefois s’exécuter, et votre équipe doit être informée en cas d’échec.

Votre hébergeur n’a aucun contrôle sur la réponse du CRM. Il vous fournit simplement la capacité d’exécuter votre intégration et les outils permettant de suivre son déroulement.

Que se passe-t-il en cas d’échec d’une API ?

Un problème d’API ne rend pas toujours votre site Web indisponible. Parfois, la page d’accueil se charge normalement, tandis que les clients ne parviennent pas à obtenir un devis d’expédition ou que les nouveaux prospects n’atteignent jamais votre CRM. Du point de vue du visiteur, le site ne fonctionne pas là où il en a besoin.

Et la nature du dysfonctionnement dépend de ce que le service gère réellement :

  • Expédition : votre client doit attendre que les options de livraison s’affichent, car le service d’expédition met trop de temps à fournir un devis.
  • Paiements : un paiement est effectué, mais la confirmation n’atteint jamais WordPress. Une nouvelle tentative sans vérification préalable peut entrainer une double facturation au client.
  • CRM : un visiteur remplit votre formulaire, mais le CRM rejette la soumission. Vous disposez de la piste dans WordPress, tandis que votre équipe commerciale n’en a aucune trace.
  • IA : votre site atteint la limite d’utilisation fixée par le fournisseur, et la fonctionnalité d’IA cesse d’accepter les requêtes.
  • Stock : les mises à jour de stock ne sont plus transmises, de sorte que les clients ne savent plus ce qui est réellement disponible.
  • Webhooks : le fournisseur envoie une notification deux fois, et votre intégration la traite à chaque fois, ce qui peut entrainer la duplication d’une mise à jour de commande ou d’un e-mail.

Certaines de ces défaillances génèrent des erreurs évidentes. D’autres ressemblent à des requêtes réussies jusqu’à ce que vous examiniez le résultat.

Un délai d’expiration vous laisse avec une question sans réponse : l’action a-t-elle abouti ? WordPress cesse d’attendre une réponse, mais l’autre service pourrait tout de même poursuivre le traitement de la requête. Avant de réessayer un paiement ou une mise à jour d’enregistrement, vérifiez ce qui se passe réellement de l’autre côté.

Ensuite, déterminez comment votre site doit réagir dans chaque cas. Une mise à jour du CRM peut généralement attendre une nouvelle tentative. Mais une erreur de paiement, par exemple, nécessite un message utile. De même, un paiement incertain peut nécessiter qu’une personne vérifie son statut.

Prévoyez un plan pour les appels API lents ou ayant échoué

Un client ne devrait pas avoir à attendre que votre plateforme de messagerie l’ajoute à une liste de diffusion avant de voir la confirmation de sa commande. Or, cela peut se produire si une extension tente de tout finaliser lors du paiement. Passez en revue les appels effectués par votre site et déterminez ceux qui nécessitent une réponse immédiate. Vous pouvez souvent faire en sorte que les autres n’interfèrent pas avec l’expérience client.

Voici quelques points à vérifier au fur et à mesure :

  • Cela doit-il se faire immédiatement ? Envoyez les mises à jour du CRM et les tâches de reporting dans une file d’attente en arrière-plan lorsque cela est possible. Assurez-vous de pouvoir vérifier si elles aboutissent. Déplacer une tâche en arrière-plan n’est pas d’une grande utilité si elle échoue discrètement sans que personne ne s’en aperçoive.
  • Combien de temps le site attend-il ? Vérifiez les réglages de délai d’expiration dans vos extensions et votre code personnalisé. Les valeurs par défaut ne sont pas toujours adaptées à la fonctionnalité concernée. Une personne qui attend des suggestions de recherche a moins de patience qu’une importation planifiée s’exécutant pendant la nuit.
  • Limitez le nombre de tentatives. Une extension peut continuer à envoyer la même requête bien après que cela n’ait plus de sens ; examinez donc l’erreur renvoyée. Si le service est occupé ou temporairement indisponible, espacez les tentatives, en attendant plus longtemps à chaque fois et en respectant tout délai spécifié par le fournisseur. Fixez une limite maximale afin que la tâche cesse finalement de réessayer.
  • Un délai d’expiration de paiement vous impose certaines vérifications à effectuer. Le prestataire peut facturer le client même si la confirmation n’est pas encore parvenue à WordPress ; vous devez donc vérifier cette transaction avant de procéder à un nouveau prélèvement. Si l’API prend en charge les clés idempotentes, utilisez la clé d’origine à chaque fois que vous réessayez la même action. Cependant, ne négligez pas non plus les webhooks en double. Conservez une trace de chaque identifiant d’évènement afin de pouvoir vérifier vos enregistrements lorsqu’une notification vous parvient.
  • Déterminez l’ancienneté maximale admissible des données. Les recommandations n’ont pas nécessairement besoin d’être mises à jour à chaque fois qu’un utilisateur ouvre une page. Ce n’est pas forcément le cas pour les stocks. Définissez la durée d’expiration de votre cache en fonction de la fréquence à laquelle les informations changent et de la manière dont vous les utilisez.
  • Prévoyez ce qu’il faut afficher en cas d’échec d’un appel. Vous pouvez utiliser une liste de produits standard si le service de recommandations ne répond pas. En cas de paiement, vous devez informer le client si vous ne pouvez pas confirmer le résultat et lui indiquer comment vérifier sa commande. N’affichez un message de réussite que lorsque vous savez que l’action est terminée.
  • Vérifiez la manière dont vous gérez les identifiants. Conservez les clés API confidentielles sur le serveur, en leur attribuant uniquement les autorisations nécessaires à l’intégration. Elles ne doivent en aucun cas être stockées dans le code du navigateur ou dans les journaux, et utilisez des identifiants différents pour les tests.

Testez les modifications en environnement de staging en faisant en sorte qu’un appel API prenne plus de temps que d’habitude ou aboutisse à un délai d’expiration. Pendant ce temps, essayez de passer commande ou de vous connecter pour voir si ce retard affecte d’autres processus. Envoyez également deux fois le même webhook et vérifiez que votre site n’y réagit qu’une seule fois.

Suivez la transaction jusqu’à sa destination. Vous devriez trouver une seule commande, et non deux, et le prospect devrait apparaitre dans votre CRM. Lorsqu’une tâche en arrière-plan échoue, elle doit laisser une trace utile afin que votre équipe puisse la retracer, identifier ce qui n’a pas fonctionné et la relancer sans dupliquer le travail.

Une capacité serveur accrue peut s’avérer utile lorsque la charge de travail le justifie. Vérifiez toutefois au préalable si des appels superflus, de longs délais d’attente ou des tentatives répétées ne mobilisent pas la capacité dont vous disposez déjà.

Surveiller le parcours complet de la requête

Lorsqu’un client signale que le processus de paiement semble lent, vous devez déterminer où passe le temps. WordPress peut le consacrer à l’exécution du code d’une extension, à l’interrogation de la base de données ou à l’attente d’un prestataire de livraison. Chaque cause nécessite une solution différente.

Vous pouvez commencer par reproduire l’action concernée et vérifier les requêtes qu’elle déclenche. Vous devrez notamment examiner les éléments suivants :

  • Les temps de réponse : quels services mettent le plus de temps à répondre ?
  • Erreurs et délais d’expiration : quels appels échouent, et que renvoie le prestataire ?
  • Limites de débit et nouvelles tentatives : l’intégration connectée continue-t-elle d’envoyer des requêtes après que le prestataire lui a demandé d’attendre ?
  • Tâches en arrière-plan : certaines tâches planifiées sont-elles effectivement menées à bien, ou échouent-elles ?
  • Webhooks : le site reçoit-il et traite-t-il correctement chaque évènement ?
  • Origine de la requête : quelle extension, quelle tâche planifiée ou quelle action du visiteur déclenche l’appel ?

Les outils de développement du navigateur affichent les requêtes effectuées depuis le navigateur du visiteur. Ils peuvent également révéler un long temps d’attente de la part de votre serveur, mais ils n’expliquent pas tout ce que WordPress effectue pendant cette attente. Pour cela, vous avez besoin d’une surveillance côté serveur.

Kinsta APM vous aide à mener votre enquête en enregistrant l’activité PHP, les requêtes de base de données et les appels HTTP externes. Son onglet Externe met en évidence les requêtes côté serveur lentes, et les traces de transaction vous aident à voir où ces appels s’inscrivent dans le fonctionnement de WordPress.

Kinsta APM affichant la durée de deux appels vers l’API Gemini.
Kinsta APM affichant la durée de deux appels vers l’API Gemini.

Comparez ces durées avec les journaux de votre application et les enregistrements de tâches pour obtenir une vue d’ensemble. L’APM indique à quel endroit une requête ralentit. Les enregistrements propres à l’intégration devraient montrer si les données parviennent à leur destination et si un webhook modifie l’ordre.

Après avoir remplacé la connexion que vous utilisez, répétez le même processus dans des conditions similaires. Vérifiez à la fois le temps de réponse et le résultat. Une page de confirmation plus rapide n’est utile que si le traitement en arrière-plan aboutit.

Ne vous limitez pas à la liste des plugins

Une liste d’extensions ne vous dira pas pourquoi une commande n’est jamais traitée ni pourquoi un nouveau prospect disparait entre le formulaire et le CRM. Ainsi, lorsque vous effectuez des audits de site ou toute autre maintenance de routine, faites également le point sur les services qui se cachent derrière ces extensions.

Pour chaque site client, posez-vous les questions suivantes :

  • Quelles tâches WordPress confie-t-il à des services externes ?
  • Quels appels retardent le visiteur, et quelles tâches peuvent attendre plus tard ?
  • Si un service ralentit ou devient indisponible, que se passe-t-il sur le site ?
  • Combien de temps l’intégration attend-elle avant d’abandonner une requête ?
  • Tente-t-elle automatiquement une nouvelle fois ? Cela pourrait-il entrainer une deuxième facturation, une deuxième entrée dans le système ou un deuxième e-mail ?
  • Quelles données pouvez-vous réutiliser, et quand doivent-elles être actualisées ?
  • Où sont stockées les identifiants ? Qui peut les récupérer ou les remplacer ?
  • Où pouvez-vous vérifier si les tâches planifiées et les webhooks ont bien été exécutés ?
  • Si une requête prend trop de temps, pouvez-vous identifier l’extension ou le processus qui l’envoie ?
  • Vos tests de staging incluent-ils les appels ayant échoué et plusieurs requêtes s’exécutant simultanément ?

Conservez les réponses dans la documentation technique du site, en précisant qui est responsable de chaque connexion.

Les environnements de staging de Kinsta, les ressources PHP configurables, la prise en charge des tâches cron côté serveur, les journaux et l’APM fournissent aux agences les outils nécessaires pour tester et analyser ces flux de travail. Utilisez-les pour évaluer les besoins de chaque site, puis réexaminez cette évaluation lorsqu’un client ajoute une intégration ou modifie le fonctionnement d’une intégration existante.

La fiabilité de votre site web dépend de celle de ses connexions

« Juste WordPress » peut impliquer un nombre surprenant de relais. Suivez un achat, une inscription ou une recherche du début à la fin, et vous découvrirez peut-être plusieurs services externes en cours de route. Chacun d’entre eux suit son propre rythme et impose ses propres limites, et votre site doit s’adapter lorsqu’un d’entre eux prend du retard ou cesse de répondre.

Vous n’avez pas besoin de remanier le site de fond en comble. Choisissez simplement une tâche sur laquelle vos clients comptent, comme le paiement ou l’inscription, et identifiez où le processus se bloque. Si un service externe ne répond jamais, le client reçoit-il au moins un message utile, ou votre équipe est-elle informée qu’une intervention est nécessaire ? Ce sont là des problèmes que vous pouvez commencer à résoudre dès maintenant.

L’hébergement joue un rôle dans ce processus. Il fournit les ressources dont WordPress a besoin pour traiter les requêtes, ainsi que les outils nécessaires à votre équipe pour analyser les retards. Une conception d’intégration bien pensée permet d’exploiter au mieux ces ressources.

À mesure que votre site prend en charge davantage d’opérations métier, prévoyez les services qui les sous-tendent. Découvrez l’hébergement WordPress infogéré de Kinsta pour bénéficier de l’infrastructure et des outils de développement nécessaires à ce travail.

Carlo Daniele Kinsta

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.