Le Blog du DSI
Opérations

Liaison Internet de secours : testez la vraie bascule

Deux abonnements ne garantissent pas la reprise. Vérifiez les chemins réseau, les accès métier et le retour au lien principal avant la prochaine coupure.

Routeur réseau relié par des câbles bleus, voyant allumé
Photo Unsplash
À retenir

Testez votre liaison Internet de secours depuis les postes utilisateurs, jusqu'à une opération métier complète. Vérifiez les dépendances communes aux accès, la détection de panne, les restrictions liées à l'adresse IP et le retour au lien principal. Un routeur connecté ne prouve pas que l'entreprise peut travailler. Conservez les résultats et faites corriger chaque blocage avant de déclarer le secours opérationnel.

Vous payez une liaison Internet de secours, mais personne n’a essayé de travailler dessus. Voici les vérifications à exiger avant de compter sur elle lors d’une coupure.

Je pars d’une question simple : depuis un poste du site, peut-on se connecter à l’application indispensable et terminer une tâche ? Le voyant du routeur répond à une autre question. Entre les deux se cachent les règles d’accès, le DNS et les équipements communs aux liaisons. C’est là que je concentrerais le prochain exercice.

Exigez le trajet des liens, pas seulement deux factures

Demandez à chaque opérateur par où arrive son accès. Les fibres entrent-elles dans le bâtiment par le même passage ? Traversent-elles le même local technique ? Le fournisseur connaît-il le chemin complet, ou seulement la portion qu’il exploite ?

Le guide numérique des entreprises de l’Arcep rappelle que des accès peuvent partager une infrastructure physique. Il recommande de demander l’indépendance des cheminements lorsqu’un niveau élevé de sécurisation est recherché. Changer de logo sur la facture ne règle donc pas la question du coup de pelleteuse.

Faites dessiner les dépendances sur une page. Ajoutez le pare-feu, le commutateur et l’alimentation électrique. Si les liens aboutissent au même équipement, inscrivez sa panne parmi les scénarios non couverts. N’achetez pas une redondance supplémentaire sans savoir quelle panne elle doit absorber.

Pour un secours mobile, vérifiez la réception à l’emplacement prévu du routeur. Un téléphone testé près d’une fenêtre ne valide pas une installation au fond de la baie. Demandez aussi quel réseau mobile porte réellement l’offre.

Fixez les usages qui doivent passer sur le secours

Ne dimensionnez pas le secours à partir du seul débit annoncé. Faites choisir au responsable du site les activités à maintenir : saisir une commande, joindre un client, consulter un dossier. Associez à chacune un utilisateur et un essai précis.

Voici un modèle à adapter, sans lui attribuer de résultat avant l’exercice.

Usage retenuVérification sur le secoursDécision si l’essai échoue
Application de gestionOuvrir une nouvelle session et enregistrer une opération de testCorriger l’accès avant validation
TéléphonieAppeler vers l’extérieur et recevoir un appelPrévoir un renvoi testé
Liaison avec le siègeReconnecter le VPN et ouvrir la ressource attendueFaire corriger le tunnel
Transfert volumineuxObserver son effet sur les usages prioritairesLe reporter ou limiter son débit

Faites préciser au fournisseur les limites de consommation, les restrictions et les conditions de dépassement du forfait. Demandez un chiffrage séparé du matériel, de l’installation et des interventions de test. Ces postes doivent apparaître dans le budget, même si l’abonnement semble modeste.

Un secours limité peut suffire si le métier accepte les restrictions. Écrivez lesquelles dans vos engagements de service, avec les activités qui restent possibles.

Vérifiez ce qui déclenche réellement la bascule

Une interface réseau active ne prouve pas qu’Internet répond. Le modem peut rester accessible alors que la panne se situe plus loin chez l’opérateur.

La documentation de dépannage multi-WAN de Netgate décrit précisément ce cas : une adresse de surveillance encore joignable peut empêcher pfSense de considérer le lien comme défaillant. Vérifiez la cible surveillée et le chemin emprunté pour la joindre.

Demandez à votre intégrateur de montrer les critères configurés : perte de réponse, dégradation, délai avant bascule et conditions de retour. Refusez une réponse limitée à “c’est automatique”. Faites expliquer comment le réglage distingue une panne du lien d’une indisponibilité de la cible surveillée.

Préparez des essais distincts pour une perte physique du lien et une panne en amont avec interface encore active. Le second scénario exige une simulation maîtrisée avec l’intégrateur ou l’opérateur. Ne touchez pas à leurs équipements pour improviser la coupure.

Rejouez les accès avec l’adresse IP du secours

Une page web publique qui s’ouvre ne valide pas vos applications. Réessayez avec une nouvelle authentification, puis avec une session déjà ouverte avant la bascule. Notez ce qui continue, ce qui se reconnecte et ce qui exige une intervention.

Certaines règles d’accès dépendent de l’adresse publique de sortie. Microsoft décrit ce fonctionnement pour les emplacements réseau dans l’accès conditionnel Entra. J’en tire une vérification pratique : examiner les règles concernées avant de tester depuis le secours. Une adresse différente peut changer la décision d’accès.

Ne désactivez pas les protections pour faire réussir l’exercice. Faites adapter les règles au chemin de secours autorisé. Si l’adresse varie, demandez une solution compatible avec cette contrainte, sans déclarer toute une plage opérateur comme fiable.

Vérifiez également la résolution des noms et les connexions initiées par le pare-feu. Les précautions multi-WAN de Netgate distinguent ces flux de ceux des postes utilisateurs. Le fait qu’un poste navigue ne valide donc pas tous les services du boîtier. Pour les accès entrants, ajoutez un essai depuis l’extérieur du site.

Préparez le retour avant de provoquer la panne

Commencez par diriger un poste ou un réseau de test vers le secours, si votre équipement le prévoit. Corrigez les blocages d’accès ainsi repérés. Réservez ensuite une fenêtre autorisée pour vérifier la bascule automatique du périmètre retenu.

Avant la coupure, exigez un accès local d’administration, une sauvegarde de configuration et une personne capable de rétablir le branchement initial. Fixez une condition d’arrêt avec le métier. Gardez un canal de contact utilisable pendant l’essai ; la communication pendant une panne se prépare aussi pour un exercice.

Au rétablissement, observez le retour au lien principal. Vérifiez les sessions, les appels et les tunnels. Faites préciser si le retour est automatique, différé ou manuel. Un lien principal instable ne doit pas provoquer une succession de bascules incontrôlées.

Le secours est validé quand le travail reprend et que le retour au fonctionnement normal a lui aussi été testé.

Conservez les heures, les opérations réussies et les interventions nécessaires. Mentionnez la charge réellement présente : un test avec quelques utilisateurs ne démontre pas que tout le site tiendra dessus.

Faites cette checklist cette semaine

Choisissez un site et un responsable métier disponible. Ouvrez une fiche d’essai dans votre outil habituel, puis attribuez les actions suivantes :

  • Demander aux opérateurs les chemins d’accès et noter les dépendances encore inconnues.
  • Obtenir la configuration de bascule, les restrictions du secours et le contact d’assistance.
  • Faire choisir les opérations métier prioritaires et leurs critères de réussite.
  • Vérifier les accès depuis un poste dirigé vers le secours.
  • Programmer la coupure contrôlée et le retour, avec un responsable du retour arrière.
  • Affecter chaque échec à une personne, avec une échéance de correction et un nouvel essai.

Si un fournisseur refuse de participer, faites préciser par écrit qui couvre la configuration et l’assistance pendant l’exercice. Gardez le secours au statut “non validé” tant que les opérations indispensables restent en échec ou n’ont pas été testées.

Questions fréquentes

Deux opérateurs différents garantissent-ils un secours Internet indépendant ?

Non. Des abonnements distincts peuvent emprunter une infrastructure physique commune. Demandez aux fournisseurs de préciser les chemins d'accès et leurs points communs. Vérifiez aussi les équipements et l'alimentation dans vos locaux. Inscrivez les dépendances inconnues dans le dossier : deux contrats ne prouvent pas l'indépendance des liens.

Une liaison mobile suffit-elle pour secourir un site ?

Oui, si les usages prioritaires fonctionnent dans les conditions testées. Vérifiez la réception à l'emplacement du routeur, la capacité disponible, les restrictions du forfait et les accès applicatifs. Faites décider quels usages peuvent attendre. Un essai réussi avec un seul poste ne valide pas la charge de tout le site.

Peut-on tester la bascule sans couper Internet pour tous ?

Oui, pour une première vérification : dirigez un poste ou un réseau de test vers le secours selon les fonctions de votre équipement. Cela valide une partie des accès, mais pas le déclenchement automatique sur panne. Ce dernier exige un exercice préparé, avec une fenêtre autorisée, un accès local d'administration et un retour arrière.