Comment traduire un site web en dix langues : mon système avec WordPress, Polylang, un plugin maison et beaucoup d’IA

L’une des façons les plus simples d’obtenir plus de trafic organique est de traduire un site web.

C’est logique : plus d’URL, plus d’intentions de recherche ; si le contenu est bon, cela apporte plus de trafic.

Évidemment, le faire avec l’IA paraît facile. Et ça l’est sur les petits sites.

Sur les sites moyens et grands, les choses se compliquent, au moins si tu essaies de le faire correctement.

Parce qu’il ne s’agit pas seulement de prendre un article en espagnol, de le coller dans ChatGPT et de demander cinq versions. 

Ça marche pour un test, mais un vrai site a des catégories, des étiquettes, du SEO, des images, des champs personnalisés, des liens internes, des menus, des pages d’archive, des pages d’accueil, des slugs, des dates, du hreflang et une structure éditoriale. 

Sans parler du fait que chaque article contient du gras, des listes et de l’italique qu’il vaut mieux conserver dans la traduction.

Et tout doit être traduit.

Ce que j’ai fait cette semaine sur mon site, c’est construire un système pour passer d’un site en espagnol à un site multilingue en dix langues : anglais, français, portugais, italien, allemand, néerlandais, suédois, polonais et norvégien, avec le plugin Polylang, un plugin développé maison et quelques GPTs personnalisés.

Résultat : j’ai déjà le site en dix langues, avec toute la structure de catégories et d’étiquettes, et plusieurs articles publiés déjà traduits.

Et avec un système qui ajoute entre 5 et 10 minutes de charge supplémentaire à n’importe quel article en espagnol pour l’avoir traduit dans ces dix langues, ce qui me semble plus que raisonnable.

Je te raconte tout le processus au cas où tu voudrais le reproduire.

1. Le problème initial : traduire les articles ne suffisait pas

Quand je me suis mis à analyser le développement, j’ai découvert que dans mon cas, au-delà des articles eux-mêmes, je devais traduire tout ça :

• Catégories.
• Étiquettes.
• Slugs.
• Méta-descriptions.
• Titres SEO.
• Images mises en avant.
• Textes alternatifs.
• Champs ACF.
• Blocs internes.
• Liens entre articles.
• Pages d’archive.
• Textes fixes du thème.
• Modules de page d’accueil.
• CTAs.
• Formulaires.
• Tables des matières.
• Articles liés.
• Conserver les dates et les notes.
• …

Beaucoup de textes à cet endroit, et beaucoup trop de langues pour faire ça une par une.

Mais il fallait le traduire, parce que si l’un de ces éléments reste en espagnol, la traduction reste à moitié faite.

C’est pour cela que l’objectif n’était pas de « traduire du contenu », mais de créer une architecture multilingue complète et évolutive, au cas où je voudrais ajouter d’autres langues demain.

Et c’est d’ailleurs ce qui s’est passé : j’ai commencé avec seulement cinq langues (anglais, portugais, français, allemand et italien) et j’ai ajouté les quatre autres en cours de route. Au passage, j’ai vérifié que le système me permettait de monter en charge autant que nécessaire.

2. La base : WordPress, Polylang et copie locale

Le projet part de un site WordPress avec un thème Genesis, un design maison de type magazine et plusieurs modèles personnalisés.

Comme c’était un projet d’une certaine ampleur et qu’il allait demander beaucoup de tests, j’ai travaillé avec une copie locale avec LocalWP. L’idée était de pouvoir casser des choses sans peur, tester des importations, revoir les taxonomies et vérifier que Polylang reliait correctement chaque traduction.

Au passage, j’ai utilisé ce plugin comme base parce qu’il génère déjà tout le nécessaire pour avoir un site en plusieurs langues. À partir de lui, j’ai créé mon plugin en le complétant et en l’adaptant à ce dont j’avais besoin : créer rapidement la structure du site et les articles en plusieurs langues.

Dans cette première phase, j’ai aussi optimisé LocalWP parce qu’au début l’environnement était trop lent et j’avais besoin d’un endroit où exporter, importer, supprimer, répéter et valider de façon fluide..

3. Le système : plugin maison plus GPTs

J’aurais pu utiliser une solution standard de traduction automatique, mais l’objectif était autre.

Traduction simple de chaque article

Pour la traduction des articles, j’ai été TRÈS ambitieux, car je voulais un système où des GPTs créés pour cela traduiraient le contenu de chaque article en conservant :

• Mon style personnel.
• La même structure que l’article original.
• Les titres officiels de films, séries ou livres dans chaque langue (c’est-à-dire que si l’œuvre est en espagnol, la traduction devait reprendre le titre sous lequel elle est sortie en Italie, par exemple.
• Des slugs propres.
• Les alt des images traduits.
• Yoast avec les champs complets traduits, y compris la description.
• Des champs ACF personnalisés, pour que je puisse choisir s’ils sont exportés ou non, s’ils sont traduits ou s’ils restent comme ils étaient (par exemple, la note que je donne à chaque œuvre dans mes critiques).
• Des fragments HTML sans les casser: listes, gras, blocs de code… qu’ils soient conservés et que les parties nécessaires restent non traduites (comme les scripts de code).
• Les liens internes des articles: pour qu’ils pointent vers l’URL de chaque langue, et pas toujours vers l’originale.
• Date de publication: il faut conserver l’originale de l’article en espagnol.

Comme tu le vois, la logique derrière tout ça n’est pas « traduire et voilà ». Il y a beaucoup de tests derrière, et même quelques exclusions, comme le schéma qui, pour l’instant, reste seulement en espagnol.

Et, en plus, je voulais que ce soit un système gratuit, en utilisant des GPTs au lieu de l’API d’OpenAI ou de Claude. Plus manuel, mais moins coûteux.

La solution que j’ai adoptée comprend ces étapes :

1. Je publie un article en espagnol comme d’habitude.
2. J’utilise mon plugin pour exporter un JSON structuré, qui contient tout le contenu de l’article découpé pour sa traduction.
3. Un GPT traduit ce JSON dans les neuf langues, en me renvoyant neuf JSON (un par langue).
4. Le plugin importe les neuf JSON traduits.
5. Polylang relie chaque traduction à son original.
6. Les articles sont générés comme brouillons.
7. Je révise et/ou je publie.
8. Je répare les liens internes (automatiquement) si nécessaire.

En plus, il y a eu une étape initiale : créer la structure en plusieurs langues. Cela ne se fait que la première fois qu’il y a de nouvelles langues, ce qui dans mon cas est arrivé deux fois : la première pour les cinq langues initiales et la seconde pour les quatre autres.

Si l’on retire cette première tâche ponctuelle, le processus que j’ai conçu ajoute environ cinq minutes de plus à la préparation de chaque article seulement, tout en multipliant par neuf le contenu utile de mon site.

Pas mal.

La structure multilingue

Voyons :

• Site ultra personnalisé.
• Avec des textes d’interface.
• Une page d’accueil qui gardait presque tous ses textes dans le code.
• 23 catégories et sous-catégories, avec leurs en-têtes de modules, leurs nombreux textes dans des champs sur mesure et leurs variables SEO.
• 24 étiquettes aux caractéristiques similaires.
• Plusieurs modules sur mesure.
• Des plugins qui ne permettent pas le multilingue par défaut.

Et je ne sais pas si j’oublie autre chose.

Tout cela devait être traduit une fois par langue. Et cela m’aurait pris, je ne sais pas, au moins quatre heures dans chaque cas. En supposant en plus que je connaisse toutes les langues en question, ce qui n’est pas le cas.

Même pas en rêve.

Qu’ai-je fait ?

Eh bien, ce processus :

1. Adapter tous les textes en variables, dans le code et dans les champs personnalisés d’ACF..
2. Créer une fonctionnalité dans le plugin qui exporte toutes ces variables de chaque catégorie ou étiquette en JSON.
3. Créer un GPT qui traduit ce JSON dans la langue dont j’ai besoin.
4. Ajouter un importateur dans le plugin qui récupère le JSON traduit et crée la structure complète des taxonomies dans la nouvelle langue.
5. Répéter le processus avec chaque langue.
6. Changer les textes qui restaient en attente.

Plusieurs points m’ont donné du fil à retordre, comme les slugs dans les taxonomies, puisque Polylang de base ne permet pas de créer deux slugs identiques (seulement avec la version Pro).

Autrement dit, l’étiquette « comic » en espagnol ne pouvait pas être créée comme « comic » en anglais ; il fallait qu’elle soit « comic-en » ou quelque chose du genre.

J’ai développé le plugin pour le permettre, en conservant dominio.com/comic en espagnol et dominio.com/en/comic en anglais.

Yaarp (le plugin que j’utilisais pour les articles liés) me posait aussi des problèmes, je l’ai donc désactivé, car il recommandait des articles dans d’autres langues. Je lui créerai probablement à l’avenir une fonctionnalité qui priorise la langue par rapport aux autres variables dans ses recommandations.

La souscription à la liste dans les autres langues a aussi été écartée pour le lancement. Peut-être qu’à l’avenir je déciderai d’envoyer ma newsletter traduite, mais pour l’instant je ne vais pas le faire, donc je n’ai pas créé de nouvelles listes dans Acumbamail.

4. Le contenu déjà créé : petit à petit

Tout ce que je t’ai raconté fonctionne très bien pour les nouveaux articles, mais que se passe-t-il avec les plus de deux cents que j’ai déjà publiés ?

J’aimerais pouvoir te dire que j’ai créé une fonctionnalité qui automatise leur traduction, mais ce n’est pas le cas.

Le maximum auquel je suis arrivé, c’est de créer une fonctionnalité qui me génère des JSON exportés par lots de plusieurs articles, mais quand j’ai essayé de traduire plusieurs articles à la fois en neuf langues, le GPT les traite moins bien. Donc, pour l’instant, un par un.

En considérant que je mets environ trois minutes par article, il est assez simple de traduire dix articles par jour, ce qui ferait qu’en moins d’un mois j’aurais tout le site dans les dix langues.

Ça me convient.

J’ai aussi pensé à me monter un Hermes et à voir s’il le fait manuellement, mais comme pour l’instant je ne suis pas pressé et que cela ne me rapporte pas d’argent, je préfère ne pas dépenser plus de tokens que nécessaire.

Le résultat

Pour l’instant, je suis content. J’ai déjà plus de dix articles traduits en dix langues. Autrement dit, mon site a grandi de 33 % en une semaine.

Pour l’instant je ne force l’indexation de rien. Je veux attendre d’avoir au moins 50 ou 60 articles. Mais si ça s’indexe, ça ne m’inquiète pas non plus. C’est du long terme.

Ce que je peux te dire, c’est que je suis content du résultat. 

Je pense que le système que j’ai monté est assez robuste — avec ses améliorations probables, bien sûr — mais même dans mes meilleurs rêves, il y a un an, je n’aurais pas imaginé gérer un site multilingue avec ce volume de contenu.

Maintenant, comme je le dis toujours, on verra où tout cela me mène.

Enseignements du processus et conclusion

La principale conclusion — que j’avais déjà anticipée — est que traduire un site avec l’IA ne consiste pas à « traduire des textes », mais à concevoir un système.

L’IA est super utile si elle reçoit des entrées propres et renvoie des sorties contrôlées. Mais si tu lui donnes un énorme bloc, sans structure et sans règles, elle te renvoie quelque chose de joli, mais qui ne sert pas à l’import.

Crois-moi, cela m’est arrivé souvent au début de tout ça.

La clé a été de construire un système où chaque partie fait ce qu’elle doit faire:

• WordPress est le cœur de tout.
• Polylang relie les contenus.
• Le plugin exporte et importe.
• GPT traduit.
• Je prends les décisions éditoriales.

Savoir clairement où chaque pièce s’insère et pourquoi elle fait cela, et rien de plus, c’est ce qui m’a permis de créer un vrai système pour faire évoluer un site en utilisant la traduction par IA comme levier.

Si mon système t’a plu et que tu veux que je clarifie un point, laisse tes questions en commentaire et je te répondrai.