Auditer un vieux site WPML avant reprise : ce qu’on trouve systématiquement

Notre agence reprend en moyenne cinq à six sites WPML par an, laissés par des prestataires ayant cessé leur activité, changé de spécialité, ou simplement perdu le client suite à une insatisfaction. Ce volume de reprises, cumulé sur plusieurs années, nous a permis d’identifier des schémas récurrents : les mêmes erreurs et dettes techniques reviennent, indépendamment du secteur d’activité du client ou de la taille du site. Cet article ne reprend pas l’audit d’architecture générale que nous avons déjà détaillé par ailleurs pour un cas précis, mais dresse la liste des constats systématiques observés à chaque reprise.

Bloc 1 : l’état des versions

Dans neuf reprises sur dix, WPML lui-même ou l’un de ses modules complémentaires (WPML String Translation, WPML Media, WPML SEO) tourne sur une version vieille de plus de deux ans, souvent bien au-delà de la fenêtre de compatibilité garantie par l’éditeur avec les versions récentes du cœur WordPress. Ce constat n’est presque jamais signalé par le client lui-même : il découvre l’ampleur du décalage au moment de l’audit, ayant simplement vu son site continuer à fonctionner sans alerte visible.

La commande suivante, exécutée en tout début d’audit, donne une première photographie rapide de la situation :

wp plugin list --field=name,version,update --format=table | grep -i wpml

Un décalage de version important s’accompagne presque systématiquement d’un second problème : l’absence de sauvegarde récente testée, le client ayant reporté indéfiniment la mise à jour par crainte de casser quelque chose, faute de pouvoir revenir en arrière sereinement.

Bloc 2 : l’état des tables de traduction

Second constat quasi systématique : les tables propres à WPML (icl_translations, icl_strings, icl_string_translations) n’ont jamais été nettoyées depuis la création du site. Sur un site de cinq ans d’ancienneté, il n’est pas rare de trouver plusieurs milliers de chaînes orphelines issues de plugins désinstallés ou de contenus supprimés depuis longtemps. Ce n’est pas qu’un problème d’esthétique de base de données : passé un certain volume, l’interface de traduction de thèmes et plugins devient perceptiblement plus lente à charger, ce qui décourage les équipes éditoriales de l’utiliser correctement.

SELECT COUNT(*) AS total_chaines,
       SUM(CASE WHEN context NOT IN (
           SELECT DISTINCT context FROM wp_icl_strings WHERE context IS NOT NULL
       ) THEN 1 ELSE 0 END) AS potentiellement_orphelines
FROM wp_icl_strings;

Bloc 3 : les relations de traduction cassées

Troisième constat fréquent : des groupes de traduction incomplets ou incohérents, où une page existe dans une langue sans être correctement reliée à sa source, ou où une relation de traduction pointe vers un contenu supprimé (article à la corbeille, voire définitivement effacé de la base sans que la relation n’ait été nettoyée). Ces incohérences se traduisent en front par des liens de sélecteur de langue menant vers des pages 404, ou par un badge « traduction manquante » affiché en boucle sur des contenus pourtant traduits mais mal reliés.

Bloc 4 : la configuration héritée non documentée

Dernier constat, plus qualitatif : l’absence quasi systématique de documentation sur les choix de configuration initiaux. Pourquoi tel type de contenu est-il en mode « dupliqué » plutôt qu’en « traduction indépendante » ? Pourquoi telle langue a-t-elle été désactivée puis réactivée ? Sans réponse disponible auprès de l’ancien prestataire, chaque reprise commence par une phase de reverse engineering des décisions passées, ce qui rallonge sensiblement le temps d’audit facturable au client.

La checklist en quatre blocs utilisée aujourd’hui

• Versions : lister les versions de WPML et de ses modules, comparer à la dernière version stable, identifier les changelogs de sécurité manqués entre-temps ;
• Tables de traduction : compter les chaînes enregistrées, croiser avec les plugins et thèmes réellement actifs, identifier les candidates à la purge ;
• Relations de traduction : requêter les groupes de traduction incomplets ou pointant vers des contenus supprimés, vérifier un échantillon de sélecteurs de langue en front ;
• Documentation héritée : interroger le client sur l’historique du site, documenter à défaut ce qui peut être déduit de la configuration actuelle, pour éviter de reproduire l’erreur sur la prochaine reprise du site.

Un audit de reprise ne sert pas seulement à lister des problèmes : il sert à reconstituer une mémoire de projet que personne n’a pris le temps d’écrire, et qui manquera cruellement au prochain prestataire si elle n’est pas consignée cette fois.

En résumé

Ces quatre blocs de constats reviennent avec une régularité qui a fini par structurer notre méthodologie d’audit de reprise, indépendamment du secteur d’activité ou de la taille du site concerné. Aucun de ces problèmes n’est en soi dramatique pris isolément, mais leur accumulation silencieuse sur plusieurs années finit par représenter une dette technique substantielle, que seul un audit systématique permet de chiffrer précisément avant de s’engager sur une reprise de maintenance.