# Intégrations IA dans WordPress : les anti-patterns à bannir

> Appels synchrones au chargement de page, clés API dans le front, prompts non versionnés, absence de repli : les erreurs qui reviennent le plus dans les intégrations IA que nous corrigeons.

- Auteur : Clément Hadrot
- Publié le : 2025-05-23
- Mis à jour le : 2025-05-23
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/anti-patterns-integrations-ia-wordpress/

## L’essentiel

- Un appel IA synchrone au chargement ralentit toute la page
- Une clé API visible côté client est une faille de sécurité immédiate
- Un prompt non versionné rend les régressions impossibles à tracer

Depuis deux ans, nous auditons régulièrement des extensions et des thèmes qui intègrent une fonctionnalité IA, souvent développés dans l'urgence pour répondre à une demande commerciale. Les mêmes erreurs reviennent, projet après projet, avec des conséquences qui vont du simple ralentissement à la faille de sécurité exploitable. Cet article ne traite pas de la sécurité des prompts eux-mêmes, mais de l'architecture technique qui entoure l'appel à un modèle d'IA dans WordPress.

Nous avons choisi quatre anti-patterns, ceux que nous retrouvons le plus souvent, avec pour chacun ce que nous observons, pourquoi c'est un problème réel, et ce qu'il faut faire à la place.

## Anti-pattern 1 : l'appel synchrone au chargement de la page

Ce qu'on voit : un shortcode ou un bloc qui déclenche un appel à une API d'IA directement dans sa fonction de rendu, exécutée à chaque affichage de page, parfois même sans cache. Pourquoi c'est un problème : chaque visiteur attend la réponse du fournisseur d'IA avant de voir la page s'afficher, ce qui ajoute plusieurs centaines de millisecondes, parfois plusieurs secondes, au temps de chargement, et expose le site à une panne totale si le fournisseur répond lentement ou tombe en erreur. Quoi faire à la place : précalculer le contenu généré en tâche de fond via Action Scheduler ou WP-Cron, le stocker en base ou en transient, et ne servir que du contenu déjà prêt au moment du rendu.

## Anti-pattern 2 : la clé API exposée côté client

Ce qu'on voit : une clé API embarquée directement dans un fichier JavaScript enqueue côté front, parfois même visible en clair dans le code source de la page. Pourquoi c'est un problème : n'importe quel visiteur peut extraire la clé et l'utiliser pour ses propres appels, sur votre facturation, sans limite si aucun quota n'est posé côté fournisseur. Quoi faire à la place : tout appel à un fournisseur d'IA doit transiter par une route REST côté serveur, la clé restant stockée côté PHP, jamais transmise au navigateur.

> L'essentiel à retenir : Un appel IA synchrone au chargement ralentit toute la page ; Une clé API visible côté client est une faille de sécurité immédiate ; Un prompt non versionné rend les régressions impossibles à tracer

## Anti-pattern 3 : le prompt non versionné

Ce qu'on voit : un prompt écrit en dur dans une chaîne de caractères PHP, modifié directement en production par qui a accès au code, sans trace de ce qui a changé ni pourquoi. Pourquoi c'est un problème : le jour où la qualité des réponses se dégrade, personne ne peut dire si le prompt a changé, si le modèle a changé, ou si le contenu source a changé. Impossible de revenir en arrière avec certitude. Quoi faire à la place : conserver les prompts dans des fichiers versionnés avec le reste du code, avec un identifiant de version inclus dans les journaux d'appel, pour pouvoir corréler chaque réponse à la version exacte du prompt qui l'a produite.

### Un exemple vécu

Sur un projet client, un prompt de génération de descriptions produit avait été modifié à la main pour corriger un problème ponctuel, sans que personne ne documente le changement. Trois semaines plus tard, une régression de ton signalée par le client nous a fait perdre une demi-journée à comparer des captures d'écran d'anciennes générations, faute de trace exploitable.

## Anti-pattern 4 : l'absence totale de repli

Ce qu'on voit : une fonctionnalité entièrement dépendante d'un appel IA, sans aucun comportement de secours si l'API répond en erreur, en timeout, ou avec un contenu vide. Pourquoi c'est un problème : une panne chez le fournisseur d'IA, même de quelques minutes, devient une panne visible côté site, parfois sur une fonctionnalité critique comme un moteur de recherche ou un formulaire de contact enrichi. Quoi faire à la place : prévoir systématiquement un comportement par défaut, un contenu statique, une réponse générique, ou simplement le masquage discret de la fonctionnalité en cas d'échec de l'appel.

- Aucun appel IA bloquant dans le rendu d'une page publique
- Clé API toujours côté serveur, jamais dans le JavaScript public
- Prompts versionnés avec identifiant tracé dans les journaux
- Comportement de repli défini pour chaque fonctionnalité dépendante d'une IA

> Une intégration IA qui casse le site en cas de panne du fournisseur n'est pas une fonctionnalité, c'est une dette technique déguisée.

## En résumé

Ces quatre anti-patterns partagent un point commun : ils passent inaperçus en développement, sur un poste local avec une connexion rapide et un fournisseur d'IA qui répond bien, et n'explosent qu'en production, sous charge réelle ou lors d'un incident chez le fournisseur. Les corriger en amont coûte peu ; les découvrir après un incident client coûte beaucoup plus cher, en temps comme en confiance.