Mise en contexte
Vous êtes designer, et vous travaillez sur un projet client : une boutique en ligne sous WooCommerce, construite avec Elementor.
Le besoin, en langage concret : le client veut qu’un visiteur puisse taper un mot-clé dans une barre de recherche, et voir apparaître immédiatement les produits disponibles qui correspondent à cette requête — sans avoir à recharger la page. Pas de bouton « valider » à cliquer, pas d’écran blanc pendant le chargement : les résultats s’affichent au fur et à mesure de la frappe, avec la photo et le prix de chaque produit.
Pour obtenir ce comportement précis, il est nécessaire d’utiliser un plugin de recherche basé sur Ajax.
Pourquoi Ajax, précisément ? C’est la seule technique qui permette à une page d’aller chercher une information auprès du serveur — ici, la liste des produits correspondant à la recherche — sans recharger la page entière. C’est exactement l’exemple détaillé dans l’Axe 3 du panorama (chapitre 1) : en PHP seul, sans JavaScript, une recherche de produits ne peut pas afficher instantanément ses résultats sans recharger la page ; avec Ajax, ces informations sont récupérées à la volée, en arrière-plan, pendant que le visiteur continue de taper.
Vous ne connaissez pas encore les plugins qui existent pour ça. Plutôt que de chercher vous-même au hasard, vous allez procéder en deux temps : d’abord identifier des candidats sérieux, puis les auditer en profondeur avant de faire un choix.
⚠️ Important : ne jamais se fier à une seule IA
Avant de vous lancer, un principe essentiel, découvert au fil de la construction de cet exercice : une seule IA, même bien promptée, ne suffit jamais pour ce genre de vérification. Il faut systématiquement confronter plusieurs IA entre elles, pour trois raisons précises :
- Le recoupement de sources — une IA peut manquer une information (comme rater une faille de sécurité importante), citer un chiffre approximatif, ou même inventer un détail qu’elle n’a pas vraiment vérifié. Interroger une deuxième, une troisième IA sur la même question permet de vérifier si l’information tient debout ailleurs aussi.
- La mise en challenge — quand deux IA arrivent à des conclusions différentes sur le même sujet, ce désaccord n’est pas un problème : c’est un signal. Il indique précisément où creuser, où l’une des deux (ou les deux) a probablement fait une erreur.
- Ne jamais faire une confiance aveugle à une seule source — même la meilleure IA du moment peut se tromper sur un point précis un jour donné. La sécurité de votre travail ne doit jamais reposer sur la parole d’un seul outil.
Cette méthode a été appliquée à la lettre pour construire cet exercice : 3 tests indépendants, un par IA (Claude, Gemini, ChatGPT), ont été nécessaires avant d’obtenir un résultat cohérent et fiable — vous en retrouverez le détail complet à la fin de ce chapitre.
Phase 1 : identifier les candidats
Comment ce prompt a été construit, et pourquoi
- Forcer une vraie recherche web, pas une réponse de mémoire — l’écosystème des plugins WordPress change constamment ; un plugin très recommandé il y a deux ans peut être aujourd’hui abandonné, ou l’inverse.
- Exiger uniquement des plugins réellement gratuits (pas un simple essai limité) — cohérent avec la contrainte budgétaire fréquente d’un premier projet client, et ça évite de perdre du temps à évaluer des solutions hors budget.
- Exiger la compatibilité Elementor dès cette étape — inutile de garder un candidat qui, de toute façon, ne s’intégrera pas à l’outil utilisé par le client.
- Demander le « slug » WordPress.org (l’identifiant technique visible dans l’URL de la fiche du plugin) — cet identifiant exact sera indispensable à la Phase 2, pour être certain d’auditer le bon plugin et pas un homonyme.
Le prompt — Phase 1
Résultat obtenu lors de nos tests (août 2026)
- FiboSearch — slug :
ajax-search-for-woocommerce - Ajax Search Lite — slug :
ajax-search-lite - Smart WooCommerce Search — slug :
smart-woocommerce-search - YITH WooCommerce Ajax Search — slug :
yith-woocommerce-ajax-search - Instant Search — slug :
instant-search - ProSearch — slug :
modern-product-search-for-woocommerce
Ce résultat peut varier selon l’IA utilisée, ou évoluer avec le temps (nouveaux plugins, plugins abandonnés). Ce qui compte n’est pas de retrouver exactement cette liste, mais de savoir la générer soi-même, à n’importe quel moment.
Phase 2 : auditer les candidats en profondeur
La liste obtenue en Phase 1 n’est qu’un point de départ : elle ne dit rien sur la fiabilité réelle de chaque plugin. Il faut maintenant écrire un second prompt, entièrement différent du premier, dont le rôle n’est plus de trouver des candidats, mais de les auditer un par un sur la sécurité, la légitimité d’usage, et la compatibilité.
Comment ce second prompt a été construit, et pourquoi
Ce prompt n’a pas été écrit d’un coup — il résulte de plusieurs essais successifs, dont certains ont révélé des failles qu’il a fallu corriger une par une. Voici la logique de chaque bloc :
- 1. Interdire la mémoire, forcer la recherche réelle. Une IA peut répondre « de tête » avec des informations datées ou approximatives. Le prompt l’oblige explicitement à aller chercher, à chaque fois, l’information à sa source.
- 2. Exiger une URL et une citation exacte pour chaque faille. Sans cette contrainte, on a vu une IA citer des CVE différents des vraies sources, ou inventer un score CVSS. Demander un lien vérifiable et un titre cité mot pour mot rend l’invention beaucoup plus difficile à masquer.
- 3. Aller chercher le nombre d’installations à la source officielle (wordpress.org), pas une estimation. Ce chiffre sert de repère de confiance : un plugin très installé a été massivement testé par la communauté, donc son dossier de sécurité — qu’il soit chargé ou vide — est plus fiable qu’un plugin à peine utilisé.
- 4. La règle de départage, la pièce la plus importante. Sans elle, on a observé deux IA différentes préférer un plugin peu installé avec un dossier « presque vide » à un plugin massivement installé avec un dossier plus documenté — une erreur de logique, pas un vrai jugement de sécurité. La règle impose : on classe d’abord par nombre d’installations, et on ne rétrograde un plugin que s’il remplit simultanément trois conditions précises (faille grave, exploitable sans compte, non corrigée depuis plus de 30 jours). Ça retire la place à l’improvisation.
- 5. Les 3 passes de vérification, avec auto-déclaration finale. Une première recherche peut être bâclée. La deuxième repasse spécifiquement sur les « aucune faille trouvée » (souvent un manque de recherche, pas une vraie sécurité). La troisième recontrôle le ou les candidats en tête — puisque c’est justement là qu’on est tenté de moins vérifier. Et on demande à l’IA de dire, à la fin, si elle a vraiment fait ce travail — pas comme garantie absolue, mais comme trace explicite.
Le prompt — Phase 2
N’utilise aucune information provenant de ta mémoire d’entraînement. Effectue une recherche web réelle pour chaque plugin, sur chaque critère.
Pour chacun, effectue les recherches suivantes, dans cet ordre de priorité :
1. SÉCURITÉ (critère le plus important) : recherche l’historique de failles de sécurité connues, en croisant au moins deux bases différentes (WPScan et Patchstack). Pour chaque faille retenue, fournis le lien exact (URL) de la page qui la documente, et cite entre guillemets le titre exact de la vulnérabilité tel qu’il apparaît sur cette page. Si tu ne peux pas produire cette URL, indique « non vérifié ». Précise la gravité (CVSS), si la faille était exploitable sans authentification, le délai entre signalement et correctif si disponible (et « non vérifié » si tu ne peux pas l’établir avec certitude), et si le changelog officiel documente clairement la faille.
2. LÉGITIMITÉ : va directement sur la fiche officielle du plugin sur wordpress.org et relève le nombre exact d' »Active installations ».
3. COMPATIBILITÉ : vérifie que chaque plugin fonctionne avec WooCommerce, puis avec Elementor.
RÈGLE DE DÉPARTAGE, à appliquer strictement et de façon identique à tous les plugins, sans exception ni préférence personnelle : classe les plugins par ordre décroissant de leur nombre d’installations actives. Puis, en partant du plus installé, vérifie si l’un de ses défauts de sécurité connus remplit SIMULTANÉMENT ces trois conditions : (a) gravité CVSS supérieure ou égale à 7, ET (b) exploitable sans authentification, ET (c) resté non corrigé plus de 30 jours après sa divulgation publique. Si un plugin remplit ces trois conditions à la fois, rétrograde-le derrière le plugin suivant dans l’ordre des installations qui ne les remplit pas toutes les trois. Un dossier de sécurité « presque vide » sur un plugin peu installé ne doit jamais être considéré comme supérieur à un dossier plus documenté sur un plugin massivement installé, sauf si la règle des trois conditions ci-dessus s’applique.
Cite tes sources (URL) pour chaque affirmation. Si tu n’es pas certain d’une information, dis-le explicitement plutôt que de l’inventer ou de l’estimer.
Présente un tableau classant les 6 plugins selon la règle de départage ci-dessus. Termine par une conclusion claire indiquant lequel tu recommandes en priorité, et lequel tu déconseilles.
Avant de conclure, effectue impérativement 3 passes de vérification distinctes, et indique explicitement à la fin si tu les as bien réalisées.
Note sur le résultat attendu
En août 2026, ce prompt devrait recommander FiboSearch en priorité, avec YITH WooCommerce Ajax Search à surveiller de près (passif de sécurité plus sérieux, bien que corrigé rapidement). C’est le résultat obtenu de façon cohérente sur plusieurs IA testées à cette période.
Mais les plugins évoluent, se corrigent, ou se dégradent avec le temps — une future vulnérabilité grave sur FiboSearch, ou une amélioration technique chez un concurrent, peut légitimement inverser ce classement. Ce qui compte n’est pas de retrouver exactement ce résultat, mais de savoir mener cette même méthode de vérification, à n’importe quel moment, avec n’importe quels plugins.
Exercice
Soumettez la Phase 1 puis la Phase 2 aux trois IA — Claude, Gemini et ChatGPT, comme rappelé dans l’encadré ci-dessus. Comparez les trois résultats obtenus entre eux, puis avec le nôtre.