Sommaire
Ce qui compte en 2026
Le bon stockage n'est pas celui qui promet la plus grande capacité. C'est celui qui respecte les besoins réels de disponibilité, de récupération, de sécurité, de performance et de coût. Avant de choisir un fournisseur, une PME doit donc classer ses données, identifier les dépendances de ses applications et décider combien de données elle peut perdre et combien de temps elle peut rester arrêtée.
Les objectifs RPO et RTO rendent cette discussion concrète. Le RPO définit la quantité de données qu'une organisation accepte de perdre; le RTO fixe le délai maximal pour remettre le service en fonction. Ces deux valeurs doivent être décidées par les responsables des opérations, puis traduites en réplication, sauvegardes et procédures de reprise.
Objet, blocs, fichiers ou base de données
- Le stockage objet convient aux médias, aux documents, aux archives et aux volumes qui doivent croître facilement.
- Le stockage par blocs répond aux charges qui exigent une latence prévisible, notamment certaines bases de données et machines virtuelles.
- Le stockage de fichiers reste utile pour les répertoires partagés et les outils qui attendent une arborescence classique.
- Une base de données gérée convient aux données transactionnelles, mais ne remplace ni l'archivage ni une stratégie de sauvegarde.
Le choix peut être hybride. Une application web sur mesure utilise souvent une base transactionnelle, du stockage objet pour les pièces jointes et une couche de cache. L'architecture doit préciser où se trouve la copie de référence et comment chaque composant est restauré.
Une sauvegarde n'est utile que si elle est restaurable
Automatiser une copie ne suffit pas. Il faut isoler au moins une copie des accès de production, chiffrer les données sensibles, surveiller les échecs et effectuer des restaurations périodiques. Le cadre de fiabilité AWS recommande explicitement d'automatiser les sauvegardes, de les sécuriser et de vérifier leur intégrité par des restaurations. Le NIST rappelle aussi que les erreurs humaines et les événements destructeurs menacent autant l'intégrité que la disponibilité.
Un test de reprise doit produire une preuve : date, durée, volume restauré, écarts observés et responsable de la correction. Sans ce test, le RTO reste une hypothèse.
Checklist de décision
- 1Inventorier les données, leur propriétaire et leur niveau de sensibilité.
- 2Définir RPO et RTO pour chaque processus critique.
- 3Choisir le modèle de stockage selon les accès, pas selon la mode.
- 4Séparer les droits d'administration, de lecture et de sauvegarde.
- 5Chiffrer les données en transit et au repos lorsque le risque l'exige.
- 6Tester une restauration complète et documenter le résultat.
- 7Mesurer le coût total : capacité, requêtes, transfert, réplication et exploitation.
À retenir
Une architecture de données robuste combine des choix techniques simples, une responsabilité claire et des exercices de reprise. La résilience vient moins du nombre de copies que de la capacité démontrée à récupérer la bonne donnée, dans le délai convenu.
Sources
- AWS Well-Architected — Reliability Pillar
- NIST SP 1800-11 — Recovering from ransomware and destructive events
- NIST IR 8374 Rev. 1 — Ransomware Risk Management
D
Rédigé par
DAILLAC
