Hot Site / Warm Site / Cold Site
generalDéfinition
Les termes Hot Site, Warm Site et Cold Site désignent les trois niveaux de préparation d'un site de reprise d'activité (site de secours), classés selon la rapidité avec laquelle ils peuvent prendre en charge les opérations en cas de sinistre affectant le site principal. Chaque niveau représente un compromis entre le coût de préparation et le délai de reprise (RTO). Un Hot Site (site chaud) est une installation complètement opérationnelle, miroir du site principal, avec les mêmes systèmes démarrés et les données répliquées en temps réel. Les serveurs sont sous tension, les applications en cours d'exécution, et les utilisateurs peuvent basculer en quelques minutes. C'est la solution la plus coûteuse (le site de secours fonctionne en permanence) mais offre le RTO le plus court (< 15 minutes). Les architectures actif-actif distribuées géographiquement sont le hot site moderne, où les deux sites traitent le trafic simultanément. Un Warm Site (site tiède) est un site pré-équipé avec du matériel installé et connecté, mais les systèmes ne sont pas nécessairement démarrés et les données peuvent être en retard sur le site principal (réplication asynchrone). Le basculement nécessite quelques heures (démarrage des systèmes, synchronisation des données, reconfiguration DNS). C'est la solution intermédiaire : moins coûteuse qu'un hot site (les serveurs consomment moins en mode standby) avec un RTO de quelques heures. Un Cold Site (site froid) est un local équipé en termes d'alimentation électrique, climatisation, et connectivité réseau, mais sans serveurs ni données. En cas de sinistre, il faut installer le matériel (livré par les fournisseurs ou provenant du stock), restaurer les données depuis les sauvegardes, et reconfigurer tous les systèmes. Le RTO est de plusieurs jours. C'est la solution la moins coûteuse mais la moins réactive. Avec la généralisation du cloud public, la distinction Hot/Warm/Cold a évolué. Le cloud offre une quatrième approche : Pilot Light (infrastructure minimale maintenue dans le cloud — DNS, bases de données en veille, configuration prête) ou Cloud Warm/Hot Site (environnement cloud entier préconfiguré, activé uniquement en cas de sinistre via infrastructure-as-code). AWS Elastic Disaster Recovery, Azure Site Recovery, et Google Cloud Disaster Recovery permettent de mettre en place des sites de secours cloud avec des RTO de minutes à quelques heures.
Cloud Disaster Recovery — évolution du hot/warm/cold site
Le cloud a transformé les stratégies de reprise après sinistre. AWS Elastic Disaster Recovery (DRS) réplique en continu les serveurs physiques ou virtuels vers des "staging area" EC2 à faible coût — le RPO est de secondes. En cas de sinistre, les serveurs sont lancés en quelques minutes sur EC2. Sans incident, le coût est minimal (stockage EBS uniquement). Azure Site Recovery fonctionne de manière similaire pour les VMs Hyper-V, VMware et Azure. Cette approche "Warm Site cloud" combine les avantages du warm site (RTO court) avec la flexibilité et l'économie du cloud (pas de matériel à acheter et maintenir). Le warm site cloud remplace progressivement les warm sites physiques dans les stratégies modernes.
Stratégie de reprise multi-cloud
Pour les organisations qui veulent éviter la dépendance à un seul cloud provider, les architectures multi-cloud DR sont émergentes. La stratégie de base : production sur AWS, reprise sur Azure (ou vice versa). Les défis sont réels : formats différents des VMs, services incompatibles, coûts de transfer de données entre providers, et complexité de gestion. Des solutions comme Zerto, Carbonite Recover, ou Veeam Cloud Connect permettent la réplication cross-cloud. Terraform facilite la définition d'infrastructure-as-code déployable sur plusieurs clouds. Cependant, la plupart des organisations privilégient le multi-régions intra-provider (plus simple) au multi-cloud pour la DR, sauf pour les contraintes réglementaires spécifiques qui exigent l'indépendance du provider.
Test annuel du site de secours — DRTest
Un site de secours non testé est inutile en cas de sinistre réel. Les tests de DRP (Disaster Recovery Plan) doivent être annuels au minimum, et idéalement semestriels pour les systèmes critiques. Les types de tests sont progressifs : Component Test (test d'un composant isolé — restauration d'un serveur), Integration Test (basculement d'une application complète), Full Scale Test (basculement de tous les systèmes critiques vers le site de secours, opérations réelles depuis le site de secours pendant quelques heures), et Surprise Test (sans préavis pour tester la réactivité réelle des équipes). PCI-DSS exige des tests de DRP annuels documentés. ISO 22301 exige des tests à une fréquence cohérente avec les risques identifiés.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.