Avez-vous vraiment besoin des fonctions de Redmine ? 10 points à vérifier avant de l’adopter ou de le garder

Publié le : 4 novembre 2026

Redmine est un excellent outil de gestion de projets, utilisé depuis de nombreuses années. Il est gratuit et open source, et couvre tout le nécessaire, de la gestion des tickets au suivi du temps en passant par l’intégration aux dépôts.

Faire tourner Redmine suppose toutefois de préparer un serveur capable d’exécuter Ruby, puis de l’entretenir. Il ne passe généralement pas sur un hébergement mutualisé : il faut donc un VPS ou un service cloud spécialisé (voir le détail dans « Peut-on installer Redmine sur un hébergement mutualisé ? »).

Cet effort en vaut-il la peine ? Tout dépend de la part de Redmine que vous utilisez vraiment. Cet article passe en revue 10 fonctions propres à Redmine et vous aide à vérifier si votre équipe a besoin de chacune. Si vous utilisez déjà Redmine, il montre aussi comment vérifier ce que vous utilisez aujourd’hui.

Remarque : cet article est rédigé par le développeur de GeckoFlag. Les fonctions de Redmine ont été vérifiées dans les guides officiels le 24 octobre 2026 (dernière version : 7.0.2).

Les fonctions que tous les outils ont n’aident pas à trancher

Commençons par écarter les fonctions qui ne justifient pas, à elles seules, le choix de Redmine.

Création de tickets, statuts, assignés, échéances, commentaires, wiki, partage de fichiers, diagramme de Gantt. La plupart des outils de gestion de projets actuels proposent tout cela. Si les fonctions qu’utilise votre équipe restent dans ce périmètre, on ne peut pas dire qu’il « faut absolument Redmine ».

Les vraies raisons de choisir Redmine sont les fonctions de la section suivante, que les autres outils laissent souvent de côté.

10 fonctions propres à Redmine

Pour chacune, nous voyons ce qu’elle permet, quand elle est utile, et les signes qui montrent que vous pouvez vous en passer. Comptez, au fil de la lecture, celles dont vous pensez avoir besoin.

1Suivi du temps et rapports

Ce qu’elle permet : vous pouvez saisir le temps passé par ticket ou par projet. Chaque saisie peut comporter une activité (conception, développement, réunions, etc.) et un commentaire. Vous pouvez aussi indiquer un temps estimé, et consulter la liste et les totaux dans l’écran « Temps passé » du projet.

Quand elle est utile : quand vous facturez au temps passé, que vous comparez estimations et temps réel pour mieux estimer la fois suivante, ou que vous suivez la charge de chaque membre en heures.

Vous pouvez vous en passerVous saisissez le temps, mais ne l’avez jamais totalisé ni exploité. Vous facturez un forfait par projet, sans lien avec le temps passé.

2Champs personnalisés

Ce qu’elle permet : vous pouvez ajouter vos propres champs aux tickets, aux projets et aux utilisateurs. Vous choisissez un format (texte, nombre, date, liste, etc.) et pouvez afficher des champs différents selon le tracker (type de ticket).

Quand elle est utile : quand une information doit être saisie pour chaque ticket, comme « nom du client », « navigateur concerné » ou « environnement où le problème s’est produit », et que vous voulez filtrer ou totaliser selon ce champ.

Vous pouvez vous en passerLes champs ajoutés restent vides sur beaucoup de tickets. L’écrire dans la description suffit.

3Workflows

Ce qu’elle permet : pour chaque combinaison de rôle et de tracker, vous décidez vers quels statuts un statut peut évoluer. Par exemple : « le rôle Développeur peut passer un bug en Résolu, mais seul le rôle Manager peut le passer en Fermé ». Vous pouvez aussi rendre des champs obligatoires ou en lecture seule selon le statut.

Quand elle est utile : quand vous avez un processus de validation établi et que sauter une étape pose problème. Elle convient aussi aux équipes qui doivent contrôler qui ferme les tickets, pour la gestion de la qualité ou les audits.

Vous pouvez vous en passerVous utilisez toujours les réglages par défaut de l’installation. Tout le monde peut changer un statut, et cela vous convient.

4Permissions détaillées par projet

Ce qu’elle permet : vous pouvez créer les rôles de votre choix et définir les permissions action par action : consulter, créer et modifier des tickets, saisir du temps, modifier le wiki, etc. Une même personne peut être Manager dans le projet A et en lecture seule dans le projet B.

Quand elle est utile : quand vous voulez donner un accès en lecture seule à des personnes extérieures, ou séparer ce que chaque service peut modifier.

Vous pouvez vous en passerTous les membres ont à peu près les mêmes permissions. Vous n’utilisez que les rôles par défaut (Manager, Développeur, Rapporteur).

5Relations entre tickets

Ce qu’elle permet : vous pouvez relier des tickets entre eux. En plus de « lié à », il existe notamment « doublon de », « bloque » et « précède / suit ». Tant qu’un ticket bloquant reste ouvert, le ticket bloqué ne peut pas être fermé. Si l’échéance d’un ticket précédent bouge, les dates du ticket suivant se décalent d’autant de jours.

Quand elle est utile : quand l’ordre du travail comporte de fortes dépendances, et que vous voulez suivre dans le planning l’effet d’un retard sur le reste.

Vous pouvez vous en passerÉcrire « après #123 » dans la description ou un commentaire suffit. Découper le travail en tickets parents et enfants vous suffit.

6Versions et roadmap

Ce qu’elle permet : vous pouvez créer des versions (jalons) comme « v2.0 » ou « Sortie d’avril » et y rattacher des tickets. L’écran Roadmap montre l’avancement de chaque version.

Quand elle est utile : quand vous avancez par versions livrées, comme pour un logiciel.

Vous pouvez vous en passerVous créez un projet par mission, et suivre les échéances à l’intérieur suffit.

7Intégration aux dépôts

Ce qu’elle permet : vous pouvez relier à un projet des dépôts Git ou Subversion, par exemple, et parcourir le code et l’historique des modifications à l’écran. Si vous indiquez un numéro de ticket dans un message de commit, le commit est lié au ticket ; selon la façon dont le message est rédigé, vous pouvez aussi changer le statut ou saisir du temps.

Quand elle est utile : quand une équipe de développement veut savoir quelle modification du code correspond à quel ticket.

Vous pouvez vous en passerVotre code est sur GitHub ou GitLab, et vous y reliez déjà les tickets. Votre équipe n’écrit pas de code.

8Création de tickets par e-mail

Ce qu’elle permet : les e-mails envoyés à une adresse donnée peuvent créer de nouveaux tickets ou ajouter des commentaires à des tickets existants.

Quand elle est utile : quand vous recevez par e-mail des demandes de clients ou des signalements de bugs et voulez les gérer directement sous forme de tickets.

Vous pouvez vous en passerVous recevez les demandes par un autre canal (formulaire ou outil de support). Qu’une personne transforme les e-mails en tickets à la main suffit.

Notez que cette fonction nécessite des réglages côté serveur de messagerie et un moyen de relever les e-mails régulièrement (cron, par exemple) sur votre serveur.

9API REST et intégrations externes

Ce qu’elle permet : une fois l’API REST activée, des programmes externes peuvent lire et écrire tickets, projets, utilisateurs, temps passé, etc.

Quand elle est utile : quand vous voulez la relier à d’autres systèmes internes, ou automatiser la création de tickets récurrents et les rapports.

Vous pouvez vous en passerPersonne dans l’équipe n’écrit de code d’intégration. Travailler depuis les écrans suffit.

10Extension par plugins

Ce qu’elle permet : vous pouvez installer des plugins pour ajouter des fonctions absentes du cœur de Redmine, comme un tableau Kanban, des checklists, la gestion de clients ou un service d’assistance. De nombreux plugins sont répertoriés sur le site officiel.

Quand elle est utile : quand les fonctions standard ne suffisent pas et que vous voulez construire des fonctions adaptées à votre activité.

Vous pouvez vous en passerVous n’avez installé aucun plugin. Ou vous en avez installé, n’avez pas pu suivre leurs mises à jour, et ils freinent désormais les mises à niveau de Redmine.

La compatibilité des plugins doit être vérifiée à chaque mise à niveau de Redmine lui-même. Ils sont pratiques, mais tenez compte de cette maintenance supplémentaire dans votre décision.

Vérifier ce que vous utilisez vraiment dans votre Redmine actuel

Si vous utilisez déjà Redmine, les écrans d’administration montrent si chaque fonction est réellement utilisée. Vous trouverez peut-être des fonctions configurées à l’installation que personne n’utilise vraiment. Les noms des écrans peuvent légèrement varier selon la version de Redmine et la langue choisie.

Fonction	Où vérifier	Ce qu’il faut regarder
1. Suivi du temps	« Temps passé » dans chaque projet	Y a-t-il des saisies récentes ? Quelqu’un regarde-t-il les totaux ?
2. Champs personnalisés	Administration → Champs personnalisés	Combien de champs existent. Sont-ils remplis dans la liste des tickets ?
3. Workflows	Administration → Workflow	A-t-il été modifié par rapport aux réglages par défaut ?
4. Permissions	Administration → Rôles et permissions	Avez-vous créé des rôles en plus de ceux par défaut ?
5. Relations	« Demandes liées » sur la page de chaque ticket	Combien de tickets ont des relations ?
6. Versions	« Roadmap » dans chaque projet	Avez-vous créé des versions et y avez-vous rattaché des tickets ?
7. Dépôts	Configuration de chaque projet → Dépôts	Un dépôt est-il enregistré, et les commits récents apparaissent-ils ?
8. E-mails entrants	Administration → Configuration → Emails entrants, et tâches planifiées sur le serveur	Y a-t-il des tickets créés par e-mail ?
9. API	Administration → Configuration → API	Le service web REST est-il activé ? Une intégration l’utilise-t-elle ?
10. Plugins	Administration → Plugins	Quels plugins sont installés, et chacun est-il utilisé ?

Les fonctions qui ressortent « non utilisées » dans ce tableau comptent comme « pas nécessaires » dans la vérification de la section suivante.

Ce que votre total vous indique

Raisonnez en nombre de fonctions, sur les 10, dont votre équipe a besoin.

3 ou plus : Redmine en vaut la peine

Votre équipe peut tirer pleinement parti des points forts de Redmine. Préparer et entretenir un serveur en vaut la peine. S’il ne passe pas sur un hébergement mutualisé, choisissez un VPS ou un service cloud spécialisé dans Redmine. La manière de choisir est expliquée dans « Peut-on installer Redmine sur un hébergement mutualisé ? ».

1 ou 2 : voyez si vous pouvez couvrir ces fonctions autrement

Si vous n’avez besoin que d’une ou deux fonctions, demandez-vous si vous pouvez les couvrir sans Redmine. Par exemple, si seul le suivi du temps compte, vous pouvez associer un tableur ou un outil dédié au suivi du temps à un autre outil. Si vous ne pouvez pas les couvrir, Redmine reste le choix sûr.

0 : un outil plus simple à configurer suffira très probablement

Si vous n’exploitez pas les points forts de Redmine, il y a peu de raisons de le choisir au prix d’un serveur à faire tourner. Si votre travail porte surtout sur les tickets, les échéances et les assignés, un outil plus simple à configurer s’installera peut-être plus facilement dans votre équipe.

Au-delà du total, un autre point compte : qui s’occupe du serveur. Si vous hébergez Redmine vous-même, la personne qui l’a installé prend aussi en charge les mises à jour et le dépannage. Demandez-vous si tout continuerait à fonctionner si cette personne partait.

Pour les équipes qui ont compté zéro

Pour finir, voici une option pour les équipes qui ont compté zéro : GeckoFlag, l’outil que nous développons.

Disons-le d’emblée : la plupart des 10 fonctions de cet article n’existent pas dans GeckoFlag. Il n’a ni suivi du temps, ni champs personnalisés, ni paramétrage des workflows, ni relations entre tickets, ni versions, ni intégration aux dépôts, ni création de tickets par e-mail, ni API externe, ni plugins, et il compte trois rôles : administrateur, membre et invité. Si vous en avez besoin, Redmine est le bon choix.

En revanche, GeckoFlag réunit les fonctions dont toute équipe a besoin, sous une forme utilisable sans se battre avec les réglages.

Il réunit la gestion des tickets (tickets parents et enfants), un tableau Kanban, un diagramme de Gantt, un wiki et le partage de fichiers en un seul endroit.
Il fonctionne sur un serveur avec PHP 8.2 ou supérieur et MySQL ou MariaDB. Ni Composer, ni Docker, ni ligne de commande.
Vous l’installez avec un installateur dans le navigateur et le mettez à jour en envoyant un ZIP depuis l’écran d’administration. Il fait automatiquement une sauvegarde avant d’appliquer une mise à jour.
Vous pouvez inviter des personnes extérieures en tant qu’invités. Les projets ne sont visibles que par les membres qui y participent.
C’est un paiement unique de 30 $ / 27 €, sans différence de fonctions selon les offres ni limite d’utilisateurs ou de projets (une licence par domaine ; l’hébergement est à prévoir en plus).

Les différences avec Redmine sont détaillées dans GeckoFlag vs Redmine, et celles avec d’autres outils qui fonctionnent sur un hébergement mutualisé dans Les outils de gestion de projets que vous pouvez installer sur un hébergement mutualisé sans Docker. Vous pouvez essayer les vrais écrans dans la démo.

Sources

Remarque : informations vérifiées le 24 octobre 2026. Les écrans et les fonctions de Redmine peuvent varier selon la version.