SLA dans Redmine 5.1 : sélection et personnalisation de plugins | Guide

SLA dans Redmine 5.1 : Analyse des plugins non fonctionnels et la voie vers la personnalisation

En l'absence de métriques automatisées dans la gestion des tâches, les managers sont contraints de surveiller manuellement les délais, ce qui entraîne des erreurs et une efficacité réduite. Pour les entreprises utilisant Redmine 5.1, la mise en œuvre d'un SLA (accord de niveau de service) est d'une importance critique. Cependant, la recherche d'une solution prête à l'emploi parmi les plugins a révélé de sérieux problèmes de compatibilité et de fonctionnalité.

Mise en place d'un environnement de test dans Docker

Pour tester les plugins en toute sécurité sans risquer le système de production, un environnement de test isolé a été déployé à l'aide de Docker. La configuration incluait des conteneurs séparés pour Redmine et PostgreSQL, une version fixe de Redmine 5.1, et un accès uniquement via localhost. La solution clé consistait à mapper des répertoires locaux pour les fichiers et les plugins, évitant ainsi de reconstruire l'image à chaque modification.

Exemple de configuration docker-compose.yml :

services:
   postgres:
     image: postgres:16
     volumes:
       - db_data:/var/lib/postgresql/data
     environment:
       POSTGRES_USER: "redmine"
       POSTGRES_PASSWORD: "password"
       POSTGRES_DB: "redmine"
       PGDATA: "/var/lib/postgresql/data"
     restart: always
   redmine:
     image: redmine:5.1
     ports:
       - 80:3000
     volumes:
       - ./local-files:/usr/src/redmine/files
       - ./local-plugins:/usr/src/redmine/plugins
     depends_on:
       - postgres
     environment:
       REDMINE_DB_POSTGRES: "postgres"
       REDMINE_DB_USERNAME: "redmine"
       REDMINE_DB_PASSWORD: "password"
       REDMINE_DB_DATABASE: "redmine"
     restart: no
     

volumes:
  redmine_data:
  db_data:  

L'environnement a été lancé avec la commande docker-compose up -d. Après un démarrage réussi (aucune erreur n'est survenue), l'auteur s'est connecté à l'interface web (login : admin, password : admin) et a préparé des données de test : trackers, un projet et des issues. Avant d'installer les plugins, une sauvegarde de la base de données a été créée via l'export de volume dans Docker Desktop.

Méthodologie de test des plugins

Chaque plugin a été testé individuellement pour écarter les conflits. Le processus impliquait trois étapes :

• Copie du dossier du plugin vers le répertoire ./local-plugins sur la machine hôte.
• Installation des dépendances via bundle install à l'intérieur du conteneur Redmine.
• Exécution des migrations (si nécessaire) avec la commande rake redmine:plugins:migrate.

Pendant l'installation des dépendances, des problèmes typiques sont apparus avec des gems manquantes, par exemple :

Could not find gem 'business_time (>= 0.13.0)'
Could not find gem 'holidays (>= 7.1.0)'

La solution consistait à installer manuellement les composants manquants :

gem install business_time
gem install holidays

Cette étape était obligatoire pour la plupart des solutions testées.

Analyse de la compatibilité des plugins avec Redmine 5.1

Huit plugins correspondant à la fonctionnalité de contrôle SLA ont été testés. Exigences clés pour la solution :

• Surveillance du temps de réponse aux issues.
• Surveillance du temps pour résoudre complètement les issues.
• Possibilité de filtrer les issues par paramètres spécifiés.

Résultats des tests :

• reporting_sla (dernière mise à jour 18.11.2025) : incompatible avec les versions Rails/Redmine. Nécessite une modification profonde.
• likehopper/redmine_sla (12.02.2026) : ne fonctionne qu'avec PostgreSQL, mais Oracle a été utilisé dans l'environnement de test. Haute performance grâce au déchargement de la logique vers la BD.
• redmine_issue_sla (29.01.2018) : plugin obsolète pour Redmine 3.x, ne démarre pas sur la version 5.1.
• redmine_sla_timer (12.07.2020) : aucune description et incompatible avec la version actuelle.
• redmine_sla_ola (12.07.2020) : la seule option fonctionnelle, mais nécessite une configuration supplémentaire — ajout de champs personnalisés products et first_reply.
• agile (03.12.2025) : gère les tâches de gestion de projet mais ne fournit pas de fonctionnalité SLA.
• RedmineUP Helpdesk : solution commerciale avec support, mais ne couvre pas tous les scénarios et nécessite un budget.

Recommandations pour la mise en œuvre SLA

Après analyse des options, aucune solution prête à l'emploi « out-of-the-box » pour Redmine 5.1 n'a été trouvée. Les organisations ont trois voies possibles :

• Acheter une solution commerciale (p. ex., RedmineUP). Avantages : support, mises à jour régulières. Inconvénients : restrictions de politique de sécurité, inadéquation avec les exigences spécifiques.
• Modifier un plugin existant (redmine_sla_ola). Avantages : fonctionnalité principale déjà implémentée. Inconvénients : besoin de personnalisation pour s'adapter aux processus, risques lors des mises à jour de Redmine.
• Développer un plugin personnalisé. Avantages : correspondance exacte aux processus métier, pas de fonctionnalités inutiles. Inconvénients : investissement en temps (estimé 3-5 jours pour une version démo).

Pour les organisations avec des processus SLA strictement réglementés, ignorer l'automatisation conduit à plus de délais manqués. Lors du choix d'une voie de mise en œuvre, considérer non seulement les coûts actuels mais aussi le TCO (coût total de possession). Les solutions commerciales peuvent nécessiter des frais de licence annuels, tandis que la personnalisation résout le problème une fois pour toutes avec des coûts récurrents minimaux.

Points clés à retenir

• La compatibilité de version est critique : La plupart des plugins n'ont pas été mis à jour pour Redmine 5.1, les rendant non fonctionnels sans modification.
• Configuration supplémentaire requise : Même les plugins « fonctionnels » nécessitent une personnalisation (p. ex., ajout de champs), augmentant l'effort.
• Docker est essentiel : Tester dans un environnement isolé empêche les dommages au système de production et accélère les rollbacks.
• Les dépendances Gem sont un problème courant : Les gems de logique métier manquantes (business_time, holidays) nécessitent une installation manuelle, compliquant le processus.
• Personnalisation vs solutions commerciales : Avec un budget limité et des exigences claires, développer son propre plugin économise des ressources à long terme.

— Editorial Team