De nombreux sites WordPress enrichissent leurs pages avec des données d'une API : catalogue, géolocalisation, tarifs, disponibilités. Tant que tout va bien, ça marche. Le problème survient le jour où l'API sature — et un site dont le rendu dépend d'un appel réseau en direct devient aussi fragile que le service dont il dépend.
Le problème : le couplage au moment du rendu
Le schéma fautif est simple. À chaque visite d'une page, WordPress appelle l'API pour récupérer les données à afficher. Si l'API répond en 50 ms, personne ne voit rien. Mais que se passe-t-il quand :
- un pic de trafic — ou un crawl intensif de Google — multiplie les appels ?
- l'API applique une limitation de débit et renvoie des erreurs 429 (Too Many Requests) ?
- l'API est simplement lente, ou en maintenance ?
Dans tous ces cas, les pages qui dépendent de l'API se mettent à échouer, à ralentir, ou à se rendre incomplètes. Et ce, précisément au pire moment : quand le trafic est fort. Le couplage transforme un incident mineur sur l'API en panne visible du site entier.
La règle d'architecture : le rendu d'une page publique ne doit jamais dépendre de la disponibilité, en temps réel, d'un service tiers.
Le piège aggravant : l'appel qui traverse Internet inutilement
Un détail qui aggrave tout : quand le site et l'API sont hébergés au même endroit (deux conteneurs sur le même serveur, par exemple), il est tentant — et fréquent — que WordPress appelle l'API par son URL publique (https://api.exemple.fr). L'appel sort alors sur Internet, repasse par le reverse-proxy, la couche TLS, l'éventuelle limitation de débit… pour joindre un service qui est physiquement à côté.
La correction est immédiate : en interne, appelez l'API par son nom de service réseau interne (par exemple http://mon-api sur le réseau Docker partagé). L'appel ne quitte plus la machine, évite le proxy et la limitation de débit publique, et devient bien plus rapide et fiable.
La solution : un cache local et un mode dégradé
Découpler ne veut pas dire se passer de l'API. Cela veut dire ne plus faire dépendre le rendu de sa disponibilité immédiate. Deux mécanismes complémentaires :
1. Synchroniser à froid, servir à chaud
Plutôt que d'appeler l'API à chaque visite, une tâche planifiée récupère périodiquement les données et les stocke localement (une table dédiée, ou un cache persistant). Les pages publiques lisent uniquement ce magasin local — une lecture instantanée, sans réseau. L'API peut tomber sans qu'aucun visiteur ne le remarque : les pages continuent de se servir à partir de la dernière synchronisation réussie.
2. Prévoir un repli explicite
Pour les données qui doivent tout de même être demandées à la volée, encadrez l'appel :
- Un timeout court pour ne jamais bloquer le rendu si l'API traîne.
- Un repli sur les données locales en cas d'échec, plutôt qu'une erreur affichée à l'utilisateur.
- Surtout : ne jamais laisser un échec d'API produire une 404, une 500 ou un noindex. Une page doit toujours pouvoir se rendre en 200, même dégradée. C'est ce qui protège votre indexation.
Le bénéfice, au-delà de la résilience
Une architecture découplée apporte des gains qui dépassent la simple tolérance aux pannes :
- Vitesse : une lecture locale est incomparablement plus rapide qu'un aller-retour réseau. Le TTFB s'effondre, les Core Web Vitals s'améliorent.
- Prévisibilité : la charge sur l'API devient régulière (les synchronisations planifiées) au lieu d'être proportionnelle au trafic.
- Protection de l'indexation : Google ne rencontre jamais d'erreur serveur due à une saturation d'API, ce qui évite les désindexations accidentelles.
Le principe est général et dépasse WordPress : tout ce qui est nécessaire au rendu d'une page publique doit être disponible localement et instantanément. Les services externes alimentent votre cache en arrière-plan ; ils ne doivent jamais se trouver sur le chemin critique d'une requête utilisateur.