Stockage de données cloud : usages, coûts et restauration

Choisir un service cloud pour stocker des données commence par leur usage. Documents partagés, fichiers envoyés par une application, volumes de base de données, sauvegardes et jeux de données d'IA nécessitent des interfaces et des dispositifs de restauration différents. Comparez le modèle de stockage, le coût complet, les contrôles d'accès, la localisation et les modalités de sortie avant de choisir un fournisseur.

Ce guide s'adresse aux développeurs, aux équipes data et aux acheteurs qui évaluent le stockage de volumes croissants. Il explique les modèles fichier, bloc et objet, précise les éléments d'une estimation de coût et propose une liste de vérifications pour un pilote. L'objectif est une décision que vous pouvez tester, documenter et revoir lorsque vos besoins changent.

Partir de l'usage, pas du chiffre de capacité

Un besoin comme « il nous faut 50 To » laisse des questions importantes sans réponse. S'agit-il d'une archive vidéo téléchargée deux fois par an, d'un jeu de données lu chaque jour ou de millions de petits fichiers applicatifs ? Ces usages peuvent représenter la même capacité et avoir des besoins de performance, des volumes de requêtes et des coûts de transfert très différents.

Créez un inventaire avec un responsable identifié pour chaque jeu de données. Consignez sa taille actuelle, sa croissance, le nombre de fichiers ou d'objets, leurs tailles habituelles, la fréquence des lectures et des écritures, la durée de conservation et la sensibilité. Identifiez les applications qui l'utilisent et leur lieu d'exécution. Incluez les anciennes versions, les répliques et les sauvegardes dans l'estimation du volume stocké.

Définissez séparément les besoins de restauration. Quelle quantité de travail récent pourriez-vous perdre et combien de temps l'application pourrait-elle rester indisponible ? Ce sont les objectifs de point de reprise et de délai de reprise, souvent désignés par RPO et RTO. Ils aident à déterminer la fréquence des sauvegardes, les capacités de restauration et la pertinence d'une classe d'archivage peu coûteuse.

Comment fonctionne le stockage cloud ?

Le stockage cloud conserve les données sur une infrastructure accessible par le réseau, depuis une application, un partage monté ou une API. Un fournisseur de service géré exploite les systèmes de stockage sous-jacents, tandis que les clients configurent toujours les comptes, les permissions, l'organisation des données et les procédures de restauration. La présentation du stockage cloud par AWS introduit les principaux modèles.

Le stockage cloud peut apporter de la capacité à la demande, réduire la maintenance matérielle et permettre l'accès depuis différents lieux. Ces avantages ont des limites. La connectivité, les clients compatibles, les quotas, la disponibilité du service et l'accès au compte restent nécessaires. Le cloud ne supprime pas toutes les responsabilités informatiques et ne garantit pas un coût inférieur au stockage sur site.

Services de partage de fichiers et stockage d'infrastructure

Les applications de partage permettent de conserver des documents, de partager des fichiers et de travailler sur plusieurs appareils. Pour la bureautique, vérifiez la synchronisation, les droits des collaborateurs externes, les applications mobiles, les limites de taille et la récupération des fichiers supprimés. L'intégration à Google Workspace ou Microsoft Office peut compter davantage qu'une API objet.

Le stockage d'infrastructure sert les applications et les tâches automatisées. Un bucket ne fournit pas automatiquement l'édition de documents, la synchronisation sur ordinateur ou une interface familière de gestion de fichiers. À l'inverse, un forfait grand public offrant beaucoup d'espace ne fournit pas forcément les API, les contrôles d'accès, les journaux ou l'assistance nécessaires à une application en production.

Choisir entre stockage fichier, bloc et objet

Modèle	Accès par les applications	Usages courants	Points à vérifier
Fichier	Fichiers et répertoires, souvent via NFS ou SMB	Dossiers de projets partagés et applications nécessitant un système de fichiers	Permissions, verrouillage, opérations sur les métadonnées et compatibilité des clients
Bloc	Volumes utilisés par un système d'exploitation ou une application	Disques de VM et stockage de bases de données transactionnelles	Latence, IOPS, règles de rattachement, instantanés et disponibilité
Objet	Objets désignés par des clés et accessibles par API	Fichiers applicatifs, sauvegardes, médias, journaux, archives et jeux de données	Comportement de l'API, coût des requêtes, tailles d'objets et fonctions de restauration

Le stockage fichier pour un accès partagé

Un partage de fichiers géré peut convenir aux logiciels qui attendent des répertoires, des permissions et un accès partagé. Il diffère d'une application grand public qui synchronise un dossier local. Vérifiez le protocole et les comportements nécessaires, notamment si l'application dépend du verrouillage, de renommages fréquents ou de nombreux petits fichiers.

Déplacer un usage de stockage en réseau, ou NAS, vers un partage distant peut modifier la réactivité. Testez l'application depuis les lieux de travail réels. Un transfert réussi de gros fichier ne prouve pas que parcourir un répertoire contenant des milliers d'entrées sera rapide.

Le stockage bloc pour les volumes et les bases de données

Le stockage bloc présente les données sous forme de volume plutôt que de collection d'objets. Il sert couramment aux systèmes d'exploitation et aux bases de données qui effectuent des mises à jour fréquentes. Le résultat dépend du volume choisi, de l'hôte de calcul, du réseau et de la configuration de la base ; le mot « bloc » ne garantit pas les performances.

Vérifiez si un volume peut être rattaché à un ou plusieurs hôtes, où il peut l'être et comment fonctionnent les instantanés et les sauvegardes cohérentes du point de vue de l'application. Ne déplacez pas une base active en copiant des fichiers en cours de modification, sauf si sa procédure de sauvegarde prise en charge rend cette copie cohérente.

Le stockage objet pour les applications et les jeux de données

Le stockage objet organise les données en objets associés à des identifiants et à des métadonnées. Amazon S3, Azure Blob Storage et Google Cloud Storage en sont des exemples. Ils servent des applications et des traitements de données, mais leurs interfaces, leurs classes de stockage et leurs fonctions de gestion diffèrent.

Ce modèle convient aux données non structurées comme les images et les vidéos, ainsi qu'aux données structurées enregistrées dans des fichiers CSV ou Parquet. Il n'est donc pas limité aux contenus non structurés. Une vue en dossiers ou un outil de montage ne prouve pas non plus que toutes les opérations se comportent comme l'application l'attend. Testez le client et les opérations réellement utilisés.

Pour l'IA et l'analyse, mesurez le débit de lecture des données utiles par les processus de traitement. De très petits objets, des listes répétées, des lectures distantes et des formats peu efficaces peuvent ralentir une chaîne de traitement malgré une bande passante nominale suffisante. Comparez des lots et des niveaux de concurrence réalistes, en incluant le coût du transfert vers le calcul.

Choisir un mode de déploiement pour un besoin précis

Les services de cloud public utilisent l'infrastructure d'un fournisseur partagée entre clients, dont les ressources sont séparées par des contrôles d'accès. Une infrastructure de cloud privé est dédiée à une organisation et peut être exploitée en interne ou par un prestataire. Un déploiement privé ne sécurise pas automatiquement les données : configuration, compétences et maintenance restent déterminantes.

Une architecture hybride relie des systèmes sur site à des services cloud. Une architecture multicloud utilise plusieurs fournisseurs. Ces choix peuvent répondre à des besoins de localisation, d'intégration ou de restauration, mais ajoutent du travail de coordination. Une copie chez un second fournisseur n'est utile que si elle est à jour, accessible pendant un incident et restaurable par les personnes responsables.

Le stockage distribué décrit la répartition des données dans l'infrastructure. Il ne suffit pas à établir qui possède cette infrastructure, dans quel pays se trouve une réplique ou si les défaillances des comptes sont indépendantes. Demandez le modèle réel de placement et de défaillance plutôt que de traiter « distribué », « européen » ou « souverain » comme une spécification complète.

Distinguer durabilité, disponibilité et sauvegarde

La durabilité concerne la conservation des données intactes dans le temps. La disponibilité concerne la possibilité d'y accéder au moment voulu. Une copie durable peut être temporairement inaccessible et un service très disponible peut exécuter une suppression autorisée. Un objectif de conception publié diffère également d'un accord de niveau de service, ou SLA, et des recours qu'il prévoit.

La redondance contribue à protéger les données contre les pannes matérielles, mais son périmètre varie. La documentation de protection des données d'Amazon S3 distingue les options réparties sur plusieurs zones de celles limitées à une seule zone. Comparez la classe et les scénarios de panne précis plutôt que d'appliquer un chiffre de durabilité à tous les services.

La sauvegarde cloud ajoute une procédure de récupération : quelles données sont copiées, quand, pour combien de temps et comment elles sont restaurées. La synchronisation peut propager une suppression ou un fichier endommagé vers un autre appareil. Notre guide de la synchronisation et de la sauvegarde cloud explique cette différence.

Le versionnage et les règles de conservation peuvent aider, mais leur configuration et les droits d'administration comptent. Les recommandations de la CISA sur les rançongiciels préconisent des copies de récupération protégées, dont des sauvegardes chiffrées hors ligne, et des tests réguliers de restauration. Testez avec les identifiants et la documentation qui resteraient disponibles pendant un incident. Télécharger un fichier témoin ne constitue pas un exercice complet de reprise après sinistre.

Calculer le coût du stockage cloud sur l'ensemble de l'usage

Le prix par Go ou To n'est qu'un point de départ. Les services peuvent facturer la capacité provisionnée, l'utilisation réelle, les abonnements, les requêtes, la récupération, la réplication ou le transfert. Certains coûts dépendent de la région et de la classe. Utilisez les tarifs actuels et un devis lorsque les conditions sont négociées.

Poste de coût	Éléments à estimer	Oubli fréquent
Capacité stockée	Volume facturable moyen par classe et par mois	Anciennes versions, répliques et tailles minimales facturables
Requêtes	Envois, lectures, listes, copies et opérations de cycle de vie	Nouvelles tentatives et millions de petits objets
Récupération	Données extraites des classes peu fréquentes ou d'archivage	Tests et restaurations urgentes
Transfert	Sorties vers Internet, échanges entre régions et autres mouvements facturables	Calcul chez un autre fournisseur ou dans une autre région
Conservation	Durée minimale et conditions de suppression anticipée	Données souvent remplacées dans une classe froide
Exploitation	Journaux, gestion des clés, assistance et temps de l'équipe	Migration et fonctionnement parallèle

La page officielle des tarifs Amazon S3 distingue par exemple plusieurs dimensions de facturation. Ne réutilisez pas un ancien tarif sans vérifier la région, la classe, les volumes inclus et la destination du transfert. De même, la « sortie gratuite » concerne un poste de coût ; elle ne rend pas l'ensemble du service ou de la migration gratuit.

Un calcul simple à adapter

Supposons qu'une équipe conserve en moyenne 20 000 Go et en télécharge 5 000 par mois. Avec des tarifs fictifs de 0,015 € par Go stocké et par mois et de 0,02 € par Go téléchargé, le stockage coûterait 300 € et le transfert 100 €, soit 400 € avant les requêtes, la récupération, l'assistance, les taxes et les autres frais. Ces valeurs sont illustratives et ne sont pas des tarifs de fournisseurs.

Répétez le calcul pour un mois courant, un mois chargé et une exportation ou restauration complète. Utilisez des unités cohérentes : les Go ou To facturables peuvent différer des Gio ou Tio affichés par les outils locaux. Incluez la période pendant laquelle les anciens et nouveaux services fonctionneront simultanément et désignez l'équipe responsable des dépassements.

Adapter les classes de stockage aux accès

Les données fréquemment consultées nécessitent généralement une classe immédiatement accessible. Les classes peu fréquentes et d'archivage peuvent échanger un coût de stockage inférieur contre des frais de récupération, des durées minimales ou un accès différé. Le terme « froid » ne correspond pas à un délai universel. Le comparatif des classes S3 montre ces différences chez un même fournisseur.

Avant d'activer des règles de cycle de vie, testez-les sur des données jetables et examinez ce qu'elles déplacent ou suppriment. Une règle peut modifier les coûts et la restauration de tout un ensemble de données. Distinguez les exigences de conservation des hypothèses sur la fréquence d'utilisation.

Évaluer la sécurité et la localisation des données

Vérifier qui peut lire, modifier et supprimer

Utilisez des identités distinctes pour les personnes et les applications, accordez les accès nécessaires et révisez les permissions lorsque les rôles changent. Protégez les comptes d'administration par une authentification multifacteur lorsque le service le permet. Évitez de placer des identifiants durables dans le code source, des documents partagés ou des journaux.

Vérifiez le caractère privé par défaut, les contrôles de partage public, les journaux d'accès et la révocation des identifiants. Le chiffrement en transit et au repos protège contre des menaces différentes ; il ne signifie pas automatiquement un chiffrement de bout en bout ni l'impossibilité pour le fournisseur d'accéder aux données en clair. Demandez qui contrôle les clés et comment restaurer les données si une clé devient indisponible.

Les recommandations de sécurité S3 donnent des exemples propres au service, dont les contrôles d'accès public et la gestion des politiques. Appliquez les contrôles documentés pour votre fournisseur. Notre guide de sécurité du stockage cloud propose des questions plus générales pour cette évaluation.

Vérifier la résidence et les responsabilités contractuelles

Consignez les lieux de stockage des données principales, des répliques, des sauvegardes et des journaux pertinents. Renseignez-vous sur les accès de l'assistance, les sous-traitants, les procédures de suppression et les engagements contractuels. Le siège du fournisseur ou le nom d'une région ne répond pas à toutes ces questions.

Pour les données personnelles, évaluez les obligations applicables avec les responsables de la protection des données et des achats. Les recommandations du Comité européen de la protection des données expliquent pourquoi les transferts internationaux nécessitent leur propre analyse. Choisir un lieu de stockage dans l'UE ne suffit pas à établir la conformité au RGPD de l'ensemble du traitement.

Si un fournisseur cite une certification, demandez une preuve à jour et son périmètre : organisation, installations, services et exclusions. Si l'impact environnemental entre dans la décision, demandez une période et une méthode de mesure définies. Une architecture distribuée ou une affirmation d'efficacité ne constitue pas une mesure de l'empreinte de votre usage.

Comparer les fournisseurs sur les besoins réels

Amazon S3, Azure Blob Storage et Google Cloud Storage peuvent être pratiques lorsque les applications dépendent déjà des services de ces clouds. Un fournisseur indépendant peut répondre à d'autres exigences de coût, de localisation ou d'exploitation. Aucune de ces catégories n'est automatiquement le meilleur choix.

La compatibilité S3 peut permettre d'utiliser des clients connus avec un autre point de terminaison, mais ne promet pas une équivalence complète avec les fonctions AWS. Testez l'authentification, les envois, les téléchargements, les listes, la pagination, les nouvelles tentatives et les opérations de l'application. Confirmez séparément les fonctions nécessaires de versionnage, cycle de vie, verrouillage de conservation, événements et permissions.

Où se situe Hivenet Object Storage ?

Hivenet Object Storage est le nom public actuel de l'offre de stockage objet professionnel de Hivenet. Sa page produit décrit des usages compatibles S3 avec boto3, aws-cli et rclone, la sortie de données gratuite et une infrastructure reposant sur Policloud. L'accès et l'accompagnement à la migration passent par une demande d'accès ou un échange commercial.

Évaluez cette offre pour les sauvegardes, archives, médias, jeux de données et objets applicatifs avec les mêmes critères de pilote que les autres fournisseurs. Confirmez la région disponible lors de la mise en place et demandez les conditions actuelles, les limites, la documentation de sécurité et les fonctions API nécessaires. La description publique ne prouve pas que chaque opération S3 ou chaque exigence de conformité est prise en charge.

Store with Hivenet est un produit distinct pour les fichiers du quotidien et la sauvegarde de photos, avec des forfaits de stockage. N'appliquez pas ses quotas grand public, son modèle de compte ou ses tarifs au stockage objet professionnel. Choisissez le produit correspondant à la façon dont les personnes ou les applications accéderont aux données.

Tester aussi la restauration et la sortie pendant le pilote

Utilisez des données non sensibles ou préparées de manière appropriée, représentatives de l'usage réel. Fixez les critères d'acceptation avant le test : restauration dans le délai requis, refus correct des accès interdits et facture conforme à l'estimation, par exemple. Le pilote doit produire des preuves qu'une autre personne peut examiner.

1. Testez l'interface. Connectez l'application, l'outil de sauvegarde ou le SDK réellement utilisé. Exécutez les opérations nécessaires et consignez les comportements non pris en charge.
2. Testez les performances réelles. Utilisez des tailles et nombres d'objets, des niveaux de concurrence et des lieux représentatifs. Mesurez les envois, lectures, listes, nouvelles tentatives et durées de traitement complètes.
3. Testez les contrôles d'accès. Confirmez que les actions autorisées réussissent et que les actions interdites échouent. Révoquez un identifiant de test et vérifiez qu'il ne fonctionne plus.
4. Testez la restauration. Restaurez un ensemble représentatif vers une destination propre, puis vérifiez l'intégrité et l'utilisation par l'application. Testez la conservation et la suppression sur des objets jetables.
5. Vérifiez la facture. Comparez l'utilisation mesurée à l'estimation, en incluant requêtes, transferts, versions et données conservées. Expliquez les écarts avant d'augmenter le volume.
6. Testez la sortie. Exportez les données et les métadonnées nécessaires vers un autre emplacement. Consignez la durée, les limites des outils, les coûts et la procédure de suppression ou de fermeture du compte.

Pendant la migration, indiquez quel système fait autorité, comment les modifications survenues pendant la copie sont reprises et quels événements déclenchent un retour arrière. Comparez les sommes de contrôle lorsque cela convient, les nombres d'objets, les métadonnées et les résultats applicatifs. Les sommes de contrôle ne sont pas toujours interchangeables entre outils ou méthodes d'envoi : vérifiez ce que chacune représente.

Conservez la possibilité de restauration d'origine jusqu'à la validation du nouveau service. Retirez l'ancien stockage uniquement dans le cadre du plan de conservation et de migration approuvé. Examinez ensuite les coûts, les permissions, les tests de restauration et la croissance à une fréquence adaptée à l'usage.

Questions fréquentes sur le stockage de données cloud

Peut-on utiliser du stockage gratuit pour des données professionnelles ?

Une offre gratuite peut servir à apprendre ou à réaliser un pilote limité. Vérifiez ses conditions, sa capacité, son assistance, ses contrôles de sécurité et ses règles de suppression ou d'inactivité. La gratuité n'est pas automatiquement un défaut, mais une décision de production exige des preuves que le service répond aux besoins.

Le stockage objet remplace-t-il une base de données ?

Il peut contenir des sauvegardes, des exports et des fichiers utilisés par des systèmes analytiques. Il ne fournit pas automatiquement les requêtes, transactions, index ou comportements de mise à jour d'une base de données. Utilisez l'architecture prise en charge par la base ou la plateforme de données.

Comment réduire la dépendance à un fournisseur ?

Conservez des formats exportables, documentez les dépendances et testez une autre destination. Les API standard facilitent l'interface, mais la migration implique aussi permissions, intégrations applicatives, capacité de transfert, coûts et temps de travail. Multiplier les fournisseurs sans procédure de restauration ou de sortie testée ne résout pas ces difficultés.

Le stockage illimité est-il un bon critère d'achat ?

Considérez-le comme une condition à examiner. Demandez les règles d'utilisation raisonnable, les limites de taille des objets et fichiers, les débits de requêtes, les quotas de compte et les modalités d'augmentation de capacité. Le critère utile est la capacité du fournisseur à prendre en charge votre volume et vos accès prévus dans des conditions claires.