Construire un service de traduction de sites web avec des LLM

Le problème : traduire un site sans changer de plateforme

Les entreprises et les propriétaires de sites souhaitent rendre leur contenu accessible dans plusieurs langues tout en conservant leur hébergement, leur design et leurs outils. Qu’il s’agisse de pages statiques ou de pages publiées sur Shopify, WordPress ou Squarespace, ils ne maîtrisent pas toujours le HTML produit par leur fournisseur.

Traduire ces sites demande donc plus qu’un appel à un modèle de langage. Il faut retrouver le contenu utile, préserver sa place dans la page, tenir compte du contexte éditorial et servir des versions localisées sans recalculer la traduction à chaque visite.

Ma contribution : du parsing spécifique à la classification

J’ai conçu et implémenté le workflow de traduction. La première version utilisait un parsing codé en dur pour extraire les contenus candidats, puis un LLM pour les traduire. Cette approche permettait de valider le service, mais les règles d’extraction dépendaient trop des particularités du HTML de chaque fournisseur.

J’ai ensuite fait évoluer la première partie du workflow vers un navigateur automatisé, suivi d’une classification par LLM. Le navigateur exécute le JavaScript et capture la page rendue, sans appel à un LLM pendant cette étape. Un parseur déterministe relève ensuite les textes, les attributs et leurs positions ; le modèle décide quels candidats traduire ou exclure.

Cette séparation réduit la dépendance aux règles propres à chaque plateforme. Elle ne supprime pas tout le parsing : elle conserve un repérage précis du HTML et confie au modèle la décision sémantique.

Les décisions d’ingénierie

Préserver la mise en forme de la page rendue

Le service enregistre une image HTML et les positions des contenus à remplacer. Il applique les traductions à ces emplacements au lieu de demander au modèle de réécrire la page. La structure, les classes et les éléments de présentation restent ainsi attachés au document source. Les identifiants et les remplacements sont validés avant publication.

Séparer sélection du contenu et traduction

La classification utilise Llama 3.3 70B, par lots allant jusqu’à 20 candidats. La traduction utilise Llama 3.1 8B sur les textes et segments d’URL qui ne sont pas déjà en cache. J’ai donc retenu deux modèles distincts pour ces deux tâches. Le coût des tokens a été l’un des critères de ce choix, avec la qualité attendue, la latence, la fiabilité des réponses structurées et le volume d’appels. Cette répartition reste à évaluer sur des entrées identiques : la taille du modèle ne garantit pas, à elle seule, de meilleures décisions de classification.

Le contexte éditorial et le glossaire guident la traduction pour préserver le vocabulaire et la voix de la marque. La validation structurelle des réponses ne remplace toutefois pas une revue linguistique.

Réduire les règles spécifiques aux fournisseurs

Travailler à partir d’une page rendue permet de prendre en compte les contenus générés en JavaScript. La classification s’appuie sur les textes, les attributs et leur contexte pour sélectionner le contenu utile selon un même contrat, quel que soit l’hébergeur.

Certaines normalisations restent nécessaires. Par exemple, le workflow retire le marqueur global de non-traduction ajouté par Weglot lorsqu’il est identifié, tout en conservant les exclusions locales intentionnelles. Les contenus intégrés sont préparés avant extraction. L’objectif est de réduire les exceptions de plateforme, puis de mesurer les cas qui résistent encore.

Réutiliser le travail déjà effectué

Une image identique permet de réutiliser les sélections enregistrées. La déduplication, la mémoire de traduction et les points de reprise évitent de retraiter les textes déjà disponibles. Pour la classification, des identifiants courts limités à chaque requête réduisent la taille des échanges ; ils sont ensuite remappés vers les identifiants persistants de l’image.

Garder les appels aux modèles hors du parcours visiteur

Les files de messages orchestrent l’extraction et les traductions en amont. Le cache conserve les images et la Bdd les blocs sélectionnés. Lors d’une visite, le service charge l’image et les traductions sauvegardées, applique les remplacements, les liens localisés et les éléments SEO, puis renvoie le HTML sans appel à un LLM.

Résultats observés et limites

Le service a permis de démontrer les capacités de traduction à des clients. Un benchmark sur plusieurs sites, dont des sites de fournisseurs différents, a mesuré la couverture d’extraction, les décisions de classification, les correspondances de remplacement, les temps de traitement et les tokens consommés. Ces mesures permettent de repérer les écarts entre plateformes ; elles ne constituent pas une garantie de compatibilité universelle.

Benchmarker le passage du mode Standard au mode Agent

Pour évaluer ce changement, j’ai comparé sur les mêmes pages les blocs retenus par le mode Standard, fondé sur des règles d’extraction, et les candidats sélectionnés par le mode Agent, qui associe rendu navigateur et classification par LLM. Le benchmark examine les contenus récupérés ou omis, la pertinence des exclusions, la fidélité des remplacements dans le HTML, ainsi que le temps de traitement et la consommation de tokens du parcours Agent. Le nombre de blocs ne suffit pas à départager les approches : leur découpage et leur couverture des attributs diffèrent. Une revue des sélections complète donc les mesures pour identifier les gains de couverture et les régressions. Les remplacements synthétiques vérifient le positionnement dans la page ; la qualité linguistique et le comportement des pages traduites demandent des essais distincts.

L’adaptation des entrées, du contexte et du format de réponse est donc un levier concret d’optimisation. Réduire les tokens ne suffit pas : il faut vérifier que le modèle conserve la bonne sélection de contenus et produit une traduction adaptée à leur usage.

La suppression du mode Standard permet de retirer environ 5 % des sources du worker.

Le déploiement passe aussi par le DNS

Servir les pages localisées sur le domaine attendu demande de configurer les enregistrements DNS et le routage selon le domaine et l’hébergement d’origine. Ce travail fait partie de l’intégration : préserver l’accès au site source, vérifier le routage des versions localisées et contrôler leur comportement sur le domaine final. La traduction seule ne règle pas cette étape de mise en ligne.

Conclusion

Ce service est en production sur Cloudflare en mode Agent. Le workflow de traduction s’exécute sans intervention humaine à chaque étape. C’est un workflow automatisé avec des décisions prises par IA, mais pas encore un agent IA autonome où le modèle observe, choisit une action, vérifie son résultat et adapte la suite.