J'ai traduit 3,9 millions de mots en 4 jours avec des agents IA parallèles
493 articles de blog sur 17 ans, traduits en 10 langues, ~4 900 fichiers, ~3,9 millions de mots. Les agents parallèles de Claude Code ont rendu ça possible — mais le désastre coréen, le problème de voix en cantonais et le plafond d'utilisation de 5 heures m'ont appris bien plus que les succès.
Il y a un mois, j'ai ajouté 5 langues à DIALØGUE en 48 heures et j'ai écrit sur la façon dont les documents de planification sont le secret d'une exécution rapide avec l'IA.
C'était 5 langues pour une seule application avec peut-être 400 chaînes d'interface.
Cette semaine, j'ai essayé quelque chose de bien plus ambitieux : localiser l'intégralité de mon blog — 493 articles couvrant 17 ans — en 10 langues. Vietnamien, indonésien, espagnol, français, portugais, allemand, japonais, coréen, chinois simplifié et cantonais.
~4 900 fichiers traduits. ~3,9 millions de mots. 4 jours.
Ce n'est pas une histoire sur la magie de l'IA. C'est une histoire sur ce qui se passe vraiment quand on confie des milliers de tâches de traduction à des agents IA parallèles — l'orchestration qui fonctionne, les échecs qui ne se voient pas avant d'avoir lu le résultat, et la vérité inconfortable sur le contrôle qualité quand les machines écrivent à grande échelle.
Le problème de l'échelle
Mon blog remonte à 2007. Certains articles sont des mises à jour de 300 mots sur le marketing de recherche à Singapour. D'autres sont des analyses approfondies de 5 000 mots sur les relations sino-américaines ou des guides de relocalisation pour expatriés. Les archives incluent tout, de Yahoo SEM Analytics aux critiques de livres, en passant par des lancements de produits IA.
Traduire manuellement 493 articles en 9 langues prendrait des semaines à une équipe de traduction professionnelle. Peut-être des mois. Et ça coûterait quelque chose entre "gênant" et "hypothéquer la maison."
Mais j'avais déjà construit l'infrastructure i18n — le routage next-intl, les composants sensibles aux locales, l'ISR pour les pages non anglophones — dans le cadre d'une démarche d'internationalisation plus large. La pile technique était prête. Il ne me manquait que le contenu.
Jour 1 : Le vietnamien et les premières leçons
J'ai commencé par le vietnamien parce que c'est personnel — c'est ma langue maternelle. Je pouvais lire chaque article traduit et détecter immédiatement si quelque chose sonnait faux.
Claude Code a traduit les 493 articles en une seule session. Le processus semblait propre :
- Lire le fichier MDX en anglais
- Traduire le contenu en préservant toute la structure du frontmatter
- Garder les URLs, les blocs de code et les termes techniques intacts
- Écrire le fichier traduit dans
content/blog/vi/YYYY/MM/DD/slug.mdx - Signer avec l'équivalent vietnamien de "Cheers, Chandler"
Le premier passage de QA a révélé le schéma qui allait hanter chaque langue : les URLs et les signatures. L'agent "traduisait" les URLs internes du blog (transformant /blog/2024/... en slugs vietnamiens qui n'existent pas), remplaçait "Chandler" par une variante vietnamienne du prénom, et perdait parfois le champ slug du frontmatter.
J'ai construit une checklist de QA :
- Le nombre de fichiers correspond à la source (493)
- Pas de fichiers vides ou de stubs
- Tout le frontmatter contient
slug,title,date,categories - Pas d'URLs internes réécrites
- La signature correspond à la convention de la locale cible
- Pour les langues CJK : présence effective de caractères natifs
Cette checklist est devenue la colonne vertébrale de chaque locale suivante.
Jour 2 : La percée des agents parallèles
Le vietnamien terminé et la checklist de QA éprouvée, je devais aller plus vite. La fonctionnalité phare de Claude Code pour ce type de travail est la distribution de sous-agents parallèles — on peut lancer plusieurs agents indépendants qui travaillent simultanément sur des fichiers séparés.
Voici à quoi ressemblait l'orchestration pour l'espagnol :
Dispatching 30 translation agents...
├── Agent 1: 2007-2008 posts (42 posts)
├── Agent 2: 2009 posts (38 posts)
├── Agent 3: 2010-2011 posts (35 posts)
├── ...
├── Agent 28: 2025 Nov-Dec posts (12 posts)
├── Agent 29: 2026 Jan posts (8 posts)
└── Agent 30: 2026 Feb posts (9 posts)
Chaque agent recevait un lot d'articles, le guide de style, la checklist de QA et la convention de signature. Ils s'exécutaient en parallèle, écrivant les fichiers de façon indépendante. Pas de coordination nécessaire puisque chaque agent touche des fichiers différents.
Espagnol : 493 articles traduits en une seule session. Puis le français. Puis le portugais. Puis l'allemand. Puis le japonais.
Cinq langues en à peu près 12 heures. C'est la partie qui donne l'impression d'être dans le futur — regarder son terminal se remplir de 30 indicateurs de progression simultanés, chaque agent avançant à travers une décennie d'articles de blog pendant qu'on prépare à dîner.
Voici une simulation de ce à quoi ressemblait la session de traduction en cantonais (zh-HK) — de la planification à la distribution jusqu'au QA :
Le schéma d'orchestration
Le schéma qui s'est dégagé :
- Pré-créer tous les répertoires — les agents échouent silencieusement si le répertoire cible n'existe pas
- Regrouper par tranche d'années — 10 à 15 articles par agent pour les articles normaux, 2 à 3 par agent pour les articles de plus de 3 000 mots
- Inclure le guide de style dans chaque distribution — les agents n'ont pas de mémoire partagée, donc chacun a besoin du contexte complet
- Lancer le QA après chaque locale complétée — nombre de fichiers, fichiers vides, frontmatter cassé, réécriture d'URLs, cohérence des signatures
- Corriger les retardataires avec des agents de nettoyage ciblés — il y a toujours 5 à 15 articles ratés ou mal formés
Le désastre coréen
Le coréen était censé être routinier. Même schéma que les 7 autres langues. Distribuer les agents, attendre, QA, corriger les retardataires.
À la place, c'était la pire qualité de traduction de toutes les locales.
72 % des articles coréens n'étaient pas des traductions — c'étaient des résumés. Les agents avaient réduit plus de 350 articles en abstraits de 2 à 3 paragraphes, perdant tous les détails, toute la personnalité, toute la nuance. Une analyse de 4 000 mots sur "Principles" de Ray Dalio était devenue un aperçu de 200 mots. Un tutoriel SEM détaillé était devenu "Cet article traite des stratégies de marketing sur les moteurs de recherche."
Le fichier de chaînes d'interface (messages/ko.json) était encore pire. Du coréen et de l'anglais mélangés partout, avec des caractères corrompus comme "Ch및ler" à la place de "Chandler." Le caractère 및 signifie "et" en coréen — le modèle l'avait somehow substitué au milieu d'un mot.
J'ai dû refaire entièrement la locale depuis zéro. Chaque article. La deuxième tentative, avec des instructions plus strictes sur la préservation du contenu intégral et la correspondance de la longueur avec l'article source, était propre.
Leçon : l'exécution parallèle amplifie les erreurs. Si votre prompt a un défaut subtil, 30 agents feront tous la même erreur 30 fois plus vite. Le QA n'est pas optionnel — c'est la seule chose qui sépare "terminé" de "désastre."
Le problème chinois : 43 commits pour s'en sortir
Le chinois simplifié (zh) a été la locale la plus laborieuse. Pas pour des problèmes de qualité — les traductions étaient bonnes — mais parce que 493 articles sur 43 commits distincts indique que la session n'arrêtait pas d'atteindre des limites.
Claude Code tourne sur l'API d'Anthropic, et il y a un plafond d'utilisation. Même sur le niveau Max avec Sonnet 4.6, les sessions prolongées qui distribuent des dizaines d'agents parallèles finissent par déclencher une période de refroidissement de 5 heures. Pour le chinois, ça voulait dire traduire en vagues : ~50 articles, atteindre le plafond, attendre, continuer, atteindre le plafond à nouveau.
Les traductions chinoises ont aussi nécessité le plus de QA parce que le contenu CJK a des modes d'échec uniques :
- Des caractères du mauvais script (kanji japonais mélangés dans le chinois simplifié)
- Un registre trop formel qui lit comme un document gouvernemental plutôt qu'un blog
- De la ponctuation occidentale à la place de la ponctuation chinoise (，vs. , et 。vs. .)
- Des noms traduits qui ne devraient pas l'être ("Claude" est "Claude" en chinois, pas 克劳德)
Le problème de voix en cantonais
Quand j'ai ajouté le chinois traditionnel avec voix cantonaise (zh-HK), j'ai fait face à un défi totalement différent. Les traductions devaient utiliser des particules spécifiques au cantonais — 嘅 (possessif), 咗 (passé), 喺 (à/dans), 啲 (quelques), 冇 (ne pas avoir) — et maintenir le ton décontracté et conversationnel qui définit l'écriture en cantonais.
Les traductions en mandarin standard sonnent bureaucratiques à Hong Kong. "本网站提供中文版本" est du mandarin correct, mais un lecteur cantonophone s'attend à "呢個網站有中文版本." Même sens, voix complètement différente.
Le défi n'est pas la précision de la traduction — c'est l'authenticité de la voix. Le modèle peut produire du cantonais grammaticalement correct, mais il bascule par défaut vers un registre mandarin à moins qu'on ne lui indique explicitement d'utiliser des particules colloquiales et des schémas de code-switching.
Mon contrôle QA pour le cantonais incluait un grep de chaque fichier pour vérifier la présence de particules cantonaises spécifiques. 493 sur 493 ont passé. Mais j'ai quand même dû réécrire manuellement l'intégralité du fichier de chaînes d'interface messages/zh-HK.json parce que la première version était à ~70 % en anglais — l'agent avait sauté la plupart des traductions.
Ce que j'ai essayé avec OpenAI Codex
Quelque part pendant les traductions allemandes, j'ai atteint le plafond d'utilisation de Claude Code et décidé d'essayer OpenAI Codex pendant l'attente. J'avais un mois gratuit de ChatGPT Plus, qui inclut l'accès à Codex.
Le bon : Codex produit de solides documents de planification. Son analyse initiale de la base de code et l'approche de traduction proposée étaient bien structurées et raisonnables. Les temps de réponse étaient rapides. Et il suit les instructions de près — presque trop près, ce qui peut être une qualité.
Le mauvais : La version que j'ai utilisée (gpt-5.2-codex) ne pouvait pas exécuter de sous-agents parallèles. Elle traitait les articles séquentiellement — un par un. Pour 493 articles, ce n'est pas viable. Elle travaillait aussi en courtes rafales, complétant 5 à 10 articles avant de s'arrêter pour demander un retour. À chaque fois, je devais dire "continuer" pour obtenir le prochain lot.
Quand gpt-5.3-codex est devenu disponible en milieu de session, j'ai basculé. Mieux, mais toujours pas d'exécution parallèle. La différence architecturale fondamentale — Claude Code peut distribuer 30+ agents indépendants qui s'exécutent simultanément, tandis que Codex fonctionne comme un processus séquentiel unique — rend Claude Code dramatiquement plus rapide pour les tâches de contenu en masse.
La comparaison honnête : Codex est bon pour un travail ciblé sur un seul fichier. Il est réactif et suit bien les instructions. Mais pour le type d'exécution parallèle massive dont j'avais besoin — 4 437 fichiers sur 9 locales — l'architecture d'agents de Claude Code est dans une catégorie à part entière.
La checklist qui a tout sauvé
Chaque locale est passée par le même pipeline de QA :
✓ File count: 493/493
✓ Empty files: 0
✓ Small files (<100 bytes): 0
✓ Missing slugs: 0
✓ Rewritten URLs: 0
✓ Broken frontmatter: 0
✓ Wrong sign-off: 0
✓ Native characters present: 493/493
Pour les langues CJK, j'ai ajouté :
✓ Cantonese particles (嘅/咗/喺/啲/冇): 493/493
✓ No mixed-script contamination: PASS
✓ Chinese punctuation: PASS
Sans cette checklist, j'aurais mis en production les résumés coréens. J'aurais mis en production l'interface cantonaise à 70 % en anglais. J'aurais mis en production des articles avec des liens internes cassés pointant vers des slugs traduits qui n'existent pas.
La checklist n'est pas de la bureaucratie. C'est le seul QA fiable quand votre pipeline de production génère des milliers de fichiers que vous ne pouvez pas lire personnellement.
Les chiffres finaux
| Langues | 11 (anglais + 10 traductions) |
| Articles traduits | 493 par langue × 10 = ~4 900 fichiers |
| Mots | ~3,9 millions |
| Jours calendaires | 4 (24–27 fév.) |
| Fichiers de chaînes d'interface | 10 fichiers JSON par locale (~475 clés chacun) |
| Templates d'email | 10 locales |
| Données Journey | Jalons + parcours d'apprentissage traduits via JSONB |
| Fois où le plafond a été atteint | Perdu le compte |
| Locales entièrement refaites | 1 (coréen) |
Ce que j'ai vraiment appris
1. Les guides de style sont tout. La voix cantonaise, le niveau de formalité coréen, la signature portugaise "Abraço" — ce ne sont pas des ornements. Ce sont la différence entre "traduit" et "localisé." Sans guide de style, on obtient du contenu grammaticalement correct qui lit comme un formulaire administratif.
2. Les agents parallèles sont un multiplicateur de force — et un multiplicateur de risque. Quand 30 agents s'exécutent correctement, on boucle une langue en une heure. Quand 30 agents font la même erreur, on se retrouve avec 350 articles tronqués et une reprise complète.
3. Le QA n'est pas optionnel à grande échelle. On ne peut pas revoir manuellement 4 437 articles traduits. Mais on peut automatiser des vérifications structurelles qui détectent les échecs les plus courants : fichiers manquants, frontmatter cassé, URLs réécrites, mauvaises signatures, contenu tronqué.
4. La partie la plus difficile n'est pas la traduction — c'est la voix. N'importe quel LLM peut traduire du texte. Faire en sorte que ça sonne comme la personne qui a écrit l'original — maintenir la chaleur, la décontraction, la curiosité intellectuelle — sur 9 langues et 17 ans d'un style d'écriture en évolution, ça demande des instructions explicites et un raffinement itératif.
5. Les plafonds d'utilisation sont une vraie contrainte. Même au niveau le plus élevé, les sessions prolongées d'agents parallèles atteindront des limites. Planifiez les interruptions. Structurez votre travail pour pouvoir reprendre là où vous vous êtes arrêté.
6. Testez avec de vrais lecteurs. J'ai pu faire le QA des traductions vietnamiennes moi-même. Pour le coréen ou le japonais, je me suis appuyé sur des vérifications structurelles et j'ai fait confiance au modèle. C'est un angle mort connu. Si vous êtes sérieux sur la qualité dans des langues que vous ne parlez pas, faites relire un échantillon par des locuteurs natifs.
Est-ce que ça valait le coup ?
Mon blog touche maintenant des lecteurs dans leur langue maternelle sur 11 locales. Un professionnel du marketing vietnamien à Hô Chi Minh-Ville peut lire mon analyse de 2011 du marché de la recherche à Singapour en vietnamien. Un chercheur en IA japonais peut lire mes articles de 2024 sur la construction de Sydney en japonais. Un locuteur cantonais à Hong Kong obtient du contenu qui semble avoir été écrit pour lui, pas traduit à son attention.
Est-ce que chaque traduction est parfaite ? Non. La traduction automatique à cette échelle a ses aspérités. Certaines métaphores ne passent pas. Certaines références culturelles nécessitent une localisation qui va au-delà de la substitution mot pour mot.
Mais l'alternative, c'était 493 articles uniquement en anglais, accessibles à peut-être 20 % des internautes dans le monde. Maintenant, c'est accessible à plus de 60 %.
Quatre jours. 3,9 millions de mots. L'infrastructure est en place. Chaque nouvel article que j'écris en anglais est traduit en 10 langues dans le cadre du processus de déploiement.
La vraie question n'est pas de savoir si la traduction IA est parfaite. C'est de savoir si la perfection est l'ennemie de l'accessibilité.
Cordialement, Chandler
