Automatiser la traduction d'articles avec Make (2026)

Tu publies en français depuis un an. Quarante articles, parfois cinquante. Les statistiques montrent quelques visites venues de Belgique, du Canada, de Suisse, et une poignée de lecteurs qui arrivent d'ailleurs et repartent aussitôt, faute de comprendre la langue. Chaque fois que tu vois ce chiffre, la même idée revient : "si je traduisais ce contenu, l'audience potentielle serait dix fois plus grande".

Puis tu fais le calcul. Un article de 2 000 mots, c'est environ deux heures de relecture même avec un outil de traduction ouvert dans l'autre onglet. Quarante articles dans trois langues, c'est 240 heures. Personne ne dégage ce temps sur un projet solo ou une petite équipe, alors le projet reste dans un tiroir, mois après mois.

Ce que tu cherches vraiment quand tu tapes "traduction automatique article WordPress" ou "make deepl", ce sont des réponses à quatre questions précises : est-ce que ça peut vraiment tourner sans moi, combien ça coûte chaque mois, est-ce que Google va pénaliser ces pages, et à partir de quel moment la qualité devient un problème de réputation. Cet article répond aux quatre, chiffres de 2026 à l'appui.

Le principe est simple à énoncer. Quand tu publies un article en français, Make détecte la publication, envoie le texte à un moteur de traduction (DeepL ou Claude), crée l'article traduit en brouillon, le relie à l'original, et te prévient. Tu relis, tu publies. Le tout coûte quelques dizaines de centimes par article, mais seulement si tu contournes deux ou trois pièges que les tutoriels de démonstration passent sous silence.

Ce que coûte vraiment une traduction manuelle à l'échelle d'un blog

La question du coût se pose d'abord en temps, ensuite en argent. En temps, la conversion est brutale : un article de 2 000 mots pèse environ 12 000 à 13 000 caractères espaces compris (calcul de base : 6 à 6,5 caractères par mot en français). Le coller dans un outil de traduction prend une minute. Le relire, corriger les faux amis, rétablir la mise en forme HTML, retrouver les liens internes et republier dans le bon CMS prend le reste de la session.

En argent, la traduction professionnelle sert de référence mentale, mais elle ne s'applique pas à un blog qui publie chaque semaine. Le vrai comparatif est plutôt entre trois options : ne pas traduire (coût nul, audience plafonnée par la langue), traduire à la main avec un outil ouvert dans un onglet (coût en heures), ou déléguer la mécanique à un scénario et ne garder que la relecture humaine.

C'est ce "autour" que Make automatise. Le moteur, lui, coûte peu. Un ordre de grandeur pour fixer les idées, calculé à partir des tarifs publics de septembre 2026 : traduire un article de 12 500 caractères avec un modèle de type Claude Haiku (1 $ le million de tokens en entrée, 5 $ en sortie) revient à environ 2 centimes de dollar, en comptant environ 3 100 tokens en entrée et 3 500 en sortie. Ce calcul est une estimation de ma part à partir de la règle usuelle d'environ 4 caractères par token, pas une mesure officielle, mais l'ordre de grandeur est robuste : c'est le temps humain qui coûte, pas l'API.

Reste la question qui fâche, celle de la qualité. Une traduction automatique brute d'un article technique produit très souvent 90 % de texte correct et 10 % de phrases qui sonnent faux ou changent le sens d'un terme métier. Le scénario que tu vas construire ne supprime pas ces 10 %. Il te les présente en brouillon, à relire en vingt minutes plutôt qu'en deux heures.

Make comme chef d'orchestre du scénario

Make ne traduit rien lui-même. Son rôle est de relier les briques : détecter une nouvelle publication, extraire le texte, appeler le moteur de traduction, recréer l'article dans la bonne langue, et prévenir. C'est exactement le type de tâche répétitive où un scénario visuel se rentabilise en une semaine.

DeepL, Claude ou Google Translate : quel moteur brancher

Le choix du moteur détermine la qualité du brouillon et une partie de la facture. Trois candidats réalistes en 2026, avec des profils très différents.

Face à DeepL, un modèle de langage comme Claude change la nature du travail. Il ne se contente pas de traduire : il peut adapter une accroche, garder un ton tutoyant, respecter une consigne de style, et laisser intacts les blocs de code et les balises HTML si tu le lui demandes dans le prompt. La contrepartie : il faut soigner le prompt, et un modèle peut reformuler là où tu voulais une traduction fidèle.

Côté coût, les grilles de septembre 2026 relevées donnent 1 $ le million de tokens en entrée et 5 $ en sortie pour Claude Haiku 4.5, et 2 $ / 10 $ pour Sonnet 5, avec une remise de moitié via l'API Batch si le résultat n'est pas attendu en direct. Pour de la traduction en brouillon, l'API Batch est une vraie option : tu n'as pas besoin de la réponse dans la seconde.

Une remarque de méthode sur ce tableau : le score de 60,8 est celui de ChatGPT dans le test cité, faute de mesure équivalente publiée pour Claude sur la même paire. Ne le lis pas comme un score Claude. La ligne "coût pour un article" met côte à côte un tarif au caractère et un tarif au token : la comparaison est indicative, jamais exacte à la troisième décimale.

Le scénario complet, module par module

Voici l'architecture en cinq briques, pensée pour WordPress avec l'extension Polylang. Le principe reste valable avec un autre CMS, seuls les modules d'entrée et de sortie changent.

Brique 1 — Déclencheur : un article français vient d'être publié

Le module de surveillance WordPress détecte un nouvel article publié. Pour éviter de traduire chaque brouillon sauvegardé, filtre sur le statut "publié" et sur la langue française. Un filtre à ce stade évite de consommer des credits pour rien.

Brique 2 — Extraction et découpage du texte

Récupère le titre, l'extrait, le contenu HTML et les balises SEO. Si le contenu dépasse la limite de taille de la requête du moteur, découpe-le par blocs de paragraphes, jamais au milieu d'une phrase. La règle pratique : des blocs de 4 000 à 5 000 caractères, coupés à la fin d'un paragraphe.

Brique 3 — Traduction, une langue à la fois

Un itérateur parcourt la liste de tes langues cibles. Pour chaque langue, le module DeepL traduit les blocs. Deux paramètres comptent : la formalité (formel ou informel, disponible pour certaines langues seulement) et le glossaire, dont l'usage impose de préciser la langue source plutôt que de la laisser détecter.

Ce que cela implique pour ton scénario : si tu veux le glossaire (et tu le veux), fixe la langue source à "FR" en dur dans le module. Tu perds la détection automatique, ce qui est sans conséquence puisque ton blog est en français.

Brique 4 — Création du brouillon dans la bonne langue

Le module de création d'article WordPress reçoit le titre traduit, le contenu traduit et le statut "brouillon". Ajoute la langue via le paramètre prévu par Polylang. Conserve le slug de l'original avec un suffixe de langue, ou laisse le moteur générer un slug traduit selon ta politique SEO.

Brique 5 — Liaison des versions et notification

C'est l'étape que les démonstrations sautent. L'API REST de Polylang permet d'associer une traduction à son original : un appel de la forme POST /wp/v2/posts/3376?lang=fr&translations[en]=3374 attribue le français à l'article 3376 et le relie à l'article anglais 3374. Sans cet appel, WordPress affiche deux articles indépendants et le sélecteur de langue ne sait pas basculer d'une version à l'autre. Termine par un message Slack ou un email avec le lien du brouillon à relire.

Combien de credits Make consomme ce scénario ? Une hypothèse de conception, à ajuster selon ton propre montage : environ 7 modules exécutés par langue (lecture de l'article, découpage, traduction, création, liaison, notification, plus le déclencheur partagé). Pour un article traduit en 3 langues, cela donne une vingtaine de credits. Avec 10 000 credits par mois sur le plan Core, tu couvres théoriquement plus de 400 articles traduits en trois langues. Le goulot n'est donc jamais Make, mais le quota de caractères du moteur et ton temps de relecture.

Le piège du glossaire et des noms de marques

Le défaut le plus visible d'une traduction automatique brute sur un blog d'outils, c'est le traitement des noms propres. "Make" devient "Faire" dans une phrase comme "Make peut se connecter à WordPress". "Notion" est traduit comme un concept. "Zap" perd sa majuscule et son sens. Le lecteur natif repère l'erreur au premier paragraphe, et il ne reviendra pas.

Avec un modèle comme Claude, l'équivalent passe par le prompt : "Ne traduis pas les noms suivants : Make, Notion AI, Zapier. Conserve tel quel tout ce qui se trouve entre balises de code. Ne modifie aucune balise HTML." Ce type de consigne fonctionne bien, mais teste-le sur trois articles avant de lancer le scénario en production : un modèle de langage peut respecter la règle 99 fois et l'oublier la centième.

Un test simple avant de déployer : traduis un article contenant volontairement une dizaine de noms d'outils, puis cherche-les un par un dans le résultat. Si un seul est altéré, complète ton glossaire ou ton prompt avant d'aller plus loin. Ce test prend dix minutes et évite une correction à l'échelle de quarante articles.

Combien ça coûte selon ton volume d'articles

Le calcul qui compte est le coût mensuel total, moteur compris. Trois profils types, chiffrés à partir des tarifs de septembre 2026.

Blog qui démarre (4 articles par mois, 2 langues)

4 articles × 12 500 caractères × 2 langues = 100 000 caractères par mois. Make Free (1 000 credits) suffit largement : environ 60 credits par mois. Côté moteur, l'enveloppe unique d'un million de caractères du plan Developer couvre dix mois de ce rythme. Coût mensuel : zéro, pendant un bon moment. Le vrai coût est ton temps de relecture, autour de vingt minutes par article et par langue.

Blog régulier (12 articles par mois, 3 langues)

12 × 12 500 × 3 = 450 000 caractères par mois. Make Core à 9 $ par mois (facturation annuelle) et le forfait DeepL Growth à 26 $ par mois, dont 12 millions de caractères annuels, soit environ 1 million par mois, ce qui laisse de la marge. Total : environ 35 $ par mois, soit une douzaine de fois moins que ce que coûterait le temps d'un traducteur, et sans dépasser le quota.

Média qui publie beaucoup (30 articles par mois, 4 langues)

30 × 12 500 × 4 = 1,5 million de caractères par mois. Ici, le forfait Growth est dépassé d'environ 0,5 million par mois, soit environ 14 $ de dépassement au tarif de 27,50 $ le million. La question se pose alors de passer sur un modèle de langage en mode Batch : à 2 centimes l'article-langue, 120 traductions coûteraient environ 2,40 $ (estimation), mais avec le risque de reformulation évoqué plus haut. C'est le profil où mixer les deux moteurs a du sens : DeepL pour les langues européennes, Claude pour les contenus à fort enjeu de ton.

Une remarque sur les sources de ces tarifs. Les pages de comparaison consultées donnent des chiffres qui ne concordent pas toujours entre elles, en particulier sur la structure exacte de l'ancienne offre API Pro (un prix par million de caractères d'un côté, un abonnement plus un tarif au million de l'autre). J'ai retenu les chiffres qui recoupent le plus de sources, et je te conseille de vérifier la page officielle avant de souscrire.

Google pénalise-t-il les articles traduits par une machine ?

C'est la question qui bloque la plupart des projets. La réponse a bougé : la traduction automatique n'est plus considérée comme du spam par principe. Plusieurs analyses françaises constatent que Google a retiré d'anciennes consignes qui bloquaient les traductions automatiques et mis à jour ses guides multilingues. Le critère n'est plus de savoir si une machine a produit la page, mais si la page est utile, pertinente et adaptée à son public.

Cette évolution ne donne pas un permis de tout traduire. Google continue de sanctionner les pratiques dont le but principal est de manipuler les résultats, quelle que soit la méthode de production. Traduire en masse des centaines de pages sans relecture pour occuper du terrain relève de cette catégorie. Traduire tes vingt articles les plus lus, les relire, les relier à leurs originaux avec les balises hreflang et les publier en brouillon d'abord, c'est le contraire.

Trois règles pratiques découlent de ce cadre. Premièrement, ne traduis pas tout : commence par les articles qui génèrent déjà du trafic ou des conversions. Deuxièmement, relis toujours le titre, la description et l'introduction, qui pèsent le plus dans la perception d'un lecteur natif et dans les extraits de résultats. Troisièmement, vérifie que chaque version pointe vers ses équivalents avec des balises hreflang, faute de quoi Google peut prendre ta version anglaise pour un doublon de la française.

Ce point n'a pas été vérifié dans les sources consultées pour cet article : le détail technique de la configuration hreflang selon ton CMS. Polylang et les extensions similaires ajoutent normalement ces balises automatiquement dès que les traductions sont liées, mais teste-le en inspectant le code source d'une page traduite avant de compter dessus.

Ce que ce système ne fera jamais à ta place

Un article honnête doit dire ce qui ne marche pas, pas seulement ce qui marche.

Le scénario ne relit pas. Un moteur de traduction produit un texte grammaticalement correct qui peut, sur un terme métier ou une tournure idiomatique, dire autre chose que l'original. Pour du contenu juridique, médical ou financier, les comparatifs consultés recommandent de ne jamais s'en remettre à la traduction automatique seule. Pour un blog d'outils, le risque est moins grave, mais un contresens sur un prix ou une fonctionnalité reste un contresens.

Il ne localise pas. Traduire "en France" par "in France" est facile. Adapter les exemples, les devises, les références culturelles ou les réglementations au marché visé est un travail éditorial. Un article qui parle de TVA française ou de statut d'auto-entrepreneur, traduit tel quel pour un lecteur allemand, sera exact mot pour mot et inutile dans le fond.

Il ne gère pas les médias. Les images qui contiennent du texte, les captures d'écran d'interfaces en français, les vidéos sous-titrées restent en français. Le scénario traduit le texte du corps de l'article, pas ce que ton lecteur voit à l'écran.

Il ne décide pas quoi traduire. Aucun outil ne sait quels articles méritent l'effort. Ce choix se fait avec tes statistiques de trafic, tes pages qui convertissent et tes marchés cibles.

Pour garder un point de contrôle humain sur ce type de pipeline, la logique décrite dans l'article sur l'autonomie et les risques des agents Make s'applique telle quelle : plus tu confies d'étapes à une automatisation, plus le point de validation final doit rester explicite.

Verdict : qui devrait automatiser sa traduction ?

Le duo Make + DeepL coûte entre zéro et une trentaine de dollars par mois selon ton volume, contre plusieurs heures de travail humain par article traduit. La condition : accepter de relire chaque brouillon, et de ne jamais publier en direct.

Articles liés

• Automatiser les meta descriptions avec Writesonic et Make — Un autre scénario Make qui traite un lot de pages SEO d'un seul coup.
• Automatiser la création d'un livre blanc B2B avec Make (2026) — Même logique de chaîne de production éditoriale pilotée par Make.
• n8n vs Zapier vs Make : le guide pour choisir en 2026 — Si tu hésites encore sur la plateforme d'automatisation.
• Automatiser son community management avec Make (2026) — Diffuser ensuite tes versions traduites sur les réseaux de chaque marché.
• Make AI Agents : quelle autonomie, quels risques (2026) — Pourquoi garder une validation humaine sur les pipelines automatisés.