Stockage cloud ou stockage d’entreprise : où conserver vos données ?

Le stockage cloud et le stockage d’entreprise sont deux catégories qui se recoupent. Le stockage d’entreprise désigne des systèmes conçus pour répondre aux besoins d’une organisation. Ils peuvent fonctionner sur site, dans un cloud public ou privé, ou dans plusieurs environnements. Le stockage cloud décrit un mode de fourniture du service, sans réserver son usage à un type d’utilisateur.

La comparaison utile porte sur le stockage cloud géré par un fournisseur, le stockage que vous exploitez vous-même et une organisation hybride. Partez des usages : où fonctionnent les applications, comment accèdent-elles aux données, quels résultats la reprise doit-elle atteindre et qui gérera le système ? Un prix bas par téraoctet ne répond pas à ces questions.

Ce guide traite de ce choix de déploiement. Pour une présentation plus large des catégories de services, consultez notre guide du stockage cloud d’entreprise.

Que comparez-vous exactement ?

Distinguez trois décisions avant de demander des devis :

• L’emplacement : vos locaux, un centre de colocation, une région du fournisseur ou plusieurs de ces lieux.
• L’exploitation : votre équipe, un prestataire de services gérés ou un fournisseur cloud, avec des responsabilités clairement délimitées.
• L’interface d’accès : fichiers, blocs ou objets, selon les besoins de l’application.

Installer une baie de stockage dans vos locaux ne suffit pas à constituer un cloud privé. Dans la définition du cloud computing du NIST, un cloud privé sert une seule organisation. Celle-ci ou un tiers peut l’exploiter, sur site ou à distance. Des caractéristiques comme le libre-service et la mutualisation des ressources décrivent le fonctionnement du service, pas seulement l’emplacement du matériel.

De même, louer du matériel dédié ne signifie pas que le fournisseur gère vos sauvegardes ou vos applications. Définissez le service acheté avant de comparer son coût ou sa sécurité avec ceux d’une autre offre.

Stockage cloud et stockage sur site : comparaison pratique

Dans le tableau ci-dessous, le stockage « sur site » désigne une infrastructure exploitée par votre organisation. Un contrat de service géré ou une facturation à l’usage peut modifier la répartition du travail et le modèle de paiement.

Critère	Stockage cloud géré	Stockage sur site	Stockage hybride
Exploitation quotidienne	Le fournisseur exploite le service sous-jacent ; vous gérez les données et les contrôles qui vous incombent.	Votre équipe ou un prestataire exploite le matériel, les logiciels et les installations.	Les responsabilités couvrent les deux environnements et leur connexion.
Augmentation de capacité	Allocation dans les limites du service, des quotas et de la capacité disponible.	Utilisation de la capacité installée, puis achat et déploiement de ressources supplémentaires.	Extension là où la capacité et la compatibilité des applications le permettent.
Accès aux données	Dépend de l’interface du service et du chemin réseau depuis l’application.	Les applications locales peuvent utiliser le réseau local ; l’accès distant doit être conçu.	L’accès local et les copies distantes nécessitent des règles de synchronisation.
Coûts à prévoir	Frais récurrents, avec d’éventuels frais de requêtes, de récupération et de transfert.	Matériel, support, personnel, installations, renouvellement et infrastructure de reprise.	Les deux ensembles de coûts, plus l’intégration et les capacités dupliquées.
Reprise	Choisir et configurer la protection ; démontrer la reprise de l’application.	Concevoir et exploiter les sauvegardes, la capacité de reprise et les procédures.	Valider la reprise entre environnements, y compris les identités et la connectivité.
Contrainte principale	Limites du fournisseur, fonctionnement du service et dépendance au chemin d’accès.	Capacité interne d’exploitation, approvisionnement et risques de panne locale.	Coordination, cohérence des données et coût de deux environnements.

Aucun de ces modèles ne garantit à lui seul un coût inférieur, une meilleure sécurité ou une interruption plus courte. Comparez une architecture précise à des exigences communes.

Choisir le type de stockage avant le déploiement

AWS distingue le stockage de fichiers, de blocs et d’objets. Ces interfaces comptent, car une application ne prend pas nécessairement en charge les trois.

Type	Accès des applications	Usage courant
Fichiers	Fichiers et répertoires accessibles par un système de fichiers ou un protocole réseau.	Dossiers partagés et applications qui utilisent des chemins de fichiers.
Blocs	Volumes de stockage présentés à un système.	Disques de machines virtuelles et applications nécessitant un accès à des volumes.
Objets	Objets accessibles par une API, avec leurs métadonnées.	Dépôts de médias, destinations de sauvegarde et données applicatives conçues pour cet accès.

Une application de documents partagés ajoute une autre couche. La coédition, le partage par lien et un historique de versions accessible aux utilisateurs sont des fonctions applicatives. Tous les services de stockage ne les proposent pas. Un stockage objet ne doit pas être évalué comme un espace collaboratif complet.

Pour les applications utilisant des fichiers, vérifiez les protocoles, les droits, le verrouillage et le comportement lorsque plusieurs utilisateurs modifient les données. Notre guide des systèmes de fichiers dans le cloud aborde ces questions d’architecture et de performance.

Comparer le coût complet sur une même période

Construisez le calcul autour d’un usage et d’une période définis. Retenez la même capacité utile, la même protection, les mêmes performances, les mêmes horaires de support et les mêmes exigences de reprise pour chaque option. Comparer un disque sans protection à un service géré avec réplication donne un résultat trompeur.

Ce qu’il faut compter pour le cloud

Incluez la capacité stockée, les performances provisionnées si nécessaire, les requêtes API, la récupération de données, les transferts, les sauvegardes, la supervision, le support et l’administration. Vérifiez les engagements minimaux et le coût de sortie. Un abonnement fixe et un stockage objet facturé à l’usage ne suivent pas la même logique tarifaire.

La documentation tarifaire d’Amazon S3 montre pourquoi la capacité ne suffit pas : les requêtes et la récupération peuvent être facturées, et certaines classes appliquent une taille ou une durée minimale de facturation. Utilisez les tarifs en vigueur pour la région et la classe choisies.

Pour les données rarement consultées, une classe moins chère peut imposer un délai de récupération plus long ou des frais supplémentaires. Testez l’usage prévu et un scénario défavorable, comme la restauration d’une archive volumineuse pendant un incident.

Ce qu’il faut compter pour le stockage sur site

Comptez le matériel, les licences, la maintenance, les pièces de rechange, le réseau, l’électricité, le refroidissement, l’espace en baie, le temps de travail et le remplacement futur. Incluez la capacité nécessaire à la protection et à la croissance. Un système déjà installé peut encore exiger des dépenses lorsque le support prend fin ou que les besoins de reprise évoluent.

Le matériel existant modifie le calcul, mais son prix d’achat initial ne doit pas masquer les coûts futurs. Notez sa durée d’utilisation restante, sa couverture de support, sa capacité libre et le travail nécessaire à son exploitation. Le stockage local peut être économique pour un usage adapté sans être gratuit.

Utiliser des scénarios plutôt qu’un seuil universel

Aucune règle universelle ne permet d’affirmer que le cloud devient plus cher au-delà d’un certain nombre de téraoctets. Les accès aux données, les fonctions du service, les effectifs et l’architecture de reprise peuvent changer le résultat.

Prenons un exercice de planification : une organisation possède 100 To de données, dont 20 To sont fréquemment utilisés. Comparez au moins trois architectures : toutes les données dans un service cloud correctement configuré ; toutes les données sur une infrastructure locale avec des copies de reprise indépendantes ; et une organisation hybride avec un ensemble de travail local de 20 To. Ces volumes sont hypothétiques, pas des tailles recommandées.

Dans le cas hybride, précisez si ces 20 To restent également dans le cloud. Si oui, comptez les deux copies. Ajoutez les transferts de données modifiées et le temps nécessaire pour reconstituer l’ensemble de travail local après une panne.

Mesurer les performances depuis l’application

La distance physique compte, mais affirmer que le stockage local est toujours plus rapide serait excessif. Une baie locale saturée peut être lente, tandis qu’une application proche de son stockage cloud peut éviter un aller-retour depuis les bureaux. Le chemin complet comprend le client, le réseau, le service et le comportement de l’application.

Les recommandations de performance d’AWS soulignent l’importance d’adapter le stockage aux modes d’accès. Traduisez cela en mesures correspondant au travail réel :

• Latence : temps de réponse des opérations attendues par les utilisateurs ou les applications, en examinant aussi les requêtes lentes plutôt que la seule moyenne.
• IOPS : nombre d’opérations d’entrée-sortie par seconde, avec une taille de requête et une répartition lecture-écriture représentatives.
• Débit : quantité de données transférée par seconde dans des conditions réalistes d’accès simultanés.
• Opérations sur les métadonnées : ouverture, énumération, création et suppression lorsque le travail implique de nombreux petits fichiers.
• Durée du traitement : temps nécessaire à une importation, une analyse, un rendu ou une restauration représentative.

Effectuez le test depuis l’emplacement où fonctionnera l’application. Incluez les pics d’accès simultanés, un jeu de données plus grand que le cache si cela est pertinent, et une interruption de connexion. Une copie séquentielle rapide ne prouve pas qu’une base de données respectera son délai de réponse.

Le stockage sur site ne permet de travailler pendant une coupure Internet que si ses autres dépendances fonctionnent encore. Vérifiez l’authentification, la résolution de noms, les licences applicatives et les composants hébergés dans le cloud. À l’inverse, l’accès au cloud ne passe pas toujours par l’Internet public : une connexion privée ajoute ses propres coûts et contraintes d’exploitation.

La sécurité dépend des contrôles et des responsabilités

Avec un stockage cloud géré, le fournisseur prend en charge certaines parties de l’infrastructure. Votre organisation doit toujours maîtriser les accès aux données et leur utilisation. Les recommandations de Microsoft sur la responsabilité partagée maintiennent des responsabilités client concernant les données, les identités et les paramètres sous son contrôle dans les différents modèles de services cloud.

Pour un exemple précis, AWS détaille les responsabilités pour S3 : AWS exploite l’infrastructure et la plateforme, tandis que le client gère ses données, ses choix de chiffrement et ses autorisations. Le contrat et la documentation du service déterminent cette répartition.

Sur site, l’accès direct au matériel vous donne davantage de décisions à prendre. Quelqu’un doit aussi gérer les correctifs, la protection physique, la segmentation réseau, la supervision et la reprise. Posséder le matériel ne prouve pas l’efficacité de ces mesures.

Évaluez les données sensibles avec une liste de critères écrite : intégration des identités, moindre privilège, chiffrement en transit et au repos, gestion des clés, journaux d’audit, localisation des données, conservation et réponse aux incidents. Vérifiez les fonctions incluses dans le service et l’offre retenus. Une certification du fournisseur ne suffit pas à établir la conformité de votre usage.

Pour les vérifications opérationnelles des droits et du partage, consultez notre guide de sécurité du stockage cloud. Appliquez une attention comparable au stockage local et aux comptes d’administration qui le contrôlent.

Concevoir la reprise avant de choisir le stockage

Définissez deux exigences avec les personnes qui utilisent les données. Le RPO, ou objectif de point de reprise, exprime la perte de données acceptable, généralement sous forme de durée. Le RTO, ou objectif de délai de reprise, est le temps acceptable pour rétablir le service. Une exigence de restauration en une heure doit être étayée par un test.

Microsoft distingue la réplication de la sauvegarde : la réplication peut transmettre des modifications indésirables aux autres copies. Conserver une version antérieure intacte exige une protection adaptée. La redondance seule ne prouve pas que des données supprimées ou corrompues pourront être récupérées.

Le choix des emplacements a également des conséquences. Azure Storage documente la réplication asynchrone entre régions pour ses options géoredondantes : la copie secondaire peut être en retard sur la principale. Configurez la protection selon la panne à surmonter, sans assimiler tout service répliqué à un stockage sans perte de données.

Pour chaque architecture envisagée, identifiez la source de reprise, les personnes autorisées à l’utiliser et les systèmes nécessaires au retour à un fonctionnement normal. Prévoyez le cas d’un compte administrateur compromis ou d’un site entièrement indisponible. La reprise d’un système sur site peut utiliser des services cloud ; elle n’exige pas toujours de posséder un second centre de données.

Une restauration représentative doit mesurer l’intégrité des données et le fonctionnement de l’application, en plus du temps écoulé. Notre guide des tests de récupérabilité explique comment obtenir des preuves au-delà d’une notification de sauvegarde réussie.

Quand le stockage hybride est utile

Le stockage hybride peut conserver les données actives près des applications locales et placer une archive ou une copie de reprise ailleurs. Il peut aussi permettre une migration progressive lorsque déplacer toutes les applications en une fois serait trop perturbant.

Cette séparation nécessite des règles explicites. Déterminez quelle copie fait autorité, comment les changements circulent, ce qui se passe pendant une déconnexion et comment résoudre les conflits. Un cache peut ne contenir que les fichiers récemment utilisés : une présence locale ne prouve donc pas que l’ensemble des données est accessible hors ligne.

Budgétez les deux environnements jusqu’à la mise hors service effective d’un système. Attribuez les responsabilités pour la passerelle, la synchronisation, le réseau et l’intégration des identités. Notre guide du stockage cloud hybride présente plus largement ces architectures.

Partir des usages, puis mener un pilote

Ces exemples servent de points de départ à l’évaluation, pas de recommandations automatiques :

Usage	Option à étudier	Test décisif
Équipe répartie partageant des documents	Service géré de fichiers d’équipe avec des contrôles d’identité et de reprise adaptés.	Droits, collaboration, exportation et récupération avec de vrais utilisateurs.
Système de production local avec des délais stricts	Stockage local ou application et stockage cloud placés à proximité de manière réfléchie.	Latence de bout en bout et fonctionnement lors de pannes des dépendances.
Archive applicative en croissance	Stockage objet avec un plan de conservation et de récupération.	Délai et coût d’une récupération au volume représentatif d’un incident.
Application locale existante nécessitant une reprise hors site	Sauvegarde ou réplication hybride adaptée aux RPO et RTO.	Rétablissement de l’application lorsque le site d’origine est indisponible.

Donnez au pilote des critères écrits de réussite et d’échec. Précisez l’interface, la capacité utile, la croissance prévue, les modes d’accès, les emplacements autorisés, le délai de réponse, les RPO et RTO ainsi que le responsable de l’exploitation. Fixez un budget pour le fonctionnement normal et pour un incident nécessitant une reprise.

Migrez ensuite un échantillon représentatif. Vérifiez les droits et l’intégrité, exécutez le travail réel, restaurez des données de test supprimées ou modifiées, puis exportez de nouveau l’échantillon. Gardez une possibilité de retour en arrière jusqu’à ce que les résultats respectent les exigences convenues. Choisissez la solution qui réussit ces tests pour un coût complet acceptable.

Questions fréquentes

Le stockage cloud d’entreprise diffère-t-il du stockage personnel ?

Les offres d’entreprise sont évaluées selon des besoins organisationnels : gestion centralisée des identités, administration, audit, support et reprise. Cette appellation ne garantit pas toutes les fonctions. Vérifiez le service, l’offre, le contrat et les intégrations prises en charge, sans supposer qu’un compte personnel devient adapté à l’entreprise parce qu’il offre davantage de capacité.

Le cloud ou le stockage sur site est-il plus sûr ?

Comparez les contrôles réellement mis en place et la capacité de l’équipe à les exploiter. Un fournisseur géré peut assurer un travail d’infrastructure difficile à maintenir en interne, tandis qu’un déploiement local peut répondre à une exigence opérationnelle ou de localisation particulière. Aucun emplacement ne supprime le besoin de contrôle d’accès, de supervision, de mises à jour et de reprise testée.

Le stockage cloud dispense-t-il de sauvegardes ?

Non. Évaluez la redondance, l’historique de versions, la récupération après suppression, la conservation et la protection contre les comptes compromis. Déterminez si ces fonctions répondent aux exigences de reprise ou s’il faut une sauvegarde indépendante supplémentaire. Vérifiez le résultat par une restauration.

Quels sont les principaux inconvénients du stockage d’entreprise sur site ?

Votre organisation doit prévoir la capacité, la maintenance, le support, les installations et la reprise. L’extension et le remplacement peuvent prendre du temps. Une panne de site peut toucher simultanément le stockage et ses dépendances. Mettez ces coûts et obligations en regard des besoins d’accès local et de maîtrise directe de l’exploitation.