Standard téléphonique en panne : bâtir le plan de continuité

Un standard téléphonique qui tombe un mardi à 10 h ne prévient pas : les clients entendent une sonnerie dans le vide ou un message d'erreur, les commerciaux ne peuvent plus appeler, et personne ne sait si la panne vient de la box, de l'IPBX, du certificat ou de l'opérateur. La différence entre dix minutes et une journée perdues ne tient pas au matériel, mais à l'existence d'un plan de continuité téléphonique : des causes identifiées, des secours déjà en place, une procédure écrite que la première personne disponible peut dérouler, et des tests qui prouvent que tout cela fonctionne encore.

Les causes fréquentes, par ordre de probabilité

Sur les incidents que nous voyons chez les TPE, PME et plateaux, la téléphonie IP tombe pour un petit nombre de raisons qui reviennent sans cesse.

• La coupure d'accès Internet : fibre sectionnée par des travaux, box qui redémarre en boucle, panne de l'opérateur d'accès. C'est la première cause, et la plus simple à couvrir. Avec la fin du cuivre, plus aucune ligne analogique ne survit à cette coupure.
• L'alimentation électrique : une coupure, ou simplement un onduleur dont la batterie est morte depuis deux ans, fait tomber le commutateur, la box et l'IPBX en même temps.
• Le certificat expiré : les postes WebRTC et les softphones en TLS refusent de se connecter le jour où le certificat HTTPS du serveur arrive à échéance, le plus souvent un certificat gratuit à 90 jours dont le renouvellement automatique a cessé de fonctionner sans que personne le remarque. Les symptômes et prérequis sont décrits dans notre article sur le poste agent WebRTC.
• Le trunk SIP qui ne s'enregistre plus : mot de passe changé, adresse IP publique modifiée par l'opérateur d'accès alors que le trunk est authentifié par IP, compte suspendu pour facture impayée ou pour suspicion de fraude, plage de ports fermée après une modification du pare-feu. Les appels internes fonctionnent, rien n'entre ni ne sort.
• La mise à jour : mise à jour de l'IPBX, du système, du pare-feu ou de la box qui change un comportement, un chemin de fichier ou une règle NAT. Appliquée un vendredi soir, elle se découvre le lundi matin.
• Le disque plein : enregistrements d'appels et journaux qui saturent le volume ; la base de données s'arrête et l'IPBX avec elle.
• Le DNS ou la panne de l'opérateur VoIP : nom de domaine expiré, ou incident chez l'opérateur lui-même ; plus rare, mais hors de votre contrôle.

Le piratage d'IPBX, lui, ne se manifeste en général pas par une panne mais par une facture ; il relève d'un autre plan, celui de notre article sur la sécurisation de l'IPBX contre la fraude.

Le renvoi d'urgence côté opérateur : le secours qui marche quand tout est tombé

Si l'IPBX, la connexion ou le bâtiment sont hors service, aucune fonction configurée dans l'IPBX ne vous sauvera. Le seul secours qui fonctionne dans tous les cas est celui qui vit chez l'opérateur qui porte vos numéros. La plupart des opérateurs VoIP professionnels proposent, sur leur portail ou par API, un renvoi d'urgence par numéro ou par tranche : si le trunk ne répond pas, ou sur simple activation manuelle, les appels entrants partent vers un mobile, un autre site, un service de permanence ou une messagerie hébergée chez l'opérateur.

Quatre réglages à vérifier dès maintenant, pas pendant l'incident :

• le renvoi automatique sur non-réponse du trunk existe-t-il, et avec quel délai de détection (quelques secondes à quelques minutes selon l'opérateur) ;
• les destinations sont-elles déjà saisies (le mobile du dirigeant, celui de l'assistante, le numéro du prestataire de permanence), avec une destination par groupe de numéros si le service client et le standard ne doivent pas aboutir au même endroit ;
• qui a l'identifiant du portail, et le second facteur d'authentification, un samedi ;
• le renvoi est-il facturé comme un appel sortant vers mobile, ce qui, sur une journée de trafic, peut représenter une somme à connaître à l'avance.

Si votre opérateur ne propose rien de tel, c'est une raison sérieuse de le changer ou d'héberger vos numéros chez un opérateur qui le fait, en gardant éventuellement votre trunk sortant ailleurs.

Les secours techniques à mettre en place, par coût croissant

• Un onduleur dimensionné et testé pour la box, le commutateur et l'IPBX : vingt à trente minutes d'autonomie couvrent la majorité des microcoupures, et laissent le temps d'activer le renvoi d'urgence pour le reste. Changez les batteries tous les trois à quatre ans.
• Un accès 4G/5G de secours derrière un routeur capable de basculer automatiquement (double WAN), avec une carte SIM professionnelle réellement activée et un forfait data suffisant. Deux précautions : la bascule change l'adresse IP publique, ce qui casse un trunk authentifié par IP et peut perturber le NAT ; préférez un trunk authentifié par identifiant et mot de passe, ou déclarez les deux adresses chez l'opérateur. Et la capacité en voix d'un lien 4G partagé est limitée ; les ordres de grandeur sont dans notre article sur la bande passante par appel.
• Un double trunk : un deuxième opérateur pour les appels sortants, configuré en route de secours dans l'IPBX, pour continuer à appeler quand le premier est en panne ou vous suspend. Pour les appels entrants, le double trunk ne sert à rien tant que les numéros sont portés par un seul opérateur ; c'est le renvoi d'urgence qui couvre ce sens. Les points de configuration sont ceux de notre guide du trunk SIP.
• Des postes mobiles de repli : un softphone ou un accès WebRTC déjà testé sur le téléphone de quelques personnes clés, pour travailler depuis la 4G si le réseau du bureau est tombé mais pas le serveur.
• Un IPBX hébergé ou un deuxième serveur : la redondance la plus coûteuse. Le cloud supprime les causes locales (électricité, box, disque) mais pas les autres (certificat, trunk, mise à jour).

Détecter avant les clients

La plupart des pannes citées se voient venir. Une supervision minimale vérifie toutes les minutes que le serveur répond, que le trunk est enregistré, que l'espace disque reste sous 80 % et que le certificat expire dans plus de quinze jours. Ajoutez un appel de test quotidien depuis l'extérieur vers l'un de vos numéros, qui teste d'un coup l'opérateur, le trunk, le réseau et l'IPBX. Les alertes partent vers deux personnes, jamais une seule.

La procédure écrite, en une page

En pleine panne, personne ne lit un document de vingt pages. La procédure tient sur une page, imprimée et stockée aussi hors du réseau de l'entreprise, et elle répond à cinq questions :

• Comment constater : trois vérifications en deux minutes (Internet passe-t-il depuis un PC ? les postes sont-ils enregistrés ? le trunk est-il enregistré ?) pour distinguer la panne d'accès, la panne de serveur et la panne d'opérateur.
• Qui décide et qui agit : le nom de la personne qui active le renvoi d'urgence et de son suppléant, avec les identifiants rangés dans un gestionnaire de mots de passe accessible hors du réseau.
• Quoi activer, dans quel ordre : renvoi d'urgence chez l'opérateur, puis bascule 4G, puis postes mobiles ; avec, pour chaque action, le lien exact et les captures d'écran.
• Qui prévenir : l'équipe (par un canal qui ne dépend pas du réseau en panne), les clients clés si la panne dépasse une heure, le prestataire ou l'opérateur, avec les numéros de support et le numéro de contrat.
• Comment revenir : la désactivation du renvoi, dans l'ordre inverse, et un appel de test entrant et sortant avant d'annoncer la fin de l'incident.

Fixez aussi, par écrit, le délai de reprise visé : pour la plupart des PME, quinze minutes pour les appels entrants par renvoi, une heure pour un fonctionnement dégradé, une demi-journée pour le retour à la normale. Ces objectifs dimensionnent les secours.

Les tests trimestriels, et pourquoi ils sont la partie la plus importante

Un plan de continuité jamais testé est une hypothèse. L'onduleur dont la batterie est morte, la SIM 4G désactivée pour inactivité, le renvoi d'urgence qui pointe vers le mobile d'un salarié parti depuis un an, le mot de passe du portail opérateur qui a changé : tout cela se découvre pendant le test, ou pendant la panne. Une fois par trimestre, à une heure creuse et en prévenant l'équipe :

• activez réellement le renvoi d'urgence et appelez le numéro principal depuis un mobile extérieur ; chronométrez ;
• débranchez l'accès principal et vérifiez que la bascule 4G se fait, que le trunk se ré-enregistre et qu'un appel sortant aboutit avec le bon numéro affiché ;
• coupez l'alimentation du local technique quelques minutes et notez l'autonomie réelle de l'onduleur ;
• vérifiez les dates d'expiration du certificat, du nom de domaine et des contrats, et l'état de la supervision ;
• faites dérouler la procédure par quelqu'un qui ne l'a pas écrite, et corrigez ce qu'il n'a pas compris.

Notez la date, la durée et les écarts dans un journal. Après une mise à jour majeure ou un changement d'opérateur, refaites le test sans attendre le trimestre. Et profitez-en pour vérifier que le fonctionnement nominal reste bon : une qualité d'appel qui se dégrade lentement, mesurée avec les indicateurs de notre article sur la qualité VoIP, annonce souvent la panne suivante.