Agilité et gestion de projet
Outils de gestion de projet : bien les choisir et bien s'en servir
Débutant11 min de lectureMis à jour
Cette page a été traduite de l'anglais avec l'aide de l'IA, puis vérifiée par rapport à l'original. Lire la version anglaise
Un outil de suivi enregistre des décisions ; il ne les prend pas, et la plupart des reproches faits aux outils visent en réalité le processus. Ce guide compare les principales options selon les situations qui leur conviennent, explique quand un tableau, un backlog ou une vue Gantt est la bonne vue, met en garde contre la personnalisation des workflows et traite de l'intégration au pipeline, des rapports utiles et de l'hygiène des données.
Ce que vous allez apprendre
- Distinguer les décisions qu'un outil doit enregistrer de celles que l'équipe doit prendre
- Comparer Jira, Azure DevOps, GitLab, Trello et Redmine selon les situations qui conviennent à chacun
- Choisir entre tableau, backlog, chronologie et roadmap en fonction de la question posée
- Éviter les pièges de personnalisation des workflows et des champs qui rendent un outil inutilisable
- Relier le suivi au pipeline de livraison et produire des rapports qui déclenchent des actions
Presque toutes les équipes qui se sont plaintes de leur outil de suivi se plaignaient en réalité de leur processus. L'outil a rendu quelque chose visible (une file de travail à moitié terminé, une étape de validation floue, un backlog que personne ne priorise) et cette visibilité était inconfortable. Changer de produit n'y change rien, et c'est pourquoi les migrations d'outils se soldent si souvent par un an d'efforts et les mêmes problèmes sous d'autres couleurs.
Cela dit, le choix compte à la marge, car les outils ont des partis pris. Certains supposent une équipe unique avec un tableau ; d'autres un portefeuille avec des dépendances et des dates ; d'autres encore considèrent que le travail est indissociable du code. Ce guide vise à faire correspondre le parti pris de l'outil à votre situation, puis à le configurer pour qu'il aide au lieu de gêner.
Ce qu'un outil doit décider, et ce qu'il ne doit pas décider
Un outil de suivi est un référentiel partagé. Ses missions légitimes : tenir une liste unique et faisant autorité du travail, montrer honnêtement l'état courant, conserver l'historique de ce qui a été décidé et quand, relier le travail au code et aux déploiements qui l'ont réalisé, et répondre aux questions sur le flux auxquelles personne ne saurait répondre de mémoire.
Ce qu'il ne doit pas faire, c'est décider du processus. Si le workflow compte sept états parce que le modèle de l'outil en comptait sept, l'équipe a adopté par accident le processus d'un inconnu. Si un élément ne peut pas passer « en cours » sans estimation parce qu'un champ est obligatoire, une politique d'estimation a été fixée par la configuration et non par un accord. L'ordre est toujours le même : se mettre d'accord sur la façon de travailler, configurer l'outil pour qu'il la reflète, puis réexaminer les deux.
Corollaire : un outil ne peut pas régler la question de la responsabilité. Un backlog n'est priorisé que si quelqu'un le priorise, quoi que permette le logiciel ; voyez product owner et gestion du backlog pour ce que cela implique.
Les principales options, selon les situations
Les listes de fonctionnalités ne servent presque à rien pour choisir, car les produits les plus répandus ont convergé. Ce qui les distingue, c'est la situation dans laquelle chacun est à l'aise.
| Outil | À l'aise quand | Mal à l'aise quand | Remarques |
|---|---|---|---|
| Jira | Plusieurs équipes, des workflows formels, des consolidations au niveau du portefeuille, un écosystème d'intégrations | Une petite équipe veut quelque chose de simple ; personne n'est responsable de la configuration | Le choix par défaut dans les moyennes et grandes organisations ; sa puissance s'accompagne d'une charge d'administration |
| Azure DevOps | L'organisation utilise déjà l'outillage Microsoft et veut tableaux, dépôts, pipelines et gestion des tests dans un seul produit | Vous voulez le meilleur outil dans chaque domaine plutôt qu'une suite intégrée | Lien natif solide entre work items, branches et builds |
| GitLab | Des équipes centrées sur le développement qui veulent tickets, code, revue et CI dans une seule application | Les principaux utilisateurs sont des parties prenantes non techniques | Tableaux de tickets, epics et jalons plus légers que dans Jira, mais étroitement liés aux merge requests |
| Trello | Une petite équipe, un flux simple, peu de cérémonial, un travail qui tient sur des cartes | Vous avez besoin de hiérarchie, de dépendances, de reporting ou de nombreuses équipes | Excellent dans ce qu'il fait ; les équipes finissent par le dépasser, puis par lutter contre lui |
| Redmine | L'auto-hébergement est exigé, le budget est nul ou les données doivent rester sur site | Vous voulez une interface moderne et soignée sans effort | Open source, pérenne, inclut Gantt et suivi du temps ; nécessite un administrateur |
Deux constats honnêtes. D'abord, la plupart des équipes pourraient bien travailler avec n'importe lequel de ces outils : l'écart de résultats entre deux outils bien configurés est bien plus faible que celui entre une instance bien configurée et une instance mal configurée du même outil. Ensuite, le coût dominant n'est pas la licence mais l'administration et la migration ; changer d'outil pour une fonctionnalité ne se justifie donc presque jamais, alors que changer parce que personne ne maintient l'instance actuelle se justifie souvent.
Les logiciels de planification dédiés restent une catégorie à part. Quand une livraison a réellement besoin d'un réseau de dépendances, d'un histogramme des ressources et d'un chemin critique, la vue chronologique d'un outil de suivi n'est qu'un diagramme à barres et non un modèle de planning, et la différence compte pour les raisons exposées dans gestion des délais.
Les vues, et la question à laquelle chacune répond
La plupart des outils proposent la même poignée de vues, et la confusion sur leur rôle cause plus de problèmes que n'importe quelle fonctionnalité manquante.
Un tableau répond à « où en est le travail en cours, maintenant ? ». Les colonnes sont des états, les cartes des éléments, et la valeur vient de la limite du nombre de cartes autorisées par colonne : c'est la limite de travail en cours (WIP) qui transforme un tableau d'affichage d'état en outil de régulation du flux. Un tableau sans limite avec quarante cartes en cours n'est qu'un mur de bonnes intentions.
Un backlog répond à « que devons-nous faire ensuite ? ». C'est une liste ordonnée, et l'ordre en est le contenu même ; un backlog affiché comme une pile plate et non triée de centaines de tickets n'est pas un backlog.
Une vue chronologique ou Gantt répond à « quand les choses arriveront-elles les unes par rapport aux autres ? ». Elle convient aux dates externes fixes, aux délais d'approvisionnement de matériel et aux dépendances entre équipes, et devient trompeuse lorsqu'elle est dessinée à la main et ne se recalcule pas quand une barre bouge.
Une vue roadmap répond à « que visons-nous sur les prochains horizons ? » et fonctionne mieux lorsqu'elle montre des objectifs plutôt que des fonctionnalités datées.
Un rapport ou tableau de bord répond à « comment nous en sortons-nous ? », question qui n'a d'intérêt que si la réponse change une décision.
Choisissez la vue selon la question, pas selon les préférences de chacun, et méfiez-vous de toute demande de vue dont l'objet ne peut pas s'énoncer sous forme de question.
Les pièges de la personnalisation
C'est dans la configuration que les outils déraillent, et les modes d'échec sont assez constants pour être énumérés.
- La prolifération du workflow. Dix états, six transitions chacun, dont trois soumises à approbation. Chaque état supplémentaire est un endroit où le travail stagne et une décision que quelqu'un doit prendre. Trois à cinq états suffisent à la plupart des équipes ; n'en ajoutez un que lorsqu'un vrai passage de relais existe et que son absence a posé problème.
- L'inflation des champs obligatoires. Chaque champ semblait raisonnable à la personne qui l'a demandé. Ensemble, ils font de la création d'un élément une corvée de cinq minutes ; on colle alors du texte bidon dans des champs qu'on ne comprend pas, et les données obtenues valent moins que pas de données du tout.
- La divergence entre équipes. Huit équipes, huit workflows et types de tickets différents, et aucune vue transverse pertinente possible. Mettez-vous d'accord sur un socle commun et autorisez des ajouts locaux.
- La configuration dictée par le reporting. Des champs qui n'existent que pour alimenter un graphique de pilotage. L'équipe ne tire aucun bénéfice à les tenir à jour, donc elle ne les tient pas à jour correctement.
- Les automatisations qui prennent les gens par surprise. Des règles qui réassignent, font changer d'état ou ferment des éléments de manière invisible. L'automatisation est excellente pour les étapes mécaniques et corrosive quand le tableau change pour des raisons que personne ne sait expliquer.
- Le verrouillage des droits. Des configurations où les développeurs ne peuvent pas modifier leurs propres éléments et doivent passer par un administrateur. Chaque restriction de ce genre fait sortir le travail de l'outil pour le déplacer vers la messagerie instantanée, où il ne reste aucune trace.
Le principe général : le coût de la configuration se paie à chaque interaction, pour toujours, alors que le bénéfice se résume généralement à un rapport que quelqu'un a demandé une fois.
Relier l'outil au pipeline de livraison
L'intégration la plus utile est aussi la moins chère : mettez la clé de l'élément dans le nom de la branche et dans le message de commit, et l'outil relie automatiquement le travail au code. À partir de là, le système de build peut indiquer quels commits, et donc quels éléments, figurent dans un déploiement donné, et l'élément peut montrer s'il a atteint la préproduction ou la production. Le guide sur les workflows de branches décrit les conventions de nommage qui rendent cela fiable.
Trois autres connexions méritent l'effort. Les transitions automatiques au merge (passer un élément « en revue » ou « terminé » quand sa merge request est approuvée) suppriment une mise à jour de statut que personne n'a envie de faire à la main. Un lien d'un déploiement vers ses éléments produit des notes de version gratuitement. Et relier les tickets d'incident au changement qui les a provoqués constitue les données nécessaires pour mesurer honnêtement le taux d'échec des changements : c'est là que le suivi rejoint le pipeline de livraison comme boucle de rétroaction plutôt que comme système administratif.
Résistez à la tentation d'automatiser les transitions qui traduisent un jugement humain. « Terminé » signifie généralement que quelqu'un a vérifié quelque chose ; une règle qui positionne cet état au merge redéfinit discrètement la definition of done de l'équipe.
Les rapports utiles, et l'hygiène des données
Chaque outil fournit plus de graphiques que quiconque n'en a besoin. Un petit nombre seulement éclaire réellement les décisions.
| Rapport | Question à laquelle il répond | Point de vigilance |
|---|---|---|
| Diagramme de flux cumulé | Où le travail s'accumule-t-il, et le travail en cours augmente-t-il ? | Illisible sans états cohérents |
| Distribution du temps de cycle | Combien de temps prennent les éléments, et avec quelle variabilité ? | Une moyenne masque la traîne ; regardez la dispersion |
| Débit par période | Combien d'éléments sont terminés, et ce nombre est-il stable ? | Comparable seulement si les éléments sont découpés de façon homogène |
| Ancienneté du travail en cours | Quels éléments sont ouverts depuis anormalement longtemps ? | Le rapport quotidien le plus directement exploitable |
| Burn-up avec ligne de périmètre | Progressons-nous, et le périmètre grossit-il ? | Le burn-down masque l'augmentation du périmètre ; le burn-up la montre |
| Données de déploiement et d'échec | Le travail terminé atteint-il vraiment la production ? | Nécessite l'intégration au pipeline décrite plus haut |
Vous remarquerez l'absence des graphiques de vélocité. Ils conviennent comme donnée interne à une équipe, comme l'explique le guide sur le framework Scrum, et deviennent nuisibles dès qu'ils apparaissent sur un tableau de bord qui compare des équipes.
Tous ces rapports dépendent de l'hygiène des données, un sujet ingrat mais décisif. Les états doivent être mis à jour quand ils changent, pas reconstitués le vendredi précédant un rapport. Les éléments doivent être fermés une fois terminés, et les éléments obsolètes supprimés plutôt que laissés s'accumuler : un backlog contenant trois ans de tickets jamais touchés est un backlog auquel personne ne fait confiance. Les doublons doivent être fusionnés. Et l'estimation ou la taille enregistrée doit être celle dont l'équipe a réellement convenu, jamais une valeur retouchée après coup pour embellir un graphique.
Choisir et déployer
Écrivez les questions auxquelles vous avez besoin de réponses
Pas des fonctionnalités : des questions. « Quels éléments sont bloqués ? », « quand cette version sortira-t-elle ? », « quelle part de notre capacité part dans les anomalies ? ». Un outil incapable de répondre à vos questions est disqualifié, quelle que soit sa liste de fonctionnalités.Modélisez d'abord votre processus réel
Dessinez les états par lesquels le travail passe réellement aujourd'hui, y compris les états informels. Si le processus est flou, corrigez cela avant de faire votre marché ; un outil encodera toute la confusion que vous y apporterez.Faites un essai avec une vraie équipe sur du vrai travail
Deux à quatre semaines, sur du travail réel, pas dans un bac à sable. Évaluez la rapidité des actions quotidiennes, la qualité du tableau et la charge d'administration exigée.Configurez le strict minimum
Workflow par défaut, peu de champs, peu de types de tickets. N'ajoutez de la configuration qu'en réponse à un problème avéré, et notez pourquoi chaque ajout existe pour pouvoir le retirer plus tard.Désignez le responsable de la configuration
Un administrateur nommément désigné, avec du temps alloué. Les instances sans responsable accumulent champs personnalisés et projets abandonnés jusqu'à ce que plus personne ne fasse confiance aux données.Migrez de façon sélective, pas exhaustive
Reprenez les éléments encore ouverts et l'historique récent ; archivez le reste en lecture seule. Une migration fidèle de plusieurs années de tickets fermés coûte bien plus qu'elle ne rapporte.Faites le bilan au bout d'un trimestre
Quels champs restent vides, quels états ne servent jamais, quels rapports personne n'ouvre. Supprimer de la configuration vaut autant qu'en ajouter, et se fait beaucoup plus rarement.
Points clés à retenir
- Un outil enregistre des décisions et rend l'état visible ; il ne peut fournir ni responsabilité, ni priorisation, ni un processus sur lequel l'équipe ne s'est pas accordée.
- Les produits les plus répandus ont convergé sur les fonctionnalités : choisissez selon la situation dans laquelle chacun est à l'aise et selon qui l'administrera, pas sur la foi de tableaux comparatifs.
- Adaptez la vue à la question : tableaux avec limites pour le travail en cours, backlogs pour la priorisation, chronologies pour les dates externes, roadmaps pour les objectifs.
- La configuration se paie à chaque interaction : limitez les workflows à trois à cinq états, résistez aux champs obligatoires et ne configurez jamais pour un rapport dont l'équipe ne tire rien.
- Reliez les éléments aux branches, aux commits et aux déploiements ; cette seule intégration produit notes de version, traçabilité et indicateurs de livraison honnêtes presque gratuitement.
- Les rapports ne valent que par la propreté des données : fermez, fusionnez et supprimez sans relâche, et tenez la vélocité à l'écart de tout tableau de bord qui compare des équipes.
Sources et lectures complémentaires
Questions fréquentes
- Un tableau physique vaut-il encore mieux qu'un tableau numérique ?
- Pour une équipe réunie sur un même site, souvent oui. Un mur est toujours visible, ne coûte rien à modifier, invite les gens à se rassembler autour et ne peut pas être filtré pour masquer les mauvaises nouvelles. Les outils numériques l'emportent dès que quelqu'un travaille à distance, quand l'historique et le reporting comptent, et quand le travail doit être relié aux commits et aux pipelines. Beaucoup d'équipes utilisent les deux : le mur comme surface de travail, l'outil comme référence.
- Jusqu'où faut-il personnaliser l'outil ?
- Partez des réglages par défaut et ne modifiez quelque chose que lorsqu'un problème précis s'est produit deux fois. La plupart des installations lourdement personnalisées ont été configurées le premier mois par des gens qui devinaient leur propre processus, et les workflows qui en résultent survivent des années aux raisons qui les avaient motivés. Un workflow à dix états avec des champs obligatoires collecte des données que personne ne lit et ralentit chaque mise à jour.
- Faut-il suivre les tâches séparément des user stories ?
- Seulement si l'équipe y trouve un intérêt. Les sous-tâches aident quand plusieurs personnes travaillent sur un même élément et doivent se le répartir de façon visible ; elles deviennent du pur surcoût quand un développeur crée quatre sous-tâches après coup pour alimenter un rapport. L'unité qui doit être suivie avec précision est celle que le product owner priorise et que l'équipe termine ; tout ce qui se trouve en dessous relève de l'équipe elle-même.
- Un même outil peut-il servir à la fois une équipe agile et le reporting de la direction ?
- En général oui, mais pas avec les mêmes vues. Les équipes ont besoin d'un tableau et d'un backlog ; la direction a besoin de résultats, de jalons et de prévisions. L'écueil consiste à obliger l'équipe à tenir à jour des champs dont le seul but est un rapport de pilotage, ce qui corrompt les données, car on remplit les champs obligatoires avec n'importe quoi pourvu que la validation passe. Construisez les vues de pilotage à partir des données que l'équipe tient à jour pour ses propres besoins.