L'auto-hébergement d'un réducteur d'URL était autrefois un projet de week-end. PHP plus MySQL plus un contrôleur de redirection et vous aviez quelque chose ressemblant à Bitly vers 2010. La catégorie n'est pas restée immobile ; les options open-source modernes sont plus performantes que YOURLS, plus exigeantes à exploiter que le projet de week-end, et toujours significativement en retard sur un produit hébergé en ce qui concerne l'analyse. Ce post présente le paysage honnête — ce que chaque option open-source offre réellement, ce à quoi vous renoncez par rapport à un fournisseur hébergé, et où les calculs penchent à nouveau en faveur du paiement d'un tiers pour gérer la couche de redirection.
Le public visé est constitué des équipes d'ingénierie ou des opérateurs techniques qui se demandent s'ils doivent s'auto-héberger. L'article pilier bitly alternatives cornerstone couvre la comparaison plus large ; ce post se concentre spécifiquement sur le côté open-source. Le self-hosting Elido k3s playbook couvre le cas où vous souhaitez auto-héberger Elido lui-même plutôt qu'une alternative tierce.
Ce à quoi vous vous engagez#
Un réducteur d'URL semble trompeusement simple. Une base de données, un processus de redirection, un tableau de bord pour gérer les liens. En production, cette forme simple cache quatre surfaces opérationnelles :
La couche de redirection. C'est le chemin critique. Chaque URL courte cliquée n'importe où sur Internet finit par atteindre ce code. Elle doit être rapide (sub-15ms p95 si l'expérience utilisateur vous importe), hautement disponible (une interruption ici brise chaque lien que vous avez déjà diffusé) et distribuée mondialement si vos utilisateurs ne se trouvent pas dans une seule zone géographique. Le post redirect p95 < 15ms explique ce que signifie réellement la rapidité et comment elle est atteinte.
Le pipeline d'analyse des clics. Enregistrement, stockage et interrogation des événements de clic. À grande échelle, il s'agit d'un système différent de la couche de redirection — généralement Kafka ou Redpanda pour l'ingestion, ClickHouse ou BigQuery pour le stockage, une API séparée pour les requêtes. La plupart des réducteurs open-source ignorent complètement cela et stockent les clics dans la même base de données relationnelle que celle qui contient les liens, ce qui fonctionne à faible volume mais s'effondre une fois que vous dépassez quelques millions de clics par mois.
Le tableau de bord. L'interface utilisateur pour créer, éditer, organiser et analyser les liens. C'est là que la plupart des projets open-source consacrent la majeure partie de leur travail sur les fonctionnalités, et là où l'écart avec les produits hébergés est le plus faible — la plupart des tableaux de bord open-source sont corrects.
La machinerie de domaine personnalisé. Émission de TLS, validation DNS, renouvellement de certificat, provisionnement de certificat à la demande lorsqu'un nouveau domaine pointe vers le cluster. C'est là que le coût opérationnel s'accumule ; faire fonctionner ACME à grande échelle est véritablement difficile.
Une configuration auto-hébergée signifie que vous gérez les quatre surfaces. Un produit hébergé signifie que vous n'en gérez aucune (en échange du paiement d'un fournisseur et de l'acceptation de sa politique de résidence des données). La question est de savoir quel ensemble de compromis convient le mieux à votre situation.
Les options open-source actuelles#
Cinq projets méritent d'être considérés, par ordre approximatif d'activité au 2026-05-22.
YOURLS#
Le précurseur. PHP, MySQL, serveur unique, architecture de plugins. YOURLS existe depuis 2009 et reste le réducteur open-source le plus déployé, et de loin. Points forts : simple à installer, fonctionne partout où PHP fonctionne, l'écosystème de plugins est mature. Points faibles : les analyses sont minimales (nombre de clics par lien, géo IP via un service externe), pas de support intégré pour les domaines personnalisés au-delà de l'exécution de plusieurs instances, pas de limitation de débit d'API, pas de concept d'équipes ou de rôles.
YOURLS est un excellent choix si vous voulez un outil de liens courts personnel avec un seul propriétaire et un trafic modeste. C'est le mauvais choix si vous avez une équipe, des domaines personnalisés pour des clients, ou des analyses qui doivent survivre à la base de données. Le post Elido vs YOURLS couvre l'écart de fonctionnalités en détail.
Shlink#
Encore du PHP, mais plus moderne. Shlink est livré avec une API REST, un support multi-domaine, une interface web séparée et des mises à jour en temps réel basées sur Mercure. Les analyses sont plus performantes que celles de YOURLS — géographie par visite, appareil, séries chronologiques — mais stockées dans la même base de données MySQL/Postgres que les liens. L'équipe de Shlink est réactive et le projet a publié des versions régulières depuis 2019.
Shlink est un choix raisonnable si vous êtes prêt à exploiter une configuration PHP-FPM + MySQL/Postgres et que vous n'avez pas besoin que les analyses dépassent quelques millions de clics par mois. La couche de redirection à processus unique devient un goulot d'étranglement à des volumes plus élevés ; une mise à l'échelle horizontale est possible mais nécessite de la placer derrière un équilibreur de charge et un cache partagé.
Polr#
PHP léger. Polr était populaire vers 2017-2019 et le projet est largement en sommeil aujourd'hui, bien que des forks existent. Fonctionnellement similaire à YOURLS mais avec une API plus propre. Si vous commencez aujourd'hui, l'absence de maintenance récente est une préoccupation majeure — les correctifs de sécurité n'arrivent pas régulièrement.
Kutt#
Node.js, Postgres, Redis. Kutt est le réducteur "stack moderne" le plus actif. Livré avec une fonctionnalité de domaine personnalisé, des liens protégés par mot de passe, l'expiration et des analyses de base. La surface d'analyse est plus utilisable que celle de YOURLS mais repose toujours sur une base de données relationnelle.
Le profil opérationnel de Kutt est plus lourd que celui de YOURLS — Node + Postgres + Redis signifie trois services à exécuter plutôt qu'un — mais la stack moderne vous offre de meilleures performances par dollar à des volumes modérés. Si votre équipe est à l'aise avec Node, Kutt est le choix le plus sûr aujourd'hui pour "nous voulons un réducteur open-source moderne".
Dub-self-hosted#
Dub.co publie une version auto-hébergée de son produit hébergé. Dub propose une stack Next.js + Postgres + Redis + Tinybird avec un tableau de bord poli et des analyses correctes. La complexité opérationnelle est la plus élevée des cinq — Tinybird est un service ClickHouse hébergé dans le déploiement par défaut, et le remplacer par un ClickHouse auto-hébergé est un projet important.
Dub-self-hosted est le bon choix si vous avez une équipe à l'aise avec l'exploitation d'une stack web moderne et que vous voulez l'aspect et la convivialité d'un produit hébergé actuel. C'est le mauvais choix si votre budget opérationnel est limité ou si votre équipe ne maîtrise pas Next.js.
La matrice des fournisseurs#
Une évaluation sur quatre axes : analyse, opérations, domaines personnalisés et potentiel de mise à l'échelle. Les notes sont approximatives — de A à D — basées sur ce que le projet propose nativement, et non sur ce qui est possible avec un travail personnalisé.
| Projet | Analyse | Opérations | Domaines personnalisés | Mise à l'échelle | Stack |
|---|---|---|---|---|---|
| YOURLS | D | A | C (manuel) | D | PHP + MySQL |
| Shlink | C | B | B | C | PHP + Postgres |
| Polr | D | B | C | D | PHP + MySQL |
| Kutt | C | C | B | C | Node + Postgres + Redis |
| Dub-self-hosted | B | D | A | B | Next.js + Postgres + Redis + Tinybird |
| Elido-self-hosted | A | C | A | A | Go + Postgres + Redis + ClickHouse + Redpanda |
Deux tendances se dégagent de la matrice. Premièrement, l'analyse s'améliore avec la complexité de la stack — les projets qui stockent les clics dans une base de données relationnelle aux côtés des liens obtiennent des notes inférieures aux projets qui proposent un pipeline d'analyse dédié. Deuxièmement, les domaines personnalisés sont assez bien gérés par tout le monde sauf YOURLS, car l'automatisation ACME est devenue banalisée.
Le coût caché : des analyses qui passent à l'échelle#
Les événements de clic s'accumulent plus vite qu'on ne le pense. Un seul lien avec 100 clics par jour génère 36 500 clics par an — gérable dans n'importe quelle base de données relationnelle. Un seul lien avec 100 000 clics par jour génère 36,5 millions de clics par an, et c'est là que MySQL ou Postgres commence à peiner. Un petit produit SaaS avec un millier de liens actifs recevant en moyenne 1 000 clics par jour chacun représente un milliard de clics par an, et à ce stade, n'importe quel stockage relationnel s'effondre sans une optimisation significative.
Les cinq projets open-source ci-dessus (sauf Dub et Elido) stockent les clics dans la même base de données que les liens. Les schémas de requête sont également différents de l'OLTP typique — "donnez-moi le nombre de clics par jour pour ce lien au cours des 30 derniers jours" est un balayage de plage avec agrégation, le pire cas pour une base de données optimisée pour l'OLTP.
Vous pouvez résoudre cela. ClickHouse gère confortablement les charges de travail d'analyse de milliards d'événements ; le post why ClickHouse en explique les raisons. Mais ajouter ClickHouse à votre stack signifie un autre service à exploiter, un autre pipeline de sauvegarde, une autre surface de surveillance. Si votre volume de liens est faible (moins de 10 millions de clics par mois), l'approche par base de données relationnelle convient pendant des années ; si votre volume est plus important, la couche d'analyse devient un projet à part entière.
Le coût caché : les POP edge et la latence#
Un réducteur auto-hébergé sur un serveur unique sert les redirections depuis un seul emplacement géographique. Si vos utilisateurs sont répartis sur trois continents, la latence depuis l'autre bout du monde est de 200 à 300ms — ce qui est visible en termes d'expérience utilisateur.
Les correctifs :
- Des IP Anycast devant plusieurs POP. Pratique uniquement si vous avez votre propre configuration AS et BGP. Pas réaliste pour la plupart des déploiements auto-hébergés.
- Routage géo basé sur le DNS. Cloudflare, Route53 ou NS1 peuvent router les utilisateurs vers le POP le plus proche. Cela fonctionne, mais ajoute une latence de recherche DNS en plus de la redirection.
- CDN en amont. Cloudflare ou Fastly devant le processus de redirection. Le CDN met en cache les réponses GET ; les redirections sont misérables en cache, mais la logique d'invalidation du cache lorsqu'une destination de lien change n'est pas triviale.
- Un POP par région. Exécutez le processus de redirection à Francfort, Ashburn et Singapour, avec une base de données partagée ou une cohérence éventuelle entre eux. C'est la voie de la production. C'est aussi significativement plus de travail que l'auto-hébergement dans une seule région.
Le post edge POPs vs DNS-only routing couvre ce choix en détail. La plupart des déploiements auto-hébergés s'arrêtent à une seule région car le travail multi-région est un projet distinct.
Quand l'auto-hébergement est logique#
Trois scénarios :
La souveraineté des données est non négociable. Un secteur réglementé — santé, finance, gouvernement — exige que les données résident sur votre infrastructure. La posture du produit hébergé (même s'il réside dans l'UE) n'est pas suffisante car les données doivent vivre à l'intérieur de votre périmètre de sécurité. L'auto-hébergement est la bonne réponse ici. Le coût de maintenance est le prix de la conformité.
Le volume est faible et vous êtes technique. Une équipe gérant ses propres liens courts pour un usage interne, avec moins d'un million de clics par mois, pas de domaines personnalisés pour des clients externes, et un développeur capable de maintenir une stack Docker Compose en vie. YOURLS ou Shlink conviennent parfaitement. Le produit hébergé est excessif pour ce périmètre.
Vous construisez un produit dérivé. Si vos liens courts sont le front-end d'un produit plus large que vous construisez — par exemple, une plateforme de billetterie d'événements où l'URL courte pointe vers le billet — l'auto-hébergement vous permet de coupler la couche de redirection avec votre logique métier d'une manière que le fournisseur hébergé ne peut égaler. La plupart des adoptants de Dub en auto-hébergement font partie de cette catégorie.
Quand l'auto-hébergement cesse d'être logique#
Trois scénarios de l'autre côté :
Vous avez besoin d'analyses sérieuses. Dès que vos parties prenantes demandent "quelle est la répartition des clics par pays au cours des 90 derniers jours pour ces 50 campagnes ?", le stockage en base de données relationnelle ne suffit plus. Soit vous construisez le pipeline d'analyse (un projet de plusieurs mois), soit vous payez un fournisseur hébergé qui le propose nativement.
Vous avez besoin de domaines personnalisés pour de nombreux clients. Faire fonctionner ACME pour un seul domaine est trivial. Faire fonctionner ACME pour 10 000 domaines fournis par des clients, avec révocation, renouvellement et émission à la demande, est une surface d'ingénierie sérieuse. Le post custom domain TLS couvre le mécanisme ; construire cela en interne représente un trimestre de travail, pas un après-midi.
Le temps de votre équipe est le goulot d'étranglement. Un réducteur auto-hébergé coûte environ 4 à 8 heures d'ingénieur par mois en régime de croisière une fois configuré, plus le temps de chaque panne et de chaque mise à niveau. Avec un taux horaire de développeur de 100 $, cela représente 400 à 800 $/mois avant de compter l'inévitable session de débogage de panne de deux semaines chaque trimestre. Un fournisseur hébergé à 300-500 $/mois commence à paraître bon marché.
Le calcul du seuil de rentabilité est sensible à deux facteurs : la valeur du temps de votre équipe et la fréquence à laquelle vous rencontrez des problèmes opérationnels. Pour une équipe gérant déjà son propre cluster k3s, le coût marginal de l'ajout d'un réducteur est faible. Pour une équipe qui n'exploite actuellement aucune infrastructure, l'hébergement du réducteur entraîne des coûts adjacents (surveillance, journalisation, sauvegardes) qui alourdissent la facture.
Un arbre de décision pragmatique#
La décision en cinq questions :
- Êtes-vous tenu par une réglementation ou une politique de conserver les données de liens sur une infrastructure que vous contrôlez ? Si oui, auto-hébergez. Arrêtez-vous ici.
- Votre volume de clics dépasse-t-il ou devrait-il dépasser 50 millions de clics par mois d'ici 24 mois ? Si oui, prévoyez une couche d'analyse dédiée — ce qui oriente soit vers Dub-self-hosted ou Elido-self-hosted, soit vers un fournisseur hébergé avec des analyses basées sur ClickHouse.
- Avez-vous besoin de domaines personnalisés pour plus de 10 clients ? Si oui, le coût de l'automatisation ACME est significatif — mêmes projets que ci-dessus, ou hébergé.
- Votre équipe gère-t-elle actuellement d'autres services de production avec une rotation d'astreinte ? Si non, le coût opérationnel de l'auto-hébergement est plus élevé qu'il n'y paraît.
- Les liens courts sont-ils une surface stratégique de votre produit (par ex. vous construisez une plateforme d'intégration) ou un utilitaire de support (par ex. liens internes de l'équipe) ? Surface stratégique = auto-hébergement ou hébergement avec intégration profonde ; utilitaire de support = l'option la moins chère.
La plupart des équipes opteront pour l'hébergement après avoir parcouru cet arbre. C'est normal. L'auto-hébergement est la bonne réponse lorsque les contraintes sont claires ; c'est le mauvais choix par défaut lorsqu'elles ne le sont pas.
Lectures connexes#
- Bitly alternatives — l'écart réel de fonctionnalités — l'article pilier plus large sur les fournisseurs hébergés.
- Auto-hébergement d'Elido sur k3s — le guide — le guide opérationnel pour le côté Elido.
- Elido vs YOURLS — le face-à-face contre l'option open-source la plus déployée.
- Pourquoi ClickHouse pour l'analyse des clics — le raisonnement derrière la couche d'analyse.
- Edge POPs vs routage DNS uniquement — la voie multi-région.
- Surface produit :
/solutions/developerset/pricing. - Architecture : docs edge-redirect.