Le SLA de votre éditeur n'est pas votre disponibilité réelle.

Le SLA affiché par l’éditeur rassure. Il ne décrit pas la réalité d’exploitation. Dans un centre de contact cloud, la disponibilité utile dépend d’une chaîne complète, pas d’un seul contrat bien présenté.

Le point de rupture se situe souvent hors de la plateforme. Lien internet, SBC, opérateur, intégrations, poste agent : un seul maillon faible suffit à faire tomber l’appel avant la prise en charge. Le 99,99 % ne couvre pas ce trajet de bout en bout.

Le SLA de l’éditeur s’arrête à sa frontière

Un éditeur garantit sa couche. C’est normal. Il ne garantit pas le transport de la voix, ni les interconnexions, ni la terminaison chez l’agent. Confondre ces périmètres crée une sécurité de façade.

Le contrat peut afficher un taux très élevé. La disponibilité vécue par le client se mesure sur le chemin complet. Si l’accès WAN tombe, si le SBC sature, si l’opérateur a une panne, la plateforme peut rester “up” et les appels être perdus avant d’atteindre le conseiller.

La question à poser est directe : “Montrez-moi, ligne par ligne, où commence et où s’arrête votre SLA.” Demandez aussi : “Quels éléments sont exclus du périmètre, et avec quel impact mesurable sur la prise d’appel ?” Vérifiez dans le contrat la présence explicite du lien, de l’opérateur, des équipements edge et des intégrations critiques. Le piège classique est un SLA très haut accompagné d’exclusions nombreuses ; le symptôme apparaît quand les tickets se renvoient entre fournisseurs alors que la plateforme reste déclarée disponible.

La chaîne la plus solide reste limitée par son maillon faible

La disponibilité n’est pas une moyenne morale. C’est une dépendance en cascade. Une plateforme à 99,99 % ne compense pas un opérateur mono-source, un accès internet unique ou un SBC sans redondance.

Le piège consiste à additionner des engagements séparés et à croire au résultat global. Ce calcul ne vaut rien si personne ne consolide les responsabilités. Chaque acteur peut être conforme dans son coin, pendant que le service global échoue au premier incident de chemin.

Demandez : “Quel est le schéma exact du trajet voix, du poste agent jusqu’au cœur de plateforme ?” Exigez un document de bout en bout avec chaque rupture possible, chaque bascule et chaque dépendance externe. Vérifiez contractuellement la redondance réelle, pas seulement annoncée : double accès, double opérateur, double SBC, et chemins de secours testés en production ou en préproduction. Le symptôme d’un dispositif fragile est simple : les indicateurs éditeur restent au vert, mais les appels chutent dès qu’un lien se dégrade ou qu’un équipement edge redémarre.

Les intégrations et le poste de travail font partie de la disponibilité

Un appel reçu mais un conseiller incapable d’agir n’est pas un service disponible. Si le CRM ne s’ouvre pas, si l’authentification casse, si le poste est instable, la chaîne est rompue côté métier. Le contrat éditeur ne couvre pas ce ressenti.

Les intégrations temps réel sont souvent traitées comme un sujet secondaire. C’est une erreur. Elles participent directement à la prise en charge. Une panne d’API, un proxy mal réglé, un SSO mal configuré ou un poste non conforme suffit à dégrader le service, même si la téléphonie fonctionne.

Posez cette question en réunion : “Quels composants sont dans le chemin critique entre la sonnerie et l’action de l’agent ?” Demandez ensuite : “Quel est le critère de disponibilité séparé pour la téléphonie, pour les applications métier et pour le poste de travail ?” Vérifiez que les tests incluent un appel réel avec ouverture CRM, identification et traitement complet. Le piège précis est le suivant : l’appel arrive, mais l’agent perd 20 à 40 secondes à cause d’un chargement applicatif ou d’un jeton expiré ; le symptôme est une file qui grossit alors que les tableaux de bord techniques restent nominalement stables.

Ce qui n’est pas garanti de bout en bout n’est garanti par personne.

Le bon critère n’est pas le pourcentage, c’est la chaîne prouvée

Un pourcentage sans périmètre clair sert surtout à calmer une réunion. Le bon sujet est la traçabilité de bout en bout. Vous devez pouvoir montrer chaque maillon, son secours, son responsable et son mode de défaillance.

La vraie question n’est pas “quel est le SLA de l’éditeur ?”. C’est “qui porte la disponibilité totale du parcours d’appel ?”. Si la réponse se fragmente entre trois contrats, vous n’avez pas d’engagement global. Vous avez une addition de promesses locales, pas une garantie de service.

Demandez : “Pouvez-vous produire une matrice qui relie chaque composant à son impact métier, avec le responsable et le temps de rétablissement associé ?” Exigez un engagement consolidé sur le service complet, avec seuils de disponibilité, pénalités et exclusions lisibles. Refusez tout dispositif où aucun acteur n’assume le trajet entier de l’appel jusqu’au conseiller. Le critère vérifiable est simple : un document unique doit relier réseau, opérateur, edge, plateforme, intégrations et poste agent, sinon le SLA reste théorique. Le piège se voit quand chaque fournisseur promet 99,99 % et que personne ne garantit la chaîne complète.

Le jour du pic, seul le bout en bout compte

Les pannes ordinaires se cachent. Les pics les révèlent. C’est là que les liens saturent, que les contournements cassent, que les dépendances non redondées deviennent visibles.

Le contrat le plus flatteur ne protège pas contre un chemin incomplet. Si le réseau d’accès, l’opérateur ou le SBC ne suivent pas, la plateforme seule ne suffit pas. La disponibilité réelle se juge au moment où tout le monde parle en même temps, où les files montent et où chaque seconde perdue coûte des contacts.

Demandez le plan de charge et les seuils de saturation de chaque maillon : bande passante, sessions simultanées, capacité SBC, limites opérateur, capacité poste et charge applicative. Demandez aussi les preuves de bascule bout en bout, avec horodatage et résultat observable côté agent. La question à poser est : “Quel est le comportement du service quand le trafic atteint 80 %, 90 % puis 100 % de la capacité nominale ?” Le piège précis est la saturation partielle : la téléphonie semble encore fonctionner, mais les temps de réponse explosent, les transferts échouent et les abandons d’appel montent en flèche.