Traduire son site WordPress : le comparatif des extensions multilingues et de l’IA

Les extensions multilingues ne sont pas mortes, et elles ne le seront pas de sitôt. En avril 2020, cette même page vous annonçait qu’une fonction multilingue serait ajoutée "prochainement" dans le cœur de WordPress. J’ai relu la feuille de route officielle, modifiée le 20 août 2026 : le multilingue y occupe toujours la quatrième et dernière phase, sans la moindre date.

Donc, si vous voulez traduire votre site WordPress maintenant, il vous faut une extension ou un service (ou plusieurs installations reliées à la main). Et ce choix engage bien plus qu’on ne le croit… Selon l’outil, vos traductions vivent dans votre base de données, ou sur les serveurs d’un prestataire qui peut rendre votre site à sa langue d’origine le jour où vous arrêtez de payer.

Tous les prix de cette page ont été relevés le 29 septembre 2026 sur les pages officielles des éditeurs, et les chiffres d’installation viennent de wordpress.org le même jour. L’avis, lui, est le mien, et il est tranché.

WordPress va-t-il enfin gérer le multilingue tout seul ?

Pas à un horizon que vous pouvez inscrire dans un planning. La feuille de route de WordPress rappelle les grandes phases du projet Gutenberg : l’édition simplifiée, la personnalisation avec l’éditeur de site, la collaboration, puis une phase "Multilingual", décrite en une ligne : "Core implementation for Multilingual sites". Aucune date n’y est associée.

La même page précise que "Phase 3 is underway" : la collaboration, l’édition à plusieurs en temps réel, occupe le chantier en cours. Les grands objectifs affichés pour 2026 parlent du cœur et de WordPress 7.0, de l’IA, des meetups et des contributeurs. Le multilingue n’en fait pas partie.

Lors de ma lecture du 29 septembre 2026, la seule date projetée concernait WordPress 7.2, alors prévu pour le 10 décembre 2026, avec cet avertissement : "Projected dates below are for rough planning purposes only." Même les dates proches restent indicatives. Alors une phase qui n’a pas de date du tout…

La documentation officielle en anglais, mise à jour le 7 juillet 2025, le dit sans détour : "WordPress currently does not support a bilingual or multilingual blog out-of-the-box." Elle renvoie elle aussi à la quatrième phase du projet.

La version française, dont la dernière mise à jour remonte au 31 décembre 2021, ouvre sur le même constat : "WordPress ne propose pas de prise en charge native de la gestion multilingue."

N’attendez donc pas le cœur pour lancer un projet international. Et gardez en tête que rien, dans la feuille de route, ne dit comment cette phase 4 reprendra un jour ce que vous aurez traduit d’ici là.

Les 5 avantages d’un site WordPress multilingue

Avant l’outil, une question de fond. Traduire vaut-il vraiment l’effort ? Un site multilingue se maintient langue par langue, pendant des années : chaque page ajoutée en français devra exister en anglais, en allemand… Quand le travail est bien fait, voici ce qu’il rapporte.

Vendre au-delà de la France

L’argument le plus solide, chiffres à l’appui. Dans un communiqué du 9 juillet 2020, le cabinet CSA Research indique avoir interrogé 8 709 consommateurs dans 29 pays : 76 % des acheteurs en ligne préfèrent acheter avec des informations dans leur langue maternelle, et 40 % n’achètent jamais sur un site rédigé dans une autre langue.

Une réserve, tout de même : l’étude date de 2020, et elle vient d’un cabinet dont le métier est la localisation. Prenez ces chiffres comme un ordre de grandeur, et vérifiez la tendance dans vos propres données avant d’investir.

Rassurer avec un service client dans la langue

Une fiche produit traduite ne sert pas à grand-chose si la réponse au message du client arrive en français. Le formulaire de contact, les e-mails de commande, le service après-vente : tout ce qui suit l’achat compte autant que la vitrine. Soyez réaliste avec vos ressources humaines. Si personne ne parle japonais dans l’équipe, ne promettez pas un support en japonais.

Être repris par des médias étrangers

Un journaliste ou un blogueur étranger relaie plus volontiers une page qu’il peut lire et citer dans sa langue. Une page traduite ouvre la porte à des liens et à des mentions que vous n’auriez jamais obtenus avec la seule version française.

Viser des requêtes moins disputées

La concurrence sur un mot-clé change du tout au tout d’une langue à l’autre. Une requête saturée en anglais peut être peu travaillée en espagnol, et l’inverse existe aussi. Ne le supposez pas : vérifiez-le requête par requête, avec un outil de mots-clés réglé sur le bon pays et la bonne langue.

Répondre aux attentes de votre secteur

Le tourisme, la formation en ligne et le e-commerce sont, à mon sens, les secteurs les plus concernés. Pour savoir si c’est votre cas, commencez par le rapport des utilisateurs par pays de Google Analytics 4. Il vous montre d’où viennent déjà vos visiteurs, avant même d’avoir traduit une ligne.

Préparer la traduction : langues, marché, localisation

La partie la plus négligée d’un projet multilingue se joue avant d’installer quoi que ce soit. Choisir les langues, comprendre le marché, décider qui traduit : ces décisions pèsent bien plus lourd sur la qualité finale que le choix de l’extension.

Quelles langues, et combien ?

Partez de vos données. Les pays qui vous visitent déjà, et ceux où vous vendez, donnent la première liste. Puis vient la question qui fâche. Combien de langues pouvez-vous maintenir, vraiment ? Un site vitrine qui bouge deux fois par an n’a rien à voir avec un blog qui publie chaque semaine, où chaque nouvel article devra être traduit, relu et mis en ligne dans toutes les langues.

Certains pays imposent plusieurs langues d’un coup. Le Canada fonctionne en anglais et en français, la Belgique en français, en néerlandais et en allemand, la Suisse en allemand, en français et en italien (sans oublier le romanche). Viser un de ces marchés avec une seule langue laisse une partie du public sur le pas de la porte.

Étudiez le marché

Pour chaque pays visé, posez les questions de base : quels appareils vos futurs clients utilisent, par quels réseaux sociaux ils passent, comment ils préfèrent vous contacter (e-mail, téléphone, messagerie), quels moyens de paiement ils attendent. Les réponses changent d’un pays à l’autre, et elles pèsent autant que la traduction elle-même.

Côté référencement, refaites l’étude de mots-clés dans chaque langue : on ne cherche pas avec les mêmes mots en France, au Québec ou en Belgique. Google Trends, réglé sur le bon pays, donne une première idée des tendances, et un outil de mots-clés payant affinera les volumes. Pour les bases, ma checklist SEO WordPress s’applique à chaque langue.

Décidez par qui et comment le site sera traduit

Humain ou machine, il faut choisir. La traduction automatique a fait des progrès énormes, et je ne l’exclus pas, au contraire. Toutefois, une traduction mot à mot rate tout ce qui fait la couleur d’une langue. Prenez "c’est pas Versailles ici !", qu’on lance quand toutes les lumières restent allumées. Dites "This is not Versailles" à un anglophone, la référence tombera à plat.

Même chose pour "mon petit doigt me l’a dit", qui devient en anglais "a little bird told me" (un petit oiseau, donc). Mon conseil : que la traduction vienne d’un humain ou d’une machine, faites relire chaque langue par une personne qui la parle couramment, idéalement native. J’y reviens plus bas avec les coûts réels de l’IA.

Traduction ou localisation ?

Traduire change les mots ; localiser adapte l’offre au pays. La nuance paraît académique jusqu’au jour où un client suisse tombe sur des prix en euros… Voici ce qu’il faut adapter en plus du texte :

• la devise et l’affichage des prix, avec ou sans taxes selon le pays ;
• les moyens de paiement et les conditions de livraison ;
• les mentions légales, les conditions générales et la politique de confidentialité ;
• les formats de date, d’heure et de numéro de téléphone, indicatif du pays compris (un +33 oublié, et le client étranger ne vous joint plus) ;
• les photos, les exemples et l’humour, qui ne voyagent pas tous ;
• la longueur des textes : "BOOK NOW" devient "RÉSERVEZ MAINTENANT", et le bouton doit l’encaisser, surtout sur mobile.

Langues RTL : prévoir le sens de lecture

L’arabe et l’hébreu se lisent de droite à gauche. Si ces marchés sont dans vos plans, votre thème doit gérer l’écriture RTL (right-to-left) : alignements, menus, icônes directionnelles. Un point à vérifier dès que vous choisissez un thème WordPress.

Polylang, par exemple, indique sur sa fiche que "RTL scripts are supported", mais le rendu final dépend du thème. Testez-le avant de promettre une version arabe.

Une page, une langue

Ne mélangez pas les langues sur une même page. Google détermine la langue d’une page à partir de son contenu visible, et vous aide à la reconnaître "by using a single language for content and navigation on each page, and by avoiding side-by-side translations". Traduire le menu en laissant l’article en français ne crée donc pas une page anglaise.

Pire, Google précise que des versions localisées ne sont vues comme des doublons que si le contenu principal reste non traduit : "Localized versions of a page are only considered duplicates if the main content of the page remains untranslated." Une page dont seul le menu est traduit tombe exactement dans ce cas.

Même logique pour vos liens internes : un bouton "Learn more" posé sur une page anglaise doit mener à la page anglaise correspondante. L’erreur est facile à commettre quand chaque traduction est une page à part.

Le sélecteur de langue, sans drapeaux si possible

Le sélecteur doit être visible sur toutes les pages, en général dans l’en-tête ou le pied de page, et mener à la même page dans l’autre langue plutôt qu’à l’accueil. Écrivez chaque langue dans sa propre langue : "Deutsch", "Español", "Italiano". Et méfiez-vous des drapeaux, qui désignent des pays. Quel drapeau choisir pour l’espagnol, celui de l’Espagne ou celui du Mexique ?

Comment traduire un site WordPress : quelles architectures possibles ?

Il existe plusieurs façons de rendre un WordPress multilingue, et elles diffèrent sur un point qu’on oublie souvent : l’endroit où vivent vos traductions. De lui dépendent l’indexation par Google, le poids de votre base et, surtout, ce qui vous reste le jour où vous changez d’outil.

Architecture	Exemples	Où sont les traductions	Pages indexables	Si vous arrêtez l’outil
Un contenu par langue, dans la même base	Polylang, WPML	Dans votre base, sous forme d’articles et de pages WordPress	Oui	Les contenus traduits restent des publications WordPress
Traduction de la page générée, dans la même base	TranslatePress	Dans votre base, au format de l’extension	Oui	Traductions conservées si vous ne renouvelez pas la licence
Des sites séparés	Un WordPress par langue, sur un domaine ou un sous-domaine	Dans chaque site	Oui	Rien à perdre, mais les liens entre langues sont à votre charge
Un multisite	MultilingualPress, Multisite Language Switcher	Dans chaque site du réseau	Oui	Chaque site continue de fonctionner, seul le lien entre les traductions disparaît
Un service de traduction en ligne	Weglot, GTranslate payant	Sur les serveurs de l’éditeur	Oui, avec une URL par langue	Chez Weglot, le site n’est plus traduit
Un widget JavaScript	GTranslate gratuit	Nulle part : traduction à la volée dans le navigateur	Non	Rien à récupérer

La documentation française de WordPress résume bien l’intérêt de la première famille, celle des extensions qui créent une publication par langue : "Le contenu de la base de données de chaque publication demeure intact (cela facilite l’installation et la désinstallation de l’extension)." Le revers : la base grossit à chaque langue ajoutée.

Les services en ligne jouent dans une autre catégorie. Weglot, sur WordPress, traduit côté serveur mais stocke tout chez lui. GTranslate payant fonctionne en proxy : il sert une copie traduite de vos pages depuis ses serveurs.

Le widget, lui, traduit dans le navigateur sans rien stocker, et GTranslate l’écrit franchement pour sa version gratuite : "translated pages do not have separate URLs, so they are not indexed and do not provide SEO benefits".

Le multisite, pour les réseaux de sites

Reste le multisite, plus technique : un site du réseau par langue, reliés entre eux par une extension. La documentation française y voit un avantage, "chaque langue est un site WordPress normal avec des publications classiques", et un inconvénient : il faut se connecter à chaque site pour en gérer le contenu.

Multisite Language Switcher est la solution gratuite de cette famille. Elle relie les traductions d’un réseau multisite, "whether using multiple subdomains or folders", sans offre payante à acheter.

Attention au piège de cette fiche : elle correspond à l’ancienne branche gratuite de MultilingualPress, restée en version 2.11.3, mise à jour pour la dernière fois le 24 janvier 2025 et testée jusqu’à WordPress 5.2.28. La version commerciale, 5.3.0, mise à jour le 7 septembre 2026, se vend sur multilingualpress.org.

Une fiche testée jusqu’à WordPress 5.2 seulement est le signe typique des extensions WordPress abandonnées : n’installez pas cette branche.

Sur son site, l’éditeur affirme que vous gardez vos traductions même en désactivant l’extension : "Retain every translation you’ve created, even if you deactivate the plugin". Logique, puisque chaque traduction est un contenu normal de son site. Le prix, en revanche, se situe dans le haut du panier, on le verra plus bas.

URL, hreflang, slugs : ce que Google attend d’un site multilingue

Quelle que soit l’extension, Google lit votre site de la même façon. Ses règles tiennent en quelques pages de documentation, relues le 29 septembre 2026, et elles sont plus simples qu’on ne le dit. Si vous partez de zéro, les bases du SEO multilingue sur WordPress posées ici en 2016 restent une bonne introduction.

Une URL par langue, de préférence en sous-répertoire

Premier principe, sans ambiguïté, dans le guide de Google sur les sites multilingues : "Google recommends using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language on the page." Pas de langue stockée dans un cookie, donc, ni devinée d’après le navigateur.

Pour la forme, Google compare les structures dans un tableau. Le domaine par pays (exemple.de) cible nettement un pays mais demande plus d’infrastructure. Le sous-domaine (de.exemple.com) reste facile à mettre en place. Le sous-répertoire (exemple.com/de/) est jugé "Easy to set up" et "Low maintenance (same host)". Le paramètre d’URL (exemple.com?loc=de), lui, est classé "Not recommended".

Je conseille le sous-répertoire à la grande majorité des sites vitrines et des blogs : un seul hébergement (voyez mon comparatif des hébergeurs WordPress), une seule installation, un seul certificat. Le domaine par pays se justifie quand vous avez une vraie présence locale, avec des prix, des stocks ou une entité propres au pays.

Hreflang : la réciprocité ou rien

La balise hreflang indique à Google qu’une page existe dans d’autres langues, et laquelle montrer à qui. Elle se déclare dans le code HTML, dans un en-tête HTTP ou dans le sitemap XML, et selon la documentation de Google sur les versions localisées, "the three methods are equivalent from Google’s perspective".

Les extensions sérieuses la génèrent pour vous : votre travail consiste à vérifier qu’elle est juste.

Chaque version doit se citer elle-même et citer toutes les autres : "Each language version must list itself as well as all other language versions." Le lien doit aussi être réciproque, sinon Google l’ignore : "If two pages don’t both point to each other, the tags will be ignored." Voici, pour une page de tarifs en trois langues, le bloc que chaque version porte à l’identique dans son en-tête :

<link rel="alternate" hreflang="fr" href="https://exemple.com/tarifs/" />
<link rel="alternate" hreflang="en" href="https://exemple.com/en/pricing/" />
<link rel="alternate" hreflang="de" href="https://exemple.com/de/preise/" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/en/pricing/" />

La dernière ligne, x-default, désigne la page à montrer quand aucune langue ne correspond. Google la conseille "especially on language/country selectors or auto-redirecting home pages". Polylang ne la pose que sur la page d’accueil redirigée automatiquement, et son filtre pll_rel_hreflang_attributes sert à ajuster les valeurs.

Weglot, de son côté, écrit que "la balise hreflang x-default n’est pas nécessaire pour la plupart des sites web et n’est pas ajoutée par défaut par Weglot", et documente le filtre weglot_href_lang pour l’ajouter. Dernier piège, les codes : Google n’accepte que les langues ISO 639-1 et les régions ISO 3166-1 Alpha 2, et un code comme es-419 (l’espagnol d’Amérique latine) n’est pas pris en charge.

Faut-il traduire les slugs ?

Oui : le visiteur lit mieux une URL dans sa langue, et Google l’accepte, "It’s fine to use localized words in the URL", à condition d’encoder l’URL en UTF-8. Une page /en/pricing/ parle mieux à un anglophone qu’une page /en/tarifs/. Reste à savoir quelle offre le permet, car les extensions se différencient justement là :

• Polylang : chaque traduction est une publication à part, avec son propre slug, dès la version gratuite (partager le même slug entre langues est d’ailleurs réservé à la version Pro), et Polylang Pro ajoute la traduction des bases d’URL (catégories, auteurs, types de contenus personnalisés) ;
• WPML : l’éditeur indique que, "par défaut, WPML crée automatiquement un slug d’URL traduit lorsque vous traduisez du contenu" ;
• TranslatePress : la traduction des slugs ("URL Slug Translation") figure dans l’offre Personal, à 99 € par an ;
• Weglot : les URL traduites ("translated URLs") n’apparaissent qu’à partir de l’offre Pro, à 790 € HT par an.

Redirection automatique : Google dit non

La version 2020 de cette page vous conseillait de rediriger vos visiteurs selon leur localisation ou la langue de leur navigateur. C’était une erreur, et je la corrige. Google écrit l’inverse : "Avoid automatically redirecting users from one language version of a site to a different language version of a site. For example, don’t redirect based on what you think the user’s language may be."

La raison suit : ces redirections "could prevent users (and search engines) from viewing all the versions of your site". Google ajoute que son robot "usually originates from the USA" et envoie ses requêtes sans en-tête de langue (Accept-Language) : une redirection automatique peut donc lui cacher vos versions traduites.

Plusieurs outils proposent pourtant l’option : la détection automatique de la langue de TranslatePress (offre Business), la redirection selon la langue du navigateur de Weglot, ou celle de WPML, que WPML lui-même déconseille : "nous recommandons de laisser les visiteurs sélectionner manuellement leur langue à l’aide d’un sélecteur de langue".

Mon conseil : laissez l’option désactivée. Proposez plutôt la langue, par un lien ou un bandeau discret, comme le suggère Google : "Consider adding hyperlinks to other language versions of a page."

Serveur ou JavaScript : ce que Googlebot voit vraiment

Une traduction qui n’existe que dans le navigateur du visiteur n’existe pas pour Google. Sa documentation le formule avec prudence : si vous changez le contenu dynamiquement selon la langue, "Google might not find and crawl all your variations". Le widget gratuit de GTranslate l’assume : pas d’URL distincte, pas d’indexation.

Weglot, sur WordPress, traduit côté serveur, et sa documentation SEO l’explique en français : "Weglot traduit le contenu côté serveur, ce qui signifie que votre contenu est traduit dans votre code source et pas seulement de manière dynamique".

Pour vérifier n’importe quelle solution, l’outil d’inspection d’URL de la Search Console affiche le code HTML que Google récupère. Si le texte traduit n’y figure pas, la page n’est pas traduite pour lui.

Que dit Google en 2026 de la traduction automatique ?

Pendant des années, la consigne a nourri la peur de la traduction automatique. Jusqu’au printemps 2025, la documentation multilingue de Google disait encore : "Use robots.txt to block search engines from crawling automatically translated pages on your site. Automated translations don’t always make sense and could be viewed as spam." La version 2020 de cette page relayait la même crainte.

Le 11 juin 2025, Google a retiré ce passage. Son journal des mises à jour l’explique en une ligne : "Removed a section from our multilingual documentation about using robots.txt to block all automatically translated pages." Le motif : s’aligner sur la mise à jour de sa politique anti-spam de mars 2024. Et une précision qui change la lecture : "This is a docs-only change, no change in behavior."

Dans sa documentation, Google a donc cessé de traiter la traduction automatique à part. La règle qui s’applique est celle de l’abus de contenu à grande échelle ("scaled content abuse"), définie dans ses règles anti-spam comme la génération de nombreuses pages "for the primary purpose of manipulating search rankings and not helping users", et ce "no matter how it’s created".

La traduction y figure en toutes lettres parmi les exemples : produire beaucoup de pages "including through automated transformations like synonymizing, translating, or other obfuscation techniques", quand elles apportent peu de valeur.

Traduire à la machine 2 000 fiches produits sans relecture, juste pour occuper le terrain en espagnol, entre dans le cadre. Un site traduit et relu pour servir de vrais clients hispanophones n’y entre pas.

Les consignes de Google sur l’IA générative vont dans le même sens, et visent jusqu’aux métadonnées : "focus on accuracy, quality, and relevance, especially when automatically generating the content. This includes metadata like <title> elements, meta description elements, structured data, and alternate texts for images".

Titres, descriptions, textes alternatifs des images : tout ce qu’une extension traduit en silence mérite la même relecture que le corps du texte. Les descriptions et les textes alternatifs ne s’affichent pas dans la page : raison de plus pour les relire.

Dernier point, plus discret. Google traduit déjà lui-même certains résultats : il peut afficher un titre et un extrait traduits à un internaute qui cherche dans une autre langue, et cela dans 21 langues, dont le français. Il le précise : "Google doesn’t host any translated pages." Ce service ne crée aucune version indexée dans cette langue, et vous pouvez le refuser avec la règle notranslate.

Polylang, WPML, TranslatePress, Weglot : mon comparatif

Place à l’avis. J’ai essayé WPML, j’ai essayé Polylang, j’ai essayé Weglot. Celui que je préfère, c’est clairement Polylang, parce que je trouve que c’est le plus simple et qu’on est propriétaire de ses traductions. Et puis demain, on arrête de payer l’abonnement, on a toujours nos traductions qui sont disponibles, ce qui n’est pas le cas notamment avec Weglot.

WPML, c’est beaucoup trop lourd, c’est une usine à gaz, c’est totalement insupportable. Dès que je vois un site avec WPML, j’essaye de faire changer pour passer à un plugin de multilingue qui n’est pas aussi pénible. Voilà pour le fond de ma pensée…

Ça fait une bonne décennie que je bricole des sites WordPress, et mon avis vient de là. Mais un avis tranché ne dispense pas des faits. Pour ce comparatif, je n’ai pas monté de laboratoire : je juge sur pièces, avec la documentation de chaque éditeur, ses pages de prix relevées le 29 septembre 2026 et les chiffres publics de wordpress.org du même jour.

Le tableau ci-dessous indique, fonction par fonction, à partir de quelle offre chaque extension la propose. Prix affichés le 29 septembre 2026 : hors taxes chez Polylang et Weglot, taxes non précisées chez WPML et TranslatePress.

Fonction	Polylang	WPML	TranslatePress	Weglot
Offre d’entrée	Gratuite, sans limite de langues	Multilingual Blog, 39 € par an	Gratuite	Free : 2 000 mots, 1 langue
Slugs traduits	Gratuit pour les publications ; bases d’URL avec Pro (99 € par an)	Automatique, selon l’éditeur	Personal (99 € par an)	Pro (790 € par an)
Traduction automatique	Pro : DeepL avec votre clé, hors Elementor	Multilingual CMS : 22 500 mots d’IA inclus	Gratuit : 2 000 mots d’IA ; Personal : 50 000 ; DeepL avec Business (199 € par an)	Comprise dans le quota de mots
WooCommerce	Polylang for WooCommerce, 99 € par an	Multilingual CMS (99 € par an)	Compatible dès la version gratuite	Oui, selon la fiche wordpress.org
Parties de modèle (éditeur de site)	Pro	Multilingual CMS	Traduites sur la page affichée	Traduites dans le code source servi
Où sont les traductions	Votre base	Votre base (tables de WPML)	Votre base	Serveurs de Weglot
Si vous ne payez plus	Pro continue, sans mises à jour ni support	Continue et affiche les traductions, sans mises à jour	Traductions conservées, IA et certaines fonctions premium coupées	Site plus traduit ; export CSV ou XLIFF réservé à Advanced (2 990 € par an)
Installations actives (wordpress.org, 29/09/2026)	+800 000	Non publiées (hors wordpress.org)	+400 000	+50 000

Polylang, mon choix par défaut

Polylang a ma préférence, pour les raisons dites plus haut. Sa fiche, relevée sur wordpress.org le 29 septembre 2026 :

Polylang s’appuie sur une brique native de WordPress, les taxonomies, pour rattacher chaque contenu à une langue ("using only its built-in core features (taxonomies)"), sans limite de langues. La version gratuite traduit articles, pages, médias, catégories, étiquettes, types de contenus personnalisés, menus et widgets classiques, avec un sélecteur disponible en bloc.

Polylang Pro, à 99 € HT par an avec un renouvellement à moitié prix, ajoute la traduction des bases d’URL, la duplication et la synchronisation des contenus, l’import et l’export XLIFF pour vos traducteurs, et DeepL avec votre propre clé API. Attention, l’éditeur prévient que cette intégration DeepL est "currently not compatible with Elementor".

Ses limites ? Elle vous laisse le travail : chaque traduction est une publication à créer, à relire et à tenir à jour. C’est justement ce qui me plaît, parce que le résultat reste du WordPress standard, lisible par n’importe quel outil. Le tutoriel Polylang pas à pas publié ici en 2020 reste utile pour les écrans principaux, même si ses tarifs et sa partie sur Lingotek sont dépassés.

WPML, complet mais lourd

WPML n’est pas distribué sur wordpress.org : sa fiche y est fermée depuis le 28 novembre 2017, et l’extension se télécharge sur wpml.org. Pas de fiche à afficher ici, donc, ni de compteur d’installations public. L’éditeur annonce "65 langues et plus", mais sa diffusion réelle échappe à toute statistique indépendante.

Techniquement, WPML crée lui aussi une publication par langue, et range les liens entre traductions dans ses propres tables, dont icl_translations. Sa documentation technique en donne un exemple limpide : un article anglais d’identifiant 3 et sa traduction espagnole d’identifiant 7, reliés par un même numéro de groupe de traduction.

L’offre d’entrée, Multilingual Blog à 39 €, exclut beaucoup de choses : String Translation, la traduction des menus, les constructeurs de pages, WooCommerce et l’éditeur de site y sont marqués "Not included". Dans la pratique, visez Multilingual CMS à 99 € (3 sites en production, 22 500 mots de traduction par IA inclus), ou Multilingual Agency à 199 € pour un nombre de sites illimité.

Je lui reconnais de vrais atouts : la gestion d’équipes de traducteurs et de services de traduction professionnels, un moteur d’IA maison baptisé PTC, et une bonne tenue quand on arrête de payer, puisque "WPML will continue to work on your site and all translations will keep showing up". Sans mises à jour, en revanche, ce que WPML qualifie lui-même de risque pour votre site.

Pour une grosse structure qui fait travailler des traducteurs dédiés, WPML a sa place. Pour un site de PME, je le trouve disproportionné. Le tutoriel WPML de 2020 donne d’ailleurs une bonne idée de l’étendue des réglages.

TranslatePress, la traduction sur la page

TranslatePress prend le problème à l’envers : on traduit directement sur la page affichée, dans un éditeur visuel.

TranslatePress ne duplique pas vos publications, et ses traductions restent chez vous : "All the translations are stored locally in your server’s database." L’extension traduit "the entire page at once, including output from shortcodes, forms and page builders", et annonce une compatibilité WooCommerce dès la version gratuite.

La version gratuite inclut 2 000 mots de traduction par IA et l’intégration de Google Traduction avec votre propre clé. L’offre Personal, à 99 € par an, ajoute la traduction des slugs, le pack SEO (titres, descriptions, balises sociales) et les langues supplémentaires, avec 50 000 mots d’IA. DeepL n’arrive qu’avec l’offre Business, à 199 € par an.

Sur mon critère numéro un, TranslatePress coche la case. Si vous ne renouvelez pas, "You’ll still own your existing translations and they will continue to function normally on your website", et le quota de mots d’IA se recharge à chaque renouvellement.

Mon bémol tient au modèle : la documentation française de WordPress note, pour cette famille, qu'"il y a un lien fort entre le contenu et sa traduction, donc les modifications sur le contenu d’origine risquent de casser ses traductions".

Weglot, le confort qui se loue

Weglot est le plus rapide à mettre en place : vous installez l’extension, collez une clé API, choisissez vos langues, et le site est traduit.

Sa fiche annonce une traduction automatique "powered by DeepL, Google Translate, and Microsoft Translator", plus un modèle d’IA personnalisé basé sur OpenAI et Gemini. Sur WordPress, la traduction se fait côté serveur, avec un sous-répertoire par langue et des balises hreflang ajoutées automatiquement.

Le modèle économique est un abonnement au mot. Chaque offre plafonne le nombre total de mots traduits, toutes langues confondues, et la page de prix de Weglot précise : "This is a fixed limit and does not renew." Au-delà, soit vous montez d’offre, soit "the translations will be discontinued" jusqu’à ce que vous repassiez sous la limite.

Weglot a du sens pour un petit site, sous les 2 000 mots de l’offre gratuite, ou pour une équipe qui gère aussi des sites hors WordPress avec le même outil. Au-delà, lisez la partie sur la propriété des traductions avant de signer.

GTranslate et la fin de l’ancien widget de Google

GTranslate propose une version gratuite et des offres payantes qui ne fonctionnent pas du tout de la même façon.

La version gratuite est un widget JavaScript qui traduit dans le navigateur, à l’aide d’un cookie ou d’une session : aucune URL par langue, donc aucune indexation. Les offres payantes, de 12 à 50 $ par mois (120 à 500 $ par an), fonctionnent en proxy : "We host the translated versions of your website on our cloud network". Vos traductions vivent alors chez GTranslate, comme chez Weglot.

Le même éditeur gère aussi Google Language Translator, une extension qui s’appuyait sur l’ancien widget de Google Traduction.

Les deux fiches annoncent la même chose : leurs versions de septembre 2026 (5.0.1 et 7.0.1) remplacent l’ancien widget "Google Website Translator" par celui de GTranslate, "following Google’s announcement that support for its old widget ends on October 1, 2026".

Je n’ai pas retrouvé cette annonce dans la documentation de Google. Son billet de mai 2020 réservait déjà ce widget aux sites publics, associatifs ou non commerciaux engagés contre la COVID-19, et renvoyait tous les autres vers l’API Cloud Translation. Si un site que vous gérez colle encore ce widget à la main, remplacez-le.

Combien coûte un site multilingue sur 1 an et sur 3 ans ?

Les prix de départ ne disent rien du coût réel. J’ai donc fait le calcul, explicitement, à partir des pages de prix officielles relevées le 29 septembre 2026. Le scénario : un site vitrine de 20 pages d’environ 500 mots, traduit en deux langues. Weglot prend lui-même cet exemple sur sa page de prix, soit 20 000 mots traduits.

Solution et offre	Pourquoi cette offre	Année 1	Sur 3 ans	Base du calcul
Polylang gratuit	Contenus, menus, sélecteur, langues illimitées	0 €	0 €	Traduction à votre charge
Polylang Pro	Bases d’URL traduites, DeepL avec votre clé	99 € HT	198 € HT	99 €, puis deux renouvellements à 50 % (49,50 €)
TranslatePress Personal	Langues supplémentaires, slugs, pack SEO	99 €	297 €	Renouvellement supposé au même prix ; TVA non précisée
WPML Multilingual CMS	Menus et String Translation, exclus de l’offre Blog	99 €	297 €	Renouvellement supposé au même prix ; TVA non précisée
Weglot Business	50 000 mots, 3 langues	290 € HT	870 € HT	Tarif annuel reconduit à l’identique, slugs non traduits
Weglot Pro	Nécessaire pour traduire les URL	790 € HT	2 370 € HT	Tarif annuel reconduit à l’identique
GTranslate Startup	L’offre Custom est présentée comme bilingue	250 $	750 $	Tarif annuel en dollars, reconduit à l’identique ; TVA non précisée
MultilingualPress professional	3 langues au total, l’offre starter n’en compte que 2	499 € TTC	1 497 € TTC	Tarif annuel reconduit à l’identique, multisite obligatoire

Sur un petit site vitrine, les écarts restent supportables. Polylang, TranslatePress et WPML coûtent entre 0 et 297 € sur trois ans, Weglot entre 870 et 2 370 € HT selon que vous voulez des URL traduites ou non, MultilingualPress près de 1 500 € TTC.

Et si votre site grossit ? Tout bascule. Prenons un blog de 300 articles d’environ 1 000 mots, traduit dans une seule langue : 300 000 mots. Chez Weglot, l’offre Pro plafonne à 200 000 mots, il faut donc l’offre Advanced, à 2 990 € HT par an, soit 8 970 € HT sur trois ans. Chez Polylang, TranslatePress ou WPML, la licence ne bouge pas.

Seul le coût de la traduction augmente, et les traductions payées restent chez vous. C’est tout l’enjeu de la partie suivante.

À qui appartiennent vos traductions le jour où vous arrêtez de payer ?

Pour moi, c’est la question qui décide, avant la qualité de traduction et avant le prix. Mon passage chez Weglot, en 2020, m’a servi de leçon.

Cette année-là, j’ai traduit wpformation.com en anglais avec Weglot. Le site comptait plus de 500 articles d’environ 1 000 mots. J’ai dû passer à l’offre Pro, 200 000 mots, en un rien de temps, pour quasiment 500 euros par an… et ça ne suffisait toujours pas pour traduire le site en entier. J’ai suspendu la licence. Le retour d’expérience Weglot publié en 2020 raconte l’épisode.

Le 29 septembre 2026, la même offre Pro affichait 790 € HT par an. Et pour plus de 500 000 mots dans une seule langue, seule l’offre Advanced (1 000 000 de mots, 2 990 € HT par an) passerait. Mais le prix n’est pas le fond de l’affaire. Le vrai sujet, c’est ce qui se passe quand on arrête.

Chez Weglot, la réponse est écrite sur sa propre fiche : "If you decide to stop using Weglot, your website will no longer be translated. All translations are stored on Weglot’s servers." La fiche ajoute que vous pouvez exporter vos traductions avant de partir.

Sauf que l’aide de Weglot, mise à jour le 29 septembre 2026, précise : "The import/export feature is available for Advanced and higher plans."

Traduisez : sur les offres Free, Starter, Business et Pro, pas d’export en masse. Vos milliers de phrases traduites, relues, parfois corrigées à la main, restent chez Weglot. Et le fichier exporté, quand vous y avez droit, contient des paires de phrases en CSV ou en XLIFF, qu’il faudra réimporter dans un autre outil.

Chez les autres, les éditeurs le disent eux-mêmes :

• WPML : "WPML will continue to work on your site and all translations will keep showing up", sans mises à jour ;
• Polylang Pro : sans renouvellement, "the plugin will continue to operate" sans mises à jour automatiques ni support, et la version gratuite n’a aucune licence à renouveler ;
• TranslatePress : traductions conservées dans votre base, mais plus d’accès à l’IA ni aux nouveautés ;
• MultilingualPress : l’éditeur promet que vous gardez vos traductions même en désactivant l’extension ;
• GTranslate payant : les traductions sont hébergées sur son réseau, comme chez Weglot.

Voilà pourquoi je préfère Polylang : on est propriétaire de ses traductions. Ce qu’on y traduit devient des articles et des pages WordPress, dans sa propre base, qu’on peut sauvegarder et exporter avec les outils de WordPress. Le jour où l’on change d’avis, on ne repart pas de zéro.

Traduction par IA : combien coûtent DeepL, Google et les modèles d’IA ?

La traduction automatique a fait un bond, et les extensions l’intègrent toutes, sous des formes très différentes. Certaines vendent un quota de mots inclus dans la licence, d’autres vous demandent votre propre clé d’API, facturée à part par le fournisseur. Voici les tarifs relevés le 29 septembre 2026. Ils complètent mon calcul du vrai coût de l’IA sur WordPress.

Moteur ou service	Comment l’utiliser dans WordPress	Tarif relevé
Google Cloud Translation (modèle NMT)	Votre clé API dans TranslatePress ou Loco Translate	500 000 premiers caractères par mois gratuits (crédit de 10 $), puis 20 $ par million de caractères
Google Cloud Translation (LLM de traduction)	Via l’API Cloud Translation	10 $ par million de caractères en entrée et 10 $ par million en sortie
DeepL API	Votre clé dans Polylang Pro, TranslatePress Business ou Loco Translate	API Free et API Pro plus commercialisées ; Developer : 1 000 000 de caractères au total, non renouvelés ; Growth : offre suivante, plafonnée à 50 millions de caractères par mois
OpenAI (modèles GPT-6)	Votre clé API dans Loco Translate ou MultilingualPress ; intégré à TranslatePress AI et au modèle d’IA de Weglot	Par million de jetons, traitement standard et contexte court : de 0,10 $ (gpt-6-luna) à 10 $ (gpt-6-astra) en entrée, de 0,50 $ à 50 $ en sortie
Gemini (Gemini 3.8 Flash)	Intégré à TranslatePress AI et au modèle d’IA de Weglot	Par million de jetons : 0,75 $ en entrée et 3,75 $ en sortie jusqu’au 31 décembre 2026, puis 1,50 $ et 7,50 $ à partir du 1er janvier 2027 ; l’offre gratuite sert à améliorer les produits de Google
TranslatePress AI (Gemini, GPT, DeepL, Google)	Inclus dans les licences	2 000 mots gratuits, 50 000 à 500 000 mots selon l’offre, recharge de 100 000 mots à 24 €
PTC, le moteur de WPML	Inclus dans Multilingual CMS et Agency	22 500 ou 45 000 mots inclus, puis "moins de 0,002 € par mot" selon WPML
Weglot	Inclus dans l’abonnement	Compris dans le quota de mots ; traducteurs professionnels à partir de 0,13 € par mot

Nota : OpenAI et Gemini facturent au jeton, une unité différente du mot et du caractère. Mesurez la consommation réelle sur un article type avant de budgéter un site entier.

Pour estimer votre volume chez Google Cloud Translation, le compteur de caractères de votre traitement de texte suffit sur un article type. Un exemple de calcul avec le tarif ci-dessus : 3 millions de caractères traduits dans le mois donnent 500 000 caractères gratuits, puis 2,5 millions facturés, soit 50 $.

À l’autre bout, la traduction humaine. Weglot affiche ses traducteurs professionnels à partir de 0,13 € par mot : pour les 20 000 mots de notre site vitrine, comptez au moins 2 600 €. WPML annonce moins de 0,002 € par mot pour PTC, soit moins de 40 € pour le même volume. L’écart est d’au moins 1 à 65.

Faut-il alors tout confier à la machine ? Non. Je vous invite plutôt à procéder ainsi : traduction automatique pour le premier jet, relecture par une personne native sur les pages qui vendent (accueil, offres, tunnel de commande, e-mails), puis le reste au fil de l’eau.

Je parle d’expérience : en 2020, sur wpformation.com, quelques coquilles se cachaient dans la traduction automatique de Weglot, et une relecture s’est imposée.

Ajoutez un glossaire dès le départ pour vos noms de produits et vos termes métier, que Weglot et Polylang Pro, avec les glossaires DeepL, savent appliquer.

Traduire le thème et les extensions : le rôle de Loco Translate

Traduire vos contenus ne suffit pas. Les textes du thème et des extensions (boutons, messages d’erreur, libellés de formulaire) vivent dans des fichiers de langue au format .po et .mo. WordPress télécharge les traductions officielles quand elles existent. Pour les chaînes manquantes ou mal traduites, il reste Loco Translate.

Loco Translate édite ces fichiers dans l’administration de WordPress, extrait les chaînes à traduire du code source et se branche sur des API de traduction automatique, "including DeepL, Google, Lecto, Microsoft and OpenAI". L’extension est gratuite ("You don’t need a Loco account to use it") : les offres payantes que vous croiserez concernent la plateforme en ligne Loco, un service distinct.

Un réflexe à prendre : enregistrez vos traductions personnalisées dans le dossier protégé que propose l’extension ("Protected language directory for saving custom translations"). Sinon, la prochaine mise à jour du thème ou de l’extension écrasera votre travail. Et n’hésitez pas à la combiner avec Polylang ou WPML : elle traduit l’interface, eux traduisent vos contenus.

WooCommerce et éditeur de site : quelles extensions suivent ?

Avec une boutique ou un thème de blocs, les offres d’entrée montrent vite leurs limites. Mieux vaut le savoir avant d’acheter.

Une boutique WooCommerce multilingue

Une boutique multiplie les objets à traduire : produits, variations, attributs, pages panier et commande, e-mails transactionnels… Et chaque langue ajoutée alourdit la base. La documentation française de WordPress donne l’ordre de grandeur : "Un site basé sur WooCommerce disposant de 100 000 produits aura 500 000 enregistrements en base s’il est disponible en 5 langues", métadonnées en plus.

Polylang for WooCommerce (99 € HT par an, ou dans le Business Pack affiché à 139 € HT au lieu de 198 €) traduit produits, catégories et attributs globaux, les pages Boutique, Panier, Commande et Mon compte, ainsi que les e-mails WooCommerce, et synchronise le panier d’une langue à l’autre. Chez WPML, il faut l’offre Multilingual CMS et son extension gratuite pour WooCommerce.

Cette extension gratuite apporte le multidevise même sans licence WPML, mais pour le reste, "To use all features, you need WPML’s Multilingual CMS or Multilingual Agency plan". TranslatePress annonce une compatibilité WooCommerce dès sa version gratuite, et Weglot traduit produits, pages de commande et e-mails selon sa fiche.

Pour les bases de la boutique, le guide pour installer et configurer WooCommerce reste le point de départ.

Éditeur de blocs et modèles FSE

Avec un thème de blocs, l’en-tête, le pied de page et les modèles se construisent dans l’éditeur de site (FSE). Ils doivent eux aussi changer de langue, et toutes les offres ne le permettent pas :

• Polylang propose son sélecteur de langue en bloc dès la version gratuite, et Polylang Pro rend les parties de modèle traduisibles ("Template parts translatable in the site editor (FSE)") ;
• chez WPML, la prise en charge de l’éditeur de site ("Translate headers, footers, templates and more from Gutenberg") est réservée aux offres Multilingual CMS et Agency ;
• TranslatePress traduit la page affichée, blocs compris ("Native Gutenberg support"), donc aussi ce que produisent les modèles ;
• Weglot traduit le code source servi, modèles compris.

Même vigilance avec les constructeurs de pages : l’offre Blog de WPML ne les couvre pas, et l’intégration DeepL de Polylang Pro ne fonctionnait pas avec Elementor au 29 septembre 2026. Si votre site en dépend, vérifiez ces deux points avant d’acheter. Et si ces limites vous donnent envie de quitter votre constructeur, voyez comment migrer d’Elementor ou Divi vers Gutenberg.

Comment sortir de WPML sans tout casser ?

C’est la migration que je propose le plus volontiers, pour les raisons dites plus haut. Bonne nouvelle, elle est outillée : le développeur de Polylang publie une extension dédiée.

WPML to Polylang importe les langues, les options de WPML qui existent aussi dans Polylang, la langue et les liens de traduction des publications et des termes (types de contenus et taxonomies personnalisés compris), les menus multilingues, les traductions de chaînes et les options de traduction d’ACF. Elle ne supprime aucune donnée WPML.

Son auteur indique l’avoir testée avec succès sur un site d’environ 9 000 publications et médias. Attention, elle "does not include error management". D’où la méthode que je vous conseille :

1. Faites une sauvegarde complète de WordPress, base de données comprise, et travaillez sur une copie de préproduction.
2. Relevez la structure d’URL actuelle (sous-répertoires ou sous-domaines) et reprenez exactement la même dans Polylang, pour ne créer aucune redirection (si une adresse change malgré tout, posez des redirections 301 pour chaque ancienne URL).
3. Désactivez WPML, activez Polylang (ou Polylang Pro) et WPML to Polylang, sans créer de langue à la main : elles seront importées.
4. Lancez l’import depuis Outils, puis WPML Importer, et désactivez l’outil une fois l’import terminé.
5. Remettez en place le sélecteur de langue, puis contrôlez les balises hreflang, les menus et les chaînes traduites sur quelques pages clés.
6. Mettez en production, puis suivez l’indexation des versions traduites dans la Search Console pendant les semaines suivantes.

Pour sortir de Weglot, tout dépend de votre offre. Sous Advanced, pas d’export en masse : vos traductions se refont dans le nouvel outil ou se recopient une à une depuis le tableau de bord de Weglot.

Mon conseil pour choisir votre solution multilingue

Commencez par Polylang gratuit, pour presque tous les sites vitrines et les blogs. Vous paierez Polylang Pro le jour où vous voudrez des bases d’URL traduites, la synchronisation des contenus ou DeepL, et Polylang for WooCommerce si vous vendez. Si votre équipe préfère traduire directement sur la page, TranslatePress est une alternative honnête, qui garde elle aussi vos traductions chez vous.

Réservez WPML aux structures qui gèrent de vrais flux de traduction, avec des traducteurs et des agences. Et n’envisagez Weglot que pour un petit site, ou en connaissant d’avance le prix de la sortie.

Surtout, testez avant de trancher : installez la solution retenue sur une copie de votre site, traduisez trois pages, puis regardez le code source et l’inspection d’URL de la Search Console. Une heure de test vous épargnera une migration.

Si vous voulez un regard extérieur sur votre cas, ou un plan de sortie de WPML sans casse, je fais ce diagnostic en mission Expert WordPress, à 190 € HT de l’heure, premier appel offert.

Questions fréquentes

Comment traduire automatiquement un site WordPress ?

Installez une extension qui intègre un moteur de traduction : TranslatePress (2 000 mots d’IA gratuits, puis un quota selon l’offre), Polylang Pro avec votre clé DeepL, WPML avec son moteur PTC, ou Weglot, dont l’abonnement inclut la traduction automatique. Faites ensuite relire les pages clés par une personne native, titres et descriptions compris.

Quelle est la meilleure extension multilingue gratuite ?

Pour moi, Polylang : sans limite de langues, avec plus de 800 000 installations actives selon wordpress.org au 29 septembre 2026, et des traductions stockées comme des publications WordPress. TranslatePress gratuit est une bonne alternative pour traduire sur la page. Évitez le widget gratuit de GTranslate si vous visez le référencement : ses pages traduites ne sont pas indexées.

Combien coûte la traduction d’un site WordPress ?

Pour un site vitrine de 20 pages traduit en deux langues, la licence coûte de 0 € avec Polylang gratuit à 297 € sur trois ans avec TranslatePress Personal ou WPML Multilingual CMS (renouvellement supposé au même prix), contre 870 à 2 370 € HT chez Weglot. La traduction elle-même va de moins de 40 € avec le moteur PTC de WPML à au moins 2 600 € avec les traducteurs professionnels de Weglot.

Peut-on créer un site WordPress multilingue sans extension ?

Oui, en créant un site par langue, en installations séparées ou en multisite, et en reliant les versions entre elles, comme le décrit la documentation officielle de WordPress. Vous devrez alors gérer vous-même les liens entre les langues et des balises hreflang réciproques. Pour la plupart des sites, une extension reste bien plus simple.

Google pénalise-t-il la traduction automatique ?

Pas en tant que telle. Le 11 juin 2025, Google a retiré de sa documentation le conseil de bloquer les pages traduites automatiquement. Sa politique anti-spam vise la production de nombreuses pages sans valeur pour l’utilisateur, traduction automatique comprise. Une traduction relue, utile à vos visiteurs, n’entre pas dans ce cadre.

Weglot ou WPML, lequel choisir ?

Aucun des deux par défaut, pour moi. Weglot est le plus simple à lancer, mais vos traductions restent sur ses serveurs et le site n’est plus traduit si vous arrêtez l’abonnement. WPML garde vos traductions dans votre base, mais je le trouve lourd pour un site de PME. Pour la plupart des sites, je conseille Polylang.

Sources

Sources primaires lues le 29 septembre 2026. WordPress et wordpress.org :

• Roadmap, wordpress.org (page modifiée le 20/08/2026)
• Multilingual WordPress, Advanced Administration Handbook (mis à jour le 07/07/2025)
• Gérer un site multilingue avec WordPress, documentation française (mise à jour le 31/12/2021)
• API des extensions de wordpress.org : fiches de Polylang, TranslatePress, Weglot, GTranslate, Google Language Translator, Loco Translate, WPML Multilingual & Multicurrency for WooCommerce, MultilingualPress, Multisite Language Switcher et WPML to Polylang, fiches fermées de Lingotek et de WPML

Google Search Central :

• Managing multi-regional and multilingual sites (mis à jour le 10/12/2025)
• Tell Google about localized versions of your page (mis à jour le 21/09/2026)
• Spam policies for Google web search (mis à jour le 28/08/2026)
• Latest Google Search documentation updates, entrée du 11/06/2025
• Google Search’s guidance on using generative AI content (mis à jour le 10/12/2025)
• Translated results in Google Search (mis à jour le 10/12/2025)
• Google Translate’s Website Translator, available for non-commercial use (19/05/2020)

Pages de prix et documentation des éditeurs :

• WPML : page de prix, guide de traduction (mis à jour le 04/02/2026) et tables de la base
• Polylang : page de prix et article sur hreflang
• TranslatePress : page de prix
• Weglot : page de prix, aide SEO pour WordPress (mise à jour le 29/06/2026) et aide import et export (mise à jour le 29/09/2026)
• MultilingualPress : page d’accueil et tarifs et choix de la licence
• GTranslate : page de prix
• Loco : page de l’extension et offres de la plateforme

Traduction automatique et étude citée :

• Tarifs de Cloud Translation, Google Cloud
• DeepL API plans, centre d’aide DeepL (mis à jour le 24/06/2026)
• Pricing, documentation de l’API OpenAI, et Gemini Developer API pricing (mis à jour le 24/09/2026)
• Communiqué de CSA Research sur l’étude "Can’t Read, Won’t Buy - B2C" (09/07/2020)