Table des matières
Traduction de site web par Proxy : Fonctionnement, cas d'usage et alternatives
Points clés
- La traduction par Proxy sert des versions traduites de votre site web en interceptant les requêtes HTTP — aucune modification de code requise
- Les Proxys sont rapides à configurer (souvent le jour même), mais introduisent des compromis en matière de performance, de contrôle SEO et de maintenabilité à long terme
- Le i18n basé sur le code (utilisant des bibliothèques comme react-intl, next-intl ou vue-i18n) vous donne un contrôle total sur les traductions, mais nécessite un effort de développement
- Les solutions Proxy fonctionnent bien pour les sites marketing et les pages à fort contenu où la rapidité de mise sur le marché compte le plus
- Pour les produits logiciels avec des interactions UI complexes, le i18n basé sur le code offre généralement une meilleure expérience utilisateur et maintenabilité
Comment fonctionne la traduction par Proxy
Un Proxy de traduction se place entre vos utilisateurs et votre serveur web. Lorsqu'un utilisateur demande une page dans une langue spécifique, le Proxy :
- Récupère la page originale depuis votre serveur (dans la langue source)
- Identifie les éléments de texte traduisibles dans le HTML
- Remplace le texte source par des traductions issues de sa base de données
- Sert la page traduite à l'utilisateur
Utilisateur (Français) → Proxy → Votre Serveur (Anglais)
↓
Proxy remplace le texte anglais
par des traductions françaises
↓
L'utilisateur reçoit la page en français
Le Proxy gère généralement aussi le routage des URL — en servant des pages traduites sous des sous-domaines (fr.example.com), des sous-répertoires (example.com/fr/) ou des domaines séparés.
Avantages de la traduction par Proxy
Aucune modification de code requise
L'avantage principal : votre équipe de développement n'a pas besoin d'internationaliser le code base. Le Proxy gère la traduction en externe. C'est particulièrement précieux quand :
- Votre code base n'a pas été conçu avec le i18n à l'esprit et la mise à niveau serait coûteuse
- Vous devez traduire un site rapidement (en jours, pas en semaines)
- Le site est construit sur une plateforme que vous ne contrôlez pas (p. ex., un CMS hébergé)
Mise sur le marché rapide
Les solutions Proxy peuvent avoir une version traduite de votre site en ligne en quelques jours. Le Proxy explore votre site, identifie le contenu traduisible et le présente pour traduction. Pas de sprints de développement, pas de revues de code, pas de déploiements.
Fonctionne avec n'importe quelle stack technologique
Comme le Proxy opère au niveau HTTP, il fonctionne quelle que soit la technologie de votre site — React, WordPress, Shopify ou HTML statique. Le Proxy voit la sortie HTML rendue, pas votre code source.
Limitations et compromis
Impact sur les performances
Chaque requête de page passe par un saut réseau supplémentaire (le Proxy). Cela ajoute de la latence :
- Chargement initial : Le Proxy doit récupérer la page depuis votre serveur d'origine, la traiter et servir la version traduite. Cela peut ajouter 100 à 500 ms selon la complexité de la page et l'emplacement du Proxy.
- Mise en cache : Les Proxys atténuent cela avec une mise en cache agressive, mais l'invalidation du cache lors de modifications de votre contenu source peut être difficile.
- Contenu dynamique : Le contenu chargé via AJAX, la navigation en application monopage et le rendu côté client peuvent ne pas être interceptés par le Proxy, entraînant l'apparition brève de contenu non traduit.
Contrôle SEO
La traduction par Proxy crée des versions traduites de vos pages, mais vous avez moins de contrôle sur :
- Balises hreflang : Le Proxy les génère, mais déboguer les problèmes hreflang est plus difficile quand vous ne contrôlez pas le HTML directement
- URLs canoniques : S'assurer que les balises canoniques sont correctes entre les versions linguistiques nécessite une configuration du Proxy
- Métadonnées : La traduction des méta-titres, descriptions et balises Open Graph dépend des capacités de détection de contenu du Proxy
- Vitesse de page : Le saut Proxy supplémentaire peut affecter les scores Core Web Vitals, qui influencent les classements de recherche
Limitations de détection de contenu
Les Proxys identifient le contenu traduisible en analysant le HTML. Ils peuvent avoir des difficultés avec :
- Texte dans les images : Le texte intégré nécessite une traduction séparée et un remplacement de l'image
- Texte dans JavaScript : Les chaînes rendues côté client peuvent ne pas être visibles par le Proxy
- Contenu dynamique : Contenu chargé via AJAX ou WebSocket après le chargement initial de la page
- Composants UI complexes : Tooltips, modales et menus déroulants qui ne sont pas dans le HTML initial
- Données structurées : JSON-LD et autres formats de métadonnées peuvent ne pas être détectés
Dépendance au fournisseur
Votre contenu traduit réside dans le système du fournisseur Proxy. Si vous changez de fournisseur ou migrez vers un i18n basé sur le code, migrer les traductions nécessite un export/import et peut impliquer un reformatage.
Coût à long terme
Les services Proxy facturent généralement des frais mensuels basés sur le volume de trafic et le nombre de langues. Pour les sites à fort trafic avec de nombreuses langues, les coûts récurrents peuvent dépasser l'investissement unique de mise en œuvre d'un i18n basé sur le code.
Quand utiliser la traduction par Proxy
Bon choix
- Sites marketing : Sites à fort contenu où la rapidité de mise sur le marché compte plus que le contrôle détaillé
- Applications legacy : Bases de code difficiles ou coûteuses à internationaliser
- Preuve de concept : Tester si un nouveau marché est viable avant d'investir dans un i18n complet
- Sites hébergés sur plateforme : Sites sur Shopify, WordPress.com ou d'autres plateformes hébergées où vous ne pouvez pas modifier le code source
- Campagnes temporaires : Pages d'atterrissage ou sites de campagne avec une courte durée de vie
Mauvais choix
- Produits SaaS : Applications web complexes avec UI dynamique, mises à jour en temps réel et contenu généré par les utilisateurs
- Applications mobiles : Le Proxy ne fonctionne pas pour les apps mobiles natives ou hybrides
- Exigences de haute performance : Sites où chaque milliseconde de latence compte
- Besoins complets en i18n : Applications nécessitant un formatage sensible aux paramètres régionaux (dates, nombres, devises), la gestion des pluriels et le support RTL au-delà de la simple traduction de texte
i18n basé sur le code comme alternative
L'internationalisation basée sur le code intègre les traductions directement dans votre application en utilisant des bibliothèques i18n :
| Aspect | Basé sur Proxy | Basé sur le code |
|---|---|---|
| Temps de configuration | Heures à jours | Jours à semaines |
| Modifications de code requises | Aucune | Significatives (externalisation des chaînes) |
| Performance | Saut réseau supplémentaire | Aucun overhead (traductions groupées) |
| Contenu dynamique | Peut manquer le contenu côté client | Couverture complète |
| Contrôle SEO | Limité | Contrôle total |
| Formatage des paramètres régionaux | Remplacement de texte basique | Complet (dates, nombres, pluriels) |
| Coût à long terme | Frais mensuels récurrents | Coût de développement unique |
| Dépendance au fournisseur | Élevée (contenu dans le système fournisseur) | Faible (traductions dans votre dépôt) |
Bibliothèques populaires basées sur le code
- React : react-intl, next-intl, better-i18n
- Vue : vue-i18n, nuxt-i18n
- Angular : @angular/localize, ngx-translate
- Svelte : svelte-i18n
- Général : i18next (fonctionne avec la plupart des frameworks)
Approche hybride
Certaines équipes utilisent les deux approches :
- Proxy pour les pages marketing : Traduction rapide du contenu marketing, articles de blog et pages d'atterrissage
- Basé sur le code pour l'application : Contrôle i18n complet pour l'UI principale du produit
Cela fonctionne quand votre site marketing et votre application sont des déploiements séparés. Pour les applications monopages où marketing et produit partagent le même code base, une approche hybride ajoute de la complexité.
FAQ
Un Proxy peut-il traduire une application monopage (SPA) ?
Partiellement. Les Proxys fonctionnent mieux avec le HTML rendu côté serveur. Pour les SPA qui rendent le contenu côté client, le Proxy peut ne traduire que le shell HTML initial. Le contenu chargé via JavaScript après le chargement de la page peut ne pas être intercepté. Certains services Proxy offrent l'injection de fragments JavaScript pour gérer le contenu côté client, mais cela ajoute de la complexité et peut affecter les performances.
Comment la traduction par Proxy gère-t-elle les mises à jour de contenu ?
La plupart des services Proxy explorent votre site périodiquement pour détecter les changements de contenu. Le contenu nouveau ou modifié est signalé pour traduction. Le délai entre votre changement de contenu et la disponibilité de la version traduite dépend de la fréquence d'exploration et du délai de traduction. C'est moins réactif que le i18n basé sur le code, où les mises à jour de traduction se déploient avec votre code.
La traduction par Proxy est-elle bonne pour le SEO ?
Cela peut fonctionner pour le SEO si le Proxy est correctement configuré : balises hreflang appropriées, méta-balises traduites, structure d'URL propre et performances raisonnables. Cependant, vous avez moins de contrôle qu'avec le i18n basé sur le code, et déboguer les problèmes SEO est plus difficile car le Proxy se place entre vous et les robots des moteurs de recherche. Pour les sites critiques en matière de SEO, le i18n basé sur le code offre plus de contrôle et de transparence.
