J’avais un site WordPress en italien et en anglais. Je voulais ajouter l’espagnol, le français et l’allemand. Soixante-douze articles à traduire en trois langues, plus des pages de navigation, des catégories, des shortcodes, des redirections, du SEO. Face à ce volume de travail, la réponse honnête était : c’est impossible. Pas avec le temps et les ressources d’un projet personnel. Puis j’ai utilisé Claude Code, et en huit sessions de travail réparties sur quelques semaines j’ai tout terminé.
Cet article raconte comment ça s’est vraiment passé : les décisions, les erreurs, les solutions, et surtout ce que signifie collaborer avec un agent IA sur un projet à grande échelle. Ce n’est pas un guide technique étape par étape — c’est le récit d’une expérience, avec suffisamment de détails pratiques pour vous permettre de la reproduire.
La Frustration du Départ
Le problème avec l’internationalisation d’un site WordPress n’est pas la traduction. C’est la complexité systémique qui l’entoure.
Avec Polylang — le plugin que j’utilise pour gérer les langues — chaque langue n’est pas simplement une étiquette sur le texte. C’est un ensemble séparé d’articles, de pages, de catégories avec des IDs distincts, des URLs avec des préfixes différents, des shortcodes à mettre à jour, des redirections à configurer. Traduire un article manuellement signifie : créer l’article dans la nouvelle langue, le lier à l’original, lui attribuer les catégories dans la version de la nouvelle langue (pas les italiennes — les allemandes, avec des IDs différents), copier l’image à la une, définir la bonne date, remplir les champs SEO. Pour chaque article. Pour soixante-douze articles. Pour trois langues.
J’ai regardé les alternatives. Les plugins de traduction automatique (WPML + DeepL, TranslatePress) traduisent le texte mais ne comprennent pas la structure — les blocs Gutenberg avec des IDs de catégorie codés en dur restent incorrects, les shortcodes personnalisés ne sont pas touchés, la configuration technique reste votre responsabilité. Une agence de localisation aurait géré la traduction mais pas la partie technique WordPress. Un développeur freelance aurait géré la partie technique mais pas la traduction. La combinaison des deux, pour soixante-douze articles en trois langues, représentait un projet de plusieurs mois et de plusieurs milliers d’euros.
Donc le projet était resté en suspens. Comme la plupart des projets ambitieux sur des sites personnels : non par manque d’intention, mais par manque de temps et de ressources.
La Première Session : Comprendre ce que Pouvait Faire Claude Code
Claude Code n’est pas un chatbot auquel poser des questions. C’est un agent ayant accès aux outils du système : il peut lire et écrire des fichiers, exécuter des commandes dans le terminal, interroger des bases de données, modifier du code. Quand je lui ai décrit le problème — site WordPress, plugin Polylang, soixante-douze articles, trois langues à ajouter — il n’a pas répondu avec une liste d’instructions à suivre. Il a commencé à travailler.
Il a lu le code du mu-plugin personnalisé qui gère la navigation du site. Il a interrogé la base de données pour comprendre comment Polylang organise les traductions en interne. Il a identifié les sept points du plugin à mettre à jour pour prendre en charge une nouvelle langue. Tout cela sans que je lui explique comment fonctionne Polylang — il l’a compris en lisant le code source et les structures de la base de données.
Mon rôle dans cette première session était différent de ce à quoi je m’attendais. Je ne donnais pas d’instructions techniques. Je prenais des décisions : on ajoute l’allemand ou le chinois ? On commence par l’espagnol ou le français ? Priorité à la structure de navigation ou aux articles ? Les décisions stratégiques étaient les miennes. L’exécution technique était celle de Claude Code.
Comment la Collaboration a Évolué
Après la première session, j’ai compris quel était le schéma de collaboration qui fonctionnait le mieux :
- J’apportais le contexte et les priorités : “cette semaine je veux terminer le français”, “d’abord les pages de navigation puis les articles”, “l’allemand est plus important que le portugais car le marché DACH est pertinent”
- Claude Code apportait le plan et l’exécution : proposait l’approche, l’exécutait, montrait le résultat, signalait les problèmes, corrigeait de façon autonome quand quelque chose ne fonctionnait pas
- Je validais le résultat : ouvrir le site dans la nouvelle langue, vérifier qu’un article avait la bonne image, les catégories correctes, la date d’origine
Aucune connaissance technique sur Polylang, WP-CLI ou PHP n’était nécessaire. Ce qu’il fallait, c’était savoir ce que je voulais obtenir et être capable de reconnaître si le résultat était correct.
Le Problème des Sessions Multiples et de la Mémoire
Un projet de cette envergure — soixante-douze articles par langue — ne se termine pas en une seule session. Claude Code a une limite de contexte : à un moment donné, la conversation devient trop longue et il faut recommencer. Le risque est que chaque nouvelle session reparte de zéro, ré-explorant des choses déjà découvertes, répétant des erreurs déjà corrigées.
La solution est le système de mémoire persistante intégré à Claude Code : des fichiers texte enregistrés dans un répertoire spécifique qui sont chargés automatiquement au début de chaque nouvelle session. Nous avons utilisé ce système pour sauvegarder :
- La liste complète des étapes pour ajouter une langue (dans l’ordre, avec les pièges de chacune)
- La correspondance de toutes les catégories italien → langue cible
- Les erreurs déjà rencontrées et les correctifs appliqués
- L’état du projet : quels lots avaient été complétés, combien d’articles restaient
Grâce à ces fichiers de mémoire, chaque nouvelle session reprenait exactement là où elle s’était arrêtée. Le “coût de démarrage” d’une session se réduisait à quelques minutes au lieu de plusieurs heures de ré-exploration.
C’est l’un des aspects les moins évidents de Claude Code : ce n’est pas seulement un outil pour faire des choses, mais aussi pour construire une connaissance persistante sur un projet au fil du temps.
Le Pipeline Technique qui a Fonctionné
Pour ceux qui veulent comprendre le côté technique : le cœur du processus était un pipeline en trois phases.
Claude Code écrivait les traductions des articles et les métadonnées dans un fichier JSON standard. Ce fichier était ensuite lu par un script PHP exécuté directement dans le contexte WordPress via WP-CLI. Le script PHP créait chaque article dans la nouvelle langue, le liait à l’original italien, lui attribuait les catégories dans la version de la nouvelle langue, copiait l’image, définissait la date et remplissait les champs SEO.
Chaque lot traitait dix articles. Pour soixante-douze articles : sept ou huit lots. Chaque lot produisait une sortie lisible — “OK IT:123 → DE:456 | Titre de l’article” — permettant de vérifier immédiatement ce qui avait réussi et ce qui avait échoué.
Le choix du format JSON comme pont entre la génération IA et l’exécution WordPress n’était pas évident au départ — la première approche utilisait un format différent qui produisait des erreurs d’analyse. Mais une fois le bon pipeline établi, il a fonctionné de façon fiable pour tous les lots suivants.
Les Erreurs : Ce qui a Mal Tourné et Comment ça a été Résolu
Ne parler que des succès serait malhonnête. Voici les vraies erreurs que nous avons rencontrées.
La Première Approche de Transfert de Données ne Fonctionnait pas
La tentative initiale était de générer du code PHP directement depuis le code Python utilisé pour préparer les données. Le résultat était des erreurs d’analyse immédiates : les deux langages ont des conventions différentes pour représenter les structures de données, et les mélanger produisait du code invalide. Solution : séparer les formats. Python écrit du JSON standard, PHP lit avec ses fonctions natives. Le JSON est un format d’échange de données explicite — il fonctionne toujours entre des systèmes différents.
Les Catégories des Articles Étaient dans la Mauvaise Langue
Polylang crée un ensemble séparé d’identifiants numériques pour chaque langue. La catégorie “Technologie” en italien a un numéro. En allemand, elle a un numéro différent. Si vous attribuez le numéro italien à un article allemand, vous lui attribuez la catégorie italienne — et les grilles d’articles affichent un contenu mixte ou vide. Cette erreur n’était pas visible dans la sortie du script, seulement en ouvrant le site dans la nouvelle langue. D’où la règle : toujours valider après le premier lot, pas à la fin de tous.
Une Catégorie Allemande Pointait vers “Uncategorized”
Quand nous avons ajouté l’allemand, l’une des catégories était déjà liée dans la base de données de Polylang à un terme générique créé automatiquement, et non à la vraie catégorie. Claude Code a trouvé l’anomalie en interrogeant la base de données, a créé la catégorie correcte et mis à jour le lien. Sans la possibilité d’interroger directement la base de données, ce type de problème aurait été invisible jusqu’à bien plus tard.
Les Articles Étaient Créés Sans Image et avec la Mauvaise Date
La fonction de Polylang qui crée des articles dans une nouvelle langue ne copie pas automatiquement l’image à la une ni la date de publication originale. Les articles apparaissaient sans image et datés du jour de la création plutôt que de la date originale. Solution : ajouter explicitement dans le script PHP la copie de l’image et de la date pour chaque article créé.
La Qualité des Traductions
La question la plus fréquente : quelle est la qualité de la traduction générée par l’IA ?
Pour le contenu technique — articles sur Linux, bases de données, outils de développement, Raspberry Pi — la qualité est très bonne. La terminologie est correcte, les commandes restent inchangées, les explications sont cohérentes. Un lecteur allemand qui lit un article sur Ansible ou SQL Server ne remarquera pas qu’il a été généré par une IA.
Pour le contenu plus éditorial — critiques de jeux vidéo, réflexions personnelles, articles d’opinion — la qualité est bonne mais avec un ton légèrement plus formel qu’un texte écrit nativement. Ce n’est pas une traduction littérale : Claude Code adapte le contenu au contexte de la langue cible. Un article sur Cyberpunk 2077 écrit dans un registre familier en italien devient en allemand quelque chose de stylistiquement approprié pour le public allemand, et non une transposition mot à mot.
Le seuil utile à garder en tête : la qualité est largement suffisante pour apporter du contenu de valeur aux lecteurs dans différentes langues. Elle n’est pas identique à une traduction professionnelle humaine. Mais elle est infiniment meilleure que de n’avoir rien — ce qui était exactement la situation de départ.
Pourquoi cette Approche est Différente d’un Traducteur Automatique
Un traducteur automatique (DeepL, Google Translate) fait une seule chose : convertit du texte d’une langue à une autre. Il ne touche pas à la structure du site, ne met pas à jour le plugin de navigation, ne crée pas les catégories dans la nouvelle langue, ne configure pas les redirections, ne remplit pas les champs SEO.
Claude Code en tant qu’agent fait tout cela ensemble. Non pas parce qu’il est “plus intelligent” dans un sens abstrait, mais parce qu’il a accès aux outils du système et peut agir sur eux. La différence pratique est énorme : un traducteur automatique vous donne du texte traduit à coller. Claude Code vous donne un site fonctionnel dans une nouvelle langue.
Il y a aussi une différence qualitative dans la traduction elle-même. Un traducteur automatique applique des règles linguistiques. Claude Code comprend le contexte : il sait qu’un article est une critique de jeu vidéo, que le public est passionné de technologie, que le ton doit être informel mais précis. La traduction résultante est plus cohérente avec l’intention originale de l’article.
Le Bilan Final
Soixante-douze articles pour cinq langues. Quarante-cinq pages de navigation. Cinq cent quarante champs SEO. Des dizaines de mises à jour du code du plugin. Tout terminé en sessions de travail réparties sur quelques semaines, sans équipe, sans budget significatif, sans expertise technique spécialisée en Polylang ou WP-CLI.
Mais le nombre qui compte le plus est un seul : zéro. Zéro articles en espagnol, français et allemand qui auraient existé sans cette approche. Le projet serait resté sur la liste des choses à faire, comme il y était resté pendant des mois.
C’est le vrai avantage de travailler avec un agent IA sur des projets à grande échelle : pas qu’il soit plus rapide (il l’est), pas qu’il coûte moins cher (c’est le cas), mais qu’il rend réalisables des projets qui ne seraient autrement jamais faits. Il abaisse le seuil d’accès à un niveau où un seul propriétaire de site peut faire des choses qui nécessitaient auparavant une équipe.
Ce Dont Vous Avez Besoin pour Commencer
Si vous voulez reproduire cette approche sur votre site WordPress multilingue, le point de départ pratique :
- Claude Code — la CLI d’Anthropic, disponible sur claude.ai/code. Nécessite un accès au terminal du serveur où tourne votre WordPress
- WP-CLI — installé sur le serveur, permet à Claude Code d’interagir avec WordPress depuis la ligne de commande
- Polylang — le plugin gratuit fonctionne. Pro ajoute quelques commodités mais n’est pas nécessaire
- Un document de contexte initial — avant de commencer, rédigez (ou faites rédiger par Claude Code) un document décrivant la structure de votre site, les plugins utilisés, le fonctionnement de la navigation. Cela réduit considérablement le temps de “mise en route” de chaque session
Ce qui est le moins évident : votre rôle n’est pas de donner des instructions techniques. C’est de savoir ce que vous voulez obtenir, approuver les plans proposés et valider les résultats. Les compétences techniques sont apportées par Claude Code.
