Reverse Proxies en 2026 : Caddy vs Nginx pour TLS Automatique et Performance

1. HTTPS Automatique : Zéro Configuration TLS

La caractéristique déterminante de Caddy est que HTTPS est le comportement par défaut, pas une option à activer. Pointez l’enregistrement DNS A d’un domaine vers votre VPS, écrivez un Caddyfile contenant simplement le nom de domaine et une directive reverse_proxy, et Caddy obtient automatiquement un certificat Let’s Encrypt à la première requête, le renouvelle automatiquement bien avant son expiration, et redirige HTTP vers HTTPS sans que vous ayez à écrire la moindre commande certbot ou tâche cron. Cela élimine toute une catégorie d’incidents de production — la panne par certificat expiré — qui a mis hors service plus de sites que presque n’importe quel autre oubli opérationnel isolé.

Nginx atteint le même état final, mais ce n’est pas son comportement par défaut — c’est un système séparé (Certbot, ou acme.sh) greffé par-dessus : vous installez Certbot, vous l’exécutez pour obtenir un certificat, vous configurez Nginx pour référencer les fichiers de certificat, et vous vous reposez sur une tâche cron ou un timer systemd pour renouveler avant l’expiration à 90 jours de Let’s Encrypt. Chacune de ces étapes est un endroit où une dérive peut se produire — une tâche cron de renouvellement qui cesse silencieusement de se déclencher après qu’une mise à jour de paquet a changé son chemin, ou un rechargement de configuration qui n’a jamais lieu après un renouvellement réussi, laissant Nginx servir l’ancien certificat jusqu’à ce que quelqu’un remarque l’avertissement du navigateur.

Pour une stack de production maintenue en solo, la différence de coût opérationnel est réelle : l’approche de Caddy signifie une pièce mobile de moins à surveiller et une catégorie d’incidents à 3 heures du matin en moins. L’approche de Nginx est parfaitement fiable une fois correctement automatisée, et la grande majorité des déploiements Nginx en production le font correctement, mais « une fois correctement automatisée » porte beaucoup de poids dans cette phrase pour une équipe d’une seule personne.

2. Support Natif de HTTP/3 et QUIC

HTTP/3, construit sur QUIC par-dessus UDP plutôt que TCP, améliore sensiblement la latence sur les connexions instables ou à forte latence, en éliminant le head-of-line blocking de TCP et en réduisant les allers-retours de mise en place de connexion grâce à la poignée de main combinée transport-et-TLS de QUIC. Pour les utilisateurs mobiles sur des connexions cellulaires variables, ou les visiteurs de régions géographiquement éloignées, cela se traduit par un time-to-first-byte nettement plus rapide et moins de chargements de page bloqués en cas de perte de paquets, comparé à HTTP/2 sur TCP.

Caddy prend en charge HTTP/3 dès la sortie de la boîte depuis Caddy 2, sans configuration supplémentaire requise au-delà de ce que le HTTPS automatique met déjà en place — le même Caddyfile qui vous obtient un certificat vous obtient aussi HTTP/3, annoncé via l’en-tête Alt-Svc, et les clients compatibles basculent de façon transparente. C’est un cas où « automatique » signifie réellement automatique : il n’y a pas de module séparé à compiler, pas de directive supplémentaire à retenir.