Le guide serein pour bloquer le trafic de bots sur Shopify

Dernière vérification en juillet 2026. Cloudflare et Shopify changent souvent leurs dashboards et leurs politiques ; quand ce guide décrit un réglage, nous décrivons ce qu'il fait, pas où se trouve le bouton ce mois-ci.

Un marchand avec qui nous travaillons a ouvert son rapport de trafic et découvert qu'environ 70 % venait de Chine. Il n'y vend pas, n'y livre pas, n'y fait aucune publicité. Commandes issues de ce trafic : zéro. Un autre a compté 250 000 sessions en un mois et conclu qu'environ 215 000 d'entre elles étaient des bots.

Aucune de ces boutiques n'est un cas isolé. Pendant les fêtes 2024, les bots ont représenté 57 % du trafic des sites e-commerce, la première fois que le trafic automatisé dépassait les acheteurs humains, selon le rapport 2025 de Radware sur les bots en e-commerce. Ce chiffre compte tous les bots, bons et mauvais. En ne comptant que les mauvais, le Bad Bot Report 2025 d'Imperva évalue les bots malveillants à 33 % du trafic des sites retail en 2024, contre 26 % l'année précédente. En juin 2026, le PDG de Cloudflare rapportait que les systèmes automatisés avaient dépassé les humains en requêtes HTML sur le réseau de Cloudflare, à 57,5 %.

Si votre boutique tourne sur Shopify, ce trafic n'est pas qu'un bruit de fond dans un graphique. Il gonfle chaque outil que vous payez à la session. Il remplit vos analytics de visites qui n'achèteront jamais, ce qui corrompt en silence chaque décision prise à partir de ces chiffres. Il envoie des signaux parasites à vos pixels publicitaires, et Meta comme Google optimisent alors vers plus de parasites. Et fin 2025, une vague exactement de ce type a frappé des milliers de boutiques Shopify d'un coup, remplissant les forums de la communauté Shopify de marchands décrivant un trafic composé de 50 à 90 % de bots, venu de pays où ils n'avaient jamais vendu.

La solution existe, et ce n'est pas une app. C'est placer un compte Cloudflare gratuit devant votre boutique et filtrer le trafic à la périphérie du réseau, avant même qu'il n'atteigne Shopify. La mise en place comporte une étape réellement stressante, le déplacement de votre DNS, et une poignée de décisions faciles à rater, dont une qui peut vous rendre invisible, sans bruit, aux assistants IA qui commencent à envoyer de vrais acheteurs.

Ce guide déroule tout : comment mesurer votre part de bots, quels bots garder délibérément, quelle stratégie convient à votre boutique, le déplacement du DNS avec une checklist de préparation et un plan de retour arrière, et comment vérifier ensuite que rien n'a cassé. Rien ici n'exige un développeur ; si vous en avez un, le chapitre DNS est la partie à lui confier.

Votre dashboard vous ment, et cela vous coûte de l'argent

Commençons par ce qui justifie d'y consacrer un après-midi, parce que «mes sessions sont gonflées» est très en dessous de la réalité.

Des outils facturés au trafic. Une bonne partie de l'écosystème d'apps Shopify facture à la session ou à la page vue. Lucky Orange, une app populaire de heatmaps et d'enregistrement de sessions, va de 32 $ par mois pour 3 500 sessions à 839 $ par mois pour 300 000. OptiMonk facture à la page vue. Des outils d'analytics comme Matomo facturent au hit. Ces éditeurs filtrent les bots connus, mais les vagues récentes utilisent des proxys résidentiels et une navigation imitant l'humain précisément pour passer ce filtre. Si 60 % de vos sessions sont des bots, vous payez peut-être un palier tarifaire pour une audience composée à 60 % de personne. Dans les fils de la communauté sur la vague de 2025, les marchands rapportaient exactement cela : des factures à l'usage qui grimpent sur un trafic qui ne pourra jamais acheter.

Des signaux publicitaires empoisonnés. Vos pixels Meta et Google apprennent du trafic qu'ils voient. Des sessions de bots avec 100 % de rebond et zéro intention d'achat enseignent à l'algorithme les mauvaises leçons, et si des bots cliquent sur vos annonces payantes, le budget brûle directement. Dans les fils de la communauté sur la vague de 2025, l'apprentissage corrompu du Meta Pixel était le dégât le plus souvent cité, devant les analytics eux-mêmes.

Des décisions prises sur de la fiction. Le taux de conversion, ce sont les commandes divisées par les sessions. Inondez le dénominateur et votre taux de conversion s'effondre, vos rapports par pays pointent vers des marchés qui n'existent pas, et votre attribution par canal dérive. Le rapport retail d'Imperva cite littéralement le biais des analytics comme activité standard des mauvais bots. Si vous merchandisez à partir de vos données, rétrograder ce qui ne bouge pas, mettre en avant ce qui marche, voilà le coût silencieux : les données elles-mêmes se gâtent.

Une charge que personne ne paie de gaieté de cœur. Chaque page vue par un bot est servie par une infrastructure bien réelle. Sur les plans Shopify standard, la bande passante est le problème de Shopify, mais chaque outil de votre stack qui mesure l'usage la ressent, et pour les boutiques headless, la ligne bande passante est directe et immédiate.

Combien cela représente-t-il pour votre boutique ? Plus loin dans ce guide, un calculateur vous attend : cochez ceux de vos outils facturés au trafic, entrez vos sessions et votre part de bots, et voyez le montant annuel.

Mesurez l'ampleur des dégâts

Avant de changer quoi que ce soit, mesurez. Vous découvrirez peut-être une part de bots de 8 %, auquel cas fermez cet onglet et passez à plus utile. Les marchands qui ont besoin de ce guide trouvent en général un chiffre plus proche de la moitié.

Dans l'admin Shopify :

• Ouvrez le rapport des sessions par localisation et posez-le à côté des commandes par localisation. Un pays qui produit des milliers de sessions et zéro commande, c'est la signature classique. Les conseils de Shopify pour identifier l'activité des bots recommandent de surveiller les sessions venant de datacenters connus, et citent Ashburn en Virginie et Los Angeles ; les marchands de la communauté ajoutent Council Bluffs dans l'Iowa, qui abrite une région Google Cloud.
• Depuis octobre 2025, les rapports Shopify incluent une dimension "Human or bot session" (session humaine ou bot) sur laquelle filtrer (docs Shopify). Utilisez-la, mais connaissez ses limites : elle ne couvre que les données à partir du 7 octobre 2025, elle est volontairement prudente (Shopify préfère manquer des bots plutôt que mal étiqueter un vrai client), et elle n'existe pas pour les boutiques headless. Traitez son chiffre comme un plancher, pas comme un total.
• Passez en revue le rapport des termes recherchés dans votre boutique, à la recherche de requêtes qui ressemblent à des chaînes générées par machine, et votre liste clients, à la recherche de noms absurdes. Shopify cite les deux comme indices de bots.
• Regardez des fenêtres de 30 à 90 jours. Les fenêtres courtes fluctuent trop pour être lisibles.

Dans GA4 : Google filtre déjà automatiquement les bots connus ; tout ce qui reste suspect a donc déjà franchi ce premier filtre. La signature composite qui survit : un taux d'engagement proche de zéro, plus une source Direct ou «(not set)», plus un pays hors de vos marchés. Chacun de ces indices seul est une preuve faible. Les trois ensemble, en volume, c'est presque une certitude.

Une réserve structurelle. Les analytics Shopify, GA4 et vos pixels sont tous des compteurs JavaScript qui tournent dans le navigateur du visiteur. Un bot qui n'exécute jamais de JavaScript leur est invisible tout en chargeant vos pages. Quel que soit le chiffre affiché par vos dashboards, la périphérie du réseau en voit davantage. Votre premier décompte honnête viendra après la mise en place Cloudflare ci-dessous, via ses analytics de trafic, et il est normal qu'il fasse l'effet d'un choc.

Notez vos chiffres : sessions totales, part de bots suspectée, et quels pays ou motifs dominent. Le choix de stratégie ci-dessous en dépend, et la comparaison avant-après est ce qui prouvera que le travail a payé.

Les bots que vous voulez garder

Voici la partie que tous les tutoriels «bloquez les bots» sautent, et la raison de ne pas simplement pousser toutes les défenses au maximum.

Certains bots sont la plomberie de votre visibilité. Googlebot et Bingbot décident si vous existez dans les résultats de recherche. Le crawler d'aperçus de liens de Meta décide si vos produits s'affichent correctement quand quelqu'un les partage. Et une classe plus récente pèse un peu plus chaque trimestre : les crawlers et récupérateurs derrière les assistants IA.

Ils ne forment pas un bloc. Les bots IA se divisent en trois familles, et c'est en les confondant qu'une boutique disparaît des radars par accident :

• Les crawlers d'entraînement (GPTBot d'OpenAI, ClaudeBot d'Anthropic, meta-externalagent de Meta) collectent du contenu pour entraîner les futurs modèles. Les bloquer est un choix d'entreprise légitime, sans effet sur votre visibilité aujourd'hui.
• Les indexeurs de recherche (OAI-SearchBot, Claude-SearchBot, PerplexityBot) construisent les index dans lesquels les assistants IA puisent leurs réponses. La documentation d'OpenAI est sans détour : les sites qui refusent OAI-SearchBot «n'apparaîtront pas dans les réponses de ChatGPT search» (docs bots d'OpenAI).
• Les récupérateurs à la demande (ChatGPT-User, Claude-User, Perplexity-User) chargent une page parce qu'un humain vient de poser une question, là, maintenant. Bloquez-les et l'assistant ne peut pas lire votre page produit au moment exact où un acheteur demande «cette veste taille-t-elle normalement, est-elle en stock ?»

Ce trafic pèse-t-il déjà ? L'analyse d'Adobe sur les sites retail américains a mesuré un trafic issu de l'IA en hausse de 693 % sur un an pendant les fêtes 2025, et, plus intéressant, ces visiteurs convertissaient 31 % mieux que le visiteur moyen. C'est un renversement : un an plus tôt, la même mesure montrait des visites issues de l'IA qui convertissaient moins bien. Le canal est passé de curiosité à qualité en une douzaine de mois. Il reste petit en valeur absolue, mais c'est le seul canal de referral qui croît à ce rythme, et les acheteurs qu'il envoie arrivent déjà convaincus par un assistant qui a lu vos pages.

Il y a une vraie asymétrie à peser honnêtement : les mesures de Cloudflare montrent que les entreprises d'IA crawlent bien plus qu'elles ne renvoient de visites (en août 2025, Anthropic crawlait environ 50 000 pages par visite renvoyée, OpenAI moins de 900, Perplexity autour de 118). La charge de crawl est un coût réel et sert surtout l'entraînement. C'est exactement pourquoi la bonne posture se règle bot par bot, pas en tout ou rien : gardez les indexeurs de recherche et les récupérateurs qui produisent des acheteurs, tranchez consciemment pour les crawlers d'entraînement, et bloquez les imposteurs qui ne respectent rien.

Une raison de plus de faire cela à la périphérie du réseau plutôt qu'avec un fichier robots.txt : robots.txt est une demande polie, et Shopify note lui-même que les règles de crawl sont «indicatives et consultatives». Les crawlers sérieux les respectent ; les bots qui inondent votre boutique, non (même les acteurs honnêtes se disputent publiquement sur qui a crawlé quoi, comme l'a montré l'accrochage entre Cloudflare et Perplexity en 2025). Les préférences ont besoin d'être appliquées, et l'application vit à la périphérie.

La liste blanche condensée, les bots qui doivent survivre à n'importe quelle configuration :

Ce que Shopify gère déjà

Shopify ne dort pas sur le sujet, et il vaut la peine de savoir exactement ce que la plateforme fait, pour savoir aussi ce qu'elle vous laisse.

Chaque boutique Shopify est déjà derrière l'infrastructure de périphérie de Shopify (qui tourne elle-même sur Cloudflare), avec une protection DDoS au niveau plateforme et un pare-feu applicatif, plus des captchas sur les formulaires par défaut (docs Shopify). Les marchands Shopify Plus peuvent en plus armer une protection anti-bots du checkout conçue pour les drops : elle protège le checkout pendant des événements programmés de 60 minutes maximum (docs). C'est une armure de jour de drop, pas une hygiène de trafic au quotidien.

Ce que les marchands n'obtiennent pas, c'est le moindre contrôle sur cette périphérie. Aucun réglage dans l'admin Shopify ne permet de bloquer une plage d'IP, de challenger un pays ou de brider un scraper. Le filtre "Human or bot session" d'octobre 2025 nettoie vos rapports, ce qui est réellement utile, mais lisez les petites lignes de ce que filtrer veut dire : les bots visitent toujours, déclenchent toujours vos pixels, comptent toujours dans chaque app facturée à la session, occupent toujours l'infrastructure. Le rapport a meilleure mine pendant que le compteur continue de tourner.

Ce vide explique pourquoi l'App Store regorge d'apps de blocage par pays et d'anti-bots, et pourquoi elles déçoivent. Une app ne peut pas se placer devant la périphérie de Shopify ; la page a déjà été servie au moment où une app s'exécute. Ces apps fonctionnent donc en chargeant dans votre thème du JavaScript qui détecte, puis masque ou redirige. Deux conséquences. La session a déjà été comptée quand le script se déclenche, donc vos analytics et vos apps à l'usage sont pollués de toute façon. Et un bot qui n'exécute pas de JavaScript ne lance jamais le script de blocage. Même chose pour la suppression d'un pays dans Shopify Markets : cela empêche le checkout depuis une région, pas la navigation, pas les bots.

Si votre part de bots mesurée était faible, les protections intégrées de Shopify plus le filtre d'analytics sont un endroit parfaitement raisonnable où s'arrêter. Si elle était de 30, 50, 70 %, la seule solution structurelle est de filtrer le trafic avant qu'il n'atteigne Shopify. Cela veut dire placer votre propre périphérie devant, ce qui nous amène à Cloudflare.

Choisissez votre stratégie avant de toucher au DNS

La mise en place Cloudflare est la même dans tous les cas ; ce qui change, ce sont les règles que vous activez une fois le trafic passé par votre zone. Décidez maintenant, calmement, plutôt que d'improviser dans un dashboard à minuit.

Un point de vocabulaire. Les règles Cloudflare peuvent bloquer une requête net, ou servir un managed challenge (défi géré) : une vérification automatique rapide que la plupart des humains passent sans la remarquer (au plus une fois par demi-heure environ), et à laquelle la plupart des bots échouent. Cloudflare lui-même recommande le challenge plutôt que le blocage pour la plupart des règles, et ce guide aussi : cela transforme «j'espère que cette règle n'a pas de faux positifs» en «un rare humain voit un interstitiel de deux secondes».

La défense anti-bots de base

Le plan gratuit de Cloudflare inclut Bot Fight Mode, un interrupteur unique qui challenge le trafic correspondant à des motifs connus de bots simples. Il est brut de décoffrage : il s'applique à tout votre domaine, ne peut être ni restreint ni assorti d'exceptions, et peut attraper du trafic d'API ou d'app légitime. Sur le plan Pro à 20-25 $ par mois, il devient Super Bot Fight Mode, configurable : vous choisissez l'action pour le trafic clairement automatisé, un interrupteur autorise d'un coup tous les bons bots vérifiés, et vous obtenez des analytics de bots. Si la question budgétaire est «Pro en vaut-il la peine», pour une boutique avec un vrai problème de bots la réponse est en général oui, rien que pour cet interrupteur et la visibilité. (Les plans Business à partir de 200 $ et Enterprise ajoutent un contrôle plus fin, dont un score par requête ; la plupart des marchands qui lisent ceci n'en ont pas besoin.)

Pour qui : toutes les boutiques qui font cette mise en place. C'est le plancher.
Risques : sur le plan gratuit, la brutalité, sans possibilité d'exception : si Bot Fight Mode gêne une app de thème ou un appel de boutique sur mesure, vos options sont de le couper (et de filtrer avec des règles WAF à la place) ou de passer à Pro, où les exceptions existent. Après l'avoir activé, cliquez donc à travers votre boutique comme un client et guettez tout ce qui aurait cessé de fonctionner.

Une barrière géographique sur un pays où vous ne vendez pas

Si votre diagnostic a montré un pays qui produit des sessions massives et zéro commande, une seule règle WAF personnalisée suffit. Le motif, tiré directement de la documentation de Cloudflare, est une règle qui cible le pays avec une exemption pour les crawlers vérifiés. Dans l'éditeur de règles, l'expression est :

ip.src.country eq "CN" and not cf.client.bot

et l'action, choisie séparément dans le menu déroulant de la règle, est le managed challenge. (L'expression et l'action sont deux champs distincts ; l'éditeur d'expression rejettera tout le reste.) La clause «not cf.client.bot» compte : elle exempte du challenge tous les crawlers de la liste des bons bots vérifiés de Cloudflare, pour ne pas combattre les moteurs de recherche par accident. Le plan gratuit inclut 5 règles personnalisées, largement assez ici.

Soyez honnête avec vous-même sur les compromis avant de choisir un blocage dur plutôt que le challenge. La géolocalisation identifie le point de sortie du réseau, pas la personne : utilisateurs de VPN, voyageurs et clients expatriés qui envoient des cadeaux au pays tomberont sur votre règle, et c'est exactement pourquoi le challenge (que les humains passent) bat le blocage dur. Bloquer un pays met aussi fin à votre visibilité dans ses moteurs de recherche locaux (bloquer la Chine, c'est bloquer Baidu). Et une note juridique pour les marchands européens : le règlement européen sur le géoblocage (2018/302) interdit de bloquer les acheteurs des autres pays de l'UE et de l'EEE ; la barrière géographique est donc un outil pour les pays que vous ne servez réellement pas, hors de cette zone.

Pour qui : le motif «70 % venus d'un seul pays, zéro commande».
Risques : les cas limites ci-dessus ; atténués par le challenge plutôt que le blocage, et par l'exemption des bots vérifiés.

Une politique délibérée pour les crawlers IA

En juillet 2026, Cloudflare classe les bots IA en trois comportements, Search (recherche), Agent (chargement à la demande) et Training (entraînement), et vous laisse définir une politique par comportement, ou par crawler individuel, dans son panneau AI Crawl Control, sur tous les plans y compris le gratuit. C'est ici que vous appliquez la liste à garder vue plus haut : autorisez les catégories Search et Agent, tranchez consciemment pour Training, et laissez le système de bots vérifiés de Cloudflare séparer les crawlers honnêtes des imposteurs qui falsifient leur user agent.

Deux avertissements. D'abord, vérifiez ce qui est déjà réglé : Cloudflare bloque les crawlers IA par défaut pour les zones créées après la mi-2025 ; votre boutique est donc peut-être déjà invisible pour la recherche IA sans que personne ne l'ait choisi. Ensuite, les réglages par défaut changent encore le 15 septembre 2026 (Search autorisé, Training et Agent bloqués sur les pages porteuses de publicité, pour les nouvelles zones et les clients gratuits qui n'ont pas choisi). N'héritez d'un défaut dans aucun sens. Réglez-le vous-même.

Pour qui : tout le monde ; c'est cinq minutes dans un seul panneau.
Risques : aucun si le réglage est conscient. Le risque, c'est de ne pas le régler.

Filtrer les rapports et s'arrêter là

Activez le filtre de bots de Shopify, ajoutez des annotations dans GA4, acceptez les coûts. Zéro risque, zéro mise en place, et le choix honnête si votre part de bots est mineure ou si un changement de DNS ce trimestre est au-dessus de vos forces. Vous pourrez revenir à ce guide quand la part grandira. Elle grandit, en général.

La plupart des boutiques avec un vrai problème voudront la défense de base plus la politique de crawlers IA, en ajoutant la barrière géographique si la géographie est déséquilibrée. Les trois reposent sur la même mise en place ci-dessous.

Déplacer votre DNS sans perdre le sommeil

Tout ce qui précède se passe dans un compte Cloudflare. Ce qui l'applique à votre boutique, c'est de pointer le DNS de votre domaine vers Cloudflare, pour que le trafic traverse le réseau de Cloudflare en route vers Shopify. C'est l'étape que les marchands redoutent, à raison : le DNS est le système d'adressage qui fait exister votre boutique sur internet, et oui, un changement raté peut mettre votre site hors ligne. La peur rétrécit quand on sait trois choses : les modes de défaillance sont peu nombreux et connus, chacun a une sortie rapide, et rien dans ce déplacement n'est définitif.

Avant toute checklist, prenez en main le seul mot de vocabulaire dont dépend tout le déplacement : le petit nuage à côté de chaque enregistrement DNS dans Cloudflare, gris ou orange. Basculez-le vous-même :

Ensuite, l'aveu honnête que la plupart des guides enterrent ou omettent.

Cloudflare prend en charge cette configuration. Shopify, non. Cloudflare documente la configuration officiellement (elle s'appelle Orange-to-Orange, ou O2O, parce que votre zone et celle de Shopify sont toutes deux des zones Cloudflare), la prend en charge sur tous les plans y compris le gratuit depuis juin 2025, et la détecte automatiquement : pas de ticket, pas de contrat Enterprise, quoi qu'en disent d'anciens posts de forum (le guide Shopify de Cloudflare). Le centre d'aide de Shopify, lui, indique noir sur blanc que les configurations avec proxy Cloudflare, O2O compris, ne sont pas prises en charge, qu'elles peuvent affecter la fourniture des certificats et réduire la précision de la détection de bots de Shopify, et que les problèmes qui en découlent sortent du périmètre du support Shopify. En pratique : ça fonctionne, beaucoup de boutiques tournent ainsi, Cloudflare a construit une mécanique explicite pour cela, et si vous contactez un jour le support Shopify pour un problème de domaine sans rapport, sa première consigne sera de couper le proxy. Sachez aussi ce que vous cédez : les défenses anti-bots de Shopify voient moins bien les caractéristiques d'origine du trafic quand il arrive via un autre proxy ; vous substituez donc la couche anti-bots de Cloudflare à une partie de celle de Shopify.

Jusqu'où ça peut mal tourner, vraiment

Le risque, dimensionné honnêtement, pour qui doit valider qu'on touche au DNS :

• Le processus est conçu pour que la boutique ne tombe jamais. La première étape ne déplace que qui répond aux requêtes DNS, avec des enregistrements identiques ; le flux du trafic ne change pas tant que vous n'avez pas basculé un interrupteur, plus tard, et cet interrupteur revient en arrière en quelques secondes. Il n'existe aucun moment où le site serait «déménagé» et injoignable par conception.
• Pire cas réaliste n°1 : un enregistrement oublié. L'e-mail ou une vérification casse quelques jours plus tard parce qu'un enregistrement n'a pas fait le voyage. La prévention, c'est la comparaison enregistrement par enregistrement de la checklist ci-dessous ; la réparation, c'est ajouter l'enregistrement manquant, quelques minutes une fois le problème repéré.
• Pire cas réaliste n°2 : un conflit de certificat ou de proxy. L'admin Shopify affiche "SSL pending" (certificat en attente), ou les visiteurs voient une erreur de sécurité ou une boucle de redirection. La sortie : rebasculez l'enregistrement proxifié sur "DNS only" et la situation se dégage pendant que vous investiguez. La dégradation se compte en minutes si vous surveillez, et c'est pourquoi la checklist dit de faire cela dans un créneau calme et de vérifier immédiatement.
• Pire cas différé : le renouvellement du certificat échoue des semaines plus tard parce que "Always Use HTTPS" était activé. La prévention tient en une consigne ci-dessous ; la réparation est le même retour d'interrupteur.
• Le coût durable est organisationnel, pas technique : Shopify traite cette configuration comme non prise en charge ; sur tout futur ticket de support lié au domaine, attendez-vous à «veuillez désactiver votre proxy Cloudflare» comme premier réflexe de tri. C'est une taxe permanente sur vos échanges avec le support, à peser comme telle.
• Côté performance : les deux zones tournent sur le réseau de Cloudflare, le saut supplémentaire reste donc à l'intérieur de Cloudflare au lieu de traverser l'internet public. Si les millisecondes comptent pour vous, mesurez le time to first byte de votre boutique avant et après ; c'est le test honnête.

Si ce compromis vous paraît acceptable, et pour une boutique qui se noie dans le trafic parasite il l'est en général, voici la marche à suivre. Réservez une soirée calme, pas la veille d'une campagne.

Avant de toucher à quoi que ce soit

1. Faites l'inventaire de votre DNS. Connectez-vous là où vit actuellement votre DNS (souvent votre registrar). Exportez ou capturez chaque enregistrement : l'enregistrement A de votre domaine nu, le CNAME www, chaque autre sous-domaine (shop, blog, les CNAME de suivi de liens créés par votre plateforme e-mail comme Klaviyo, tout ce qu'une app a ajouté), et surtout vos enregistrements e-mail (MX, plus les TXT pour SPF, DKIM, DMARC) et les TXT de vérification (Google Search Console, vérification de domaine Meta, etc.). Les enregistrements e-mail oubliés sont la blessure auto-infligée la plus courante des migrations DNS ; l'importateur de Cloudflare est bon, mais la documentation de Cloudflare prévient elle-même qu'il n'est pas garanti de tout trouver.
2. Abaissez vos TTL. Si votre hébergeur DNS actuel le permet, descendez le time-to-live de vos enregistrements à 300 secondes un jour ou deux avant le déplacement. Le TTL est la durée pendant laquelle internet met vos enregistrements en cache ; avec des TTL courts, une erreur se dissipe en minutes plutôt qu'en heures.
3. Sachez où sont vos identifiants. Registrar, hébergeur DNS actuel, admin Shopify. Le chemin de retour arrière passe par le registrar, alors testez cette connexion maintenant.
4. Vérifiez que vos enregistrements Shopify suivent le standard actuel. En juillet 2026, un domaine tiers se connecte à Shopify avec un enregistrement A pointant vers 23.227.38.65 et un CNAME www pointant vers shops.myshopify.com (docs Shopify). Si les vôtres diffèrent, comprenez pourquoi avant de migrer.

Le déplacement lui-même

5. Créez un compte Cloudflare gratuit et ajoutez votre domaine. Cloudflare scanne et importe vos enregistrements existants. Faites maintenant la vérification la plus importante de tout le processus : comparez la liste importée à votre inventaire de l'étape 1, enregistrement par enregistrement, et ajoutez tout ce qui manque. C'est l'étape qui évite l'histoire du «mon e-mail est mort trois jours plus tard».
6. Laissez pour l'instant chaque enregistrement sur "DNS only" (nuage gris). Tout en gris d'abord, pour que le déplacement ne change rien au flux du trafic. Vous procédez en deux étapes sûres : déplacer le DNS, puis activer le proxy.
7. Changez vos serveurs de noms chez le registrar pour les deux que Cloudflare vous attribue. C'est le déplacement proprement dit. La propagation prend officiellement jusqu'à 24 heures ; en pratique, elle se termine souvent en quelques heures, même si certains registrars et certaines extensions de domaine sont plus lents. Votre boutique continue de fonctionner dans tous les cas, parce que les enregistrements eux-mêmes sont identiques ; seul le serveur qui y répond a changé.
8. Attendez que Cloudflare marque la zone Active (vous recevez un e-mail), puis vérifiez que votre boutique charge, que votre admin fonctionne et qu'un e-mail de test arrive. Rien n'a fonctionnellement changé, et c'est le but.

Activer le filtre

9. Basculez le CNAME www en proxifié (nuage orange), et lui seul. Tous les autres enregistrements, CNAME d'envoi d'e-mails, sous-domaines de blog et d'apps, tout le reste, restent sur "DNS only", sauf si vous savez exactement pourquoi vous les proxifiez ; un enregistrement de suivi e-mail proxifié est la façon classique de casser quelque chose sans rapport quelques jours plus tard. Comme la cible du www est shops.myshopify.com, Cloudflare reconnaît automatiquement la relation Shopify et route le trafic de zone à zone ; un logo Shopify apparaît à côté de l'enregistrement dans le dashboard. Vos règles WAF, vos réglages anti-bots et vos analytics s'appliquent désormais au trafic de la boutique.
10. Laissez l'enregistrement A du domaine nu en nuage gris, et laissez le domaine nu rediriger vers www. Le relais de zone à zone s'active sur les CNAME, pas sur les enregistrements A proxifiés ; un enregistrement A proxifié devant Shopify est exactement la configuration non prise en charge qui produit des erreurs de certificat. Le schéma propre : gardez l'apex non proxifié et assurez-vous que www est votre domaine principal dans Shopify (vérifiez Paramètres, puis Domaines ; c'est le réglage par défaut de la plupart des boutiques). Shopify redirige le domaine nu vers le domaine principal ; avec www en principal, les visiteurs de l'apex arrivent de toute façon sur le www filtré. Si votre domaine nu est actuellement principal, basculez le principal sur www avant cette étape, sinon votre filtrage ne verra jamais que la redirection.
11. N'activez jamais "Always Use HTTPS" sur cette zone. C'est le piège qui mord des semaines plus tard. Shopify renouvelle votre certificat TLS via un fichier de validation servi en HTTP simple sur «/.well-known/acme-challenge/». La redirection HTTPS globale de Cloudflare intercepte ce chemin, la validation échoue, et votre certificat cesse de se renouveler, en silence (le guide Shopify de Cloudflare documente exactement cette mise en garde). Si vous voulez une redirection HTTPS à la périphérie, créez une règle de redirection qui exclut ce chemin, comme le décrit le guide de Cloudflare. Réglez le mode de chiffrement SSL/TLS sur Full (strict), jamais sur Flexible ; Flexible face à Shopify produit une boucle de redirection infinie.
12. Appliquez maintenant la stratégie choisie plus haut : activez Bot Fight Mode (ou Super Bot Fight Mode avec les bots vérifiés autorisés, sur Pro), créez la règle géographique si vous en avez choisi une, et réglez votre politique de crawlers IA dans AI Crawl Control.

Prouvez que ça a marché

Déroulez cette liste le soir même, puis à nouveau après une journée :

• La boutique charge en HTTPS sur www et sur le domaine nu, depuis un navigateur normal et depuis votre téléphone hors wifi.
• Passez une vraie commande de test via le checkout, paiement compris. Le checkout est le seul parcours qu'on ne suppose jamais acquis.
• Admin Shopify, Paramètres, Domaines : statut au vert, SSL actif, pas d'avertissement de proxy.
• Envoyez-vous un e-mail sur votre domaine personnalisé, et envoyez-en un vers l'extérieur.
• Vérifiez que Google Search Console et vos autres vérifications de domaine (Meta, Pinterest) affichent toujours «vérifié» ; leurs enregistrements TXT ont fait le voyage avec le reste, cette vérification le prouve.
• Dans Cloudflare, surveillez les analytics de sécurité pendant une journée : vous devez voir des challenges servis, avec des taux de résolution proches de zéro pour le trafic parasite (les bots ne résolvent pas les challenges ; les humains, si).
• Comparez votre rapport de sessions Shopify d'une semaine sur l'autre au bout de sept jours. C'est votre avant-après.

Si quelque chose casse

Les sorties, de la plus rapide à la plus lente :

• Annuler le filtre, garder le DNS : rebasculez l'enregistrement www en nuage gris. Effet en quelques secondes à quelques minutes, et le trafic circule exactement comme avant que Cloudflare ne touche à quoi que ce soit. Erreurs de certificat, boucles de redirection, avertissements «domaine derrière un proxy non pris en charge» dans l'admin Shopify : ce seul geste dégage la condition qui les cause toutes, pendant que vous investiguez. C'est pour cela que l'approche en deux étapes compte ; le retour arrière complet, qui fait peur sur le papier, n'est presque jamais celui dont vous avez besoin.
• Retour arrière complet : remettez les anciens serveurs de noms chez votre registrar, vers votre ancien hébergeur DNS. Gardez votre ancienne zone DNS intacte chez l'ancien hébergeur pendant au moins deux semaines, précisément pour que cela reste une opération de cinq minutes. Avec les TTL abaissés de la checklist de préparation, la propagation est rapide.
• Certificat bloqué sur "SSL pending" dans l'admin Shopify : repassez les enregistrements en nuage gris et laissez Shopify finir de provisionner ; puis réactivez le proxy. C'est le mode de défaillance connu d'un proxy activé trop tôt ou avec les mauvais réglages, et il se résout de la même façon à chaque fois.

La semaine d'après

Vos courbes vont changer de forme, volontairement, et mieux vaut savoir à quoi s'attendre avant que votre patron ne pose la question.

• Les sessions tombent d'une falaise. C'est le signe que ça marche. Chaque courbe de tendance qui compte des sessions casse son historique le jour de la bascule. Annotez la date, dans GA4 et partout où votre équipe prend des notes, pour que personne dans trois mois ne lise la chute comme un problème de trafic. La phrase pour la réunion du lundi : les sessions ont chuté parce que nous avons arrêté de servir des robots ; chacune de ces sessions gonflait nos factures d'apps à l'usage et nourrissait les pixels publicitaires de déchets.
• Le taux de conversion bondit pour la même raison. Le dénominateur est devenu honnête. Résistez à l'envie de le célébrer comme de la croissance ; ce sont les mêmes commandes sur de vraies sessions.
• Sachez quel chiffre dit désormais la vérité. Les analytics de Cloudflare comptent tout ce qui arrive à la périphérie, y compris ce que les challenges écartent ; les rapports de Shopify comptent ce qui est passé. Attendez-vous à un chiffre Cloudflare bien plus élevé, et lisez l'écart comme le travail de votre filtre. Comme la détection de bots de Shopify voit moins clairement le trafic proxifié (leur avertissement, et il est juste), le dashboard Cloudflare est désormais votre source de vérité pour le trafic ; Shopify reste la vérité pour les commandes et tout ce qui compte plus que le trafic.
• Guettez le rare humain attrapé par une règle. Le journal des événements de sécurité de Cloudflare montre exactement quelle règle a challengé ou bloqué chaque requête. Si un vrai client ou l'outil d'un partenaire se dit bloqué, retrouvez l'événement, puis assouplissez la règle d'un blocage vers un managed challenge (les humains les passent) ou ajoutez au-dessus une règle d'exception pour son IP. Vous n'avez jamais à choisir entre «la règle reste» et «le client reste».

La facture du trafic qui n'achète jamais

Vous savez désormais arrêter le flot. Voici un cadre pour chiffrer ce qu'il coûtait, afin que l'après-midi de mise en place ait un montant en face.

Pour une boutique Shopify standard, le coût n'est pas la bande passante (Shopify l'inclut) mais tout ce qui se facture à l'usage autour de la boutique :

• Les outils facturés à la session et à la page vue. Comptez les vôtres : heatmaps, personnalisation, popups, analytics, certains outils d'avis et de support. Chacun a son échelle de paliers, et les sessions de bots la gravissent pour vous. Une échelle réelle en référence : les tarifs publics de Lucky Orange vont de 32 à 839 $ par mois selon le volume de sessions.
• Le budget publicitaire et les dégâts sur les pixels. Les clics de bots sur vos annonces sont une perte directe ; l'apprentissage pollué des pixels est indirect mais cumulatif, parce que l'algorithme optimise vers ce qui convertit, et que les bots lui apprennent que rien ne convertit.
• Les décisions. Taux de conversion, priorisation des marchés, bilans de campagne, signaux de merchandising : tous se dégradent avec le dénominateur. Ce coût est immesurable, et c'est exactement pourquoi c'est le pire.
• L'infrastructure de tout le monde. Pour les boutiques headless, la ligne bande passante est réelle et immédiate (Vercel, par exemple, facture 0,15 $ par Go au-delà du transfert inclus). Quand la plateforme de documentation Read the Docs a bloqué les crawlers IA en 2024, sa bande passante a chuté de 75 %, environ 1 500 $ par mois ; ce n'est pas une boutique, mais c'est un avant-après limpide de ce que servir des bots coûte à qui les sert.

Entrez vos propres chiffres, issus de votre diagnostic :

Pourquoi une entreprise de merchandising écrit-elle ce guide ?

La question est légitime. Depict construit du merchandising assisté par IA pour les boutiques Shopify : du visual merchandising pour les pages de collection. Le trafic de bots n'est pas notre produit, et ce guide ne vend rien.

Nous l'avons écrit parce que nos marchands posaient sans cesse la question, et parce que nous sommes concernés trois fois. Notre propre tarification compte les sessions comme le font les outils d'analytics, sans séparer les bots ; les déluges de bots poussent donc nos clients vers des limites pour un trafic qui n'achètera jamais (notre position : des limites généreuses, suivies mais pas appliquées automatiquement, et des conversations honnêtes). Les sessions de bots polluent aussi les données comportementales sur lesquelles tourne le merchandising. Les bots n'achètent pas, vos chiffres de vente survivent donc ; ce qui se corrompt, c'est tout ce qui repose sur les vues et les clics. Les sessions parasites gonflent la popularité apparente des pages qu'elles martèlent, si bien que les produits placés délibérément par un merchandiser peuvent passer pour des sous-performants à côté de ce que les bots ont frappé par hasard, et le tri par popularité apprend en silence de la fiction. Et la charge des bots brûle du calcul, le nôtre et celui de chaque fournisseur, pour personne.

Donc : un trafic plus propre assainit vos coûts et rend vos données honnêtes, et des données honnêtes sont la matière première d'un bon merchandising. Si les heures reprises à la lutte contre le trafic parasite sont des heures que vous préférez passer à composer les collections qui portent votre histoire, c'est le travail que fait Depict.

Questions fréquentes

Les faits de ce guide ont été vérifiés en juillet 2026 face à la documentation des éditeurs et aux rapports primaires ; les sources sont liées dans le texte. Cloudflare et Shopify évoluent vite sur ce terrain. Si vous repérez quelque chose qui a bougé, dites-le-nous et nous corrigerons.