Que se passe-t-il quand un agent IA internationalise un vrai monorepo ?

Il a extrait 28 chaînes d'interface candidates, réécrit 41 entrées de traduction réparties sur plusieurs fichiers, configuré le middleware et le routage, et généré les fichiers de traduction pour 5 langues cibles. La configuration, la conversion et la traduction ont pris environ 90 minutes de bout en bout. globalize.now est une infrastructure de localisation propulsée par l'IA, et nous l'avons testée sur un monorepo de production pour voir ce qui se passerait réellement. Pas de démo préparée. Pas de filet de sécurité. Juste une vraie base de code avec sa vraie complexité.

La base de code appartenait à un vétéran du secteur de la localisation, qui a passé plus de dix ans comme architecte dans l'une des principales plateformes de gestion de traduction.

Que contenait le monorepo ?

Ce n'était pas un projet de tutoriel. Le monorepo contenait une application web Next.js, une application Android, des serveurs MCP, et une documentation générée par un service tiers. Le développeur utilise Claude Code au quotidien, construit avec des outils IA de bout en bout, et avait assemblé toute la stack en trois mois.

La cible était le frontend Next.js. L'application Android, les serveurs MCP, le site de documentation construit sur Mintlify — rien de tout cela ne devait être touché. La question était de savoir si un agent IA pouvait le comprendre sans instruction explicite.

C'était possible. L'agent a analysé l'ensemble du dépôt et s'est concentré sur l'application Next.js. Aucun cadrage manuel n'a été nécessaire en pratique, même si le développeur a noté qu'il aurait apprécié de pouvoir préciser « convertir uniquement /apps/web » pour plus de tranquillité d'esprit. C'est une remarque pertinente et quelque chose qui mériterait d'être ajouté. Mais cela n'a pas bloqué la conversion.

Comment s'est déroulée la configuration ?

Le développeur a choisi le mode guidé pour bien comprendre le processus. La configuration a couvert cinq décisions: gestionnaire de paquets (NPM, malgré la présence d'un ancien lockfile PNPM), format de catalogue (PO/GetText, recommandé pour la prise en charge des commentaires), mode de configuration (guidé), langue source (anglais), et langues cibles (espagnol, italien, hongrois, tchèque, slovaque).

Une observation à noter: la question du format de catalogue a suscité de l'hésitation, même chez quelqu'un ayant une solide expertise en localisation. Sa réaction a été directe. Il n'a pas jugé que ce choix méritait qu'on interroge l'utilisateur à ce sujet. Autant l'automatiser.

La stratégie de routage était basée sur les chemins. Pas de routage par domaine, le développeur ne possédant pas de domaines supplémentaires. L'application utilise une authentification basée sur OAuth, donc les flux de connexion sont restés en anglais par conception. L'agent a géré cela correctement.

Que fait réellement l'étape de conversion ?

C'est là que ça devient intéressant. L'agent a identifié 28 chaînes UI candidates dans l'application Next.js et traité 41 entrées de traduction. Il a réorganisé les fichiers, mis à jour le middleware, modifié les imports de composants et généré les fichiers de locale PO pour les 5 langues cibles.

La seule étape de conversion a pris environ 30 minutes. En ajoutant la configuration initiale avant, et le travail effectué ensuite par le développeur pour finaliser la connexion de traduction en autonomie, le processus complet de bout en bout a duré près de 90 minutes. Ce n'est pas instantané. Pour donner un ordre de grandeur, une application simple avec quelques pages boucle le flux complet en moins de 15 minutes. Une application complexe avec des dizaines de surfaces traduisibles prend plus de temps. Le temps dépend du nombre de chaînes, pas de la taille du dépôt.

Le développeur a observé l'étape de conversion se dérouler et a résumé la situation ainsi: l'extraction des chaînes et la réécriture du code, c'est le gros du travail. C'est la tâche que les développeurs redoutent. Dans son entreprise précédente, un TMS reconnu du marché, les fichiers de traduction du dépôt n'étaient que la partie visible de l'iceberg. Le vrai calvaire, c'était le travail de préparation et d'internationalisation. Et c'est exactement cette partie que l'agent IA a prise en charge.

Ce constat rejoint ce que nous entendons de tous les développeurs qui sont passés par l'i18n manuellement. Personne ne se plaint des traductions. Ce qui pose problème, c'est de devoir toucher 40 fichiers pour envelopper des chaînes dans des appels t(), générer des clés qui ont du sens, restructurer les imports et configurer le middleware. C'est exactement ce que globalize.now automatise.

Est-ce que ça a vraiment fonctionné de bout en bout ?

Oui. Une fois la session en direct terminée, le développeur a réalisé les étapes restantes en autonomie. Il a publié la branche Git de globalize.now, connecté l'application à la plateforme web, configuré le suivi sur la branche globalize.now, et confirmé que les fichiers avaient été correctement importés et traduits.

Son évaluation de la qualité de la traduction en tchèque: proche de la perfection. Ce jugement vient de quelqu'un qui a passé sa carrière à évaluer professionnellement des résultats de localisation. Ce n'est pas un simple pouce levé de circonstance. C'est un expert du domaine qui confirme une qualité prête pour la production sur une paire de langues loin d'être triviale.

Il a signalé deux problèmes dans l'application web après avoir terminé le flux en autonomie. D'abord, une nouvelle analyse du dépôt affichait « aucun fichier i18n détecté », alors même que le job de traduction tournait en arrière-plan. Un état d'interface trompeur, pas un véritable échec. Ensuite, le job de traduction démarrait sans consentement explicite. Toute action qui consomme des crédits devrait exiger une confirmation. Ces deux problèmes UX sont légitimes et en cours de correction.

Qu'est-ce qui a mal tourné ?

Il y a eu des accrocs. C'était un vrai test, alors autant être honnêtes.

La commande d'installation (npx skills add globalize-now/globalize-skills) a échoué sur Windows PowerShell. C'était la première fois que l'outil était testé sous Windows. Les compétences ont dû être envoyées sous forme de fichier zip via Swiss Transfer après que Google a bloqué la pièce jointe de l'e-mail. Friction totale à la mise en place: environ 15 minutes avant même le début du flux réel.

Un conflit entre modules ES et CommonJS a surgi en pleine conversion. Le projet utilise CommonJS, et à un endroit, la sortie de l'agent supposait des modules ES. Pas un bloqueur, mais un point qui devrait être détecté dès la configuration et traité de façon proactive.

À la fin de la session, la connexion du dépôt GitHub dans l'application web globalize.now a renvoyé une page blanche. Le développeur utilisait Opera. Aucun écran de connexion, aucune erreur, aucun contenu. La session s'est terminée avant que le problème soit résolu.

Trois bugs. Tous réels. Tous corrigés ou en cours de correction.

Pourquoi l'extraction des chaînes est-elle le vrai goulot d'étranglement ?

La plupart des contenus sur l'i18n se concentrent sur la qualité de traduction, la configuration des frameworks ou la comparaison des fonctionnalités des TMS. Cela passe à côté de l'endroit où les développeurs perdent réellement du temps.

Ajouter l'internationalisation à une base de code existante implique de scanner chaque composant à la recherche de chaînes codées en dur, de décider quelles chaînes sont traduisibles, de générer des clés de traduction pertinentes, d'envelopper chaque chaîne dans l'appel t() ou <Trans> approprié, de mettre à jour les imports dans toute l'arborescence, de créer les fichiers de locale initiaux et de configurer le middleware de routage. Pour un monorepo, il faut en plus déterminer quelles parties de la base de code ont réellement besoin d'i18n.

C'est fastidieux, source d'erreurs, et exactement le genre de tâche pour laquelle les agents IA excellent. Le développeur qui a assisté à l'opération l'a formulé clairement: de son point de vue, c'est le plus gros du travail. C'est un vrai soulagement. Les vibe coders qui construisent avec des outils IA peuvent désormais s'épargner entièrement la pire partie de l'internationalisation.

Qu'avons-nous appris sur le scoping en monorepo ?

L'agent a géré le scoping du monorepo de manière implicite. Il s'est concentré sur l'application web Next.js et a ignoré le code Android, les serveurs MCP et la documentation Mintlify, sans qu'on le lui demande. C'est le comportement attendu dans la plupart des cas.

Mais un scoping implicite n'équivaut pas à un scoping explicite. Le développeur voulait pouvoir dire « convertis uniquement mon application Next.js » comme étape de configuration. Dans un monorepo avec plusieurs frontends web, disons une application destinée aux clients et un tableau de bord d'administration, il faudrait un contrôle précis sur le frontend à internationaliser en premier.

C'est une lacune produit que nous sommes en train de combler. Pour l'instant, l'agent fait le bon choix en pratique. Le scoping explicite devrait être une étape de configuration, surtout quand la conversion touche des dizaines de fichiers.

Comment cela se compare-t-il à une configuration i18n manuelle ?

Une configuration i18n manuelle sur une base de code de cette complexité prend des jours. Non pas parce qu'une étape en particulier est difficile, mais parce qu'il y en a des dizaines et que chacune exige de l'attention. Oubliez une chaîne, et vous livrez une page à moitié traduite. Nommez mal une clé, et vous créez des doublons qui vous hanteront pendant des mois. Oubliez de mettre à jour le middleware, et votre routage par locale se casse silencieusement.

L'agent IA a accompli l'équivalent de ce travail en environ 90 minutes, de bout en bout. Le développeur, quelqu'un qui a vu passer des milliers d'implémentations i18n dans un cadre professionnel, a qualifié le résultat d'élégant.

Pour les développeurs qui construisent avec des outils IA, cela change la donne sur le moment d'ajouter des langues. Si la mise en place de l'i18n prend une semaine, on la repousse jusqu'à avoir validé le product-market fit. Si elle prend 90 minutes, on peut lancer une application multilingue dès le premier jour.

globalize.now s'en charge. Connectez votre dépôt, la conversion s'exécute une fois, dans l'application; les compétences npx skills add globalize-now/globalize-skills couvrent la suite dans votre éditeur. Découvrez comment ça marche sur globalize.now.