{"id":85332,"date":"2026-11-12T10:21:49","date_gmt":"2026-11-12T09:21:49","guid":{"rendered":"https:\/\/kinsta.com\/fr\/?p=85332&preview=true&preview_id=85332"},"modified":"2026-11-12T12:50:33","modified_gmt":"2026-11-12T11:50:33","slug":"ia-wordpress-modernisation","status":"publish","type":"post","link":"https:\/\/kinsta.com\/fr\/blog\/ia-wordpress-modernisation\/","title":{"rendered":"L’IA peut-elle moderniser des sites WordPress existants sans les endommager ?"},"content":{"rendered":"

Un site WordPress peut sembler fonctionner correctement aux yeux des visiteurs, alors m\u00eame qu\u2019il utilise des extensions datant de plusieurs ann\u00e9es, qu\u2019il supporte une charge inutile sur la base de donn\u00e9es ou qu\u2019il cache des probl\u00e8mes de compatibilit\u00e9 qui n\u2019apparaissent que dans des conditions sp\u00e9cifiques.<\/p>\n

C\u2019est ce que nous avons constat\u00e9 lorsque nous avons utilis\u00e9 Claude Code<\/a> pour analyser une boutique WooCommerce<\/a> vieille de trois ans.<\/p>\n

Le site fonctionnait : les produits s\u2019affichaient dans la boutique, les clients pouvaient parcourir le catalogue et le th\u00e8me existant g\u00e9rait la mise en page. Mais un premier audit a r\u00e9v\u00e9l\u00e9 des d\u00e9pendances obsol\u00e8tes, une extension qui saturait les journaux d\u2019erreurs, une mise \u00e0 jour de la base de donn\u00e9es WooCommerce en attente et une erreur fatale PHP dans l\u2019int\u00e9gration d\u2019Elementor au th\u00e8me.<\/p>\n

Nous souhaitions voir jusqu\u2019o\u00f9 l\u2019IA pouvait aller dans la modernisation du site sans le reconstruire ni perturber ses fonctionnalit\u00e9s existantes.<\/p>\n

\u00c0 l\u2019aide de l\u2019environnement de staging de Kinsta<\/a>, de Visual Studio Code via SSH<\/a> et de Claude Code, nous avons examin\u00e9 les probl\u00e8mes, supprim\u00e9 les activit\u00e9s superflues des extensions, mis \u00e0 jour le th\u00e8me et rafraichi l\u2019apparence de la boutique en ligne.<\/p>\n

Voici comment le processus s\u2019est d\u00e9roul\u00e9, ce qui a chang\u00e9 et ce que les d\u00e9veloppeurs peuvent en retenir pour la maintenance d\u2019installations WordPress plus anciennes.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Partir d\u2019une boutique WordPress existante<\/h2>\n

Pour cette exp\u00e9rience, nous avons utilis\u00e9 une boutique WordPress de d\u00e9monstration cr\u00e9\u00e9e il y a plusieurs ann\u00e9es pour vendre des produits de beaut\u00e9 et de soins capillaires.<\/p>\n

\"La
La boutique WooCommerce d\u2019origine avant la modernisation assist\u00e9e par l\u2019IA.<\/figcaption><\/figure>\n

La boutique utilise WooCommerce avec Astra, <\/span>Elementor<\/a>, CartFlows et plusieurs autres extensions qui g\u00e8rent tout, de la pr\u00e9sentation des produits aux formulaires de contact en passant par le processus de commande.<\/span><\/p>\n

Il s\u2019agit d\u2019une situation courante pour les agences<\/a> charg\u00e9es de la maintenance de sites WordPress bien \u00e9tablis. Au fil du temps, les extensions s\u2019accumulent, le design d\u2019origine semble d\u00e9pass\u00e9 et les mises \u00e0 jour deviennent plus difficiles, car la modification d\u2019un composant peut en affecter un autre.<\/p>\n

Nous ne souhaitions ni reconstruire le site ni remplacer ses fonctionnalit\u00e9s e-commerce existantes. Notre objectif \u00e9tait de d\u00e9terminer ce que nous pouvions am\u00e9liorer et d\u2019apporter des modifications de mani\u00e8re progressive.<\/p>\n

Au d\u00e9but de l\u2019exp\u00e9rience, l\u2019installation de staging pr\u00e9sentait la configuration suivante :<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Composant<\/strong><\/td>\nVersion ou \u00e9tat<\/strong><\/td>\n<\/tr>\n
WordPress<\/td>\n7.1.4<\/td>\n<\/tr>\n
PHP<\/td>\n8.2.35<\/td>\n<\/tr>\n
Astra<\/td>\n4.1.5<\/td>\n<\/tr>\n
Elementor<\/td>\n3.18.3<\/td>\n<\/tr>\n
WooCommerce<\/td>\n8.5.5<\/td>\n<\/tr>\n
CartFlows<\/td>\n2.1.5<\/td>\n<\/tr>\n
Extensions actives<\/td>\n15, dont 14 disposent de mises \u00e0 jour<\/td>\n<\/tr>\n
Code personnalis\u00e9 du th\u00e8me ou de l’extension<\/td>\nAucun th\u00e8me enfant ni extension personnalis\u00e9e n\u2019ont \u00e9t\u00e9 d\u00e9tect\u00e9s<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

L\u2019absence de code personnalis\u00e9 \u00e9tait un \u00e9l\u00e9ment important. Il ne s\u2019agissait pas d\u2019un projet o\u00f9 nous pouvions confier \u00e0 Claude une classe PHP h\u00e9rit\u00e9e et lui demander de refactoriser l\u2019impl\u00e9mentation. La majeure partie du comportement du site provenait d’extensions tierces et de leur configuration.<\/p>\n

Cela signifiait que la modernisation n\u00e9cessitait de comprendre les d\u00e9pendances, de v\u00e9rifier la compatibilit\u00e9 et de d\u00e9terminer quels composants nous pouvions modifier sans affecter le reste du site.<\/p>\n

Utilisation de Claude Code pour auditer le site web<\/h2>\n

Nous avons commenc\u00e9 par nous connecter \u00e0 l\u2019environnement de staging Kinsta via SSH depuis Visual Studio Code<\/a>. Nous avons \u00e9galement install\u00e9 l\u2019extension Claude Code<\/a> dans VS Code et nous nous sommes connect\u00e9s, ce qui a permis \u00e0 Claude d\u2019inspecter les fichiers WordPress, d\u2019ex\u00e9cuter des commandes WP-CLI<\/a> et d\u2019analyser directement l\u2019installation.<\/p>\n

Avant d\u2019apporter des modifications, nous avons cr\u00e9\u00e9 une sauvegarde de l\u2019environnement de staging<\/a> et enregistr\u00e9 les r\u00e9glages existants du site, les r\u00e9ponses des pages et les journaux d\u2019erreurs afin d\u2019\u00e9tablir une base de r\u00e9f\u00e9rence.<\/p>\n

\"Claude
Claude inspectant les fichiers WP.<\/figcaption><\/figure>\n

Une fois connect\u00e9, Claude Code a pu inspecter l\u2019installation WordPress, examiner les fichiers du th\u00e8me et des extensions, et ex\u00e9cuter des commandes au sein de l\u2019environnement de staging.<\/p>\n

Au lieu de demander \u00e0 Claude de mettre \u00e0 jour le site imm\u00e9diatement, nous avons commenc\u00e9 par un audit en lecture seule :<\/p>\n

Inspecter l\u2019installation WordPress et identifier les d\u00e9pendances obsol\u00e8tes, le code personnalis\u00e9, les probl\u00e8mes de compatibilit\u00e9, les erreurs r\u00e9currentes et les opportunit\u00e9s de modernisation progressive. Fournir des preuves \u00e0 l\u2019appui de chaque constat et distinguer les probl\u00e8mes confirm\u00e9s des risques potentiels. Ne modifiez pas les fichiers, ne mettez pas \u00e0 jour les extensions et ne modifiez pas la base de donn\u00e9es.<\/em><\/p>\n

Cela a permis de dresser un inventaire de l\u2019installation, mais les conclusions les plus int\u00e9ressantes sont issues de l\u2019examen des journaux et de la base de donn\u00e9es.<\/p>\n

\"Rapport
Rapport de Claude apr\u00e8s l\u2019audit du site.<\/figcaption><\/figure>\n

Ce que l\u2019audit a r\u00e9v\u00e9l\u00e9<\/h3>\n

Claude a identifi\u00e9 plusieurs probl\u00e8mes de maintenance qui n\u2019\u00e9taient pas \u00e9vidents \u00e0 la simple navigation sur la vitrine en ligne.<\/p>\n

\n\n\n\n\n\n\n\n\n\n
Constat<\/strong><\/td>\nPreuves<\/strong><\/td>\n<\/tr>\n
Messages r\u00e9p\u00e9t\u00e9s dans le journal des erreurs<\/td>\nStarter Templates<\/a>, une extension permettant d\u2019importer des th\u00e8mes WordPress pr\u00eats \u00e0 l\u2019emploi, a g\u00e9n\u00e9r\u00e9 \u00e0 plusieurs reprises des messages dans le journal d\u2019erreurs PHP lors de nos requ\u00eates de test.<\/td>\n<\/tr>\n
JavaScript inutile c\u00f4t\u00e9 client<\/td>\nStarter Templates a charg\u00e9 un script d\u2019aper\u00e7u de mod\u00e8le sur les pages publiques.<\/td>\n<\/tr>\n
Quantit\u00e9 excessive d\u2019options charg\u00e9es automatiquement<\/td>\nEnviron 2,9 Mo d\u2019options ont \u00e9t\u00e9 charg\u00e9es automatiquement, dont deux options relatives aux donn\u00e9es de documentation repr\u00e9sentaient la majeure partie du total.<\/td>\n<\/tr>\n
Maintenance WooCommerce en attente<\/td>\nLa version de la base de donn\u00e9es WooCommerce stock\u00e9e \u00e9tait la 7.7.0, alors que la version de l’extension install\u00e9e \u00e9tait la 8.5.5.<\/td>\n<\/tr>\n
T\u00e2ches en arri\u00e8re-plan ayant \u00e9chou\u00e9<\/td>\nCartFlows a enregistr\u00e9 122 \u00e9checs lors d\u2019une action de mise \u00e0 jour de la base de connaissances.<\/td>\n<\/tr>\n
D\u00e9pendances obsol\u00e8tes<\/td>\nPlusieurs extensions ainsi que le th\u00e8me Astra avaient plusieurs versions de retard par rapport aux mises \u00e0 jour disponibles.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Ces constatations nous ont ouvert plusieurs pistes possibles. Nous aurions pu tout mettre \u00e0 jour, mais cela aurait rendu difficile l\u2019identification de la modification \u00e0 l\u2019origine du probl\u00e8me. Cela aurait \u00e9galement accru le risque d\u2019affecter le processus de commande, CartFlows ou le contenu Elementor.<\/p>\n

Nous avons donc choisi un probl\u00e8me mineur que nous pouvions isoler et \u00e9valuer.<\/p>\n

Suppression des activit\u00e9s superflues des plugins<\/h2>\n

Le premier probl\u00e8me concernait Starter Templates, une extension couramment utilis\u00e9e pour importer des designs WordPress pr\u00e9d\u00e9finis.<\/p>\n

Sur cette installation, l’extension avait d\u00e9j\u00e0 rempli sa fonction initiale. La boutique en ligne \u00e9tait cr\u00e9\u00e9e, et l\u2019importateur n\u2019\u00e9tait plus n\u00e9cessaire pour afficher ses pages existantes.<\/p>\n

Cependant, la version install\u00e9e continuait d\u2019ex\u00e9cuter du code qui \u00e9crivait dans le journal d\u2019erreurs PHP. Claude a remont\u00e9 la piste des messages jusqu\u2019\u00e0 un appel dans :<\/p>\n

wp-content\/plugins\/astra-sites\/inc\/lib\/class-astra-sites-zip-ai.php<\/code><\/pre>\n
L\u2019instruction concern\u00e9e \u00e9tait :<\/p>\n
error_log( $zip_ai_path );<\/code><\/pre>\n
L\u2019enqu\u00eate a r\u00e9v\u00e9l\u00e9 que ce m\u00eame message repr\u00e9sentait l\u2019int\u00e9gralit\u00e9 des 281 lignes de cinq journaux d\u2019erreurs \u00e9chantillonn\u00e9s.<\/p>\n
\"Claude
Claude d\u00e9tectant des probl\u00e8mes sur un site WordPress.<\/figcaption><\/figure>\n
L’extension mettait \u00e9galement en file d\u2019attente un fichier JavaScript de 6,5 Ko utilis\u00e9 par sa fonctionnalit\u00e9 de pr\u00e9visualisation des mod\u00e8les, m\u00eame sur les pages de boutique classiques.<\/p>\n
Aucun de ces probl\u00e8mes n\u2019\u00e9tait catastrophique. Cependant, la r\u00e9p\u00e9tition de ces messages rendait les fichiers journaux d\u2019erreurs moins utiles, tandis que le script c\u00f4t\u00e9 client ne semblait servir aucun objectif apparent pour les visiteurs.<\/p>\n
Choisir entre la mise \u00e0 jour et la d\u00e9sactivation<\/h3>\n
Une version plus r\u00e9cente de Starter Templates avait supprim\u00e9 l\u2019instruction de journalisation ; une mise \u00e0 jour aurait donc pu r\u00e9soudre cette partie du probl\u00e8me.<\/p>\n
Un examen plus approfondi a r\u00e9v\u00e9l\u00e9 que la nouvelle version chargeait toujours le script de pr\u00e9visualisation. La d\u00e9sactivation de l’extension permettrait de supprimer les deux. Avant d\u2019effectuer cette modification, Claude a v\u00e9rifi\u00e9 si d\u2019autres extensions ou le th\u00e8me actif d\u00e9pendaient de Starter Templates lors de l\u2019ex\u00e9cution. Il n\u2019a constat\u00e9 aucune d\u00e9pendance n\u00e9cessaire \u00e0 l\u2019affichage de la vitrine existante.<\/p>\n
\"Claude
Claude hi\u00e9rarchise les \u00e9tapes de modernisation.<\/figcaption><\/figure>\n
Un compromis : la d\u00e9sactivation supprimerait la biblioth\u00e8que \u00ab Starter Templates \u00bb d\u2019Elementor et de l\u2019\u00e9diteur de blocs. Cela avait de l\u2019importance si les \u00e9diteurs utilisaient encore la biblioth\u00e8que pour cr\u00e9er de nouvelles sections, m\u00eame si les pages existantes continueraient de fonctionner.<\/p>\n
Apr\u00e8s avoir \u00e9valu\u00e9 cet impact, nous avons d\u00e9sactiv\u00e9 les \u00ab Starter Templates \u00bb sur l\u2019environnement de staging via MyKinsta <\/strong>> Sites <\/strong>> Extensions et th\u00e8mes<\/strong>.<\/p>\n
\"Mise
Mise \u00e0 jour des extensions WordPress dans MyKinsta.<\/figcaption><\/figure>\n