Mettre Cloudflare devant Shopify est désormais plus sûr : ce que O2O a corrigé, et ce que les avertissements signifient encore.

Démarrage rapide : à faire sur votre boutique

Si vous êtes venu pour les étapes, les voici. Toute la configuration tient en un CNAME proxifié dans Cloudflare, le même domaine connecté dans Shopify, et un réglage HTTPS auquel il ne faut pas toucher. Le reste de cet article explique pourquoi chaque étape compte et comment vérifier qu'elle a tenu, mais voici l'intégralité de la configuration.

Vous préférez regarder : Field Notes: Cloudflare in front of Shopify couvre le même terrain en trois minutes, avec une transcription complète sur la page.

L'étape 1 dans le tableau de bord Cloudflare : les deux enregistrements sont des CNAME vers shops.myshopify.com avec un Proxy status sur Proxied.

Les valeurs clawmart.digital présentées tout au long de cet article proviennent d'une boutique de test réelle que nous exploitons sur une instance Shopify pleinement fonctionnelle, pas d'une maquette. Chaque capture, enregistrement et test ci-dessous vient de cette boutique.

L’avertissement sur une boutique qui fonctionne

Votre domaine Shopify s'affiche comme connecté, le checkout fonctionne et le cadenas SSL est en place. Juste sous ce statut vert se trouve un avertissement ambre indiquant que votre domaine passe par un proxy Cloudflare, ce que Shopify ne prend pas en charge. Les deux sont vrais en même temps, et c'est sur cette contradiction que la plupart des marchands se bloquent.

C'est l'un des messages les plus déroutants de l'infrastructure e-commerce, parce qu'il n'est ni faux ni tout à fait juste. Pendant des années, placer Cloudflare devant Shopify était une vraie mauvaise idée qui cassait les boutiques d'une manière précise et prévisible. Puis Cloudflare a livré une fonctionnalité de routage qui a corrigé exactement ce qui cassait, et pourtant Shopify vous dit encore de ne pas le faire. Cet écart, entre un correctif qui fonctionne et un éditeur qui refuse de l'avaliser, c'est là que vit l'inquiétude du « ma boutique va-t-elle casser ».

Voici donc la version pratique : ce qui cassait vraiment, ce que O2O a corrigé, le seul réglage qui peut encore mettre votre site à terre si vous passez à côté, et comment décider si tout cela a sa place sur votre boutique.

Pourquoi cela cassait avant : deux nuages orange

Cloudflare représente un domaine proxifié par un nuage orange. Le trafic vers ce domaine traverse le réseau de Cloudflare avant d'atteindre votre origine. Le piège avec Shopify, c'est que Shopify tourne lui-même sur Cloudflare. Donc, quand vous faites pointer votre domaine au nuage orange vers Shopify, la requête arrive chez Cloudflare avec deux zones qui la revendiquent toutes les deux : la vôtre et celle de Shopify. Deux nuages orange, empilés.

Historiquement, Cloudflare ne pouvait pas déterminer de façon fiable quelle zone devait prendre cette requête : elle se résolvait au mauvais endroit ou bouclait. Le résultat était une boutique qui fonctionnait à moitié et échouait de façons difficiles à reproduire.

Le point le plus tranchant était le SSL. Shopify provisionne et renouvelle votre certificat via Let's Encrypt, et Let's Encrypt prouve que le domaine vous appartient avec un challenge ACME servi sur un chemin précis :

Si un proxy placé devant Shopify intercepte, met en cache ou redirige ce chemin, le challenge n'aboutit jamais. Pas de challenge abouti, pas de certificat. Et comme les certificats se renouvellent selon un calendrier, l'échec était souvent silencieux : la boutique tournait parfaitement sur le certificat existant pendant des semaines, puis passait en non sécurisé le jour de l'expiration. C'est pourquoi l'ancien conseil tenait en une ligne brutale : passez le nuage en gris, DNS only, sortez le proxy de Cloudflare du chemin.

Ce que Orange-to-Orange a changé

Orange-to-Orange, ou O2O, est la réponse de Cloudflare au problème des deux zones, et elle fait partie d'un produit appelé Cloudflare for SaaS. Cloudflare a ouvert ce produit à tous ses clients en 2021, avec une disponibilité générale en octobre : O2O est donc un chemin de routage établi, avec des années de recul, pas une expérimentation récente. Le mécanisme est simple : quand votre zone proxifiée fait pointer un CNAME vers un service qui est lui aussi client de Cloudflare for SaaS, Cloudflare reconnaît la cible et cesse de traiter les deux zones comme une collision. Il fait passer la requête par votre zone d'abord et par celle du fournisseur ensuite, dans un ordre défini, et le double proxy devient un passage de relais.

Vous n'avez pas à croire sur parole que O2O s'est activé. Créez le CNAME avec le proxy actif et Cloudflare place une petite icône Shopify à côté de l'enregistrement. Cette icône est la détection qui confirme que Cloudflare sait où va le trafic. Cloudflare fait aussi de la maintenance propre au fournisseur en arrière-plan, notamment en désactivant Workers et Snippets sur le chemin /checkout, pour que rien de ce que vous exécutez à l'edge ne puisse interférer avec le paiement.

Vous ajoutez cet enregistrement dans le tableau de bord Cloudflare, sous DNS, puis Records. Cliquez sur Add record, réglez le Type sur CNAME, la cible sur shops.myshopify.com, et le Proxy status sur Proxied pour que le nuage passe à l'orange. L'icône Shopify apparaît à côté de l'enregistrement dès que Cloudflare reconnaît la cible comme l'un de ses propres clients SaaS.

Gérer la seule exception : le SSL

O2O a corrigé la collision de routage. Il n'a pas corrigé le SSL, parce que le SSL n'a jamais vraiment été un problème de routage. C'était un proxy qui touchait au seul chemin que Shopify utilise pour renouveler les certificats. Sur une boutique correctement configurée, presque tout cela tourne désormais tout seul : l'utile est donc de savoir ce qui est automatique, puis de vérifier la courte liste de ce qui ne l'est pas.

Ce qui se fait automatiquement aujourd'hui

Votre boutique porte deux certificats, et les deux se renouvellent sans vous. Comme le domaine est proxifié, le certificat que voient les visiteurs est le certificat edge de Cloudflare, que Cloudflare valide par DNS et renouvelle tout seul : le chemin ACME ne le concerne donc jamais. Derrière, Shopify conserve un certificat d'origine distinct pour le segment entre Cloudflare et Shopify, renouvelé via Let's Encrypt, et votre mode de chiffrement Full est fait pour lui faire confiance. Shopify assure aussi le passage de HTTP à HTTPS à sa propre origine, si bien que les visiteurs arrivent sur une connexion sécurisée que Cloudflare lève le petit doigt ou non.

Ce certificat d'origine se renouvelle via ACME, l'échange automatisé que Let's Encrypt utilise pour confirmer que vous contrôlez le domaine. Il demande à ce qui répond pour votre domaine de servir un jeton à usage unique sur le chemin ci-dessus, en HTTP simple, et Shopify gère tout l'échange en arrière-plan. C'est pour cela que vous n'y pensez jamais. La configuration reste saine exactement aussi longtemps que ce chemin reste accessible.

La seule chose qui casse tout

Tout ce renouvellement automatique repose sur un seul réglage Cloudflare qui doit rester désactivé, et il est activé par défaut dans bon nombre de configurations.

Le correctif consiste donc surtout à ne pas activer ce bouton et à laisser la redirection d'origine de Shopify faire la conversion qu'elle assure déjà. Si vous voulez aussi que Cloudflare impose le HTTPS à son propre edge, utilisez une règle de redirection qui ignore le chemin du challenge, jamais Always Use HTTPS.

Ce qu'il faut vérifier

Tout ce qui suit se trouve dans le tableau de bord Cloudflare. Connectez-vous sur dash.cloudflare.com, choisissez votre compte et cliquez sur le domaine pour ouvrir sa zone. Chaque point correspond à un chemin dans la barre latérale gauche de cette zone.

Un voisin sur cette page Edge Certificates fait souvent trébucher : Automatic HTTPS Rewrites peut rester activé sans risque. Il se contente de réécrire les liens de ressources http en https pour éviter les avertissements de contenu mixte, ce qui n'a rien à voir avec Always Use HTTPS qui force une redirection de page entière. Opportunistic Encryption et TLS 1.3 peuvent rester activés eux aussi. Always Use HTTPS est le seul bouton de cet écran qui doit rester désactivé.

Confirmez ensuite depuis l'extérieur, sans attendre l'échec d'un renouvellement. Demandez le chemin du challenge en HTTP simple et lisez la réponse :

curl -sI http://clawmart.digital/.well-known/acme-challenge/test

Atteindre Shopify, c'est gagné, et un 404 pour le jeton inventé est exactement ce qu'il faut. Une redirection 301 ou 308 vers HTTPS signifie qu'Always Use HTTPS ou une règle fourre-tout avale encore ce chemin. Ensuite, vérifiez le statut SSL sous Settings → Domains dans votre admin Shopify, et au fil des semaines suivantes regardez la date d'expiration du certificat d'origine avancer d'elle-même. Un certificat qui se renouvelle sans intervention est le signal que la configuration tient.

Refaites ce test après chaque modification de vos DNS ou de vos réglages Cloudflare, pas seulement à l'installation. Hardeep, membre de la Shopify Community, l'a soulevé dans le fil de discussion consacré à cet article, et cela correspond à la façon dont ces configurations tombent en pratique. La configuration était bonne le premier jour, quelqu'un a modifié une règle ou un enregistrement des mois plus tard, et personne n'a revérifié le chemin du challenge avant qu'un certificat ne se renouvelle pas, en silence.

Un piège mérite d'être nommé clairement : un certificat qui apparaît comme provisionné aujourd'hui vous dit que le certificat actuel a bien été émis, pas que le prochain renouvellement aboutira. Les certificats Let's Encrypt se renouvellent sur un cycle d'environ soixante à quatre-vingt-dix jours : une boutique qui paraît en parfaite santé peut simplement ne pas avoir encore atteint sa date de renouvellement. Cela, plus le fait que beaucoup de boutiques n'ont jamais activé Always Use HTTPS, explique pourquoi tant d'entre elles tournent ainsi pendant des mois sans le moindre souci, et pourquoi la panne, quand elle arrive, est déroutante. Rien n'a changé, sauf un certificat qui ne s'est pas renouvelé, sans bruit.

Donnez-lui le poids qu'il mérite. C'est une assurance peu coûteuse contre une panne rare mais silencieuse, pas le signe que votre boutique est sur le point de casser. Faites la configuration en deux minutes, lancez le test, et vous aurez refermé la seule faille au moment du renouvellement qui soit vraiment difficile à repérer.

Shopify ne validera toujours pas cette configuration, parce que…

La documentation de Shopify ne parle plus vaguement de « proxys » en général. Elle nomme O2O directement :

« Les configurations avec proxy Cloudflare, O2O compris, ne sont pas prises en charge par Shopify. Même si votre boutique semble fonctionner correctement, cette configuration peut casser à tout moment. »

Ce n'est pas un avertissement périmé au sujet d'un problème résolu. C'est une position actuelle et assumée, et deux des raisons qui la sous-tendent tiennent toujours après O2O :

La documentation de Shopify ajoute une troisième raison, la détection des bots, en avançant que le trafic passant par Cloudflare lui parvient avec des attributs de requête modifiés. En pratique, c'est la plus faible des trois : Cloudflare exploite l'un des plus grands réseaux de gestion des bots qui soient, si bien que la plupart des boutiques gagnent bien plus de filtrage à l'edge que Shopify ne perd de signal. C'est le seul point de la liste de Shopify où le proxy a plus de chances d'aider que de nuire.

L’avertissement est-il excessif ?

Un peu, et cela se comprend. Le tableau de bord signale une boutique connectée et fonctionnelle avec un « Issue » ambre et la formule sèche « not supported », qui pèse plus lourd que les vrais modes de défaillance, évitables pour la plupart avec une configuration correcte. Un marchand lit « Issue » et entend « votre boutique va casser », alors que Shopify veut plutôt dire « nous ne nous portons pas garants de cela ».

Mais « non pris en charge » n'est pas « ne fonctionne pas », et la distinction compte. Cela signifie que Shopify ne garantira pas, ne débuguera pas et n'assumera pas la responsabilité du comportement d'une couche qu'il ne contrôle pas. Pour une plateforme qui détient votre checkout et votre disponibilité, c'est une limite raisonnable à poser, même si la bannière la pose sans nuance. Le signalement vous dit que Shopify ne se portera pas garant de la configuration. Il ne vous dit pas que la configuration est en train d'échouer.

De nombreuses boutiques Shopify tournent ainsi

Vous n'avez pas à vous fier à une seule boutique de test. Un proxy Cloudflare devant Shopify n'est pas une configuration marginale : beaucoup de marques établies l'exploitent en production, tous les jours. Les noms ci-dessous sont des exemples réels que nous avons vérifiés à la main, chacun servant actuellement sa vitrine à travers un proxy Cloudflare avec Shopify derrière.

Vérifié en juillet 2026 en interrogeant chaque domaine et en confirmant une réponse de proxy Cloudflare ainsi que des marqueurs de vitrine Shopify. La configuration d'une boutique peut changer à tout moment : voyez donc cette liste comme un instantané, pas comme une recommandation de la part des marques citées.

Ce que l’edge vous apporte et que Shopify n’offre pas

Shopify fournit déjà un CDN, des certificats SSL et une protection anti-DDoS sur tous les forfaits, comme Hardeep l'a également souligné dans le fil de la communauté. Ce n'est pas le proxy qui rend votre boutique rapide, chiffrée ou capable d'absorber une vague de trafic, et si c'est ce que vous cherchiez, vous l'avez déjà. Ce qui suit est l'ensemble plus restreint de choses que Shopify ne vous donne pas.

La raison d'accepter le compromis n'est pas le proxy en lui-même. C'est la couche que le proxy place devant votre boutique : un edge programmable auquel Shopify ne vous donne pas accès. Trois capacités comptent avant tout, et la troisième est celle que la plupart des boutiques ne voient jamais.

Rien de tout cela n'est inclus dans un forfait Shopify, parce que rien de tout cela ne vit à l'intérieur de Shopify. Cela vit un saut plus tôt, à l'edge, ce qui est toute la raison pour laquelle un marchand accepterait un proxy non pris en charge.

Une réserve : la mise en cache à l'edge n'est pas automatique. Cloudflare peut conserver des fichiers statiques comme les feuilles de style et les images à son edge et les servir depuis un serveur proche au lieu d'aller les chercher chez Shopify à chaque visite, mais une boutique Shopify proxifiée ne met rien en cache d'elle-même, et une règle de cache par défaut ou mal ciblée peut supprimer complètement ce comportement : des fichiers marqués comme cachables pour un an passent alors directement, sans être retenus. Le réseau de Shopify garde de toute façon la vitrine rapide : voyez donc le cache à l'edge comme un bonus de vitesse auquel vous choisissez de souscrire. Vous confirmez le mode de chiffrement qui prévient les anciens problèmes SSL dans les configurations SSL/TLS, le même écran que le bouton Configure vu plus haut ; le cache se règle dans sa propre section, et il vaut donc la peine de vérifier les deux tant que vous êtes dans le tableau de bord, le cache étant le réglage qui laisse le plus souvent de la vitesse sur la table.

Ce qu’un développeur vous signalera

Un bon développeur ne laissera pas passer cela sans poser de questions, et ces questions sont légitimes. Aucune n'est une raison d'éviter la configuration, mais chacune mérite d'être vérifiée sur votre propre boutique plutôt que d'être prise pour acquise. Ce n'est pas du travail en plus : ce sont les mêmes tests que vous feriez après n'importe quel changement d'infrastructure, et cela fait partie de l'entretien d'une boutique en bonne santé. Nous testons les deux points suivants sur la boutique que nous exploitons, et vous devriez faire de même.

La latence au passage de relais

La première question est celle de la vitesse : le passage par votre zone Cloudflare avant celle de Shopify ajoute-t-il un temps perceptible ? Cela ne devrait pas, car les deux zones se trouvent déjà sur le même réseau Cloudflare : le relais a donc lieu à l'intérieur de ce réseau plutôt que sur l'internet ouvert. Nous l'avons mesuré sur clawmart.digital, la boutique de test proxifiée, face à des points de terminaison Shopify bruts en myshopify.com, depuis la même machine. La boutique proxifiée répondait à l'edge en 150 à 200 millisecondes environ, la même plage que les points de terminaison Shopify non proxifiés testés à côté. Le saut supplémentaire se perdait dans la variabilité normale d'une mesure à l'autre.

Quand une boutique Shopify proxifiée paraît lente, la cause est presque toujours un thème lourd ou une application tierce lente, pas le proxy. Mesurez avant d'accuser l'edge. Le temps jusqu'au premier octet, mesuré plusieurs fois depuis un même endroit, est la lecture la plus rapide :

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://clawmart.digital/

Comparez ce résultat à une référence en nuage gris (DNS only), ou à votre adresse myshopify.com, ou encore à un test WebPageTest. Quelques millisecondes d'écart signifient que le proxy n'est pas votre goulot d'étranglement. Des centaines de millisecondes signifient que ce sont le thème et la pile d'applications, et c'est là qu'il faut passer du temps : alléger le thème, supprimer les applications que vous n'utilisez plus et corriger le chargement des images feront bouger le chiffre bien plus que tout ce que vous pourrez configurer à l'edge.

Les applications dans le checkout

La deuxième question porte sur le checkout : le proxy va-t-il perturber les applications de checkout extensibility, le paiement ou les scripts qui s'exécutent à l'étape la plus importante ? Par conception, il ne devrait pas. Le routage O2O de Cloudflare désactive Workers et Snippets sur le chemin /checkout précisément pour que rien de ce que vous exécutez à l'edge ne puisse toucher au paiement. Lors de nos tests, aucune des applications de checkout extensibility populaires ne s'est mal comportée derrière cette configuration. C'est notre expérience, pas une garantie pour toutes les applications du marché : effectuez donc toujours vous-même un checkout complet.

Passez une vraie commande avec vos applications actives : vérifiez que les remises, la logique de livraison, les upsells et les éventuelles extensions post-achat se déclenchent comme sans le proxy, et que la commande arrive dans Shopify avec les attributs attendus. Si une application doit mal se comporter, cela se voit ici, sur votre commande de test, bien avant qu'un client ne le rencontre.

Vos fonctionnalités Shopify continueront-elles de fonctionner ?

C'est la question que les marchands posent juste avant de renoncer : si Cloudflare se place devant, ce que je gère dans Shopify se comporte-t-il toujours pareil ? Celle qui inquiète le plus concerne les redirections d'URL, parce qu'elles se gèrent dans l'admin Shopify, qu'elles comptent pour le SEO, et qu'il n'est pas évident de savoir si un proxy placé devant va les mettre en cache, les réécrire ou les avaler.

Nous l'avons donc testé sur la boutique proxifiée plutôt que de raisonner dessus. Nous avons créé une 301 dans l'admin Shopify depuis /pages/redirect-test-20260727 vers la page d'accueil, vérifié au préalable que ce chemin renvoyait un 404 pour que rien de réel ne soit affecté, contrôlé le résultat sous plusieurs angles, puis supprimé la redirection.

La réponse propre à Cloudflare est dans cette dernière ligne. Il a laissé passer les redirections telles quelles et ne les a jamais mises en cache : votre logique de redirection reste donc entièrement sous le contrôle de Shopify. Ce n'est pas de la chance non plus : Shopify envoie cache-control: private, no-store sur la 301 elle-même, si bien que Cloudflare ne la mettrait pas en cache même si vous le lui demandiez. Les chaînes de requête survivent, l'apex fonctionne, et le HTTP simple fonctionne.

Un détail du nettoyage mérite d'être connu, car il ressemble à un problème Cloudflare sans en être un. Après la suppression de la redirection, l'URL nue a continué de servir l'ancienne 301 pendant une trentaine de secondes, alors qu'une version de la même URL avec cache-buster renvoyait déjà un 404. C'était un seul nœud edge de Shopify qui gardait une copie périmée, pas Cloudflare : cf-cache-status est resté DYNAMIC tout du long et la variante avec chaîne de requête était correcte immédiatement. Cela s'est résolu tout seul. Après avoir modifié ou supprimé une redirection, laissez donc passer une minute avant de conclure que cela n'a pas fonctionné, et testez avec un cache-buster en cas de doute.

Cela rejoint aussi la réserve sur le cache évoquée plus haut, et cela joue dans les deux sens. Avec le cache à l'edge désactivé, les modifications de redirections prennent effet instantanément, ce qui est un avantage accidentel. Si vous activez plus tard la mise en cache du HTML à l'edge, les redirections peuvent y être mises en cache elles aussi et vos modifications cesseront d'apparaître immédiatement. Dans ce cas, excluez les chemins de redirection de la règle de cache ou intégrez une étape de purge dans l'outillage que vous utilisez pour gérer les redirections en masse.

Configurer avant que la boutique soit publique

Vous n'avez pas besoin d'une vitrine lancée pour configurer et tester tout cela. Il est même souvent plus malin de le faire tant que la boutique est privée, pour que la détection O2O, le provisionnement SSL et le test de checkout se déroulent là où aucun client ne peut tomber sur une configuration à moitié terminée. La seule exigence est un forfait Shopify payant, car les domaines personnalisés ne sont pas disponibles en essai gratuit. Vous n'avez pas pour autant à lancer la boutique : un forfait payant gardé derrière sa page de mot de passe suffit à toute la configuration. Si vous êtes sur une boutique de développement Partner gratuite, qui restreint les domaines personnalisés, transférez-la d'abord sur un forfait payant, puis suivez les mêmes étapes.

Faut-il donc l’adopter ?

Transformez la question en une décision sur ce dont vous avez besoin à l'edge, plutôt qu'en un oui ou non, car c'est la seule chose qui justifie le compromis.

Steve_TopNewYork et sophia24, membres de la Shopify Community, ont tous deux abouti à cette troisième raison dans le même fil, et c'est le coût que les marchands sous-estiment. Le proxy est rarement ce qui casse, mais une fois qu'il est dans le chemin, c'est une couche de plus à écarter à deux heures du matin quand le checkout se comporte mal et que vous ne savez pas encore pourquoi. C'est une charge réelle pour une petite équipe, et elle ne vaut la peine d'être payée que pour une fonctionnalité que vous savez nommer.

Si vous l'adoptez, traitez la checklist comme non négociable : un CNAME proxifié vers shops.myshopify.com, la confirmation que l'icône Shopify apparaît, Always Use HTTPS laissé désactivé, le chemin ACME exclu de votre redirection HTTPS, et la vérification de la date de renouvellement du certificat comme vous vérifieriez qu'une sauvegarde s'est bien exécutée. Configurées ainsi, beaucoup de boutiques tournent avec Cloudflare devant Shopify sans le moindre drame. Sautez ces étapes et vous aurez mis en place exactement la panne silencieuse que l'avertissement cherche à éviter.

La version courte, en vidéo : Field Notes: Cloudflare in front of Shopify détaille ce que O2O a corrigé et les deux choses qu'un service à l'edge vous montre et que Shopify ne montre pas.

Questions fréquentes

Est-il sûr de placer Cloudflare devant une boutique Shopify ?

C’est bien plus viable qu’auparavant, mais Shopify ne le prend pas officiellement en charge : c’est donc un choix calculé et non une option sans risque. Le problème de routage qui cassait les boutiques, deux zones Cloudflare qui entraient en collision, a été résolu par la fonctionnalité Orange-to-Orange (O2O) de Cloudflare. Correctement configurée, c’est-à-dire avec un CNAME proxifié vers shops.myshopify.com, sans Always Use HTTPS, et avec le chemin du challenge ACME exclu de toute redirection HTTPS, de nombreuses boutiques tournent ainsi de façon fiable. La documentation de Shopify indique toujours que les configurations avec proxy Cloudflare, O2O compris, ne sont pas prises en charge et peuvent casser à tout moment, parce que Shopify ne peut pas garantir le comportement d’une couche de proxy qu’il ne contrôle pas. Le résumé honnête : techniquement solide quand c’est bien monté, officiellement non pris en charge, à réserver aux boutiques qui ont besoin à l’edge de quelque chose que Shopify ne fournit pas.

Qu’est-ce que Orange-to-Orange (O2O) ?

Orange-to-Orange est la fonctionnalité de routage de Cloudflare pour le cas où un client Cloudflare fait pointer son domaine proxifié vers un service qui est lui aussi client de Cloudflare. Le proxy de Cloudflare est représenté par un nuage orange dans le tableau de bord : deux zones Cloudflare empilées, c’est donc de l’orange vers l’orange. Shopify est client de Cloudflare for SaaS, et une boutique Shopify correspond exactement à ce cas de figure. Avant O2O, Cloudflare ne pouvait pas déterminer de façon fiable quelle zone devait prendre la requête et les deux entraient en collision. O2O détecte que la cible du CNAME appartient à un autre client Cloudflare et fait passer la requête par votre zone d’abord, puis par celle du fournisseur, dans cet ordre. Vous pouvez confirmer que cela fonctionne quand une petite icône Shopify apparaît à côté de l’enregistrement CNAME dans votre tableau de bord Cloudflare.

Pourquoi Shopify dit-il que Cloudflare n’est pas pris en charge ?

La documentation de Shopify avance trois raisons principales. Deux tiennent parfaitement la route. D’abord le SSL : Shopify émet et renouvelle les certificats via Let’s Encrypt en utilisant un challenge HTTP ACME, et tout proxy placé devant est un élément de plus susceptible d’interférer avec cette validation. Ensuite la gestion des incidents : quand l’infrastructure de Shopify rencontre un problème, des proxys supplémentaires devant la boutique compliquent le reroutage par Shopify, ce qui augmente votre exposition aux pannes au lieu de la réduire. La troisième, la détection des bots, est plus faible : Shopify avance que le trafic passant par Cloudflare arrive avec des attributs de requête modifiés, mais Cloudflare exploite l’un des plus grands réseaux de gestion des bots au monde, si bien que la plupart des boutiques gagnent plus de filtrage à l’edge que Shopify ne perd de signal. Aucune de ces raisons ne signifie que la configuration ne peut pas fonctionner. Elles signifient que Shopify n’assumera pas la responsabilité du comportement d’une couche qui ne lui appartient pas.

Pourquoi mon certificat SSL Shopify échoue-t-il derrière Cloudflare ?

Presque toujours à cause du réglage Always Use HTTPS. Shopify valide la propriété du domaine et renouvelle les certificats SSL en répondant à un challenge servi sur le chemin /.well-known/acme-challenge/. Always Use HTTPS impose une redirection sur chaque requête, y compris sur ce chemin : le challenge n’aboutit donc jamais et le certificat ne peut être ni émis ni renouvelé. La boutique continue de fonctionner sur le certificat existant jusqu’à son expiration, puis le domaine passe en non sécurisé ou cesse de répondre. Le correctif documenté par Cloudflare consiste à laisser Always Use HTTPS désactivé et à créer à la place une règle de redirection qui force le HTTPS partout sauf sur le chemin /.well-known/acme-challenge/.

Dois-je poser un rappel dans mon agenda pour vérifier le renouvellement SSL afin que ma boutique ne casse pas ?

Non, pas si la configuration est correcte. Le renouvellement est conçu pour se faire tout seul. Le certificat que vos visiteurs voient réellement est le certificat edge de Cloudflare, que Cloudflare valide par DNS et renouvelle automatiquement : il ne dépend donc jamais du chemin du challenge ACME. Derrière, le certificat d’origine de Shopify se renouvelle via Let’s Encrypt en arrière-plan, et cela continue de fonctionner tant qu’Always Use HTTPS reste désactivé et que le chemin /.well-known/acme-challenge/ n’est pas redirigé. Lancez le test curl une fois après la configuration pour confirmer que ce chemin renvoie un 404 et non une redirection, et le renouvellement automatique aura tout ce qu’il lui faut. Si vous voulez un filet de sécurité, le bon outil n’est pas un rappel manuel dans l’agenda qui demande une action de votre part, c’est une surveillance automatisée de l’expiration SSL qui vous envoie un e-mail si le certificat approche de l’expiration à quelques semaines près. Ainsi, rien ne dépend de votre mémoire.

Comment être prévenu avant qu’un problème de certificat ne mette la boutique hors ligne ?

Mettez en place une surveillance pour être averti plutôt que de l’apprendre par un client. Un outil gratuit de surveillance SSL et de disponibilité comme UptimeRobot, Better Uptime ou un service équivalent peut surveiller le domaine et vous alerter plusieurs jours avant l’expiration d’un certificat, ou dès l’instant où le HTTPS commence à échouer. Cloudflare peut lui aussi envoyer des notifications sur les problèmes de certificat et d’origine depuis la zone Notifications du tableau de bord. Avec l’un ou l’autre en place, l’échec silencieux de renouvellement, le seul vrai risque de cette configuration, cesse d’être silencieux : vous recevez un e-mail avec plusieurs semaines d’avance, bien avant que le cadenas ne lâche pour vos acheteurs.

Les redirections d’URL Shopify fonctionnent-elles toujours derrière un proxy Cloudflare ?

Oui. Nous l’avons testé de bout en bout sur une boutique proxifiée : une 301 créée dans l’admin Shopify est devenue active immédiatement, sans attente de propagation, a renvoyé la bonne 301 et le bon en-tête location, a mené jusqu’à un 200 sur la cible en un seul saut, a conservé les chaînes de requête comme ?utm_source=test, et a fonctionné depuis le domaine apex et en HTTP simple. Cloudflare a laissé passer la redirection telle quelle et ne l’a jamais mise en cache, en rapportant cf-cache-status: DYNAMIC sur chaque requête : votre logique de redirection reste donc entièrement sous le contrôle de Shopify. Shopify envoie par ailleurs cache-control: private, no-store sur la 301 elle-même, si bien que Cloudflare ne la mettrait pas en cache même si vous le lui demandiez. Une réserve : après la modification ou la suppression d’une redirection, un nœud edge de Shopify peut servir une copie périmée pendant une trentaine de secondes ; laissez donc passer une minute et testez avec un cache-buster avant de conclure que cela n’a pas fonctionné. Si vous activez plus tard la mise en cache du HTML à l’edge Cloudflare, excluez les chemins de redirection ou ajoutez une étape de purge, car les redirections peuvent y être mises en cache elles aussi.

Puis-je configurer Cloudflare sur une boutique Shopify qui n’est pas encore publique ?

Oui, et c’est souvent la manière intelligente de procéder. Vous n’avez pas besoin d’une vitrine lancée, seulement d’un forfait Shopify payant, puisque les domaines personnalisés ne sont pas disponibles en essai gratuit. Gardez la boutique derrière sa page de mot de passe sous Online Store puis Preferences, créez dans Cloudflare le même CNAME proxifié vers shops.myshopify.com en utilisant un hôte que vous ne servez pas en production, par exemple un sous-domaine de préproduction, et connectez cet hôte dans Shopify sous Settings puis Domains. Shopify provisionne le SSL et le tableau de bord Cloudflare affiche l’icône Shopify dès qu’Orange-to-Orange s’active, pendant que le public ne voit que la page de mot de passe. Lancez le test curl ACME et une commande de test complète avec vos applications actives, puis, quand tout passe, retirez le mot de passe et définissez votre vrai domaine comme domaine principal. Vous lancez sur une configuration déjà éprouvée. Si vous êtes sur une boutique de développement Partner gratuite, qui restreint les domaines personnalisés, transférez-la d’abord sur un forfait payant.