Pourquoi la périphérie sert encore l'ancien fichier
Quand un visiteur demande un fichier, l'emplacement en périphérie le plus proche vérifie s'il en détient une copie valide. Si oui, il répond immédiatement sans interroger votre serveur — c'est tout l'intérêt d'un CDN, et c'est ce qui rend votre site rapide. La durée de cette validité vient des en-têtes de cache envoyés par votre origine lorsque la périphérie a récupéré le fichier pour la première fois, le plus souvent Cache-Control: max-age.
Donc, quand vous uploadez une nouvelle version et voyez encore l'ancienne, rien n'est cassé. Vous avez modifié le fichier à l'origine, mais la périphérie est encore dans la fenêtre pendant laquelle vous lui avez demandé de conserver la copie précédente. Vous avez trois issues : attendre l'expiration, purger tout de suite, ou publier sous une nouvelle URL pour qu'il n'y ait plus rien d'obsolète à servir. Laquelle choisir, c'est tout le sujet de ce guide.
Exacte, par préfixe, par variantes — prenez le plus petit marteau
Une purge exacte supprime une URL précise. C'est la valeur par défaut la plus judicieuse : vous avez remplacé /images/hero.jpg, donc vous purgez /images/hero.jpg. Précis, immédiat, et tout le reste reste chaud.
Une purge par préfixe supprime tout ce qui se trouve sous un chemin — /assets/ vide tous les fichiers en dessous. Utilisez-la après un déploiement qui a réécrit tout un répertoire. C'est puissant, alors visez bien : purger /images/ parce qu'un logo a changé jette des milliers d'objets mis en cache encore utiles.
Une purge par variantes efface toutes les versions mises en cache d'une même clé. La périphérie peut détenir plusieurs copies d'une seule URL — compressée et non compressée, ou différentes variantes selon l'appareil — et si vous remplacez le fichier sous-jacent, vous voulez qu'elles disparaissent toutes, pas seulement celle qui correspond à votre propre navigateur. C'est l'option que l'on oublie quand une purge « n'a pas marché » pour certains visiteurs alors qu'elle marchait pour soi.
Les trois mêmes options depuis la CLI
# one URL (the usual case)
cdnctl purge --account <uuid> --path /images/hero.jpg
# several at once
cdnctl purge --account <uuid> --paths "/css/app.css,/js/app.js"
# everything under a folder
cdnctl purge --account <uuid> --path /assets --type prefix
# every cached variant of one key
cdnctl purge --account <uuid> --path /index.html --type variants
# save this list to re-run after future deploys
cdnctl purge --account <uuid> --paths "/,/sitemap.xml" --saveQuand tout purger (et ce que cela coûte)
Purger l'intégralité du cache d'un compte est le bon réflexe après un changement à l'échelle du site : une refonte, une modification de template qui touche chaque page, une migration de CMS. C'est une seule commande, et elle est honnête sur ce qu'elle fait — tout disparaît.
Mesurez d'abord le coût. Pendant un moment après une purge complète, la périphérie ne détient plus rien : les requêtes autrefois traitées près de l'utilisateur remontent jusqu'à votre origine. Un site qui sert confortablement dix requêtes par seconde derrière un cache peut soudain devoir toutes les affronter d'un coup. Sur une petite origine, c'est la différence entre rapide et en difficulté. Parce qu'elle est délibérément brutale, la CLI exige une confirmation.
Une confirmation explicite est exigée — c'est volontaire
# clear the whole account cache
cdnctl purge all --account <uuid> --yes
# watch it complete
cdnctl purge all status --account <uuid>La purge que vous n'aurez jamais à lancer
La meilleure stratégie d'invalidation, c'est de ne pas en avoir besoin. Si le nom d'un fichier change dès que son contenu change — app.a1b2c3.js, style.9f8e7d.css — alors un déploiement publie de nouvelles URLs. Les anciennes restent en cache, inoffensives et plus référencées ; les nouvelles n'ont jamais été mises en cache, donc chaque visiteur obtient instantanément la nouvelle version. Tous les outils de build modernes le font pour vous, et c'est pourquoi le cache des assets peut être réglé sans risque sur un an.
Restent les fichiers dont le nom ne peut pas changer : vos pages HTML, /sitemap.xml, robots.txt, les flux JSON. Donnez-leur un max-age court pour qu'ils se rafraîchissent d'eux-mêmes, et purgez-les explicitement quand vous voulez que le changement soit visible immédiatement. En pratique, une installation saine purge une poignée de chemins après un déploiement, pas des milliers.
Pourquoi la purge a semblé sans effet
Presque tous les signalements « la purge n'a rien fait » relèvent de l'une de ces quatre causes, et aucune n'est une erreur de la périphérie.
Votre propre navigateur l'a aussi mis en cache. Cache-Control s'applique également au navigateur ; la périphérie est fraîche, mais pas votre ordinateur. Vérifiez dans une fenêtre privée ou avec un paramètre d'URL anti-cache avant d'escalader.
Vous avez purgé une autre URL que celle qui est servie. /page et /page/ peuvent être des clés de cache distinctes, tout comme les versions http et https, ou une URL avec des paramètres de suivi. Purgez l'URL que vos utilisateurs demandent réellement.
Vous n'avez purgé qu'une variante. Les copies compressée et non compressée d'un même fichier sont des entrées distinctes — si certains visiteurs voient la nouvelle version et d'autres non, purgez avec le type variants.
Ou bien l'origine a resservi l'ancien fichier. Une purge dit seulement à la périphérie d'oublier ; la requête suivante va rechercher le fichier sur votre serveur. Si votre propre application ou un plugin conserve encore l'ancienne page en cache, la périphérie remettra fidèlement cette copie obsolète en cache. Videz d'abord le cache applicatif, puis purgez la périphérie.
En faire une étape du déploiement, pas une chose à retenir
Purger à la main après chaque mise en production, c'est une étape que quelqu'un finit par oublier, généralement lors de la version qui comptait. Mettez-la dans le pipeline : une fois le déploiement réussi, lancez une purge sur la poignée de chemins dont le nom ne change jamais. Sur cdn.com.tr, vous pouvez le faire depuis le panneau, via l'API REST, ou avec cdnctl dans un job CI — la même commande, qu'elle tourne depuis votre terminal ou depuis un runner. Les listes de chemins enregistrées (--save) en font une commande d'une ligne que vous conservez au lieu d'une liste à retaper.
Questions fréquentes
Combien de temps faut-il pour qu'une purge prenne effet ?
C'est rapide — la périphérie supprime l'entrée en cache et la toute prochaine requête pour cette URL la récupère depuis votre origine. Ce qui n'est pas instantané, c'est le cache de votre propre navigateur : une copie distincte régie par le même en-tête Cache-Control.
Purger tout le cache est-il dangereux ?
Pas dangereux, mais pas gratuit : tant que le cache ne s'est pas rerempli, les requêtes atteignent votre origine au lieu d'être absorbées près de l'utilisateur. C'est le bon outil après un changement à l'échelle du site et le mauvais outil pour une seule image modifiée.
Quelle différence entre une purge et une actualisation forcée ?
Une actualisation forcée (Ctrl+F5) ne vide que VOTRE copie navigateur — elle corrige ce que vous voyez et rien pour les autres. Une purge vide la copie partagée en périphérie, celle qui est servie à chaque visiteur.
Puis-je purger automatiquement après un déploiement ?
Oui — c'est la configuration recommandée. Appelez l'API de purge ou exécutez cdnctl comme dernière étape de votre pipeline de déploiement, en ciblant les chemins dont le nom de fichier ne change pas (pages HTML, sitemap, flux).