Azure Blob Storage : types de blobs, accès, niveaux et coûts

Avec Azure Blob Storage, une application peut conserver ses documents, médias et sauvegardes sous forme d'objets nommés individuellement dans le cloud de Microsoft. Le service traite les données non structurées. Si vous développez une application ou gérez ses données, les décisions principales concernent l'écriture des objets, les personnes autorisées à les récupérer et le délai de disponibilité nécessaire. Ce guide présente les types de blobs, les contrôles d'accès, les niveaux de stockage, les coûts et les vérifications à effectuer avant une migration.

Qu'est devenu Windows Azure Blob Storage ?

« Windows Azure Blob Storage » est une ancienne appellation encore utilisée dans les recherches. Microsoft a renommé Windows Azure en Microsoft Azure en 2014. La documentation actuelle emploie Azure Blob Storage. Les références Microsoft liées dans ce guide sont en anglais.

Données non structurées et autres services de stockage Azure

Azure Blob Storage conserve les données textuelles et binaires sous forme d'objets, sans fournir une base de données traditionnelle ni un système de fichiers partagé. Dans une application, les fichiers audio ou les images originales peuvent ainsi résider dans le stockage objet, tandis qu'une base de données contient les enregistrements permettant de les rechercher. Choisissez le service selon les opérations nécessaires.

Comment Azure Blob Storage organise les données

La structure repose sur trois ressources : un compte de stockage délimite le service, un conteneur regroupe les blobs et chaque blob contient un objet. La présentation de Blob Storage décrit ce modèle et les interfaces disponibles. Pour préparer votre organisation, vous pouvez par exemple prévoir un conteneur pour les fichiers envoyés par les clients et un autre pour les rapports générés, avec des droits examinés séparément.

Noms d'objets et répertoires

Dans un espace de noms plat, un nom comme reports/2026/october.csv utilise des barres obliques pour représenter un chemin. L'activation de l'espace de noms hiérarchique pour Azure Data Lake Storage ajoute des fonctions liées aux répertoires. Ce choix influe sur la compatibilité des fonctionnalités : prenez-le avant de définir la récupération et les accès.

Une application conçue pour un système de fichiers ne peut pas nécessairement utiliser le stockage objet sans modification. Vérifiez ses besoins de renommage, de verrouillage et de mise à jour des fichiers. Notre guide des systèmes de fichiers dans le cloud explique les principales approches. Pour une nouvelle application, choisissez des noms d'objets stables et déterminez si une mise à jour remplace l'objet ou crée une nouvelle version.

Choisir le compte selon la charge de travail

Un compte standard à usage général v2 constitue un point de départ courant. Les comptes de blobs de blocs Premium répondent à d'autres besoins de performance et n'offrent pas les mêmes possibilités de changement de niveau. Comparez les types de comptes disponibles avant de créer le vôtre. Le terme « Premium » doit conduire à tester un besoin précis, pas à éviter de le mesurer.

Consignez la région souhaitée, la croissance attendue, le chemin réseau et les fonctions de récupération nécessaires. Désignez aussi la personne responsable des paramètres du compte. Une configuration techniquement valide reste difficile à exploiter si personne ne répond de ses autorisations, de ses dépenses ou de sa procédure de restauration.

Blobs de blocs, blobs d'ajout et blobs de pages

Choisissez le type de blob en fonction des écritures réalisées par l'application. La référence Microsoft sur les types de blobs distingue trois modèles :

Type	Mode d'écriture	Usage courant
Blob de blocs	Envoyer des blocs puis valider l'objet constitué	Documents, médias, sauvegardes et jeux de données
Blob d'ajout	Ajouter des blocs à la fin	Journaux alimentés par ajout
Blob de pages	Modifier des plages alignées dans un objet	Charges nécessitant des lectures et écritures aléatoires

Pour un service d'envoi de documents, les blobs de blocs sont le premier choix à examiner. Les blobs d'ajout méritent une étude lorsque l'application ajoute continuellement des enregistrements sans modifier les précédents. Les blobs de pages nécessitent une application conçue pour leurs opérations ; ils ne constituent pas une amélioration générale pour les envois de fichiers ordinaires.

Vérifier les limites de la version d'API

La capacité n'est pas illimitée. Avec la version de service 2019-12-12 ou ultérieure, la taille maximale documentée d'un blob de blocs atteint environ 190,7 Tio ; celle d'un blob de pages est de 8 Tio. Les anciennes versions ont des limites inférieures pour les blobs de blocs. Consultez les limites actuelles correspondant au client et au compte prévus.

Une taille maximale d'objet ne renseigne guère sur la durée d'un transfert. Testez le plus grand objet attendu, puis un ensemble représentatif de petits objets. Ces essais répondent à des questions différentes : le premier mesure le transfert soutenu, tandis que le second aide à observer le coût de nombreuses requêtes distinctes.

Contrôler la lecture et l'écriture des données

Privilégier les identités

Microsoft recommande l'autorisation par Microsoft Entra ID, anciennement Azure Active Directory, lorsqu'elle est prise en charge. Utilisez le contrôle d'accès basé sur les rôles (RBAC) et envisagez les identités managées pour les applications exécutées dans Azure. Le droit de gérer un compte de stockage est distinct du droit de lire son contenu. Les clés de compte donnent un accès étendu et ne doivent pas figurer dans le code source.

Définissez les accès à partir des tâches. Un service de rapports peut avoir besoin de lire un jeu de données, tandis qu'un service d'ingestion doit écrire de nouveaux objets. Examinez chaque identité séparément au lieu d'accorder les mêmes permissions étendues à tous les services. Testez les opérations refusées autant que les opérations autorisées, notamment une tentative d'écriture avec une identité limitée à la lecture.

Limiter la délégation avec une signature d'accès partagé

Une signature d'accès partagé (SAS) délègue un accès avec des permissions et une échéance définies. Microsoft recommande une SAS de délégation d'utilisateur lorsque c'est possible pour Blob Storage. Traitez l'URL signée comme un identifiant secret : toute personne qui la possède peut exercer les droits accordés tant qu'elle reste valide.

Pour un envoi temporaire, précisez la destination autorisée, la possibilité de remplacer des objets existants et la durée d'accès nécessaire. Évitez de placer les URL signées dans les événements d'analyse, les captures destinées au support ou les journaux ordinaires. La facilité de partage d'un lien ne rend pas son contenu anodin.

Un point de terminaison privé ne désactive pas seul l'accès public

Un point de terminaison privé Azure fournit un chemin réseau privé. Sa création ne bloque pas automatiquement le point de terminaison public du compte. Configurez séparément l'accès réseau public et les règles de pare-feu, puis vérifiez la résolution DNS depuis les clients concernés. L'accès réseau et l'autorisation restent deux contrôles distincts.

Vérifiez également le transport et le chiffrement. Azure Storage chiffre les données au repos avec Storage Service Encryption. Pour l'accès REST, l'exigence de transfert sécurisé rejette les requêtes HTTP lorsqu'elle est activée. Aucun de ces réglages ne corrige des permissions excessives. Notre guide de sécurité du cloud replace ces contrôles dans un plan opérationnel plus large.

Choisir le niveau selon les besoins de récupération

Pour les blobs de blocs standard éligibles, les principaux niveaux d'accès sont les suivants :

Niveau	Accès	Durée minimale facturable en usage général v2
Hot	En ligne, pour un usage fréquent	Aucune
Cool	En ligne, pour un usage moins fréquent	30 jours
Cold	En ligne, pour un usage rare	90 jours
Archive	Hors ligne ; réhydratation nécessaire	180 jours

Ces durées minimales de facturation ne verrouillent pas la conservation. Une suppression, un remplacement ou un changement de niveau anticipé peut entraîner des frais. Un prix de capacité inférieur s'accompagne aussi de coûts d'accès différents. Ces niveaux ne s'appliquent pas aux blobs d'ajout et de pages.

Tester l'archivage avant d'en dépendre pour une restauration urgente

La réhydratation depuis Archive est asynchrone. Sa durée dépend notamment de la priorité et de la demande, et peut se compter en heures. Une priorité élevée ne permet pas de promettre un délai de récupération fixe pour toutes les charges.

Distinguez les documents conservés pour une enquête occasionnelle de la sauvegarde nécessaire au redémarrage des activités. Si un service doit être restauré en moins d'une heure, testez toute la procédure avant de placer sa seule copie utilisable dans Archive. Incluez le temps nécessaire pour trouver les objets, obtenir les accès, transférer les données et redémarrer l'application.

Examiner Smart tier si les conditions conviennent

Smart tier déplace automatiquement les blobs de blocs éligibles entre Hot, Cool et Cold selon leur utilisation. Il n'utilise pas Archive et impose des conditions de compte, de redondance et de région, avec des frais de surveillance à prendre en compte. Comparez ces conditions au jeu de données réel sans supposer que l'automatisation réduit toujours la facture.

Estimer le prix à partir de l'activité

La page des tarifs Azure Blob Storage distingue la capacité, les opérations, la récupération et les autres frais applicables. La région, la redondance et le niveau influent sur l'estimation. Le transfert de données et certaines fonctions peuvent ajouter des coûts. Un tarif de stockage par Go ne constitue pas à lui seul un budget mensuel.

Préparez une estimation pour un mois normal et une autre pour un mois comprenant une restauration. Relevez le volume moyen stocké, le nombre d'objets, les requêtes de lecture et d'écriture, les données récupérées et celles qui quittent la région. Ajoutez les versions et copies conservées à la capacité. Simulez ensuite une restauration importante ou une exportation vers un autre fournisseur.

Un jeu de données rarement consulté peut par exemple sembler économique dans un niveau plus froid, jusqu'à ce qu'un traitement mensuel le relise entièrement. Un autre peut rester intact pendant des années, mais nécessiter une restauration urgente. Leurs volumes moyens peuvent être identiques alors que leurs hypothèses de coût et de récupération diffèrent. Utilisez l'activité mesurée pour orienter le choix.

Encadrer la gestion du cycle de vie

Les stratégies de cycle de vie déplacent les données éligibles vers des niveaux plus froids ou les suppriment selon des conditions. Elles peuvent cibler des préfixes ou des balises d'index. Leur exécution est asynchrone et elles ne réhydratent pas les blobs archivés. Les modifications peuvent prendre jusqu'à 24 heures avant de commencer à s'appliquer.

Commencez par un ensemble restreint de données non critiques et une règle documentée. Examinez, par exemple, si des exportations terminées deviennent éligibles à un niveau plus froid après une période définie, tandis que les envois actifs restent hors de cette règle. Faites valider les suppressions séparément par le responsable des données. Une mesure d'économie ne doit pas devenir discrètement la politique de conservation de l'organisation.

Prévoir la récupération dans la configuration

Le guide de protection des données Blob Storage distingue les contrôles selon les incidents. La suppression réversible des conteneurs, celle des blobs et le versionnage protègent des ressources ou modifications différentes. Un verrou sur le compte concerne sa suppression, pas toutes les opérations sur les blobs. La configuration influe aussi sur les fonctions disponibles : le versionnage des blobs n'est pas pris en charge avec un espace de noms hiérarchique.

La redondance nécessite un choix séparé. Les options de réplication Azure couvrent les configurations locales, zonales et géographiques, avec une réplication asynchrone entre régions. La réplication ne prouve pas à elle seule qu'une version utile sera récupérable après une erreur applicative. Choisissez délibérément la localisation ; notre explication de l'emplacement des données dans le cloud apporte du contexte à cette décision.

Effectuez un test de récupérabilité limité comprenant un objet remplacé, un conteneur supprimé et l'indisponibilité de l'opérateur principal. Notez ce qui a été récupéré, par qui et en combien de temps. Répétez l'essai lorsque les fonctions du compte ou le comportement de l'application changent.

Envoyer, migrer et vérifier les données

Commencer par un petit envoi avec Azure Storage Explorer

Pour un premier essai, créez un compte de stockage Azure depuis le portail Azure, Azure CLI ou Azure PowerShell. Dans Azure Storage Explorer, connectez-vous, choisissez l'abonnement et développez le compte. Sous Blob Containers, créez un conteneur, puis utilisez Upload pour sélectionner un fichier et son type de blob. Examinez le résultat du transfert et téléchargez l'objet pour le vérifier.

Utilisez un échantillon non sensible et confirmez le nom du compte avant l'envoi, surtout lorsque plusieurs comptes se ressemblent. Gardez le conteneur privé pour cet essai et vérifiez l'accès avec l'identité que l'application utilisera réellement. Un envoi réussi par un administrateur ne démontre pas qu'un service en production dispose des bonnes permissions.

Respectez les règles de nommage des conteneurs : de 3 à 63 caractères, avec des lettres minuscules, des chiffres et les traits d'union autorisés. Les noms de blobs distinguent majuscules et minuscules. Définissez une convention avant de déplacer les données existantes afin d'éviter les doublons imprévus ou les références illisibles.

Choisir l'outil et un point de départ maîtrisé

AzCopy est l'utilitaire de transfert en ligne de commande de Microsoft. Il accepte l'autorisation par Entra ID ou jeton SAS. Azure Storage Explorer offre une interface graphique ; les applications peuvent utiliser l'API REST ou les bibliothèques clientes prises en charge. Microsoft précise qu'AzCopy ne prend pas en charge les transferts dont la source ou la destination change activement.

Prévoyez une transition cohérente pour l'application, avec un point défini à partir duquel la source cesse de changer. La réussite d'une commande de copie ne prouve pas que l'application est prête. Une migration peut transférer tous les octets tout en omettant des autorisations, des conventions de nommage ou des métadonnées attendues.

Pour une intégration applicative, le guide de démarrage de la bibliothèque Azure Storage pour Python présente la création, la liste, l'envoi et le téléchargement de blobs avec une autorisation fondée sur les identités. Écartez du code source les identifiants secrets, y compris les chaînes de connexion contenant des clés de compte. Choisissez la version du SDK Azure et testez son comportement avec les types de blobs et niveaux utilisés.

Liste de validation d'une migration

1. Inventorier la source. Comptez objets et octets, repérez les grands objets et relevez les métadonnées et règles de conservation nécessaires.
2. Préparer la destination. Confirmez le compte, l'espace de noms, la région, le type de blob, le niveau et les identités autorisées.
3. Copier un échantillon représentatif. Incluez petits et grands fichiers, noms inhabituels et profondeur réaliste des répertoires.
4. Valider le résultat. Comparez nombres et tailles, vérifiez l'intégrité avec des sommes de contrôle adaptées, puis testez les métadonnées et les lectures applicatives.
5. Tester les incidents et la récupération. Vérifiez les transferts interrompus, les accès expirés, les écritures refusées et la restauration.
6. Approuver la bascule. Rapprochez les dernières modifications et documentez les conditions de retour arrière avant de supprimer la copie source.

Mesurez depuis l'emplacement habituel de l'application avec son véritable profil de requêtes. Relevez ensemble débit, latence, erreurs et coûts. Un essai de grands objets séquentiels ne démontre pas les performances de milliers de petites lectures interactives. Conservez le jeu de test et la méthode pour comparer les résultats ultérieurs.

Surveiller Azure Blob Storage après la migration

Azure Monitor fournit des métriques et une journalisation pour Blob Storage. Les journaux de ressources nécessitent des paramètres de diagnostic qui les acheminent vers une destination. La présence de métriques dans le portail ne signifie donc pas qu'un historique des requêtes est disponible. Configurez des alertes utiles et désignez les personnes chargées d'y répondre.

Examinez les échecs d'accès, le volume de requêtes, la latence et la croissance avec les dépenses. Une hausse soudaine des téléchargements peut correspondre à une analyse légitime, à une boucle de nouvelles tentatives ou à un problème d'accès. Recherchez le contexte applicatif au lieu d'interpréter un graphique isolé. Surveillez aussi les transferts qui alimentent les conteneurs : le bon état du stockage ne prouve pas que les fichiers de la nuit sont arrivés.

Conservez une fiche d'exploitation pour chaque charge en production : responsable, identités autorisées, comptes de stockage, règles de cycle de vie, objectif de récupération et dernière restauration réussie. Réexaminez-la après les modifications applicatives. La gestion des données se poursuit après l'envoi initial, surtout lorsque plusieurs équipes partagent le compte.

Deux décisions avant la mise en production

L'hébergement de site statique convient-il ?

La fonction d'hébergement de site statique sert les fichiers du conteneur $web par un point de terminaison dédié. Elle utilise la lecture anonyme ; modifier le niveau d'accès anonyme du conteneur ne sécurise pas ce point de terminaison. Des règles réseau peuvent limiter son accessibilité, mais la fonction ne fournit pas d'authentification des utilisateurs. Pour des pages privées propres à chaque utilisateur, choisissez un service applicatif avec une authentification adaptée.

Faut-il une intégration Azure ou un service compatible S3 ?

Si l'application dépend des identités, API ou services de données Azure, examinez ces dépendances avant de comparer les fournisseurs. Object Storage avec Hivenet est une option compatible S3 à évaluer pour les charges adaptées. Une intégration utilisant l'API Azure Blob nécessite une étude de compatibilité et de migration ; changer uniquement le point de terminaison ne suffit pas.

Décidez après avoir testé vos opérations et estimé le coût complet de conservation, de récupération et de déplacement des données. La configuration retenue doit pouvoir être expliquée, exploitée et restaurée par votre équipe lorsqu'un problème survient.