# Traduire WordPress avec l’IA : rapide, économique et sans les tracas de WPML – notre workflow complet > URL: https://4eck-media.de/fr/blog/traduire-wordpress-avec-lia-rapide-economique-et-sans-les-tracas-de-wpml-notre-workflow-complet/ > Language: fr > Description: WordPress fait tourner environ 41 % de tous les sites web dans le monde. Et pourtant, en 2026, il n'existe toujours aucun moyen, sur le CMS numéro un, de traduire un site web sans… --- WordPress fait tourner environ 41 % de tous les sites web dans le monde. Et pourtant, en 2026, il n’existe toujours aucun moyen, sur le CMS numéro un, de traduire un site web sans que cela ne coûte des semaines, n’engloutisse une petite fortune – ou ne perde silencieusement des traductions en cours de route. Nous le savons parce que nous avons vécu les trois variantes. Un article de plus de 10 000 mots, traduit dans l’éditeur WPML, cases cochées, enregistré – et sur le site en ligne : de l’allemand. Pas partout, cela aurait été trop facile à repérer. Seulement dans 1 247 des 1 725 champs. Cet article est le compte rendu de la façon dont nous avons résolu ce problème chez nous. Vous y découvrirez pourquoi les traductions échouent si souvent dans WordPress et quels bugs de WPML nous ont coûté le plus de nerfs. Vous verrez notre solution en détail : un complément d’environ 300 lignes de code que Claude Code a écrit en dix minutes, et un workflow de traduction qui traduit, vérifie et importe un article de 10 000 mots en 3 à 5 minutes – de façon vérifiable et complète. Et à la fin, vous obtiendrez les deux prompts qui vous permettront de reproduire l’ensemble chez vous : un pour votre développeur ou pour Claude Code, un pour le travail de traduction proprement dit. Une précision d’abord, pour bien poser les attentes : ceci n’est pas un article « l’IA fait tout ». Chez nous, l’IA prend en charge la routine – de façon fiable, vérifiable et pour une fraction des coûts habituels. La responsabilité, elle, repose sur un processus doté de contrôles intégrés. À quoi il ressemble, vous allez le lire maintenant. ![Les contenus WordPress sont traduits et vérifiés automatiquement dans plusieurs langues grâce à l'IA](https://4eck-media.de/wp-content/uploads/2026/07/wordpress-wpml-claude-cover-safe-layout-source.avif) ## Pourquoi le multilinguisme n’est plus un simple bonus La réponse courte : parce que votre prochaine demande ne viendra plus forcément du village voisin, mais de Zurich, de Vienne – ou de Tokyo. Qui exploite son site web uniquement en allemand fait de la langue un obstacle à la vente. Et ce, sur un marché qui a précisément aboli cet obstacle depuis longtemps. ### Qu’est-ce que le marché intérieur de l’UE vient faire là-dedans ? Le marché intérieur a largement supprimé les droits de douane, les frontières et la bureaucratie entre les États membres. Une agence de Görlitz peut travailler pour un client de Lisbonne, une boutique de Graz livrer à Helsinki – sur le plan juridique et logistique, c’est le quotidien. La dernière véritable frontière qui subsiste, c’est la langue. Qui ne propose son site web que dans une seule langue relève la frontière que le marché vient tout juste d’abaisser. La pression économique est donc bien réelle : vos concurrents ne sont plus les trois prestataires des environs, mais tous ceux qui parlent la langue du client. ### Comment savons-nous que le marché est réellement mondial ? Par notre propre boîte de réception. Nous recevons désormais des demandes de Suisse, d’Autriche, du Japon, du Canada et des États-Unis. La raison est remarquable : les assistants d’IA nous recommandent lorsque quelqu’un cherche la « meilleure agence WordPress » ou de l’aide en SEO, en marketing et en intégration de l’IA. Comment on entre dans ces recommandations, nous l’avons décrit en détail dans notre [article GEO](https://4eck-media.de/fr/blog/le-4eck-geo-framework-pour-la-visibilite-et-les-recommandations-ia/) – ici, seule compte la conséquence : le client fait ses recherches dans sa langue, son assistant d’IA répond dans sa langue, et si votre site web n’existe pas à cet endroit, vous n’existez pas pour ce client. Cela change le calcul. Autrefois, une version anglaise était « sympathique pour les visiteurs internationaux ». Aujourd’hui, elle détermine si vous apparaissez ne serait-ce que dans les moteurs de réponse. Et plus personne ne peut prédire dans quelle langue arrivera la prochaine demande – chez nous, c’était récemment le japonais. Nous en avons tiré les conséquences et créé dix langues dans WPML. Non pas parce que nous voulons ouvrir des bureaux sur dix marchés, mais parce que nous ne pouvons plus décider où le prochain client fera ses recherches. ### Pourquoi le prix et la rapidité sont-ils une question stratégique ? Parce que le multilinguisme n’est pas un projet ponctuel, mais un état permanent. Chaque nouvel article de blog, chaque référence, chaque page de prestation doit être mise à jour – sinon la version en langue étrangère se transforme en ruine aux contenus périmés. Et c’est là que la déclaration d’intention se sépare de la pratique : si une série de traductions prend des semaines ou coûte un montant à quatre chiffres par langue, on finit par y renoncer. Non par mauvaise volonté, mais parce que, dans le quotidien, il y a toujours quelque chose de plus urgent qui attend. C’est précisément pour cela que nous ne traitons pas les coûts et la vitesse de traduction comme un détail opérationnel, mais comme un levier stratégique : ils déterminent si le multilinguisme est réellement vécu ou s’il prend la poussière sur la liste des « un jour, peut-être ». Comment nous avons maîtrisé les deux, les chapitres suivants le montrent. Pourquoi le marché n'est plus local - Le marché intérieur de l’UE a supprimé presque toutes les frontières – la langue est la dernière, et elle se trouve sur votre site web - Nos demandes viennent désormais de Suisse, d’Autriche, du Japon, du Canada et des États-Unis - Les assistants d’IA nous recommandent pour des requêtes comme « meilleure agence WordPress » ainsi qu’en SEO, marketing et intégration de l’IA - Qui ne propose qu’une seule langue est tout simplement absent des réponses d’IA en langue étrangère - Le prix et la rapidité des traductions déterminent si le multilinguisme est entretenu durablement ### Questions fréquentes sur le multilinguisme Le multilinguisme en vaut-il aussi la peine pour les petites entreprises ? Justement dans ce cas. Les grands prestataires s’offrent des agences de traduction, les petits perdent des demandes internationales sans combattre. Lorsque les traductions deviennent rapides et économiques, le seul argument rationnel qui s’y oppose disparaît – et le marché adressable s’agrandit sans que vous ayez diffusé la moindre publicité. Par quelle langue faut-il commencer ? Par celle d’où proviennent déjà des demandes ou dans laquelle vos clients cibles font leurs recherches. L’anglais est le plus souvent la première étape, car il sert aussi de langue passerelle aux assistants d’IA. Ensuite, c’est votre marché qui décide, pas votre intuition. Le traducteur automatique du navigateur du visiteur ne suffit-il pas ? Non. La traduction du navigateur n’intervient que lorsque le visiteur est déjà sur votre site. Le moment décisif se situe avant : dans la recherche et dans la recommandation de l’IA, qui se déroulent dans la langue de l’utilisateur. Là, seul compte ce qui est réellement traduit et présent sur votre domaine. ## Comment fonctionnent les traductions dans WordPress – et pourquoi elles échouent Si vous voulez comprendre pourquoi les traductions de sites web sont si pénibles et si coûteuses, il vous suffit d’une seule prise de conscience : WordPress ne stocke pas un article comme un seul texte. Il le stocke sous forme de centaines de petits champs – et chacun d’eux doit passer par la traduction. ### Pourquoi un article n’est-il pas « un seul texte » ? Ce qui, dans le navigateur, ressemble à un article continu se présente dans la base de données sous forme découpée : le titre est un champ, chaque paragraphe est un champ, chaque point de liste, chaque légende d’image, chaque intertitre. À cela s’ajoutent les parties invisibles qu’aucun visiteur ne lit, mais que lit chaque moteur de recherche : le titre SEO, la méta-description, le slug de l’URL. Un exemple concret tiré de notre propre blog : notre plus gros article, le framework GEO, se compose de 1 599 blocs et se décompose en 1 725 segments de traduction. Plus de 10 000 mots, répartis sur plus de 1 700 champs de formulaire. C’est un cas extrême, certes – mais il montre à quelle échelle se joue un seul article de fond ambitieux. Les plugins de traduction reproduisent exactement cette structure. WPML est le leader du marché, Polylang et TranslatePress sont les alternatives les plus connues – le principe de base est partout le même : le plugin crée pour chaque langue une copie de la structure de champs et fait passer chaque champ un à un par la traduction. Ce n’est pas un défaut de conception, mais une nécessité pour que la mise en page, les liens et le formatage survivent à la traduction. Cela explique cependant pourquoi « traduis-moi vite fait la page » n’est pas une petite demande. Il existe pour l’essentiel trois façons de remplir ces champs – et chacune fait mal à sa manière. ### Voie 1 : manuellement dans l’éditeur de traduction L’éditeur de traduction affiche à gauche le champ allemand, à droite le champ cible vide. On traduit, on clique pour continuer, on traduit, on clique pour continuer. Pour une page de contact avec vingt champs, c’est faisable. Pour un article de 10 000 mots comptant plus de 1 700 champs, c’est du travail à la chaîne pendant des jours – par langue, notons-le bien. Et c’est le type de travail le plus éprouvant : assez monotone pour engendrer des erreurs, mais trop exigeant pour être confié à des personnes non formées. Celui qui perd sa concentration après le champ 900 ne s’en aperçoit pas – le résultat, lui, s’en aperçoit. Nous avons créé dix langues dans WPML ; qui fait ce calcul honnêtement jusqu’au bout repose très vite sa calculatrice. ![Éditeur de traduction WPML avec la longue liste de champs d'un gros article, de nombreux champs par publication](https://4eck-media.de/wp-content/uploads/2026/07/Bild-2-wpml.avif) ### Voie 2 : l’agence de traduction La voie classique : exporter le texte, le confier à une agence, intégrer le résultat. Souvent de bonne qualité – mais la facturation suit une formule impitoyable : prix par mot × volume × nombre de langues. Pour un site web comme le nôtre, avec 116 articles de blog, 53 références et 199 pages de compétences, cette multiplication aboutit à un montant qu’aucun budget marketing ne cède de son plein gré. À cela s’ajoute le chemin du retour : quelqu’un doit réintégrer les textes livrés dans les centaines de champs – ce qui vous offre gratuitement une partie de la voie 1. ### Voie 3 : traduction automatique avec les crédits WPML WPML intègre un mécanisme automatique : d’un clic, DeepL, Google ou Microsoft traduisent les contenus, la facturation se faisant via des crédits. C’est la voie la plus confortable – et elle a deux hics. Premièrement, la facturation : par mot et par langue. Amener un article dans une langue est bon marché ; amener 116 articles dans plusieurs langues ne l’est plus. Qui publie régulièrement paie régulièrement. Deuxièmement, et cela pèse plus lourd : le mécanisme automatique traduit sans contexte de projet. Il ne connaît pas votre marque, ni vos noms de produits, ni votre terminologie – il ne voit jamais que le segment isolé en cours de traitement. Il traduit donc allègrement les noms de marque, et les termes techniques sautent d’une page à l’autre : sur une page c’est dit ainsi, sur la suivante autrement, et le lecteur se demande s’il s’agit de deux choses différentes. Le résultat est rarement faux, mais fiablement médiocre. Pour une page de type carte de visite, cela peut suffire. Pour un blog censé prouver une expertise – et qui veut être cité comme source par les assistants d’IA -, « fiablement médiocre » est le mauvais objectif de qualité. Retenons-le : cher, lent ou médiocre – choisissez-en un. C’est précisément là qu’intervient notre workflow. Mais avant, nous devons encore parler de quelque chose de plus désagréable : des endroits où WPML n’est pas seulement pénible, mais tout bonnement cassé. Trois voies – chère, lente ou médiocre - Un article WordPress n’est pas un texte, mais des centaines de champs : notre plus gros se décompose en 1 725 segments pour plus de 10 000 mots - Voie 1, manuelle dans l’éditeur : plus de 1 700 champs par langue – du travail à la chaîne pendant des jours - Voie 2, agence de traduction : prix par mot × volume × langues – impayable pour 116 articles - Voie 3, crédits WPML : confortable, mais facturation par mot et par langue – et sans contexte de projet, les marques sont traduites elles aussi - Les trois voies passent mal à l’échelle : chère, lente ou médiocre ### Questions fréquentes sur les traductions WordPress Pourquoi ne puis-je pas simplement copier l'article en entier et le coller traduit ? Parce que la structure se perd alors : les blocs, les formatages, les liens internes et les métadonnées SEO sont rattachés aux différents champs. C’est précisément pour cela que les plugins de traduction décomposent le contenu en segments – c’est le seul moyen pour que la page reste techniquement identique à l’original après la traduction. WPML est-il le bon choix, ou plutôt Polylang ou TranslatePress ? Pour les sites web aux contenus complexes (champs ACF, blocs Gutenberg, métadonnées SEO), WPML est le plus profondément intégré et donc le leader du marché. Polylang et TranslatePress sont des alternatives plus légères pour des configurations plus simples. Qui est déjà profondément engagé dans WPML doit savoir : une migration est le plus souvent plus coûteuse que la réparation des problèmes. La traduction automatique de WPML ne suffit-elle pas pour commencer ? Pour des pages isolées : oui, tout à fait. Le problème commence avec le volume et l’exigence – beaucoup d’articles multipliés par plusieurs langues, cela devient cher, et sans glossaire ni contexte, la cohérence en souffre. Correct pour un site vitrine, insuffisant pour un blog spécialisé. Combien de segments compte une page normale ? Cela varie énormément. Une courte page de prestation se contente de quelques dizaines de champs, notre plus gros article de blog atteint 1 725 segments. C’est précisément cette amplitude qui rend les affirmations générales sur la charge de traduction si peu fiables – comptez les segments, pas les pages. ## Les bugs de WPML que nous avons appris à la dure D’emblée, pour éviter tout malentendu : nous aimons WordPress. Il fait tourner environ 41 % de tous les sites web et détient près de 60 % du marché des CMS – nous bâtissons notre activité dessus. C’est précisément pour cela que nous nous agaçons. Ce qui suit n’est pas le règlement de comptes de détracteurs, mais le compte rendu d’utilisateurs qui exploitent WPML en production et y ont trouvé des choses qu’on ne lit dans aucune fiche produit. ### La perte silencieuse de données : max_input_vars Le pire bug est celui qui ne lève aucun message d’erreur. Notre article sur le framework GEO compte 1 599 blocs, qui deviennent plus de 1 700 champs de formulaire dans l’éditeur de traduction. Or PHP a une limite par défaut du nombre de champs de formulaire qu’un serveur accepte par requête : max_input_vars, fixé d’usine à 1 000. Tout ce qui dépasse est silencieusement écarté à l’enregistrement. Aucune erreur, aucun avertissement – l’éditeur signale un succès, les champs excédentaires ont tout simplement disparu. Le résultat chez nous : 1 247 des 1 725 segments restaient bloqués. Proprement traduits dans l’éditeur, case « Translation is complete » cochée – mais les traductions ne sont jamais arrivées sur le site en ligne. On a travaillé pendant des jours, le système confirme le travail, et le visiteur de la page traduite lit malgré tout de l’allemand. Le plus perfide : l’erreur ressemble à une erreur de manipulation. Quelqu’un a-t-il oublié d’enregistrer ? S’est-on trompé de langue ? Qui ne sait pas quoi chercher se cherche des semaines durant chez lui-même – alors que la cause est une constante serveur dont la plupart des rédacteurs n’ont jamais entendu parler. ### Des coches vertes sur des champs vides Plus pervers encore : nous avons trouvé des traductions où la case « Translation is complete » était cochée – sur des champs vides. Le statut dit terminé, le champ ne dit rien. Pour un système de traduction, c’est la catastrophe absolue, car le statut est la seule chose sur laquelle s’appuient la planification et la validation. Notre conclusion figure depuis dans chaque consigne de travail : il ne faut pas croire les cases de statut. Le contrôle se fait sur le contenu exporté, jamais sur le tableau de bord. ![Éditeur WPML : plusieurs champs cibles vides avec la case « Translation is complete » cochée à 1 % de progression](https://4eck-media.de/wp-content/uploads/2026/07/bild-03-wpml-complete-leer.avif) ### La Translation Memory oublie La Translation Memory est en fait la meilleure fonctionnalité de WPML : ce qui a été traduit une fois est prérempli la fois suivante. Pour notre gros article, elle a tout de même livré 462 des 1 725 segments prêts – près d’un quart de travail offert, nous prenons volontiers. Mais elle a une faiblesse : quand un article change et que WPML resegmente les contenus, des segments qui étaient pourtant déjà traduits se perdent au passage. On paie alors la même traduction une deuxième fois – ou, pire, on ne remarque pas qu’elle manque, puisque « au fond, tout avait déjà été traduit ». On ne fonde aucune planification sur une mémoire qui oublie en tournant la page. ### Et par-dessus, il y a encore le cache Supposons que vous ayez trouvé tout cela et importé les corrections. Alors, entre vous et le visiteur, il reste encore le cache de pages : dans un cas, la correction était depuis longtemps dans le système, mais les visiteurs voyaient encore, pendant 24 heures, l’ancienne version erronée. Pour le contrôle qualité, cela signifie : même un coup d’œil sur le site en ligne ne prouve rien tant qu’on ne sait pas quand le cache a été vidé pour la dernière fois. La recherche d’erreurs devient ainsi un modèle en couches – éditeur, base de données, cache, et chaque couche peut raconter une autre vérité. ### Les petits détails qui coûtent des heures Deux trouvailles de la catégorie « ça ne coûte que des nerfs » : l’export livre toujours du XML – peu importe l’extension de fichier demandée. Qui a bâti son outillage sur un autre format n’a plus qu’à le refaire. Et l’API REST ne voit pas les langues masquées : tant qu’une langue n’est pas encore publiée, on ne peut tout simplement pas l’interroger via l’interface – justement dans la phase où l’on souhaite le plus urgemment vérifier de façon automatisée. ### Pourquoi nous ne changeons malgré tout pas On pourrait maintenant s’écrier : à bas WPML ! Nous voyons les choses autrement, pour deux raisons. Premièrement, WPML est profondément intégré à notre site web – ACF, Gutenberg, métadonnées SEO. Une migration serait plus coûteuse que la réparation. Deuxièmement, et c’est le point le plus important : sous le capot, tout est là. Export et import XLIFF, Translation Memory, API internes – la machine fonctionne. Seule la couche du formulaire de navigateur est cassée, c’est-à-dire précisément la couche avec laquelle les humains travaillent. Et retenons-le : ce ne sont pas des erreurs de manipulation. Nous avons cherché assez longtemps dans l’autre direction pour le dire avec une certaine assurance. Ce sont des problèmes systémiques d’un outil comptant plus d’un million d’installations. Quand un formulaire écarte silencieusement des données sur les gros articles et qu’une case de statut apparaît sur des champs vides, cela touche tout le monde qui publie sérieusement en plusieurs langues – la plupart ne le remarquent simplement pas, parce que personne ne relit la version polonaise de son propre blog champ par champ. La bonne nouvelle : c’est précisément parce que les fonctions sous-jacentes sont intactes qu’on peut contourner la couche de formulaire cassée au lieu de la réparer. Comment, c’est ce que montre le prochain chapitre. Les pièges de WPML qui nous ont coûté des nerfs - max_input_vars (par défaut : 1 000 champs) tronque silencieusement le formulaire de l’éditeur sur les gros articles – 1 599 blocs, plus de 1 700 champs, aucun message d’erreur - Conséquence chez nous : 1 247 des 1 725 segments traduits et marqués « complete », mais jamais arrivés sur le site en ligne - La case « Translation is complete », nous l’avons aussi trouvée sur des champs entièrement vides – il ne faut pas se fier au statut - La Translation Memory perd des segments déjà traduits lors d’une resegmentation ; le cache a montré aux visiteurs l’ancienne version pendant 24 heures - Détails : l’export livre toujours du XML, l’API REST ne voit pas les langues masquées - Bilan : des problèmes systémiques, pas des erreurs de manipulation – mais l’infrastructure (XLIFF, TM, API internes) fonctionne ### Questions fréquentes sur les problèmes de WPML Comment savoir si je suis concerné par le bug max_input_vars ? À la contradiction entre le statut et le site en ligne : l’éditeur signale « complete », mais sur la page traduite figure encore du texte allemand ou des champs restent vides. Sont concernés surtout les longs articles comptant beaucoup de blocs. Exportez la traduction et cherchez dans la cible les segments vides et la langue source – vous ne devez pas vous fier à la seule case. Suffit-il d'augmenter max_input_vars sur le serveur ? Cela désamorce ce bug précis, oui – à condition que votre hébergeur autorise seulement à modifier la valeur. Les autres problèmes demeurent : faux statuts « complete », pertes de segments dans la Translation Memory, retards de cache. Nous avons donc décidé de contourner entièrement le formulaire et d’importer par XLIFF – une seule opération, aucune limite de champs. Devrions-nous migrer hors de WPML à cause de ces bugs ? Dans la plupart des cas : non. En cas d’intégration profonde avec ACF, Gutenberg et les métadonnées SEO, une migration est plus coûteuse que la réparation, et les fonctions centrales de WPML sont intactes. Ce qui est cassé, c’est la couche de formulaire dans le navigateur – et elle peut être contournée au lieu de remplacer tout le système. Comment nous assurons-nous que les traductions sont réellement en ligne ? Par un contrôle sur le contenu plutôt que sur le statut : réexporter la traduction après l’import et vérifier que tout est bien arrivé ; sur le site en ligne, chercher par sondage la langue source ; et après des corrections, garder un œil sur le cache. Chez nous, cet export de contrôle fait partie intégrante de chaque cycle de traduction. ## Réparer plutôt que changer : notre décision Nous sommes restés sur WPML – et avons construit à la place une voie qui contourne le formulaire cassé. Cette décision n’a pas été prise par nostalgie, mais après un calcul sobre : WPML est profondément ancré dans notre projet. Champs ACF, blocs Gutenberg, métadonnées SEO – tout passe par WPML, à travers dix langues. Une migration vers un autre plugin de traduction aurait signifié reconstruire tout ce câblage sur 116 articles de blog, 53 références et 199 pages de compétences. Cela serait revenu plus cher que la réparation. Nettement plus cher. S’y est ajoutée une observation qui a tout changé. Quand nous avons regardé sous le capot, rien n’était cassé. WPML a l’export et l’import XLIFF. WPML a une Translation Memory qui retient chaque passage jamais traduit. WPML a des API internes qui gèrent tout cela proprement. La salle des machines fonctionne. Seul l’étage utilisateur est cassé : le formulaire de navigateur de l’éditeur de traduction, qui, sur les gros articles, envoie plus de champs que le serveur n’en accepte – et écarte silencieusement les excédentaires. Un changement de plugin aurait donc jeté avec l’eau du bain la salle des machines qui fonctionne, juste pour se débarrasser d’une surface défectueuse. Et par-dessus, la Translation Memory : chaque traduction déjà payée, déjà validée, dans dix langues. Ce capital, personne ne l’abandonne de son plein gré. Qui démolit toute la maison à cause d’un étage défectueux a un problème de budget. La réponse rationnelle est : nous prenons l’escalier. Concrètement, cela signifie faire passer le cycle « exporter, traduire, réimporter » entièrement à côté du formulaire – directement via les fonctions que WPML embarque de toute façon. Aucun fork, aucun remplacement, aucune exploitation en parallèle de deux plugins. Juste une déviation autour du seul endroit qui ne tient pas. Et c’est précisément là que l’IA entre en jeu. Non pas comme un bouton magique portant l’inscription « traduire », sur lequel on appuie en espérant – de tels boutons venaient justement de nous offrir des champs vides avec des coches vertes. Mais comme un ouvrier à qui l’on peut confier deux missions très concrètes. Premièrement : le complément lui-même – écrire le code qui ouvre la déviation. Deuxièmement : la traduction – le vrai travail de fourmi, segment par segment, avec des vérifications avant et après. Les deux sont des tâches aux règles claires et au résultat mesurable. Exactement le type de travail où l’IA livre aujourd’hui de façon fiable – et où un humain garde malgré tout le dernier mot en tant que relecteur. À quoi ressemble ce complément, combien de temps il a réellement pris et pourquoi il transforme un éditeur cassé en un workflow de traduction continu – ce sont les deux prochains chapitres. ## Le complément : un mini-plugin à quatre routes que Claude Code a écrit en dix minutes Toute la réparation tient dans un unique mu-plugin : environ 300 à 400 lignes de PHP qui ouvrent quatre routes HTTP vers des fonctions que WPML possède depuis longtemps. Le plugin ne traduit rien, ne génère rien, ne supprime rien. C’est une porte – rien de plus. Le code, Claude Code l’a écrit d’après une spécification technique, notre développeur l’a relu et déployé. La génération elle-même était une affaire de dix minutes. ![Architecture du mini-plugin geo-helper : environnement d'IA, routes REST, fonctions WPML et base de données](https://4eck-media.de/wp-content/uploads/2026/07/bild-04-plugin-architektur.avif) ### Que fait exactement le plugin ? Il met à disposition cinq points d’accès, dont quatre portent le vrai travail : - **/status** – ce qui est traduit, ce qui ne l’est pas. La réponse qu’il faudrait péniblement reconstituer clic par clic dans le back-end WPML, en une seule requête. - **/requeue** – remettre un contenu dans la file d’attente de traduction. WPML construit alors le job et préremplit depuis la Translation Memory tout ce qui a déjà été traduit. - **/export** – exporter le contenu complet sous forme de fichier XLIFF, les segments par paires : source allemande, champ en langue cible. - **/import** – réinjecter le fichier XLIFF terminé, en une seule opération. S’y ajoute **/ping** pour le diagnostic : l’installation répond-elle seulement, avant de lancer une exécution ? Ce qui est déterminant, c’est ce que le plugin ne fait *pas*. Il n’invente aucune nouvelle logique de traduction, aucun éditeur propre, aucun modèle de données parallèle. Chaque route est un pur wrapper autour d’une fonction interne de WPML – les mêmes mécanismes qu’utilise aussi le workflow XLIFF officiel de WPML. Nous n’avons procédé à aucune refonte, mais donné à quatre capacités existantes une adresse que l’on atteint sans navigateur. ### Comment est-il né ? Racontons-le en toute transparence, car c’est précisément cette partie qui intéresse beaucoup de chefs de projet : au départ, il n’y avait pas du code, mais une spécification technique – quelles routes, quels paramètres, quel comportement en cas d’erreur, ce qui est expressément interdit. Cette spécification, nous l’avons élaborée avec Claude Code, puis rendue sous forme de mission : écris le mu-plugin exactement d’après ce document. ![Spécification technique des cinq routes REST du plugin geo-helper](https://4eck-media.de/wp-content/uploads/2026/07/bild-05-spezifikation-routen.avif) La génération du code a duré environ dix minutes. Et là, restons honnêtes, car le chiffre des dix minutes seul brosserait un tableau faussé : la relecture par notre développeur, la mise en place de l’IP-Allowlist et le déploiement ont coûté une soirée. Un humain a lu chaque ligne avant qu’elle ne soit autorisée sur l’environnement de production. Ce n’est pas de la méfiance envers l’IA, mais simplement la répartition du travail que nous appliquerions à tout code sur un environnement client – peu importe qui l’a écrit. Le calcul est malgré tout clairement favorable : une soirée d’effort pour un outil qui, depuis, porte chaque cycle de traduction. ### Est-ce sûr ? La question s’est posée en interne dès le début, et elle est légitime : quatre routes HTTP ouvertes sur un site web de production, cela ressemble d’abord à une surface d’attaque. Notre réponse comporte trois niveaux. Premièrement : une IP-Allowlist plutôt que des tokens. Seules les adresses IP de sortie fixes de l’environnement d’IA peuvent seulement solliciter les routes ; toute autre requête est repoussée. Ainsi, aucun token ne se trouve non plus dans le code, susceptible d’expirer, de fuiter ou d’être committé par mégarde. Deuxièmement : le plugin ne peut rien supprimer. Cette capacité n’existe tout simplement pas dans le code – le pire cas envisageable est un import échoué, pas un contenu perdu. Troisièmement : il ne génère aucun contenu. Aucune nouvelle publication, aucune page, aucun utilisateur. Il ne fait que déplacer des données de traduction à travers des canaux que WPML lui-même définit. ### Pourquoi est-ce le tournant décisif ? Parce que cela change *qui* peut mener le cycle. Auparavant, « exporter → traduire → réimporter » dépendait du navigateur : se connecter, cliquer, attendre – et, à l’enregistrement des gros articles, tomber précisément dans le piège max_input_vars que nous avons disséqué dans les chapitres précédents. Un agent d’IA ne peut pas sauver un formulaire de navigateur que le serveur tronque côté serveur. Avec les quatre routes, le même cycle se déroule sans navigateur. Et cela signifie : un agent d’IA peut le reprendre entièrement. Il interroge le statut, remet l’article dans la file d’attente, récupère le fichier XLIFF, traduit, vérifie, réinjecte et compare – sans échouer sur un formulaire qui n’a jamais été conçu pour 1 700 champs. D’un outil qu’un humain doit manipuler et qui échoue sur les gros contenus, on fait une interface qu’une machine peut manipuler de façon fiable. La section suivante montre ce déroulement pas à pas sur le plus gros article de notre site web. Le plugin d'aide en cinq points - Un mu-plugin, env. 300–400 lignes de PHP – de purs wrappers autour de fonctions WPML existantes - 4 routes de travail (/status, /requeue, /export, /import) plus /ping pour le diagnostic - Génération du code par Claude Code : ~10 minutes ; relecture, IP-Allowlist et déploiement par le développeur : une soirée - Sécurité : IP-Allowlist au lieu de tokens, aucune suppression possible, ne génère aucun contenu - Effet : le cycle « exporter → traduire → réimporter » se déroule sans navigateur – un agent d’IA peut le reprendre entièrement ### Questions fréquentes sur le complément Le mini-plugin remplace-t-il WPML ? Non. Il complète WPML par quatre routes accessibles de l’extérieur vers des fonctions que WPML embarque déjà : export XLIFF, import XLIFF, file d’attente, interrogation du statut. La traduction se fait toujours dans les structures de données de WPML – Translation Memory comprise. Le plugin traduit-il lui-même ? Non, pas une seule ligne. Il exporte des contenus en XLIFF et réinjecte des fichiers XLIFF terminés. La traduction se passe à l’extérieur – chez nous par des agents d’IA, mais une agence de traduction humaine pourrait tout aussi bien se trouver à l’autre bout. Pourquoi une IP-Allowlist et non des tokens d'API ? Parce que l’environnement d’IA a des adresses IP de sortie fixes et que nous réduisons ainsi la surface d’attaque au minimum, sans avoir à gérer de secrets dans le code. Aucun token signifie : rien qui puisse expirer, fuiter ou se retrouver par mégarde dans un dépôt. Un tel plugin peut-il endommager le site web ? Le potentiel de dommage est volontairement maintenu faible : le plugin ne peut ni supprimer ni générer de contenus, il ne fait que déplacer des données de traduction via des mécanismes propres à WPML. S’y ajoute l’export de contrôle après chaque import, qui vérifie que ce qui devait arriver est réellement arrivé. ## Voici comment se déroule une traduction aujourd’hui : le workflow pas à pas Le résultat d’abord, sur l’exemple le plus difficile de notre site web : notre plus gros article – le framework GEO, 1 725 segments de traduction, plus de 10 000 mots – a été traduit avec ce workflow en 3 à 5 minutes. 1 215 segments fraîchement traduits, vérifiés automatiquement, importés et confirmés par export de contrôle. Le même article dont 1 247 segments restaient auparavant bloqués dans l’éditeur cassé. Voici le déroulement, pas à pas. ![File d'attente de traduction WPML avec de nombreux contenus dans plusieurs langues, tous au statut à traduire](https://4eck-media.de/wp-content/uploads/2026/07/bild-10-wpml-queue.avif) ### Étape 1 : requeue – WPML met la table L’agent appelle la route /requeue, WPML construit le job de traduction et préremplit depuis la Translation Memory tout ce qui a déjà été traduit. Pour notre article, la TM a livré 462 des 1 725 segments prêts – un bon quart du travail était fait avant que quiconque ait traduit un seul mot. C’est le moment où chaque traduction enregistrée auparavant rapporte, y compris celles de l’ère WPML antérieure au complément. ### Étape 2 : Export – tout l’article en un seul fichier Via /export, l’article complet sort sous forme d’un unique fichier XLIFF : tous les segments par paires, source allemande à côté du champ en langue cible. Un fichier, un état, un point de vérité – au lieu de 1 700 champs de formulaire dont le serveur n’accepte que les 1 000 premiers. ### En bref : qu’est-ce qu’un fichier XLIFF ? XLIFF signifie « XML Localization Interchange File Format » – un standard industriel établi depuis des années pour les traductions. On peut se le représenter comme un conteneur normalisé : un fichier XLIFF contient le texte proprement découpé en segments, et à chaque segment correspondent un champ source (l’original) et un champ cible (la traduction). Le formatage, les balises et l’ordre sont préservés au passage. Son charme : presque tout outil de traduction sérieux parle XLIFF – WPML aussi exporte et importe dans ce format. Au lieu de faire passer du texte de force à travers d’étroits champs de formulaire, on se transmet un unique fichier vérifiable. C’est exactement ce que nous exploitons : WPML sort l’article en XLIFF, l’IA remplit les champs cibles, et WPML relit le fichier terminé – sans que rien ne se perde en chemin. ### Étape 3 : trier – tout n’est pas à traduire Un script répartit les segments en trois piles : **à traduire**, **ne pas toucher** (noms de marque, URLs, réglages ACF – tout ce qui doit rester identique dans chaque langue) et **déjà terminé** (les 462 correspondances de la TM). Cette étape paraît anodine, mais elle évite les deux erreurs classiques de la traduction automatique : que quelqu’un « traduise » une URL ou qu’un champ de réglage technique finisse en belle prose dans la langue cible. ### Étape 4 : agents d’IA en parallèle – 14 batches, un glossaire Les segments restants partent en 14 batches d’environ 85 segments vers des agents d’IA parallèles. Pour que quatorze traducteurs ne choisissent pas quatorze mots pour un même terme technique, tous travaillent avec un glossaire terminologique commun, construit au préalable à partir des traductions existantes. Ici, la cohérence ne naît pas de l’espoir, mais d’une liste de mots partagée. Le parallélisme est la raison pour laquelle un article de 10 000 mots ne devient pas une tâche de plusieurs semaines : 14 ouvriers, en même temps, avec des règles identiques. ![Journal du pipeline : 14 batches, vérifications et confirmation d'import de la traduction par IA](https://4eck-media.de/wp-content/uploads/2026/07/bild-06-pipeline-log.avif) ### Étape 5 : vérifications avant l’import – la machine contrôle la machine Avant que quoi que ce soit ne reflue vers WordPress, chaque fichier traduit passe par des vérifications automatiques : le XML est-il valide ? Toutes les balises HTML sont-elles complètes ? Les listes ont-elles autant de points que dans l’original ? Les liens sont-ils intacts ? Et : reste-t-il des mots allemands résiduels dans le texte cible ? Pour cette dernière vérification, il existe une liste blanche de noms propres – une « Deutsche Gesellschaft für … » s’appelle ainsi dans toutes les langues et ne doit pas être recalée comme une erreur de traduction. Si un batch échoue, il est corrigé avant de pouvoir poursuivre. Rien n’atteint l’import sans avoir été vérifié. ### Étape 6 : Import – une opération, en contournant le formulaire Le fichier XLIFF vérifié repart via /import – en une seule opération, directement via les fonctions internes de WPML. Aucun formulaire de navigateur, aucune limite max_input_vars, aucun rejet silencieux de champs. L’endroit précis où l’ancienne voie se brisait n’existe tout simplement pas dans cette voie-ci. ### Étape 7 : export de contrôle – la confiance c’est bien, la comparaison c’est obligatoire Pour finir, nous exportons une nouvelle fois le même article et comparons : chaque champ cible contient-il réellement ce qui a été importé ? Cette paranoïa, nous nous la sommes forgée avec les champs vides portant la case « Translation is complete ». Depuis, nous ne croyons plus une case de statut – mais bien une comparaison d’export. [Emplacement de capture d’écran : page d’article avant/après – traduction vide avec case « complete » vs. page en ligne entièrement traduite] ### Qu’est-ce que cela donne en chiffres ? 1 215 segments fraîchement traduits, vérifiés et importés – en 3 à 5 minutes. À titre de comparaison, l’ancien calcul pour le même article : une semaine de travail de traduction, plus une semaine supplémentaire pour retrouver ce que l’éditeur avait perdu à l’enregistrement. Et le workflow passe à l’échelle : pour l’anglais, nous avons traité en un jour 638 segments répartis sur 50 références, un article de blog et 4 pages ; le français en est à 53 références complètes avec 401 segments traduits et corrigés. Aujourd’hui, EN, FR et PL sont complètes à 100 % – blog, références, pages. L’espagnol est en cours de façon autonome, d’après une consigne de travail écrite. L’humain dans la chaîne n’a pas disparu. Il est simplement passé de la saisie à la validation. Le workflow à l'exemple de notre plus gros article - 1 725 segments, plus de 10 000 mots – le plus gros article du site web - La Translation Memory a livré 462 segments prêts - 14 agents d’IA en parallèle, batches d’environ 85 segments, glossaire terminologique commun - 5 vérifications automatiques avant l’import : XML, balises HTML, points de liste, liens, mots allemands résiduels - Résultat : 1 215 segments traduits, vérifiés et importés en 3 à 5 minutes - Ancienne voie : une semaine pour traduire plus une semaine pour chercher ce qui n’avait pas été enregistré ### Questions fréquentes sur le workflow Pourquoi l'article est-il exporté sous forme d'un unique fichier XLIFF ? Parce qu’un fichier est un état cohérent : source et cible sont côte à côte par paires, rien n’est tronqué par le serveur, et l’import se déroule plus tard en une seule opération. C’est précisément ce que le formulaire de navigateur ne peut pas assurer sur les gros articles – là, le processus s’interrompait. Comment garantissez-vous que 14 agents parallèles traduisent de façon uniforme ? Via un glossaire terminologique commun, construit avant l’exécution à partir des traductions existantes. Chaque batch travaille avec la même liste de mots ; les termes techniques et les formulations récurrentes restent ainsi cohérents à travers tous les batches. Que se passe-t-il si une traduction échoue aux vérifications automatiques ? Alors elle n’atteint pas l’import. Les vérifications tournent avant la réinjection : validité du XML, balises HTML complètes, même nombre de points de liste, liens intacts, aucun mot allemand résiduel. Seul un fichier propre repart via /import. Comment savez-vous qu'après l'import tout est réellement arrivé ? Grâce à l’export de contrôle : l’article est réexporté après l’import et comparé à la version réinjectée. Nous ne nous fions plus à la seule case de statut – des champs vides avec « Translation is complete » ont bien été le point de départ de toute cette histoire. ### Le vrai levier de la rapidité : en parallèle plutôt qu’à la suite Si une tâche de plusieurs semaines devient quelques minutes, ce n’est pas grâce à une saisie plus rapide. C’est grâce au parallélisme. Au lieu de traiter champ par champ et langue après langue, Claude découpe le travail en batches indépendants, les traduit simultanément et réunit tout à la fin – vérifications comprises. ![Schéma de l'orchestration parallèle : Claude divise le travail en batches, les exécute simultanément et les réunit ; comparaison de temps, des semaines contre des minutes](https://4eck-media.de/wp-content/uploads/2026/07/bild-09-parallel-orchestrierung.avif) Le côté agréable : Claude le fait souvent de lui-même. Il reconnaît que les différents batches n’ont pas besoin de se connaître les uns les autres, et les lance en parallèle sans qu’on ait à le demander expressément. Mais justement pas toujours. Face à une consigne formulée de façon vague, le modèle travaille parfois sagement dans l’ordre – le résultat est correct, seulement cela prend plus de temps. C’est pourquoi nous inscrivons la rapidité directement dans le prompt. Une phrase suffit, et on l’ajoute simplement à la consigne de travail : ``` Traite les batches en parallèle, pas les uns après les autres : lance plusieurs agents de traduction en même temps et réunis les résultats à la fin. Process the batches in parallel, not one after another: run several translation agents at the same time and merge the results at the end. ``` L’effet est exactement celui du graphique : des semaines deviennent des minutes. Et dans un métier où le temps est la seule matière première qu’on ne peut pas acheter, ce n’est souvent pas le meilleur produit qui l’emporte au final, mais le plus rapide. Qui met une idée en œuvre immédiatement est là avant même que la concurrence ne commence. ## Comment nous savons que TOUT est réellement traduit Réponse courte : nous ne croyons aucune case. À la place, nous vérifions chaque langue à trois niveaux – d’abord le statut global, puis chaque segment isolé, puis le contenu lui-même. Ce n’est que lorsque les trois niveaux sont propres qu’une langue est considérée comme terminée chez nous. Et c’est précisément cette méfiance qui nous a fait trouver des erreurs que personne n’avait remarquées dans l’original allemand depuis des années. Si vous avez lu jusqu’ici, vous connaissez la raison de notre méfiance : 1 247 segments avec la case « Translation is complete » cochée – et derrière, des champs vides. Qui a vécu cela une fois se construit un système de contrôle. Le nôtre a trois niveaux. ### Niveau 1 : où en sommes-nous au juste ? La matrice de statut. Par langue et par type de contenu – articles de blog, références, pages – nous voyons d’un coup d’œil : complete, périmé ou non traduit. C’est l’aperçu d’une minute qu’un chef de projet veut avoir chaque matin. Pas vingt clics à travers le back-end WPML, mais un tableau qui répond à la question : où manque-t-il encore quelque chose ? La matrice ne dit toutefois que ce que WPML *croit*. C’est pourquoi il y a le niveau 2. ![Matrice de statut avant/après : lacunes de traduction au début du projet et langues entièrement vertes EN, FR, PL](https://4eck-media.de/wp-content/uploads/2026/07/bild-08-status-matrix.avif) ### Niveau 2 : les cases sont-elles justes ? Le scan des segments. Nous exportons chaque job de traduction et cherchons automatiquement deux choses : des champs cibles vides et du texte allemand là où il ne devrait pas y en avoir. Car il ne faut pas croire les cases de statut – c’est justement avec ce scan que nous avons trouvé les articles où « complete » figurait sur des champs vides. Le statut était soigné, le site en ligne à moitié allemand. Cela paraît beaucoup de travail, mais c’est un script : exporter, comparer, liste de constats. Les noms propres comme « Deutsche Gesellschaft für… » figurent sur une liste blanche pour ne pas passer pour des erreurs. ### Niveau 3 : est-ce aussi du bon polonais ? Un champ vide, tout script le trouve. Mais un germanisme ? Un nom propre non décliné ? Pour cela, nous faisons lire la traduction par des agents d’IA en tant que relecteurs de langue maternelle, face à l’original allemand – phrase par phrase, sens contre sens. Le résultat en polonais nous a nous-mêmes surpris. Les 53 références étaient toutes en « complete ». La relecture a pourtant trouvé environ 70 constats : germanismes, noms propres non déclinés – et, dans un cas, la description du mauvais client. Une erreur de copier-coller qui figurait même dans l’original allemand. En ligne depuis des années, remarquée par aucun humain, trouvée par l’IA lors de la comparaison systématique. Les 132 corrections, nous les avons toutes appliquées en une soirée. C’est pour nous le véritable enjeu de ce chapitre : l’IA ne fait pas que traduire – elle est l’auditeur qui ne se fatigue pas au 1 500e segment. Un relecteur humain lit 53 pages de références et finit par se lasser ; ce n’est pas une critique, c’est de la biologie. L’agent lit le segment 1 500 avec la même attention que le segment 1. Le contrôle qualité à trois niveaux - Niveau 1 – matrice de statut : langue × type de contenu, vue d’ensemble en une minute - Niveau 2 – scan des segments : exporter chaque job, chercher les champs vides et les mots allemands résiduels ; les cases ne comptent pas - Niveau 3 – relecture par IA de langue maternelle face à l’original : contresens, calques, déclinaisons - Preuve pratique : 53 références polonaises « complete » – malgré tout ~70 constats, dont le mauvais client dans une description - Les 132 corrections appliquées en une soirée ### Questions fréquentes sur le contrôle qualité L'affichage du statut dans WPML ne suffit-il pas ? Non. Le statut indique seulement qu’un job de traduction a été achevé – pas que le contenu est arrivé sur le site en ligne. Nous avions 1 247 segments avec la case cochée et des champs vides. C’est pourquoi nous vérifions toujours au niveau des segments. Qui contrôle le contrôle – l'IA peut-elle trouver ses propres erreurs ? La relecture se fait face à l’original allemand, non face à sa propre traduction, et se déroule comme une étape distincte avec un rôle distinct. S’y ajoutent des vérifications automatiques avant chaque import : XML valide, balises HTML complètes, liens intacts. Au bout du compte, un humain effectue tout de même des contrôles par sondage chez nous. Combien de temps dure un tel cycle de vérification ? La matrice de statut, c’est une minute. Le scan des segments et la relecture tournent de façon automatisée – pour le polonais, nous avons appliqué les 132 corrections de la relecture en une seule soirée. La relecture trouve-t-elle réellement des choses que les humains laissent passer ? Oui, de façon avérée : l’erreur de copier-coller avec le mauvais client figurait même dans l’original allemand – et n’y avait jamais été remarquée par personne. La comparaison systématique phrase par phrase ne se fatigue pas, et c’est précisément là que réside son avantage. ## Qui traduit et qui contrôle : la répartition du travail entre les modèles Le conseil secret de notre workflow n’est pas un logiciel, mais une décision de personnel : nous employons deux modèles d’IA différents – l’un traduit, l’autre contrôle. Cette répartition des rôles est la raison pour laquelle le calcul finit par être bon. La répartition se présente ainsi : Claude Opus 4.8 est le modèle exécutant. Il est rapide et nettement plus économique pour le travail de masse – idéal pour la traduction proprement dite, les batches parallèles d’environ 85 segments, le traitement de la file d’attente. Claude Fable 5 est analytiquement plus fort, mais plus cher – et n’est donc mobilisé que ponctuellement : il planifie le déroulement, vérifie des échantillons et valide le résultat. Si cela vous rappelle quelque chose, c’est parce que vous organisez probablement votre équipe ainsi : le junior traduit, le senior relit. Personne ne laisse la tête la plus chère de la maison transcrire 1 700 segments de texte courant – elle doit définir la structure et jeter un œil à la fin. C’est exactement ce que nous faisons avec les modèles. À ceci près que les deux travaillent la nuit et ne tombent pas malades. ### Rapide, économique, bon – choisissez-en deux ? Le vieux triangle de la gestion de projet dit : parmi rapide, économique et bon, vous n’en obtenez jamais que deux. La répartition des rôles est notre réponse à cela – elle livre les trois. Rapide, parce que le modèle exécutant travaille en parallèle par batches. Économique, parce que le modèle coûteux n’est payé que pour les moments où l’analyse est réellement nécessaire : planification, échantillon, validation. Et bon, parce que ce n’est justement pas le même modèle qui valide son propre travail, mais une seconde instance, plus forte, qui contrôle. L’ordre est important : d’abord le modèle senior planifie la mission – ce qui est traduit, ce qui reste intact (marques, URLs, réglages ACF), quel glossaire terminologique s’applique. Le glossaire, nous le construisons à partir des traductions existantes, afin que tous les agents parallèles utilisent les mêmes termes – sinon le même terme technique s’appelle autrement dans le batch 3 que dans le batch 11. Ensuite, le modèle junior traite la masse. À la fin, le senior revient et vérifie par sondage si le résultat correspond à la consigne. Aucun segment ne va à l’import sans avoir traversé cette chaîne. Pour l’article de 1 725 segments, cela s’est concrètement présenté ainsi : 14 agents parallèles, chacun avec un batch d’environ 85 segments et le même glossaire. La masse a tourné sur le modèle économique – la planification en amont et la validation en aval sur le modèle puissant. Résultat en 3 à 5 minutes, sans que l’instance coûteuse ait traduit elle-même ne serait-ce qu’un segment de texte courant. Pour vous en tant que chef de projet, cela signifie : dans les projets d’IA, ne pensez pas en termes de « Quel modèle est le meilleur ? », mais de « Quel rôle a besoin de quel modèle ? ». Employer le meilleur modèle partout a autant de sens que confier chaque tâche de l’équipe à la personne la plus chère. Qui traduit, qui contrôle - Claude Opus 4.8 traduit : rapide, plus économique pour le travail de masse, batches parallèles d’environ 85 segments - Claude Fable 5 planifie, vérifie des échantillons, valide : analytiquement plus fort, mobilisé seulement ponctuellement - Principe : le junior traduit, le senior relit – les deux travaillent la nuit et ne tombent pas malades - Résultat : rapide ET économique ET bon – la répartition des rôles déjoue le vieux « choisissez-en deux » ## Ce que cela signifie en chiffres Le bilan d’abord : 116 articles de blog, 53 références, 19 pages – l’anglais, le français et le polonais sont à 100 % en complete. L’espagnol est en cours, et ce de façon autonome : d’après une consigne de travail écrite, sans que personne ne soit assis à côté. Le délai pour cela : des heures au lieu de semaines. Deux exemples qui rendent la différence tangible. Pour l’anglais, nous avons traduit, vérifié et importé 638 segments en une seule journée – 50 références, un article de blog, quatre pages. Et le plus gros morceau de tout le site web, l’article sur le framework GEO avec ses 1 725 segments et plus de 10 000 mots, était bouclé en 3 à 5 minutes : la Translation Memory a livré 462 segments prêts, les 1 215 restants ont été traduits, vérifiés et importés par 14 agents d’IA parallèles. Le même article sur lequel l’éditeur de traduction avait auparavant échoué, avec 1 247 segments bloqués. À cela s’ajoute le français : 53 références complètes, 401 segments traduits ou corrigés. Et pour le polonais, les 132 corrections de la relecture sont toutes passées en ligne en une soirée. Côté coûts, la logique est simple : nous payons un abonnement Claude – pas de facturation par mot et par langue. La traduction automatique de WPML via des crédits (DeepL, Google, Microsoft) existe, mais elle est facturée exactement ainsi : par mot, par langue. Pour 116 articles multipliés par plusieurs langues, cela s’additionne considérablement. À cela s’ajoute : l’abonnement ne couvre pas seulement la traduction, mais aussi la relecture, les scripts de vérification et l’export de contrôle – des étapes de travail qui n’apparaissent même pas dans un calcul au mot. S’y ajoute un effet que nous n’avions pas prévu : les demandes viennent désormais de Suisse, d’Autriche, du Japon, du Canada et des États-Unis. Les assistants d’IA nous recommandent pour des requêtes comme « meilleure agence WordPress » ainsi qu’en SEO, marketing et intégration de l’IA. Le marché est devenu mondial – et un site web qui ne parle qu’allemand est invisible sur ce marché. ### Ce que l’IA ne peut pas faire ici Pour éviter tout malentendu : nous ne prétendons pas que l’IA sait tout faire. Les textes juridiques et les slogans de marque ont besoin, au bout de la chaîne, d’un humain – pour les uns, il y va de la responsabilité, pour les autres, de la nuance, et ni l’un ni l’autre ne se délègue à un modèle de langage. Dans notre workflow aussi, une personne valide l’échantillon final. Mais ce n’est pas un argument contre l’approche, c’est sa limite. Là où des semaines de travail de routine peuvent être automatisées – exporter, traduire, vérifier, importer 1 725 segments -, le faire est la seule décision rationnelle. La responsabilité repose alors sur le processus et ses vérifications : matrice de statut, scan des segments, relecture, contrôles automatiques avant chaque import. Pas sur la foi dans le modèle. Le projet en chiffres - 116 articles de blog, 53 références, 19 pages – EN, FR et PL à 100 % complete - L’espagnol tourne de façon autonome d’après une consigne de travail écrite - 638 segments EN en une journée ; l’article de 1 725 segments en 3 à 5 minutes - Coûts : un abonnement Claude au lieu d’une facturation par mot et par langue - Limite : les textes juridiques et les slogans de marque ont besoin d’un humain au bout de la chaîne ## Ce dont vous avez besoin pour reproduire cela La bonne nouvelle d’abord : la liste de courses est courte. Vous n’avez besoin ni d’une nouvelle plateforme de traduction, ni d’une migration, ni d’un budget spécial – mais de quatre choses, dont vous en avez probablement déjà trois. **Premièrement : WordPress avec WPML.** Toute version prenant en charge XLIFF suffit. L’ensemble du workflow utilise des fonctions déjà présentes dans WPML – export et import XLIFF, Translation Memory, les API internes. Rien n’est remplacé, seulement rendu accessible. **Deuxièmement : un développeur pour une demi-journée.** Le mu-plugin – environ 300 à 400 lignes de PHP, de purs wrappers autour de fonctions internes de WPML – l’IA le génère en une dizaine de minutes. L’humain fait ce qui ne se délègue pas : la relecture du code, le déploiement, l’IP-Allowlist. Chez nous, c’était une soirée. Pour la sécurité : seules les IP de sortie fixes de l’environnement d’IA passent, aucun token dans le code, et le plugin ne peut rien supprimer – il exporte, importe et remonte le statut, rien de plus. **Troisièmement : un abonnement Claude** avec accès à Claude Code et Cowork. C’est le moteur de l’ensemble – et la raison pour laquelle aucune facture au mot ne se crée. **Quatrièmement : une personne pour la validation finale.** Des contrôles par sondage en langue maternelle au bout de la chaîne. L’IA relit systématiquement, mais l’autorisation finale reste chez un humain. Il n’est pas nécessaire que ce soit un traducteur à plein temps – il s’agit de sondages, pas d’une relecture intégrale ; l’intégralité, la machine s’en est déjà chargée en amont. ### Quand notre voie ne vaut-elle pas la peine ? Cela aussi a sa place dans une checklist honnête. Un site web de 5 pages, vous le traduisez plus vite à la main – la mise en place du workflow ne vaut la peine que lorsque le volume l’emporte sur le manuel. Et les contenus juridiques ne passent chez nous par principe qu’avec une relecture professionnelle ; cela, nous ne l’automatisons volontairement pas. Pour tout ce qui se trouve entre les deux – blogs, références, pages de compétences en plusieurs langues – vaut ceci : les outils sont prêts. Export XLIFF, Translation Memory, les API internes – tout cela est déjà dans WPML ; les quatre routes du plugin (/status, /requeue, /export, /import) ne font que le rendre accessible de l’extérieur. Ce qui manque, ce n’est le plus souvent pas la technique, mais la décision de tout assembler. Ce dont vous avez besoin pour la reproduction - WordPress + WPML, toute version prenant en charge XLIFF - Un développeur pour une demi-journée : relecture du plugin, déploiement, IP-Allowlist - Abonnement Claude avec Code + Cowork - Une personne pour la validation par sondage en langue maternelle - Peu pertinent pour : les sites web de 5 pages (le travail manuel est plus rapide) et les contenus juridiques sans relecture professionnelle ## À emporter : Prompt 1 – le complément (pour Claude Code ou votre développeur) Nous tenons maintenant la promesse de l’introduction. Le prompt suivant est la version condensée de la spécification à partir de laquelle notre plugin d’aide est né. Copiez-le dans Claude Code – le résultat est une ébauche de plugin que votre développeur relit et déploie. C’est exactement ainsi que le nôtre est né : dix minutes de génération, une soirée de relecture et de déploiement. Deux choses supplémentaires sont à faire à la main, sans lesquelles rien ne fonctionne : Premièrement : autorisez votre domaine de site web pour l’environnement d’IA. Important – cela ne se passe pas dans l’application Claude, mais dans les paramètres de compte sur le site claude.ai, sous Capabilities → Allow network egress → Additional allowed domains. Vous y saisissez votre domaine (chez nous 4eck-media.de). La raison : Claude travaille dans un environnement cloisonné qui, de lui-même, n’a pas le droit d’aller sur le réseau ouvert. Si cette entrée manque, l’environnement bloque toute requête vers votre serveur – requeue, export et import échouent avant même de démarrer. Un geste unique, sans lequel tout le workflow ne tourne pas. ![Paramètres sur claude.ai : votre propre domaine de site web saisi sous Capabilities, Allow network egress, Additional allowed domains](https://4eck-media.de/wp-content/uploads/2026/07/bild-11-claude-domain-allowlist.avif) Deuxièmement : si vous utilisez aussi Claude dans le navigateur (par exemple pour des contrôles dans l’admin WordPress), ajoutez votre site web à la liste des sites autorisés dans l’extension de navigateur Claude. ``` Task: Build a WordPress mu-plugin ("translation-helper", single PHP file, ~300–400 lines) that exposes existing WPML translation operations over HTTP, so an external AI agent can run a full translation cycle without using the wp-admin browser forms. Routes (REST namespace translation-helper/v1): 1. GET /ping → { ok, wpml_version, plugin_version } - health check, no params. 2. GET /status → params: lang (required), type (post type, e.g. post/page/custom), per_page, page. Returns items with: post_id, title, target_lang, translation_status (not_translated | in_progress | needs_update | complete), job_id, needs_requeue. 3. POST /requeue → JSON body { post_id, target_lang }. Re-queues the post for translation using WPML's Translation Management API (equivalent to sending it to translation in the dashboard). WPML must prefill targets from Translation Memory. Returns new job_id. 4. GET /export → param job_id. Streams the job as XLIFF 1.2 (XML). 5. POST /import → multipart: job_id + file (the translated XLIFF). Applies the translation using WPML's own import routines. Returns { ok, segments_total, segments_applied, status }. Hard requirements: - Wrap EXISTING WPML functions only (Translation Management API, XLIFF export/import). Do not reimplement translation logic. Confirm exact function names against the installed WPML version before finalizing. - Auth: IP allowlist from a constant in the plugin file. Behind Cloudflare/proxies check CF-Connecting-IP (or X-Forwarded-For), not REMOTE_ADDR. Reject everything else with 403. - The plugin must not be able to delete content, create posts, or modify anything except applying translation jobs via /import. - Rate limiting: one concurrent write (requeue/import); return { code: "busy" } or { code: "rate_limit" } so the client can back off and retry. - Log every write operation (timestamp, IP, route, post_id/job_id) to a rotating file. Deliverables: the plugin file + a short README with the curl calls for all five routes. ``` Prompt 1 : le complément en bref - Un mu-plugin, ~300–400 lignes, cinq routes : ping, status, requeue, export, import - Seulement des wrappers autour de fonctions WPML existantes – ne traduit rien lui-même, ne supprime rien - Accès par IP-Allowlist, chaque opération d’écriture est journalisée - Génération : ~10 minutes. Relecture et déploiement par un humain : une soirée - Ensuite, tout le cycle de traduction se déroule sans formulaire de navigateur ## À emporter : Prompt 2 – la consigne de travail pour la traduction (Claude Cowork) Le deuxième prompt est la consigne de travail pour la traduction proprement dite. Il suppose que le plugin du Prompt 1 tourne. Nous l’utilisons dans Claude Cowork ; là, l’IA peut traiter des fichiers, exécuter des scripts et travailler des heures durant de façon autonome. Adaptez la langue, le domaine et la liste « ne pas traduire » à votre projet. ``` Task: Translate the website content of [YOUR-DOMAIN] from [SOURCE-LANG] to [TARGET-LANG] using the translation-helper plugin (REST namespace translation-helper/v1). Work autonomously, sequentially, and keep a verifiable journal. Cycle per post: 1. POST /requeue { post_id, target_lang } → new job_id. WPML prefills targets from Translation Memory - do not re-translate those segments. 2. GET /export?job_id=... → save the XLIFF (keep it as "before" artifact). 3. Classify every trans-unit: (a) TRANSLATE if target is empty or identical to a source that is real [SOURCE-LANG] text; (b) KEEP AS IS if it is a brand name, person, city, URL, or a short technical setting value; (c) TM-DONE if target differs from source - never overwrite these, but reuse them as your terminology reference. 4. Translate with strict rules: reproduce the HTML structure of the source byte-for-byte (same tags, attributes, entities, number of
  • ); translate only human text; SEO title ≤ 60 chars, meta description ≤ 160; [add your language conventions here]. Do not translate: [YOUR BRAND LIST], people, places, technical terms (SEO, PageSpeed…). 5. Validate before import: XML parses; tag list of every changed target equals its source; list item counts match; no leftover [SOURCE-LANG] function words (keep a whitelist for proper names). 6. POST /import (multipart) → expect segments_applied == segments_total, status complete. 7. GET /export again → verify your translations are actually in the re-export ("after" artifact). A status flag alone is NOT proof. 8. Journal line per post: post_id, job_id, segments total/prefilled/translated/kept, import result, verified yes/no. Constraints: all write requests strictly sequential; on "busy"/"rate_limit" back off 30→60→120s; batches of 5–10 posts; never touch posts outside the given list; never change source content; skip WordPress sample pages. Order of work: pilot on ONE small post first and show me the result. Then: references → pages → blog posts → [other post types]. Report after every batch. ``` Et le conseil qui, chez nous, a fait la plus grande différence sur les coûts : séparez les rôles. La traduction de masse tourne chez nous sur Claude Opus 4.8 – rapide et économique. La planification, les sondages et la validation, c’est Claude Fable 5 qui les fait – analytiquement plus fort, mais mobilisé seulement ponctuellement. Le junior traduit, le senior relit. Vous obtenez ainsi la qualité, la rapidité et un prix raisonnable en même temps. ### Questions fréquentes sur la traduction de WordPress avec l'IA Cela remplace-t-il un traducteur professionnel ? Non – et nous le disons volontairement aussi clairement. Pour les textes juridiques et les slogans de marque, un humain a sa place au bout de la chaîne, et même la meilleure IA n’y change rien. Ce que l’IA remplace, c’est le travail de masse : faire traduire à la main 116 articles de blog, 53 références et 199 pages de compétences n’a jamais été pour nous une option réaliste. Avec un processus de vérification propre – contrôles automatiques avant l’import plus relecture en langue maternelle face à l’original -, l’IA est la seule décision rationnelle pour ce contenu de masse. Combien coûte la traduction d'un site web WordPress avec l'IA ? Honnêtement : nettement moins que les alternatives, mais le chiffre exact dépend de votre configuration. La différence décisive réside dans le modèle de facturation – la traduction automatique via les crédits WPML (DeepL, Google, Microsoft) est facturée par mot et par langue, ce qui devient très cher pour 116 articles multipliés par plusieurs langues. Notre workflow, lui, tourne via un abonnement d’IA qui ne compte pas au mot. À cela s’ajoute la mise en place ponctuelle : environ 300–400 lignes de PHP, déployées par le développeur en une soirée. Cela fonctionne-t-il aussi avec Polylang ou TranslatePress ? En principe oui, car l’idée centrale est indépendante du plugin : sortir les contenus du système par export, les traduire et les vérifier à l’extérieur, puis les réinjecter par import – en contournant le formulaire de navigateur. C’est justement ce formulaire qui était chez nous le goulot d’étranglement (max_input_vars coupait silencieusement 1 247 segments sur 1 725). Les routes concrètes de notre plugin geo-helper sont toutefois des wrappers autour de fonctions internes de WPML ; pour Polylang ou TranslatePress, un développeur devrait reconstruire le raccordement à leurs interfaces. Le motif reste le même, l’implémentation non. Qu'en est-il du SEO et du hreflang ? WPML pose lui-même le balisage hreflang dès qu’une traduction est considérée comme complète – vous n’avez pas à vous en préoccuper séparément. Les titres et méta-descriptions Yoast passent comme des segments tout à fait normaux dans l’export XLIFF et sont traduits dans le même cycle. Il importe seulement que les agents d’IA respectent au passage les limites de longueur pour le titre et la description, sinon Google tronque. Cela peut s’écrire comme règle dans la consigne de travail et se vérifier automatiquement. Est-il sûr de donner à une IA l'accès au site web ? Oui, car l’IA n’obtient justement aucun accès général. Le mu-plugin n’ouvre que quatre routes étroitement délimitées pour des opérations de traduction – statut, requeue, export, import – et n’invente rien de nouveau, il wrappe des fonctions WPML existantes. Une IP-Allowlist ne laisse passer que les IP de sortie fixes de l’environnement d’IA, les tokens ne sont pas dans le code. Et de par sa conception, le plugin ne peut ni supprimer ni générer de contenus : le pire cas concevable est une mauvaise traduction, qui reste bloquée à la relecture. Que se passe-t-il lors d'une mise à jour de WPML ? En règle générale : rien, car le plugin utilise les fonctions internes officielles de WPML plutôt que des astuces de base de données maison. Ce sont précisément ces fonctions qui alimentent aussi l’export XLIFF régulier et la Translation Memory – elles sont le socle stable, seule la couche de formulaire de navigateur était cassée chez nous. Nous recommandons malgré tout, après chaque mise à jour majeure, un cycle pilote : faire passer un article par requeue, export, import et export de contrôle, puis comparer le résultat. Cela coûte quelques minutes et enlève à la mise à jour son côté effrayant. Combien de langues sont réalistes ? Notre chiffre honnête : 10 langues sont créées dans WPML, 4 d’entre elles sont complètes – EN, FR et PL à 100 %, l’espagnol tourne actuellement de façon autonome d’après une consigne de travail écrite. Le goulot d’étranglement n’est ici plus la traduction elle-même ; 638 segments anglais en un jour ou 1 215 segments en 3 à 5 minutes montrent à quelle vitesse cela va. Le goulot d’étranglement, c’est la relecture : qui vérifie les résultats, qui tranche sur les questions de terminologie ? Planifiez donc les langues d’après votre capacité de relecture, non d’après la faisabilité technique. Combien de temps dure la mise en place ? Plus court que la plupart ne l’attendent : chez nous, le développeur a eu besoin d’une demi-journée, et le premier article est passé par le cycle complet le jour même. La spécification du mu-plugin est prête et copiable – Claude Code a généré le code en une dizaine de minutes, la relecture, le déploiement et l’IP-Allowlist ont été effectués par notre développeur en une soirée. Ensuite, le workflow est immédiatement productif : requeue, export, traduire, vérifier, import, export de contrôle. ## Glossaire : les termes de cet article **ATE (Advanced Translation Editor)** – L’éditeur de traduction basé sur le navigateur de WPML, dans lequel les traductions sont éditées segment par segment et marquées « complete ». Sur les très gros articles, son formulaire se heurte à des limites côté serveur – chez nous, 1 247 des 1 725 segments se sont ainsi perdus silencieusement. **Egress-Allowlist** – Une liste de sécurité d’adresses IP de sortie fixes depuis lesquelles l’environnement d’IA accède au réseau. Seules ces IP peuvent appeler les routes du plugin de traduction ; toutes les autres requêtes sont rejetées. **hreflang** – Un attribut HTML qui indique aux moteurs de recherche dans quelle langue et pour quelle région une version de page est prévue. WPML pose hreflang automatiquement pour les traductions terminées, afin que Google serve la bonne version linguistique aux bons utilisateurs. **max_input_vars** – Un réglage PHP qui limite le nombre de champs de formulaire qu’un serveur accepte par requête (par défaut : 1000). Si un formulaire de traduction dépasse cette limite – notre plus gros article avait plus de 1 700 champs – le reste est tronqué sans message d’erreur. **mu-plugin** – Un « Must-Use-Plugin » dans WordPress : il se trouve dans un répertoire dédié, est toujours actif et ne peut pas être désactivé via le back-end d’administration. Notre geo-helper est un tel mu-plugin d’environ 300–400 lignes de PHP. **Segment** – La plus petite unité de traduction dans WPML, typiquement un paragraphe, un titre ou un champ isolé. Notre plus gros article se compose de 1 725 segments pour plus de 10 000 mots ; nos agents d’IA les traitent par batches d’environ 85 segments. **Translation Memory** – La mémoire de traduction de WPML : les segments traduits une fois sont mémorisés et préremplis automatiquement lors de nouveaux jobs. Pour notre plus gros article, elle a livré 462 des 1 725 segments prêts. **XLIFF** – Un format d’échange basé sur XML pour les traductions, qui range le texte source et le texte cible par paires pour chaque segment. Via l’export et l’import XLIFF, des articles entiers passent chez nous à côté du formulaire sous forme d’un seul fichier – l’import est une unique opération sans limite max_input_vars. ## Un mot de notre part Tout ce qui est présenté dans cet article repose sur nos propres observations et conclusions issues de notre pratique. Il ne s’agit ni d’un guide universel ni d’un conseil juridique ou technique. Ce que vous mettez en œuvre vous-même, vous le faites à vos propres risques. ## Conclusion : le CMS numéro un mérite de meilleures traductions Pendant une décennie et demie, l’ancienne règle de projet valait pour les traductions WordPress : rapide, économique, bon – choisissez-en deux. Notre conclusion après ce projet : la règle était une propriété de l’outil, non de la tâche. Depuis que le cycle contourne le formulaire cassé et qu’une IA reprend la routine, nous traduisons en heures plutôt qu’en semaines, payons un abonnement plutôt que des tarifs au mot – et savons, grâce au contrôle à trois niveaux, pour la première fois de façon démontrable, que tout est réellement traduit. Vous voulez cela pour votre propre site web ? Copiez cet article – le texte entier – et donnez-le à votre Claude Code. Il y a suffisamment de détails pour qu’il puisse en déduire la reproduction ; les deux prompts ci-dessus sont le point de départ. Et si vous préférez déléguer : c’est précisément pour cela que nous sommes là. Nous construisons des sites web WordPress multilingues qui sont trouvés – par les humains et par les systèmes d’IA. Plus d’informations sur notre page [Faire créer un site web multilingue](https://4eck-media.de/fr/competences/faites-creer-un-site-multilingue-plus-de-portee-plus-de-clients/) – ou [prenez contact avec nous](https://4eck-media.de/fr/contact/).