Exigez un travail défini et un responsable désigné
Avant de chercher, décrivez l’issue pour le visiteur ou le personnel en une phrase. Vérifiez ensuite si WordPress, le thème, les contrôles de l’hébergeur ou une extension existante ne remplissent déjà ce rôle. N’ajoutez pas un deuxième outil simplement pour son interface ou sa liste de fonctionnalités.
Pour chaque extension approuvée, consignez son responsable, où elle est utilisée, ses réglages clés, comptes liés ou clés API, et une condition de retrait. Le responsable examine les notifications et teste les changements. Cela transforme un historique d’installation en un registre de dépendances.
Listez les pages, formulaires, flux d’édition ou processus back-office que l’extension peut modifier.
Évitez les doublons d’analytics, cache, formulaires, pop-ups ou fonctions d’optimisation sauf si cela est documenté.
Révisez les extensions nouvelles et à fort impact après leur mise en production et selon un calendrier de maintenance régulier.
Évaluez les candidates avant activation
Utilisez l’écran Ajouter des extensions (Plugins > Ajouter) et l’annuaire d’extensions WordPress comme points de départ. WordPress affiche l’auteur, la note utilisateur, la date de dernière mise à jour, la compatibilité et un lien vers les détails. Lisez la documentation, les notes de version, les options de support et les informations de confidentialité. Appliquez la même rigueur aux extensions achetées ou téléchargées ailleurs.
Vérifiez que le mainteneur explique les versions de WordPress et PHP prises en charge, ce que l’extension modifie et comment signaler un problème de sécurité. WordPress.org peut retirer une extension du répertoire pour un problème de sécurité, mais cela ne remplace pas votre propre évaluation ou maintenance.
Rejetez une candidate si le core, le thème, l’hébergeur ou une fonctionnalité existante répond déjà au besoin.
Comparez les exigences déclarées avec votre environnement en production, le thème actif et les extensions critiques.
Les notes peuvent révéler des tendances, mais elles ne constituent pas un audit de code.
Cartographiez l’accès, les données et les services externes
Avant approbation, décrivez ce que l’extension modifie, les informations qu’elle collecte ou stocke, où ces informations transitent, qui administre son intégration et ce qui se passe si son service est indisponible ou retiré. Notez aussi les scripts côté navigateur, iframes, webhooks, clés API et comptes de service.
Les recommandations de confidentialité de WordPress demandent aux auteurs d’extensions de fournir un texte suggéré pour la politique de confidentialité lorsque leur extension collecte, utilise, stocke ou transmet des données utilisateur à un tiers. Servez-vous de ce texte pour investiguer l’explication du fournisseur, pas comme une conformité juridique automatique. Pour les paiements, données de santé, données personnelles sensibles ou travaux réglementés, obtenez une revue qualifiée confidentialité, sécurité, paiement et juridique avant la mise en production.
N’utilisez que les rôles, comptes, périmètres (scopes) et clés nécessaires ; supprimez les accès obsolètes lorsque des personnes ou outils changent.
Consignez les catégories de données, les destinataires, les contrôles de conservation et les étapes de suppression.
Testez la compatibilité dans une copie de staging protégée
Le staging est une copie de test séparée utilisée pour vérifier un changement avant la production. Servez-vous-en pour une nouvelle extension ou un changement à fort impact. Protégez-la, évitez autant que possible les données réelles des clients et empêchez l’envoi d’e-mails, paiements ou webhooks en production.
Testez les parcours affectés : pages publiques, formulaires, connexion, publication, recherche et panier/commande lorsque pertinent. Vérifiez ensuite les journaux d’erreurs et Site Health (Santé du site). Site Health affiche les versions des extensions, les créateurs et les paramètres de mise à jour automatique. Le staging ne peut pas reproduire toutes les conditions de production.
Mettez à jour ou introduisez une extension à fort impact à la fois afin que les régressions aient une zone de recherche plus petite.
Testez en tant que visiteur et en tant qu’éditeur ou administrateur qui utilise le flux de travail affecté.
Consignez la version antérieure, le comportement attendu, les erreurs et la décision d’approbation.
Mesurez les performances et adoptez une politique de mise à jour basée sur le risque
Comparez des pages représentatives avant et après en utilisant la même méthode de test. Inspectez le poids de la page, les requêtes réseau, les erreurs navigateur et l’interaction supportée. WordPress recommande de désactiver sélectivement des extensions pour mesurer les performances serveur lorsqu’on suspecte une extension. Ne vous fiez pas uniquement à un écran d’administration ou à un score synthétique.
Google web.dev indique que le JavaScript tiers peut augmenter le travail réseau, retarder le rendu et affecter la confidentialité, la sécurité et le comportement de la page. Auditez les scripts et fournisseurs redondants. WordPress prend en charge les mises à jour automatiques par extension et envoie des notifications, mais les mises à jour planifiées dépendent de WordPress Cron. Vérifiez que les deux fonctionnent. Des mises à jour automatiques contrôlées peuvent convenir aux extensions peu impactantes, bien comprises et accompagnées de sauvegardes et vérifications. Mettez en staging et approuvez explicitement le checkout (paiement), l’authentification, le consentement ou les intégrations personnalisées. Ce sont des choix basés sur le risque, pas des catégories universelles.
Désignez qui lit les avis, évalue les changements de sécurité et approuve les exceptions.
Pour les changements à fort impact, lisez les notes de version et la compatibilité avant de tester.
Consignez pourquoi une mise à jour est différée, son responsable, les sauvegardes et la date de revue.
Sauvegardez, revenez en arrière et retirez avec méthode
Avant une mise à jour ou une suppression susceptible d’affecter le site, confirmez une sauvegarde actuelle, son emplacement, l’autorité de restauration et la première action de rollback. WordPress conseille de sauvegarder avant les mises à jour et indique qu’une sauvegarde peut être restaurée si une mise à niveau provoque des problèmes. Testez la restauration sur une copie sûre lorsque le risque le justifie.
Lorsqu’une extension n’est plus nécessaire, confirmez qu’aucun flux de travail ne dépend d’elle, préservez les enregistrements requis et révoquez les clés ou webhooks connectés. Désactivez ensuite et supprimez via l’écran Extensions. Le nettoyage varie selon l’extension, suivez donc sa documentation et vérifiez le résultat. La désactivation n’est pas une suppression complète : les extensions inactives restent installées jusqu’à leur suppression.
Sachez s’il faut la désactiver, restaurer sa version antérieure, corriger un réglage ou restaurer une sauvegarde complète.
Après rollback, retestez les parcours affectés, les identifiants, le comportement du cache et l’administration.