- Description
- Ruban à mesurer déroulé en diagonale sur une table de bois.
- Source
- Douglas Perkins · page d’origine
- Licence
- CC0 Domaine public
Comparatif des outils de planification
Une grille de notes /5 sur neuf critères pour dix outils, avec sa justification et son contexte.
En bref
- Une grille de notes /5 sur neuf critères pour dix outils, avec sa justification et son contexte.
- Une heatmap lisible, un score pondéré modifiable selon vos priorités.
- Des recommandations par contexte, dont le cas « projet data/BI on-premise avec TFVC ».
- Une méthode pour refaire la grille avec vos propres poids : la grille est un outil de discussion, pas un verdict.
Contexte de toutes les notes : équipe de 5 à 15 personnes, projet data/BI (datamart SQL Server alimenté par une application terrain, rapports Power BI, versionnement TFVC, livraison en kits). Ce sont des appréciations d'expert, contextuelles (voir NOTATION) ; les offres et licences évoluent (état 2026-10, à revérifier). Détails : panorama, Azure DevOps, Jira et alternatives.
Niveau : 🟢→🔴
🟢 Novice — Comment lire la grille#
Neuf critères (cf. le dossier) :
| Code | Critère | Ce que veut dire une note haute |
|---|---|---|
| FLX | Flexibilité du modèle | on représente nos types, états et liens sans contorsion |
| REP | Reporting | burndown, flux, tendances sans effort ; connexion à Power BI |
| INT | Intégration code/CI | lien ticket ↔ code ↔ build ↔ déploiement, dans notre GDS |
| COÛ | Coût | coût total bas pour le contexte (5 = très économique) |
| ADO | Adoption | facile à prendre en main, connu des équipes et des métiers |
| GOU | Gouvernance | droits, audit, séparation des rôles, conformité |
| ÉCH | Passage à l'échelle | tient de 5 à 500 utilisateurs, multi-équipes |
| PRO | Personnalisation du processus | adapte workflows et champs sans développement |
| API | Extensibilité / API | REST, webhooks, extensions, scripts |
Les notes sont relatives au contexte décrit ci-dessus. Un Linear à 2/5 en intégration code reflète l'absence de TFVC, pas un défaut général ; pour une équipe 100 % Git/GitHub, la note monterait à 4/5.
🟡 Pratique — La grille de notes#
| Outil | FLX | REP | INT | COÛ | ADO | GOU | ÉCH | PRO | API | Moyenne simple |
|---|---|---|---|---|---|---|---|---|---|---|
| Azure DevOps Server (on-prem) | 4 | 4 | 5 | 4 | 3 | 4 | 4 | 4 | 4 | 4,0 |
| Azure DevOps Services (SaaS) | 4 | 4 | 5 | 4 | 3 | 4 | 4 | 4 | 4 | 4,0 |
| Jira Cloud | 5 | 4 | 3 | 3 | 4 | 4 | 4 | 5 | 5 | 4,1 |
| GitLab (auto-hébergé ou SaaS) | 3 | 3 | 3 | 4 | 3 | 4 | 4 | 3 | 4 | 3,4 |
| GitHub Projects | 3 | 2 | 2 | 4 | 4 | 3 | 3 | 3 | 4 | 3,1 |
| Linear | 2 | 3 | 2 | 3 | 5 | 3 | 3 | 2 | 4 | 3,0 |
| Trello | 2 | 1 | 1 | 5 | 5 | 2 | 2 | 2 | 3 | 2,6 |
| Asana / Monday | 3 | 3 | 1 | 3 | 5 | 3 | 4 | 3 | 3 | 3,1 |
| Notion | 4 | 1 | 1 | 4 | 4 | 2 | 2 | 4 | 3 | 2,8 |
| YouTrack | 4 | 3 | 3 | 4 | 3 | 3 | 3 | 4 | 4 | 3,4 |
| Redmine | 3 | 2 | 3 | 5 | 2 | 3 | 3 | 3 | 3 | 3,0 |
| Rally / Jira Align (échelle) | 3 | 5 | 2 | 1 | 2 | 5 | 5 | 3 | 3 | 3,2 |
Justifications des écarts notables :
- Azure DevOps : INT 5/5 car l'association ticket ↔ changeset TFVC est native (et rendable obligatoire) ; ADO 3/5 car l'interface est moins plébiscitée et moins connue des métiers.
- Jira Cloud : meilleure flexibilité/API (5/5), mais INT 3/5 faute d'intégration native avec TFVC ; COÛ 3/5 (par siège, apps en sus) ; en on-premise, Data Center disparaît en 2029 (voir Jira).
- GitHub Projects / Linear : excellents quand le code est sur Git/GitHub, ici pénalisés par TFVC et par un reporting plus léger.
- Trello / Notion : très simples, mais REP 1/5 : ils ne gardent pas l'historique d'état exploitable pour lead/cycle time.
- Rally / Jira Align : COÛ 1/5 : justifiés seulement à partir de beaucoup d'équipes.
La moyenne simple est trompeuse : un outil à 5 partout sauf un critère éliminatoire (par exemple, pas d'on-premise) ne vaut rien. Séparez critères éliminatoires (contraintes dures) et critères de classement (notes).
🟡 Pratique — Heatmap#
Légende : 🟩 5 · 🟢 4 · 🟨 3 · 🟧 2 · 🟥 1.
| Outil | FLX | REP | INT | COÛ | ADO | GOU | ÉCH | PRO | API |
|---|---|---|---|---|---|---|---|---|---|
| Azure DevOps Server | 🟢 | 🟢 | 🟩 | 🟢 | 🟨 | 🟢 | 🟢 | 🟢 | 🟢 |
| Azure DevOps Services | 🟢 | 🟢 | 🟩 | 🟢 | 🟨 | 🟢 | 🟢 | 🟢 | 🟢 |
| Jira Cloud | 🟩 | 🟢 | 🟨 | 🟨 | 🟢 | 🟢 | 🟢 | 🟩 | 🟩 |
| GitLab | 🟨 | 🟨 | 🟨 | 🟢 | 🟨 | 🟢 | 🟢 | 🟨 | 🟢 |
| GitHub Projects | 🟨 | 🟧 | 🟧 | 🟢 | 🟢 | 🟨 | 🟨 | 🟨 | 🟢 |
| Linear | 🟧 | 🟨 | 🟧 | 🟨 | 🟩 | 🟨 | 🟨 | 🟧 | 🟢 |
| Trello | 🟧 | 🟥 | 🟥 | 🟩 | 🟩 | 🟧 | 🟧 | 🟧 | 🟨 |
| Asana / Monday | 🟨 | 🟨 | 🟥 | 🟨 | 🟩 | 🟨 | 🟢 | 🟨 | 🟨 |
| Notion | 🟢 | 🟥 | 🟥 | 🟢 | 🟢 | 🟧 | 🟧 | 🟢 | 🟨 |
| YouTrack | 🟢 | 🟨 | 🟨 | 🟢 | 🟨 | 🟨 | 🟨 | 🟢 | 🟢 |
| Redmine | 🟨 | 🟧 | 🟨 | 🟩 | 🟧 | 🟨 | 🟨 | 🟨 | 🟨 |
| Rally / Jira Align | 🟨 | 🟩 | 🟧 | 🟥 | 🟧 | 🟩 | 🟩 | 🟨 | 🟨 |
🟡 Pratique — Score pondéré et sensibilité#
Score = Σ (poids × note) / Σ poids. Exemple avec les poids du panorama pour un projet data/BI on-premise (FLX 12, REP 14, INT 15, COÛ 10, ADO 10, GOU 10, ÉCH 6, PRO 10, API 8 ; somme 95, normalisée ci-dessous) :
| Outil | Score pondéré /5 (arrondi) | Lecture |
|---|---|---|
| Azure DevOps Server | 4,05 | ex æquo en tête : INT et REP pèsent lourd |
| Jira Cloud | 4,05 | très flexible, mais pénalisé par l'intégration TFVC et le coût ; et non disponible on-premise de façon durable |
| YouTrack | 3,4 | bon rapport, écosystème plus petit |
| GitLab | 3,4 | solide si le code migre vers Git |
| Rally / Jira Align | 3,2 | pertinent seulement à l'échelle |
| GitHub Projects | 3,0 | bon pour équipes Git |
| Asana / Monday | 3,0 | adoption forte, intégration faible |
| Redmine | 3,0 | économique, ergonomie |
| Linear | 2,9 | élégant, peu adapté ici |
| Notion | 2,7 | ne tient pas la mesure du flux |
| Trello | 2,4 | complément, pas centre |
Le ex æquo Azure DevOps / Jira est instructif : la grille ne tranche pas, ce sont les critères éliminatoires (on-premise exigé, TFVC conservé) qui départagent, et ils désignent Azure DevOps Server dans ce contexte.
Variante de sensibilité : si l'on double le poids de l'adoption (équipes métier nombreuses), Jira prend l'avantage sur Azure DevOps. Si l'on supprime l'intégration code (code hors périmètre), les écarts se resserrent fortement. Conclusion : la hiérarchie dépend de deux poids, INT et ADO ; discuter ces deux poids avant toute chose.
Refaites le calcul dans un tableur avec les poids de votre équipe, et notez à côté de chaque score les trois hypothèses qui le sous-tendent. Un score sans hypothèses est invérifiable.
🔴 Expert — Recommandations par contexte#
| Contexte | Recommandation | Pourquoi | Vigilance |
|---|---|---|---|
| Projet data/BI on-premise, code en TFVC | Azure DevOps Server (Boards + Repos TFVC + Pipelines + Test Plans) | traçabilité native ticket ↔ changeset ↔ kit ; Power BI via Analytics ; pas de nouvelle plateforme | planifier la montée de version régulière ; envisager à moyen terme TFVC → Git (Git vs TFVC) |
| Équipe data 100 % Git (analytics engineering), SaaS autorisé | GitHub Projects ou GitLab ; Linear si culture produit | proximité du code, CI/CD, simplicité | reporting de flux limité : compléter par exports vers Power BI |
| Organisation multi-équipes, support + projets, SaaS autorisé | Jira Cloud (+ Jira Service Management) | flexibilité, écosystème, SLA | gouvernance du modèle ; coût des apps ; plan de sortie |
| On-premise obligatoire, hors Microsoft | GitLab auto-hébergé ; YouTrack ou Redmine pour petits besoins | Jira Data Center fin de vie 2029 | compétences d'exploitation |
| Petite équipe (≤ 5), peu de formalisme | Trello, GitHub Projects ou Azure Boards Basic | légèreté | éviter la prolifération d'outils |
| Recette métier avec nombreux non-techniciens | Trello/Asana/Monday pour la recette, outil technique pour le backlog | adoption des métiers | synchroniser le lien avec les tickets techniques |
| Grande échelle (SAFe, > 10 équipes) | Jira Align / Rally ou Azure DevOps Delivery Plans selon l'existant | dépendances, capacité inter-équipes | ne pas commencer par là |
| Contexte réglementé, audit fort | Azure DevOps (CMMI) ou Jira avec workflows contraints | traçabilité exigences ↔ tests ↔ livraisons | processus lourd : justifier chaque champ |
🔴 Cas détaillé : datamart SQL Server + rapports Power BI + TFVC + kits#
Le profil : équipe de ~8, backlog mixte (évolutions du modèle, nouveaux rapports multilingues, correctifs, support), livraison par kits d'installation versionnés, besoin de traçabilité (quels tickets dans quelle version), recette sur chiffres de référence, contrainte on-premise.
- Outil central : Azure DevOps Server. Arguments : lien ticket ↔ changeset obligatoire (check-in policy) → notes de version par requête ; Analytics + Power BI → tableaux de bord de flux et de qualité ; Test Plans → cas de test paramétrés pour la recette de chiffres ; Pipelines → construction du kit.
- Modèle de work items (processus hérité Scrum ou Agile) : Epic (thème), Feature (capacité livrable), PBI/Story, Task, Bug, + types dédiés : Incident de donnée, Recette. Champs : Version cible (liste de valeurs), Domaine (liste), Impact chiffres (oui/non).
- Organisation : 1 projet, 2 à 3 équipes (Datamart, Rapports, Support), area paths par domaine, iteration paths par sprint ; version = champ, pas itération.
- Rituels adaptés (Scrum et data) : sprints de 2 semaines, un flux Kanban séparé pour le support, limite de WIP.
- Mesure : cycle time (P85), âge des éléments, burnup de release, fraîcheur/rejet/écarts de recette (métriques).
- Hygiène : revue trimestrielle du backlog et du modèle de champs ; documentation de l'usage de l'outil dans le wiki.
- Horizon : suivre la trajectoire Microsoft (TFVC et Git), évaluer à 12–24 mois une migration vers Git si les outils de build, la formation et la gouvernance le permettent.
Sur un trimestre, l'équipe constate : 41 stories livrées, cycle time P85 = 9 jours, 7 bugs échappés (dont 5 écarts de chiffres), fenêtre de chargement respectée 97 % des nuits. La décision : renforcer les cas de test de recette sur les 2 mesures à l'origine de 5 écarts, plutôt qu'« accélérer ». Ce raisonnement n'est possible que si ticket, changeset, test et incident sont liés dans le même outil.
Symptôme : l'équipe choisit un outil « moderne » pour son confort, puis perd la traçabilité des livraisons. Cause : critère d'intégration au GDS pondéré trop bas. Remède : tester la chaîne complète (ticket → code → kit → test → livraison) sur un cas réel avant de décider.
🔴 Expert — Quand ne pas changer d'outil#
Changer d'outil est un chantier coûteux (migration d'historique, formation, double fonctionnement, outillage de reporting à refaire). Les raisons mauvaises : une démonstration séduisante, la mode, l'envie d'un tableau de bord plus joli. Les raisons bonnes : contrainte contractuelle ou réglementaire, fin de vie du produit, limite fonctionnelle bloquante démontrée sur cas réel, coût total sensiblement inférieur à horizon 3 ans.
Avant de migrer, tenter d'abord trois remèdes moins coûteux : (1) réduire le modèle (champs, états), (2) corriger les pratiques (liens, mise à jour), (3) mieux exploiter les fonctions existantes (Analytics, tableaux de bord). Voir pièges et bonnes pratiques.
🤖 Contribution de l'IA#
| Cas d'usage | Gain /5 | Risque /5 | Maturité /5 | Garde-fous |
|---|---|---|---|---|
| Produire une première grille de comparaison | 3 | 4 | 3 | vérifier chaque fait sur la documentation officielle ; l'IA se trompe sur tarifs et fonctions récentes |
| Rédiger des scénarios de pilote | 4 | 2 | 4 | relecture par l'équipe |
| Aider à migrer des exports (mapping de champs) | 3 | 3 | 3 | échantillon de contrôle, réconciliation de comptes |
Les fonctions IA des outils eux-mêmes sont traitées dans 11 — IA et outils.
Voir aussi#
- Panorama · Azure DevOps en profondeur · Jira et alternatives · Métriques et reporting
- TFVC en profondeur · Git vs TFVC · Choisir et hybrider les méthodes
- Gouvernance et pilotage (matrice) · Glossaire
✻ Rédigé par Claude Sonnet 5.5
