Stockage objet S3 : à quoi ça sert et quand le préférer à un disque

Un site grossit, et un jour le disque du serveur est plein de choses qui n'ont rien à y faire : des sauvegardes de l'an dernier, des milliers d'images téléversées par les visiteurs, des exports que personne n'ouvre plus. Le réflexe est de prendre un disque plus grand. C'est parfois la bonne réponse. Souvent, ces fichiers seraient mieux dans un stockage objet, c'est-à-dire dans des « buckets » auxquels on accède par le protocole S3.

Voici ce que c'est, à quoi ça sert, et dans quels cas il vaut mieux s'en passer.

Un bucket, des objets, une clé

Dans un stockage objet, vous ne montez pas un disque. Vous envoyez des objets dans un bucket (un conteneur nommé). Un objet est un fichier accompagné de quelques informations (sa taille, sa date, son type) et identifié par une clé, par exemple sauvegardes/2026-11/site.tar.gz.

Deux conséquences à connaître :

• Il n'y a pas de vraie arborescence. Les « dossiers » que montrent les outils ne sont que des préfixes dans le nom de la clé (documentation AWS sur les préfixes).
• On ne modifie pas un objet en place : on l'envoie de nouveau, en entier. C'est pourquoi le stockage objet convient aux fichiers que l'on écrit, que l'on lit et que l'on remplace, mais pas à une base de données ou à un système de fichiers qui change tout le temps.

S3 est à l'origine le service d'Amazon, mais son protocole est devenu un standard que beaucoup d'hébergeurs et de logiciels parlent. On parle de stockage « compatible S3 » : un outil écrit pour S3 fonctionne en changeant l'adresse (l'« endpoint ») et les clés d'accès.

Quatre usages où le stockage objet est le bon choix

1. La copie hors site de vos sauvegardes. C'est l'usage numéro un. La règle 3-2-1 demande trois copies, sur deux supports, dont une ailleurs. Un bucket est un « ailleurs » simple à brancher : rclone, Restic, Veeam ou les sauvegardes de cPanel savent y écrire. Notre article sur la stratégie de sauvegarde 3-2-1 détaille le reste de la règle.

2. Les fichiers qui s'accumulent. Images produits, pièces jointes, exports, journaux. Les sortir du disque du serveur allège les sauvegardes de la machine et évite le disque plein un vendredi soir. Pour les médias lourds ou très demandés, regardez aussi notre article sur l'hébergement de médias à fort trafic et celui sur la vidéo et le streaming.

3. Les archives. Factures, documents conservés pour des raisons légales, anciens journaux : des fichiers que l'on garde longtemps et que l'on relit rarement. Certains stockages proposent des classes plus économiques pour cet usage.

4. Les données d'une application. Les fichiers déposés par les utilisateurs d'une application web passent par un SDK S3 (PHP, Python, Node.js, Go, Java…) au lieu d'être écrits sur le disque local. L'application peut alors tourner sur plusieurs serveurs sans partager un disque.

Trois protections à comprendre avant de commencer

Un bucket n'est pas protégé du simple fait d'être « dans le cloud ». Trois réglages font la différence.

• Les clés d'accès limitées. Une clé par outil ou par serveur, restreinte au seul bucket dont il a besoin, en lecture seule quand il n'a pas à écrire. Si un serveur est compromis, vous révoquez sa clé et rien d'autre.
• Le versioning. Il garde les versions précédentes d'un objet : un fichier remplacé ou supprimé par erreur reste récupérable. Chaque version occupe de la place, donc elle compte dans l'espace utilisé (documentation AWS).
• Le verrou d'objet (Object Lock). Il rend un objet impossible à modifier ou à supprimer pendant la durée choisie, sur le modèle « écrire une fois, lire plusieurs fois » (documentation AWS). Pour des sauvegardes, c'est la meilleure parade contre un rançongiciel : tant que la durée fixée n'est pas écoulée, l'attaquant qui aurait mis la main sur vos identifiants ne peut pas effacer la copie verrouillée (vérifiez le mode de rétention proposé par votre fournisseur, certains modes peuvent être contournés par un compte autorisé). Le plus simple est de l'activer dès la création du bucket, avant d'y envoyer les premières sauvegardes.

Un dernier réflexe : une copie que l'on n'a jamais restaurée n'est pas une sauvegarde. Essayez de relire un fichier depuis le bucket dès le premier jour, puis régulièrement.

Quand ne pas utiliser un stockage objet

• Pour une base de données en production. MySQL ou PostgreSQL attendent un disque rapide qui accepte les petites écritures. Sauvegardez la base vers le bucket, ne la mettez pas dedans.
• Pour le code d'un site WordPress. Les fichiers du site doivent rester sur le disque de l'hébergement ; en revanche, des extensions savent envoyer la médiathèque vers un stockage S3.
• Pour un partage de fichiers monté comme un lecteur réseau. S3 n'est pas un système de fichiers. Si vos logiciels attendent un dossier partagé, un disque ou un partage NFS reste le bon outil.

Les questions à poser à n'importe quel fournisseur

Avant de choisir, vérifiez ces points, chez nous comme ailleurs :

1. La région. Où sont les données ? Si vous traitez des données personnelles, voyez avec votre délégué à la protection des données ce que vos obligations demandent.
2. Ce qui est facturé en plus de l'espace. L'envoi de données vers le stockage, la sortie de données, les requêtes, les anciennes versions conservées. Lisez la page de l'offre ligne à ligne.
3. Ce qui se passe quand l'espace inclus est dépassé. Le service s'arrête-t-il, ou continue-t-il avec une ligne de dépassement ? Existe-t-il un plafond qui protège d'une facture qui s'emballe ?
4. Le verrou d'objet et le versioning sont-ils disponibles, et sur quels buckets ?
5. La sortie. Pouvez-vous récupérer vos données avec vos outils habituels (rclone sync, aws s3 sync) si vous partez ?
6. L'endpoint. Les requêtes S3 sont signées avec le nom d'hôte : on ne peut en général pas utiliser son propre nom de domaine comme endpoint. Pour servir des fichiers sous votre domaine, passez par un CDN ou par votre serveur web.

Chez Atlas Hoster

Notre stockage objet S3 est compatible avec le protocole standard : rclone, l'AWS CLI, s3cmd, Restic, Veeam, Nextcloud, JetBackup et les SDK des principaux langages s'y branchent. Chaque offre inclut un espace ; au-delà, le Go est compté au prorata du temps où il est stocké. Vous êtes prévenu par e-mail à 80 % puis à 100 % de l'espace inclus, et un plafond passe vos clés en lecture seule si l'usage s'emballe. Les clés peuvent être limitées à un bucket, le versioning et le verrou d'objet sont disponibles, et les fichiers sont chiffrés au repos. Les buckets, les clés et l'usage se gèrent depuis votre espace client.

Pour la copie hors site d'un VPS ou d'un compte cPanel, voyez aussi nos sauvegardes et les offres VPS. Si vous préparez une migration, le guide pour migrer un site web explique comment déplacer les fichiers sans coupure inutile.

Questions fréquentes

Le stockage objet remplace-t-il un disque de serveur ?

Non. Il complète le disque. Le système, le code et les bases de données restent sur le disque du serveur ; les sauvegardes, les médias, les archives et les fichiers déposés par les utilisateurs vont dans les buckets.

Que veut dire « compatible S3 » ?

Que le service comprend le protocole de requêtes défini à l'origine par Amazon S3. Les outils et les bibliothèques écrits pour S3 fonctionnent en changeant l'adresse de l'endpoint et les clés d'accès.

Comment protéger mes sauvegardes d'un rançongiciel ?

En les envoyant hors du serveur, dans un bucket dont les clés sont limitées, avec le verrou d'objet activé pour une durée au moins égale à celle de votre rétention. Une copie que l'attaquant peut atteindre et effacer ne vous protège pas.

Puis-je utiliser mon propre nom de domaine pour accéder aux fichiers ?

Pas comme endpoint S3 : la signature des requêtes inclut le nom d'hôte. Vos fichiers publics peuvent en revanche être servis sous votre domaine par un CDN ou par votre serveur web.

Sources

• Amazon S3, Organizing objects using prefixes, S3 Versioning et S3 Object Lock, documentation officielle.
• Fonctions de notre offre : page Stockage objet S3.