Failover et Failback
generalDéfinition
Le failover (basculement) est le processus automatique ou manuel de transfert du trafic et des opérations d'un système principal défaillant vers un système de secours préalablement configuré. Le failback est l'opération inverse : le retour vers le système principal une fois qu'il a été restauré et validé. Ces deux opérations constituent le cœur de toute architecture de haute disponibilité et de reprise après sinistre. Le failover peut être déclenché de deux manières. Le failover automatique est déclenché par des mécanismes de détection (heartbeat monitoring, health checks) qui identifient une défaillance et initient le basculement sans intervention humaine — c'est l'approche pour les applications critiques où chaque seconde d'interruption compte. Le failover manuel nécessite une action humaine — préféré quand le risque de "split-brain" (deux systèmes qui pensent être le principal) est élevé, ou quand les conséquences d'un basculement non justifié sont importantes. Les architectures de failover se déclinent en plusieurs modèles. Actif-Passif : le nœud principal traite tout le trafic, le nœud passif est en veille et prend le relais en cas de défaillance. Actif-Actif : les deux nœuds traitent le trafic simultanément, chacun pouvant reprendre la charge de l'autre — pas d'interruption car le trafic est redistribué entre les nœuds opérationnels. Geographique : les systèmes sont répartis sur plusieurs sites distants (ou régions cloud) pour résister aux sinistres géographiques. Chaque modèle implique des compromis entre coût, performances, RPO/RTO, et complexité opérationnelle. Le failback est souvent plus risqué que le failover car il est réalisé en mode récupération, sans la pression immédiate d'urgence. Les risques du failback incluent : perte de données survenues pendant la période sur le site de secours si elles n'ont pas été répliquées vers le primaire, problèmes de synchronisation (qui est la source de vérité ?), et régression fonctionnelle (le primaire restauré correspond-il à l'état actuel des données ?). Un plan de failback détaillé, distinct du plan de failover, est indispensable. Dans les environnements cloud, les services managés incluent souvent le failover automatique : Amazon RDS Multi-AZ bascule en 60-120 secondes sur le standby en cas de panne de l'AZ, Azure SQL Database bascule automatiquement entre les répliques, et les régions AWS/Azure peuvent être utilisées pour un failover géographique via Route 53 ou Traffic Manager.
Clustering et High Availability pour le failover
Les clusters de haute disponibilité (HA clusters) implémentent le failover automatique pour les services critiques. Windows Server Failover Clustering (WSFC) et Pacemaker/Corosync sur Linux permettent de regrouper des serveurs en cluster — si un nœud tombe, les services migrent automatiquement sur les nœuds disponibles. SQL Server AlwaysOn Availability Groups utilise WSFC pour les bases de données avec réplication synchrone et failover automatique en < 30 secondes. La détection de la défaillance repose sur des heartbeats réseau et disk-witness (ou cloud witness) qui permettent au cluster de déterminer quel nœud est défaillant et d'éviter le split-brain où plusieurs nœuds se déclarent primaires.
DNS failover et load balancing géographique
Le failover géographique (disaster recovery avec basculement entre régions) utilise souvent le DNS comme mécanisme de routage. Route 53 (AWS), Azure Traffic Manager, et Cloudflare Load Balancing permettent de basculer le trafic DNS vers une région de secours en cas de défaillance de la région primaire. Les TTL courts (60 secondes ou moins) permettent une propagation rapide des changements DNS. Route 53 Health Checks surveillent en permanence la disponibilité des endpoints et déclenchent automatiquement le basculement DNS si les health checks échouent. Cette approche est particulièrement adaptée aux applications web où le DNS est le point d'entrée — mais attention : le failover DNS ne suffit pas si les données ne sont pas synchronisées vers la région de secours.
Plan de failback — retour au primaire
Le failback doit être aussi planifié que le failover. Les étapes incluent : (1) Validation que le système primaire est opérationnel et stable ; (2) Synchronisation des données depuis le système de secours vers le primaire (les données accumulées pendant la crise) ; (3) Test en environnement de staging ; (4) Planification d'une fenêtre de maintenance pour le failback (idéalement en heures creuses) ; (5) Communication aux utilisateurs de l'interruption planifiée ; (6) Exécution du failback avec monitoring intensif ; (7) Validation post-failback et retour à la surveillance normale. Les équipes qui planifient soigneusement leur failback sont souvent celles qui font les failovers les plus propres — elles ont une meilleure connaissance de leur architecture et de ses dépendances.
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.