# Choisir ses extensions WordPress : méthode de sélection raisonnée > Date de dernière mise à jour, nombre d'installations actives, notes de support : les critères concrets pour évaluer une extension avant de l'installer sur un site client. - Auteur : Clément Hadrot - Publié le : 2023-01-17 - Mis à jour le : 2023-01-17 - Catégorie : Extensions - URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/choisir-extensions-selection-raisonnee/ ## L’essentiel - Une extension non mise à jour depuis un an est un signal d'alerte - Le nombre d'installations actives ne garantit pas la qualité du code - Toujours tester en environnement de recette avant la production Avec plus de soixante mille extensions disponibles sur le seul répertoire officiel de WordPress.org, sans compter les extensions premium distribuées hors de ce circuit, le choix d'une extension pour répondre à un besoin donné n'a plus rien d'évident. Installer la première extension venue parce qu'elle répond fonctionnellement au besoin immédiat est une pratique risquée : elle néglige la maintenabilité à moyen terme, la sécurité et la performance du site sur la durée. Cet article propose une méthode de sélection concrète, construite à partir des critères qu'on vérifie systématiquement avant de recommander une extension à un client, qu'il s'agisse d'un site vitrine modeste ou d'une plateforme e-commerce à fort trafic. ## Les signaux visibles sur la page WordPress.org Avant même d'installer quoi que ce soit, la fiche de l'extension sur le répertoire officiel donne des indications précieuses : - **Dernière mise à jour** : une extension non mise à jour depuis plus de douze mois est un signal d'alerte sérieux, en particulier si elle interagit avec des versions récentes de WordPress ou de PHP. Une extension abandonnée ne recevra plus de correctif de sécurité. - **Compatibilité affichée** : le champ « Testé jusqu'à la version » indique la dernière version de WordPress sur laquelle l'auteur a validé l'extension. Un écart de plus de deux versions majeures mérite investigation avant installation. - **Nombre d'installations actives** : un indicateur de popularité, mais pas un gage de qualité en soi. Certaines extensions très installées cumulent aussi de nombreux tickets de support non résolus. - **Note moyenne et répartition des avis** : une note globale élevée avec une forte proportion d'avis à une étoile mérite d'être creusée : ces avis négatifs révèlent souvent un problème récurrent non corrigé. - **Tickets de support résolus** : le pourcentage de sujets résolus sur les deux derniers mois donne une idée directe de la réactivité de l'auteur. > L'essentiel à retenir : Une extension non mise à jour depuis un an est un signal d'alerte ; Le nombre d'installations actives ne garantit pas la qualité du code ; Toujours tester en environnement de recette avant la production ## Les signaux invisibles, à vérifier soi-même Les indicateurs affichés sur la fiche ne suffisent pas. Une inspection technique rapide, avant installation en production, révèle des éléments décisifs. ### Inspecter le code sans l'installer ``` # Télécharger le code source sans l'installer sur un site actif wp plugin install nom-extension --version=latest --path=/tmp/inspection # Vérifier la présence de fonctions dépréciées ou de mauvaises pratiques grep -r "eval(" /tmp/inspection/nom-extension/ grep -r "base64_decode" /tmp/inspection/nom-extension/ grep -rn "\$wpdb->query" /tmp/inspection/nom-extension/ | grep -v prepare ``` La présence d'`eval()` ou de `base64_decode()` n'est pas systématiquement malveillante, mais mérite toujours une explication claire avant d'aller plus loin : ces fonctions servent parfois à des mécanismes légitimes d'obfuscation de licence, mais aussi, plus rarement, à dissimuler du code malveillant. Une requête `$wpdb->query` sans passer par `$wpdb->prepare()` est un signal direct de vulnérabilité potentielle à l'injection SQL. ### Mesurer l'impact sur les performances Le plugin officiel Query Monitor, installé temporairement sur un environnement de recette, permet de mesurer concrètement le nombre de requêtes SQL additionnelles et le temps de génération de page ajoutés par une nouvelle extension, avant et après activation. Une extension qui ajoute plus d'une dizaine de requêtes SQL non mises en cache sur chaque chargement de page mérite d'être questionnée, surtout si une alternative plus légère existe pour le même besoin. ## La checklist avant toute installation en production 1. L'extension a-t-elle été mise à jour au cours des douze derniers mois ? 2. Le nombre de tickets de support ouverts et non résolus est-il raisonnable ? 3. Le code source contient-il des pratiques manifestement dangereuses (requêtes SQL non préparées, capacités mal vérifiées) ? 4. L'impact sur le nombre de requêtes SQL et le temps de génération est-il mesuré sur un environnement de recette ? 5. Une alternative plus légère ou plus activement maintenue existe-t-elle pour le même besoin fonctionnel ? 6. L'extension a-t-elle une politique de désinstallation propre (voir notre article dédié à l'uninstall.php) ? > Sur les audits de sites clients qu'on réalise régulièrement, la cause la plus fréquente de ralentissement n'est presque jamais une seule extension manifestement mauvaise, mais l'accumulation de dix ou quinze extensions installées au fil des années pour des besoins ponctuels, jamais retirées une fois leur usage terminé. ## Le cas des extensions premium hors WordPress.org Une extension vendue directement par son éditeur, sans passer par le répertoire officiel, échappe aux contrôles automatisés de sécurité effectués par l'équipe de revue de WordPress.org. La vigilance doit alors porter davantage sur la réputation de l'éditeur, la fréquence documentée des mises à jour (changelog public) et, idéalement, un test en environnement isolé avant tout déploiement en production, notamment via un scanner de sécurité comme celui proposé par certaines extensions de sécurité dédiées. ## En résumé Choisir une extension WordPress engage la maintenabilité du site pour des années, bien au-delà du besoin ponctuel qui motive son installation. La date de dernière mise à jour, la réactivité du support, une inspection rapide du code et une mesure de l'impact réel sur les performances constituent un socle de vérification simple mais trop souvent négligé, en particulier sous la pression d'un délai de livraison serré.