Un hot site est un site de reprise entièrement équipé, avec matériel, logiciels, liaisons réseau et données à jour déjà en place, capable de prendre le relais de votre site principal en quelques minutes à quelques heures. C'est le type de site de reprise après sinistre le plus rapide et le plus coûteux. Dans le cloud, l'équivalent est une configuration en hot standby ou active/active dans une seconde région.
Points clés
- Le NIST décrit les hot sites comme des installations dimensionnées pour le système et configurées avec le matériel, l'infrastructure de support et le personnel nécessaires.
- Leurs données sont mises à jour en continu ou peu après le site principal : la perte de données est faible et la reprise rapide.
- Les warm sites contiennent une partie des équipements et demandent une préparation avant usage. Les cold sites ne fournissent que l'espace et l'alimentation électrique.
- Dans le vocabulaire AWS, cela correspond au « hot standby » (actif/passif à pleine capacité) ou au « multi-site active/active », la stratégie la plus complexe et la plus coûteuse.
- La réplication ne protège pas contre la corruption de données ni contre les rançongiciels. Vous avez toujours besoin de sauvegardes à un instant donné.
Qu'est-ce qu'un hot site en reprise après sinistre ?
C'est un site alternatif qui exécute déjà, ou peut exécuter immédiatement, une copie de vos systèmes de production. Quand le site principal tombe, vous redirigez les utilisateurs et vous continuez à travailler.
La référence américaine est le NIST SP 800-34, Contingency Planning Guide for Federal Information Systems. Il définit ce type de site comme disposant d'un équipement suffisant, du logiciel de production à jour et d'un stockage adapté, avec les dernières données sauvegardées chargées. Dans de nombreux cas, ses bases de données sont mises à jour en même temps que celles du site principal, ou peu après. Le NIST précise aussi que le site doit permettre de basculer rapidement la connectivité des utilisateurs, avec un support opérationnel proche de celui du site de production.
Un exemple du NIST : deux systèmes identiques, dans des lieux différents, tous deux en production, chacun capable d'assumer toute la charge, avec des données synchronisées en continu. Le NIST y voit l'option la plus coûteuse.
Hot site, warm site et cold site
Les trois types de sites diffèrent par ce qui est prêt avant le sinistre. Plus la préparation est avancée, plus la reprise est rapide et plus le coût d'exploitation est élevé.
| Caractéristique | Cold site | Warm site | Hot site |
|---|---|---|---|
| Ce qui est en place | Espace, alimentation, liaisons télécoms, contrôle de l'environnement | Une partie ou la totalité du matériel, des logiciels, des télécoms et de l'alimentation | Matériel complet, infrastructure de support et personnel |
| Données | Restaurées depuis une sauvegarde après l'incident | Restaurées ou partiellement répliquées | À jour ou quasi à jour, souvent répliquées en continu |
| Délai de mise en route | Long | Moyen | Court |
| Coût | Faible | Moyen | Moyen à élevé |
| Usage typique | Systèmes pouvant rester à l'arrêt plusieurs jours | Systèmes importants avec une certaine tolérance | Systèmes pour lesquels quelques minutes d'indisponibilité comptent |
Les lignes sur le délai de mise en route et le coût reprennent le tableau de critères de sites alternatifs donné en exemple par le NIST. Les délais de reprise réels dépendent de votre conception et de vos tests, pas de l'étiquette.
Comment fonctionne un hot site ?
Une configuration opérationnelle comprend quatre éléments qui doivent rester synchronisés avec la production :
- Infrastructure : serveurs, stockage et capacité réseau dimensionnés pour la charge que vous devez y exécuter.
- Réplication des données : copie synchrone ou asynchrone des bases de données et des fichiers depuis le site principal.
- Configuration et code : mêmes versions logicielles, mêmes correctifs et mêmes paramètres qu'en production, idéalement déployés à partir des mêmes modèles d'infrastructure as code.
- Bascule du trafic : modifications DNS, de répartiteur de charge ou de réseau qui dirigent les utilisateurs vers le site de reprise lorsque vous l'activez.
Que se passe-t-il lors de l'activation ?
L'activation est une décision, pas seulement une étape technique. Le responsable d'incident confirme que le site principal ne peut pas être rétabli dans le délai de reprise (RTO) convenu, puis l'équipe suit le runbook : arrêter les écritures sur le site principal si possible, promouvoir les bases de données répliquées, basculer le trafic, vérifier que les applications fonctionnent et informer les utilisateurs et les parties prenantes. AWS précise qu'il faut utiliser avec prudence le basculement automatique fondé sur des contrôles de santé, car une fausse alerte coûte en disponibilité et en données. De nombreuses équipes déclenchent donc le basculement manuellement, mais automatisent chaque étape derrière le bouton.
Hot sites dans le cloud : hot standby et active/active
Dans le cloud, on loue rarement un bâtiment distinct. On exécute plutôt une seconde copie de l'environnement dans une autre région ou une autre zone de disponibilité. Le livre blanc AWS sur la reprise après sinistre décrit quatre stratégies, de la moins chère à la plus complète :
| Stratégie AWS | Ce qui tourne dans la région de reprise | Type de site le plus proche |
|---|---|---|
| Backup and restore | Sauvegardes uniquement ; l'infrastructure est redéployée après l'incident | Cold site |
| Pilot light | Données répliquées et services essentiels actifs ; serveurs d'application éteints | Cold à warm |
| Warm standby | Une copie réduite mais pleinement fonctionnelle, capable d'absorber le trafic immédiatement | Warm site |
| Hot standby / multi-site active/active | Pleine capacité, soit en attente (actif/passif), soit au service des utilisateurs (active/active) | Hot site |
AWS qualifie le multi-site active/active d'approche la plus complexe et la plus coûteuse, mais indique qu'il peut ramener le temps de reprise proche de zéro pour la plupart des sinistres. AWS souligne aussi que la plupart des clients qui construisent un second environnement complet finissent par l'utiliser en active/active, puisqu'ils le paient de toute façon.
Une configuration cloud présente deux avantages par rapport à une configuration physique. Vous pouvez tester le basculement sans déplacer de personnel, et vous pouvez reconstruire tout l'environnement à partir du code en cas de dérive. La contrepartie : vous payez la pleine capacité à deux endroits, plus le transfert de données pour la réplication.
Un hot site vaut-il son coût ?
Seulement pour les systèmes dont le coût d'indisponibilité dépasse le coût d'exploitation d'un second environnement. Partez d'une analyse d'impact sur l'activité, définissez un RTO et un objectif de point de récupération (RPO) pour chaque système, puis choisissez le type de site en fonction de ces objectifs. Notre guide sur le RPO et le RTO explique comment les fixer.
Le NIST fait ici une remarque utile : un même système peut nécessiter des stratégies différentes selon les fonctions. Le traitement des commandes peut exiger un basculement instantané, tandis que le reporting mensuel de la même plateforme peut attendre plusieurs jours. Ce découpage en niveaux limite l'empreinte permanente et maintient la facture à un niveau raisonnable.
Checklist avant de construire un hot site
- Assez éloigné du site principal pour qu'un seul événement régional ne puisse pas toucher les deux.
- Capacité suffisante pour la charge critique, pas nécessairement pour tout.
- Décalage de réplication surveillé par rapport à votre RPO, avec des alertes.
- Sauvegardes à un instant donné conservées séparément, pour se rétablir après une corruption ou un rançongiciel que la réplication copierait.
- Mesures de sécurité équivalentes à celles de la production : identités, pare-feu, journalisation et chiffrement.
- Un runbook de basculement avec des responsables nommés, et un plan de retour à la normale.
- Tests de basculement réguliers, consignés dans votre plan de reprise après sinistre.
Comment Opsio vous accompagne
Opsio conçoit et exploite la reprise après sinistre dans le cloud sur AWS, Azure et Google Cloud, du pilot light aux configurations multirégions complètes, et teste le basculement avec votre équipe. Pour WorkBuster, une plateforme SaaS mondiale de recrutement, nous avons construit l'environnement AWS sur MySQL RDS Multi-AZ et de la mise à l'échelle automatique, avec des modèles CloudFormation permettant de redéployer l'infrastructure de manière cohérente ; consultez le cas WorkBuster.
Foire aux questions
Quelle est la différence entre un hot site et un cold site ?
Le premier dispose d'équipements, de logiciels et de données à jour, prêts à prendre le relais rapidement. Le second ne fournit que l'espace, l'alimentation et les connexions réseau : les systèmes doivent être installés et restaurés depuis une sauvegarde avant que le travail reprenne.
En combien de temps un hot site peut-il reprendre les opérations ?
En général de quelques minutes à quelques heures, selon l'actualité des données et le degré d'automatisation de la bascule. Une configuration cloud active/active peut ramener le temps de reprise proche de zéro pour la plupart des pannes, mais le rétablissement après une corruption de données dépend toujours des sauvegardes.
Un hot site est-il identique à un site miroir ?
Les deux notions sont proches. Un site miroir exécute une copie identique de la production, synchronisée en continu. L'exemple du NIST de deux systèmes de production identiques assumant chacun toute la charge est en pratique un site miroir.
Ai-je besoin d'un hot site si j'exploite mes systèmes dans le cloud ?
Pas automatiquement. Exécuter vos charges sur plusieurs zones de disponibilité protège déjà contre la perte d'un centre de données. Un hot standby dans une seconde région se justifie lorsque des pannes régionales, la réglementation ou les contrats imposent des délais de reprise très courts.
Que signifie « hotsite » en marketing ?
En marketing, notamment au Brésil, un « hotsite » est un petit site web temporaire dédié à une campagne ou à un lancement de produit. Il n'a aucun rapport avec la reprise après sinistre.
Rédigé par
Group COO & CISO
Fredrik est le COO et CISO du groupe chez Opsio. Il se concentre sur l'excellence opérationnelle, la gouvernance et la sécurité de l'information, travaillant en étroite collaboration avec les équipes de livraison et de direction pour aligner technologie, risque et résultats métier dans des environnements IT complexes. Il dirige la pratique sécurité d'Opsio, incluant les services SOC, les tests d'intrusion et les cadres de conformité.
Charte éditoriale : Cet article a été rédigé par le praticien du cloud cité ci-dessus. Nous le révisons lorsque la technologie ou la réglementation qu'il traite évolue ; les dates de cette page indiquent la dernière mise à jour. Opsio est éditorialement indépendant.