<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workers on vanityURLs</title><link>https://vanityurls.link/fr/tags/workers/</link><description>Recent content in Workers on vanityURLs</description><generator>Hugo</generator><language>fr-CA</language><lastBuildDate>Sun, 07 Jun 2026 18:08:29 -0400</lastBuildDate><atom:link href="https://vanityurls.link/fr/tags/workers/index.xml" rel="self" type="application/rss+xml"/><item><title>Migrer des redirections Cloudflare Pages vers vanityURLs Workers</title><link>https://vanityurls.link/fr/blog/migrating-from-cloudflare-pages-redirects/</link><pubDate>Fri, 22 May 2026 00:00:00 +0000</pubDate><guid>https://vanityurls.link/fr/blog/migrating-from-cloudflare-pages-redirects/</guid><description>&lt;p&gt;Les premières instances vanityURLs étaient volontairement simples : un domaine, un fichier &lt;code&gt;_redirects&lt;/code&gt; et Cloudflare Pages. C&amp;rsquo;était un bon point de départ. Les liens courts restaient faciles à garder dans Git, faciles à relire et faciles à déployer.&lt;/p&gt;
&lt;p&gt;Le runtime actuel garde le même esprit, mais déplace la décision de redirection dans un Cloudflare Worker. Ce changement donne à l&amp;rsquo;instance une base plus robuste : pages opérationnelles protégées, politique générée, pages publiques localisées, analytics côté serveur, protection contre les probes et séparation plus claire entre les defaults du produit et les fichiers propres à l&amp;rsquo;instance.&lt;/p&gt;</description></item></channel></rss>