Ajouter comme source préférée sur Google
Un site WordPress peut sembler fonctionner correctement aux yeux des visiteurs, alors même qu’il utilise des extensions datant de plusieurs années, qu’il supporte une charge inutile sur la base de données ou qu’il cache des problèmes de compatibilité qui n’apparaissent que dans des conditions spécifiques.
C’est ce que nous avons constaté lorsque nous avons utilisé Claude Code pour analyser une boutique WooCommerce vieille de trois ans.
Le site fonctionnait : les produits s’affichaient dans la boutique, les clients pouvaient parcourir le catalogue et le thème existant gérait la mise en page. Mais un premier audit a révélé des dépendances obsolètes, une extension qui saturait les journaux d’erreurs, une mise à jour de la base de données WooCommerce en attente et une erreur fatale PHP dans l’intégration d’Elementor au thème.
Nous souhaitions voir jusqu’où l’IA pouvait aller dans la modernisation du site sans le reconstruire ni perturber ses fonctionnalités existantes.
À l’aide de l’environnement de staging de Kinsta, de Visual Studio Code via SSH et de Claude Code, nous avons examiné les problèmes, supprimé les activités superflues des extensions, mis à jour le thème et rafraichi l’apparence de la boutique en ligne.
Voici comment le processus s’est déroulé, ce qui a changé et ce que les développeurs peuvent en retenir pour la maintenance d’installations WordPress plus anciennes.
Partir d’une boutique WordPress existante
Pour cette expérience, nous avons utilisé une boutique WordPress de démonstration créée il y a plusieurs années pour vendre des produits de beauté et de soins capillaires.
La boutique utilise WooCommerce avec Astra, Elementor, CartFlows et plusieurs autres extensions qui gèrent tout, de la présentation des produits aux formulaires de contact en passant par le processus de commande.
Il s’agit d’une situation courante pour les agences chargées de la maintenance de sites WordPress bien établis. Au fil du temps, les extensions s’accumulent, le design d’origine semble dépassé et les mises à jour deviennent plus difficiles, car la modification d’un composant peut en affecter un autre.
Nous ne souhaitions ni reconstruire le site ni remplacer ses fonctionnalités e-commerce existantes. Notre objectif était de déterminer ce que nous pouvions améliorer et d’apporter des modifications de manière progressive.
Au début de l’expérience, l’installation de staging présentait la configuration suivante :
| Composant | Version ou état |
| WordPress | 7.1.4 |
| PHP | 8.2.35 |
| Astra | 4.1.5 |
| Elementor | 3.18.3 |
| WooCommerce | 8.5.5 |
| CartFlows | 2.1.5 |
| Extensions actives | 15, dont 14 disposent de mises à jour |
| Code personnalisé du thème ou de l’extension | Aucun thème enfant ni extension personnalisée n’ont été détectés |
L’absence de code personnalisé était un élément important. Il ne s’agissait pas d’un projet où nous pouvions confier à Claude une classe PHP héritée et lui demander de refactoriser l’implémentation. La majeure partie du comportement du site provenait d’extensions tierces et de leur configuration.
Cela signifiait que la modernisation nécessitait de comprendre les dépendances, de vérifier la compatibilité et de déterminer quels composants nous pouvions modifier sans affecter le reste du site.
Utilisation de Claude Code pour auditer le site web
Nous avons commencé par nous connecter à l’environnement de staging Kinsta via SSH depuis Visual Studio Code. Nous avons également installé l’extension Claude Code dans VS Code et nous nous sommes connectés, ce qui a permis à Claude d’inspecter les fichiers WordPress, d’exécuter des commandes WP-CLI et d’analyser directement l’installation.
Avant d’apporter des modifications, nous avons créé une sauvegarde de l’environnement de staging et enregistré les réglages existants du site, les réponses des pages et les journaux d’erreurs afin d’établir une base de référence.
Une fois connecté, Claude Code a pu inspecter l’installation WordPress, examiner les fichiers du thème et des extensions, et exécuter des commandes au sein de l’environnement de staging.
Au lieu de demander à Claude de mettre à jour le site immédiatement, nous avons commencé par un audit en lecture seule :
Inspecter l’installation WordPress et identifier les dépendances obsolètes, le code personnalisé, les problèmes de compatibilité, les erreurs récurrentes et les opportunités de modernisation progressive. Fournir des preuves à l’appui de chaque constat et distinguer les problèmes confirmés des risques potentiels. Ne modifiez pas les fichiers, ne mettez pas à jour les extensions et ne modifiez pas la base de données.
Cela a permis de dresser un inventaire de l’installation, mais les conclusions les plus intéressantes sont issues de l’examen des journaux et de la base de données.
Ce que l’audit a révélé
Claude a identifié plusieurs problèmes de maintenance qui n’étaient pas évidents à la simple navigation sur la vitrine en ligne.
| Constat | Preuves |
| Messages répétés dans le journal des erreurs | Starter Templates, une extension permettant d’importer des thèmes WordPress prêts à l’emploi, a généré à plusieurs reprises des messages dans le journal d’erreurs PHP lors de nos requêtes de test. |
| JavaScript inutile côté client | Starter Templates a chargé un script d’aperçu de modèle sur les pages publiques. |
| Quantité excessive d’options chargées automatiquement | Environ 2,9 Mo d’options ont été chargées automatiquement, dont deux options relatives aux données de documentation représentaient la majeure partie du total. |
| Maintenance WooCommerce en attente | La version de la base de données WooCommerce stockée était la 7.7.0, alors que la version de l’extension installée était la 8.5.5. |
| Tâches en arrière-plan ayant échoué | CartFlows a enregistré 122 échecs lors d’une action de mise à jour de la base de connaissances. |
| Dépendances obsolètes | Plusieurs extensions ainsi que le thème Astra avaient plusieurs versions de retard par rapport aux mises à jour disponibles. |
Ces constatations nous ont ouvert plusieurs pistes possibles. Nous aurions pu tout mettre à jour, mais cela aurait rendu difficile l’identification de la modification à l’origine du problème. Cela aurait également accru le risque d’affecter le processus de commande, CartFlows ou le contenu Elementor.
Nous avons donc choisi un problème mineur que nous pouvions isoler et évaluer.
Suppression des activités superflues des plugins
Le premier problème concernait Starter Templates, une extension couramment utilisée pour importer des designs WordPress prédéfinis.
Sur cette installation, l’extension avait déjà rempli sa fonction initiale. La boutique en ligne était créée, et l’importateur n’était plus nécessaire pour afficher ses pages existantes.
Cependant, la version installée continuait d’exécuter du code qui écrivait dans le journal d’erreurs PHP. Claude a remonté la piste des messages jusqu’à un appel dans :
wp-content/plugins/astra-sites/inc/lib/class-astra-sites-zip-ai.phpL’instruction concernée était :
error_log( $zip_ai_path );L’enquête a révélé que ce même message représentait l’intégralité des 281 lignes de cinq journaux d’erreurs échantillonnés.
L’extension mettait également en file d’attente un fichier JavaScript de 6,5 Ko utilisé par sa fonctionnalité de prévisualisation des modèles, même sur les pages de boutique classiques.
Aucun de ces problèmes n’était catastrophique. Cependant, la répétition de ces messages rendait les fichiers journaux d’erreurs moins utiles, tandis que le script côté client ne semblait servir aucun objectif apparent pour les visiteurs.
Choisir entre la mise à jour et la désactivation
Une version plus récente de Starter Templates avait supprimé l’instruction de journalisation ; une mise à jour aurait donc pu résoudre cette partie du problème.
Un examen plus approfondi a révélé que la nouvelle version chargeait toujours le script de prévisualisation. La désactivation de l’extension permettrait de supprimer les deux. Avant d’effectuer cette modification, Claude a vérifié si d’autres extensions ou le thème actif dépendaient de Starter Templates lors de l’exécution. Il n’a constaté aucune dépendance nécessaire à l’affichage de la vitrine existante.
Un compromis : la désactivation supprimerait la bibliothèque « Starter Templates » d’Elementor et de l’éditeur de blocs. Cela avait de l’importance si les éditeurs utilisaient encore la bibliothèque pour créer de nouvelles sections, même si les pages existantes continueraient de fonctionner.
Après avoir évalué cet impact, nous avons désactivé les « Starter Templates » sur l’environnement de staging via MyKinsta > Sites > Extensions et thèmes.
Les résultats
Nous avons comparé l’environnement de test avant et après la désactivation.
| Vérifié | Avant | Après |
| Nouvelles entrées dans le journal d’erreurs lors de 10 requêtes non mises en cache | 10 | 0 |
| Script d’aperçu des modèles de démarrage | Chargé sur 10 des 11 pages testées | N’est plus chargé |
| Sortie inattendue dans WP-CLI | Présent | Disparu |
| Statuts de réponse de Storefront | Référence établie | Inchangé |
| Affichage du contenu Elementor | Référence établie | Inchangé |
Les commandes d’éditeur spécifiques à l’extension, auxquelles nous nous attendions, ont également disparu. Cela nous a permis d’obtenir notre première amélioration vérifiée sans toucher aux données produit de la boutique en ligne, à la configuration du paiement ni au contenu existant des pages.
Cela a également démontré pourquoi cet audit était important. La solution ne consistait pas à écrire davantage de code, mais à identifier un composant dont le site n’avait plus besoin et à supprimer son activité superflue.
Correction d’une erreur de compatibilité PHP via une mise à jour du thème
Au cours de l’enquête, Claude a découvert un élément plus important. Une requête anonyme adressée au point de terminaison des réglages globaux d’Elementor a renvoyé une erreur HTTP 500 :
/wp-json/elementor/v1/globalsLe journal PHP indiquait le code de compatibilité Elementor du thème Astra :
astra/inc/compatibility/class-astra-elementor.phpL’erreur était la suivante :
Call to undefined method WP_Error::get_data()Le problème provenait d’une hypothèse faite dans l’ancienne implémentation d’Astra. Le point de terminaison Elementor restreint l’accès en fonction des autorisations. Lorsqu’une requête ne dispose pas des autorisations nécessaires, WordPress peut renvoyer un objet WP_Error.
La fonction de compatibilité d’Astra traite alors la réponse via le filtre rest_request_after_callbacks de WordPress. Dans Astra 4.1.5, le code tentait d’appeler la méthode get_data() sans vérifier au préalable que la réponse était bien une réponse REST réussie.
Or, WP_Error ne fournit pas cette méthode ; la requête a donc entrainé une erreur fatale PHP.
Trouver la solution sans modifier manuellement le thème
Nous avons demandé à Claude de comparer la version installée d’Astra avec la version plus récente disponible via WordPress. Il a identifié cette condition de sécurité dans Astra 4.14.1 :
if ( is_wp_error( $response ) || ! $response instanceof \WP_REST_Response ) {
return $response;
}Cette condition vérifie si WordPress a renvoyé une erreur ou un autre type de réponse inattendu avant de tenter d’accéder aux données de la réponse REST.
C’était la correction appropriée pour l’erreur que nous avions reproduite. Nous aurions pu modifier directement le fichier de compatibilité de l’ancien thème, mais cela aurait entrainé une modification locale au sein du code d’un thème tiers. Une future mise à jour du thème aurait pu l’écraser.
Nous avons donc opté pour la mise à jour officielle d’Astra.
La mise à jour a-t-elle corrigé l’erreur ?
Oui, pour les requêtes que nous avons reproduites.
| Test | Astra 4.1.5 | Astra 4.14.1 |
| Requête anonyme sur les variables globales d’Elementor | Erreur HTTP 500 avec erreur fatale PHP | Erreur HTTP 401, rest_forbidden |
| Utilisateur connecté ne disposant pas des droits nécessaires | Erreur fatale PHP | Erreur HTTP 403 |
| Administrateur autorisé | HTTP 200 | HTTP 200 |
| Nouvelles erreurs PHP lors des vérifications REST | Erreur fatale enregistrée | Aucune enregistrée |
La requête anonyme n’a toujours pas pu accéder au point de terminaison, ce qui est normal. La différence est que WordPress a renvoyé l’erreur d’autorisation appropriée au lieu de planter.
Modernisation de la vitrine sans refonte de WooCommerce
Une fois le thème mis à jour, nous nous sommes penchés sur l’apparence du site. Le design d’origine utilisait les accents bleus d’Astra, la typographie Lato, des boutons carrés et une grille de produits WooCommerce basique. Il affichait également des badges de commande WhatsApp surdimensionnés qui ne correspondaient pas à l’identité visuelle du site.
Nous avons demandé à Claude de rafraîchir le design sans modifier le catalogue de produits ni les fonctionnalités commerciales existantes.
Claude a tout d’abord examiné les réglages d’Astra et d’Elementor afin d’identifier les dépendances de couleurs existantes. Nous avons ensuite introduit une nouvelle palette : bordeaux (#7B2342), espresso (#211A16) et ivoire (#F7F2EC), ainsi que la police Cormorant Garamond pour les titres et Jost pour le corps du texte. Ces modifications ont également permis d’introduire des boutons arrondis et d’améliorer le contraste des couleurs. Par exemple, le contraste entre le texte blanc et la couleur d’accent principale est passé de 3,98:1 à 9,72:1, dépassant ainsi les exigences WCAG AAA pour le texte normal.
Claude a créé une petite extension obligatoire dans le répertoire wp-content/mu-plugins/ afin de charger du CSS personnalisé sans modifier les fichiers d’Astra ou de WooCommerce.
Les nouveaux styles ont introduit des fiches produits aux coins arrondis, des proportions d’images cohérentes, des effets de survol subtils, des libellés de catégories plus clairs, des titres de produits en police à empattement et des prix en bordeaux. Le CSS ciblant le balisage existant de la grille de produits de WooCommerce, les modifications se sont appliquées à l’ensemble de la boutique et aux autres fiches produits.
La première tentative n’a pas été entièrement couronnée de succès. Lorsque Claude a repensé le style des boutons de commande WhatsApp, les badges noirs et verts d’origine sont restés visibles à côté du nouveau design.
Après avoir examiné une capture d’écran, Claude a constaté que le CSS existant de WooCommerce remplaçait sa règle visant à masquer l’image. Il a également découvert que l’extension plaçait le lien WhatsApp entre l’image du produit et les informations sur le produit.
Claude a ajusté les sélecteurs CSS et la mise en page de la fiche produit, en déplaçant le bouton sous les détails du produit et en remplaçant le grand badge par un élément de contrôle plus petit, en forme de pilule.
Application de cette approche à d’autres sites WordPress
Notre expérience portait sur une boutique en ligne plus ancienne, mais la même approche s’applique à d’autres projets de maintenance WordPress.
Pour les développeurs et les agences, la démarche est simple : auditer l’installation existante, hiérarchiser les améliorations spécifiques, préparer des sauvegardes, effectuer les modifications sur l’environnement de staging et tester les fonctionnalités concernées avant de poursuivre.
Les instructions données sont également importantes. Au lieu de demander à un agent IA de moderniser immédiatement l’intégralité d’un site web, commencez par lui demander d’identifier les problèmes avérés, d’examiner les dépendances et de proposer des modifications que vous pourrez tester individuellement.
Avec Kinsta, les environnements de staging, l’accès SSH, la gestion des extensions et des thèmes via MyKinsta, ainsi que les outils de sauvegarde offrent une configuration pratique pour ce flux de travail sans avoir à effectuer d’expérimentations directement sur le site en production.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
