Une PME surveille ses serveurs et son pare-feu ; son standard téléphonique tourne souvent depuis des années sans que personne n’ait regardé ce qu’il voit passer. Pourtant chaque autocommutateur, vieux PABX numérique ou IPBX SIP, écrit pour chaque appel une ligne de journal : le ticket (CDR, Call Detail Record). Ces tickets répondent à des questions concrètes : combien de lignes payer, combien d’appelants raccrochent avant qu’on décroche, quel service sature à 11 h le lundi. Encore faut-il savoir quoi mesurer, et dans quelle unité.

Ce que contient un ticket d’appel

Le format varie selon le constructeur, mais le contenu utile est toujours le même : horodatage de début, durée de sonnerie, durée de conversation, poste interne, numéro externe, sens (entrant, sortant, interne), ligne ou trunk utilisé, et le sort de l’appel — répondu, occupé, non répondu, renvoyé, transféré. Sur un IPBX, ce sort se lit directement dans les codes de réponse SIP : 200 pour un appel décroché, 486 pour un poste occupé, 480 pour un correspondant indisponible, 503 pour un équipement qui refuse la charge.

Un ticket isolé ne dit presque rien. C’est l’agrégation sur des semaines qui fait apparaître le profil de trafic, exactement comme pour les tickets de maintenance des machines industrielles : la valeur est dans la série, pas dans l’événement.

L’unité de base : l’erlang, et pourquoi le nombre d’appels ne suffit pas

Compter les appels est le réflexe naturel, et c’est une erreur de dimensionnement. Ce qui occupe une ligne, c’est la durée. La théorie du télétrafic mesure donc l’intensité de trafic, définie par l’UIT comme le nombre de ressources occupées à un instant donné ; son unité est l’erlang, du nom du mathématicien danois A. K. Erlang. Le manuel de référence de Villy B. Iversen (DTU, édition révisée 2015 du Teletraffic Engineering Handbook publié par l’UIT-D) en donne la formule pratique :

  • trafic offert A = λ × s, où λ est le nombre moyen d’appels par unité de temps et s la durée moyenne d’occupation, exprimés dans la même unité ;
  • un canal ne peut porter au plus qu’un erlang : 1 erlang, c’est une ligne occupée en permanence pendant la période observée ;
  • le volume total, somme des durées d’occupation, s’exprime en erlangs-heures.

L’exemple du manuel est parlant : 5 appels par minute d’une durée moyenne de 3 minutes font 15 erlangs, soit 120 erlangs-heures sur une journée de 8 heures. Dix appels de 30 secondes et un appel de 5 minutes représentent le même trafic — les compter séparément trompe sur la charge.

Point souvent oublié : le trafic offert n’est pas mesurable directement, seul le trafic écoulé l’est. Un standard saturé affiche donc un trafic plafonné qui ressemble, à tort, à une situation stable.

L’heure chargée, seule mesure qui dimensionne

Une moyenne journalière ne sert à rien pour dimensionner : les lignes doivent tenir le pic. La notion retenue est l’heure chargée cohérente (time consistent busy hour, TCBH) : les 60 minutes, calées à 15 minutes près, qui portent en moyenne le trafic le plus élevé sur une longue période. Certains jours, le pic du jour la dépasse, mais c’est elle qui sert de référence pour mesurer et dimensionner.

Les ordres de grandeur du manuel donnent des repères utiles pour vérifier ses propres chiffres :

  • le trafic sur 24 heures vaut environ 8 fois celui de l’heure chargée — c’est le « facteur de concentration » ;
  • en heures ouvrées, la durée moyenne d’occupation des circuits observée y est d’un peu moins de 3 minutes.

Une PME peut donc partir de ses tickets d’un mois, calculer heure par heure la somme des durées d’occupation des lignes externes divisée par 3 600 secondes, et retenir la tranche horaire la plus chargée en moyenne : c’est son trafic d’heure chargée, en erlangs.

De l’erlang au nombre de lignes : la formule d’Erlang B

Connaître le trafic ne dit pas encore combien de canaux il faut. C’est l’objet de la formule d’Erlang B (1917), qui donne la probabilité de blocage — la part d’appels qui trouvent toutes les lignes occupées — pour un trafic A offert à n canaux, sous hypothèse d’arrivées poissonniennes et d’appels perdus non mis en file d’attente. Le manuel recommande sa forme récursive, numériquement très stable : E0 = 1, puis En = A·En−1 / (n + A·En−1). Quelques lignes de tableur suffisent.

Prenons une PME de quarante postes dont les tickets montrent, à l’heure chargée, 90 appels externes de 3 minutes en moyenne : A = 90 × 3 / 60 = 4,5 erlangs. La récursion donne :

  • 6 canaux : environ 15 % des appels bloqués à l’heure chargée ;
  • 8 canaux : environ 4,8 % ;
  • 10 canaux : environ 1 % ;
  • 12 canaux : environ 0,16 %.

Deux enseignements. D’abord, la relation n’est pas linéaire : passer de 8 à 10 canaux divise le blocage par près de cinq. Ensuite, si le même trafic monte à 6 erlangs, dix canaux laissent passer environ 4,3 % de blocage. Le manuel retient une perte de quelques pour cent à l’heure chargée comme compromis usuel entre qualité et coût : c’est un choix explicite. Avec un accès SIP, le « canal » est un appel simultané autorisé par l’opérateur : le calcul s’applique tel quel au nombre de sessions souscrites.

Les indicateurs de qualité : ce que disent les échecs

Le volume ne dit pas si les appelants sont servis. Pour la téléphonie SIP, la RFC 6076 de l’IETF normalise des métriques de bout en bout directement calculables à partir des tickets :

  • SER (Session Establishment Ratio) : part des tentatives (INVITE) ayant reçu un 200 OK, hors redirections 3xx ; la RFC le rapproche de l’ASR (Answer Seizure Ratio) de la recommandation UIT-T E.411 ;
  • SEER (Session Establishment Effectiveness Ratio) : même calcul, mais en comptant aussi comme « effectifs » les 480, 486, 600 et 603, qui traduisent le comportement de l’usager appelé et non une défaillance du réseau ;
  • ISA (Ineffective Session Attempts) : part des tentatives tombées sur un 408, 500, 503 ou 504, symptômes d’un équipement en défaut ou en surcharge.

La distinction SER / SEER est exactement celle dont un responsable a besoin. Un SER bas avec un SEER élevé signale un problème d’organisation : les gens ne décrochent pas, les groupements sonnent dans le vide. Un SEER bas signale un problème technique : trunk saturé, opérateur défaillant, IPBX qui refuse des sessions. Ce dernier cas relève de la supervision au sens large, celle qui regarde le service rendu plutôt que le simple fait qu’un équipement réponde au ping, comme nous l’avions détaillé pour les machines qui ne sont pas des serveurs.

Côté accueil, le taux d’appels entrants non répondus par service et par tranche horaire, la durée de sonnerie avant décroché et le taux de rappel des appels manqués complètent la norme, à partir des mêmes tickets.

Ce que la CNIL encadre

Les tickets contiennent des numéros, donc des données personnelles. La fiche de la CNIL sur l’utilisation du téléphone au travail — ancienne et signalée par la CNIL elle-même comme en cours de mise à jour, mais dont les principes restent la référence publiée — reconnaît explicitement l’usage de l’autocommutateur pour la comptabilisation statistique des flux et l’imputation des coûts par service ou par poste. Elle pose trois règles opérationnelles : les quatre derniers chiffres des numéros sont occultés sur les relevés, l’accès aux numéros complets reste exceptionnel, et les données d’usage ne sont pas conservées plus d’un an. Les lignes des représentants du personnel ne doivent pas servir au contrôle de leurs appels. Un tableau de bord de trafic se construit donc sur des agrégats par service et par heure, pas sur la surveillance nominative.

Passer à la pratique

Tout cela se fait avec un export de tickets et un tableur. Le plus long n’est pas le calcul, mais d’obtenir un flux de tickets propre et normalisé, chaque constructeur ayant son format. Pour une petite structure qui veut voir son trafic réel sans engager de budget, il existe aussi un logiciel de taxation utilisable gratuitement sur un petit parc de postes, qui fait cette collecte et ces agrégats ; le raisonnement exposé ici reste le même quel que soit l’outil.

Récapitulatif : les cinq mesures à poser

  1. Collecter les tickets du standard sur au moins quatre semaines ordinaires.
  2. Calculer le trafic heure par heure en erlangs (somme des durées d’occupation / 3 600 s) et en déduire l’heure chargée cohérente.
  3. Dimensionner avec Erlang B le nombre de lignes ou de canaux SIP pour un objectif de blocage choisi (1 à quelques pour cent).
  4. Suivre le SER, le SEER et les ISA pour séparer les problèmes d’organisation des problèmes techniques.
  5. Agréger par service et masquer les numéros, conservation limitée à un an, conformément aux recommandations de la CNIL.