Deux connexions Internet : comment assurer le failover d’une entreprise ou d’un hôtel ?

Une seule fibre optique peut suffire pour un usage ordinaire, mais dans un hôtel connecté ou une entreprise, une coupure Internet perturbe potentiellement les réservations, les paiements, la téléphonie, les échanges avec le cloud et le Wi-Fi des clients. Mettre deux abonnements dans la même baie ne garantit pourtant pas une continuité réelle. Le failover Internet entreprise hôtel doit être pensé comme une chaîne complète : diversité des accès, détection des pannes, routeur, règles de bascule, alimentation, supervision et essais de reprise.

Photo by imgix on Unsplash

Synthèse pour décideur (ce qui compte vraiment)

• Objectif : maintenir les services essentiels (réservations/PMS, paiement, réception/VoIP, support) selon des priorités décidées métier.
• Risque principal : deux abonnements peuvent partager des dépendances (trajet physique, point de mutualisation, local technique) ; le « double WAN » n’est pas automatiquement redondant.
• Décision d’architecture : multi-WAN « simple » (bascule) vs SD-WAN (pilotage plus fin) ; le bon choix dépend des applications, du support et du niveau de service attendu.
• Succès mesurable : une recette (tests) et un runbook d’exploitation, pas une promesse de « zéro coupure ».

Définir ce qui doit rester disponible

Commencez par classer les usages de l’entreprise : PMS (Property Management System) et gestion des réservations, terminaux de paiement, réception, téléphonie IP, outils des équipes, accès distants de maintenance et Wi-Fi des clients. Certains services doivent retrouver rapidement Internet ; d’autres peuvent accepter une interruption temporaire ou passer en mode local.

Cette hiérarchisation évite de faire basculer l’intégralité d’un Wi-Fi invité très chargé sur une liaison de secours mobile limitée au détriment de la réception. Elle se construit avec l’exploitant, pas uniquement avec l’administrateur réseau. Notre guide sur les familles de réseaux IP d’un hôtel explique les besoins propres à chaque service.

Deux abonnements ne signifient pas deux chemins indépendants

Une fibre principale et une fibre secondaire de deux opérateurs peuvent parfois suivre des dépendances communes (fourreaux, points de mutualisation, locaux techniques, énergie). Une coupure physique unique peut alors interrompre les deux abonnements. Le projet doit examiner la diversité réelle des chemins et, quand c’est pertinent, utiliser un lien mobile 4G/5G ou une autre technologie comme secours.

Cette prudence est particulièrement importante dans les environnements où les accès fixes s’appuient sur des points d’accès et des modalités d’interconnexion/partage d’infrastructures : cela crée des dépendances possibles qu’il faut identifier au cas par cas (ANRT — Décision n°10/14 ; ANRT — Décision n°19/14).

La seconde liaison doit être dimensionnée selon les usages essentiels, la qualité de couverture disponible et les conditions de service. Les mesures doivent être effectuées sur site, en particulier si l’antenne du modem est placée dans un local fermé ou une baie métallique.

Contexte Maroc : hypothèses à vérifier (contrat + tests sur site)

Les points ci-dessous sont des situations fréquentes en projets, mais variables selon l’opérateur, l’offre, les options souscrites et le site. Ils doivent être vérifiés dans les documents contractuels, puis confirmés par mesures sur site et tests de recette.

• Diversité de chemin : ne pas présumer l’indépendance physique de deux accès. Formaliser (quand c’est possible contractuellement) les informations de cheminement, et documenter les dépendances identifiées. Le cadre de régulation met en évidence l’existence de points d’accès et d’interconnexion possibles, sans permettre de conclure sur un cas particulier (ANRT — Décision n°10/14 ; ANRT — Décision n°19/14).
• Qualité 4G/5G hétérogène : les performances et la stabilité varient selon la zone, l’épaisseur des murs, la position des antennes et la charge aux heures de pointe. Une campagne de tests à plusieurs moments de la journée est souvent déterminante.
• CGNAT possible sur liens mobiles : certains accès 4G/5G peuvent être derrière un partage d’adresses (CGNAT, Carrier-Grade NAT), ce qui peut limiter les services entrants (accès à distance, certains VPN, redirections de ports). C’est un mécanisme courant sur mobile ; il faut le valider explicitement auprès de l’opérateur pour l’offre retenue (explication générique du mécanisme : Transacom — FAQ CGNAT).
• Options « IP fixe » / offres business : selon les usages (VPN site-à-site, accès entrant, interconnexion), une option d’IP fixe ou un APN/option entreprise peut être proposée… ou non. Exemple public à date : une offre 4G business mentionnant une option IP fixe existe chez Orange Maroc Pro (Orange Maroc Pro — Business Box 4G). D’autres opérateurs/offres peuvent différer : à confirmer au devis/contrat.
• Latence vers des clouds hors Maroc : pour des applications hébergées à l’international, la latence et la stabilité du chemin peuvent impacter VoIP, visioconférence et certaines applications métier ; le lien de secours doit être évalué aussi sur ces critères.

Questions à poser à l’opérateur (checklist)

• L’accès est-il derrière CGNAT ? Si oui, existe-t-il une option (IP publique, APN entreprise, etc.) ?
• L’offre fournit-elle une IP publique fixe ou variable ? IPv6 est-il disponible et exploitable dans votre contexte ?
• Quels sont les engagements de service (SLA) et les modalités de support : horaires, escalade, temps d’intervention (GTR/équivalent contractuel) ?
• En cas de double accès : l’opérateur peut-il fournir (contractuellement) des éléments sur la diversité de parcours ?

Détecter une vraie panne : routeur multi-WAN et sondes de santé

Un port Internet qui reste physiquement actif ne prouve pas que le trafic atteint les services métier. Une défaillance DNS, une route opérateur interrompue ou un portail de connexion inattendu peuvent laisser la liaison « up » sans accès réellement utilisable. Le routeur ou pare-feu doit disposer de sondes de santé représentatives ; la décision de bascule ne doit pas dépendre d’un seul ping vers un site extérieur.

Concrètement, pour chaque WAN, documenter l’adressage, les sorties NAT (Network Address Translation), le DNS, les routes, les tunnels VPN et les éventuels services accessibles depuis Internet. Prévoir plusieurs cibles représentatives (par exemple DNS + HTTP/HTTPS sur une cible métier), les intervalles de test, des seuils d’échec et de rétablissement évitant les oscillations (flapping), et une notification à l’équipe de maintenance. Les règles de filtrage et de segmentation doivent rester effectives sur les deux accès.

Failover et load balancing : deux objectifs différents

Le failover maintient un service au moyen d’une liaison secondaire si la liaison active est jugée défaillante. Le load balancing répartit des sessions entre plusieurs accès pour répartir la charge. Les deux fonctions peuvent coexister, mais elles ne répondent pas au même besoin.

Une entreprise peut ainsi réserver l’accès principal aux usages métier, puis activer le secours uniquement lors d’une panne. Dans certains projets, une approche SD-WAN (Software-Defined Wide Area Network) peut améliorer la sélection des chemins et la visibilité applicative, sous réserve des performances du matériel, des opérateurs, des licences et du contrat.

NAT, sessions TCP, VPN : ce que la bascule peut interrompre

Avec deux abonnements Internet classiques, le second accès dispose souvent d’une autre adresse IP publique. Lors d’une bascule, les communications établies sur la première liaison peuvent perdre leur chemin ou leur traduction NAT et nécessiter une reconnexion. La détection d’une panne et le rétablissement de l’accès Internet ne garantissent donc pas la préservation de chaque session applicative : appels VoIP, paiements en cours, VPN, logiciels cloud et connexions entrantes doivent être testés séparément.

Point d’attention : « conserver la même IP » n’est pas le cas général

Certaines architectures avancées peuvent viser une continuité plus transparente (par exemple via des options opérateur spécifiques ou du multi-homing), mais cela ne correspond généralement pas à deux abonnements standard (grand public/PME) posés en parallèle. Si le projet a cet objectif, il faut le traiter explicitement comme un besoin d’architecture et de contrat, avec des compétences réseau adaptées, plutôt que de le supposer possible.

Attention sur les liens mobiles : si la liaison de secours 4G/5G est en CGNAT, certains VPN ou accès entrants peuvent être impossibles ou nécessiter une architecture différente (à valider avec l’opérateur et l’équipe sécurité). Il faut l’intégrer au design dès le départ, plutôt que de le découvrir pendant l’incident (mécanisme CGNAT : Transacom — FAQ).

Pour un hôtel, vérifier en particulier le parcours réservation/PMS, la téléphonie de la réception, les terminaux de paiement, le télétravail et les VPN de support. Lors du retour du lien principal, définir si les flux établis restent sur le secours jusqu’à leur fin ou sont transférés immédiatement ; le choix doit réduire les interruptions, sans compromettre la sécurité ni bloquer durablement les services.

Les applications doivent pouvoir gérer les échecs de manière claire pour les équipes. Un paiement interrompu ne doit pas être relancé aveuglément sans contrôler son statut ; une conversation VoIP peut nécessiter un nouvel appel, même si Internet fonctionne de nouveau. Le guide Domocasa sur la téléphonie IP hôtelière identifie les fonctions à recetter.

Dimensionnement du lien de secours (critères décisionnels)

Le lien de secours n’a pas besoin d’offrir le même débit que le principal, mais il doit être cohérent avec les services à maintenir. Une méthode praticable consiste à dimensionner par catégories (métier, VoIP, accès distant, Wi‑Fi invité), puis à valider par des essais.

• Débit montant (upload) : souvent plus critique que le download pour VoIP, VPN, sauvegardes et certains usages cloud. En secours mobile, l’upload peut être très variable.
• Latence / gigue (jitter) / pertes : déterminants pour la VoIP et la visioconférence. Une liaison « rapide » mais instable peut dégrader la qualité.
• Quota/consommation de données : prévoir une politique de limitation (Wi‑Fi invité, mises à jour, sauvegardes lourdes) pour éviter une saturation ou un dépassement.
• Priorisation (QoS, Quality of Service) : définir ce qui est prioritaire en mode secours (ex. PMS/TPV, VoIP réception) et ce qui est plafonné ou suspendu (ex. streaming client).
• Tests à différentes heures : illustrativement, mesurer en journée, soirée et week-end peut révéler des congestions ; ces essais servent à valider les seuils et politiques.

Les seuils chiffrés (débit minimal, latence maximale, etc.) doivent être fixés au cas par cas, en fonction des applications, du nombre de postes et du périmètre de services à maintenir.

Ne pas oublier l’alimentation et le réseau local

Un modem de secours ne sert à rien si l’onduleur (UPS, Uninterruptible Power Supply) n’alimente que le routeur mais pas le switch reliant la réception. Listez ONT, routeurs, pare-feu, switches essentiels, serveurs de gestion et éventuel modem cellulaire ; définissez une autonomie réaliste.

La segmentation LAN doit rester identique quand le WAN bascule, sans ouvrir de flux entre Wi-Fi invité et réseau métier. Les règles de sécurité appliquées à Internet et aux VPN doivent être revues pour les deux accès. Notre article sur les VLAN et la séparation des réseaux détaille ce point.

Ce que le failover Internet ne résout pas (SPOF à traiter)

Le failover WAN réduit le risque lié à l’accès Internet, mais ne couvre pas automatiquement les Single Points of Failure (SPOF) internes ou amont. Selon l’architecture, il peut être nécessaire d’intégrer aussi :

• Alimentation : UPS sous-dimensionnés, PDU non secourus, absence de redondance sur les alimentations des équipements critiques.
• Cœur LAN : switch de distribution/cœur unique, liens montants uniques vers la réception ou la salle serveurs.
• Services réseau internes : DNS interne, DHCP, contrôleur Wi‑Fi, authentification (RADIUS/AD selon cas). Une panne locale peut ressembler à une panne Internet.
• VoIP : IPBX/SIP trunk (trunk SIP), routeur voix, dépendances du fournisseur (à recetter).
• Fournisseurs externes : indisponibilité du prestataire PMS, passerelles de paiement, services cloud ; un secours WAN ne répare pas une panne côté fournisseur.

Ces points relèvent du plan de continuité (PCA/PRA selon le contexte) et doivent être validés avec les responsables IT/sécurité et l’exploitation.

Décision & contrat : clarifier les responsabilités (sans “zone grise”)

Un failover est souvent à cheval entre opérateur, intégrateur/infogérant et éditeur applicatif. Pour réduire le risque opérationnel, les livrables et responsabilités peuvent être clarifiés dès le cadrage (exemples à adapter au projet) :

• Opérateur(s) : engagements de service (SLA), modalités de support/escalade, délais d’intervention (GTR/équivalent contractuel), conditions d’IP publique (fixe/variable), options liées au mobile (CGNAT / APN / inbound).
• Intégrateur/infogérant : conception (priorités, segmentation, politiques), configuration documentée, supervision/alertes, runbook, organisation des tests et compte-rendus.
• Métiers / exploitation : validation des priorités (ce qui doit tenir pendant le secours), validation des scénarios de recette, consignes en réception (procédures en mode dégradé).

Ces points relèvent d’un choix contractuel et d’un cadrage projet : l’objectif est d’éviter qu’un incident se perde entre plusieurs interlocuteurs.

Recette du failover : mesurer plutôt que promettre zéro interruption

La procédure d’essai doit relever l’heure de l’incident, la détection de panne, le transfert de nouvelles sessions, la réouverture des services métier et le retour au principal. Pour chaque étape, l’équipe valide des critères métier avant de définir des délais acceptables. Un résultat donné sur une famille de routeurs/pare-feu, une version logicielle ou un opérateur ne doit pas être extrapolé à d’autres configurations.

Exemple de plan d’essais d’un hôtel

Résumé (lecture rapide) : l’essentiel est de prouver (1) que la panne est détectée, (2) que les nouveaux flux repartent, (3) que les applications critiques se réouvrent proprement, (4) que le retour au principal ne crée pas d’instabilité.

Les tests doivent être organisés avec les professionnels habilités et sans provoquer l’interruption d’une prestation essentielle à des clients présents. En pré-ouverture, le scénario peut être simulé dans une fenêtre dédiée. La réception conserve aussi la configuration du routeur, les informations opérateurs, les contacts d’escalade et les contraintes de liaisons de secours.

Exploitation : supervision, alertes et runbook

Un failover n’est réellement exploitable que si l’équipe est informée et sait quoi faire. À définir selon l’organisation (interne / infogérance) :

• Supervision & journalisation : conserver les journaux (bascule, sondes, routes, erreurs) et, si possible, corréler avec les incidents applicatifs. Si les logs contiennent des données personnelles (identifiants, adresses IP rattachables à une personne, etc.), appliquer les principes de finalité, de sécurité et de durée de conservation limitée au besoin, conformément au cadre CNDP (définition et principes : Loi 09-08 ; information CNDP : CNDP — Notifier un traitement).
• Alerting : déclenchement d’alertes lors d’un basculement, d’un retour, ou d’une dégradation (perte, latence). Les canaux (email/SMS/outil ITSM, etc.) sont à choisir selon vos procédures et à valider avec l’équipe sécurité.
• Runbook : une procédure opérationnelle courte (qui contacter, quelles vérifications faire, quelles actions sont autorisées, comment revenir en arrière) réduit le temps de diagnostic et les erreurs.
• Gestion des changements : après une mise à jour, un changement opérateur ou une modification de règles, prévoir une revalidation ciblée du failover pour limiter les régressions.
• Périodicité des tests : illustrativement, une revalidation périodique (par exemple trimestrielle ou semestrielle selon criticité) peut être discutée ; l’important est de produire un compte-rendu, de tracer les écarts et de corriger.

Exemple de politique pendant le secours

Résumé (lecture rapide) : en mode secours, l’objectif n’est pas de « tout maintenir », mais de tenir l’essentiel et d’éviter qu’un usage non critique consomme la liaison de secours.

Checklist de validation

• Classer les applications critiques avec le responsable métier.
• Vérifier la diversité réelle des deux chemins opérateurs (ne pas présumer).
• Établir le débit et la qualité nécessaires sur le secours (dont upload, latence et stabilité).
• Vérifier les contraintes d’IP publique et, le cas échéant, de CGNAT sur le lien mobile (auprès de l’opérateur).
• Configurer sondes de santé, seuils, routes, DNS et NAT pour chaque WAN.
• Prévoir priorité des flux métier et politiques Wi-Fi invité (QoS/limitation).
• Dimensionner l’alimentation secourue des équipements de la chaîne.
• Mettre en place supervision/alertes et runbook (bascule, retour, retour arrière).
• Tester coupures et rétablissements, puis consigner les résultats.

Questions fréquentes

Deux fibres de deux opérateurs garantissent-elles la continuité ?

Non. Elles peuvent partager un trajet physique ou des dépendances. Une analyse de résilience (site + contrats) est nécessaire.

Le failover empêche-t-il toute coupure d’appel ?

Pas nécessairement. Des sessions peuvent être interrompues lors du changement d’adresse IP publique, de chemin réseau ou de traduction NAT.

Une liaison 4G/5G suffit-elle ?

Cela dépend de sa couverture, de son débit, de sa stabilité (latence/gigue), des besoins métiers, d’un éventuel CGNAT et de la consommation de données. Elle doit être testée à l’emplacement prévu et confirmée au contrat.

Conclusion

Un failover efficace ne consiste pas à poser deux modems côte à côte. Il vise à concevoir puis valider une continuité réaliste des services essentiels : diversité des accès, détection de panne fiable, règles de bascule et de retour, priorisation des flux, alimentation secourue, supervision et recette.

Dans un projet, les livrables attendus (à adapter au périmètre) peuvent inclure : une cartographie des dépendances, une configuration documentée (WAN/NAT/VPN/sondes), une politique de priorisation en mode secours, un plan d’essais avec preuves, et un runbook d’exploitation. Toute exigence contractuelle, sécurité ou conformité doit être confirmée avec les parties habilitées.

Échanger avec Domocasa sur votre projet

Références techniques

• ANRT — Décision n°10/14 : cadre d’accès/régulation du réseau fixe ; utile pour cadrer l’existence de dépendances possibles.
• ANRT — Décision n°19/14 : modalités techniques/tarifaires du dégroupage ; renforce la prudence sur les points d’interconnexion.
• Orange Maroc Pro — Business Box 4G : exemple public mentionnant une option « IP fixe » sur une offre 4G business (à revalider au devis/contrat).
• Transacom — FAQ Accès Internet : explication générique du CGNAT (source non marocaine, ne prouve pas une pratique uniforme au Maroc).
• Loi 09-08 (CNDP) : définition de donnée personnelle et principes (finalité, durée limitée, sécurité).
• CNDP — Notifier un traitement : éléments d’information sur les régimes de notification/autorisation, selon les cas.