
Non. Affirmer que tout stockage distant est du stockage cloud est faux. Le stockage distant désigne des données auxquelles vous accédez par un réseau, plutôt que depuis un support directement connecté à votre appareil. Le stockage cloud décrit la manière dont le stockage est fourni comme service, avec notamment un accès en libre-service, des ressources mutualisées et une capacité ajustable.
Un serveur de fichiers d'entreprise accessible par VPN est un stockage distant. Cette connexion seule n'en fait pas un service cloud. À l'inverse, un cloud privé peut fonctionner dans le propre centre de données d'une organisation. Pour comparer des solutions de stockage, les questions utiles portent sur la mise à disposition des ressources, les responsabilités, les limites et la restauration, au-delà de l'emplacement du matériel.
Le terme « distant » dépend de l'appareil ou de l'application qui utilise les données. Un serveur de fichiers dans la pièce voisine peut être un stockage distant pour votre ordinateur portable, même s'il se trouve dans le même bâtiment. Un serveur dans un autre pays l'est aussi. La distance ne définit pas un modèle de service particulier.
Un dossier partagé au bureau, un serveur de stockage en réseau (NAS), un serveur hébergé de transfert de fichiers et un compte de stockage cloud en sont des exemples. Tous permettent de conserver des données au-delà de l'appareil client, mais leur fonctionnement peut différer sur presque tous les autres points.
Un NAS sur votre réseau domestique peut proposer une application pour accéder aux fichiers lorsque vous êtes absent. Il reste à savoir qui entretient l'appareil, ce qui se passe lorsqu'il est plein et si une copie distincte existe. L'accès à distance ne répond à aucune de ces questions à lui seul.
La définition du cloud computing du NIST, en anglais, inclut le stockage parmi les ressources qu'un cloud peut fournir. Elle retient cinq caractéristiques essentielles. Appliquées à un service de stockage, elles donnent des repères plus utiles qu'une adresse Internet ou une étiquette commerciale :
Notre guide des cinq caractéristiques du cloud computing détaille ces points. Avant d'acheter un service de stockage, demandez comment ils se traduisent dans l'offre que vous utiliserez.
Un portail seul constitue une preuve limitée. Il peut simplement transmettre une demande à une équipe qui attribue manuellement un disque de capacité fixe. De même, un abonnement avec un quota fixe peut correspondre à un service cloud. La limite du forfait client et le modèle de ressources de la plateforme sont deux choses différentes.
| Configuration | Stockage distant ? | Stockage cloud ? | Explication |
|---|---|---|---|
| Serveur de fichiers au bureau accessible par VPN | Oui | Pas sur ce seul critère | Un VPN modifie l'accès, pas l'allocation des ressources ni la gestion de capacité. |
| NAS domestique avec une application d'accès à distance | Oui | Pas sur ce seul critère | L'accès à distance ne suffit pas à établir un modèle de service cloud. |
| Serveur loué de capacité fixe pour transférer des fichiers | Oui | Pas nécessairement | Un hébergement externe ne garantit ni libre-service, ni mutualisation, ni élasticité. |
| Service cloud de fichiers géré, comme Amazon EFS | Oui | Oui | Le service gère le stockage et ajuste la capacité selon les fichiers. |
| Cloud privé sur site proposant du stockage | Oui, depuis ses clients réseau | Oui, s'il fournit les caractéristiques du cloud | Une infrastructure cloud peut servir une seule organisation dans ses locaux. |
| Disque USB branché directement sur un ordinateur portable | Non, pour cet ordinateur | Non | Il s'agit de stockage directement connecté ; le partage ajoute un accès distant. |
Ces exemples classent le service décrit, pas tous les usages possibles du matériel. Un NAS peut fournir de la capacité à une plateforme cloud plus large. Une machine dédiée peut être mise à disposition par un service cloud. Examinez l'offre complète au lieu de considérer une catégorie de matériel comme décisive.
Le stockage cloud ne signifie pas toujours qu'un fournisseur tiers possède les serveurs. Le NIST précise qu'un cloud privé peut appartenir à l'organisation, à un tiers ou aux deux, être exploité par eux et se trouver sur site ou hors site.
La différence tient à la manière dont l'organisation fournit les ressources. Une plateforme interne qui donne à ses services un accès en libre-service à du stockage mutualisé peut suivre un modèle de cloud privé. Un serveur de fichiers administré manuellement ne devient pas un cloud privé simplement parce que seuls les salariés peuvent l'utiliser.
Distinguez aussi le cloud privé d'un accès privé à un service de cloud public. Limiter un compte de stockage à des utilisateurs autorisés ou à une connexion réseau privée ne transforme pas la plateforme du fournisseur en cloud privé. Le guide du cloud privé explique cette distinction.
Public, privé, communautaire et hybride désignent des modèles de déploiement. Fichier, bloc et objet désignent des façons d'organiser le stockage et d'y accéder. Ils répondent à des questions différentes ; notre guide des types de cloud computing sépare modèles de déploiement et modèles de service.
Ces quatre modèles décrivent qui utilise l'infrastructure et comment les clouds sont connectés. Ils ne déterminent pas si vos fichiers sont visibles par d'autres utilisateurs.
Les fournisseurs de stockage cloud public proposent des services ouverts à une clientèle générale. Les clients accèdent à une plateforme exploitée par un fournisseur au lieu de construire la leur. Un cloud public peut néanmoins garder privés les comptes individuels et leurs données.
Un cloud communautaire sert un groupe défini d'organisations partageant des préoccupations, comme une mission ou une politique de sécurité commune. Il ne s'agit pas simplement d'un service public dont les clients travaillent dans le même secteur.
Un cloud hybride relie des infrastructures cloud distinctes tout en préservant leur identité. Des clouds privés peuvent en faire partie. Utiliser plusieurs fournisseurs décrit autre chose : comptez les fournisseurs, puis examinez les connexions réelles entre les services.
Pour chacun de ces modèles, demandez à l'exploitant de préciser les limites entre les services. Le partage des données, la gestion des identités et la restauration nécessitent des dispositions explicites ; une appellation de déploiement ne les configure pas.
Le stockage cloud est souvent associé à un portail web ou à une API, mais les protocoles de fichiers traditionnels peuvent aussi faire partie d'un service cloud. Amazon EFS, documenté ici en anglais, est par exemple un stockage de fichiers élastique géré qui prend en charge NFS. Utiliser NFS n'en fait pas un serveur de fichiers de bureau classique.
L'inverse est également vrai. Ajouter une API à un serveur de stockage de capacité fixe n'apporte pas, à lui seul, mutualisation ou élasticité. L'interface indique comment une application communique avec le stockage, sans décrire tout son fonctionnement.
Un service cloud peut être atteint par une connexion réseau privée plutôt que par un point d'accès exposé publiquement. Un accès étendu par le réseau ne signifie pas que les fichiers sont publics. Pour les différences au niveau des applications, le guide des systèmes de fichiers cloud aborde les accès, l'architecture et les performances.
L'interface fait partie de l'architecture du stockage cloud. La présentation de Google Cloud, en anglais, distingue trois types courants : le stockage fichier organise les fichiers en dossiers ; le stockage objet conserve des objets avec identifiants et métadonnées, souvent pour des données non structurées ; le stockage bloc présente des volumes aux applications. Ils décrivent l'organisation et l'accès, pas la propriété. Vérifiez la compatibilité avec votre application avant de déplacer ses données.
Un stockage élastique conserve des limites. Les quotas du compte, les limites du service, le budget, la capacité régionale et les contraintes des applications peuvent freiner sa croissance. L'exploitant d'un cloud privé gère lui aussi du matériel en quantité finie. Demandez comment ajouter de la capacité, quelles limites nécessitent une demande et ce qui se passe lorsque le quota est épuisé.
Le cloud ne place pas automatiquement chaque fichier dans plusieurs régions géographiques. Les options de redondance d'Azure Storage illustrent cette différence : redondance locale, redondance de zone et réplication géographique couvrent des pannes différentes. La configuration choisie compte.
Demandez où se trouvent les données principales et leurs répliques, comment fonctionne le basculement et quelles écritures récentes pourraient être perdues lors d'une panne. Un engagement de durabilité et un engagement de disponibilité répondent à des questions différentes. Aucun ne précise à lui seul le délai de reprise de votre application.
La réplication peut reproduire une modification indésirable autant qu'une modification voulue. La synchronisation peut propager une suppression. Vérifiez l'historique des versions, la conservation, l'isolation des sauvegardes et la restauration séparément de l'emplacement du stockage. Pour la continuité d'activité, documentez la perte de données et l'interruption acceptables, puis testez ces limites. Notre guide de la synchronisation et de la sauvegarde cloud explique pourquoi des copies distantes ne sont pas automatiquement des sauvegardes indépendantes.
Un service de stockage géré peut réduire les tâches d'infrastructure tout en vous laissant des décisions importantes. Le modèle de responsabilité partagée d'AWS montre que les obligations varient selon le service : un client qui gère une machine virtuelle n'a pas les mêmes tâches qu'un utilisateur de stockage objet géré.
Pour chaque service, déterminez qui contrôle les accès, met à jour les logiciels, gère les réglages de chiffrement et assure la restauration. Comparez les responsabilités documentées et votre configuration réelle. Le guide de la sécurité cloud donne des repères pour ces vérifications.
Pour les données sensibles, renseignez-vous sur le chiffrement, l'accès aux clés, l'authentification et les autorisations de partage. Que peut lire un administrateur ? Qui peut rendre un fichier public ? Quelles protections pouvez-vous vérifier dans le compte ? Ces questions concernent aussi bien un serveur loué que les fournisseurs cloud.
Pour chaque service, reliez les données conservées aux personnes autorisées à les gérer. Une brochure publique et un dossier confidentiel exigent des règles d'accès différentes, même sur le même système de stockage. Testez les autorisations avec un compte utilisateur ordinaire, pas seulement avec un compte administrateur.
Un service cloud peut être utile lorsque les équipes ont besoin d'obtenir rapidement de la capacité sans exploiter le matériel sous-jacent. Un serveur de fichiers distant classique peut rester adapté à une charge stable disposant d'une équipe de support. La classification seule ne justifie pas une migration.
Commencez par l'application. A-t-elle besoin de fichiers partagés, d'une API objet ou d'un périphérique bloc ? Vérifiez ensuite les connexions utilisées, la latence acceptable et le volume à transférer. Un stockage accessible par un réseau local peut se comporter différemment de la même interface utilisée à longue distance.
Comparez les coûts totaux sur une période réaliste. Pour une infrastructure détenue en propre, incluez matériel, électricité, remplacement, maintenance et temps de travail. Pour les services hébergés, vérifiez les frais de capacité, de requêtes, de transfert, de récupération et de support lorsqu'ils s'appliquent. Une facture mensuelle ne prouve pas un modèle cloud, et ce modèle ne garantit pas un coût inférieur.
Pour l'accès quotidien aux fichiers, Store with Hivenet est une option de stockage cloud. Son guide de démarrage, en anglais, commence par un envoi suivi du téléchargement d'une copie distincte. Utilisez ce type de petit essai pour vérifier un usage réel ; ne supposez pas qu'une application de stockage grand public fournit les interfaces ou fonctions de restauration d'un service de stockage d'infrastructure.
Testez un dossier ou un jeu de données représentatif avant de dépendre du service. Ouvrez une copie récupérée et vérifiez son contenu. Conservez l'original jusqu'à la réussite de l'essai. Pour les données critiques, documentez le résultat et répétez le test de restauration après des changements importants. L'appellation aide à décrire une architecture ; le test montre si elle répond à vos besoins.
Faux. Le stockage distant décrit de manière large un accès par le réseau. Le cloud ajoute un modèle de service. Un serveur de fichiers ordinaire peut être distant sans présenter les caractéristiques du cloud.
Non. Louer de l'espace sur un serveur de capacité fixe établit un hébergement, pas nécessairement un service cloud. Examinez l'allocation des ressources, la mutualisation, l'élasticité et la mesure d'utilisation plutôt que la seule propriété du matériel.
Oui. Un cloud privé peut fonctionner sur site. Il doit toujours présenter les caractéristiques du cloud ; un simple partage réseau interne ne suffit pas.
Cela associe un stockage local et un service hors site. Cette configuration peut être utile, sans correspondre automatiquement à la définition du cloud hybride du NIST, qui implique des infrastructures cloud connectées. Décrivez les composants et le fonctionnement de la sauvegarde plutôt que de vous fier à l'appellation.
Choisissez une charge de travail d’IA, de calcul ou de stockage à tester sur Hivenet, ou échangez avec notre équipe sur sa mise en production.