Redmine SLA

Support

5.0 (0)·New installations

Un SLA de quatre heures ne fait pas quatre heures. Réponse et résolution mesurées en temps ouvré — vos calendriers, vos jours fériés, vos règles de pause — avec alertes, seuil critique et détection des dépassements.

$199 / un serveur

Guide utilisateur

Plusieurs serveurs: $399

Remboursement sous 5 jours ouvrés12 mois de mises à jourSources incluses

Le tableau de bord SLA d’un projet Redmine : un anneau de conformité à 75 % avec la première réponse à 80 % et la résolution à 66,7 %, un délai moyen de réponse de 35 minutes et un délai moyen de résolution de 12 heures 40 minutes, des compteurs pour 10 demandes SLA dont 6 en cours, 2 menacées, 3 dépassées, 1 en pause et 2 terminées, une barre d’état de santé à code couleur, des tableaux des demandes menacées et dépassées avec leurs échéances, et la conformité par politique SLA. — Projet › SLA La conformité par objectif, des compteurs en direct, et chaque demande menacée ou dépassée avec son échéance.

Redmine: 4, 5, 6 et 7
Objectifs: 4 horloges indépendantes
Bases de données: PostgreSQL, MySQL, MariaDB, SQLite
Rapports: 4, avec export CSV
Gems supplémentaires: Aucune
Fichiers du cœur modifiés: Aucune

Les heures ouvrées, correctement

Plannings hebdomadaires avec pauses en milieu de journée, fuseau horaire par calendrier, jours fériés fixes et récurrents, et jours travaillés exceptionnels. Heure murale à travers les changements d'heure : 09:00–18:00 reste 09:00–18:00.

Quatre horloges indépendantes

Première réponse, prise en charge, résolution et clôture — chacune avec son objectif, son état et son comportement de pause. Ne configurez que celles que vous utilisez.

En attente du client

Des règles par statut décident quelles horloges s'arrêtent. « En attente du client » peut geler la résolution pendant que la première réponse continue — celle-là reste votre dû.

Des conditions en toutes lettres

Ciblez par projet, tracker, statut, catégorie, assigné, groupe, client ou n'importe quel champ personnalisé — par noms réels, jamais par identifiants.

Alerte, critique, dépassement

Les seuils se déclenchent avant l'échéance, pas après. L'envoi passe par le mailer de Redmine, et un index unique empêche qu'une alerte parte deux fois.

Une conformité défendable

Conformité par objectif, distributions des temps de réponse et de résolution avec médiane et valeurs extrêmes, et un tableau des dépassements avec échéance, date réelle et retard.

Votre horloge s’arrête quand votre équipe rentre chez elle

Soustraire deux horodatages vous pénalise pour les week-ends. Redmine SLA parcourt votre calendrier ouvré et ne compte que les minutes où vous êtes ouvert : un objectif de quatre heures ouvert tard le vendredi arrive à échéance le lundi, pas le soir même.

Un objectif de résolution de quatre heures sur un calendrier du lundi au vendredi, de 09:00 à 18:00
Demande ouverte	Temps ouvré compté	Échéance	Temps réel
Mardi 09:30	4h, sans interruption	Mardi 13:30	4 heures
Vendredi 17:00	1h le vendredi, 3h le lundi	Lundi 12:00	67 heures
Vendredi 17:00, lundi férié	1h le vendredi, 3h le mardi	Mardi 12:00	91 heures
À toute heure, sur un calendrier 24×7	4h écoulées	Quatre heures plus tard	4 heures

Les calendriers gèrent les journées en deux temps, leur propre fuseau horaire, les jours fériés ponctuels et récurrents, et les jours ouvrés exceptionnels.

Quatre horloges, chacune avec ses règles

Ne définissez que les objectifs que vous promettez vraiment. Chacun démarre, se met en pause et s’arrête sur son propre événement : « en attente du client » peut donc geler la résolution pendant que la première réponse continue de tourner.

Première réponse : quelqu’un a répondu

S’arrête au premier commentaire public de toute personne autre que l’auteur. Ce qui compte comme une réponse se définit par politique.

Prise en charge : quelqu’un s’en occupe

S’arrête quand la demande est assignée, ou quand elle atteint un statut que vous choisissez.

Résolution : le problème est corrigé

S’arrête quand la demande atteint un statut fermé, ou l’un des statuts de résolution que vous choisissez.

Clôture : le ticket est terminé

Un objectif distinct pour la fermeture définitive, pour les équipes qui résolvent d’abord et confirment ensuite avec le client.

Ça ressemble à Redmine, parce que c’est Redmine

Pas d’iframe, pas d’application séparée, pas de seconde connexion. Ce sont de vrais écrans du plugin sur Redmine 7.0, montrant un projet de démonstration avec des demandes dans chaque état SLA.

Agents : le panneau SLA sur chaque demande

Une ligne par objectif, avec son état, le temps restant, la part de l’objectif consommée et l’échéance exacte.

Une anomalie Redmine, Checkout page intermittently times out, avec un panneau SLA sous ses attributs. Le panneau est marqué Menacé et affiche la politique SLA demo - Critical sur un calendrier 24x7 en UTC. La première réponse est Menacée, avec quelques minutes restantes et un anneau de progression au-dessus de 80 %. La résolution est Saine, avec plus de trois heures restantes. Les liens vers la chronologie SLA et le recalcul se trouvent en dessous. — Page de la demande La première réponse est menacée à quelques minutes de l’échéance, alors que la résolution est encore saine. Le compte à rebours se met à jour en direct, et le panneau indique la politique, le calendrier et le fuseau horaire qui servent de référence.

Le panneau SLA d’une demande en pause : première réponse terminée en 5 minutes pour un objectif de 30 minutes, et résolution en pause à 50 % avec 2 heures consommées sur 4. — En pause L’agent a répondu en 5 minutes, puis la demande est passée à un statut d’attente. La résolution est gelée à 2h sur 4h jusqu’à la réponse du client.

La chronologie SLA de la même anomalie : horloges démarrées pour la première réponse et la résolution, SLA démarré, horloge de première réponse terminée, SLA affecté à la politique Critical, et horloge de résolution mise en pause, chaque étape avec son horodatage et l’utilisateur qui l’a déclenchée. — Chronologie SLA Chaque démarrage, achèvement, pause et dépassement dans l’ordre, avec son auteur. C’est la trace que vous montrez quand un client conteste un chiffre.

Responsables d’équipe : la file d’attente, triée selon ce qui va bientôt mal tourner

Filtrez par statut, état de santé, politique ou dépassement, triez par échéance, exportez en CSV. Les mêmes champs sont des filtres et des colonnes dans la liste des demandes de Redmine.

La liste des demandes SLA avec des filtres pour le statut SLA, l’état de santé SLA, la politique et le dépassement. Dix demandes sont listées avec le projet, la politique SLA, le statut, un badge d’état de santé coloré (en pause, terminé, dépassé, critique, menacé ou sain), le résultat ou le temps restant pour la première réponse et la résolution, et l’échéance SLA. — Demandes SLA Dix demandes couvrant tous les états de santé : en pause, terminé, dépassé, critique, menacé et sain, chacune avec le temps restant ou le retard pour les deux objectifs.

Managers : des rapports que vous pouvez présenter à un client

Conformité, temps de réponse, temps de résolution et dépassements, filtrés par période, politique, tracker et priorité. Chaque rapport s’exporte en CSV.

La page des rapports SLA sur l’onglet conformité, avec des raccourcis de période allant de 7 jours à tout l’historique, des filtres pour la politique SLA, le tracker et la priorité, et une synthèse de conformité à 75 % avec la première réponse à 80 % et la résolution à 66,7 %. — Conformité Objectifs atteints par rapport aux objectifs mesurés, répartis entre première réponse et résolution.

Le rapport de temps de réponse : médiane de 10 minutes, moyenne de 35 minutes, minimum de 5 minutes, maximum de 2 heures sur 5 réponses mesurées, et un histogramme de distribution avec des tranches allant de 15 minutes à plus de 3 jours. — Temps de réponse Médiane, moyenne, plus rapide et plus lent, plus une distribution qui montre où se trouvent les valeurs extrêmes.

Le rapport des dépassements, listant quatre dépassements sur la période avec la demande, le projet, la politique SLA, la priorité, l’assigné, le type de dépassement (première réponse ou résolution), l’échéance SLA, la date réelle et la durée du dépassement. — Dépassements Quel objectif a été manqué sur quelle demande, quand il arrivait à échéance, quand il a réellement été atteint, et de combien il a été dépassé.

Administrateurs : des politiques écrites en langage clair

« Quand la Priorité de la demande est l’une de Urgent, Immédiat. » Les conditions utilisent de vrais noms choisis dans des listes, pas des identifiants d’enregistrement. Les durées acceptent 30, 4h ou 1d 4h.

Le formulaire de politique SLA : nom, description, active, par défaut et position, puis les objectifs de première réponse, prise en charge, résolution et clôture, un calendrier ouvré et un fuseau horaire, et un tableau de conditions où la Priorité est l’une de Urgent et Immédiat. — Objectifs et conditions Les quatre objectifs, le calendrier sur lequel ils sont mesurés, et les conditions qui déterminent à quelles demandes la politique s’applique.

La section des événements du formulaire de politique : le SLA démarre à la création de la demande, la première réponse s’arrête au premier commentaire public et ignore les mises à jour de l’auteur de la demande, la prise en charge s’arrête quand la demande est assignée, et la résolution et la clôture s’arrêtent quand la demande atteint un statut fermé ou l’un des statuts sélectionnés. — Événements Choisissez ce qui démarre chaque horloge et ce qui l’arrête.

Les seuils du formulaire de politique fixent l’alerte à 75 % et le niveau critique à 90 % avec les notifications activées, au-dessus d’un tableau de règles de pause où un statut met en pause la Résolution et la Clôture, mais pas la Première réponse ni la Prise en charge. — Seuils et règles de pause Alertez à 75 %, passez en critique à 90 %, et cochez les objectifs que chaque statut gèle.

Les heures ouvrées d’un calendrier ouvré : de 09:00 à 18:00 du lundi au vendredi, week-ends vides, une seconde plage facultative par jour pour les journées en deux temps, et un raccourci pour appliquer du lundi au vendredi de 09:00 à 18:00. — Calendrier ouvré Des heures ouvrées par jour de la semaine, une seconde plage pour les journées en deux temps, un fuseau horaire et des jours fériés, ou tout simplement 24×7.

L’onglet SLA de la configuration d’un projet Redmine : SLA activé, héritage du projet parent, calendrier ouvré, politique SLA et fuseau horaire par défaut, et des cases à cocher limitant les politiques SLA utilisables par le projet. — Configuration du projet Activez le SLA projet par projet, héritez du projet parent, remplacez le calendrier ou limitez les politiques applicables.

Exploitation : un seul endroit pour vérifier que tout fonctionne

La page d’administration SLA : une liste de contrôle de mise en place pour les calendriers ouvrés, les politiques, les projets activés, les règles de pause globales et le traitement en arrière-plan avec l’heure de la dernière exécution, une vue d’ensemble avec des compteurs et une conformité de 75 %, et des liens vers les politiques, les calendriers, les jours fériés, les règles de pause, les modèles d’e-mail, les paramètres, les rapports, les demandes SLA et le journal d’audit. — Administration › SLA Une liste de contrôle qui vous indique ce qui manque, la dernière exécution de la tâche d’arrière-plan, et une vue d’ensemble en direct.

Le journal d’audit SLA : un tableau filtrable indiquant quand chaque SLA a été affecté ou recalculé, par quel utilisateur, sur quel objet, avec des détails tels que le nom de la politique et l’identifiant de la demande. — Journal d’audit Qui a affecté, modifié ou recalculé quel SLA, et quand.

Tout ce dont un centre de support débat vraiment

Les litiges portent rarement sur le fait qu’un ticket était en retard. Ils portent sur les heures qui comptaient, sur le moment où l’horloge aurait dû s’arrêter, et sur l’objectif en vigueur à ce moment-là.

Les heures ouvrées, traitées sérieusement

Des horaires hebdomadaires avec journées en deux temps, un fuseau horaire par calendrier, des jours fériés fixes et récurrents et des jours ouvrés exceptionnels. 09:00 reste 09:00 lors des changements d’heure.

En attente du client

Des règles de pause par statut, globales ou par politique. Seul le temps ouvré est restitué : une pause pendant le week-end ne coûte donc rien.

Alerte, critique, dépassement

Les seuils se déclenchent avant l’échéance. Chaque notification est envoyée une seule fois via le système d’e-mail de Redmine, avec des modèles modifiables par événement et par langue.

La bonne politique pour chaque demande

Ciblez par projet et sous-projets, tracker, priorité, statut, catégorie, auteur, assigné, groupe ou n’importe quel champ personnalisé. Quand plusieurs politiques correspondent, la position la plus basse l’emporte.

Dans la liste des demandes

Politique SLA, statut, état de santé, dépassement, échéance et temps restant comme filtres et colonnes dans la liste des demandes de Redmine : triables, regroupables et exportables.

Les modifications ne réécrivent pas l’historique

Chaque SLA conserve un instantané de la politique avec laquelle il a démarré. Modifier un objectif le trimestre prochain ne touche pas aux chiffres du trimestre dernier. Le recalcul est une action délibérée de l’administrateur.

Ce qui arrive à une demande

Une anomalie critique ouverte un vendredi après-midi, sur un calendrier du lundi au vendredi de 09:00 à 18:00, avec un objectif de première réponse de 30 minutes et un objectif de résolution de quatre heures.

Quand	Événement	Ce que fait le plugin
Ven 15:00	Ouverte	La première politique correspondante est appliquée et ses horloges démarrent. Il reste trois heures ouvrées aujourd’hui, donc une heure est reportée à lundi.
Ven 15:20	Première réponse	Un commentaire public d’un agent arrête l’horloge de première réponse à 20 minutes, dans les limites de son objectif de 30 minutes.
Ven 16:00	En attente	La résolution se met en pause. Quand le client répond lundi, l’échéance est décalée d’exactement le temps ouvré perdu.
Lundi	Alerte à 75 %	L’e-mail d’alerte part tant qu’il est encore temps d’agir.
Lundi	Résolue	Le temps consommé et l’atteinte ou non de l’objectif sont enregistrés, et ne changent plus jamais.

L’état de santé SLA sur chaque demande, avec des seuils définis par politique
Consommé	État de santé
Moins de 75 %	Sain
75%	Menacé
90%	Critique
100%	Dépassé
Suspendu	En pause
Objectif atteint	Terminé

Du JSON pour chaque écran

Une API JSON en lecture seule couvre tout ce que montrent les écrans. Elle s’authentifie avec une clé d’API Redmine classique et respecte les mêmes permissions que les pages.

Méthode	Point d’accès	Renvoie
GET	/sla/issues/:id.json	Le SLA d’une demande
GET	/sla/issues.json	Demandes SLA, filtrables
GET	/projects/:id/sla/issues.json	Demandes SLA d’un projet
GET	/sla/timeline/:id.json	Chronologie d’une demande
GET	/sla/dashboard.json	Compteurs du tableau de bord et conformité
GET	/sla/reports/:report.json	L’un des quatre rapports
GET	/sla/policies.json	Politiques et leurs objectifs
GET	/sla/calendars.json	Calendriers et heures ouvrées

Lire le SLA d’une demande

Envoyez votre clé dans l’en-tête X-Redmine-API-Key. La réponse contient la politique, le calendrier, l’état de santé global, et une entrée par objectif avec son état, son échéance et le temps consommé. Servez-vous-en pour afficher des comptes à rebours SLA sur un écran mural, ou pour alimenter vos propres rapports en chiffres de conformité.

Six permissions, accordées par rôle

SLA est un module de projet Redmine standard. Activez-le sur les projets que vous mesurez et ne donnez à chaque rôle que ce dont il a besoin. Les administrateurs Redmine disposent toujours des deux permissions globales.

Permission	Portée	Ce qu’elle autorise
view_sla	Projet	Voir le panneau SLA sur les demandes, la liste des demandes SLA et la chronologie
view_sla_dashboard	Projet	Voir le tableau de bord SLA
view_sla_reports	Projet	Voir et exporter les rapports SLA
manage_sla	Projet	Modifier les paramètres SLA du projet et recalculer le SLA d’une demande
manage_sla_policies	Globale	Créer et modifier les politiques et les règles de pause
manage_sla_calendars	Globale	Créer et modifier les calendriers et les jours fériés

Fonctionne là où votre Redmine tourne déjà

Environnement	Statut	Remarques
Redmine 7.x	Compatible	Testé sur Redmine 7.0 avec Rails 8.1 et Ruby 3.4.2. Les captures d’écran de cette page proviennent de la version 7.0.
Redmine 6.x	Compatible
Redmine 5.x	Compatible	Nécessite la tâche d’assets des plugins après la migration
Redmine 4.x	Compatible	4.0 est la version minimale déclarée par le plugin
Bases de données	Compatible	PostgreSQL, MySQL, MariaDB et SQLite, sans SQL propre à une base de données
Gems supplémentaires	Aucune	Ni Redis, ni Sidekiq. Une entrée cron ou un timer systemd lance la vérification en arrière-plan.
Cœur de Redmine	Intact	Aucun fichier du cœur n’est modifié : les mises à jour de Redmine ne sont pas affectées

Installation en trois étapes

Nécessite un accès shell et la possibilité de lancer des tâches rake. Sauvegardez toujours avant d'installer un plugin.

Décompressez dans votre dossier de plugins

cd /path/to/redmine
# the package arrives by email, or from your download link
unzip redmine_sla-1.0.0.zip -d plugins/

Migrez et redémarrez

RAILS_ENV=production bundle exec rake redmine:plugins:migrate
# Redmine 4 and 5 only (Redmine 6+ serves plugin assets directly)
RAILS_ENV=production bundle exec rake redmine:plugins:assets
touch tmp/restart.txt   # or systemctl restart redmine

Planifiez les alertes et les dépassements

# every five minutes: evaluate timers that are due, safe to run repeatedly
*/5 * * * * cd /path/to/redmine && RAILS_ENV=production bundle exec rake redmine_sla:process >> log/sla.log 2>&1

Activez-le dans Redmine

# Administration → SLA → create the default business calendars, then follow the checklist
# Administration → SLA → Policies → write one policy: targets, calendar, conditions
# Project → Settings → Modules → tick SLA for each project you measure
# Administration → Roles and permissions → grant the SLA permissions

Le plugin modifie-t-il des fichiers du cœur de Redmine ?

Non. Il utilise l’API de plugins, les hooks de vue et le système de permissions de Redmine. Là où Redmine n’offre pas de hook, le plugin ajoute de petits patchs qui ne font que compléter le comportement existant. Aucun fichier de Redmine n’est modifié : la mise à jour de Redmine n’est donc pas affectée.

Qu’arrive-t-il aux SLA existants quand je modifie une politique ?

Rien ne change. Chaque SLA fige la politique avec laquelle il a été créé : objectifs, seuils, événements et heures ouvrées. Le chiffre de conformité du trimestre dernier reste exactement tel qu’il a été communiqué. Appliquer une politique modifiée aux enregistrements existants est une action délibérée de l’administrateur.

Faut-il Redis, Sidekiq ou des gems supplémentaires ?

Non. Le plugin n’ajoute aucune dépendance de gem et ne présuppose aucun système de jobs. Les alertes et les dépassements sont détectés par une seule commande, que vous pouvez relancer sans risque. Planifiez-la avec cron, un timer systemd ou l’outil que vous utilisez déjà.

Des clients ou des projets différents peuvent-ils avoir des SLA différents ?

Oui. Rédigez une politique par engagement et donnez-lui des conditions : projet, tracker, priorité, catégorie, assigné, groupe ou n’importe quel champ personnalisé. Chaque projet peut aussi remplacer le calendrier et le fuseau horaire, et limiter les politiques qui peuvent s’y appliquer.

Et les demandes qui existaient avant l’installation ?

Les nouvelles demandes reçoivent un SLA automatiquement. Pour les demandes existantes, une tâche de rattrapage affecte un SLA à chaque demande qui n’en a pas encore, pour tous les projets ou pour un seul.

La désinstallation est-elle sans risque ?

Oui. Supprimer le dossier du plugin conserve chaque ligne SLA dans la base de données. Seule une migration explicite vers la version zéro supprime les tables. Effacer les données de suivi tout en laissant le plugin installé est une action distincte, soumise à confirmation et désactivée par défaut.

Les captures d’écran sont-elles réelles ?

Ce sont de vrais écrans du plugin sur Redmine 7.0, issus du projet de démonstration que le plugin peut générer pour vous : dix demandes, une dans chaque état SLA. Les chiffres montrent ce que vous verrez pour vos propres projets, pas les résultats d’un client.