Connexion Internet de secours en PME : préparer et tester le relais 4G/5G

Une connexion Internet de secours doit permettre à votre équipe de reprendre ses usages prioritaires après la panne de la ligne principale. Le relais 4G/5G se prépare avec une réception mesurée dans les locaux, des règles de basculement et des tests sur les applications réellement utilisées.

Pour une PME à Genève qui travaille avec Microsoft 365, une téléphonie Internet ou un logiciel métier hébergé, la question est concrète : que pourra encore faire l’équipe, et après quel délai ? Voici une méthode pour définir le besoin et réceptionner l’installation avec votre prestataire.

Définir le travail à maintenir pendant la panne

Listez les services qui dépendent de la connexion : messagerie, appels, dossiers cloud, logiciel de gestion, paiement, accès distants et transferts. Pour chacun, désignez une personne capable de confirmer que le travail a repris. Un navigateur qui affiche une page ne valide pas toute cette liste.

Classez les usages en deux groupes : ceux à maintenir pendant l’incident et ceux pouvant attendre, comme certains téléchargements volumineux. Cette décision aide à dimensionner le secours et à éviter qu’un transfert non prioritaire occupe toute la capacité disponible.

Exemple fictif : un petit bureau de conseil genevois souhaite répondre aux appels, consulter ses dossiers et envoyer des messages pendant une panne. Il accepte de différer un transfert volumineux et les mises à jour non urgentes. Ce périmètre de travail sert de référence au test ; il ne décrit pas une installation client de Pixel’IT.

Fixez aussi le délai acceptable jusqu’à une tâche métier terminée. Notre guide sur le RTO, le délai de reprise visé, explique pourquoi il faut mesurer jusqu’au service rendu à l’utilisateur. L’objectif retenu doit ensuite être confronté aux résultats de l’exercice.

Choisir une architecture de secours adaptée

Trois approches courantes répondent à des périmètres différents. Avant tout achat, faites préciser les équipements compatibles, le mode de déclenchement et les appareils qui profiteront du secours.

Un mode de basculement utilise le lien de secours lorsque le principal est considéré indisponible. La répartition de charge utilise plusieurs accès en fonctionnement normal. La documentation Omada distingue ces deux mécanismes. Vérifiez lequel a été configuré, notamment lorsque le forfait mobile doit rester réservé aux incidents.

Des solutions intégrées existent en Suisse : Swisscom décrit un secours Internet par le réseau mobile avec retour sur la ligne câblée après résolution du dérangement. Il s’agit d’une offre avec ses conditions d’éligibilité ; son comportement ne doit pas être extrapolé à n’importe quelle carte SIM ou installation.

Vérifier la réception et les dépendances

Mesurer à l’endroit où le matériel sera installé

Testez le secours mobile dans sa position définitive, aux horaires représentatifs de l’activité. Relevez le débit descendant, le débit montant et le comportement lors des usages simultanés prévus. Un essai réalisé dehors avec un autre appareil ne décrit pas nécessairement ce que recevra le routeur dans son local.

Swisscom précise que les performances effectives de son secours mobile dépendent notamment du lieu, de la charge de la cellule et du terminal. Retenez donc des résultats mesurés pour votre configuration et prévoyez une nouvelle vérification si le matériel ou son emplacement change.

Identifier ce qui reste commun aux deux accès

Examinez l’alimentation, le routeur, le pare-feu et le commutateur qui relie les postes. Si l’un de ces éléments communs tombe en panne, une seconde connexion ne traite pas automatiquement ce scénario. Demandez aussi quel réseau mobile porte réellement l’offre et quelles dépendances subsistent avec la ligne principale.

La protection électrique doit couvrir les équipements nécessaires au chemin de secours. Notre guide sur les onduleurs pour NAS et serveurs explique comment inclure les dépendances réseau dans le dimensionnement et les tests. L’autonomie locale ne prouve toutefois pas que le réseau de l’opérateur restera disponible.

Cette analyse fait partie de la résilience du réseau, qui associe architecture, surveillance et procédure. Elle aide à définir précisément les pannes couvertes par le projet.

Détecter une vraie panne Internet

Le basculement dépend de la manière dont l’équipement décide qu’un accès fonctionne encore. Un câble branché ou un routeur opérateur joignable localement ne démontre pas que les services Internet restent accessibles.

Dans son guide de configuration Link Backup, Omada explique le rôle de la détection en ligne et des sondes DNS ou ping selon le mode choisi. Sophos documente également les passerelles principales et de secours et le délai de détection. Les réglages disponibles dépendent du modèle, du logiciel et de son mode d’administration.

Faites documenter les cibles de surveillance, les critères de panne et le délai de déclenchement. Le choix des sondes doit éviter qu’une cible unique défaillante provoque une bascule inutile, tout en détectant une panne située au-delà du routeur local. Les règles doivent être vérifiées par un essai, sans copier des seuils génériques.

Une conséquence pratique : un accès peut être déclaré disponible alors qu’un service cloud particulier est indisponible. Le contrôle de liaison et le contrôle du service utilisé par l’équipe répondent à deux questions différentes.

Contrôler la téléphonie, les VPN et les applications

Valider un usage réel, au-delà du test de débit

Pour la téléphonie ou Teams, testez l’émission et la réception d’appels, la qualité audio et les usages simultanés. La documentation réseau Microsoft Teams relie notamment les problèmes audio aux pertes de paquets et à la gigue, c’est-à-dire la variation du délai de transmission. Un bon débit maximal ne suffit pas à conclure que les appels sont satisfaisants.

Prévoyez qu’une connexion en cours puisse devoir se rétablir pendant le changement de chemin réseau. Mesurez ce comportement avec votre solution et distinguez la possibilité de passer un nouvel appel du maintien d’un appel déjà engagé.

Vérifier séparément les connexions sortantes et entrantes

Ouvrir une application cloud depuis le bureau et joindre un serveur du bureau depuis l’extérieur sont deux parcours distincts. Pour un VPN ou une application autorisée seulement depuis une adresse IP précise, faites vérifier les règles, les adresses utilisées et les possibilités de reconnexion.

En IPv4, certaines offres mobiles placent l’abonné derrière une traduction d’adresses opérateur, appelée CGNAT. La documentation TP-Link sur les adresses mobiles publiques et privées décrit pourquoi des connexions entrantes et redirections de ports peuvent alors ne pas fonctionner. Faites confirmer par l’opérateur et votre prestataire la solution adaptée aux accès nécessaires ; une carte SIM seule ne démontre pas leur disponibilité.

Tester le basculement avec une méthode précise

Organisez l’exercice pendant une plage convenue, avec un responsable technique, les utilisateurs de test et une procédure de retour à la normale. Notez la configuration de départ et utilisez des documents ou opérations de démonstration lorsque c’est possible.

1. Contrôler le fonctionnement initial : vérifier les usages retenus et confirmer quel accès transporte le trafic.
2. Simuler la panne prévue : faire interrompre de manière maîtrisée le lien principal par le prestataire, puis relever l’heure de début.
3. Observer la détection et le basculement : confirmer le passage sur le secours dans l’équipement et le fonctionnement des alertes.
4. Valider les tâches prioritaires : passer et recevoir un appel, ouvrir puis enregistrer un document de test, utiliser le logiciel métier et vérifier les accès distants concernés.
5. Mesurer la reprise : relever quand chaque tâche fonctionne réellement, les reconnexions nécessaires et les limites constatées.
6. Rétablir le lien principal : vérifier le chemin réseau, les applications et la fin de l’incident avant de clôturer l’exercice.

Lorsque votre procédure le permet, ajoutez un scénario où le routeur opérateur reste allumé et joignable, mais où son accès Internet amont est interrompu. Ce contrôle vérifie un comportement différent du simple retrait d’un câble réseau. La méthode de simulation doit être définie par le prestataire pour votre installation.

Conservez pour chaque service une fiche courte : résultat attendu, résultat constaté, délai mesuré, action manuelle et correction à prévoir. Un exercice réussi doit démontrer les usages retenus, avec leurs limites.

Préparer le retour sur la connexion principale

Le retour mérite son propre test. Selon les réglages, les nouvelles connexions peuvent reprendre la ligne principale tandis que les connexions existantes restent temporairement sur le secours, ou certaines connexions peuvent être rétablies. Sophos détaille ces options de retour sur la passerelle restaurée, avec des conditions liées au routage configuré.

Demandez quel comportement a été choisi et comment il affecte les appels, les transferts et les VPN. Vérifiez aussi ce qui se passe si la ligne principale revient de façon instable : le dispositif doit être réglé pour éviter des changements répétés non maîtrisés entre les accès.

Consignez la décision de retour, les contacts opérateur et les actions utilisateurs dans votre plan de reprise informatique. L’équipe doit pouvoir retrouver la procédure pendant une panne de sa connexion habituelle.

Prévoir le suivi et le budget complet

Une fois le secours installé, attribuez le traitement des alertes à une personne identifiée. Vérifiez la disponibilité de la carte SIM, l’état du matériel, la consommation et les changements de configuration. Réévaluez le dispositif après un déménagement, un changement d’opérateur ou l’ajout d’un service important.

Définissez une fréquence de test adaptée à votre activité et conservez le dernier compte rendu accessible. Si un transfert a été différé pendant l’incident, vérifiez sa reprise ; si une sauvegarde a été suspendue selon votre procédure, confirmez son redémarrage et son résultat.

Pour comparer les offres à Genève, demandez un chiffrage en CHF, avec la mention HT ou TTC, séparant le matériel, l’abonnement mobile, les éventuelles options d’adressage, les licences, la configuration, les tests et le suivi. Faites préciser les volumes inclus, les limitations de débit et les conditions de dépassement ou d’itinérance. Un prix de boîtier ne décrit pas le coût du service complet.

Faire vérifier votre secours Internet à Genève

Vous avez une clé 4G, une seconde ligne ou un routeur mobile, mais aucun compte rendu de basculement ? Pixel’IT peut examiner le périmètre couvert, les dépendances et les vérifications à prévoir dans le cadre de votre infogérance informatique à Genève.

Contactez Pixel’IT pour définir les usages à maintenir et préparer un exercice adapté à votre entreprise.

Documentation consultée le 23 octobre 2026. Les exemples sont illustratifs. Les fonctions de basculement, les conditions des offres et les possibilités d’accès dépendent du matériel, de sa version logicielle, des licences, de l’abonnement et de la configuration retenue. Les documents Sophos cités concernent la version 21.5 ; utilisez l’aide correspondant à votre installation.