Toute mise en œuvre ITSM connaît un moment, généralement six semaines environ après la mise en production, où le manager du service desk envoie le premier rapport SLA trimestriel au DSI et remarque discrètement que les chiffres sont faux. Pas énormément — un point de pourcentage ici, une violation isolée là — mais faux. Le schéma est toujours le même : un incident ouvert à 16h55 le vendredi précédant le Kurban Bayramı, marqué comme en violation le lundi matin, alors qu'en réalité aucun technicien n'était de garde. La politique SLA disait « 9h à 17h, du lundi au vendredi », le calendrier disait que le Ramazan Bayramı tombait un mercredi, et quelque part entre ces deux faits, un ticket est passé entre les mailles du filet.
Le calendrier SLA naïf — celui que tout ITSM propose par défaut — est à l'origine de ce problème. C'est la source la plus fréquente de rapports SLA peu fiables, et elle peut être corrigée. Cet article parcourt le modèle de calendrier que nous utilisons et recommandons, ainsi que les quatre catégories de complications que tout calendrier en production doit gérer.
Le défaut naïf : « 9h à 17h, du lundi au vendredi »
La plupart des outils ITSM proposent, dès l'installation, un calendrier SLA d'heures ouvrées qui ressemble à ceci :
- Du lundi au vendredi, 09h00 à 17h00.
- Week-ends exclus.
- Une courte liste de « jours fériés » que quelqu'un doit penser à mettre à jour chaque mois de décembre.
C'est acceptable pour une petite entreprise dont toute l'équipe IT vit dans la même ville, travaille les mêmes horaires et prend les mêmes congés. Ce n'est pas acceptable ailleurs. Dans le monde réel, au moins quatre catégories de complications font voler ce modèle en éclats dès la première année :
- Les jours fériés mobiles — la plupart des fêtes religieuses turques suivent le calendrier lunaire et avancent de 10 à 11 jours chaque année.
- Les modèles d'équipes — un NOC 24/7 n'observe aucune « heure ouvrée ».
- Les absences des techniciens — l'horloge SLA continue de tourner, que le technicien assigné soit à son poste ou non.
- Les opérations multi-régions — Istanbul ouvre à 09h00 Europe/Istanbul ; Londres ouvre à 09h00 Europe/London ; le ticket P1 s'en moque.
Nous allons traiter chacune de ces catégories à tour de rôle.
1. Les jours fériés turcs ne sont pas des dates fixes
Le calendrier officiel des jours fériés turcs comporte deux types de jours :
- Fêtes civiles fixes. Nouvel An (1er janvier), Fête de la Souveraineté nationale et des Enfants (23 avril), Fête du Travail et de la Solidarité (1er mai), Commémoration d'Atatürk, Fête de la Jeunesse et des Sports (19 mai), Journée de la Démocratie et de l'Unité nationale (15 juillet), Journée de la Victoire (30 août), Fête de la République (29 octobre). Ce sont de simples règles de date.
- Fêtes religieuses mobiles. Le Ramazan Bayramı (3,5 jours) et le Kurban Bayramı (4,5 jours) sont fixés selon le calendrier lunaire hégirien et se déplacent chaque année grégorienne. En 2026, le Ramazan Bayramı se déroule du 20 mars (demi-journée) au 23 mars ; en 2027, il commence vers le 10 mars. Le Kurban Bayramı en 2026 se déroule du 27 mai (demi-journée) au 31 mai ; en 2027, vers le 17 mai.
La règle de la demi-journée compte. Le Conseil des ministres déclare régulièrement la journée ouvrée précédant un bayram comme demi-journée officielle (arefe), où les administrations publiques ferment à 13h00. Les service desks du secteur privé varient — certains suivent la demi-journée gouvernementale, d'autres observent une journée complète, d'autres ferment entièrement. Quelle que soit la politique suivie par votre organisation, le calendrier SLA doit l'encoder explicitement. Une demi-journée n'est pas « la moitié des heures ouvrées » ; c'est une fenêtre précise qui commence à l'heure d'ouverture habituelle et se termine à 13h00.
Par-dessus tout cela, la présidence turque déclare parfois un jour férié ad hoc — le lendemain d'une victoire nationale de football, un jour de deuil national décrété en urgence, ou un jour de pont entre une fête fixe et un week-end. Ces jours ne peuvent pas être préchargés dans un quelconque calendrier. Le modèle de calendrier SLA doit permettre l'insertion d'un jour férié ponctuel avec 24 heures de préavis, sans recalculer l'historique.
Tout calendrier SLA qui exige d'un ingénieur qu'il redéploie du code pour ajouter un jour férié échouera dès sa première année d'exploitation. Le calendrier doit être une donnée, pas une configuration.
2. Les modèles d'équipes ne sont pas des « heures ouvrées »
Un centre d'opérations réseau 24/7 n'a pas d'heures ouvrées. Il a des équipes. Le calendrier SLA d'un service desk 24/7 devrait être entièrement différent de celui d'un service desk du lundi au vendredi. Et dans la plupart des organisations réelles, les deux coexistent — le NOC 24/7 traite les incidents d'infrastructure P1 tandis qu'un desk 09h-18h traite les demandes N1. Vous ne pouvez pas utiliser un seul calendrier pour les deux.
Les trois modèles d'équipes que nous modélisons le plus souvent :
- Équipe de jour standard. Lun-ven, 09h00 à 18h00, avec une fenêtre de déjeuner d'une heure qui ne met pas l'horloge SLA en pause (les techniciens se chevauchent volontairement sur le déjeuner).
- Journée étendue. Dim-jeu (pour les service desks du secteur financier dont l'activité suit une semaine dimanche-jeudi), 07h00 à 21h00.
- Rotation en continu. Trois équipes en 24/7 avec relèves à 08h00, 16h00 et 00h00. L'horloge SLA tourne en continu ; la relève est invisible pour le client.
Le bon modèle de calendrier s'attache à la politique SLA, pas au service desk dans son ensemble. Un incident d'infrastructure P1 est mesuré par rapport au calendrier 24/7 ; une demande P4 « merci de m'ajouter à la boîte mail du groupe » est mesurée par rapport au calendrier 09h-18h. Même organisation, deux calendriers, routage ticket par ticket.
3. L'absence des techniciens — le débat que personne ne veut avoir
Voici la question qui finira, tôt ou tard, par surgir en réunion de revue SLA : un ticket P2 a été assigné à Ayşe le vendredi après-midi. Ayşe a pris le lundi suivant en congé annuel. L'horloge SLA a continué de tourner. Elle l'a résolu le mardi matin, quatre heures ouvrées après son retour, et le rapport indique qu'elle a violé le SLA. Est-ce juste ?
Deux écoles de pensée :
- Le point de vue du client. Le client ne sait pas, et ne se soucie pas, qu'Ayşe était en congé. Le SLA promet une réponse en X heures ouvrées ; la réponse a été tardive ; le SLA a été violé. Cause racine : le routage aurait dû détourner le ticket d'Ayşe au moment de la demande de congé.
- Le point de vue de l'équipe. Si l'absence des techniciens ne met pas le SLA en pause, alors les service desks ayant un fort taux d'utilisation des congés paraissent artificiellement moins performants que les desks qui découragent les congés. C'est une incitation perverse.
Notre recommandation, et le modèle que nous construisons par défaut :
- L'absence d'un technicien ne met pas le SLA en pause sur le ticket assigné.
- À la place, le système de calendrier déclenche une réassignation lorsque le congé d'un technicien commence alors que des tickets actifs figurent encore dans sa file.
- Le ticket réassigné conserve son SLA d'origine et son horloge d'origine.
- Le manager reçoit une alerte au moment de la demande de congé si le technicien a des tickets dont l'objectif SLA tombe pendant la période de congé.
Cela impose le bon comportement : la planification des congés relève de la responsabilité managériale, et le rapport SLA reflète l'expérience du client, pas l'organisation interne des effectifs. L'incitation de l'équipe est préservée, car les tickets sont déplacés, non parce que l'horloge est mise en pause.
4. Les heures silencieuses par utilisateur
Un concept distinct mais connexe : certaines organisations veulent promettre à un client « votre ticket recevra une réponse dans les quatre heures ouvrées » tout en promettant au technicien « vous ne recevrez pas de notifications push entre 22h00 et 07h00, même si le calendrier SLA est actif ». L'ITSM moderne doit modéliser ces deux notions séparément.
La distinction :
- Calendrier SLA = la promesse de l'entreprise envers le client. Régit quand l'horloge tourne.
- Calendrier de notification par utilisateur = la préférence personnelle push/email du technicien. Régit si le téléphone vibre.
Ces deux notions entreront en conflit. Un incident P1 ouvert à 03h00 sur un calendrier 24/7 constitue une véritable violation si personne ne le prend en charge. Si tous les techniciens d'astreinte ont désactivé leurs notifications, le ticket attend jusqu'à 07h00 et l'horloge de quatre heures du client expire. La réponse ne consiste pas à fusionner les deux concepts ; il faut modéliser la rotation d'astreinte comme un calendrier distinct qui prime sur les heures silencieuses personnelles pendant la fenêtre d'astreinte.
5. Multi-régions et fuseaux horaires
Une organisation ayant des bureaux à Istanbul, Ankara et Londres n'a pas une journée ouvrée — elle en a trois qui se chevauchent. Si le calendrier SLA est stocké dans l'heure locale du serveur, les transitions d'heure d'été casseront silencieusement les rapports deux fois par an. S'il est stocké en UTC, les heures ouvrées sembleront se décaler pour les utilisateurs dans d'autres fuseaux, à moins que l'interface ne soit conçue avec soin.
Notre règle : toutes les entrées de calendrier sont stockées en UTC, et chaque calendrier porte son propre fuseau horaire d'affichage. Le calcul SLA s'exécute en UTC ; l'interface se rend dans le fuseau horaire du calendrier. Les utilisateurs situés dans un fuseau différent voient toujours l'heure d'ouverture correcte pour le calendrier qu'ils consultent.
Un P1 signalé à 08h55 Europe/Istanbul sur un calendrier d'Istanbul est dans les heures ouvrées. Le même ticket, signalé à 08h55 Europe/London sur le calendrier de Londres, n'est pas encore dans les heures ouvrées (Londres ouvre à 09h00 GMT, soit 11h00 Europe/Istanbul en hiver, 12h00 en été). C'est le routage qui décide quel calendrier s'applique.
6. Fenêtres de changement d'urgence
La gestion des changements ajoute encore une complication. Un changement d'urgence sur un système de production peut exiger que le service desk mette en pause le SLA de tout ticket dont la résolution dépend de ce système. C'est le seul cas légitime de suspension SLA initiée par un manager.
La règle que nous mettons en œuvre :
- Un changement d'urgence est un objet de premier rang, avec une fenêtre de début et de fin.
- Tout ticket marqué comme dépendant du CI X, où le CI X est affecté par le changement, voit son horloge SLA mise en pause pour la durée de la fenêtre de changement.
- La pause est journalisée avec l'ID du changement, afin que la piste d'audit montre exactement quel ticket a été mis en pause pour quel changement.
- Lorsque le changement se clôture, tous les tickets en pause reprennent automatiquement.
Ce n'est pas un moyen de dissimuler des violations. C'est un moyen de modéliser le fait que la résolution était véritablement impossible pendant une coupure contrôlée.
Assembler le tout
Le modèle de calendrier complet, au niveau des entités, se présente ainsi :
| Entité | Objet | Exemple |
|---|---|---|
| WorkCalendar | La promesse de l'entreprise. Rattaché aux politiques SLA. | « Istanbul 09-18 », « NOC 24/7 », « Londres 09-17 » |
| WorkCalendarWeek | Fenêtre hebdomadaire récurrente par calendrier. | Lun-ven, 09h00-18h00 Europe/Istanbul |
| WorkCalendarHoliday | Exception jour complet ou demi-journée. S'applique une fois. | 10-03-2027 Ramazan Bayramı Jour 1 (fermeture complète) |
| WorkCalendarOverride | Règle ponctuelle insérée avec un préavis court. | 14-11-2026 jour de pont, fermé |
| OnCallRotation | Qui est joignable par équipe ; prime sur les heures silencieuses personnelles. | Ayşe nuit du lundi, Mehmet nuit du mardi, ... |
| UserSilentHours | Préférence personnelle de notification. | Bora : pas de push 22h00-07h00 sauf astreinte |
| SlaPauseWindow | Pause explicite déclenchée par un changement d'urgence ou une transition de statut. | CI-4728 changement n° 331 : pause du 19-09-2026 20h00 à 22h00 |
Ce sont des préoccupations distinctes, qui interagissent de manière prévisible. Le calcul SLA lit WorkCalendar plus WorkCalendarHoliday plus WorkCalendarOverride plus SlaPauseWindow. La couche de notification lit OnCallRotation plus UserSilentHours. Les rapports peuvent être filtrés par calendrier, par motif de pause ou par cause de violation — car chaque information est stockée, et non déduite.
Pourquoi cela compte pour les rapports
Un calendrier bien conçu répond à la question qui revient toujours lors de la deuxième ou troisième revue trimestrielle : pourquoi le ticket n° 4728 a-t-il été en violation ? La réponse doit être plus qu'un simple « c'est comme ça ». Idéalement, ouvrir le ticket affiche le panneau SLA, et ce panneau montre exactement quel calendrier a été appliqué, quelles fenêtres étaient ouvertes, quelles pauses ont eu lieu, et combien de minutes ouvrées se sont écoulées avant la réponse. Si la pause était liée à un changement, l'ID du changement est lié. Si le technicien était en congé et que le ticket a été réassigné, la réassignation apparaît dans la chronologie.
L'intérêt de bien modéliser cela n'est pas le perfectionnisme. C'est que les rapports SLA sont scrutés. Quand le DSI demande pourquoi le taux de conformité P2 a chuté, l'équipe d'exploitation dispose soit d'une réponse défendable, avec les tickets, calendriers et pauses précis qui expliquent l'évolution — soit elle n'en a pas, et le rapport SLA devient un objet de doute plutôt qu'un outil.
L'implémentation LinaDesk, en bref
LinaDesk modélise chacune des entités du tableau ci-dessus comme des agrégats de premier rang du domaine. WorkCalendar est l'ancrage ; WorkCalendarHoliday et WorkCalendarOverride sont des enregistrements enfants ; SlaPolicy référence un WorkCalendarId. Le calcul SLA est une fonction pure des transitions de statut d'un ticket et des entités de calendrier visibles à chaque transition. Comme les pauses sont stockées sous forme d'enregistrements explicites, rejouer le calcul SLA pour n'importe quel ticket historique produit aujourd'hui la même réponse que le jour de sa clôture — ce que les équipes d'audit attendent, et ce qui n'est pas vrai des systèmes ITSM qui recalculent par rapport au calendrier actuel.
Le ticket du Ramazan Bayramı évoqué en ouverture de cet article n'est pas, dans ce modèle, une violation. Le ticket est ouvert à 16h55 le dernier jour ouvré avant le Bayram. Le WorkCalendarHoliday des quatre jours de Bayram place le calendrier en fermeture. L'horloge SLA ne décompte que les cinq minutes ouvrées restantes avant 17h00 ce vendredi-là, puis reprend à 09h00 le premier jour ouvré après le Bayram. La fenêtre de réponse est préservée.
Découvrez le modèle de calendrier dans la démo
Le panneau de démo LinaDesk propose trois calendriers préconfigurés, un jour férié en plein Bayram, et une fenêtre de pause pour changement d'urgence délibérée — pour que vous puissiez voir comment le rapport SLA gère chaque cas.
Ouvrir le panneau de démo