wp plugin list --status=active renvoie WPML, actif depuis deux ans sur ce site, avec trois langues déjà bien installées : français, anglais, espagnol. La demande semble simple à première vue — ajouter l’italien — mais un site en production avec du trafic réel n’est jamais l’endroit idéal pour découvrir qu’une opération de configuration a des effets de bord plus larges que prévu.
Cette checklist couvre spécifiquement les vérifications à mener avant l’activation d’une langue supplémentaire, pas le choix du traducteur ni la stratégie de contenu pour cette nouvelle langue, qui relèvent d’une décision éditoriale distincte.
1. Tester d’abord sur un environnement de staging identique
Avant toute manipulation en production, l’activation doit être reproduite sur une copie récente du site, avec la même version de WPML, de WordPress et des extensions tierces. Les comportements de synchronisation initiale peuvent varier sensiblement selon le volume de contenu déjà présent, ce qui rend un test sur un environnement trop léger peu représentatif.
2. Vérifier l’impact sur les URL des langues existantes
Selon le mode de gestion des URL choisi (sous-dossiers, paramètre de requête, ou domaines distincts), l’ajout d’une langue peut, dans certaines configurations mal maîtrisées, réorganiser silencieusement la structure d’URL des langues déjà actives. Un contrôle systématique consiste à relever un échantillon d’URL en français et en anglais avant activation, puis à les revérifier immédiatement après, pour confirmer qu’aucune ne change.
curl -s -o /dev/null -w "%{http_code}\n" https://exemple.fr/fr/services/
curl -s -o /dev/null -w "%{http_code}\n" https://exemple.fr/en/services/
3. Anticiper la charge de resynchronisation initiale
L’activation d’une nouvelle langue déclenche généralement une resynchronisation des tables internes de WPML pour intégrer cette langue dans les groupes de traduction existants. Sur un catalogue de contenu volumineux, cette opération peut consommer des ressources serveur significatives pendant plusieurs minutes. Il vaut mieux planifier l’activation en heure creuse plutôt qu’au pic de trafic du site.
4. Vérifier la compatibilité des extensions tierces avec la nouvelle langue
Certaines extensions (formulaires, moteur de recherche interne, extensions de prix) maintiennent leurs propres réglages par langue et ne détectent pas toujours automatiquement une langue nouvellement activée. Un tour des réglages de chaque extension multilingue-sensible du site permet d’ajouter manuellement la nouvelle langue là où elle ne s’ajoute pas d’elle-même.
- Formulaires de contact : vérifier les notifications par langue
- Recherche interne : vérifier le filtre de langue actif
- Extension de sitemap XML : vérifier la génération d’une entrée dédiée
5. Préparer le contenu minimal avant l’ouverture publique
Activer une langue sans contenu traduit associé peut, selon la configuration du repli linguistique, afficher un mélange de contenu original et de contenu manquant aux premiers visiteurs de cette langue. Un socle minimal (page d’accueil, page de contact, mentions légales) devrait être traduit et publié avant l’annonce publique de la nouvelle langue, même si le reste du site suit progressivement.
6. Vérifier le sélecteur de langue et les liens hreflang
Une fois la langue activée, le sélecteur de langue du thème doit afficher la nouvelle option sans rupture de mise en page, et les balises hreflang générées automatiquement doivent inclure le nouveau code de langue sur toutes les pages concernées. Un contrôle rapide via l’inspecteur du navigateur, sur quelques pages représentatives, permet de confirmer ce point avant l’annonce.
7. Prévoir un point de retour arrière documenté
Avant l’activation en production, il convient de documenter précisément la procédure de désactivation de la langue en cas de problème majeur découvert après coup, ainsi qu’une sauvegarde de la base de données antérieure à l’opération. Cette précaution, rarement nécessaire, évite l’improvisation si un effet de bord inattendu apparaît une fois la langue ouverte au public.
Une langue supplémentaire sur un WPML en production n’est jamais une simple case à cocher dans un réglage : c’est une opération qui touche les URL, la charge serveur et la compatibilité de chaque extension du site.
En résumé
Sept vérifications suffisent à couvrir l’essentiel du risque : test préalable en staging, contrôle des URL existantes, anticipation de la charge de synchronisation, vérification des extensions tierces, contenu minimal prêt, sélecteur de langue et hreflang fonctionnels, et un plan de retour arrière documenté. Aucune de ces étapes ne demande beaucoup de temps isolément, mais leur absence collective est précisément ce qui transforme une activation de langue de routine en incident de production.
