-- Mes preuves --

PMT qui était une étude de cas d’examen avait quelque chose d'un peu particulier dans cet examen : développer un outil de gestion de projet en appliquant soi-même les principes de gestion de projet qu'on était en train d'implémenter. PMT demandait de couvrir l'inscription, la connexion, la création de projets, la gestion des rôles, les tâches avec priorités, l'historique des modifications et les notifications par e-mail. Un scope large, conduit seul, dans un délai contraint. La planification a été la condition de survie du projet. Dès le début, les user stories ont été découpées en issues GitHub avec des labels, des priorités et un ordre de traitement pensé pour éviter les blocages : les entités de base d'abord (utilisateurs, projets), les relations ensuite (rôles, memberships), puis les fonctionnalités qui dépendent de ces fondations (tâches, historique, notifications). Chaque commit lié à son issue, chaque branche correspondant à une fonctionnalité isolée. Ce workflow n'était pas une contrainte de l'énoncé à respecter mécaniquement, c'était le seul moyen de ne pas perdre le fil sur un projet aussi dense. ShopWise était une étude de cas d’examen posait un problème de séquençage. Trois modules fonctionnels interdépendants : la gestion des clients, la gestion des rendez-vous, et la fidélisation par points. Le module de fidélisation dépendait des clients. La fidélisation dépendait des rendez-vous. Commencer par le mauvais module, c'était se retrouver à réécrire des fondations en cours de route. La planification a consisté à tracer les dépendances avant d'écrire la première ligne de code : schéma de base de données conçu en premier, entités JPA définies dans l'ordre des relations, endpoints construits du plus simple au plus complexe. Les issues GitHub ont matérialisé cette logique : chaque tâche indiquait clairement de quoi elle dépendait, ce qui permettait de savoir à tout moment où en était le projet et ce qui restait à faire. Livré dans les délais, testé à 60% de couverture, dockerisé et documenté. InnotechFusion était une étude de cas d’entrainement qui était extrême. Le délai était minimal, les livrables nombreux : application fonctionnelle, tests, Docker, pipeline CI/CD, document d'architecture, schéma V2. Tout livrer sans planifier, c'était garantir d'oublier quelque chose ou de passer trop de temps sur la mauvaise tâche. La planification dans ce contexte a pris une forme différente : pas d'outil sophistiqué, mais une hiérarchie claire des priorités. Ce qui bloque tout le reste en premier (schéma de base de données, structure du projet), ce qui est indépendant et peut avancer en parallèle ensuite (Docker, pipeline), ce qui se fait en dernier parce que ça ne débloque rien d'autre (documentation, schéma V2). Cette hiérarchie mentale, posée avant de commencer, a permis de livrer l'ensemble dans les délais sans se retrouver à la fin avec un Docker manquant ou une pipeline non configurée.

-- Autocritique --

La planification est une compétence qui progresse à chaque projet, et les erreurs de débutant sont bien identifiées. La tendance initiale : sous-estimer les tâches qui semblent simples et ne pas anticiper les dépendances cachées. Une migration de schéma qui "prend cinq minutes" et qui en prend quarante parce que les données de test ne correspondent plus. Un endpoint qui semble trivial et qui nécessite de refactoriser un service entier parce que la logique métier n'avait pas été isolée correctement. Ce qui s'est amélioré d'un projet à l'autre : le réflexe de modéliser les dépendances avant de coder, l'habitude de créer les issues avant de toucher au code, la discipline de lier chaque commit à sa tâche. Ces pratiques ne sont pas naturelles au départ. Elles s'installent par répétition, et surtout par les fois où on ne les a pas appliquées et où ça s'est vu. Ce qui reste à travailler : l'estimation. Savoir qu'une tâche dépend d'une autre, c'est acquis. Savoir combien de temps elle va prendre avec un niveau d'erreur raisonnable, c'est encore perfectible. Sur des projets conduits seul en conditions d'examen, l'estimation se fait à l'instinct. Sur un vrai projet en équipe, avec des engagements client et des sprints à tenir, cet instinct doit devenir une méthode. C'est la prochaine étape. La planification est une compétence centrale dans le profil actuel. Elle conditionne la qualité de toutes les autres : un développeur qui code sans planifier livre en retard ou livre incomplet. Le niveau actuel permet de conduire un projet de bout en bout sans se perdre. La marge de progression porte essentiellement sur la précision des estimations et la gestion des imprévus en cours de sprint.

-- Évolution --

L'estimation est le chantier prioritaire. Apprendre à décomposer une tâche jusqu'au niveau où elle est estimable avec précision, utiliser des techniques comme le planning poker ou les story points de manière consciente plutôt que mécanique, tenir un historique de ses estimations pour les calibrer dans le temps : ce sont des pratiques qui s'apprennent sur le terrain, en équipe, sur des projets qui durent. La gestion des imprévus en cours de planification est le deuxième axe. Quand une tâche estimée à deux heures en prend six, comment réajuster le plan sans tout faire tomber ? Identifier ce qui peut être repoussé sans impact, ce qui est bloquant pour d'autres et doit rester prioritaire, ce qui peut être simplifié pour tenir le délai : ce type de décision se prend mieux quand on a un plan clair que quand on improvise. Dans le cadre du projet de société de développement logiciel, la planification sera une compétence critique à un niveau différent : planifier pour soi-même, mais aussi pour des clients, des équipes, des délais contractuels. C'est un registre plus exigeant que le projet académique, et c'est précisément ce qui rend la progression sur cette compétence aussi importante que la progression technique.

-- Projets liés --