Une grande partie des plannings de centres de contacts repose encore, directement ou indirectement, sur Erlang C, même quand l'outil de WFM propose des moteurs plus sophistiqués.
Erlang C fait pourtant bien ce pour quoi il a été conçu. Le problème vient surtout des hypothèses qu'on lui applique. Elles fonctionnent plutôt bien pour une file voix classique. Beaucoup moins quand les clients abandonnent, que le trafic arrive par à-coups ou que plusieurs conversations sont traitées en parallèle. Et dès qu'on passe au chat ou à WhatsApp, on finit par essayer de corriger un modèle qui ne décrit plus vraiment ce qui se passe.
Erlang C a été conçu pour tailler large
Personne n'abandonne la file : c'est une des hypothèses d'Erlang C qui paraît étrange quand on la compare à ce qui se passe réellement dans un centre de contacts.
En clair, tous les appelants attendent jusqu'à ce qu'un agent soit disponible. C'est une hypothèse plutôt pratique. Si tout le monde reste en ligne, il faut dimensionner les équipes pour absorber toute la charge entrante. Le resultat est donc implicitement conservateur et permet d'obtenir un dimensionnement avec une marge de sécurité.
Pendant longtemps, ce fonctionnement avait aussi un autre avantage très concret : il était facile à utiliser et à expliquer : à partir d'un volume d'appels, d'une DMT et d'un objectif de service, le planner peut calculer un besoin et défendre son chiffre : Avec une cible de 80% des appels répondus en moins de 20 secondes, le raisonnement est très lisible, il est possible de justifier ligne à ligne chaque position.
Le sujet est devenu plus sensible avec les nouveaux outils/canaux et l'évolution des objectifs de service. Dans certains parcours, on accepte désormais qu'une partie du flux abandonne, se reporte ou soit absorbée par du self-care. Dimensionner comme si 100% des clients devaient finir par être servis revient à viser un objectif que l'on ne recherche plus.
Repère - L'intérêt d'Erlang C réside dans le fait qu'on connaît assez bien le sens de ses erreurs.
Sur la voix, on sait encore où le modèle se trompe
La patience des appelants est probablement le cas le plus simple : Erlang C considère que tous les appels présents dans la file finiront par être traités. En réalité, une partie des clients raccroche avant. Le modèle prévoit donc des positions pour une charge qui disparaîtra avant d'atteindre un agent. Sur ce point, il surdimensionne. Erlang A corrige cette limite en ajoutant un paramètre de patience. Le modèle a notamment été formalisé par Garnett, Mandelbaum et Reiman en 2002.
Les pics posent un autre problème : Un calcul effectué sur une demi-heure travaille avec la moyenne de cette demi-heure. Si 30% des appels arrivent pendant cinq minutes, cette concentration disparaît dans le calcul. L'intervalle peut sembler correctement staffé alors que la file a saturé pendant quelques minutes avant de se résorber. Cette fois, Erlang C peut sous-dimensionner le besoin au moment du pic. Passer de 30 à 15 minutes aide, mais ne supprime pas le problème.
Il y a aussi la surdispersion : Dans un trafic poissonien pur, la variance est égale à la moyenne. Le trafic réel est souvent plus dispersé. Deux journées ayant le même forecast peuvent produire des charges très différentes. Brown, Gans, Mandelbaum et leurs coauteurs l'avaient notamment documenté dans leur analyse d'un centre d'appels publiée en 2005. Ignorer la surdispersion, c'est planifier une régularité que le flux n'a pas.
Le Multiskill est moins simple : Traiter un pool polyvalent comme plusieurs files indépendantes peut faire perdre le bénéfice de la mutualisation et conduire à surdimensionner. À l'inverse, un routage mal conçu peut dégrader cette mutualisation et créer un besoin supplémentaire.
Il n'y a donc pas de direction unique. Sur une activité voix classique, on arrive malgré tout à poser le problème :
- patience non prise en compte : tendance au surdimensionnement
- pics noyés dans une moyenne d'intervalle : risque de sous-dimensionnement
- surdispersion : risque sous-estimé
- multiskill : effet dépendant du routage et de la mutualisation réelle
À retenir - Tant que l'on sait dans quel sens le modèle dérive, on peut toujours travailler avec.
Avec le Chat, le problème change
Erlang C suppose qu'un agent traite une interaction à la fois et que cette interaction l'occupe jusqu'à sa fin.
Le chat ne fonctionne déjà plus comme ça : Un agent peut gérer plusieurs sessions simultanément. Trois conversations, quatre, parfois davantage selon le métier et le type de demandes.
Cette concurrence ne se représente pas simplement en modifiant une DMT dans Erlang C.
Tezcan et Zhang ont travaillé dès 2014 dans Operations Research sur des modèles de files de chat dans lesquels un agent sert plusieurs clients impatients en parallèle. Ces travaux ont depuis été prolongés récemment en 2024 avec des hypothèses de service et de patience plus générales.
On change ici de mécanique car l'agent partage sa capacité entre plusieurs conversations. Des nouveaux modèles de partage de ressources existent, mais ce n'est plus de l'Erlang C.
WhatsApp pousse le problème plus loin
WhatsApp a une particularité supplémentaire : le canal est semi-synchrone.
Une conversation peut fonctionner pendant quelques minutes presque comme un chat. Le client envoie un message, attend une réponse rapide, répond à nouveau quelques secondes ou quelques minutes plus tard. Puis il disparaît pendant vingt minutes, une heure ou davantage, avant de reprendre exactement la même conversation.
On alterne donc des phases où l'agent doit être très réactif et des temps morts pendant lesquels la conversation reste ouverte sans consommer de temps agent. C'est ce qui rend le dimensionnement compliqué. Une conversation peut rester ouverte pendant plusieurs heures alors que l'agent n'y consacre que quelques minutes de travail réel. Sa durée d'ouverture ne correspond plus au temps agent consommé. Mais on ne peut pas non plus la traiter comme un simple backlog asynchrone : quand le client est actif, il attend généralement une réponse rapide.
La charge dépend donc du temps réellement passé à répondre, du nombre de conversations qui se chevauchent, mais aussi du moment où les conversations inactives redeviennent actives. Dix conversations ouvertes ne représentent pas forcément beaucoup de charge si neuf clients ne répondent plus. Elles peuvent en revanche redevenir une charge immédiate si plusieurs clients reviennent au même moment.
Une DMT calculée comme sur la voix décrit mal ce fonctionnement. La durée d'une conversation dépend aussi de la charge de l'agent : plus il gère de conversations actives en parallèle, plus le délai entre deux réponses peut s'allonger, et avec lui la durée totale de la conversation.
Et le parcours client ne reste plus dans une seule file
Un client peut commencer en chat, poursuivre sur WhatsApp puis appeler ou demander à se faire rappeler. Un dimensionnement effectué canal par canal voit trois ou quatre flux. Il ne voit pas forcément qu'ils correspondent au même parcours, ni comment la charge circule entre eux.
Les travaux académiques sont d'ailleurs beaucoup moins aboutis sur ce type de combinaison que sur une file voix ou même sur un chat synchrone mono-type. Les modèles existants posent souvent des hypothèses assez fortes sur le type de conversations, les compétences des agents ou le fonctionnement des canaux.
Il faut donc distinguer deux sujets : Tout d'abord, le chat synchrone avec plusieurs conversations concurrentes sait être modélisé. Mais le mélange entre voix, chat et messagerie asynchrone et semi-synchrone (whatsapp), avec des conversations longues et des passages d'un canal à l'autre, reste beaucoup plus difficile à représenter proprement. Dans ce cas, l'erreur n'a même plus une direction évidente.
Traiter une conversation asynchrone ou semi-synchrone comme une interaction occupante peut conduire à surestimer le besoin. Ignorer la charge qui reste ouverte et s'accumule peut produire l'effet inverse. C'est une limite beaucoup plus gênante que quelques points d'écart sur un paramètre.
Le point qui compte - La frontière d'utilisation de l'Erlang C se situe surtout dans le type de file
Conclusion
Pour une activité voix, Erlang C reste utilisable à condition de connaître ses hypothèses et de corriger celles qui comptent réellement : abandons, variabilité du trafic, granularité des intervalles, routage.
Sur le chat concurrent ou la messagerie asynchrone ou semi-synchrone, continuer à raisonner uniquement en appels, DMT et positions simultanément occupées devient vite artificiel. Le risque n'est donc pas tellement d'utiliser Erlang C. Il est de continuer à l'utiliser après avoir quitté le type de file qu'il sait représenter.
La lecture business du même problème, c'est-à-dire la façon dont une erreur de dimensionnement se traduit ensuite en sous-effectif ou en sureffectif, est développée dans cet article sur le sous-effectif et le dimensionnement. article dédié au sous-effectif et au dimensionnement. Et la question de ce que les moteurs WFM récents corrigent réellement est traitée dans cet article l'apport concret de l'IA au WFM
Votre dimensionnement suit-il encore vos canaux ?
Votre dimensionnement repose-t-il encore sur un modèle taillé pour un canal que vos clients n'utilisent plus seuls ? Un diagnostic capacitaire permet d'identifier où vous sur-staffez sans le voir et où la charge multicanal vous échappe.
Lancer le diagnostic gratuit →