Imaginez une réunion de suivi classique du lundi. Votre équipe a des dizaines de demandes dans Redmine, et chacune a un responsable et une date d'échéance.

.

Pourtant, quand le sponsor demande si la version sortira toujours à temps, la réponse honnête est « ça dépend ». Le suivi des tâches vous dit ce que fait chaque personne. Il ne vous dit pas si le projet dans son ensemble arrivera à l'heure.

Suivi des tâches ou planification de projet dans Redmine

Redmine excelle dans la première mission. Les demandes sont assignées, les statuts évoluent, le temps est saisi, et chacun sait qui est responsable de quoi. Pour une petite équipe avec un horizon court, cela suffit souvent.

Quand les projets grandissent, d'autres questions apparaissent, et la liste des demandes ne peut pas y répondre :

  • Sommes-nous réellement dans les temps ?
  • Quelles tâches bloquent l'avancement ?
  • Que se passe-t-il si un membre de l'équipe manque une échéance ?
  • Ce retard aura-t-il un impact sur la version finale ?
  • Suivons-nous toujours le plan de projet initial ?

Chacune de ces questions porte sur des liens : ce qui attend une tâche en retard, la marge dont dispose le reste du plan, et l'écart entre le planning actuel et la version validée par tous. Le suivi de l'avancement par statut de demande montre ce qui est terminé. La planification de projet transforme cette information en une date de livraison que vous pouvez défendre. Les sections suivantes reprennent ces questions une par une.

Redmine pour la planification de projet : ce que vous obtenez en standard

Avant d'ajouter quoi que ce soit, il est utile de savoir ce qu'une installation Redmine standard propose déjà. C'est plus que ce que beaucoup d'équipes utilisent :

  • Des dates et des estimations sur chaque demande, avec des tâches parentes et enfants pour découper le travail.
  • Des relations entre demandes. Les relations « précède » et « suit » indiquent qu'une tâche ne peut pas commencer avant la fin d'une autre, avec un délai éventuel. Quand la première demande est décalée, Redmine repousse la suivante avec elle.
  • Des versions avec dates d'échéance, qui servent de jalons de livraison et affichent l'avancement dans la feuille de route.
  • Le diagramme de Gantt, qui place les demandes et les versions sur une ligne de temps et affiche ces relations sous forme de flèches.
  • Les requêtes enregistrées et l'export CSV, suffisants pour les rapports d'avancement et une copie manuelle du plan.

Pour une petite équipe, Redmine fonctionne déjà comme outil de planification de projet. Les manques apparaissent quand le planning grandit. Redmine ne calcule pas de chemin critique (une demande pour l'afficher sur le diagramme de Gantt est ouverte sur redmine.org depuis 2013), il n'offre aucun moyen intégré de conserver le plan validé à côté du plan actuel, et chaque changement de date passe par le formulaire de la demande.

Les limites du diagramme de Gantt de Redmine

Le diagramme de Gantt est au cœur de cette boîte à outils, et un Gantt de planification de projet doit faire plus qu'afficher des dates.

Le Gantt standard offre une vue d'ensemble utile des demandes, des dates et des relations. Ce n'est cependant pas un espace de planification interactif : modifier des dates oblige à éditer les demandes, et mesurer l'impact global d'un changement proposé demande un effort supplémentaire. Un chef de projet qui décale un jalon d'une semaine finit par ouvrir une douzaine de demandes, et lire les dépendances dans une longue liste de tâches prend du temps. Deux questions restent aussi sans réponse : quelles tâches fixent la date de fin, et comment le planning d'aujourd'hui se compare à celui qui a été validé.

C'est toute la différence entre consulter un planning et le piloter. Consulter relève de l'affichage. Piloter, c'est pouvoir modifier le plan, voir les conséquences du changement et le valider avec l'équipe. Planner apporte l'édition du planning, la visibilité des dépendances et la revue des changements directement dans le diagramme. C'est le type d'alternative au Gantt de Redmine dont parle cet article : un diagramme qui reste dans Redmine mais qui se modifie, et non un outil séparé.

Tout commence par une bonne vue d'ensemble. Quand responsables, dates et durées figurent sur une même ligne de temps, vous lisez le projet d'un coup d'œil au lieu de le reconstituer à partir de listes de demandes. Voici un plan de livraison de dix tâches dans RedmineUP Planner, le plugin sur lequel nous reviendrons plus loin.

Diagramme de Gantt Redmine affichant le calendrier du projet, les tâches et les responsables assignés

Obtenez une vue claire du planning, des tâches et des responsabilités de votre projet dans un seul diagramme de Gantt Redmine.

Dépendances entre tâches : comment un retard décale tout le projet

La plupart des retards de projet ne viennent pas d'un échec spectaculaire. Ils viennent d'un petit glissement sur une tâche dont d'autres dépendent discrètement.

Prenons une livraison logicielle courante : Développement backend → Intégration → Tests QA → Mise en production. Le backend était prévu pour deux semaines et en prend trois. L'intégration ne peut pas commencer avant la fin du backend, elle est donc décalée. La QA ne peut pas démarrer avant la fin de l'intégration, elle est décalée à son tour. La date de mise en production, promise à un client le mois dernier, glisse avec elles. Personne n'a commis d'erreur après le premier glissement. Le planning a simplement suivi la logique des dépendances.

Les dégâts sont les plus importants quand le glissement est découvert tard. Si vous apprenez que l'intégration est bloquée seulement quand le développeur backend annonce « terminé » avec une semaine de retard, les options sont limitées. Si vous voyez la chaîne à l'avance, vous pouvez ajouter une personne, réduire le périmètre ou recadrer les attentes tant que cela coûte encore peu.

C'est pourquoi un chef de projet doit comprendre les dépendances avant de modifier une échéance ou de prendre un engagement de livraison. Posez-vous la question « qu'est-ce qui attend cette tâche ? » à chaque fois qu'une date bouge. Les relations de Redmine permettent d'enregistrer la réponse, et un diagramme visuel la rend rapide à lire.

Dans la capture ci-dessous, les flèches relient chaque tâche à celles qui en dépendent. L'une d'elles est tracée en rouge. Ici, les écrans frontend sont planifiés d'une façon qui entre en conflit avec la tâche d'intégration qui les suit. Un tel conflit passe facilement inaperçu dans une liste mais saute aux yeux sur une ligne de temps : il peut donc être corrigé en réunion de planification plutôt que découvert pendant les tests.

Diagramme de Gantt Redmine pour la planification de projet avec dépendances entre tâches et conflits de planning

Comprenez comment les tâches dépendent les unes des autres et repérez les conflits de planning avant qu'ils n'affectent la livraison.

Chemin critique dans Redmine : les tâches qui fixent la date de fin

Une fois les dépendances visibles, une deuxième question se pose. Si tout est lié, quels retards comptent le plus ?

La réponse vient de la méthode du chemin critique (CPM), une technique classique d'ordonnancement de projet. Le chemin critique est la séquence de tâches dépendantes la plus longue, celle qui détermine la date de fin au plus tôt du projet. Les tâches de ce chemin ont une marge totale nulle : tout retard sur l'une d'elles repousse la date de fin du projet, sauf si l'équipe agit pour rattraper le temps perdu. Les tâches hors du chemin disposent d'une certaine latitude.

Cette latitude s'appelle la marge (float), et il en existe deux types :

  • La marge totale (total float) est le retard qu'une tâche peut prendre sans décaler la date de fin du projet.
  • La marge libre (free float) est le retard qu'une tâche peut prendre sans décaler le début de la tâche qui la suit.

La marge se compte en jours ouvrés. Une tâche avec 12 jours de marge totale peut glisser de 12 jours ouvrés avant d'affecter la date de fin, tant que rien d'autre ne bouge dans sa chaîne. Une valeur négative signifie que le plan tel qu'il est planifié ne peut pas tenir sa date de fin, ou qu'une dépendance n'est pas respectée, par exemple quand une tâche se termine plus tard que ne le permet la tâche suivante.

Voici pourquoi cela change les priorités. Imaginez deux demandes, toutes deux marquées « Haute » dans Redmine. L'une est le travail d'intégration, sur le chemin critique. L'autre est la mise en place d'un environnement de staging dont rien d'urgent ne dépend. Si l'intégration prend deux jours de retard, la mise en production recule de deux jours, sauf si l'équipe rattrape ce temps ailleurs. Si l'environnement de staging prend une semaine de retard, la date de mise en production ne change pas. Les étiquettes de priorité ne vous le disent pas, le chemin critique si. Sans lui, les équipes ont tendance à placer leurs meilleurs éléments sur les tâches les plus bruyantes ou les plus proches de leur échéance, au lieu de celles qui conditionnent la livraison.

Redmine standard n'inclut pas d'analyse du chemin critique : beaucoup d'équipes s'en passent ou la tiennent dans un outil séparé qui finit par ne plus être à jour. Dans la capture, la chaîne critique est surlignée en rouge et chaque tâche affiche sa marge. Backend, intégration, QA et mise en production sont à zéro. L'environnement de staging et le webinaire client disposent de 12 jours ouvrés de marge. Les écrans frontend affichent une valeur négative : ils se terminent plus tard que ne le permet la tâche suivante, le même conflit que dans la capture précédente, et il faut s'en occuper.

Diagramme de Gantt Redmine mettant en évidence le chemin critique et la marge des tâches

Identifiez les tâches critiques qui conditionnent directement la date de fin de votre projet et concentrez les efforts de l'équipe là où ils comptent le plus.

Baselines de projet : rendre l'exécution du plan mesurable

Même un plan bien construit a une durée de vie limitée. Les exigences changent, des personnes sont mobilisées sur d'autres sujets, un fournisseur prend du retard. Chaque changement est minime et raisonnable, et chacun est fait dans sa propre demande, à sa propre date.

Au bout de quelques mois, le plan initial a disparu. Plus personne ne se souvient des dates validées, et juger de l'exécution du plan devient une affaire d'opinion. L'un dit que le projet a « environ une semaine de retard », un autre dit « deux », et le manager qui doit expliquer à un client pourquoi la date de livraison a bougé n'a aucun moyen clair de montrer où le temps est passé.

Une baseline de projet règle ce problème. Une baseline est un instantané enregistré du planning validé. Elle conserve les dates de début et d'échéance prévues, pas les estimations, les assignations ni les autres propriétés des demandes. Vous la gardez telle quelle et vous comparez le planning actuel avec elle à tout moment. Au lieu d'une vague impression de dérive, vous obtenez des informations précises : quelles tâches ont bougé, dans quel sens et de combien de jours.

Cela apporte trois choses qui manquent souvent aux équipes :

  • La responsabilisation. Le plan sur lequel tout le monde s'est engagé est consigné et ne peut pas être réécrit en douce.
  • Des prévisions réalistes. Une série de petits glissements dans un même domaine est un signal précoce, plus honnête qu'une « marge de sécurité » ajoutée à la fin.
  • Une communication transparente. « La mise en production a quatre jours de retard sur le plan validé, et voici les trois tâches en cause » est une meilleure conversation avec un sponsor que « nous avons rencontré quelques problèmes ».

Dans la capture, l'équipe a enregistré une baseline nommée « Initial plan » au lancement. Un trait fin sous chaque barre indique la position prévue à l'origine, et une colonne montre de combien de jours ouvrés chaque tâche s'est décalée. L'environnement de staging est exactement là où il était prévu. La landing page a cinq jours ouvrés de retard, les écrans frontend six, et le déploiement de la version quatre. Voilà l'état réel du projet, chiffré, avant que quiconque ait à deviner.

Comparaison avec la baseline du projet Redmine — calendrier prévu et calendrier actuel des tâches

Comparez le planning actuel de votre projet avec le plan initial et repérez les retards avant qu'ils ne deviennent de vrais problèmes.

Planification collaborative : valider les changements avant de les appliquer

La planification n'est pas l'affaire du seul chef de projet, aussi soigné que soit le diagramme. Un changement de planning est rarement une modification privée. Quand une tâche bouge, le développeur qui en est responsable est concerné, tout comme la personne qui en dépend, le testeur qui attend le build et le team lead qui a affecté des personnes à cette semaine-là.

Pourtant, dans beaucoup d'équipes, les changements de planning se font sans prévenir. Quelqu'un ajuste les dates, les notifications partent, et tous les autres découvrent le nouveau plan dans leur boîte mail. C'est une mauvaise façon de prendre une décision qui concerne plusieurs personnes.

Une pratique plus saine repose sur quatre étapes :

  1. Un changement est proposé, et non appliqué directement.
  2. Les personnes concernées voient exactement ce qui changerait, y compris les effets en cascade sur les autres tâches.
  3. Le chef de projet examine les conséquences avant de valider.
  4. Ce n'est qu'ensuite que le nouveau planning devient le plan de travail.

Les équipes qui fonctionnent ainsi passent moins de temps sur les corrections et les replanifications surprises. Elles construisent aussi une compréhension partagée du plan actuel, ce qui est précieux quand les personnes travaillent sur des fuseaux horaires ou des projets différents.

La capture montre cette idée en pratique. Planner trace les flèches de dépendance et signale les violations de planning. Quand un changement proposé affecte des demandes suivantes, le tableau Review affiche les nouvelles dates avant qu'elles ne soient appliquées dans Redmine. Ici, un changement proposé sur les écrans frontend attend dans un brouillon partagé (Draft), avec les anciennes et les nouvelles dates côte à côte et le nom de l'auteur. La fenêtre indique aussi que Redmine décalerait en conséquence la tâche d'intégration à la fin du mois. Rien n'a encore été écrit dans les vraies demandes, et l'équipe peut décider de ce qu'elle applique.

Interface de brouillon partagé de Redmine Planner pour revoir les modifications du planning du projet

Examinez les changements de planning proposés et leur impact avant de les appliquer à votre projet Redmine.

RedmineUP Planner : une alternative au Gantt de Redmine pour la planification de projet

Tout ce qui précède est faisable avec de la discipline, des tableurs et beaucoup de patience. RedmineUP Planner est un logiciel de planification de projet qui réunit ces pratiques dans un seul workflow au sein de Redmine, au-dessus des demandes sur lesquelles votre équipe travaille déjà. Vous planifiez sur un diagramme de Gantt modifiable où les dépendances sont tracées en flèches et les violations signalées. Les changements proposés attendent dans un brouillon partagé jusqu'à ce que quelqu'un les examine et les applique, et le chemin critique, les baselines et les jalons de version figurent sur le même diagramme.

Le gain concret ne tient pas à une fonctionnalité en particulier. Les changements de planning deviennent plus faciles à discuter, à valider et à gérer en un seul endroit, Redmine restant la source de vérité pour le travail lui-même.

Planner associe le diagramme de Gantt modifiable, le Draft partagé avec Review et Apply, les dépendances et Undo/Redo à des fonctions de planification avancées : analyse du chemin critique avec marge totale et marge libre, baselines avec colonne d'écart, regroupement, colonnes de requête supplémentaires, couleurs des barres et jalons de versions. Tous les détails sont sur la page Planner et dans la documentation.

Planner fonctionne aussi avec le reste de la suite RedmineUP. Les équipes qui travaillent en sprints peuvent garder leurs tableaux dans le plugin Agile, et les managers qui doivent répartir les personnes entre projets peuvent ajouter le plugin Resources. Pour une vue plus large des options, consultez notre guide des meilleurs plugins Redmine pour la gestion de projet, ou parcourez le catalogue complet des plugins Redmine.

Intégrer la planification Gantt à votre workflow Redmine

Redmine est l'endroit où votre équipe gère déjà son travail. Avec de meilleures pratiques de planification, il peut aussi devenir l'endroit où vous construisez le planning, comprenez les dépendances et suivez l'exécution du plan, sans déplacer le plan dans un outil séparé que personne ne met à jour.

Si vous voulez commencer sans rien installer, partez d'une petite habitude. Choisissez un projet en cours et posez les cinq questions du début de cet article. Chaque question à laquelle votre configuration actuelle ne permet pas de répondre révèle une lacune dans votre planification de projet. Cette liste est un bon point de départ pour discuter de ce dont votre équipe a besoin ensuite.

Pour les équipes qui veulent aller au-delà du simple suivi des tâches, RedmineUP Planner est l'étape suivante. Ouvrez la démo en ligne, choisissez Planner et essayez le chemin critique, les baselines et la revue du Draft sur des données d'exemple. Quand vous êtes prêt, installez Planner sur votre propre Redmine (5.0 à 7.0).

Obtenir RedmineUP Planner