Vos SLA mentent : les huit pièges du calcul
Un SLA faux n'affiche pas d'erreur. Il affiche un chiffre, et ce chiffre est vert.
Un engagement de délai a l'air simple : « première réponse en 4 heures ». Le calcul, lui, ne l'est pas — et son défaut caractéristique est de ne jamais échouer bruyamment. Un compteur de SLA mal posé ne plante pas : il rend un nombre, le nombre est plausible, et le tableau de bord est vert.
Voici les huit endroits où ça se casse, dans l'ordre où on les rencontre en écrivant le moteur. Chacun est un cas de test chez nous, et chacun a une décision à prendre — il n'y a pas de bonne réponse universelle, il y a une réponse qui doit être écrite quelque part.
1. Les heures ouvrées à cheval sur minuit
Une équipe qui travaille de 9 h à 18 h se calcule facilement. Une équipe d'astreinte de 22 h à 6 h casse la plupart des implémentations naïves, parce que l'intervalle « début > fin » n'en est pas un : il en faut deux.
# Faux : l'intervalle est vide
si heure >= 22 ET heure < 6 -> jamais vrai
# Juste : deux intervalles, et le jour change au milieu
si heure >= 22 -> ouvert (jour J)
si heure < 6 -> ouvert (jour J, mais la plage a commencé la veille)Le piège dérivé, plus vicieux : la durée restante d'un compteur ouvert à 23 h ne doit pas se calculer en soustrayant des heures d'horloge, mais en accumulant les minutes ouvrées jusqu'à épuisement. Un compteur qui soustrait tombe d'un jour dès que la plage traverse minuit.
2. Le fuseau du client n'est pas celui de l'agent
Un ticket ouvert à 8 h à Lisbonne arrive à 9 h à Paris. La question n'est pas « quelle heure est-il », c'est de qui les heures ouvrées comptent. Trois réponses possibles, et il faut en choisir une :
- Les heures de l'équipe qui doit répondre. C'est le plus honnête vis-à-vis de l'engagement : on promet un délai qu'on peut tenir.
- Les heures du client. Défendable pour un engagement commercial, mais alors un même ticket a un délai différent selon le client, et deux tickets identiques ne se comparent plus.
- Le fuseau de l'espace, pour tout le monde. Le plus simple, et il devient faux dès qu'une équipe couvre deux continents.
3. Les jours fériés, qui ne sont pas les mêmes partout
Un calendrier de jours fériés est une donnée par pays et par année, parfois par région — l'Alsace-Moselle a deux jours que le reste de la France n'a pas, et le Vendredi saint est férié dans une partie de l'Allemagne seulement.
Le piège de mise en œuvre : coder une liste de dates. Une liste de dates est juste un an, fausse le suivant, et personne ne s'en aperçoit parce qu'un jour férié manquant ne fait qu'accélérer un compteur — donc le SLA passe au vert au lieu de passer au rouge. Le sens de l'erreur compte : un bug qui rend le tableau plus flatteur ne remonte jamais tout seul.
4. La mise en pause, et surtout ce qui la lève
« En attente du client » suspend le compteur, et c'est légitime : on ne peut pas être tenu d'un délai pendant qu'on attend une information. La difficulté n'est pas la pause, c'est la reprise. Trois candidats, aux effets très différents :
| Reprise déclenchée par | Effet | Risque |
|---|---|---|
| Toute réponse du client | Le compteur repart à la réception | Un « merci » du client relance un délai sur un ticket réglé |
| Un changement de statut par l'agent | Contrôlé | Le compteur reste en pause si l'agent oublie — le SLA devient décoratif |
| Une réponse du client suivie d'une relecture | Le plus juste | Demande de distinguer un accusé de réception d'une vraie réponse |
Il n'existe pas de choix sans défaut. Le seul mauvais choix est de ne pas savoir lequel on a fait — et c'est le cas le plus fréquent.
5. La réouverture d'un ticket résolu
Un client répond trois semaines après la résolution : « en fait le problème est revenu ». Le ticket se réouvre. Le compteur de première réponse repart-il de zéro ?
S'il repart de zéro, l'indicateur de première réponse ment : la première réponse a bien eu lieu, il y a trois semaines. S'il ne repart pas, le client attend sans qu'aucun compteur ne s'en soucie. La sortie est de ne pas réutiliser le même compteur : une réouverture ouvre un compteur de *réponse suivante*, distinct, avec son propre engagement. Le compteur de première réponse, lui, est un fait historique et ne se recalcule jamais.
Un indicateur qu'on peut remettre à zéro n'est plus une mesure, c'est un score.
6. Le ticket qui arrive hors ouverture
Un email reçu le samedi à 3 h du matin, pour une équipe ouverte du lundi au vendredi de 9 h à 18 h. Le compteur démarre-t-il à la réception, ou à l'ouverture du lundi ?
S'il démarre à la réception, le SLA de 4 heures est brûlé avant que quiconque ait pu lire le message : l'engagement est mécaniquement intenable, et l'indicateur mesure les week-ends au lieu de mesurer l'équipe. S'il démarre à l'ouverture, il faut assumer que le client attend 54 heures pour une promesse de 4 — donc le dire dans la promesse. C'est le piège où la technique renvoie une question au commerce, et où le commerce doit répondre.
7. Plusieurs SLA sur un même ticket
Un ticket urgent d'un client sous contrat Entreprise correspond à deux politiques : celle de la priorité et celle du contrat. Laquelle s'applique ?
- La plus stricte paraît généreuse, mais rend les engagements imprévisibles : personne ne sait à l'avance quel délai s'applique.
- La première qui correspond, dans un ordre explicite, est prévisible. C'est notre choix, et l'écran de configuration montre l'ordre — parce qu'une règle de priorité invisible est une règle qu'on découvre en réunion.
- Toutes en parallèle est tenable techniquement et illisible humainement : trois compteurs sur un ticket, dont deux rouges, ne disent plus quoi faire.
8. L'escalade n'a pas l'horloge de la résolution
« Escalader au niveau 2 à 80 % du délai » suppose qu'on sache de quel délai on parle. La première réponse ? La résolution ? Le piège concret : une escalade calée sur la résolution se déclenche après que la première réponse a été manquée, donc trop tard pour servir à quelque chose.
Et une escalade est un événement, pas un état : elle doit se produire une fois. C'est exactement le terrain de la panne que nous avons publiée — une règle planifiée qui a envoyé 32 094 notifications parce qu'elle réévaluait sa population à chaque passage sans mémoire de ce qu'elle avait déjà traité. Un déclencheur d'escalade sans mémoire escalade indéfiniment.
Comment vérifier votre outil en dix minutes
Ces huit points se testent sans documentation, sur un ticket jetable. Prenez un environnement de test et faites ceci :
- 1Créez un ticket un vendredi à 17 h 50 avec un SLA de 4 heures. Regardez l'échéance annoncée : si c'est vendredi 21 h 50, l'outil ignore vos heures ouvrées.
- 2Mettez-le en attente du client, puis faites répondre le client « merci ». Le compteur repart-il ? Vouliez-vous qu'il reparte ?
- 3Résolvez-le, puis faites répondre le client. Regardez si le compteur de première réponse a bougé. S'il est reparti de zéro, votre historique de première réponse est faux.
- 4Ajoutez un jour férié régional dans un an et vérifiez qu'il est pris en compte. La plupart des outils ont une liste, pas un calendrier.
Notre moteur d'heures ouvrées et son jeu de tests sont lisibles — licence AGPL-3.0, voir la page open source. Ce qu'ils font est décrit sur la page SLA et règles. Nous ne prétendons pas avoir bien tranché les huit ; nous prétendons que les huit sont tranchés explicitement, ce qui est la seule chose qu'un acheteur peut vérifier.
Nous ne publions pas d'article sans un chiffre mesuré chez nous, du code qu'on peut aller lire, ou une limite avouée. C'est la seule façon d'écrire sur ce métier sans répéter ce que tout le monde écrit déjà.