Servir des fichiers publics avec un domaine CDN

Vous pouvez servir des fichiers publics avec un domaine CDN personnalisé sans déplacer votre site. Gardez l’application chez son hébergeur actuel, placez quelques images approuvées dans un compartiment Spaces Standard et utilisez un sous-domaine tel que assets.example.com. Ce guide commence par ce changement limité.

Le test de validation compte davantage que le premier envoi réussi. Vous chargerez deux images différentes, passerez de l’une à l’autre sur une page de prévisualisation et examinerez séparément un fichier écrasé. Vous disposerez ainsi d’une procédure de publication avant qu’une brochure périmée ou une image absente ne pose problème.

Cette méthode convient aux captures, illustrations et téléchargements publics que chacun peut conserver. Gardez factures, originaux envoyés par les clients, sauvegardes et téléchargements payants hors de ce compartiment. Rendre un fichier public est une décision de publication. Un nom difficile à deviner ne contrôle pas l’accès.

La procédure suit la documentation consultée le 6 septembre 2026. Elle propose un test guidé. Elle ne prétend pas que j’ai configuré votre domaine ni mesuré un gain de vitesse. Consignez vos propres résultats à chaque étape.

Un compartiment stocke des objets, c’est-à-dire des fichiers accompagnés de métadonnées. L’origine contient la copie stockée. Un réseau de diffusion de contenu, ou CDN, garde des copies sur des serveurs de périphérie. Votre navigateur peut conserver une autre copie après réception. Un nom personnalisé change l’adresse, sans réunir ces copies.

Je recommande Spaces lorsque vous cherchez déjà un stockage distinct pour des fichiers publics ordinaires. Son CDN intégré limite le nombre de services à configurer. En contrepartie, vous gérez les permissions, le DNS et le cache en plus du déploiement du site. Ce travail existe même avec peu de visiteurs.

Si votre hébergeur sert déjà correctement quelques images statiques, gardez-les là tant qu’aucune raison ne justifie le déplacement. Ajouter un compte ne constitue pas une optimisation. Si votre application dépend de fonctions propres à AWS, examinez son architecture de diffusion avant de migrer pour reproduire ce tutoriel.

Spaces Standard commence à 5 USD par mois avec 250 Gio de stockage et 1 024 Gio de transfert sortant. Le CDN n’ajoute pas de forfait distinct. Le stockage supplémentaire coûte 0,02 USD par Gio-mois et le transfert supplémentaire 0,01 USD par Gio. Les compartiments du compte partagent ces quotas.

Prenons un mois illustratif avec 10 Gio stockés et 100 Gio distribués. Cette charge reste dans le forfait de base si les autres compartiments n’ont pas consommé les quotas. Taxes, domaine, hébergement applicatif et autres services restent hors de cet exemple. Un téléchargement populaire peut augmenter le transfert sans presque modifier le stockage.

Estimez les téléchargements mensuels avant de créer le compartiment. Partez de la taille réelle des fichiers publiés et multipliez-la par le nombre de téléchargements attendu. Prévoyez les nouvelles tentatives et les visites répétées. Après lancement, comparez votre estimation à l’usage du compte au lieu de supposer que chaque visite profite du cache local.

Utilisez un nouveau compartiment Standard Storage pour cet exercice. Cold Storage ne convient pas à ce trajet CDN. Un compartiment dédié délimite le test et évite de sélectionner un dossier de sauvegarde au moment de changer les permissions. Choisissez sa région selon votre application et le lieu de ses envois.

Préparez deux petits PNG sur votre ordinateur. Placez un grand A dans le premier et un grand B dans le second. Enregistrez-les sous cdn-check-a.png et cdn-check-b.png. Ces fichiers de test ne contiennent rien de sensible. Une mauvaise réponse sera visible sans comparer une nuance de couleur ni se fier au nom.

Une liste restreinte peut contenir des objets publics. La liste détermine si une personne peut énumérer les noms. Les permissions de l’objet déterminent si elle peut lire un fichier précis. Gardez la liste restreinte même lorsque les deux objets choisis sont publics.

Si la racine du compartiment refuse l’accès mais que l’URL exacte de l’image fonctionne, ce n’est pas nécessairement une erreur. Testez le chemin complet, avec les mêmes majuscules et dossiers. À l’inverse, ouvrir le fichier dans le panneau de votre compte connecté ne prouve pas son accès public. Utilisez la navigation privée.

Avant de continuer, recopiez les deux URL d’origine dans une courte note de publication. Pour chacune, indiquez la lettre attendue et le résultat observé. Cette note permettra de distinguer un envoi incorrect d’un problème DNS ou CDN. N’y ajoutez aucun identifiant ni lien signé temporaire.

Ouvrez Settings dans le compartiment, modifiez la section CDN, activez le CDN et enregistrez. Gardez le TTL de cache de périphérie par défaut d’une heure pour ce premier test. Copiez l’adresse CDN affichée et ajoutez le chemin d’objet déjà vérifié à l’origine.

Ouvrez les deux URL CDN en navigation privée. Comparez les lettres aux résultats obtenus à l’origine. Si l’une échoue, arrêtez-vous ici. Un domaine personnalisé ajoute une dépendance ; il ne corrigera ni un chemin incorrect ni une permission publique manquante.

Ajoutez ensuite le sous-domaine personnalisé dans les réglages CDN. Ce guide utilise le certificat Let’s Encrypt géré pour un domaine dont le DNS faisant autorité est déjà chez DigitalOcean. Choisissez un sous-domaine assets inutilisé. Laissez le panneau configurer les enregistrements et le certificat. Ne réutilisez pas un nom qui sert déjà une application.

Si votre DNS est ailleurs, interrompez cette procédure et suivez les instructions liées pour fournir votre certificat. Ne changez pas les serveurs de noms simplement pour terminer le tutoriel. Une migration DNS concerne tous les enregistrements, y compris ceux du courrier, et demande une préparation distincte.

Une fois la configuration terminée, ouvrez l’adresse HTTPS personnalisée de chaque image. Remplacez le nom d’exemple par celui que vous avez configuré et conservez le chemin exact. Le résultat attendu montre la bonne lettre, sans avertissement de certificat ni redirection vers une page de connexion.

Ouvrez les outils de développement du navigateur, puis Network avant de recharger. Sélectionnez la requête de l’image et examinez Request URL, le statut, Content-Type et la réponse. Une nouvelle récupération doit réussir et annoncer image/png. Une réponse en cache ou revalidée peut se présenter autrement. Notez la présence éventuelle d’un cache local.

Une erreur de certificat appelle une vérification du nom et du certificat. Si l’adresse CDN par défaut fonctionne mais pas votre nom, commencez par la résolution DNS et l’état de configuration. Si l’origine échoue aussi, revenez à l’envoi et aux permissions. Cet ordre évite de modifier plusieurs réglages pour une seule panne.

Ne contournez pas un avertissement de certificat pour valider le test. Ne concluez pas non plus que le CDN est plus rapide après un seul rechargement. Un cache local déjà rempli peut rendre presque toute adresse instantanée. Validez d’abord la bonne diffusion ; une mesure de vitesse exige une méthode reproductible.

Modifiez l’URL d’une seule image sur une page locale ou de préproduction pour utiliser votre domaine et cdn-check-a.png. Conservez l’ancienne valeur dans Git ou dans une révision enregistrée. Ouvrez l’aperçu dans une nouvelle session et vérifiez que la requête réelle part vers votre nouveau nom.

Remplacez ensuite uniquement le chemin par cdn-check-b.png et publiez la nouvelle prévisualisation. Vérifiez que B apparaît. Rétablissez enfin le chemin de A et vérifiez son retour. Ce test constitue votre retour arrière. Les deux objets restent disponibles, donc la restauration de la page ne dépend pas d’un fichier à reconstruire.

Appliquez la même règle aux publications réelles. Envoyez les nouveaux octets sous un nouveau chemin, vérifiez leur lecture, puis modifiez la référence dans la page. Gardez les anciens objets pendant une durée de retour arrière documentée. Une empreinte de contenu générée lors du build devient utile à grande échelle. Les deux noms explicites enseignent le même ordre.

N’ajoutez pas une valeur aléatoire dans l’URL à chaque visite. Les comparaisons deviennent difficiles et les clés du cache changent. Donnez une URL stable à chaque version. N’écrasez pas un fichier déclaré immutable après avoir annoncé aux navigateurs que son contenu ne changerait pas.

Pour cet exercice seulement, copiez l’image A sous le nom cdn-check-mutable.png. Envoyez-la, rendez ce seul fichier public et chargez-le avec votre nom personnalisé. Remplacez ensuite ses octets stockés par l’image B sous le même nom. Ne touchez pas aux deux fichiers versionnés.

Comparez l’URL exacte de ce fichier à l’origine et au CDN. Désactivez le cache du navigateur dans les outils de développement pour ce diagnostic. Cette option ne vide pas le CDN. Vous pouvez voir A en périphérie alors que B existe à l’origine. Si les deux montrent B, cela ne prouve pas que tous les serveurs de périphérie sont à jour.

Purgez uniquement cet objet depuis son menu dans Files avec Purge from CDN cache. Vérifiez de nouveau la même URL. Notez le nom utilisé et l’état du cache local. Un test de purge ne doit pas commencer par vider tout le compartiment de production.

La purge CDN ne rappelle pas les copies déjà téléchargées ou gardées par les navigateurs. Pour une correction urgente, publiez un nouveau chemin et modifiez la page. Si un contenu confidentiel était public, restreignez ou supprimez la source, purgez le CDN et considérez que des copies peuvent subsister. Une purge réussie ne prouve pas leur effacement.

Le TTL en périphérie décrit combien de temps un serveur CDN peut réutiliser un contenu. Le navigateur suit les en-têtes de la réponse reçue. Examinez Cache-Control dans Network avant de supposer qu’un réglage du panneau donne la même durée aux deux caches. Gardez une politique initiale modeste jusqu’à la réussite du test de mise à jour.

Cross-Origin Resource Sharing, ou CORS, détermine quelles applications web peuvent lire des réponses provenant d’une autre origine. Il ne rend pas privés les fichiers publics. Si une image directe fonctionne mais que l’application signale une erreur CORS, identifiez le type de requête avant de changer les réglages. Les polices et les appels JavaScript fetch méritent une vérification.

Lorsqu’un site doit lire des réponses entre origines, configurez seulement ses origines et méthodes nécessaires dans les réglages CORS du compartiment. Testez ensuite depuis ce site réel. N’autorisez pas toutes les méthodes et toutes les origines pour faire disparaître un message. Afficher une image et lire ses octets par script constituent des tests différents.

Peut-on utiliser un domaine personnalisé avec le CDN Spaces ? Oui, avec un certificat pour ce nom. Ce guide utilise le DNS géré par DigitalOcean et son certificat géré. Un DNS externe demande la configuration documentée du certificat. Testez d’abord l’adresse CDN par défaut pour séparer domaine et permissions.

Pourquoi le fichier reste-t-il ancien après une purge CDN ? Le navigateur peut conserver sa propre copie. Comparez origine et CDN avec le cache local désactivé pour diagnostiquer le décalage. Pour publier une version, envoyez un nouveau nom et modifiez la référence dans la page. La purge ne rappelle pas les téléchargements existants.

Restreindre la liste protège-t-il les fichiers publics ? Non. Les permissions de liste concernent l’énumération ; celles des objets concernent la lecture. Un objet public reste lisible par son URL exacte. Utilisez une conception privée distincte pour les fichiers sensibles et testez les objets publics sans connexion.

Les liens signés profitent-ils du cache CDN ? DigitalOcean indique que son CDN ne met pas en cache les requêtes présignées. Cette procédure publique ne convient donc pas aux téléchargements privés ou payants. Leur accès demande une conception distincte avec autorisation, expiration et modèle de coût adapté.

Choisissez une image publique à faible risque pour le premier changement réel. Notez ancienne URL, nouvelle URL, révision de page et résultat sur ordinateur et mobile. Vérifiez également ses dimensions affichées. Une bonne réponse réseau n’empêche pas un décalage de mise en page lorsque l’image n’a aucun espace réservé.

Demandez à une personne hors de votre session de consulter la page, ou utilisez un autre appareil et un autre réseau que vous contrôlez. Vérifiez le nom personnalisé et les octets attendus. Adaptez la surveillance au rôle du fichier. Une illustration décorative cassée et un téléchargement d’installation cassé n’ont pas les mêmes conséquences.

Si la page échoue, rétablissez d’abord son ancienne URL ou sa révision précédente. Ne supprimez pas le compartiment pour annuler une modification de page. Gardez les anciens objets jusqu’à l’examen de la période de retour arrière et des références applicatives. Supprimez le fichier mutable jetable à la fin de l’exercice.

Choisissez cette méthode lorsque séparer fichiers publics et hébergement applicatif résout un problème réel de publication ou de facturation. Gardez votre hébergeur actuel s’il convient déjà. Après les tests de publication et de retour arrière, augmentez progressivement le nombre de fichiers puis examinez la facture après un mois complet.