Outils de planification et de suivi de projet : panorama

Vous saurez situer les grandes familles d'outils (suivi de tickets, tableaux Kanban, gestion de portefeuille, suites intégrées au code) et ce que chacun fait réellement.

Guide≈ 13 min de lectureVérifié en partieLecture

En bref

Vous saurez situer les grandes familles d'outils (suivi de tickets, tableaux Kanban, gestion de portefeuille, suites intégrées au code) et ce que chacun fait réellement.
Vous saurez lister les fonctions indispensables pour Scrum (backlog ordonné, sprint, capacité, burndown, limite de WIP) et vérifier qu'un outil les porte sans bricolage.
Vous disposerez de critères de choix pondérables et d'une méthode pour décider sans céder à la mode.
Vous saurez ce qui change pour un projet data/BI (éléments non codables, recette sur chiffres, kits de livraison).
Les fiches détaillées : Azure DevOps / TFS, Jira et alternatives, métriques, IA, comparatif noté.

Les notes /5 de ce dossier sont des appréciations d'expert, contextuelles (équipe de 5 à 15 personnes, projet data/BI avec un datamart SQL Server alimenté par une application terrain SFA, rapports Power BI, versionnement TFVC). Voir NOTATION.

Sur cette page

🟢 Novice — À quoi sert un outil de planification
1. 🟢 Les cinq familles d'outils
🟢 Novice — Fonctions indispensables pour Scrum
🟡 Pratique — Panorama des outils
🟡 Pratique — Critères de choix
🟡 Pratique — Fonctions Scrum en détail : ce qui sépare les outils
🔴 Expert — Modèle de données, coûts cachés et portabilité
🔴 Expert — Méthode de décision en cinq étapes
Voir aussi

Niveau : 🟢→🔴

🟢 Novice — À quoi sert un outil de planification#

Un outil de planification n'est pas le projet : c'est la mémoire partagée et visible du travail à faire, en cours et terminé. Il répond à quatre questions que l'équipe se pose chaque jour : quoi (le contenu), qui (la responsabilité), quand (l'ordre et les dates) et où en est-on (l'état). Un tableur peut tenir ce rôle pour trois personnes pendant un mois ; au-delà, on cherche historique, liens entre éléments, droits, notifications et rapports.

Le vocabulaire minimal (voir le glossaire) :

Terme	Sens courant	Remarque
Work item / ticket / issue	l'unité de travail suivie	le nom change selon l'outil : work item (Azure DevOps), issue (Jira, GitHub, GitLab)
Backlog	liste ordonnée de ce qui reste à faire	l'ordre est une décision de produit, pas un détail d'affichage
Sprint / itération	période à durée fixe	Scrum : 1 à 4 semaines, voir le cadre Scrum
Board / tableau	colonnes = états, cartes = éléments	Kanban visuel
Workflow	états permis et transitions	le cœur de la personnalisation
Epic / Feature / Story / Task	niveaux de granularité	les noms varient, la hiérarchie persiste

🟢 Les cinq familles d'outils#

Suivi de tickets orienté équipes logicielles : Azure DevOps Boards (ex-TFS), Jira, YouTrack, Redmine, Taiga. Forts en workflows, requêtes, historique, intégration au code.
Outils intégrés à la forge de code : GitHub Projects, GitLab Issues/Boards. Le ticket vit à côté du dépôt, des demandes de fusion et du pipeline.
Outils « modernes » centrés vitesse et simplicité : Linear, Shortcut. Peu de réglages, forte opinion, très bonne ergonomie.
Tableaux collaboratifs généralistes : Trello, Asana, Monday, Notion, ClickUp. Faibles en rigueur de processus, forts en adoption hors équipes techniques.
Gestion de portefeuille et agilité à l'échelle : Jira Align, Rally (Broadcom), Planview, ADO Portfolio. Pour l'alignement stratégie → équipes, les dépendances inter-équipes.

💡 Astuce d'expert

Une organisation mature a toujours deux niveaux : un outil proche du code pour le détail (tickets, tâches, liens aux changesets) et, si la taille l'exige, une vue portefeuille agrégée. Vouloir qu'un seul outil fasse les deux produit un outil trop lourd pour les développeurs ou trop pauvre pour la direction.

🟢 Novice — Fonctions indispensables pour Scrum#

Avant de comparer des logos, cochons ce que Scrum exige réellement (cadre, pratique).

Fonction	Pourquoi Scrum en a besoin	Test simple pour l'outil
Product Backlog ordonné	l'unique liste du Product Owner, l'ordre = la priorité	puis-je glisser-déposer un élément et que l'ordre soit partagé et persistant ?
Hiérarchie (Epic → Feature → Story → Task)	découper sans perdre la traçabilité	un parent affiche-t-il l'avancement (somme) de ses enfants ?
Sprint Backlog	sélection pour l'itération + plan de réalisation	peut-on affecter des éléments à un sprint et voir un tableau de sprint ?
Capacité	éviter l'engagement irréaliste	saisie des jours disponibles par personne (congés, jours fériés), total par sprint
Estimation	points, taille de t-shirt, heures de reste à faire	champ numérique agrégeable ; réestimation tracée
Burndown / vélocité	transparence sur la trajectoire	graphique calculé sans export manuel
Limites de WIP	éviter l'accumulation (esprit Kanban)	limite par colonne avec alerte visuelle
Définition de « terminé »	qualité transparente	case/état bloquant, ou checklist obligatoire
Historique et audit	rétrospective, preuve	journal des changements d'état et de champ
Liens	dépendances, bugs ↔ stories, changesets	lien typé (parent, lié, prédécesseur, commit/changeset)
Requêtes et tableaux de bord	pilotage	filtre sauvegardé, partage, widget

⚠️ Piège

Symptôme : le burndown est « plat puis en falaise » à chaque sprint. Cause : l'outil suit le reste à faire en heures sur les tâches, mais l'équipe ne le met jamais à jour (ou ne crée les tâches qu'à la fin). Remède : décider un seul mode de suivi (points au niveau story, ou reste à faire au niveau tâche), le documenter dans la Définition de Terminé, et l'inspecter à la mêlée quotidienne.

Pour les notions d'estimation et de vélocité sous-jacentes, voir métriques et reporting et le thème de matrice planification et estimation.

🟡 Pratique — Panorama des outils#

Les descriptions ci-dessous sont celles d'un praticien (état 2026-10). Les fonctionnalités changent vite ; les modèles (ce que l'outil considère comme un objet de première classe) changent peu et sont ce qui compte.

Azure DevOps Boards (et TFS, Azure DevOps Server)#

Modèle : work items typés, dépendant du process template (Agile, Scrum, CMMI) ; hiérarchie parent-enfant ; area paths et iteration paths ; backlogs, boards, sprints, capacité ; requêtes WIQL ; liens natifs vers changesets TFVC, commits, builds, releases. Existe en SaaS (Azure DevOps Services) et on-premise (Azure DevOps Server, successeur de TFS). Forces : intégration code/CI/tests dans un seul produit, processus personnalisable sans marketplace, coût bas si licences Visual Studio déjà présentes. Faiblesses : écosystème de tiers plus mince que Jira, ergonomie datée, roadmap Microsoft plus orientée GitHub. Détail : fiche dédiée.

Jira (Software, Work Management, Service Management)#

Modèle : issues + workflows + schémas (types, champs, écrans, permissions, notifications) ; boards Scrum/Kanban ; JQL ; Advanced Roadmaps / Plans ; Marketplace très riche. SaaS (Cloud) ; l'offre Data Center a une fin de vie annoncée au 28 mars 2029 (annonce Atlassian du 8 septembre 2025 ; vente aux nouveaux clients arrêtée depuis le 30 mars 2026 ; les clients existants peuvent encore acheter de nouveaux abonnements, applications et extensions jusqu'au 30 mars 2028 — état 2026-10). Forces : flexibilité, écosystème, standard du marché. Faiblesses : dérive de personnalisation, coût au siège, performance sur gros volumes. Détail : Jira et alternatives.

GitLab (Issues, Boards, Epics, Iterations)#

Modèle : issues liées aux merge requests et aux pipelines ; epics et iterations sur offres payantes ; auto-hébergeable ou SaaS. Force : plateforme unique de la planification au déploiement ; faiblesse : la planification est plus simple que Jira ou Azure DevOps (champs, workflows et reporting moins riches), certaines fonctions sont réservées aux paliers payants.

GitHub Projects (+ Issues)#

Modèle : tableaux/tables/roadmaps orientés vues sur des issues et PR ; champs personnalisés ; automatisations. Force : adoption naturelle quand le code est sur GitHub, intégration aux agents de codage IA ; faiblesse : peu de notions Scrum natives (itérations et graphiques d'Insights de type burn up, mais pas de saisie de capacité ni de burndown dédié), gouvernance et reporting modestes.

Linear#

Modèle : issues, cycles (sprints), projets, initiatives ; très rapide, très opiné (peu de configuration) ; paliers Free/Basic/Business/Enterprise ; plateforme d'agents IA et « Linear Agent » dès l'offre gratuite, certaines fonctions IA fonctionnant avec des crédits (état 2026-10, d'après la page tarifaire). Force : ergonomie, vélocité d'équipe produit ; faiblesse : peu adapté aux processus réglementés, à la personnalisation lourde et au on-premise (SaaS uniquement).

Trello, Asana, Monday#

Tableaux de cartes simples (Trello), gestion de travail généraliste (Asana), plateformes no-code de pilotage (Monday). Forces : adoption éclair, utilisateurs non techniques, clients et métiers. Faiblesses pour Scrum : pas de sprint rigoureux, capacité/burndown rudimentaires ou via compléments. Excellents pour un suivi de recette métier ou un tableau de demandes, rarement pour le cœur d'un backlog technique.

Notion#

Bases de données relationnelles + pages : on peut modéliser un backlog, des sprints, une documentation, le tout dans un outil. Force : unification doc + suivi, souplesse. Faiblesse : pas de workflow transactionnel, gouvernance et audit faibles, performance sur gros volumes, dépendance aux conventions de l'équipe qui s'érodent.

YouTrack, Redmine, Taiga#

YouTrack (JetBrains) : suivi de tickets très flexible (workflows scriptés, commandes de saisie rapide), auto-hébergeable ou cloud, tarification attractive pour petites équipes.
Redmine : libre, mature, auto-hébergé, très modulable par plug-ins ; interface datée, agilité par extensions. Choix classique de petites structures et de l'administration.
Taiga : libre, agilité très visuelle (Scrum/Kanban), communauté plus réduite ; vérifier la vitalité du projet avant de s'engager.

Rally (Broadcom), Jira Align, Planview : l'échelle#

Pour 10+ équipes, SAFe/LeSS ou portefeuille : trains de livraison, objectifs d'incrément, dépendances, capacité multi-équipes. Coût et lourdeur élevés ; pertinent seulement si la coordination est réellement le goulot, pas pour « faire sérieux ». Voir méthodes agiles et Lean.

Azure DevOps vs Jira, en une table#

Dimension	Azure DevOps (Server/Services)	Jira (Cloud)
Modèle de données	work items typés par process template	issues + workflow + schémas
Lien avec le code	natif (changesets TFVC, commits Git, builds, tests)	via Bitbucket/GitHub/GitLab ou apps
On-premise	oui (Azure DevOps Server, cycle moderne sans date de fin fixe)	Data Center en fin de vie 2029
Écosystème tiers	correct, plus mince	très riche
Reporting natif	Analytics + OData + widgets ; Power BI direct	tableaux de bord, rapports ; BI via exports/apps
Coût	souvent déjà couvert (abonnements Visual Studio)	par siège, paliers
Gouvernance de personnalisation	par collection/projet, processus hérité	par schémas ; risque de prolifération

🟡 Pratique — Critères de choix#

On ne choisit pas « le meilleur outil » mais l'outil le moins mauvais pour un contexte. Pondérez les critères (somme 100) avant d'évaluer, sinon la démonstration commerciale décide à votre place.

Critère	Question à se poser	Poids typique (équipe data/BI on-prem)
Flexibilité du modèle	peut-on représenter nos types (par exemple « Livraison », « Recette », « Incident donnée ») ?	12
Reporting	burndown, vélocité, tendances sans export ? Connexion à Power BI ?	14
Intégration code/CI	lien ticket ↔ changeset/commit, build, déploiement	15
Coût total	licences + admin + migration + formation	10
Adoption	courbe d'apprentissage, présence chez les métiers	10
Gouvernance	droits fins, audit, séparation des rôles	10
Passage à l'échelle	5 → 50 → 500 utilisateurs, volumes	6
Personnalisation du processus	champs, états, règles, sans développement	10
Extensibilité / API	REST, webhooks, extensions, scripts	8
Souveraineté / hébergement	on-premise exigé ? données en UE ?	5

🧪 Exemple

Une équipe de 8 personnes maintient un datamart SQL Server et ses rapports Power BI, versionnés en TFVC, livrés en kits d'installation. Poids élevés : intégration code (15) et reporting (14), car chaque kit doit être traçable jusqu'aux tickets, et la direction veut un tableau de bord. Un outil SaaS non connecté au TFVC perdrait la traçabilité changeset ↔ ticket : malgré une meilleure ergonomie, son score pondéré chute. Le tableau noté complet est dans le comparatif.

✅ Bonne pratique

Faites un essai de bout en bout de deux semaines avec un vrai sprint : création du backlog, estimation, un changement de périmètre en cours de sprint, une livraison, un rapport pour la direction. Les écarts apparaissent là, pas dans la brochure.

🟡 Pratique — Fonctions Scrum en détail : ce qui sépare les outils#

Backlog#

La différence majeure : le backlog est-il une vue sur un champ d'ordre global (Azure DevOps : Stack Rank/Backlog Priority, Jira : rank) ou un tableau trié à la main par vue ? Un champ d'ordre global permet à plusieurs équipes de s'accorder sur « la même liste » ; un ordre local par vue produit des divergences invisibles.

Sprint et capacité#

La capacité se calcule ainsi (formule utilisée par l'outil ou à reproduire à la main) :

Capacité du sprint (h) = Σ_personnes (jours ouvrés du sprint − congés − jours fériés) × heures_productives_par_jour
Heures productives/jour ≈ 4 à 6 sur 8 (réunions, support, imprévus) — ordre de grandeur, à calibrer
Capacité en points ≈ vélocité moyenne des 3 à 5 derniers sprints × (capacité actuelle / capacité moyenne passée)

Azure DevOps propose la saisie de capacité par personne et par activité (Development, Testing, Design…) et affiche un voyant de sur-engagement ; Jira l'obtient par apps ou par des plans Advanced Roadmaps ; Linear, GitHub Projects n'en font pas une fonction centrale.

Burndown, burnup, cumulative flow#

Voir métriques et reporting : le point crucial est de savoir si l'outil trace le périmètre (burnup) en plus du reste à faire (burndown), car le périmètre bouge.

WIP#

Les limites de WIP sont natives dans les boards Kanban d'Azure DevOps et de Jira (à vérifier pour les autres outils, dont Linear), mais jamais contraignantes : elles alertent. C'est un levier de comportement, pas un verrou technique.

🔴 Expert — Modèle de données, coûts cachés et portabilité#

Ce qu'un outil impose sans le dire#

Le modèle d'estimation : Azure DevOps stocke Story Points (Agile/Scrum) ou Effort (Scrum) et Remaining Work en heures ; Jira : champ Story Points ou Original Estimate ; les passer d'un outil à l'autre demande une table de correspondance.
L'historique des états : indispensable pour calculer lead time et cycle time (métriques). Un outil qui n'historise pas les transitions rend ces mesures impossibles, ou approximatives.
Le modèle de liens : un lien « parent-enfant » unique contraint la hiérarchie ; un lien « lié » libre ouvre le chaos. Le lien ticket ↔ changeset/commit est la clé de la traçabilité réglementaire et de l'audit.

Coût total de possession (TCO)#

Ne comparer que le prix par siège est une erreur. Poste par poste, pour un horizon de 3 ans :

Poste	À chiffrer	Piège
Licences	par utilisateur, par palier, apps tierces	les utilisateurs « parties prenantes » sont gratuits dans Azure DevOps (accès Stakeholder, aux fonctions limitées) mais payants ailleurs (invités de Linear réservés au palier Business) : à vérifier outil par outil
Administration	temps de l'administrateur par mois	un Jira sur-personnalisé exige un quasi temps plein
Hébergement	serveurs, sauvegardes, mises à jour (on-prem)	oubli de l'astreinte de montée de version
Migration	outils, nettoyage, perte d'historique	l'historique des liens est le plus dur à conserver
Formation	initiale et continue	souvent oubliée dans le budget
Sortie	export de ses données	réversibilité : tester l'export avant de signer

Réversibilité et lock-in#

⚠️ Piège

Symptôme : après 4 ans d'usage, impossible de quitter l'outil sans perdre l'historique des décisions. Cause : champs et workflows spécifiques, liens vers des objets propriétaires (builds, changesets). Remède : exporter régulièrement vers un format neutre (CSV, JSON via API REST), garder la documentation durable hors outil (ADR, wiki versionné), et ne pas stocker de décision uniquement en commentaire de ticket.

Dépendances d'un projet data/BI#

Un projet de datamart et de rapports comporte des éléments que les outils pensés pour le logiciel couvrent mal :

Élément data	Besoin	Réponse outillée
Recette sur chiffres (écart ≤ seuil entre ancien et nouveau rapport)	critère d'acceptation chiffré, preuve jointe	champ « critère de recette » + tâche de test liée ; voir recette et validation
Kit d'installation versionné	lien ticket → version livrée	champ « version cible » ou iteration path ; voir GDS et données SQL/BI
Incident de donnée	type différent du bug logiciel (fraîcheur, rejet)	type de ticket dédié, SLA de correction
Migrations de schéma	séquencement, rollback	tâches liées en prédécesseur/successeur
Documentation générée	traçabilité des métadonnées	lien vers wiki/pipeline de documentation

Voir aussi Scrum et data pour l'adaptation des rituels.

🤖 IA

Les outils intègrent des assistants (résumé, rédaction de stories, déduplication). Utiles pour réduire l'effort de saisie, jamais pour trancher la priorité ni l'acceptation. Voir IA et outils.

🔴 Expert — Méthode de décision en cinq étapes#

Cadrer le besoin réel : taille, contraintes (on-premise, souveraineté, audit), flux (Scrum, Kanban, hybride). Écrire 10 « histoires » d'usage.
Pondérer les critères avant toute démonstration (table ci-dessus).
Présélectionner 2 ou 3 outils, jamais 6 ; éliminer sur contraintes dures (on-premise, droits d'export).
Pilote de 2 à 4 semaines sur une équipe volontaire, avec un jeu de données réel (50 à 100 éléments migrés).
Décider et planifier la sortie : date de bascule, gel de l'ancien outil en lecture seule, plan d'archivage.

💡 Astuce d'expert

Un excellent signal de maturité : l'équipe sait dire ce qu'elle ne mesurera pas. Chaque rapport créé est un coût de maintenance et un risque de pilotage par la cible (loi de Goodhart, voir métriques).

Voir aussi#

✻ Rédigé par Claude Sonnet 5.5