La traduction par proxy inverse commence généralement de la même manière : modification du DNS, pointage du trafic vers le service de traduction, terminé.
Cette histoire s'effondre dès que le site est déjà sur Cloudflare.
Votre zone termine déjà TLS. Votre WAF filtre déjà le trafic. Votre DNS utilise déjà des enregistrements proxy orange-cloud. Pointer le sommet ailleurs revient à arracher la pile pour laquelle vous avez payé — ou pire, à créer une boucle de routage où Cloudflare parle à Cloudflare et personne ne peut atteindre la véritable origine.
C'est le problème que nous avons construit Travailleurs Cloudflare (Orange à Orange / O2O) résoudre.
Je ne voulais pas d'une autre page de fonctionnalités. J'ai pris un site déjà présent sur Cloudflare, j'ai exécuté la nouvelle configuration ConveyThis de bout en bout et j'ai pris des notes sur ce qui était évident, ce qui était surprenant et ce sur quoi vous ne devriez pas cliquer par accident.
Le problème que O2O résout réellement
Le support entend souvent cela : “Nous sommes sur Cloudflare. Pouvons-nous conserver notre configuration ?”
Avec un proxy DNS classique, la réponse honnête était : oui, mais vous traiterez ConveyThis comme un saut réseau différent. Pour de nombreuses équipes Cloudflare, ce n’est pas le bon argument. Ils veulent des URL traduites sans abandonner la zone qu’ils gèrent déjà.
Orange à orange est le nom de Cloudflare pour le trafic qui passe par deux Zones Cloudflare : la vôtre d'abord, puis celle d'un fournisseur SaaS. Vous l'activez en ajoutant un Par procuration CNAME dans votre tableau de bord qui pointe vers le nom d'hôte Cloudflare-for-SaaS du fournisseur. Cloudflare documente le modèle dans leur Aperçu de l'O2O.
En termes ConveyThis :
- Les visiteurs sont toujours touchés ton Zone Cloudflare en premier (les règles de sécurité, le DNS, les habitudes de mise en cache restent en place).
- Le trafic est ensuite acheminé vers notre zone Cloudflare pour SaaS.
- UNE Travailleur récupère votre HTML d'origine et renvoie la page traduite depuis le bord.
Vous n’échangez pas Cloudflare contre autre chose. Vous laissez Cloudflare parler à Cloudflare exprès.

ConveyThis détecte que le domaine est sur Cloudflare et propose l'option Workers (O2O).
Ce qui m'a surpris dans la configuration
Je m'attendais à une liste de contrôle intitulée “Migrez votre DNS vers nous.” Ce que j'ai obtenu était plus silencieux.
Après avoir ajouté le domaine, ConveyThis a exécuté une vérification du serveur de noms. La bannière était franche : Votre domaine est sur Cloudflare. À partir de là, sous-dossier / sous-domaine déverrouillé Travailleurs Cloudflare (O2O) comme alternative au proxy DNS standard — opt-in, non forcé.
Cela comptait plus que le texte marketing. Le produit s'est adapté à la zone que j'avais déjà, au lieu de me plonger dans des documents CNAME génériques et d'espérer remarquer le nuage orange.
J'ai choisi Sous-dossier (example.com/en/) et a changé la méthode de service en Travailleurs Cloudflare (O2O).

Le proxy DNS standard reste disponible. O2O est l'option native de Cloudflare lorsque la zone est détectée.
Le seul détail DNS qui compte réellement
ConveyThis a imprimé les enregistrements. Pour mon exécution de sous-dossier, cela signifiait des CNAME proxy vers fallback.conveythis.net — typiquement @ et www, plus un origine enregistrez afin que le travailleur puisse toujours atteindre le site réel sans revenir au proxy.
Copier/coller dans Cloudflare a pris moins d'une minute. La règle non négociable :
Chaque CNAME de routage doit rester Proxied (orange). Grey-cloud / DNS ne casse que O2O. Il n'y a pas de mode de défaillance subtil ici — le routage ne prend tout simplement pas le chemin Orange-to-Orange.

Vérifier le DNS : proxy @ / www vers fallback.conveythis.net, plus l'enregistrement d'origine du serveur réel.
Si vous utilisez plutôt le mode Sous-domaine, attendez-vous à un hôte de langue par langue (et des certificats pour chacune). Le sous-dossier maintient le nombre de noms d'hôtes plus petit — c'est pourquoi je l'ai utilisé pour ce test. Pour les compromis SEO entre ces formes d'URL, voir sous-répertoires vs. sous-domaines pour le référencement multilingue.
SSL : attendez, puis revérifiez
Une fois les enregistrements enregistrés, Cloudflare pour SaaS a émis des certificats. Pas de téléchargements, pas de fichiers ACME sur l'origine, pas de ticket d'assistance.
Je me suis rafraîchi jusqu'à ce que la table bascule vers Actif. Dans ma course : quelques minutes, puis “2 des 2 certificats actifs.”

Lorsque le statut est actif, les noms d'hôtes traduits sont prêts à être touchés.
Si le vôtre reste “Émission…” plus longtemps, résistez à l’envie de brouiller les pistes “pour accélérer les choses.” Cela aggrave généralement la situation.
La première page traduite
Voici la partie que les démos de produits ignorent : ouvrez une véritable URL après que SSL soit devenu vert.
J'ai ouvert une page traduite. Site source inchangé. Copie allemande, commutateur de langue, même mise en page — servie via le chemin Worker, pas un plugin CMS et pas une migration de serveur de noms.

La page traduite après la configuration — servie via Cloudflare Workers (O2O).
Aucune modification de thème. Non “installez notre plugin et priez.” Le résultat ennuyeux est le but.
Ce que fait réellement la demande
Pour les lecteurs qui souhaitent le schéma de câblage :
- Le visiteur demande une URL traduite.
- La demande entre ton Zone d'éruptions nuageuses.
- Le CNAME proxy le remet à ConveyThis via O2O.
- Notre Worker charge la configuration du locataire, récupère le HTML d'origine, réécrit le texte en bordure.
- Le code HTML traduit revient au visiteur ; les pages chaudes peuvent être mises en cache pour le prochain hit.
Un travail de traduction coûteux reste en dehors du chemin critique du visiteur lorsque le dictionnaire est chaud. Votre WAF a quand même vu la demande en premier. C'est tout le pitch, compressé.
Des erreurs faciles à commettre
Quelques notes de la course qui sont plus utiles qu'une autre fin heureuse :
- Nuage gris = O2O brisé. Si quelqu'un de votre équipe “DNS uniquement pour le débogage” remet le nuage orange avant de blâmer ConveyThis.
- Le décalage SSL est normal. Les certificats suivent le DNS de quelques minutes. Revérifiez ; ne reconstruisez pas la zone.
- L'accès à l'origine est la pointe de la technologie. Les configurations de sous-domaines (et certains sous-dossiers) nécessitent un moyen pour que le travailleur atteigne le serveur réel — souvent un proxy
origin.yourdomain.comenregistrement, ou une IP d'origine lorsque l'hôte ne répond pas pour ce nom. ConveyThis fait surface cela dans la configuration ; ne sautez pas la ligne car elle semble facultative. - O2O est opt-in. Si vous préférez le proxy classique, gardez-le. Détection uniquement offres Travailleurs lorsque la zone est sur Cloudflare.
Qui devrait utiliser ça
Utilisez Cloudflare Workers (O2O) si :
- Le DNS du domaine utilise déjà les serveurs de noms Cloudflare
- Vous souhaitez traduire les URL de sous-dossiers ou de sous-domaines
- Vous vous souciez de maintenir la posture WAF / Proxied ton compte
Restez fidèle au proxy DNS standard si le domaine n'est pas encore sur Cloudflare — ou si vous n'êtes pas prêt à gérer les enregistrements Proxied dans le tableau de bord Cloudflare. Les domaines non Cloudflare doivent suivre les Configuration de CNAME dans le gestionnaire DNS plutôt.
En résumé
La course, du début à la fin :
- Ajouter le domaine dans ConveyThis
- Confirmez la détection “sur Cloudflare”
- Choisissez Sous-dossier ou Sous-domaine → Travailleurs Cloudflare (O2O)
- Coller les CNAME proxy (et l'origine lorsqu'on le demande)
- Attendre Actif certificats
- Ouvrir une URL traduite
L’O2O n’impressionnera personne avec des feux d’artifice. Cela devrait sembler légèrement ennuyeux : même zone Cloudflare, nuages orange laissés allumés, pages traduites sur le bord.
Si votre site vit déjà sur Cloudflare, cet ennui est la fonctionnalité.
Questions fréquemment posées
Qu'est-ce que Cloudflare Workers (O2O) dans ConveyThis ?
Il s'agit du moyen natif de Cloudflare de diffuser des pages traduites lorsque le DNS de votre domaine réside déjà sur Cloudflare. Le trafic atteint d'abord votre zone, puis est acheminé vers ConveyThis via Orange-to-Orange et un Worker qui traduit le HTML en bordure.
Dois-je changer mes serveurs de noms Cloudflare ?
Non. O2O suppose que le domaine est déjà sur Cloudflare. Vous ajoutez des CNAME proxy dans votre tableau de bord DNS Cloudflare existant.
Quels enregistrements DNS dois-je ajouter pour O2O ?
ConveyThis affiche la liste exacte dans la configuration. Dans ce test, le sous-dossier O2O a utilisé des CNAME proxy pour @ et www pointant vers fallback.conveythis.net, plus un enregistrement d'origine pour que le travailleur puisse accéder au site réel. Gardez le nuage orange allumé.
O2O est-il meilleur pour le référencement multilingue que le proxy standard ?
Les deux peuvent utiliser des URL de sous-dossier ou de sous-domaine optimisées pour le référencement. L'avantage d'O2O est opérationnel : vous conservez Cloudflare WAF, Proxied posture et le contrôle de zone tout en obtenant des URL de langue indexables. Associez-le à solide référencement multilingue (hreflang, canoniques, structure d'URL cohérente).
Puis-je revenir au proxy DNS standard plus tard ?
Oui. O2O est opt-in. Si Workers ne convient pas, vous pouvez rester sur — ou revenir à — le chemin proxy DNS classique ConveyThis à partir des paramètres de configuration / domaine.
Est-ce que cela fonctionne sans plugin CMS ?
Oui. Le Worker récupère votre HTML en direct et renvoie une page traduite. Vous n’avez pas besoin d’une réécriture de thème WordPress/Shopify pour le chemin proxy lui-même.
Ressources utiles
Prêt à configurer Cloudflare Workers (O2O) ?
Si votre domaine est déjà sur Cloudflare, ajoutez-le dans ConveyThis, confirmez la bannière de détection et choisissez Travailleurs Cloudflare (O2O) sur Sous-dossier ou Sous-domaine.
Commencez avec notre forfait gratuit — ou se connecter et ouvrez la configuration du domaine pour voir si O2O est disponible pour votre site.