-- Définition --
Prioriser, c'est décider ce qui compte le plus quand tout semble urgent. Dans un contexte de développement logiciel, c'est la capacité à distinguer ce qui bloque les autres tâches de ce qui peut attendre, ce qui apporte de la valeur immédiate de ce qui est secondaire, ce qui est indispensable pour livrer de ce qui est un nice-to-have. Sans cette capacité, un développeur passe du temps sur les mauvaises choses et livre ce qui ne comptait pas vraiment.
Pour un junior, la priorisation est l'une des premières compétences où l'on se retrouve seul face à ses choix. Le Product Owner donne les user stories, mais c'est le développeur qui décide dans quel ordre les implémenter techniquement, quelle dette technique traiter maintenant plutôt que plus tard, quel bug corriger avant de continuer à avancer. Ces décisions ont des conséquences directes sur la qualité du livrable et sur la tenue des délais.
En 2025, les équipes agiles modélisent la priorisation via des backlogs ordonnés, des matrices d'impact/effort, des définitions of done et des critères d'acceptance. Des outils comme GitHub Projects ou Linear permettent de visualiser et de réordonner les priorités en temps réel. Mais derrière les outils, c'est toujours un jugement humain qui décide : qu'est-ce qui a le plus de valeur maintenant, dans ce contexte précis, avec ces contraintes précises.
-- Mes preuves --
PMT qui était une étude de cas d’examen couvrait un périmètre fonctionnel dense : inscription, connexion, projets, rôles, tâches avec priorités, historique des modifications, notifications par e-mail. Tout implémenter dans le désordre aurait été une catastrophe. Les notifications par e-mail ne peuvent pas être testées si les tâches n'existent pas. Les tâches ne peuvent pas être assignées si les membres ne sont pas gérés. Les membres ne peuvent pas avoir de rôles si les projets n'existent pas.
La priorisation s'est donc imposée comme une contrainte technique autant que organisationnelle. Les entités fondamentales en premier : utilisateurs, projets, la relation d'appartenance avec son attribut de rôle. Les fonctionnalités qui s'appuient sur ces fondations ensuite : création de tâches, assignation, mise à jour. L'historique et les notifications en dernier, parce qu'ils enrichissent une application déjà fonctionnelle sans en être les prérequis. Ce séquençage a permis d'avoir une application testable et démontrable à chaque étape, pas seulement à la toute fin.
ShopWise était une étude de cas d’examen ajoutait une dimension supplémentaire à la priorisation : les user stories avaient une logique métier claire, et cette logique devait guider l'ordre d'implémentation. Un commerçant ne peut pas créer un rendez-vous sans avoir d'abord un client. Des points de fidélité ne peuvent pas être attribués sans un rendez-vous honoré. La priorisation technique et la priorisation métier convergeaient vers le même ordre : clients d'abord, rendez-vous ensuite, fidélisation en dernier.
Mais la priorisation s'est aussi exprimée dans les compromis. Avec un délai contraint et une couverture de tests à atteindre, il a fallu choisir : tester en priorité les règles métier critiques (l'attribution automatique de points, l'irréversibilité du statut d'un rendez-vous annulé) plutôt que de disperser l'effort de test sur des endpoints CRUD basiques. Ce choix de priorisation dans les tests a permis d'atteindre le seuil de 60% requis tout en couvrant ce qui avait vraiment de la valeur.
-- Autocritique --
La priorisation est une compétence que les projets d'examen ont forcée à développer, mais pas toujours de manière consciente. Au début, la priorisation se faisait par instinct : on commençait par ce qui semblait "logique" sans forcément formaliser pourquoi. Avec le recul, certains choix d'ordre étaient bons pour les mauvaises raisons, et d'autres auraient pu être meilleurs avec un peu plus de recul.
Ce qui est acquis : le réflexe de tracer les dépendances techniques avant de coder, la capacité à identifier ce qui est bloquant pour d'autres tâches et doit passer en premier, la discipline de ne pas s'attaquer aux fonctionnalités périphériques avant que le cœur soit solide. Ces réflexes ont été mis en pratique sur plusieurs projets et ont produit des résultats mesurables : des applications livrées complètes, dans les délais, avec les fonctionnalités principales fonctionnelles.
Ce qui manque encore : la priorisation en situation de conflit. Quand deux tâches sont également critiques, quand le client veut une fonctionnalité et que la dette technique crie à être traitée en même temps, quand le délai force à choisir entre qualité et périmètre : ces situations de tension ne se sont pas vraiment présentées dans un contexte académique où le périmètre est fixé à l'avance. C'est sur des projets réels, avec de vrais arbitrages, que cette dimension de la priorisation se travaillera.
-- Évolution --
L'objectif à court terme est de formaliser ce qui est aujourd'hui encore trop intuitif. Apprendre à utiliser une matrice impact/effort de manière systématique, pas seulement quand la situation est complexe mais comme réflexe de départ sur chaque nouveau projet. Se forcer à noter explicitement pourquoi une tâche passe avant une autre, pour pouvoir relire cette décision plus tard et calibrer le jugement.
La priorisation en contexte client est le prochain registre à explorer. Prioriser pour soi-même sur un projet personnel, c'est une chose. Prioriser pour un client qui a des attentes, des contraintes budgétaires et une vision parfois floue de ce qu'il veut vraiment, c'est une compétence différente qui mobilise autant l'écoute et la négociation que le jugement technique.
Dans le cadre du projet de société de développement logiciel, la priorisation sera une compétence de survie. Gérer plusieurs projets en parallèle, arbitrer entre les demandes de différents clients, décider quelles fonctionnalités méritent un investissement de qualité et lesquelles peuvent rester simples : ce sont des décisions quotidiennes qui détermineront la viabilité de la structure. La progression sur cette compétence n'est pas optionnelle, elle est au cœur du modèle.
-- Projets liés --